Thomas M. Connolly Carolyn E. Begg
PEARSON
Addison Wesley
Sistemas de bases de datos UN ENFOQUE
PRÁCTICO
PARA DISEÑO,
IMPLEMENTACIÓN
y
GESTIÓN
Cuarta edición
THOMAS M. CONNOLLY CAROLYN E. BEGG University 01Paisley
Traducción Vuelapluma
Madrid
e México e
Santafé de Bogotá e Buenos Aires e Caracas e Lima Montevideo e San Juan e San José e Santiago e Sao Paulo Reading e Massachusetts e Harlow e England
Datos de catalogación
SISTEMAS Connolly, Pearson
bibliográfica
DE BASES DE DATOS T. M.; Begg, C. E.
Educación
S.A., Madrid,
2005
ISBN: 84-7829-075-3 Materia: Formato:
Informática,
681.3
195 x 250 mm.
Páginas:
1320
Todos los derechos reservados. Queda prohibida, salvo excepción prevista en la Ley, cualquier forma de reproducción, distribución, comunicación pública y transformación de esta obra sin contar con autorización de los titulares de propiedad intelectual. La infracción de los derechos mencionados puede ser constitutiva de delito contra la propiedad intelectual (arts. 270 y sgts. Código Penal).
DERECHOS RESERVADOS © 2005 por PEARSON EDUCACIÓN S.A. Ribera del Loira, 28 28042 Madrid
SISTEMAS DE BASES DE DATOS Connolly, T. M.; Begg, C. E. ISBN: 84-7829-075-3 Depósito Legal: M-30.815-2005 ADDISON WESLEY es un sello editorial autorizado de PEARSON EDUCACIÓN
S.A.
© Pearson Education Limited 1995,2005 This translation ofDATABASE SYSTEMS -APRACTICALAPPROACH TO DESIGN, IMPLEMENTATION AND MANAGEMENT 04 Edition is published by arrangement with Pearson Education Limited, United Kingdom Equipo editorial Editor: Miguel Martín-Romo Técnico editorial: Marta Caicoya Equipo de producción Director: José A. Clares Técnico:Tini Cardoso Diseño de cubierta: Equipo de diseño de Pearson Educación S.A. Impreso por: Gráficas Rógar IMPRESO EN ESPAÑA - PRlNTED IN SPAIN Este libro ha sido impreso con papel y tintas eco lógicos
\ Prefacio
XXXIII
.
Parte 1 Introducción Capítulo
1 Introducción
a las bases de datos
Introducción
1.2
Sistemas tradicionales
1.4
1.5
1
.
1.1
1.3
3 4
1.2.1
La técnica
1.2.2
Limitaciones
basados en archivos
basada en archivos de la técnica
....
basada en archivos
6 7 11
Sistemas de bases de datos
13
1.3.1
La base de datos
14
1.3.2
Sistema de gestión de base de datos (SGBD)
15
1.3.3
Programa de aplicación
16
1.3.4
Componentes
1.3.5
Diseño de bases de datos: un cambio en el paradigma
de un entorno
Papeles en un entorno 1.4.1
Administradores
1.4.2
Diseñadores
SGBD
de base de datos de datos y de la base de datos
de bases de datos
1.4.3
Desarrolladores
1.4.4
Usuarios finales
de aplicaciones
y desventajas
17 19 20 20 20 21 21
Historia de los sistemas de gestión de bases de datos
1.6 Ventajas
de los SGBD
22 24
28
Resumen Cuestiones
29 30
de repaso
Ejercicios Capítulo 2 El entorno de la base de datos 2.1
Contenido
La arquitectura
31
en tres niveles de ANSI-SPARC
32
2.1.1
Nivel externo
33
2.1.2
Nivel conceptual
33
2.1.3
Nivel interno
34
2.1.4
Esquemas, asignaciones
e instancias
34
XII
Sistemas de bases de datos 2.1.5
Independencia de los datos
36
2.2 Lenguajes de base de datos 2.2.1
37
El lenguaje de definición de datos (DDL)
2.2.2
El lenguaje de manipulación de datos (DML)
2.2.3
Lenguajes de cuarta generación (4GL)
37 37 -.-.-
2.3 Modelos de datos y modelado conceptual
39 40
2.3.1
Modelos de datos basados en objetos
41
2.3.2 2.3.3
Modelos de datos basados en registros Modelos de datos físicos
41 43
2.3.4 Modelado conceptual 2.4 Funciones de un SGBD
43 44
2.5 Componentes de un SGBD
48
2.6 Arquitecturas de SGBD multiusuario
51
2.6.1
Teleprocesamiento
51
2.6.2
Arquitectura de servidor de archivos
51
2.6.3
Arquitectura cliente-servidor tradicional en dos niveles
52
2.6.4
Arquitectura cliente-servidor en tres niveles
55
2.6.5
Monitores de procesamiento de transacciones
56 57
Resumen Cuestiones
de repaso
59 59
Ejercicios
Parte 2 El modelo relacional y los lenguajes relacionales Capítulo 3 Introducción a las bases de datos 3.1 Breve historia del modelo relacional 3.2 Terminología 3.2.1 Estructuras de datos relacionales
61 63 64 65 65
3.2.2
Relaciones matemáticas
68
3.2.3
Relaciones en una base de datos
68
3.2.4 3.2.5
Propiedades de las relaciones Claves relacionales
69 70
3.2.6
Representación de esquemas de base de datos relacional
72
3.3 Restricciones de integridad 3.3.1 Valores nulos
72 72
3.3.2
Integridad de entidad
74
3.3.3
Integridad referencial
74
Restricciones generales
75 75
3.4.1
Terminología
75
3.4.2 3.4.3
Propósito de las vistas Actualización de las vistas
76 76
3.3.4 3.4 Vistas
Contenido
77
Resumen Cuestiones
77
de repaso
78
Ejercicios
Capítulo 4 Álgebra relacional y cálculo relacional 4.1
4.2
4.3
_._._
79
El álgebra relacional
80
4.1 .1
Operaciones
unarias
80
4.1.2
Operaciones
de conjuntos
82
4.1.3
Operaciones
de combinación
4.1.4
Operación
4.1.5
Operaciones
4.1.6
Resumen de las operaciones
..
de división
86 89
de agregación
y de agrupamiento de álgebra relacional
El cálculo relacional
90 92 93
4.2.1
Cálculo relacional
de tuplas
.
93
4.2.2
Cálculo relacional
de dominios
96
Otros lenguajes
98
Resumen
98
Cuestiones
99 99
de repaso
Ejercicios
Capítulo 5 SQL: manipulación 5.1
XIII
Introducción
101
de datos
a SOL
102
5.1.1
Objetivos
5.1.2
Historia de SOL
de SOL
103
102
5.1.3
Importancia
104
5.1.4
Terminología
de SOL
105
5.2
Escritura de comandos
5.3
Manipulación
SOL
105
de datos
5.3.1
Consultas
5.3.2
Ordenación
106
simples
107
de los resultados
(cláusula ORDER BY)
5.3.3
Utilización
de las funciones
5.3.4
Agrupación
de resultados
5.3.5
Subconsultas
121
5.3.6
ANY
123
5.3.7
Consultas
Y
multitabla
5.3.8
EXISTS y NOT EXISTS Combinación EXCEPT) Actualizaciones
Cuestiones
de tablas de resultados
116 118
125 130 (UNION, INTERSECT, 131
de la base de datos
134
138
Resumen
Ejercicios
de SOL
(cláusula GROUP BY)
ALL
5.3.9 5.3.10
de agregación
114
de repaso
139 139
XIV
Sistemas de bases de datos Capítulo 6 SOL: definición 6.1
6.2
6.3
6.4
6.5
141
~.
Tipos de datos SOL de ISO
.
142
6.1.1
Identificadores
.
142
6.1.2
Tipos de datos SOL escalares
.
143
6.1.3
Datos numéricos
.
144
.
147
Características
SOL
exactos
de mejora de la integridad
6.2.1
Datos requeridos
.
147
6.2.2
Restricciones
.
147
6.2.3
Integridad
de entidades
.
149
6.2.4
Integridad
referencial
.
149
6.2.5
Restricciones
.
150
.
151
Definición
de dominio
generales
de datos
6.3.1
Creación de una base de datos
.
151
6.3.2
Creación de una tabla (CREATE TABLE)
.
152
6.3.3
Modificación
.
155
6.3.4
Eliminación
de una tabla (DROP T ABLE)
.
156
6.3.5
Creación de un índice (CREATE INDEX)
.
157
6.3.6
Eliminación
.
158
de la definición
de una tabla (ALTER T ABLE)
de un índice (DROP INDEX)
158
Vistas 6.4.1
Creación de una vista (CREA TE VIEW)
6.4.2.
Eliminación
de una vista (DROP VIEW) de vistas
6.4.3
Resolución
6.4.4
Restricciones
de las vistas
6.4.5
Actualización
de vistas
6.4.6
WITH CHECK OPTION
6.4.7
Ventajas
6.4.8
Materialización
.
.
161
.
162 .
163 .
y desventajas
de las vistas
de vistas
de integridad
inmediatas
.
165 167 168
e inferidas
Control de acceso discrecional 6.6.1
Concesión
6.6.2
Revocación
de privilegios
a otros usuarios
de privilegios
(GRANTI
de los usuarios (REVOKE)
Resumen Cuestiones
de repaso
Ejercicios
164
. .
Restricciones
158 161
Transacciones 6.5.1
6.6
de datos
.
169
.
169
.
171
.
172 .
174
.
175
.
175 179
Capítulo 7 OSE
7.1
Introducción
7.2
Diseño de consultas
a las consultas
en Microsoft
de selección
7.2.1
Especificación
7.2.2
Creación de consultas
mediante
de criterios multitabla
Of?ce Access OBE
.
180
.
182
.
182
.
186
Contenido 7.2.3 7.3
7.4
Cálculo de totales
Utilización
de consultas
.
188 189
7.3.1
Consultas
7.3.2
Consulta
7.3.3
Consultas
7.3.4
Consulta de localización
7.3.5
Consultas
Modificación
186
avanzadas
paramétricas matricial
...
190
de localización
de duplicados
192
de no correspondencias
194
de autobúsqueda
del contenido
de las tablas mediante
7.4.1
Consultas
7.4.2
Consulta de acción de borrado
consultas
7.4.3
Consulta de acción de actualización Consulta de acción de adición
195 195 199
199 .
199
"
Capítulo 8 Bases de datos comerciales:
8.2
195
.
7.4.4
Microsoft
. de acción
de acción para creación de tablas
Ejercicios
8.1
.
Office Access y Oracle
Objetos
202
205
.
Office Access 2003
8.1.1
xv
205 .
206
8.1.2
Arquitectura
8.1.3
Definición
de tablas
de Microsoft
Of?ce Access
8.1.4
Definición
de relaciones
8.1.5
Definición
de restricciones
206 .
y de integridad
referencial
generales
208 213
.
213
.
8.1.6
Formularios
.
215
8.1.7
Informes
.
217
8.1.8
Macros
8.1 .9
Dependencias
.
218
entre objetos
221
.
Oracle9i 8.2.1
Objetos
8.2.2
Arquitectura
8.2.3
Definición
de tablas
8.2.4
Definición
de restricciones
8.2.5
PL/SQL
.
221
.
223
de Oracle
224
....
230 233
generales .
8.2.6
Subprogramas,
8.2.7
Disparadores
procedimientos
8.2.8
Oracle Internet
8.2.9
Otras funcionalidades
8.2.10
Oracle10g
almacenados,
funciones
233
.
244
de Oracle
248 .
248
de repaso
Parte 3 Técnicas de análisis y diseño de bases de datos .... Capítulo 9 Planificación,
240
Suite
Developer
Resumen Cuestiones
239
y paquetes
diseño y administración
de bases de datos
.
252
.
253
255 .
257
Contenido 10.4 Ejemplo de utilización de técnicas de determinación de hechos 10.4.1 El caso de estudio de DreamHome:
panorámica
10.4.2 El caso de estudio de DreamHome: de datos
planificación de la base
10.4.3 El caso de estudio de DreamHome:
definición del sistema
10.4.4 El caso de estudio de DreamHome: requisitos 10.4.5 El caso de estudio de DreamHome:
recopilación y análisis de
293 293 298
diseño de la base de datos
302
..
303 311 311
Resumen Cuestiones
XVII
311
de repaso
312
Ejercicios
Capítulo 11 Modelado entidad-relación
313
11 .1 Tipos de entidad
314
11.2 Tipos de relación
316
11.2.1 Grado de un tipo de relación 11.2.2 Relación recursiva 11.3 Atributos
319
11.3.1 Atributos simples y compuestos
320
11.3.2 Atributos univaluados y multivaluados 11.3.3 Atributos derivados
321 321
11.3.4 Claves
322
11.4 Tipos de entidad fuertes y débiles
323
11.5 Atributo~de las relaciones 11.6 Restricciones estructurales
324 324
11.6.1 Relaciones uno a uno (1: 1)
325
11.6.2 Relaciones uno a muchos (1: *)
326
11.6.3 Relaciones muchos a muchos (*:*)
328
11.6.4 Multiplicidad para relaciones complejas
329
.11.6.5 Restricciones de cardinalidad y de participación 11.7 Problemas con los modelos ER
330 331
11.7.1 Trampas multiplicativas
331
11.7.2 Trampas de corte
333 334
Resumen Cuestiones
336
de repaso
336
Ejercicios
Capítulo
318 318
12 Modelado entidad-relación
avanzado
12.1 Especialización/Generalización
339 340
12.1.1 Superclases y subclases
340
12.1.2 Relaciones superclase y subclase 12.1.3 Herencia de atributo
340 341
XVIII
Sistemas de bases de datos 12.1.4
Proceso de especialización
342
12.1.5
Proceso de generalización
342
12.1.6
Restricciones
344
12.1.7
Utilización de las técnicas de especialización/generalización modelar la vista Branch del caso de estudio DreamHome
a la especialización/generalización para
346
12.2
Agregación
350
12.3
Composición
350
Resumen
352
Cuestiones
352
de repaso
352
Ejercicios
Capítulo
13 Normalización 13.1 El propósito de la normalización 13.2
Cómo ayuda la normalización
13.3
Redundancia
13.4
353
.
354
.
354
al diseño de bases de datos
355
de los datos y anomalías de actualización
356
13.3.1
Anomalías
de inserción
13.3.2
Anomalías
de borrado
13.3.3
Anomalías
de modificación
Dependencias
357
.
funcionales de las dependencias
Características
.
358
funcionales.
13.4.2
Identificación
de dependencias
13.4.3
Identificación
de la clave primaria de una relación utilizando
funcionales
362
....
364
funcionales
13.5
El proceso de normalizaclPn
.
365
13.6
Primera forma normal (1 NF)
.
367
13.7
Segunda forma normal (2NF)
13.8
Tercera forma normal (3NF)
13.9
Definiciones
370 372
.
generales de las formas 2NF y 3NF
Resumen Cuestiones
de r@paso
Ejercicios
Capítulo
357
358
13.4.1
las dependencias
.
.
14 Normalización 14.1
14.2
Más aspectos
avanzada relativos
a las dependencias
14.1.1
Reglas de inferencia
14.1.2
Conjuntos
Definición
funcionales
funcionales
(BCNF)
.
Revisión del proceso de normalización
14.4
Cuarta forma normal (4NF)
.
14.4.1
Dependencia
.
14.4.2
Definición
multivaluada
.
376 376
379 380 382 383
385
hasta BCNF
de cuarta forma normal
.
383
de la forma normal de Boyce-Codd
14.3
374
375
380
funcionales
para dependencias
mínimos de dependencias
Forma normal de Boyce-Codd 14.2.1
.
.
391 391 .
392
Contenido 14.5
Quinta forma normal (5NF) 14.5.1
Dependencia
14.5.2
Definición
393
de combinación
sin pérdidas
393
de quinta forma normal
393
395
Resumen Cuestiones
395
de repaso
Ejercicios
_..
Parte 4 Metodología Capítulo
15 Metodología: 15.1
15.2 15.3
Introducción
.
diseño conceptual a la metodología
de diseño de bases de datos
15.1.1
¿Qué es una metodología
15.1.2
Diseño conceptual,
15.1.3
Factores críticos
Panorámica
de diseño?
en el diseño de una base de datos de diseño de la base de datos
de diseño conceptual
Cuestiones
de la base de datos
397 399 400
400 401 401 404 41 7
418
de repaso
Ejercicios
4 19
16 Metodología: diseño lógico de bases de datos para el modelo relacional . 16.1
395
400
lógico y físico de una base datos
de la metodología
Metodología
de la base de datos
Resumen
Capítulo
XIX
Metodología relacional
421
de diseño lógico de bases de datos para el modelo 422
.".
Paso 2 Construir
y validar el modelo lógico de datos
Cuestiones
448 449
de repaso
Ejercicios
Capítulo
17 Metodología: 17.l
Comparación
17.2
Panorámica
17.3
Metodología
diseño físico de bases de datos relacionales del diseño lógico y el diseño físico de bases de datos
de la metodología
de diseño físico de bases de datos
de diseño físico de bases de datos relacionales
18 Metodología: 18.1 18.2
monitorización
Desnormalización Monitorización
e introducción
Ejercicios
y optimización de redundancia
452 454
del sistema final
473
controlada
473
del sistema para mejorar el rendimiento
485
489
Resumen Cuestiones
452
471 472
de repaso
Ejercicios
Capítulo
451
471
Resumen Cuestiones
422
447
Resumen
de repaso
489 490
XX
Sistemas de bases de datos
Parte 5 Problemas fundamentales Capítulo
19
Seguridad
19.1
Seguridad 19.1.1
19.2
491
en las bases de datos
de la base de datos
Amenazas
Contramedidas:
controles
informatizados
495
.
495
.
497
Controles
.
499
19.2.3
Vistas
.
501
19.2.4
Copia de seguridad
.
501
19.2.5
Integridad
.
502
19.2.6
Cifrado
.
502
19.2.7
RAID (Redundant
.
503
.
504
.
508
de acceso
y recuperación
Array of Independent
19.4
Seguridad
19.5
Seguridad de un SGBD en entornos
Disks)
Office Access
en el SGBD de Oracle
1 9.5.1
Servidores
19.5.2
Cortafuegos
19.5.3
Algoritmos
19.5.4
Certificados
19.5.5
Kerberos
19.5.6
Secure Sockets
19.5.7
Secure Electronic
19.5.8
Seguridad
19.5.9
Seguridad ActiveX
Cuestiones
web
.'
proxy
de compendio
de mensajes y firmas digitales
digitales
Layer y Secure HTTP Transactions
y Secure Transaction
T echnology
Java
de repaso
Ejercicios
20.2
494
Autorización
Seguridad en el SGBD de Microsoft
20.1
. .
1 9.2.2
19.3
20
493
19.2.1
Resumen
Capítulo
.
Gestión
de transacciones
Soporte de transacciones Propiedades
de las transacciones
20.1.2
Arquitectura
de la base de datos
512 512
.
513
.
514
.
514
.
514
.
515
.
515
.
516
.
518
.
518
.
519
.
520
.
521 522
.
20.1.1
. .
524 524
Control de concurrencia
.
525
20.2.1
La necesidad del control de concurrencia
525
20.2.2
Serializabilidad
528
20.2.3
Métodos
20.2.4
Interbloqueos
20.2.5
Métodos
20.2.6
Ordenación
20.2.7
Técnicas optimistas
y recuperabilidad
de bloqueo
535
. .
de marca temporal de marcas temporales
.
541 544 547
multiversión .
548
Contenido
20.2.8 20.3
Recuperación
20.3.1 20.3.2 20.3.3 20.3.4 20.3.5 20.4
20.5
Granularidad
de los elementos
de la base de datos
549 552
de datos
.....
La necesidad de la recuperación Transacciones
552
.
y recuperación
Funcionalidades
Modelos avanzados
de recuperación
. .
en un SGBD distribuida
Modelo de transacciones
20.4.2 20.4.3 20.4.4
Sagas
20.4.5
Modelos de flujo de trabajo
560 561
.
de transacciones
20.4.1
.
anidadas
562 564 564
. .
Modelo de transacciones Reestructuración
Control de concurrencia
multinivel
..
dinámica
Niveles de aislamiento
20.5.2
Coherencia
20.5.3 20.5.4
Detección
.
567 567 568
en Oracle
en Oracle
.
de lectura multiversión
.
interbloqueos
Copia de seguridad
565 566
.
y recuperación
20.5.1
y recuperación
572
.
Cuestiones
de repaso
Capítulo 21 Procesamiento
de consultas
Descomposición
21.3
Método
heurístico
21.3.1
Reglas de transformación relacional
Panorámica
del procesamiento
de consultas
.
de optimización
de consultas
583
.
para las operaciones
del álgebra
heurístico
de costes para las operaciones
21.4.1
Estadísticas
21.4.2 21.4.3
Operación
de selección
Operación
de combinación
21.4.4 21.4.5
Operación
de proyección
.
del álgebra relacional
de la base de datos
.
(S =
=
I1A"
.
590 596
.
603
. .
605 606
.
606
.
F
S)) Az'
, Am(R))
Operaciones de conjuntos de álgebra relacional (T = R S, T = R S, T = R - S)
Numeración
n
de las estrategias
21 .5. 1 21 .5.2
Pipelining
21.5.3 21.5.4
Operadores
583 588 589 589
.
de procesamiento
u
576 579
.
de consultas
Estrategias
Estimación
575
.
21.1 21.2
21.5
.
.
Ejercicios
21.4
.
569 569 570 571
.
Resumen
21.3.2
553 555 558
.
Técnicas de recuperación Recuperación
de ejecución
alternativas
Árboles lineales físicos y estrategias
.
607
de ejecución
Reducción del espacio de búsqueda
XXI
.
608 609
XXII
Sistemas de bases de datos
21.6
21.5.5
Enumeración
de árboles de profundidad
21.5.6
Optimización
semántica
21 .5.7
Técnicas
21.5.8
Optimización
Optimización 21.6.1
alternativas
Optimización
21.6.2
Histogramas
21.6.3
Visualización
610
de consultas
611
de optimización
distribuida
de consultas
izquierda.
de consultas
612
de consultas
612
en Oracle
613
basada en reglas y basada en costes.
613
del plan de ejecución
618
616
619
Resumen Cuestiones
de repaso
620
621
Ejercicios
Parte 6 Bases de datos distribuidas y replicación Capítulo 22 Bases de datos distribuidas: 22.1
22.2 22.3
22.4
22.5
22.6
conceptos
.
y diseño
623 625
Introducción
626
22.1.1
Conceptos
626
22.1.2
Ventajas
22.1.3
Sistemas SGBDD homogéneos
Panorámica Funciones
y desventajas
de los SGBDD
de la comunicación y arquitectura
630
y heterogéneos
por red
de un SGBDD
639
22.3.1
Funciones
de un SGBDD
22.3.2
Arquitectura
de referencia
22.3.3
Arquitectura
de re,f.erencia para un MDBS federado
22.3.4
639
Componentes
para un SGBDD
Asignación
22.4.2
Fragmentación
Transparencia
639
de un SGBDD
Diseño de bases de datos relacionales 22.4.1
633 635
641 642
distribuidas
643
de los datos
644 645
en un SGBDD
653
22.5.1
Transparencia
de distribución
653
22.5.2
Transparencia
de transacción
655
22.5.3
Transparencia
de rendimiento
658
22.5.4
Transparencia
de SGBD
22.5.5
Resumen de los conceptos
660 de transparencia
en un SGBDD
661
Las doce reglas de Date para un SGBDD
661
Resumen
662
Cuestiones
664
de repaso
664
Ejercicios
Capítulo 23 Bases de datos distribuidas: 23.1
Gestión de transacciones
23.2
Control de concurrencia
conceptos
distribuidas distribuido
avanzados
667 668 668
Contenido 23.2.1
Objetivos
23.2.2
Serializabilidad
23.2.3
Protocolos
de bloqueo
23.2.4
Protocolos
de marcado temporal
672
de interbloqueos
673
23.3
Gestión distribuida
23.4
Recuperación 23.4.1
. distribuida
676
....
676
los fallos a la recuperación
677
23.4.2
Cómo afectan Confirmación
en dos fases (2PC)
678
23.4.4
Confirmación
en tres fases (3PC)
683
23.4.5
Particionamiento
Localización
23.6.2
Combinaciones
23.6.3
Optimización
Distribución
distribuido
692 695
Introducción
700
del SGBDD de Oracle
700
.
705 706 706
y bases de datos móviles
.
709
a la replicación
.
710
.
710
24.2
Beneficios
24.3
Aplicaciones
24.4
Componentes
24.5
Entornos de replicación
de la replicación
de bases de datos de base de datos
de la replicación
.
básicos de la replicación
711
24.5.1
Replicación
Propiedad de los datos
.
712
síncrona y asíncrona
712 .
de replicación del servidor
713
.
24.6.1
Funcionalidad
24.6.2
Problemas de implementación
716
717
de replicación
717
.
a las bases de datos móviles
720
Sistemas SGBD móviles
Resumen de repaso
721
.
en Oracle
Funcionalidad
Cuestiones
712
de bases de datos
de bases de datos
24.5.2
Ejercicios
696
. .
.
-
Replicación
691
de repaso.
Capítulo 24 Replicación
24.8.1
.
global
Ejercicios
24.7.1
688
de transacciones
distribuidas
distribuidas
Resumen
Introducción
687
de los datos
Funcionalidad
Servidores
.
en Oracle
Cuestiones
..
de la red
de consultas
23.6.1
23.7.1
24.8
670
23.4.3
Optimización
24.7
669
....
distribuido
El modelo X/Open de procesamiento
24.6
.
de bases de datos distribuidas
Fallos en un entorno
23.6
24.1
669
.
23.5
23.7
XXIII
. de replicación
722
de Oracle
722 .
726
.
726
.
727
XXIV
Sistemas de bases de datos
729
Parte 7 Bases de datos orientadas a objetos Capítulo 25 Introducción 25.1
Aplicaciones
25.2
Debilidades
25.3
Conceptos
25.4
a los SGBD orientados
732
avanzadas de bases de datos de los SGBDR de orientación
. a objetos
25.3.1
Abstracción,
encapsulación
25.3.2
Objetos y atributos
25.3.3
Identidad de los objetos
25.3.4
Métodos
25.3.5
Clases
25.3.6
Subclases,
25.3.7
Anulación
25.3.8
Polimorfismo
25.3.9
Objetos complejos
Almacenamiento
736
y ocultación
de la información
744
y mensajes .
745
superclases
746
y herencia
y sobrecarga y enlace dinámico
.
748
.
749
de objetos en una base de datos relacional'
25.4.2
Acceso a los objetos en la base de datos relacional
de las clases a relaciones
25.6
Diseño de bases de datos orientadas
a objetos
25.6.2
Relaciones e integridad
25.6.3
Diseño comportamental
Análisis y diseño orientados
referencial
UML
25.7.2
Utilización datos
de UML en la metodología
754 a objetos .
758 759
..
760
.
de diseño de bases de
a objetos: conceptos
a los modelos de datos orientados
26.1.1
Definición
de un SGBD orientado
26.1.2
Modelos de datos funcionales
26.1.3
Lenguajes de programación de los sistemas
a objetos y a los SGBDOO
Perspectivas 26.2.1
.
.
766
.
767
.
768
.
769 770
776
de base de datos orientados 777
. para el desarrollo
de transformación
765
771
persistentes
de los SGBDOO
Técnicas
.
770
a objetos
a objetos
26.2
755 755
Ejercicios
alternativas
750
753
de repaso
Estrategias
.
752
Resumen
26.1.5
750
.
Diagramas
El Manifiesto
.
..
25.7.1
26.1.4
749
....
a objetos con UML
Capítulo 26 Bases de datos orientadas
.
..
Comparación del modelado de datos orientado y del modelado de datos conceptual
Introducción
740
742
Sistemas de bases de datos de nueva generación
26.1
.
..
Asignación
Cuestiones
740
741
25.4.1
25.6.1
.
.
25.5
25.7
731
a objetos
de un SGBDOO .
de punteros
.
780 780 782
xxv
Contenido 26.2.2 Acceso a un objeto 26.3 Persistencia 26.3.1
Esquemas de persistencia
26.3.2 Persistencia ortogonal 26.4 Cuestiones relativas a los SGBDOO
. .
785
.
787
.
788
787
790
26.4.1 Transacciones
.
790
26.4.2 Versiones
.
790
26.4.3
Evolución de los esquemas
.
791
26.4.4
Arquitectura
26.4.5
Bancos de pruebas
794
.
796
.
799
26.5 Ventajas y desventajas de los SGBDOO 26.5.1 Ventajas 26.5.2
Desventajas
Resumen Cuestiones
de repaso
Ejercicios
:
Capítulo 27 Bases de datos orientadas sistemas
a objetos:
27.1 Object Management Group 27.1.1 Preliminares
estándares
.
799
.
800
. .
802 803
.
804
y
805
. _
. .
806 806
27.1.2
La arquitectura CORBA
.
809
27.1.3
Otras especificaciones de OMG
.
810
27.1.4 ..•Arquitectura basada en modelos
.
812
27.2 Estándar de objetos de datos ODMG 3.0, 1999
.
813
27.2.1
Object Data Management Group
.
815
27.2.2
El modelo de objetos
.
815
27.2.3
El lenguaje de definición de objetos
.
823
27.2.4
El lenguaje de consulta de objetos
.
826
27.2.5
Otras partes del estándar ODMG
.
832
27.2.6
Correspondencia entre el diseño conceptual y el diseño lógico (orientado a objetos)
.
834
27.3 ObjectStore
.
835
27.3.1
Arquitectura
.
835
27.3.2
Desarrollo de una aplicación ObjectStore
.
837
27.3.3
Definición de datos en ObjectStore
.
839
27.3.4
Manipulación de datos en ObjectStore
.
842
.
845
.
846
.
846
.
847
.
848
Resumen Cuestiones
de repaso
Ejercicios
Capítulo 28 Bases de datos objeto-relacionales 28.1 Introducción a los sistemas de bases de datos objeto-relacionales
XXVI
Sistemas de bases de datos 28.2
Los manifiestos 28.2.1
28.3
28.4
28.5
28.7
El manifiesto
de los sistemas
851
de bases de datos de tercera .
851
28.2.2
.
852
El Tercer manifiesto
Postgres:
854
un SGBDOR pionero
28.3.1
Objetivos
de Postgres
28.3.2
Tipos abstractos
28.3.3
Relaciones y herencia
28.3.4
Identidad de los objetos
854
.
854
de datos
855
..... .
SQL: 1999 y SQL:2003 28.4.1
Tipos de filas
28.4.2
Tipos definidos
28.4.3
Subtipos
y supertipos
28.4.4
Rutinas definidas
28.4.5
Polimorfismo
28.4.6
Tipos de referencia
28.4.7
Creación de tablas
28.4.8
Consulta de datos
28.4.9
Tipos de colección
28.4.10
Vistas tipadas
28.4.11
Módulos
28.4.12
Disparadores
861 863
por el usuario
e identidad
.
864
de los objetos
865 865
.
868 869
almacenados
873
persistentes
874
.
Objetos de gran tamaño Recursión
877
":"
.
879
y optimización
de consultas
880
Nuevos tipos de índices orientadas
Tipos de datos definidos
28.6.2
Manipulación
28.6.3
Vistas de objetos
28.6.4
Privilegios
Cuestiones
..
884
por el usuario
884
891
.....
891
de los SGBDOR y los SGBDOO .
892
. .
893 893
.
895
web y sistemas de gestión de bases de datos
.
897
a Internet y a la Web
.
898
.
899
.
900
de repaso
29.1 .1 Intranets 29.1.2
890
....
Parte 8 Las bases de datos y la World Wide Web
Introducción
889
de tablas de objetos
Ejercicios
Capítulo 29 Tecnología
883
.
a objetos en Oracle
28.6.1
Comparación
872
.
28.4.13
Extensiones
858
.
.....
28.4.14
Procesamiento
857
. por el usuario
856 856
.
Resumen
29.1
.
generación
28.5.1 28.6
de las bases de datos de tercera generación
Comercio
y Extranets electrónico
y e-Business
XXVII
Contenido 29.2
La Web 29.2.1
29.3
29.4
HTTP
29.2.2
HTML
29.2.3
Direcciones
29.2.4
Páginas web estáticas
29.2.5
Servicios web
29.2.6
Requisitos Ventajas
y desventajas
29.2.8
Técnicas
para la integración
29.3.2
VBScript
29.3.3
Perl y PHP
Common
Paso de información
29.4.2
Ventajas
29.6
Extensiones
29.7
Java
29.6.1
del servidor
Comparación
29.7.1 29.7.2
SQLJ
-
29.7.4
Persistencia
.
907
912
.
913
.
913
.
914
.
915
.
915 917
.
de CGI
.
web de servidor
de JDBC y SQLJ gestionada
906
.
de CGI y de las extensiones
Comparación
904
.
de los SGBD y la Web
JDBC
29.7.3
904
.
908
al script CGI
y desventajas
.
907
Interface
29.4.1
902
.
y JScript
Gateway
.
.
web-SGBD
de la integración
Lenguajes script JavaScript
901
web-SGBD
para la integración
29.3.1
Cookies HTTP
29.9
y dinámicas
29.2.7
29.5
29.8
URL
.
por el contenedor
(CMP)
918 .
919
.
920
.
921
.
921
.
925
.
930
.
930
.
931
29.7.5
Objetos de datos Java (JDO)
.
935
29.7.6
Servlets Java
.
939
29.7.7
Páginas JavaServer
.
940
29.7.8
Servicios
.
940
.
941
.
943
Plataforma
web Java
web de Microsoft
29.8.1
Acceso
29.8.2
ASP y ADO
.
943
29.8.3
Servicios de datos remotos
.
946
29.8.4
Comparación
.
947
29.8.5
Microsoft
.NET
.
29.8.6
Servicios
web de Microsoft
.
29.8.7
Microsoft
Office Access y generación
Plataforma 29.9.1
universal a datos
Internet de Oracle
Oracle Application
Resumen Cuestiones Ejercicios
de ASP y JSP
de repaso
Server (OracleAS)
de páginas web
948 951 .
951
.
952
.
953
.
958
.
960
.
960
XXVIII
Sistemas de bases de datos
Capítulo 30 Datos semiestructurados 30.1
30.2
30.3
30.4
30.6
30.7
963
Datos semiestructurados
964
30.1.1
Modelo de intercambio
30.1.2
Lore y Lorel
Introducción
de objetos
(OEM)
966 966
a XML
30.2.1
Panorámica
30.2.2
Definiciones
Tecnologías
970 de XML
972
de tipos de documentos
relacionadas
(DTD)
975
con XML
978
30.3.1
Interfaces
30.3.2
Namespaces
30.3.3
XSL y XSL T
979
30.3.4
XPath (XML Path Language)
980
30.3.5
XPointer
981
30.3.6
XLink (XML Linking Language)
30.3.7
XHTML
30.3.8
Simple Object Access Protocol
30.3.9
Web Services Description
DOM y SAX
978
30.3.10
Universal Discovery,
979
(XML Pointer Language)
981 982 (SOAP)
982
Language (WSDL)
983
Description
y Integration
(UDDI)
983
XML Schema 30.4.1
30.5
y XML
985
RDF (Resource Description
Lenguajes de consulta
Framework)
992
para XML
30.5.1
Extensión
30.5.2
XML Query Working
993
de Lore...• y Lorel para tratar datos XML
994
Group
30.5.3
XQuery - un lenguaje de consulta
30.5.4
XML Information
30.5.5
XQuery
30.5.6
Semántica
995 para XML
996
Set
1006
1.0 and XPath 2.0 Data Model
1007
formal
101 2
Bases de datos y XML
1019
30.6.1
Almacenamiento
de XML en bases de datos
1019
30.6.2
XML y SQL
1021
30.6.3
Bases de datos XML nativas
1027
XML en Oracle
1028
Resumen
1031
Cuestiones
de repaso
1033
Ejercicios
1034
Parte 9 Inteligencia empresarial Capítulo 31 Conceptos 31.1
Introducción 31.1.1
1035
de almacenes de datos
.
1037
a los almacenes
.
1038
.
1038
Evolución
de datos
de los almacenes de datos
XXIX
Contenido
31.2
31.1.2
Conceptos
31.1.3
Ventajas
de almacenes
de datos
de los almacenes
1038
de datos
31.1.4
Comparación
31.1.5
Problemas de los almacenes
Arquitectura
.
de los sistemas
1040
Ol TP Y los almacenes
Datos operacionales
31.2.2
Repositorio
31.2.3
Gestordecarga
31.2.4
Gestor del almacén de datos
31.2.5
Gestor de consultas
31 .2.6
Datos detallados
31.2.7
Datos poco resumidos
1043
.
1044
.
1044
de datos operacionales
..
1045 .
..
1045
.
31.2.8
Datos de archivo/copia Metadatos
31.2.10
Herramientas
1045 1046
y muy resumidos de seguridad
...
1046
.
1046
de acceso para usúarios finales
1046 .
1048
31.3.1
Flujo de entrada
31 .3.2
Flujo ascendente
31 .3.3
Flujo descendente
31.3.4
Flujo de salida
.
1050
31.3.5
Metaflujo
.
1051
Herramientas
y tecnologías
.
1050
de almacén de datos
31.4.1
Herramientas
Sistemas SGBD para almacenes
31.4.3
Metadatos
31.4.4
Herramientas
de extracción,
.
1051
limpieza y transformación
de un almacén de datos de administración
1051
de datos
.
1052
....
1054
y gestión
1056
de datos
.
.31 .5.1
Razones para crear un mercado de datos
31.5.2
Cuestiones
Almacenes
fundamentales
en los mercados
1056
.
1058
de datos
1058
de datos en Oracle
Oracle9i
Resumen Cuestiones
1060 1060 1062
de repaso .
1064
.
1065
Capítulo 32 Diseño de almacenes de datos
.
32.1
Diseño de la base de datos para un almacén de datos
32.2
Modelado
de la dimensionalidad
Comparación
Metodología datos
. .
.
Ejercicios
32.2.1
1049 1049
31.4.2
31.6.1
32.3
1045 1045
.
31.2.9
31 .5 Mercados
31.6
1042
.
de un almacén de datos
31.2.1
31 .3 Flujos de datos en un almacén de datos
31.4
de datos
de datos
de los modelos
.
1067 1067
.
1068
DM y ER
1071
de diseño de bases de datos para almacenes
de .
1072
XXX
Sistemas de bases de datos 32.4 32.5
Criterios datos
para verificar
Diseño de almacenes 32.5.1
Componentes
32.5.2
Utilización
la dimensionalidad
de un almacén de .
de datos con Oracle de Oracle Warehouse
de Oracle Warehouse
1081
. Builder
Builder
Resumen
1081 .
1081
.
1082
.
Cuestiones
1086
de repaso.
1087
Ejercicios
1087
.
.
1089
en línea
.
1090
1 Baterías de prueba OlAP
.
1090
.
1091
.
1092
.
1093
.
1095
Capítulo 33 OlAP 33.1
Procesamiento 33.1
33.2
Aplicaciones 33.2.1
analítico
OlAP
Beneficios
33.3
Representación
33.4
Herramientas 33.4.1 33.4.2
33.5
33.6
de OlAP
de datos multidimensionales OlAP
Reglas de Codd para las herramientas Categorías
Extensiones
de herramientas
OlAP
OlAP al estándar SOL
33.5.1
Capacidades
33.5.2
Operadores
Aplicaciones
OlAP
de agrupación
ampliadas
OlAP elementales
OlAP
en Oracle
33.6.1
Entorno OlAP
33.6.2
Plataforma
-
de Oracle
para aplicaciones
de inteligencia
empresarial
.
1095
.
1097
.
1100
.
1101
.
1105
.
1107
.
1107
.
1108
.
1108
33.6.3
Base de datos Oracle9i
33.6.4
Oracle OlAP
.
1110
33.6.5
Prestaciones
.
1111
33.6.6
Gestión del sistema
.
1111
33.6.7
Requisitqs
.
1112
.
1112
.
1112
.
1113
del sistema
Resumen Cuestiones
de repaso
Ejercicios
Capítulo 34 Minería de datos
.
1115
34.1
Minería de datos
.
1115
34.2
Técnicas de minería de datos
.
1117
34.2.1
.
1117
34.3
Modelado
predictivo
34.2.2
Segmentación
.
1119
34.2.3
Análisis de enlaces
.
1120
34.2.4
Detección
.
1120
El proceso de minería de datos
.
1120
34.3.1
.
1121
de la base de datos
de desviaciones
El modelo CRISP-DM
Contenido 3404
Herramientas
de minería de datos
34.5
Minería de datos y almacenes
34.6
Oracle Data Mining (ODM)
de datos
34.6.1
Capacidades
34.6.2
Soporte para aplicaciones
34.6.3
Predicciones
34.604
Entorno de Oracle Data Mining
.
1123
.
1124
.
1124
de minería de datos
1124
.
1125
de minería de datos.
y asociaciones
",'
1125
.
1125
.
1126
.
1127
.
1127
Resumen Cuestiones de repaso
XXXI
,
Ejercicios
1129
Apéndices A Especificación de requisitos estudio de DreamHome A.l
A.2
de usuario para el caso de .
Vistas de usuario Branch de DreamHome A.l .1 Requisitos
de datos
A.l.2
de transacciones
Requisitos
.
1131 1131
.
1132
(ejemplos)
1133
Vistas de usuario Staff para DreamHome A.2.1
Requisitos
de datos
A.2.2
Requisitos
de transacciones
(ejemplo)
B Otros casos de estudio B.l
Caso de estudio
University Accommodation Orrice
13.1.1 Requisitos B.l.2 B.2
B.3
e
1133
.
1134
1137
.
1137 .
de consulta
B.2.1
Requisitos
de datos
B.2.2
Transacciones
1140 1140
.
de consulta
(ejemplos)
1140
.
1141
Wellmeadows Hospital.
El caso de estudio B.3.1
Requisitos
de datos
B.3.2
Requisitos
de transacciones
1141
. (ejemplo)
1147
.
de archivos e índices
C.l
Conceptos
C.2
Archivos
C.3
Archivos
ordenados
CA
Archivos
hash
.
básicos desordenados
.
1151
" .
Hash dinámico
CA.2
Limitaciones
de las técnicas
1151
hash
índices
.
C.5.1
Tipos de índices
C.5.2
Archivos
secuenciales
indexados
1149 1150
.
CA.l
1137 1139
(ejemplos)
Caso de estudio EasyDrive School or Motoring
Organizaciones
C.5
.
.
de datos
Transacciones
1131
.
1153
.
1155
.
1156 1157
.
1157
.
1158
XXXII
Sistemas de bases de datos C.5.3
índices secundarios
C.5.4
índices multinivel
.
1160
C.5.5ÁrbolesB+
C.6
C.7
.
C.5.6
índices de mapa de bits
C.5.7
índices de combinación
Tablas agrupadas Clústeres
C.6.2
Clústeres hash
1164
.....
1165
..
indexados
para seleccionar
1160 1162
y no agrupadas
C.6.1
Directrices
1159
.
1165
.
1166
la organización
1167
de los archivos
Resumen del Apéndice
.
1173
O ¿Cuándo es relacional un SGBD? E SOL procedimental E.1
1177
.
SOL embebido
.
E.1 .1 Instrucciones
SOL embebidas
simples
E.1.2
Área de comunicaciones
E.1.3
Variables del lenguaje host
E.1.4
Extracción
de datos mediante
E.1.5
Utilización
de cursores
E.1.6
Estándar ISO para el SOL embebido
E.2
SOL dinámico
E.3
El estándar
1178 1178
..
de SOL
1179 1182
.... SOL embebido
para modificar
1183
y cursores
1186
los datos
1188 1189
.
ODBC (Open Database Connectivity)
E.3.1
La arquitectura
E.3.2
Niveles de ~umplimiento
1170
1190
.
ODBC
1191
. ODBC
1192
..
Resumen del Apéndice
.
1195
Cuestiones
.
1195
.
1196
.
1197
de repaso
Ejercicios
F Notaciones
alternativas
para modelado ER
F.1
Modelad9
ER utilizando
la notación
Chen
.
1197
F.2
Modelado
ER utilizando
la notación
en pie de cuervo
.
1197
G Resumen de la metodología relacionales
de diseño de bases de datos .
1203
Referencias
1209
Lecturas adicionales
1223
índice
1237
Prefacio Introducción La historia de investigación en sistemas de bases de datos en los últimos 30 años es la de una investigación de excepcional productividad, que ha hecho que los sistemas de bases de datos sean probablemente el desarrollo más importante en el campo de la ingeniería del software. Las bases de datos constituyen ahora el fundamento de todos los sistemas de información y han cambiado de manera fundamental la forma en que muchas organizaciones operan. En particular, los desarrollos relativos a esta tecnología en los últimos años han producido sistemas que son mucho más potentes y más intuitivos de utilizar, lo que ha hecho que haya sistemas de bases de datos a disposición de un número cada vez mayor de usuarios. Desafortunadamente, la aparente simplicidad de estos sistemas ha hecho que algunos usuarios creen bases de datos y aplicaciones sin los necesarios conocimientos como para construir un sistema efectivo y eficiente. De aquí proviene la 'crisis del software' o, como algunas veces se la denomina, la 'depresión del software' que parece afectar a todos los desarrollos en este campo. El estímulo original para la escritura de este libro proviene del trabajo de los autores dentro del sector de las tecnologías de la información, donde han estado proporcionando servicios de consultoría sobre el diseño de bases de datos para nuevossistemas software y, en muchas ocasiones, resolviendo los problemas de los sistemas existentes. Además, el trabajo académico de los autores les permitió entrar en contacto con problemas similares experimentados por otros usuarios distintos, los estudiantes. Los objetivos de este libro son, por ello, proporcionar un texto que presenta la teoría relativa a las bases de datos de la forma más clara posible y, en concreto, proporcionar una metodología del diseño de bases de datos que pueda ser utilizada por lectores tanto técnicos como no técnicos. La metodología presentada en este libro para sistemas de gestión de bases de datos relacionales (SGBDR) (el sistema actualmente predominante para las aplicaciones de carácter empresarial) ha sido probada a 10 largo de los años en entornas tanto empresariales como académicos. Está compuesta de tres fases principales: diseño conceptual, lógico y fisico de la base de datos. La primera fase comienza con la producción de un modelo conceptual de los datos que sea independiente de todas las consideraciones fisicas. Este modelo se refina a continuación en la segunda fase, para obtener un modelo lógico de los datos donde se eliminen las estructuras que no puedan representarse en los sistemas relacionales. En la tercera fase, el modelo lógico de los datos se traduce a un diseño fisico adecuado al SGBD elegido. La fase de diseño fisico considera las estructuras de almacenamiento y métodos de acceso requeridos para un acceso seguro y eficiente a la base de datos contenida en el almacenamiento secundario. La metodología de cada una de las fases se presenta en forma de una serie de pasos. Para el diseñador inexperto, recomendamos que los pasos se sigan en el orden descrito, proporcionándose directrices que le ayudarán durante todo este proceso. Para el diseñador más experimentado, la metodología puede ser menos prescriptiva, actuando más como un marco de trabajo o lista de comprobación. Para ayudar a que el lector pueda utilizar la metodología y comprender los aspectos más importantes, hemos descrito esta metodología utilizando un ejemplo realista, basado en un caso de estudio integrado, DreamHome. Además, en el Apéndice B se proporcionan casos de estudio adicionales para que los lectores puedan aplicar la metodología por sí mismos.
XXXIV
Sistemas de bases de datos
UML (Unified Modeling Language) Cada vez más, las empresas están estandarizando la forma de modelar los datos, seleccionando una técnica de modelado de datos concreta y utilizándola en todos sus proyectos de desarrollo de bases de datos. Un modelo de datos de alto nivel muy popular que se utiliza en el diseño conceptual/lógico de bases de datos, y que es el que empleamos en este libro, está basado en los conceptos del modelo entidad-relación (ER). Actualmente no hay ninguna notación están dar para los modelos ER, en la mayoría de los libros dedicados al diseño de bases de datos para servidores SGBD relacionales tienden a usar una de dos notaciones convencionales: •
la notación Chen, compuesta por rectángulos que representan entidades y rombo s que representan relaciones, con líneas que enlazan los rectángulos y los rombos; o
•
la notación en pie de cuervo, que de nuevo consta de rectángulos que representan las entidades y líneas entre las entidades que representan relaciones, con un símbolo de pie de cuervo en uno de los extremos de la línea para representar las relaciones uno a muchos.
Ambas notaciones son soportadas por las herramientas CASE actuales. Sin embargo, pueden resultar bastante engorrosas de utilizar y algo difíciles de explicar. Con anterioridad a esta edición, utilizábamos la notación de Chen; sin embargo, después de procesar un completo cuestionario que fue elaborado por Pearson Education, vimos que había un consenso general en que la notación debería cambiarse, para utilizar el último lenguaje de modelado orientado a objetos, denominado UML (Unified Modeling Language). UML es una notación que combina elementos de las tres tendencias principales de diseño orientado a objetos: el modelado OMT de Rumbaugh, el análisis y diseño orientado a objetos de Booch y la técnica Objectory de Jacobson. Hay tres razones principales para adoptar una notación distinta: (1) UML se está convirtiendo en un estándar del sector; por ejemplo, OMG (Object Management Group) ha adoptado UML como notación estándar para los métodos de los objetos; (2) UML es más claro y fácil de utilizar; (3) UML está siendo ahora adoptado en el mundo académico para enseñar análisis y diseño orientados a objetos, y la utilización de UML en los módulos de base de datos proporciona una mayor sinergia. Por tanto, en este edición hemos adoptado la notación de diagramas de clases de UML. Estamos convencidos de que el lector encontrará esta notación más fácil de entender y de utilizar. Antes de hacer esta transición a UML, los autores hemos dedicado una considerable cantidad de tiempo a experimentar con UML ya comprobar su adecuación al diseño de bases de datos, habiendo concluido este trabajo con la publicación de un libro a través de Pearson Education llamado Database Solutions: A Step-by-Step Guide to Building Databases. Dicho libro utiliza la metodología de diseño y de desarrollo de bases de datos en dos casos de estudio, uno para el SGBD Microsoft Office Access y otro utilizando Oracle como base de datos objetivo. Este libro contiene también muchos otros casos de estudio con soluciones de ejemplo.
Novedades en la cuarta edición La cuarta edición del libro ha sido revisada para mejorar la legibilidad, para actualizar o ampliar el tratamiento de determinados temas y para incluir otros temas nuevos. Los cambios principales en la cuarta edició~ • Un tratamiento más amplio del tema de la normalización (el capítulo original ha sido dividido en dos). •
Una metodología simplificada para el diseño de bases de datos utilizando la notación UML para los diagramas ER.
•
Una nueva sección sobre el uso de otras partes de UML dentro del análisis y el diseño, cubriendo los temas de los casos de uso, diagramas de secuencia, diagramas de colaboración, diagramas de estados y diagramas de actividad. Una nueva sección dedicada a la enumeración de estrategias de ejecución dentro del proceso de optimización de consultas, para servidores SGBD tanto centralizados como distribuidos.
• •
Tratamiento de las especificaciones MDA (Model Driven Architecture).
OMG, incluyendo CWM (Common Warehouse Metamodel)
•
Actualización del capítulo de bases de datos objeto-relacionales, nuevo estándar SQL:2003.
y
para incluir información acerca del
Prefacio
XXXV
•
Un tratamiento ampliado de la integración de los SGBD con la Web, incluyendo los temas de CMP (Container-Managed Persistence), IDO (Java Data Objects) y ADO.NET.
•
Un tratamiento ampliado de XML, SOAP, WSDL, UDDI, XQuery 1.0 y XPath 2.0 (incluyendo el modelo de datos revisado y la semántica formal), el estándar SQL:2003 SQL/XML, el almacenamiento de información XML en bases de datos relacionales y el tema de las bases de datos XML nativas .
•
Un tratamiento ampliado de OLAP y de la minería de datos, incluyendo la funcionalidad de SQL:2003 y el modelo CRISP-DM.
•
Actualización 2003.
•
Recursos web adicionales, incluyendo un capítulo ampliado dedicado a la organización de archivos y a las estructuras de almacenamiento, una implementación web completa del caso de estudio de DreamHome, una guía de usuario para Oracle y más ejemplos para el apéndice dedicado a la integración de sistemas SGBD y la Web.
del tratamiento de Oracle9i (panorámica de Oracle 1Og) y de Microsoft Office Access
Audiencia objetivo Este libro está pensado como texto para un curso de uno a dos semestres sobre gestión o diseño de bases de datos, a nivel introductorio, normal o avanzado. Dichos cursos son normalmente incluidos en los currícula relacionados con los sistemas de información, con las tecnologías de la información o con la informática. El libro también pude utilizarse como texto de referencia por parte de los profesionales de las tecnologías de la información como por ejemplo analistas de sistemas, diseñadores, programadores de aplicaciones, programadores de sistemas, administradores de bases de datos y personas interesadas en general. Debido al amplio uso actual de los sistemas de bases de datos, este tipo de profesionales interesados puede estar trabajando en cualquier empresa donde se necesite emplear una base de datos. Resultaría útil para los estudiantes disponer de ciertos conocimientos sobre organización de archivos y estructuras de datos, por lo que hemos incluido dicha información en el Apéndice C como preparación para el Capítulo 17 dedicado al diseño físico de bases de datos y el Capítulo 21, dedicado al procesamiento de consultas. Lo ideal es que estos conocimientos los hubiera adquirido el lector en algún curso anterior, pero en caso de no ser posible, el Apéndice C puede repasarse al comienzo del curso, inmediatamente después del Capítulo l. También conviene tener unos ciertos conocimientos sobre algún lenguaje de programación de alto nivel, como C, para poder comprender el Apéndice E dedicado al SQL embebido y al SQL dinámico, y la Sección 27.3, dedicada a ObjectStore.
Características distintivas (1) Una metodología paso a paso fácil de utilizar para el diseño conceptual y lógico de bases de datos, basada en el ampliamente aceptado modelo entidad-relación, utilizándose la normalización técnica de validación. Hay un caso de estudio integrado que muestra cómo utilizar la metodología. blecimiento de la correspondencia entre el diseño lógico y la implementación física, la selecci' n de (2) organizaciones Una metodologíadepaso a paso fácil deapropiados utilizar parapara el diseño físico de base datos, quedecubre eltta- de archivo e índices las aplicaciones y ladeutilización técnic introducción de redundancia controlada. De nuevo, hay un caso de estudio integrado que muestra utilizar la metodología. (3) Hay capítulos independientes que muestran cómo encaja el diseño de la base de datos dentro del ciclo de desarrollo de los sistemas de base de datos, cómo pueden utilizarse las técnica de determinación de hechos para identificar los requisitos del sistema y cómo encaja UML dentro de esta metodología. (4) Una presentación clara y fácil de entender, con definiciones claramente resaltadas, con una exposición preliminar de los objetivos del capítulo y con un resumen de cada capítulo. Se proporcionan en todos los capítulos numerosos ejemplos y diagramas para ilustrar los conceptos. A lo largo de todo el libro
XXXVI
Sistemas de bases de datos
hay un caso de estudio realista integrado, pudiéndose utilizar otros casos de estudio adicionales como proyectos para los estudiantes. (5) Un tratamiento completo de los más recientes estándares formales y de Jacto: SQL (Structured Query Language), QBE (Query-By-Example) y el estándar ODMG (Object Data Management Group) para bases de datos orientadas a objetos. (6) Tres capítulos de tipo tutorial sobre el estándar SQL, que cubren tanto el SQL interactivo como el SQL embebido. (7) Un capítulo de nivel introductorio que cubre dos de los SGBD comerciales más populares: Microsoft Office Access y Oracle. Muchos de los capítulos subsiguientes proporcionan información sobre el modo en que Microsoft Office Access y Oracle soportan los mecanismos analizados. (8) Un tratamiento completo de los conceptos y problemas relativos a los SGBD distribuidos y los servidores de replicación. (9) Una introducción completa a los conceptos y cuestiones relativos a los SGBD basados en objetos, incluyendo una revisión del estándar ODML y un tutorial sobre las funcionalidades de gestión de objetos incluidas en la última versión del estándar SQL, SQL:2003. (10) Un tratamiento completo de la utilización de la Web como plataforma para aplicaciones de base de datos, con muchos ejemplos de código que explican cómo acceder a bases de datos a través de la Web. En particular, se cubre el tema de la persistencia presentando tecnologías tales como CMP (ContainerManaged Persistence), JDO (Java Data Objects), JDBC, SQLJ, ADO (ActiveX Data Objects), ADO.NET y PSP (Oracle PL/SQL Pages). (11) Una introducción a los datos semiestructurados y a su relación con XML y un tratamiento completo de XML y sus tecnologías relacionadas. En particular, se presentan XML Schema, XQuery y el modelo de datos y la semántica formal de XQuery. También se analiza la integraci~n de XML con las bases de datos y se examinan las extensiones añadidas a SQL:2003 para permitir la publicación de datos XML. (12) Una introducción completa al tema de los almacenes de datos, el procesamiento (OLAP, Online Analytical Processing) y la minería de datos.
analítico en línea
(13) Una introducción completa al modeladCMie dimensionalidad para el diseño de bases de datos para almacenes de datos. Se utiliza un caso de estudio integrado para demostrar una metodología para el diseño de almacenes de datos. (14) Un tratamiento de los conceptos de implementación de los sistemas SGBD, incluyendo el control de concurrencia y recuperación, la seguridad y el procesamiento y optimización de consultas.
Pedagogía Antes de comenzar a escribir el libro, uno de los objetivos que nos planteamos era que el texto fuera fácil de seguir y comprender para los profesores, independientemente de su formación y experiencia. Según la experiencia de los autores en la utilización de libros de texto, que era bastante considerable antes de acometer un proyecto de este tipo, y teniendo también en cuenta la opinión de los colegas, clientes y estudiantes, vimos que había distintas características que a los lectores les gustaban o les disgustaban. Teniendo en cuenta estos comentarios, decidimos adoptar el siguiente estilo y la siguiente estructura para el libro: •
Un conjunto de objetivos, claramente identificados al principio de cada capítulo.
•
Cada concepto importante que se presenta se define y se resalta claramente, utilizando un tipo de letra diferente a la del resto del texto.
•
Se utilizan diagramas por todo el texto para ampliar y clarificar los conceptos.
•
Se decidió adoptar una orientación muy práctica: con este fin, cada capítulo contiene muchos ejemplos resueltos que ilustran los conceptos presentados.
•
Un resumen al final de cada capítulo, en el que se cubren los principales conceptos que se han presentado
t7o:----
Prefacio
XXXVII
~ •
Un conjunto de cuestiones de repaso, cuyas respuestas se encuentra dentro del propio texto.
•
Un conjunto de ejercicios que los profesores pueden utilizar para verificar que los estudiantes han comprendido el capítulo, pudiendo encontrarse las respuestas en la Guía del Profesor que acompaña a este libro.
Guía del profesor Un suplemento muy completo que contiene numerosos recursos de ayuda para la impartición del material contenido en este libro; esta guía puede solicitarse a Pearson Education. La guía incluye: . •
Estructuras de curso. Se incluyen sugerencias relativas a los capítulos que pueden incluirse en diversos tipos de cursos.
•
Sugerencias pedagógicas. Incluyen sugerencias sobre lecturas recomendadas, consejos pedagógicos e ideas sobre proyectos que los estudiantes pueden acometer y que están relacionados con el contenido de distintos capítulos.
•
Soluciones. Se proporcionan respuestas de ejemplo para todas las cuestiones de repaso y ejercicios.
•
Preguntas de examen. Preguntas de examen similares a las cuestiones y ejercicios del final de cada capítulo, con sus correspondientes soluciones.
•
Plantillas de transparencia. Un conjunto de transparencias electrónicas que contienen los puntos principales de cada capítulo, con ilustraciones más grandes y tablas extraídas del texto, que ayudarán al profesor a ligar las explicaciones y las discusiones de la clase con el material contenido en el libro.
•
Una Guía del Usuario para Microsoft Office Access 2003, para el trabajo de los estudiantes en ellaboratorio.
•
Una Guía del Usuario para Oracle9i, para el trabajo de los estudiantes en el laboratorio.
•
Un capítulo ampliado sobre organizaciones de archivos y estructuras de almacenamiento.
•
Una implementación
web del caso de estudio de DreamHome.
El lector interesado puede encontrar información adicional sobre la Guía del Profesor y el libro en el sitio web de Pearson Education en: .".
http://www.booksites.net/connbegg
Organización del libro Parte 1 Introducción La Parte 1 del libro sirve como introducción al tema de los sistemas de bases de datos y el diseño de bases de datos. El Capítulo 1 introduce los conceptos de la gestión de base de datos, examinando los problemas que presentaban los precursores de los sistemas de base de datos, que son los sistemas basados en archivos, y las ventajas ofrecidas por la utilización de una base de datos. El Capítulo 2 examina el entorno de una base de datos, analizando las ventajas que ofrece la arquitectura ANSI-SPARC en tres niveles, introduciendo los modelos de datos más populares y resaltando las funciones que debe proporcionar un SGB multi-usuario. El capítulo examina también la arquitectura software subyacente de los SGBD, pudiendo omitirse esta exposición en los cursos introductorios dedicados a la gestión de bases de datos.
Parte 2
El modelo relacional y los lenguajes relacionales
La Parte 2 del libro sirve como introducción al modelo relacional y a los lenguajes relacionales, especialmente el álgebra relacional y el cálculo relacional, QBE (Query-By-Example) y SQL (Structured Query Lan-
XXXVIII
Sistemas de bases de datos
guage). Esta parte examina también dos sistemas comerciales muy populares: Microsoft Office Access y Oracle. El Capítulo 3 introduce los conceptos subyacentes al modelo relacional, que es el modelo de datos más popular en la actualidad y el que más a menudo se elige para aplicaciones estándar de carácter empresaria!. Después de presentar la terminología y mostrar la relación existente con las relaciones matemáticas, se explica el tema de las reglas de integridad relacionales, de la integridad de entidades y de la integridad referencia!. El capítulo concluye con una panorámica del tema de las vistas, del que se habla más extensamente en el Capítulo 6. El Capítulo 4 presenta el álgebra relacional y el cálculo relacional con una serie de ejemplos para ilustrar todas las operaciones. Puede omitirse en un curso introductorio sobre gestión de bases de datos. Sin embargo, el álgebra relacional es necesaria para comprender los temas de procesamiento de consultas del Capítulo 21 y de la fragmentación en los SGBD distribuidos del Capítulo 22. Además, los aspectos comparativos del álgebra procedimental y el cálculo no procedimental resultan de utilidad para el estudio de SQL en los Capítulos 5 y 6, aunque no son estrictamente esenciales. El Capítulo 5 presenta las instrucciones de manipulación de datos del estándar SQL: SELECT, INSERT, UPDATE y DELE TE. El capítulo se presenta como un tutorial, dando una serie de ejemplos resueltos que ilustran los conceptos principales relacionados con estas instrucciones. El Capítulo 6 cubre las principales funcionalidades de definición de datos del estándar SQL. De nuevo, el capítulo se presenta en forma de tutoria!. El capítulo analiza los tipos de datos SQL y las instrucciones de definición de datos, las características de mejora de integridad y las características más avanzadas en las instrucciones de definición de datos, incluyendo las instrucciones de control de acceso GRANT y REVOKE. También se examinan las vistas y se muestra cómo pueden crearse en SQL. El Capítulo 7 es otro capítulo práctico que examina el lenguaje de consulta interactivo QBE (Query-ByExample), que tiene la reputación de ser una de las formas más sencillas mediante la que los usuarios no técnicos pueden acceder a la información contenida en una base de datos. QBE se ilustra utilizando Microsoft Office Access. El Capítulo 8 completa la segunda parte dellib!;9 proporcionando una introducción a dos de los SGBD relacionales comerciales más populares, Microsoft Office Access y Oracle. En los siguientes capítulos del libro se examina cómo implementan estos sistemas diversas funcionalidades de base de datos, como la seguridad y el procesamiento de consultas.
Parte 3 Técnicas de análisis y diseño de bases de datos La Parte 3 del libro explica las técnicas principales del análisis y el diseño de bases de datos y cómo pueden aplicarse de una forma práctica. El Capítulo 9 presenta una panorámica de las etapas principales del ciclo de desarrollo de aplicaciones de base de datos. En particular, enfatiza la importancia del diseño de base de datos y muestra cómo puede descomponerse el proceso en tres fases: diseño conceptual, lógico y físico de la base de datos. También describe cómo afecta el diseño de la aplicación (el enfoque funcional) al diseño de la base de datos (el enfoque de datos). Una etapa crucial en el ciclo de desarrollo de las aplicaciones de base de datos es la selección de un SGBD apropiado. Este capítulo explica el proceso de selección de un SGBD y proporciona algunas directrices y recomendaciones. El capítulo concluye con un análisis de la importancia de la administración de datos y de la administración de bases de datos. El Capítulo 10 explica cuándo puede utilizar el desarrollador las técnicas de determinación de hechos y qué tipos de hechos debe capturarse. El capítulo describe las técnicas más comúnmente utilizadas para la determinación de hechos e identifica las ventajas y desventajas de cada una. El capítulo también ilustra el modo en que pueden usarse estas técnicas durante las etapas iniciales del desarrollo de aplicaciones de base de datos, utilizando como ilustración el caso de estudio de DreamHome. Los Capítulos 11 y 12 cubren los conceptos del modelo entidad-relación (ER) y del modelo entidad-relación avanzado (EER), que permite un modelado de datos más avanzado utilizando subclases y superclases y téc-
Prefacio
XXXIX
nicas de categorización. El modelo EER es un modelo de datos conceptual de alto nivel muy popular y constituye una técnica fundamental de la metodología del diseño bases de datos que aquí se presenta. También se introduce el tema de la utilización de UML para la representación de diagramas ER. Los Capítulos 13 y 14 examinan los conceptos subyacentes a la normalización, que es otra técnica importante utilizada en la metodología de diseño lógico de bases de datos. Empleando una serie de ejemplos resueltos extraídos del caso de estudio integrado, se ilustra cómo pasar un diseño de una forma normal a otra y se muestran las ventajas de disponer de un diseño lógico de la base de datos que se adapte a determinadas formas normales, hasta la quinta forma norma!.
Parte 4 Metodología Esta parte del libro cubre una metodología para el diseño de bases de datos. La metodología está dividida en tres partes, que cubren el diseño conceptual, lógico y fisico de la base de datos. Cada parte de la metodología se ilustra utilizando el caso de estudio de DreamHome. El Capítulo 15 presenta una metodología paso a paso para el diseño conceptual de bases de datos. Muestra cómo descomponer el diseño en áreas más manejables basadas en las vistas individuales y proporciona a continuación directrices para la identificación de entidades, atributos, relaciones y claves. El Capítulo 16 presenta una metodología paso a paso para el diseño lógico de bases de datos basadas en el modelo lógico relaciona!. Se muestra cómo establecer la correspondencia entre un modelo conceptual de los datos y un modelo lógico de los datos y como validar el modelo de acuerdo con las transacciones requeridas, utilizando la técnica de la normalización. Para las aplicaciones de base de datos con múltiples vistas de usuario, este capítulo muestra cómo combinar los modelos de datos resultantes en un modelo de datos global que represente todas las vistas de la parte de la organización que se esté modelando. Los Capítulos 17 y 18 presentan una metodología paso a paso para el diseño físico de bases de datos relacionales. Muestra cómo traducir el modelo lógico de los datos obtenido durante el diseño lógico de la base de datos a un diseño fisico basado en un sistema relaciona!. La metodología contempla la cuestión de las prestaciones de la implementación resultante, proporcionando directrices para la selección de organizaciones de archivos y estructuras de>'almacenamiento, y explicando cuando debe introducirse redundancia controlada.
Parte 5
Problemas fundamentales en las bases de datos
La Parte 5 del libro examina cuatro temas específicos que los autores consideran necesarios para cualquier curso moderno dedicado a la gestión de bases de datos. El Capítulo 19 analiza el tema de la seguridad en las bases de datos, no sólo en el contexto de la seguridad del SGBD sino también en el de la seguridad del entorno del SGBD. Se ilustra cómo proporcionar seguridad con Microsoft Office Access y Oracle. El capítulo examina también los problemas de seguridad que pueden surgir en un entorno web y presenta algunas técnicas dedicadas a prevenir estos problemas. El Capítulo 20 se concentra en tres funciones que todo sistema de gestión de bases de datos debe proporcionar: la gestión de transacciones, el control de concurrencia y la recuperación. Estas funciones tratan de garantizar que la base de datos sea viable y permanezca en un estado coherente cuando múltiples usuarios estén accediendo a la base de datos, y en presencia de fallos tanto de los componentes hardware como software. El capítulo también explica los modelos avanzados de transacciones que resultan más apropiados para las transacciones de larga duración. Se concluye el capítulo examinando el tema de la gestión de transacciones en Oracle. El Capítulo 21 examina las cuestiones del procesamiento y optimización de consultas. En el capítulo se presentan las dos técnicas principales de optimización de consultas: utilización de reglas heurísticas que ordenen las operaciones de la consulta, y otra técnica que compara diferentes estrategias basándose en sus costes relativos y selecciona aquella que minimiza el uso de recursos. El capítulo concluye examinando el procesamien~ to de consultas en Oracle.
XL
Sistemas de bases de datos
Parte 6
Bases de datos distribuidas y replicación
La Parte 6 del libro examina los SGBD distribuidos y los SGBD basados en objeto. La tecnología de sistemas de gestión de bases de datos distribuidas (SGBDD) constituye uno de los desarrollos principales en la actualidad dentro del área de los sistemas de base de datos. Los capítulos anteriores del libro se centran en los sistemas de bases de datos centralizados, es decir, sistemas con una única base de datos lógica ubicada en una plataforma bajo control de un único SGBD. El Capítulo 22 explica los conceptos y problemas de los SGBD distribuidos, en los que los usuarios pueden acceder a la base de datos situada en su propia plataforma y también a los datos almacenados en otros sitios remotos. E! Capítulo 23 examina varios conceptos avanzados asociados con los SGBD distribuidos. En particular, se concentran los protocolos asociados con la gestión de transacciones distribuidas, el control de concurrencia, la gestión de interbloqueos y la recuperación de la base de datos. El capítulo examina también el protocolo DTP (Distributed Transaction Processing) de X/Open. Se concluye el capítulo examinando la cuestión de la distribución de datos en Oracle. El Capítulo 24 presenta los servidores de replicación como alternativa a los SGBD distribuidos y examina los problemas asociados con las bases de datos móviles. En el capítulo se analizan también las funcional idades de replicación de datos de Oracle.
Parte 7
Bases de datos orientadas a objetos
Los capítulos anteriores del libro se centran en el modelo relacional y en los sistemas relacionales. La justificación es que tales sistemas son actualmente el tipo de SGBD predominante para las aplicaciones tradicionales de base de datos en el ámbito empresaria!. Sin embargo, los sistemas relacionales no carecen de desventajas, y los SGBD basados en objetos constituyen uno de los principales desarrollos en el área de los sistemas de base de datos, tratando precisamente de resolver dichas desventajas. Los Capítulos 25-28 examinan esta tecnología con un cierto grado de detalle. El Capítulo 25 sirve como introducción a los SGJ3D basados en objetos y examina en primer lugar los tipos de aplicaciones avanzadas de base de datos que están comenzando a surgir, explicando las desventajas del modelo de datos relacional que hacen que éste no resulte adecuado para dichos tipos de aplicaciones. El capítulo presenta a continuación los conceptos principales de la orientación a objetos y analiza los problemas de almacenar objetos en una base de datos relaciona!. El Capítulo 26 examina los SGBD orientados a objetos (SGBDOO) y comienza proporcionando una introducción a los modelos de datos orientados a objetos y a los lenguajes de programación persistente. El capítulo explica la diferencia entre el modelo de almacenamiento en dos niveles utilizado por los SGBD tradicionales y el modelo de almacenamiento en mi único nivel utilizado por los SGBDOO, explicando cómo afecta esto al acceso a los datos. También se analizan las distintas técnicas para proporcionar persistencia en los lenguajes de programación y las distintas alternativas para transformación de punteros, examinando las cuestiones de la gestión de versiones, la evolución del esquema y de las arquitecturas de los SGBDOO. El capítulo concluye mostrando brevemente cómo puede emplearse la metodología presentada en la Parte 4 del libro para las bases de datos orientadas a objetos. El Capítulo 27 contempla el modelo de objetos propuesto por ODMG (Object Data Management Group), que se ha convertido en un estándar de Jacto para los SGBDOO. El capítulo también examina ObjectStore, un SGBDOO comercial El Capítulo 28 analiza los SGBD objeto-relacionales, proporcionando una panorámica detallada de las características de gestión de objetos que se han añadido a la nueva versión del estándar SQL, SQL:2003. El capítulo también explica cómo es necesario ampliar el procesamiento y la optimización de consultas para gestionar de manera eficiente la extensibilidad de los tipos de datos. El capítulo concluye examinando algunas de las características objeto-relacionales de Oracle.
Prefacio
Parte 8
XLI
las bases de datos y la World Wide Web
La Parte 8 del libro trata del tema de la integración de los SGBD en los entornos web, así como sobre los datos semiestructurados y su relación con XML, los lenguajes de consulta XML y la integración de XML con las bases de datos. El Capítulo 29 examina la integración de los SGBD en los entorno s web. Después de proporcionar una breve introducción a Internet y a la tecnología web, el capítulo examina la adecuación de la Web como plataforma de aplicación de bases de datos y explica las ventajas y desventajas de esta técnica. A continuación se presentan diversas alternativas para la integración de los SGBD en los entorno s web, incluyendo los lenguajes de script, COI, las extensiones de servidor, Java, ADO y ADO.NET y la plataforma Internet de Oracle. El Capítulo 30 examina el tema de los datos semiestructurados y explica el lenguaje XML y por qué este lenguaje se está convirtiendo en un estándar cada vez más aceptado para la representación de datos y el intercambio de datos a través de la Web. El capítulo explica a continuación una serie de tecnologías relacionadas con XML, como los espacios de nombres, XSL, XPath, XPointer, XLink, SOAP, WSDL y UDDI. También examina cómo puede utilizarse XML Schema para definir el modelo de contenido de un documento XML y el modo en que RDF (Resource Description Framework) proporciona un marco de trabajo para el intercambio de metadatos. En el capítulo se examinan los lenguajes de consulta para XML, centrándose en particular en XQuery, propuesto por W3C. También se examinan las extensiones añadidas a SQL:2003 para permitir la publicación de datos XML y, con carácter más general, la integración de XML con las bases de datos con el fin de almacenar en éstas información XML.
Parte 9
Inteligencia empresarial
La parte final del libro trata el tema de los almacenes de datos, el procesamiento analítico en línea (OLAP) y la minería de datos. El Capítulo 31 presenta los almacenes de datos, lo que son, cómo han evolucionado y cuáles son los potenciales beneficios y problemas asociados con este tipo de sistemas. En el capítulo se examinan la arquitectura, los componentes principales y las herramientas y tecnologías asociadas con un almacén de datos. El capítulo explica también los mercados.,.de datos y los problemas relativos al desarrollo y gestión de este tipo de sistemas. Se concluye el capítulo describiendo las funcionalidades de almacén de datos proporcionadas por el SGBD de Oracle. El Capítulo 32 proporciona una técnica para el diseño de la base de datos de un almacén/mercado de datos diseñado para soportar los procesos de toma de decisiones. El capítulo describe los conceptos básicos asociados con el modelado de dimensionalidad y compara esta técnica con el modelado entidad-relación (ER) tradicional. También describe e ilustra una metodología paso a paso para el diseño de almacenes de datos, utilizando ejemplos resueltos tomados de la versión ampliada del caso de estudio de DreamHome. El capítulo concluye describiendo cómo diseñar un almacén de datos utilizando Oracle Warehouse Builder. El Capítulo 33 describe el tema del procesamiento analítico en línea (OLAP, Online Analytical Processing). Explica lo que es OLAP y las principales características de las aplicaciones OLAP. En el capítulos se analiza cómo pueden representarse datos multidimensionales y las principales categorías de herramientas OLAP. También se explican las extensiones OLAP al estándar SQL y el modo en que Oracle soporta las tecnologías OLAP. El Capítulo 34 describe el tema de la minería de datos. Se explica lo qué es la minería de datos y las principales características de las aplicaciones de minería de datos. El capítulo describe las características fundamentales de las operaciones de minería de datos y las técnicas asociadas. También se describe el proceso de minería de datos y las principales características de las herramientas de minería de datos, y en especial el soporte que Oracle presta a este tipo de tecnologías.
Apéndices El Apéndice A proporciona una descripción de DreamHome, un caso de estudio que se utiliza ampliamente en todo el libro.
XLII
Sistemas de bases de datos
Parte 1 1 Introducción a las bases de datos
2 El entorno de las bases de datos
Parte 3 9 Planificación, diseño y administración de bases de datos
10 Técnicas de determinación de hechos
12 Modelado Entidad-Relación avanzado
14 Normalización avanzada
Parte 4 18 Metodologia: monitorización y optimización del sistema final
17 Metodología: diseño fisico de bases de datos relaciona les
16 Metodologia: díseño lógico de bases de datos para el modelo relacional
20 Gestión de transacciones
21 Procesamiento de consultas
15 Metodología: diseño conceptual de la base de datos
Parte 5 19 Seguridad
Parte 6 24 Replicación y bases de datos móviles
23 Bases de datos distribuidas: avanzados
conceptos
Parte 7 27 Bases de datos
28 Bases de datos objeto-relaciona
les
orientadas a objetos: estándares y sistemas
26 Bases de datos orientadas conceptos
a objetos:
Parte 8 30 Datos semiestructurados
yXMl Parte 9 34 Mineria
de datos
330lAP
Figura P.1. Organización
32 Diseño de almacenes de datos
lógica del libro y formas recomendadas
de lectura/impartición.
Prefacio
XLIII
El Apéndice B proporciona tres casos de estudio adicionales, que pueden utilizarse como proyectos de los estudiantes.
e
proporciona infonnación de referencia sobre organización de archivos y estructuras de almaEl Apéndice cenamiento, información que es necesaria para comprender la metodología de diseño fisico de bases de datos presentada en el Capítulo 17 y el tema del procesamiento de consultas del Capítulo 21. El Apéndice D describe las 12 reglas de Codd para un SGBD relacional, las cuales forman una comparativa con la que pueden identificarse los productos SGBD relaciona les 'reales'. El Apéndice E examina la cuestión del SQL embebido y el SQL dinámico, con programas de ejemplo en lenguaje C. El capítulo también examina el estándar ODBC (Open Database Connectivity), que se ha consolidado como un estándar de Jacto del sector para el acceso a bases de datos SQL heterogéneas. El Apéndice F describe dos notaciones alternativas de modelado de datos que pueden emplearse en lugar de UML, que son la notación de Chen y la notación en pie de cuervo. El Apéndice G resume los pasos de la metodología presentada en los Capítulos 15-18 para el diseño conceptual, lógico y fisico de la base de datos. El Apéndice H (véase el sitio web de acompañamiento) explica cómo estimar los requisitos de espacio de disco para una base de datos OracIe. El Apéndice 1 (véase el sitio web de acompañamiento) proporciona algunas script web para complementar el Capítulo 29, dedicado a la integración de los SGBD y la Web. En la Figura P.1 se ilustra la organización lógica del libro y las formas de lectura e impartición recomendadas.
Correcciones y sugerencias Ya que un libro de texto de este tamaño es tan vulnerable a los errores, desacuerdos, omisiones y confusiones, solicitamos al lector su opinión para futuras reimpresiones y ediciones. Los comentarios, las correcciones y las sugerencias constructivas deben enviarse a Pearson Education o por correo electrónico a: thomas.connoUy@paisl~.ac.uk
XLIV
Sistemas de bases de datos
Agradecimientos Este libro es el resultado de muchos años de trabajo por parte de los autores en empresas, en la investigación y en el mundo académico. Resulta por tanto dificil enumerar a todas las personas que nos han ayudado directa o indirectamente en nuestros esfuerzos. Talo cual idea puede haber parecido insignificante en el momento en que la oímos por primera vez y, sin embargo, habrá tenido un efecto de gran importancia posteriormente. Pedimos de nuevo disculpas a todos aquellos a los que no mencionamos aquí. Sin embargo, nuestra gratitud y nuestras disculpas van dirigidas en primer lugar a nuestras familias, que a lo largo de los años han sido relegadas e incluso ignoradas durante las épocas de mayor trabajo. A continuación, para la primera edición, queremos dar las gracias a nuestros editores Dr Simon Plumtree y Nicky Jaeger, por su ayuda, apoyo y profesionalidad durante la redacción del libro; y a nuestro editor de producción del libro Martin Tytler y al editor de copia Lionel Browne. También queremos dar las gracias a los revisores de la primera edición, que contribuyeron con sus comentarios, sugerencias y consejos. En particular, queremos mencionar a: William H. Gwinn, Instructor, Texas Tech University; Adrian Lamer, De Montfort University, Leicester; Profesor Andrew McGettrick, University of Strathclyde; Dennis McLeod, Profesor de Informática, University of Southern California; Josephine DeGuzman Mendoza, Profesor asociado, California State University; JeffNaughton, Profesor A. B. Schwarzkopf, University ofOklahoma; Junping Sun, Profesor ayudante, Nova Southeastern University; Donovan Young, Profesor asociado, Georgia Tech; Dr Barry Eaglestone, Catedrático en Informática, University of Bradford; John Wade, IBM. También queremos dar las gracias a Anne Strachan por su contribución a la primera edición. Para la segunda edición, queremos dar primero las gracias a Sally Mortimore, nuestro editor, y a Martin Klopstock y Dylan Reisenberger del equipo de producción. También queremos agradecer a los revisores de la segunda edición, que contribuyeron con sus comentarios, sugerencias y consejos. En particular, queremos mencionar a: Stephano Ceri, Politecnico di Milano; Lars Gillberg, Mid Sweden University, Oestersund; Dawn JutIa, St Mary's University, Halifax, Canadá; Julie McCann, City University, Londres; Munindar Singh, North Carolina State University; Hugh Darwen, Hursely, Reino Unido; Claude Delobel, París, Francia; Dennis Murray, Reading, Reino Unido; y de nuestro propio departamento a John Kawala y al Dr Peter Knaggs. Para la tercera y cuarta ediciones, queremos dar primero las gracias a Kate Brewin, nuestro editor, a Stuart Hay, Kay Holman y Mary Lince del equipo de producción y a los editores de copia Robert Chaundy y Ruth Freestone King. También queremos agradecer a los revisores de la segunda edición, que contribuyeron con sus comentarios, sugerencias y consejos. En particular, queremos mencionar a: Richard Cooper, University of Glasgow, Reino Unido; Emma Eliason, University of Orebro, Suecia; Sari Hakkarainen, Stockholm University y the Royal Institute of Technology; Nenad Jukic, Loyola University Chicago, EE.UU; Jan Paredaens, University of Antwerp, Bélgica; Stephen Priest, Daniel Webster College, EE.UU. Hay muchos otros que siguen siendo para nosotros anónimos y a los que queremos dar las gracias por el tiempo que han invertido en la lectura del manuscrito .. También queremos dar las gracias a MaIcolm Bronte-Stewart por el concepto de DreamHome, a Moira O'Donnell por garantizar la precisión de del caso de estudio Wellmeadows Hospital, a Alistair McMonnies, Richard Beeby y Pauline Robertson por su ayuda con el material para el sitio web y un agradecimiento especial a la secretaria de Thomas, Lyndonne MacLeod y a la secretaria de Carolyn, June Blackburn, por su ayuda y soporte a lo largo de los años. Thomas M. Connolly Carolyn E. Begg Glasgow, Marzo de 2004
Prefacio
XLV
Agradecimientos del editor Queremos dar las gracias a las siguientes organizaciones por su permiso para reproducir material incluido en el libro: The McGraw-Hill Companies, Inc., New York por la Figura 19.11, reproducida de BYTE Magazine, Junio 1997. Reproducida con permiso. © by The McGraw-Hill Companies, Inc., New York, NY USA. Todos los derechos reservados; las Figuras 27.4 y 27.5 son diagramas de «Common Warehouse Metamodel (CWM) Specification», Marzo 2003, Versión 1.1, Volumen 1, formaI/03-03-02. Reimpreso con permiso. Object Management, Inc. © OMG 2003; capturas de pantalla reimpresas con permiso de Microsoft Corporation. En algunos casos no hemos podido determinar los propietarios de determinado material, y agradeceríamos cualquier información que nos permita hacerlo.
Características del libro
XLVI
Cap;I\.I.'
Capítulo
S¡alMna
bando •••• archivo.
Introducción
a las bases de datos
Objetivos del capitulo: EnCSlccapilulo.prcndcnj • •
AlgUllO:'lll_c"'llluncsdelos~iSlcmasdebascsded'IO!l LasearaocleñSlJcas de los SiSlCIlW basados en an:llOvoa.
•
Losproblemaw:>ciadoialalknocab:>oatb.enan:hi>'O
•
El Slg,urlCadodclltmullO'bucdelbl05'
•
F.Jsop1lflCadodd
• tu funcioncltipocu
Inll'Oduc<:ió".I
•••• bas ••
d.dalos
7
1.2.1 Latécnica basada en archivos
ltrnuno
'siSlemadc
pio6ndebasc$dc-"·(SGBD)
de un SGBO
•
Los componcnlCl
• •
El personal ,mphcado en cl cntOflWlSGllD Lani,toriadcldesar",llodclosSGllD
•
La-•• 'enlajasydesvenlajasdelosSGBD
Una eole
Los S,SIC"'"'Sb;¡•• lcm ",dearehi· vo "",nu,1l con los que to.xlos nosolros esl:uno< familianzOOos. Por: ejemplo. pu«k c~ un areh,vo m:mual cnun;lQq:anÍ7.aciónpQr.lalbcrga.-lodala~nc'aclucrnacintc:rna~lilIivaaunproyttlo.aunpro. dueto. a u ••• larc.a. a un el......, o a "" cmplc3do. Nonn;dlll('nu:. uislm mucho!. de dicbos an:tli,-os. los cv.a. 1csC$¡nc •••• ctlqUCIaryalmaccnar ••• ...."ollÚr:O<'lCSde..,pndad L.oo;lup· res donde se a1_~"""'arcbi_¡u:dmdi~dc lbv<:.l3mboEn plWcur:ol_de qurid:ad.o puo.cnirassegw2SddediflCio_EIInUO:fuapropaCa$3,probab!C'rnCnlcd,spongamosdc alg~nupodefisle1nlldean:hivoenelquedeposilarooslolnxibos.lasfxtufb.lalOfofmaciónbanc3l'i .•• 1os ••.••••ralosdcseguru&.t'lc.SiJ'ott(:Sj'al11Ofronsul.aralgo.vamosanUCSIroan:h,>'Ol'Cf"IKL"lybuscamosentl. de pnnc'pio a fin. 1l:lSla e.\COIllrar la mfoonacióodeseada,Ahcmalivamc:me. rUOda cuaodo hay un 11"" nolmcm dc elementos y lo únICO que JJO>CesiW'l1Of,esallD3lCCnarlo5oClllI3lCrIos.Sincmbarxo.Jossi$lL-masmanuaJesdearrlu>'OdejandeliCr~nlrsc-'· dotenc:mosqueestablcccrrcfef'Cllciaor;~opn:a:sarlamfonnaci(lnCOOll"""''''lo6documcnoos.Por: eJCOllplo.UDlIagenciainmoblharialIpicapodñadisp;lnerde ••• arduvo..".,.sopancadaiNnucblcquedcscc vcnOe.-o •••• iw. pan cada po ••:ucial comJ'W1lCb o i'"l"ihno y pu;Il cada mocmbro de su penonaI. P1CD5Cen eleoormeesfPCIIDq""f>Crequcnñapal1lrcspondcrala~"guimtcscuo:s.1OnC$
po-incipalca del enlOrTlO SGBO
L.ahJSlOI;adelalnv~":lCióocnli>lcm:os"'bases"';("".,ru,!UOO. Con apmas 20 anos de ;IJIlICilabd como carJ1f!Ode: InVC>llp' clÓnCl(nlíflCll.. III onvuupr:ióocnbuc:sdc:daoos hapcnnlt.oocl ~,mlt"'o'" LInll,nd\lWLlde Ios_· "1C_dc •••rOOtlllCOÓIIQIOCsólooCnIosEsudoosUnodosrllCt"'llIIO$IOOOOmlllQnQde~poo-oi'io_ Losdlvtl'SCJ$loposcnbin,'~ia:a<:o6n",blJvaa1asbasc::ldto:bloo.lurlpnmllodo.-eaI".aravanct:Sfunda. mcnlaIescnJos •• ""maconSidc",ble en dl~CfWS cam· pdadeu
Objetivos del capítulo claramente resaltados.
•
•.Qut vi~iccndas de 1= domutoriO$ hay disponibles
•
¡".Qué araJ1amcmQ¡; e.iSle~ para alquilar.
•
¿eu"1 es el precio medjo de alquiler Ix"a un pi<;o de dos dOJ1niH)rios'!
para la \'Cnt.:Ique .engan jan:lin y ga"'Je1
•
~Cuálcscl
mel101 de 5 km del ccmro de la eiuda.d?
imporle 10la1dc l. TlÓnuna anual de 1lld¡)c1 persona!"!
.~Cuá.lcslacompanciÓf!enlrrkl$,~deloíh"nomrsyI0$'ngresosprcvUlOlSp:lf1\CSIe1 •
~~
••.••.•b,~"""""",lesprc,-isI"'par.lclpról:'rooa/lo1
lloyo:ndosc pan cada unoan formulaoo •• m,laral quefCmllCSUllcn la Filura l.l(b). Con la I.S1Slcncia del dep:lIumemo de proccsosdedalos. el dcpaJ1amcn'ode vcnLncn:<> un $i$lcma de información paragcsloonar cl alquiler dc 101 inmuebles. El S,SlcmaCSl"oomp"CSlOporlll:l
°
Cada concepto importante está claramente definido y se ha resaltado con un tipo de letra diferente. Capitulo
10
Tknieaa
d.
det ••••• i••ació"
de h6choa
293
H•.y dos tip<>llOCsl.ende.po· cioproporcionndoacontmuneión.Comoejempl"",lceI1es!,oncsdeformn,olihrepodrbnloUC$la·. l..,s prohlcma' L"O/1la. c""-"ion ••••de fOl"m~l" libre son q~ 1", resp"csl"-' .x..cn,daspocdcn onuI13rdificilcsdeI300131'y.enalgunoscailOS.puc.dcn no correspondel)C Mdccu:Id,unen· leeoolllcucs.tiónqueiCpo-eguma. l.a.C:'la..e'pcc(f"",,,dcl"'~lfIICrcllctwlel~ ••.•• nario.lb.buaacu.:slilln.lapenonldebcc~ircnln:II.SIl:¡;pocsw;di>f'Oll,blcs.loquchattquebfC.Slll tados\CalllDllCbonlÚUe.lrsdetalJul •. I'OI"OlroIado.>.IaJlCf'dcaly""debccamt>tarsc·.Lapc11iOllaqucrenc""e1 <:ui:>l1On.:u1Opuc.dc lCIlC1la O(lCión de m.pondI:r 'S,' o 'No' aesta cuc.uón. o puede dá~1c I~ O(lCi6n de ck-· gorcmrc:un3..L'QIOOporc;:mplo·Muyde'lCuerdo·. ·OcllCucrdo·. 'No lcng<1"l'lOión·. 'Endes3~ue,,;!,)')"Mu'jcn,b,"c"ado'
FIgura 2.11.
ArqlUledu,adeaerw:lo
rcd.k'quca"' •.••zpucdcJlffi""'X";lfprobk:mlllode......wnucnw.Por:cFmpIo.confidcreelca quesnloc •••:lo6nomllrt$de1OdosIosempkildoJsquclral»FncnlaoflCl~""""""" npKQf C$IlI ..:>Iicllud en SQL. 1''¡aR el CapilulQ 5} ok la fcnna so: •••••••c SF.LECTINamo •.•_ }'KO\IBrarct1bSlolls \\lll;REbllr-.t!o
•.••dcunusuano 163MaUlSl.1'oo.ierIlO1
EII CSla sección. van.x. ~tar Jlf11l"oCro una paMIrimica del caso de CloluJoo de DU"",1IOfW y lucg<) 1I111,,:an:..o.dichoc~ parallllSlnreómo ••••ablecct un ~"CC\ode base dcdalos.. En "..uclllar. ilu\ln· ••IOdoC1lquep...:dcncmplcan.c:laslécnK:z¡dedctcnninaci6adehcchol;y'UCITIl)'I:ladocumen· .ación'f'IC5CgcneracnlaspnInCJ'lll'C1apasdelriclodedcsarrollodcl ••sle" •• debascdedalOS .••. dcc". e"ltielapasdcpla",n,':ocióodcbtoa""dedalos.dedcfin,c;óndcls •• 'cma)dcr\:COp,11lC.6nyanáh.isdc requilllOS
"'~cl .lIrrd-HoA;\l)b'_··'6)M
••nSl
P\lcStO q"" el •• ¡"V,dor do arc~" ••• no lte,IC n",soín ,"OO<>;,mielllllde SQL. el SGBO l,ellC q,," solkilotr al ""rv,dordc archIVO< 1,,, :,rcblv", c"rrc'I",,,dlelll~<. la, ,d:"'I""cs Br.""" y Sla~."" lugar ,le .oheitaf ,imrle. ">cntcl<.>:>nombrc.nlu·" ••• dclacoo,>ulla. La anlllilCc!UCd del scrv,""'dc atrh"·,,,, llCllC. 1"""lanr.1. 're. tlcsvelOlajasJ'rincip;11cs: 11) lby una gr.1Ocanlldad de u:lflCO de rctI. ¡21Sc n:qu~
10.4 Ejemplo de utilización de técnicas de determinación de hechos
una ropia complera del SGBO en cadaC
131E1cnnuo1de~X1nCUfrl:nc •.•. der«"JlC<>"oCn)deUlOC'p1'>""""'veo..
de uabap ••..•• _c""'plejOlo.)";l",,"pucdchabcr
2.6.3 Arquitectura cliente-servidor tradicional en dos niveles Para rey:,l"crla, :> compOnCnlC' ",f1ware para ("'",ar el sistema. C(llllO el j)(Hnhrc sllllic..,.h.yunprlanlcron,un .•nuucl\C •••odorL"11unadel('nll"'adllubocacióndcn'",tIcunaredolcá-c~localylon. La hgwa 2.12 iluwalalf'llU"CC1\1r.i1docnfC·.er.odúryla h¡Ur:lL13 n••.••••"'a1gu""'poI-Jbln <'Of1\btnacioncsdcbI<.lp.lloj!Cachc ••••,..,"odúr. l..•••llpl~ ~cmprnarlabc""n:qu'''IOSUII. •.••••'·•.•.•dcdalosC>Un.-........sa.JlOI"cual1O~'OfDJ'OIICOIC< p'''''iJ'Olb;lahascdedat •.•••lalóglcadelnlnsan:ionc •. blóJlCldcnego.: •••• yltOnde dalo.yla ,mcñ;ar:l!i~'cade CSfO>eo.np"nen'co. El dicnlc (nrvcl Il ~ pnnc'{IlIh\"oClltCre..I"","llO.micnlra,qucclscr •.ió: •. (n,vcl ~lesJ'ri'lCil,"ln'cnICreSIX"'sablcde ••mÚni"ra'
Se utilizan diagramas por todo el libro para clarificar y ampliar los conceptos.
10.4.1 Elcaso de estudio de DresmHome: panorámica La pnnICra s""""""l •.•• DUdmUome fue abic1ta en 1992 en Gla.o·.Cn cl Re ••.•" Unido. Desde (:01'00<. .••.. la cmpruah •. crecidodcf","n'ronllOuayah.-n'icned,vt'lSllS"",,'"salesenlanlll)"OI"Íadewp".::ipale>.ci ••. dado:sdelhinoUnido.S.n~laemp. Ademh, la oom'blOCaco6n y eornp.vuci6nde i"f....-mación cnlre_W'SaIcs.. incl ••••.•de••uo de Iamismae"Idad.t:SbastllnIedcfrientc La rnJ'tC\Of:ldclacmpC$;l.Sall) MeU ••.cadovolo.crcequc>Cesl ••• lgu,e ••" b";~e mc "'Iá c. inmuch"'" dur.,"le un pe.iodo f,JoOde '",mpo. Drr"",/J"",~ cucnla llC.""hncme con uoo.< 2000 emplea· dos que lr.lbajan CIIcien wcun.ales. ~un nuevo rnlpl<.'lldo se incorpOr.ia lacml""$l-.lIC unl" .• el fOl" .• :.11la FlIura 10.1 poflsahle de cono.ro/..-. un grupo de cmplc::>da¡qllC' 'ICOICla cafcgor;~ dc ayudalllC" (A>S'lilanli). En la J'-igura 10.2 lr. un ejc"'pIo de la J'rimcca página de un inforrnrdrmrlcsc iooocan 100o
Una orientación muy práctica. Cada capítulo contiene muchos ejemplos resueltos para ilustrar los distintos conceptos cubiertos.
Características del libro
ClIpitulo1
•
Int,od ••CCiÚnllIUb"sesdedlltos
29
-
ElSG80~lII1IC4~cnntrol.1do.lah2scde(btoll..l'rop.lox_rntt:>nismoo¡"'squridad. "'le¡pidad.oooooIdc:CllI'Il:UlTl:n(qyC\lQlRJldcn.:upmlCiún."'¡.--un~IC<:<:SIblcpord_ no·'farnb;60prOpOrClOO;l •••• ~dc:ylSU>p>n.<.it1lrlifl(Vb •••••• ronloo;qucclllSUMiolicnc
•.. •
•
I)Q,cnlla cómo funOona el a1gonuno S) ••.•onR
fJ enl\llTlOSG8DC>.Ui~lodeh."hn •.•; (IaCOf11Jlllladon). Iktofl •••.•••.(el SGlm.cl-llSlMnJ.O(l<"'nui,""ylM';Slenw.dc."helCión).ded31_dl:f'l"'dimicolOS)'depcnonas.Lu~<,quelereb~:;~
de eaadons
de ba=
de
Ul~ rake$ d<;1", SGBD "ll.in erl 10'<'¡'lema, llasadi>< en archivo>. L<» s.ire,;cnl,ld" poorIMS \luform"l;oo Mon"~emenl SY"lem). mjentrn, (I~ el modelo ell red {>COUASYL eSl~ ~;':m[>lif",ad" por lDS (lnlcgr¡uc Dau St<>re). ambo::.
21.17.
U¡il;,;>,>tIu el ""'lncmn II00el <1:><10 al pri,>r;ipi"d.c lo.• cjcrcki""del leS eo",,,llas ",n "'nl~rIl;ca"'entc eorrec1a. (a)
••• ul1.s
621
de
WIIERE
1_2
bl'hqueead,ulloOOI"",siguicnlcswrmit><: (~) dato<
Cnphul0 3, dclcmlL,1<;
~ilas "i¡¡uie,,·
'
~h.h"IIU .••nb••. ,\NI)~. __
"" ••••• 'Cn)I\wnorHOlel'
,\NI)rtype:>
100;
FRO~t_l<.~b._1I WIIEREI<._.t>._,v"n...--. (el
'Grw~1t0lC1',
SEUCT'-'h_ t-RO~I_l<.lkIcIlJrIOb.Room,
21.18
"
p,<>por~"'''~euMroeJC'''plosdesi'ICm"sdcba$e
••.••••lOOOOmpllli. (Px cada suc""",l) y
(bISF:U;Crll~lI_
\\II~:RE
1.1.
••.
~.
b'-"¡" ANU ~hcMlNo' "Nllo_HG.·IU2·;
'H21' ,,¡\U
b._'
,__
ANO type."S'
Ulili, .•mdo de n....,vo el c:;qucllla HOld. r;n,¡"icas dada, cn la &.:dÓn 2 1.3.2 p"'" '",nst'''"Mr 1,,, conu.",la., s"llas en "n" rumm m~s etieiente. bl'liquc cada i"'w y enu"de la' regla.
(al SEU;cr,.~.,1)'pe.'~
(b)
baseded:uCl
le)
'lSl.madegc"liónlkl=csdcdaia<;
(d)
prop3ffi3de3plltJl<:i6ndcbaseslkdalOlo
le) eO
'nJcpmdc •••••• dcbdalos "'1l1lfi
rRO~IRoom'.IooIun\IO._h WIIERE •.I'OOff\No'b_ANUb_.~_ANl> h __ (b)
' 'Grosvenorl\OOeI'ANU,._:>
SELECTII~.g
100.
_
rHOMRaatn'._I<.ll<>
CI'lnl~
\l"IIEREh_O· ••._Al\UII~·b_INoANOn_"a' n.-· ·G"".'CDOr HOlel' ANI)_,om_ ANI)tla1eTo
,,"¡a>;
1.3
Dc>cnNoelenroq""dctralamienlodelnsdal<>lladopla~lU¡p""siSl:ema.,ha.~cllarchivo< Jl\d>qucl".
21.19
Ulili ••.•'loo el ""'I""n,,,
De""ri!>. la, p,-;ne,p~lcscar:\CJen'Micasdcl da cu archivos.
•
un fr>dice
Oo:scrillalosci""v«llnpollcnle_.delcnMnoSCRDycceÓmolO:relac;'-""'''ell!rc~r
• •
"" frldicc decl"vc \In;ndi.-eR·-uee~celalribul"""",enR""",;
lb
bphquccll'X'l'
•••
y
MlllpárclMCOllla
1écnicu basa
••nenlOO>S:
n¡ndice
!'Q.,h
sir; dcohvrdnmicP\{(] whre los.uibUlo.deduve
10_000
nOi.sl""'-lR~1
'" 100000 '"
"Oi.sli~Hoorn) ••Otsli~Room,
"'"
nTupIcs(lkllcl) oTupIcs(BooI;.q)
dcsarroll~dc.p~~ u>U3I'>O
Un conjunto de cuestiones de repaso, cuyas respuestas pueden encontrarse en el texto.
C.pítulo21
Proc ••• mi ••••tod.c:o
.'M)
ptinc'p;ll,
roomNoIhotelNc en Room:
c~lerna hOlO1NC en Room'
•••:••ndario~el,,";bulOtype""Room.
nTuplcs(Roornl
ad,.nnislt3dordeb.bawdedaoos
(e,OOtiIadorIói_dcb.basedeLblos (dlOOcñadorfl$Ocodela'-edcdalco;
__ '1-) ••••..(1.1'
HOlel. ,u[Xlflga q,," e~'>lcn Iol; sjg:";c"I~~ ¡,Id;oes
1.4 l.j
le) (O
••todeco
del optimLZador de consu!"'"
SEI,ECTrlype.rpn.:. rRO.'l/l00m'._~
Cuestiones de repaso
(b¡
dl'wl1lc~
211ó.CaleuIc.ICOGI"lkwll'C.CSltll ••'!-;a,;euadasendEJC1Ilplo21.1.,1.l'Cla.ción_l ., _ uene.soo '''¡>las, <.ihay.soo emplc:tdo:s con caI.~O'U de M.nager s, hay 10sucuual.scnL;;lnd", •.
EnI",laovmujaodcla¡lalle.dcbasesde
(bl
PrOC:.llImie
de rrovarnaci6n
Ejercicios
~~::'I:'~~I~~:a~=~~:': •
C.pltulo21
211j
XLVII
bF3ICliJf(Room) bFacK>«HoleI) bf"acIOf(BookinC)
'"
Un conjunto de ejercicios que los profesores pueden utilizar para comprobar la comprensión del capítulo por parte de los estudiantes, pudiendo encontrarse las respuestas en la Guía del Profesor.
••••• l~a
Resumen del capítulo •
lA$ot"..,'_dclprvcesa",ienlo~_I","!iOIllralll.romw-_rom.ul •• _rit:amuJ\lcngaajclka1to ,,¡."d • .......,QJ_SQl..munaC5tral(g •••de.J'OC'I'C16nCCllTl:CboyerlClCnIo(expresadaC1lWlknJuajcde ~=.-;:1.
como. poreJCTllplo. clilgd>r:o
,dacoonal.
y .jecu.",
die ••.•• ro;U.gia """" e~lr.lC:f los d:Yll$llOl¡-
•
P\oc$IOl/I'C hay mucha.. lrllnsform:lCioncs Cllha de .Iu') lIi,"<'I. el SGRD llene (J"': elegir "'Iuell. que nlllllll""" el uso de n.'Cu
•
Ilayd"'léenie"'pr;,lCil"'lcl; ••• opl'mi'''''ión, •••••. ,on'"Illl<.''u'''lucl"'.,... ••• t8~g;" ••• "",lenco",I""", en b pr.iclic~. Lo p cstm.flaS ba
.'")pruce:um ••••••• lkcomullao.,...di,;..¡,neC1lel,laln)f:»c!.pnncl(llOb;~i6n(lDlicticoy v••hd ••em¡.op.i ••••'.x>ón. ~ióadc códigoy.¡enonón. U;. pnmaas l=f:lr§(:S pucdcnoal'l-"'""" ••• IICmp:>dccompiu<,lÓlIycn¡JemPOde.,.,....,iúoI. • L.I de:;ll(llC dlC~ consulta ""'" "ndeuc. y SClWnue.mentc romx:ta. Los e1~<' líplCa' dc la dclooon'p
L:I ol'limilación de e,,"Sullm; ruede apli'a'rcglas de lransfQ"ua"ó" pOI1lC/lnven;,unauprc_,ión(le Illllehl1l rel:K:ioml en unacxl're,ióncquivalo'lle4"c."''''pa4''''e."rl.dícieme. E",,,, bSl'Cgla,dc t•.~"sf"f!I",eión se jncluycnlaeonexiónen e:l.\l;oo.adeorc",eioolC.dc ",I<,<.."ión. l"eOlun"I'liv,dad 'naci6nThcla(ydcll'rodUCIocan""iano).'aeoomu l,.¡",(bdde la<:la (y dcl pr ••d ••..-cocanoiallo) y la:o.'lOCi.¡i .>
.Enlrel3>~bcurist;cassciDclu)"."la=l'-laci6ndcla.t,IIri6n.la";lilXi6ndcla:l.'iOC""',odaddc b.opIClOIICSbonaoias 1"""'.--conJenulot< -.boo,~,x. modoqucaqudbquc¡""I3II1ao >elc<:<.•••.••••~lllkrcslnC1'\;b,;eeJCClllCllprimcro.a<: •
La ~¡" ••••ióo d. eo,M"'penok de la inromlllClÓn es'-""'Í>lJCa rec<>ptlada",1 Cll:Uog<>del ~,••• rna_ F""re l~s""aod;'lICa.lípica.&<:illC'u)'clacanl"'ahdaddccad3relaciónluo ••. clnúmcmdcbllcsd"!i"'<> .• l"'r.t,ad;'.I"hU!o.la'.ardmalodad,lcselccei6nJc,·adaalril>llloyclnllmcrudcniyejc.cnca(laín
•
u,¡prlll<,palc''''lrJleg'asp:¡mirtll'lolllenl''rl'u¡>cr:ICión'''que.ld'ClÓllCClbtdariollll)dcclllSlCringy rondH."ióndedesJguald:od''''lIoíndic.sceundanodcllpoB'-lrtt
•
u.<. prineip:tles CSlr.IlCI'''' par:¡ Iloplcmcnw la upención de •..•••n•.••"""io\n son: C'1IaCIÓlImcdunle buclcarudadlJporbloques.<:oml:w.naei6nmcdl'nlClou.;lc""KIado'r>dcudo.combonaeióon'lCdianlc:ordc-_·iOO· ••••.'.:larCOOl'lbnlaciOO/orldI
•
Cnn la tknic:o.de mattria.liud6oo la .ahdadc lbQO{l<:f1ICi6n le a1nll«NC1l """ relación lCnlpOfal pantl ••• po•••-""amicn ••.• po.-panedclaSl.gu>cnleopcr:toCiót.O""t6mJCa.lr ••.•••"".~cn~ren ""dt1ta""'",.ulladoo.deu"'Q('Crac'6n."">oálI,,,",abopcraclÓll •.•g"'cnl ••• nCTC3lu ••• n:I~OÓII'lcmpo-
Un resumen al final de cada capítulo, donde se cubren los principales conceptos presentados.
W~N>_('~w
••/wt
••.t""'01o~~"I"
=r~::!:=~P?~~'tI~ bi..:..:.
~
~~~~!i.:r~~ .-. ~ ~ .. - _. _.ll"""1. •••.
...
•..•.•....
.•.....,
..•
•..........
Un sitio web de acompañamiento en www. booksites.net/connbegg. En la página siguiente se proporcionan detalles adicionales sobre su contenido.
XLVIII
Características
del libro
Cklpter 1- RebtionallVloflel Tutoría} Whal
kind of dala model
Explain
(11.)
is lhe relatíonal. model?
lhe followingtelIllSinlhecomextoflherelalionaldrdalTlOdel
Rtla.tion Attnbute 00""'"
T"p" Degret
Cardinality (b)
UsetheSuwliers-Pattsdalabt.Setoprovideexamp]¡¡sofe&:h(&eeAppendix loflhislulorisl)
(a)
Explain
lhe followin(;
lenns
in lhe COBen
ofthe
relatioMl.
dala model
CandidaleKey
PrinwyKey ForeignKey (b)
UselheSuppliers-PMlsdalahasetoprovidee=plesofeach
Tutoriales sobre capítulos seleccionados
Aet;"!l.' PI-l Practise
using
the Microsoft
Access
following tapies: creatíng tables, and the web publísher wizard.
OneIÚJU!
a
A Microsoft
help facilities.
data types,
Search
primal)'
[(Ir help
key, referential
or ask questions integrity,
Dntabase Access
database
is a collectíon
of objects,
not just a single table of data. Oue
dalabase fiJe contains the tables as well as queries, you use the information in the database
forros, reports
When
dia!og box is displayed,
Pl~1
00 the
data valídation
you f1rst ¡oad Access,
the Microsoft
Access
and other objects
as shown
Manual de laboratorio para Access
that he!p
in Figure
Parte
Introducción
Capítulo 1 Introducción a las bases de datos Capítulo 2 El entorno de la base de datos
Introducción a las bases de datos
Objetivos del capítulo: En este capítulo aprenderá: • •
Algunos usos comunes de los sístemas de bases de datos. Las característícas de los sistemas basados en archivos.
•
Los problemas asociados a la técnica basada en archivo.
•
El significado del término 'base de datos'.
•
El significado del término 'sistema de gestión de bases de datos' (SGBD).
•
Las funciones típicas de un SGBD.
•
Los componentes principales del entorno SGBD.
• •
El personal implicado en el entorno SGBD. La historia del desarrollo de los SGBD.
•
Las ventajas y desventajas de los SGBD.
La historia de la investigación en sistemas de bases de datos es de una excepcional productividad y ha tenido un impacto económico extraordinario. Con apenas 20 años de antiguedad como campo de investigación científica, la investigación en bases de datos ha permitido el surgimiento de una industria de los servicios de información que sólo en los Estados Unidos factura unos 10.000 millones de dólares por año. Los diversos logros en la investigación relativa a las bases de datos han permitido realizar avances fundamentales en los sistemas de comunicaciones, transporte y logística, gestión financiera, sistemas de gestión del conocimiento, accesibilidad a la literatura técnica y una miríada de otras aplicaciones tanto civiles como militares. También han servido como base para permitir un progreso considerable en diversos campos básicos de la ciencia, desde la informática a la biología. (Silberschatz el al., 1990, 1996) Esta cita está tomada de una conferencia sobre sistemas de bases de datos celebrada a principios de la década de 1990 y que tuvo su continuación en otra conferencia posterior en 1996, y nos sirve como motivación para el estudio del tema de este libro: los sistemas de bases de datos. Desde la celebración de estas conferencias, la importancia de los sistemas de bases de datos se ha incrementado todavía más, con significativos desarrollos en lo que respecta a la capacidad del hardware, a la funcionalidad de éste y a las comunicaciones, incluyendo la aparición de Internet, del comercio electrónico, de los sistemas de inteligencia empresarial, de las comunicaciones móviles y de la informática reticular. Los sistemas de bases de datos son, posiblemente, el desarrollo más importante en el campo de la ingeniería del software y las bases de datos forman ahora el marco de trabajo fundamental de los sistemas de formación, habiendo cambiado de forma sig-
4
Sistemas de bases de datos
nificativa la manera en que muchas organizaciones operan. La tecnología de bases de datos constituye un área de enorme interés en la que trabaja y, desde su aparición, ha actuado de catalizador para muchos desarrollos importantes en ingeniería del software. La conferencia a la que aludimos puso de manifiesto que los desarrollos en sistemas de bases de datos no habían terminado, al contrario de lo que algunas personas opinaban. De hecho, parafraseando una antigua frase pronunciada por un político, puede que sólo estemos al final del principio de los desarrollos. Las aplicaciones que será preciso soportar en el futuro tienen un grado de complejidad tanto más alto que nos veremos abocados a rehacer muchos de los algoritmo s que actualmente se utilizan, como por ejemplo los algoritmo s para el almacenamiento y acceso a archivos y para la optimización de consultas. El desarrollo de estos algoritmo s originales ha tenido significativas ramificaciones en la ingeniería del software y el desarrollo de nuevos algoritmo s tendrá, sin ninguna duda, efectos similares. En este primer capítulo vamos a proporcionar una introducción a los sistemas de bases de datos.
Estructura del capítulo En la Sección 1.1 vamos a examinar algunas de las aplicaciones de los sistemas de bases de datos que podemos encontrar en nuestra vida cotidiana, pero de las que quizá no seamos conscientes. En las Secciones 1.2 y 1.3 compararemos la antigua técnica basada en archivos para la informatización de sistemas de archivos manuales con la técnica moderna, mucho más adecuada, que se apoya en las bases de datos. En la Sección lA hablaremos de los cuatro tipos de papeles que juegan las personas en un entorno de bases de datos, es decir: administradores de datos y de bases de datos, diseñadores de bases de datos, desarrolladores de aplicaciones y usuarios finales. En la Sección 1.5 proporcionamos una breve historia de los sistemas de bases de datos, la cual está seguida, en la Sección 1.6, por un análisis de las ventajas y desventajas de los sistemas de bases de datos. A lo largo del libro, ilustraremos los conceptos utilizando un caso de estudio basado en una empresa ficticia de gestión inmobiliaria denominada DreamHome. Proporcionamos una descripción detallada de este caso de estudio en la Sección 1004 Y en el Apéndice A. En el Apéndice B se presentan otros casos de estudio que pretenden proporcionar más proyectos de carácter realista con los que pueda practica el lector. Al final de muchos capítulos se incluyen ejercicios basados en estos casos de estudio.
1.1 Introducción Las bases de datos forman hoy en día una parte integrante de nuestra vida cotidiana, hasta tal punto que muchas veces no somos conscientes de estar usando una base de datos. Para comenzar nuestras explicaciones sobre las bases de datos, vamos a examinar en esta sección algunas explicaciones de este tipo de sistemas. En lo que respecta a las explicaciones siguientes, consideraremos que una base de datos es una colección de datos relacionados y que el Sistema de Gestión de Bases de Datos (SGBD) es el software que gestiona y controla el acceso a la base de datos. Una aplicación de bases de datos es simplemente un programa que interactúa con la base de datos en algún punto de su ejecución. También utilizaremos el término más inclusivo sistema de base de datos para referimos a una colección de programas de aplicación que interactúan con la base de datos, junto con el SQL y la propia base de datos. En la Sección 1.3 proporcionaremos definiciones más precisas.
Las compras en el supermercado Cuando se compra cualquier tipo de producto en el supermercado local, lo más probable es que se esté accediendo a una base de datos. El cajero utiliza un lector de códigos de barras para introducir en el sistema cada una de las compras. Este proceso de introducción de datos está enlazado con un programa de aplicación que utiliza el código de barras para averiguar el precio del elemento, que se extrae de una base de datos de productos. El programa reduce a continuación el número de elementos existentes y muestra el precio en la pantalla del cajero. Si el número de productos existentes en almacén cae por debajo de un umbral especificado, el sistema de bases de datos puede emitir automáticamente un pedido para tener más existencias de dicho producto. Si un cliente telefonea al supermercado, un asistente puede comprobar si un cierto producto está dis-
Capítulo 1 Introducción a las bases de datos
5
ponible en almacén ejecutando el programa de aplicación que determina la disponibilidad a partir de la base de datos.
Compras utilizando una tarjeta de crédito Cuando se compran productos utilizando la tarjeta de crédito, el cajero comprueba normalmente si el cliente tiene disponible el crédito suficiente como para realizar la compra. Esta comprobación puede llevarse a cabo telefónicamente o realizarse automáticamente mediante un lector de tarjetas conectado a un sistema informático. En cualquiera de los dos casos, en algún sitio existe una base de datos que contiene información acerca de las compras que el cliente ha realizado con su tarjeta de crédito. Para comprobar el nivel de crédito existente, hay un programa de aplicación que utiliza el número de la tarjeta de crédito para comprobar el precio de los productos que se pretende adquirir, añadiéndolo al total de las compras que se hayan realizado este mes y luego comprobando si el nuevo total es inferior al límite de crédito predefinido. Una vez confirmada la compra, se añaden los detalles de la misma a esa base de datos. El programa de aplicación también accede a la base de datos para comprobar que la tarjeta de crédito no se encuentre incluida en la lista de tarjetas robadas o perdidas, antes de realizar la compra. Hay otros programas de aplicación que se encargan de enviar resúmenes mensuales a cada propietario de tarjeta de crédito y de cancelar las cuentas pendientes cuando se reciben los pagos.
Reserva de un programa de vacaciones en una agencia de viajes Cuando se pide información acerca de un programa de vacaciones, la agencia de viajes puede acceder a diversas bases de datos que contienen los detalles sobre dichos programas y sobre los vuelos existentes. Cuando se reserva un cierto programa, el sistema de base de datos tiene que realizar todas las reservas necesarias. En este caso, el sistema debe garantizar que no haya dos agentes distintos que reserven el mismo programa de vacaciones y asegurarse de que no se vendan más billetes de avión que los asientos disponibles en un vuelo. Por ejemplo, si sólo queda un asiento en un vuelo de Londres a Nueva York y dos agentes tratan de reservar ese último asiento al mismo tiempo, el sistema debe detectar dicha situación, permitiendo que una de las reservas se confirme e informando al otro agente de que ya no queda ningún asiento disponible. La agencia de viajes puede disponer también de otra base de datos, usualmente separada, para el tema de facturación.
Utilización de la biblioteca
local
Cualquier biblioteca local dispone, probablemente, de una base de datos que contiene los detalles de los libros disponibles en la biblioteca, la información sobre los lectores, sobre las reservas, etc. Existirá un índice informatizado que permita a los lectores encontrar un libro a partir de su título, de sus autores o de su tema. El sistema de bases de datos se encarga de gestionar las reservas para permitir que un lector reserve un libro y de informarle por prestado correo cuando esténodisponible. El sistema también envíaNormalmente, recordatorios el a las personas jlue tienen un libro cuandoéste éstas lo devuelven en la fecha prevista. sistema diSpondrá de un lector de códigos de barras similar al que se utiliza en los supe_rmercados, códigos de barras~ue se emplean para controlar los libros que entran y salen de la biblioteca.
Contratación
de un seguro
Cada vez que se quiere contratar un seguro, ya sea un seguro pers
Alquiler de un vídeo Cuando se desea alquilar una película en un videoclub, lo más probable es que la empresa propietaria del videoclub mantenga una base de datos compuesta por los títulos de las películas que tiene en almacén, por deta-
6
Sistemas de bases de datos
lles de las copias existentes de cada película y por información de si la copia está disponible para su alquiler o ya ha sido alquilada. La base de datos incluirá también detalles de los miembros del videoclub (las personas que alquilan las películas) y de los títulos que tienen prestados y la fecha en que deben devolverlos. La base de datos puede incluso almacenar información más detallada sobre cada película, como por ejemplo su director o sus actores y la empresa puede usar esta información para monitorizar el uso que se hace de los productos existentes en almacén y para predecir las tendencias futuras de alquiler basándose en los datos histórICos.
Utilización
de Internet
Muchos de los sitios de Internet funcionan utilizando aplicacioJ1es de bases de datos. Por ejemplo, podemos visitar una librería en línea que permita consultar y comprar libros, como por ejemplo Amazon.com. Dicha librería nos permiten consultar los libros disponibles en diferentes categorías, como por ejemplo informática o gestión empresarial, o los libros escritos por un determinado autor. En cualquier caso, existe una base de datos en el servidor web de la empresa que está compuesta por los detalles correspondientes a cada libro, por la información de disponibilidad, por la información de envíos, por los niveles de existencias y por la información de pedidos. Los detalles de los libros que se almacenan en la base de datos incluyen el título del libro, el ISBN, el autor, el precio, el historial de ventas, el editor, las reseñas y una descripción detallada. La base de datos permite establecer referencias cruzadas entre los libros. Por ejemplo, un libro puede aparecer en varias categorías distintas, como por ejemplo informática, lenguajes de programación, libros más vendidos y títulos recomendados. Las referencias cruzadas también permiten a Amazon proporcionar información sobre otros libros que se suelen pedir junto con el título en el que el cliente está interesado en ese momento. Al igual que sucedía en un ejemplo anterior, podemos proporcionar los detalles de nuestra tarjeta de crédito para comprar uno o más libros en línea. Amazon.com personaliza su servicio para los clientes que acuden de forma repetitiva a su sitio web, manteniendo un registro de todas las transacciones, incluyendo los elementos adquiridos y los detalles de envío y de la tarjeta de crédito. Cuando el cliente vuelve al sitio web, el sistema puede saludarle utilizando su nombre y presentarle una lista de títulos recomendados que está basada en las compras anteriores.
Estudio en una universidad Si el lector es estudiante en una universidad, existirá un sistema de bases de datos que contenga información personal sobre él, información sobre el curso en el que está matriculado, detalles sobre las posibles becas existentes, información sobre los cursos que se hayan seguido en años anteriores y detalles sobre los resultados de los exámenes. También puede haber una base de datos que contenga información sobre los estudiantes admitidos para el curso siguiente y otra con detalles sobre el personal que trabaja en la universidad, en la que se incluirán tanto información personal como información salarial, para la posterior elaboración de las nóminas.
1.2 Sistemas tradicionales basados en archivos Resulta casi una tradición que los libros de bases de datos introduzcan los sistemas de bases de datos mediante una revisión de sus predecesores, los sistemas basados en archivos. Nosotros vamos también a ajustamos a esta tradición porque, aunque los sistemas basados en archivos pueden considerarse obsoletos, siguen existiendo buenas razones para analizarlos: •
Si comprendemos los problemas inherentes a los sistemas basados en archivos, podemos evitar repetir esos problemas en los sistemas de bases de datos. En otras palabras, resulta conveniente que aprendamos de nuestros anteriores errores. En realidad, no resulta justo emplear la palabra' errores', ya que parece que estamos quitando valor a un trabajo que sirvió a un propósito útil durante muchos años. En realidad, es mucho lo que hemos aprendido de ese trabajo y gracias a él hemos visto que hay formas mejores de gestionar los datos .
•
Si se desea convertir un sistema basado en archivos en un sistema de bases de datos, resulta extremadamente útil, si no esencial, comprender cómo funcionan los sistemas basados en archivos.
Capítulo 1 Introducción a las bases de datos
1.2.1
7
La técnica basada en archivos
Sistema basado en archivos
Una colección de programas de aplicación que realiza diversos servicios para los usuarios finales, como por ejemplo la producción de informes. Cada programa define y gestiona sus propios datos.
Los sistemas basados en archivos fueron uno de los primeros intentos para informatizar los sistemas de archivo manual con los que todos nosotros estamos familiarizados. Por ejemplo, puede crearse un archivo manual en una organización para albergar toda la correspondencia externa e interna relativa a un proyecto; a un producto, a una tarea, a un cliente o a un empleado. Normalmente, existen muchos de dichos archivos, los cuales es preciso etiquetar y almacenar en una o más caja o contenedores por cuestiones de seguridad. Los lugares donde se almacenen esos archivos pueden disponer de llave, también por cuestiones de seguridad, o pueden estar ubicados en áreas seguras del edificio. En nuestra propia casa, probablemente dispongamos de algún tipo de sistema de archivo en el que depositamos los recibos, las facturas, la información bancaria, los contratos de seguros, etc. Si necesitamos consultar algo, vamos a nuestro archivo personal y buscamos en él, de principio a fin, hasta encontrar la información deseada. Alternativamente, puede que dispongamos de un sistema de indexación que nos ayude a localizar más rápidamente lo que queremos. Por ejemplo, puede que tengamos subdivisiones en el sistema de archivo o carpetas separadas para los diferentes elementos que están relacionadas de alguna manera lógica entre sí. Los sistemas de archivo manual funcionan bien cuando el número de elementos almacenados es pequeño. También puede funcionar de forma adecuada cuando hay un gran número de elementos y lo único que necesitamos es almacenados o extraerlos. Sin embargo, los sistemas manuales de archivo dejan de ser útiles cuando tenemos que establecer referencias cruzadas o procesar la información contenida en los documentos. Por ejemplo, una agencia inmobiliaria típica podría disponer de un archivo separado para cada inmueble que desee vender o alquilar, para cada potencial comprador o inquilino y para cada miembro de su personal. Piense en el enorme esfuerzo que se requeriría para responder a las siguientes cuestiones: •
¿Qué viviendas de tres dormitorios hay disponibles para la venta que tengan jardín y garaje?
•
¿Qué apartamentos existen para alquilar a menos de 5 km del centro de la ciudad?
•
¿Cuál es el precio medio de alquiler para un piso de dos dormitorios?
•
¿Cuál es el importe total de la nómina anual de todo el personal?
•
¿Cuál es la comparación entre los ingresos del último mes y los ingresos previstos para este?
•
¿Cuales son los ingresos mensuales previstos para el próximo año?
Hoy en día, los clientes, los gestores de las empresas y el personal de las mismas quieren cada vez más información. En algunas áreas, existe la obligación legal de generar informes mensuales, trimestrales y anuales detallados. Claramente, los sistemas manuales no resultan adecuados para este tipo de tarea. Los sistemas basados en archivos fueron desarrollados para dar respuesta a la necesidad que las empresas tenían de acceder de forma más eficiente a los datos. Sin embargo, en lugar de establecer un sistema centralizado de gestión de los datos operacionales de las organizaciones, lo que se hizo fue adoptar un enfoque descentralizado, en el que cada departamento, con la ayuda de personal especializado en procesamiento de datos, almacenaba y controlaba sus propios datos. Para comprender las implicaciones de esto, vamos a utilizar el ejemplo de DreamHome. El departamento de ventas (Sales) es responsable de la venta y alquiler de los inmuebles. Por ejemplo, cada vez que un cliente contacta con el departamento de ventas con la intención de vender o alquilar un inmueble, se rellena un formulario similar al que se muestra en la Figura 1.1(a). Esto proporciona diversos detalles sobre el inmueble, como la dirección del número de habitaciones, junto con la información personal acerca del propietario. El departamento de ventas también gestiona las consultas de los clientes interesados en comprar o alquilar un inmueble, rellenándose para cada uno un formulario similar al que se muestra en la Figura 1.1(b). Con la asistencia del departamento de procesos de datos, el departamento de ventas crea un sistema de información para gestionar el alquiler de los inmuebles. El sistema está compuesto por tres
~
~
."
o
Ul
."
g _.
o
1"
_. ;:l
Ul
-
cr"
(1)
¡::
Ul " Ul
...,
cr"
!!
...,
-.
CD
"'O
Ol
CD
CD
3
~
::J
CD
<
CD
o..
CD
(JJ
o.. W
CD
o..
o'
CD
3e ::J o
O'
~Ol
o-;:¡.
~
CD
=0..-
.o e
_:
(JJ
o
~o..
::J
Ol
(JJ
..,
_
..,
CD
CD
3e O o- 3 -e
-
(JJ
Ol :::!.
-
..,
_o e3
CD
(1l
cr"
;:l ....•
(1;'
o
-
Ul I
."
¡::
(1l
o.. _.
(1l Ul Ul (1l
~ 8 E.o
¡::
Ul (1l ¡:: " ("l ("l
~ Ul
." 2-
Ul
(JJ
(")
(JJ
ro
W
CD
CD
..., o o;:l ..., 15'0 ::J o.. ~~ Cii o..
.;'< (1l Ul
~ o'
w ¡:;. '9. _. (1l Cifm < ....• (JJ~ o ." Ul ..., o.. o
(1l
-o
...,"0
(D(1l Ul -
E.(1l
(1l ....•
0..0
o Ul
_(1l
...,
_.
::i-'
8o 8
Ul ."
8o o~
8<0-
Ul
?)~ro 8 ." r;;'~ b
_
S"
("l
(1l
~
(1)
_
0.."0
'"""'t
"O '"""'t. -
---
"
--- \
(a)
(b)
Carol Farrel St, DreamHome C087 B003 163 Main St, Glasqow Casa Mike Ann Beech Ritchie 0141-357-7419 6 Achray Actualmenie vive con GI suss padres DreamHome 01475-392178 lO sucursal: responsable Asignado AnnaBeech N°Te!. Fecha Apellido 24-Mar-04 N° Tel. \ '1Empleado 600 Al N° Dirección qUler---propietario c: Nombre empresa o N (1l contacto Se cas~ en agosto \cliente .., Detalles G32 9DX Número del cliente: CR74 del inmueble "O Glasgow . ;:l Detalles del del N° sucursal Comentarios generales Ciudad sucursal Nombre de inmueble PG21 "'O III Número a~gow PA1G lYQpor habitaciones _5_ Tipo de empresa Atendido Dirección _. "'ti (1l N° propietario Glasgow Ol •.•.•• $P.. O ;:l Dirección 18 Tain St, N0 sucursal B003 N°Te!. .., . p:¡ Nombre Ol •...•• Detalles sobre el\lnmueble buscado Nombredel propietario Detalles 18 Dale Rd S' §. ~. ~ Dirección Tipo preferido inmueble Casa Alquiler mensual máximo 750 Ul 8 o.. TI
Ul
("l
¡::
(1l
_.
(Jq
O" Ei
."
'< >-rj.c
Ul ."
"g g g: (1l <
8 ." 8
(1)
3
III
O
..•.
al
Q.
ID
Q.
III
ID
C" al III
ID
Q.
al III
ID
..•.
¡¡j'
rn
00
Capítulo 1 Introducción a las bases de datos
9
PropertyForRent 4rent 50 75G129AX C093 563C040 C087 00 Flat 2street 6616 ManorRd Lawrence Dale Rd C046 House 518 Novar Dr St G12 NW2 London AB75SU Aberdeen Holhead ownerNo rooms propertyNo G324QX G1l9QX Glasgow Argyll St postcode city type
PrivateOwner ownerNo
Tina ShawSt, Carol Farrel 0141-357-7419 fName IName telNo 0141-225-7025 0141-943-1728 Joe 01224-861212 address 6263 Fergus Keogh Dr, St,Glasgow Glasgow AberdeenG42 G32 AB2 9DX 7SX 12Achray Well Park Tony Murphy PI, G4 OQR
Client clientNo
House Flat 425Aline 350Mike 750 Ritchie Stewart 01475-392178 0207-774-5632 0141-848-1825 600 address maxRent fName IName telNo 01224-196720 518 Tarbot John Rd,PA1G Aberdeen AB9 3ST 56 64 High Fern Tain Mary Kay Tregear St, Dr, St, London Glasgow 1YQ SWl G42 4EH OBL prefType
Archivos PropertyForRent, PrivateOwner y Client utilizados por el departamento de ventas.
Figura 1.2.
El departamento de contratos (Contracts) es responsable de gestionar los contratos de alquiler relativos a los distintos inmuebles. Cuando un cliente accede a alquilar un inmueble, un miembro del departamento de ventas rellena un formulario en el que se indican los detalles relativos al cliente y al inmueble, como se muestra en la Figura 1.3. Este formulario es enviado al departamento de contratos, que le asigna un número de referencia y termina de rellenar los detalles relativos al pago y al periodo de alquiler. De nuevo, con la ayuda del departamento de proceso de datos, el departamento de contratos crea un sistema de información para gestionar estos contratos de alquiler. El sistema está compuesto por tres archivos donde se almacenan los detalles relativos al contrato de alquiler, al inmueble y al cliente y donde se introducen datos similares a los que ya posee el departamento de ventas, como se ilustra en la Figura 1.4. La situación completa se ilustra en la Figura 1.5. En ella podemos ver que cada departamento accede a sus propios archivos utilizando programas de aplicación escritos especialmente para ellos. Cada conjunto de programas de aplicación departamentales se encarga de gestionar la introducción de datos, el mantenimiento de los archivos y la generación de un conjunto fijo de informes específicos. Además, lo cual tiene mayor importancia, la estructura fisica y el almacenamiento de los archivos y registros de datos están definidos por el código de aplicación. Podemos encontrar ejemplos similares en otros departamentos. Por ejemplo, el departamento de nóminas (Payroll) almacena información relativa al salario de cada miembro del personal, es decir: StaffSalary(StaffNo,
fName, IName, sex, salary, branchNo)
El departamento de personal (Personnel) también almacena información sobre los miembros del personal, es decir: Staff(staffNo, fName, IName, position, sex, dateOfbirth,
salary, branchNo)
10
Sistemas de bases de datos
Glasgow G12 DreamHome CR74 Mike N° Ritchie inmueble Duración 1 añoinicio alquiler Dirección Fecha fin alquiler DalePG21 Rd, 30-Jun-05 18 Tain St,18 Fecha Cheque 1200 Pagado (5 o 10012 N~
l-Jul-04
Detallesdedel alquiler Número alquiler:
Fianza Dirección(previa) Nombre completo PAIG Forma de pago lYQN° Te\. 01475-392178 Renta mensual 600 e cliente Información de pago
Figura 1.3.
Formulario de alquiler utilizado por el departamento
de contratos.
Lease leaseNo 6C 600 1200 Y NY PL94 400 R76 12 rent Visa PAI4 650 1300 R62 PG21 CR74 Cash 800 rentStart rentFinish duration c1ientNo 31-Jan-05 I-Jun-05 l-]ul-05 30-Jun-05 payment Cheque I-Aug-05 31-May-05 paid propertyNo deposit
PropertyForRent AB75SU 650 400 600 rent Aberdeen street Halhead NW2 Landan 8Argyll Dale Rd propertyNo GI2 postcode city 6116 St Glasgow
Client clientNo Ritchie 01224-196720 address fName Mike 01475-392178 0171-774-5632 telNo John 5IName Mary Rd, Aberdeen AB9 3ST 18Tarbot Tain St, PAIG lYQ 56 Kay High St, London SWI 4EH Tregear
Figura 1.4.
Archivos Lease, PropertyForRent
y Client utilizados por el departamento
de contratos.
Podemos ver claramente que existe una gran cantidad de duplicación de datos en estos departamentos, de este
y esto siempre suele ser así en los sistemas basados en archivos. Antes de analizar las limitaciones
Capítulo 1 Introducción a las bases de datos
Introducción de datos e informes
Rutinas de de datos de Definición
archivos tratamiento
11
·0 ·0
Ventas
Archivos de ventas Programas de aplicación de ventas
datos Introducción e informes de
Kutinas de datosdede Definición
tratamiento archivos
Archivos de contratos
Contratos Programas de aplicación de contratos Archivos de ventas PropertyForRent PrivateOwner
(propertyNo,
street, city, postcode, type, rooms, rent, ownerNo)
(ownerNo, fName, IName, address, telNo)
Client (c1ientNo, fName, IName, address, telNo, prefrype,
maxRent)
Archivos de contratos Lease (leaseNo, propertyNo, PropertyForRent
(propertyNo,
clientNo, rent, paymentMethod,
deposit, paid, rentStart, rentFinish, duration)
street, city, postcode, rent)
Client (c1ientNo, fName, IName, address, telNo)
Figura 1.5.
Procesamiento
basado en archivos.
enfoque, puede resultar útil comprender la terminología utilizada en los sistemas basados en archivos. Un archivo es simplemente una colección de registros, que contienen datos lógicamente relacionados. Por ejemplo, el archivo PropertyForRent de la Figura 1.2 contiene seis registros, uno para cada inmueble. Cada registro contiene un conjunto lógicamente relacionado de uno o más campos, donde cada campo representa alguna característica del objeto del mundo real que se quiere modelar. En la Figura 1.2 los campos del archivo PropertyForRent representan características de los inmuebles, como su dirección, tipo de inmueble y número de habitaciones.
1.2.2
Limitaciones de la técnica basada en archivos
Esta breve descripción de los sistemas tradicionales basados en archivo debería ser suficiente para explicar las limitaciones de este enfoque. En la Tabla 1.1 se enumeran cinco problemas diferentes. Tabla 1.1.
Limitaciones de los sistemas basados en archivos.
Separación y aislamiento de los datos Duplicación de los datos Dependencias
entre los datos
Formatos de archivos incompatibles Consultas fijas/proliferación
de programas de aplicación
Separación y aislamiento de los datos Cuando se aíslan los datos en archivos separados, resulta más difícil acceder a los datos que deben estar disponibles. Por ejemplo, si queremos generar una lista de todos los chalets que satisfacen los requisitos de los clientes, necesitamos primero crear un archivo temporal de aquellos clientes cuyo tipo preferido de inmueble sea 'chalet'. A continuación hay que explorar el archivo PropertyForRent para localizar aquellos inmuebles cuyo tipo sea 'chalet' y cuyo alquiler sea inferior al alquiler máximo fijado por el cliente. Con los sistemas de archi-
12
Sistemas de bases de datos
vos, este tipo de procesamiento resulta difícil. El desarrollador de aplicaciones debe sincronizar el procesamiento de los dos archivos para garantizar que se extraigan los datos correctos. Esta dificultad se hace todavía mayor si se necesita extraer datos de más de dos archivos.
Duplicación
de los datos
Debido al enfoque descentralizado adoptado por los departamentos, la técnica basada en archivos, promueve, si es que no requiere, una duplicación incontrolada de los datos. Por ejemplo, en la Figura 1.5 podemos ver claramente que existe una duplicación de la información tanto de los inmuebles como de los clientes en los departamentos de ventas y de contratos. La duplicación descontrolada de los datos resulta indeseable por varias razones, como por ejemplo: •
La duplicación implica un desperdicio de recursos. Cuesta tiempo y dinero introducir los datos más de una vez.
•
Se consume un espacio de almacenamiento innecesario, lo que también tiene su coste asociado. A menudo, puede evitarse la duplicación de los datos compartiendo los archivos de datos.
•
Lo más importante quizá sea que la duplicación puede conducir a que se pierda la integridad de los datos. En otras palabras, los datos podrían dejar de ser coherentes. Por ejemplo, considere el caso de la duplicación de datos en los departamentos de personal y de nóminas, como hemos descrito anteriormente. Si un empleado cambia de domicilio y ese cambio de dirección sólo se comunica al departamento de personal y no al de nóminas, la nómina de ese empleado podría ser enviada a la dirección incorrecta. Otro problema más grave sucede cuando se asciende a un empleado, incrementándole a su vez el sueldo. De nuevo, si el cambio se notifica al departamento de personal pero no llega al de nóminas, el empleado recibirá una paga incorrecta. Cuando este error se detecte, se necesitará tiempo y esfuerzo para resolverlo. Estos dos ejemplos ilustran el tipo de incoherencia que puede surgir como resultado de la duplicación de los datos. Puesto que los miembros del departamento de personal no disponen de ningún sistema automático para actualizar los datos contenidos en los archivos del departamento de nóminas, no resulta difícil prever que dichas incoherencias terminarán por surgir. Incluso aunque se notifiquen los cambios al departamento de nóminas, es posible que éstos se introduzcan de forma incorrecta.
Dependencias entre los datos Como ya hemos mencionado, la estructura física y el almacenamiento de los archivos y registros de datos están definidos en el código de la aplicación. Esto significa que resulta difícil realizar cambios a una estructura existente. Por ejemplo, si se incrementa el tamaño del campo PropertyForRent address de 40 a 41 caracteres, parece que dicho cambio debería poder incrementarse de forma simple, pero se requiere la creación de un programa de un solo uso (es decir, un programa que sólo se ejecute una vez y luego pueda descartarse) que convierta el archivo PropertyForRent al nuevo formato. Este programa tiene que: •
abrir el archivo PropertyForRent original para lectura;
•
abrir un archivo temporal con la nueva estructura;
•
leer un registro del archivo original, convertir los datos para adecuarlos a la nueva estructura y escribirlo en el archivo temporal, repitiendo este paso para todos los registros del archivo original;
•
borrar el archivo PropertyForRent original;
•
renombrar el archivo temporal, denominándolo PropertyForRent.
Además, todos los programas que accedan al archivo PropertyForRent deberán ser modificados para adecuarlos a la nueva estructura del archivo. Puede que existan muchos de tales programas accediendo al archivo PropertyForRent. Por tanto, el programador necesitará identificar todos los programas afectados, modificarlos y luego volverlos a probar. Observe que los programas ni siquiera tienen que utilizar el campo address para verse afectados: basta con que utilicen el archivo PropertyForRent. Obviamente, todo esto puede requerir un tiempo considerable y se trata de un proceso sujeto a errores. Esta característica de los sistemas basados en archivos se denomina dependencia entre los programas y los datos.
Capítulo 1 Introducción a las bases de datos
13
Formatos de archivo incompatibles Puesto que la estructura de los archivos está incrustada en los programas de aplicación, dichas estructuras dependen delleguaje de programación de aplicaciones que se utilice. Por ejemplo, la estructura de un archivo generador por un programa COBOL puede ser diferente de la estructura de un archivo creada por un programa C. La incompatibilidad directa de dichos archivos hace difícil que se los pueda procesar conjuntamente. Por ejemplo, suponga que el departamento de contratos quiere averiguar los nombres y direcciones de todos los propietarios cuyos inmuebles estén actualmente alquilados. Desafortunadamente, el departamento de contratos no dispone de la información de detalles sobre los propietarios de los inmuebles, ya que sólo el departamento de ventas tiene esa información. Sin embargo, el departamento de contratos sí que dispone del número de inmueble (propertyNo), que puede utilizarse para localizar el número de inmueble correspondiente en el archivo PropertyForRent del departamento de ventas. Este archivo contiene el número de propietario (ownerNo), que puede utilizarse para localizar los detalles del propietario en el archivo PrivateOwner. Los programas del departamento de contratos han sido desarrollados en Cabal, mientras que los del departamento de ventas han sido desarrollados en C. Por tanto, para establecer la correspondencia entre los campos propertyNo de los dos archivos PropertyForRent se necesita que un desarrollador de aplicaciones escriba un programa software que convierta los archivos a un formato común para facilitar el procesamiento. De nuevo, este proceso puede requerir mucho tiempo y resultar muy caro.
Consultas fijas/proliferación
de programas de aplicación
Desde el punto de vista del usuario final, los sistemas basados en archivos representaron una enorme mejora con respecto a los sistemas manuales. En consecuencia, las peticiones de nuevas consultas o de modificaciones de las ya existentes comenzaron a crecer. Sin embargo, los sistemas basados en archivos son muy dependientes del desarrollador de aplicaciones, que es quien tiene que escribir todas las consultas e informes requeridos. Como resultado, sucedieron dos cosas, en algunas organizaciones, el tipo de consulta o de informe que podía producirse era fijo. No existía ninguna posibilidad de solicitar consultas no planificadas (es decir, consultas pensadas en el momento o ad hoc) ni acerca de los propios datos ni acerca de los datos disponibles. En otras organizaciones, se produjo una proliferación de archivos y de programas de aplicación. Al final, se alcanzó un punto en el que el departamento de proceso de datos, con sus recursos existentes, era incapaz de gestionar todo el trabajo. Esto normalmente llevaba a que se presionara en exceso al personal del departamento de proceso de datos, lo que daba como resultado programas inadecuados o ineficientes a la hora de satisfacer las demandas de los usuarios, o bien sistemas de documentación excesivamente limitados o bien programas cuyo mantenimiento era muy complicado. A menudo, se tendía a omitir diversos tipos de funcionalidad: •
no se incluían mecanismos de seguridad o integridad;
•
la recuperación, para los casos de fallos de hardware o software, era limitada o inexistente;
•
el acceso a los archivos estaba restringido, de modo que sólo un usuario podía acceder en cada instante: no había ningún tipo de mecanismo para facilitar el acceso compartido por parte de distintas personas pertenecientes al mismo departamento.
En cualquier caso, lo que está claro es que ese tipo de situación no era aceptable. Se necesitaba algún otro tipo de solución.
1.3 Sistemas de bases de datos Todas estas limitaciones de los sistemas basados en archivos pueden atribuirse a dos factores distintos: (1) la definición de los datos está incluida en los programas de aplicación, en lugar de almacenarse de forma separada e independiente; (2) no existe ningún control sobre el acceso y manipulación propios programas de aplicación.
de los datos, más allá del que imponen los
14
Sistemas de bases de datos
Para poder ser más efectivos, se necesitaba una nueva técnica y lo que surgió fue el concepto de base de datos y los Sistemas de Gestión de Bases de Datos (SGBD). En esta sección, vamos a proporcionar una definición más formal de estos términos y a examinar los componentes que podemos esperar encontramos en un entorno SGBD.
1.3.1
La base de datos
Base de datos
Una colección compartida de datos lógicamente relacionados, junto con una descripción de estos datos, que están diseñados para satisfacer las necesidades de información de una organización.
Examinemos ahora la definición de base de datos para tratar de entender el concepto adecuadamente. Una base de datos es un repositorio centralizado, posiblemente de gran tamaño, compuesto por datos que pueden ser utilizados simultáneamente por múltiples departamentos y usuarios. En lugar de disponer de una serie de archivos desconectados con datos redundantes, todos los elementos de datos están integrados, manteniéndose al mínimo las posibles duplicaciones. La base de datos deja de ser propiedad de un departamento y pasa a ser un recurso corporativo compartido. La base de datos almacena no sólo los datos operacionales de la organización, sino también una descripción de dichos datos. Por esta razón, a veces se suele describir a las bases de datos como una colección autodescriptiva de registros integrados. La descripción de los datos se conoce con el nombre de catálogo del sistema (o diccionario de datos o metadatos, es decir, 'datos acerca de los datos'). Es esta naturaleza autodescriptiva de la bases de datos la que proporciona la independencia entre programas y datos. El enfoque adoptado por los sistemas de bases de datos, en el que la definición de los datos está separada de los programas de aplicación, es similar a la técnica utilizada en el desarrollo moderno de software, donde se proporciona tanto una definición interna de un objeto como una definición externa independiente de la anterior. Los usuarios de un objeto sólo ven la definición externa y no son conscientes del modo en que el objeto está definido ni de su manera de funcionar. Una de las ventajas de esta técnica, denominada abstracción de datos, es que podemos modificar la definición interna de un objeto sin afeptar a los usuarios de dicho objeto, siempre y cuando la definición externa continúe siendo la misma. De la misma forma, los sistemas de bases de datos separan la estructura de los datos de los programas de aplicación y almacenan dicha estructura en la propia base de datos. Si se añaden nuevas estructuras de datos o se modifican las existentes, los programas de aplicación no se verán afectados, siempre y cuando no dependan directamente de la información que haya sido modificada. Por ejemplo, si añadimos un nuevo campo a un registro o creamos un nuevo archivo, las aplicaciones existentes no se verán afectadas. Sin embargo, si eliminamos de un archivo un campo utilizado por un programa de aplicación, entonces dicho programa de aplicación sí se verá afectado por el cambio y deberá ser modificado correspondientemente. El último término en la definición de base de datos que debemos explicar es el 'lógicamente relacionado'. Al analizar las necesidades de información de una organización, tratamos de identificar entidades, atributos y relaciones. Una entidad es un objeto distintivo (una persona, lugar, cosa, concepto o suceso) dentro de la organización y que hay que representar en la base de datos. Un atributo es una propiedad que describe algún aspecto del objeto que queremos almacenar y una relación es una asociación entre entidades. Por ejemplo, la Figura 1.6 muestra un diagrama Entidad-Relación (ER) para una parte del caso de estudio de DreamHome. Está compuesto por: •
seis entidades (los rectángulos): Branch (sucursal), 8taff (personal), ler) Client (cliente) PrivateOwner (propietario) y Lease (alquiler);
•
siete relaciones (los nombres adyacentes a las líneas): Has (tiene), Offers (ofrece), Views (vista), Owns (posee), LeasedBy (alquilado por) y Holds (alquila);
•
PropertyForRent
(inmueble en alquiOversees
(gestiona),
seis atributos, uno para cada entidad: branchNo (número de sucursal), staffNo (número de empleado), de inmueble), c1ientNo (número de cliente), ownerNo (número de propietario) y contrato de alquiler).
propertyNo (número leaseNo (número de
Capítulo 1 Introducción a las bases de datos
BranchstaffNo Lease1..1 Staff ..* Client clientNo 00..* 0 ..*1..~ Views PropertyForRentHas ~ 0..100
1..-
Figura 1.6.
T 0T..1 1..1 Oversees 1..1 T LeasedBy
Holds 0 ..*
15
leaseNo
Ejemplo del diagrama de entidad-relación.
La base de datos representa las entidades, los atributos y las relaciones lógicas entre entidades. En otras palabras, la base de datos almacena un conjunto de datos que están lógicamente relacionados. Hablaremos en detalle del modelo entidad-relación en los Capítulos 11 y 12.
1.3.2 SGBD
Sistema de gestión de base de datos (SGBO) Un sistema software que permite a los usuarios definir, crear, mantener y controlar el acceso a la base de datos.
El SGBD es el software que interactúa con los programas de aplicación del usuario y con la base de datos. Normalmente, un SGBD proporciona la siguiente funcionalidad: •
Permite a los usuarios definir la base de datos, usualmente mediante un lenguaje de definición de datos (DDL, Data Definition Language). El DDL permite a los usuarios especificar las estructuras y tipos de datos y las restricciones aplicables a los datos que hay que almacenar en la base de datos.
•
Permite a los usuarios insertar, actualizar, borrar y extraer datos de la base de datos, usualmente mediante un lenguaje de manipulación de datos (DML, Data Manipulation Language). Al disponer de un repositorio centralizado para todos los datos y las descripciones de los datos, el lenguaje DML puede proporcionar un mecanismo general de consulta de esos datos, denominado lenguaje de consulta. La existencia de un lenguaje de consulta resuelve el problema de los sistemas basados en archivos en los que el usuario tenía que trabajar con un conjunto fijo de consultas, o bien en los que existía una proliferación de programas que provocaban graves problemas de gestión del software. El lenguaje de consulta más común es el lenguaje SQL (Structured Query Language, lenguaje estructurado dé consulta), que es ahora tanto el estándar formal como el estándar defacto para los SGBD relacionales. Para recalcar la importancia del SQL, hemos dedicado los Capítulos 5 y 6, la mayor parte del Capítulo 28 y el Apéndice E a un estudio en profundidad de este lenguaje.
•
Proporciona un acceso controlado a la base de datos. Por ejemplo, puede proporcionar: • • • •
un sistema de seguridad, que evita que los usuarios no autorizados accedan a la base de datos; un sistema de integridad, que mantiene la coherencia de los datos almacenados; un sistema de control de concurrencia que permite el acceso compartido a la base de datos; un sistema de control de recuperación, que restaura la base de datos a un estado previo coherente después de cada fallo hardware o software;
16
Sistemas de bases de datos
•
un catálogo accesible por el usuario, que contiene descripciones de los datos que están almacenados en la base de datos.
1.3.3 Programa de aplicación Programa aplicación
de
Un programa informático que interactúa con la base de datos emitiendo las apropiadas solicitudes (normalmente una instrucción SQL) dirigidas al SGBD.
Los usuarios interactúan con la base de datos mediante una serie de programas de aplicación que se utilizan para crear y mantener la base de datos y para generar información. Estos programas pueden ser programas de procesamiento por lotes convencionales o, lo que resulta más habitual hoy en día, aplicaciones en línea. Los programas de aplicación pueden estar escritos en algún leguaje de programación o en un lenguaje de cuarta generación de mayor nivel. La Figura 1.7 ilustra la técnica de bases de datos, utilizando los archivos indicados en la Figura 1.5. La figura muestra cómo los departamentos de ventas y de contratos utilizan sus programas de aplicación para acceder a la base de datos a través del SGBD. Cada conjunto de programas de aplicación departamentales gestiona la introducción de datos, el mantenimiento de los mismos y la generación de informes. Sin embargo, si lo comparamos con la técnica basada en archivos, la estructura fisica y el almacenamiento de los datos ahora son responsabilidad del SGBD.
Vistas Con esta funcionalidad, el SGBD es una herramienta extremadamente potente y útil. Sin embargo, como a los usuarios finales no les interesa demasiado si una determinada tarea resulta sencilla o compleja para el sistema, podría argumentarse que los SGBD han hecho que las cosas se compliquen, ya que ahora los usuarios ven más datos de los que quieren 9 necesitan. Por ejemplo, los detalles que el departamento de contratos quiere ver en lo que respecta a un inmueble en alquiler, como se indica en la Figura 1.5, han cambiado en la técnica que utiliza una base de datos, como se muestra en la Figura 1.7. Ahora la base de datos también almacena el tipo de inmueble, el número de habitaciones y los detalles referidos al propietario. Para hacer frente a este problema, un SGBD proporciona otra funcionalidad denominada mecanismo de vistas que permite que cada usuario disponga de su propia vista de la base de datos (una vista es, en esencia, un cierto subconjunto de la base de datos). Por ejemplo, podríamos definir una lista que permita que el departamento de contratos sólo vea los datos que les interesan referidos a los inmuebles en alquiler. Sistema de base de datos
Detalles y definiciones de los archivos PropertyForRent. PrivateOwner, Client, y Lease
Introducción de datos e informes Ventas SGBD
Introducción de datos e informes Contratos
PropertyForRent PrivateOwner
o
Base de datos
Programas de aplicación para contratos
(propertyNo,
street, city, postcode, type, rooms, rent, ownerNo)
(ownerNo, fName, IName, address, telNo)
Client (clientNo, fName, IName, address, telNo, prefType, maxRent) Lease (leaseNo, propertyNo,
clientNo, paymentMethod,
Figura 1.7.
Procesamiento
deposit, paid, rentStart, rentFinish)
con bases de datos.
Capítulo 1 Introducción a las bases de datos
17
Además de reducir la complejidad al permitir que los usuarios vean los datos en la forma que desean verlos, las vistas tienen otras diversas ventajas: •
Las vistas proporcionan un cierto nivel de seguridad. Pueden configurarse las vistas para excluir aquellos datos que algunos usuarios no deban ver. Por ejemplo, podemos crear una lista que permita que los gerentes de sucursal y el departamento de nóminas vean todos los datos referidos al personal, incluyendo los detalles salariales, y una segunda vista que utilizaría el resto del personal y de la que se excluirían esos detalles salariales.
•
Las vistas proporcionan un mecanismo para personalizar la apariencia de la base de datos. Por ejemplo, el departamento de contratos podría denominar al campo de alquiler mensual (rent) utilizando un nombre más conveniente, como por ejemplo MonthlyRent.
•
Una vista puede presentar una imagen coherente y estática de la estructura de la base de datos, aún cuando se modifique la base de datos subyacente (por ejemplo, podrían añadirse o eliminarse campos, podrían modificarse relaciones o podrían partirse, reestructurarse o renombrarse los archivos). Si se añaden o eliminan campos de un archivo y estos campos no son requeridos por la vista, ésta no se verá afectada por la modificación. Por tanto, las vistas ayudan a conseguir la independencia entre programas y datos de la que hemos hablado en la sección precedente.
La explicación anterior es de carácter general y el nivel real de funcionalidad ofrecido por un SGBD difiere entre unos productos y otros. Por ejemplo, un SGBD para una computadora personal puede no permitir el acceso compartido concurrente y proporcionar sólo mecanismos limitados de seguridad, integridad y control de recuperación. Sin embargo, los productos SGBD multiusuario modernos y de gran complejidad ofrecen todas las funciones anteriores y mucha otras. Los sistemas modernos son programas software extremadamente complejos compuestos por millones de líneas de código y para los que la documentación está formada por múltiples volúmenes. Esto se debe a la necesidad de proporcionar un programa software que gestione requisitos de naturaleza muy general. Además, la utilización de un SGBD hoy en día suele requerir un sistema que proporcione una fiabilidad prácticamente total y una disponibilidad 24/7 (24 horas al día, 7 días a la semana) incluso en el caso de fallos de hardware o software. Los SGBD están continuamente evolucionándose y expandiéndose para adaptarse a las nuevas necesidades de los usuarios. Por ejemplo, algunas aplicaciones requieren ahora el almacenamiento de imágenes gráficas, vídeo, sonido y otros tipos de información similar. Para poder satisfacer las necesidades de este mercado, es necesario cambiar los SGBD. Resulta previsible que cada vez se vayan recibiendo nuevas funcionalidades, por lo que las funciones de un SGBD nunca serán estáticas. Hablaremos de las funciones básicas proporcionadas por un SGBD en los capítulos posteriores.
1.3.4
Componentes de un entorno SGBD
Podemos identificar cinco componentes principales dentro del entorno SGBD: bardware, software, datos, procedimientos y personas, como se ilustra en la Figura 1.8.
Hardware El SGBD y las aplicaciones requieren una plataforma hardware sobre la que ejecutarse. El hardware puede ir desde una única computadora personal hasta un único mainframe o una red de computadoras. El hardware concreto dependerá de las necesidad de la organización y del SGBD utilizado. Algunos SGBD sólo se ejecutan sobre una plataforma hardware concreta o sobre un sistema operativo particular, mientras que otros se ejecutan sobre un rango más amplio de plataformas bardware y sistemas operativos. Todo SGBD requiere una cantidad mínima de memoria principal de espacio de disco para poder ejecutarse, pero esta configuración
I
I Puente Máquina
Operador
Figura 1.8. Entorno SGBD.
18
Sistemas de bases de datos
Clientes
Oficina de Londres
Oficina Oeste
Servidor de base de datos
Clientes
Clientes Base de datos
Clientes
Figura 1.9.
Configuración
hardware para DreamHome.
mínima puede no necesariamente proporcionar un rendimiento aceptable. En la Figura 1.9 se ilustra una configuración hardware simplificada para DreamHome. Está compuesta de una red de minicomputadoras, con una computadora central ubicada en Londres y en la que se ejecuta el sistema de servicio (backend) del SGBD, es decir, la parte del SGBD que gestiona y controla el acceso a la base de datos. También se muestran varias computadoras en distintas ubicaciones en las que se ejecuta el sistema de interfaz (frontend) del SGBD, es decir, la parte del SGBD que implementa la interfaz con el usuario. Este tipo de arquitectura se denomina cliente-servidor: el backend es el servidor y el frontend es el cliente. Hablaremos de este tipo de arquitectura en la Sección 2.6.
Software El componente software comprende el propio software SGBD y los programas de aplicación, junto con el sistema operativo, que incluye el software de red si el SGBD se está utilizando en una red. Normalmente, los programas de aplicación se escriben en un lenguaje de aplicación de tercera generación (3GL), como C, C++, Java, Visual Basic, COBOL, Fortran, Ada o Pascal, o utilizando un lenguaje de cuarta generación (4GL) como SQL, incrustado dentro de un lenguaje de tercera generación. El SGBD objetivo puede disponer de sus propias herramientas de cuarta generación que permitan el desarrollo rápido de aplicaciones gracias a la existencia de lenguajes de consulta no procedimentales, generadores de informes, generadores de formularios, generadores gráficos y generadores de aplicaciones. La utilización de herramientas de cuarta generación puede mejorar de forma significativa la productividad y dar como resultado programas que son más fáciles de mantener. Hablaremos de las herramientas de cuarta generación en la Sección 2.2.3.
Capítulo 1 Introducción a las bases de datos
19
Datos Quizá el componente más importante de un entorno SGBD, al menos desde el punto de vista de los usuarios finales sean los datos. En la Figura 1.8 podemos observar que los datos actúan como una especie de puente entre los componentes ligados a la máquina y los componentes ligados al operador humano. La base de datos contiene tanto los datos operacionales como los metadatos, es decir, los' datos acerca de los datos'. La estructura de la base de datos se denomina esquema. En la Figura 1.7, el esquema está compuesto por cuatro archivos o tablas, que son: PropertyForRent, PrivateOwner, Client y Lease. La tabla PropertyForRent tiene ocho campos o atributos, a saber: propertyNo,street, city, postcode, type (el tipo de inmueble), rooms (el número de habitaciones), rent (el alquiler mensual) y ownerNo. El atributo ownerNo modela la relación entre PropertyForRent y PrivateOwner:es decir, el propietario posee (Owns) un inmueble para alquiler, como se muestra en el diagrama entidad-relación de la Figura 1.6. Por ejemplo, en la Figura 1.2 podemos observar que el propietario C046, loe Keogh, posee el inmueble PA14. Los datos incorporan también el catálogo del sistema, del que hablaremos en detalle en la Sección 204.
Procedimientos Los procedimientos son las instrucciones y reglas que gobiernan el diseño y utilización de la base de datos. Los usuarios del sistema y el personal que gestiona la base de datos requieren una serie de procedimientos documentados que les permitan saber cómo utilizar o ejecutar el sistema. Estos procedimientos pueden estar compuestos de instrucciones que les digan cómo: •
iniciar una sesión en el SGBD;
• •
utilizar una funcionalidad concreta del SGBD o un programa de aplicación; iniciar y detener el SGBD;
•
realizar copias de seguridad de la base de datos;
•
gestionar los fallos de hardware o de software. Esto puede incluir procedimientos para identificar el componente fallido, para reparar el componente fallido (por ejemplo, telefonear al ingeniero de hardware apropiado) y, después de la reparación del fallo, para recuperar la base de datos;
•
cambiar la estructura de una tabla, reorganizar la base de datos entre múltiples discos, mejorar el rendimiento o archivar los datos en un almacenamiento secundario.
Personas El componente final son las personas que se relacionan con el sistema. Hablaremos de este componente fundamental en la Sección lA.
1.3.5
Diseño de bases de datos: un cambio en el paradigma
Hasta ahora, hemos dado por supuesto que los datos de la base de datos tenían una estructura. Por ejemplo, en la Figura 1.7 hemos identificado cuatro tablas: PropertyForRent, PrivateOwner, Client y Lease. Pero, ¿cómo obtenemos esta estructura? La respuesta es muy simple: la estructura de la base de datos se determina durante el diseño de la base de datos. Sin embargo, realizar el diseño de una base de datos puede ser extremadamente complejo. Para producir un sistema que satisfaga las necesidades de información de una organización, se necesita un enfoque distinto del utilizado en los sistemas basados en archivo, donde el trabajo estaba dirigido por las necesidades de los departamentos individuales en términos de aplicaciones. Para que el enfoque de base de datos tenga éxito, la organización debe ahora pensar primero en los datos y luego en las aplicaciones. Este cambio en el enfoque se denomina en ocasiones cambio de paradigma. Para que el sistema sea aceptable para los usuarios finales, resulta crucialla actividad de diseño de la base de datos. Una base de datos inadecuadamente diseñada generará errores que pueden conducir a que se tomen decisiones incorrectas, lo cual podría tener repercusiones serias para la organización. Por otro lado, una base de datos bien diseñada produce un sistema que proporciona la información correcta para que el proceso de toma de decisiones tenga éxito y funcione de una manera eficiente. El objetivo de este libro es ayudar a llevar a cabo este cambio de
20
Sistemas de bases de datos
paradigma. Dedicaremos diversos capítulos a la presentación de una metodología completa de diseños de bases de datos (véanse los Capítulos 15-18). Dicha metodología se presenta como una serie de pasos fáciles de seguir, proporcionándose directrices a todo lo largo del texto. Por ejemplo, en el diagrama entidad-relación de la Figura 1.6, hemos identificado seis entidades, siete relaciones y seis atributos. Proporcionaremos directrices para ayudar a identificar las entidades, los atributos y relaciones que deben ser representados en la base de datos. Desafortunadamente, las metodologías de diseño de bases de datos no son muy populares. Muchas organizaciones y diseñadores individuales utilizan bastante poco las metodologías para realizar el diseño de bases de datos, lo cual se considera comúnmente como una de las principales causas de fallo en el desarrollo de sistemas de bases de datos. Debido a la falta de enfoques estructurados del diseño de bases de datos, suelen subestimarse el tiempo y los recursos necesarios para un proyecto de base de datos y las bases de datos desarrolladas resultan inadecuadas o poco eficientes a la hora de satisfacer las demandas de las aplicaciones, o bien la documentación es limitada o puede que el mantenimiento resulte muy difícil.
1.4 Papeles en un entorno de base de datos En esta sección, vamos a examinar el quinto de los componentes básicos de un entorno SGBD que mencionamos en la sección anterior: las personas. Podemos identificar cuatro tipos distintos de personas que pueden participar en un entorno SGBD: administradores de datos y de la base de datos, diseñadores de bases de datos, desarrolladores de aplicaciones y usuarios finales.
1.4.1
Administradores de datos y de la base de datos
La base de datos y el SGBD son recursos corporativos que deben gestionarse igual que cualquier otro recurso. La administración de datos y de la base de datos son papeles que generalmente se asocian con la gestión y control de un SGBD y de los datos en él almacenados. El administrador de datos (DA, Data Administrator) es responsable de gestionar los recursos de datos, lo que incluye la planificación de la base de datos, el desarrollo y mantenimiento de estándares, políticas y procedimientos y el diseño procedimental/lógico de la base de datos. El DA consulta con los gerentes de mayor nivel y les aconseja, para garantizar que la dirección seguida por el desarrollo de la base de datos permita soportar los objetivos corporativos. El administrador de la base de datos (DBA, Database Administrator) es responsable de la materialización física de la base de datos, incluyendo la implementación y diseño físicos de la base de datos, el control de la seguridad y de la integridad, el mantenimiento de la fiabilidad del sistema y la garantía de que las aplicaciones exhiban un rendimiento satisfactorio para los usuarios. El papel de un DBA tiene una orientación más técnica que el de DA, requiriéndose un conocimiento detallado del SGBD de destino y del entorno de sistema en el que está implementado. En algunas organizaciones no hay distinción entre estos dos papeles, mientras que en otras la importancia de los recursos corporativos se ve reflejada en la asignación de equipos de personas a cada uno de estos dos papeles. Hablaremos de la administración de datos y de la base de datos con más detalle en la Sección 9.15.
1.4.2
Diseñadores de bases de datos
En los grandes proyectos de diseño de bases de datos, podemos distinguir entre dos tipos de diseñador: los diseñadores lógicos de la base de datos y los diseñadores físicos de la base de datos. Las responsabilidades del diseñador lógico de la base de datos son identificar los datos (es decir, las entidades y atributos), las relaciones entre los datos y las restricciones que hay que aplicar a los datos que se almacenen en la base de datos. El diseñador lógico de la base de datos debe tener una comprensión profunda y completa de los datos de la organización y de las restricciones aplicables (las restricciones se denominan en ocasiones reglas de negocio). Estas restricciones describen las principales características de los datos, tal como la organización los ve. Como ejemplos de restricciones para DreamHome podemos citar: •
un empleado no puede gestionar más de 100 inmuebles para alquiler o venta al mismo tiempo;
Capítulo 1 Introducción a las bases de datos
21
•
un empleado no puede gestionar la venta o alquiler de un inmueble de su propiedad;
•
un mismo representante legal no puede actuar en representación tanto del comprador como del vendedor de un inmueble.
Para poder tener éxito, el diseñador lógico de la base de datos debe implicar a todos los potenciales usuarios de la base de datos en el desarrollo del modelo de datos, y esta implicación debe producirse lo más pronto posible dentro del proceso. En este libro, dividiremos el trabajo del diseñador lógico de la base de datos en dos etapas: •
diseño conceptual de la base de datos, que es independiente de los detalles de implementación, como el SGBD de destino, los programas de aplicación, los lenguajes de programación o cualquier otra consideración fisica;
•
diseño lógico de la base de datos, dirigido a un modelo de datos específico, como por ejemplo el modelo relacional, el modelo en red, el modelo jerárquico o el modelo orientado a objetos.
El diseñador físico de la base de datos decide cómo materializar fisicamente el diseño lógico de la base de datos. Esto implica: •
establecer la correspondencia tricciones de integridad;
entre el diseño lógico de la base de datos y un conjunto de tablas y res-
•
seleccionar estructuras de almacenamiento de conseguir unas buenas prestaciones;
•
diseñar las medidas de seguridad que los datos requieran.
y métodos de acceso específicos para los datos con el fin
Muchas partes del diseño físico de una base de datos dependen en gran medida del SGBD de destino y puede haber más de una forma de implementar cada mecanismo concreto. Por tanto, el diseñador fisico de la base de datos debe conocer a la perfección la funcionalidad del SGBD de destino y puede entender las ventajas y desventajas de cada alternativa para cada implementación concreta. El diseñador fisico de la base de datos debe ser capaz de seleccionar una estrategia de almacenamiento adecuada que tenga en cuenta el uso de la base de datos. Mientras que el diseño conceptual y lógico de la base de datos estén relacionados con el qué, el diseño físico de la base de datos se preocupa de cómo. Se requieren capacidades y conocimientos diferentes, lo que implica en muchas ocasiones utilizar personas distintas. Presentaremos una metodología para el diseño conceptual de bases de datos en el Capítulo 15, mientras que en el Capítulo 16 se presentará el diseño lógico de bases de datos y el diseño fisico de las bases de datos será objeto de los Capítulos 17 y 18.
1.4.3
Desarrolladores de aplicaciones
Una vez implementada la base de datos, es necesario implementar también los programas de aplicación que proporcionen la funcionalidad requerida por los usuarios finales. Esto es responsabilidad de los desarroUadores de aplicaciones. Normalmente, los desarrolladores de aplicaciones trabajan a partir de una especificación producida por los analistas de sistemas. Cada programa contiene enunciados que exigen al SGBD realizar algún tipo de operación sobre la base de datos. Esto incluye extraer datos, insertados, actualizados o borrados. Los programas pueden estar escritos en un lenguaje de programación de tercera generación o en un lenguaje de cuarta generación, como se ha mencionado en la sección precedente.
1.4.4
Usuarios finales
Los usuarios finales son los 'clientes' de la base de datos, que se diseña, implementa y mantiene precisamente para dar servicio a sus necesidades de información. Los usuarios finales pueden clasificarse de acuerdo con la forma en que utilizan el sistema:
• Usuarios inexpertos, que normalmente no son conscientes de la existencia de un SGBD. Acceden a la base de datos mediante programas de aplicación escritos a propósito y que intentan que las operaciones sean lo más simples posible. Estos usuarios invocan las operaciones sobre la base de datos introduciendo comandos simples o seleccionando una serie de opciones en un menú. Esto quiere decir que
22
Sistemas de bases de datos
no necesitan conocer ningún detalle ni sobre la base de datos, ni sobre el SGBD. Por ejemplo, el cajero de un supermercado utiliza un lector de código de barras para averiguar el precio de un artículo. Sin embargo, se está ejecutando un programa de aplicación que lee el código de barras, consulta el precio del artículo en la base de datos, ajusta el campo de la base de datos que contiene el número de artículos en almacén y muestra el precio en la pantalla . •
Usuarios avanzados. En el otro extremo del espectro, los usuarios avanzados están familiarizados con la estructura de la base de datos y con las funcionalidades ofrecidas por el SGBD. Los usuarios finales avanzados pueden utilizar un lenguaje de consulta de alto nivel, como SQL, para llevar a cabo las operaciones requeridas. Algunos usuarios finales avanzados pueden incluso escribir sus propios programas de aplicación para su uso personal.
1.5 Historia de los sistemas de gestión de bases de datos Ya hemos visto que los predecesores de los SGBD eran los sistemas basados en archivos. Sin embargo, no puede identificarse un punto temporal concreto en el que diera comienzo la técnica de bases de datos y dejaran de utilizarse los sistemas basados en archivos. De hecho, los sistemas basados en archivos continúan existiendo en determinadas áreas específicas. Se ha aducido que los sistemas de gestión de bases de datos tienen sus raíces en el proyecto lunar Apollo de la década de1960, que fue iniciado en respuesta al objetivo establecido por el presidente Kennedy para enviar un hombre a la Luna al final de esa década. En aquel tiempo no había ningún sistema disponible que pudiera utilizarse para gestionar y controlar las enormes cantidades de información que el proyecto iba a generar. Como resultado, North American Aviation (NAA, ahora Rockwell International), el contratista principal del proyecto, desarrolló un sistema software denominado GUAM (Generalized Update Access Method, método generalizado de acceso y actualización). GUAM estaba basado en el concepto de que pueden utilizarse componentes de menor tamaño para formar otros componentes mayores y así sucesivamente, hasta terminar por ensamblar el producto final. Esta estructura, que se asemeja a un árbol invertido, se denomina también estructura jerárquica. A mediados de la década de 1960, IBM unió sus fuerzas con NAA para desarrollar GUAM, lo que tuvo como resultado lo que ahora se conoce con el nombre de IMS (Information Management System, sistema de gestión de la información). La razón por la que IBM restringió IMS a la gestión de jerarquías de registros era poder utilizar dispositivos de almacenamiento en serie, especialmente las cintas magnéticas, lo cual era un requisito de mercado en aquella época. Posteriormente, dicha restricción desapareció. Aunque fue uno de los SGBD comerciales pioneros, IMS continúa siendo el principal SGBD jerárquico utilizado por la mayoría de las grandes instalaciones de tipo mainframe. A mediados de la década de 1960, otro desarrollo significativo fue la aparición de IDS (Integrated Data Store, almacenamiento integrado de datos) de General Electric. Este trabajo fue liderado por uno de los primeros pioneros de los sistemas de bases de datos, Charles Bachmann. Este desarrollo condujo a un nuevo tipo de sistema de bases de datos denominado SGBD en red, que tubo un profundo impacto sobre los sistemas de información de dicha generación. La base de datos en red fue desarrollada parcialmente para resolver la necesidad de presentar relaciones de datos más complejas que las que podían modelarse con las estructuras jerárquicas, además de para tratar de imponer un estándar de base de datos. Para ayudar a establecer dichos estándares, la conferencia CODASYL (Conference on Data Systems Languages, conferencia sobre lenguajes de sistemas de datos), en la que participaron representantes del gobierno americano y del mundo empresarial, formó un grupo de trabajo en 1965 que recibió en 1967 el nombre de DBTG (Data Base Task Group, grupo de trabajo en bases de datos). La misión encomendada al DBTG era definir especificaciones estándar para un entorno que permitiera la creación de bases de datos y la manipulación de datos. En 1969 se emitió un informe preliminar, completándose el primer informe definitivo en 1971. La propuesta del DBTG identificaba tres componentes: •
el esquema de la red, es decir, la organización lógica de la base de datos completa, vista por el DBA, en la que se incluía una definición del nombre de la base de datos, del tipo de cada registro y de los componentes de cada tipo de registro;
Capítulo 1 Introducción a las bases de datos •
23
el subesquema, es decir, la parte de la base de datos vista por el usuario o por los programas de aplicación.
•
un lenguaje de gestión de datos para definir las características y la estructura de los datos y para manipularlos. De cara a la estandarización, el DBTG especificó tres lenguajes diferentes: •
un lenguaje de definición de datos (DDL, Data Definition Language) esquema, que permite al DBA definir los esquemas de base de datos;
•
un DDL de subesquemas, que permite a los programas de aplicación definir qué parte de la base de datos requieren;
•
un lenguaje de manipulación datos.
de datos (DML, Data Manipulation
Language), para manipular los
Aunque el informe no fue adoptado formalmente por ANSl (American National Standards Institute, Instituto nacional de estándares de los Estados Unidos), sí que se desarrollaron diversos sistemas posteriormente de acuerdo con la propuesta del DBTG. Estos sistemas se conocen hoy en día con el nombre de sistemas CODASYL o DBTG. Los sistemas CODASYL y jerárquicos representaron la primera generación de sistemas de gestión de bases de datos. En el sitio web de este libro (véase la URL en el Prefacio) se examinan más en detalle estos sistemas. Sin embargo, estos dos modelos presentan algunas desventajas fundamentales: • es necesario escribir programas complejos para responder hasta la más simple de las consultas, utilizando un acceso de navegación orientado a registros; •
la independencia de los datos es mínima;
•
no existe una base teórica ampliamente aceptada.
En 1970, E. F. Codd, del laboratorio IBM Research Laboratory elaboró su muy influyente artículo sobre el modelo de datos relaciona!. Este artículo fue muy oportuno y contemplaba las desventajas de las técnicas anteriores. Después de él, se implementaron muchos SGBD relacionales experimentales, llegando a aparecer los primeros productos comerciales a finales de la década de 1970 y principios de la de 1980. Mención especial merece el proyecto System R del laboratorio San Jose Research Laboratory de IBM en California, que se desarrolló a finales de la década de 1970 (Astrahan et al., 1976). Este proyecto se llevó a cabo para demostrar el carácter táctico del modelo relacional, proporcionando una implementación de sus estructuras de datos y operaciones, y condujo a su vez a dos desarrollos principales: •
el desarrollo de un lenguaje estructurado de consulta denominado SQL, que desde entonces se ha convertido en el lenguaje estándar para los SGBD relacionales;
•
la implementación de diversos productos SGBD relacionales de carácter comercial durante la década de 1980, por ejemplo DB2 y SQL/DS de IBM y Oracle de Oracle Corporation.
Hoy en día existen centenares de sistemas SGBD relacionales tanto para entornas mainframe como para entornas PC, aunque muchos de ellos no se ajustan estrictamente a la definición del modelo relaciona!. Otros ejemplos de SGBD relacional multiusuario son Advantage Ingres Enterprise Relational Database, de Computer Associates, e Informix de IBM. Como ejemplos de SGBD relacional basado en PC están Office Access y Visual FoxPro de Microsoft, InterBase y JDataStore de Borland y R:Base de R:Base Technologies. Los SGBD relacionales se denominan sistemas de gestión de bases de datos de segunda generación. Hablaremos del modelo de datos relacional en el Capítulo 3. El modelo relacional no carece de desventajas, en particular sus limitadas capacidades de modelado. Desde entonces, se ha investigado en profundidad, tratando de resolver este problema. En 1976, Chen presentó el modelo entidad-relación, que hoy en día constituye una técnica ampliamente aceptada para el diseño de bases de datos y constituye el fundamento para la metodología presentada en los Capítulos 15 y 16 de este libro. En 1979, el propio Codd trató de resolver algunas de las carencias de su propuesta original con una versión ampliada del modelo relacional denominada RM/T (1979) y posteriormente RM!V2 (1990). Los intentos de proporcionar un modelo de datos que represente el 'mundo real' de forma más precisa se han clasificado, con carácter general, bajo el término de modelado de datos semántico.
24
Sistemas de bases de datos
En respuesta a la creciente complejidad de las aplicaciones de bases de datos, han surgido dos 'nuevos' sistemas: los SGBD orientados a objetos (OODBMS) y los SGBD objeto-relacionales (ORDBMS). Sin embargo, a diferencia de los modelos anteriores, la composición real de estos modelos no está clara. Esta evolución representa lo que se denomina sistemas de gestión de bases de datos de tercera generación, de los que hablaremos en los Capítulos 25-28.
1.6 Ventajas y desventajas de los SGBD Los sistemas de gestión de bases de datos presentan enormes ventajas potenciales. Desafortunadamente, bién tienen algunas desventajas y en esta sección vamos a examinar tanto unas como otras.
tam-
Ventajas Las ventajas de los sistemas de gestión de bases de datos se enumeran en la Tabla 1.2. Tabla 1.2.
Ventajas de un SGBD.
Control de la redundancia de los datos
Economía de escala
Coherencia de los datos
Equilibrio entre requisitos conflictivos
Más información a partir de la misma cantidad de datos
Mejor accesibilidad a los datos y mayor capacidad de respuesta
Compartición de datos
Productividad
Mayor integridad de los datos
Mantenimiento
Mayor seguridad
Mayor nivel de concurrencia
Imposición de estándares
Servicios mejorados de copia de seguridad y recuperación
mejorada más sencillo gracias a la independencia
de los datos
Control de la redundancia de los datos
Como hemos explicado en la Sección 1.2, los sistemas tradicionales basados en archivos desperdician espacio al almacenar la misma información en más de un archivo. Por ejemplo, en la Figura 1.5 vemos que se almacenaban datos similares relativos a los inmuebles en alquiler y a los clientes tanto en el departamento de ventas como en el de contratos. Por contraste, la técnica de base de datos trata de eliminar la redundancia integrando los archivos, de modo que no se almacenen múltiples copias de los mismos datos. Sin embargo, la técnica de base de datos no elimina la redundancia por completo, sino que controla la cantidad de redundancia inherente a la base de datos. Algunas veces, resulta necesario duplicar elementos de datos clave para modelar las relaciones, mientras que en otras ocasiones resulta deseable duplicar algunos elementos de datos para mejorar las prestaciones. Las razones que impulsan a este tipo de duplicación controlada quedarán más claras después de leer los siguientes capítulos. Coherencia de los datos
Al eliminar o controlar la redundancia, reducimo~ el riesgo de que se produzcan incoherencias. Si un elemento de datos sólo se almacena una vez en la base de datos, las actualizaciones de su valor sólo tienen que llevarse a cabo una vez y el nuevo valor estará disponible de forma inmediata para todos los usuarios. Si almacenamos un elemento de datos más de una vez y el sistema es consciente de esto, el sistema podrá garantizar que todas las copias del elemento sean coherentes. Desafortunadamente, muchos de los SGBD actuales no garantizan de manera automática este tipo de coherencia. Más información a partir de la misma cantidad de datos
Al integrar los datos operacionales, la información puede deducir información adicional a partir del conjunto de datos existente. Por ejemplo, en el sistema basado en archivos de la Figura 1.5, el departamento de contra-
Capítulo 1 Introducción a las bases de datos
25
tos no sabe quién es el propietario de un inmueble alquilado. De forma similar, el departamento de ventas no conoce los detalles de los contratos de alquiler. Al integrar los archivos, el departamento de contratos tiene acceso a los detalles referidos a los propietarios y el departamento de ventas a los detalles referentes a los contratos. A partir de la misma cantidad de datos, podemos ahora obtener mucha más información. Compartición de los datos
Normalmente, los archivos son propiedad de las personas o departamentos que los usan. Por otro lado, la base de datos pertenece a toda la organización y debe ser compartida por todos los usuarios autorizados. De este modo, un número mayor de usuarios puede compartir una mayor cantidad de datos. Además, pueden escribirse nuevas aplicaciones que utilicen los datos existentes en la base de datos y añadir sólo los datos que no estén actualmente almacenados, en lugar de tener que volver a definir todos los requisitos referidos a los datos. Las nuevas aplicaciones también pueden emplear las funciones proporcionadas por el SGBD, como los mecanismos de definición y manipulación y los de control de concurrencia y recuperación, en lugar de tener que proporcionar esas funciones por sí mismas. Mayor integridad en los datos
El concepto de integridad de la base de datos hace referencia a la validez y coherencia de los datos almacenados. La integridad se suele expresar en términos de restricciones, que son reglas de coherencia que no se permite que la base de datos viole. Las restricciones pueden aplicarse a los elementos de datos contenidos en un único registro o aplicarse en las relaciones entre registros. Por ejemplo, una restricción de integridad podría establecer que el salario de un empleado no sea superior a 40.000 euros o que el número de sucursal contenido en el registro de un empleado, que representa la sucursal en la que el empleado trabaja, debe corresponderse con una sucursal existente. De nuevo, la integración permite que el DBA defina y que el SGBD imponga las restricciones de integridad. Mayor seguridad
La seguridad de la base de datos es la protección de los datos frente a su uso por personas no autorizadas. Sin unas medidas de seguridad adecuadas, la integración hace que los datos sean más vulnerables que en los sistemas basados en archivos. Sin embargo, la integración permite que el DBA defina y que el SGBD imponga medidas de seguridad en la base de datos. Estas medidas pueden tomar la forma de nombres de usuario y contraseñas para identificar a las personas autorizadas a usar la base de datos. También puede restringirse el tipo de acceso a los datos para los usuarios autorizados, según los tipos de operación (extracción, inserción, actualización, borrado). Por ejemplo, el DBA tiene acceso a todos los datos de la base de datos; un gerente de sucursal puede tener acceso a todos los datos relacionados con su sucursal; y un vendedor puede tener acceso a todos los datos relativos a los inmuebles, pero no a datos confidenciales como puedan ser los detalles salariales referidos al personal. Imposición de estándares
De nuevo, la integración permite al DBA definir e imponer los estándares necesarios. Puede tratarse de estándares departamentales, de la organización, nacionales o internacionales referidos a cosas tales como los formatos de datos necesarios para facilitar el intercambio de datos entre sistemas, los convenios de denominación, los estándares de documentación, los procedimientos de actualización y las reglas de acceso. Economía de escala
Al combinar todos los datos operacionales de una organización en una única base de datos y crear un conjunto de aplicaciones que funcionan con esta fuente centralizada de datos, pueden reducirse enormemente los costes. En este caso, el presupuesto que normalmente se asignaría a cada departamento para el desarrollo y mantenimiento de su sistema basado en archivos puede condenarse, lo que posiblemente resulte en un coste total inferior, lo que conduce a la obtención de economías de escala. El presupuesto combinado puede em-
26
Sistemas de bases de datos
plearse para comprar una configuración de sistema más adecuada a las necesidades de la organización. Dicha configuración puede consistir de una única computadora de gran potencia y tamaño o de una red de computadoras más pequeñas. Equilibrio entre los requisitos conflictivos
Cada usuario de departamento tiene necesidades que pueden entrar en conflicto con las de otros usuarios. Puesto que la base de datos está bajo control del DBA, éste puede tomar decisiones acerca del diseño y la utilización operacional de la base de datos que proporcionen el mejor uso de los recursos, considerando a la organización como un todo. Estas decisiones proporcionarán un rendimiento óptimo para las aplicaciones importantes, posiblemente a expensas de las que sean menos críticas. Mejor accesibilidad de los datos y mayor capacidad de respuesta
De nuevo, como resultado de la integración, los datos que atraviesan las fronteras departamentales son accesibles de modo directo por los usuarios finales. Esto proporciona un sistema con una funcionalidad potencialmente mucho mayor que puede, por ejemplo, emplearse para proporcionar mejores servicios al usuario final o a los clientes de la organización. Muchos SGBD proporcionan lenguajes de consulta o herramientas de escritura de informes que permiten a los usuarios plantear cuestiones ad hoc y obtener la información requerida casi inmediatamente en su terminal, sin necesidad de que ningún programador escriba un programa software para extraer la información de la base de datos. Por ejemplo, el gerente de una sucursal podría obtener un listado de todos los apartamentos cuyo alquiler mensual sea superior a 400 euros introduciendo la siguiente instrucción SQL en un terminal: SELECT* FROM PropertyForRent WHERE type = 'Flat' ANO rent > 400; Mayor productividad
Como hemos mencionado anteriormente, el SGBD proporciona muchas de las funciones están dar que el programador tendría normalmente que incluir dentro de su aplicación basada en archivos. A un nivel básico, el SGBD proporciona todas las rutinas de bajo nivel para gestión de archivos que se utilizan normalmente en los programas de aplicación. La disponibilidad de estas funciones permite al programador concentrarse en la funcionalidad específica requerida por los usuarios, sin tener que preocuparse por los detalles de implementación de bajo nivel. Muchos SGBD también proporcionan un entorno de cuarta generación compuesto por herramientas que simplifican el desarrollo de aplicaciones de base de datos. Como resultado, se mejora la productividad de los programadores y se reducen los tiempos de desarrollo (lo que implica, a su vez, unos menores costes). Mantenimiento simplificado gracias a la independencia de los datos
En los sistemas basados en archivos, las descripciones de los datos y la lógica para acceder a los datos están integradas en cada programa de aplicación, haciendo que los programas sean dependientes de los datos. Un cambio en la estructura de los datos, por ejemplo, que hiciera que una dirección tuviera 41 caracteres en lugar de 40, o un cambio en la forma de almacenar los datos en disco, podría requerir efectuar alteraciones sustanciales en todos los programas que se vieran afectados por el cambio. Por contraste, un SGBD separa las descripciones de los datos de las aplicaciones, haciendo así que las aplicaciones sean inmunes a los cambios que se efectúen en las descripciones de los datos. Este concepto se conoce con el nombre de independencia de los datos y hablaremos más de él en la Sección 2.1.5. La independencia de los datos simplifica el mantenimiento de las aplicaciones de la base de datos. Mayor nivel de concurrencia
En algunos sistemas basados en archivos, si se permite a dos o más usuarios acceder al mismo archivo simultáneamente, es posible que los accesos se interfieran entre sí, provocando una pérdida de información o inclu-
Capítulo 1 Introducción a las bases de datos
27
so de la integridad de los datos. Muchos SGBD se encargan de gestionar el acceso concurrente a la base de datos y garantizan que dichos problemas no puedan presentarse. Hablaremos del control de concurrencia en el Capítulo 20. Servicios
mejorados
de copia de seguridad
y recuperación
Muchos sistemas basados en archivo asignan al usuario la responsabilidad de proporcionar medidas para proteger los datos frente a fallos del sistema informático o de los programas de aplicación. Esto puede requerir realizar copias de seguridad de los datos a diario, durante las horas nocturnas. En caso de que se produzca un fallo al día siguiente, se restaura la copia de seguridad y el trabajo que se haya realizado desde que lue hecha la copia de seguridad se pierde y es preciso volverlo a efectuar. Por contraste, los SGBD modernos proporcionan facilidades para minimizar la cantidad de procesamiento que se pierde debido a un fallo. Hablaremos de las cuestiones de recuperación de una base de datos en la Sección 20.3
Desventajas Las desventajas de la técnica de base de datos se resumen en la Tabla 1.3. Tabla 1.3.
Desventajas de un SGBD.
Complejidad Tamaño Coste del SGBD Costes del hardware adicional Costes de conversión Prestaciones Mayor impacto de los fallos Complejidad
Para que un buen SGBD pueda proporcionar la funcionalidad esperada, el SGBD tiene que ser un programa software de gran complejidad. Los desarrolladores y diseñadores de bases de datos, los administradores de datos y de bases de datos y los usuarios finales deben ser capaces de comprender esta funcionalidad para poder aprovecharla al máximo. Si no se comprende adecuadamente el sistema, pueden tomarse decisiones de diseño incorrectas, lo que podría tener serias consecuencias para la organización. Tamaño
La complejidad y el amplio rango de funcionalidades hacen que el SGBD sea un programa software de gran tamaño, que ocupa muchos megabytes de espacio de disco y requiere una cantidad de memoria importante para poder ejecutarse de manera eficiente. Coste del SGBD
El coste de los SGBD varía significativamente, dependiendo del entorno y de la funcionalidad proporcionada. Por ejemplo, un SGBD monousuario para una computadora personal puede costar sólo unos 100 euros. Sin embargo, un SGBD multiusuario de gran tamaño para mainframe, que preste servicio a centenares de usuarios, puede ser enormemente caro, quizá del orden de 100.000 o incluso 1.000.000 de euros. También hay que tener en cuenta el coste recurrente de mantenimiento anual, que normalmente suele ser un porcentaje del precio de venta. Coste del hardware
adicional
Los requisitos de almacenamiento en disco para el SGBD y la base de datos pueden imponer la compra de espacio de almacenamiento adicional. Además, para obtener las prestaciones requeridas, puede que sea nece-
28
Sistemas de bases de datos
sario comprar una plataforma hardware mayor, quizás incluso una máquina dedicada a ejecutar en exclusiva el SGBD. Estas compras de hardware adicional hacen que se incrementen los costes. Costes de conversión
En algunas situaciones, el coste del SGBD y del hardware adicional puede ser insignificante si lo comparamos con el coste de convertir las aplicaciones existentes para que se ejecuten sobre el nuevo SGBD y sobre la nueva plataforma hardware. Este coste también incluye el coste de formar al personal en la utilización de los nuevos sistemas y, posiblemente, la contratación de personal especializado como ayuda durante la conversión y la operación del sistema. Este coste es una de las razones principales por las que algunas organizaciones se sienten atadas a sus sistemas actuales y no se deciden a cambiar a tecnologías de base de datos más modernas. Algunas veces se utiliza el término sistema heredado para referirse a un sistema más antiguo y usualmente inferior. Prestaciones
Normalmente, los sistemas basados en archivos se escriben para una aplicación específica, como por ejemplo una aplicación de facturación. Como resultado, las prestaciones suelen ser muy buenas. Por el contrario, un SGBD se escribe para constituir una solución más general, con el fin de que puedan utilizado muchas aplicaciones y no sólo una aplicación concreta. El efecto es que algunas aplicaciones pueden ejecutarse más lentamente de lo que solían. Mayor impacto de los fallos
La centralización de los recursos implementa la vulnerabilidad del sistema. Puesto que todos los usuarios y aplicaciones dependen de la disponibilidad del SGBD, el fallo de ciertos componentes puede hacer que se detengan todas las operaciones.
Resumen del capítulo •
El sistema de gestión temas de información Los sistemas de base muchos los problemas
de bases de datos (SGBD) constituye hoy en día la base fundamental de los sisy ha cambiado de modo radical la forma en que muchas organizaciones operan. de datos continúan siendo un área muy activa de investigación y son todavía significativos que hay que resolver de manera satisfactoria.
•
Los predecesores de los SGBD eran los sistemas basados en archivos, que son una colección de programas de aplicación que realizan una serie de servicios para los usuarios finales, usualmente la generación de informes. Cada programa define y gestiona sus propios datos. Aunque los sistemas basados en archivos constituyeron una gran mejora con respecto a los sistemas de archivo manual, siguen presentado problemas significativos, principalmente la redundancia de datos existente y la dependencia entre los programas y los datos.
•
La técnica de bases de datos hizo su aparición para resolver los problemas asociados con los sistemas basados en archivos. Una base de datos es una colección compartida de datos lógicamente relacionados, junto con una descripción de estos datos, diseñada para satisfacer las necesidades de información de una organización. Un SGBD es un sistema software que permite a los usuarios definir, emplear, mantener y controlar el acceso a la base de datos. Un programa de aplicación es un programa informático que interactúa con la base de datos emitiendo solicitudes (normalmente instrucciones SQL) dirigidas al SGBD. Normalmente se utiliza el término sistema de bases de datos para definir una colección de programas de aplicación que interactúan con la base de datos, junto con el SGBD y la propia base de datos.
•
Todos los accesos a la base de datos se realizan a través del SGBD. El SGBD proporciona un lenguaje de definición de datos (DDL, Data Definition Language), que permite a los usuarios definir la base de datos, y un lenguaje de manipulación de datos (DML, Data Manipulation Language), que permite a los usuarios insertar, actualizar, borrar y extraer datos de la base de datos.
Capítulo 1 Introducción a las bases de datos
29
•
El SGBp proporciona un acceso controlado a la base de datos. Proporciona mecanismos de seguridad, integridad, control de concurrencia y control de recuperación, así como un catálogo accesible por el usuario. También proporciona un mecanismo de vistas para simplificar los datos con los que el usuario tiene que tratar.
•
El entorno SGBD está compuesto de hardware (la computadora), de software (el SGBD, el sistema operativo y los sistemas de aplicación), de datos, de procedimientos y de personas. Las personas que se relacionan con el SGBD son los administradores de datos y de base de datos, los diseñadores de bases de datos, los desarrolladores de aplicaciones y los usuarios finales.
•
Las raíces de los SGBD están en los sistemas basados en archivos. Los sistemas jerárquicos y CODASYL representan la primera generación de sistemas de gestión de bases de datos. El modelo jerárquico está representado por IMS (Information Management System), mientras que el modelo en red o CODASYL está ejemplificado por IDS (Integrate Data Store), ambos desarrollados a mediados de la década de 1960. El modelo relacional, propuesto por E. F. Codd en 1970, representa la segunda generación de sistemas de gestión de bases de datos. Este modelo tuvo una gran influencia sobre la comunidad de los SGBD y hoy en día existen más de 100 SGBD relacionales. La tercera generación de sistemas de gestión de bases de datos está representada por los SGBD objeto-relacional y los SGBD orientados a objetos.
•
Entre las ventajas de la técnica de bases de datos podemos citar el control de la redundancia de los datos, la coherencia de los datos, la compartición de datos y unos mejores mecanismos de seguridad e integridad. Entre sus desventajas cabe resaltar la complejidad, el coste, la reducción de las prestaciones y el mayor impacto de los fallos sobre el sistema.
Cuestiones de repaso 1.1.
Proporcione cuatro ejemplos de sistemas de bases de datos distintos de los enumerados en la Sección 1.1.
1.2.
Explique cada uno de los siguientes términos: (a)
datos
(b)
base de datos
(c)
sistema de gestión de bases de datos
(d) programa de aplicación de bases de datos (e)
independencia de los datos
(f)
seguridad
(g)
integridad
(h) vistas. 1.3.
Describa el enfoque de tratamiento de los datos adoptado en los antiguos sistemas basados en archivos. Indique las desventajas de este enfoque.
lA.
Describa las principales características del enfoque de base de datos y compárelas con la técnica basada en archivos.
1.5.
Describa los cinco componentes del entorno SGBD y explique cómo se relacionan entre sí.
1.6.
Explique el papel de cada una de las siguientes personas en un entorno de base de datos: (a)
administrador de los datos
(b)
administrador de la base de datos
(c)
diseñador lógico de la base de datos
(d)
diseñador fisico de la base de datos
(e)
desarrollador de aplicaciones
(f)
usuarios finales
30
Sistemas de bases de datos
1.7.
Explique las ventajas y desventajas de los SGBD.
Ejercicios 1.8.
Entreviste a algunos usuarios de sistemas de bases de datos. ¿Qué características de los SGBD encuentran más útiles y por qué? ¿Qué funciones de los SGBD encuentran menos útiles y por qué? ¿Cuáles creen estos usuarios que son las ventajas y desventajas de los SGBD?
1.9.
Escriba un pequeño programa (utilizando pseudocódigo si fuera necesario) que permita la introducción y visualización de detalles de los clientes, incluyendo un número de cliente, el nombre, la dirección, el número telefónico, el número deseado de habitaciones y el alquiler máximo. Los detalles deben almacenarse en un archivo. Introduzca unos cuantos registros y muestre los detalles. Ahora repita este proceso pero, en lugar de escribir un programa especial, utilice cualquier SGBD al que tenga acceso. ¿Qué conclusiones puede sacar de estas dos técnicas?
1.10.
Analice el caso de estudio de DreamHome presentado en la Sección 10.4 Y en el Apéndice A. ¿De qué forma podría un SGBD ayudar a esta organización? Identifique los datos que es necesario representar en esta base de datos. ¿Qué relaciones existen entre los elementos de datos? ¿Qué consultas cree que se necesitarán?
1.11.
Analice el caso de estudio de Wellmeadows Hospital presentado en el Apéndice B.3. ¿De qué forma podría un SGBD ayudar a esta organización? Identifique los datos que se necesiten representar en la base de datos. ¿Qué relaciones existen entre los elementos de datos?
Capítulo
El entorno de la base de datos
Objetivos del capítulo: En este capítulo aprenderá: •
El propósito y origen de la arquitectura de base de datos en tres niveles.
•
El contenido de los niveles externo, conceptual e interno.
• •
El propósito de las asignaciones entre los niveles externo/conceptual El significado de la independencia de datos lógica y física.
y los niveles conceptual/interno.
•
La distinción entre un lenguaje de definición de datos (DDL, Data Definition Language) y un lenguaje de manipulación (DML, Data Manipulation Language). • Una clasificación de los modelos de datos. •
El propósito y la importancia del modelado conceptual.
•
Los servicios y funciones típicas que un SGBD debe proporcionar.
•
La función y la importancia del catálogo del sistema.
•
Los componentes software de un SGBD.
•
El significado de la arquitectura cliente-servidor y las ventajas que este tipo de arquitectura tiene para un SGBD.
•
La función y usos de los monitores de procesamiento de transacciones (TP, Transaction Processing).
Uno de los objetivos principales de un sistema de base de datos consiste en proporcionar a los usuarios una visión abstracta de los datos, ocultando ciertos detalles acerca de cómo se almacenan y manipulan esos datos. Por tanto, el punto de partida para el diseño de una base de datos debe ser una descripción abstracta y general de los requisitos de información de la organización que haya que representar en la base de datos. En este capítulo, y a lo largo del libro, utilizaremos el término 'organización' en un sentido general, para referirnos a la organización como un todo o a una parte de la misma. Por ejemplo, en el caso de estudio de DreamHome puede que nos interese modelar: del 'mundo real'
y
•
las entidades
•
los atributos que describan las propiedades o cualidades de cada entidad (por ejemplo, tener los atributos name, position y salary);
•
las relaciones entre estas entidades (por ejemplo,
8taff, ProperlyForRent,
PrivateOwner
8taff Manages
Client; 8taff
puede
ProperlyForRent).
Además, puesto que una base de datos es un recurso compartido, cada usuario puede requerir una vista diferente de los datos contenidos en la base de datos. Para satisfacer estas necesidades, la arquitectura de la mayoría de los SGBD comerciales disponibles hoy en día está basada, hasta cierto punto, en la denominada arquitectura ANSI -SPARC. En este capítulo, hablaremos de diversas características arquitectónicas y funcionales de los SGBD.
32
Sistemas de bases de datos
Estructura del capítulo En la Sección 2.1 se examina la arquitectura ANSI-SPARC en tres niveles y los beneficios asociados. En la Sección 2.2, consideramos los tipos de lenguaje utilizados por los SGBD y en la Sección 2.3 se introducen los conceptos de modelos de datos y modelado conceptual, que ampliaremos en secciones posteriores del libro. En la Sección 2.4 se explican las funciones que debe proporcionar un SGBD y en las Secciones 2.5 y 2.6 se examina la arquitectura interna de un SGBD típico. Los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome, del que se habla más en detalle en la Sección 10.4 Y en el Apéndice A. Buena parte del material de este capítulo proporciona importante información de referencia sobre los SGBD. Sin embargo, el lector para el que este libro constituye su primer contacto con los sistemas de bases de datos puede encontrarse con que parte del material resulta difícil de comprender en una primera lectura. No se preocupe demasiado por esto; puede volver a leer determinadas partes de este capítulo posteriormente, después de haber leído los capítulos siguientes del libro.
2.1
La arquitectura en tres niveles de ANSI-SPARC
En 1971 se elaboró una de las primeras propuestas de terminología estándar y de arquitectura general para los sistemas de bases de datos; el responsable de elaborar esa propuesta fue el DBTG (Data Base Task Group, grupo de trabajo en bases de datos) nombrado por la conferencia CODASYL (Conference on Data Systems and Languages), celebrada en 1971. El DBTG percibió la necesidad de adoptar un enfoque en dos niveles, con una vista del sistema denominada esquema y una serie de vistas de usuario denominadas subesquemas. El comité SPARC (Standard Planning and Requirements Committee, comité de requisitos y planificación de estándares) de ANSI (American National Standars Institute), ANSI/X3/SPARC, elaboró una terminología y una arquitectura similares en 1975 (ANSI, 1975). ANSI-SPARC decidió adoptar un enfoque basado en tres niveles, en el que se añadía un catálogo del sistema. Estas propuestas reflejaban las publicadas por determinadas organizaciones de usuarios de IBM algunos años antes, y se concentraban en la necesidad de disponer de un nivel independiente de la implementación con el fin de aislar los programas de los problemas de representación subyacentes (Guide/Share, 1970). Aunque el modelo ANSI-SPARC no llegó a convertirse en un estándar, continúa proporcionando una base para comprender parte de la funcionalidad de un SGBD. En lo que a nosotros concierne, el punto fundamental de estos informes, y de otros posteriores, es la identificación de tres niveles de abstracción, es decir, tres niveles diferentes mediante los cuales pueden describirse los elementos de datos. Estos niveles forman una arquitectura en tres niveles que comprende un nivel externo, otro conceptual y otro interno, como se muestra en la Figura 2.1. La forma en que los usuarios perciben los datos se denomina nivel externo. La forma en que el SGBD y el sistema operativo perciben los datos es el nivel interno, y en este nivel es donde se almacenan realmente los datos utilizando las estructuras de datos y organizaciones de archivos descritas en el Apéndice C. El nivel conceptual proporciona tanto la correspondencia como la necesaria independencia entre los niveles externo e interno. El objetivo de la arquitectura en tres niveles es el de separar la vista que cada usuario tiene de la base de datos de la forma en que se representa la base de datos físicamente. Son varias las razones por las que esta separación resulta deseable: •
Todos los usuarios deben poder acceder a los mismos datos, pero al mismo tiempo conviene que dispongan de diferentes vistas personalizadas de los mismos. Cada usuario debería poder ser capaz de cambiar la forma en que puede ver los datos y este cambio no debería afectar a otros usuarios.
•
Los usuarios no deberían tener que tratar directamente con los detalles de almacenamiento físico de la base de datos, como puedan ser los índices o los mecanismos de hash (véase el Apéndice C). En otras palabras, la interacción del usuario con la base de datos debería ser independiente de las consideraciones de almacenamiento.
•
El administrador de la base de datos (DBA) debe poder cambiar las estructuras de almacenamiento la base de datos sin afectar a las vistas de los usuarios.
de
Capítulo 2 El entorno de la base de datos Usuario 1
Usuario 2
33
Usuario n
Nivel externo
Nivel conceptual
Nivel interno
Organización fisica de los datos Base de datos
Figura 2.1.
Arquitectura
en tres niveles de ANSI-SPARC .
•
La estructura interna de la base de datos no debería verse afectada por los cambios que se efectúen en lo relativo a los aspectos físicos del almacenamiento, como por ejemplo el traslado a un nuevo dispositivo de almacenamiento .
•
El DBA debe poder modificar la estructura conceptual de la base de datos sin afectar a todos los usuanos.
2.1.1
Nivel externo
Nivel externo
La vista que los usuarios tienen de la base de datos. Este nivel describe la parte de la base de datos que es relevante para cada usuario.
El nivel externo está compuesto por una serie de diferentes vistas externas de la base de datos. Cada usuario tiene una vista del 'mundo real' representada en una forma que resulta familiar para dicho usuario. La vista externa incluye únicamente aquellas entidades, atributos y relaciones del 'mundo real' que resultan de interés para el usuario. Otras entidades, atributos o relaciones que no sean de su interés pueden estar, asimismo, representadas en la base de datos, pero el usuario no será consciente de que existen. Además, las diferentes vistas pueden constituir diferentes representaciones de los mismos datos. Por ejemplo, uno de los usuarios puede ver las fechas con el formato (día, mes, año), mientras que otros puede verlas con el formato (año, mes, día). Algunas vistas pueden también incluir datos derivados o calculados: datos que no están realmente almacenados en la base de datos como tales, sino que son creados cada vez que se los necesita. Por ejemplo, en el caso de estudio de DreamHome, puede que queramos ver la edad de un empleado. Sin embargo, resulta bastante poco probable que se almacenen las edades como tales, ya que estos datos tendrían que ser actualizados a diario. En lugar de ello, se almacena la fecha de nacimiento del empleado y la edad puede ser calculada por el SGBD cada vez que sea necesario. Las vistas pueden también incluir datos combinados o derivados a partir de varias entidades. Hablaremos de las vistas con más detalle en las Secciones 3.4 y 6.4.
2.1.2
Nivel conceptual
Nivel conceptual
La vista comunitaria de la base de datos. Este nivel describe qué datos están almacenados en la base de datos y las relaciones existentes entre los mismos.
34
Sistemas de bases de datos
El nivel intermedio en la arquitectura de tres niveles es el nivel conceptual. Este nivel contiene la estructura lógica de toda la base de datos, tal como la ve el DBA. Se trata de una vista completa de los requisitos de datos de la organización, siendo esa vista independiente de cualesquiera consideraciones de almacenamiento. El nivel conceptual representa: •
todas las entidades, sus atributos y sus relaciones;
•
las restricciones aplicables a los datos;
•
la información semántica acerca de los datos;
•
la información de seguridad e integridad.
El nivel conceptual proporciona soporte a cada una de las vistas externas, en el sentido de que todos los datos accesibles por un usuario deben estar contenidos en, o ser derivables a partir de, el nivel conceptual. Sin embargo, este nivel no debe contener ningún detalle que sea dependiente del almacenamiento. Por ejemplo, la descripción de una entidad sólo debe contener los tipos de datos de los atributos (por ejemplo, entero, real, carácter) y su longitud (como pueda ser el número máximo de dígitos o caracteres), pero no información sobre el almacenamiento, como pueda ser el número de byte s ocupados.
2.1.3
Nivel interno
Nivel interno
Representación física de la base de datos en la computadora. están almacenados los datos en la base de datos.
Este nivel describe cómo
El nivel interno, cubre la implementación física de la base de datos que se necesita para conseguir unas prestaciones óptimas en tiempo de ejecución y una utilización óptima del espacio de almacenamiento. Cubre las estructuras de datos y organizaciones de archivos utilizadas para almacenar los datos en los dispositivos de almacenamiento. Este nivel utiliza los métodos de acceso del sistema operativo (técnicas de gestión de archivos para almacenamiento y extracción de registros de datos) con el fin de introducir los datos en los dispositivos de almacenamiento, construir los índices, extraer los datos, etc. El nivel interno se ocupa de conceptos tales como: •
la asignación de espacio de almacenamiento
para los datos e índices;
•
las descripciones de los registros para el almacenamiento elementos de datos);
•
la ubicación de los registros;
•
la compresión de datos y las técnicas de cifrado de datos.
(almacenando
los tamaños requeridos para
Por debajo del nivel interno se encuentra el nivel físico, que puede ser gestionado por el sistema operativo bajo la dirección del SGBD. Sin embargo, las funciones de SGBD y del sistema operativo en el nivel físico no tienen una separación perfectamente clara y varían de un sistema a otro. Algunos SGBD aprovechan muchos de los métodos de acceso del sistema operativo, mientras que otros sólo utilizan los métodos más básicos y crean sus propias organizaciones de archivos. El nivel físico situado por debajo del SGBD está compuesto de elementos de los que sólo entiende el sistema operativo, como por ejemplo la forma exacta en que se implementan los secuenciamientos y la información sobre si los campos de los registros internos se almacenan como bytes contiguos en el disco.
2.1.4
Esquemas, asignaciones e instancias
La descripción global de la base de datos se denomina esquema de la base de datos. Existen tres tipos diferentes de esquemas en la base de datos y dichos tipos se definen de acuerdo con los niveles de abstracción de la arquitectura en tres niveles ilustrada en la Figura 2.1. En el nivel más alto, disponemos de múltiples esquemas externos (también denominados subesquemas), que se corresponden con las diferentes vistas de los datos. En el nivel conceptual, tenemos el esquema conceptual, que describe todas las entidades, atributos y relaciones, junto con las restricciones de integridad aplicables. En el nivel más bajo de abstracción, tenemos
Capítulo 2 El entorno de la base de datos
35
el esquema interno que es una descripción completa del modelo interno en la que se incluyen las definiciones de los registros almacenados, los métodos de representación, los centros de datos y los índices y estructuras de almacenamiento utilizados. Sólo existe un esquema conceptual y un esquema interno en cada base de datos. El SGBD es responsable de establecer la correspondencia entre estos tres tipos de esquema. También debe comprobar la coherencia de los esquemas; en otras palabras, el SGBD debe comprobar que cada esquema externo pueda derivarse a partir del esquema conceptual, y debe emplear la información del esquema conceptual para establecer la correspondencia entre cada esquema externo y el esquema interno. El esquema conceptual se relaciona con el esquema interno mediante una correspondencia conceptual/interno. Esto lJermite al SGBD localizar el registro o combinación de registros dentro del almacenamiento físico que constituyen un registro lógico en el esquema conceptual, j unto con cualesquiera restricciones que haya que aplicar a las operaciones que se realicen sobre dicho registro lógico. También permite resolver las diferencias que existan entre los nombres de entidad, nombres de atributo, orden de los atributos, tipos de datos, etc. Finalmente, cada esquema externo se relaciona con el esquema conceptual mediante la asignación externo/conceptual. Esto permite al SGBD establecer la correspondencia entre los nombres de la vista del usuario y las partes correspondientes del esquema conceptual. En la Figura 2.2 se muestra un ejemplo de los diferentes niveles. Aquí, hay dos vistas externas diferentes de la información de los empleados. Una de ellas está compuesta por el número de empleado (sNo), el nombre (fName), el apellido (iName), la edad (age) y el salario (salary); una segunda vista está compuesta por el número de empleado (staffNo), el apellido (IName) y el número de sucursal donde trabaja el empleado (branchNo). Estas vistas externas se combinan en una única vista conceptual. En este proceso de combinación, la principal diferencia es que el campo age ha sido modificado para obtener un campo de fecha de nacimiento (008, date ofbirth). El SGBD mantiene la correspondencia entre el nivel externo y el nivel conceptual; por ejemplo, asigna el campo sNo de la primera vista externa al campo staffNo del registro conceptual. A continuación, se establece la correspondencia entre el nivel conceptual y el nivel interno, que contiene una descripción física de la estructura del registro conceptual. En este nivel, podemos ver una definición de la estructura en un lenguaje de alto nivel. La estructura contiene un puntero, next, que permite enlazar entre sí la lista de registros de empleados para formar una cadena. Observe que el orden de los campos en el nivel interno es diferente del orden existente en el nivel conceptual. De nuevo, corresponde al SGBD mantener la correspondencia entre el nivel conceptual y el interno. Resulta importante distinguir entre la descripción de la base de datos y la propia base de datos. La descripción de la base de datos es el esquema de la base de datos. El esquema se especifica durante el proceso de Vista externa 1
Vista externa 2
Nivel conceptual
Nivel interno
struct STAFF { int staffNo; int branchNo; char fName [15J; char IName [15J; struct date dateOfBirth; float salary; struct STAFF *next;
1*
puntero en siguiente registro Staff *[
};
index staffNo; index branchNo;
[* definición de indices para Staff *[
Figura 2.2. Diferencias entre los tres niveles.
36
Sistemas de bases de datos
diseño de la base de datos y no suele tener que cambiar frecuentemente. Sin embargo, los propios datos contenidos en la base de datos sí que pueden cambiar de manera frecuente; por ejemplo, cambiarán cada vez que insertemos los detalles de un nuevo empleado o de un nuevo inmueble. Los datos de la base de datos en cualquier instante concreto de tiempo se denominan instancia de la base de datos. Por tanto, a un mismo esquema de la base de datos le pueden corresponder muchas instancias de base de datos. El esquema se denomina en ocasiones intensión de la base de datos, mientras que a una instancia se la denomina extensión (o estado) de la base de datos.
2.1.5
Independencia de los datos
Uno de los objetivos principales de la arquitectura de tres niveles es el de proporcionar independencia de los datos, lo que quiere decir que los niveles más altos no se ven afectados por los cambios que se efectúen en los niveles inferiores. Existen dos tipos de independencia de los datos: lógica y física. Independencia lógica de los datos
El concepto de independencia lógica de los datos hace referencia a la inmunidad de los esquemas externos a las modificaciones que se efectúen en el esquema conceptual.
Debe ser posible efectuar cambios en el esquema conceptual, como por ejemplo la adición o eliminación de nuevas entidades, atributos o relaciones, sin necesidad de modificar los esquemas externos existentes ni reescribir los programas de aplicación disponibles. Obviamente, aquellos usuarios para los que se hayan realizado los cambios tendrán que ser conscientes de los mismos, pero lo importante es que los otros usuarios no se vean afectados. Independencia física de los datos
El concepto de independencia
física de los datos hace referencia a la inmunidad del
esquema conceptual a los cambios que se efectúen en el esquema interno.
Debe ser posible efectuar cambios en el esquema interno, como por ejemplo utilizar diferentes organizaciones de archivos o distintas estructuras de almacenamiento, utilizar diferentes dispositivos de almacenamiento, modificar índices o cambiar los algoritmo s de hash, sin tener que cambiar los esquemas conceptuales o externos. Desde el punto de vista de los usuarios, el único efecto que debe poder apreciarse es un cambio en las.prestaciones. De hecho, el deterioro de las prestaciones suele ser la razón más común para efectuar cambios en el esquema interno. La Figura 2.3 ilustra dónde se sitúa cada tipo de independencia de los datos en relación con la arquitectura de tres niveles.
Correspondencia externo/conceptual
Correspondencia conceptual/interno
Figura 2.3.
Independencia
Independencia física de los datos
de los datos en la arquitectura
de tres niveles ANSI-SPARC.
Capítulo 2 El entorno de la base de datos
37
La correspondencia en dos etapas que se efectúa en la arquitecturaANSI-SPARC puede ser poco eficiente, pero proporciona una mayor independencia de los datos. Sin embargo, si se quiere conseguir una asignación más eficiente, el modelo ANSI-SPARC permite establecer una correspondencia directa entre los esquemas externos y el esquema interno, evitando el esquema conceptual. Por supuesto, esto reduce la independencia de los datos, de modo que cada vez que se modifique el esquema interno puede ser necesario cambiar también algún esquema externo y los programas de aplicación que dependan del mismo.
2.2
Lenguajes de base de datos
Un sublenguaje de datos está compuesto de dos partes: un lenguaje de definición de datos (DDL, Data Definition Language) y un lenguaje de manipulación de datos (DML, Data Manipulation Language). El DDL se utiliza para especificar el esquema de la base de datos y el DML se emplea tanto para leer como para actualizar la base de datos. Estos lenguajes se denominan sublenguajes de datos, porque no incluyen las estructuras requeridas para todas las necesidades de computación, como por ejemplo instrucciones condicionales o iterativas, que son proporcionadas por los lenguajes de programación de alto nivel. Muchos SGBD tienen una funcionalidad para incrustar el sublenguaje en un lenguaje de programación de alto nivel tal como COBOL, Fortran, Pascal, Ada, C, C++, Java o Visual Basic. En este caso, el lenguaje de alto nivel se denomina en ocasiones lenguaje host. Para compilar el archivo incrustado, primero se eliminan del programa en lenguaje host las instrucciones en el sublenguaje de datos y se las sustituye por llamadas a función. A continuación se compila el archivo preprocesado, se lo coloca en un módulo objeto, se lo enlaza con una biblioteca específica del SGBD que contiene las funciones que se han utilizado para la sustitución y se ejecuta cada vez que sea requerido. La mayoría de los sublenguajes de datos proporcionan también instrucciones no incrustadas o interactivas, que pueden introducirse directamente desde un terminal.
2.2.1 DDL
El lenguaje de definición de datos (DDL) Un lenguaje que permite al DSA o al usuario describir y nombrar las entidades, atributos y relaciones requeridas por la aplicación, junto con cualquier restricción asociada de integridad y seguridad.
El esquema de la base de datos se especifica mediante un conjunto de definiciones expresadas por medio de un lenguaje especial denominado lenguaje de definición de datos (DDL). El DDL se utiliza para definir un esquema o para modificar uno ya existente. No puede emplearse para manipular los datos. El resultado de la compilación de las instrucciones DDL es un conjunto de tablas almacenado en archivos especiales a los que se les denomina, de modo colectivo, catálogo del sistema. El catálogo del sistema integra los metadatos, que son datos que describen los objetos contenidos en la base de datos y que hacen más fácil el acceso y la manipulación de dichos objetos. Los metadatos contienen definiciones de registros, de elementos de datos y de otros objetos que sean de interés para los usuarios o necesarios para el SGBD. El SGBD normalmente consulta el catálogo del sistema antes de acceder a los propios datos contenidos en la base de datos. También se utilizan los términos diccionario de datos y directorio de datos para referirse al catálogo del sistema, aunque el término 'diccionario de datos' se reserva usualmente para un sistema software más general de lo que pueda ser un catálogo para un SGBD. Hablaremos más en detalle del catálogo del sistema en la Sección 2.4. En un nivel teórico, podemos identificar diferentes lenguajes DDL para cada esquema en la arquitectura de tres niveles, es decir, un DDL para los esquemas externos, otro para el esquema conceptual y un tercer DDL para el esquema interno. Sin embargo, en la práctica, lo que suele existir es un único lenguaje DDL común que permite la especificación de al menos los esquemas externos y conceptuales.
2.2.2 DML
El lenguaje de manipulación de datos (DML) Un lenguaje que proporciona un conjunto de operadores para permitir las manipulaciones básicas de los datos contenidos en la base de datos.
38
Sistemas de bases de datos
Entre las operaciones de manipulación de datos podemos citar: •
la inserción de nuevos datos en la base de datos;
•
la modificación de los datos ya almacenados;
• •
la extracción de los datos contenidos en la base de datos; el borrado de datos de la base de datos.
Por tanto, una de las principales funciones del SGBD consiste en proporcionar un lenguaje de manipulación de datos mediante el cual pueda el usuario construir instrucciones que realicen el procesamiento necesario. Las operaciones de manipulación de datos se aplican tanto en el nivel externo como en los niveles conceptual e interno. Sin embargo, a nivel interno, debemos definir procedimientos de bajo nivel bastante complejos que nos permitan un acceso eficiente a los datos. Por contraste, en los niveles más altos, el énfasis se pone en la facilidad de uso, dirigiendo los esfuerzos a proporcionar una interacción eficiente entre el usuario y el sistema. La parte de un lenguaje DML relacionada con la extracción de datos se denomina lenguaje de consulta. Un lenguaje de consulta puede definirse como un lenguaje de propósito especial y alto nivel que se utiliza para satisfacer solicitudes diversas de extracción de los datos contenidos en la base de datos. Por tanto, el término 'consulta' se reserva para referirse a una instrucción de extracción expresada en un lenguaje de consulta. Comúnmente, los términos 'lenguaje de consulta' y DML se utilizan de modo indistinto, aunque esto no es correcto desde el punto de vista técnico. Los lenguajes DML se distinguen unos de otros por sus estructuras subyacentes de extracción de datos. Podemos distinguir entre dos tipos fundamentales de lenguaje DML: procedimental y no procedimental. La principal diferencia entre estos dos tipos de lenguaje de manipulación de datos es que los lenguajes procedimentales especifican cómo debe obtenerse la salida de una instrucción DML, mientras que los lenguajes no procedimentales describen únicamente cuál es la salida que hay que obtener. Normalmente, los lenguajes procedimentales manipulan los registros de forma individual, mientras que los lenguajes no procedimentales operan sobre conjuntos de registros.
Lenguajes DML procedimentales DML procedimental
Un lenguaje que permite al usuario decirle al sistema qué datos necesita y cuál es la forma exacta de extraerlos.
Con un lenguaje DML procedimental, el usuario, o más normalmente el programador, especifica qué datos necesita y el modo de obtenerlos. Esto quiere decir que el usuario debe expresar todas las operaciones de acceso a los datos que hay que utilizar, invocando los procedimientos apropiados para obtener la información requerida. Normalmente, este tipo de lenguaje DML procedimental extrae un registro, lo procesa y, dependiendo de los resultados del procesamiento, extrae otro registro para procesarlo de forma similar, y así sucesivamente. Este proceso de extracción continúa hasta que todos los datos solicitados han sido recopilados. Normalmente, los lenguajes DML procedimentales están incrustados en un lenguaje de programación de alto nivel que contiene estructuras para facilitar la iteración y gestionar la lógica de navegación. Los lenguajes DML de los sistemas en red y jerárquicos son, normalmente, de tipo procedimental (véase la Sección 2.3).
Lenguajes DML no procedimentales DML no procedimental
Un lenguaje que permite al usuario indicar qué datos necesita, en lugar de cómo hay que extraerlos.
Los lenguajes DML no procedimentales permiten especificar los datos requeridos en una única instrucción de extracción o actualización. Con un lenguaje no procedimental, el usuario especifica cuáles datos requiere, sin indicar el modo de obtenerlos. El SGBD traduce la instrucción DML a uno o más procedimientos que manipulan los conjuntos de registros requeridos. Esto libera al usuario de conocer cómo están implementadas internamente las estructuras de datos y qué algoritmo s se necesitan para extraer, y posiblemente transformar, dichos datos, lo que proporciona a los usuarios un considerable grado de independencia de los datos. Los len-
Capítulo 2 El entorno de la base de datos
39
guajes no procedimentales se denominan también lenguajes declarativos. Los SGBD relacionales suelen incluir algún tipo de lenguaje no procedimental para la manipulación de datos, normalmente SQL (Structured Query Language) o QBE (Query-By-Example, consulta mediante ejemplos). Los lenguajes DML no procedimentales son normalmente más fáciles de aprender y de utilizar que los lenguajes procedimentales, ya que el usuario hace menos trabajo y el SGBD se encarga de una parte mayor de la tarea. Examinaremos SQL en detalle en los Capítulos 5 y 6 y en el Apéndice E, mientras que hablaremos de QBE en el Capítulo 7.
2.2.3
Lenguajes de cuarta generación (4GL)
No existe consenso acerca de lo que constituye un lenguaje de cuarta generación; se trata, en esencia, de un lenguaje de programación optimizado. Una operación que requiera cientos de líneas de código en un leguaje de tercera generación (3GL), como Cobol, requiere generalmente un número mucho menor de líneas en un 4GL. Comparado con un 3GL, que es procedimental, un 4GL es no procedimental: el usuario define qué hay que hacer, no el modo de hacerlo. Lo normal es que un 4GL dependa de modo fundamental de componentes de mucho mayor nivel, conocidos con el nombre de herramientas de cuarta generación. El usuario no define los pasos que un programa debe seguir para llevar a cabo una tarea, sino que define una serie de parámetros para las herramientas, las cuales los usan para generar un programa de aplicación. La opinión generalizada es que los 4GL pueden mejorar la productividad en un factor de 10, aunque a cambio limitan los tipos de problemas que pueden abordarse. Los lenguajes de cuarta generación comprenden: •
lenguajes de presentación, como por ejemplo los lenguajes de consulta y los generadores de informes;
•
lenguajes especializados, como las hojas de cálculo y los lenguajes de base de datos;
•
generadores de aplicaciones que definen, insertan, actualizan y extraen datos de la base de datos para construir aplicaciones;
•
lenguajes de muy alto nivel que se emplean para generar códigos de aplicación.
SQL y QBE, que ya hemos mencionado anteriormente, son ejemplos de lenguajes 4GL. Vamos a hablar ahora brevemente de algunos de los otros tipos de 4GL.
Generadores de formularios Un generador de formularios es un programa interactivo para crear de forma rápida disposiciones de introducción y visualización de datos para formularios en pantalla. Los generadores de formularios permiten al usuario definir cuál debe ser el aspecto de la pantalla, qué información hay que mostrar y en qué parte de la pantalla mostrarla. También pueden permitir la definición de colores para los elementos de la pantalla y otras caracteristicas, como los atributos de negrita, subrayado, parpadeo, vídeo inverso, etc. Los generadores de formularios más avanzados permiten la creación de atributos derivados, posiblemente utilizando operadores aritméticos o de agregación, así como la especificación de comprobaciones de validez para los datos de entrada.
Generadores de informes Un generador de informes es un programa que permite crear informes a partir de los datos almacenados en la base de datos. Es similar a un lenguaje de consulta, en el sentido de que permite al usuario formular preguntas a la base de datos y extraer información de la misma para componer un informe. Sin embargo, en el caso de un generador de informes, se tiene un control mucho mayor sobre el aspecto de la salida. Se puede dejar que el generador de informes determine automáticamente cuál debe ser el aspecto de la salida, o pueden crearse informes de salida personalizados utilizando instrucciones especiales del generador de informes. Existen dos tipos principales de generador de informes: orientados al lenguaje y visual mente orientados. En el primer caso, se introduce una instrucción en un sublenguaje para definir los datos que hay que incluir en el informe y cómo deben disponerse los datos dentro del mismo. En el segundo caso, se utiliza un programa similar a un generador de formularios para definir la misma información.
40
Sistemas de bases de datos
Generadores gráficos Un generador gráfico es un programa que extrae datos de la base de datos y los muestra en forma de gráfico, para visual izar tendencias y relaciones entre los datos. Normalmente, permite al usuario crear gráficos de líneas, gráficos de sectores, gráficos de barras, gráficas de dispersión, etc.
Generadores de aplicaciones Un generador de aplicaciones es un programa que permite producir otros programas para comunicarse con la base de datos. Si se utiliza un generador de aplicaciones, puede reducirse el tiempo necesario para diseñar las aplicaciones software. Los generadores de aplicaciones normalmente están compuestos de una serie de módulos predefinidos que incluyen las funciones fundamentales utilizadas por la mayoría de los programas. Estos módulos, usualmente escritos en un lenguaje de alto nivel, constituyen una 'biblioteca' de funciones de entre la cual se pueden elegir las funciones deseadas. El usuario especifica qué tiene que hacer el programa y el generador de aplicaciones determina cómo llevar a cabo las tareas.
2.3
Modelos de datos y modelado conceptual
Ya hemos mencionado anteriormente que los esquemas se escriben utilizando un lenguaje de definición de datos. De hecho, se escriben en el lenguaje de definición de datos de un SGBD concreto. Desafortunadamente, este tipo de lenguaje tiene un nivel demasiado bajo como para describir los requisitos de datos de una organización de forma que sean fácilmente comprensibles por los diversos usuarios. Lo que nos hace falta es una descripción de mayor nivel de esquema, es decir, un modelo de datos. Modelo de datos
Una colección integrada de conceptos para describir y manipular datos, las relaciones existentes entre los mismos y las restricciones aplicables a los datos, todo ello dentro de una organización.
Un modelo es una representación de objetos y sucesos del 'mundo real', así como de sus asociaciones. Se trata de una abstracción que se concentra en los aspectos esenciales e inherentes de una organización e ignorar las propiedades accesorias. Un modelo de datos representa a la propia organización y debe proporcionar los conceptos básicos y las notaciones que permitan a los diseñadores de la base de datos y a los usuarios finales comunicar de forma precisa y no ambigua su comprensión de los datos de la organización. Podemos considerar que los modelos de datos comprenden tres componentes: (1) una parte estructural, compuesta por un conjunto de reglas que son las que definen cómo pueden construirse las bases de datos; (2) una parte manipulativa, que define los tipos de operaciones que pueden realizarse sobre los datos (esto incluye las operaciones empleadas para actualizar o extraer datos de la base de datos y para modificar la estructura de la base de datos); (3) posiblemente, un conjunto de restricciones de integridad, que garantiza la precisión de los datos. El propósito de un modelo de datos es representar los datos y hacer que sean comprensibles. Si lo consigue, se lo podrá utilizar con facilidad para diseñar una base de datos. Para reflejar la arquitectura ANSI-SPARC que hemos presentado en la Sección 2.1, podemos identificar tres modelos de datos relacionados: (1) un modelo de datos externo, para representar la vista que cada usuario tiene de la organización; este modelo de datos se denomina en ocasiones universo de discurso (UoD, Universe ofDiscourse); (2) un modelo de datos conceptual, para representar la vista lógica (o comunitaria), que es independiente del SGBD; (3) un modelo de datos interno, para representar el esquema conceptual de forma tal que pueda ser comprendido por el SGBD.
Capítulo 2 El entorno de la base de datos
41
En la literatura técnica se han propuesto numerosos modelos de datos, que podemos clasificar en tres categorías generales: basados en objetos, basados en registros y físicos. Los primeros dos se utilizan para describir los datos en los niveles conceptual y externo, mientras que el último se emplea para describir los datos en el nivel interno.
2.3.1
Modelos de datos basados en objetos
Los modelos de datos basados en objetos utilizan conceptos tales como entidades, atributos y relaciones. Una entidad es un objeto singular (una persona, lugar, cosa, concepto, suceso) dentro de la organización que hay que representar mediante una base de datos. Un atributo es una propiedad que describe algún aspecto del objeto suficientemente relevante como para registrarlo y una relación es una asociación entre entidades. Los tipos más comunes de modelos de datos basados en objetos son: • Entidad-Relación. •
Semántica
•
Funcional
•
Orientado a objetos.
El modelo Entidad-Relación se ha consolidado como una de las técnicas principales para el diseño de bases de datos y forman la base de la metodología de diseño de bases de datos utilizada en este libro. El modelo de datos orientado a objetos amplía la definición de entidad para incluir no sólo los atributos que describen el estado del objeto, sino también las acciones asociadas con el objeto, es decir, su comportamiento. En este caso, decimos que el objeto encapsula tanto el estado como el comportamiento. Analizaremos en detalle el modelo Entidad-Relación en los Capítulos 11 y 12, mientras que el modelo orientado a objetos será tratado en los Capítulos 25-28. También examinaremos el modelo de datos funcional en la Sección 26.1.2.
2.3.2
Modelos de datos basados en registros
En un modelo de datos basados en registros, la base de datos está compuesta por una serie de registros de formato fijo, posiblemente de tipos distintos. Cada tipo de registros define un número fijo de campos, cada uno de los cuales suele tener una longitud también f~a. Existen tres tipos principales de modelos lógicos de datos basados en registros: el modelo de datos relacional, el modelo de datos en red y el modelo de datos jerárquico. Los modelos de datos en red y jerárquico fueron desarrollados casi diez años antes que el modelo de datos relacional, por lo que su vinculación con los conceptos tradicionales de procesamiento de archivos resulta más evidente.
Modelo de datos relacional El modelo de datos relacional está basado en el concepto de relaciones matemáticas. En el modelo relacional, los datos y las relaciones se representan mediante tablas, cada una de las cuales tiene una serie de columnas con nombres distintivos. La Figura 2.4 muestra un ejemplo de esquema relacional para una parte del caso de estudio de DreamHome, donde se muestran los detalles correspondientes a las sucursales y a los empleados. Por ejemplo, muestra que el empleado lohn White es un gerente con un salario de 30.000 libras, que trabaja en la sucursal (branchNo) B005, la cual, si consultamos la primera tabla, está situada en 22 Deer Rd, en Londres. Es importante observar que existe una relación entre 8taff y Branch; una sucursal tiene una serie de empleados. Sin embargo, no existe ningún enlace explícito entre estas dos tablas; el enlace se basa en darse cuenta de que el atributo branchNo en la relación 8taff coincide con el atributo branchNo de la relación Branch; de este modo podemos establecer que existe una relación. Observe que el modelo de datos relacional sólo requiere que la base de datos sea percibida por el usuario como una serie de tablas. Sin embargo, esta percepción únicamente se aplica a la estructura lógica de la base de datos, es decir, a los niveles externo y conceptual de la arquitectura ANSI-SPARC. No se aplica a la estructura fisica de la base de datos, que podríamos implementar utilizando diversas estructuras de almacenamiento. Hablaremos del modelo de datos relacionales en el Capítulo 3.
42
Sistemas de bases de datos Sranch branchNo
32 163 London Bristol Manse Main Rd St NW10 BS991NZ 56 Clover 6EU Dr AB23SU street SW14EH 22 Deer Rd G119QX Glasgow postCode city 16Aberdeen Argyll St
B002 B004 B003 B007 B005
Staff staffNo24-Mar-58 DOS B005 Lee B007 Howe Brand Susan F 24000 1O-Nov-60 1-0ct-45 B003 B005 Ford Assistant White Beech Ann David 19000 8000 3-jun-40 19-Feb-709000 M 30000 12000 IName fName sex branchNo 13-jun-65 julie Mary ]ohn position Supervisor Manager salary
Figura 2.4.
Ejemplo de esquema relaciona!.
Modelo de datos en red En el modelo en red, los datos se representan como colecciones de registros, mientras que las relaciones se representan mediante conjuntos. Comparado con el modelo relacional, las relaciones están modeladas de forma explícita por los conjuntos, que se transforman en punteros a la hora de la implementación. Los registros se organizan como estructuras de grafos generalizados en las que los registros aparecen como nodos (también denominados segmentos) y los conjuntos como aristas del grafo. La Figura 2.5 ilustra una instancia de un esquema en red para el mismo conjunto de datos presentado en la Figura 2.4. El SGBD en red más popular es IDMS/R, de Computer Associates. El modelo de datos en red se analiza con más detalle en el sitio web del libro (véase la URL en el Prefacio).
Modelo de datos jerárquico El modelo jerárquico es un tipo restringido de modelo en red. De nuevo, los datos se representan como colecciones de registros, mientras que las relaciones se representan mediante conjuntos. Sin embargo, el modelo jerárquico sólo permite que cada nodo tenga un padre. Un modelo jerárquico puede representarse como un grafo en árbol, donde los registros aparecen como nodos (también denominados segmentos) y los conjuntos 22 Deer Rd
16 Argyll St 163 Main St
~
32 ManseRd
~
56 Clover Dr
Figura 2.5.
Una instancia de ejemplo de un esquema de red.
Capítulo 2 El entorno de la base de datos
Figura 2.6.
43
Una instancia de ejemplo de un esquema jerárquico.
aparecen como aristas. La Figura 2.6 ilustra un ejemplo de esquema jerárquico para el mismo conjunto de datos presentado en la Figura 2.4. El principal SGBD jerárquico es IMS de IBM, aunque IMS también proporciona características no jerárquicas. Hablaremos con más detalles del modelo de datos jerárquico. El modelo de datos jerárquico se analiza con más detalle en el sitio web del libro (véase la URL en el Prefacio). Los modelos de datos (lógicos) basados en registros se utilizan para especificar la estructura global de la base de datos y una descripción de más alto nivel de la implementación. Su principal desventaja radica en el hecho de que no proporcionan la funcionalidad adecuada para especificar explícitamente las restricciones aplicables a los datos, mientras que el modelo de datos basado en objetos carece de los mecanismos para la especificación de la estructura lógica pero proporciona una mayor sustancia semántica al permitir al usuario especificar las restricciones relativas a los datos. La mayoría de los sistemas comerciales modernos están basados en el paradigma relacional, mientras que los primeros sistemas de bases de datos estaban construidos a partir de los modelos de datos en red o jerárquico. Estos dos modelos requieren que el usuario tenga unos ciertos conocimientos de la base de datos fisica a la que se está accediendo, mientras que el modelo relacional proporciona un considerable grado de independencia de los datos. De este modo, mientras que los sistemas relacionales adoptan una técnica declarativa en lo que respecta al procesamiento de base de datos (es decir, especifican qué datos hay que extraer), los sistemas en red y jerárquicos adoptan una técnica navegacional (es decir, especifican cómo hay que extraer los datos).
2.3.3
Modelos de datos físicos
Los modelos de datos físicos describen cómo se almacenan los datos en la computadora, representando información tal como las estructuras de registro, el ordenamiento de los registros y las rutas de acceso. No hay tanto modelos físicos de datos como modelos lógicos, y los modelos fisicos más comunes son el modelo unificador y la memoria de marco.
2.3.4
Modelado conceptual
Al examinar la arquitectura en tres niveles, vemos que el esquema conceptual es el 'corazón' de la base de datos. Da soporte a todas las vistas externas y se apoya, a su vez, en el esquema interno. Sin embargo, el
44
Sistemas de bases de datos
esquema interno no es otra cosa que la implementación fisica del esquema conceptual. El esquema conceptual debe ser una representación completa y precisa de los requisitos de datos de la organizaciónt. Si no es así, parte de la información de la empresa estará representada de modo incorrecto, o no estará representada en absoluto, y tendremos dificultades para implementar de forma completa una o más de las vistas externas. El modelado conceptual, o diseño conceptual de la base de datos, es el proceso de construir un modelo del uso de la información dentro de una empresa, modelo que debe ser independiente de los detalles de implementación, como por ejemplo el SGBD de destino, los programas de aplicación, los lenguajes de programación o cualquier otro tipo de consideración fisica. Este modelo se denomina modelo de datos conceptual. Los modelos conceptuales también se suelen denominar modelos lógicos en la literatura técnica. Sin embargo, en este libro haremos la distinción entre modelos de datos lógicos y conceptuales. El modelo conceptual es independiente de todos los detalles de implementación, mientras que el modelo lógico presupone un conocimiento del modelo de datos subyacente en el SGBD de destino. En los Capítulos 15 y 16 presentaremos una metodología de diseño de bases de datos que comienza produciendo un modelo de datos conceptual, que posteriormente se refina para obtener un modelo lógico basado en el modelo de datos relaciona!. Hablaremos más en detalles del diseño de bases de datos en la Sección 9.6.
2.4
Funciones de un SGBD
En esta sección vamos a examinar los tipos de funciones y servicios que debe proporcionar un SGBD. Codd (1982) enumera ocho servicios que todo SGBD completo debe proporcionar, y nosotros hemos añadido, por nuestra parte, otros dos servicios que cabe razonablemente esperar que estén disponibles.
(1) Almacenamiento,
extracción y actualización
de datos
Un SGBD debe proporcionar a los usuarios la capacidad de almacenar, extraer y actualizar los datos de la base de datos. Ésta es la función fundamental de un SGBD. Teniendo en cuenta las explicaciones de la Sección 2.1, el SGBD debe claramente, al proporcionar esta funcionalidad, ocultar los detalles internos de implementación fisica (como por ejemplo la organización de archivos y las estructuras de almacenamiento), de modo que dichos detalles sean transparentes para el usuario.
(2) Un catálogo accesible por el usuario Un SGBD debe proporcionar un catálogo en el que se almacenen las descripciones datos y que sea accesible por parte de los usuarios.
de los elementos de
Una de las características clave de la arquitectura ANSI-SPARC es que incluye un catálogo integrado del sistema en el que se almacenan los datos acerca de los esquemas, usuarios, aplicaciones, etc. No sólo debe poder el SGBD acceder al catálogo, sino que también deben poder acceder los usuarios. Un catálogo del sistema, o diccionario de datos, es un repositorio de información que describe los datos contenidos en la base de datos, es decir, los 'datos acerca de los datos' o metadatos. La cantidad de información y la manera en que ésta se emplean varían de un SGBD a otro. Normalmente, el catálogo del sistema almacena: • •
los nombres, tipos y tamaños de los elementos de datos; los nombres de las relaciones;
•
las restricciones de integridad aplicables a los datos;
•
los nombres de los usuarios autorizados que tienen acceso a los datos;
•
los elementos de datos a los que cada usuario puede acceder y los tipos de acceso permitidos; por ejemplo, acceso de inserción, de actualización, de borrado o de lectura;
t Cuando hablemos de las organizaciones para referimos a las organizaciones
en el contexto del diseño de bases de datos, utilizaremos
de carácter comercial.
en ocasiones el término empresa
Capítulo 2 El entorno de la base de datos
45
•
los esquemas externos, conceptual e interno y las correspondencias se describe en la Sección 2.1.4;
entre los distintos esquemas, como
•
las estadísticas de uso, como las frecuencias de transacciones y el número de accesos realizados a los distintos objetos de la base de datos.
El catálogo del sistema es uno de los componentes fundamentales de un SGBD. Muchos de los componentes software que describiremos en la siguiente sección utilizan la información contenida en el catálogo del sistema. Entre las ventajas que proporciona disponer de uno de tales catálogos podemos citar: •
Se puede recopilar y almacenar de forma centralizada la información acerca de los datos. Esto ayuda a mantener el control sobre los datos, considerados como uno de los recursos empresariales.
•
Puede definirse el significado de los datos, lo que ayuda a otros usuarios a comprender el propósito de los datos.
•
Se simplifica la comunicación, al almacenarse significados exactos. El catálogo del sistema puede también identificar el usuario o usuarios que poseen o acceden a los datos.
•
Pueden identificarse la información redundante y las incoherencias más fácilmente, por estar los datos centralizados.
•
Puede mantenerse un registro de los cambios efectuados en la base de datos.
•
Puede determinarse el impacto de un cambio antes de implementarlo, ya que el catálogo del sistema almacena información de cada elemento de datos, de sus relaciones y de sus usuarios.
•
Pueden imponerse mecanismos de seguridad.
•
Puede garantizarse la integridad.
•
Puede proporcionarse información de auditoría.
Algunos autores realizan una distinción entre el catálogo del sistema y el directorio de datos, en cuyo caso definen el directorio de datos como un repositorio que almacena información relativa al lugar y al modo en que están almacenados los datos. ISO (International Organization for Standardization) ha adoptado un estándar para diccionario de datos denominado IRDS (Information Resource Dictionary System, sistema de diccionario para recursos de información; ISO 1990, 1993). IRDS es una herramienta software que puede utilizarse para controlar y documentar las fuentes de información dentro de una organización. Proporciona una definición de las tablas que comprenden el diccionario de datos y de las operaciones que pueden utilizarse para acceder a dichas tablas. En este libro, utilizamos el término 'catálogo del sistema' para referimos a toda la información de repositorio. En la Sección 21.4.1 hablaremos de otros tipos de información estadística almacenada en el catálogo del sistema y que se utiliza para optimizar las consultas.
(3) Soporte de transacciones Un SGBD debe proporcionar un mecanismo que garantice que se lleven a cabo todas las actualizaciones correspondientes a una determinada transacción, o que no se lleve a cabo ninguna.
Una transacción es una serie de acciones, llevadas a cabo por un único usuario o programa de aplicación y mediante las que se accede al contenido de la base de datos o se lo modifica. Por ejemplo, algunas transacciones simples para el caso de estudio de DreamHome serían añadir un nuevo empleado a la base de datos, actualizar el salario de un empleado o borrar un inmueble del registro. Un ejemplo más complicado podría ser borrar un empleado de la base de datos y reasignar los inmuebles que gestionaba dicho empleado a otro miembro de la plantilla. En este caso, hay que hacer en la base de datos más de un cambio. Si fallara la transacción durante la ejecución, por ejemplo debido a un fallo del hardware, la base de datos quedaría en un estado incoherente: algunos cambios habrían sido realizados y otros no. Como consecuencia, sería preciso deshacer los cambios realizados para devolver a la base de datos a un estado coherente. Hablaremos del soporte de transacciones en la Sección 20.1.
46
Sistemas de bases de datos
(4) Servicios de control de concurrencia Un SGSD debe proporcionar un mecanismo para garantizar que la base de datos se actualice correctamente cuando haya múltiples usuarios actualizando de manera concurrente la base de datos.
Uno de los principales objetivos a la hora de usar un SGBD es el de permitir que muchos usuarios accedan de forma concurrente a una serie de datos compartidos. El acceso concurrente es relativamente fácil si lo único que están haciendo es leer los datos, ya que no hay ninguna forma de que unos usuarios puedan interferir con otros. Sin embargo, cuando dos o más usuarios acceden simultáneamente a la base de datos y al menos uno de ellos está actualizando datos, pueden producirse interferencias que den como resultado incoherencias de algún tipo. Por ejemplo, considere dos transacciones TI y T2 que se estén ejecutando concurrentemente, como se ilustra en la Figura 2.7. TI está extrayendo la euros de una cuenta bancaria (cuyo saldo es balx) y T2 está depositando 100 euros en la misma cuenta. Si estas transacciones se ejecutaran en serie, una después de otra sin que se entremezclen las operaciones, el saldo final sería de 190 euros independientemente de cuál de las dos se ejecutara primero. Sin embargo, en este ejemplo, las transacciones TI y T2 dan comienzo de forma prácticamente simultánea y ambas leen un saldo igual a 100 euros. T2 incrementa entonces balx en 100 euros, lo que da un total de 200, y almacena el resultado actualizado en la base de datos. Mientras tanto, la transacción TI reduce su copia del valor balx en la euros, lo que da como resultado 90 euros, y almacena este valor en la base de datos, sobreescribiendo la actualización previa y 'perdiéndose', por tanto, 100 euros. El SGBD debe garantizar que, cuando haya múltiples usuarios acudiendo a la base de datos, no se produzcan interferencias de ningún tipo. Hablaremos de esta cuestión en detalle en la Sección 20.2.
(5) Servicios de recuperación Un SGSD debe proporcionar dañada de alguna forma.
un mecanismo
para recuperar la base de datos en caso de que ésta resulte
Cuando hablamos anteriormente del soporte de transacciones, hemos mencionado que si la transacción falla la base de datos debe ser devuelta a un estado coherente. Un fallo puede ser resultado de un problema de hardware, de un fallo del soporte físico de almacenamiento, de un error hardware o software que haga que el SGBD se detenga, o puede ser el resultado de que el usuario detecte un error durante la transacción y la aborte antes de que se complete. En cualquiera de estos casos, el SGBD debe proporcionar un mecanismo para devolver la base de datos a un estado coherente. Hablaremos de las cuestiones de recuperación de una base de datos en la Sección 20.3.
(6) Servicios de autorización Un SGSD debe proporcionar acceder a la base de datos.
un mecanismo
para garantizar
que sólo los usuarios autorizados
puedan
No resulta dificil imaginar situaciones en las que resulte conveniente impedir que algunos de los datos almacenados en la base de datos puedan ser vistos por todos sus usuarios. Por ejemplo, puede que queramos que sólo los gerentes de sucursal puedan ver la información salarial de los empleados, impidiendo a todos los usuarios que visualicen estos datos. Además, siempre conviene proteger la base de datos frente a accesos no Tiempo 100
read(balx) read(balx)
balx = balx + 100
100
balx = balx - 10
write(balx)
200 90
write(balx)
90
Figura 2.7.
El problema de la actualización
perdida.
Capítulo 2 El entorno de la base de datos
47
autorizados. El término seguridad hace referencia a la protección de la base de datos frente a accesos no autorizados, ya sean intencionados o accidentales. El SGBD debe proporcionar mecanismos que garanticen que los datos estén seguros. Hablaremos de las cuestiones de seguridad en el Capítulo 19.
(7) Soporte para la tramitación
de datos
Un SGSD debe poder integrarse con software de comunicaciones. La mayoría de los usuarios acceden a la base de datos desde estaciones de trabajo. Algunas veces, estas estaciones de trabajo están conectadas directamente a la computadora donde se ejecuta el SGBD, pero en otros casos se encuentran ubicadas en lugares remotos y se comunican con la computadora del SGBD a través de una red. En cualquiera de los dos casos, el SGBD recibe las solicitudes en forma de mensajes de comunicaciones y responde a ellas de forma similar. Todas estas transmisiones son gestionadas por un gestor de comunicaciones de datos (DCM, Data Communication Manager). Aunque el DCM no forma parte del SGBD, sí que es necesario que el SGBD sea capaz de integrarse con diversos DCM para que el sistema sea comercialmente viable. Incluso los SGBD para computadoras personales deben poder ejecutarse en una red de área local para poder establecer una base de datos centralizada que todos los usuarios puedan compartir, en lugar de tener una serie de bases de datos diferentes, una para cada usuario. Esto no quiere decir que la base de datos tenga que estar distribuida por la red, sino simplemente que los usuarios deben poder acceder a una base de datos centralizada desde una serie de ubicaciones remotas. Este tipo de topología se denomina procesamiento distribuido (véase la Sección 22.1.1).
(8) Servicios de integridad Un SGSD debe proporcionar un medio de garantizar que tanto los datos de la base de datos como los cambios efectuados en los mismos se adecuen a ciertas reglas. El concepto de integridad de una base de datos hace referencia a la corrección y coherencia de los datos almacenados: puede considerárselo como otro tipo de protección de la base de datos. Aunque la integridad está relacionada con la seguridad, sus implicaciones son más genéricas: la integridad está relacionada con la calidad de los propios datos. La integridad se suele expresar en términos de restricciones, que son reglas de coherencia que la base de datos no debe violar. Por ejemplo, podríamos especificar una restricción que dijera que ningún empleado puede gestionar más de 100 inmuebles al mismo tiempo. En este caso, lo que queremos es que el SGBD compruebe, cuando asignemos un inmueble a un empleado, que esta operación no hará que se exceda el límite impuesto, y que evite que la asignación del inmueble se produzca en caso de que el límite se haya alcanzado. Además de estos ocho servicios, también cabe razonablemente siguientes dos servicios adicionales.
(9) Servicios para mejorar la independencia
esperar que todo SGBD proporcione
los
de los datos
Un SGSD debe incluir funcionalidades para permitir que los programas sean independientes tura real de la base de datos.
de la estruc-
Ya hemos hablado del concepto de independencia de los datos en la Sección 2.1.5. La independencia de los datos se consigue normalmente mediante un mecanismo de vistas o subesquemas. La independencia física de los datos suele ser más fácil de lograr: suele haber diversos tipos de cambio que pueden realizarse en las características físicas de la base de datos sin afectar a las vistas. Sin embargo, conseguir una completa independencia lógica de los datos suele resultar más difícil. La adición de una nueva entidad, atributo o relación suele ser fácil de gestionar, pero su eliminación es más complicada. En algunos sistemas, se prohibe todo tipo de cambio de los componentes existentes en la estructura lógica.
(10) Servicios de utilidad Un SGSD debe proporcionar una serie de servicios de utilidad.
48
Sistemas de bases de datos
Los programas de utilidad ayudan al DBA a administrar la base de datos de forma efectiva. Algunas utilidades funcionan en el nivel externo y, consecuentemente, pueden ser creadas por el DBA. Otras utilidades trabajan en el nivel interno y sólo pueden ser proporcionadas por el fabricante del SGBD. Como ejemplos de utilidades de este último tipo podemos citar: •
facilidades de importación, para cargar la base de datos a partir de archivos sin estructura, y facilidades de exportación, para descargar la base de datos en dicho tipo de archivos;
•
facilidades de monitorización,
•
programas de análisis estadístico, para examinar las estadísticas de rendimiento o de uso;
•
facilidades de reorganización de índices, para reorganizar los índices y sus correspondientes mientos;
•
mecanismos de recolección y reasignación de memoria, para eliminar físicamente los registros borrados de los registros de almacenamiento, para consolidar el espacio liberado y para reasignarlo cada vez que sea necesano.
2.5
)
para controlar el uso y operación de la base de datos; desborda-
Componentes de un SGSD
Los SGBD son programas software altamente complejos y sofisticados que tratan de proporcionar los servicios que hemos explicado en la sección anterior. Resulta imposible generalizar la estructura de componentes de un SGBD, ya que varía enormemente de unos sistemas a otros. Sin embargo, resulta útil, a la hora de tratar de comprender los sistemas de bases de datos, intentar visualizar los componentes y las relaciones existentes entre ellos. En esta sección, vamos a presentar una posible arquitectura para un SGBD. Examinaremos la arquitectura completa del SGBD de Oracle en la Sección 8.2.2. Un SGBD está estructurado en diversos componentes software (o módulos), a cada uno de los cuales se le asigna una operación específica. Como hemos indicado anteriormente, algunas de las funciones del SGBD están soportadas por el sistema operativo subyacente. Sin embargo, el sistema operativo sólo proporciona servicios básicos y el SGBD debe diseñarse para funcionar por encima suyo. Por tanto, el diseño de un SGBD debe tener en consideración la interfaz entre el SGBD y el sistema operativo. En la Figura 2.8 se muestran los componentes software principales de un entorno SGBD. Este diagrama muestra cómo se comunica el SGBD con otros componentes software, como las consultas de usuario y los métodos de acceso (técnicas de gestión de archivos para el almacenamiento y extracción de registros de datos). En el Apéndice C se proporciona una panorámica de las organizaciones de archivo y de los métodos de acceso. El lector interesado en consultar un tratamiento del tema más completo puede acudir a los textos de Teorey y Fry (1982), Weiderhold (1983), Smith y Barnes (1987) y Ullman (1988). La Figura 2.8 muestra los siguientes componentes: •
Procesador de consultas. Se trata de uno de los componentes principales del SGBD, componente que se encarga de transformar las consultas en una serie de instrucciones de bajo nivel dirigidas al gestor de base de datos. Hablaremos del procesamiento de consultas en el Capítulo 21.
•
Gestor de base de datos (DM, Database Manager). El DM se comunica con las consultas enviadas por el usuario y con los programas de aplicación. El DM acepta las consultas y examina los esquemas externos y conceptual para determinar qué registros conceptuales se necesitan para satisfacer la solicitud. A continuación, el DM hace una llamada al gestor de archivos para satisfacer esa solicitud. Los componentes del DM se muestran en la Figura 2.9.
•
Gestor de archivos. El gestor de archivos manipula los archivos de almacenamiento subyacentes y gestiona la asignación del espacio de almacenamiento en disco. Establece y mantiene la lista de estructuras y de índices definidos en el esquema interno. Si se utilizan archivos hash, efectúa las llamadas a las funciones de hash para generar las direcciones de los registros. Sin embargo, el gestor de archivos no gestiona directamente la entrada y salidas físicas de los datos. En lugar de ello, pasa las solicitudes a los métodos de acceso apropiados, que son los que se encargan de leer o escribir los datos en el búfer del sistema (o caché).
Capítulo 2 El entorno de la base de datos
Programadores Programas de aplicación
Usuarios Consultas
49
DBA Esquema de base de datos
SGBD
Base de datos y
catálogo del sistema
Figura 2.8.
Componentes
principales de un SGBD.
•
Preprocesador DML Este módulo convierte las instrucciones DML integradas en un programa de aplicación en llamadas a estándar a funciones en el lenguaje host. El preprocesador DML debe interactuar con el procesador de consultas para generar el código apropiado.
•
Compilador DDL. El compilador DDL convierte las instrucciones DDL en una serie de tablas que contienen metadatos. Esta tablas se almacenan a continuación en el catálogo del sistema, mientras que la información de control se almacena en las cabeceras de los archivos de datos.
•
Gestor de catálogo. El gestor de catálogo gestiona el acceso al catálogo del sistema y se encarga de mantenerlo. El catálogo del sistema es utilizado por la mayoría de los componentes del SGBD.
Los principales componentes software del gestor de la base de datos son los siguientes: •
Control de autorización. Este módulo se encarga de comprobar que el usuario tiene las autorizaciones necesarias para llevar a cabo la operación requerida.
•
Procesador de comandos. Después de que el sistema compruebe que el usuario tiene autoridad para llevar a cabo la operación, se pasa el control al procesador de comandos.
•
Comprobador de integridad. Para las operaciones que modifiquen la base de datos, el comprobador de integridad se encarga de verificar que la operación solicitada satisface todas las restricciones de integridad necesarias (como por ejemplo las restricciones relativas a las claves).
•
Optimizador de consultas. Este módulo determina una estrategia óptima para la ejecución de las consultas. Hablaremos de la optimización de consultas en el Capitulo 2l.
•
Gestor de transacciones. Este módulo realiza el procesamiento recibe de las transacciones.
requerido para las operaciones que
50
Sistemas de bases de datos
Procesador de consultas
Comprobador de integridad
Gestor del búfer
Gestor de datos
Base de datos y
catálogo del sistema
Figura 2.9.
Componentes
de un gestor de base de datos.
•
Planificador. Este módulo es responsable de garantizar que las operaciones concurrentes en la base de datos puedan llevarse a cabo sin entrar en conflicto unas con otras. Controla el orden relativo en que se ejecutan las operaciones de las transacciones.
•
Gestor de recuperación. Este módulo garantiza que la base de datos permanezca en un estado coherente cuando se produzcan fallos. Es responsable de la confirmación y cancelación de transacciones.
•
Gestor de búfer. Este módulo es responsable de la transferencia de datos entre la memoria principal y el almacenamiento secundario, como por ejemplo los discos o las cintas. El gestor de recuperación y el gestor de búfer se denominan en ocasiones, conjuntamente, gestor de datos. El gestor de búfer a veces se denomina gestor de caché.
Hablaremos de los últimos cuatro módulos en el Capítulo 20. Además de los módulos anteriores, se requieren muchas otras estructuras de datos como parte de la implementación de nivel físico. Entre estas estructuras se incluyen los archivos de datos y de índices y el catálogo del sistema. Ha habido algún intento de estandarizar los SGBD, y el DAFTG (Database Architecture Framework Task Group, grupo de trabajo de arquitecturas de base de datos) propuso en 1986 un modelo de referencia. El propósito de este modelo de referencia era definir un marco de trabajo conceptual con el que dividir los intentos de estandarización en
Capítulo 2 El entorno de la base de datos una serie de partes manejables y mostrar, en un nivel muy genérico, cómo podrían interrelacionarse tintas partes.
51
esas dis-
2.6 Arquitecturas de SGBD multiusuario En esta sección vamos a examinar las arquitecturas que más comúnmente se utilizan para implementar sistemas de gestión de bases de datos multiusuario; las arquitecturas concretas que analizaremos son el teleprocesamiento, el servidor de archivos y el modelo cliente-servidor.
2.6.1
Teleprocesamiento
La arquitectura tradicional para los sistemas multiusuario era el teleprocesamiento, donde hay una computadora con una única unidad central de proceso (UCP) y una serie de terminales, como se ilustra en la Figura 2.10. Todo el procesamiento se lleva a cabo dentro de una misma computadora física. Los terminales de usuario son típicamente terminales (no inteligentes) incapaces de funcionar por sí mismos y que están conectados a la computadora central. Los terminales envían mensajes a través del subsistema de control de comunicaciones del sistema operativo hacia el programa de aplicación del usuario, que a su vez utiliza los servicios del SGBD. De la misma forma, el SGBD devuelve los mensajes al terminal de usuario por la misma vía. Desafortunadamente, esta arquitectura imponía una enorme carga de trabajo a la computadora central, que no sólo tenía que ejecutar los programas de aplicación y el SGBD, sino también llevar a cabo una gran cantidad de tareas por cuenta de los terminales (como por ejemplo formatear los datos para su visualización en pantalla). En los últimos años se han producido avances significativos en el desarrollo de computadoras personales de altas prestaciones y de redes informáticas. Ahora podemos identificar dentro del sector una tendencia bastante pronunciada hacia lo que se denomina downsizing, es decir, sustituir las caras computadoras de tipo mainframe por redes más baratas de computadora s personales que permiten conseguir los mismos resultados, o incluso mejores. Esta tendencia es la que dio lugar al surgimiento de las dos siguientes arquitecturas que vamos a analizar: el servidor de archivos y el modelo cliente-servidor.
2.6.2
Arquitectura de servidor de archivos
En un entorno de servidor de archivos, el procesamiento está distribuído por toda la red, que normalmente suele ser una red de área local (LAN, local area network). El servidor de archivos almacena los archivos que las aplicaciones y el SGBD necesitan. Sin embargo, las aplicaciones y el SGBD se ejecutan en cada estación de trabajo, solicitando los archivos al servidor de archivos cada vez que es necesario, como se ilustra en la Figura 2.11. De esta forma, el servidor de archivos actúa simplemente como una unidad de disco compartida. El SGBD de cada estación de trabajo envía las solicitudes al servidor de archivos para extraer todos los datos que necesita y que estén almacenados en disco. Esta técnica puede dar lugar a una gran cantidad de tráfico de
Figura 2.10.
Topología de teleprocesamiento.
52
Sistemas de bases de datos
Estaciónde trabajo2
Solicitudesde datos
Archivosdevueltos
Base de datos Servidorde archivos Figura 2.11.
Arquitectura de servidor de archivos.
red, lo que a su vez puede provocar problemas de rendimiento. Por ejemplo, considere el caso de un usuario que solicite los nombres de todos los empleados que trabajen en la oficina situada en 163 Main St. Podemos expresar esta solicitud en SQL (véase el Capítulo 5) de la forma siguiente: SELECT fName, IName FROM Branch b, Slaft s WHERE b.branchNo = s.branchNo AND b.slreel =
'163
MainSI';
Puesto que el servidor de archivos no tiene ningún conocimiento de SQL, el SGBD tiene que solicitar al servidor de archivos los archivos correspondientes a las relaciones Branch y Slaft, en lugar de solicitar simplemente los nombres de los empleados que satisfacen los criterios de la consulta. La arquitectura del servidor de archivos tiene, por tanto, tres desventajas principales: (l) Hay una gran cantidad de tráfico de red. (2) Se requiere una copia completa del SGBD en cada estación de trabajo. (3) El control de concurrencia, de recuperación y de integridad son más complejos, ya que puede haber múltiples SGBD accediendo a los mismos archivos.
2.6.3
Arquitectura cliente-servidor tradicional en dos niveles
Para resolver las desventajas de las dos primeras arquitecturas y adaptarse a los entorno s empresariales, crecientemente centralizados, se desarrolló la arquitectura cliente-servidor. El término cliente-servidor hace referencia a la forma en la que interactúan los componentes software para formar el sistema. Como el nombre sugiere, hay un proceso cliente que necesita algún recurso y un servidor que proporciona el recurso. No es obligatorio que el cliente y el servidor residan en ]a misma máquina; en ]a práctica, resulta bastante común situar e] servidor en una determinada ubicación dentro de una red de área loca] y los clientes en las ubicaciones restantes. La Figura 2. ]2 ilustra ]a arquitectura cliente-servidor y ]a Figura 2.13 muestra algunas posibles combinaciones de ]a topología cliente-servidor. Las aplicaciones empresariales con requisitos intensivos de datos están formadas por cuatro componentes principales: ]a base de datos, ]a lógica de transacciones, ]a lógica de negocios y de ]a aplicación de gestión de datos y ]a interfaz de usuarios. La arquitectura tradicional cliente-servidor en dos niveles proporciona una separación muy básica de estos componentes. El cliente (nivel 1) es principalmente responsable de la presentación de los datos al usuario, mientras que el servidor (nivel 2) es principalmente responsable de suministrar
Capítulo 2 El entorno de la base de datos
53
Cliente (a)
Servidor
Cliente 2
Servidor Cliente 2 (b)
Base de datos Servidor (con SGBD)
Cliente 3 (e)
Figura 2.12.
Arquitectura
cliente-servidor.
Figura 2.13. Topologias cliente-servidor alternativas: (a) un cliente, un servidor; (b) múltiples clientes, un servidor; (e) múltiples clientes, múltiples servidores.
servicios de datos al cliente, como se ilustra en la Figura 2.14. Los servicios de presentación gestionan las acciones relativas a la interfaz de usuario y la lógica principal de negocio y de las aplicaciones de tratamiento de datos. Los servicios de datos proporcionan una lógica limitada de las aplicaciones empresariales, normalmente las tareas de validación que el cliente no puede llevar a cabo debido a la falta de información y el acceso a los datos seleccionados, independientemente de dónde estén ubicados. Los datos pueden provenir de un SGBD relacional, de un SGBD objeto-relacional, de un SGBD orientado a objetos, de un SGBD heredado o de un sistema propietario de acceso a datos. Normalmente, el cliente se ejecuta en las plataformas de escritorio de los usuarios finales e interactúa con un servidor de base de datos centralizado a través de la red. Una interacción típica entre el cliente y el servidor sería la siguiente. El cliente acepta la solicitud del usuario, comprueba la sintaxis y genera solicitudes de base de datos en SQL o en otro lenguaje de base de datos que resulta apropiado para la lógica de la aplicación. A continuación, transmite el mensaje al servidor, espera la respuesta y formatea los resultados para el usuario final. El servidor acepta y procesa las solicitudes de base de datos y luego transmite los resultados al cliente. El procesamiento implica comprobar las autorizaciones, garantizar la integridad, mantener el catálogo del sistema y realizar el procesamiento de las consultas y actualizaciones. Además, también se proporcionan los mecanismos de control de concurrencia y de recuperación. Las operaciones de los clientes y servidores se resumen en la Tabla 2.1.
54
Sistemas de bases de datos
Primer nivel
Tareas
Cliente
• •
Interfaz de usuario Lógica principal de negocio y de procesamiento de datos
--------------------------~--------------------------------------------------------
Tareas
Segundo nivel Servidor de base de datos
Figura 2.14.
Arquitectura
•
Validaciones del lado del servidor
•
Acceso a base de datos
tradicional cliente-servidor
en dos niveles.
Este tipo de arquitectura tiene muchas ventajas, como por ejemplo: • Permite un acceso más universal a las bases de datos existentes. •
Mejores prestaciones: si los clientes y el servidor residen en computadoras distintas, las diferentes vep podrán procesar distintas aplicaciones en paralelo. También resulta más fácil optimizar la máquina servidora si su única tarea consiste en realizar el procesamiento relacionado con la base de datos.
•
Pueden reducirse los costes de hardware: sólo el servidor requiere el suficiente espacio de almacenamiento y la suficiente capacidad de proceso como para almacenar y gestionar la base de datos.
•
Se reducen los costes de comunicaciones: las aplicaciones llevan a cabo parte de las operaciones en el cliente y sólo envían a través de la red las solicitudes de acceso a la base de datos, con lo que se envían menos datos a través de la red.
•
Mayor coherencia: el servidor puede gestionar las comprobaciones de identidad, por lo que sólo es necesario definir y validar las restricciones en un único lugar, en lugar de hacer que cada programa de aplicación lleve a cabo sus propias comprobaciones.
•
Esta arquitectura puede ajustarse de forma bastante natural a la arquitectura de los sistemas abiertos. Tabla 2.1.
Resumen de funciones en un entorno cliente-servidor.
Cliente
Servidor
Gestiona la interfaz de usuario
Acepta y procesa las solicitudes de base de datos de los clientes
Acepta los comandos del usuario y comprueba su sintaxis Comprueba las autorizaciones Procesa la lógica de la aplicación
Garantiza que no se violen las restricciones de integridad
Genera solicitudes de base de datos y las transmite al servidor
Realiza el procesamiento de las consultas/actualizaciones y transmite la respuesta al cliente
Devuelve la respuesta al usuario
Mantiene el catálogo del sistema Permite un acceso concurrente a la base de datos Proporciona mecanismos de control de recuperación
Capítulo 2 El entorno de la base de datos
55
Algunos fabricantes de bases de datos han utilizado esta arquitectura para señalar que ofrecen capacidades de base de datos distribuida, lo que es una colección de múltiples bases de datos interrelacionadas lógicamente y distribuidas a lo largo de una red informática. Sin embargo, aunque la arquitectura cliente-servidor puede utilizarse para proporcionar un SGBD distribuído, no constituye por sí misma un SGBD distribuido. Hablaremos de los SGBD distribuidos en los Capítulos 22 y 23.
2.6.4
Arquitectura cliente-servidor en tres niveles
La necesidad de mejorar la escalabilidad de los sistemas empresariales hizo que se pusiera en cuestión este modelo tradicional cliente-servidor en dos niveles. A mediados de la década de 1990, a medida que las aplicaciones fueron creciendo en complejidad y debían poder implantarse en centenares o miles de clientes, el lado del cliente comenzó a mostrar síntomas de dos problemas que impedían conseguir una escalabilidad adecuada: •
Se utilizaban clientes 'complejos', lo que requería unos recursos considerables en la computadora del cliente para que éste pudiera ejecutarse de forma adecuada. Estos recursos incluían espacio de disco, memoria RAM y potencia de procesamiento de la UCP.
•
Las tareas de administración en el lado del cliente eran bastante significativas.
En 1995 apareció una nueva variación del modelo tradicional cliente-servidor en dos niveles, para intentar resolver los problemas de escalabilidad en las empresas. Esta nueva arquitectura proponía tres niveles, cada uno de los cuales puede ejecutarse en una plataforma distinta: (1) El nivel de interfaz de usuario, que se ejecuta en la computadora del usuario final (el cliente). (2) El nivel de lógica de negocio y procesamiento de datos. Este nivel intermedio se ejecuta en un servidor que a menudo se denomina servidor de aplicaciones. (3) Un SGBD, que almacena los datos requeridos por el nivel intermedio. Este nivel puede ejecutarse en un servidor independiente, denominado servidor de base de datos. Como ilustra la Figura 2.15, el cliente sólo es ahora responsable de la interfaz de usuario de la aplicación y, quizás, de realizar algún tipo de procesamiento lógico simple, como por ejemplo la validación de los datos de entrada, por lo que con esta arquitectura se dispone de lo que se denomina clientes 'simples'. La lógica de negocio principal de la aplicación reside ahora en su propio nivel, que se conecta físicamente al cliente y el servidor de base de datos a través de una red de área local (LAN) o de una red de área extensa (WAN, wide area network). Un mismo servidor de aplicaciones puede dar servicio a múltiples clientes. El diseño en tres niveles tiene muchas ventajas con respecto a los diseños tradicionales de dos niveles o de un nivel. Entre esas ventajas podemos citar: •
El hardware necesario es menos costoso, ya que los clientes son 'simples'.
•
El mantenimiento de las aplicaciones está centralizado, al transferirse la lógica de negocio desde las plataformas de los usuarios finales a un único servidor de aplicaciones. Esto elimina los problemas de distribución del software que tantos quebraderos proporcionan en el modelo tradicional cliente-servidor en dos niveles.
•
Al ser mayor la modularidad, resulta más sencillo modificar o sustituir uno de los niveles sin que los otros se vean afectados.
•
Resulta más fácil equilibrar la carga de procesamiento funciones de base de datos.
al separar la lógica principal de negocio de las
Otra ventaja adicional es que la arquitectura en tres niveles se adapta de forma bastante natural a los entornos web, en los que un explorador web actúa como cliente 'simple' y un servidor web actúa como servidor de aplicaciones. La arquitectura en tres niveles puede ampliarse a n niveles, añadiéndose los niveles adicionales para aumentar la flexibilidad y la escalabilidad. Por ejemplo, el nivel intermedio de la arquitectura en tres niveles puede partirse en dos, disponiéndose de un nivel para el servidor web y de otro para el servidor de aplicaciones.
56
Sistemas de bases de datos
Primer nivel
Tareas
Cliente
•
Interfaz de usuario
--------------------------~--------------------------------------------------------
Segundo nivel
Tareas
Servidor de aplicaciones
•
Lógica principal de negocio
•
Lógica de procesamiento de datos
Tercer nivel
Tareas
Servidor de base de datos
•
Validaciones de datos
•
Acceso a base de datos
o Figura 2.15.
Arquitectura en tres niveles.
Esta arquitectura en tres niveles ha demostrado ser más adecuada para algunos entornos, como la Internet y las intranets corporativas, en las que puede utilizarse un explorador web como cliente. También es una arquitectura de gran importancia para los monitores de procesamiento de transacciones, como se explica a continuación.
2.6.5
Monitores de procesamiento de transacciones
Monitor TPI
Un programa que controla la transferencia de datos entre clientes y servidores para proporcionar un entorno coherente, particularmente para el procesamiento de transacciones en línea (OLTP, online transaction processing).
Las aplicaciones complejas se suelen construir basándose en diversos gestores de recursos (como por ejemplo un SGBD, el sistema operativo, la interfaz de usuario y el software de mensajería). Un monitor de procesamiento de transacciones o monitor TP (Transaction Processing) es un componente middleware que proporciona acceso a los servicios de una serie de gestores de recursos y proporciona también una interfaz uniforme para los programadores que desarrollen software transaccional. El monitor TP constituye el nivel intermedio de una arquitectura en tres niveles, como se ilustra en la Figura 2.16. Los monitores TP proporcionan significativas ventajas, entre las que se incluyen: •
Encaminamiento de transacciones. El monitor TP puede incrementar la escalabilidad transacciones a sistemas SGBD específicos .
dirigiendo las
•
Gestión de transacciones distribuidas. El monitor TP puede gestionar transacciones que requieran acceder a datos almacenados en múltiples y posiblemente heterogéneo s SGBD. Por ejemplo, una cierta transacción puede requerir actualizar elementos de datos contenidos en un SGBD Oracle en el servidor 1, un SGBD Informix en el servidor 2 y un SGBD IMS en el servidor 3. Normalmente, los monitores TP controlan las transacciones utilizando el estándar X/Open DTP (Distributed Transaction
Capítulo 2 El entorno de la base de datos
57
D Solicitudes de servicio
Base de datos
D Base de datos
Clientes
Servidor de aplicaciones con monitor TP
Servidores de base de datos
Nivel 1
Nivel 2
Nivel 3
Figura 2.16.
Monitor de procesamiento de transacciones como nivel intermedio en una arquitectura cliente-servidor de tres niveles.
Processing, procesamiento distribuido de transacciones). Un SGBD que cumpla este estándar puede funcionar como gestor de recursos bajo control de un monitor TP que actúe como gestor de transacciones. Hablaremos de las transacciones distribuidas y del estándar DTP en los Capítulos 22 y 23. •
Equilibrado de carga. El monitor TP puede equilibrar las solicitudes de los clientes distribuyéndolas entre múltiples SGBD situados en una o más computadoras, dirigiendo en todo momento las solicitudes de servicio de los clientes al servidor que menos carga de procesamiento tenga asignada. Además, puede poner en marcha dinámica otros SGBD adicionales según sea necesario para conseguir las prestaciones deseadas.
•
Multiplexación. En entorno s con un gran número de usuarios, puede resultar difícil en ocasiones que todos los usuarios mantengan activa una sesión simultáneamente con el SGBD. En muchos casos, los usuarios no necesitan disponer de un acceso continuo al SGBD. En lugar de hacer que cada usuario se conecte al SGBD, el monitor BD puede establecer una serie de conexiones con el SGBD de la forma necesaria y multiplexar las solicitudes de los usuarios a través de estas conexiones. Esto permite que pueda acceder un mayor número de usuarios a los SGBD disponibles utilizando un número de conexiones mucho más pequeño, lo que implica un menor gasto de recursos.
•
Mejora de la fiabilidad. El monitor TP actúa como gestor de transacciones, llevando a cabo las acciones necesarias para mantener la coherencia de la base de datos, y actuando el SGBD como un gestor de recursos. Si el SGBD falla, el monitor TP puede ser capaz de reenviar la transacción a otro SGBD o puede retenerla hasta que el SGBD vuelva a estar disponible.
Los monitores TP suelen utilizarse en entornos que tengan un volumen muy alto de transacciones, en los que el monitor TP puede emplearse para descargar tareas de procesamiento del servidor SGBD. Como ejem· plos destacados de monitores TP podemos citar CICS y Encina de IBM (que se utilizan principalmente en IBM AIX o Windows NT y que ahora se incluyen en los productos IBM TXSeries) y Tuxedo de BEA Systems.
Resumen del capítulo •
La arquitectura de base de datos ANSI-SPARC utiliza tres niveles de abstracción: externo, conceptual e interno. El nivel externo está compuesto por las vistas que los usuarios tienen de la base de
58
Sistemas de bases de datos datos. El nivel conceptual es la vista comunitaria de la base de datos. Especifica el contenido de información de la base de datos completa, con independencia de las consideraciones relativas al almacenamiento. El nivel conceptual representa todas las entidades, sus atributos y sus relaciones, así como las restricciones aplicables a los datos y la información de seguridad e integridad. El nivel interno es la vista de la base de datos que tiene la computadora. Especifica cómo se representan los datos, cómo se secuencian los registros, qué índices y punteros existen, etc.
•
La correspondencia entre los niveles externo y conceptual transforma las solicitudes y resultados entre esos dos niveles. La correspondencia entre los niveles conceptual a interno transforma las solicitudes y resultados entres los niveles interno y conceptual de la base de datos.
•
Un esquema de base de datos es una descripción de la estructura de la base de datos. La independencia de los datos hace que cada nivel sea inmune a los cambios efectuados en los niveles inferiores. El concepto de independencia lógica de los datos hace referencia a la inmunidad de los esquemas externos con respecto a los cambios efectuados en el esquema conceptual. La independencia física de los datos hace referencia a la inmunidad del esquema conceptual frente a los cambios que se efectúen en el esquema interno.
•
Un sublenguaje de datos está compuesto de dos partes: un lenguaje de definición de datos (DDL, Data Definition Language) y un lenguaje de manipulación de datos (DML, Data Manipulation Language). El DDL se utiliza para especificar el esquema de la base de datos y el DML se emplea para consultar y actualizar la base de datos. La parte de un DML relacionada con la extracción de datos se denomina lenguaje de consulta.
•
Un modelo de datos es una colección de conceptos que pueden usarse para describir un conjunto de datos, las operaciones de manipulación de los mismos y una serie de restricciones de integridad aplicables a los datos. Los modelos de datos pueden c1asificarse en tres categorías amplias: modelos de datos basados en objetos, modelos de datos basados en registros y modelos de datos físicos. Los primeros dos se utilizan para describir los datos en los niveles conceptual y externo, mientras que el último se emplea para describir los datos en el nivel interno.
•
Los modelos de datos basados en objetos incluyen el modelo Entidad-Relación, el modelo semántico, el modelo funcional y el modelo orientado a objetos. Los modelos de datos basados en registros incluyen el modelo relacional, el modelo en red y el modelo jerárquico.
•
El modelado conceptual es el proceso de construir una arquitectura detallada para una base de datos que sea independiente de los detalles de implementación, como por ejemplo el SGBD de destino, los programas de aplicación, los lenguajes de programación o cualquier otra consideración física. El diseño del esquema conceptual es crítico para el éxito del sistema. Merece la pena invertir el tiempo y la energía necesarios para producir el mejor diseño conceptual posible.
•
Las funciones y servicios de un SGBD multiusuario incluyen el almacenamiento, extracción y actualización de los datos; un catálogo accesible por los usuarios; el soporte de transacciones; los servicios de control de concurrencia y recuperación; los servicios de autorización; el soporte para la comunicación de datos; los servicios de integridad; servicios para promover la independencia de los datos y servicios de utilidad.
•
El catálogo del sistema es uno de los componentes fundamentales de un SGBD. Contiene 'datos acerca de los datos' o metadatos. El catálogo debe ser accesible por los usuarios. El IRDS (Information Resource Dictionary System) es un estándar ISO que define una serie de métodos de acceso para diccionario de datos. Esto permite compartir los diccionarios y transferirlos de un sistema a otro.
•
El concepto de arquitectura cliente-servidor hace referencia a la forma en que los componentes software interactúan. Existe un proceso cliente que requiere algún tipo de recurso y un servidor que proporciona el recurso. En el modelo en dos niveles, el cliente gestiona ]a interfaz de usuario y la lógica de procesamiento del negocio y el servidor gestiona la funcionalidad de la base de datos. En el entorno web, el modelo tradicional en dos niveles ha sido sustituido por un modelo en tres niveles, compuesto por un modelo de interfaz de usuario (el cliente), un nivel de lógica de negocios y de proce-
Capítulo 2 El entorno de la base de datos samiento de datos (el servidor de aplicaciones) dos en máquinas distintas . •
59
y el SGBD (el servidor de base de datos), distribui-
Un monitor de procesamiento de transacciones (TP, Transaction Processing) es un programa que controla la transferencia de datos entre clientes y servidores para proporcionar un entorno coherente, particularmente para el procesamiento de transacciones en línea (OLTP). Entre las ventajas podemos citar el encaminamiento de transacciones, las transacciones distribuidas, el equilibrado de la carga de procesamiento, la multiplexación y una mayor fiabilidad.
Cuestiones de repaso 2.1.
Explique el concepto de independencia de los datos y explique su importancia en un entorno de base de datos.
2.2.
Para resolver la cuestión de la independencia de los datos, se propuso la arquitectura en tres niveles de ANSI-SPARC. Compare y contraste los tres niveles de este modelo.
2.3.
¿Qué es un modelo de datos? Indique y explique los tipos principales de modelos de datos.
2.4.
Explique la función y la importancia del modelado conceptual.
2.5.
Describa los tipos de servicios que cabe esperar que un SGBD multiusuario proporcione.
2.6.
De las distintas funciones descritas en respuesta a la Cuestión 2.5, ¿cuáles cree que no serían necesarias en un SGBD autónomo para PC? Justifique su respuesta.
2.7.
Explique la función y la importancia del catálogo del sistema.
2.8.
Describa los componentes principales de un SGBD e indique qué componentes podrían ser responsables de cada uno de los servicios identificados en la Cuestión 2.5.
2.9.
¿Qué quiere decir el término 'arquitectura cliente-servidor' y cuáles son las ventajas de este enfoque? Compare la arquitectura cliente-servidor con las otras dos arquitecturas.
2.10. Compare la arquitectura cliente-servidor en dos niveles para un SGBD tradicional con la arquitectura cliente-servidor en tres niveles. ¿Por qué resulta esta última arquitectura más apropiada para la Web? 2.11. ¿Qué es un monitor TP? ¿Qué ventajas aporta un monitor TP a un entorno OLTP?
Ejercicios 2.12. Analice los SGBD que esté utilizando actualmente. Determine hasta qué punto proporciona cada uno de los sistemas las funciones que cabe esperar de un SGBD. ¿Qué tipo de lenguaje proporciona cada sistema? ¿Qué tipo de arquitectura utiliza cada SGBD? Compruebe la accesibilidad y la facilidad de ampliación del catálogo del sistema. ¿Es posible exportar el catálogo del sistema a otro sistema? 2.13. Escriba un programa que almacene nombres y números telefónicos en una base de datos. Escriba otro programa que almacene nombres y direcciones en una base de datos. Modifique los programas para utilizar esquemas externos, un esquema conceptual y un esquema interno. ¿Cuáles son las ventajas y desventajas de esta modificación? 2.14. Escriba un programa que almacene nombres y fechas de nacimiento en una base de datos. Amplíe el programa para que almacene el formato de los datos en la base de datos; en otras palabras, cree un catálogo del sistema. Proporcione una interfaz que haga que este catálogo del sistema sea accesible por los usuarios externos. 2.15.
Cómo modificaría el programa del Ejercicio 2.13 para adaptarlo a una arquitectura cliente-servidor. ¿Cuáles son las ventajas y desventajas de esta modificación?
El modelo lenguaj es
Gapítulo 3 lntroducción a las bases de datos Gapítulo 4 Álgebra relacional y cálculo relacional Gapítulo 5 SOL: manipulación de datos Gapítulo 6 SOL: definición de datos Gapítulo 7 OBE Gapítulo 8 Bases de datos comerciales: Off¡ce Access y Oracle
los
a\
El modelo relacional
Objetivos del capítulo: En este capítulo aprenderemos:
I I I I I I r I
Los orígenes del modelo relacional. La terminología del modelo relacional. Cómo se utilizan las tablas pata representar datos. La conexión entre las relaciones matemáticas y las relaciones usadas en el modelo relacional. Las propiedades de las relaciones de bases de datos.
Cómo identificar claves candidatas, principales, altemativas y externas.
El significado de la integridad de las entidades y de la entidad referencial. El propósito y las ventajas de las vistas en los sistemas relacionales.
Los sistemas de gestión de bases de datos relacionales (SGBDR) se han convertido en el software de procesamiento de datos de uso más dominante en la actualidad, con una estimación de nuevas ventas en licencias de entre 6.000 y 10.000 millones de dólares por año (25.000 millones de dólares si incluimos las ventas de herramientas). Este tipo de software representa la segunda generación de sistemas SGBD y está basado en el modelo de datos relacional propuesto por E. F. Codd (1970). En el modelo relacional, todos los datos están estructurados desde el punto de vista lógico mediante relaciones (tablas). Cada relación tiene un nombre y está compuesta de atributos (columnas) nominados de datos. Cada tupla (fila) contiene un valor por cada atributo. Una de las mayores forta"lezas del modelo relacional es esta estructura lógica simple. Sin embargo, por debajo de esta estructura simple se encuentra una base teórica muy sólida que se echaba en falta en la primera generación de sistemas de gestión de bases de datos (los SGBD en red y jerárquicos). Vamos a dedicar una parte sustancial de este libro a los SGBDR, como corresponde a la importancia de estos sistemas. En este capítulo, hablaremos de la terminología y de los conceptos estructurales básicos del modelo de datos relacional. En el siguiente capítulo, examinaremos los lenguajes relacionales que pueden utilizarse parala acfualización y extracción de datos.
Estructura del capítulo Para poner en perspectiva nuesho tratamiento de los SGBDR, en la Sección 3.1 proporcionamos una breve historia del modelo relacional. En la Sección 3.2 se explican los conceptos subyacentes en la terminología del modelo relacional. En la Sección 3.3 hablaremos de las reglas de integridad relacionales, incluyendo la integridad de entidades y la integridad referencial. En la Sección 3.4 se presentará el concepto de vistas, que constituyen una de las características más importantes de los SGBD relacionales aunque, estrictamente hablando, no se trata de un concepto del modelo relacioralper se.
Sistemas de bases de datos
64
Por adelantar un poco los acontecimientos, en los Capítulos 5 y 6 examinaremos SQL (Structure Query Language), el lenguaje estándar formal y de facto para los SGBDR y en el Capítulo 7 aralizaremos QBE (Query-By-Example), otro lenguaje de consulta visual muy popular para los SGBDR. En los Capítulos 15-18 presentaremos una rnetodología completa para el diseño de bases de datos relacionales. En el Apéndice D se examinan las doce reglas de Codd, que forman un rnarco que permite identificar los productos SGBDR. Los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome, qve se describe en detalle en la Sección 10.4 y en el Apéndice A.
3.1 Breve historia del modelo relacional El modelo relacional fue propuesto en primer lugar por E. F. Codd en su artículo original titulado 'A relational model of datafor large shared data banks'(Codd, 1970). Este artículo se acepta ahora generalmente como uno de los hitos principales en los sistemas de bases de datos, ar¡nque anteriormente se había propuesto un modelo orientado a conjuntos (Childs, 1968). Los objetivos especificados del modelo relacional eran:
I
I
I
Permitir un alto grado de independencia de los datos. Los programas de aplicación no deben verse afectados por las modificaciones efectuadas en la representación interna de los datos, y en particular por los cambios efectuados en Ia organización de los archivos, en la ordenación de los registros o en
PC, aunque muchos d
plos de SGBDR
basa
JDataStore de Borlanc Debido a la popul¿ interfaz de usuario re Associates, el principz cional de los datos. Ol
Cornputer Corporatior También se han prr
I I r
capturar de fon soportar concel
soportar capact
las rutas de acceso.
Proporcionar una base teórica sólida que permitiera tratar con la semántica de los datos y con los problemas de coherencia y de redundancia. En particular, el artícu.lo de Codd introducía el concepto de relaciones normalizadas, es decir, relaciones en las que no haya grupos repetidos (el proceso de normalización se explica en los Capítulos 13 y 14).
3.2 Termin,
Pennitir la ampliación de lenguajes de manipulación de datos orientados a conjuntos.
Aunque el interés en el modelo relacional se manifestó desde múltiples direcciones, la investigación rnás
cipales:
I
Los sistemas come de 1970 y principios r
Hablaremos de alg de objetos.
significativa puede atribuirse a tres proyectos que tenían perspectivas bastante distintas. El primero de éstos, en el laboratorio San Jose Research Laboratory de IBM, en California, fue el SGBD relacional prototipo System R, que fue desarrollado a ñnales de la década de 1970 (Astrahan et al.,1976). Este proyecto se llevó a cabo para demostrar la posibilidad de implementar el modelo relacional, desarrollando un ejeurplo de sus estructuras de datos de operaciones. También demostró ser una fuente excelente de información acerca de problemas de implementación tales como la gestión de transacciones, el control de concurrencia, las técnicas de recuperación,la optimización de consultas, los problemas de seguridad e integridad de los datos, los factores humanos y las interfaces de usuario, y condujo a la publicación de muchos artículos de investigación en el desarrollo de otros prototipos. En particular, el proyecto Systern R condujo a dos desarrollos prin-
r
yectosSystemRelN( procesamiento y optin
el desarrollo de un lenguaje de consulta estructurado denominado SQL, que desde entonces se ha convertido en el lenguaje estándar formal de ISO (International Organization for Standardization) y en el lenguaje estándar defacto para los SGBD relacionales;
el desarrollo de varios productos comerciales de SGBD relacional a finales de la década de 1970 y principios de la de 1980, como por ejemplo DB2 y SQLiDS de IBM y Oracle de Oracle Corporation.
El segundo proyecto de importancia en el desarrollo del modelo relacional fue INGRES (Interactive Graphics Retrieval System, sistema gráfico interactivo de extracción) en la Universidad de Califomia en Berkeley, que más o menos se desarrolló al mismo tiempo que el proyecto System R. El proyecto INGRES implicaba el desarrollo de un prototipo de SGBDR, concentrándose en la investigación en los mismos objetivos globales que el proyecto System R. Estas investigaciones condujeron a una versión académica de INGRES que contribuyó a la popularización de los conceptos relacionales y dio como resultado los productos comerciales INGRES de Relational Technology lnc. (ahora Advantage Ingres Enterprise Relational Database de Computer Associates) e Intelligent Database Machine de Britton Lee lnc. El tercer proyecto fue el denominado Peterlee Relational Test Vehicle en el laboratorio del IBM Scientific Centre en Peterlee, Reino Unido (Todd, 1976). Este proyecto tenía una orientación más teórica que los pro-
El modelo relacional e forma de una tabla. ( matemáticas, principal explicar la terminolog
3.2.1 Estruc Relación
Una
Un SGBDR requiere Observe, sin embargo
a los niveles externo ) a la estructura física d de almacenamiento (u
Atributo
Un
¿
En el modelo relac
huy que representar er las filas de latabla cor Los atributos pueden a tiendo por tanto el mis
Por ejemplo, la inl para los atributos bran,
lorma similar, la infon los atributos staffNo (e1 DOB (fecha de nacimie ,Jo). La Figura 3.1 rlur columna contiene los I ros de sucursales exist
Capítulo tre Query mos QBE los 15-18 rdice D se BDR. Los :talle en la
',4 relatioLente
como
:puesto un raIl:
eben verse r particular Irstros o en
3
El modelo relacional
65
yectos System R e INGRES y su principal importancia radica en la investigación en cuestiones tales como el procesamiento y optimización de consultas y Ia ampliación funcional. Los sistemas comerciales basados en el modelo relacional comenzaron a aparccff a finales de la década de 1970 y principios de la de 1980. Ahora hay centenares de SGBDR para entomos tanto mainframe como PC, aunque muchos de ellos no se adhieren estrictamente a la definición del modelo relacional. Como ejemplos de SGBDR basado en PC podemos citar Office Access y Visual FoxPro de Microsoft, InterBase y JDataStore de Borland y R:Base de R:BASE Technologies. Debido a la popularidad del modelo relacional, muchos sistemas no relacionales proporcionan ahora una ínferfaz de usuario relacional, independientemente de cuál sea su modelo subyacente. IDMS de Computer Associates, el principal SGBD en red, se ha convertido en Advantage CA-IDMS, que soporta una vista relacional de los datos. Otros SGBD para mainframe que soportan características relacionales son Model 204 de Computer Corporation of America y ADABAS de Software AG. También se han propuesto algunas extensiones del modelo relacional, como por ejemplo extensiones para:
I I I
capturar de forma más precisa el significado de los datos (por ejemplo, Codd, 1979); soportar conceptos de orientación a objetos (por ejemplo, Stonebrakery Rowe, 1986); soportar capacidades deductivas (por ejemplo, Gardarin y Valduriez, 1989).
Hablaremos de algunas de estas extensiones en los Capítulos 25-28, cuando tratemos el tema de los SGBD de objetos.
:on los pro:oncepto de eso cle nor-
gación más ro de éstos, rl prototipo cto se llevó
nplo de
sus
n acerca de t, las técnis datos, los
r investigarollos prin; se ha conion) y en el
3.2 Terminología El modelo relacional está basado en el concepto matemático de relación, la cual se representa fisicamente en forma de una tabla. Codd, que tenía formación matemática, utilizó terminología sacada del campo de las matemáticas, principalmente de la teoría de conjuntos y de la lógica de predicados. En esta sección vamos a explicar la terminología y los conceptos estructurales del modelo relacional.
3.2.1 Estructuras de datos relac¡onales Relación
Una relación es una tabla con columnas y filas.
Un SGBDR requiere sólo que la base de datos sea percibida por el usuario como una serie de tablas. Observe, sin embargo, que esta percepción sólo se aplica a la estructura lógica de la base de datos, es decir, a los niveles externo y conceptual de la arquitectura ANSI-SPARC expuesta en la Sección 2.1. No se aplica a la estructura fisica de la base de datos, que puede implementarse utilizando una diversidad de estructuras de almacenamiento (véase el Apéndice C).
Atributo
Un atributo es una columna nominada de una relación.
4 Scientific
En el modelo relacional, las relaciones se utilizan para almacenar información acerca de los objetos que hay que representar en la base de datos. Una relación se representa como una tabla bidimensional en la que las filas de la tabla corresponden a registros individuales y las columnas de la tabla corresponden a atributos. Los atributos pueden aparecer en cualquier orden y la relación continuará siendo exactamente igual, transmitiendo por tanto el mismo significado. Por ejemplo, la información sobre las sucursales está representada por la relación Branch, con columnas para los atributos branchNo (el número de sucursal), street (calle), city (ciudad) y postcode (código postal). De forma similar, la información sobre los empleados está representada por la relación Staff, con columnas para los atributos staffNo (el número de empleado), fName (nombre), lName (apellido), position (puesto), sex (sexo) ooa (fecha de nacimiento), salary (salario) y branchNo (el número de la sucursal en la que trabaja el empleado). La Figura 3.1 muestra instancias de las relaciones Branch y Staff. Como puede ver en este ejemplo, cada columna contiene los valores de un único atributo; por ejemplo, las columnas branchNo contienen sóIo núme-
¡ue los pro-
ros de sucursales existentes.
de 1970 y o{poratron.
'Interactive
rlifornia
en
o INGRES rros objeti-
démica de producRelational
.os
66
Sistemas de bases de datos {
Atributos
(
I
I
branch No C
22 Deer Rd
rO C)
16
(ú
o
Argyll
St
163 Main St
É.
London
Aberdeen AB2 3SU
G
l 9QX
o
Gl
Glasgow
Bristol 56 Clover Dr London 32 Manse Rd
BS99
T
o(ú p
SWl 4EH
(ú
lNZ
()
NW1O 6EU
Clave principal
Clave externa
t I
t lName
salary
C
Manager
1-
Oct- 45
'6
Assistant
10
-Nov- 60
Supervisor
24-Mar-58
Assistant
19-Feb-70
Manager
3-Iun- 40
Assistant
l3-Jun-65
rQ (ú
o
É,
¡ t
t I
Figura Dominio
3.1.
lnstancias de las relaciones Branch y Staff.
Un dominio es un conjunto de valores permitidos para uno o más atributos.
Los dominios son una característica extremadamente potente del modelo relacional. Cada atributo de una relación está definido sobre un dominio. Los dominios pueden ser diferentes para caü atributo o puede haber dos o más atributos definidos sobre el mismo dominio. La Figura 3.2 muestra los dominios para algunos de los atributos de las relaciones Branch y Staff. Observe que, en cualquier instante determinado, habrá normalmente valores en un dominio que no aparczcan actualmente como valores del atributo correspondiente. El concepto de dominio es impofante porque permite al usuario definir en un lugar central el significado y el origen de los valores que los atributos pueden adoptar. Como resultado, el sistema tiene a su disposición a la hora de ejecutar una operación relacional mucha más información, pudiendo evitarse las operaciones que sean semánticamente incorrectas. Por ejemplo, no resulta lógico comparar el nombre de ura calle con un número telefónico, aunque la definición del dominio de ambos atributos sea el conjunto de las cadenas de Atributo
Nombre de dominio
Significado
Definición del dominio
branchNo
Números de sucursal
Conjunto de todos los posibles
carácfer: tamaño 4, rango B001-8999
números de sucursal street
Nombres de calle
Conjunto de todos los nombres de
carácteri tamaño 25
calles en Gran Bretaña
crty
Nombres de ciudad
Conjunto de todos los nombres de
carác[er: tamaño 15
ciudad en Gran Bretaña postcode
Códigos postales
Conjunto de todos los códigos
carácter: tamaño
8
l, valor M o F
postales en Gran Bretaña sex
Sexo
Sexo de la persona
carácter: tamaño
DOB
Fechas de nacimiento
Posibles fechas de nacimiento de
fecha, rango desde el I -Enero-2},
salary
Salarios
Posibles salarios de un empleado
un empleado
Figura
3.2.
formato dd-mrnm-yy nronetario: 7 dígitos, rango 6000,00-40000,00
Dominios para algunos atributos de las relaciones Branch y Staff.
t I
I
-l--:.-teres. Por otro lado, el alquiler mensual de un inmueble y el número de meses que un inmueble ha esta1,. ..quilado tienen diferentes dominios (el primero es un valor monetario, mientras que el segundo es un valor ::.:ro), aunque continua siendo una operación legal multiplicar dos valores extraídos de estos dos dominios. -- -:ro ilustran estos dos ejemplos, una implementación completa de concepto de dominios no resulta sencilla iLrmo resultado, muchos SGBDR no soportan este concepto plenamente. Tupla
Una tupla es una fila de una relación.
Los elementos de una relación son las filas o tuplas de la tabla. En la relación Branch, cada fila contiene ;uatro valores, uno para cada atributo. Las tuplas pueden aparecer en cualquier orden y la relación continua:e siendo la misma y transmitirá, por tanto, el mismo significado. La estructura de una relación, junto con una especificación de los dominios y cualesquiera restricciones sobre los posibles valores se denomina en ocasiones intensión de la relación; la intensión suele estar fija, a menos que se cambie el significado de una relación para incluir atributos adicionales, Las tuplas se denominan extensión (o estado) de una relación; la extensión cambia a lo largo del tiempo. Grado
EI grado de una relación es el número de atributos que cont¡ene.
La relación Branch de la Figura 3.1 tiene cuaffo affibutos, por lo que su grado es igual a cuatro. Esto significa que cada flrla de la tabla es una tupla formada por cuatro columnas y que contiene cuatro valores. Una relación con un único atributo tendrá grado uno y se denominará relación unaria. Una relación con dos atributos se denomina binaria y una de tres atributos, ternaria; por encima de tres, se suele utilizar el término n-tria. El grado de una relación es una propiedad de la intensión de la relación.
Cardinalidad
e una
raber cs de
lnal-
La cardinalidad de una relación es el número de tuplas que cont¡ene.
Por contraste, el número de tuplas se denomina cardinalidad de la relación; la cardinalidad cambia a medida que se añaden o se borran tuplas. La cardinalidad es una propiedad de la extensión de la relación y está determinada a partir de la instancia concreta de la relación en cualquier momento determinado. Finalmente, tenemos la definición de base de datos relacional. Base de datos
relacional
Una colección de relaciones normalizadas en la que cada relación tiene un nombre distintivo.
cado
ición
i qLre
nun us de
Una base de datos relacional está compuesta de relaciones apropiadamente estructuradas. Para referimos a que la estructura de las relaciones sea apropiada utilizamos el término normalización. Por el momento, vamos a diferir la explicación de la normalizacíón hasta los Capítulos 13-14.
Terminología alternativa La terminología del modelo relacional puede ser bastante confusa. Hemos presentado dos conjuntos de términos, pero en ocasiones se utiliza también un tercer conjunto: una relación puede denominarse archivo, las
tuplas pueden llamarse registros y los atributos pueden denominarse también campos. Esta terminología surge del hecho de que, fisicamente, el SGBDR puede almacenar cada relación en un archivo distinto. La Tabla 3.1 resume los diferentes términos para el modelo relacional. Tabla
3.1.
Terminologías alternat¡vas para el modelo relacional.
Términos formales
Alternativa
Relación
Tabla
Archivo
Tupla
Fila
Registro
Atributo
Columna
Campo
1
Alternativa 2
Sistemas de bases de datos
3.2.2
Relaciones matemáticas
Se
r¡n
Para entender el verdadero signiñcado del término relación, tenemos que revisar algunos conceptos tomados del campo de las matemáticas. Suponga que tenemos dos conjuntos Di y Dr, donde D, : {2,4} y or: {1,3, 5). El producto cartesiano de estos dos conjuntos, escrito D1 x D2, es el conjunto de todas las parejas ordenadas tales que el primer elemento de la pareja es un miembro de D., y el segundo elemento es un miembro de Dr. Una forma altemativa de expresar esto consiste en hallar todas las combinaciones de elementos que pueden formarse tomando el primero de D. y el segundo de Dr. En nuestro caso, tenemos: D1 x D2 :
:
{(2,1), (2, 3), (2,5), (4,1), (4,3), (4, 5)}
{(2,1), (4, l)}
{l
C 'cl¡fm(
de
la
r¡na r
E
to ca elem
nio f {
(x,y)lx e Drl e D,ey: l}
om¿
Utilizando estos mismos conjuntos, podremos formar otra relación S en la que el primer elemento
sea
siempre igual a dos veces el segundo. Así, podríamos expresar S como:
s: {(x,y)lxe D.,,ye Dzyx=2y\
I 1
bir t
o, en este caso,
s:
{t
oom(
Podemos especificar qué parejas ordenadas formar¿ln una relación indicando alguna condición de selección. Por ejemplo, si observamos que R inc§e todas las parejas ordenadas en las que el segundo elemento es uno, podríamos escribir R como:
n:
nes.d(
üoma
Cualquier subconjunto de este producto cartesiano será una relación. Por ejemplo, podemos definir una relación R tal que: R
e§(
cal
rela
{(2, 1)}
ya que sólo hay una pareja ordenada en el producto cartesiano que satisfaga esta condición. Podemos ampliar fácilmente la noción de relación a tres conjuntos. Sean D¡, Dzy D. tres conjuntos cualesquiera. El producto cartesiano D1 x D2 x Ds de estos tres conjuntos es el conjunto de todas las tripletas ordenadas tales que el primer elemento esté tomado de D., el segundo elemento de Dry el tercer elemento de D.. Cualquier subconjunto de este producto cartesiano sea ufia relación. Por ejemplo, suponga que tenemos: D1
_ {1,3}
D1x
D2
X
Dz
:
{2, 4}
Ds
:
{5, 6}
D.: {(1,2,5),(1,2,6),(1,4,5),(1,4,6),(3,2,5),(3,26),(3,4,5),(3,4,6)}
Cualquier subconjunto de esta serie de hipletas ordenadas será una relación. Podemos ampliar el número de conjuntos y decidir una relación general sobre z dominios. Sean D.,, Dr, . . ., D, n conjuntos. Su producto cartesiano se define como: D1
)(D2X...X D,: {(dr,dr,...,4)14€
D1,d2e
Ur
Dr,...,d,eD,\
y usualmente se denota mediante: Í,D,
Cualquier conjunto de n-tuplas de este producto cartesiano será una relación sobre los z conjuntos. Observe que al definir estas relaciones tenemos que especificar los conjuntos, o dominios, entre los que vamos a seleccionar los valores.
3.2.3
Relaciones en una base de datos
Aplicando los conceptos anteriores a las bases de datos, podemos definir un esquema de relación.
T
u
Esquema de
relación
Una relación denominada definida por un conjunto de parejas de atributos y nombres de dominio.
f
I
Capítulo
Iomados
lue pLle-
lnlr
una
e selecernento
El modelo
relacional
69
Sean 4,, Ar, . . ., A, atributos con dominios Dr, Dr, .. ., D,. Entonces, el conjunto {Ar:Dr, A2:D2, .. ., A,:Dn} es esquema de relación. Una relación R definida por un esquema de relación s es un conjunto de asignacio-¡s de los nombres de atributo a sus colrespondientes dominios. Así, la relación R es un conjunto de z-tuplas:
i
i,Ar:dr, Ar:dr, . . ., An:d,\ tales que d1
as orde-
mbro de
3
e
D1, dz
e
Dz,
. . .,
dn
e
Dn
Cada elemento de la r-tupla está compuesto de un atributo y un valor para dicho atributo. Normalmente, -¿ndo escribimos una relación en forma de tabla, enumeramos los nombres de atributo como encabezados :; las columnas y escribimos las tuplas como filas que tienen la forma (dr, dr,. . ., d,), donde cada valor se . ¡i:ra del dominio apropiado. De esta forma, podemos pensar en una relación dentro del modelo relacional -:'mo en un subconjunto del producto cartesiano de los dominios de los atributos. Una tabla es, simplemente, -l.l representación fisica de dicho tipo de relación. En nuestro ejemplo, la relación Branch mostrada en la Figura 3.1 tiene los atributos branchNo, street, c¡ty y :..stcode, cada uno con su correspondiente dominio. La relación Branch será cualquier subconjunto del produc.¡ cartesiano de los dominios, es decir, cualquier conjunto de tuplas de cuatro elementos en las que el primer ;-:mento pertenezca al dominio formado por todos los números de sucursal, el segundo perterrezca al domi-: .¡ tbrmado por todos los nombres de calles, etc. Una de las fuplas de cuatro elementos será: -
i(B005, 22Deer Rd, London, SWI 4EH)) nto
sea
- rás correctamente: ,i(branchNo: 8005, street: 22Deer Rd, city: London, postcode: SW1 4EH))
Nos referimos a esto como una instancia de relacién. Latabla Branch es una forma conveniente de escrien cualquier instante específico, Io que expl! -, por qué las filas de las tablas en el modelo relacional se denominan tuplas. De la misma forma que toda -:ieción tiene un esquema, también lo tiene la base de datos relacional.
:.r todas las tuplas de cuatro elementos que forman la relación
rmpliar
Esquema de la base de datos relacional
:to car-
prlmer mto de
Un conjunto de esquemas de relación, cada uno con un nombre distintivo.
Si Rr, R2, ., R, es un conjunto de esquemas de relación, entonces podremos escribir el esquema de la :¿se de datos relacional, o simplemente esquema relacional, R, como:
R= {R1,R,...,R,} úmero rducto
untos. )S que
lom-
3.2.4 Propiedades de las relac¡ones -:a
I I I t I I r
relación tiene las siguientes propiedades: la relación tiene un nombre distinto de los demás nombres de relación del esquema relacional; cada celda de la relación contiene exactamente un valor atómico (único); cada tributo tiene un nombre distintivo;
los valores de un atributo pertenecen todos al mismo dominio; cada tupla es diferente; no hay tuplas duplicadas;
el orden de los atributos no tiene importancia; el orden de las tuplas no tiene importancia, teóricamente (sin embargo, en la práctica, el orden puede afectar a la eficiencia de acceso a las tuplas).
Para ilustrar 1o que significan estas restricciones, considere de nuevo la relación Branch mostrada en la Figura 3.1. Puesto que cada celda sólo debe contener un valoq es ilegal almacenar dos códigos postales para ina misma sucursal en una única celda. En otras palabras, las relaciones no contienen grupos repetitivos. Una ¡elación que satisfaga esta propiedad se denomina normalizada, diciéndose también que está en primera forma normal (las formas normales se explican en los Capítulos 13 y 14).
Sistemas de bases de datos
70
Los nombres de columna enumerados en la parte superior de las columnas se corresponden con los atributos de la relación. Los valores del atributo branchNo pertenecen todos al dorninio formados por todos los posibles números de sucursal; no se permite, por ejemplo, qrte aparezca en esta columna un valor de código postal. No puede haber tuplas duplicadas en rrna relación. Por ejemplo, la fila (8005 ,22 Deer Rd, London, SWI 4EH) sólo aparece üiaYez. Siernpre que movamos los nombres de atributos junto con sus corespondientes valores, podemos intercambiar libremente las columnas . Lafabla representaría la misma relación si pusiéramos el atributo city antes del atributo postcode, aunque por cuestiones de legibilidad tiene más sentido mantener los elementos que describen la dirección postal en el orden habitual. De forma similar, podemos intercambiar las tuplas, de modo que los registros correspondientes a la sucursal 8005 y 8004 pueden intercambiarse y la relación continuará siendo la misma. La rnayoría de las propiedades especificadas para las relaciones se derivan de las propiedades de las relaciones matemáticas:
r Al hablar del producto
I
atrl
nul n]0 :co( il ( '- :,.\ SLIr
-nil
relacional.
;.\
En una relación, los valores posibles para cada posición dada están determinados por el conjunto, o
En un conjunto, no hay elementos repetidos. De forma similar, en una relación no hay tuplas duplicadas.
I
Da
cartesiano de conjuntos con elementos simples, de un único valor, como por ejernplo los números enteros, cada elemento de cada tupla tenía un único valor. De forma similar, cada celda de una relación contiene exactamente un valor. Sin embargo, una relación matemática no necesita estar normalizada. Codd eligió prohibir los grupos repetitivos para simplificar el modelo de datos
dominio, sobre el que esa posición está def,rnida. En una tabla, los valores de cada columna deben provenir del mismo dominio de atributo.
I
LIN
Puesto que una relación es un conjunto, el orden de los elementos no tiene importancia. Por tanto, en una relación el orden de las tuplas es indiferente.
Sin embargo, en una relación matemática el orden de los elementos dentro de una tupla sí es importante. Por ejemplo, la pareja ordenada (1,2) es totalmente diferente de la pareja ordenada (2, 1). Esto no es así, en las relaciones del modelo relacional, que específicamente requiere que el orden de los atributos sea indiferente. La razón es que los encabezados de las columnas definen a qué atributo pertenece el valor. Esto significa qr"re el orden de los encabezados de las columnas en la intensión es indiferente, pero una vez que se ha elegido la estructurra de la relación, el orden de los elementos dentro de las tuplas de la extensión debe corresponderse con el orden de los nornbres de los atributos.
3.2.5 Claves relac¡onales Como hemos indicado antes, no existen tuplas duplicadas dentro de una relación. Por tanto, tenemos que poder identificar uno o rnás atributos (denominados claves relacionales) que identifiquen de forrna unívoca cada tupla de rura relación. En esta sección, vamos a explicar la terminología utilizada para las claves relacionales.
Superclave
Un atributo o conjunto de atributos que identifica de forma unívoca cada tupla den-
tro de una relación. Una superclave identifica de forma unívoca cada tupla dentro de una relación. Sin embargo, una supercla-
ve puede contener atributos adicionales que no sean necesarios para la identif,rcación unívoca, por lo que resultaría interesante identiñcar aquellas superclaves que sólo contengan el número mínimo de atribr.rtos necesarios para efectuar de forma unívoca la identificació
Clave
candidata
Una superclave tal que ningún subconjunto propio de la misma es una superclave
de la relación. Una clave candidata, K,para una relación R tiene dos propiedades:
Jer
:'3 .!, . -il :f
Capítulo )n los atrt-
todos los de código
l, London. mos mter) city antes s que des, de modo
:ontinuará e las rela-
como por
rilar, cada no necer de datos ,
)nJ unto, o eben pro-
; duplica-
tanto, en Lportante. 35 aSí, en
ndiferen-
significa ha elegi)n espon-
firos que unívoca
relaciorla den-
Lrpercla-
r lo que f,s nece-
)rclave
3
El modelo relacional
71
I unicidad: en cada tupla de R, los valores de K identifrcan unívocamente a la tupla; I irreducibilidad: ningún subconjunto propio de Kpresenta la propiedad de unicidad. Puede haber múltiples claves candidatas para una relación. Cuando una clave está compuesta de más de -:. "iributo, decimos que es una clave compuesta. Considere una relación Branch mostrada en la Figura 3.1. l.io un valor de city, podemos determinar varias sucursales (por ejemplo, Londres tiene dos sucursales). Este :.-.buto no puede ser una clave candidata. Por otro lado, puesto que DreamHome asigna a cada sucursal un : -:rero de sucursal distintivo, entonces tendremos que dado un valor de número de sucursal, branchNo, pode- - s determinar como máximo una tupla, por lo que branchNo es una clave candidata. De forma similar, pos::.:e también sería una clave candidataparu esta relación. Considere ahora una relación Viewing, que contenga información relativa a los inmuebles vistos por los -.::ntes. La relación comprende un número de cliente (clientNo), un número de inmueble (propertyNo), una --:ha de visita (viewDate) y, opcionalmente, un comentario (comment). Dado un número de cliente, clientNo, : -ede haber varias visitas correspondientes para diferentes inmuebles. De forma similar, dado un número de -:;nueble, propertyNo, puede haber varios clientes que 1o hayan visitado. Por tanto, clientNo y propertyNo no pue:3:1 ser seleccionadas por sí mismas como claves candidatas. Sin embargo, la combinación de clientNo y :'cpertyNo identif,rca como máximo una tupla, por lo que parala relación Viewing estos dos campos, clientNo '. propertyNo, forman juntos la clave candidata (compuesta). Si tenemos que contemplar la posibilidad de que :. cliente visite un inmueble más de una vez, podemos añadir viewDate a la clave compuesta. Sin embargo, . amos a suponer que esto no es necesano. Observe que no puede utilizarse una instancia de una relación para demostrar que un atributo o combina:ión de atributos es una clave candidata. El hecho de que no haya duplicados para los valores que aparecen ¡r un instante concreto no gararfiiza que los duplicados no sean posibles. Sin embargo, lapresencia de dupli:ados en una instancia sí puede usarce para demosffar que una ciefa combinación de atributos no es una clave ;andidata. La identificación de una clave candidata requiere que conozcamos el significado en el 'mundo real' Je los atributos implicados, para poder decidir si es posible qve aparezcan valores duplicados. Sólo utilizanlo esta información semántica podemos estar seguros de que una cierta combinación de atributos es una clave ,'andidata. Por ejemplo, a partir de los datos presentados en la Figura 3.1, podríamos pensar que una clave ;andidata adecuada para la relación Staff es lName, el apellido del empleado. Sin embargo, aunque sólo haya un úmico valor de 'White' en esta instancia de la relación Staff, en el futuro podría entrar en la empresa un ruevo empleado con el apellido 'White', lo que invalidaría la elección de lName como clave candidata.
Clave principal
La clave candidata seleccionada para identificar las tuplas de forma unívoca dentro de la relación.
Puesto que una relación no tiene tuplas duplicadas, siempre es posible identificar cada fila de forma unívoca. Esto significa que toda relación tiene siempre una clave principal. En el peor de los casos, puede utilizarse el conjunto de atributos completo como clave principal, pero usualmente basta con emplear algún subconjunto más pequeño para distinguir las tuplas. Las claves candidatas que no se seleccionen como clave principal se denominan claves alternativas. Parala relación Branch, si seleccionamos branchNo como clave principal, postcode sería una clave altemaliya.Para la relación Viewing, sólo hay una clave candidata, compuesta por clientNo y propertyNo, por lo que estos atributos formarían automáticamente la clave principal.
Glave externa
Un atributo, o conjunto de atributos, dentro de una relación que se corresponden con la clave candidata de alguna (posiblemente la misma) relación.
Cuando un atributo aparece en más de una relación, su aparición suele representar que existe algún tipo de conexión entre las tuplas de las dos relaciones. Por ejemplo, la inclusión de branchNo en las relaciones Branch y Staff es deliberada y conecta cada sucursal con los detalles de los empleados que trabajan en la misma. En la relación Branch, branchNo es la clave principal. Sin embargo, en la relación Staff, el atributo branchNo existe para poder establecer la correspondencia entre los empleados y la sucursal en la que trabajan. En la relación Staff, branchNo es una clave extema. Decimos que el atributo branchNo en la relación Staff apunta al atributo de clave principal branchNo en la relación de origen, Branch. Estos atributos comunesjuegan un papel importanfe ala hora de realizar manipulaciones de los datos, como veremos en el siguiente capítulo.
72
Sistemas de bases de datos
3.2.6 Representación de esquemas
de
base de datos relacional Una base de datos relacional está compuesta de un número cualquiera de relaciones normalizadas. El esquema relacional de la parte del caso de estudio de DreamHome esl. Branch
(branchNo, street, city, postcode)
Staff
(staffNo, fName, lName, position, sex, DOB, salary, branchNo)
PropertyForRent (propertyNo, street, city, postcode, type, rooms, rent, ownerNo, staffNo, branchNo) Client
(clientNo, fName, lName, telNo, prefType, maxRent)
PrivateOwner
(ownerNo, fName, lName, address, telNo)
Viewing
(clientNo, propertyNo, viewDate, comment)
Registration
(clientNo, branchNo, staffNo, dateJoined)
El convenio común para representar un esquema de relación consiste en indicar el nombre de la relación seguido por los nombres de los atributos entre paréntesis. Normalmente, se suele subrayar Ia clave principal. El modelo conceptual o esquema conceptual, es el conjunto de todos esos esquemas de la base de datos. La Figura 3.3 muestra una instancia de este esquema relacional.
3.3
Restricciones de integridad
En la sección anterior hemos hablado de la parte estructura del modelo de datos relacional. Como hemos indicado en la Sección 2.3, un rnodelo de datos tiene otras dos partes: una parte manipulativa, que define los tipos de operaciones permitidas sobre los datos, y un conjunto de restricciones de integridad, que garantizan que los datos son precisos. En esta sección hablarernos de las restricciones de integridad relacionales y en el siguiente capítulo explicaremos las operaciones de manipulación relacional. Ya hemos visto un ejemplo de restricción de integridad en la Sección 3.2. I . Puesto que cada atributo tiene un dominio asociado, existen restricciones (denominadas restricciones de dominio) que imponen una lirnitación al conjunto de valores permitidos para los atributos de las relaciones. Además, hay dos importantes reglas de integridad, que son restricciones o restricciones que se aplican a todas las instancias de la base de datos. Las dos reglas principales para el modelo relacional se conocen con los nombres de integridad de entidad e integridad referencial. Otros tipos de restricciones de integridad son las restricciones de multiplicidad, de los que hablaremos en la Sección I 1.6, y las restricciones generales que presentaremos en la Sección 3.3.4. Antes de deñnir la integridad de entidad y la integridad referencial, es necesario entender el concepto de valores nulos.
3.3,1 Valores nulos Valor nulo
Representa un valor para un atributo que es actualmente desconocido o no es aplicable para esta tupla.
Un valor nulo puede considerarse como representativo del valor lógico 'desconocido'. Puede significar que tm valor no es aplicable a una tupla concreta, o podría simplemente querer decir que todavía no se ha suministrado un valor. Los valores nulos son una forma de tratar con datos incompletos o excepcionales. Sin embargo, un valor nulo no es lo misrno que un valor numérico cero o una cadena de texto llena de espacios; los ceros y los espacios son valores, mientras que un valor nulo representa la ausencia de valor. Por tanto, los valores nulos deben tratarse de forma distinta de los otros valores. Algunos autores prefieren sfllizar el término 'nulo'en lugar de 'valor nulo'ya que un valor nulo es, en realidad, la ausencia total de valor. Por ejemplo, en la relación Viewing rnostrada en la Figura 3.3, el atributo comment puede estar indefinido hasta que el potencial inquilino haya visitado el inmueble y haya enviado su comentario a la agencia. Sin los valores nulos, sería necesario introducir datos falsos para representar este estado o añadir atributos adicionales que pueden no ser significativos para el usuario. En nuestro ejemplo, podríamos tratar de representar un
Capítulo
3
El modelo
relacional
Branch branchNo street
:adas. El
postcode
city
B005
22 Deer Rd
London
SWl 4EH
B007
16
Aberdeen
AB2 3SU
B003
Argyll St 163 Main St
Glasgow
Gll
B004
32 Manse Rd
Bristol
BS99
B002
56 Clover
Dr London
eQX
lNZ
NWIO 6EU
Staff staffNo fName lName
relación 'incipal. e datos"
position
sex DOB
salary branchNo
SL2I
John
White
Manager
M
1-Oct-45
30000
B005
SG37
Ann
Beech
Assistant
F
10-Nov-60
12000
B003
SG14
David
Ford
Supervisor
M
24-Mar-58 18000
B003
SA9
Mary
Howe
Assistant
F
19-Feb-70
9000
B007
SG5
Susan
Brand
Manager
F
3-Iun-40
24000
B003
SL4I
Iulie
Lee
Assistant
F
13-Iun-65
9000
B005
PropertyForRent propertyNo
¡s indirs trpos
:an que
/enel
street
city
postcode
type
Aberdeen
AB7 5SU
House
6
650
London
NW2
FIat
4
400
rooms rent ownerNo staffNo branchNo
PA14
16 Holhead
PLg4
6
PG4
6 Lawrence St
Glasgow
GlleQX
Flat
3
350
PG36
2 Manor Rd
Glasgow
G32 4QX
FIat
3
375
co46 co87 co40 co93
SG37
8003
PG21
18 Dale Rd
Glasgow
House
5
600
co87
SG37
8003
PG16
5 Novar
Dr
Glasgow
Gt2 Gl2 9AX
Flat
4
450
co93
SG14
8003
Argyll
St
8007
SA9 SL4
1
B005 B003
o tlene
a limirtantes rase de
Client clientNo fName lName
telNo
prefType maxRent
de en-
CR76
John
K"y
0207 -774-5632
Flat
425
iplici-
CR56
Aline
Stewart 0141-848-1825
Flat
350
ección
CR74
Mike
Ritchie
01475-392178
House
750
ncepto
CR62
Mary
Tiegear
01224-t96720
Flat
600
PrivateOwner
to es
lr que sumt-
s. Sin AC1OS;
ownerNo fName lName
address
co46
co87 co40 co93
telNo
Ioe Carol
Keogh
2 Fergus Dr, Aberdeen AB2 7SX
Farrel
6 Achray St, Glasgow G32
Tina
Murphy
63 Well St, Glasgow G42
0L4t-943-1728
Tony
Shaw
12 Park Pl, Glasgow G4 OQR
0r4t-225-7025
9DX
01224-861212 0141-3s7-7419
Registration
Viewing clientNo propertyNo
viewDate
comment
clientNo branchNo staffNo dateJoined
o, los
CR56
PA14
B00s
SL4
CR76
PG4
24-May-04 too srnall too remote
CR76
érmi-
20-Apr-04
CR56
8003
SG37
CR74
B003
SG37
l6-Nov-02
CR62
8007
SA9
7-Mar-03
CR56
PG4
26-May-04
inido
CR62
PA14
L4-May-04
in los
CR56
PG36
28-Lpr-04
no dining room
1
2-lan-04 I I -Apr-03
1Ona-
ar
Ltn
Figura
3.3.
lnstancia de la base de datos de alquileres de DreamHome.
73
74
Sistemas de bases de datos
comentario nulo con
el valor
'-1'
.
Alternativamente, podríamos añadir
un nuevo
atributo
:-3mplo.
a
hasCommentBeenSupplied (comentario suministrado) a la relación Viewing, que contenga un valor Y (Yes) si se ha suministrado un comentario y N (No) en caso contrario. Cualquiera de estos dos enfoques podría resultar
. -r. sí que :-¡r 1a situ
confuso para el usuario. Los valores nulos pueden causar problemas de implementación, que surgen del hecho de que el modelo relacional está basado en el cálculo de predicados de primer orden, que es una lógica booleana o bivaluada, siendo los únicos valores permitidos el valor verdadero y el valor falso. Si se permiten valores nulos, quiere decir qr.re tenemos que trabajar con Llna lógica de orden superior, como por ejemplo una lógica trivaluada o tetravaluada (Codd, 1986, 1987, 1990). La incorporación de valores nulos en el rnodelo relacional es una cuestión sujeta a controversia. Codd consideró posteriormente los valores nulos como una parte integrante del rnodelo (Codd, 1990). Otros consideran que este enfoque es incorrecto, sosteniendo que el problema de la falta de información no ha sido suficientemente cornprendido, que no se ha encontrado ninguna solución satisfactoria y que, consecuentemente, la incorporación de valores nulos en el modelo relacional es prematura (véase, por ejemplo, Date, 1995). Ahora podemos ya definir las dos reglas de integridad relacionales.
:
3.3.2 lntegridad de entidad La primera regla de integridad se aplica a las claves principales de las relaciones base. Por el momento, podemos definir una relación base como una relación que se corresponde con alguna de las entidades del esquema conceptual (véase la Sección 2.1). Proporcionaremos una definición más precisa en la Sección 3.4.
lntegridad de entidad
En una relación base ningún atributo de una clave principal puede ser nulo.
Por definición, una clave principal es un identificador mínimo que se utiliza para identificar de manera unívoca las tuplas. Esto quiere decir que ningún subconjunto de la clave principal es suficiente como para permitir una identificación unívoca de las tuplas. Si permitimos que cualquier parte de la clave principal tome un valor nulo, estaremos diciendo que no todos los atributos son necesarios para distinguir entre las tuplas, lo que contradice la definición de clave principal. Por ejemplo, como branchNo es la clave principal de la relación Branch, no deberíamos poder insertar una tupla en la relación Branch que tenga un atributo branchNo de valor nulo. Como ejemplo adicional, considere la clave principal compuesta de la relación Viewing, que estaba formada por el número de cliente (clientNo) y el nunero de inmueble (propertyNo). No deberíamos poder insertar una tupla en la relación Viewing en la que el atributo clientNo o el atributo propertyNo tuvieran un valor nulo. Si examinamos esta regla en detalle, podremos encontrar algunas anomalías. En primer lugar, ¿por qué esta regla sólo se aplica a las claves principales y no, de manera más general, a las claves candidatas, que también identifrcan las tuplas unívocamente? En segundo lugar, ¿por qué está restringida esta regla a las relaciones base? Por ejemplo, utilizando los datos de la relación Viewing mostrada en la Figua 3.3, considere la consulta 'Enumerar todos los comentarios de las visitas'. Esto producirá una relación unaria compuesta por el atributo comment. Por definición, este atributo debe ser una clave principal, pero contiene valores nulos (correspondientes a las visitas de PG36 y PG4 por parte del cliente CR56). Puesto que esta relación no es una relación base, el modelo permite que la clave principal sea nula. Ha habido diversos intentos de redefinir esta regla(véase, por ejemplo, Codd, 1988; Date, 1990).
-JutS31
C(
3"3.4 Restrir gener¿
Tambié ?'.,r ej empl
-.;cursal, el
-:i
este cas
:^ número > u-rpOtte psr Je las restr
3.4
V
En la arqui aa como la palabra 'vit 'isuario ve, cho propio, r¡n modelo .as relacion ,a Sección
SQL.
3.4.1 Las relacio ciones base
Relacit
Podem«
Vista
3.3.3 lntegridadreferenc¡al La segunda regla de integridad se aplica a las claves externas.
lntegridad referencial
Si hay una clave externa en una relación, el valor de la clave externa debe corres-
ponderse con el valor de una clave candidata de alguna tupla en su relación de origen o el valor de la clave externa debe ser completamente nulo.
Por ejemplo, branchNo en la relación Staff es una clave externa que apunta al atributo , branchNo de la relación de origen, Branch. No debe ser posible crear un registro de empleado con número de sucursal 8025, por
Una vir relación ba ¡ido en qu€ del sistem¿ Las operac la vista se base que a
Capítulo atribr-rto
:s) si
se
resultar
3
El modelo relacional
75
a menos que ya exista un registro para el número de sucursal 8025 en la relación Branch. Sin embarque debemos poder crear un nuevo registro de empleado con un número de sucursal nulo, para contemsí _:o. :jar la situación en la que un nuevo empleado ingresa en la compañía pero todavía no se le ha asignado a una
:lemplo,
,*cursal concreta. rnodelo aluada, . qulere luada o
3.3.4 Restricciones generales Restricciones
Son reglas adicionales especificadas por los usuarios o administradores de la
generales
base de datos que definen o restringen algún aspecto de la organización.
Jd con-
onside-
lo strfi't1rente, r5
).
podeqlrema
También es posible que los usuarios especifiquen restricciones adicionales que los datos deben satisfacer. Por ejemplo, si se ha impuesto un límite superior de 20 al número de empleados que pueden trabajar en una sucursal, el usuario debe poder ser capaz de especificar esta restricción general y el SGBD deberá imponerla. En este caso, no debería ser posible añadir un nuevo empleado a una sucursal concreta en la relación Staff si :1 número de empleados actualmente asignados a dicha sucursal es de 20. Desafortunadamente, el nivel de soporte para las restricciones generales varía entre unos sistemas y otros. Hablaremos de la implementación Je las restricciones de integridad relacionales en los Capítulos 6 y 17.
3.4
Vistas
En la arquitectura ANSI-SPARC en tres niveles presentada en el Capítulo 2, hemos descrito una vista exter-
lo que lación
:ra como la estructura de la base de datos que se muestra a un usuario concreto. En el modelo relacional, la palabra 'vista' tiene un sig:rificado ligeramente distinto. En lugar de ser el modelo externo completo que un .suario ve, una vista es una relación virtual o derivada: una relación que no existe necesariamente por dere;ho propio, sino que puede que sea derivada dinámicamente a partir de una o más relaciones base. Por tanto, :n modelo externo puede estar compuesto tanto por relaciones base (nivel conceptual) y vistas derivadas de -¡s relaciones base. En esta sección, vamos a explicar brevemente las vistas en los esquemas relacionales. En -¡ Sección 6.4 examinaremos las vistas con más detalle y mostraremos cómo se las puede crear y utilizar en
valor
SQL.
lanera per-
'a
rne Lln
a for-
sertar r1o.
r qué tarnaclocon-
3.4.1 Terminología -
as relaciones con las que hemos estado tratando hasta ahora en el capítulo se conocen con el nombre de rela:iones base.
Relación base
,Of el
rulos ; una 'esta
oe-
de
ela-
por
Una relación nominada correspondiente a una entidad del esquema conceptual y cuyas tuplas están almacenadas físicamente en una base de datos.
Podemos definir las vistas en términos de las relaciones base:
Vista
El resultado dinámico de una o más operaciones relacionales que operan sobre las relaciones base para producir otra relación. Una vista es una relación vi¡tual que no tiene por qué existir necesariamente en la base de datos, sino que puede producirse cuando se solicite por parte de un usuario concreto, generándosela en el momento de la solicitud.
Una vista es una relación que al usuario le parece que existe, que puede manipularse como si fuera una ::lación base, pero que no necesariamente tiene que existir en el espacio de almacenamiento en el mismo sen::Jo en que las relaciones base existen (aunque la definición de la vista sí que está almacenada en el catálogo :e1 sistema). Los contenidos de la vista se definen mediante una consulta sobre una o más relaciones base. as operaciones sobre las vistas se traducen automáticamente en operaciones sobre las relaciones de las que -¿ r'ista se deriva. Las vistas son dinámicas lo que significa que los cambios que se hagan en las relaciones r¿se que afecten a la vista se reflejan inmediatamente en ésta. Cuando los usuarios realizan cambios autori-
76
Sistemas de bases de datos
zados en la vista, estos cambios se efectuan sobre las relaciones subyacentes. En esta sección, vamos a describir el propósito de las vistas y a examinar brevemente las relaciones que se aplican a las actualizaciones hechas mediante vistas. Sin embargo, diferiremos las explicaciones sobre el modo en que se definen y procesan las vistas hasta la Sección 6.4.
I 'Los sisl
El mecanismo de las vistas resulta deseable por diversas razones:
I
Proporciona un mecanismo de seguridad potente y flexible al ocultar pafes de la base de datos a ojos de ciertos usuarios. Los usuarios no son conscientes de la existencia de ningún atributo o tupla que no estén incluidos en la vista.
I
Permite a los usuarios acceder a los datos en una forma personalizada para sus necesidades, de modo que unos mismos datos pueden ser vistos de forma distinta por diferentes usuarios simultáneamente.
r
Puede simplificar las operaciones complejas sobre las relaciones base. Por ejemplo, si se define una vista como combinación de dos relaciones (véasela Sección 4.1) los usuarios podnán realizar operaciones más simples sobre la vista, que serán traducidas por el SGBD a una serie de operaciones equivalentes sobre la combinación de relaciones.
Las vistas deben diseñarse para soportar el modelo externo que resulte familiar al usuario. Por ejemplo:
I I
Un usuario puede necesitar tuplas de Branch que contengan los nombres de los gerentes, así como el resto de los atributos contenidos en Branch. Esta vista se crea combinando la relación Branch con una forma restringida de la relación §aff en la que el puesto ocupado por el empleado sea 'Manager'.
cesami(
prendid ventas (
enelm
I
Una rel de base atributc
elige
I
Los atributos pueden ser renombrados, o también puede cambiarse el orden de los atributos. Por ejem-
dr
Las reli
individ
¡
La estr la intel extensj
I
Las prt co, los
Algunos empleados podrían ver las tuplas de Staff sin el atributo salary.
plo, el usuario acostumbrado a denominar al usuario branchNo de las sucursales mediante el nombre
I
'
Resur
3.4.2 Propósito de las vistas
I
Se han
parcial.mel mica de la
el orde
I
El gra
completo Branch Number podría ver dicho encabezado de columna, más explícito.
Una rt
Algunos empleados sólo deben ver los registos de inmuebles para aquellos inmuebles que ellos estén
una re
gestionando.
Aunque todos estos ejemplos ilustran que las listas proporcionan una independencia lógica de los datos (véase la Sección 2.1.5),las vistas permiten un tipo más significativo de independencia lógica de los datos que soporta lareorganrzación del esquema conceptual. Por ejemplo, si se añade un nuevo atributo a una relación, los usuarios existentes pueden no ser conscientes de su existencia si sus üstas est¿ín definidas para excluirlo. Si se reordena o se divide una relación existente, podemos definir una vista pam que los usuarios puedan continuar tabajando con sus vistas originales. Veremos un ejemplo de esto en la Sección 6.4.7, cuardo hablemos de las ventajas y desventajas de las vistas con mayor detalle.
I
Una
candi«
clave
otra rt
I
Unv¿ aPlica
I Lain clave
3.4.3 Actualización de las vistas
colT9l
Todas las actualizaciones efectuadas en una relación base deben verse inmediatamente reflejadas en todas las üstas que hagan referencia a esa relación base. De forma similar, si se actualiza una vista, la relación base subyacente debe reflejar el cambio. Sin embargo, eústen restricciones en los tipos de modificaciones que pueden efectuarse mediante vistas. A continuación resumimos las condiciones que la mayoría de los sistemas utilizan para determinar si está permitida una acttnlizaciónmediante una vista:
I
Esüin permitidas las actualizaciones mediante una vista que esté definida utilizando una consulta simple en la que esté involucrada una única relación base y que contenga la clave principal o una clave candidata de la relación base.
I I
No
se
permiten las actualizaciones mediante vistas que impliquen multiples relaciones base.
No se permiten las actualizaciones mediante vistas que impliquen operaciones de agregación o agrupación.
sl
relacir
de
pletat requ( nan r
I
Una de la segu
zabk
Cuesti
3.1.
I
(
Capítulo
3
E! modelo relacional
77
)s a deszaclones
Se han definido clases de vistas que son teóricamente no actualizables, teóricamente actualizables y parcialmente actualizables. El lector interesado puede encontrar en Furtado y Casanova (1985) una panorá-
y proce-
mica de la acflualización de vistas relacionales.
Resumen del capítulo I
Los sistemas de gestión de bases de datos relacionales (SGBDR) se han convertido en el software de procesamiento de datos dominante hoy en día, con un volumen estimado de ventas de nuevas licencias comprendido entre 6.000 y 10.000 millones de dólares por año (25.000 millones de dólares si inclümos las ventas de herramientas). Este software representa la segunda generación de sistemas SGBD y está basado en el modelo de datos relacional propuesto por E. F. Codd.
I
Una relación matemática es un subconjunto del producto cartesiano de dos o más conjuntos. En términos de bases de datos, una relación es cualquier subconjunto del producto cartesiano de los dominios de los atributos. Una relación se escribe normalmente como un conjunto de n-tuplas, en el que cada elemento se elige del dominio apropiado.
es equl-
I
Las relaciones se representan fisicamente mediante tablas, en las que las filas se corresponden con tuplas individuales y las columnas, con atributos.
:rnplo:
I
La estructura de la relación, con las especificaciones de los dominios y otras restricciones, forma parte de la intensión de la base de datos, mientras que la relación con todas sus tuplas representa una instancia o extensión de la base de datos.
I
Las propiedades de las relaciones de bases de datos son: cada celda contiene exactamente un valor atómico, los nombres de los atributos son exclusivos, los valores de los atributos provienen del mismo dominio, el orden de los atributos es indiferente, el orden de las tuplas es indiferente y no existen tuplas duplicadas.
I
El grado de una relación es el número de atributos, mientras que la cardinalidad es el número de tuplas. Una relación unaria tiene un atributo; una relación binaria tiene dos, una relación ternaria tiene tres y una relación n-ariatiene n atributos.
)s a oJos
I que no le modo rnente.
ñne una
r opera-
;omo el con una
3r'. )r eJemnombre
rs estén
I Una superclave
es un atributo, o conjunto de atributos, que identiflrca de forma unívoca las teclas de una relación, mientras que una clave candidata es una superclave mínima. Una clave principal es la clave candidata elegida para identificar las tuplas. Una relación debe siempre tener una clave principal. Una clave externa es un atributo, o conjunto de atributos, dentro de una relación que son la clave candidata de otra relación.
,s datos rs datos Lra
rela-
as para suanos
I
Un valor nulo representa un valor para un atributo que es desconocido en el momento actual o que no aplicable para esta tupla concreta.
I
La integridad de entidad es una restricción que indica que en una relación base ningún atributo de una clave principal puede ser nulo. La integridad referencial requiere que los valores de clave externa se correspondan con el valor de una clave candidata en alguna tupla de la relación de origen, o que sean completamente nulos. Además de la integridad relacional, las restricciones de integridad incluyen los datos requeridos, los dominios y las restricciones de multiplicidad; otras restricciones de integridad se denomi-
, cuan-
das las n base. re pLre-
as utr-
a slm-
nan restricciones generales.
I Una vista en el modelo relacional
es una relación virtual o derivada que se crea dinámicamente a partir subyacentes cuando es necesario. Las vistas proporcionan mecanismos de de la relación o relaciones base personalizar el modelo de los usuarios. No todas las vistas son actualiy permiten al diseñador seguridad zables.
clave
Cuestiones de repaso ode
es
3.1.
Explique cada uno de los siguientes conceptos en el modelo de datos relacional:
(a)
relación
Sistemas de bases de datos
78
3.2. 3.3. 3.4. 3.5.
(b) (c) (d) (e)
atributo
(f)
grado y cardinalidad.
dominio tupla intensión y extensión
Describa la relación entre relaciones matemáticas y relaciones en el modelo de datos relacional.
Describa las diferencias entre una relación y un esquema de relación. ¿Qué es un esquema de base de datos relacional? Explique las propiedades de una relación.
Explique las diferencias entre las claves candidatas y la clave principal de una relación. Explique el concepto de clave extema. ¿Cómo se relacionan las claves extemas de una relación con las claves candidatas? Proporcione ejemplos para ilustrar su respuesta.
3.6.
Defina las dos principales reglas de integridad para el modelo relacional. Explique por qué es deseable imponer estas reglas.
3.7.
¿Qué es una vista? Explique la diferencia entre una vista y una ¡elación base.
Ejercicios
0bje
Las siguientes tablas forman parte de una base de datos almacenada en un SGBD relaciona:
Hotel Room
Er
I I I I I
(hotelNo, hotelName, city) (¡OOpNS, hotelNo, type, pr¡ce)
Booking
(hotelNo, guestNo, dateFrom, dateTo, roomNo.¡
Guest
(SUCslNg,guestName,guestAddress)
donde Hotel contiene los detalles de un hotel y hotelNo (núrmero del hotel) es la clave principal; Room contiene los detalles de las habitaciones para cada hotel
y
(roomNo, hotelNo) forma la clave prin-
cipal; Booking contiene los detalles de las reservas y (hotetNo, guestNo, dateFrom) tbrma la clave principal; Guest contiene los detalles de los huéspedes y guestNo es la clave principal.
3.8. 3.9
.
ldentifrque las claves extemas en est€ esquema. Explique cómo se aplican las reglas de integridad de entidad e integridad referencial a estas relaciones. Escriba algunas tablas de ejemplo para estas relaciones que cumplan con las reglas de integridad relacionales. Sugiera algunas restricciones de carácter empresarial que resultaran apropiadas para este esquerna.
3.10. Analice los SGBDR
que esté utilizando actualmente. Determine el grado de soporte que proporcione el sistema para las claves principales, claves altemativas, claves externas, reglas de integridad relacional y vistas.
3.11. Implemente el esquema anterior
en uno de los SGBDR que utilice actualmente. lmplemente, siempre que sea posible, las claves principales, alternativas y extemas y las apropiadas restricciones de integridad relacional.
-
t5
_Jn0
r-3nl
,:Capítulo
Algebra relacional y cálculo relacional
ral. r base de
rlique el ves cans desea-
Obietivos del capítulo: En este capítulo aprenderá:
ie prln-
?al; dad de d relara este
rcione :lacioempre
fegri-
I I I I I
El significado del termino 'completud relacional'. Cómo construir consultas en álgebra relacional. Cómo construir consultas en el cálculo relacional de tuplas. Córno construir consultas en el cálculo relacional de dominios. Las categorías de lenguajes de manipulación de datos (DML, Data Manipulation Language) relacionales.
En el capítulo anterior hemos introducido los principales componentes estructurales del modelo relacional. Como se explica en la Sección 2.3, otra parte muy importante de un modelo de datos es el mecanismo de manipulación , o lenguaje de consulta, que permite extraer y actualizar los datos subyacentes. En este capítulo, vamos a examinar los lenguajes de consulta asociados con el modelo relacional. En particular, vamos a concentramos en el álgebra relacional y en el cálculo relacional, según fueron definidos por Codd (1971) como base para los lenguajes relacionales. De un modo informal, podemos describir el álgebra relacional como un lenguaje procedimental (de alto nivel). Puede utilizarse para decir al SGBD cómo construir una nueva relación a partir de una o más relaciones existentes ya en la base de datos. También de una manera informal, se puede describir el cálculo relacional como un lenguaje no procedimental. Puede utilizarse para formular la definición de una relación en términos de una o más relaciones de base de datos. Sin embargo, formalmente, el álgebra relacional y el cálculo relacional son equivalentes entre sí: para toda expresión del álgebra, existe una expresión equivalente en el cálculo (y viceversa). Tanto el álgebra como el cálculo son lenguajes formales, que no resultan amigables para el usuario. Ambos se han utilizado como base para otros lenguajes de manipulación de datos (DML, Data Manipulation Language) de más alto nivel para bases de datos relaciones. Si resulta de interés su estudio es porque ilustran las operaciones básicas requeridas en cualquier DML y porque sirven como estándar de comparación para otros lenguajes relacionales.
El cálculo relacional se utiliza para medir la potencia selectiva de los lenguajes relacionales. Un lenguaje que pueda usarse para producir cualquier relación que se pueda obtener mediante el cálculo relacional se denomina relacionalmente completo. La mayoría de los lenguajes de consulta relacionales son relacionalmente completos, aunque tienen mayor potencia expresiva que el álgebra relacional o que el cálculo relacio-
I 80
Sistemas de bases de datos
nal, debido a que incluyen operaciones adicionales como funciones de cálculo, funciones de totalización y funciones de ordenación.
Estructura del capítulo En Ia Sección 4. I vamos a examinar el álgebra relacional y en la Sección 4.2 examinaremos dos formas del cálculo relacional: el cálculo relacional de tuplas y el cálculo relacional de dominios. En la Sección 4.3 se analizan brevernente algunos otros lenguajes relacionales. Utiiizaremos la instancia de base de datos de alquileres de DreamHome que se muestra en la Figura 3.3 para ilustrar las operaciones. En los Capítulos 5 y 6 examinaremos SQL (Stmctured Query Language, lenguaje estructurado de consulta), el lenguaje estándar formal y de.facto para los SGBD, que tiene estructuras basadas en el cálculo relacional de tuplas. En el Capítulo 7 se examina QBE (Query-By-Examp1e, consulta mediante ejemplo), otro lenguaje de consulta visual mr"ry popular para sistemas SGBD, que se basa parcialmente en el cálculo relacional de dominios.
4.1 El álgebra relacional El álgebra relacional es un lenguaje teórico con operaciones que se aplican a L¡na o más relaciones, con el fin de definir otra relación sin modihcar las relaciones originales. Por tanto, tanto los operandos como los resultados son relaciones, de manera que la salida de una operación puede utilizarse como entrada de otra operación. Esto permite anidar las expresiones en e1 álgebra relacional, de la misma forma que podemos anidar operaciones aritméticas. Esta propiedad se denomina cierre: las relaciones exhiben la propiedad de cierre en el álgebra relacional, de la misma forma que los nurneros exhiben la propiedad de cierre con respecto a las operaciones ari tméticas. El álgebra relacional es un lenguaje de rnanipulación de una relación (o conjunto) cada vez, en la que todas las tr.rplas, posiblemente obtenidas a través de varias relaciones, se rnanifiestan mediante una instrucción, sin que existan bucles. Existen diversas variantes sintácticas para los comandos del álgebra relacional y 1o que nosotros haremos en el texto es utilizar una notación simbólica comirn para los comandos y presentar éstos de manera informal. Ei lector interesado puede consultar el libro de Uilman (1988), donde podrá encontrar un tratarmiento más formal. Existen mirltipies variaciones de las operaciones incluidas en el álgebra relacional. Codd (1972a) puso originalmente ocho operaciones, pero después se han propuesto muchas otras. Las cinco operaciones fundamentales en el álgebra relacional, selección, proyección, producto cartesiano, unión y diferencia de conjuntos, penniten realizar la mayoría de las operaciones de extracción de datos que nos interesan. Además, están def-rnidas las operaciones de combinación, intersección y división, que pueden expresarse en ténninos de las cinco operaciones básicas. En la Figura 4.1 se ilustra la función de cada una de estas operaciones. Las operaciones de selección y proyección son operaciones unarias, ya que operan sobre una úrnica relación. Las otras operaciones se aplican a parejas de relaciones y se denonrinan, por tanto, operaciones binarias. En las siguientes definiciones, sean R y S dos relaciones definidas sobre los atributos A: (a,, á2, . . ., áN) y B : (b,, b2. . . .. br). respectivamente.
4.1.1 Operaciones unar¡as Comenzamos nuestro análisis del álgebra relacional examinando las dos operaciones unarias: selección y pro-
yección.
Selección (o Restricción)
r; Ent
(r0."0,"","(R)
La operación de selección se aplica a una única relación R y define otra relación que contiene únicamente aquellas tuplas de R que satisfacen la condición (predicado) especificada.
Capítulo
4
Álgebra relacional y cálculo relac¡onal 81
lc10n v
PQ
EH
T T E tt ! E
*, "r ;e analquile6 exabrmal
(a)
oTse
(b)
Selección
[:l ¿]
H¡
Proyección
RUS
popu-
PxQ
Producto cartesiano
R-S
RNS
[]
el fin esulope-
'1.
ridar
(d)
:e en
a las
(e)
Unión
U
{{= (f)
lntersección
T>
Diferencia de conjuntos 7 :-:" U
T>_B U
[_GTJ
ffi l,l,l,l
rdas
, sin que
l,l,l'l
sde
:un (s)
orien-
R
E
tos,
:filCO ¡^
lar*)
l-*"1 [)
Combinación natural
J
t--l L_l
Semicombinación
VW
R+S
l T
División (área sombreada)
(h)
A
B
a
1
a
2
b b
2
1
(i)
Combinación externa izquierda
l;t f;
E
H E_l
1
Ejemplo de división
Figura 4.1. llustración que muestra la función de las operaciones del álgebra relacional.
tI
Ejemplo
4.1 Operación de selección
Enumerar todos los miembros del personal cuyo salario sea superior a 10.000 euros. o""¡"r,
166¡0(Staff)
Aquí, la relación de entrada es Staff y el predicado es salary > 10000. La operación de selección define una relación que contiene únicamente aquellas tuplas de Staff con un salario superior a 10.000 eu:os.
AZ
Sistemas de bases de datos
El resultado de esta operación se muestra en
1a
Figura 4.2. Pueden generarse predicados más comple- (NOT).
jos r-rtilizando los operadores lógicos A (AND), V (OR) y staffNo fName
lName
position
sex
DOB
salary branchNo
SL2 I
White
Manager
M
1-Oct-45
30000
B005
SG37
lohn Ann
Beech
Assistant
F
10-Nov-60
r2000
8003
SC 14
David
F'ord
Supervisor
lvl
24-Mar-58
r8000
B003
SG5
Susan
Brand
Manager
F
3-lun-40
24000
u00l
Figura
4.2
r =:'s _.
:li\l
- -::r= ::-i,l'i1 ,
,
.,1'n.
I= I
Selección de salarios > 10000 en la relac¡ón Staff.
Eler
Et:i,¡ t
P;r¡
Proyección
["r,
tI
I
La operación de proyección se apllca a una única relación R y define otra relación que contiene un subconjunto vertical de R, extrayendo los valores de los atributos espec¡f¡cados y el¡minando los duplicados.
,""(R)
f lur) JL:pl. :1Ue\
4.2 Operación de proyecc¡ón
Ejemplo
Generctr una lisla de salarios para todo el personal, mostrando solatnenfe los detalles re/'eridos a los atributos staffNo, fName, lName y salary. llsu'r.¡o,
rr..ame,
^am.. ""r"ry(Staff
)
En este ejemplo, la operación de proyección det-rne una relación que contiene úrnicamente los atribr-rtos designados de Staff; staffNo, fName, lName y salary, en el orden especif,rcado. El resultado de esta operación se muestra en ia Figura 4.3.
Figura
4.3.
staffNo
fName
lName
salary
SL2 I
White
30000
SG37
Iohn Ann
Beech
12000
SGI4
David
Ford
r8000
SA9
Mary
Howe
9000
SG5
Susau
Brand
24000
SL4I
Iulie
Lee
Difert R-
9000
Proyección de la relación Staff sobre los atributos staffNo, fName, lName y salary.
J
4.1.2 Operaciones de conjuntos Las operaciones de selección y proyección extraen información de una única relación. Sin embargo, existen obviarnente casos en los que nos gustaría combinar información de diversas relaciones. En el resto de esta sección, vamos a exalrinar las operaciones binarias del álgebra relacional, comenzando con las operaciones de conjuntos de unión, diferencia de conjuntos, intersección y producto cartesiano.
Unión RUS
fL
La unión de dos relaciones R y S define una relación que contiene todas las tuplas R, de S o tanto de R como de S, eliminándose las tuplas duplicadas. R y S deben ser compatibles con respecto a la unión.
: -. :
:Sf
:- Iel ',
1-
Capítulo omple-
+
Álgebra relacional y cálculo relacional 83
>r R y S tienen tuplas 1 y J, respectivamente, su unión se obtiene concatenándolas en una única relación con -n máximo de (1 + -/) tuplas. La unión es posible sólo si los esquemas de las dos relaciones se corresponden, .i tienen el misr¡o número de atributos y cada pareja de atributos correspondientes tiene el mismo dominio. :n otras palabras, las relaciones debe ser compatibles con respecto a la unión. Observe que no se utilizan -is nombres de los atributos al definir la compatibilidad con respecto a la unión. En algunos casos, la opera-
::ón de proyección puede ulilizarse para hacer que las dos relaciones sean compatibles con respecto a la -nrón. I
I
Ejemplo
4.3 Operación de unión
Enumerar todas las ciudades en las Ere exista una sucursal o un inmueble en alquiler. lI",u(Branch)
u fI",r(PropertyForRent)
Para producir relaciones compatibles con respecto a 1a unión, primero utilizamos la operación de proyección para proyectar las reiaciones Branch y PropertyForRent sobre el atributo city, eliminando los duplicados según sea necesario. A continuación, utilizamos 1a operación de unión para combinar estas nuevas relaciones con e1 fin de producir ei resultado que se muestra en la Figura 4.4.
reiación rtributos
:t lo,s
Figura 4.4. Unión basada en el atributo city y generada a partir de las relaciones Branch y PropertyForRent.
rrtos
era-
Diferencia de conjuntos R- S La operación
de diferencia de con.juntos define una relación compuesta por las tuplas que encuentran en la relación R, pero no en S. R y S deben ser compatibles con respecto a la unión.
I
I
Elemplo
4.4 Operación de diferencia de conjuntos
Enumerar todas las ciudades en las que erista tota sucursctl, pero no haya inmttebles en alquiler.
II",r(Branch)
.isten I sec-
lI",,r(PropertyForRent)
Corno en e1 ejemplo anterior, generamos relaciones compatibles con respecto a la unión proyectando ias relaciones Branch y PropertyForRent sobre e1 atributo city. A continuación, utilizamos la operación de diferencia de conjuntos para combinar estas nuevas relaciones con el fin de producir el resultado que se rnuestra en Ia Figura 4.5.
:s de
rias
)en
Figura 4.5. Diferencia de conjuntos basada en el atributo city y generada a partir de las relaciones Branch y PropertyForRent.
84
Sistemas de bases de datos
lntersección RnS
I
I
Ejemplo
La operación de intersección define una relación compuesta por el conjunto de todas las tuplas que existen tanto en R como en s. R y s deben ser compatibles con respecto a la unión.
4.5 Operación de intersección
Ettutnerur toc/as las ciutlucles en las cpre eristo fanfo t.tna sucursal contt¡ tluiler. fl",r(Branch)
n
tl
nteyos yn inmueble en ul-
Il",r(PropertyForRent)
Como en el ejerriplo anterior, gereralnos sendas relaciones compalibles con respecto a la unión proyectando las relaciones Branch y PropertyForRent sobre el atributo city. A continuación, utilizaruos la óperación de intersecci«in para combinar estas nuevas relaciones con el fln de proclucir el resultado que se rnLrestr¿r en la Figura 4.6.
Figura 4.6. lntersección basada en el atributo city y generada a partir de las relaciones Branch y propertyForRent.
Observe que podemos expresar la operación de intersección en términos de la operación de diferencia de conjuntos:
RnS:R-(R-S) Producto cartesiano RXS
La operación de producto cartesiano define una relación que es la concatenación de cada tupla de la relación R con cada tupla de la relación S.
La operación de producto cartesiano multiplica dos relaciones para definir otra relación compuesta por todas las posibles parejas de tuplas de las dos relaciones. Por tanto, ii una de las relaciones tiene i tuplas y N atributos y la otra tiene -/ tuplas y Matributos, la relación de producto carlesiano contendrá (1 * J) iuplas con (N -f It4) attlbutos. Es posible que las dos relaciones tengan atributos con el mismo nombre. En este caso, se añade como prefijo a los nombres de los atributos el nombre de la relación, con el frn de mantener Ia uricidad de los nombres de atributo dentro de una misma relación.
I
I
Ejemplo
4.6 Operación producto cartesiano
Enumerctr los nombres y comentarios de todos los clientes que hayan visto un inmueble en alquiler
Los nombres de los clientes están almacenados en la relación Client y los detalles sobre las visitas se conseryan en la relación Viewing. Para obtener la lista de clientes y los comentarios sobre los inmuebles que han visitado, necesitamos combinar estas dos relaciones: (nclientNo, r¡lame,
trua."(Client))
x
(n.rienu,,:o, propeny¡o,
Sesc
_.:
_: ,... . .: ' :
"..*"n,(Viewing))
El resultado de esta operación se muestra en ia Figura 4.7. En su forma actual, esta relación contiene más información de la que necesitamos. Por ejemplo, la primera tupla de esta relación contiene dife-
-:-:l ::
Gapítulo
4 Algebra relacional y cálculo relacional
85
rentes valores clientNo. Para obtener la lista requerida, necesitamos llevar a cabo una operación de selección sobre esta relación para extraer aquellas tuplas en las que Client.clientNo : Viewing.clientNo. La operación completa será, por tanto:
unto de pat¡bles
ocrient.crientNo . viewins.c ientNo(ndientNo,
fName,
tName(Client)) X (flctient'to,
propenyruo,
"orr"n,(Viewing))
El resultado de esta operación se muestra en la Figura 4.8.
n al-
proopere se
J rcia de
client.clientNo
fName lName
Viewing.clientNo
propertyNo
comment
CR76
Iohn
Kay
CR56
PAI4
too small
CR76
John
Kay
CR76
PG4
too remote
CR76
John
Kay
CR5ó
PG4
CR76
John
Kay
CR62
PA14
CR76
John
Kay
CR56
PG36
CR56
AIine
Stewart
CR56
PA14
too small
CR56
Aline
Stewart
CR76
PG4
too remote
CR56
Aline Aline
Stewart
CR56
PG4
CR56
Stewart
CR62
PA14
CR56
AIine
Stewart
CR56
PG36
CR74
Mike
Ritchie
CR56
PAI4
too small
CR74
Ritchie
CR76
PG4
too remote
CR74
Mike Mike
Ritchie
CR56
PG4
CR74
Mike
Ritchie
CR62
PAI4
CR74
Ritchie
CR56
PG36
CR62
Mike Mary
Tregear
CR56
PA14
too small
CR62
Mary
Tregear
CR76
PG4
too remote
CR62
Mary
Tregear
CR56
PG4
CR62
Mary Mary
Tregear
CR62
PAI4
Tregear
CR56
PG36
CR62
Figura
4.7.
no dining room
no dining room
no dining room
no dining room
Producto cartesiano de las relaciones reducidas Client y V¡ew¡ng.
ación fName
lName
Mewing.clientNo
propertyNo
comment
CR76
John
Kay
CR76
PG4
too remote
CR56
Aline
Stewart
CR56
PAI4
too small
atrion (1/
CR56
Aline
Stewart
CR56
PG4
CR56
CR56
PG36
CR62
Aline Mary
Stewart
lo,
Tregear
CR62
PA14
client.clientNo
todas y'
se
no dining room
.rnici-
Figura 4.8. Producto cartesiano restring¡do de las relaciones reducidas Client y Viewing.
I
Descompos¡c¡ón de operaciones comple¡as operaciones de álgebra relacional pueden tener una complejidad arbitrariamente grande. Podemos des-,lmponer dichas operaciones en una serie de operaciones más pequeñas de álgebra relacional y proporcionar -r nombre a los resultados de las expresiones intermedias. Utilizamos la operación de asignación, denotada -iediante <-,para nombrar ios resultados de una operación del álgebra relacional. Esto funciona de forma ..milar a la operación de asignación que puede encontrarse en cualquier lenguaje de programación: en este :,rso, el lado derecho de la operación se asigna al lado izquierdo. Por ejemplo, en el ejemplo anterior, poüía:,os reescribir la operación de la forma siguiente.
-ls
86 Sistemas de bases de datos TempViewing(clientNo
rempctient(crie.,*",
r'iffi::fl#:::H"'
G fr"
"n'xo
p'op'nvruo,.o.,"n¡(Vi€wins)
;:IT"J':#:;":::ij*:,:;;,i,i::T.j#;ü:'::il",,)
EnelI e- rempc,ien, x
este lis
rempv¡ew¡ns
binacii
Alten.rativamente' oodemos trtilizar la operación renor¡rbrar p (rho), que proporciona un nor¡bre ar resuluri,izar un nombre op.iona,
(fI",
;xxl:;,:',1,".T:'il::,X,1J11'::t'*:***fiff,;ffih:;n::""ire ps(E) o Ps1u1, a2, . . .,
La operación renombrar proporciona un nuevo opcionarmentu
,rijn, ,
""1(E)
ros
atributos-r;
#;;:J:,T::: : ,::-
o
Resl
El resul
ra expresión E y
4.7.A Operaciones de combinación
Combin
NormaLnente, sólo nr nes. así que
RXS
habirrarrrl:i[".',"T[i::;:l'l,l:tT":*.ix:::ffi;*ffi:1]rñ:i:*ilff:ril;TÍ[[
fbrmar u,u n,"uu re,ación, es una i:T:ff:1':i":::':::::ü.::T'.iT,'-':**§;1*TilT#f,:HHpara es una derivada del proclucto reati carresia_ ;"::',:l::i,::^T:1"r:ron a.,"rl."i*, ñ;ff:iJ[1""[ffi,,]Xj:;:1".:1ó" utitizan¿o eip,=at.uao de combinacion.o*o rórmura no. equivalenre a
es una de
La operació:
=laciones qr elaciones R
ru,,p".u.io,::11,T ¿iri",",
á.;;ii::§üii.J?:n:§:::f razones por las que los sistemas relacionaiest'i*a prour"-ur'*,.trr"a", .:Ximfl";?l;*JfJfi
estrategias de implementación de r"
de prestacion"a.'¡**urrinu.emos
"p"'.""..
de combhación en la sección 2r.4.3.
u.,,tJ:'J;[J:H'*:Tfi":'q::*H'f;;ui,"..",'."á1,.,"'á" I I I I r
"r*
las
con sut,es dir-erencias, y argunas
Enumera quiler.
Combinación rhera Equricornbinación
(r_rn
tipo parlicular
Combinaciónnatr-rral
combinación rheta)
En el Eje tante mo: natural p;
Co¡nbinación externa Semicornbinación.
(11",'"n^
Combinación Theta (0_combinación) R XFS La operación de combinación
ülü:;:i"ist: ,, =, _, +). ,::[t#:t
o Result
theta define una
El resulta
,:r::]1
que contiene tupras der proF er preoiájl F tiene ra .' tsvevs osr ur¡u ue ros operadores de comparación (<, <,
::J""'#.""'#n;"'"#"'icado
reescribir la combinación theta en rén¡inos de las operaciones básicas de serección y producro car_
RXFS:o.(RxS) AI igual que con t' caftesiano,. el grado cle una combinación thera es relaciones R y s que actúan T:.9lttt., la suma de los grados de ras corno up..rnáor.-rn- caso d" ;';;;d-i.udo F.sóro conrenga er se utiliza c;;'ü"-..i;r"JJ nuevo ra consurra d-el operador de 'l Ejempro
té'*;ú;i;;riiir"",¿r.
3t:'' Ir
ñ;
4.6.
t¡emplo 4.7 Operación equicombinación
f:;t:*'
los nombres
y
comentarios de todos los clientes que hayan visitado un inmueble en al-
Combina . :renudo, a r)tra; en Otr
, _
.
_.eramos qu,
irespondier
Capítulo
4 Álgebra relacional
y cálcuto retacional 87
:n el Ejemplo 4.6, hemos utilizado las operaciones de producto cartesiano y selección para obte-ner :ste listado. Sin embargo, podemos obtener el mismo resultado utilizando la operación de equicom:rnación: (ficlentNo,fName,
)re a[ resul,re
lNa."(Client))Xchent.ctLenrNo vewinsclientNo(flctientruo,propenyruo,"orr"n,(VieWing))
o
opcional
Result <- TempClient
Xrempcrienr.,ienrNo
:
rempviewins.crientN"
(TempViewing)
El resultado de estas operaciones es el que ya hemos mostrado en la Figura 4.8.
'esión E y
Combinación natural
RXS
La combinación natural es una equicombinación entre las dos relaciones R y
; condicio1
producto
ión, es una o cartesia-
fórmula nbinación Lo
una de las Lremos las
y algunas
S
sobre todos los atributos comunes x. Del resultado se elimina una de las dos aparic¡ones de cada atributo común.
-' -.
..peración de combinación natural lleva a cabo una equicombinación sobre todos los atributos de las dos iciones que tengan el mismo nombre. El grado de una combinación natural es la suma de los grados de las -.-'ciones R y S, menos el número de atributos de x. I
I
e¡empto
4.8 Operación de combinación natural
Enumerar los nombres
y
comentarios de lodos los clientes que hayan visitado un inmueble en al-
luiler. En el Ejemplo 4.7, hemos utilizado la equicombinación para generar este listado, pero la relación resul.¡nte mostraba dos ejemplares del atributo de combinación clientNo. Podemos utilizar ia combinación :1arural para eliminar uno de los dos ejemplares del atribr"rto clientNo: (flcr¡en*.,ro, rr.rame,
rNa-"(Client))
X
(ll"ii"ntruo, propenvruo, comment(Vi€wiItg))
D
Result <- TempClient XTempViewing
Ei resultado de este operación se muestra en la Figura 4.9. Cel pro-
tiene la I (<, <,
cto car-
s
de las
idor '¡
Figura
clientNo fName
lName
propertyNo
comment
CR76
John
Kuy
PG4
too remote
CR56
Aiine
Stewart
PAI4
too small
CR56
Stewart
PG4
CR56
Aline Aline
Stewart
PG36
CR62
Mary
Tiegear
PA14
no dining room
4.9. Combinación natural de las relaciones restringidas Cl¡ent
y Viewing.
de
4.6.
Combinación externa al-
.- menudo, al combinar dos relaciones, una tupla de una relación no tiene ninguna tupla correspondiente en : u-rtr&i el1 otras palabras, no existe ningún valor correspondiente en los atributos de combinación. Puede que
:.-eramos que en e1 resultado aparczcat las tuplas de una de 1as relaciones aun cuando no existan valores - -:respondientes en la otra relación. Esto puede llevarse a cabo utilizando la combinación extema.
88
Sistemas de bases de datos
R >< S
La combinación externa (izquierda) es una combinación en la que también se incluyen en la relación resultante las tupas de R que no tengan valores correspondientes en los atributos comunes de S. A los valores no existentes en la segunda relación se les asigna un valor nulo.
La combinación extema está cada vez más disponible en los sistemas relacionales y es uno de los operadores especificados en el estándar SQL (véase la Sección 5.3.7).La ventaja de una combinación externa es que se preserva la información, es decir, la combinación externa preserva las tupas que se habrían perdido si se utilizaran otros tipos de combinación.
¡I I
R
h
Ésta r semic
Emtm
Si estr raciór
Ejemplo 4.9 Operación de combinac¡ón externa izquierda
SE
Generar un informe de estado sobre las visitas a los inmuebles. En este caso, queremos generar una relación compuesta de los inmuebles que han sido visitados, con sus corespondientes comentarios, y aqueilos que no han sido visitados. Esto puede hacerse utiiizando la siguiente combinación externa: npropenyr.ro, sreet,
crry(ProPertyForRent))
)<
Viewing
4. 10. Observe que los inmuebles PL94,PG21 y PG16 no han tenido ninguna visita, pero estas tuplas siguen incluyéndose en el conjunto de resultados, asignando valores nnlos a los atributos correspondientes a la relación Viewing.
La relación resultante se muestra en la Figura
propertyNo
street
city
clientNo viewDate
PAI4
l6 Holhead
Aberdeen CR56
2,1 May-04
too smal.l
PAT4
16 Holhead
Aberdeen
CR62
14-May-04
no dining room
PL94
6
London
null
null
null
PG4
6 Lawrence St
Glasgow
CR76
20-Apr-04
too remote
PG4
6 Lawrence St
Glasgow
CIt56
26-May-04
PG36
2 Manor Rd
Glasgorv
CR56
28-Apr-04
PG21
18 Dale Rd
Glasgow
null
PG16
5 Novar
Dr
Glasgow
null
null null
Argyll St
1.1.4
comment
La operar ¡rrncia e
hrtos A y
SeaC:, división
nuli null
Figura 4.10. Combinación externa izquierda (natural) de las relaciones
c
R+l PropertyForRent
y'u'"*'* _J
Poder
Estrictamente hablando, el Ejernplo 4.9 es una combinación externa izquierda (natural), ya que conserva todas las tuplas de la relación de1 lado izquierdo en e1 resultado. De forma similar, existe una combinación externa derecha que conserva todas las tuplas de la relación del lado derecho en el resuitado. También existe una combinación externa completa que conserva todas las tuplas de ambas relaciones, rellenando las tuplas con nulos cuando no se encuentra ninguna tupla correspondiente en la otra relación.
T1
Semicombinación RtrrS
La operación de semicombinación define una relac¡ón que contiene las tuplas de R que part¡c¡pan en la combinación de R con S.
T2
Tr
I; Identi Poder
La operación de semicombinación realiza una cornbinación cle 1as dos relaciones y luego la proyecta sobre los atributos del prir.r-rer operando. Una ventaja de las sernicombinaciones es qlle reducen e1 nirmero de tuplas que es preciso manejar para formar la cornbinación. Resulta particularmente útil para calcular combinaciones en sistemas distribuidos (véan.se las Secciones 22.4.2y 23.6.2). Podemos reescribir la semicombinación utilizanclo las operaciones de semiproyección y de combinación:
luego dichor
ner la
(r
Capítulo se tn-
R >F S
:
IIA(R <>F
S)
4 Álgebra relacional y cálculo relacional
89
A es el conjunto de todos los atributos de R
spon,unda
Ésta es, en la práctica, una sernicombinación theta. Existen variantes para las semi-equicombinaciones y las semicombinaciones naturales.
opera-
!-
irna es dido si
¡
I
Ejemplo 4.10 Operación de semicombinación Enumerar los detalles completos de todos los empleados que trabajen en la sucursal de Glasgow. Si estamos interesados en ver sólo los atributos de la relación Staff, podemos utilizar la siguiente operación de Semicombinación, generando la relación mostrada en la Figura 4.1l. Staff D*o.o,"n"n"o
.
jon
Branch.branchNo
(o.., - .o,urro*,(Branch))
staffNo fName lName
Ldo
I6
position
sex DOB
salary branchNo
SG37
Ann
Beech
Assistant
F
10-Nov-60
12000
B003
sGl4
Daüd
Ford
Supervisor
M
24- Mar-58
18000
B003
SG5
Susan
Brmd
Manager
F
3-Jun-40
24000
B003
Figura 4.11. Semicombinación de las relaciones Staff y Branch.
ig-
4.1.4 Operación de división La operación de división resulta útil para un tipo concreto de consulta que suele presentarse con bastante frecuencia en las aplicaciones de base de datos. Suponga que la relación R está def,rnida sobre el conjunto de atributos A y que la relación S está definida sobre el conjunto B, de modo que B c A (B es un subconjunto de A). Sea C : A - B, es decir, C es el conjunto de atributos de R que no son de S. Podemos dehnir la operación de división de la forma siguiente:
R+S
La operación de división define una relación sobre los atributos C que está compuesta por el conjunto de tuplas de R que se corresponden con la combinación de todas las tuplas de S.
Podemos expresar la operación de división en términos de las operaciones básicas nser-
T, <- rIc(R)
rción
T, +- lI"((S
exis-
o
:
x
T.,)
-
R)
T<-T,-T,
las
l-
I
ER
I
Eiemplo 4.11 Operación de división Identificar lodos los clientes que hayan visto todos los inmuebles con tres habitaciones.
e
los
que en
rs
Podemos utilizar la operación de selección para localizar todos los inmuebles con tres habitaciones y luego utilizar una operación de proyección para realizar una operación que contenga exclusivamente dichos números de inmueble. Después, podemos emplear la siguiente operación de división para obtener la nueva relación mostrada en la Figura 4.12.
zafl(naientNo, propenyruo§iewing))
:
np,op",tyruo(o,*,"
:
r(PropertyForRent)))
90
Sistemas de bases de datos
g
IctientNo,propertyNo(V¡ewin
clientNo propertyNo CR56
PA14
CR76
PG4
CR56
PG4
CR62
PA14
CR56
PG36
)
IpropertyNo(o.o.,,"=
ñ;-*l
ffi o.r" I
,(PropertyForRent)) RllSUl;l
I
Figura 4.12. Resultado de la operación de dlvisión de las relaciones V¡ewing y PropertyForRer
r
Operae
4.1.5 Operaciones de agregac¡ón y de agrupamiento Además de simplemente extraer deten¡inadas tr.rplas y atributos de una o rnás relaciones, a menudo nos interesa realizar algún tipo de resumen o agregación de los datos, de forma similar a ios totales que aparecen en la parte inferior de un informe. En otras ocasiones, nos interesa agrupar los datos, de fbnna similar a los subtotales de ur informe. Estas operaciones no pr,ieden reaiizarse utilizando las operaciones básicas del álgebra relacional que hemos expuesto anteriormente. Sin embargo, se han propuesto otras operaciones adicionales. corno se explica a continuación.
*,§¡
,
.
a.
-
Operaciones de agregac¡ón
,:I1,1
:: )
:
.a-
Aplica la lista de funciones de agregación, AL, a la relación R para definir una rela-
So.(R)
ción sobre la lista de agregación. AL contiene una o más parejas (, ).
I :.r, I .::
Las principales fimciones de agregación son:
I f I I I
lI !
COUNT: devuelve el número de valores en el atributo asociado. SUM: devuelve la suma de los valores en el atributo asociado. AVG: devuelve la rnedia de los valores en el atributo asociado.
MIN: devuelve el valor más pequeño en el atributo asociado. MAX: devr"relve el valor máximo en el atributo asociado.
Ejem - -i..
?:-nt,
: Ejemplo 4.12 Operaciones de agregación (a) ¿Cuánto.s inmuebles tienen un precio de alcluiler superior a 350 euros por mes? Podemos utilizar la función de agregación COUNT para generar la relación R rnostrada en la Figura l3(a). de la fonna siguiente:
4.
po(myCount)
J
couNr
properyno
(orenr.
350
(PropertyForRent))
(b) Localizar los valores mínimo, máximo y medio de los salqrios de los empleados. Podemos utilizar las funciones de agregación MlN, MAX y AVERAGE para producir la relación R rlostrada en la Figura 4. 13(b), de la forma siguiente: po(myCount, myMax, myAverage)
J
vlN sarary MAX saiav AVER,rct
(Stáff) "arary,
/
geb
Capítuto
+
Álgebra relacional y cálculo relac¡onat 91
myMin
myMax myAverage
9000
30000
17000
(b)
Figura 4.13. Resultado de las operaciones de agregación: (a) determinación del número de inmuebles cuyo alquiler es super¡or a 350 euros; (b) determinación de los salarios mínimo, máximo y medio para los empleados.
-r-"*
J
Operación de agrupac¡ón ooSo.(R)
rudo nos inteaparecen en rilar a los subas del álgebra s adicionales, .e
-:
Agrupa las tuplas de la relación R según los atributos de agrupación, GA, y luego aplica la lista de funciones de agregación AL para definir una nueva relación. AL contiene una o más parejas (, ). La relación resultante cont¡ene los atributos de agrupación, GA, junto con los resultados de cada una de las funciones de agregación.
tbrma general de la operación de agrupación es d1, a,2, . . ., án ] .npup,,.&ro',. . ., .¡.".' (R)
1a
siguiente:
R es cualquier relación, at, á2, .. ., an son atributos de R con respecto a los cuales hay que agrupar, ap, ., á, son otros atributos de R y Ao, Aq, . . ., A, son funciones de agregación. Las tuplas de R se particionan ::. grupos de foma tal que:
:¡nde
2,.. inir una rela;ión_agrega-
r r
todas las tuplas de cada grupo tienen el misuto valor de
á1, d2;
.
.1an,
las tuplas de los diferentes grupos tienen diferentes valores de a,,
ar,
. .,
?n.
Vamos a ilustrar el uso de la operación de agrupación con el siguiente ejemplo.
[I
Ejemplo
4.13 Operación de agrupación
Calcular el número de empleados Ete trabajan en cada sucursal y la suma de sus salarios. Primero necesitamos agrupar las tuplas de acuerdo con el número de sucursal, branchNo, y luego emplear las funciones de agregación COUNT y SUM para generar la relación requerida. La expresión de álgebra relacional correspondiente sería: p*(brachNo, myCount, mySum)
bmnc¡ro
J
couNr sbñNo, srrM sar",y
(Staff)
La relación resultante se muestra en la Figura 4.14. Ia Figura
'lación
R
lrF -
myCount
branchNo
mySum
8003
j
54000
B00s
2
39000
8007
I
9000
Figura 4.14. Resultado de la operación de agrupación para calcular el número de empleados que trabajan en cada sucursal y la suma de sus salarios.
92
Sistemas de bases de datos
4.1.6 Resumen de las operaciones de álgebra relacional
4.2
Las operaciones de álgebra relacional se resumen en la Tabla 4.1.
En las e: vez impl ción de fugar de
Tabla Operación
Notación
4.1.
Operaciones en el álgebra relacional.
Función
Selccción
on,.4,.",.(R)
Produce una relación que contiene únicarnente acluellas tuplas de R que satisfaccn el predicudo especificado.
Proyección
ll",'
Producc una relación que contiene un subconjunto vertical de R, extrayendo los valores de los atributos especificaclos y elininanclo los duplicados.
RUS
Unión
Diltrencia
""(R)
cle
R-S
Produce una lelación quc conticnc todas las tuplas dc R quc no sc cucucntran en S. R y S deben scr cornpatiblcs con rcspccto a la unión.
RnS
Ploducc nna rclación que conticne todas las tuplas qLre se encuerltran tanto c¡n R como en S. R y S deben ser cornpatibles con respccto a la unión.
conj untos
lnte¡secoión
Productcr
RXS
Produce nna relación quc cs la concatcnación dc todas las tr.rplas cic la rclación R con cada trlpltr de la relaci(rn S.
RD{nS
Pt-oduoe una relación quc conticnc las tuplas del produoto cartesiano cle R y S que satisf-acen el prcdicado F.
caltesiano Combinación
Procluce una relación que contiene todas las tuplas dc R o S, o las ruplas que estén tal1to en R como en S, climinando las tuplas duplicaclas. R y S deben scr cornpatiblcs con rcspecto a la ur-rión.
thcta [,qr.Licornbirrac ión
R D-
Produce una fclación que contiene las tuplas de] producto cartesiano dc R y S cluc satisfaccn cl prcdicaclo F (que sólo contiene comparaciones de igualdacl).
Combinación natnral
R >,
Una eqr"ricorr-rbinación dc las dos rclacioncs R y S sobre todos los atributos comuncs x. Sc climina uno de los ejernplares de cada atributo comÍrn.
Combinación cxtcrna (izquierda)
R>
S
ern icombinac
Drvisión
Agregación
Agrupación
El cá foma su las bases
ginalmo En
l¿
mentos-
proposir White ga daderos
White);
r
Beech). Si un do para-r
ralores, l
John Wh p€rsona (
SiPr ¡delafc {x
Podel
NNOT) pr
4-2-1 En el cál sea verd¿
Una cornbinación en la que las tuplas de R clue no tienen valores correspondicntcs cn S para los atributos corrllnes sc incluycn también en la relación resultante.
ble que 't &s son 1,
Se el rar ión
R tr,.S
Produce tura rclación que contiene las tr.rplas de R que parlicipan en la cornbinación de R con S y que satisfaccn cl prcdicado 1r.
R-S
Produce una relación conlpucsla pol cl conjnnto de tuplas de R definidas sobre los atributos C c¡uc sc comcspondcn con la combinación de TODAS las tuplas de S, siendo C el conjr-rnto de atributos prescntes en R pero no en S.
lo.(R)
,,ojo.(R)
Aplica la lista de tirncioncs dc agrcgación, AL. a la relación de R para definir una relación sobrc Ia lista de agregaci(rn, AL conticnc una o más parcjas (, ). Agrupa las tupias de la rclación R scgÍrn los atributos de agr-upaciór-r, GA, y luego aplica la lista dc flnciones de agregación AL para deflniruna nucva rclación. AL contiene una o más palcjas (<ñlnción-agrc'_qación>, ). La rclación rcsult¿rnte contiene los atributos dc agr-r-rpaciór-r, GA, junto con los rcsultados dc cada una dc las funciones cle agregación.
51¡
Para
e
ecribir: {s
,F'se d
¡onsulta'
dos que g
{s S.salar
como sala
{s
Capítulo
4
Átgebra relac¡onal y cálculo relac¡onat 93
4.2 El cálculo relacional -: las expresiones del álgebra relacional siempre
se especifica de
forma explícita un cierto orden,
1o
que a su
:z implica una cierta estrategia para evaluar la consulta. En el cálculo relacional, no existe ninguna descrip",¡n de cómo evaluar una consulta. Las consultas de cálculo relacional especifican quéhay que extraer, en
que satisfa-
rayendo los
ls que estén ser compa-
luentran en
tanto en R
relación R
--iar de cómo exlraerlo. El cálculo relacional no está relacionado con el cálculo diferencial e integral de las Matemáticas, sino que ,:na su nombre de una rama de la lógica simbólica denominada cálculo de predicados. Cuando se aplica a .-. bases de datos, se 1o puede encontrar en dos formas: cálculo relacional de tuplas, que fue el propuesto ori..:aimente por Codd (1912a), y cálculo relacional de dominios, propuesto por Lacroix y Pirotte (1971). En la lógica de primer orden o cálculo de predicados, un predicado es una ftlnción booleana con argur 3ntos. Cuando asignamos valores a los argumentos, la función nos proporciona una expresión, denominada :,roposición que puede ser verdadera o falsa. Por ejemplo, las frases 'John White es un empleado'y 'John i. rite gana más que Ann Beech'son ambas proposiciones, ya que podemos determinar si son enunciados ver-'ieros o falsos. En el primer caso, tenemos una función, 'es un empleado', que tiene un argumento (John ,:te); en el segundo caso, tenemos una función, 'gana más que', con dos argumentos (John White y Ann
: .:ch). Si un predicado contiene una variable, como en la frase 'x es un empleado', debe existi¡ un rango asocia: - l3ra;r. Cuando sustituimos n por algunos valores de este rango, la proposición puede ser cierta; para otros :-Jres, puede que sea falsa. Por ejemplo, si el rango es el conjunto de todas las personas y sustituimos x por . .:,r White, la proposición 'John White es un empleado'es verdadera. Si sustituimos rr: por el nombre de una :isona que no sea un empleado, la proposición será falsa. Si P es un predicado, entonces podemos escribir el conjunto de todos los x tales que P es verdadero para ie la forma siguiente:
RySque
{x lP(x)}
Podemos conectar unos predicados con otros mediante los conectores lógicos
RySque l). los comu-
\OT) para formar predicados compuestos.
A (AND), V (OR) y .-
4.2.1 Gálculo relac¡onal de tuplas el cálculo relacional de tuplas, 1o que nos interesa es iocalizar las tuplas para las que un cierto predicado verdadero. Este cálculo está basado en el uso de variables de tuplas. Una variable de tupla es una varia- -: que 'toma sus valores' en una determinada relación. Es deci¡ una variable cuyos únicos valores permitil,rs son las tuplas de Ia relación. Por ejemplo, para especificar el rango de una variable de tupla S de forma --.re el rango sea la relación Staff, escribiríamos:
-: .pondien:sultante.
.:¡
ornbina-
Staff(S)
Para expresar la consulta 'Extraer el conjunto de todas las tuplas S tales que F(S) sea verdadera', podemos as sobre
;plas de
=.,'ribir:
is lF(s» ,E se
inir una parejas
-
denomina fórmula (fórmula bien formad a,
et la lógica matemática). Por ejemplo, para expresar la
--nsulta 'Extraer los valores de staffNo, fName, lName, position, sex, DOB, salary y branchNo para todos los emplea-
l,rs que ganen más de 10.000 euros', podemos escribir: r luego ón. AL
:lación Cos de
{S I Staff(S) A S.salary > 10000} S.salary significa el valor del atributo salary para la variable de tupla S. Para extraer un atributo concreto, :.rmo salary, escribiríamos: {S.salary lStafr(S)A S.salary
> 10000}
94
Sistemas de bases de datos
Los cuantificadores ex¡stencial y universal
Pod<
Existen dos cuantificadores que podemos utlTizar con las fórmulas para decir a cuántas instancias se aplica el predicado. El cuantificador existencial I ('existe') se utiliza en las formulas que deben ser ciertas pira al menos u¡a instancia, como en:
A (lB) (Branch(B) A (B.branchNo : S.branchNo) A B.city : .London') Esta fórmula significa: 'Existe una tupla de Branch que tiene el mismo valor de branchNo que el valor de branchNo correspondiente a la tupla actual de Staff, S, y cuya ciudad correspondiente es Londres'. El cuantificador universal V ('para todo') se utiliza en enunciados que deben ser ciertos para todas las instancias, como Staff(S)
rI rS r!
en:
(VB) (B.city
#
(")
'Paris')
Este enunciado quiere decir: 'Para todas las tuplas de Branch, la dirección no coresponde a parís'. Podemos aplícar una generalización de las leyes de De Morgan a los cuantificaclores existencias y universal. Por ejemplo:
- (VxX-G(x)» (vxxF(x» - - (lxx-(F(x))) (lxxFr(x) A F,(x» - - (Vxx.-G,(x)) v -(Fz(x))) (vxxF,(x) A F2(x» = - (]xx*(F,(x)) v -G,rx)))
r
{ (b)
i
(lxxF(x)) =
{
El
que(
valor Obse
Utilizando estas reglas de equivalencia, podemos reescribir la fórmula anterior como:
-(3s)
(e.city
:
'Paris')
:
:
,London,)}
{s.fruame, s.tName I staff(s) A
(lB)
S es la única variable libre
S se liga a continuación de forma sucesiva con cada tupla de Staff.
(Branch(B) A (B.branchNo
s.branchNo) A B.city
Expresiones y fórmulas AI igual que sucede con los caracteres de cualquier alfabeto, donde algunas secuencias de caracteres no forman una frase correctamente estructurada, también en el cálculo no todas las secuencias de fórmulas son aceptables. Fórmulas son aquellos enunciados que sean no ambiguos y que tengan sentido. Una expresión del cálculo relacional de tuplas tiene la siguiente forma general:
{S,.a,,Sr.ar,...,Sn.ánlF(Sr,Sr,...,S,» m> n donde S,, Sr, . . ., S,, . . ., S. son variables de tupla, cada a,es un atributo de la relación que actúa como rango de s y F es una fórmula. Una fórmula (bien formada) está compuesta de uno o más átomo^s, donde un átomo tiene una de las siguientes formas:
r
R(S), donde
S, es
una variable de tupla y R es una relación.
§.a, 0 §.ar, donde S, y S, son variables de tupla, a1 es un atributo de la relación que actúa como rango de §, a, es un atributo de la relación que actúa como rango d" s, y á es uno de loi operadores de comparación ((, ', ), =, :, *); los atributos a, y a, debentener dominios cuyos miembros puedan compararse mediante á. 5,.a. 0 c, donde
es una variable de tupla, a1 es un atributo de la relación que actúa como rango de §, c es una constante del dominio del atributo a, y 0 es uno de los operadores de comparación.
§
cutar order
cion¡
que significa 'No existe ninguna sucursal situada en parís,. Las variables de tupla cualificadas mediante V o I se denominan variables legadas, mientras que si no están cualificadas se denominan variables libres. Las únicas variables libres de cálculo relacional pueden ser aquellas que estén situadas en el lado izquierdo de la barra"rr,rrrui*p."rión ( | ). Porijemplo, en la siguiente consulta;
y
al
inmu
su c0
(c) E
It l,
urili,
poder
{r
(d) E,
{( Para
r
propi Glas¡
(e) Et
t1
Com¡ Ejemt
aü
qr.
{E
Com¡
Ejemt
Capítulo
+ Álgebra relacional y cálculo relacional
95
Podemos construir recursivamente formulas a partir de los átomos utilizando las siguientes reglas: se aplica rs
para al
valor de )uantifils, como
r r
Un átomo es una fórmula.
I
Si .F es una fórmula con la variable libre X, entonces
, París'.
Fty
Fz
y la negación
-Ft.
lTr'" -l
riversal.
Si,F, y ,F, son fónnulas, también lo son su conjunción Ft A F2, su disyunción
4.14
(IXXO y §x)(F") también son fórmulas.
cátcuto retacionat de tuptas
Enumerar los nombres de todos los gerentes que ganen más de 25.000 euros. {S.fruame, S.lName I Staff(S)
A S.position
:
'Manager'A
S.salary > 25000}
b) Enumerctr los empleados que gestionen inmuebles en alquiler en Glasgow. {S I Staff(S) A
(lP)
(PropertyForRent(P) A (P.staffNo
:
S.stafrNo)
A P.ci§
:
'Glasgow'.
El atributo staffNo de la relación PropertyForRent almacena el número de empleado que gestiona el inmueble. Podemos reformular Ia consulta de la forma siguiente: 'Para cada empleado cuyos detalles queremos enumerar, existe una tupla en la relación PropertyForRent para dicho ernpleado en la que el i'alor del atributo city es Glasgow'. Observe, que en esta formulación de la consulta, no hay ninguna indicación de una estrategia para ejecutar la consulta: SGBD es libre de elegir las operaciones requeridas para satisfacer la solicitud y el orden de ejecución de dichas operaciones. Por otro lado, la formulación equivalente en álgebra relacional sería: 'Seleccionar las tuplas de PropertyForRent tales que el valor de city sea Glasgow y realizar su combinación con la relación Staff', que lleva implícito un orden de ejecución.
lsrno
(c) Enumerar los nombres de los empleados clue no gestionan actualmenÍe ningún inmueble.
o rela-
{S.fName, S.lName I Staff(S) A
guien-
(-(lP)
(PropertyForRent(P) A (S.statttrto = p.staffNo)))}
Utilizando las reglas generales de transformación de cuantificadores que hemos dado anteriormente, podemos reescribir esta consulta como: {S.fName, S.lName I Staff(S) A ((VP) (-PropertyForRent(P)
V -(S.statttrto
= p.staffNo)))}
(d) Enttmerar los nombres de los clientes que hayan visitado un inmueble en alquiler en Glasgow. {C.fName, C.lName I Client(C) A
«lV) (3P) (Viewing(V) A PropertyForRent(P) A (C.cllentNo=V.clientNo)A(V.propertyNo=P.propertyNo)Ae.city='Clasgow')))
r foracep1
cál-
ango
Para responder esta consulta, observe que podemos reformular el enunciado 'clientes que han visto una propiedad en Glasgow'como 'clientes para los que existe alguna visita a algún inmueble situado en Glasgow'.
(e) Enumerar todas las ciudades en las que exista una sucursal o un inmueble en alquiler.
otno
rngo
om-
om-
{T.city | (38) (Branch(B) A B.city = T.city) V GP) (PropertyForRent(P) A P.city = 7.6¡1r;¡
Compare esta formulación con la expresión equivalente en álgebra relacional proporcionada en el Ejemplo 4.3.
(fl
Enumerar todas las ciudades en las que exista una sucursal pero no haya ningún inmueble en alquiler. {a.city ¡ Branch(B) A
3 s,,
(-(lP)
(PropertyForRent(P) A B.city = P.city))}
Compare esta formulación con la expresión equivalente en álgebra relacional proporcionada en el Ejemplo 4.4.
96
Sistemas de bases de datos
(g) Eru.rmerar todas las ciudades en las que haya tanto una sucursal conto al menos un inmueble en
alquiler. {e.city ¡ Branch(B)
/\ ((lP)
(PropertyForRent(P) A B.city = P.city))}
En los si
J
Compare esta fbrmuiación con la expresión equivalente en álgebra relacional proporcionada en el Ejemplo 4.5.
(fd,, (a) Hallc
tfN,lr\
Seguridad de las expresiones
pos
Antes de completar esta sección, debemos mencionar que es posible que una expresión de cálculo genere un conjunto infrnito. Por ejemplo:
{s
|
-
staff(s)}
indicaría el conjunto de todas las tuplas que no se encllentren en la relación Staff. Decimos de tales expresiones que son inseguras. Para evitarlas, tenemos que medir la restricción de que todos los valores que aparezcan en el resultado deben ser vaiores contenidos et el dominio de la expresión.8, lo que se denota dom(E). En otras paiabras, el dominio de E es el conjunto de todos los valores que aparecen explícitamente en E o que aparecen en una o más relaciones cuyos nombres aparecen en E. En este ejemplo, el dorninio de la expresión es el conjunto de todos los valores qLle aparecen en ia relación Staff. Una expresión es segura si todos los valores que aparecen en el resultado son valores pertenecientes al dorninio de Ia expresión. La expresión anterior no es segura porque incluiría, normalmente, tuplas no pertenecientes a la relación Staff (y que por tanto caen fuera del dorninio de la expresión). Todos los demás ejemplos de expresiones de cálcuio relacional de tuplas proporcionados en esta sección son seguros. Algunos autores evitan este problerna utilizando variables de rango que se definen mediante una instrucción RANGE independiente. El lector interesado pLrede consultar Date (2000).
Si
compr
Ejempio fN, . ", b] Por tanto
también
l
do escrib do Staff(P,
dominio' sal, bN), t
En aras d variables (b) Enum
{sN, f
Pr<
Esta cont
4.2.2 Cálculo relacional de dominios
{sN, f Prc
En el cálculo relacional de tuplas, utilizamos variables cuyo rango son todas tuplas de una relación. En el cálculo relacional de dominios, también r.rtilizamos variables, pero en este caso dichas variables toman sus valores de dominios de atributos, en lugar de tomarios de tuplas de alguna relación. Una expresión en el cálculo relacional de dominios tiene la siguiente forma: ldr,
dr,.
.,
d"l F(ü d,,
. , d_)|
En
esta
'Glasgov da para §
(c) Enun
m>n
quile
donded,,dr,...,dn,...,d.representavariablesdedominioyF(dr,dr,...,d,)representaunat'ón¡rulacom{rru,
puesta de átomos, donde cada átomo tiene una de las formas siguientes:
r t '
t
R(d,, dr, . . d, 0 d,,
.,4),
donde
d,
y
donde R es una relación de grado n d,
son variables de dominio
y
y
GI
cada 4 es una variable de dominio.
(i es uno de los operadores de comparación
:, +);los dorninios { y d, deben tener miembros qlre puedan compararse
mediante
t
(<, =, >, =,
(d) Enun
d.
tfN,
t
Vit
d, 0 c, donde d, es una variable de dominio, c es una constante del dorninio de d,y 0 es uno de los operadores de comparación.
(cl
Podemos construir formulas de manera recursiva a partir de átomos utilizando las siguientes reglas:
(e) Enut
¡ I
(fl
I
Un átomo es una tórmula.
f', y F, son fonnulas, -Ft.
Si
{ctY
también 10 son su conj unción F I A F2, su disyunción F t V Fz y la negación
Si F es una fónnula con la variable libre
Enut
quilt
X
entonces
(IXXO y (V&(F) también son fórmulas.
{ctY
G
Capítuto
I
I
Ejemplo
+
Álgebra relacionat y cálculo retaciona! 97
4.15 Cálculo relacional de dominios
En los siguientes ejemplos, utilizamos la siguiente notación abreviada: I
J
(30,, dr,. . ., d,) en lugarde (30,), (a)
(ldJ, . .., (fd,)
Hallar los nombres de todos los gerentes
que ganen más de 25.000 euros.
ffN, lN | (3sN, posn, sex, DOB, sal, bN) (Statf(sru, fN, lN, posn, sex, DOB, sal, bN) A posn ='Manager' A sal > 25000)) E
LIN
sio-
fez-
.En que
;ión
sal rte-
Si comparamos esta consulta con la consulta equivalente en cálculo relacional de predicados del Ejemplo 4.12(a), vemos que a cada atributo se le asigna un nombre (variable). La condición Staff(sN, N, . . ., bN) garantiza que las variables de dominio están restringidas a ser atributos de la misma tupla. Por tanto, podemos usar la formula posn : 'Manager', en lugar de Staff.position : 'Manager'. Observe también la diferencia en el uso del cuantificador existencial. En el cálculo relacional de tuplas, cuando escribimos 3posn para alguna variable de tupla posn, ligamos la variable a la relación Staff escribiendo Staff(posn). Por el contrario, en el cálculo relacional de dominios, posn hace referencia a un valor del dominio y permanece sin restringir hasta que aparecen en la subfórmula Staff(sN, fN, lN, posn, sex, DOB, sal, bN), momento en que queda restringida a los valores de position que aparecen en la relación Staff. En aras de la concisión, en los ejemplos restantes de esta sección cuantiñcaremos únicamente aquellas variables de dominio qtre aparezca en una condición (en este ejemplo, posn y sal). (b) Enumerar los empleados que gestionan inmuebles en alquiler en Glasgow.
3111-
ltOGE
{sN, fN, lN, posn, sex, DOB, sal, bN l(3sN1, cty) (Staff(sN, fN, lN, posn, sex, DOB, sal, bN) A 'Glasgow')) PropertyForRent(pN, st, cty, pc, typ, rms, rnt, oN, sN1, bNf ) A (sN = sN1) A cty
:
Esta consulta también puede escribirse como:
rei SLIS
rel
{sN, fN, lN, posn, sex, DOB, sal, bN | (Staff(sN, fN, lN, posn, sex, DOB, sal, bN) A PropertyForRent(pN, st, 'Glasgow', pc, typ, rms, rnt, oN, sN, bN1)))
En esta versión, la variable de dominio c§ en PropertyForRent ha sido sustituida por la constante 'Glasgow'y la misma variable de dominio sN, que representa el número de empleado, ha sido repetida para Staff y PropertyForRent. /c) Enumerar los nombres de los empleados que no gestionan actualmente ningún inmueble en alquiler. {ru,
tru ¡
(3sN) (Stan(sN, fN, lN, posn, sex, DOB, sal, bN) A
(-(3sru1) (PropertyForRent(pN, st, cty, pc, typ, rms, rnt, oN, sN1, bN1) A (sN
:
sN1)))))
td¡ Enumerar los nombres de los clientes Ete hayan visto algún inmueble en alquiler en Glasgow. {fN, lN | (3cN, cN1, pN, pN1, cty) (Client(cN, fN, lN, tel, pT, mR) A Viewing(cN1, pN1, dt, cmt) A PropertyForRent(pN, st, cty, pc, typ, rms, rnt, oN, sN, bN) A
(cN
:
cN1) A (pru
:
pN1) A
cty:
'Glasgow'))
/e) Enumerar todas las ciudades en las que exista una sucursal o un inmueble en alquiler. {cty | (Branch(bN, st, cty, pc) on
y
PropertyForRent(pN, st1, cty, pc1, typ, rms, rnt, oN, sN, bN1))}
'.f) Enumerar todas las ciudades en las que exista una sucursal pero no haya ningún inmueble en alquiler. {cty | (Branch(bN, st, cty, pc) A
(-(lctyt)
;
(PropertyForRent(pN, st1, cty1, pc1, typ, rms, rnt, oN, sN, bNr) A
(cty: ctyt)))))
98
Sistemas de bases de datos
(g) Enunterar tod¿ts las ciudades en la.s que haya tanto una sucursal como al menos un inmueble en
que nos
alquiler.
sión, qt
¡
{cty | (Branch(bN, st, cty, pc) A
(3ctyt) (PropertyForRent(pN,
st1,
ctyl, pc1, typ, rms, rnt, oN, sN, bN1) A (ctv
: ctvt)))) J
Estas consuhas son seguras. Cuando se restringe e1 cálculo relacional de dominios a expresiones seguras, es equivalente al cálculo relacional de tuplas restringido también a expresiones seguras, y ambos son a slr vez eqr"rivalentes al álgebra relacional. Esto quiere decir que, para toda expresión del álgebra reiacional, existe una
¡
Aunque el cálculo relacional resulta difícil de comprender y de utilizar, sí que resultó claro desde el principio que su propiedad no procedimental resulta enonnemente deseable, lo que a sLr vez ü'ajo consigo una búsqueda de otras técnicas no procedimentales que fueran más fáciles de utilizar. Esto condujo al surgimiento de otras dos categorías de lenguajes relacionales: lenguajes orientados a transformación y lenguajes gráficos. Los lenguajes orientados a transformacién son una clase de lenguajes no procedimentales que utilizan relaciones para transformar los datos de entrada en las salidas requeridas. Estos lenguajes proporcionan estructuras fáciles de utilizar para expresar lo que se desea en términos de otra infomración ya conocida. SQUARE (Boyce et a|.,1975), SEQUEL (Chamberlin et aI.,1976) y el derivado de SEQUEL, SQL, son lenguajes orientados a transfbnnación. Hablaremos de SQL en los Capítr"rlos 5 y 6. Los lenguajes gráficos proporcionan al usuario una úlagen o ilustración de la estruclura de la re1¿rción. El usuario rellena un ejemplo de 1o que desea y el sistema devuelve los datos requeridos en dicho fonnato. QBE (Query-By-Example) es un ejemplo de lenguaje grál'rco. Hablarernos de las capacidades de QBE en el Capítulo 7. Otra categoría son los lenguajes de cuarta generacién (4GL), que permiten crear una aplicación persoralizada cornpleta utilizando uur conjunto limitado de comandos en un enlomo amigable y frecuentemente basado en menús {véasela Sección 2.2). Algunos sistemas aceptan algún tipo de lengtaje nahral, que suele ser una versión restringida del inglés, lo que a veces se denomina lenguajes de quinta generación (5GL), aunque estos desarrollos se encuentran todavía en una etapa temprana.
En el
¡
En el ci
atributo
El álget cional (
¡
Los 1en¡ cedime.
Cuestion
-+.1.
¿Cur
1.2.
Expl
álge (a)
(b)
1.3. 1.4.
ción en ténnino de una o más relaciones de base de datos. Sin embargo, formalmente, el álgebra relacional y el cálculo relacional son equivalentes entre sí. Para toda expresión del álgebra, existe una expresión equivalente en el cálculo (y viceversa).
I
ejen
1.5.
Con to, e
1.6.
Defi
cálcr
Exp ejen
Ejercicior
Para los sil
Capítulo 3.
4.8.
Desr
(a)
El cálcr-¡lo relacional se utiliza para medir la potencia selectiva de los lenguajes relacionales. Un lenguaje que pueda utilizarse para producir cualqr"rier relación que pueda obtenerse mediante el cálculo relacional se denomina lenguaje relacionalmente completo. La rnayoría de los lenguajes de consulta relacionales son relacionalmente completos, reciben una potencia expresiva rnayor que el álgebra relacional o que el cálculo relacional, debido a que incluyen operaciones adicionales, corno funciones de cálculo, de resurnen y de ordenación. Las cinco operaciones fundarnentales del álgebra relacional, selecc:ión, proyección, producto cartesiano, unión y diferencia de conjuntos, permiten rcalizar la mayoría de las operaciones de extracción de datos
Expi
thet¿
Resumen del capítulo Ei álgebra relacional es un lenguaje procedimental (de alto nivel): puede utilizarse para decir al SGBD cómo construir una nueva relación a partir de una o más relaciones existentes en la base de datos. El cálculo relacional es un lenguaje no procedimental: puede utilizarse para formular la definición de una rela-
Defi inter
4.7.
I
cr
predica, nada re
expresión equivalente en el cálculo relacional, y para toda tr"rpla o expresión del cálculo relacional de dominios existe una expresión equivalente en el álgebra relacional.
4.3 Otros lenguajes
El cálcr del cálc
(b) (c) (d) (e)
(0
1.9.
Prop
ded
Capítulo eble en
-,:
4 Álgebra relacional y cálculo relacional
99
nos interesan. Además, también disponemos de las operaciones de combinación, interseccióny divi-
,:. que pueden expresarse en lérminos de las cinco operaciones básicas.
t :
cálculo relacional es un lenguaje formal no procedimental que utiliza predicados. Existen dos fonnas -.. cálcu1o relacional: cálculo relacional de tuplas y cá1culo relacional de dominios.
I :
el cálculo relacional de tuplas, 1o que nos interesa es extraer las tuplas para las que un determinado es verdadero. Una variable de tupla es una variable que 'toma sus valores'sobre una detenni',rl relación: es decir, una variable cuyos únicos valores permitidos son las tuplas de dicha relación.
::.Jicado 's seguras.
Il a su vez
r : :l cálculo
ixiste una de domi-
,
I
relacional de dominios, las variables de dominio toman sus valores a partir de dominios de ..'iLrlos, en lugar de a partir de tuplas de relaciones. :leebra reiacional es equivalente desde
e1
punto de vista lógico a un conjunto seguro del cálculo rela-
- - ra1 (y viceversa).
I ,
: lenguajes de manipulación de datos relacionales pueden clasificarse como procedimentales o no pro;cdimentales, orientados a transformación, gráficos, de cuarta generación o de quinta generación.
principio L
búsque-
riento de iflcos. : utilizan crcionan onocida. son len-
l.estiones de repaso ;Cuál es la diferencia entre un lenguaje procedimental y otro no procedimental? ¿Cómo clasificaría el álgebra reiacional y el cálculo relacional?
-
-
-r elación. brm¿1to.
perso-
(a) (b)
relacionahnente completo cierre de
1as
operaciones relacionales
Deñna las cinco operaciones básicas del álgebra relacional. Deñna las operaciones de combinación, intersección y división en términos de estas cinco operaciones básicas. Explique las diferencias existentes entre las cinco operaciones básicas de combinación: combinación theta, equicombinación, combinación natural, combinación extema y semicombinación. Proporcione
]E en el 1
Explique los siguientes ténninos:
ejemplos para ilustrar su respuesta.
-I
Compare y contraste el cálculo relacional de tuplas con el cálculo relacional de dominios. En concreto, explique la diferencia entre las variables de tuplas y de dominio.
(5GL),
-
Defina la estructura de una fórmula (bien formada) tanto en el cálculo relacional de tuplas como en el cálculo relacional de dominios. Explique por qué una expresión del cálculo relacional pnede ser insegura. Ilustre su respuesta con un ejemplo. Explique cómo garantizan qoe las expresiones del cálcr.rlo relacional sean seguras.
SGBT)
ilercicios
El cál-
.,-:
.el11ente
re strele
a
rela-
:lacio,¡esión
- :.
cional rnales 1ue el
ulnen
b
3.
Describa las relaciones que se generarían rnediante
1as
siguientes operaciones de álgebra reiacional:
(a) flnot"r.ro(op,i"",ro(Room)) (b) o,ot r.¡ot"^o = Room n.,.,*.(Hotel X Room) (c) fIn,,.,*","(Hotel X *o,.,.no,",*o = R@m horerNo(Op,ce > ,o(noom))) (d) Guest )< (oo","ro=,1-1",,-,¡¡2,(Booking)) (e) Hotel F ro,",no,",No : Room.horerNo(Opri"", so(Room)) (0 [sues^ame,roterNo(Booking XBoorngsuesrNo=Guesr.suestNo Guest) , f]no,"*o(o"nr= '.onoon'(Hotel))
rgua.je
:iano, dalos
los siguientes ejercicios, utilice el esquema Hotel definido al principio de la sección Ejercicios del
::ttttlo
:9.
Proporcione las expresiones equivalentes en el cálculo relacional de tuplas y en el cálculo relacional de dominios para cada una de las consr.rltas de áigebra relacional indicadas en el Ejercicio 4.8.
lOO
Sistemas de bases de datos
4.10.
Describa ias relaciones que se generarían mediante las siguientes expresiones del cáiculo relacional de tuplas:
(a) (b) (c) (d)
{H.hotelName lHotel(H) A
C,
H.city: 'London'}
(lR) (Room(R) A H.hotelNo : R.hotelNo A R.price > 50)} A (lB) (3G) (Booking(a) n cuest(o) A H.hotelNo : B.hotelNo A
{H.hotelName I Hotel(H) A
{H.hotetName I Hotel(H) B.guestNo G.guestNo A G.guestName
:
:
{H.hotelName, G.guestName, Bl.dateFrom, 82.dateFrom I Hotel(H) A Guest(G) A Booking(B1) Booking(B2) A H.hotelNo: Bl.hotelNoA G.guestNo: B'l.guestNo A B2.hotelNo: Bl.hotelNo B2.guestNo =
B1
.guestNo
=.1
'John Smith'))
A B2.dateFrom +
A A
81 .dateFrom)
4.11. Proporcione
ias expresiones equivalentes en el cálculo relacional de dominios y en el álgebra relacional de dominios para cada una de las expresiones del cálcuio relacional de tuplas indicadas en el
Ejercicio 4.10.
4.12.
Escriba las expresiones de álgebra reiacional, de cálculo relacional de tuplas y de cálculo relacional de dominio correspondientes a las siguientes consultas:
(a) (b) (c) (d) (e) (0 (g)
0bjetivos
Enunerar todos los hoteles.
En este
Enumerar todas las habitaciones individuales cuyo precio sea inferior a 20 euros por noche.
I
Enutrerar los nombres y ciudades de todos los huéspedes.
El pro consul
Enumerar el precio y ei tipo de todas las habitaciones del Grosvenor Hotel.
I I I I
Enumerar todos los huéspedes actualmente alojados en el Grosvenor Hotel.
Enumerar los detalles de todas las habitaciones del Grosvenor Hotel, incluyendo el nombre huésped alojado en la habitación, si es que la habitación está ocr.rpada.
de1
Enumerar los detalles de los huéspedes (guestNo, guestName y guestAddress) para todos los huéspedes alojados en el Grosvenor Hotel.
La his Cómo Cómo Cómo
r uti .or . ut: .aE
4.13. Utilizando el álgebra relacional, 4.14.
c¿
cree una vista de todas las habitaciones del Grosvenor Hotel donde se excluyan los detalles relativos ai precio. ¿Cuáles son ias ventajas de esta vista? Analice los SGBD que esté actualmente utilizando. ¿Qué tipos de lenguajes relacionales proporciona el sistema? Para cada uno de los lenguajes proporcionados, ¿cuáles son las operaciones equivalentes a las ocho operaciones de álgebra relacional definidas en la Sección 4.1?
'ut .cc .re I
Cóm<
-n los Capít
:.r detalle. U
SQL (Struct '.
ertido en
e
Srandard Int
,rtemaciona :rstemas de
ras PC a r¡
Debido t :uaje con ul :e¡a los no
.erentes. Er
:or ISO.
Sir
.:nguaje. Er ;uaje.
culo relacional de
Capítulo
oA ng(er)
n
'rotelNo
A
SQL: manipulación de datos
álgebra relacioindicadas en el ulo relacional de
Objetivos del capítulo: En este capítulo aprenderá:
por noche.
I
El propósito y la importancia del lenguaje SQL (Structured Query Language, Ienguaje estructurado de
I I I I
La historia y el desarrollo de SQL.
consulta).
¡ ei nombre del todos los hués-
Hotel donde es
Córno escribir un comando SQL.
Cómo extraer datos de la base de datos utilizando la instrucción SELECT. Cómo construir instrucciones SQL qtre:
I o o . r o I
se
proporciona
equivalentes a
I
utiiicen la cláusula WHERE para extraer filas que satisfagan diversas condiciones; ordenen los resultados de las consultas mediante ORDER BY' utiiicen las funciones de agregación de SQL; agrupen los datos mediante GROUP BY;
utilicen subconsultas; combinen tablas; realicen operaciones de conjuntos (UNION, INTERSECT, EXCEPT).
Cómo realízar actualizaciones en la base de datos mediante INSER! UPDATE y DELETE.
::
ios Capítulos 3 y 4 hernos descrito el modelo de datos relacional y los lenguajes relacionales con un cier. letalle. Uno de los lenguajes que ha emergido a partir del desarrollo del modelo relacional es el lenguaje
:t-)L (Structured Query Language, lenguaje estructurado de consulta). En los últimos años, SQL se ha con:nido en el lenguaje estándar para las bases de datos relacionales. En 1986, ANSI (American National >:"ndard lnstitute) dehnió un estándarpara SQL que fue posteriormente adoptado en 1987 corno estándar .:emacional por ISO (Intemational Organization for Standardization). Hoy en día hay más de un centenar de :::temas de gestión de bases de datos que soportan SQL sobre diversas plataformas hardware, desde platafor::-¡s PC a mainframes. Debido a la actual importancia de SQL, vamos a dedicar tres capítulos del libro para examinar dicho len:-*a.¡e con un cierto detalle, proporcionando un tratamiento exhaustivo tanto para los lectores técnicos como :'ra los no técnicos, lo que incluye a los programadores, a los profesionales de las bases de datos y a los -erentes. En estos capítulos nos vamos a concentrar principalmente en la definición del lenguaje SQL hecha :'.rr ISO. Sin embargo, debido a la complejidad de este estándar, no pretendemos cubrir todas las partes del .:nguaje. En este capítulo, nos centraremos en las instrucciones de manipulación de datos incluidas en el len=uaje.
1O2 Sistemas de bases de datos
Estructura del capítulo En la Sección 5.1 se introduce SQL y se explica por qué este lenguaje tiene tanta importancia en las aplicaciones de base de datos. En la Sección 5.2 presentaremos la notación ufllizada en el libro para especificar la estructura de instrucción SQL. En la Sección 5.3, veremos cómo extraer datos de las relaciones utilizando SQL, y cómo insertar, actualizar y borrar datos de dichas relaciones. Adelantándonos un poco a los acontecimientos, diremos que en el Capítulo 6 se examinarán otras características del lenguaje, incluyendo la definición de datos, las vistas, las transacciones y el control de acceso. En la Sección 28.4 se examinan en detalle las características que se han añadido a la especificación SQL para soportar la gestión de datos orientada a objetos, 1o que se denomina SQL: 1999 o SQL3. En el Apéndice E se cómo integrar SQL en lenguajes de programación de alto nivel para acceder a estructuras que no han "rplica esiado disponibles en SQL hasta hace relativamente poco. Los dos lenguajes formales, el álgebra relacional y el cálculo relacional, que hemos presentado en el Capítulo 4 proporcionan la base para buena parte de1 estándar SQL, por lo que puede que le resulte útil consultar dicho capítulo ocasionalmente para ver la singularidad
y las similitudes. Sin embargo, la presentación que aquí haremos de SQL es bastante independiente de dichos lenguajes, para aquellos lectores que hayan omitido el Capítulo 4. Los ejemplos de este capítulo ufllizanla instancia de base de datos de alquileres de DreamHome que se muestra en la Figura 3.3.
5.1 lntroducción
a SOL
En esta sección se resumen los objetivos de SQL, se proporciona una breve historia del lenguaje y se explica por qué este lenguaje es tan importante para las aplicaciones de bases de datos.
5.'1.1 Obietivos de SOL ldealmente, un lenguaje de base de datos debe permitir al usuario:
I a
crear la base de datos y las estructuras de relación;
I
realizar consultas tanto simples como complejas.
realizar tareas básicas de gestión de datos, como la inserción, modificación y borrado de los datos de las relaciones;
Un lenguaje de base de datos debe realizar estas tareas requiriendo un esfuerzo mínimo por pafie del usuario, y su sintaxis y la estructura de los comandos deben ser relativamente fáciles de aprender. Finalmente, el lenguaje debe ser portable, es decir, debe ajustarse a algún estándar reconocido, para poder utllizat la misma estructura de comandos y la misma sintaxis cuando pasemos de un SGBD a otro. SQL tiene como objetivo satisfacer estos requisitos. SQL es un ejemplo de lenguaje orientado a transformación, es decir, un lenguaje diseñado para usar relaciones con el fin de transformar los datos de entrada en las salidas requeridas. Como lenguaje, el estándar SQL de ISO tiene dos componentes principales:
I
un lenguaje de definición de datos (DDL, Data Definition Language) para deñnir la estructura de la base de datos y controlar el acceso a los datos;
I
un lenguaje de manipulación de datos (DML, Data Manipulation Language) para extraer los datos.
y acinlizat
Hasta SQL:1999, el lenguaje SQL sólo contenía estos comandos de definición y manipulación; no conte-
níaningúncomandoparacontroldeflujo,comoIF...THEN...ELSE,GOTOoDO...WHILE.Estos comandos tenían que implementarse utilizando un lenguaje de programación o un lenguaje de control de tareas, o bien implementarlos de manera interactiva mediante las decisiones del usuario. Debido a esta falta de completud compufacional, SQL puede usarse de dos formas distintas. La primera forma consiste en utilizar
SQL interactivamente introduciendo las instrucciones en un terminal. La segunda forma consiste en incrus-
Capítulo
ica-
rla
SOL: manipulación de
datos
103
',;r instrucciones SQL en un lenguaje procedimental, como se explica en el Apéndice E. Hablaremos también :: SQL:1999 y de SQL:2003 en el Capítulo 28. SQL es un lenguaje relativamente fácil de aprender:
r
ndo :ac)so.
ise 1an
Se trata de un lenguaje no procedimental: 1o que especificamos es qué tnformación queremos, en lugar de especificar cómo obtenerla. En otras palabras, SQL no requiere que se especifique el método de acceso a los datos.
r
Al igual que la mayoría
I
La estructura de los comandos está compuesta por palabras inglesas normales, tal como, CREATE TABLE, INSERT, SELECT. Por ejemplo:
tafa
Lly
de los lenguajes modemos, SQL es de formato prácticamente libre, lo que quiere decir que las diversas partes de las instrucciones no tienen por qué ser escritas en ubicaciones concrelas de la pantalla.
. . .
inlad ros
la
r -tl
5
CREATE TABLE staff (staffNo VARCHAR(5), tName VARCHAR(15), INSERT INTO Staff VALUES ('SG16', 'Brown', 8300); SELECT staffNo, lName, salary FROM stan WHERE salary > 10000;
satary
DECIMAL(7,2));
SQL puede ser utilizado por diversos tipos de usuarios, incluyendo administradores de bases de datos
(DBA), personal administrativo, desarrolladores de aplicaciones y muchos otros tipos de usuario final. Hoy en día existe un estándar intemacional para el lenguaje SQL, 1o que hace que sea tanto el lenguaje =.:ándar formal como el estándar defacto para la definición y manipulación de bases de datos relacionales ,
>O. 1 992, 1999a).
5.1.2 Historia de SOL ---,¡ro hemos indicado en el Capítulo 3, la historia del modelo relacional (e indirectamente de SQL) comen¡on la publicación del artículo original de E. F. Codd, mientras éste trabajaba en el laboratorio de investi-'-'ión de IBM en San José (Codd, 1970). En 1974,D. Chamberlin, también del laboratorio San José de IBM, -..nió un lenguaje denominado Structured English Query Language (lenguaje de consulta en inglés estruc--.do) o SEQUEL. En 1976 se definió una versión revisada, SEQUEL/2, pero posteriormente se cambió el .:rbre a SQL por razones legales (Chamberlin y Boyce, 1974; Chamberlir et aL.,1976). Hoy en día, muchas :tr:sonas en el mundo anglosajón siguen pronunciando SQL como 'sicuel'(que es la pronunciación inglesa de
-
::
IUEL).
:
.BM desarrolló un SGBD prototipo basado en SEQUEL/2, denominado System R (Astrahan et a\.,1976). :;opósito de este prototipo era validar la factibilidad del modelo relacional. Además de sus otros éxitos,
- .je los resr.rltados más importantes que se han atribuido a este proyecto es el desarrollo de SQL. Sin embar-,. .¿s raíces de SQL se encuentran en el lenguaje SQUARE (Specifoing Queries As Relational Expressions, :.:ecificación de consultas como expresiones relacionales), que es anterior al proyecto System R. SQUARE --: diseñado como lenguaje de investigación para implementar el álgebra relacional mediante fiases en inglés :,rr ce el al., 197 5). -\ finales de la década de 1970, la empresa que ahora se denomina Oracle Corporation desarrolló el siste,' de bases de datos Oracle, que fue probablemente la primera implementación comercial de un SGBD rela- -,ral basado en SQL. Poco después aparecería INGRES, con un lenguaje de consulta denominado QUEL, - -i aunque está más 'estructurado' que SQL, se parecía menos al idioma inglés. Cuando SQL se consolidó - - ro el lenguaje estándar de base de datos para sistemas relacionales, INGRES fue convertido en un SGBD :.sado en SQL. IBM desarrolló sus primeros SGBD comerciales, denominados SQL/DS para los entomos -,JS/VSE y VM/CMS en 1981 y 1982, respectivamente, y posteriormente desarrolló DB2para el entomo l|S en 1983. En 1982, ANSI (American National Standards lnstittrte, instituto nacional americano de normalización) -,menzó atrabajar en un lenguaje de bases de datos relacional (RDL, Relational Database Language) basa-.-
1O4 Sistemas de bases de datos do en un artículo publicado por IBM. ISO se unió a esta tarea en 1983 y ambas organizaciones definieron conjuntarnente un estándar para SQL (el nombre RDL fue abandonado en 1984 y el borrador de estándar adoptó una fbnna más parecida a las implementaciones existentes de SQL). El estándar ISO inicial publicado en 1987 atrajo numerosas críticas. Date, un investigador muy influyente en este área, criticó que se hubieran omitido características importantes tales como las restricciones de integridad refbrencial y ciertos operadores relacionales. También señaló que el lenguaje era extremadamente redr.rndante; en otras palabras, que había más de una forma de escribir una rnisma consuita (Date, 1986, I 987a, 1990). Muohas de estas críticas eran válidas y fr,reron adrnitidas por las organizaciones de normalización antes de que el estándar f'uera publicado. Sin embargo, se decidió que lo más irnportante era promulgar un estándar lo antes posible para establecer una base cornún a partir de la cual pudieran desarrollarse el lenguaje y las implernentaciones, en lugar de esperar a que se definieran y se acordaran todas las características que deter-
llsem,
minadas personas pensaban que debían estar presentes. En 1989, ISO publicó un apéndice que deñnía una'característica de mejora de la integridad'(ISO, 1989). En 1992 tuvo lugar la primera revisión principal del estándar ISO, que a veces se denominan SQL2 o SQL92 (lSO, 1992). Aunque algunas características se definían por primera yez et esta versión del estándar, rnuchas de ellas ya habían sido implerrentadas de forma parcial, o mediante mecanismos parecidos, en una o más de las implementaciones SLQ disponibles. No fue hasta 1999 que se fonnalizó la siguiente versión del estándar, a la que comúrnmente se denomina SQL: 1999 (ISO, 1 999a). Esta versión contiene características adicionales para soportar la gestión de datos orientada a objetos, de la que hablaremos en la Sección 28.4. A finales de 2003 se pr.rblicó una nueva versión SQL:2003. Todas las características adicionales al estándar proporcionadas por los fabricantes de bases de datos se denominan extensiones. Por ejemplo, el estándar especifica seis tipos de datos diferentes en una base de datos SQL, mientras que muchas implementaciones complementan esta lista con diversos tipos de extensiones. Cada implementación de SQL se denomina dialecto. No hay dos dialectos exactamente iguales, y ninguno de los dialectos actualmente existentes se adapta de fbrma exacta al estándar ISO. Adernás, a medida que los t'abricantes de bases de datos introducen nuevas funcionalidades, arnplían sus dialectos SQL y hacen que se diferencien todavía más de los restantes. Sin embargo, la parte fundamental del lenguaje SQL muestra signos de estar cadavez más estandarizada.De hecho, SQL:2003 tiene un conjunto de características denomiuado Core SQL que los fabricantes deben obligatoriamenle implementar para poder decir qr.re se adaptan al estándar SQL:2003. Muchas de las restantes características están divididas en paquetes; por ejemplo, hay paquetes para las características de orientación a objetos y para OLAP (Onl-ine Analytical Processing, procesamiento analítico en línea). Aunque SQL fire originalmente un concepto desarrollado en IBM, su importanciahizo que otros fabricantes crearan muy rápidamente sus propias irnplementaciones. Hoy en día, existen literahnente cientos de produrotos basados en SQL, introduciéndose nuevos productos con una cierta fiecuencia.
*.minos
5.1.3 lmportanc¡a de SOL
I
SQL es el prirner, y hasta ahora único, lenguaje estándar de base de datos que ha tenido una amplia aceptación. El útnico otro lenguaje estándar de base de datos, NDL (Network Database Language, lenguaje de base de datos en red), basado en el modelo en red CODASYL, tiene pocos seguidores. Casi todos los fabricantes de bases de datos principales proporcionan productos de base de datos basados en SQL o con una itterfaz SQL, y la mayoría están representados en al menos una de las organizaciones de normalización. Se ha realizado una enoñne inversión en el lenguaje SQL tanto por pafie de los fabricantes como de los usuarios. EI lenguaje SQL ha pasado a fomrar parte de arquitecturas de aplicación tales como SAA (Systems Application Architecttrre) de IBM y es la opción estratégica elegida por muchas organizaciones de gran tamaño y de considerable influencia, colno por ejemplo el consorcio YOPEN para la estandarización de UNIX. SQL también es un estándar FIPS (Federal Information Processing Standard), lo cual es obligatorio para todas las ventas de sistemas SGBD al gobiemo de los Estados Unidos. SQL Access Group, un consorcio de fabricantes, ha definido una serie de ampliaciones de SQL para permitir la interoperabilidad entre sistemas heterogéneos. SQL se utiliza en otros estándares e incluso influye sobre el desarroilo de otros estándares como herrarnienta de definición. Como ejernplos podemos citar el sistema IRDS (Information Resource Dictionary
sl
Lsess, ac ¡mrmidat it
=spara a-ión de &SQLdi' o'aalíticr
5.1.4 Et es¡ánda d
hi"ryminol
delo
rel
doder¡¡
l mite
r
á2E
Er ega so
mpafi Lt ¡esel bsQLy
ñilirse t Érus rq §*rrmá+
ül¡na§
pese util Iza el pn I.ama
-r qrc ql drctpciq
rFEcE[ IxÉ
-\uqi 3 ¡ñliz¡r
¡ca lel t§
sa
En
es
§rFq ¡sr g
!s Iu
rE ¡t
Capítulo n,tó
nete a.
IS
r-
t, 0 ,l
datos
105
-ralítico en línea).
5.1.4 Terminología :
-s;ándar SQL de ISO no utiliza los términos formales de relaciones, atributos y tuplas, sino que emplea los columnas y filas. En nuestra presentación del lenguaje SQL utilizaremos principalmente - .:rminología de ISO. Tenga tarnbién en cuenta que SQL no se adhiere de manera estricta a la dehnición del '- ,¿¿1o relacional descrito en el Capítulo 3. Por ejemplo, SQL permite que las tablas producidas como resul.---, de unas instrucciones SELECT contengan filas duplicadas; asimismo, impone un orden a las columnas -:rnite al usuario ordenar las filas de una tabla de resultados.
:
).
SOL: manipulación de
,,ein, sisterna de diccionario para recursos de información) de ISO y el estándar RDA (Rernote Data ---3ss, acceso remoto a datos). El desarrollo del lenguaje cuenta con un considerable apoyo porparte de la -unidad académica, lo que proporciona tanto rma base teórica para el lenguaje como las técnicas necesa-: par& implementarlo de manera satisfactoria. Esto es especialmente cierto en 1o que respecta a la optimi,,.rrfl de consultas, la distribución de datos y la seguridad. Existen ahora implementaciones especializadas -. SQL dirigidas a nuevos mercados, como por ejemplo OLAP (Onl-ine Analytical Processing, procesamien-
ls 1r
5
.:-,.nos de tablas,
5.2 Escritura de comandos SOL : - :sta sección, vamos a describir brevemente la escritura de una instrucción SQL y la notación que utiliza': i.rrS por& definir el formato de las diversas estructuras SQL. Una instrucción SQL está compuesta por pala::¡: reservadas y palabras definidas por el usuario. Las palabras reservadas son una parte fija del lengua' iQL y tienen un significado también fijo. Deben escribirse exactaruente como se indica y no pueden - Jirse entre varias líneas. Las palabras definidas por el usuario son compuestas por éste (de acuerdo con .: as regias sintácticas) y representan los nornbres de diversos objetos de la base de datos, como tablas, . -mnas, vistas, índices, etc. Las palabras qLie componen una instrucción también se combinan de acuerdo . - Lrna serie de reglas sintácticas. Aunque el estándar no obliga a ello, muchos dialectos de SQL requieren - -. se utilice un terminador de instrucción para marcar el final de cada instrucción SQL (normalmente se uti-
-, -:l
punto y coma';'). mayoría de los componentes de una instrucción SQL no distinguen entre mayúsculas y minúsculas, :,ue quiere decir que se pueden escribir cualquiera de las ietras en cualquiera
r I I
cada cláusula de una instrr-¡cción debe comenzar en una nueva línea; el principio de cada cláusula debe estar alineado con el comienzo de las cláusulas restantes;
si una cláusula tiene varias partes, cada una de ellas debe aparecer en una línea distinta y debe estar sangrada con respecto al comienzo de la cláusula, para que se vea claramente la relación.
En este capítulo y en el siguiente, utilizaremos la siguiente forma ampliada de la notación BNF (Backus ,;r Form) para definir las instrucciones SQL:
I I I r r
se usarán letras en mayirsculas para representar las palabras reservadas, las cuales deben escribirse exactamente como se indica; se usarán letras en minúsculas para representar las palabras
deñnidas por el usuario;
(
) indica una elección entre diversas altemativas; por ejemplo, a I b ] c; las llaves indican un elemento obligatorio; por ejemplo, {a};
una barra vertical
los corchetes indican un elemento opcional; por ejemplo, [a];
1OO Sistemas de bases de datos
I
los puntos suspensivos (
:l
) se emplean para indicar la repetición opcional de un elemento cero o
más veces.
vaior d
.:spondier ,-.is colutn
-:
Por ejempio:
:
{alb}(,c...) significa a o b segr.ridas de cero o más repeticiones de c, separadas por comas. En la práctica, las instrucciones DDL se utilizan para crear la estructura de la base de datos (es decir, las tablas) y los mecanismos de acceso (es decir, para especificar a qué cosas puede cada usuario acceder legalmente), y luego se emplean las instrucciones DML para rellenar las tablas y para consuitarlas. Sin embargo, en este capítr-rlo vamos a presentar el lenguaje DML antes que las instrucciones DDL para reflejar la importancia que las instrucciones DML tienen para el usuario non¡al. Hablaremos de las instrucciones DDL en el
:ii
es.
5.3.1 c : -
'
.
::rrpósito
. -,
<
:-rios. Se t -:e Se/ec'c,
SELEC-
siguiente capítu1o.
SELECT
5.3 Manipulación
de datos
FRO}T
i\\ HERI
En esta sección se examinan las inslrucciones DML de SQL, es decir:
I f r I
iGROUP
SELECT - para consultar los datos de la base de datos; INSERT - para insertar datos en una tabla; UPDATE - para actualizar los datos de una tabla;
DELETE - para borrar datos de una tabla.
ioRDER . - - -.,4^t..t
,.'
Debido a la complejidad de la instrucción SELECT y a la relativa simplicidad de las otras instrucciones
: ?-(-)\l
DML, varnos a decidir la mayor parte de esta sección a la instrucción SELECT y a sus varios formatos.
.
Comenzaremos considerando una serie de consultas sinples e iremos añadiendo sucesivamente mayor complejidad, para rnostrar cómo pueden generarse consultas más complicadas que empieen mecanisrnos de ordenación, agrupaciones, agregaciones y también consultas sobre rnirltiples tablas. Tenlinaremos el capítrilo analizando las instrucciones INSERT, UPDATE y DELETE. Varnos a ilustrar las instrucciones SQL utilizando la instancia del caso de estudio DreamHome que se mLlestra en la Figura 3.3, que está compuesta de las siguientes tablas: Branch
(branchNo, street, city, postcode)
Staff
(staffNo, fName, lName, positron, sex, DOB, salary, branchNo)
PropertyForRent (oropertyNo, street, c¡ty, postcode, type, rooms, rent, ownerNo, staffNo, branchNo)
Client
(clientNo, fName, IName, telNo, preffype, maxRent)
PrivateOwner
(ownerNo, fName, lName, address, telNo)
Viewing
(clientNo, propertyNo, viewDate, comment)
Literales Antes de hablar de las instrucciones DML de SQL, es necesario comprende el concepto de literales. Los literales son constantes que se utilizan en ias instrucciones SQL. Hay dit'erentes formas de literales para todos ios tipos de datos soportados por SQL (véasela Sección 6. l.l). Sin embargo, en aras de las simplicidad, podemos distinguir entre literales encerados entre comillas simples y aquellos otl'os que no lo están. Todos los valores de datos no numéricos deben estar encerrados entre cornillas sirnples; todos los valores de datos nunéricos no deben estar encerrados entre comillas simples. Por ejernplo, podemos utilizar literales para insertar d¿rtos en una tabla:
INSERT INTO
PropertyForRent(propertyNo,
street, city, postcode, type, rooms, rent, ownerNo,
staffNo, branchNo)
VALUES ('PAi4', '16 Holhead', 'Aberdeen', 'AB7 5SU', 'House', 6, 650.00, 'CO46' , 's49"'8007',);
Je b¿:
-:-:7ac,a.
.
1ERE
- --ir-iL.P
I\L ': -'C '
--:,'r
.-.f
:. "--:
:R
-:¿:: :-l'.
"
,':"dg :' i.
rtracci
Capítulo [o cero o
5
SOL: manipulación de
datos
1O7
El valor de la columna rooms es un literal entero, mientras que el valor de la columna rent es un literal :orespondiente a un número decimal; ninguno de los dos están encerrados entre comillas simples. Todas las lemás columnas son cadenas de caracteres, por lo que se utilizan comillas simples para encerrar los valores
'':erales.
Jeci¡ las ler legal-
:mbargo, a impor-
DL en el
5.3.1 Gonsultas s¡mples :i
propósito de la instrucción SELECT consiste en extraer y visualizar datos de una o más tablas de la base datos. Se trata de un comando extremadamente potente, capaz de realizar el equivalente de las operacio:.es de Selección, Proyección y Combinación del álgebra relacional en una única instrucción (véase la Sección r. 1). SELECT es el comando SQL más frecuentemente utilizado y tiene el siguiente formato general:
ic
SELECT FROM [WHERE BY
[ORDER
IDISTINCT
IALLI {*
| [ expresióncolumna [AS nuevoNombre]l
[,...]]
Nombrel'iabla [alias] [,...] condición]
listaColumnas]
:xpresiónColumna representa un nombre de columna o una expresión, NombreTabla es el nombre de una tabla -r vista de base de datos ya existente y ala que se tenga acceso, y atias es una abreviatura opcional para 'rombreTabla.
¡cciones
)nnatos. ,or comde ordeulo ana?
que se
La secuencia de procesamiento en una instrucción SELECT es:
FROM especifica la tabla o tablas que hay que usar WHERE filtra las filas de acuerdo con alguna condición GROUP BY forma grupos de filas que tengan el mismo vaior de columna HAVING filtra los grupos de acuerdo con alguna condición SELECT especifica qué columnas deben aparecer en la salida ORDER BY especifica el orden de la salida El orden de las cláusulas en la instrucción SELECT no puede cambiarse. Las dos únicas cláusulas obliga.ürias son las dos primeras: SELECT y FROM; las restantes son opcionales. La operación SELECT está cerrada: el resultado de una consulta sobre una tabla es otra tabla (véase la Sección 4. I ). Hay muchas varia:iones de esta instrucción, como vamos a ver a continuación.
Extracción de todas las filas
-os lite'a todos l, pode,dos los ; numéinsertar
fI ej"-plo
5.1 Extraer todas las columnas de todas las filas
Generar un listado con lodos los detalles de todos los miembros del personal. Puesto que no se especifica ninguna restricción en esta consulta, la cláusula WHERE será innecesaria
y deben extraerse todas las columnas. Escribiremos esta consulta como: SELECT
FROM
staffNo, fName, lName, position, sex, DOB, salary, branchNo
staff;
Puesto que muchas extracciones de datos en SQL requieren todas las columnas de una tabla, hay una forma rápida de expresar 'todas las columnas'en SQL, utilizando un asterisco (x) en lugar de los nombres de las columnas. La siguiente instrucción es una forma equivalente y más corta de expresar la misma consulta:
--
1O8 Sistemas de bases de datos SELECT X FROM Stafr;
:il
Latabla de resultados en cualquiera de los dos casos es la que Tabla
.
5.1
fName
lName
position
sex
DOB
salary
branchNo
SL2
John
White
Manager
M
1-Oct-45
30000.00
8005
SGJT
Ann
Becch
Assistant
F
10-Nov-60
12000.00
B003
SC I,1
David
Ford
Supervisor
M
24-NIar-58
18000.00
8003
SA9
Mary
Howe
Assistant
F
I
9-Feb-70
9000.00
B007
SG5
Susan
Brand
Managcr
F
3-Jun-40
24000.00
B003
SL¿I I
Julie
Lee
Assistant
F
I
9000.00
B005
lT"*,"
.:d.'
:
Tabla de resultados para el Ejemplo 5.1.
staffNo I
::itn¡
se muestra en la Tabla 5.1.
3-Jun-65
! t :3 tti
.-: -:u\ r
-a
bla
:
__! =
-
5.
--.i¡
!-oper
5.2 Extraer toda una serie de columnas específ¡cas de todas las fitas
Generar una lista con los salarios de todos los empleados en la que sólo se muestre el número de empleado, el nombre, el apellido y los datos salariales.
SELECT
FROM
il::
EIer
staffNo, fName, lName, salary
Staff;
En este ejemplo, se crea una nueva tabla a partir de Staff que contiene sólo las columnas designadas y salary, en el orden especificado. El resultado de esta operación se muesra en la Tabla 5.2. Observe que, a menos que se especifique lo contrario, las filas de la tabla de resultados puede que no estén ordenadas. Algunos SGBD sí ordenan latabla de resultados basándose en una o más columnas (por ejemplo, Microsoft Off,rce Access ordenaría esta tabla de resultados basándose en la clave principal staffNo). En la siguiente sección explicaremos cómo ordenar las filas de una tabla de staffNo, fName, lName
resultados.
Tabla 5.2. Tabla de resultados para el Ejemplo 5.2.
s
t \
.
!¿
t.
. . I --l.L
do
staffNo
fName
lName
salary
: - a,:t
SL2 I
.Tohn
White
30000.00
l-".i
SG37
Ann
Beech
12000.00
Dar"id
Ford
r
SG
I4
8000.00
SA9
Mury
Hou''^
9000.00
SG5
Susan
Brand
24000.00
hrlic
Lcc
SL4
1
9000.00
t-
I
Ejemplo 5.3 Uso de DISTINCT
Generar un listado con lo's números de inmueble de todos los innruebles qtre havan sido visitado.s.
SELECT propertyNo FROM Viewing;
:,:: _i
. !
-
-t-:
--
J.
Capítulo
5
SOL: manipulación de
datos
1O9
Lafabla de resultados se muestra en la Tabla 5.3(a). Observe que hay varios duplicados porque, a diferencia de la operación de proyección de álgebra relacional (véase la Sección 4.1.1), SELECT no elimina los duplicados cuando efectua una proyección sobre una o más columnas. Para eliminar los duplicados, utilizamos la palabra clave DISTINCT. Reescribiendo la consulta como: SELECT DISTINCT
FROM se
propertyNo
Viewing;
obtiene la tabla de resultados mostrada en la Tabla 5.3(b), en la que los duplicados han sido elimi-
nados.
-abla 5.3(a). Tabla de resultados para
:
Tabla 5.3(b). Tabla de resultados para el Ejemplo 5.3, habiendo eliminado los duplicados
Elemplo 5.3 con duplicados.
dc I
I Cas
rla los
ao en de
Ejemplo 5.4 Campos calculados Generar una lista con el salario mensual de todos los empleados en la que se muestre el número de entpleado, el nombre, el apellido y la información salarial.
SELECT
FROM
staffNo, fName, lName, salary/12
Statr;
Esta consulta es casi idéntica al Ejemplo 5.2, con la excepción de que lo que se pide son los salarios mensuales. En este caso, el resultado deseado puede obtenerse dividiendo simplemente el salario por i2, 1o que nos da latabla de resultados mostrada en la Tabla 5.4. Esto es un ejemplo de utilización de un campo calculado (algunas veces denominado campo derivado). En general, para utilizar un campo calculado se especif,rca una expresión SQL en la lista de selección de SELECT. Una expresión SQL puede incluir los operadores de suma, resta, multiplicación y división, y también pueden utilizarse paréntesis para construir expresiones complejas. En una columna calculada pueden usarse más de una columna de la tabla; sin embargo, es obligatorio que las columnas a las que se hagan referencia en una expresión aritmética sean de tipo numérico. La cuarta columna de esta tabla de resultados ha sido impresa con el título col4. Normalmente, las columnas de la tabla de resultados toman su nombre de la columna correspondiente de la tabla de base de datos
Tabla
5.4.
Tabla de resultados para el Ejemplo 5.4.
staffNo
fName
lName
salary
SL2 I
John
White
30000.00
SG37
Ann
Beech
12000.00
sc14
David
Ford
18000.00
SA9
Mary
Howe
9000.00
SG5
Susan
Brand
24000.00
SL41
Julie
Lee
9000.00
--
110
S¡stemas de bases de datos
de la que ha sido extraída. Sin embargo, en este caso, SQL no sabe cómo etiquetar la columna. Algunos dialectos dan a la columna un nombre que se corresponde con su posición en la tabla (por ejemplo, col4); otros dialectos pueden dejar en blanco el nombre de la columna o Lrsar como nombre la expre-
En SQL, están dis <
sión introducida en la lista de selección de la instrucción SELECT. El estándar ISO permite dar un nombre a la columna mediante la cláusula AS. En el ejemplo anterior, podríamos haber escrito:
SELECT
FROM
staffNo, fName, lName, salarylT2
AS
< >
monthlySalary
Staff;
En este caso, el encabezado de columna en la tabla de resultados sería monthlySalary en lugar de
col4.
¡
I
Selección de filab (cláusula WHERE) Los ejemplos anteriores muestran el uso de la instrucción SELECT para extraer todas las filas de una tabla. Sin embargo, a menudo necesitamos restringir las filas que hay que extraer. Esto puede hacerse mediante la cláusula WHERE que está compuesta de la palabra clave WHERE seguida de una condición de búsqueda que especifica las filas que hay que extraer. Las cinco condiciones básicas de búsqueda (o predicados) en terminología ISO son las siguientes:
1 I I I
Comparación. Compara el valo¡ de una expresión con el valor de otra. Rango. Comprueba si el valor de una expresión cae dentro de un rango especificado de valores.
Pertenencia a conjunfo. Comprueba si el valor de una expresión coincide con uno de los valores de un cierto conjunto. Correspondencia de patrones. Comprueba si una cadena de caracteres se ajusta a un patrón especificado.
a Nub. Comprueba si una columna tiene un valor nulo (desconocido). La cláusula WHERE es equivalente a la operación de selección de álgebra relacional que hemos explicado en la Sección 4.1 . I . Vamos a presentar a continuación ejemplos de cada de estos tipos de condiciones de
>
igual distinto (e menor qu mayor qLI
Pueden generarse .,réntesis (si se nece: , ¡n condicional son:
I I I I
las expresione:
primero se el'e
el operador N(
el operador A)
Se recomienda uti
t_ I Elemplo 5.b uc Generar ttn listatt
SELECT * FROM BranclWHERE citY'
En este ejemplo. existentes en Lor muestra en 1a Tab
:
búsqueda.
lI I
Ejemplo 5.5 Condición de búsqueda basada en comparación Generar una lista con todos los empleados cuyo salario sea superior a 10.000 euros.
SELECT
staffNo, fName, lName, position, salary
FROM stan WHERE salary
)
10000;
Aquí, la tabla es Stafi y el predicado es salary > 10000. La operación de selección crea una nueva tabla que contiene únicamente aquellas filas de Staff en las que el salario es superior a 10.000 euros. El resultado de esta operación se muestra en la Tabla 5.5.
Tabla 5.5. Tabla de resultados para el Ejemplo 5.5. staffNo
fName
lName
salary
SL21
John
Whitc
Manager
30000.0t)
Ann
Bccch
Assistant
r2000.00
SC 14
David
Forcl
Supervisor'
18000.00
Susan
Brand
Manager
Ct
Generar un listtt, allros.
SE,LECT staf
position
SG37
SG5
Ejemplo 5.7
24000.00
FROM statt WHERE sal¿ La condición BE bién a todos los
,
tado se muestra También existe t si el valor se enr
(
Capítulo
5
SOL: man¡pulac¡ón de
datos
111
En SQL, están disponibles los siguientes operadores simples de comparación
gunos
mplo,
:
)xpre-
<
lar un
>
igual distinto (estándar ISO)
distinto (permitido en algunos dialectos) menor o igual que mayor o igual que
Pueden generarse predicados más complejos utilizando los operadores lógicos AND, OR y NOT, con :.:.ntesis (si se necesitan o desean) para mostrar el orden de evaluación. Las reglas para evaluar una expre-
, -,r condicional
I ! I I
¡na tabla.
las expresiones se evalúan de izquierda a derecha;
primero se evalúan las subexpresiones contenidas entre corchetes; el operador NOT se evalúa antes que los operadores AND y OR;
el operador AND se evalira antes que ei operador OR. Se recomienda utllizar siempre paréntesis para eliminar cualquier posible ambigüedad.
:diante ia ¡ueda que en termi-
I res.
gjernplo 5.6 Condición de búsqueda basada en una comparac¡ón compuesta Generar un listado con la dirección de todas las sucursales de Londres
rres de un
SELECT * FROM Branch WHERE city = '¡orr¿orr'OR
especifi-
s
son:
city =
y Glasgow
'Glasgow';
En este ejemplo, se utiliza el operador iógico OR en la ciáusula WHERE paralocalizar las sucursales eristentes en Londres (city : '¡orrdon') o en Glasgow (city = '6ruttow'). La tabla de resultados se niuestra en la Tabla 5.6.
explica-
ciones de
Tabla 5.6. Tabla de resultados para el Ejemplo 5.6.
tabla resul-
I
branchNo
Street
city
postcode
B005
22 Deer Rd
London
SWI 4EH
B003
163 Main St
B002
56 Clover
Dr
Glasgow
cll9QX
London
NWIO 6EU
Ejemplo 5.7 Condición de búsqueda basada en rango (BETWEEN/NOT BETWEEN) Generar un listado con todos los empleados cltyo salario esté comprendido entre 20.000 y 30.000 cuI'os.
SELECT
staffNo, fName, lName, position, salary
FROM Staff WHERE salary BETWEEN 20000 AND 30000; La condición BETWEEN indica los puntos extremos del rango, por lo que el resultado incluirá también a todos los empleados cuyo salario sea igual a 20.000 euros o a 30.000 euros. La tabla de resultado se muestra en la Tabla 5.7. También existe una versión negada de la comprobación de rango (NOT BETWEEN) que comprueba si el valor se encuentra fuera del rango especificado. La comparación BETWEEN no añade mucha
112
S¡stemas de bases de datos
potencia expresiva a SQL, ya que este tipo de condición puede expresarse perfectamente utilizando dos comparaciones. Podíar¡os haber escrito la consulta anterior como:
lName
position
salary
John
White
Manager
i0t)00.00
Susan
Brand
Manager
24000.00
fName
SL2 I SG5
!
de
lYoel Iel Todos los
I
Sin embargo, la condición BETWEEN constituye una fonna más senciila de expresar una condición de búsqueda cuando lo que esternos considerando es un rango de valores.
II
dentro
correspol
Tabla 5.7. Tabla de resultados para el Ejemplo 5.7. staffNo
Para esta
_t
Ejemplo 5.8 Condición de búsqueda basada en pertenencia a un conjunto (lN/NOT lN)
ser cu
I
addres lI19rO
I
,
addres
igual i
I
addres
conter
I
Generar un listado con todos los gerentes y sttpervisores.
addres
addres
Si la cadt
SELECT staffNo, fName, lName, position tr'ROM stan WHERE position lN ('Manager', 'Supervisor');
carácter car
I
la cad
I,IKE
La condición de pertenencia a un conjunto (IN) cornprueba si el valor de ios datos se coresponde con uno de los valores especificados en Llna determinad¿r lista, que en este caso está compuesta por sólo dos opciones: 'Manager'y 'Supervisor'. La tabla de resultados se muestra en la Tabla 5.8. Tabla 5.8. Tabla de resultados para el Ejemplo 5.8 StaffNo
fName
lName
position
SL21
John
White
Manager
SGI4
David
Ford
Supervisor
SG5
Susan
Brand
Manager
Utilizand( zaf a toda siguiente
SELE FRO¡
WHE
Tenga en res como(
Existe una versión inversa (NOT IN) que puede utilizarse para buscar vaiores de datos que no estén comprendidos en una lista especificada de valores. Al igual que BETWEN, ia condición lN no añade mucha potencia expresiva a SQL, ya que podríamos haber expresado la consuita anterior de la forma siguiente:
SELECT
staffNo, fName, lName, position
FROM Staff WHERE pos¡tion
:
'Manager' OR positton
:
'Superuisor';
Sin embargo, ia operación IN constituye una lbrma rnás eficiente de expresar la condición de da, particulannente si el conjunto contiene múltiples valores.
':l
5.9 Condición de búsqueda basada en correspondencia de patrones (LIKE/ NOT LIKE) Localizar todos los propietrtrios en cuya dirección aparezca la cadena de caracteres 'Glasgow'
Generar ducido nt
A partir c PG4: una pensar qt
Capítulo 1o
dos
5
SOL: manipulación de
datos ll3
Para esta consuha, debemos comprobar si 1a cadena de caracteres 'Glasgow' aparece en algún lugar ientro de la columna address de la tabla Privateowner. SQL dispone de dos símbolos especiales para ;orrespondencia de patrones:
a o/o el carácter de porcentaje representa cualquier secuencia de cero o más caracteres (comodín). I _ el carácter de subrayado representa cualquier carácter individual. lodos los demás caracteres incluidos en un patrón hacen referencia a sí mismos. Por ejemplo:
I ición
J N)
address
LIKE 'H%' quiere decir que el prirner carácter
debe ser.I/, pero el resto de la cadena puede
ser cualquier cosa.
r
address
I
address
I
address
LIKE 'H_ _,' quiere decir que la cadena debe tener exactamente cuatro caracteres el primero de los cuales debe ser una H.
LIKI '%e' quiere decir cualquier secuencia de caracteres qlle tenga una longitud al menos igual a 1, siendo el últirno carácter una e. LIKE '%Glasgowoá' quiere decir rma secuencia de caracteres de cualquier longitud
que
contenga la paiabra Glasgow.
I
address NOT
LIKE 'H7o' quiere decir que el primer carácter no puede
ser una.I/.
Si 1a cadena de búsqueda inciuye al propio carácter de bÍrsqueda de patrones, podemos utilizar un carácter de escape para representar a dicho carácter de búsqr"reda de patrones. Por ejemplo, para bus::rr la cadena '15%', podemos uftliza¡ el predicado:
LIKE '15#%' ESCAPE con dos
'#'
r,'tilizando la condición de búsqueda de SQL basada en corespondencia de patrones, podemos localiz¡r a todos los propietarios en cuya dirección aparczca la cadena de caracteres 'Glasgow'mediante la .:guiente consulta, que genera la tabla de resultados que se muestra en la Tabla 5.9:
SELECT ownerNo, fName, lName, address, telNo
FROM PrivateOwner WHERE address LIKE
'%Glasgowo/o';
Tenga en cuenta que algunas SGBD, como por ejemplo Microsoft Office Access, utilizan los caracte:es comodín * y ? en lugar de % y _.
Tabla 5.9. Tabla de resultados para el Ejemplo 5.9. én de
na
J
Ejemplo
ownerNo
fName
lName
address
co87 co40
Carol
Farrel
6
Tina
Murphy
63 Well St, Glasgow G42
0141-943-1728
c093
Tony
Shaw
12 Park Pl, Clasgow G4 OQR
0t4r-225-7025
5.10
Achray St, Glasgow G32 gDX
telNo 0l4l-3s7-7419
Condición de búsqueda NULL (lS NULL/IS NOT NULL)
Generar un listado con los detalles de todas las visitas al inmueble PG4 para las que no se haya introu c ido ningú n coment ari o.
'l
-\ partir de la tabla Viewing de la Figura 3.3, podemos ver que se han producido dos visitas al inmueble PG4: una de ellas incluye un comentario, mientras que la otra no. En este ejemplo simple, podríamos pensar que se puede acceder a 1a última fila utilizando una de ias siguientes condiciones de búsqueda:
114
Sistemas de bases de datos (propertyNo
='PG4' AND comment ='')
rste ejemplr s¡ de forma
o
ts\'al final (propertyNo =
'PG4'AND comment
<
>'too remote')
t
rrdenación I de resultado
Sin embargo, ninguna de estas condiciones tuncionarÍa correctamente. Los comentarios nulos tienen un valor desconocido, por 1o que no podemos comprobar si son iguales o distintos a ninguna otra cadena de caracteres. Si tratáramos de ejeoutar la instrucción SELECT utilizando cualquiera de estas dos condiciones compuestas, obtendríamos una tabla de resultados vacía. En lugar de ello, tenemos que cornprobar explícitamente la existencia de valores nulos utilizando ia palabra clave especial IS NULL:
ORDER BY
ra incluido
e
SELECT clientNo, viewDate
FROM Viewing WHERE propertyNo ='PG4'AND
comment
IS NULL;
La tabla de resultados se muestra en la Tabla 5.10. También puede emplearse la versión inversa (IS NOT NULL) para buscar valores que no sean nulos. Tabla 5.10. Tabla de resultados para el Ejemplo 5.'10 clientNo
viewDate
CR56
26-May-04
5.3,2 Ordenación de los resultados (cláusula
Se puede incl -.;na el orden gir
ORDER BY)
En general, las filas de la tabla de resultados de una consulta SQL no están ordenadas según ningún criterio partictrlar, aunque algunos SGBD pueden utllizar alguna ordenación predeterminada basándose, por ejemplo, en una clave principal. Sin embargo, podemos garanlizar que los resultados de la consulta queden ordenados utilizando la cláusula ORDER BY en la instrucción SELECT. La cláusuia ORDER BY está compuesta por una lista de identilicadores de columna segirn los cuales hay que ordenar los resultados, separados por comas. Cada identificador de columna puede ser el nombre de una columna o un número de columnar qtre identifica un eietnento de la lista SELECT según su posición dentro de la lista, corespondiendo el I al primer elelnento de la lista (el situado rnás a la izquierda), el 2 al segundo elernento de la lista, etc. Pueden usarse los nútmeros de columna si la columna segúrn la cual hay que ef-ectuar la ordenación es una expresión y no se ha especificado en ninguna cláusula AS para asignar a la columna un nombre al qr,re luego pueda hacerse referencia. La cláusula ORDER BY permite ordenar las ñlas extraídas en orden ascendente (ASC) o descendente (DESC) según cualquier columna o cornbinación de columnas, independientemente de si dichas columnas aparecen en el resultado o no. Sin ernbargo, en algunos diaiectos los elementos de ORDER BY deben aparecer en la lista de selección de la instrucción SELECT. En cualquier caso, la cláusula ORDER BY siempre debe ser la úrltirna cláusula de la instrncción SELECT. I
!
:. los valores de --licionales para iJenación, puec ::
ordenación. E;
."ción principal
-.iusula ORDER
I
Ejemplo 5.' Generar wta
SELECT
FROM
Pr
ORDER En este caso. Tabla
Ejemplo 5.11 Ordenación según una sola columna Generar una lista con el salario de todos los empleados, en orden descendenÍe de salurir¡.
SELECT staffNo, FROM stan
fName, lName, salary
ORDER BY salary DESC; tLos nÍutrcros dc columna son una caractcrística del cstándar tSO quc ya ha dcjado dc rccorncndarsc y no dcbcrían utilizarse
Hay cuatro pr nación, el sis
Capítulo
5
SOL: manipulación de
datos
115
Este ejemplo es muy similar al Ejemplo 5.2. La diferencia en este caso es que la salida debe ordenarse de forma descendente según el contenido de salary. Esto se consigue añadiendo la cláusula ORDER BY al final de Ia instrucción SELECI especificando salary como columna que debe utilizarse parala ordenación y DESC para indicar que el orden debe ser descendiente. En este caso, se obtiene la tabla de resultados que se muestra en la Tabla 5.11. Observe que podríamos haber expresado la cláusula ORDER BY como: ORDER BY 4 DESC, haciendo el número 4 referencia al cuarto nombre de columna incluido en la lista SELECT, es decir, a salary.
Tabla 5.11. Tabla de resultados para elEjemplo 5.11 staffNo
fName
lName
SL21
John
White
30000.00
SG5
Susan
Brand
24000.00
SGI4
David
Ford
I
salary
8000.00
SG37
Ann
Beecl-r
12000.00
SA9
Mary
Howc
9000.00
Julie
Lee
9000.00
SL4I
Se puede incluir rnás de un elemento en Ia cláusula ORDER BY. La clave principal de ordenación deter:rina el orden global de la tabla de resultados. En el Ejemplo 5.11, la clave principal de ordenación es satary. Si los valores de la clave principal de ordenación son unívocos, no hay ninguna necesidad de incluir claves .dicionales para controlar la ordenación. Sin embargo, si no son unívocos los valores de la clave principal de tdenación, puede que haya múltiples filas en la tabla de resultados con el mismo valor de la clave principal
ie ordenación. En este caso, )rio )1o,
puede que queramos ordenar las ñlas que tengan el mismo valor de clave de orde-
:ación principal utilizando alguna otra clave adicional de ordenación. Si aparece un segundo elemento en la :iáusula ORDER B! se lo denomina clave secundaria de ordenación.
Cos
por por
I
I
Ejemplo 5.12 Ordenación multicolumna
:lLle
rri;ar-
no rse es1a§
]Y ER
Generar una lista abreviada de inmuebles ordenada según el tipo de inmueble.
SELECT
FROM
propertyNo, type, rooms, rent
PropertyForRent
ORDER BY
type;
En este caso, obtenemos la tabla de resultados mostrada en la Tabla 5.12(a). Tabla 5.12(a). Tabla de resultados para el Ejemplo 5.12 con una clave de ordenación. propertyNo
type
Rooms
rent
PL94
Flat
4
400
PG4
Flat
3
350
PG36
Flat
J
375
PG16
Flat
4
450
PA14
House
6
650
PG2I
House
5
600
Hay cuatro pisos (flat) en esta lista. Como no hemos especificado ninguna clave secundaria de ordenación, el sistema ordena estas filas de cualquier manera. Para disponer los inmuebles, por ejemplo,
1
16
Sistemas de bases de datos
ordenándolos según el importe del alquiler (rent), podemos especiñcar un orden secundario de la forma siguiente:
SELECT
FROM
propertyNo, type, rooms, rent
PropertyForRent
ORDER BY type, rent DESC; Ahora, el resultado estará ordenado en primer lugar, según el tipo de inmueble, en orden alfabético ascendente (porque ASC es la opción predeterminada) y, dentro de cada tipo de inmueble, en orden descendiente del importe del alquiler. En este caso, se obtiene la tabla de resultados que se muesffa en la Tabla 5.12(b). El estándar ISO especifica que los valores nulos contenidos en una columna o expresión que se ordene mediante ORDER BY deben tratarse como si fueran menores que cualquier valor no nulo o superiores que cualquier valor no nulo. Se deja ala elección del implementador del SGBD cuál de las dos opciones utllizar.
Tabla 5.12(b). Tabla de resultados para el Ejemplo 5.12 con dos clave de ordenación.
be úplicado
¡oisma consul Es import "a cláusula fL Si la lista SEI Fa agrupar
ringuna refer ción. Por ejel
SELECT FROM §
porque la con rize¡fa 5in gp1
[T0,.
PropertyNo
type
rooms
PG16
Flat
4
'150
SELEI
PLg4
Flat
4
400
FROIV
PG36
Fl¿rt
3
375
WHEI
PG4
Flat
3
350
Para restri
PA14
House
6
650
PG21
Housc
5
600
la cláusula condición
rent
¿Cuántos
5.13.
5.3.3 Utilización de las funciones de agregac¡ón de SQL Además de extraer filas y columnas de la base de datos, a menudo surge la necesidad de realizar algún tipo de resumen o agregacién de los datos, de fonna similar a los totales que aparecen en la pafie inferior de un informe. El estándar ISO define cinco funciones de agregación:
I r r I r
COUNT - dewelve el número de valores en una columna especificada; SUM - devuelve la suma de los valores contenidos en una columna especif,cada; AVG - devuelve la media de los valores contenidos en una columna especificada;
MIN - devuelve el valor más pequeño contenido en una columna especificada;
MAX - devuelve el valor máximo contenido
en una columna especificada.
Estas funciones operan sobre una única columna de una tabla y devuelven un único valor. COUNT, MIN se aplican a campos tanto numéricos como no numéricos, pero SUM y AVG sólo pueden emplearse con campos numéricos. Dejando aparte COUNT(*), todas las funciones eliminan en primer lugar ios valores nulos y utrlizan para sus operaciones únicamente los restantes valores no nulos. COUNT(*) es un caso especial de COUNT que se emplea paru contar todas las filas de una tabla, independientemente de si existen valores nulos o valores duplicados. Si queremos eliminar los duplicados antes de emplear la función, utilizamos la palabra clave DISTINCT antes del nombre de la columna a la que se aplica la función. El estándar ISO permite emplear la palabra clave ALL si no se quieren eliminar los duplicados, aunque ALL es la opción que se presupone si no se especifica nada. DISTINCT no tiene ningún efecto con las funciones MIN y MAX. Sin embargo, sí que puede influir sobre el resultado de SUM o AVG, así que es preciso decidir de antemano si hay que incluir o excluir
y MAX
t_I Elemplo ¿Cuánto.s
I
,
SELE(
FRO}I WHET
De nuevo. en mayo d aplicando
sido visita inmuebles
Capítulo orma
-
,
5
SOL: man¡pulac¡ón de
datos
117
Juplicados en los cálculos que se realicen. Sólo puede especificarse DISTINCT vnavez dentro de una
:::1a COnSUlta.
rs importante observar que las funciones de agregación sólo pueden duplicarse en la lista SELECT y
en Es incorrecto usar dichas funciones en cualquier otra cláusula. lista SELECT incluye una función de agregación y no se está empleando ninguna cláusula GROUP BY
- -.:usu1a HAVING (véasela Sección 5.3.4).
: . : : agrupar los datos (véase \a Sección 5.3.4), entonces ningún elemento de la lista SELECT puede incluir - -üna referencia a una columna, a menos que dicha columna sea el argumento de una función de agrega-
etlco
. ,:,
)rden ra 9n
Por ejemplo, la siguiente consulta sería ilegal:
SELECT staffNo, COUNT(salary) FROM stan;
)rdeupe-
- ::-ue 1a consulta -.:¡ sin emplear
; dos
Ejemplo
no tiene una cláusula GROUP BY y la columna staffNo en la lista SELECT está siendo uticon ella una ñrnción de agregación.
5,13 Utilización de COUNT(")
: Cuántos inmuebles tienen un alquiler superior a 350 euros
SELECT COUNT(*) AS
por
mes?
myCount
FROM PropertyForRent WHERE rent > 350; Para restringir la consulta a los inmuebles cuyo alquiler sea superior a 350 euros por mes, utilizamos ,a cláusula WHERE. Entonces podemos determinar el número total de inmuebles que satisfacen esta condición aplicando la función de agregación COUNT. La tabla de resultados se muestra en la Tabla
i.r3. Tabla 5.13. Tabla de resultados para el Ejemplo 5.13
jn tipo 'de
un I
I
Elemplo
5.14 Utilización de COUNT(DISTINCT)
;Cuántos inmuebles dislintos fueron visitados en mayo de 2004?
SELECT COUNT(DISTINCT
propertyNo)
AS
myCount
FROM Viewing WHERE viewDate BETWEEN'l-May-O4' AND'31-May-04'; , MIN learse
alores espe-
valo-
INCT clave ;peciluede
De nuevo, utilizamos la cláusula WHERE para restringir las consultas a las visitas que tuvieron lugar en mayo de 2004. Entonces podemos hallar el número total de visitas que satisfacen esta condición aplicando la función de agregación COUNT. Sin embargo, ya que un mismo inmueble puede haber sido visitado múltiples veces, es necesario emplear la palabra clave DISTINCT para eliminar los inmuebles duplicados. La tabla de resultados se muestra en la Tabla 5.14.
ilil|lil
Tabla 5.14. Tabla de resultados para el Ejemplo 5.14 illiltl
1la
Sistemas de bases de datos
1I
I I ¡
Ejempto 5.15 Utilización de COUNT y SUM
Calcular el número total de gerentes y la suma de
SELECT COUNT(staffNo) AS FROM Staff WHERE position = 'Manager',
sus
consü
unae)
salarios.
mycount, SUM(salary)
AS
Todos los
s'la GROUP
mySum
ümbatgo, no
Ilafezffin
Para restringir la consulta a los gerentes (Manager) utilizamos de nuevo la cláusula WHERE. El niunero de gerentes y la sr"una de sus salarios pueden detenninarse aplicando las funciones COUNT y SUM, respectivamente, a este conjunto restringido. La tabla de resultados se muestra en la Tabla 5.15.
Tabla 5.15. Tabla de resultados para el Ejemplo 5.15 myCount
mySum
2
54000.00
¿l¡rrul¿
en
\!!l
hrsqueda.
El estand.
§ hay dos fil
h
c6l rmnaS
l-=,"*,o Calcular
tI
fi¡ncir
t
Ejemplo 5.16 Utilización de MlN, MAX, AVG
SELE FROII
Calcular el salario mínimo, ntáximo y medio de los empleados.
GROI ORDI
SELECT MlN(salary)AS FROM staff;
myMin, MAX(salary)
AS
myMax, AVG(salary)
AS
myAvg
En este ejemplo, queremos tor.nar en consideración a todos los ernpleados, por lo qlle no hace falta ninguna cláusula WHERE. Los valores requeridos pueden calcularse utilizando las frurciones MIN, MAX y AVG con la columna salary. La tabla de resultados se rluestra en la Tabla 5. 16.
No es necr
recen en li
con ningu BY. La tal
Tabla 5.16. Tabla de resultados para el Ejemplo 5.16. myMin
myMax
myAvg
9000.00
30000.00
17000.00
Conceptut
5.3.4 Agrupación de resultados (cláusula GROUP BYI Las consultas de resumen o agregación que acabamos de ver son similares a los totales que aparecen en la parte inferior de un infome. Permiten condensar todos los datos de detalle del inforrne en una irnica flla de resumen de los datos. Sin embargo, a rnenudo resulta tarnbién útil disponer de subtotales en los infbrmes; para esto, podemos emplear la cláusula GROUP BY de la instrucción SELECT. Una consulta que incluya la cláusLria GROUP BY se denomina consulta agrupada, porque agrupa los datos de las tablas indicadas en la instrucción SELECT y genera una única fila de resuffren para cada grupo. Las columnas especificadas en la cláusula GROUP BY se denor¡inan columnas de agrupamiento. El estándar ISO exige que la cláusula SELECT y la cIáusula GROUP BY estén estrechamente integradas. Cuando se emplea GROUP BY, cada elernento de la lista SELECT debe tener un único valor para cada grupo. Además, la cláusula SELECT sólo puede contener:
I
nombres de columnas;
(r) sQL d cada g
drán tr
5
Capítulo
I I r
SOL: manipulación de
datos llg
funciones de agregación; constantes; una expresión en la que se combinan algunos de los anteriores elementos.
me-
l.rdos los nombres de columna contenidos en la lista SELECT deben obligatoriamente aparecer en Ia cláu- GROUP BY, a menos que el nombre se esté usando únicamente dentro de una función de agregación. Sin ' -:rso, no sucede lo mismo al revés: puede haber nombres de columnas en la cláusula GROUP BY que no -, :zcan en la lista SELECT. Cuando se utiliza la cláusula WHERE con GROUP Bt se aplica primero la ---..ila WHERE y luego se forman los grupos a partir de las ñlas restantes que satisfacen la condición de
JM,
-
:,*eda. :. estándar ISO considera que dos valores nulos son iguales en 1o que respecta a la cláusula GROUP BY. '.' dos filas que tienen valores nulos en las mismas columnas de agrupamiento y valores idénticos en todas -,,^umnas de agrupamiento no nulas, ambas filas se combinarán en un mismo grupo.
Ejemplo
5.17 Utilización de GROUP
BY
-'tlc'ular el número de empleados que trabajan en cada sucursal y la swna de SELECT
FROM
branchNo, COUNT(staffNo)
AS myCount, SUM(satary) AS
sus
salarios.
mySum
Staff
GROUP BY ORDER BY
branchNo branchNo;
'ir-r €s oecesario incluir los nombres de columna staffNo y salary en la lista GROUP BY, ya que sólo apa:3cen en la lista SELECT dentro de funciones de agregación. Por otro lado, branchNo no está asociado
:,rn ninguna función de agregación, por lo que deberá obligatoriarnente aparecer en la lista GROUP
3\'. La tabla
de resultados se muestra en la Tabla 5.17.
Tabla 5.17. Tabla de resultados para elEjemplo 5.17 branchNo
myCount
mySum
B003
J
54000.00
8005
2
39000.00
8007
1
9000.00
--rrnceptualmente, SQL ejecuta la consulta de la forma siguiente: -t \47
SQL divide el personal en grupos de acuerdo con sus respectivos números de sucursal. Dentro de cada grupo, todos los empleados tienen un número de sucursal idéntico. En este ejemplo, se obtendrán tres grupos:
de
ra u-
la
branchNo
staffNo
salary
8003
SG37
12000.00
8003
sG14
18000.00
8003
SG5
24000.00
B005
sL2t
30000.00
8005
SL41
9000.00
B007
SA9
9000.00
-..._ )
COUNT(staffNo)
SUM(salary)
J
54000.00
2
39000.00
I
9000.00
12O Sistemas de bases de datos (2)Para cada grupo, SQL calcula el número de empleados y la suma de los valores contenidos en la columna salary, con el fin de obtener el salario total. SQL generará una única fila de resumen para cada grupo dentro del conjunto de resultados de la consulta.
(3) Finalmente, se ordena el resultado en orden ascendente del número de sucursal, branchNo.
El estándar SQL permite que la lista SELECT contenga consultas anidadas (véase la Sección 5.3.5). Por tanto, también podríamos expresar la consulta anterior de la forma siguiente: SELECT branchNo, (SELECT COUNT(staffNo) AS
myCount
FROM Staff s WHERE s.branchNo = b.branchNo), (SELECT SUM(salary) AS mySum FROM Staff s WHERE s.branchNo = b.branchNo) FROM
Branch b
ORDER BY
Restricción de los agrupam¡entos (cláusula HAVING) La cláusula HAVING está diseñada para ser utllizada con la cláusula GROUP BY con el fin de restringir los grupos que aparecen en Ia tabla final de resultados. Aunque son similares en cuanto a sintaxis, las cláusulas HAVING y WHERE se utilizan para diferentes propósitos. La cláusula WHERE filtra las filas individuales que se incluyen en la tabla final de resultados, mientras que HAVING filtra los grupos que se incluyen en dicha tabla de resultados final. El estándar ISO exige que los nombres de columna utilizados en la cláusula HAVING aparezcan también en la vista GROUP BY o estén contenidos dentro de una función de agregación. En la práctica, la condición de búsqueda de la cláusula HAVING siempre incluye al menos una función de agregación, ya que en caso contrario la condición de búsqueda podría incluirse en la cláusula WHERE y aplicarse a cada fila individual (recuerde que no pueden utilizarse funciones de agregación en la cláusula WHERE). La cláusula HAVING no es una parte necesaria del lenguaje SQL: cualquier consulta que pueda expresarse utilizando la cláusula HAVING puede siempre reescribirse sin utilizar dicha cláusula.
lI
Ejemplo
5.18
üucció trucció
g¡bsel
cer tatr ripos d
t T
I
l;
Get
Utilización de HAVTNG
Para cada sucursal que tengq más de un empleado, averiguar el número de empleados que trabajan en cada sucursal
En est
mina a
branchNo;
Sin embargo, con esta versión de la consulta, se generan los dos valores agregados para cada sucursal contenida en Branch, en algunos casos posiblemente con valores iguales a cero.
I
5.3.
y la suma
de sus salarios.
SELECT branchNo, COUNT(staffNo) AS myCount, SUM(satary) AS mySum FROM Staff GROUP BY branchNo HAVING COUNT(staffNo) > 1 ORDER BY branchNo; Este ejemplo es similar al anterior, con la restricción adicional de que sólo queremos considerar aquellos grupos (es decir, sucursales) que tengan más de un empleado. Esta restricción se aplica a los grupos y no a las filas individuales, por 1o que utilizamos la cláusula HAVING. La tabla de resultados se muestra en la Tabla 5.18.
La
coÍl sati
est(
tra¡ tad(
loc
T.
Capítulo
5
SOL: manipulación de datos
121
Tabla 5.18. Tabla de resultados para el Ejemplo 5.18.
.a ,a
branchNo
myCount
mySum
B003
3
54000.00
8005
2
39000.00
5.3.5 Subconsulta§ :
esta sección vamos a examinar el uso de una instrucción SELECT completa incluida dentro de otra ins---:,'ión SELECT. Los resultados de esta instrucción SELECT interna (o subselección) se utilizan en la ins-
:'-:.'ión externa como
ayuda para determinar el contenido de la tabla de resultados final. Puede utilizarse una
-:.elección en las cláusulas WHERE y HAVING de una instrucción SELECT extema, en cuyo caso se deno- :.: a esa instrucción SELECT intema subconsulta o consulta anidada. Las subselecciones pueden apare:: .ambién dentro de las instrucciones INSERT, UPDATE y DELETE (véasela Sección 5.3.10). Existen tres :,, s de subconsultas: '1
J
I
Una subconsulta escalar devuelve una única columna y una única hla, es decir, un único valor. En principio, puede utilizarse una subconsuita escalar en cualquier lugar donde haga falta un único valor. Los Ejemplos 5.13 y 5.14 son subconsultas escalares.
I
Una subconsulta de fila devuelve múltiples columnas, pero de nuevo de una única fila. Puede utilizarse una subconsulta de fila siempre que se necesite un constructor para generar un valor de fila, lo que normalmente sucede en los predicados. El Ejemplo 5.15 es una subconsulta de fila.
I
nen
Una subconsulta de tabla devr¡elve una o más columnas y múltiples filas. Puede utilizarse una subconsulta de tabla en cualquier lugar donde se necesite una tabla, como por ejemplo como operando para
rsuia
e1
r los ;uias Lales
predicado [N.
:ión.
nde iplisula )sar-
Ejemplo 5.19 Ut¡lización de una subconsulta con el operador de igualdad i¿¡terar un listado con todos los empleados de la sucursal ubicada en ' I63 Main St'. SELECT staffNo, fName, lName, position FROM star
\\'HERE
branchNo
:
itililtil
(SELECT branchNo FROM Branch WHERE street:'163 Main St');
-;rstrucción SELECT intema (SELECT branchNo FROM Branch . . . ) extrae el número de sucursal -,-rrespondiente a la sucursal situada en la calle'163 Main St'(sólo hay un número de sucursal que .iiisfaga la condición, por 1o que se trata de un ejemplo de subconsulta escalar). Habiendo obtenido :sre número de sucursal, la instrucción SELECT extema extrae los detalles de todos los ernpleados que :iabajan en esta sucursal. En otras palabras, la instrucción SELECT interna devuelve una tabla de resul.ados qr.re contiene un único va1or, '8003'correspondiente a la sucursal ubicada en'163 Main St', por .'r que la instrucción SELECT externa se convierte en:
-,
SELECT staffNo, fName, lName, position FROM Staff
WHERE
branchNo
-=:abla de resultados
:'8003'; se muestra en la Tabla 5.19.
ililil1
122
Sistemas de bases de datos Tabla 5.19. Tabla de resultados para el Ejemplo 5.19.
:rDem¡:
staffNo
fName
lName
positlon
.ie tabl: .., r -h
SG37
Ann
Bccch
Assistant
a3
SGI4
David
Ford
Supervisor
SG5
Sttsan
Brand
Manager
-,
(1 c'rl
CuanJc C
LrnSLl.:.
i.ltitr.r SEI
Podemos considerar que la subconsulta produce una tabla temporal con una serie de resultados a los que puede acceder la consulta extema y utilizarlos como si de cualquier otra tabia se tratara. Puede emplearse una subconsulta inmediatamente después de un operador relacional (:, <, >, (:, ):, < >) dentro de una cláusula WHERE o HAVING. La propia subconsulta siempre debe encerarse entre paréntesis.
I
I
Ejemplo 5.20 Utilización de una subconsulta con una func¡ón de agregación Generur un listado de todos los empleados cuyo salario sea superior al salario ntedio, indicando cuál es la diJbrencia en cada ('a,\o con respecto al salario medio.
SELECT
staffNo, fName, lName, position, salary
-
(SELECTAVG(salary) FROM Staff) AS salDiff
FROM Staff WHERE salary > (SELECT AVG(satary) FROM
porque
l-=n*,o,
Generar ut, da en'l6i
SELE( FROM WHEN
Staff);
En prirner lugar, observe que no podemos escribir 'WHERE salary > AVG(satary)' ya que no pueden utilizarse funciones de agregación dentro de una cláusula WHERE. En lugar de ello, utilizamos una subconsulta para hallar ei salario medio y luego empleamos la instrucción SELECT extema para extraer los empleados que tengan un salario superior al salario rnedio calculado. En otras palabras, Ia subconsulta devuelve un salario medio igual a 17.000 euros. Fíjese tar¡bién en la utilización de una sLlbconsulta escalar en la lista SELECI para determinar la dif'erencia con respecto al salario medio. La consulta externa queda reducida entonces a:
SELECT staffNo, fName, lName, posit¡on, FROM Staff WHERE salary > 17000;
FR(
\\H
Si analizar el número
dos que tr:
salary
-
en la tabla
17000 AS salDiff
igualdad (
extsrna ex empleados
La tabla de resultados se muestra en la Tabla 5.20. Tabla 5.20. Tabla de resultados para el Ejemplo 5.20 staffNo
fName
lName
posit¡on
SL2I
John
White
Manager
SGI4
David
Ford
Supervisor
1000.00
SC5
Susan
Brand
Manager
7000.00
SAID¡ff r
3000.00
Las reglas aplicables a las subconsultas son las siguientes:
(l)
s.3.6
A
No puede utilizarse la cláusuia ORDER BY dentro de una subconsulta (aunque sí puede emplearse en la instrr,rcción SELECT más externa).
-as palabras :e números.
(2) La lista SELECT de la subconsulta debe estar compuesta por un úrnico nombre de colurnna o expresión, excepto en el caso de las subconsultas que utilicen la palabra clave EXIT (véasela Sección 5.3.8)
satisfecha Po
:lave ANY,
1
Capítulo
5
SOL: man¡pulac¡ón de
datos
123
-i)De manera predeterminada, los nombres de columna de una subconsulta hacen referencia al nombre
de tabla incluido en la cláusula FROM de la subconsulta. Resulta también posible hacer referencia a una tabla contenida en la cláusula FROM de una consulta extema cualificando el nombre de la columna (véase más adelante).
1) Cuando una subconsulta actua como uno de los dos operandos implicados en una comparación, la subconsulta debe aparecer en ei lado derecho de la comparación. Por ejemplo, sería incorrecto expresar el último ejemplo que hemos visto como:
SELECT staffNo, fName, lName, position, salary FROM stan WHERE (SELECT AvG(salary) FROM Staff) < salary'
r los que rarse
ut-t¿l
r cláusr-r-
porque la subconsulta aparece en el lado izquierdo de Ia comparación con salary.
Ejemplo
5.21 Subconsultas anidadas: utilización de lN
'3enerar un listado con los inmuebles gestionados por los empleados que trabajan en la sucursal situa.la en'163 Main St'.
cuál
SELECT propertyNo, street, city, postcode, type, rooms,
FROM PropertyForRent WHERE staffNo lN (SELECT den tma )ara ;, la una
rent
staffNo
il}"ffi:l"nchNo = (sELECr branchNo FROM Branch WHERE street = '163 Main St')); Si analizamos la consulta comenzando por la subconsulta más interior, la primera consulta selecciona
La
el número de la sucursal situada en '163 Main St'. La segunda consulta selecciona entonces los empleaJos que trabajan en la sucursal que tiene dicho número. En este caso, puede que haya más de una fila cn la tabla de empleados que satisfaga esta condición, por 1o que no podemos utilizar la condición de
:gualdad (:) en la consulta más extema. En lugar de ello, utilizamos la palabra clave IN. La consulta e\terna extrae entonces los detalles correspondientes a los inmuebles gestionados por cada uno de los empleados identihcados en la consulta intennedia. Latabla de resultados se muestra en la Tabla 5.21.
Tabla 5.21. Tabla de resultados para el Ejemplo 5.21. propertyNo
street
city
postcode
type
rooms
rent 450
PGI6
5 Novar
Dr
Glasgow
G12 9AX
Flat
4
PG36
2 Manor Rd
Glasgow
G32 4QX
Flat
3
375
PG21
18 Dale Rd
Glasgow
G12
House
5
600
s.3.6 ANY y ALL ie en
,s palabras clave ANY y ALL pueden utilizarse con aquellas subconsultas que generen una única columna :iúmeros. Si la subconsulta está precedida por la palabra clave ALL, la condición sólo será cierta si se ve ,::sttcha por todos los valores generados por la subconsulta. Si la subconsulta está precedida por la palabra -.; ANY, la condición sólo será cierta si se ve satisfecha por alguno (uno o más) de los valores generados
-. :pre-
3.8)
124
Sistemas de bases de datos
por la subconsulta. Si la subconsulta está vacia, la condición ALL devuelve un valor r,erdaclero, rnienlras rlue la condición ANY devuelve un valor falso. El estándar ISO también permite r-rrilizar el cualiflcador SOME en lugar de ANY. t
I
Efemplo
5.22 Utitización de ANY/SOME
Deferninu' do.s tle
fodcts los em¡tleados t:ttt,o .sular'o sea strperior al sal,:trio cle ul ntent¡s uno cle los ent¡tleu-
la sucur,sul 8003.
SEI,ECT
5.3.7
1
staffNo, fName, lName, position, salary
FRC)M stan
Todos los r
WHERE
nas
salary > SO[/E (SELECT satary
FRON'I Star
WHERE
operación I mblas gene ¡ombinada iicos valon
branchNo =
'8003');
Auuqtte esta cousulta podría expresarse utilizando una subconstrlta que detenninara el salario mínirno de los errpleados que trabajar.r en la sucursal BOul y luego una consulta extem¿1 que localizara toclos los en-rpleados cllyo s¿rlario luera superior a dicho núutero (t,éuse el biemplo 5.20), una 1écnica alternativa es la que utiliza la palabra clave SOME/ANY. La consr¡l1a interna procluce el coryunto 12000, { 18000, 240001 y la constrlLa externa selecciona los empleados cuyos salarios sean superiores a algunos de los valores contenidos en este conjunto (es decir, sr.rperiores al valor rninir¡o, 12000). Este método alternativo puede parecer mirs natural que localizar el salario mínimo mediante una subconsulta. En cualqr-riera de los dos casos, 1a tabla de resultados es la qr.re se muestra en la "lhbla 5.22. Tabla 5.22. Tabla de resultados para el Ejemplo 5.22. staffNo
fName
lName
position
salary
John
White
Nfar-rager
30000.00
SGI4
David
Ford
Supelisor
18000.00
sc5
Susan
Brand
Manager
24000.00
SL2
incluidi
iente,
1
para
Si necer una COmb 'l remos utilir
rombre de
cláusula W
Iambién se del nomt
r¿
¡a en
todor
También pr podrá utiliz
Genero en él lo
I
I
SET
Ejemplo 5.23 Utilización de ALL Determinar todos los empleados cuyo salario sea superior al salario de todos los empleados que trabajan en la sucursal 8003. SELECT
satary >
ALL (SELECT FROM
de satary
Staff
WHERE
Queren
emplear que es t
staffNo, fName, tName, position, salary
FROM §aff
WHERE
FR( WH
branchNo
:'8003');
Este ejemplo es muy similar al anterior. De nuevo, podríamos haber utilizado una subconsulta parahallar el salario máximo de los empleados de la sucursal 8003 y luego una consulta externa para extraer todos los empleados cuyo salario sea superior a este número. Sin embargo, en este ejemplo hemos utilizado la palabra clave ALL. La tabla de resultados es la que se muistra en la Tabla 5.23.
cua1,
(podríar cabo añ
este cas Para ob en 1a co
column
equicot:
Ílueslre
Gapítulo
5
SOL: manipulación de datos
125
Tabla 5.23. Tabla de resultados para el Ejemplo 5.23.
mlentras que
or SOME en StaffNo
fName
lName
position
salary
SL21
John
White
Manager
30000.0
emplea-
5.3.7 Consultas mu¡titabla -
mtnll110 'a todos :a
alter-
12000,
|
a algue
méto-
¡lta. En
:: s los ejemplos que hemos analizado hasta ahora tenían una limitación significativa: todas las colum-
'.-. .:cluidas en la tabla de resultados provenían de una misma tabla. En muchos casos, esto no resulta sufi:. :e. p&r& combinar columnas de diversas tablas en una única tabla de resultados, necesitamos utilizar una :: ;Ción de combinación (oin). La operación de combinación de SQL combina información de dos -:.:: gererÉrndo parejas de filas relacionadas de ambas tablas. Las parejas de filas que forman la tabla :inada son aquellas en las que las columnas correspondientes de cada una de las dos tablas tienen idén-
- . r alores. >- necesitamos obtener información de más de una tabla, tendremos la opción de utilizar una subconsulta
- : !'ombinación. Si la tabla de resultados ñnal debe contener columnas de tablas diferentes, entonces debe: ' - s utilizar obligatoriamente una combinación . Para realizar una combinación, basta con incluir más de un :rre
de tabla en la cláusula FROM, utilizando una coma como separador y, normaimente, incluyendo una
-,s.:la WHERE para especificar la colurnna o columnas con las que hay que realizar la combinación. - -:len se puede utiiizar un alias para las tablas incluidas en la cláusula FROM. En este caso el alias se sepa, -:. nombre de la tabla mediante un espacio. Puede emplearse un alias para cualificar los nombres de colum- -: todos aquellos casos donde exista ambigüedad en 1o referente al origen del nombre de la columna. - :ién pr.rede utilizarse como notación abreviada para el nombre de la tabla. Si se proporciona un alias,
' ,-j utilizárselo
en cualquier lugar en vez del nombre de la tabla.
Ejemplo 5.24 Combinación simple i¿nerqr un listado con los nombres de todos los clienfes que hayan visitado un inmueble, incluyendo
.q él los comentarios realizados. SELECT
c.clientNo, fName, lName, propertyNo, comment
FROM Client c, Viewing v WHERE c.clientNo : v.clientNo; ?
tra-
;ulta 3rna este
nla
Queremos mostrar los detalles tanto de la tabla Client como de la tabia Viewing, por lo que necesitamos :mplear una combinación. La cláusula SELECT indica las columnas que hay que visualizar. Observe que es necesario cualificar el nombre de cliente, clientNo, en la lista SELECT: clientNo podría provenir de cualquier de las dos tablas, por lo que es obligatorio indicar a cuál estamos haciendo referencia rpodríamos perfectamente haber elegido la columna de la tabla Viewing). La cualificación se lleva a cabo añadiendo como prefijo del nombre de columna el nombre de la tabla apropiada (o su alias). En .ste caso, hemos utilizado c como alias para la tabla Client. Para obtener las hlas requeridas, incluimos aquellas filas de ambas tablas que tengan valores idénticos en la columna clientNo, utilizando la condición de búsqueda (c.clientNo : v.clientNo). Decimos que estas columnas son las columnas correspondientes de las dos tablas. Esto es equivalente a la operación de equicombinación del álgebra relacional que analizamos en la Sección 4.1.3. La tabla de resultados se muestra et la Tabla 5.24.
126
Sistemas de bases de datos Tabla 5.24. Tabla de resultados para el Ejemplo 5.24.
IT. I
Elemp¡o 5,
clientNo
fName
lName
propertyNo
CR56
Alinc
Stewarl
PG36
Para cada
incluyendo i
comment
CR56
Aline
Stewart
PAI4
CR56
Aline
Stewart
PG4
CR62
Mary
Trcgear
PAI4
no dining room
CR76
John
Kay
PG4
too remote
too small
s
SELEC'
FROM t WHERI ORDER
Las consr.rltas multitabla más comunes suelen aplicarse a dos tablas que tengan entre sí nna relación nnoa-muchos (l:*) o padre/hijo (véasela Sección 11.6.2). La consulta anterior relativa a los clientes y las visitas es un ejerrplo cle este tipo de consultas. Cada visita (hijo) tiene un cliente asociado (padre) y cada cliente (padre) puede tener muchas visitas asociadas (hijos). Las parejas de filas que componen los resultados de la consulta son combinaciones de filas padre/hijo. En la Sección 3.2.5 hernos descrito cómo las claves principales y claves extemas crean la relación padre/hijo en una base de datos relacional: la tabla que contiene la clave principal es la tabla padre y la tabia que contiene 1a clave extema es la tabla hijo. Para utilizar la reiación padre/hijo en una consulta SQL, especificamos Lrna condición de búsqr"reda que colnpare la clave principal y la clave extema. En el Ejemplo 5.24, comparában-ros la clave principal de la tabla Client, c.clientNo, con la clave extema de la tabla Viewing, v.clientNo. El estándar SQL proporciona las siguientes tbrmas altemativas de especificar esta combinación:
FROM FROM FROM
I
I
ción (s.staffl. resultados st
JOIN Viewing v ON c.clientNo = v.clientNo JOIN Viewing USINC clientNo Client NATURAL JOIN Viewing Client c Client
En cada uno de los casos, la cláusula FROM sustituye a las cláusul¿rs FROM y WHERE originales. Sin ernbargo, 1a primera altemativa produce una tabla con dos columnas clientNo idénticas; las dos restantes generan una tabla con una irnica colur¡na clientNo.
t-
La tabla de I por lo que e: lizando la cr ella trabajan
Observe, de FROM y W
FROM
t
Ejemplo 5.25 Ordenación de una combinación Para cucla sucur.cal, indicar los ntimeros y los nombres de los entpleaclos que gestionan inmuebles, así conto los inmuebles que gestionan.
SELECT
I-I
s.branchNo, s.staffNo, fName, lName, propertyNo
FROM Staff s, PropertyForRent WHERE s.staffNo = p.staffNo ORDER BY
p
Ejemplo 5
s.branchNo, s.staffNo, propertyNo;
Determinar
Para hacer los resultados más legibles, hemos ordenado la salida r-rtilizando el núrnero de sucursal como clave principal de ordenación y el núunero de empleado y el núrmero de inmueble como claves secundarias. La tabla de resultados se muestra en la Tabla 5.25.
Tabla 5.25. Tabla de resultados para el Ejemplo 5.25
I
SELEC
FROM
WHER GROUI
ORDEI
branchNo
staffNo
fName
lName
propertyNo
B003
sct4
David
Ford
PGI6
B003
SG37
Ann
Becch
PG2I
Para genera están gestio
B003
SG37
Ann
Bccch
PG36
te la colum
8005
SL4I
Julie
Lee
PL94
8007
SA9
Mary
Howe
PAI4
grupos com
BY. Finalm tra en la Ta
Capítulo
To,"
5
SOL: manipulación de
datos
127
b.26 combinación de tres tabtas
?ctra cada sucursal, indicar los números y los nombres de los empleados que gestionan inmuebles, ,tcluyendo la ciudad en la que eslá ubicada la sucursal y los inmuebles Erc el empleado gestiona.
SELECT b.branchNo, b.city, s.staffNo, fName, lName, propertyNo FROM Branch b, Staff s, PropertyForRent p WHERE b.branchNo = s.branchNo AND s.staffNo = p.staffNo ORDER BY b.branchNo, s.staffNo,
propertyNo;
-: tabla de resultados requiere incluir columnas de tres tablas distintas: Branch, Staff y PropertyForRent, :-',r lo que es preciso utilizar una combinación. Los detalles referentes a Branch y Staff se combinan utizando la condición (b.branchNo : s.branchNo), para enlazar cada sucursal con los empleados que en :..a trabajan. Los detalles correspondientes a Staff y PropertyForRent se combinan utilizando la condi-.uin (s.staffNo : p.staffNo), paraefilazar cada empleado con los inmuebles que gestiona. La tabla de :sultados se muestra en la Tabla 5.26. Tabla 5.26. Tabla de resultados para el Ejemplo 5.26.
,
BranchNo
city
staffNo
fName
lName
propertyNo
B003
Glasgow
SGI4
David
Ford
PGI6
8003
Glasgow
SG37
Ann
Beech
PG2I
8003
Glasgow
SG37
Ann
Beech
PG36
B005
London
SL41
Julie
Lee
PL94
8007
Aberdeen
SA9
Mary
Howe
PA14
rsere, de nuevo, que el estándar SQL proporciona formulaciones altemativas para las
:lOM
cláusulas
y WHERE, como por ejemplo:
FROM (Branch
b
JOIN staff s USING branchNo) AS bs JOIN PropertyForRent p USING staffNo
ijemplo 5.27 Múltiples columnas de agrupamiento -:¿rminar el ntimero de inmuebles gestionados por cada empleado.
SELECT s.branchNo, s.staffNo, COUNT(*) AS FROM Staff s, PropertyForRent p
\\'HERE
myCount
s.staffNo = p.staffNo
GROUP BY s.branchNo, s.staffNo ORDER BY s.branchNo, s.staffNo;
:::J
geileror un listado con los números requeridos, necesitamos primero deteminar qué empleados
::.:n gestionando inmuebles. Esto puede hacerse combinando las tablas Staff y PropertyForRent median- -¡ columna staffNo, utilizando las cláusulas FROM/WHERE. A continuación, necesitamos formar -r-pos compuestos por el número de sucursal y el número de empleado, utilizando 1a cláusula GROUP - \. Finalmente, ordenamos la salida mediante la cláusula ORDER BY. La tabla de resultados se mues-
-:
en
1&
Tabla 5.21
.
12A
Sistemas de bases de datos Tabla 5.27(a). Tabla de resultados para el Ejemplo 5.27. BranchNo
staffNo
myCount
B003
SG14
I 2
B003
SG37
8005
SL4I
I
8007
SA9
I
La combina
SELEC
FROM WHER
Cálculo de una combinación Una combinación es un subconjunto de una combinación rnás general de dos tablas conocida con el nombre de producto cartesiano (véase la Sección 4.1.2). El producto cartesiano de dos tablas es otra tabla compuesta por todas las posibles parejas de filas extraídas de las dos tablas. Las colurnnas de Ia tabla producto son todas las columnas de la primera tabla, segr-rido de todas las columnas de la segunda tabla. Si especificamos una consulta sobre dos tablas sin una cláusula WHERE, SQL genera el producto cartesiano de las dos tablas como resultado de la consulta. De hecho, el estándar ISO proporciona una forma especial de la instrucción SELECT para calcular el producto cafesiano:
SELECT IDISTINCT IALLI {*
genera la ta
| Listacolumnas}
FRONI NombreTabla'l CROSS JOIN Nombrelabla2 Considere de nuevo el Ejernplo 5.24, en el que hemos ordenado las tablas Ctient y Viewing utilizando la colulnna de corespondencia cl¡entNo. Usando los dalos de Ia Figura 3.3, el producto cartesiano de estas dos tabias contendría20 tilas ( 4 clientes * 5 visitas : 20 filas). Es eqr.rivalente a la consulta usada en el Ejemplo 5.24,pero sin la ciáusula WHERE. Conceptualmente, el procedimiento para generar los resultados
Combinac¡ones externas La operación de combinación combina datos de dos tablas formando parejas de f-rlas relacionadas para las que las colulnnas correspondientes de cada tabla tienen los rnismos valores. Si una fila de una tabla no tiene ninguna correspondencia en la otra, se omite dicha fila de la tabla de resultados. Esto es lo que sucedía en las combinaciones que hemos analizado anteriormente. El estándar ISO proporciona otro conjunto de operadores de combinación denominados combinaciones externas (véase la Sección 4.1.3). La combinación externa retiene aquellas filas que no satisfagan la condición de combinación. Para entender ios operadores de combinación externa, considere las sigr-rientes dos tablas Branch y ProperlyForRent sirnpliticadas, a las que denominaremos Branchl y PropertyForRentl, respectivalnente:
- ' .-,b.¡ ,ie ---l:-: I':,1 CLr : ., l.JiJ!) eii
. :-ierr.to. ¡ . --, izquiet
-
. --, _ii'1ii.
r'-iL¡..I, - - --L:-.
SELEC
FRO}T --
I
--
:
.--1, :. -----ru.-.. --^--- -,1. _ -_-.L -:-:!11;
I
5
Capítulo
SOL: manipulación de
datos
129
PropertyForRentl
Branchl branchNo
bCity
propertyNo
pC¡ty
8003
Glasgow
PA14
Aberdeen
8004
Bristol
PL94
London
B002
London
PG4
Clasgow
a combinación (intema) de estas dos tablas:
SELECT b.., p..
FROM Branch'l b, PropertyForRent't WHERE b.bCity : p.pCity;
p
¡enera la tabla de resultados mostrada en la Tabla 5.21(b).
Tabla 5.27(b). Tabla de resultados para la combinación interna de las tablas Branchl y PropertyForRentl. branchNo
propertyNo
bCity
pCity
8003
Glasgow
PG4
Glasgow
B002
London
PL94
London
-
¿ tabla de resultados tiene dos filas en las qr.re las ciudades son iguales. En particula¡ observe que no hay -:Ltna ñla correspondiente a la sucursal de Bristol ni tampoco hay ninguna f,tla correspondiente al inmue" : Libicado en Aberdeen. Si queremos incluir en la tabla de resultados las filas que no tienen corresponden-. podemos emplear una combinación extema. Existen tres tipos de combinación extema: combinación : '::l& izquierda, derecha y completa. Ilustraremos su funcionalidad en los siguientes ejemplos.
'
Ejemplo 5.28 Combinación externa izquierda llit
j¿terar un listado con todas las suatrsales y los inmuebles que estén
en la misma ciudad que alguna
,tCurSAl.
' a combinación
liltil
externa izquierda de estas dos tablas:
SELECT b.-, p..
FROM Branchl
b LEFT JOIN PropertyForRentl p ON b.bCity
:
p.pCity;
¡roduce la tabla de resultados mostrada en la Tabla 5.28. En este ejemplo, la combinación externa -zquierda incluye no sólo aquellas filas que tienen ia misma ciudad, sino también aquellas filas de la :rimera tabla (la de la izquierda) que no tienen ninguna hla correspondiente en la segunda tabla (la de .a derecha). Las columnas correspondientes a la segunda tabla se rellenan con vaiores
NULL.
Tabla 5.28. Tabla de resultados para el Ejemplo 5.28. branchNo
bCity
propertyNo
pCity
8003
Glasgow
PG4
Glasgow
8004
Bristol
NULL
NULL
8002
London
PL94
London
\
130
tI I
Sistemas de bases de datos
Ejemplo 5.29 Combinación externa derecha Generur wt listado de todos los inmuebles ), de las sucursales Erc estén en la misma ciudad. La combinación extema derecha de estas dos tablas:
SELECT n.., p.. FROM Branchl b RICHT JOIN
PropertyForRentl p ON o.oCity
:
p.pCity;
produce la tabla de resultados rnostrada en la Tabla 5.29. En este ejerlplo, la combinación extema derecha incluye no sólo aqueilas filas que tienen la misma ciudad, sino también aquellas filas de la segunda tabla (la de la derecha) que no tienen ninguna fila correspondiente en la primera tabla (la de la izquierda). Las columnas correspondientes a la segunda tabla se rellenan con valores NULL.
Tabla 5.29. Tabla de resultados para el Ejemplo 5.29. propertyNo
pCity
NULL
PAl,t
Aberdeen
Glasgorv
PG4
Clasgow
Londor-r
PL94
Londor-r
branchNo
bCity
NULL B003
B002
tI
E¡empto 5.30 Combinación externa completa
Generar un listctdo con lus sucursales e inmuebles que estén en la misnta ciudad, inclu¡;endo en el listado las suatrsales o inmuebles que no tengan valores corre,spondientes. La cornbinación extema completa de estas dos tablas:
SELECT b.", p.. FROM Branchl b FULL JOIN
PropertyForRentl p ON b.bCity
-
p.pCity;
produce la tabla de resultados mostrada en la Tabla 5.30. En este caso, la corrbinación extema completa incluye no sóio aquellas filas que tienen la misma ciudad, sino tarnbién aquellas filas de ambas tablas que no tienen ninguna correspondencia. Las colrunnas que no tienen correspondencia se rellen¿rn
con valores NULL.
Tabla 5.30. Tabla de resultados para el Ejemplo 5.30.
5.3.8
propertyNo
pCity
NULL
PA14
Aberdecrr
Clasgow
PC4
Glasgow
B004
Bristol
NULL
NULL
8002
London
PL94
London
branchNo
bCity
NULL B003
EXISTS y NOT EXISTS
Las palabras clave EXISTS y NO EXISTS están diseñadas para utilizarlas únicar.nente denlro de subconsultas. Estas palabras clave prodr-rcen un simple resultado de tipo verdadero/falso. EXISTS es verdadera si y sólo
:-
:I ::
Capítulo
5
SOL: manipulación de
datos
131
.xiste una fila en la tabla de resultados devuelta por la consulta y es falsa si la subconsulta devuelve una --:-e de resultados vacía. NOT EXISTS es la condición opuesta a EXISTS. Puesto que EXISTS y NOT :.iiSTS sólo comprueban la existencia o no existencia de filas en la tabla de resultados de la subconsulta, la -:consulta puede contener cualquier número de columnas. Por simplicidad, resulta habitual que las subcon-.:¡s situadas a continuación de una de estas palabras clave tengan la forma:
SELECT*FROM...) Ejemplo 5.31 Consulta utilizando EXISTS
Erlreer todos los empleados que trabajen en una sucursal
de Londres.
SELECT staffNo, fName, lName, position FROM Statr s \\'HERE EXISTS (SELECT .
FROM Branch b WHERE s.branchNo
J
:
b.branchNo AND city
:
'London');
.sta consulta podría reformularse de la forma siguiente: 'Extraer todos los empleados tales que exista irna fila de Branch que contenga el número de sucursal del empleado, branchNo, y para las que el valor :ty de la sucursal sea igual a London'. La prueba que hay que realizar para incluir un empleado en el .'onjunto de resultados es la de existencia de dicha frla. Si existe, la subconsulta se evaluará como verJadera. La tabla de resultados se muestra en la Tabla 5.31.
Tabla 5.31. Tabla de resultados para el Ejemplo 5.31 StaffNo fName
lName
position
SL2 I
John
White
Manager
SL4I
Jutie
Lee
Assistant
.
Observe que la primera parte de la condición de búsqueda s.branchNo : b.branchNo es necesaria para ¿arantizar que estamos considerando la fila correcta de sucursal para cada empleado. Si omitiéramos 3sta parte de la consulta, todas las filas de empleados aparecerían en la tabla de resultados, porque la subconsulta (SELECT * FROM Branch WHERE city : 'London') siempre sería cierta y la consulta quedaría reducida a:
SELECT
staffNo, fName, lName, position
FROM
Staff
FROM
Staff;
WHERE
true;
que es equivalente a:
SELECT
staffNo, fName, lName, position
También podríamos haber escrito esta consulta utilizando una estructura de combinación:
SELECT
FROM
staffNo, fName, lName, position
Staff s, Branch b
WHER-E s.branchNo = b.branchNo AND city = 'London';
J
5.3.9 Gombinación de tablas de resu¡tados (UN!ON, INTERSECT, EXCEPT} :n SQL, podemos utilizar
las operaciones normales de conjuntos unión, intersección y diferencia para com¡inar los resultados de dos o más consultas en una única tabla de resultados:
\-
132
Sistemas de bases de datos
I
La unión de dos tablas, A y B, es una tabla que contiene todas las filas que están incluidas en la primerafablaA o en la segunda tabla B, o en ambas. I La intersección de dos tablas, A y B, es una tabla que contiene todas las filas que son comunes tanto a la tabla A como a la tabla B. I La diferencia de dos tablas, A y B, es una tabla que contiene todas las filas que están contenidas en tabla A pero no en la tabla B. Estas operaciones de conjuntos se ilustran en la Figura 5.1. Existen restricciones sobre las tablas que pueden combinarse mediante operaciones de conjuntos, siendo la más importante de dichas restricciones que las dos tablas deben ser co-patibl"r con respecto a la unión; es decir, deben tener la misma estructura. Esto implica que las dos tablas pueden contener el mismo número de columnas y que sus correspondientes colum,ru, ti".r", que tener los mismos tipos de datos y longitudes. Es responsabilidad del usuario garantizar que los provengan del mismo dominio. Por ejemplo, no sería valores de los datos en las columnu. "orr"rpo.rdientes con el número de habitaciones de un inmuedel empleado que la edad contenga columna lógico combinar una por ejemplo SMALLINT. de datos: mismo tipo el tengan columnas ambas cuando aún ble,
RS
RNS
RUS
;r'il .]3:
L.,
(c) Diferencia
"j1","",""". ,,n,,"';1, :
.",
":::
:
T::::::"
v 0,,"," n",l')o
"
ff :..'
Los tres operaclores de conjuntos en el estándar ISO se denorr-rinan UNION, INI'ERSECT y EXCEPT. formato cle la cláusula del operador de conjuntos es, en todos los casos: operador
E1
.;:
IALLI ICORRESPO\Dl\G lB\ { columnal l....lill
Si se especific¿r CORRESPONDING BY, la operación cle conjunlos se realizará sobre las colr.rmnas designaclas; si sé especifica Ia palabra clave CORRESPONDING pero no la clirusula BY, Ia operación de conjr-rntos se realiza sobre todas 1as colun'uras que sean comunes a ambas tablas. Si se especifica ALL, el resLtltado puecle incluir lilas dqtlicaclas. Algunos dialectos de SQL I1o soportan los operadores INTERSECT y EXCEPT; otros clialectos utilizan el operador MINUS en lr"tgar de EXCEPT.
Pu.,
!
I
Elemplo 5.32 Utilización de UNION Cr¡nstrttir una li.sÍa de todu.s lus cittdades en las cltre exista tttta sttctu'sttl o (SELECT * o bien (SELECT city
FROM Branch WHERE city IS NOT NULL) UNION (SELECT city
ut
inmtteble.
FROM Branch WHERE city IS NOT NULL) UNION CORRESPONDING BY ci§ (SELECT *
La
gul
Gapítulo Ull;.
FROM
lltl
.-\
-.
) Li
r'-
city IS
NOT NULL);
SQL: manipulación de
datos
133
PropertyForRent
WHERE
city IS NOT
NULL);
Est¿ consulta se ejecuta generando una tabla de resultados a partir de la primera consulta y oha tabla de resultados a partir de la segunda y luego combinando ambas tablas en una única tabla de resultados compuesta por todas las filas de ambas tablas de resultados, eliminándose las filas duplicadas. Latabla de resultados final se muestra enlaTabla 5.32.
Tabla 5.32. Tabla de resultados para el Ejemplo 5.32.
l*, -:i
FROM
PropertyForRent
WHERE
5
-
.i1-'_-
Ejemplo
5.33 Utilización de
INTERSECT
-' tnstntir una lista de todcts las ciudades en las que halta tanto ttna stlcttrsal como un inmueble.
(SELECT
o bien
city
FROM Branch) INTERSECT CORRESPONDING BY (SELECT *
FROM Branch) INTERSECT (SELECT
FROM
(SELECT *
city
FROM
PropertyForRent);
city
PropertyForRent);
Esta consulta se ejecuta generando una tabla de resultados apartir de la primera consulta y otra tabla de resultados a partir de la segunda y luego creando una única tabla de resultados compuesta por todas las frlas que sean comunes a ambas tablas. La tabla de resultados final se muestra en la Tabla 5.33.
Tabla 5.33. Tabla de resultados para el Ejemplo 5.33.
Podemos reescribir esta consulta sin el operador INTERSECT de la forma siguiente:
SELECT DISTINCT
b.c¡ty
o bien
F'ROM Branch b,
PropertyForRent p
WHEREb.city:
p.c¡ty;
SELECT DISTINCT city FROM Branch b WHERE EXTSTS (SELECT * FROM PropertyForRent p WHERE b.city: p.city);
La capacidad de escribir una consuita de varias formas equivalentes ilustra una de las ventajas del len-
guajeSQr-.
-|
734
Sistemas de bases de datos
t!
-
Construir una lista de todas las ciudades en las que haya mta sucursal pero no haya ningún inmueble.
(SELECT
(SELECT *
o bien
city
FROM Branch) EXCEPT (SELECT citv FROM
-:'a-aa
a
,' - -l: .lS:¡ il(lr , - --.-"x
Ejemplo 5.34 Utilización de EXCEPT
FROM
-
II
uL,-.
-, -í-;
Branch)
I :. :i:ne I i:L'e h:'
city
(SELECT * FRO
- ::. ,: l;ls
. - .:, Jet'e: ..-:,-lSSParii
EXCEPT CORRESPONDING BY
PropertyForRent);
'
PropertyForRent
-.,--t^ !L
)
-L]l
;
l-
!.trl1!r1.
Esta consulta se ejecuta produciendo una tabla de resultados a partir de la primera consulta y otra tabla de resultados a partir de la segunda y luego creando una única tabla de resultados compuesta por las filas que aparecen en la primera tabla de resultados pero no en Ia segunda. La tabla de resultados final se muestra en la Tabla 5.34. Podemos reesoribir esta consulta sin el operador EXCEPT de la forma siguiente:
SELECT DISTINCT FROM Branch
city
WHERE cityNOT IN (SELECT city FROM PropertyForRent);
o
bien
SELECT DISTINCT I.'ROM
city
I
e, iiPtr . aOITeSP(
Ejemplo
5
.:\at'tLlt'ttlt
Branch b
I\SER \.{LL T
WHERE NOT EXISTS (SELECT * FROM PropertyForRent p WHERE b.city - p.city);
PLLesto qLte
,-rbla. no h; :as. como '
Tabla 5.34. Tabla de resultados para el Ejemplo 5.34.
t:, I
Elemplo :
Insertor ttt staffNo, fNa
5.3.1O Actualizac¡ones de la base de datos
INSER
VALU]
SQL es un lenguaje de manipulación de datos completo que puede usarse también para modificar los datos de Ia base de datos y no sólo para consultarlos. Los comandos para modificar la base de datos no sorl tan com-
plejos corno la instrucción SELECT. En esta sección, varros a describir bles para modificar los contenidos de las tablas de la base de datos:
r f I
1as
tres instrucciones SQL disponi-
- añade nlrevas filas de datos a una tabla; - modifica los datos existentes en una tabla; DELETE - elimina filas de datos de ¡.rna tabla.
Puesto que bres de las es
significr
poclríamos
INSERT
UPDAIE
Adición de datos a la base de datos (INSERT) Hay dos fbrmas de instrucción INSERT. La primera permite insertar una úrnica fila en una tabla especificada y tiene el siguiente fonnato:
INSERT INTO
NombreTabta [(ListaCotumnas)]
INSET
VALU
En este ca valores Nl
La segunc :bla, y tiene
IN§ERT
',,'iggtr¡
Capítulo
5
SQL: manipulación de
datos
135
'.¡mbreTabla puede ser una tabla base o una vista actualizable (véase la Sección 6.4) y ListaCo/umnas repre:i.tr uüÍI lista de uno o más nombres de columnas, separados por comas. La ListaColumnas es opcional; si se - ,:iite, SLQ utilizará de forma predeterminada una lista de todas las columnas, en su orden original especi'ble.
'
-
'io
en la instrucción CRATE TABLE. Si se especifica esa lista de columnas, todas las columnas omitidas deberán haber sido declaradas como columnas NULL en el momento de crear la tabla, a menos que
.; .: hsta
: :-rbiera utilizado la opción DEFAULT al crear la columna (véasela Sección 6.3.2).La ListaVatoresDatos -::.3 corresponderse con la LlsfaColumnas de la forma siguiente:
I r bla
r
las
el número de elementos de cada lista debe ser el mismo; debe haber una correspondencia directa entre las posiciones de los elementos en ambas listas, de modo que el primer elemento de ListaVatoresDafos se aplique al primer elemento de ListaColumnas, el segundo elemento de ListaValoresDafos se aplique al segundo elemento de ListaColumnas, etc.;
el tipo de datos de cada elemento de ListavatoresDalos debe ser compatible con el tipo de datos de la correspondiente columna.
nal
i
Ejemplo 5.35 INSERT
. . . VALUES
lnsertar una nueva fila en la tabla
Slatt
suministrando datos para todas las columnas.
INSERT INTO StatT VALUES ('SC16', 'Alan','Brown', 'Assistant', 'M', DATE '1951-05-25', 8300, '8003'); Puesto que estamos insertando los datos en cada columna en el mismo orden en el que fue creada la ¡abla, no hay necesidad de especificar ninguna lista de columnas. Observe que los literales de caracteres, como 'Alan', deben encerrarse entre comillas
simples.
[-=n*,o
J
s.3G TNSERT utitizando vatores predeterm¡nados
Insertar una ntreva
fila
en la tabla StafÍ suministrando datos para todas las columnas obligaÍorias:
staffNo, fName, lName, position, salary
y
branchNo.
INSERT INTO Staf (staffNo, fName, lName, posltion, salary, branchNo) VALUES ('SG44', 'Anne', 'Jones', 'Assistant', 8100, '8003'); rs de
rom-
oni-
Puesto que estamos insertando datos únicamente en ciertas columnas, podemos especificar los nombres de las columnas en las que ios estatnos inserlando. El orden de los nombres de las columnas no es signifrcativo, aunque lo normal es especificarlas en el orden en que aparecen en la tabla. También podríamos expresar esta instrucción INSERT de la forma siguiente:
¡NSERT INTO StatT VALUES ('SG44', 'Anne', 'Jones', 'Assistant', NULL, NULL, 8100, '8003');
I
En este caso, hemos especificado explícitamente que las colurnnas sex y DOB deben configura rse con valores NULL. ada
La segunda fbnna de la instrucción INSERT pennite copiar múltiples hlas de una o rnás tablas en otra :abla, y tiene el siguiente fbnnato:
INSERT INTO
NombreTabla
SELECT...
[( ListaColumnas)l
136
Sistemas de bases de datos
NombreTabla y ListaColumnas se deñnen de la misma fbnna que en el caso anterior, en el que sólo insertábamos una fila. La clár"rsula SELECT puede ser cualquier instrucción SELECT válida. Las filas que se insertan en la tabla especificada serán idénticas a la tabla de resultados producida por la subselección. Aquí se aplican las mismas restricciones que ya hemos indicado para la primera lbnna de instrucción INSERT.
Lt SE
}\
5.37 INSERT.,.SELECT Suponga que hay una tabla StaffPropCount que contiene los nombres de los empleados y el número de inmuebles que gestionan: StaffPropCount(staffNo, fName, lName, propCount)
Rellenar la tabla StaffPropCount utilizando los detalles contenidos en las tablas
Staff
y
PropertyForRent.
INSERT INTO StanPropcount (SELECT s.stafrNo, fName, lName, COUNT(x) FROM Staff s, PropertyForRent p WHtrRE s.staffNo = p.staffNo CROUP BY
s.staffNo, fName, lName)
UNION (SELECT
staffNo, fName, lName, 0
FROM Staff s WHERE NOT EXISTS (SELECT * FROM PropertyForRent p WHERE p.staffNo = s staffNo))i Este ejemplo es bastante complejo, porque querernos contar el niunero de inmuebles que cada empleado gestiona. Si omitimos la segunda parte de la operación UNION, obtend¡emos únicamente una lista de aquellos que gestionan actualmente al menos un inrnueble; en otras palabras, estaríamos excluyendo a aquellos empleados que no gestionan ningún inmueble en la actualidad. Por tanto, para incluir también los erapleados que no gestionan ningún inmueble, necesitamos utilízar la instrr-rcción UNION e incluir una segunda instrucción SELECI utilizando un valor 0 para el atributo que indica el número de inmuebles. La tabla StaffPropCount será ahora como se muestra en la Tabla 5.35. Observe que algunos dialectos de SQL puede que no pernitan el uso del operador UNION dentro de una srüselección para una instrucción INSERT.
Tabla 5.35. Tabla de resultados para el Ejemplo 5.37. staffNo
fName
lName
propCount
SG 14
David
Ford
I
SL2 I
John
White
0
SG37
Ann
Beech
2
SA9
Mary
Howe
I
SG5
Susan
Brand
0
SL41
Julie
Lee
i
S@ñ'i
.. ,:]:
u
Modificación de datos en la base de datos (UPDATE) La instrucción UPDATE permite modificar el contenido de filas ya existentes en formato del comando es:
Lrna
tabla especiñcada.
E
T
Capítulo
5
SOL: man¡pulac¡ón de
datos
137
rnsertába-
PDATE
NombreTabla
;e insertan
L
se aplican
SET NombreColumnal = valorDatos't [, NombreColumnaz: valorDatos2. , .] _\\'H E RE condiciónBúsqueda] ''lombreTabla puede ser
el nombre de una tabla base o de una vista actualizable (véase la Sección 6.4). La
. ' *sula SET especifica los nombres de una o más columnas que hay que actualizal La cláusula WHERE
rro de
lent.
Ejemplo 5.38 Actualización de todas las filas mediante UPDATE lncrementar un
UPDATE
30.ó
el salario de lodos los empleados.
StaTT
SET salary: salary*1.03; Puesto que la actualización se aplica a todas las hlas de la tabla Staff, omitimos la cláusula
I
ll
*nt!
Ejemplo 5.39 Actualización de filas específicas mediante UPDATE lnctementar un 59ó el salario de todos los gerentes.
lea-
UPDATE Starr SET salary: sa|ary.1.05 WHERE position : 'Manager';
ista en-
luir
]N
La cláusula WHERE localiza las filas que contienen datos para los gerentes (Manager) y la actualización salary : salary*1,05 se aplica únicamente a dichas filas concretas.
1e-
de
I I
Ejemplo
5.40
Actualización de múltiples columnas mediante UPDATE
.Tscender a David Ford (staffNo
UPDATE
:
'SGl4') a Gerente
e incrementar su salario
a
18.000 euros.
Statr
SET position = 'Manager', salary = 18000
WHERE
stafrNo =
'SG14';
Borrado de datos de la base de datos (DELETE) [¿ instrucción DELETE permite borrar filas de una tabla especificada. El formato del comando
til
es
--onal; si se la otnite, las columnas especificadas se acfualizarán para todas las filas de la tabla. Si se es-:-:tlca una cláusula WHERE, sólo se actualizarán aqr"rellas filas que satisfagan la condiciónBúsqueda. Los -;" os valores valorDatos deben ser compatibles con los tipos de datos de las columnas correspondientes. -
DELETE FROM IWHERE
NombreTabla
condiciónBúsqueda]
es:
138
Sistemas de bases de datos
Al igual que sucede con las instrucciones INSERT y UPDAIE, NombreTabla puede ser el nombre de una tabla base o de una vista actualizable (véase la Sección 6.4). La condiciónBúsqueda es opcional; si se la omite, todas las filas serán borradas de la tabla. Esto no hace que se borre la propia tabla; para borrar tanto el contenido de la tabla como su definición, es necesario utilizar la instrucción DROP TABLE (véase la Sección 6.3.3). Si se especitica una condiciónBúsqueda, sólo se borrarán aquellas filas que satisfagan la condición indi-
, -.rll
uR(
¡
!
-i ::;1
.
cada.
I
I
Ejemplo 5.41 Borrado de filas específicas mediante DELETE
I
Borrar todas las visitas relativas al inmueble PG4. DELETE FROM Viewins WHERE propertyNo - 'PG4'; La clátrsula WHERE locahza las filas correspondientes al inmueble PG4 y Ia operación de bo rrado aplica irnicarnente a esas filas concretas.
5.42 Borrado de todas las filas mediante
No
t-,;
DELETE
: ..-"
se T
.J - li:
-,.L.i
-l
:.,- ..l'
.,. !
Borrar todas las /ilas de la tabla de visitas.
DELETE FRO}I
,
-...:
I S: ^.'..
Viewins:
ción ],\'HE
ninguna cláusula WHERE, por 1o que la operación de borrado se aplica a todas las tilas de la tabla. Esto elir¡ina de la tabla el contenido de todas las filas, dejando únicamente la definición de la tabla, por 1o que continuarernos siendo capaces de insertar datos en la tabla posteriorse ha especificado
n as.
,,,-]
- r..:l
menre'
¡
\J"'¡l .;f
Resumen del capítulo I
I
-l
si¡r
SQL es un lenguaje no procedimental, compuesto de palabras inglesas nonnales, tales como SELECT. INSERT o DELETE, pudiendo dicho lenguaje ser utilizando tanto por profesionales como por no prof'esionales de la infbrmátioa. Es el lenguaje estándar tanto fbnnal como de facto para la definición y mani-
I
r
e
I uesti«
¿(
La instrucción SELECT es la instrucción más irnportante del lenguaje y se utiliza para expresar una consulta. Combina las tres operaciones fundamentales del álgebra relacional, es decir, la Selección, la Pro¡tección y \a Combinación. Cada instrucción SELECT produce una tabla de resultados de la consulta. compuesta por una o más columnas y cero o más filas.
La cláusLrla SELECT identifica las columnas y/o los datos calcr.rlados que deben aparecer en la tabla
LiI
,-lJ) t '. ilL)r
pulación de bases de datos relacionales.
I
:
¿(
E. c¿
:(
de
¿(
resultados. Para todos los nombres de columna que aparezcan en la cláusula SELECT, las tablas de vistas correspondientes deberán haber sido especificadas en la ciáusula FROM.
H
La cláusula WHERE selecciona las filas que hay que incluir en la tabla de resultados, aplicando la condición de búsqueda a las filas de la tabla o tablas especificadas. La cláusuia ORDER BY permite ordenar la tabla de resultados según los valores de una o más columnas. Para cada una de la columnas se puede utilizar un orden ascendente o descendente. Si se especif,rca, la cláusula ORDER BY debe ser la última cláusula de la instrucción SELECT. SQL soporta cinco funciones de agregación (COUNT, SUM, AVG, MIN y MAX) que totnan una coluluna completa como argllmento y calculan un irnico valor como resultado. No está permitido rnezclal fr,rn-
r_.
¿(
ut
iiercic :-::
los
-:itu1o
Capítulo
.
-1es agregadas con nombres de columna en una cláusula
5
SOL: manipulación de
datos
139
SELECI a menos que se utilice la cláusula
. ?.OUP BY,
cláusula GROUP BY permite incluir información de resumen en la tabla de resr¡ltado. Las ñlas que ten--:. Ios mismos valores para una o más columnas pueden agruparse o tratarse con una unidad para utili-.. 1as funciones de agregación. En este caso, ias funciones de agregación toman cada uno de los grupos . :ro argumento y calcr.rlan un único valor como resultado paru cada uno de esos grupos. La cláusula :^\'lNG actúa como una cláusula WHERE para los grupos, restringiendo los grupos que aparecen en la -:.¡ de resultados finales. Sin embargo, a diferencia de la cláusula WHERE, la cláusula HAVING puede :.uir funciones de agregación.
-,
, :.. subselección es una instrucción SELECT completa incrustada dentro de otra consulta. Una subselec-
. ,r
puede aparecer dentro de las cláusulas WHERE o HAVING de otra instrucción SELECT más extercaso se ia denomina subconsulta o consulta anidada. Conceptualmente, una subconsultaprotabla temporal cuyo contenido es accesible por parte de la consulta extema. Una subconsulta Lrna ---e . -:de incrustarse dentro de otra subconsulta.
--. in cuyo
J rSg
:.. lres tipos de subconsultas: escalar, de fila y de tabla. Una subconsulta escalar devuelve una única " .;mna y una única ñla, es decir, un único valor. En principio, puede utilizarse una subconsulta escalar
: -
,:ualquier lugar donde sea necesario utilizar un único valor. Una subconsulta de fila devuelve rnúltiples rrnnas, pero de nuevo de una única fila. Puede utilizarse una subconsulta de fila siempre que haga falta :--.rlear un constmctor de valores de f,rla, 1o que nonnalmente sucede en los predicados. Una subconsul.¡., rabla deluelve una o más coh,rmnas y múrltiples filas. Puede utilizarse una subconsulta de tabla siem.:. que se necesite nna tabla, como por ejemplo como operando para el predicado IN.
:
.
-¡s columnas de la tabla de resultados provienen de más de una tabla, deberá utilizarse una combina-
:ton especificando más de una tabla en la ciáusula FROM y, normalmente, inciuyendo una cláusula Ias
'.
-'IERE para indicar la columnas de combinación. El estándar ISO permite deflnir combinaciones exter-
:¡s. También pennite utilizar las operaciones de conjr.rnfos de Unión, Intersección y Diferencia, para lo - -:. se emplean los comandos UNION, INTERSECT y EXCEPT. -.:ernás de la instrucción SELECT, el lenguaje DML de SQL incluye la instrucción INSERT para inser-. una única fila de datos en una tabla especificada o para insertar un número arbitrario de filas de una o
le-
J )r-
'..s tablas mediante una subselección; la instrucción UPDATE, por su parte, permite acfuahzar uno o más
:.ores eo una columna o columnas especificadas de una determinada tabla. La instrucción DELETE :-r. e para borrar una o más fiIas de una tabla especificada. .ECT rrof-e-
nani-
I -estiones de repaso ¿Cuáles son los dos componentes principales de SQL
, :
conla ;ulta.
n,
¿Cuáles son las ventajas
y qué función tienen?
y desventajas de SQL?
Explique la función de cada una de las cláusulas de la instmcción SELECT. ¿Qué restricciones se aplican a estas cláusulas? ¿Qué restricciones se aplican al uso de instrucciones de agregación dentro de la instrucción SELECT? ¿Córno afectan los valores NULL a las funciones de agregación?
la de istas
HAVING? rndiar la
utiIáu-
'
¿Cuál es la diferencia entre una subconsulta y una combinación? ¿Bajo qué circunstancias no puede utilizarse una subconsulta?
:rerc¡clos
ul11-
.,ra ios Ejercicios 5.7
In-
--:pitulo
-
5.28, utilice el esquema Hotel definido al principio de la Sección de Ejercicios del
3.
L.
14O Sistemas de bases de datos Gonsultas simples
. 5.8. 5.9. 5.1
,,r.'f.r:{
Generar un listado con todos 1os detalles de los hoteles. Generar un listado con todos los detalles de todos 1os hoteles situados en Londres. Generar un listaclo con 1os nombres y direcciones de todos los huéspedes que viven en Londres, ordenado altabéticamente por nombre.
5. I
0.
Generar un listado cle todas 1as habitaciones dobles o fal¡ il iares cuyo precio sea inf-erior a 40 euros por noche, en orden ¿rscendente de precios.
5. I
1.
Generar un list¿rdo con todas las reservas para las qrre no se haya especit-rcado un valor de dateTo.
:.i
i,,.t'
,,,
Funciones de agregación
5.12. 5.13. 5.
I
4.
5.15.
¿,Cr.rántos hoteles hay'? ¿,Cuhl es
0bjetivos
el precio n-iedio de una habitación?
¿CLrál es el ingreso total por noche generado por lodas las habitaciones dobles'/
En este
¿,Cuán1os huéspedes dif'erentes han hecho reservas para agosto'.)
I r I
Subconsultas y comb¡nac¡ones
5.16. 5
.11
5.
.
18.
Generar un listado con el precio y el trpo de todas las habitaciones de1 Grosver.ror Hotel.
Lrn
oi ri
correspondiente a las reservas realizadas en el Grosvenor l"lotel hoy'l
.f
listado con las habitaciones acLualmente no ocupadas en el Grosvenor Hote1.
5.21. ¿Cuiii es iapérdida
I
de ingresos debido ahabitaciones no ocupadas en e1 Grosvenor Hotel?
Generar un listado con el nÍu¡ero de habit¿rciones de cada hotel. Generar un listado con el núunero de habitaciones en cada hotel de Londres. ¿CLriii es e1 número medio de reservas para cada hotel en agosto?
¿Cuál es
e1
tipo de habitación más comúnmente leservada para
cacia
hotel de Londres?
,',Cuál es la pérdida de ingresos debida a habitaciones no ocupadas en cada hotel hoy?
lntroducción de datos en tablas 5.21
.
5.2tt.
Actr,raiice el precio de todas las habitaciones en un 50á.
Cón Bajr Las
Cón Cón
Estrur SQL r.rtilizado en 1os SGBD que esté actualmente ernpleando. Determine
1a
com-
patibilidad del sistema con las instrucciones DML de1 estánciar ISO. Investigue ia firncionalidacl
c1.-
cualescluiera extensiones que sLr SGBD soporle. ¿Hay alguna fimción no soportada'? Demuestre que tocla consuha cllre tenga una cláusu1¿r I-IAVING tiene una fbrmulación equivalente sin dicha c1áusu1a.
5.31. Denuestre
Cón
::ticrllar, ( :rtación d
Guestiones generales
5.30.
E1p
::] el capitr
Inserte lilas en cada una de estas tablas.
5.29. Investigue el dialecto
Cór
TAE
r I I r I I I
Agrupamientos
5.22. 5.23. 5.24. 5.25. 5.26.
Cón aJ
Gener¿rr r-rn listado con 1os detalles de todas las habitaciones del Grosvenor Hotel, incluyendo el nombre del huésped que ocupa 1a habitación, si es que la liabitación está ocupada.
-5.20. Cener¿ir
Elpr
ac
Generar r.rn listado con todos los huéspedes que actllalmente tiene el Grosvenor [{otel.
5.19. ¿Cuiil es el ingreso total
Los
que SQL es
r"rn
lenguaje relacionalmente corr-rpleto.
:
- .a Secc r Sllca de . -'ial y ci
--
lralna
:e :
1a
c
int
-.raiizar
-,
,..
integr
Capítulo
SQL: definición de datos Objetivos del capítulo: En este capítulo aprenderá: •
Los tipos de datos soportados por el estándar SQL.
•
El propósito de las características de mejora de la integridad en SQL.
•
Cómo definir restricciones de integridad utilizando SQL, incluyendo: • •
datos requeridos; restricciones de dominio;
•
integridad de entidades;
•
integridad referencial;
•
restricciones generales.
•
Cómo utilizar las características TABLE.
•
El propósito de las vistas.
de mejora de la integridad en las instrucciones CREATE y ALTER
•
Cómo crear y borrar vistas utilizando SQL.
•
Cómo realiza el SGBD las operaciones sobre las listas.
•
Bajo qué condiciones son las vistas actualizables.
• •
Las ventajas y desventajas de las vistas. Cómo funciona el modelo de transacciones de ISO.
•
Cómo utilizar las instrucciones GRAN y REVOKE como medida de seguridad.
En el capítulo anterior hemos hablado con algún detalle del lenguaje SQL (Structured Query Language) y, en particular, de las funciones de manipulación de datos de SQL. En este capítulo, vamos a continuar nuestra presentación de SQL y a examinar las principales funciones de definición de datos en este lenguaje.
Estructura del capítulo En la Sección 6.1 se examinan los tipos de datos SQL e ISO. El estándar ISO de 1989 introdujo una característica de mejora de la integridad que proporciona funciones para definir restricciones de integridad referencial y de otros tipos (ISO, 1989). Antes de la aparición de este estándar, era responsabilidad de cada programa de aplicación garantizar la conformidad con estas restricciones. Gracias a la característica de mejora de la integridad, la funcionalidad de SQL se completa con una funcionalidad muy necesaria, que permite centralizar y estandarizar la comprobación de las restricciones. Consideraremos las características de mejora de la integridad en la Sección 6.2 y las principales funciones de definición de datos en SQL en la Sección 6.3.
142
Sistemas de bases de datos
En la Sección 6.4 mostraremos cómo pueden crearse vistas mediante SQL y cómo convierte el SGBD las operaciones sobre las vistas en otras operaciones equivalentes sobre las tablas base. También explicaremos las restricciones que el estándar ISO de SQL impone a las vistas con el fin de que éstas puedan ser actualizables. En la Sección 6.5, hablaremos brevemente del modelo de transacciones del estándar SQL de ISO. Las vistas proporcionan un cierto grado de seguridad a la base de datos, pero SQL también proporciona un subsistema independiente de control de acceso, que contiene funciones para permitir a los usuarios compartir los objetos de la base de datos o, alternativamente, para restringir el acceso a ciertos objetos. Hablaremos del subsistema de control de acceso en la Sección 6.6. En la Sección 28.4 se examinan con cierto detalle las características que se han añadido recientemente a la especificación SQL para soportar la gestión de datos orientada a objetos, haciendo referencia a los estándares SQL: 1999 y SQL:2003. En el Apéndice E se explica cómo puede integrarse SQL en lenguajes de programación de alto nivel para acceder a estructuras que hasta ahora no estaban disponibles en SQL. Como en el capítulo anterior, presentaremos las características de SQL utilizando ejemplos extraídos del caso de estudio de DreamHome. Utilizaremos la notación definida en la Sección 5.2 para especificar el formato de las instrucciones SQL.
6.1 Tipos de datos SQl de ISO En esta sección vamos a presentar los tipos de datos definidos en el estándar SQL. Comenzaremos do qué es lo que constituye un identificador válido en SQL.
definien-
6.1.1 Identificadores SOL Los identificadores SQL se utilizan para identificar objetos en la base de datos, como por ejemplo nombres de tablas, nombres de vistas y columnas. Los caracteres que pueden utilizarse en un identificador SQL definido por el usuario deben aparecer dentro de un determinado conjunto de caracteres. El estándar ISO proporciona un conjunto de caracteres predeterminado, que está compuesto por las letras mayúsculas A ... Z, las letras minúsculas a ... z, los dígitos O ... 9 Y el carácter de subrayado ( _ ). También es posible especificar conjuntos de caracteres alternativos. Las restricciones aplicables a los identificadores son las siguientes: •
cada identificador no puede tener más de 128 caracteres de longitud (la mayoría de los dialectos tienen un límite muy inferior a éste);
•
cada identificador debe comenzar con una letra;
•
los identificadores no pueden contener espacios.
booleano
INTEGER DECIMAL RAEL TIME TIMESTAMP DOUBLE VARCHAR BITVARYING SMALLINT CHAR NUMERIC FLOAT DATE INTERVAL PRECISION Declaraciones BOOLEAN BIT CHARACTER BINARY LARGE OBJECT Tabla 6.1. TiposLARGE de datosOBJECT SQL e ISO.
gran tamaño
¡BIT y BIT VARYING han sido eliminados del estándar SQL:2003.
Capítulo 6 SOL: definición de datos
143
6.1.2 Tipos de datos SOL escalares La Tabla 6.1 muestra los tipos de datos SQL escalares definidos en el estándar ISO, para propósitos de manipulación y conversión, los tipos de datos carácter y bit se denominan colectivamente como tipos de datos de cadena, mientras que los tipos de datos numérico exacto y numérico aproximado se denominan tipos de datos numéricos, ya que comparten propiedades similares. El estándar SQL:2003 también define objetos de gran tamaño de tipo carácter y de tipo binario, aunque dejaremos las explicaciones sobre estos tipos de datos para la Sección 28.4.
Datos booleanos Los datos booleanos están compuestos de los valores de verdad TRUE y FALSE. A menos que lo prohiba una restricción NOT NULL, los datos booleanos también soportan el valor de verdad UNKNOWN como valor NULL. Todos los valores de los tipos de datos booleanos y los valores de verdad de SQL son mutuamente comparables y asignables. El valor TRUE es mayor que el valor FALSE y cualquier comparación que implique el valor NULL o un valor de verdad UNKNOWN devolverá el resultado UNKNOWN (desconocido).
Datos de caracteres Los datos de caracteres están compuestos de una secuencia de caracteres extraídos de un conjunto de caracteres definidos por la implementación, es decir, definido por el fabricante del dialecto SQL concreto. Por tanto, los caracteres exactos que pueden aparecer como valores de datos en una columna de tipo carácter pueden variar. Dos conjuntos de caracteres de uso común hoy en día son ASCII y EBCDIC. El formato para especificar un tipo de datos de carácter es: CHARACTER
[VARYING] [longitud]
CHARACTER
puede abreviarse como CHAR y
CBARACTER
VARYINGcomo
VARCHAR.
Cuando se define una columna de cadena de caracteres, puede especificarse una longitud para indicar el número máximo de caracteres que la columna puede almacenar (la longitud predeterminada es 1). Las cadenas de caracteres pueden definirse como de longitud fija o variable. Si la cadena se define como de longitud fija e introducimos una cadena con menos caracteres que la longitud especificada, se rellenará la cadena de caracteres con blancos en el lado derecho hasta alcanzar el tamaño deseado. Si la cadena está definida como de longitud variable e introducimos una cadena con menos caracteres que la longitud especificada, sólo se almacenarán los caracteres introducidos, por lo que se ocupará menos espacio. Por ejemplo, la columna de número de sucursal brachNo en la tabla Branch, tiene una longitud fija de cuatro caracteres, está declarada como: branchNo
CHAR(4)
La columna address de la tabla de 30, está declarada como: address
PrivateOwner,
que tiene un número variable de caracteres, hasta un máximo
VARCHAR(30)
Datos de bit El tipo de datos bit se utiliza para definir cadenas de bits, es decir, secuencias de dígitos binarios (bits), cada uno de los cuales puede tener el valor O o l. El formato para especificar el tipo de datos bit es similar al del tipo de datos de carácter: BIT [VARYING]
[longitud]
144
Sistemas de bases de datos
Por ejemplo, para almacenar la cadena binaria de longitud fija '0011', podemos declarar una columna como:
bitString
bit8tringBIT(4)
6.1.3 Datos numéricos exactos El tipo de datos numéricos exactos se utiliza para definir números con una representación exacta. Cada número estará compuesto por dígitos, por una coma decimal opcional y por un signo también opcional. Un tipo de datos numérico exacto tendrá una precisión y una escala. La precisión indica el número total de digitos significativos, es decir, el número total de dígitos, incluyendo los dígitos decimales pero excluyendo la propia coma decimal. La escala nos indica el número total de posiciones decimales. Por ejemplo, el valor numérico exacto -12,345 tiene una precisión igual a 5 y una escala igual a 3. Un caso especial de números exactos son los enteros. Existen diversas formas de especificar un tipo de datos numérico exacto: NUMERIC [ precisión [, escala] ] DECIMAL [ precisión [, escala] ] INTEGER SMALLINT INTEGER puede abreviarse como INT y DECIMAL como DEC NUMERIC y DECIMAL almacenan los números en notación decimal. La escala predeterminada siempre es cero; la precisión predeterminada depende de la implementación. INTEGER se utiliza para números enteros positivos o negativos de gran tamaño, mientras que SMALLINT se utiliza para números enteros positivos o negativos de pequeño tamaño. Especificando este tipo de datos, puede reservarse menos espacio de almacenamiento para datos. Por ejemplo, el valor máximo absoluto que puede almacenarse con SMALLINT puede ser en algunas implementaciones igual a 32.767. La columna rooms de la tabla PropertyForRent, que representa el número de habitaciones de un inmueble, es obviamente un entero de pequeño tamaño y puede declararse como: rooms SMALLINT La columna salary de la tabla 8taff puede declarase como: salary DECIMAL(7,2) que puede contener valores hasta 99.999,99.
Datos numéricos aproximados Los tipos de datos numéricos aproximados se utilizan para definir números que no tienen una representación exacta, como, por ejemplo, los números reales. Los números aproximados o en coma flotante son similares a la notación científica, en la que los números se escriben como una mantisa multiplicada por alguna potencia de diez (el exponente). Por ejemplo, 10E3, +5,2E6, -0,2E-4. Hay diversas formas de especificar un tipo de datos numérico aproximado: FLOAT [precisión] REAL DOUBLE PRECISION La precisión controla la precisión de la mantisa. La precisión de los datos de tipo REAL y DOUBLE PRECISION depende de cada implementación.
Capítulo 6 SOL: definición de datos
145
Datos de fecha y hora Los tipos de datos de fecha y hora se utilizan para definir instantes temporales con un cierto grado de precisión. Como ejemplos tendríamos las fechas, las horas y la hora del día. El estándar ISO subdivide los tipos de datos de fecha y hora en YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, TIMEZONE _HOUR y TIMEZONE _MINUTE. Los dos últimos tipos especifican la hora y los minutos del desplazamiento de la zona horaria con respecto a la hora UCT (Universal Coordinated Time, hora universal coordinada), que anteriormente se denominaba horario de Greenwich (Greenwich Mean Time, GMT). Hay tres tipos de datos de fecha y hora: DATE TIME [precisiónTemporal]
[WITH TIME ZONE] (WITH TIME ZONE]
TIMESTAMP (precisiónTemporal]
DATE se utiliza para almacenar fechas de calendario utilizando los campos YEAR, MONTH y DAY. TIME se utiliza para almacenar la hora utilizando los campos HOUR, MINUTE y SECOND. TIMESTAMP se emplea para almacenar la fecha y la hora. La precisión Temporal es el número de posiciones decimales de precisión con las que debe almacenarse el campo SECOND. Si no se especifica, TIME utiliza una precisión predeterminada de O (es decir, segundos enteros) y TIMESTAMP utiliza una precisión predeterminada de 6 (es decir, microsegundos). La palabra clave WITH TIME ZONE controla la presencia de los campos TIMEZONE _HOUR y TIMEZONE _MINUTE. Por ejemplo, la columna DATE de la tabla Viewing, que representa la fecha (año, mes, día) en que un cliente ha visitado un inmueble, está declarada como: viewDate
DATE
Datos de intervalo El tipo de datos de intervalo se utiliza para representar periodos de tiempo. Cada tipo de datos de intervalo está compuesto por un subconjunto contiguo de los siguientes campos: YEAR, MONTH, DA Y, HOUR, MINUTE, SECOND. Hay dos clases de tipos de datos de intervalo: intervalos año-mes e intervalos día-hora. La clase año-mes puede contener únicamente los campos YEAR y/o MONTH; la clase día-hora puede contener únicamente una selección contigua de DAY, HOUR, MINUTE, SECOND. El formato para especificar el tipo de datos de intervalo es: INTERVAL {{campoInicio TO campoFin} campoFechahoraÚnico} campolnicio
= YEAR I MONTH
I
DAY I ROUR
[(precisiónCampolnicialIntervalo) campoFin
= YEAR
I
MONTR
I
campoFechahoraÚnico
= campoInicio
I
MINUTE
I
MINUTE
]
DAY I ROUR
((precisióriFraccionesSegundo)
I
I
SECOND
]
SECOND
(precisiónCampolnicialIntervalo
[, precisiónFraccionesSegundo])]
En todos los casos, campolnicio tiene una precisión predeterminada
del campo inicial igual a 2. Por ejem-
plo: INTERVAL YEAR(2) TO MONTH representa un intervalo de tiempo con un valor comprendido entre tras que INTERVALHOUR
O
años
O
meses y 99 años
11
meses, mien-
TO SECOND(4)
representa un intervalo de tiempo con un valor comprendido entre O horas O minutos 59 minutos 59,9999 segundos (la precisión fraccional de los segundos es igual a 4).
O
segundos y 99 horas
146
Sistemas de bases de datos
Operadores escalares SQL proporciona una serie de funciones y operadores escalares integrados que pueden utilizarse para construir una expresión escalar, es decir, una expresión que proporcione como resultado de la evaluación un valor los operadores que se escalar. Además de los operadores aritméticos obvios (+, -, *, /), están disponibles muestran en la Tabla 6.2. Tabla 6.2.
Operadores
escalares
SQL de ISO.
Operador
Significado
BIT LENGTH
Devuelve longitud de una cadena en bits. Por ejemplo, BIT_LENGTH(X'FFFF') devuelve 16.
OCTET
Devuelve la longitud de una cadena en octetos (número de bit dividido entre 8). Por ejemplo, OCTET_LENGTH(X'FFFF') devuelve 2.
LENGTH
Devuelve la longitud de una cadena en caracteres (u octeto s, si la cadena es una cadena de bits). Por ejemplo, CHAR_LENGTH('Beech') devuelve 5. CAST
Convierte el valor de la expresión de un tipo de datos en un valor correspondiente otro tipo de datos. Por ejemplo, CAST(5,2E6 AS INTEGER).
a
Concatena dos cadenas de caracteres o de bits. Por ejemplo, fName IIIName. CURRENT o USER SESSION
USER
USER
Devuelve una cadena de caracteres que representa el identificador actual de autorización (informalmente, el nombre del usuario actual). Devuelve una cadena de caracteres que representa el identificador de autorización de la sesión SQL. Devuelve una cadena de caracteres que representa el identificador invocado al módulo actual.
del usuario que ha
LOWER
Convierte las letras mayúsculas en minúsculas. Por ejemplo, LOWER(SELECT fName FROM Staff WHERE staffNo = 'SL21') devuelve 'john'.
UPPER
Convierte las letras minúsculas en mayúsculas s. Por ejemplo, UPPER(SELECT fName FROM Staff WHERE staffNo = 'SL21') devuelve 'JOHN'.
TRIM
Elimina los caracteres iniciales (LEADING), finales (TRAILING) como finales (BOTH) de una cadena. Por ejemplo, TRIM(BOTH Hello World ***') devuelve 'Hello World'.
o tanto iniciales
,*, FROM '***
POSITION
Devuelve la posición de una cadena dentro de otra cadena. Por ejemplo, POSITION ('ee' IN 'Beech') devuelve 2.
SUBSTRING
Devuelve una sub cadena seleccionada de una cadena. Por ejemplo, SUBSTRING ('Beech' FROM 1 TO 3) devuelve la cadena 'Bee'.
CASE
Devuelve un valor de entre una serie de valores especificados, condición. Por ejemplo,
basándose en alguna
CASEtype WHEN 'House' THEN 1 WHEN 'Flat' THEN 2 EL SE O END Continúa
Capítulo 6 SOL: definición de datos Tabla 6.2.
147
Operadores escalares SQL de ISO. (Cant.)
Operador
Significado
CURRENT DATE
Devuelve la fecha actual en la zona horaria local al usuario.
CURRENT TIME
Devuelve la hora actual en la zona horaria predeterminada de la sesión actual. Por ejemplo, CURRENT_TIME(6) proporciona la hora con una precisión de microsegundos.
CURRENT TIMESTAMP
Devuelve la fecha y la hora actuales en la zona horaria predeterminada para-la sesión. Por ejemplo, CURRENT_TIMESTAMP(O) proporciona la hora con una precisión de segundos.
EXTRACT
Devuelve el valor de un campo especificado de un valor de fecha y hora o de intervalo. Por ejemplo, EXTRACT(YEAR FROM Registration.dateJoined).
6.2 Características de mejora de la integridad En esta sección, vamos a examinar las funciones proporcionadas por el estándar SQL para el control de integridad. El control de integridad está compuesto por restricciones que deseamos imponer con el fin de proteger la base de datos frente a posibles incoherencias. Vamos a considerar cinco tipos distintos de restricciones de integridad (véase la Sección 3.3): • •
datos requeridos; restricciones de dominio;
•
integridad de entidades;
•
integridad referencial;
•
restricciones generales.
Estas restricciones pueden definirse en las instrucciones CREATE y ALTER TABLE, como veremos en breve.
6.2.1 Datos requeridos Algunas columnas deben contener un valor válido; no está permitido que dichas columnas contengan valores nulos. Los valores nulos son diferentes de los espacios en blanco o de los valores numéricos iguales a cero, y se utilizan para representar datos que o bien no están disponibles, o faltan o bien no son aplicables (véase la Sección 3.3.1). Por ejemplo, todos los empleados deben tener un cargo asociado (por ejemplo, Gerente, Asistente, etc.). El estándar ISO proporciona el especificador de columna NOT NULL en las instrucciones CREA TE y ALTER TABLE para indicar este tipo de restricción. Cuando se especifica NOT NULL, el sistema rechaza cualquier intento de insertar un valor nulo en esa columna. Si se especifica NULL, el sistema aceptará los valores nulos. La opción predeterminada de ISO es NULL. Por ejemplo, para especificar que la columna position de la tabla Staffno puede ser nula, definimos la columna como: positionVARCHAR(lO)
NOT NULL
6.2.2 Restricciones de dominio Toda columna tiene un dominio, es decir, un conjunto de valores legales (véase la Sección 3.2.1). Por ejemplo, el sexo de un empleado puede ser 'M' o 'F', por lo que el dominio de la columna sex de la tabla Staff es una única cadena de caracteres compuesta de 'M' o 'F'. El estándar ISO proporciona dos mecanismos para especificar dominios en las instrucciones CREATE y ALTER TABLE. El primero es la cláusula
148
Sistemas de bases de datos
CHECK, que permite definir una restricción sobre una columna o sobre la tabla completa. El formato de la cláusula CHECK es: CHECK (condiciónBúsqueda) En una restricción de columna, la cláusula CHECK puede hacer referencia únicamente a la columna que se esté definiendo. Por tanto, para garantizar que la columna sex solo puede especificarse como 'M' o 'F', podríamos definir la columna como: sex CHAR NOT NULL CHECK (sex IN ('M', 'F')) Sin embargo, el estándar ISO permite definir los dominios más explícitamente utilizando la instrucción CREATE DOMAIN: CREATE DOMAIN NombreDominio
[AS] tipoDatos
[DEFAULT opciónPredeterminada) [CHECK (condiciónBúsqueda)) Al dominio 6.1.2), un valor ta, pero resulta nir un dominio
se le asigna un nombre, NombreDominio, un tipo de datos (como se describe en la Sección predeterminado opcional y una restricción CHECK opcional. Ésta no es la definición complesuficiente para ilustrar el concepto básico. Con ello, para el ejemplo anterior, podríamos defipara sex de la forma siguiente:
CREATE DOMAIN SexType AS CHAR DEFAULT'M' CHECK (VALUE IN CM', 'F')); Esto crea un domino SexType que está compuesto por un único carácter que puede tener el valor 'M' o 'F'. Al definir la columna sex, podremos ahora utilizar el nombre de domino SexType en lugar del tipo de datos CHAR: sex SexType NOT NULL La condiciónBúsqueda puede implicar una búsqueda en una tabla. Por ejemplo, podemos crear un dominio BranchNumber para garantizar que los valores introducidos se correspondan con un número de sucursal existente en la tabla Branch, utilizando para ello la instrucción: CREATE DOMAIN BranchNumberAS CHAR(4) CHECK (VALUE IN (SELECT branchNo FROM Branch)); El método preferido para definir restricciones de dominio consiste en utilizar la instrucción CREATE DOMAIN. Los dominios pueden eliminarse de la base de datos utilizando la instrucción DROP DOMAIN: DROP DOMAIN NombreDominio
[RESTRICT
I
CASCADE]
El tipo de eliminación, RESTRlCT o CASCADE, especifica la acción que hay que tomar si el dominio está actualmente en uso. Si se especifica RESTRICT y el dominio está siendo utilizado en una definición de tabla, vista o aserción existente (véase la Sección 6.2.5), la eliminación no podrá llevarse a cabo. En el caso de CASCADE, las columnas de tabla que estén basadas en ese dominio se modificarán automáticamente para utilizar el tipo de datos subyacente de dicho dominio, y todas las restricciones o cláusulas de valor predeterminado para dicho dominio se sustituirán por una restricción de columna o una cláusula de valor predeterminado de la columna, en caso apropiado.
Capítulo 6 SOL: definición de datos
149
6.2.3 Integridad de entidades La clave principal de una tabla debe contener un valor univoco y no nulo en cada fila. Por ejemplo, cada fila de la tabla PropertyForRent tiene un valor unívoco para el número de inmueble propertyNo, que identifica de forma distintiva el inmueble representado por dicha fila. El estándar ISO soporta las restricciones de integridad de entidades mediante la cláusula PRIMARY KEY en las instrucciones CREATE y ALTER TABLE. Por ejemplo, para definir la clave principal de la tabla PropertyForRent, incluimos la cláusula: PRIMARY KEY(propertyNo) Para definir una clave principal compuesta, se especifican múltiples nombres de columna en la cláusula PRIMARY KEY, separando cada uno de ellos mediante una coma. Por ejemplo, para definir la clave principal de la tabla Viewing,que está compuesta por las columnas c1ientNoy propertyNo, incluimos la cláusula: PRIMARY KEY(clientNo, propertyNo) La cláusula PRIMARY KEY puede especificarse únicamente una vez por cada tabla. Sin embargo, sigue siendo posible garantizar la unicidad para cualesquiera claves alternativas que tenga la tabla utilizando la palabra clave UNIQUE. Cada columna que aparezca en una cláusula UNIQUE debe también declararse como NOT NULL. Puede haber tantas cláusulas UNIQUE por cada tabla como sea necesario. SQL rechazará todo intento de efectuar una operación INSERT o UPDATE mediante el cual se intente crear un valor duplicado dentro de algunas de las claves candidatas (es decir, claves principales o claves alternativas). Por ejemplo, con la tabla Viewingtambién podríamos haber escrito: clientNo VARCHAR(s) propertyNo VARCHAR(s) UNIQUE (c1ientNo,propertyNo)
NOTNULL, NOTNULL,
6.2.4 Integridad referencial Una clave externa es una columna o conjunto de columnas que enlazan cada fila de la tabla hijo que contiene la clave externa con la fila de la clave padre que contiene el valor correspondiente de clave candidata. La integridad referencial quiere decir que, si la clave externa contiene un valor, dicho valor debe hacer referencia a una fila existente y válida dentro de la tabla padre (véase la Sección 3.3.3). Por ejemplo, la columna de número de sucursal branchNo en la tabla PropertyForRent enlaza el inmueble con la fila de la tabla Branch a la que el inmueble está asignado. Si el número de sucursal no es nulo, debe contener un valor válido de entre los contenidos en la columna branchNo de la tabla Branch, porque de lo contrario el inmueble estaría asignado a una sucursal no válida. El estándar ISO soporta la definición de claves externas mediante las cláusula FOREIGN KEY en las instrucciones CREATE y ALTER TABLE. Por ejemplo, para definir la clave externa branchNo en la tabla PropertyForRent, incluimos la cláusula: FOREIGN KEY(branchNo) REFERENCES
Branch
SQL rechazará cualquier intento de efectuar una operación INSERT o UPDATE mediante la que se trate de crear un valor de clave externa en una tabla hijo que no tenga un valor correspondiente de clave candidata en la tabla padre. La acción que SQL toma para cualquier operación UPDATE o DELETE que intente actualizar o borrar un valor de clave candidata de la tabla padre que tenga una o más filas correspondientes en la tabla hijo depende de la acción referencial especificada mediante las subcláusulas ON UPDATE y ON DELETE de la cláusula FOREIGN KEY. Cuando el usuario trate de borrar una fila de una tabla padre y haya una o más filas correspondientes en la tabla hijo, SQL soporta cuatro opciones relativas a la acción que hay que tomar: •
CASCADE. Borra la fila de la tabla padre y borra automáticamente las filas correspondientes en la tabla hijo. Puesto que estas filas borradas pueden a su vez tener una clave candidata que esté siendo
150
Sistemas de bases de datos
utilizada como clave externa en otra tabla, se utilizarán las reglas aplicables a la clave externa de estas tablas, y así sucesivamente en cascada. •
SET NULL. Se borra la fila de la tabla padre y se asigna el valor NULL a los valores de clave externa en la tabla hijo. Esta acción sólo es válida si no se ha especificado el cualificador NOT NULL para las columnas de clave externa.
•
SET DEFAULT. Borra la fila de la tabla padre y asigna a cada componente de la clave externa de la tabla hijo el valor predeterminado especificado. Esto sólo es válido si se ha especificado un valor DEFAULT (véase la Sección 6.3.2) para las columnas de la clave externa.
•
NO ACTION. Se rechaza la operación de borrado de la tabla padre. Ésta es la opción predeterminada si no se especifica una regla ON DELETE.
SQL soporta las mismas opciones a la hora de actualizar la clave candidata en la tabla padre. Con CASCADE, los valores de clave externa en la tabla hijo se configurarán con los nuevos valores de clave candidata de la tabla padre. De la misma forma, esas actualizaciones se aplicarán en cascada si las columnas actualizadas en la tabla hijo hacen referencia a claves externas de otras tablas. Por ejemplo, en la tabla PropertyForRent, el número de empleado staffNo es una clave externa que hace referencia a la tabla Staff. Podemos especificar una regla de borrado tal que, si se borra un registro de empleado de la tabla Staff, se configuren con el valor NULL los valores en la columna staffNo correspondiente en la tabla PropertyForRent:
FOREIGN KEY
(staffNo)
REFERENCES
Staff
ON DELE TE SET NULL
De forma similar, el número de propietario ownerNo en la tabla PropertyForRent es una clave externa que hace referencia a la tabla PrivateOwner. Podemos especificar una regla de actualización tal que, si se actualiza un número de propietario en la tabla PrivateOwner, se asigna el nuevo valor a las correspondientes columnas de la tabla PropertyForRent: FOREIGN KEY
(ownerNo)
REFERENCES
PrivateOwner
ON UPDATE CASCADE
6.2.5 Restricciones generales Las actualizaciones de las tablas pueden estar restringidas por reglas de negocio que gobiernen las transacciones del mundo real representadas por dichas actualizaciones. Por ejemplo, DreamHome puede tener una regla que impida que un empleado gestione más de 100 inmuebles a un mismo tiempo. El estándar ISO permite especificar restricciones generales utilizando las cláusulas CHECK y UNIQUE de las instrucciones CREATE y ALTER TABLE Y la instrucción CREATE ASSERTION. Ya hemos hablado de las cláusulas CHECK y UNIQUE anteriormente. La instrucción CREATE ASSERTION es una restricción de integridad que no está directamente asociada a ninguna definición de tabla. El formato de la instrucción es: CREATE ASSERTION
NombreAserción
CHECK (condiciónBúsqueda) Esta instrucción es muy similar a la cláusula CHECK que hemos explicado anteriormente. Sin embargo, cuando una restricción general implica a más de una tabla, puede que sea preferible utilizar una restricción ASSERTION en lugar de duplicar la restricción en cada tabla o situar la restricción en una tabla arbitraria. Por ejemplo, para definir la restricción general que impida que un empleado gestione más de 100 inmuebles al mismo tiempo, podríamos escribir: CREATE ASSERTION StaffNotHandlingTooMuch CHECK (NOT EXISTS (SELECT staffNo FROM PropertyForRent GROUP BY staffNo HAVING COUNT(*) > 100))
Capítulo 6 SOL: definición de datos En la siguiente sección veremos cómo se utilizan estas características las instrucciones CREATE y ALTER TABLE.
151
de integridad cuando examinemos
6.3 Definición de datos El lenguaje de definición de datos (DDL, Data Definition Language) de SQL permite crear y destruir objetos de la base de datos tales como esquemas, dominios, tablas, vistas e índices. En esta sección, vamos a examinar brevemente cómo crear y destruir esquemas, tablas e índices. Veremos cómo crear y destruir vistas en la siguiente sección. El estándar ISO también permite la creación de conjuntos de caracteres, intercalaciones y traducciones. Sin embargo, no vamos a analizar dichos objetos de bases de datos en este libro. El lector interesado puede consultar Cannan y Otten (1993). Las instrucciones principales del lenguaje de definición de datos de SQL son: DROPSCHEMA
CREA TE SCHEMA CREATE DOMAIN
ALTER DOMAIN
DROPDOMAIN
CREATE TABLE
ALTER TABLE
DROPTABLE DROPVIEW
CREATE VIEW
Estas instrucciones se utilizan para crear, modificar y destruir las estructuras que forman el esquema conceptual. Aunque no están cubiertas por el están dar SQL, muchos SGBD proporcionan también las siguientes dos instrucciones adicionales: DROPINDEX
CREATE INDEX
El DBA dispone de comandos adicionales para especificar los detalles físicos relativos al almacenamiento de los datos; sin embargo, no hablaremos de ese tipo de comandos aquí, ya que son específicos de cada sistema.
6.3.1 Creación de una base de datos El proceso de creación de una base de datos difiere significativamente de unos productos a otros. En los sistemas multiusuario, la autoridad para crear una base de datos está usualmente reservada al DBA. En los sistemas monousuario, puede que se establezca una base de datos predeterminada a la hora de instalar y configurar el sistema, pudiendo el usuario crear otras cuando lo necesite. El estándar ISO no especifica cómo se crean las bases de datos, por lo que cada dialecto suele adoptar un enfoque distinto. De acuerdo con el estándar ISO, las relaciones y otros objetos de base de datos existen dentro de lo que se denomina un entorno. Entre otras cosas, cada entorno está compuesto de uno o más catálogos y cada catálogo por una serie de esquemas. Un esquema es una colección nominada de objetos de base de datos que están relacionados entre sí de alguna manera (todos los objetos de la base de datos están descritos en un esquema u otro). Los objetos de un esquema pueden ser tablas, vistas, dominios, aserciones, intercalaciones, traducciones y conjuntos de caracteres. Todos los objetos de un esquema tienen el mismo propietario y comparten una serie de valores predeterminados. El estándar deja al arbitrio de la implementación el mecanismo para crear y destruir los catálogos, pero proporciona mecanismos para crear y destruir los esquemas. La instrucción de definición de un esquema tiene el siguiente formato (simplificado): CREATE SCHEMA [Nombre
I AUTHORIZATION
Por tanto, si el creador de un esquema CREATE SCHEMA
SqlTests
SqlTests
es
Smith,
AUTHORIZATION
IdentifícadorCreador) la instrucción SQL es: Smith;
152
Sistemas de bases de datos
El estándar ISO también indica que debe ser posible especificar dentro de esta instrucción el rango de funciones disponibles para los usuarios del esquema, pero los detalles sobre cómo se especifican estos privilegios son dependientes de la implementación. Los esquemas pueden destruirse mediante la instrucción DROP SCHEMA, que tiene el siguiente formato: DROP SCHEMA Nombre [RESTRlCT
CASCADE]
I
Si se especifica la opción RESTRICT, que es la opción predeterminada cuando no se incluye ningún cualificador, el esquema deberá estar vacío, porque de lo contrario la operación fallará. Si se especifica la opción CASCADE, la operación se encadenará en cascada para eliminar todos los objetos asociados con el esquema en el orden anteriormente definido. Si alguna de estas operaciones de eliminación falla, la operación completa DROP SCHEMA fallará. El efecto total de una instrucción DROP SCHEMA con la opción CASCADE puede ser bastante significativo, por lo que esta instrucción debe utilizarse con suma precaución. Las instrucciones CREATE y DROP SCHEMA no están ampliamente implementadas todavía.
6.3.2
Creación de una tabla (CREA TE TABLE)
Habiendo creado la estructura de la base de datos, podemos ahora crear las estructuras de las tablas para formar las relaciones base que queremos incluir en la base de datos. Esto se hace por medio de la instrucción CREA TE TABLE, que tiene la siguiente sintaxis básica: CREATE TABLE NombreTabla {(NombreColumnatipoData [NOT NULL] [UNIQUE] [DEFAULT opciónPredeterminada]
[CHECK (condiciónBúsqueda)]
[, ... ])
[PRIMARY REY (IistaDeColumnas),] {[UNIQUE (listaDeColumnas)] [, ... ]} {[FOREIGN REY (IistaColumnasClaveExterna) REFEREN CES
[(listaColumnasClaveCandidatas)]
NombreTablaPadre
[MATCH {PARTIAL
I
FULL}
[ON UPDATE acciónReferencial] [ON DELETE acciónReferencial]] {[CHECK (condiciónBúsqueda)]
[, ... ]}
[, ... ]})
Como hemos explicado en la sección anterior, esta versión de la instrucción CREA TE TABLE incorpora facilidades para definir restricciones de integridad referencial y de otros tipos. Existen variaciones significativas en el soporte proporcionado por los diferentes dialectos a esta versión de la instrucción. Sin embargo, si dichas facilidades están soportadas, deben emplearse. La instrucción CREATE TABLE crea una tabla denominada NombreTablay que está compuesta de una o más columnas del tipoDato especificado. El conjunto de tipos de datos permitidos se describe en la Sección 6.1.2. La cláusula opcional DEFAULT puede especificarse para proporcionar un valor predeterminado para cada columna concreta. SQL utilizará este valor predeterminado siempre que se omita en una instrucción INSERT el valor correspondiente a una columna. Entre otros valores, la opciónPredeterminada incluye literales. Las cláusulas NOT NULL, UNIQUE Y CHECK ya han sido explicadas en la sección anterior. Las cláusulas restantes se denominan restricciones de tabla y puede precederse opcionalmente por la cláusula: CONSTRAINT NombreRestricción que permite eliminar la restricción haciendo referencia a su nombre en la instrucción ALTER TABLE (véase más abajo).
Capítulo 6
Sal:
definición de datos
153
La cláusula PRIMARY KEY especifica la columna o columnas que forman la clave principal de la tabla. Si está disponible esta cláusula, debe especificársela para todas las tablas que se creen. De manera predeterminada, se asume que está en efecto la opción NOT NULL para cada una de las columnas que forman la clave principal. Sólo se permite utilizar una única cláusula PRIMAR Y KEY por cada tabla. SQL rechazará todas las operaciones INSERT o UPDATE que intenten crear una fila duplicada en lo que se refiere al contenido de las columnas de la clave principal especificada mediante PRIMARY KEY. De esta forma, SQL garantiza la unicidad de la clave principal. La cláusula FOREIGN KEY especifica una clave externa en la tabla (hijo) y la relación que tiene con otra tabla (padre). Esta cláusula implementa las restricciones de integridad referencial. La cláusula especifica lo siguiente: •
Una listaColumnasClaveExterna, forman la clave externa.
•
Una sub cláusula REFERENCES, que indica la tabla padre; es decir, la tabla que contiene la clave candidata correspondiente. Si se omite la IistaColumnasClaveCandidatas, se dará por supuesto que la clave externa debe corresponderse con la clave principal de la tabla padre. En este caso, la tabla padre deberá tener una cláusula PRIMARY KEY en su instrucción CREATE TABLE.
•
Una regla opcional de actualización (ON UPDATE) para la relación, que especifica la acción que hay que llevar a cabo cuando se actualice una clave candidata en la tabla padre que se corresponda con una clave externa en la tabla hija. La acciónReferencial puede ser CASCADE, SET NULL, SET DEFAULT o NO ACTION. Si se omite la cláusula ON UPDATE, se toma como opción predeterminada NO ACTION (véase la Sección 6.2).
•
Una regla opcional de borrado (ON DELETE) para la relación, que especifica la acción que hay que llevar a cabo cuando se borra una fila en la tabla padre que tenga una clave candidata que se corresponda con una clave externa en la tabla hija. La acciónReferencial es igual que para la regla ON UPDATE.
•
De manera predeterminada, la restricción referencial se verá satisfecha si cualquiera de los componentes de la clave externa es nulo o si hay una fila correspondiente en la tabla padre. La opción MATCH proporciona restricciones adicionales relativas a la presencia de valores nulos dentro del plano externo. Si se especifica la opción MATCH FULL, los componentes de la clave externa deben ser todos nulos o tener todos ellos valores que no sean nulos. Si se especifica MATCH PARTIAL, los componentes de la clave externa deben ser todos nulos, o debe existir al menos una fila en la tabla padre que pudiera satisfacer la restricción si se asignaran los valores correctos a los restantes valores nulos. Algunos autores piensan que una verdadera integridad referencial debería implicar la opción MATCH FULL.
que indica la columna o columnas de la tabla que está siendo creada que
Puede haber tantas cláusulas FOREIGN KEY como se requiera. Las cláusulas CHECK y CONSTRAINT permiten definir restricciones adicionales. Si se utiliza como restricción de columna, la cláusula CHECK puede hacer referencia únicamente a la columna que esté siendo definida. Las restricciones se comprobarán en la práctica después de ejecutar cada instrucción SQL, aunque puede diferirse esta comprobación hasta que termine la transacción en la que la instrucción SQL esté incluida (véase la Sección 6.5). El Ejemplo 6.1 ilustra el potencial de esta versión de la instrucción CREATE TABLE.
I
Ejemplo 6.1 CREA TE TABLE Crear la tabla TABLE.
PropertyForRent
utilizando las características
disponibles en la instrucción CREATE
CREATE DOMAIN
OwnerNumber AS VARCHAR(5) CHECK (VALUE IN (SELECT CREATE DOMAIN StaffNumber AS VARCHAR(5)
ownerNo
FROM
PrivateOwner));
154 Sistemas de bases de datos
CREATE DOMAIN CREATE CREATE CREATE CREATE CREATE
DOMAIN DOMAIN DOMAIN DOMAIN DOMAIN
CREATE DOMAIN CREATE DOMAIN CREATE TABLE
CHECK (VALUE IN (SELECT staffNo FROM 8taff)); BranchNumber AS CHAR(4) CHECK (VALUE IN (SELECT branchNo FROM Branch)); PropertyNumber AS VARCHAR(5); 8treet AS VARCHAR(25); City AS VARCHAR(I5); PostCode AS VARCHAR(8); PropertyType AS CHAR(I) CHECK(VALUE IN ('B', 'C', 'D', 'E', 'F', 'M', 'S')); PropertyRooms AS SMALLINT; CHECK(VALUE BETWEEN 1 AND 15); PropertyRent AS DECIMAL(6,2) CHECK(VALUE BETWEEN O AND 9999.99);
PropertyForRent(
propertyNo
PropertyNumber
street
8treet
city
City
postcode
PostCode,
type
PropertyType
rooms
PropertyRooms
rent
PropertyRent
ownerNo
OwnerNumber
staffNo
8taffNumber
NOTNULL, NOTNULL, NOTNULL, NOTNULL NOTNULL NOTNULL NOTNULL,
DEFAULT 'F', DEFAULT4, DEFAULT 600,
CONSTRAINT 8taffNotHandlingTooMuch CHECK (NOT EXISTS (SELECT staffNo FROM PropertyForRent GROUP BY staffNo branchNo
BranchNumber
HAVING COUNT(*) NOTNULL,
>
100)),
PRIMARY KEY (propertyNo), FOREIGN KEY (staffNo) REFERENCES 8taff ON DELE TE SET NULL ON UPDATE CASCADE, FOREIGN KEY (ownerNo) REFERENCES PrivateOwner ON DELETE NO ACTION ON UPDATE CASCADE, Branch ON DELETE NO FOREIGN KEY (branchNo) REFERENCES ACTION ON UPDATE CASCADE); Se ha asignado un valor predeterminado de 'F' (que quiere decir Flat, es decir, apartamento) a la columna type que indica el tipo de inmueble. También se ha especificado una restricción de tipo CONSTRAlNT para la columna de número de empleado con el fin de garantizar que un empleado no gestione demasiados inmuebles a la vez. Dicha restricción comprueba que el número de inmuebles gestionados actualmente por el empleado no sea superior a 100. La clave principal es el número de inmueble, propertyNo. SQL impone automáticamente la unicidad dentro de esta columna. El número de empleado, staffNo, es una clave externa que hace referencia a la tabla 8taff. Se ha especificado una regla de borrado tal que, si se borra un registro de la tabla 8taff, los valores correspondientes de la columna staffNo en la tabla PropertyForRent se configuren con el valor NULL. Adicionalmente, se ha especificado una regla de actualización tal que, si se actualiza un número de empleado en la tabla 8taff, los valores correspondientes en la columna staffNo de la tabla PropertyForRent se actualicen correspondientemente. El número de propietario, ownerNo, es una clave externa que hace referencia a la tabla PrivateOwner. Se ha especificado una regla de borrado NO ACTION para impedir borrados en la ta-
Capítulo 6 SOL: definición de datos
155
bla PrivateOwner si existen valores correspondientes de ownerNo en la tabla PropertyForRent. Se ha especificado una regla de actualización de tipo CASCADE tal que, si se actualiza el número de un propietario, los valores correspondientes de la columna ownerNo de la tabla PropertyForRent se configuren con el nuevo valor. Las mismas reglas se han especificado para la columna branchNo. En todas las restricciones de tipo FOREIGN KEY, SQL asume (ya que se ha omitido la listaColumnasClaveCandidata) que las claves externas se corresponden con las claves principales de las respectivas tablas padre. Observe que no hemos especificado la opción NOT NULL para la columna de número de empleado staffNo, porque puede que haya periodos de tiempo en los que no haya ningún empleado asignado para gestionar el inmueble (por ejemplo, en el momento de introducir el inmueble por primera vez en el sistema). Sin embargo, las otras columnas de clave externa -ownerNo (el número de propietario) y branchNo (el número de sucursal)- deben estar siempre especificadas.
~
6.3.3 Modificación de la definición de una tabla (ALTER T ABLE) El estándar ISO proporciona una instrucción ALTER TABLE para cambiar la estructura de una tabla después de haberla creado. La definición de la instrucción ALTER TABLE en el estándar ISO está compuesta de seis opciones que permiten: •
añadir una nueva columna a una tabla;
•
eliminar una columna de una tabla;
•
añadir una nueva restricción a una tabla;
•
eliminar una restricción de tabla;
•
asignar un valor predeterminado
a una columna;
•
eliminar el valor predeterminado
de una columna.
El formato básico de esta instrucción es:
ALTER TABLE NombreTabla [ADD [COLUMN] nombreColumna tipoDato [NOT NULL] [UNIQUE] [DEFAULT opciónPredeterminada]
[CHECK (condiciónBúsqueda)]]
[DROP [COLUMN] columnName [RESTRICT [ADD [CONSTRAINT [DROP CONSTRAINT
I
CASCADE))
[NombreRestricción]] definiciónRestricciónTabla] NombreRestricción[RESTRICT
I
CASCADE]]
[ALTER [COLUMN] SET DEFAULT opciónPredeterminada] [ALTER [COLUMN] DROP DEFAULT]
Aquí, los parámetros son iguales a los definidos en la instrucción CREATE TABLE en la sección anterior. Una definiciónRestricciónTabla puede ser una de las siguientes cláusulas: PRIMARY KEY, UNIQUE, FOREIGN KEY o CHECK. La cláusula ADD COLUMN es similar a la definición de una columna en la instrucción CREATE TABLE. La cláusula DROP COLUMN especifica el nombre de la columna que hay que eliminar de la definición de la tabla y tiene un cualificador opcional que especifica si la acción de eliminación debe propagarse en cascada o no: •
RESTRICT. La operación DROP se rechaza si la columna está siendo referenciada por otro objeto de la base de datos (por ejemplo, por una definición de vista). Esta es la opción predeterminada.
156 Sistemas de bases de datos •
I
CASCADE. La operación DROP continuará, portándose automáticamente la columna de cualesquiera objetos de la base de datos que estén haciendo referencia a ella. Esta operación se propaga en cascada, por lo que si se elimina una columna de uno de los objetos que está haciendo referencia a la columna original, SQL comprobará si esa columna está siendo referenciada por cualquier otro objeto y eliminará esa columna de ese otro objeto, etc.
Ejemplo 6.2 ALTER TABLE (a) Cambiar la tabla Staff eliminando el valor predeterminado 'Assistant' para la columna asignando como valor predeterminado para la columna sex el sexo femenino ('F).
position
y
ALTER TABLE Staff ALTER position DROP DEFAULT; ALTER TABLE Staff ALTER sex SET DEFAULT 'F'; (b) Cambiar la tabla PropertyForRent eliminando la restricción de que los empleados no pueden gestionar más de 100 inmuebles al mismo tiempo. Cambiar la tabla Client añadiendo una nueva columna que represente el número preferido de habitaciones. ALTER TABLE PropertyForRent DROP CONSTRAINT ALTER TABLE Client ADD
prefNoRooms
StaffNotHandlingTooMuch;
PropertyRooms;
La instrucción ALTER TABLE no está disponible en todos los dialectos de SQL. En algunos dialectos, no puede usarse la instrucción ALTER TABLE para eliminar una columna existente de una tabla. En dichos casos, si ya no hace falta una columna, puede simplemente ignorarse, pero manteniéndola en la definición de la tabla. Sin embargo, si desea eliminar la columna de la tabla, deberá: •
almacenar en algún lugar los datos de la tabla;
•
eliminar la definición de la tabla utilizando la instrucción DROP TABLE;
•
redefinir la nueva tabla utilizando la instrucción CREATE TABLE;
•
volver a cargar los datos en la nueva tabla.
Los pasos de salvaguarda y recarga de los datos suelen realizarse con programas de utilidad de propósito especial suministrados con el SGBD. Sin embargo, también puede crearse una tabla temporal y utilizar la instrucción INSERT ... SELECT para cargar los datos de la tabla anterior en la tabla temporal y luego de la tabla temporal en la nueva tabla.
6.3.4 Eliminación de una tabla (DROP TABLE) A lo largo del tiempo, la estructura de las bases de datos cambia; pueden crearse nuevas tablas y algunas otras dejarán de ser necesarias. Podemos eliminar una tabla redundante de la base de datos utilizando la instrucción DROP TABLE, que tiene el formato: DROP TABLE
NombreTabla
[RESTRICT
Por ejemplo, para eliminar la tabla
I CASCADE]
PropertyForRent,
utilizaríamos el comando:
Capítulo 6 SOL: definición de datos DROP TABLE
157
PropertyForRent;
Observe, sin embargo, que este comando no sólo elimina la tabla designada, sino también todas las filas en ella contenidas. Para eliminar simplemente las filas de la tabla pero retener la estructura de la tabla, hay que utilizar en su lugar la instrucción DELETE (véase la Sección 5.3.10). La instrucción DROP TABLE permite especificar si la acción DROP debe propagarse en cascada o no: •
RESTRICT. La operación DROP se rechaza si hay otros objetos cuya existencia depende de que continúe existiendo la tabla que se pretende eliminar .
•
CASCADE. La operación DROP se lleva a cabo y SQL elimina automáticamente todos los objetos dependientes (y también los objetos que dependan de esos otros objetos). El efecto total de una instrucción DROP TABLE con la opción CASCADE puede ser muy significativo, por lo que esta instrucción debe utilizarse con suma precaución. Uno de los usos más comunes de DROP TABLE es para corregir los errores cometidos a la hora de crear una tabla. Si se crea una tabla con una estructura incorrecta, puede utilizarse DROP TABLE para borrar la tabla recién creada y comenzar de nuevo.
6.3.5 Creación de un índice (CREATE INDEX) Un índice es una estructura que permite acelerar el acceso a las filas de una tabla, basándose en los valores de una o más columnas (véase el Apéndice C una explicación de los índices y de cómo puede utilizárselos para mejorar la eficiencia de extracción de los datos). La presencia de un índice puede mejorar significativamente la velocidad de una consulta. Sin embargo, puesto que los índices pueden ser actualizados por el sistema cada vez que se actualizan las tablas subyacentes, eso impone al sistema una carga de trabajo adicional. Los índices se crean normalmente para satisfacer criterios de búsqueda concretos después de que la tabla haya estado en uso durante un cierto tiempo y su tamaño haya aumentado. La creación de índices no es parte del estándar SQL. Sin embargo, la mayoría de los dialectos soportan al menos las siguientes capacidades: CREATE ON
[UNIQUE] INDEX
NombreTabla
Nombrelndice
[ASC I DESe]
(NombreColumna
[, ... ])
Las columnas especificadas constituyen la clave del índice y deben enumerarse comenzando por la parte principal de la clave y continuando con las partes menos significativas. Los índices sólo pueden crearse sobre tablas base, y no sobre vistas. Si se utiliza la cláusula UNIQUE, el SGBD impondrá la unicidad de la columna combinación de columnas utilizadas para la indexación. Evidentemente, esto es obligatorio para la clave principal y posiblemente también para otras columnas (por ejemplo, para las claves alternativas). Aunque pueden crearse índices en cualquier momento, puede presentarse un problema si se intenta crear un índice unívoco sobre una tabla que ya tenga registros incorporados, porque puede que los valores almacenados en las columnas utilizadas como índice ya contengan duplicados. Por tanto, resulta conveniente crear los índices unívocos, al menos para las columnas de clave principal, cuando se crea la tabla base y el SGBD no impone automáticamente la unicidad de clave principal. Para las tablas Staff y PropertyForRent, puede resultar conveniente crear al menos los siguientes índices: CREATE UNIQUE INDEX CREATE UNIQUE INDEX
StaffNolnd
ON
PropertyNolnd
Staff (staffNo);
ON
PropertyForRent
(propertyNo);
Para cada columna, podemos especificar si el orden debe ser ascendente (ASe) o descendente (DESe). Siendo ASC la opción predeterminada. Por ejemplo, si creamos un índice sobre la tabla PropertyForRent mediante la instrucción: CREATE INDEX
Rentlnd
ON
PropertyForRent
(city, rent);
entonces se creará un índice denominado Rentlnd. Las entradas del índice estarán en orden alfabético según el contenido de la columna city y, dentro de cada valor de city, por orden de los valores de la columna rent.
158
Sistemas de bases de datos
6.3.6 Eliminación de un índice (DROP INDEX) Si creamos un índice para una tabla base y posteriormente decidimos que ya no es necesario, podemos utilizar la instrucción DROP INDEX para eliminar el índice de la base de datos. DROP INDEX tiene el formato: DROP INDEX
Nombreíndice
La siguiente instrucción permitirá eliminar el índice creado en el ejemplo anterior: DROP INDEX
Rentlnd;
6.4 Vistas Recuerde de la Sección 3.4 cuál era la definición de una vista: Vista
El resultado dinámico de una o más operaciones relacionales que operan sobre las relaciones base para producir otra relación. Una vista es una relación virtual que no tiene por qué existir necesariamente en la base de datos, sino que puede producirse cuando se solicite por parte de un usuario concreto, generándosela en el momento de la solicitud.
Para el usuario de base de datos, las vistas semejan una tabla real, con un conjunto de columnas nominadas y una serie de filas de datos. Sin embargo, a diferencia de una tabla base, las vistas no tienen por qué existir necesariamente en la base de datos en forma de conjuntos de valores de datos almacenados. En lugar de ello, las vistas se definen como una consulta sobre una o más tablas base o vistas. El SGBD almacena la definición de la vista en la base de datos. Cuando el SGBD encuentra una referencia a una vista, una de las técnicas consiste en buscar la definición de la vista y traducir la solicitud en otra solicitud equivalente sobre las tablas base de la vista, ejecutando a continuación la solicitud equivalente. Este proceso de ejecución, denominado solución de vista, se explica en la Sección 6.4.3. Otra técnica alternativa, denominada materialización de vistas, almacena la vista en forma de tabla temporal en la base de datos y mantiene la coherencia de la vista a medida que se actualizan las tablas bases subyacentes. Hablaremos de la materialización de vistas en la Sección 6.4.8, pero primero examinemos cómo crear y utilizar las vistas.
6.4.1 Creación de una vista (CREATE VIEW) El formato de una instrucción CREATE VIEW es:
CREATE VIEW
NombreVista
[(nuevoNombreColumna
L ... ])]
AS subselección [WITR [CASCADED I LOCAL] CHECK OPTlON] Las vistas se definen especificando una instrucción SELECT de SQL. Puede asignarse opcionalmente un nombre a cada columna de la vista. Si se especifica una vista de nombres de columna, debe tener el mismo número de elementos que el número de columnas generadas por la subselección. Si se omite la lista de nombres de columnas, cada una de las columnas de la vista tomará el nombre de la columna correspondiente en la instrucción de subselección. La lista de nombres de columnas debe especificarse obligatoriamente si existe cualquier ambiguedad referida al nombre de una columna. Esto puede ocurrir, por ejemplo, si la subselección incluye columnas calculadas y no se ha usado la subcláusula AS para asignar un nombre a dichas columnas, o si la subselección genera dos columnas con nombres idénticos como resultado de la combinación de dos tablas. La subselección se denomina consulta de definición. Si se especifica la opción WITH CHECK OPTlON, SQL garantiza que si una fila no satisface la cláusula WHERE de la consulta de definición de la vista, no será añadida a la tabla base subyacente de la vista (véase la Sección 6.4.6). Tenga en cuenta que para crear ade-
Capítulo 6 SOL:definición de datos
159
cuadamente una vista, es necesario disponer del privilegio SELECT sobre todas las tablas a las que se haga referencia en la subselección y el privilegio USAGE sobre todos los dominios utilizados en las columnas a las que se haga referencia. Hablaremos más en detalle de estos privilegios en la Sección 6.6. Aunque todas las vistas se crean de la misma forma, en la práctica se suelen utilizar diferentes tipos de vista para diferentes propósitos. Vamos a ilustrar los diferentes tipos de vistas existentes con una serie de ejemplos.
I
Ejemplo 6.3 Creación de una vista horizontal Crear una vista de modo que el gerente de la sucursal B003 sólo pueda ver los detalles referidos a los empleados que trabajen en su sucursal. Las vistas horizontales restringen el acceso de un usuario a una serie de filas seleccionadas más tablas:
de una o
CREATE VIEW Manager3Staff AS SELECT * FROM Staff WHERE branchNo = 'B003'; Esta instrucción crea una vista denominada Manager3Staff con los mismos nombres de columna que la tabla Staff, pero que sólo contiene aquellas filas para las que el número de sucursal es B003. (Estrictamente hablando, la columna branchNo es innecesaria y podría haber sido omitida de la definición de la vista, ya que todos las filas de la tabla tienen branchNo = 'B003 '). Si ahora ejecutamos la instrucción:
SELECT
*
FROM
Manager3Staff;
obtendremos la tabla de resultados que se muestra en la Tabla 6.3. Para garantizar que el gerente de la sucursal sólo pueda ver esas filas, debe prohibirse el acceso del gerente a la tabla base Staff. En lugar de ello, deberá asignarse al gerente permiso de acceso a la vista Manager3Staff. Esto, en la práctica, proporciona al gerente de la sucursal una vista personalizada de la tabla Staff, en la que sólo se muestra el personal que trabaja en su sucursal. Hablaremos acerca de los permisos de acceso en la Sección 6.6. Tabla 6.3. Datos correspondientes a la vista
Manager3Staff.
staffNo DOS 24-Mar-58 B003 Susan 18000.00 10-Nov-60 Assistant Beech 12000.00 Brand David Ford M 3-Jun-40 Ann B003 F 24000.00 fName IName sex branchNo Supervisor position Manager salary
I
Ejemplo 6.4 Creación de una vista vertical Crear una vista de los detalles de los empleados de la sucursal B003 que excluya la información salarial, de modo que sólo los gerentes puedan acceder a los detalles salariales de los empleados que trabajen en su sucursal. Las vistas verticales restringen el acceso de un usuario a una serie de columnas seleccionadas de una o más tablas.
160 Sistemas de bases de datos CREATE VIEW Staff3 AS SELECT staffNo,fName, IName,position,sex FROM Staff WHERE branehNo = 'B003'; Observe que podríamos reescribir esta instrucción para que utilizara la vista Manager3Staffen lugar de la tabla Staff, de la forma siguiente: CREATE VIEW Staff3 AS SELECT staffNo,fName, IName,position,sex FROM Manager3Staff; De cualquiera de las dos formas, esto crea una vista denominada Staff3 con las mismas columnas que la tabla Staff,excepto las columnas salary, DOS y branehNo. Si obtenemos un listado a partir de esta vista, obtendremos la tabla de resultados que se muestra en la Tabla 6.4. Para garantizar que sólo el gerente de la sucursal pueda ver los detalles salariales, deberá prohibirse el acceso de los empleados de la sucursal B003 a la tabla base Staffy a la vista Manager3Staff.En lugar de ello, deberá darse a esos empleados permiso de acceso a la vista Staff3, lo que en la práctica equivale a negarles el acceso a los datos salariales confidenciales. Las vistas verticales se utilizan comúnmente siempre que los datos almacenados en una tabla sean utilizados por diversos usuarios o grupos de usuarios. Este tipo de vistas proporciona una tabla privada para dichos usuarios, tabla que estará compuesta únicamente de las columnas que esos usuarios necesiten. Tabla 6.4. Datos correspondientes staffNo
I
Ejemplo
6.5
Vistas
agrupadas
a la vista Staff3.
Ford Beech Susan David F IName fName Brand Assistant Ann M sex Supervisor position Manager
y combinadas
Crear una vista de los empleados que gestionan inmuebles para alquilar, en la que se incluya el número de la sucursal en la que trabaja el empleado, el número de empleado y el número de inmuebles que gestiona (véase el Ejemplo 5.27). CREATE VIEW StaffPropCnt(branehNo, staffNo,ent) AS SELECT s.branehNo, s.staffNo,COUNT(*) FROM Staffs, PropertyForRent p WHERE sstaffNo = p.staffNo GROUP BY s.branehNo, s.staffNo; Esto nos proporciona los datos mostrados en la Tabla 6.5. Este ejemplo ilustra el uso de una subselección que contiene una cláusula GROUP BY (lo que proporciona una vista denominada vista agrupada) y que contiene múltiples tablas (lo que proporciona una vista denominada vista combinada). Una de las razones más frecuentes para utilizar vistas es la de simplificar las consultas multitabla. Una vez definida una vista combinada, podemos a menudo utilizar una simple consulta monotabla sobre la vista, en lugar de consultas que requerirían combinaciones multitabla. Observe que es preciso dar nom-
Capítulo 6 SOL: definición de datos
161
bre a las columnas en la definición de la vista, debido a la utilización de la función de agregación COUNT no cualificada en la subselección. Tabla 6.5.
Datos para la vista StaffPropCnt.
branehNo
ent 1SA9 SGl4 SL41 2staffNo SG37
BOOS B003 B007 B003
6.4.2 Eliminación de una vista (DROP VIEW) Las vistas se eliminan de la base de datos mediante la instrucción DROP VIEW: DROP VIEW NombreVista[RESTRICT
I CASCADE]
DROP VIEW hace que se elimine de la base de datos la definición de la vista. Por ejemplo, podemos eliminar la vista Manager3Staffutilizando la instrucción: DROP VIEW Manager3Staff; Si se especifica la opción CASCADE, DROP VIEW borrará todos los objetos dependientes relacionados, es decir, todos los objetos que hagan referencia a la vista. Esto significa que DROP VIEW también borra cualesquiera vistas que hayan sido definidas basándose en la vista que está siendo eliminada. Si se especifica la opción RESTRICT y hay algún objeto cuya existencia dependa de que continúe existiendo la vista que se pretende eliminar, el comando no se ejecutará. La opción predeterminada es RESTRICT.
6.4.3 Resolución de vistas Una vez analizado cómo se crean y utilizan las vistas, vamos a examinar más en detalle cómo se gestionan las consultas sobre una vista. Para ilustrar el proceso de resolución de vistas, considere la siguiente consulta, que cuenta el número de inmueble s gestionados por cada empleado de la sucursal B003. Esta consulta está basada en la vista StaffPropCntdel Ejemplo 6.5: SELECT staffNo,ent FROM StaffPropCnt WHERE branehNo = 'B003' ORDER BY staffNo; El proceso de resolución de la vista combina la consulta anterior con la consulta que define la vista StaffPropCnt,de la forma siguiente: (1) Los nombres de columna de la vista contenidos en la lista SELECT se traducen a sus correspondientes nombres de columna en la consulta de definición. Esto nos da: SELECT s.staffNoAS staffNo,COUNT(*) AS ent (2) Los nombres de vista en la cláusula FROM se sustituyen por las correspondientes consulta de definición: FROM Staffs, PropertyForRent p
listas FROM de la
162 Sistemas de bases de datos (3) La cláusula WHERE de la consulta del usuario se combina con la cláusula WHERE de la consulta de definición utilizando el operador lógico AND, con lo que nos queda: WHERE
sstaffNo
= p.staffNo
AND
branehNo = 'B003'
(4) Las cláusulas GROUP BY y HAVING se copian de la columna de definición. En este ejemplo, sólo tenemos una cláusula GROUP BY: GROUP BY
s.branehNo,
s.staffNo
(5) Finalmente, la cláusula ORDER BY se copia de la consulta del usuario traduciendo el nombre de columna de la vista a su correspondiente nombre de columna de la consulta de definición: ORDER BY
s.staffNo
(6) La consulta final combinada será: SELECT s.staffNo AS staffNo, COUNT(*) AS ent FROM Staff s, PropertyForRent p WHERE s.staffNo = p.staffNo AND branehNo = 'B003' GROUP BY s.branehNo, s.staffNo ORDER BY s.staffNo; Estos nos da la tabla de resultados mostrada en la Tabla 6.6. Tabla 6.6.
Tabla de resultados después de la resolución de la vista. staffNo
2ent 1
SG37 SG14
6.4.4 Restricciones de las vistas El estándar ISO impone diversas restricciones importantes a la creación y utilización de vistas, aunque existe una variación considerable entre unos dialectos y otros . •
Si una columna de la vista está basada en una función de agregación, dicha columna sólo puede aparecer en las cláusulas SELECT y ORDER BY de las consultas que accedan a la vista. En particular, dicha columna no podrá ser utilizada en una cláusula WHERE y no puede emplearse como argumento para una función de agregación en ninguna consulta basada en la vista. Por ejemplo, considere la vista StaffPropCnt del Ejemplo 6.5, que tiene una columna ent basada en la función de agregación COUNT. La siguiente consulta no sería legal: SELECT COUNT( FROM StaffPropCnt;
ent)
porque estaríamos utilizando una función de agregación sobre la columna ent, que está a su vez basada en otra función de agregación. De forma similar, la siguiente consulta también fallaría: SELECT * FROM StaffPropCnt WHERE ent > 2; porque estamos utilizando la columna cláusula WHERE . •
ent
de la vista, derivada de una función de agregación, en una
Una vista agrupada nunca puede combinarse con una tabla base o con otra vista. Por ejemplo, la vista StaffPropCnt es una vista agrupada, por lo que cualquier intento de combinar esta vista con otra tabla o vista fallará.
Capítulo 6 SOL: definición de datos
163
6.4.5 Actualización de vistas Todas las actualizaciones efectuadas en una tabla base se ven inmediatamente reflejadas en todas las vistas definidas sobre dicha tabla base. De forma similar, cabría esperar que si se actualiza una vista las tablas base reflejen los cambios realizados. Sin embargo, considere de nuevo la vista StaffPropCnt del Ejemplo 6.5. Piense en lo que sucedería si tratáramos de insertar un registro que indicara que, en la sucursal B003, el empleado S05 gestiona dos propiedades, utilizando la siguiente instrucción INSERT: INSERT INTO StaffPropCnt VALUES ('B003', 'S05', 2); Tendremos que insertar dos registros en la tabla PropertyForRent que indiquen qué inmueble s gestiona el empleado S05. Sin embargo, no sabemos qué inmuebles son; todo lo que sabemos es que este empleado gestiona dos inmuebles. En otras palabras, no conocemos los correspondientes valores de clave principal para la tabla PropertyForRent. Si cambiamos la definición de la vista y sustituimos el valor que indica el número de inmuebles por los números de inmueble reales: CREATE VIEW StaffPropList (branchNo, staffNo, AS SELECT s.branchNo, s.staffNo, p.propertyNo FROM Staff s, PropertyForRent p WHERE s.staffNo = p.staffNo;
propertyNo)
y tratamos de insertar el registro: INSERT INTO StaffPropList VALUES ('B003', 'S05', 'POI9'); entonces continuará existiendo un problema con de la tabla PropertyForRent que todas las columnas (véase el Ejemplo 6.1). Sin embargo, como la PropertyForRent excepto el número de inmueble, columnas no nulas.
esta inserción; porque hemos especificado en la definición excepto postcode y staffNo no pueden contener valores nulos vista StaffPropCnt excluye todas las columnas de la tabla no tenemos forma de proporcionar valores a las restantes
El estándar ISO especifica las vistas que deben ser actualizables en los sistemas que cumplan con el estándar. La definición proporcionada en el estándar ISO es que las vistas son actualizables si y sólo si: •
No se especifica la opción DISTINCT; es decir, no deben eliminarse las filas duplicadas de los resultados de la consulta.
•
Cada elemento de la lista SELECT de la consulta de definición es un nombre de columna (en lugar de una constante, expresión o función de agregación) y ningún nombre de columna puede aparecer más de una vez.
•
La cláusula FROM especifica sólo una tabla; es decir, la vista debe tener una única tabla de origen, para la cual el usuario debe disponer de los privilegios requeridos. Si la tabla de origen es en sí misma una vista, entonces esa vista deberá satisfacer estas condiciones. Por tanto, esto excluye cualquier vista basada en una combinación, unión (UNION), intersección (lNTERSECT) o diferencia (EXCEPT).
•
La cláusula WHERE no incluye ninguna instrucción SELECT anidada que haga referencia a la tabla contenida en la cláusula FROM.
•
No hay ninguna cláusula OROUP BY o HAVINO en la consulta de definición.
Además, ninguna de las filas que se añada a través de la vista debe violar las restricciones de integridad de la tabla base. Por ejemplo, si se añade una nueva fila a través de una vista, las columnas no incluidas en la vista se configurarán con valores nulos, pero esto no debe violar ninguna restricción de integridad de tipo NOT NULL en la tabla base. El concepto básico que sub yace a estas restricciones es el siguiente: Vista actualizable
Para que una vista sea actualizable, el SGSD debe ser capaz de localizar la fila o columna de la tabla base que correspondan a cada fila o columna de la vista.
164
Sistemas de bases de datos
6.4.6 WITH CHECK OPTION Las filas que existen en una vista deben satisfacer la condición WHERE de la consulta de definición. Si se altera una fila de modo que deje de satisfacer esta condición, dicha fila desaparecerá de la vista. De forma similar, siempre que se realice una operación de inserción o actualización en la vista que haga que una fila satisfaga la condición WHERE, aparecerán nuevas filas dentro de la vista. Las filas que se incorporan a una vista o que la abandonan se denominan filas migratorias. Generalmente, la cláusula WITH CHECK OPTION de la instrucción CREATE VIEW prohibe que una fila migre fuera de la vista. Los cualificadores opcionales LOCALlCASCADED son aplicables a jerarquías de vistas: es decir, una vista derivada de otra vista. En este caso, si se especifica WITH LOCAL CHECK OPTION, cualquier operación de inserción o actualización de filas que se realice en esta vista, y en cualquier otra vista directa o indirectamente definida sobre esta vista, no debe hacer que la fila desaparezca de la vista, a menos que la fila desaparezca también de la vista/tabla derivada subyacente. Si se especifica WITH CASCADED CHECK OPTION (opción predeterminada), ninguna operación de inserción o actualización de filas en esta vista y en cualquier vista directamente o indirectamente definida sobre esta vista, debe hacer que la fila desaparezca de la vista. Esta característica es tan útil que puede por sí misma hacer que trabajar con las vistas resulte más atractivo que hacerlo con las tablas base. Cuando una instrucción INSERT o UPDATE ejecutada sobre la vista viola la condición WHERE de la consulta de definición, la operación se rechaza. Esto impone el cumplimiento de las restricciones aplicables a la base de datos y ayuda a preservar la integridad de ésta. La opción WITH CHECK OPTION sólo puede especificarse para las vistas actualizables, tal como se las define en la sección anterior.
I
Ejemplo 6.6 WITH CHECK OPTION Considere de nuevo la vista creada en el Ejemplo 6.3: CREATE VIEW AS SELECT *
FROM
Manager3Staff
Staff
WHERE branchNo = 'B003' WITH CHECK OPTlON; con la tabla virtual mostrada en la Tabla 6.3. Si ahora intentamos actualizar el número de sucursal de una de las filas, cambiándolo de B003 o B005, por ejemplo: UPDATE Manager3Staff SET branchNo = 'B005' WHERE staffNo = 'SG37'; entonces, como se ha especificado la cláusula WITH CHECK OPTION en la definición de la vista, no se podrá llevar a cabo esta operación, ya que ahí haría que la fila migrara fuera de esta vista horizontal. De forma similar, si tratamos de insertar la siguiente fila a través de la vista: INSERT INTO Manager3Staff VALUES ('SLl5', 'Mary', 'Black', 'Assistant',
'F', DATE'1967-06-21',
8000, 'B002');
entonces, como se ha especificado WITH CHECK OPTION, se impedirá que se inserte la fila en la tabla Staff subyacente y que desaparezca inmediatamente de esta vista (ya que la sucursal B002 no forma parte de la vista). Ahora considere la situación en la que Manager3Staff se define no sobre la tabla Staff directamente, sino sobre otra vista de Staff:
Capítulo 6 SOL:definición de datos CREATE VIEW LowSalary AS SELECT * FROM Staff WHERE salary > 9000;
165
CREATE VIEW HighSalary CREATE VIEW Manager3Staff AS SELECT * AS SELECT * FROM HighSalary FROM LowSalary WHERE salary > ] 0000 WHERE branchNo = 'B003'; WITH LOCAL CHECK OPTION;
Si ahora intentamos realizar la siguiente actualización en Manager3Staff:
UPDATE Manager3Staff SET salary = 9500 WHERE staffNo = 'SG37'; entonces esta actualización fallará: aunque la actualización haría que la fila desapareciera de la vista HighSalary, la fila no desaparecería de la tabla LowSalary de la que hemos derivado HighSalary. Sin embargo, si la actualización tratara por el contrario de asignar un salario igual a 8000, la operación de actualización sí que tendría éxito, ya que la fila ya no formaría parte de LowSalary.Alternativamente, si la vista HighSalaryhubiera especificado la opción WITH CASCADED CHECK OPTION, se rechazaría la fijación de un salario igual a 9500 u 8000, ya que la fila desaparecería de HighSalary. Por tanto, para garantizar que no se produzcan anomalías como esta, cada vista debe normalmente crearse utilizando WITH CASCADED CHECK OPTION.
~
6.4.7 Ventajas y desventajas de las vistas Restringir el acceso de algunos usuarios a las vistas ofrece potenciales ventajas con respecto a permitir que los usuarios accedan directamente a las tablas base. Desafortunadamente, las vistas en SQL también tienen ciertas desventajas. En esta sección vamos a revisar brevemente las ventajas y desventajas de las vistas en SQL, tal como se resumen en la Tabla 6.7. Tabla 6.7.
Resumen de ventanas/desventajas
de las vistas en SQL.
Ventajas
Desventajas
Independencia de datos
Restricciones de actualización
Valores actualizados
Restricciones de estructura
Mayor seguridad
Rendimiento
Menor complejidad Comodidad Personalización Integridad de los datos
Ventajas En el caso de un SGBD que se ejecute sobre un PC autónomo, las vistas suelen resultar cómodas, definiéndoselas para simplificar las solicitudes dirigidas a la base de datos. Sin embargo, en un SGBD multiusuario, las vistas juegan un papel crucial a la hora de definir la estructura de la base de datos e imponer mecanismos de seguridad. Las principales ventajas de las vistas son las que a continuación se describen. Independencia
de los datos
Una vista puede presentar una imagen coherente y estática de las estructura de la base de datos, aún cuando se modifiquen las tablas de origen subyacentes (por ejemplo, si se eliminan o añaden columnas, si se modifi-
166
Sistemas de bases de datos
can relaciones, si se dividen las tablas, si se las reestructura o si se las renombra). Si se añaden o eliminan columnas de una tabla y estas columnas no son necesarias para la vista, no será necesario modificar la definición de la vista. Si se re ordena o divide una tabla existente, puede definirse una vista para que los usuarios continúen viendo la tabla anterior. En el caso de dividir una tabla, puede recrearse la tabla anterior definiendo una vista a partir de la combinación de las nuevas tablas, suponiendo que la división se realice de tal manera que la tabla original pueda ser reconstruida. Podemos garantizar que esto sea posible introduciendo la clave principal en las dos nuevas tablas. Así, si tuviéramos originalmente una tabla Client de la forma: Client (clientNo, fName, IName, telNo, prefType, maxRent)
podríamos reorganizarla en dos nuevas tablas: ClientDetails ClientReqts
(clientNo, fName, IName, telNo) (clientNo,
prefType, maxRent)
Los usuarios y las aplicaciones podrían continuar accediendo a los datos utilizando la anterior estructura de tabla, que se podría recrear definiendo una vista denominada Client y que fuera la combinación natural de ClientDetails y ClientReqts, con c1ientNo como columna de combinación: CREATE VIEW Client AS SELECT cd.clientNo, fName, IName, telNo, FROM ClientDetails cd, ClientReqts cr WHERE cd.c1ientNo = cr.clientNo;
prefType, maxRent
Valores actualizados
Los cambios efectuados en cualquiera de la tablas base de la consulta de definición se reflejan inmediatamente en la vista. Mayor seguridad
Puede asignarse a cada usuario el privilegio de acceder a la base de datos únicamente a través de un pequeño conjunto de vistas que contengan los datos que resultan apropiados para dicho usuario, restringiendo y controlando de este modo el acceso de cada usuario a la base de datos. Menor complejidad
Las vistas pueden simplificar las consultas, al extraer datos de varias tablas y colocarlos en una única tabla, transformando así las consultas multitabla en consultas monotabla. Comodidad
Las vistas pueden proporcionar una mayor comodidad a los usuarios ya que a éstos se les presenta únicamente la parte de la base de datos que necesitan ver. Esto reduce también la complejidad desde el punto de vista del usuario. Personalización
Las vistas proporcionan un método para personalizar la apariencia de la base de datos, de modo que unas mismas tablas base subyacentes puedan ser vistas por diferentes usuarios en distintas formas. Integridad de los datos
Si se utiliza la cláusula WITH CHECK OPTION de la instrucción CREA TE VIEW, SQL garantiza que nunca se añada a través de la vista a las tablas base subyacentes ninguna fila que no satisfaga la cláusula WHERE de la consulta de definición, lo que permite garantizar la integridad de la vista.
Capítulo 6 SOL: definición de datos
167
Desventajas Aunque las vistas proporcionan muchos beneficios significativos, también existen algunas desventajas en las vistas SQL. Restricciones de actualización
En la Sección 6.4.5 hemos visto que las vistas no pueden, en algunos casos, actualizarse. Restricciones de estructura
La estructura de una vista se determina en el momento de su creación. Si la consulta de definición tenía la forma SELECT * FROM ... , entonces el * hace referencia a las columnas de la tabla base que estuvieran presentes a la hora de crear la vista. Si se añaden posteriormente columnas a la tabla base, dichas columnas no aparecerán en la vista, a menos que se elimine dicha vista y se la vuelva a crear. Rendimiento
Al utilizar una vista se reduce el rendimiento en cierta medida. En algunos casos, esta reducción será despreciable, pero en otros casos puede resultar problemática. Por ejemplo, una vista definida mediante una consulta multitabla compleja puede requerir un largo tiempo de procesamiento, ya que el proceso de resolución de la vista puede combinar las tablas cada vez que se accede a la vista. La resolución de la vista requiere recursos de procesamiento adicionales. En la siguiente sección, presentaremos brevemente una técnica alternativa de mantenimiento de las vistas que trata de eliminar esta desventaja.
6.4.8 Materialización de vistas En la Sección 6.4.3 hemos analizado una de las técnicas para procesar las consultas basadas en una vista; en dicha técnica lo que se hacía era modificar la consulta para obtener otra consulta dirigida a las tablas base. Una de las desventajas de este sistema es el tiempo necesario para llevar a cabo la resolución de la vista, lo cual es particularmente grave cuando se accede a esa vista de manera frecuente. Otra técnica alternativa, denominada materialización de vistas, consiste en almacenar la vista en forma de tabla temporal dentro de la base de datos cuando se consulta la vista por vez primera. A partir de ahí, las consultas basadas en la vista materializada pueden ser mucho más rápidas que el proceso de recalcular la vista cada vez. La diferencia de velocidad puede resultar crítica en aquellas aplicaciones en las que la tasa de consultas sea alta y las vistas sean complejas, en cuyo caso no resulta práctico recalcular la vista para cada consulta. Las vistas materializadas resultan útiles en los nuevos tipos de aplicaciones, como los almacenes de datos, servidores de replicación, visualización de datos y sistemas móviles. Los procesos de comprobación de las restricciones de integridad y de optimización de las consultas también pueden beneficiarse de la utilización de vistas materializadas. Las dificultad inherente a esta técnica estriba en mantener la vista actualizada a medida que se modifican las tablas base. El proceso de actualizar una vista materializada en respuesta a los cambios sufridos por los datos subyacentes se denomina mantenimiento de la vista. El objetivo principal del mantenimiento de las vistas consiste en aplicar únicamente los cambios necesarios para mantener actualizada la vista. Como ilustración de los problemas asociados, considere la vista siguiente: CREATE VIEW StaffPropRent (staffNo) AS SELECT DlSTlNCT staffNo FROM PropertyForRent WHERE branchNo = 'B003' AND rent > 400; con los datos mostrados en la Tabla 6.8. Si quisiéramos insertar una fila en la tabla PropertyForRent con un valor rent ::; 400, no sería necesario actualizar la vista. Sin embargo, si quisiéramos insertar la fila C-PG24', ... ,550, 'C040', 'SG 19', 'B003') en la tabla PropertyForRent, la nueva fila debería también aparecer en la vista materializada. Por el contrario, si insertáramos la fila row C-PG54', ... ,450, 'C089', 'SG37', 'B003') en la tabla
168
Sistemas de bases de datos
PropertyForRent, no hace falta añadir ninguna nueva fila a la vista materializada porque ya existe una fila para SG37. Observe que, en estos tres casos, la decisión de si debe insertarse la fila en la vista materializada puede tomarse sin acceder a la tabla PropertyForRent subyacente. Tabla 6.8.
Datos para la vista StaffPropRent. staffNo SG37 SG14
Si ahora quisiéramos borrar la nueva fila ('PG24', ... , 550, 'C040', 'SG19', 'B003') de la tabla PropertyForRent, sería necesario borrar la fila también de la vista materializada. Sin embargo, si quisiéramos borrar la nueva fila ('PG54', ... , 450, 'C089', 'SG37', 'B003') de la tabla PropertyForRent, la fila correspondiente a SG37 no debería borrarse de la vista materializada, debido a la existencia de la fila base subyacente correspondiente al inmueble SG21. En estos dos casos, la decisión de si se debe borrarse o retenerse la fila en la vista materializada requiere acceso a la tabla base subyacente PropertyForRent. En lector interesado puede encontrar un análisis más completo de las vistas materializadas en Gupta y Mumick (1999).
6.5 Transacciones El estándar ISO define un modelo de transacciones basado en dos instrucciones SQL: COMMIT y ROLLBACK. La mayoría de las implementaciones comerciales de SQL, aunque no todas, se adaptan a este mode~ lo, que está basado en el SGBD DB2 de IBM. Una transacción es una unidad lógica de trabajo compuesta por una o más instrucciones SQL, garantizándose que esa unidad lógica sea atómica con respecto a la recuperación. El están dar especifica que cada transacción SQL comienza automáticamente con una instrucción SQL iniciadora de transacción ejecutada por un usuario o programa (por ejemplo, SELECT, INSERT, UPDATE). Los cambios realizados por una transacción no son visibles para otras transacciones que se estén ejecutando concurrentemente hasta que la transacción se complete. Toda transacción puede completarse en una de cuatro formas distintas: •
Una instrucción COMMIT hace que la transacción termine con éxito, con lo que los cambios realizados en la base de datos serán permanentes. Después de COMMIT, se iniciará una nueva transacción cuando se ejecute otra instrucción iniciadora de transacciones.
•
Una instrucción ROLLBACK aborta la transacción, deshaciendo cualesquiera cambios que ésta hubiera efectuado. Después de ROLLBACK, dará comienzo una nueva transacción en el momento en que se ejecute la siguiente instrucción iniciadora de transacciones.
•
Para el SQL programático (véase el Apéndice E), la terminación satisfactoria de un programa hace que termine con éxito la transacción final, aún cuando no se haya ejecutando una instrucción COMMIT.
•
Para el SQL programático, una terminación anormal del programa hará que se aborte la transacción.
Las transacciones SQL no pueden anidarse (véase la Sección 20.4). La instrucción SET TRANSACTION permite al usuario configurar ciertos aspectos de la transacción. El formato básico de esta instrucción es: SET TRANSACTION [READ ONLY I READ WRITE] I [ISOLATION LEVEL READ UNCOMMITTED REPEATABLE READ
I
I
READ COMMITTED
I
SERIALIZABLE]
Los cualificadores READ ONLY Y READ WRITE indican si la transacción es de sólo lectura o implica operaciones tanto de lectura como de escritura. La opción predeterminada es READ WRITE y tendrá siem-
Capítulo 6 SOL: definición de datos
169
pre efecto cuando no se especifique ninguno de los cualificadores (a menos que el nivel de aislamiento sea READ UNCOMMITTED). Puede resultar un poco confuso que READ ONLY permite que las transacciones ejecuten instrucciones INSERT, UPDATE y DELE TE en tablas temporales (pero sólo en tablas temporales). El nivel de aislamiento (ISOLATION LEVEL) indica el grado de interacción permitido por parte de otras transacciones durante la ejecución de la presente transacción. La Tabla 6.9 muestra las violaciones de serializabilidad permitidas por cada nivel de aislamiento con respecto a los siguientes tres fenómenos prevenibles: •
Lectura sucia. Una transacción lee datos que han sido escritos por otra transacción para la cual no se ha ejecutado aún la instrucción de confirmación (COMMIT).
•
Lectura no repetible. Una transacción vuelve a leer una serie de datos que ha leído anteriormente, pero otra transacción ya confirmada ha modificado o borrado los datos durante el periodo comprendido entre las dos lecturas.
•
Lecturafantasma. Una transacción ejecutan una lectura que extrae una serie de filas que satisfacen una cierta condición de búsqueda. Cuando la transacción vuelve a ejecutar la consulta en un instante posterior, se devuelven filas adicionales que han sido insertadas por otra transacción confirmada durante el periodo comprendido entre ambas lecturas. Sólo resulta seguro el nivel de aislamiento SERIALIZABLE, es decir, sólo ese nivel de aislamiento genera sucesos serializables. Los restantes niveles de aislamiento requieren que el SGBD proporcione un mecanismo que el programador pueda utilizar para garantizar la serializabilidad. En el Capítulo 20 se proporciona información adicional sobre las transacciones y la serializabilidad. Tabla 6.9. Violaciones de la serializabilidad permitidas por los distintos niveles de aislamiento.
Nivel de aislamiento
Lectura sucia
Lectura no repetible
Lectura fantasma
READ UNCOMMITTED
S
S
S
READ COMMITTED
N
S
S
REPEATABLE READ
N
N
S
SERIALIZABLE
N
N
N
6.5.1 Restricciones de integridad inmediatas e inferidas En algunas situaciones, no nos conviene que las restricciones de integridad se comprueben de manera inmediata, es decir, después de ejecutar cada instrucción SQL, sino simplemente en el momento de confirmar la transacción. La restricciones pueden definirse con las opciones INITIALLY IMMEDIATE o INITIALLY DEFERRED, que indican qué modo debe asumir la restricción al principio de cada transacción. En el primero de los casos, también resulta posible especificar si puede modificarse el modo posteriormente mediante el cualificador [NOT] DEFERRABLE. El modo predeterminado es INITIALLY IMMEDIATE. Se utiliza la instrucción SET CONSTRAINTS para fijar el modo de las restricciones especificadas para la transacción actual. El formato de esta instrucción es:
SET CONSTRAINTS {ALL I nombreRestricción
[, ... ]} {DEFERRED IIMMEDIATE}
6.6 Control de acceso discrecional En la Sección 2.4 hemos indicado que los SGBD deben proporcionar un mecanismo para garantizar que sólo puedan acceder a la base de datos los usuarios autorizados. Los SGBD modernos proporcionan normalmente uno de los siguientes mecanismos de autorización, o los dos:
170
Sistemas de bases de datos
•
Control de acceso discrecional. Se otorgan a cada usuario los derechos de acceso (o privilegios) apropiados sobre objetos de la base de datos específicos. Normalmente, los usuarios obtienen ciertos privilegios cuando crean un objeto y pueden transferir parte de estos privilegios, o su totalidad, a otros usuarios a su discreción. Aunque este tipo de mecanismo de autorización resulta bastante flexible, un usuario no autorizado malicioso podría saltarse el mecanismo de seguridad engañando a otro usuario autorizado para que revele ciertos datos confidenciales.
•
Control de acceso obligatorio. A cada objeto de la base de datos se le asigna un cierto nivel de clasificación (por ejemplo, Alto secreto, Secreto, Confidencial o No clasificado) y a cada sujeto (por ejemplo, usuarios o programas) se le proporciona un nivel de seguridad específico. Los niveles de clasificación forman un orden estricto (Alto secreto> Secreto> Confidencial> No clasificado) y un sujeto necesita el nivel de seguridad adecuado para leer o escribir un objeto de base de datos. Este tipo de mecanismo de seguridad multinivel resulta importante para ciertas aplicaciones gubernamentales, militares y corporativas. El modelo de control de acceso obligatorio más comúnmente utilizado es Bell-LaPadula (Bell y LaPadula, 1974), del que hablaremos más en detalle en el Capítulo 19.
SQL sólo soporta el control de acceso discrecional mediante las instrucciones GRANT y REVOKE. El mecanismo está basado en los conceptos de identificadores de autorización, propiedad y privilegios, como a continuación se explica.
Identificado res de autorización
y propiedad
Un identificador de autorización es un identificador SQL normal que se utiliza para establecer la identidad de un usuario. A cada usuario de la base de datos se le asigna un identificador de autorización por parte del administrador de la base de datos (DBA). Usualmente, el identificador tiene una contraseña asociada, por razones de seguridad obvias. Toda instrucción SQL ejecutada por el SGBD se realiza por cuenta de un usuario específico. Se emplea el identificador de autorización para determinar a qué objetos de la base de datos puede hacer referencia el usuario y qué operaciones pueden llevarse a cabo sobre dichos objetos. Cada objeto que se crea en SQL tiene un propietario. El propietario está identificado por el identificador de autorización definido en la cláusula AUTHORIZATION del esquema al que el objeto pertenece (véase la Sección 6.3.1). El propietario es, inicialmente, la única persona que puede conocer la existencia del objeto y, consecuentemente, realizar operaciones sobre el mismo.
Privilegios Los privilegios son las acciones que se permite al usuario llevar a cabo sobre una determinada tabla base o vista. Los privilegios definidos por el estándar ISO son: •
SELECT - el privilegio para extraer datos de una tabla;
•
INSERT - el privilegio de insertar nuevas filas en una tabla;
•
UPDATE - el privilegio de modificar filas de datos en una tabla;
•
DELETE - el privilegio de borrar filas de datos de una tabla;
•
REFERENCES - el privilegio de hacer referencia a coh¡mnas de una tabla especificada dentro de las restricciones de integridad;
•
USAGE - el privilegio de utilizar dominios, intercalaciones, conjuntos de caracteres y traducciones. En este libro no vamos a hablar de las intercalaciones, conjuntos de caracteres ni traducciones; el lector interesado puede consultar Cannan y Otten (1993).
Los privilegios INSERT y UPDATE pueden restringirse a columnas específicas de la tabla, lo que permite que se efectúen cambios en dichas columnas, pero impidiendo la modificación de las columnas restantes. De forma similar, el privilegio REFERENCES puede estar restringido también a columnas específicas de la tabla, permitiendo hacer referencia a esas columnas en las restricciones, como por ejemplo, restricciones de comprobación y restricciones de clave externa, a la hora de crear otra tabla, pero impidiendo que se haga referencia a la restantes columnas.
Capítulo 6 SQL: definición de datos
171
Cuando un usuario crea una tabla utilizando una instrucción CREATE TABLE, automáticamente se convierte en el propietario de la tabla y se les conceden privilegios completos sobre la misma. Los restantes usuarios no tendrán inicialmente ningún privilegio sobre la tabla recién creada. Para proporcionarles acceso a la tabla, el propietario debe explícitamente concederles los privilegios necesarios utilizando la instrucción GRANT. Cuando un usuario crea una vista con la instrucción CREATE VIEW, se convierte automáticamente en el propietario de la vista, pero no recibe necesariamente privilegios completos sobre la misma. Para crear la vista, el usuario debe disponer del privilegio SELECT sobre todas las tablas que forman la lista y de-lprivilegio REFERENCES sobre las columnas especificadas en la vista. Sin embargo, el propietario de la vista obtendrá los privilegios INSERT, UPDATE y DELE TE sólo si ya dispone de esos privilegios para todas las tablas de la vista.
6.6.1 Concesión de privilegios a otros usuarios (GRANT) La instrucción GRANT se utiliza para conceder privilegios sobre objetos de la base de datos a usuarios específicos. Normalmente, la instrucción GRANT es utilizada por el propietario de una tabla para proporcionar acceso a los datos a otros usuarios. El formato de la instrucción GRANT es: GRANT
{ListaPrivilegios I ALL PRIVILEGES}
ON
NombreObjeto
TO
{ListaldentíficadoresAutorizaciónl
PUBLIC}
[WITH GRANT OPTIONj ListaPrivilegios
está compuesta por uno o más de los siguientes privilegios, separados por comas:
SELECT DELETE INSERT UPDATE REFERENCES USAGE
[(NombreColumna
[,
[(NombreColumna
[,
])] ])]
[(NombreColumna
[,
])]
Por comodidad, la instrucción GRANT permite utilizar la palabra clave ALL PRIVILEGES para conceder todos los privilegios al usuario, en lugar de tener que especificar los seis privilegios individualmente. También proporciona la palabra clave PUBLIC para poder conceder el acceso a todos los usuarios autorizados presentes y futuros, no simplemente los usuarios actualmente conocidos por el SGBD. NombreObjeto puede ser el nombre de una tabla base, de una vista, de un dominio, de un conjunto de caracteres, de una intercalación o de una traducción. La cláusula WITH GRANT OPTION permite al usuario o usuarios especificados en Listaldentificadorespasar a otros usuarios los privilegios que se les han concedido sobre el objeto especificado. Si estos usuarios pasan un privilegio a otros especificando la opción WITH GRANT OPTION, los usuarios que reciban el privilegio podrán a su vez concedérselo a otros usuarios adicionales. Si no se especifica esta palabra clave, el usuario o usuarios a los que se les hayan otorgado los privilegios no podrán pasárselos a otros usuarios. De esta forma, el propietario del objeto puede mantener un control muy estricto sobre quién tiene permiso para utilizar el objeto y qué formas de acceso están permitidas. Autorización
I
Ejemplo 6.7 Concesión de todos los privilegios Proporcionar tabla Staff.
mediante
al usuario con identificador de autorización
GRANT
Manager
privilegios
completos sobre la
172
Sistemas de bases de datos GRANT ALL PRIVILEGES ON 8taff
TO
Manager
WITH GRANT OPTION;
El usuario identificado como Manager puede ahora extraer filas de la tabla 8taff y también insertar, actualizar y borrar datos de esta tabla. Manager puede también hacer referencia a la tabla 8taff y a todas las columnas de la misma en cualquier tabla que cree posteriormente. También se especifica en el ejemplo la palabra clave WITH GRAN OPTION, de modo que
I
Ejemplo 6.8 Concesión Conceder a los usuarios de la tabla 8taff.
de privilegios
Personnel
GRANT SELECT, UPDATE ON 8taff
TO
Personnel,
Manager
y
Director
podrá pasar estos privilegios a otros usuarios. ~
específicos
mediante GRANT
los privilegios SELECTy
UPDATE sobre la columna
(salary)
Director;
Hemos omitido la palabra clave WITH GRANT OPTION, de modo que los usuarios no puedan pasar ninguno de estos privilegios a otros usuarios.
I
salary
Ejemplo 6.9 Concesión de privilegios
específicos
a PUBLlC mediante
Personnel
y
Director
GRANT
Conceder a todos los usuarios el privilegio SELECT sobre la tabla Branch. GRANT SELECT ON Branch
TO PUBLIC; La utilización de la palabra clave PUBLIC implica que todos los usuarios (ahora y en el futuro) serán capaces de extraer los datos contenidos en la tabla Branch. Observe que no tiene sentido utilizar WITH GRANT OPTION ya que todos los usuarios tienen acceso a la tabla, por lo que no existe la necesidad de pasar el privilegio a otros usuarios.
~
6.6.2 Revocación de privilegios de los usuarios (REVOKE) La instrucción REVOKE se utiliza para quitar privilegios concedidos con la instrucción GRANT. Una instrucción REVOKE puede revocar todos los privilegios concedidos previamente a un usuario, o sólo algunos de ellos. El formato de la instrucción es: REVOKE
[GRANT OPTIONFOR]
ON
NombreObjeto
FROM
{ListaldentificadorAutorización
{ListaPrivilegios I PUBLIq
I ALL
[RESTRICT
PRIVILEGES} I CASCADE]
La palabra clave ALL PRIVILEGIOS hace referencia a todos los privilegios concedidos a un usuario por el usuario que está revocándolos. La cláusula opcional GRANT OPTION FOR permite que los privilegios
Capítulo 6 SOL: definición de datos
173
Usuario A
®
REVOKE INSERT ON Staff CASCADE
x
CD GRANT INSERT
ON Staff WITH GRANT OPTION
Usuario B
®
GRANT INSERT ON Staff WITH GRANT OPTION
Usuario C
Usuario E
@
®
GRANT INSERT ON Staff
GRANT INSERT ON Staff WITH GRANT OPTION
Usuario D
Figura 6.1.
Efectos de REVOKE.
pasados mediante la opción WITH GRAN OPTION de la instrucción GRANT sean revocados de forma separada de los propios privilegios. Los cualificadores RESTRICT y CASCADE operan exactamente como en la instrucción DROP TABLE (véase la Sección 6.3.3). Puesto que se requieren privilegios para crear ciertos objetos, al revocar un privilegio puede eliminarse la autoridad que permitió crear el objeto (a dichos objetos se los denomina abandonados). La instrucción REVOKE fallará si produce como resultado un objeto abandonado, como por ejemplo una vista, a menos que se haya especificado la palabra clave CASCADE. Si se especifica CASCADE, se ejecutará una instrucción DROP apropiada para cualesquiera vistas, dominios, restricciones o aserciones abandonados. Los privilegios concedidos a este usuario por otros usuarios no se verán afectados por esta instrucción REVOKE. Por tanto, si otro usuario ha concedido a éste el privilegio que está siendo revocado, la concesión hecha por ese otro usuario seguirá permitiendo a éste el acceso a la tabla. Por ejemplo, en la Figura 6.1 el Usuario A concede al Usuario B el privilegio INSERT sobre la tabla Staff con la opción WITH GRANT OPTION (paso 1). El Usuario B pasa este privilegio al Usuario C (paso 2). Posteriormente, el Usuario C obtiene el mismo privilegio que el Usuario E (paso 3). El Usuario C pasa entonces el privilegio al Usuario D (paso 4). Cuando el Usuario A revoca el privilegio INSERT concedido al Usuario B (paso 5), el privilegio no podrá ser revocado del Usuario C, porque el Usuario C también ha recibido el privilegio del Usuario E. Si el Usuario E no hubiera concedido este privilegio al usuario C, la revocación se habría propagado en cascada al Usuario C y al Usuario D.
I
Ejemplo 6.10 Revocación
de privilegios
específicos
de PUBLlC mediante
Revocar el privilegio SELECT a todos los usuarios sobre la tabla REVOKE SELECT ON Branch
FROM PUBLIC;
Branch.
REVOKE
174
I
Sistemas de bases de datos
Ejemplo 6.11 Revocación de privilegios específicos usuario mediante REVOKE
de un cierto
Revocar todos los privilegios concedidos a Directorsobre la tabla 8taff. REVOKE ALL PRIVILEGES ON 8taff FROM Director; Esto es equivalente a REVOKE SELECT ... , ya que éste fue el único privilegio que se le había concedido a Director.
~
Resumen del capítulo • •
•
El estándar ISO proporciona ocho tipos de datos base: booleano, carácter, bit, numérico exacto, numérico aproximado, fecha y hora, intervalo y objetos de carácter/binario de gran tamaño. Las instrucciones DDL de SQL permiten definir objetos de la base de datos. Las instrucciones CREATE y DROP SCHEMA permiten crear y destruir esquemas; las instrucciones CREATE, ALTER y DROP TABLE permiten crear, modificar y destruir tablas; las instrucciones CREATE y DROP INDEX permiten crear y destruir índices. El estándar SQL de ISO proporciona una serie de cláusulas en las instrucciones CREATE y ALTER TABLE para definir restricciones de integridad que se encargan de gestionar: datos requeridos, restricciones de dominio, integridad de entidades, integridad referencial y restricciones generales. Los datos requeridos pueden especificarse utilizando NOT NULL. Las restricciones de dominio pueden especificarse utilizando la cláusula CHECK o definiendo dominios mediante la instrucción CREA TE DOMAIN. Las claves primarias deben definirse utilizando la cláusula PRIMARY KEY Y las claves alternativas se definen utilizando la combinación de NOT NULL y UNIQUE. Las claves externas deben definirse utilizando la cláusula FOREIGN KEY y las reglas de actualización y borrado mediante las subcláusulas ON UPDATE y ON DELETE. Las restricciones generales pueden definirse utilizando las cláusulas CHECK y UNIQUE. Las restricciones generales también pueden crearse mediante la instrucción CREATE ASSERTION.
•
Una vista es una tabla virtual que representa un subconjunto de columnas y/o filas y/o expresiones de columna de una o más tablas base o vistas. Las vistas se crean utilizando la instrucción CREATE VIEW, en las que se especifica la consulta de definición. Las vistas pueden no necesariamente ser una tabla físicamente almacenada, en cuyo caso se las recrea cada vez que se hace referencia a ellas.
•
Las vistas pueden emplearse para simplificar la estructura de la base de datos y hacer que las consultas sean más fáciles de escribir. También se las puede usar para proteger ciertas columnas y/o filas frente a accesos no autorizados. No todas las vistas son actualizables.
•
El proceso de resolución de vistas combina la consulta efectuada sobre una vista con la definición de la propia vista, generando una consulta sobre la tabla o tablas base subyacentes. Este proceso se realiza cada vez que el SGBD tiene que procesar una consulta referida a una vista. Otra técnica alternativa, denominada materialización de vistas, almacena las vistas como tablas temporales dentro de la base de datos la primera vez que se efectúa una consulta sobre dichas vistas. Posteriormente, las consultas basadas en la vista materializada pueden ejecutarse mucho más rápidamente de lo que se podría si se recalculara la vista cada vez que se accede a ella. Una de las desventajas de las vistas materializadas es que se hace preciso mantener actualizada la tabla temporal.
•
La instrucción COMMIT indica que se ha completado con éxito una transacción y que todos los cambios realizados en la base de datos son ya permanentes. La instrucción ROLLBACK indica que la transacción debe abortarse y que los cambios en la base de datos deben deshacerse.
Capítulo 6 SOL: definición de datos •
175
El control de acceso en SQL está modelado en tomos a los conceptos de identificadores de autorización, propiedad y privilegios. Los identificadores de autorización son asignados a los usuarios de la base de datos por el DBA y permiten identificar a cada usuario. Cada objeto que se crea en SQL tiene un propietario. El propietario puede pasar privilegios a otros usuarios utilizando la instrucción GRANT y puede revocar los privilegios que les haya pasado mediante la instrucción REVOKE. Los privilegios que pueden pasarse son USAGE, SELECT, DELE TE, INSERT, UPDATE y REFERENCES; estos últimos tres pueden restringirse a columnas especificas. El usuario puede autorizar al usuario que recibe el privilegio para que pase ese privilegio a otros, utilizándose para ello la cláusula WITH GRANT OPTION, y puede revocar este privilegio mediante la cláusula GRANT OPTION FOR.
Cuestiones de repaso 6.1.
Describa los ocho tipos de datos base de SQL.
6.2. 6.3.
Explique cuál es la funcionalidad y la importancia de la característica de mejora de la integridad. Explique cada una de las cláusulas de la instrucción CREATE TABLE.
6.4.
Explique las ventajas y desventajas de las vistas.
6.5.
Describa cómo funciona el proceso de resolución de vistas.
6.6.
¿Qué restricciones son necesarias para garantizar que una vista sea actualizable?
6.7.
¿Qué es una vista materializada y cuáles son las ventajas de mantener una vista materializada, en lugar de utilizar el proceso de resolución de vistas?
6.8.
Describa la diferencia existente entre el control de acceso discrecional y el control de acceso obligatorio. ¿Qué tipo de mecanismo de control soporta SQL?
6.9.
Describa cómo funcionan los mecanismos de control de acceso de SQL.
Ejercicios Responda a las siguientes preguntas utilizando el esquema relacional especificado en la sección de Ejercicios del Capítulo 3: 6.10.
Cree la tabla
6.11.
Ahora cree las tablas Room, Booking y SQL con las siguientes restricciones:
6.12.
(a)
type
(b)
price
Hotel
utilizando las características de mejora de la integridad de SQL. Guest
utilizando las características de mejora de la integridad de
puede tener los siguientes valores: Single, Double o Family. debe estar comprendido entre 10 euros y 100 euros. debe estar comprendido entre 1 y 100.
(c)
roomNo
(d)
dateFrom
(e)
No se puede reservar dos veces una misma habitación.
(f)
Un mismo huésped no puede tener reservas que se solapen.
y
dateTo
deben ser mayores que la fecha actual..
Cree una tabla separada con la misma estructura que la tabla Booking para almacenar los registros antiguos. Utilizando la instrucción INSERT, copie los registros de la tabla Booking a la tabla de archivo, traspasando únicamente las reservas anteriores all de enero de 2003. Borre todas las reservas anteriores al 1 de enero de 2003 de la tabla Booking.
6.13.
Cree una vista que contenga el nombre del hotel y los nombres de los huéspedes albergados en el hotel.
6.14.
Cree una vista que contenga la cuenta correspondiente
6.15.
Proporcione a los usuarios el acceso a otros usuarios.
Manager
y
Director
a cada huésped del Grovenor Hotel.
acceso completo a estas vistas, con el privilegio de pasar
176
Sistemas de bases de datos
6.16.
Proporcione usuano.
6.17.
Considere
al usuario la siguiente
Accounts acceso de tipo SELECT vista definida
sobre el esquema
a estas vistas. Ahora revoque
el acceso de ese
Hotel:
CREATE VIEW HotelBookingCount (hotel No, bookingCount) AS SELECT h.hoteINo, COUNT(*) FROM Hotel h, Room r, Booking b WHERE h.hotelNo = r.hotelNo AND r.roomNo = b.roomNo GROUP BY h.hoteINo; Para cada una de las siguientes consultas indique si la consulta es válida y, en caso de que lo sea, muestre cómo se establecería la correspondencia entre la consulta y la respectiva consulta sobre las tablas base subyacentes.
(a)
SELECT * FROM HotelBookingCount;
(b)
SELECT hotel No FROM HotelBookingCount WHERE hotel No = 'R001';
(c)
SELECT MIN(bookingCount) FROM HotelBookingCount;
(d)
SELECT COUNT(*) FROM HotelBookingCount;
(e)
SELECT hotelNo FROM HotelBookingCount WHERE bookingCount > 1000;
(f)
SELECT hotelNo FROM HotelBookingCount ORDER BY bookingCount;
Cuestiones generales 6.18.
Considere
la siguiente
tabla:
Part (partNo, contract, partCost) que representa el coste de un cierto componente negociado para cada contrato (el mismo componente puede tener precios distintos en cada contrato). Ahora considere la siguiente vista ExpensiveParts, que contiene todos los números de componente diferentes para aquellos componentes que cuestan más de 1000 euros:
CREATE VIEW ExpensiveParts (partNo) AS SELECT DISTINCT partNo FROM Part WHERE partCost > 1000; Explique cómo podría mantener esta vista como una vista materializada y bajo qué circunstancias podría mantener la vista sin necesidad de acceder a la tabla base subyacente Parto 6.19.
Suponga
que tenemos
también
Supplier (supplierNo, partNo, price)
una tabla de suministradores:
se
Capítulo 6 SOL: definición de datos
177
y una vista SupplierParts, que contiene los números de los componentes que son suministrados por al menos un suministrador: CREATE VIEW SupplierParts (partNo) AS SELECT DISTINCT partNo FROM Supplier s, Part p WHERE s.partNo = p.partNo; Explique cómo podría mantener esa vista como una vista materializada y en qué circunstancias podría mantener la vista sin tener que acceder a las tablas base subyacentes, Part y Supplier.
se
6.20.
Investigue el dialecto SQL de los SGBD que esté actualmente utilizando. Determine la compatibilidad de cada sistema con las instrucciones DDL del estándar ISO. Investigue la funcionalidad de las extensiones que cada SGBD soporte. ¿Hay alguna función no soportada?
6.21.
Cree el esquema de base de datos de alquiler de DreamHome definido en la Sección 3.2.6 e inserte las tuplas mostradas en la Figura 3.3.
6.22.
Utilizando el esquema recién creado, ejecute las consultas SQL indicadas en los ejemplos del Capítulo 5.
6.23.
Cree el esquema necesario para el esquema Hotel proporcionado en ]a sección de Ejercicios del Capítulo 3 e inserte algunas tuplas de ejemplo. Ahora ejecute las consultas SQL escritas para los Ejercicios 5.7-5.28.
CapíIufo
QSE
Objetivos del capítulo: En este capítulo aprenderá: •
Las principales características de QBE (Query-By-Example,
consulta mediante ejemplos).
•
Los tipos de consultas proporcionados por la utilidad QBE del SGBD Microsoft Office Access.
•
Cómo utilizar QBE para construir consultas con el fin de seleccionar campos y registros.
•
Cómo utilizar QBE sobre una o varias tablas.
•
Cómo realizar cálculos mediante QBE.
•
Cómo utilizar las funciones avanzadas de QBE, incluyendo las consultas paramétricas, consultas de correspondencias, consultas de no correspondencias, consultas de tabulación cruzada y consultas de autobúsqueda.
•
Cómo utilizar las consultas de acción QBE para modificar el contenido de las tablas.
En este capítulo vamos a ilustrar las principales características de la utilidad QBE (Query-By-Example, consulta mediante ejemplo) utilizando el SGBD Microsoft Office Access 2003. QBE representa una técnica visual para acceder a los datos de una base de datos utilizando plantillas de consulta (Zloof, 1977). QBE se utiliza introduciendo directamente valores de ejemplo en una plantilla de consulta para representar qué es lo que debe proporcionar el acceso a la base de datos, como por ejemplo la respuesta a una consulta. QBE fue desarrollado originalmente por IBM en la década de 1970 para ayudar a los usuarios a extraer datos de una base de datos. El éxito de QBE fue tal que los SGBD más populares, incluyendo Microsoft Office Access, proporcionan ahora esta utilidad de una manera u otra. La utilidad QBE de Office Access resulta fácil de utilizar y tiene capacidades bastante potentes. Podemos usar QBE para realizar preguntas acerca de los datos contenidos en una o más tablas y para especificar los campos que queremos que aparezcan en la respuesta. Se pueden seleccionar registros de acuerdo con criterios específicos o no específicos y realizar cálculos con los datos que la tablas contienen. También podemos emplear QBE para realizar determinadas operaciones útiles sobre las tablas, como insertar o borrar registros, modificar los valores de los campos o crear nuevos campos y tablas. En este capítulo vamos a utilizar ejemplos simples para ilustrar estas funciones. Emplearemos las tablas de ejemplo del caso de estudio de DreamHome mostradas en la Figura 3.3, caso de estudio que se describe en detalle en la Sección lOA y en el Apéndice A. Cuando se crea una consulta utilizando QBE, Microsoft Office Access construye en segundo plano la instrucción SQL equivalente. SQL es un lenguaje utilizado para la consulta, actualización y gestión de bases de datos relacionales. En los Capítulos 5 y 6 hemos presentado una panorámica completa del estándar SQL. En este capítulo, presentaremos el equivalente SQL de Microsoft Office Access junto con cada uno de los ejemplos de QBE que analicemos. Sin embargo, lo que no haremos será explicar en detalle las estructuras SQL; el lector interesado puede consultar los Capítulos 5 y 6.
180
Sistemas de bases de datos
Aunque este capítulo utiliza Microsoft Office Access para ilustrar QBE, en la Sección 8.1 presentaremos una panorámica general de las restantes funciones del SGBD Microsoft Office Access 2003. Asimismo, en los Capítulos 17 y 18, cuando presentemos la metodología de diseño físico de bases de datos que se propone en el libro, utilizaremos Microsoft Office Access como uno de los SGBD objetivo.
Estructura del capítulo En la Sección 7.1 se presenta una panorámica de los tipos de consultas QBE proporcionados por Microsoft Office Access 2003 y en la Sección 7.2 se explica cómo construir consultas de selección simples utilizando la cuadrícula QBE. En la Sección 7.3 se ilustra la utilización de consultas QBE avanzadas (como por ejemplo las consultas de matriciales y de autobúsquedas) y finalmente, en la Sección 7.4, examinaremos las consultas de acción (como por ejemplo las consultas de actualización y de creación de tablas).
7.1 Introducción a las consultas en Microsoft Office Access Cuando se crea o se abre una base de datos utilizando Microsoft Office Access, se muestra la ventana Database, que presenta los objetos existentes en la base de datos (como por ejemplo, tablas, formularios, consultas e informes). Por ejemplo, cuando abrimos la base de datos de DreamHome, podemos ver las tablas contenidas en la base de datos, como se ilustra en la Figura 7.1. Para realizar una pregunta acerca de los datos contenidos en la base de datos, tenemos que diseñar una consulta que indique a Microsoft Office Access qué datos extraer. Las consultas más comúnmente utilizadas Ventana Database
-
Create table in Design view
Objetos de bases de datos
Create table by using wizard
T ables
lillJ
Crea te table by entering data
c§l
Queries
¡;m
Forrns
11
Reports
1m}
PrivateOwner
~
Pages
1m}
PropertyForRent
1m}
Registr ation
1m}
Staff
1m}
I/iewing
l:2
Macros
4
Modules
lillJ
Client
Groups
(¡)
Figura 7.1.
favorites
Ventana Database de Microsoft Office Access, mostrando las tablas de la base de datos de DreamHome.
Capítulo 7 QBE Tabla 7.1.
181
Resumen de los tipos de consultas en Microsoft Office Access 2003.
Tipo de consulta
Descripción
Consulta de selección
Realiza una pregunta o define un conjunto de criterios acerca de los datos contenidos en una o más tablas.
Consulta de totalización (agregación)
Realiza una serie de cálculos sobre grupos de registros.
Consulta paramétrica
Muestra uno o más cuadros de diálogo predefinidos en los que el usuario puede introducir los valores de los parámetros.
Consulta de localización de correspondencias
Localiza registros duplicados en una única tabla.
Consulta de localización de no correspondencias
Localiza registros diferentes en tablas relacionadas.
Consulta matricial
Permite resumir y presentar grandes cantidades de datos en un formato compacto de hoja de cálculo.
Consulta de autobúsqueda
Rellena automáticamente ciertos valores de campo para un nuevo registro.
Consulta de acción (incluyendo consultas de borrado, adición, actualización y creación de tablas)
Realiza cambios a muchos registros en una única operación. Dichos cambios incluyen la capacidad de borrar, agregar o modificar los registros de una tabla, así como de crear una nueva tabla.
Consulta SQL (incluyendo consultas de unión, de paso, de definición de datos y subconsultas)
Se utilizan para modificar las consultas descritas anteriormente y para establecer las propiedades de formularios e informes. Deben emplearse para crear consultas específicas de SQL, como consultas de unión, consultas de definición de datos, subconsultas (véanse los Capítulos 5 y 6) y consultas de paso. Las consultas de paso envían comandos a una base de datos SQL, como por ejemplo Microsoft o Sybase SQL Server.
son las denominadas consultas de selección. Con las consultas de selección, podemos ver, analizar o modificar los datos existentes. Se pueden ver datos contenidos en una única tabla o en múltiples tablas. Cuando se ejecuta una consulta de selección, Microsoft Office Access recopila los datos extraídos en lo que se denomina un conjunto dinámico (dynaset). Un conjunto dinámico es una vista dinámica de los datos de una o más tablas, seleccionados y organizados según se especifique en la consulta. En otras palabras, un conjunto dinámico es un conjunto actualizable de registros definido mediante una tabla o una consulta y que podemos tratar como un objeto. Además de las consultas de selección, también podemos crear muchos otros tipos de consultas útiles en Microsoft Office Access. La Tabla 7.1 presenta un resumen de los tipos de consultas proporcionados por Microsoft Office Access 2003. Estas consultas se explican con mayor detalle en las siguientes secciones, con la excepción de las consultas específicas de SQL. Cuando creamos una nueva consulta, Microsoft Office Access muestra el cuadro de diálogo New Query que se ilustra en la Figura 7.2. A partir de las opciones que aparecen en el cuadro de diálogo, podemos partir de cero con un objeto en blanco y construir nosotros mismos la nueva consulta seleccionado Design View, o podemos por el contrario utilizar uno de los asistentes (Office Access Wizards) enumerados, como ayuda para la construcción de la consulta. Un asistente es una especie de experto en bases de datos que nos hace preguntas acerca de la consulta que queremos construir y luego compone ésta basándose en nuestras respuestas. Como se muestra en la Figura 7.2, podemos utilizar asistentes como ayuda para construir consultas de selección simples, consultas matricia-
182
Sistemas de bases de datos
Vista de diseño Simple Query Wizard Crosstab Query Wizard Flnd Duplicates Query Wizard Find Unmatched Query Wizard
Asistentes de consulta
Create a new query without uslng awizard.
Figura 7.2.
Cuadro de diálogo New Query en Microsoft Office Access.
les o consultas que permitan localizar duplicados o registros sin correspondencia dentro de una serie de tablas. Desafortunadamente, los asistentes de construcción de consultas tienen un uso limitado a la hora de diseñar consultas de selección más complejas u otros tipos de consultas útiles como consultas paramétricas, consultas de autobúsqueda o consultas de acción.
7.2 Diseño de consultas de selección mediante aBE Las consultas de selección son el tipo más común de consulta. Permiten extraer datos de una o más tablas y mostrar los resultados en una hoja de datos en la que se pueden actualizar los registros (con algunas restricciones). Las hojas de datos muestran los datos de la tabla o tablas dispuestos en columnas y filas, de forma similar a una hoja de cálculo. Las consultas de selección también permiten agrupar los registros y calcular sumas, números de registros, medias y otros tipos de datos de totalización. Como hemos indicado en la sección anterior, pueden crearse consultas de selección simples utilizando el asistente de consultas simples (Simple Query Wizard). Sin embargo, en esta sección vamos a ilustrar el diseño de las consultas de selección simples partiendo de cero utilizando la vista de diseño. (Design View), sin emplear ningún asistente. Después de leer esta sección, el lector interesado puede experimentar con los asistentes disponibles para determinar su grado de utilidad. Cuando comenzamos a diseñar la consulta partiendo de cero, se abre la ventana Select Query (consulta de selección) en la que se muestra un cuadro de diálogo, que en nuestro ejemplo enumera las tablas y consultas existentes en la base de datos DreamHome. A continuación, seleccionamos las tablas y/o consultas que contengan los datos que queremos añadir a nuestra consulta. La ventana Select Query es una herramienta gráfica QBE (Query-By-Example). Debido a sus características gráficas, podemos emplear un ratón para seleccionar, arrastrar o manipular objetos en la ventana con el fin de definir un ejemplo de los registros que queremos ver. Los campos y registros que queramos incluir en la consulta se especifican en la cuadrícula QBE. Cuando se diseña una consulta utilizando la cuadrícula de diseño QBE, Microsoft Office Access construye de forma transparente la instrucción SQL equivalente. Dicha instrucción SQL puede mostrarse o editarse mediante la vista SQL. A lo largo de este capítulo, mostraremos la instrucción SQL equivalente para cada una de las consultas que diseñemos utilizando la cuadrícula QBE o con la ayuda de un asistente (como veremos en las secciones posteriores del capítulo). Observe que muchas de las instrucciones SQL de Microsoft Office Access que aparecen en este capítulo no se ajustan al estándar SQL presentado en los Capítulos 5 y 6.
7.2.1 Especificación de criterios Los criterios son restricciones que imponemos a una consulta para identificar los campos y registros específicos con los que queremos trabajar. Por ejemplo, para ver únicamente el número de inmueble, la ciudad, el
Capítulo 7 QBE
183
tipo y el alquiler de todos los inmueble s de la tabla PropertyForRent, podemos construir la cuadrícula QBE que se muestra en la Figura 7.3(a). Cuando se ejecuta esta consulta de selección, los datos extraídos se muestran como una hoja de datos formada por los campos seleccionados de la tabla PropertyForRent, como se muestra en la Figura 7.3(b). En la Figura 7.3(c) se proporciona la instrucción SQL equivalente para la cuadrícula QBE mostrada en la Figura 7.3(a). Lista de campos de PropertyForRent
(a)
Freid:
Table: Sort:
propertyNo
eity
PropertyForRent
Propertl'ForRent
t}/pe PropertyForRent
rent Prllpertl'ForRent
Show:
Criteria:
or: Cuadrícula
OSE Los campos seleccionados
propertyNo,
city, type y rent se muestran como columnas
(b)
Hoja de datos
Record:
(e)
I
LiJ
SELECT PropertyForRent.propertyNo, FROM PropertyForRent;
!"Il,~l
of 7
PropertyForRent.city,
PropertyForRenUype,
PropertyForRent.rent
Figura 7.3. (a) Cuadrícula QSE para extraer los campos propertyNo, city, type y rent de la tabla PropertyForRent; (b) hoja de datos resultante; (c) instrucción SQL equivalente.
184
Sistemas de bases de datos
Observe que, en la Figura 7.3(a), mostramos la ventana Select Query completa, donde aparece la tabla objetivo, PropertyForRent, encima de la cuadrícula QBE. En algunos de los ejemplos que vamos a proporcionar a continuación, mostraremos únicamente la cuadrícula QBE, pudiendo deducirse la tabla o tablas de destino fácilmente a partir de los campos mostrados en la cuadrícula. Podemos añadir criterios adicionales a la consulta mostrada en la Figura 7.3(a) con el fin de ver únicamente los inmuebles situados en Glasgow. Para hacer esto, especificamos criterios que limiten los resultados a aquellos registros cuyo campo city contenga el valor 'Glasgow' introduciendo este valor en la celda Criteria (criterios) del campo city de la cuadrícula QBE. Podemos introducir criterios adicionales para el mismo campo o para otros distintos. Cuando se introducen expresiones en más de una celda de criterios, Microsoft Office Access las combina utilizando: •
el operador And, si las expresiones se encuentran en celdas diferentes de la misma fila, lo que significa que sólo se devolverán los registros que cumplan los criterios indicados en todas las celdas;
•
el operador Or, si las expresiones se encuentran en diferentes filas de la cuadrícula de diseño, lo que quiere decir que se devolverán los registros que cumplan algún criterio de los contenidos en las distintas celdas.
Por ejemplo, para ver los inmueble s en Glasgow cuyo alquiler esté comprendido entre 350 y 450 euros, introducimos 'Glasgow' en la celda de criterios del campo city y la expresión 'Between 350 And 450' en la celda de criterios del campo rent. La construcción de esta cuadrícula QBE se muestra en la Figura 7.4(a), mientras (a) Field: Table:
propertyNo PropertyForRent
.••'(itl' Prope.rtyforRent
50rt:
type
rent
PropertyForRent
PropertyforRent
o
Show: Criteria:
o Between 350 And 450
"Glasgow"
or:
Cuadricula
Los criterios están en la misma fila por lo que se combinan utilizando el operador And
aSE
Criterio que usa el operador And
(b)
propertyNo Hoja de datos
BEG4. PG36 PG16
Glasgow Glasgow
t
Registros que satisfacen los criterios
(e)
SELECT PropertyForRent.propertyNo,
PropertyForRent.city,
FROM PropertyForRent WHERE (((PropertyForRent.city)="Glasgow")
PropertyForRenUype,
AND ((PropertyForRent.rent)
PropertyForRent.rent
Between 350 And 450));
Figura 7.4. (a) Cuadrícula QBE de la consulta de selección que permite extraer los inmuebles de Glasgow cuyo alquiler está comprendido entre 350 y 450 euros; (b) hoja de datos resultante; (c) instrucción SQL equivalente.
Capítulo 7 QBE
185
que la Figura 7A(b) muestra la hoja de datos resultante que contiene los registros que satisfacen los criterios. La instrucción SQL equivalente a dicha cuadrícula QBE se muestra en la Figura 7A(c). Suponga que queremos ahora modificar esta consulta para ver también todos los inmueble s ubicados en Aberdeen. Introducimos 'Aberdeen' en la fila or situada bajo 'Glasgow' en el campo city. La construcción de esta cuadrícula QBE se muestra en la Figura 7.5(a) y la hoja de datos resultante que contiene los registros que satisfacen los criterios se muestra en la Figura 7.5(b). La Figura 7.5(c) indica la instrucción SQL equivalente a dicha cuadrícula QBE. Observe que, en este caso, los registros extraídos por esta consulta satisfacen los criterios que indican que 'Glasgow' debe estar contenido en el campo city Yel campo rent debe estar comprendido entre 350 y 450 O alternativamente los registros que tengan 'Aberdeen' en el campo city. Podemos utilizar caracteres comodín o el operador LlKE para especificar un valor que queramos localizar cuando sólo conozcamos parte del valor, o cuando deseemos encontrar valores que comiencen con una letra específica o que se ajusten a un determinado patrón. Por ejemplo, si queremos localizar los inmuebles de Glasgow pero no estamos seguros de cómo se escribe exactamente 'Glasgow', podemos introducir 'LIKE Glasgo' en la celda de criterios del campo city. Alternativamente, podemos emplear caracteres comodín para realizar la misma búsqueda. Por ejemplo, si no estuviéramos seguros del número de caracteres que componen 'Glasgow', podríamos introducir 'Glasg*' como criterio. El comodín (*) especifica un número desconocido de caracteres. Por el contrario, si supiéramos cuál es el número correcto de caracteres de la palabra 'Glasgow', podríamos introducir 'Glasg??'. El comodín (?) especifica un único carácter desconocido. (a) Field: Table:
propertvNo PropertvForRent
citv PropertyForRent
type PropertvForRent
Sort: Show: Critería:
,
rent PropertyForRent
~ : Betw~en 350 And 450
or: Cuadricula OSE
I Los criterios están en la misma fila, por lo que se combinan utilizando el operador Or
Los criterios están en filas diferentes, por lo que se combinan utilizando el operador And
(b)
Hoja de datos
Record:
5
~. I ~Il¡.""lof 5
Registros que satisfacen los criterios
(e)
SELECT PropertyForRent.propertyNo, PropertyForRent.city, PropertyForRent.type, PropertyForRent.rent FROM PropertyForRent WHERE (((PropertyForRent.city)="Glasgow") AND ((PropertyForRent.rent) Between 350 And 450)) OR (((Pro pertyFo rRent. city)=" Aberdee n"));
Figura 7.5.
(a) Cuadrícula QSE de la consulta de selección que permite extraer los inmuebles
de Glasgow cuyo alquiler está comprendido entre 350 y 450 euros y todos los inmuebles de Aberdeen; (b) hoja de datos resultante; (e) instrucción SQL equivalente.
186
Sistemas de bases de datos
7.2.2 Creación de consultas multitabla En una base de datos que esté correctamente normalizada, los datos relacionados pueden estar almacenados en diversas tablas. Resulta, por tanto, esencial a la hora de responder una consulta que el SGBD sea capaz de combinar los datos relacionados almacenados en diferentes tablas. Para componer los datos que necesitamos de múltiples tablas, creamos una consulta de selección multitabla con las tablas y/o consultas que contengan los datos requeridos, utilizando para ello la cuadrícula QBE. Por ejemplo, para ver el nombre y apellido de los propietarios y el número de inmueble y la ciudad de los inmuebles que poseen, podemos construir la cuadrícula QBE que se muestra en la Figura 7.6(a). Las tablas de origen para esta consulta, PrivateOwner y PropertyForRent, se muestran encima de la cuadrícula. La tabla PrivateOwner proporciona los campos fName y IName y la tabla PropertyForRent proporciona los campos propertyNoy city. Cuando se ejecuta esta consulta se muestra la hoja de datos resultante, que es la que se ilustra en la Figura 7.6(b). En la Figura 7.6(c) se proporciona la instrucción SQL equivalente a esta cuadrícula QBE. La consulta multitabla mostrada en la Figura 7.6 es un ejemplo de combinación interna (natural), de la que hemos hablando en detalle en las Secciones 4.1.3 y 5.3.7. Cuando añadimos más de una tabla o consulta a una consulta de selección, tenemos que aseguramos de que las listas de campos se combinen entre sí mediante una línea de combinación para que Microsoft Office Access sepa cómo combinar las tablas. En la Figura 7.6(a), observe que Microsoft Office Access muestra un '1' por encima de la línea de combinación para indicar cuál de las tablas está en el lado 'uno' de una relación uno a muchos y un símbolo '00' para mostrar qué tabla se encuentra en el lado 'muchos'. En nuestro ejemplo, 'un' propietario tiene 'muchos' inmuebles en alquiler. Microsoft Office Access muestra automáticamente una línea de combinación entre las tablas de la cuadrícula QBE si éstas contienen un campo común. Sin embargo, la línea de combinación sólo mostrará símbolo si se ha establecido previamente una relación entre las tablas. Describiremos cómo definir relaciones entre las tablas en el Capítulo 8. En el ejemplo mostrado en la Figura 7.6, el campo ownerNo es el campo común entre las tablas PrivateOwner y PropertyForRent. Para que la combinación funciones, los dos campos deben contener datos correspondientes en los registros relacionados. Microsoft Office Access no combinará automáticamente las tablas si los datos relacionados se encuentran en campos que tengan nombres distintos. Sin embargo, podemos identificar los campos comunes de las dos tablas combinando las tablas en la cuadrícula QBE a la hora de diseñar la consulta.
7.2.3 Cálculo de totales A menudo resulta útil preguntar cuestiones acerca de grupos de datos, como por ejemplo: •
¿Cuál es el número total de inmuebles en alquiler en cada ciudad?
•
¿Cuál es el salario medio de los empleados?
•
¿Cuántas visitas ha tenido cada inmueble en alquiler desde el comienzo de este año?
Podemos realizar cálculos sobre grupos de registros utilizando las consultas de totalización (también denominadas consultas de agregación). Microsoft Office Access proporciona varios tipos de funciones de agregación, incluyendo Sum, Avg, Min, Max y Count. Para acceder a estas funciones, hay que cambiar el tipo de consultas a Totals, lo que tiene como resultado que se visualice una fila adicional denominada Total en la cuadrícula QBE. Cuando se ejecuta una consulta de totalización, la hoja de datos resultante es una instantánea, un conjunto de registros que no es actualizable. Al igual que sucede con otras consultas, también puede resultar conveniente especificar criterios en una consulta que incluya totales. Por ejemplo, suponga que queremos ver el número total de inmuebles en alquiler que hay en cada ciudad. Esto requiere que la consulta agrupe primero los inmuebles de acuerdo con el campo city utilizando Group By y luego realice el cálculo de totalización utilizando Count para cada grupo. La construcción de la cuadrícula QBE para realizar este cálculo se muestra en la Figura 7.7(a) y la hoja de datos resultante en la Figura 7.7(b). La instrucción SQL equivalente se indica en la Figura 7.7(c).
Capítulo 7 aSE (a)
Línea de combinación que representa una relación 1:* Lista de campos de PrivateOwner
Lista de campos de PropertyForRent
~ fName IName
Field: Table: 50rt: Show:
fName
IName
PrivateOwner
PrívateOWner
propertyNo PropertyForRent
city
PropertyForRent
Critería: or:
Cuadricula OSE
Los campos seleccionados de PropertyForRent se muestran como columnas
Los campos seleccionados de PrivateOwner se muestran como columnas
(b)
cit
~G~~gl)w Aberdeen London
Hoja de
datos
~asgol/V: __ Glasgow Glasgow
Ton)'
t.
Tony
Record: I~ 1 ~
of 7
(c)
SELECT PrivateOwner.fName, PrivateOwner.IName, PropertyForRent.propertyNo, FROM PrivateOwner INNER JOIN PropertyForRent ON PrivateOwner.ownerNo
PropertyForRent.city =
PropertyForRent.ownerNo;
Figura 7.6. (a) Cuadrícula OSE de una consulta multitabla utilizada para extraer el nombre y el apellido de los propietarios y el número de inmueble y la ciudad de sus inmuebles; (b) hoja de datos resultante; (e) instrucción SOL equivalente.
187
188
Sistemas de bases de datos (a)
field: Table: Total: 50rt: 5how: Criteria:
Cuadrícula QBE
city PropertyforRent Group By
propertyNo PropertyForRent Count
or:
La agrupación (Group By) sobr, el campo city se muestra como columna
El recuento (Count) sobre el campo propertyNo se muestra como columna
(b)
Hoja de datos
(c)
SELECT PropertyForRent.city, Count(PropertyForRent.propertyNo) FROM PropertyForRent GROUP BY PropertyForRent.city; Figura 7.7.
AS
CountOfpropertyNo
(a) Cuadrícula QSE de la consulta de totalización que permite calcular el número de inmuebles en alquiler que hay en cada ciudad; (b) hoja de datos resultante; (e) instrucción SQL equivalente.
Para algunos cálculos, es necesario crear nuestra propias expresiones. Por ejemplo, suponga que queremos calcular el alquiler anual para cada inmueble de la tabla PropertyForRent, extrayendo únicamente los campos propertyNo, cíty y type. El alquiler anual se calcula multiplicando por 12 el alquiler mensual de cada inmueble. Introduciríamos 'Yearly Rent: [rent]* 12' en un nuevo campo de la cuadrícula QBE, como se muestra en la Figura 7.8(a). La parte 'Yearly Rent:' de la expresión proporciona el nombre del nuevo campo y '[rent]*12 calcula un valor de alquiler anula para cada inmueble utilizando los valores mensuales contenidos en el campo rent. La hoja de datos resultante para esta consulta de selección se muestra en la Figura 7.8(b) Y la instrucción SQL equivalente en la Figura 7.8(e)
7.3 Utilización de consultas avanzadas Microsoft Office Access proporciona diversas consultas avanzadas. En esta sección, vamos a describir algunos de los ejemplos más útiles de estos tipos de consultas, incluyendo: •
consultas paramétricas;
•
consultas matriciales;
•
consultas de localización de duplicados;
•
consultas de localización de no correspondencias.
Capítulo 7 QBE
189
Expresión para crear un nuevo campo denominado Yearly Rent y para calcular un valor para cada inmueble (a) Field: Table:
propertyNo PropertyForRent
cíty Propert~IForRent
t'rpe
Vearly Rent: [rent)*12
PropertyForRent
50rt: 5how: Crltería:
or:
Crea una nueva columna denominada Yearly Rent (b)
propertvNo P.A,14
PG16 PG21 PG36 PG4 PL94
tJf Record:
1111
(e)
SELECT PropertyForRent.propertyNo, FROM PropertyForRent;
PropertyForRent.city,
PropertyForRenUype,
[rent]*12 AS [Yearly Rent]
Figura 7.8. (a) Cuadrícula QBE de la consulta de selección que permite calcular el alquiler anual de cada inmueble; (b) hoja de datos resultante; (c) instrucción SQL equivalente,
7.3.1 Consultas paramétricas Una consulta paramétrica muestra uno o más cuadros de diálogo predefinidos que piden al usuario que introduzca los valores de los parámetros (criterios), Las consultas paramétricas se crean introduciendo una pregunta encerrada entre corchetes en la celda de criterios de cada campo que queramos utilizar como parámetro. Por ejemplo, suponga que queremos modificar la consulta de selección mostrada en la Figura 7.6(a) para preguntar primero el nombre y el apellido del propietario, antes de extraer el número de inmueble y la ciudad para cada uno de sus inmuebles. La cuadrícula QBE de esta consulta paramétrica se muestra en la Figura 7.9(a). Para extraer los detalles de las propiedades para un propietario denominado 'Carol Farrel', introduciríamos los valores apropiados en el primer y segundo cuadros de diálogo, como se muestra en la Figura 7.9(b), lo que da como resultado la visualización de la hoja de datos resultante que se muestra en la Figura 7.9(c). La Figura 7.9(d) indica la instrucción SQL equivalente.
190
Sistemas de bases de datos (a)
Field: fName IName PrívateOwner PrívateOwner 50rt: shaw; ~ I ~ Criteria: [Enter Owner's first Name) t[Eriter Owne{s Last Name) ar: Table:
para crear
Expresión
el cuadro de diálogo para el campo fName
el cuadro
Expresión
prapert'yNa
city
PrapertyFarRent
PropertyfarRent
para crear de diálogo
(b)
p"'el~mpo~
(e)
~
Re:card:I~Wf
3
af
3
Registros que satisfacen los criterios
(d)
SELECT PrivateOwner.fName, PrivateOwner.IName, PrapertyforRent.propertyNo, PropertyForRent.city FROM PrivateOwner INNER JOIN PropertyforRent ON PrivateOwner.ownerNo = PropertyforRent.ownerNo WHERE (((PrivateOwner.fName)=[Enter Owner's First NameJ) AND ((PrivateOwner.IName)=[Enter Owner's
Last Name]));
Figura 7.9. (a) Cuadrícula QBE de la consulta paramétrica de ejemplo; (b) cuadros de diálogo para el nombre y apellido del propietario; (c) hoja de datos resultante; (d) instrucción SQL equivalente.
7.3.2 Consulta matricial Una consulta matricial (crosstab) puede utilizarse para resumir una serie de datos en un formato compacto tipo hoja de cálculo. Este formato permite a los usuarios de grandes cantidades de datos de resumen identificar más fácilmente las tendencias y realizar también comparaciones. Cuando se ejecuta una consulta matricial, devuelve una instantánea. Podemos crear una consulta matricial utilizando el asistente CrossTab Query Wizard o construir la consulta partiendo de cero mediante la cuadrícula QBE. La creación de una consulta matricial es similar a la de una consulta con totales, pero es necesario especificar los campos que hay que utilizar como encabezados de fila y como encabezados de columna, así como los campos que deben suministrar los valores.
Capítulo 7 OBE
191
Por ejemplo, suponga que queremos conocer, para cada empleado, el número total de inmuebles que gestiona, según el tipo de inmueble. Para este ejemplo, hemos añadido registros adicionales de inmueble s en la tabla PropertyForRent, con el fin de ilustrar más claramente la utilidad de las consultas matriciales. Para responder una cuestión planteada, primero diseñamos una consulta de totalización, como se muestra en la Figura 7.10(a), que crea la hoja de datos mostrada en la Figura 7.1O(b). La instrucción SQL equivalente para la consulta de totalización se indica en la Figura 7.10(c). Observe que la disposición de la hoja de datos resultante hace que resulte difícil realizar comparaciones entre los empleados. (a)
Field: Table: Total: Sort: Shaw: Criteria:
fName
IName
Staff
Staff
Group By
Group By
type Propertl'ForRent Group By
propertl'No Prapert)fFarRent Group Bl'
ar:
El recuento (Count) sobre el campo propertyNo se muestra como columna
La agrupación (Group By) sobre los campos fName, IName y type se muestran como columnas
(b)
- - ---"------ --~ - David Ann ..
ary rd:
t'- 1
.'
--
-
--
-----~ ..142
Flat 714,-rz!4 af 14 I,i~e_ech Howe Flat 45 42 Mid·Terrace 33 26 'Howe Ford Semi-Detached Semi·Detached fName H43 type IColtage E?,lmgalow ICotla~~ ªLLri9§low CountOfpropertyNo .Mid· __I Tarraca ¡8eech I ~~ 1rS~mi-Detached Bungalow tª-~_Ch 1
-t
(e)
SELECT
Staff.fName, CountOfPropertyNo FROM Staff INNER
Staff.IName, PropertyForRent.type,
JOIN
PropertyForRent
ON
Count(PropertyForRent.propertyNo)
Staff.staffNo
=
PropertyForRent.staffNo
Figura 7.10. (a) Cuadrícula QBE de la consulta de totalización de ejemplo; (b) hoja de datos resultante; (c) instrucción SQL equivalente.
AS
192
Sistemas de bases de datos
Para convertir la consulta de selección en una consulta matricial, modificamos el tipo de consulta a Crosstab, 10 que resulta en la adición de la fila Crosstab en la cuadrícula QBE. Después identificamos los campos que hay que utilizar como encabezados de fila y como encabezados de columna, así como los campos que suministrarán los valores, como se muestra en la Figura 7.11(a). Cuando ejecutamos esta consulta, la hoja de datos se muestra como una disposición más compacta, como se ilustra en la Figura 7.11(b). En este formato, podemos comparar fácilmente los valores para los distintos empleados. La instrucción SQL equivalente para la consulta matricial se indica en la Figura 7.11 (c). La instrucción TRANSFORM no está soportada por el SQL estándar, sino que es una extensión de Microsoft Office Access SQL. (a)
El campo propertyNo proporciona los valores para las columnas de tipo de inmueble I Fíeld: fName Table: Staff Total: Crosstab: 50rt: Críteria:
Group By Row Headíng
IName
type
propertl'No
Staff
PropertyForRent Group B\' Column Heading
PropertyForRent Group B'l'
Group By Ro'N Heading
or:
Value
t
Los campos fName y IName proporcionan
El campo type proporciona
los valores
IO'7"O''"~7d'fil/7TdO~~ Semi·Oetached
33 42
7
2 1
7
~
(e)
TRANSFORM Count(PropertyForRent.propertyNo) SELECT Staff.fName, Staff.IName FROM Staff INNER JOIN PropertyForRent ON GROUP BY Staff.fName, Staff.IName PIVOT PropertyForRenUype;
Figura 7.11.
AS
CountOfpropertyNo
Staff.staffNo = PropertyForRent.staffNo
(a) Cuadrícula OSE de la consulta matricial de ejemplo; (b) hoja de datos resultante; (e) instrucción SOL equivalente.
7.3.3 Consultas de localización de duplicados El asistente Find Duplicates Query Wizard mostrado en la Figura 7.2 puede utilizarse para determinar si existen registros duplicados en una tabla o para determinar qué registros de una tabla comparten los mismos valores. Por ejemplo, resulta posible buscar valores duplicados en los campos fName y IName con el fin de determinar si tenemos registros duplicados para los mismos propietarios de inmuebles, o buscar valores duplicados en un campo eity para ver qué propietarios viven en la misma ciudad.
Capítulo 7 QBE
193
Suponga que hemos creado inadvertidamente un registro duplicado para el propietario denominado 'Carol Farrel' y que hemos dado a este registro un número de propietario unívoco. La base de datos contendrá entonces dos registros con diferentes números de propietario, pero que representan al mismo propietario. Podemos utilizar el asistente Find Duplicates Query Wizard para identificar los registros de propietario duplicados utilizando (por simplicidad) únicamente los valores de los campos fName y IName. Como hemos explicado anteriormente, el asistente construye simplemente la consulta basándose en nuestras respuestas. Antes de ver los resultados de la consulta, podemos fijamos en la cuadrícula QBE de la consulta de totalización de duplicados, la cual se muestra en la Figura 7.12(a). La hoja de datos resultante para la consulta de localización de duplicados se muestra en la Figura 7.l2(b), donde aparecen los dos registros que representan al mismo propietario, llamado 'Carol Farrel'. La instrucción SQL equivalente se indica en la Figura 7.12( c). Observe que esta instrucción SQL muestra de forma completa la instrucción SELECT interna que sólo puede verse parcialmente en la fila de criterios del campo fName que se muestra en la Figura 7.l2(a). La instrucción SQL SELECT se muestra completa en la parte (e) de la figura (a) Field:
fName
Table:
PrivateOwner
50rt:
telNo
PrivateOwner
Ascending
~
51100: Crlteria:
ilddres;; PrivilteOwner
In (SHEeT [fName]
an
Los campos fName y IName se utilizan
(b)
7"tifi~'"'07¡;~dO' address 6 Achray Slreet, Glasgow G32~9DX 6 Achra)' Slreet, Glasgow G32 9DX
(e)
SELECT
PrivateOwner.fName, PrivaleOwner.lelNo
PrivateOwner.IName,
PrivateOwner.ownerNo,
PrivateOwner.address,
FROM PrivateOwner WHERE (((PrivateOwner.fName) In (SELECT [fName] FROM [PrivateOwner] As Tmp GROUP BY [fName].[IName] HAVING Count(*»1 And [IName] = [PrivaleOwner].[IName]))) ORDER BY PrivateOwner.fName, PrivateOwner.IName; Figura 7.12.
(a) Cuadrícula OSE para la consulta de ejemplo de localización (b) hoja de datos resultante; (c) instrucción SOL equivalente.
de duplicados;
194
Sistemas de bases de datos
7.3.4 Consulta de localización de no correspondencias El asistente Find Unmatched Query Wizard mostrado en la Figura 7.2 puede utilizarse para localizar registros de una tabla que no tenga registros relacionados en otra tabla. Por ejemplo, podemos localizar los clientes que no hayan visitado ningún inmueble en alquiler comparando los registros de las tablas Client y Viewing. El asistente construirá la consulta basándose en nuestras respuestas. Antes de visualizar los resultados de la consulta, podemos ver la cuadrícula QBE de la consulta de localización de no correspondencias, que se muestra en la Figura 7.13(a). La hoja de datos resultante para la consulta se muestra en la Figura 7.13(b), que indica que no existe ningún registro en la tabla Viewingrelacionado con el cliente 'Mike Ritchie' de la tabla Client. Observe que la casilla Show (mostrar) del campo c1ientNoen la cuadrícula QBE no está marcada ya que este campo no es necesario en la hoja de datos. La instrucción SQL equivalente para la cuadrícula QBE se indica en la Figura 7.13(c). La consulta de localización de no correspondencias es un ejemplo de combinación externa izquierda, de la que ya hablamos en detalle en las Secciones 4.1.3 y 5.3.7. (a)
cIenlNo fName IName
telJ~o
Field:
~ 'FName
Table:
Oent
IName
telNo
clientNo
Client
CUent
lIiewíng
5ort: Show: Criteria:
or:
Criterios Casilla de visualización Los campos clientNo,fName, IName y telNo seleccionados se muestran como columnas desactivada (b)
Registro de cliente que no tiene ningún registro correspondiente en la tabla Viewing (e)
SELECT Client.clientNo,Client.fName,Client./Name,Client.telNo FROM ClientLEFT JOIN ViewingON Client.elientNo= Viewing.elientNo Is Null)); WHERE (((Viewing.clientNo) Figura 7.13.
(a) Cuadrícula OSE de la consulta de ejemplo para localización de no correspondencias; (b) hoja de datos resultante; (e) instrucción SOL equivalente.
Capítulo 7 QBE
195
7.3.5 Consultas de autobúsqueda Una consulta de autobúsqueda puede utilizarse para rellenar automáticamente ciertos valores de campo para los nuevos registros. Cuando introducimos un valor en el campo de combinación de la consulta o un formulario basado en la consulta, Microsoft Office Access busca e introduce datos existentes relacionados con dicho valor. Por ejemplo, si conocemos el valor del campo de combinación (staffNo) entre las tablas PropertyForRent y Staff, podemos introducir el número de empleado y hacer que Microsoft Office Access introduzca el resto de los datos para dicho empleado. Si no se encuentra ningún registro correspondiente, Microsoft Office Access muestra un mensaje de error. Para crear una consulta de autobúsqueda, añadimos dos tablas que tengan una relación uno a muchos y seleccionamos los campos de la consulta en la cuadrícula QBE. El campo de combinación debe seleccionarse del lado 'muchos' de la relación. Por ejemplo, en una consulta que incluya campos de las tablas PropertyForRent y Staff, arrastraremos el campo staffNo (clave externa) de la tabla PropertyForRent hasta la cuadrícula de diseño. La cuadrícula QBE de esta consulta de autobúsqueda se muestra en la Figura 7.l4(a). La Figura 7.14(b) muestra una hoja de datos basada en esta consulta que nos permite introducir el número de inmueble, la calle y la ciudad para un nuevo registro de inmueble. Cuando introduzcamos el número del empleado responsable de la gestión del inmueble, por ejemplo 'SA9', Microsoft Office Access explorará la tabla Staff y rellenará automáticamente el nombre y el apellido del empleado, que en este caso es 'Mary Howe'. La Figura 7.l4(c) muestra la instrucción SQL equivalente para la cuadrícula QBE de la consulta de autobúsqueda.
7.4 Modificación del contenido de las tablas mediante consultas de acción Cuando creamos una consulta, Microsoft Office Access crea una consulta de selección, a menos que elijamos un tipo diferente en el menú Query. Cuando ejecutamos una consulta de selección, Microsoft Office Access muestra la hoja de datos resultante. Puesto que la hoja de datos es actualizable, podemos efectuar cambios en los datos; sin embargo, es preciso hacer los cambios registro por registro. Si necesitamos hacer un gran número de cambios similares, podemos ahorrar tiempo utilizando una consulta de acción. Las consultas de acción nos permiten realizar cambios en muchos registros al mismo tiempo. Hay cuatro tipos de consultas de acción: de creación de tabla, de borrado, de actualización y de adición.
7.4.1 Consultas de acción para creación de tablas Las consultas de acción para creación de tablas crean una nueva tabla a partir de los datos contenidos en una o más tablas. La tabla recién creada puede guardarse en la base de datos actualmente abierta o puede exportarse a otra base de datos. Observe que los datos de la nueva tabla no heredan de la tabla original las propiedades de los campos, incluyendo la clave principal, que será preciso configurar manualmente. Las consultas de creación de tablas son útiles por diversas razones, incluyendo la capacidad de archivar datos históricos, de crear instantáneas de la base de datos que sirvan como informes y de mejorar la velocidad de los formularios e informes basados en consultas multitabla. Suponga que queremos crear una nueva tabla denominada StaffCut, que contenga únicamente staffNo, y salary de la tabla Staff original. Primero diseñamos una consulta para extraer los campos requeridos de la tabla Staff. Después cambiamos el tipo de consulta en la ventana Design View para seleccionar Make- Table y aparecerá un cuadro de diálogo. El cuadro de diálogo nos pedirá el nombre y la ubicación de la nueva tabla, como se muestra en la Figura 7.l5(a). La Figura 7.l5(b) muestra la cuadrícula QBE para esta consulta de acción de creación de tabla. Cuando ejecutemos la consulta, un mensaje de advertencia nos preguntará si queremos continuar con la operación de creación de tabla, como se muestra en la Figura 7.l5(c). Si confirmamos la operación, se creará la nueva tabla StaffCut, como se muestra en la Figura 7.15(d). La Figura 7.15( e) indica la instrucción SQL equivalente para esta consulta de acción de creación de tabla.
fName, IName, position
196
Sistemas de bases de datos
(a)
Campo staffNo (clave externa)
'"
le lable
PTe,ty'''R,"'
ReId: Table:
Sott: Show:
Cruna: 0(:
Los campos seleccionados
de PropertyForRent
1
(b)
Los campos seleccionados
se muestran como columnas
1
1
sr"
1
de
mO"'ffiJ wmo wlomo"
street
propertyNo PA14
16 Holhead ------,
PG16 PG36
5 Novar Orive
PG21 PL94
'2 Manor R~ad 1~ O~e Roap
ª Ar9YtL§treet
I]PG97
*
Record:
tc>~~~~~ ,~on~
,25 Muir House4t\~l3!deen
i
lil.iJ I
IAnn
Glasgovv
~
i__ i__ i 6"
'''11''*1
I SL41
:Julie
I
I
of 6
El usuario introduce los valores para el nuevo inmueble
- -t,BeeCh ,Beech
El usuario introduce el valor de staffNo 'SA9'
Les_
I Howe I
i__ i
Microsoft Office Access rellena automática mente las columnas fName y IName con los valores asociados con el número de empleado staffNo 'SA9'
(c)
SELECT
PropertyForRentpropertyNo, PropertyForRentstaffNo, StaffJName,
FROM
Staff
INNER JOIN
PropertyForRentstreet, Staff,IName
PropertyForRent
ON
PropertyForRentcity,
Staff,staffNo = PropertyForRentstaffNo;
Figura 7.14. (a) Cuadrícula QSE de la consulta de autobúsqueda de ejemplo; (b) hoja de datos basada en la consulta de autobúsqueda; (c) instrucción SQL equivalente.
Capítulo 7 QBE
197
Nombre de la nueva tabla
(a)
Ubicación de la nueva tabla
(b)
Fíeld: lstaffNo Table: Sl:aff Sort:
fNeme
lName
Staff
Staff
sitioo
salary
Sl:dff
Sl:aff
Cntet'la:
or:
)
L<
[
Show: Cuadrícula ~BE de creación de tabla
f Los campos seleccionados
de la tabla 8taff para la nueva tabla 8taffCut
(e)
You are about to paste 6 row{s) joto a new table. Orn::eyou cllck Ves, you can'!: use the Undo command to reverse the changes. Are you sure you WQntto create a new rabie with the selected records?
(d)
positíon
salar_y
Man~ger Assístant
En caso afirmativo
t
I
-
<- -
Supetvisor
I~sistant Brand Hoja de datos 8taffCut
Columnas seleccionadas
24000
Manage! Assistant
--1. Lee ~
~ 1 ~I 1,,,,, 1 of
----
_
30000 12000 18006 9000 9000
7 copiadas de la tabla 8taff
(e)
SELECT
Staff.staffNo,
Staff.fName,
Staff.IName, Staff.position,
Staff.salary
INTO
StaffCut
FROMStaff;
Figura 7.15. (a) Cuadro de diálogo Make-Table; (b) cuadrícula QBE de la consulta de ejemplo para creación de tabla; (e) mensaje de advertencia; (d) hoja de datos resultante; (e) instrucción SQL equivalente.
198
Sistemas de bases de datos
(a)
Tabla objetivo del borrado I Fíeld: PropertyForRent,* Cuadrícula
aSE para borrado
rabie: Delete: Criterla:
Propel'tyForRent From Criterio que selecciona los inmuebles
or:
de Glasgow
Youare about to delete 4 row(s) froro the specjfied table. Once you díck Ves, yeu can't use the Undo command to reverse the changes, Are you sure you want te delete the selected records?
(c)
Hoja de datos de PropertyForRent con los registros borrados (los inmuebles de Glasgow)
El borrado se propaga en cascada a la tabla relacionada si está configurada la integridad referencial y están permitidos los borrados en cascada
Hoja de datos para Viewing con los registros borrados (las visitas a los ínmuebles de Glasgow) (d)
DELETE PropertyForRent.*, PropertyForRent.city FROM PropertyForRent WHERE (((PropertyForRent.city)="Glasgow")); Figura 7.16.
(a) Cuadrícula OSE para la consulta de acción de borrado de ejemplo;
(b) mensaje de advertencia; (e) hojas de datos resultantes de PropertyForRent con los registros borrados; (d) instrucción SOL equivalente.
y Viewing,
Capítulo 7 QBE
199
7.4.2 Consulta de acción de borrado Una consulta de acción de borrado borra un grupo de registros de una o más tablas. Podemos utilizar una única consulta de borrado para borrar registros de una sola tabla, de múltiples tablas que se encuentran en una relación uno a uno o de múltiples tablas que se encuentran en una relación uno a muchos con restricciones de integridad referencial configuradas para permitir borrados en cascada. Por ejemplo, suponga que queremos borrar todos los inmuebles en alquiler de Glasgow, junto .con sus registros de visitas asociados. Para llevar a cabo este borrado, primero llevamos a cabo una consulta que extraiga los registros apropiados de la tabla PropertyForRent. Después cambiamos el tipo de consulta en la ventana Design View, seleccionando el tipo Delete. La cuadrícula QBE para esta consulta de acción de borrado se muestra en la Figúra 7.16(a). Puesto que las tablas PropertyForRent y Viewingtienen una relación uno a muchos con restricciones de integridad referencial configuradas con la opción Cascade Delete Related Records (propagar en cascada el borrado de registros relacionados), también se borrarán todos los registros de visitas asociados con los inmuebles de Glasgow. Cuando ejecutamos la consulta de acción de borrado, aparecerá un mensaje de advertencia preguntándonos si queremos continuar con la operación de borrado, como se muestra en la Figura 7.16(b). Si confirmamos la operación, se borrarán los registros seleccionados de la tabla PropertyForRenty los registros relacionados de la tabla Viewing,como se muestra en la Figura 7.16( c). La Figura 7.16( d) indica la instrucción SQL equivalente para esta consulta de acción de borrado.
7.4.3 Consulta de acción de actualización Una consulta de acción de actualización realiza cambios globales en un grupo de registros de una o más tablas. Por ejemplo, suponga que queremos incrementar el alquiler de todos los inmuebles en un 10%. Para llevar a cabo esta actualización, primero creamos una consulta sobre la tabla PropertyForRent. Después, cambiamos el tipo de consulta en la ventana Design View, seleccionando el tipo Update. Introducimos la expresión '[Rent]*1.I' en la celda Update To del campo rent, como se muestra en la Figura 7.l7(a), y cuando ejecutemos la consulta, un mensaje de advertencia nos preguntará si queremos continuar con la actualización, como se muestra en la Figura 7.17(b). Si decidimos confirmar la operación, se actualizará el campo rent de la tabla PropertyForRent, como se muestra en la Figura 7.17(c). La Figura 7.17(d) muestra la instrucción SQL equivalente para esta consulta de acción de actualización.
7.4.4 Consulta de acción de adición Las consultas de acción de adición se utilizan para insertar registros de una o más tablas de origen en una única tabla de destino. Podemos añadir registros a una tabla de la misma base de datos o de otra base de datos distinta. Las consultas de adición también son útiles cuando queremos añadir campos basados en una serie de criterios o incluso cuando algunos de los campos no existen en la otra tabla. Por ejemplo, suponga que queremos insertar los detalles de una serie de nuevos propietarios de inmueble s en alquiler en la tabla PrivateOwner. Suponga que los detalles de estos nuevos propietarios están contenidos en una tabla denominada NewOwner, que sólo contiene los campos ownerNo, fName, IName y address. Además, queremos añadir únicamente los nuevos propietarios que vivan en Glasgow a la tabla PrivateOwner. En este ejemplo la tabla PrivateOwneres la tabla de destino y la tabla NewOwneres la tabla de origen. Para crear una consulta de acción de adición, primero diseñamos una consulta que extraiga los registros apropiados de la tabla NewOwner.Después cambiamos el tipo de consulta a Append y se mostrará un cuadro de diálogo, que preguntará por el nombre y la ubicación de la tabla de destino, como se muestra en la Figura 7.18(a). La cuadrícula QBE para esta consulta de acción de adición se muestra en la Figura 7.18(b). Cuando ejecutamos la consulta, un mensaje de advertencia nos preguntará si queremos continuar con la operación de adición, como se muestra en la Figura 7.18( c). Si confirmamos la operación, se añadirán a la tabla PrivateOwner los dos registros de propietarios ubicados en Glasgow dentro de la tabla NewOwner, como se indica en la Figura 7.18(d). La instrucción SQL equivalente para la consulta de acción de adición se muestra en la Figura 7.l8(e).
200
Sistemas de bases de datos
(a)
Tabla objetivo de la actualización
Fíeld:
Table; Fila Update To ---
Expresión para actualizar los valores del campo rent en un 10%
Update To: Critería:
QB~[---
or;
Cuadricula de actualización
(b)
You are about to update 6 row(s). Once you dick Ves, you can't use the Undo command to reverse the changes, Are you sure you want to update these records?
[
Ves
En caso afirmativo (e)
propertyNo PA14 PG16 PG21 PG36 PG4 PL94
~ ~. Record:
of 7
1.:!.L!J
Los valores de la columna rent actualizados en un 10% (d)
UPDATE
Figura 7.17.
PropertyForRent
SET
PropertyForRent.rent
= [rent]*1.1;
(a) Cuadrícula QBE para la consulta de acción de actualización (b) mensaje de advertencia; (c) hoja de datos resultante; (d) instrucción SQL equivalente,
de ejemplo;
Capítulo 7 QBE 201 Nombre de la tabla objetivo
(a)
Ubicación de la tabla objetivo
I
Fleld:
-
ownerNo
Uke "*GlaS90w'"
rabie: 5ort: (b) Fila Append To Append To:
- -
-."'" NewOwner NewOwner fNdme address fNewO.,vner Name lName IName addra"
Criterio que selecciona los propietarios que viven en Glasgow
Criterla:
I
or:
Cuadrícula QBE
't
t Campos seleccionados
de la tabla NewOwner
(tabla de origen)
para adición (e)
You are about to append;2 row(s). Once yo¡.¡ dkk
Ve.,
Are you sure you
(d)
Se ha añadido una copia de los registros de nuevos
address 944 Long Road,. Glasgow G45 8\11iQ
propietarios que viven en Glasgow a la tabla PrivateOwner
A~enue, Glasgow G10 7GH Slreel, Gla!gow
842
Fergus Drive, Aberdeen AB2 7SX Slreet, Glasgow G32 9DX ParkPlace ,13lasgow G4 OQR Aehray Slreel, Glasgow G32 9DX
Figura 7.18.
(a) Cuadro de diálogo Append; (b) Cuadrícula QSE de la consulta de acción de adición de ejemplo; (c) mensaje de advertencia; (d) la tabla NewOwner table y la tabla PrivateOwner con los registros recién añadidos.
202
Sistemas de bases de datos
(e)
INSERT INTO PrivateOwner (ownerNo, fName, IName,address) SELECT NewOwner.ownerNo,NewOwner.fName,NewOwner.IName,NewOwner.address FROM NewOwner WHERE (((NewOwner.address) Like "*Glasgow*")); Figura 7.18.
(Cont.)
(e) instrucción SQL equivalente.
Ejercicios 7.1.
Cree las tablas de ejemplo del caso de estudio de DreamHome que se muestran en la Figura 3.3 Y lleve a cabo los ejercicios ilustrados en este capítulo, usando (siempre que sea posible) la función QBE de su SGBD.
7.2.
Cree las siguientes consultas adicionales QBE de selección para las tablas de ejemplo del caso de estudio de DreamHome, usando (siempre que sea posible) la función QBE de su SGBD.
7.3.
7.4.
(a)
Extraiga el número de sucursal y la dirección de todas las sucursales.
(b)
Extraiga el número de empleado, el puesto y el salario para todos los empleados que trabajen en la sucursal B003.
(c)
Extraiga los detalles de todos los apartamentos (flat) situados en Glasgow.
(d)
Extraiga los detalles de todos los empleados del sexo femenino que tenga más de 25 años.
(e)
Extraiga el nombre completo y el teléfono de todos los clientes que hayan visitado algún apartamento en Glasgow.
(t)
Extraiga el número total de inmuebles, clasificados según el tipo de inmuebles.
(g)
Extraiga el número total de empleados que trabajan en cada sucursal, ordenando el listado según el número de sucursal.
Cree las siguientes consultas QBE avanzadas para las tablas de ejemplo en el caso de estudio de DreamHome, utilizando (siempre que sea posible) la función QBE de su SGBD. (a)
Cree una consulta paramétrica que solicite un número de inmueble y luego muestre los detalles de dicho inmueble.
(b)
Cree una consulta paramétrica que solicite el nombre y apellido de un empleado y a continuación muestren los detalles de los inmuebles de los que ese empleado es responsable.
(c)
Añada más registros a la tabla PropertyForRentpara reflejar el hecho de que los propietarios 'Carol Farrel' y 'Tony Shaw' poseen ahora numerosos inmuebles en diversas ciudades. Cree una consulta de selección para mostrar, para cada propietario, el número de inmuebles que posee en cada ciudad. Ahora, convierta la consulta de selección en una consulta matricial y compruebe si la hoja de datos resultante es más o menos útil para comparar el número de inmuebles que cada propietario posee en cada ciudad.
(d)
Introduzca un error en su tabla Staff añadiendo un registro adicional para el empleado denominado 'David Ford' con un nuevo número de empleado. Utilice una consulta de localización de duplicados para identificar este error.
(e)
Utilice una consulta de localización de no correspondencias tienen ningún inmueble asignado.
(t)
Cree una consulta de autobúsqueda que rellene los detalles de un propietario cuando se introduce un nuevo registro de inmueble en la tabla PropertyForRent y el propietario del inmueble ya existe en la base de datos.
para identificar los empleados que no
Utilice consultas de acción para llevar a cabo las siguientes tareas sobre las tablas de ejemplo del caso de estudio de DreamHome, empleando (siempre que sea posible) la función QBE de su SGBD.
Capítulo 7 ORE 203 (a)
Cree una versión reducida de la tabla PropertyForRent denominada PropertyGlasgow, que tenga los campos propertyNo, street, postcode y type de la tabla original y contenga únicamente los detalles de los inmuebles situados en Glasgow.
(b)
Elimine todos los registros de visitas de inmueble s que no tengan ningún dato en el campo
com-
ment.
7.5.
(c)
Actualice el salario de todos los empleados, salvo de los gerentes (Manager), en un 12,5%.
(d)
Cree una tabla denominada NewClient que contenga los detalles de nuevos clientes. Añada estos datos a la tabla Client original.
Utilizando la tablas de ejemplo del caso de estudio de DreamHome, cree consultas QBE equivalentes para los ejemplos de SQL dados en el Capítulo 5.
Capítulo
Bases de datos comerciales: Office Access y Oracle Objetivos del capítulo: En este capítulo aprenderá: •
•
Acerca de Microsoft Office Access 2003: •
la arquitectura del SOBO;
•
cómo crear tablas base y relaciones;
•
cómo crear restricciones generales;
• •
cómo utilizar formularios e informes; cómo utilizar macros .
Acerca de Oracle9i: •
la arquitectura del SOBO;
•
cómo crear tablas base y relaciones;
•
cómo crear restricciones generales;
•
cómo utilizar PL/SQL;
•
cómo crear y utilizar funciones y procedimientos
•
cómo crear y utilizar disparadores;
•
cómo utilizar formularios e informes;
•
el soporte para la informática reticular.
almacenados;
Como hemos mencionado en el Capítulo 3, los SOBOR (sistemas de gestión de bases de datos relacionales) se han convertido en el software dominante para procesamiento de datos hoy en día, con unas ventas estimadas de nuevas licencias de entre 6000 y 10.000 millones de dólares por año (25.000 millones de dólares si incluimos las ventas de herramientas). Existen centenares de SOBOR en el mercado. Para muchos usuarios, el proceso de seleccionar el mejor paquete SOBO puede resultar dificil y en el siguiente capítulo presentaremos un resumen de las principales características que deben tomarse en consideración a la hora de elegir uno de estos paquetes. En este capítulo, vamos a considerar dos de los SOBOR más utilizados: Microsoft Office Access y Oracle. En cada uno de los casos, utilizaremos la terminología de ese SOBO en particular (que no se adapta a la terminología relacional formal que hemos presentado en el Capítulo 3).
8.1 Microsoft Office Access 2003 Microsoft Office Access es el SOBO relacional más ampliamente utilizado por los entornos Microsoft Windows. Se trata de un SOBO típico basado en PC capaz de almacenar, ordenar y extraer datos para una gran diversidad de aplicaciones. Access proporciona una interfaz gráfica de usuario (ODl, Oraphical Dser
206
Sistemas de bases de datos
Interface) para crear tablas, consultas, formularios o informes, así como herramientas para desarrollar aplicaciones personalizadas de base de datos utilizando el lenguaje de macros de Microsoft Office Access o el lenguaje Microsoft Visual Basic for Applications (VBA). Además, Office Access proporciona una serie de programas, denominados asistentes, para simplificar muchos de los procesos de diseño de una aplicación de bases de datos, llevando al usuario a través de una serie de cuadros de diálogo de tipo pregunta-respuesta. También proporciona generadores para ayudar a cada usuario a construir expresiones sintácticamente correctas, como por ejemplo las que se requieren en las instrucciones SQL y en las macros. Office Access soporta buena parte del estándar SQL presentado en los Capítulo 5 y 6, así como el estándar ODBC (Open Database Connectivity, conectividad abierta de bases de datos) de Microsoft, que proporciona una interfaz común para acceder a bases de datos SQL heterogéneas, como Oracle e Informix. Hablaremos de ODBC con mayor detalle en el Apéndice E. Para comenzar nuestra presentación de Microsoft Office Access, vamos a introducir primero los objetos que pueden crearse como ayuda para el desarrollo de bases de datos.
8.1.1 Objetos El usuario interactúa con Microsoft Office Access y desarrolla aplicaciones de bases de datos utilizando diversos objetos: •
Tablas. Las tablas base que forman la base de datos. Utilizando la terminología Microsoft, una tabla está organizada en columnas (denominadas campos) y filas (denominadas registros).
•
Consultas. Permiten al usuario ver, modificar y analizar los datos de distintas maneras. Las consultas también pueden almacenarse y utilizarse como origen de registros para formularios, informes y páginas de acceso a datos. Hemos examinado las consultas con un cierto grado de detalle en el capítulo anterior.
•
Formularios. Pueden utilizarse para diversos propósitos, como por ejemplo crear formularios de introducción de datos para añadir información a una tabla.
•
Informes. Permiten presentar los datos de la base de datos de una manera efectiva, en un formato impreso personalizado.
•
Páginas. Una página (de acceso a datos) es un tipo especial de página web diseñada para visualizar y trabajar con los datos (almacenada en una base de datos Microsoft OfficeAccess o en una base de datos de Microsoft SQL Server) a través de Internet o de una intranet. La página de acceso a datos puede también incluir datos de otros orígenes, como por ejemplo Microsoft Excel.
•
Macros. Un conjunto de una o más acciones, cada una de las cuales realiza una operación concreta, como por ejemplo abrir un formulario o imprimir un informe. Las macros puede ayudar a automatizar tareas comunes tales como imprimir un informe cuando el usuario hace clic sobre un botón.
•
Módulos. Una colección de declaraciones y procedimientos VBA que se almacenan como una unidad.
Antes de analizar estos objetos con mayor detalle, vamos a examinar primero la arquitectura de Microsoft Office Access.
8.1.2 Arquitectura de Microsoft Office Access Microsoft Office Access puede utilizarse como un sistema autónomo en un único PC o como un sistema multiusuario en una red de computadoras personales. Desde el lanzamiento de Access 2000, el producto incluye dos posibles motores de datosi-:el motor Jet original y el nuevo motor MSDE (Microsoft SQL Server Desktop Engine, anteriormente llamado Microsoft Data Engine), que es compatible con el servidor SQL corporativo de Microsoft. El motor Jet almacena todos los datos de la aplicación, como tablas, índices, consultas, formularios e informes, en un único archivo de base de datos de Microsoft (.mdb), basado en una organización de acceso secuencia] indexado (ISAM, Indexed Sequentia] Access Method); consulte el Apéndice C. MSDE está t Un 'motor de datos' o 'motor
de base de datos' es el proceso fundamental que el SGBD utiliza para almacenar y mantener los datos.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
207
basado en el mismo motor de datos que SQL Server, que permite a los usuarios escribir una aplicación que pueda transportarse desde un PC con Windows 95 a un clúster multiprocesador con Windows Server 2003. MSDE proporciona también una ruta de migración para permitir a los usuarios actualizarse posteriormente a SQL Server. Sin embargo, a diferencia de SQL Server, MSDE tiene un tamaño límite de base de datos de 2 gigabytes. Microsoft Office Access, al igual que SQL Server, divide los datos almacenados en sus estructuras de tablas en páginas de datos de 2 kilobytes, que se corresponden con el tamaño de un clúster de archivo convencional DOS en disco duro. Cada página contiene uno o más registros. Ningún registro puede dividirse entre dos páginas, aunque los campos de tipo Memo y OLE Object pueden almacenarse en páginas separadas del resto del registro. Office Access utiliza registros de longitud variable como método estándar de almacenamiento y permite ordenar los registros utilizando un índice, como por ejemplo una clave principal. Utilizando registros de longitud variable, cada registro sólo ocupa el espacio necesario para almacenar los datos que contiene. A cada página se le añade una cabecera para crear una lista enlazada de páginas de datos. La cabecera contiene el puntero a la página precedente y otro a la página siguiente. Si no se están utilizando índices, los nuevos datos se añaden a la última página de la tabla hasta que la página se llena, después de lo cual se añadirá otra página al final. Una de las ventajas de que las páginas de datos incluyan su propia cabecera es que las páginas de datos de una tabla pueden mantenerse en orden ISAM alterando los punteros de la cabecera de página, y no la estructura del propio archivo.
Soporte multiusuario Microsoft Office Access proporciona cuatro formas principales de trabajar con una base de datos compartida por varios usuarios en una red: •
Soluciones basadas en servidor de archivos. Se sitúa una base de datos Office Access en una red de modo que múltiples usuarios puedan compartida. En este caso, cada estación de trabajo ejecuta una copia de la aplicación Office Access.
•
Soluciones cliente-servidor. En las versiones anteriores de Office Access la única forma de conseguir este tipo de arquitectura era crear tablas enlazadas que utilizaran un controlador ODBC para servir de enlace a una base de datos tal como SQL Server. Desde la introducción de Access 2000, también puede crearse un archivo de proyecto Access (Access Project FUe, .adp), que puede almacenar formularios, informes, macros y módulos VBA localmente y puede conectarse a una base de datos SQL Server remota utilizando OLE DB (Object Linking and Embedding for Databases, vinculación e incrustación de objetos para bases de datos) para visualizar y manipular tablas, vistas, relaciones y procedimientos almacenados. Como hemos mencionado anteriormente, también puede utilizarse MSDE para implementar este tipo de solución.
•
Soluciones de replicación de base de datos. Estas soluciones permiten compartir las modificaciones de los datos o de las bases de datos entre una serie de copias de una base de datos Office Access en diferentes ubicaciones, sin necesidad de redistribuir copias de la base de datos completa. La replicación implica producir una o más copias, denominadas réplicas, de una única base de datos original, denominada maestro de diseño. Al conjunto formado por el maestro de diseño y sus réplicas se le llama conjunto de replicación. Realizando un proceso denominado sincronización, se distribuyen a todos los miembros del conjunto de replicación los cambios realizados en los objetos y en los datos. Los cambios en el diseño de los objetos sólo pueden llevarse a cabo en el maestro de diseño, pero los cambios en los datos pueden realizarse desde cualquier miembro del conjunto de replicación. Hablaremos de la replicación en el Capítulo 24.
•
Soluciones de base de datos basadas a datos que enlazan dinámicamente Estas páginas deben ser visualizadas remos de esta solución en la Sección
en la Web. Un explorador muestra una o más páginas de acceso con una base de datos compartida Office Access o SQL Server. mediante Internet Explorer 5 o alguna versión posterior. Habla29.10.5
208
Sistemas de bases de datos
Cuando una base de datos reside en un servidor de archivos, se utilizan las primitivas de bloqueo del sistema operativo para bloquear las páginas cuando se está actualizando un registro de una tabla. En un entorno multiusuario, Jet utiliza un archivo de base de datos de bloqueo (.ldb) para almacenar información sobre qué registros están bloqueados y qué usuarios los han bloqueado. El archivo de bloqueo de la base de datos se crea cuando se abre la base de datos para acceso compartido. Hablaremos en detalle del tema de los bloqueos en la Sección 20.2.
8.1.3 Definición de tablas Microsoft Office Access proporciona cinco formas de crear una tabla en blanco (vacía): •
Utilizar el asistente de bases de datos (Database Wizard) para crear en una sola operación todas las tablas, formularios e informes requeridos por toda la base de datos. El asistente de base de datos crea una nueva base de datos, aunque este asistente concreto no puede utilizarse para añadir nuevas tablas, formularios o informes a una base de datos ya existente.
•
Utilizar el asistente de tablas (Table Wizard) para seleccionar los campos que compondrán la tabla a partir de diversas tablas predefinidas, como tablas de contactos comerciales, tablas de contabilidad doméstica o tablas de registros médicos.
•
Introducir los datos directamente en una tabla en blanco (denominada hoja de datos). Cuando se guarda la nueva hoja de datos, Office Access analiza los datos y asigna automáticamente el tipo de datos y el formato apropiados para cada campo.
•
Utilizar la vista de diseño (Design View) para especificar todos los detalles de la tabla partiendo de cero.
•
Utilizar la instruGción CREATE TABLE en la vista SQL (SQL View).
Creación de una tabla en blanco Microsoft Office Access mediante SOL En la Sección 6.3.2 hemos examinado la instrucción SQL CREATE TABLE que permite a los usuarios crear una tabla. Microsoft Office Access 2003 no es completamente compatible con el estándar SQL y la instrucción CREATE TABLE de Office Access no soporta las cláusulas DEFAULT y CHECK. Sin embargo, se pueden especificar valores predeterminados y ciertas restricciones de negocio desde fuera de SQL, como veremos en breve. Además, los tipos de datos son ligeramente distintos al estándar SQL, como se muestra en la Tabla 8.1. En el Ejemplo 6.1 del Capítulo 6 vimos cómo crear la tabla PropertyForRent en SQL. La Figura 8.1 muestra la ventana SQL View con la instrucción equivalente en Office Access. Tabla 8.1.
Tipos de datos en Microsoft Office Access.
Tipo de datos
Utilización
Tamaño
Texto
Texto o texto/números. También, números que no requieren cálculos, como por ejemplo números telefónicos. Se corresponde con el tipo de datos de carácter en SQL (véase la Sección 6.1.2).
Hasta 255 caracteres
Memo
Texto y números de gran longitud, como por ejemplo notas o descripciones.
Hasta 65.536 caracteres
Número
Datos numéricos que hay que utilizar en cálculos matemáticos, excepto los cálculos de tipo monetario (para los cuales se usa el tipo monetario). Se corresponde con los tipos de datos numérico exacto y numérico aproximado en SQL (véase la Sección 6.1.2).
1,2,4 u 8 bytes (16 bytes para el tipo Replication ID)
(Continúa)
Capítulo 8 Bases de datos comerciales: Tabla 8.1.
Office Access y Oracle
209
Tipos de datos en Microsoft Office Access. (Cant.)
Tipo de datos
Utilización
Tamaño
Fecha/hora
Fechas y horas. Se corresponde con el tipo de datos de fecha y hora en SQL (véase la Sección 6.1.2).
8 bytes
Monetario
Valores monetarios. Utiliza el tipo de datos monetario (Currency) para evitar los redondeos durante los cálculos.
8 bytes
Autonúmero
Números secuenciales univocos (que se incrementan de en 1) o aleatorios y que se insertan automáticamente cuando se añade un registro.
Si/No
Campos que sólo pueden contener uno de dos valores, como por ejemplo Si/No, VerdaderolFalso, On/Off. Se corresponde con el tipo de datos bit en SQL (véase la Sección 6.1.2).
1
Objeto OLE
Objetos (como documentos Microsoft Word, hojas de cálculo Microsoft Excel, imágenes, sonidos u otros datos binarios) creados en otros programas utilizando el protocolo OLE y que pueden enlazarse con, e incrustarse en, una tabla Microsoft Office Access.
Hasta 1 gigabyte
Hipervinculo
Campo en el que se pueden almacenar hipervinculos.
Hasta 64.000 caracteres
Asistente de búsqueda
Crea un campo que permite al usuario seleccionar un valor de otra tabla o de entre una lista de valores utilizando un cuadro de diálogo combinado. Si se selecciona esta opción en la lista de tipos de datos, se iniciará un asistente para proceder a la definición.
Mismo tamaño que la clave principal que forma el campo de búsqueda (normalmente 4 byte s)
I
4 bytes (16 byte s para el tipo Replication ID)
bit
Creación de una tabla en blanco Microsoft Office Access mediante Design View La Figura 8.2 muestra la creación de la tabla PropertyForRent en la ventana Design View. Independientemente del método que se utilice para crear una tabla, puede emplearse la ventana de diseño en cualquier momento posterior para personalizar la tabla, como por ejemplo añadiendo nuevos campos, estableciendo valores predeterminados o creando máscaras de introducción de datos. Microsoft Office Access proporciona una serie de funciones para añadir restricciones a una tabla mediante la sección Field Properties (propiedades del campo) en la vista de diseño de la tabla. Cada campo tiene una serie de propiedades que se utilizan para personalizar el modo en que se almacenan, se gestionan o visualizan
REATE TABLE PropertyForRent(propert\,'r~o '.ARCHAR(S), street VARCHAR(2S) NOT NULL, city VARCHAR(lS) ostcode VARCHAR(8), type CHAR NOT NULL, roorns BYTE ~~OTNULLJ rent CURRE~JC'( NOT NULLJ
NOT NULL,
wnerNo VARCHAR(S) NOT NULL, staffNo VARCHAR(S), branchNo CHAR(4) ~
fkpfr3
FOREIG~~ KEY (branchNo)
Figura 8.1.
REFERENCES Branch(braráNo));
Ventana SQL View que muestra la creación de la tabla PropertyForRent.
210
Sistemas de bases de datos
;H.~l"JiI'm· FleldName propertyNo street
Unlque identifier far a property Street of propertl' addr= City of prollerty address Postcode of property address Code descríbing type of property Numberof rooms in property (excludlng bathroom(s) Monthly Fent of Owner number of the property Steff number mernber responsible for managing the property branch
city postcode type f1room5 rent ownerNo 5taffNo branchNo
General 1 FíeJd Size
Byte
Format
El valor de rooms debe estar comprendido entre 1 y 15
Dedmal Places
o
Input r"lesk Caption Default Value
4
\lafidation Rule \laUdatíon Text Required Indexed
Number of Rooms >=1 And <=151 Range of possibJe values ís 1 to 15. No No
Smert lag5
Figura 8.2.
Ventana Design View que muestra la creación de la tabla PropertyForRent.
los datos contenidos en el campo. Por ejemplo, podemos controlar el número máximo de caracteres que pueden introducirse en un campo de texto ajustando su propiedad Field Size (tamaño de campo). El tipo de datos de un campo determina las propiedades disponibles para el mismo. Al configurar las propiedades del campo en la vista de diseño, se garantiza que los campos tengan una configuración coherente cuando se los utilice más adelante para construir formularios e informes. Vamos a analizar ahora brevemente cada una de las propiedades de los campos. Propiedad Field Size
La propiedad Field Size (tamaño de campo) se utiliza para establecer el tamaño máximo de los datos que pueden almacenarse en un campo de tipo texto, numérico y autonumérico. Por ejemplo, la propiedad Field Size del campo propertyNo (texto) está configurada a 5 caracteres, mientras que la propiedad Field Size del campo rooms (numérico) está configurada como Byte para almacenar números enteros comprendidos entre O y 255, como se muestra en la Figura 8.2. Además de Byte, los valores válidos para los tipos de datos numériCOS son: •
Integer - entero de 16 bits (valores comprendidos entre -32.768
• •
Long integer - entero de 32 bits; Single - representación en coma flotante de 32 bits;
y 32.767);
•
Double - representación en coma flotante de 64 bits;
• •
Replication ID - identificador de 128bits, unívoco para cada registro, incluso en un sistema distribuido; Decimal - número en coma flotante con una cierta precisión y escala.
Propiedad Format
La propiedad Format se utiliza para personalizar la manera en que se visual izan e imprimen los números, las fechas, las horas y el texto. Microsoft Office Access proporciona diversos formato s para la visualización de
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
211
los distintos tipos de datos. Por ejemplo, un campo con un tipo de datos fecha/hora puede visualizar las fechas en varios formatos, incluyendo Short Date, Medium Date y Long Date (formato corto, medio y largo, respectivamente). La fecha 1 de noviembre de 1933 puede visualizarse como 01/11/33 (formato corto), 01-Nov-33 (formato medio) o 1 November 1933 (formato largo). Propiedad Decimal Places
La propiedad Decimal Places se utiliza para especificar el número de posiciones decimales que hay que utilizar a la hora de visualizar los números (esto no afecta en la práctica al número de posiciones decimales utilizadas para almacenar el número). Propiedad Input Mask
Las máscaras de entrada (Input Mask) sirven de ayuda durante el proceso de introducción de datos, al controlar el formato de los datos a medida que se introducen en la tabla. Una máscara determina el tipo de caracteres permitidos para cada posición de un campo. Las máscaras de entrada pueden simplificar la introducción de datos al añadir caracteres especialmente formateados cada vez que se requieran y generar mensajes de error cuando se intente introducir datos incorrectos. Microsoft Office Access proporciona diversos caracteres de máscara de entrada para controlar la introducción de los datos. Por ejemplo, los valores que hay que introducir en el campo propertyNotienen un formato específico: el primer carácter debe ser 'P' (property, inmueble), el segundo carácter es una letra mayúscula y los caracteres tercero, cuarto y quinto son numéricos. Los caracteres cuarto y quinto son opcionales y sólo se utilizan si hacen falta (por ejemplo, los números de inmueble incluyen PA9, PG21 Y PL306). La máscara de entrada que se utilizaría en este caso es '\P>L099': •
'\' hace que el carácter que sigue se muestre como un carácter literal (por ejemplo, \P se muestra simplemente como P);
•
'>L' hace que la letra que sigue a la P se convierta a mayúsculas;
•
'O' especifica que debe seguir un dígito obligatoriamente, opcional de un dígito o espacio.
mientras que '9' especifica la introducción
Propiedad Caption
La propiedad Caption (descripción) se utiliza para proporcionar una descripción más completa del nombre de un campo o para mostrar información útil al usuario añadiendo descripciones a los objetos en diversas vistas. Por ejemplo, si introducimos la cadena de caracteres 'número de inmuebles' en la propiedad Caption del campo propertyNo, se mostraría como encabezado de columna 'Número de inmueble' en la tabla dentro de la vista de hoja de datos (Datasheet View) en lugar de mostrarse el nombre del campo, 'propertyNo'. Propiedad Default Value
Para acelerar el proceso de introducción de datos y reducir los posibles errores, podemos asignar valores predeterminados (Default Value) con el fin de especificar un valor que se introduzca automáticamente en un campo cada vez que se cree un nuevo registro. Por ejemplo, el número medio de habitaciones en un inmueble es de cuatro, por lo que configuraremos '4' como valor predeterminado para el campo rooms, como se muestra en la Figura 8.2. Propiedades Validation Rule/Validation Text
La propiedad Validation Rule (regla de validación) se utiliza para especificar restricciones para los datos introducidos en un campo. Cuando se introduzcan datos que violen la regla de validación especificada, se usará la propiedad Validation Text (texto de validación) para mostrar un mensaje de advertencia. Las reglas de validación también pueden utilizarse para configurar un rango de valores permitidos para los campos numéricos o de fecha. Esto reduce la cantidad de errores que pueden producirse a la hora de introducir registros en una tabla. Por ejemplo, el número de habitaciones en un inmueble va de un mínimo de 1 a un máximo de 15. La regla de validación y el texto para el campo rooms se muestran en la Figura 8.2.
212
Sistemas de bases de datos
Propiedad Required
Los campos requeridos (Required) deben obligatoriamente contener un valor en cada registro. Si se configura esta propiedad con el valor 'Sí', deberá introducirse un valor de campo requerido y este valor deberá ser no nulo. Por tanto, activar la propiedad Required es equivalente a la restricción NOT NULL en SQL (véase la Sección 6.2.1). Los campos de clave principal deben siempre implementarse como campos requeridos. Propiedad Allow Zero Length
La propiedad Allow Zero Length (permitir longitud cero) se utiliza para especificar si las cadenas de caracteres de longitud cero ("") constituyen una entrada válida en un cierto campo (para campos de tipo texto, memo e hipervínculo). Si queremos que Microsoft Office Access almacene una cadena de longitud cero en lugar de un valor nulo cuando se deje un campo en blanco, será necesario configurar con el valor 'Yes' las propiedades Allow Zero Length y Required. La propiedad Allow Zero Length funciona de forma independiente de la propiedad Required. La propiedad Required determina sólo si los valores nulos son válidos para un determinado campo. Si se configura la propiedad Allow Zero Length como 'Yes', las cadenas de caracteres de longitud cero serán valores válidos para el campo independientemente de la configuración de la propiedad Required. Propiedad Indexed
La propiedad Indexed (indexado) se utiliza para configurar un índice basado en un único campo. Un índice es una estructura empleada para ayudar a extraer los datos de forma más rápida y eficiente (de la misma forma que el índice de este libro permite encontrar de manera más rápida una sección concreta). Los índices aceleran las consultas relativas a los campos indexados, así como las operaciones de ordenación y agrupamiento. La propiedad Indexed tiene los siguientes valores: No
sin índice (opción predeterminada)
Yes (Duplicates OK)
el índice permite valores duplicados
Yes (No Duplicates)
el índice no permite valores duplicados
Para la base de datos DreamHome, hallaremos qué campos indexar dentro del Paso 5.3 en el Capítulo 17. Propiedad Unicode Compression
Unicode es un estándar de codificación de caracteres que representa cada carácter como dos bytes, lo que permite representar mediante un único conjunto de caracteres casi todos los lenguajes escritos existentes en el mundo. Para un carácter latino (un carácter de algún idioma europeo occidental, como el inglés, el español o el alemán), el primer byte es O. Por tanto, para los campos de tipo texto, memo e hipertexto, es necesario un mayor espacio de almacenamiento que en las versiones anteriores de Office Access, que no utilizaban Unicode. Para resolver esto, el valor predeterminado de la propiedad Unicode Compression (compresión Unicode) para estos campos es 'Yes' (lo que activa la compresión), por lo que cualquier carácter cuyo primer byte sea O se comprime a la hora de almacenarlo y se descomprime al extraerlo. La propiedad Unicode Compression también puede configurarse como 'No' lo que desactiva la compresión. Observe que los datos en un campo memo no estarán comprimidos a menos que requiera un espacio de almacenamiento de 4096 bytes o inferior después de la compresión. Propiedades IME Mode/lME Sentence Mode
Un editor de métodos de entrada (IME, Input Method Editor) es un programa que permite introducir texto en algún lenguaje de Extremo Oriente (chino tradicional, chino simplificado, japonés o coreano), convirtiendo las pulsaciones de tecla en caracteres complejos en dicho idioma. En esencia, el IME se trata como un tipo alternativo de disposición del teclado. El IME interpreta las pulsaciones de teclas como caracteres y luego da al usuario la oportunidad de insertar la interpretación correcta. La propiedad IME Mode (modo IME) se apli-
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
213
ca a todos los lenguajes de Extremo Oriente, mientras que la propiedad IME Sentence Mode (modo de frase IME) se aplica únicamente al japonés. Propiedad Smart tags
Las etiquetas inteligentes (Smart Tags) permiten realizar el Office Access acciones que normalmente obligarían al usuario a abrir algún otro programa. Pueden asociarse etiquetas inteligentes con los campos de una tabla o consulta o con los controles de un formulario, informe o página de acceso a datos. Cuando se activa el campo o control, aparecerá el botón Smart Tags Action ~, pudiendo hacer clic en el botón para ver qué acciones hay disponibles. Por ejemplo, para el nombre de una persona, la etiqueta inteligente podría permitir la generación de un correo electrónico; para una fecha, la etiqueta inteligente podría permitir programa una reunión. Microsoft proporciona algunas etiquetas estándar, pero también pueden construirse etiquetas inteligentes personalizadas utilizando cualquier lenguaje de programación capaz de crear un complemento COM (Component Object Model, modelo de objetos componentes).
8.1.4 Definición de relaciones y de integridad referencial Como hemos visto en la Figura 8.1, pueden crearse relaciones en Microsoft Office Access utilizando la instrucción SQL CREATE TABLE. Pero también pueden crearse relaciones en la ventana Relationships. Para crear una relación, lo que se hace es visualizar las tablas entre las que se quiere crear la relación y luego arrastrar el campo de clave principal de la tabla padre hasta el campo de clave externa de la tabla hija. En este punto, Office Access mostrará una ventana donde pueden especificarse las restricciones de integridad referencial. La Figura 8.3(a) muestra el cuadro de diálogo de integridad referencial que aparece al crear la relación uno a muchos (1: *) Staff Gestiona PropertyForRent, y la Figura 8.3(b) muestra la ventana Relationships después de crear la relación. Hay dos observaciones que realizar con respecto a la configuración de restricciones de integridad referencial en Microsoft Office Access: (1) Se creará una relación uno a muchos (1 :*) si sólo uno de los campos relacionados es una clave principalo tiene un índice unívoco; si ambos campos relacionados son claves principales o tienen índices univocos, se creará una relación 1:l. (2) Sólo hay dos acciones de integridad referencial para actualización y borrado, que se corresponden con NO ACTION y CASCADE (véase la Sección 6.2.4). Por tanto, si se requieren otras acciones, deberá considerarse si pueden modificarse estas restricciones para encajar dentro de las restricciones disponibles en Office Access, o si por el contrario se prefiere implementar dichas restricciones en el código de aplicación.
8.1.5 Definición de restricciones generales Hay varias maneras de crear restricciones generales en Microsoft Office Access utilizando, por ejemplo: •
reglas de validación para campos;
•
reglas de validación para registros;
•
validaciones para formularios utilizando VBA (Visual Basic for Applications).
Ya hemos visto un ejemplo de validación de campos en la Sección 8.1.3. En esta sección, vamos a ilustrar los otros dos métodos con algunos ejemplos simples.
Reglas de validación para registros Una regla de validación para registros controla en qué condiciones puede guardarse un registro completo. A diferencia de las reglas de validación de campos, las reglas de validación de registros pueden referirse a más de un campo. Esto puede resultar útil cuando se hace necesario comparar valores de diferentes campos de una
214
Sistemas de bases de datos
Muestra los campos de clave principal/ clave externa
Seleccionada para imponer la integridad referencial Seleccionada para
Cascada Updata
ON UPDATE CASCADE Cascada Oalet:e Relatad Reoords
Muestra la cardinalidad de la relación
•
Relationshíp
propertyNo street city postcode t'ipe roorns DOS
rent owner~,o staffNo branchNo
salar'i branchNo
(a) Establecimiento de las restricciones de integridad referencial para la relación uno a muchos Staft Gestiona PropertyForRent; (b) ventana de relación en la que se muestra la relación uno a muchos Staft Gestiona PropertyForRent.
Figura 8.3.
tabla. Por ejemplo, DreamHome tiene una restricción que indica que el periodo de alquiler de los inmuebles debe estar comprendido entre 90 días y un año. Podemos implementar esta restricción en el nivel de registros dentro de la tabla Lease mediante la regla de validación: [dateFinish]- [dateStart]Between 90 y 365 La Figura 8.4 muestra el cuadro de diálogo Table Properties para la tabla Lease con esta regla configurada.
Validación para formularios
mediante VBA
DreamHome también tiene una restricción que evita que un empleado gestione más de 100 inmuebles al mismo tiempo. Se trata de una restricción más compleja, que requiere comprobar cuántos inmuebles gestiona
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
215
Description •. " .. "" ,Date Check Default \liew . , , ...• ,.", ••Dát~~e'~< \lalídation Rula " •... ",. Ir~~EiQisbJ:(rentStarttBetwe~en 90 And ~65 _ \laUdation T6l!Zt , , , •••• ,', Duratíon of leas e must be between 90 and 365 days fílter ,' .... , : ••.. , ,. , • ,-~ ' .". ~ ~ .OrderBy,."", •• " .. , , Subdatasheet Name .• , ••..• UnkChild Flelds, , .• , , , , H' • Link Master Fíelds •• , , •• , • , •
Subdatasheet Helght ,. , ... Subdatasheet Orientation , • , • , ..•••.•••
Figura 8.4.
Ejemplo de validación de registros en Microsoft Office Access.
actualmente el empleado. Una forma de implementar esta restricción en Office Access consiste en utilizar un procedimiento de suceso, Un suceso es una acción específica que tiene lugar en o sobre un cierto objeto. Microsoft Office Access puede responder a diversos tipos de sucesos, como clics de ratón, cambios en los datos y aperturas o cierres de formulario. Los sucesos son usualmente el resultado de algún tipo de acción llevada a cabo por el usuario. Utilizando un procedimiento de suceso o un macro (véase la Sección 8.1.8), podemos personalizar la respuesta de un usuario a un suceso que tenga Jugar en un formulario, en un informe o en un control. La Figura 8.5 muestra un ejemplo de procedimiento de suceso BeforeUpdate (antes de ]a actualización) que se dispara antes de actualizar un registro, con el fin de imp]ementar esta restricción. En algunos sistemas, no existirá soporte para algunas de las restricciones generales, o para ninguna de ellas, y será necesario incluir la comprobación de dichas restricciones dentro de la aplicación, como hemos mostrado en la Figura 8.5, donde ]a restricción está integrada dentro del código VBA de ]a aplicación. La imp]ementación de restricciones generales en e] código de aplicación es potencialmente peligrosa y puede conducir a una duplicación de esfuerzos y, todavía peor, a la aparición de incoherencias, si dicha restricción no se imp]ementa en todos los lugares donde debería.
8.1.6 Formularios Los formularios de Microsoft Office Access permiten al usuario visualizar y editar los datos almacenados en las tablas base subyacentes, presentando los datos en una forma organizada y persona]izada. Los formularios se construyen como una colección de elementos de diseño individuales denominados controles u objetos de control. Existen muchos tipos de controles, como cuadros de texto para introducir y editar datos, etiquetas para especificar los nombres de los campos y botones de comando para iniciar algún tipo de acción del usuario. Los controles pueden añadirse y eliminarse fácilmente de los formularios. Además, Office Access proporciona un asistente de controles (Control Wizard) para ayudar al usuario a añadir controles a un formulario. Los formularios están divididos en una serie de secciones, siendo las tres principales las siguientes: • • •
Cabecera del formulario. Determina lo que se visualizará en la parte superior de cada formulario, como por ejemplo un título. Detalle. Esta sección muestra usualmente una serie de campos de un registro. Pie del formulario. ejemplo un total.
Determina lo que se mostrará en la parte inferior de cada formulario, como por
Los formularios también pueden contener otros formularios, en cuyo caso estos últimos se denominan subformularios. Por ejemplo, puede que queramos mostrar los detalles relativos a una sucursal (e] formulario
216
Sistemas de bases de datos
Prívate Sub Form_BeforeUpdate(Cancel As Integer) Dim MyDB As Database Dim MySet As Recordset
Nombre del campo en el formulario
'Definir consultaAspara seleccionar todos los registros para el empleado especificado' Dim MyQuery String
j
MyQuery = "SELECT sta fINo FROM PropertyForRent WHERE stafINo = ,,, + stafINoField + ",,, 'Abrir la base de datos y ejecutar la consulta' Set MyDB = DBEngine.Workspaces(O).Databases(O) Set MySet = MyDB.OpenRecordset(MyQuery) 'Comprobar si se ha devuelto algún registro y desplazarse al final del archivo para permitir' 'configurar correctamente la propiedad RecordCount' If (NOT MySet.EOF) Then MySet.MoveLast If (MySet.RecordCount = 100) Then
'Si actualmente IDO,no puede gestionar más'
MsgBox "El empleado gestiona actualmente IDOinmuebles" Me.Undo End If End If MySet.Close MyDB.Close End Sub
Figura 8.5.
Código VBA para comprobar que un empleado no está gestionando más de 100 inmuebles en ningún momento.
maestro) y los detalles de todos los empleados que trabajan en la misma (el subformulario). Normalmente, se utilizan subformularios cuando existe una relación entre dos tablas (en este ejemplo, tenemos una relación uno a muchos Branch Tiene Staff, ya que cada sucursal tiene una serie de empleados). Los formularios tienen tres vistas distintas: la vista de diseño (Design View), la vista de formulario (Form View) y la vista de hoja de datos (Datasheet View). La Figura 8.6 muestra la construcción de un formulario
Toolbox
x
•.
Regla para alinear los controles Sección del encabezado
~ AIl abl
U~
@
del formulario para mostrar el título
El:]
¡;¡:t;l
00~~
Los controles se colocan en la sección de detalle, que sirve para mostrar la información de los registros
Sección de pie del formulario, que en este caso no se utiliza
Figura 8.6.
Ejemplo de formulario en la ventana de diseño, con la barra de herramientas
adyacente.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
217
(a)
Po NW106EU 8119QX 8899 'lNZ SW14EH AB23SU
(b)
Figura 8.7.
Ejemplo de formulario para las sucursales:
(a) vista de hoja de datos; (b) vista de formulario.
en la vista de diseño para mostrar los detalles de las sucursales; la caja de herramientas adyacente proporciona acceso a los controles que pueden añadirse al formulario. En la vista de hoja de datos, pueden verse múltiples registros con la disposición convencional de filas y columnas y, en la vista de formulario, lo que se suele hacer es mostrar los registros normalmente de uno en uno. La Figura 8.7 muestra un ejemplo del formulario para sucursales en la vista de hoja de datos y en la vista de formulario. Office Access permite al usuario experimentado crear formularios partiendo de cero. Sin embargo, también proporciona un asistente de formularios (Form Wizard) que lleva al usuario a través de una serie de páginas interactivas para determinar: •
la tabla o consulta en la que hay que basar el formulario;
•
los campos que hay que mostrar en el formulario;
•
la disposición en el formulario (en columnas, en tabla, en hoja de datos o justificado);
• •
el estilo del formulario, basado en una serie de opciones predefinidas; el título del formulario.
8.1.7 Informes Los informes de Microsoft Office Access son un tipo especial de formulario continuo diseñado específicamente para impresión, en lugar de para su visualización en una ventana. Como tal, un informe sólo tiene acceso de lectura a las tablas base subyacentes. Entre otras cosas, los informes de Office Access permiten al usuario. • ordenar registros; • •
agrupar registros; calcular información de resumen;
•
controlar la disposición y apariencia globales del informe.
218
Sistemas de bases de datos
Al igual que con los formularios, la vista de diseño para los informes está dividida en una serie de secciones, las principales de las cuales son: •
Cabecera del informe. Similar a la sección de cabecera de un formulario, determina lo que se mostrará al principio del informe, como por ejemplo un título.
•
Cabecera de página. Determina lo que se mostrará en la parte superior de cada página del informe, como por ejemplo los encabezados de columnas.
•
Detalle. Constituye el cuerpo principal del informe, por ejemplo los detalles de cada registro.
•
Pie de página. Determina lo que se mostrará en la parte inferior de cada página, como por ejemplo el número de página.
•
Pie del informe. Determina lo que se mostrará al final del informe, como por ejemplo una serie de sumas o valores promedio que resuman la información contenida en el cuerpo del informe.
También resulta posible partir el cuerpo del informe en una serie de grupos basándose en registros que compartan un valor común, y calcular subtotales para cada grupo. En este caso, el informe contendrá dos secciones adicionales: •
Cabecera de grupo. Determina lo que se mostrará al principio de cada grupo, como por ejemplo el nombre del campo utilizado para agrupar los datos.
•
Pie de grupo. Determina lo que se mostrará al final de cada grupo, como por ejemplo un subtotal para el grupo.
Los informes no tienen una vista de hoja de datos, sino sólo una vista de diseño, una vista de previsualización de impresión (Print Preview) y una vista de previsualización del diseño (Layout Preview). La Figura 8.8 muestra la construcción de un infonne en la vista de diseño para mostrar los detalles relativos a los inmuebles en alquiler. La Figura 8.9 muestra un ejemplo de informe en la vista Print Preview. Layout Preview es similar a Print Preview, pero se utiliza para obtener una visualización rápida de la disposición del informe, por lo que puede que no se muestren todos los registros. Office Access permite a los usuarios experimentados crear informes partiendo de cero. Sin embargo, también proporciona un asistente de informes (Report Wizard) que lleva al usuario a través de una serie de páginas interactivas para determinar: •
la tabla o consulta en la que hay que basar el informe;
•
los campos que hay que mostrar en el informe;
•
los campos que hay que utilizar para agrupar los datos en el informe, junto con los subtotales requeridos para los grupos;
•
los campos que hay que utilizar para ordenar los datos que componen el informe;
•
la disposición fisica del informe;
• •
el estilo del informe, basándose en una serie de opciones predefinidas; el título del informe.
8. 1.8 Macros Como ya hemos explicado anteriormente, Microsoft Office Access utiliza un paradigma de programación conducida por sucesos. Office Access es capaz de reconocer ciertos sucesos, como por ejemplo: •
sucesos de ratón, que tienen lugar cada vez que se produce una acción del ratón, como presionar o hacer clic sobre un botón del ratón;
•
sucesos de teclado, que tiene lugar, por ejemplo, cuando el usuario escribe en el teclado.
•
sucesos de foco, que tienen lugar cuando un formulario o control de formulario gana o pierde el foco o cuando un formulario o informe pasa a estar activo o inactivo;
•
sucesos de datos, que tienen lugar cuando se introduce, borran o modifican datos en un formulario o control, o cuando el foco se desplaza de un registro a otro;
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
219
Regla para alinear los controles ~ Report Header
Sección de cabecera del informe para mostrar el titulo
Property FOI'Rent " ~ •
Sección de cabecera
Paga Header
de página para mostrar los encabezados de columna Sección de cabecera de grupo basada en branchNo Sección de detalle para mostrar los registros que componen el grupo Sección de pie de grupo para branchNo en la que se muestran los subtotales relativos al alquiler Sección de pie de página para mostrar la fecha y el número de página Sección de pie de informe para mostrar el alquiler total para todos los inmuebles
Figura 8.8.
,\"
--
Ejemplo del informe en la vista de diseño.
3
4 536 (350,00 (600.00 (37500 (650.00 F D (450m (400.00
Properw ForRent
PG::6 PG21 PG4 BOO7 TotalPL94 Grand Sll.mmar.~for f$1}{}'l Sll.m.m.aryfor f$1}{}3 f$I}{}S
I
Rimt (400.00 (650.00 (1,775DO
PA14 PG16
U,825.00 Brallclr No ,~ Prqperty ..~ ~ No
Type
No of Rooms
J
Figura 8.9.
Ejemplo del informe para la tabla PropertyForRent con un agrupamiento branchNo, tal como aparece en la ventana Print Preview.
basado en el campo
220
Sistemas de bases de datos
Office Access permite al usuario escribir macros y procedimientos de sucesos que se disparen cuando tenga lugar un cierto suceso. Ya hemos visto un ejemplo de procedimiento de suceso en la Sección 8.1.5. En esta sección vamos a describir brevemente las macros. Las macros resulta muy útiles para automatizar tareas repetitivas y para garantizar que estas tareas se realicen de forma coherente y completa cada vez. Una macro está compuesta por una lista de acciones que Office Access debe llevar a cabo. Algunas acciones se corresponden con comandos de menú tales como Print, Close y ApplyFilter. Otras acciones se corresponden con acciones del ratón, como por ejemplo la acción SelectObject, que selecciona un objeto de base de datos de la misma forma que se lo seleccionaría haciendo dic sobre el nombre del objeto. La mayoría de las acciones requieren información adicional en forma de argumentos de acción para determinar cómo debe funcionar la acción. Por ejemplo, para utilizar la acción SetValue, que configura el valor de un campo, controlo propiedad en un formulario o informe, necesitamos especificar el elemento que hay que configurar y una expresión que represente el valor para el elemento especificado. De forma similar, para utilizar la acción MsgBox, que muestra un recuadro de mensaje emergente, necesitamos especificar el texto que debe aparecer en el recuadro de mensaje. La Figura 8.10 muestra un ejemplo de macro que puede llamarse cuando un usuario intente añadir un nuevo registro de inmueble en alquiler a la base de datos. La macro impone la restricción de negocio de que un empleado no puede gestionar más de 100 inmuebles al mismo tiempo, que anteriormente mostramos cómo implementar utilizando un procedimiento de suceso escrito en VBA (véase la Figura 8.5). En este ejemplo, la macro comprueba si el empleado especificado en el formulario PropertyForRent (Forms!PropertyForRent!staftNo) está gestionando actualmente menos de 100 inmuebles. Si es así, la macro utiliza la acción RunCommy con el argumento Save (para guardar el nuevo registro) y luego emplea la acción StopMacro para detenerse. En caso contrario, la macro utiliza la acción MsgBox para mostrar un mensaje de error y usa la macro CanceLEvent para cancelar la adición del nuevo registro. Este ejemplo también ilustra: •
la utilización de la función DCOUNT para comprobar SELECT COUNT(*);
la restricción
en lugar de una instrucción
•
la utilización de puntos suspensivos ( ... ) en la columna Condition para ejecutar una serie de acciones asociadas con una condición.
En este caso, las acciones SetWarnings, RunCommy y StopMacro son invocadas si la condición DCOUNT("''',
"PropertyForRent",
"[staffNo] = Forms!PropertyForRent!staffNo")
<100
se evalúa como cierta; en caso contrario, se invocan las acciones MsgBox y CanceLEvent.
a me.ssage box contaíníng a or informational message, A comlílon use Í$ a appears when a vahdatíon fails. Fl for help on thís adion.
Figura 8.10.
Macro para comprobar si un empleado está gestionando actualmente menos de 100 inmuebles.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
221
8.1.9 Dependencias entre objetos Microsoft Office Access ahora permite visualizar las dependencias entre objetos de la base de datos (tablas, consultas, formularios e informes). Esto puede resultar particularmente útil para identificar objetos que ya no sean necesarios o para mantener la coherencia después de haber modificado un objeto. Por ejemplo, si añadimos un nuevo campo a la tabla Branch, podemos utilizar el panel de tareas de dependencias entre objetos (Object Dependencies) mostrado en la Figura 8.11 para identificar qué consultas, formularios e informes pueden necesitar ser modificados con el fin de incluir el campo adicional. También se puede enumerar. los objetos que estén siendo utilizados por otro objeto seleccionado. y X
Table: Branch Objects that depend o.n me Objects that 1 depend on
q:t t:!J
~
PropertyForRent
El Quedes
ffl¡il
Branch-PFR
El Forms
l±Jéi) l±léi)
Branch and Property
Form
Branch Form
El Reports l±J
Figura 8.11.
8.2
Branch Report
Panel de tareas de dependencias entre objetos que muestra las dependencias para la tabla Branch.
Oracle9i
Oracle Corporation es el suministrador de software de gestión de información líder en el mundo, y la segunda compañía independiente de software más grande del mundo. Con unos ingresos anuales de unos 10.000 millones de dólares, la empresa ofrece sus productos de bases de datos, de herramientas y de aplicaciones, junto con servicios relacionados, en más de 145 países de los cinco continentes. Oracle es el SGBDR multiusuario más vendido y las soluciones Oracle son utilizadas por el 98% de las empresas de la lista Fortune 100 Oracle Corporation, 2003. El conjunto integrado de aplicaciones de negocio de Oracle, Oracle E-Business Suite, cubre los campos de inteligencia empresarial, financiero (cobros, pagos y contabilidad general), recursos humanos, compras, fabricación, marketing, proyectos, ventas, servicios, gestión de activos empresariales, realización de pedidos, desarrollo de productos y tesorería. Oracle ha sufrido numerosas revisiones desde su primer lanzamiento al mercado a finales de la década de 1970, pero en 1997 fue presentado Oracle8, que posee amplias capacidades objeto-relacionales y unas mejores características de prestaciones y escalabilidad. En 1999 se lanzó al mercado Oralce8i con funcionalidades añadidas que soportan la implantación a través de Internet y en 2001 se presento Oracle9i con todavía más funciones dirigidas a los mercados de e-Business. Hay tres productos principales en la familia Oracle9i, como se muestra en la Tabla 8.2.
222
Sistemas de bases de datos Tabla 8.2.
Familia de productos Oracle9i.
Producto
Descripción
Oracle9i Styard Edition
Oracle para entomos OLTP (Online Transaction Processing, procesamiento de transacciones en línea) de bajo y medio volumen.
Oracle9i Enterprise Edition
Oracle para grandes números de usuarios o grandes tamaños de base de datos, con características avanzadas de gestión, ampliabilidad y prestaciones para entornos OLTB de misión crítica, para aplicaciones de almacén de datos con grandes volúmenes de consulta y para aplicaciones Internet que presenten grandes requisitos de procesamiento.
Oracle9i Personal Edition
Versión monousuario de Oracle, normalmente para el desarrollo de aplicaciones que posteriormente se implanten con Oracle9i Styard/Enterprise Edition.
Dentro de esta familia, Oracle ofrece una serie de acciones y productos avanzados, como: •
Oracle Real Application Clusters. A medida que se incrementa la demanda de prestaciones y que continúan creciendo los volúmenes de datos, se está haciendo más común el uso de servidores de base de datos con múltiples procesadores, lo que se denomina máquinas de multiprocesamiento simétrico (SMP, symmetric multiprocessing). La utilización de múltiples procesadores y discos reduce el tiempo necesario para completar una determinada tarea y al mismo tiempo proporciona una mayor disponibilidad y escalabilidad. Oracle Real Application Clusters soporta el paralelismo dentro de un único servidor SMP, así como entre múltiples nodos.
•
Oracle9i Application Server (Oracle9iAS). Proporciona un modo de implementar el nivel intermedio de una arquitectura de tres niveles para arquitecturas basadas en la Web. El primer nivel es un explorador web y el tercero es un servidor de base de datos. Hablaremos de Oracle9i Application Server con más detalle en el Capítulo 29.
•
Oracle9iAS Portal. Una herramienta basada en HTML para desarrollar aplicaciones para la Web y sitios web con contenido dinámico.
•
iFS. Incluido ahora en Oracle9iAS, el sistema de archivos Internet de Oracle (iFS, Internet File System) hace posible tratar una base de datos Oracle9i como si fuera una unidad de red compartida, permitiendo a los usuarios almacenar y extraer archivos gestionados por la base de datos como si fueran archivos gestionados por un servidor de archivos.
•
Soporte Java. Oracle ha integrado una máquina virtual Java segura dentro del servidor de base de datos Oracle9i. La máquina virtual Java (JVM, Java Virtual Machine) de Oracle soporta disparadores y procedimientos almacenados Java, métodos lava, objetos lava, componentes EJB (Enterprise JavaBeans), Servlets Java y páginas JavaServer (JSP). También soporta el protocolo IIOP (Internet Inter-Object Protocol, protocolo inter-objetos para Internet) y el protocolo HTTP (HyperText Transfer Protocol, protocolo de transferencia de hipertexto). Oracle proporciona la herramienta JDeveloper para ayudar a desarrollar aplicaciones lava básicas. Hablaremos del soporte Java con más detalle en el Capítulo 29.
•
Soporte XML. Oracle incluye una serie de características para soportar el lenguaje XML. El kit de desarrollo XML (XDK, XML Development Kit) permite a los desarrolladores enviar, recibir e interpretar datos XML desde aplicaciones escritas en Java, C, C++ y PL/SQL. XML Class Generator crea clases lava/C++ a partir de definiciones XML Schema. La utilidad XML SQL soporta la lectura y escritura de datos XML hacia o desde la base de datos utilizando SQL (mediante el paquete DBMS-XMLGEN). Oracle9i también incluye el nuevo tipo de datos XMLType, que permite almacenar un documento XML en una columna LOB de caracteres (véase la Tabla 8.3), con funciones predefinidas para extraer nodo s individuales del documento y para construir índices sobre cualquier nodo del documento. Hablaremos de XML en el Capítulo 30.
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
223
•
interMEDIA. Permite a Oracle9i gestionar texto, documento, imágenes, audio, vídeo y datos de localización. Soporta diversas interface s de clientes web, así como diversas herramientas de desarrollo web, servidores web y servidores de flujo multimedia.
•
Visual Information Retrieval (extracción visual de información). Soporta consultas basadas en el contenido utilizando los atributos visuales de una imagen, como el color, la estructura y la textura.
•
Time Series (series temporales). Permite almacenar datos de marcas temporales en la base de datos. Incluye funciones de calendario y funciones de análisis temporal, como por ejemplo cálculos de medias móviles.
•
Spatial (opción espacial). Optimiza la extracción y visualización de datos relacionados con información espacial. Características de base de datos distribuida. Permite distribuir los datos entre una serie de servidores de base de datos. Los usuarios pueden consultar y actualizar los datos como si estuvieran en una base de datos común. Hablaremos de los SGBD distribuidos y examinaremos las funciones de distribución de Oracle en los Capítulos 22 y 23.
•
•
Seguridad avanzada. Se utiliza en los entornos distribuidos para proporcionar un acceso y una transmisión seguros de los datos. Incluye funciones de cifrado de datos en red utilizando el algoritmo DES o el algoritmo RC4 de RSA Data Security; incluye también comprobaciones de integridad de los datos en red, mecanismos mejorados de autenticación y certificados digitales (véase el Capítulo 19).
•
Almacenes de datos. Proporcionan herramientas que soportan la extracción, transformación y carga de orígenes de datos corporativos en una única base de datos, y herramientas que pueden usarse posteriormente para analizar estos datos de cara a la toma de decisiones estratégicas. Hablaremos de los almacenes de datos y examinaremos las funciones de almacén de datos de Oracle en los Capítulos 31 y 32.
•
Oracle Internet Developer Sude. Un conjunto de herramientas para ayudar a los desarrolladores a construir aplicaciones sofisticadas de base de datos. Nos ocuparemos de este conjunto de herramientas en la Sección 8.2.8.
8.2.1 Objetos El usuario interactúa con Oracle y desarrolla bases de datos utilizando una serie de objetos, los principales de los cuales son: •
Tablas. Las tablas base que forman la base de datos. Utilizando la terminología de Oracle, una tabla está organizada en columnas y filas. Una o más tablas se almacenan dentro de un espacio de tablas (véase la Sección 8.2.2). Oracle también soporta tablas temporales, que sólo existen mientras dura una transacción o sesión.
•
Objetos. Los tipos de objetos proporcionan una forma de ampliar el sistema de tipos de datos relacionales de Oracle. Como hemos visto en la Sección 6.1, SQL soporta tres tipos de datos principales: caracteres, números y fechas. Los tipos de objetos permiten al usuario definir nuevos tipos de datos y usarlos como tipos de datos relacionales normales. Dejaremos la explicación de las características objeto-relacionales de Oracle para el Capítulo 28.
•
Clústeres. Un clúster es un conjunto de tablas que se almacenan fisicamente juntas, como una única tabla que comparte una serie de columnas comunes. Si los datos de dos o más tablas se extraen frecuentemente juntos basándose en los datos de la columna común, la utilización de un clúster permite mejorar grandemente la eficiencia. Aunque formen parte del mismo clúster, puede continuar refiriéndose a las tablas de forma independiente. Debido a la estructura del clúster, los datos relacionados requieren mucho menos procesamiento de entrada/salida (E/S) si se accede a ellos simultáneamente. En el Apéndice C se analiza el tema de los clústeres y se proporcionan directrices relativas a su uso.
•
Índice. Un índice es una estructura que permite acelerar el acceso a las filas de una tabla basándose en los valores de una o más columnas. Oracle soporta la existencia de tablas de un solo índice, en las que
224
Sistemas de bases de datos
los datos y el índice se almacenan juntos. En el Apéndice C se analiza el tema de los índices y en el Paso 5.3 del Capítulo 17 se proporcionan directrices relativas a cuándo crear índices. •
Vistas. Una vista es una tabla virtual que no existe necesariamente en la base de datos pero que puede ser generada bajo solicitud de un usuario concreto, en el propio momento de la solicitud (véase la Sección 6.4)
•
Sinónimos. Se trata de nombres alternativos para los objetos de la base de datos.
•
Secuencias. El generador de secuencias de Oracle se utiliza para generar automáticamente una secuencia unívoca de números en la memoria caché. El generador de secuencias evita que el usuario tenga que crear las secuencias, por ejemplo bloqueando la fila que tiene el último valor de la secuencia, generando un nuevo valor y luego desbloqueando la fila.
•
Funciones almacenadas. Se trata de una serie de instrucciones SQL o PL/SQL que se utilizan conjuntamente para ejecutar una función concreta y que se almacenan en la base de datos. PL/SQL es la extensión procedimental de SQL desarrollada por Oracle.
•
Procedimientos almacenados. Los procedimientos y las funciones son idénticos, salvo porque las funciones siempre devuelven un valor (los procedimientos no). Procesando el código SQL del servidor de base de datos, el número de instrucciones enviadas a través de la red y devueltas por las instrucciones SQL se reduce.
•
Paquetes. Se trata de colecciones de procedimientos, funciones, variables e instrucciones SQL que se agrupan y almacenan como una única unidad de programa en la base de datos.
•
Disparadores. Los disparadores son fragmentos de código almacenados en la base de datos y que se invocan (disparan) debido a sucesos que tienen lugar en la base de datos.
Antes de analizar algunos de estos objetos con más detalle, vamos primero a examinar la arquitectura de Oracle.
8.2.2 Arquitectura de Oracle Oracle está basado en la arquitectura cliente-servidor que ya hemos examinado en la Sección 2.6.3. El servidor de Oracle está compuesto de la base de datos (los datos en bruto, incluyendo los archivos registro y control) y la instancia (los procesos y la memoria del sistema servidor que proporciona el acceso a la base de datos). Cada instancia sólo puede conectarse a una base de datos. La base de datos está compuesta de una estructura lógica como puede ser el esquema de la base de datos, y de una estructura fisica que contiene los archivos que forman una base de datos Oracle. Veamos ahora con más detalle la estructura lógica y física de la base de datos y los procesos del sistema.
Estructura lógica de la base de datos Oracle En el nivel lógico, Oracle mantienen espacios de tablas, esquemas y bloques de datos y extensiones/segmentos. Espacios de tablas
Una base de datos Oracle se divide en unidades lógicas de almacenamiento denominadas espacios de tablas. Un espacio de tablas se utiliza para agrupar estructuras lógicas relacionadas. Por ejemplo, normalmente se emplean espacios de tablas para agrupar todos los objetos de aplicación, con el fin de simplificar algunas operaciones administrativas. Cada base de datos Oracle contiene un espacio de tablas denominado SYSTEM, que se crea automáticamente en el momento de crear la base de datos. El espacio de tablas SYSTEM siempre contiene las tablas del catálogo del sistema (denominado diccionario de datos) en Oracle para toda la base de datos. Una base de datos de mediano tamaño puede que sólo necesite el espacio de tablas SYSTEM; sin embargo, se recomienda que se cree al menos un espacio de tablas adicional para almacenar los datos del usuario de forma separada del diccionario de datos, reduciendo de ese modo la contienda entre los objetos de diccionario de los
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
225
objetos del esquema a la hora de acceder a los archivos de datos (véase la Figura 16.2 en el Capítulo 16). La Figura 8.12 ilustra una base de datos Oracle compuesta por el espacio de tablas SYSTEM y un espacio de tablas USER DATA. Puede crearse un nuevo espacio de tablas utilizando el comando CREATE TABLESPACE; por ejemplo: CREATE TABLESPACE user data DATAFILE 'DATA3.0RA' SIZE lOOK EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO; Posteriormente, puede asociarse una tabla con un espacio de tablas específico utilizando las instrucciones CREATE TABLE o ALTER TABLE; por ejemplo: CREATE TABLE PropertyForRent TABLESPACE user_data;
(propertyNo
VARCHAR2(5) NOT NULL, ...)
Si no se especifica ningún espacio de tablas a la hora de crear una nueva tabla, se usará el espacio de tablas predeterminado que se hubiera asociado con el usuario en el momento de crear la cuenta de usuario. En la Sección 18.4 veremos cómo especificar este espacio de tablas predeterminado. Usuarios, esquemas y objetos del esquema
Un usuario (algunas veces denominado nombre de usuario) es un nombre definido en la base de datos que puede conectarse a los objetos de la misma y acceder a ellos. Un esquema es una colección nominada de objetos de esquema, como tablas, vistas, índices, clústeres y procedimientos, los cuales están asociados con un usuario concreto. Los conceptos de esquema y de usuario ayudan a los administradores de la base de datos a gestionar las cuestiones de seguridad.
Base de datos Oracle
Archivos de datos
DATA2.0RA 1 Mb
DATA3.0RA 100 Mb
SYSTEM
, ,,
':J~_~~=-_~~!~ \, , ,
I I
I c1úster índice 1
índice
Figura 8.12.
1
I I
B B
,
Relación entre una base de datos Oracle, los espacios de tablas y los archivos de datos.
,
226
Sistemas de bases de datos
Para acceder a una base de datos, un usuario debe ejecutar una aplicación de base de datos (como Oracle Forms o SQL *Plus) y conectarse utilizando un nombre de usuario que esté definido en la base de datos. Cuando se crea una usuario de base de datos, se crea también un esquema correspondiente del mismo nombre para dicho usuario. De manera predeterminada, una vez que un usuario se conecta a una base de datos, tiene acceso a todos los objetos contenidos en el correspondiente esquema. Puesto que un usuario sólo está asociado con el esquema del mismo nombre, los términos 'usuario' y 'esquema' se usan en ocasiones de forma intercambiable. (Observe que no existe ninguna relación entre un espacio de tablas y un esquema: los objetos del mismo esquema pueden estar en diferentes espacios de tablas y un mismo espacio de tablas puede almacenar objetos de diferentes esquemas). Bloques de datos. extensiones y segmentos
El bloque de datos es la unidad de almacenamiento de menor tamaño que Oracle puede utilizar o asignar. Un bloque de datos se corresponde con un número específico de bytes de espacio físico en disco. El tamaño del bloque de datos puede configurarse para cada base de datos Oracle en el momento de su creación. Este tamaño del bloque de datos debe ser un múltiplo del tamaño de bloque del sistema operativo (dentro del límite máximo que tenga el sistema) para evitar operaciones innecesarias de E/S. Un bloque de datos tiene la siguiente estructura: •
Cabecera. Contiene información general como la dirección del bloque y el tipo de segmento.
•
Directorio de tablas. Contiene información acerca de las tablas que contienen datos dentro de ese bloque de datos.
•
Directorio de filas. Contiene información acerca de las filas contenidas en el bloque de datos.
•
Datos de las filas. Contiene las filas de datos de las tablas. Una misma fila puede estar dividida entre varios bloques de datos.
•
Espacio libre. Asignado para la inserción de nuevas filas y para las actualizaciones de filas existentes que requieren espacio adicional. A partir de Oracle8i, Oracle puede gestionar de forma automática el espacio libre, aunque existe una opción para hacerla de forma manual.
En el Apéndice G se muestra cómo estimar el tamaño de una tabla Oracle utilizando estos componentes. El siguiente nivel de espacio lógico en la base de datos se denomina extensión. Una extensión es un número específico de bloques de datos contiguos que se asigna para almacenar un tipo específico de información. El nivel situado por encima de las extensiones se denomina segmento. Un segmento es un conjunto de extensiones asignado a una cierta estructura lógica. Por ejemplo, los datos de cada tabla se almacenan en su propio segmento de datos, mientras que los datos de cada índice se almacenan en su propio segmento de índice. La Figura 8.13 demuestra la relación entre bloques de datos, extensiones y segmentos. Oracle asigna dinámicamente el espacio cuando se llenan las extensiones existentes de un segmento. Puesto que las extensiones se asignan según sea necesario, las extensiones de un segmento pueden o no estar contiguas en el disco.
Estructura física de la base de datos Oracle Las principales estructuras fisicas de la base de datos Oracle son los archivos de datos, los archivos del registro de rehacer y los archivos de control. Archivos de datos
Cada base de datos Oracle tiene uno o más archivos de datos físicos. Los datos de las estructuras lógicas de la base de datos (como tablas e índices) se almacenan físicamente en estos archivos de datos. Como se muestra en la Figura 8.12, un espacio de tablas está compuesto de uno o más archivos de datos. La base de datos Oracle más simple tendría un único espacio de tablas y un único archivo de datos, mientras que otra base de datos más compleja podría tener cuatro espacios de tablas, cada uno de ellos compuesto por dos archivos de datos, lo que nos daría un total de ocho archivos de datos.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
e
Bloque'(jjde ~ datos de 2K
2K
~
co
-
,o ""O eal X
2K 2K 2K I 2K 2KT2KT2~2K 2K Segmento de IExtensión de
24K I
~
227
32K
2K 2K Extensión de 8K formada por 4 bloques de datos
I 2K
Segmento de 32K formado por una extensión de 8K y otra extensión de 24K
Figura 8.13.
Relación entre los bloques de datos, las extensiones
y los segmentos en Oracle.
Archivos del registro de rehacer
Toda base de datos Oracle tiene un conjunto de dos o más archivos del registro de rehacer que registran todos los cambios realizados en los datos, para propósitos de recuperación. Si algún tipo de fallo impidiera escribir de forma permanente en los archivos de datos los datos modificados, dichos cambios pueden obtenerse a partir del registro de rehacer, lo que evita que se pierda el trabajo realizado. Hablaremos con detalle del tema de la recuperación en la Sección 20.3. Archivos de control
Toda base de archivos Oracle tiene un archivo de control que contiene una lista de todos los demás archivos que forman la base de datos, como por ejemplo los archivos de datos y los archivos del registro de rehacer. Para disponer de una mayor protección, se recomienda multiplexar el archivo de control (escribir múltiples copias en múltiples dispositivos). De forma similar, también puede ser aconsejable multiplexar los archivos del registro de rehacer.
La instancia Oracle La instancia Oracle está compuesta por los procesos Oracle y la memoria compartida necesaria para acceder a la información contenida en la base de datos. La instancia está formada por los procesos en segundo plano Oracle, por los procesos de usuario y por la memoria compartida usada por estos procesos, como se ilustra en la Figura 8.14. Entre otras cosas, Oracle utiliza la memoria compartida para almacenar en caché los datos e índices, así como para almacenar el código del programa compartido. La memoria compartida se descompone en varias estructuras de memoria siendo las principales el SGA (System G]obal Area, área global del sistema) y e] PGA (Program Global Area, área global de programa) . •
Area global del sistema. El SGA es una área de memoria compartida que se utiliza para almacenar datos e información de control de una instancia Oracle. El SGA se asigna a] arrancar la instancia Oracle y se desasigna cuando ésta se detiene. La información del SGA está compuesta de las siguientes estructuras de memoria, cada una de las cuales tiene un tamaño fijo y se crea durante el arranque de la instancia: •
Caché de búfer de la base de datos. Contiene los bloques de datos más recientemente utilizados de la base de datos. Estos bloques pueden contener datos modificados que todavía no hayan sido escritos en disco (bloques sucios), bloques que no hayan sido modificados o bloques que hayan sido escritos en disco desde la modificación (bloques limpios). Al almacenar los bloques más recientemente utilizados, los búferes más activos permanecen en memoria para reducir las opera-
228
Sistemas de bases de datos
~
! !EJ ~
~
del sistema (SGA)
Caché de búfer en la base de datos
Proceso de seguridad compartido
Búfer del registro de rehacer
Proceso de servidor dedicado
Leyenda: LMS
RECO PMON SMON
CKPT ARCO DBWO
LGWR
Lock manager server (servidor de gestión de bloqueos) Recoverer process (proceso recuperador) Process monitor (monitor de procesos) System monitor (monitor del sistema) Checkpoint (punto de control) Archiver (archivador) Database writer (escritor de base de datos) Log writer (escritor de registro)
Figura 8.14.
La arquitectura
Archivos de control
Archivos del registro de rehacer
Oracle (extraída de la documentación
de Oracle).
ciones de E/S y mejorar las prestaciones. Hablaremos de las políticas de gestión de búferes en la Sección 20.3.2. •
Búfer del registro de rehacer. Contiene las entradas de los archivos de registro de rehacer, que se utilizan para propósitos de recuperación (véase la Sección 20.3). El proceso de segundo plano LGWR escribe el búfer del registro de rehacer en el archivo activo de registro de rehacer en línea situado en el disco.
Capítulo 8 Bases de datos comerciales:
•
Office Access y Oracle
229
Area compartida. Contiene las estructuras de memoria compartida, como las áreas SQL compartidas en la caché de biblioteca y la información interna del diccionario de datos. Las áreas SQL compartidas contienen árboles de análisis sintáctico y planes de ejecución para las consultas SQL. Si varias aplicaciones ejecutan la misma instrucción SQL, pueden acceder al área SQL compartida para reducir la cantidad de memoria necesaria y el tiempo de procesamiento empleado para el análisis sintáctico y la ejecución. Hablaremos del procesamiento de las consultas en el Capítulo 21.
•
Area global de programa. El PGA es un área compartida que se utiliza para almacenar datos e información de control de los procesos de servidor Oracle. El tamaño y el contenido del PGA dependen de las opciones de servidor Oracle instaladas.
•
Procesos de usuario. Cada proceso de usuario representa la conexión de un usuario al servidor Oracle (por ejemplo, a través de SQL *Plus o de una aplicación Oracle Forms). El proceso de usuario gestiona la entrada de usuario, se comunica con el proceso de servidor Oracle, muestra la información solicitada por el usuario y, en caso necesario, procesa esta información para dotada de un formato más útil.
•
Procesos de Oracle. Los procesos de (servidor) Oracle realizan una serie de funciones para los usuarios. Podemos clasificar los procesos Oracle en dos grupos: procesos de servidor (que gestionan las solicitudes procedentes de los procesos de usuario conectados) y procesos de segundo plano (que realizan la E/S asíncrona y proporcionan mecanismos de paralelismo para mejorar las prestaciones y la fiabilidad). Si consultamos la Figura 8.14, vemos que existen los siguientes procesos de segundo plano: •
Escritor de base de datos (DBWR). El proceso DBWR es responsable de escribir los bloques modificados (sucio) desde la caché de búfer del SGA a los archivos de datos situados en disco. Una instancia Oracle puede tener hasta diez procesos DBWR, denominados DBWO a DBW9, para gestionar la E/S hacia múltiples archivos de datos. Oracle emplea una técnica denominada registro anticipado de escritura (véase la Sección 20.6.4), que significa que el proceso DBWR realiza escrituras por lotes cada vez que es necesario vaciar los búferes, no necesariamente en los instantes en que se confirma cada transacción.
•
Escritor de registro (LGWR). El proceso LGWR es responsable de escribir los datos desde el búfer de registro al archivo de rehacer.
•
Punto de control (CKPT). Un punto de control es un suceso en el que todos los búferes modificados de la base de datos se escriben en los archivos de datos, encargándose de esta tarea el DBWR (véase la Sección 20.3.3). El proceso CKPT es responsable de informar al proceso DBWR de que debe realizar un punto de control y actualizar todos los archivos de datos y archivos de control de la base de datos para que sean coherentes con el punto de control más reciente. El proceso CKPT es opcional y, si se lo omite, sus responsabilidades son asumidas por el proceso LGWR.
•
Monitor del sistema (SMON). El proceso SMON es responsable de efectuar la recuperación de un error cuando se arranca la instancia a continuación de algún tipo de fallo. Esto incluye recuperar las transacciones que se hayan interrumpido debido al fallo del sistema. SMON también desfragmenta la base de datos, combinando las extensiones libres que haya dentro de cada archivo de datos.
•
Monitor de procesos (PMON). El proceso PMON es responsable de controlar los procesos de usuario que accedan a la base de datos y recuperados después de producirse algún error. Esto incluye liberar cualesquiera recursos que hayan quedado bloqueados (como por ejemplo memoria) y liberar los bloqueos que posea el proceso que ha fallado.
•
Archivador (ARCH). El proceso ARCH es responsable de copiar los archivos de registro de rehacer en línea en el soporte de almacenamiento de archivo cuando dichos registros se llenan. El sistema puede configurarse para ejecutar hasta diez procesos ARCH, denominados ARCO a ARC9. Los procesos de archivado adicionales son arrancados automáticamente por el proceso LWGR cuando la carga de procesamiento así lo requiere.
230
Sistemas de bases de datos •
Recuperador (RECO). El proceso RECO es responsable de efectuar las tareas de limpieza requeridas por las transacciones distribuidas que hayan fallado o que hayan sido suspendidas (véase la Sección 23.4).
•
Despachadores (Dnnn). Los procesos Dnnn son responsables de encaminar las solicitudes de los procesos de usuario hacia los procesos de servidor compartidos disponibles, y devolver la respuesta de éstos. Los despachadores sólo están presentes cuando se utiliza la opción de servidor compartido (anteriormente denominada MTS, Multi-Threaded Server), en cuyo caso existe al menos un proceso Dnnn por cada protocolo de comunicaciones que se utilice.
•
Protocolo de gestión de bloqueos (LMS). El proceso LMS es responsable de los bloqueos inter-instancia cuando se utiliza la opción Oracle Real Application Clusters.
En las descripciones que siguen, hemos utilizado el término 'proceso' de forma genérica. Hoy en día, algunos sistemas implementan los procesos como hebras de procesamiento.
Ejemplo de interacción de estos procesos El siguiente ejemplo ilustra una configuración Oracle en la que el proceso servidor se ejecuta en una máquina y un proceso de usuario se conecta al servidor desde una máquina distinta. Oracle utiliza un mecanismo de comunicaciones denominado Oracle Net Services para permitir que procesos situados en diferentes máquinas físicas se comuniquen entre sí. Oracle Net Services soporta diversos protocolos de red, como por ejemplo TCP/IP. Los servicios de Oracle Net Services también pueden realizar traducciones de protocolos de red, permitiendo que clientes que utilizan un protocolo interactúen con un servidor de bases de datos que use un protocolo distinto. (1) La estación de trabajo del cliente ejecuta una aplicación en un proceso de usuario. La aplicación cliente trata de establecer una conexión con el servidor utilizando el controlador Oracle Net Services. (2) El servidor detecta la solicitud de conexión procedente de la aplicación y crea un proceso de servidor (dedicado) por cuenta del proceso de usuario. (3) El usuario ejecuta una instrucción SQL para cambiar una fila de una tabla y confirma la transacción. (4) El proceso de servidor recibe la instrucción y comprueba el área compartida para ver si existe un área SQL compartida que contenga una instrucción SQL idéntica. Si se encuentra un área SQL compartida, el proceso de servidor comprueba los privilegios de acceso del usuario relativos a los datos solicitados y se utiliza el área SQL compartida previamente existente para procesar la instrucción; si no se encuentra el área compartida, se asigna una nueva área compartida SQL para la instrucción, de forma que ésta pueda ser analizada sintácticamente y procesada. (5) El proceso servidor extrae los valores de datos necesarios del archivo de datos (tabla) o de los datos almacenados en el SGA. (6) El proceso servidor modifica los datos del SGA. El proceso DBWR escribe los bloques modificados permanentemente en disco si resulta eficiente hacerlo así. Una vez confirmada la transacción, el proceso LGWR registra inmediatamente la transacción en el archivo del registro de rehacer en línea. (7) El proceso servidor envía un mensaje de confirmación/fallo
a través de la red, dirigido a la aplicación.
(8) Durante este tiempo, los otros procesos de segundo plano están ejecutándose, vigilando la aparición de condiciones que requieran su intervención. Además, el servidor Oracle gestiona las transacciones de otros usuarios y evita que se produzcan contiendas entre transacciones que estén solicitando los mismos datos.
8.2.3 Definición de tablas En la Sección 6.3.2, hemos examinado la instrucción SQL CREATE TABLE. Oracle9i soporta muchas de las cláusulas CREATE TABLE del estándar SQL, de modo que podemos definir: •
claves principales, utilizando la cláusula PRIMARY KEY;
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
231
•
claves alternativas, utilizando la palabra clave UNIQUE;
• • •
valores predeterminados, utilizando la cláusula DEFAULT; atributos no nulos, utilizando la palabra clave NOT NULL; claves externas, utilizando la cláusula FOREIGN KEY;
•
otras restricciones relativas a los atributos o a la tabla, usando las cláusulas CHECK y CONSTRAINT.
Sin embargo, no existe ninguna funcionalidad que permita crear dominios, aunque Oracle9i sí que permite crear tipos definidos por el usuario, como se explica en la Sección 28.6. Además, los tipos de datos son ligeramente distintos de los del estándar SQL, como se muestra en la Tabla 8.3.
Secuencias En la sección anterior hemos mencionado que Microsoft Office Access tiene un tipo de datos autonumérico que crea un nuevo número secuencial para un valor de columna cada vez que se inserta una nueva fila. Oracle no dispone de dicho tipo de datos, pero tiene una funcionalidad similar integrada en la instrucción CREATE SEQUENCE de SQL. Por ejemplo, la instrucción: CREATE SEQUENCE appNoSeq START WITH 1 INCREMENT BY 1 CACHE 30; Tabla 8.3. Lista parcial de tipos de datos Oracle. Tipo de dato
Utilización
Tamaño
Char(tamaño)
Almacena datos de carácter de longitud fija (el tamaño predeterminado es 1).
Hasta 2000 bytes
Nchar(tamaño)
Tipos de datos Unicode que almacenan caracteres Unicode. Igual que el tipo de datos char, salvo porque la longitud máxima está determinada por el conjunto de caracteres de la base de datos (por ejemplo, inglés americano, europeo del este o coreano)
Hasta 4000 bytes
varchar2( tamaño)
Almacena datos de carácter de longitud variable.
nvarchar2(tamaño)
Igual que varchar2, con la misma observación que para el tipo de datos nchar.
Varchar
Actualmente igual que char. Sin embargo, se recomienda la utilización de varchar2, ya que varchar puede convertirse en un tipo de datos independiente con una semántica de comparación distinta en alguna versión posterior de la base de datos ..
number(l, d)
Almacena números en coma fija o coma flotante, donde I representa la longitud y d representa el número de dígitos decimales. Por ejemplo, number(5, 2) podría contener números hasta 999,99.
decimal(l, d), dec(l, d) o numeric(l, d)
Igual que number. Se proporciona por compatibilidad SQL.
integer, int o smallint
Se proporciona por compatibilidad en number(38).
Date
Almacena fechas desde el1 enero 4712 AC hasta el31 diciembre 4712 DC.
Hasta 4 gigabytes
Blob
Un objeto binario de gran tamaño.
Hasta 4 gigabytes
Clob
Un objeto de caracteres de gran tamaño.
Hasta 2000 bytes
raw(tamaño)
Datos binarios en bruto, como por ejemplo una secuencia de caracteres gráficos o una imagen digitalizada.
Hasta 2000 bytes
±1,OE-130 ... ±9,99E125 (hasta 38 dígitos significativos)
con el estándar
con el estándar SQL. Se convierte
./
232
Sistemas de bases de datos
crea una secuencia, denominada appNoSeq, que comienza con el valor inicial 1 y se incrementa en 1 cada vez. La cláusula CACHE 30 especifica que Oracle debe presagiar 30 números de secuencia y mantenerlos en memoria, para que el acceso sea más rápido. Una vez creada una secuencia, puede accederse a sus valores en las instrucciones SQL utilizando las siguientes Pseudocolumnas: •
CURRVAL Devuelve el valor actual de la secuencia .
•
NEXTV AL Incrementa la secuencia y devuelve el nuevo valor.
Por ejemplo, la instrucción SQL: INSERT INTO Appointment(appNo, aDate, aTime, clientNo) VALUES (appNoSeq.nextval, SYSDATE, '12.00', 'CR76'); inserta una nueva fila en la tabla Appointment asignando como valor para la columna appNo (el número de cita) el siguiente número disponible en la secuencia. Vamos a ilustrar ahora cómo crear la tabla PropertyForRent en Oracle, con las restricciones especificadas en el Ejemplo 6.1.
Creación de una tabla en blanco en Oracle mediante SOL *Plus Para ilustrar el proceso de creación de una tabla en blanco en Oracle, vamos a utilizar primero SQL*Plus, que es una interfaz SQL interactiva controlada mediante línea de comandos, que permite acceder a la base de datos Oracle. La Figura 8.15 muestra la creación de la tabla PropertyForRent utilizando la instrucción SQL CREATE TABLE.
Fíle
~earch
SQL*Plus: ¡Copyright
Options
Release
Help
9.2.0.1.0
(e) 1982.
Conneeted to: lpersonal Oraele9i
2002.
Release
- Produetion Oraele
on Thu Oet 2 12:34:46
Corporation.
9.2.0.1.0
All rights
2003
reserued ..
- Produetion
With the Partitioning. OLAP and Oraele JSeruer Release 9.2.0.1.0 - Produetion
Data
Mining
options
I
SQL>
I
2
3 4 5
6 7
8 9 10 11 12
nable
CREATE TABLE PropertyForRent(propertyHo UARCHAR2(5) HOT HULL. street UARCHAR2(25) HOT HULL. eity UARCHAR2(15) HOT HULL. posteode UARCHAR2(8). type CHAR DEFAULT 'F' HOT HULL. rooms SMALLIHT DEFAULT 4 HOT HULL. rent HUMBER(6.2) DEFAULT 600 HOT HULL. ownerHo UARCHAR2(5) HOT HULL. staffHo UARCHAR2(5). branehHo CHAR(4) HOT HULL. PRIMARY KEY (propertyHo). FOREIGH KEY (ownerHo) REFEREHCES PriuateOwner(ownerHo). FOREIGH KEY (staffHo) REFEREHCES Staff(staffHo). FOREIGH KEY (branehHo) REFEREHCES Braneh(branehHo»; ereated.
SQL>
Figura 8.15.
Creación de la tabla PropertyForRent utilizando la instrucción SQL CREATE TABLE de Oracle en SQL *Plus .
1
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
233
De manera predeterminada, Oracle impone las acciones de integridad referencial ON DELE TE NO ACTION y ON UPDATE NO ACTION sobre las claves externas especificadas. También permite especificar la cláusula adicional ON DELE TE CASCADE, con el fin de permitir que los borrados efectuados en la tabla padre se propaguen en cascada a la tabla hija. Sin embargo, no soporta la acción ON UPDATE CASCADE ni las acciones SET DEFAULT ni SET NULL. Si se requiere cualquiera de estas acciones, es necesario implementarlas como disparadores o procedimientos almacenados, o dentro del código de aplicación. Veremos un ejemplo de disparador utilizado para imponer este tipo de restricciones en la Sección 8.2.7.
Creación de una tabla utilizando el asistente de creación de tablas Una solución alternativa en Oracle9i consiste en utilizar el asistente de creación de tablas (Create Table Wizard) que forma parte del gestor de esquemas (Schema Manager). Utilizando una serie de formularios interactivos, el asistente de creación de tablas lleva al usuario a través del proceso de creación de cada una de las columnas, con su tipo de datos asociado, así como la definición de cualesquiera restricciones aplicables a las columnas y/o a la tabla que puedan necesitarse, y la definición de los campos clave. La Figura 8.16 muestra el formulario final del asistente de creación de tablas que se emplearía para crear la tabla PropertyForRent.
8.2.4 Definición de restricciones generales Hay varias formas de crear restricciones generales en Oracle, utilizando por ejemplo: •
SQL y las cláusulas CHECK y CONSTRAINT de las instrucciones CREA TE y ALTER TABLE;
•
funciones y procedimientos
• •
disparadores; métodos.
almacenados;
Ya hemos hablado de la primera de estas técnicas en la Sección 6.1 y vamos a dejar el tratamiento de los métodos hasta el Capítulo 28, donde hablaremos de los SGBD objeto-relacionales. Antes de ilustrar las siguientes dos soluciones, present.emos primero el lenguaje de programación procedimental de Oracle, PL/SQL.
8.2.5 PUSQL PL/SQL es una extensión procedimental de SQL diseñada por Oracle. Hay dos versiones de PL/SQL: una de ellas es parte del servidor Oracle y la otra es un motor independiente integrado en diversas herramientas Oracle. Son muy similares entre sí y tienen las mismas estructuras de programación, la misma sintaxis y los mismos mecanismos lógicos, aunque la versión de PL/SQL para las herramientas Oracle tiene algunas extensiones para ajustarse a las necesidades de cada herramienta concreta (por ejemplo, PL/SQL dispone de extensiones para Oracle Forms). PL/SQL se basa en conceptos similares a los de los lenguajes de programación modernos, como por ejemplo los conceptos de declaración de variables y constantes, estructuras de control, tratamiento de excepciones y modularización. PL/SQL es un lenguaje con estructura de bloques: los bloques pueden ser completamente independientes o estar anidados unos dentro de otros. Las unidades básicas que componen un programa PL/SQL son los procedimientos, funciones y bloques anónimos (sin nombre). Como se ilustra en la Figura 8.17, un bloque PL/SQL se compone de hasta tres partes: •
una parte opcional de declaración en la que se pueden definir y posiblemente inicializar las variables, constantes, cursores y excepciones;
•
una parte ejecutable obligatoria, en la que se manipulan las variables;
•
un parte opcional de tratamiento de excepciones, para gestionar cualesquiera excepciones que se produzcan durante la ejecución.
/
234
Sistemas de bases de datos
STREET
Clfi POS'TCODE
'E OMS
OWNERNO STAffNO BRANCHNO
tt ••.;;.~,~\:;?:<:~<,;;::~
f¡ •.
~2..¡¡;., __ PROPERfiNO ]J?M~i1r;a,:m;rn~~i1'1.~,'~~f,~r~~ii~1~~,fhT1f~'Q~:' NlIlI an
C
STREET
Clfi POSTCODE TYPE
ROOMS RENT OWNERNO STAfFNO BRANCHN(¡¡a;"'
slImmary
Figura 8.16. Creación de la tabla PropertyForRent utilizando el asistente de creación de tablas de Oracle.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
[DECLARE
235
Opcional
--- declaraciones] BEGIN
Obligatorio
instrucciones ejecutables
m
Opcional
[EXCEPTION
--- rutinas de tratamiento de excepciones] END;
Obligatorio
Figura 8.17.
Estructura general de un bloque PLlSQL.
Declaraciones Las variables y constantes deben ser declaradas antes de poder hacer referencia a las mismas en otras instrucciones, incluyendo otras instrucciones de declaración. Los tipos de variables son los que se muestran en la Tabla 8.3. Como ejemplos de declaraciones tendríamos: vStaffNo VARCHAR2(5); vRent NUMBER(6, 2) NOT NULL := 600; MAX ]ROPERTIES CONSTANT NUMBER
:= 100;
Observe que es posible declarar una variable como NOT NULL, aunque en este caso deberá asignarse un valor inicial en dicha variable. También se puede declarar una variable de forma que tenga el mismo tipo que una determinada columna de una tabla especificada, o el mismo tipo que otra variable previamente definida; para ello se utiliza el atributo %TYPE. Por ejemplo, para declarar que la variable vStaffNo debe tener el mismo tipo que la columna staffNode la tabla Staff,podríamos escribir: vStaffNo Staff.staffNo%TYPE; vStaffNol vStaffNo%TYPE; De forma similar, podemos declarar una variable para que tenga el mismo tipo que una fila completa de una tabla o vista, utilizando el atributo %ROWTYPE. En este caso, los campos del registro toman sus nombres y tipos de datos de las columnas de la tabla o vista. Por ejemplo, para declarar una variable vStaffRec que se corresponda con una fila de la tabla Staff,podríamos escribir: vStaffRec StaffUIoROWTYPE;
Asignaciones En la parte ejecutable de un bloque PL/SQL, podemos asignar las variables de dos formas distintas: utilizando la instrucción normal de asignación (:=) o como resultado de una instrucción SQL SELECT o FETCH. Por ejemplo: vStaffNo := 'SGI4'; vRent := 500; SELECT COUNT (*) INTO
X
FROM PropertyForRent WHERE staffNo = vStaffNo;
En el último caso, se asigna a la variable x el resultado de la instrucción SELECT (en este caso, igual al número de inmueble s gestionados por el empleado SG 14).
Instrucciones
de control
PL/SQL soporta los mecanismos habituales de control de flujo condicional, iterativo y secuencial: •
IF- THEN-ELSE-END
IF;
236
• •
Sistemas de bases de datos
LOOP-EXIT GOTO.
WHEN-END
LOOP; FOR-END LOOP y WHILE-END
LOOP;
Más adelante presentaremos ejemplos donde se utilizan algunas de estas estructuras.
Excepciones Una excepción es un identificador en PLlSQL que se activa durante la ejecución de un bloque, lo que hace que se termine la ejecución del cuerpo principal de acciones. Los bloques siempre terminan su ejecución si se genera una excepción, aunque la rutina de tratamiento de excepciones puede llevar a cabo algunas acciones finales. Las excepciones pueden ser generadas automáticamente por Oracle (por ejemplo, se genera la excepción NO_DATA_FOUND cuando no se extrae ninguna fila de la base de datos en una instrucción SELECT), pero también es posible generar explícitamente una excepción utilizando la instrucción RAISE. Para tratar las excepciones generadas, se especifican una serie de rutinas separadas denominadas rutinas de tratamiento de excepciones. Como hemos mencionado anteriormente, las excepciones definidas por el usuario se definen en la parte declarativa de los bloques PLlSQL. En la parte ejecutable, se realiza una comprobación para ver si se ha producido la condición de la excepción y, en caso afirmativo, se genera la excepción. La propia rutina de tratamiento de excepciones se define al final del bloque PLlSQL. En la Figura 8.18 se proporciona un ejemplo de tratamiento de excepciones. Este ejemplo también ilustra el uso del paquete DBMS _OUTPUT suministrado por Oracle, que permite generar datos de salida desde los bloques PLlSQL y subprogramas. El procedimiento puUine envía información de salida a un búfer en el SGA, información que puede visualizarse invocando el procedimiento geUne o activando la opción SERVEROUTPUT ON en SQL *Plus.
Cursores Una instrucción SELECT puede utilizarse si la consulta devuelve una fila y sólo una fila. Para tratar una consulta que pueda devolver un número arbitrario de filas (es decir, cero, una o más filas), PLlSQL utiliza cursores para poder acceder a las filas del resultado de la consulta de una en una. En la práctica, el cursar actúa DECLARE vpCount
NUMBER;
vStaffNo PropertyForRent.staffNo%TYPE:=
'SG14';
-- definir una excepción para la restricción empresarial que impide a un empleado -- gestionar más de 100 inmuebles e_too_many _properties EXCEPTION; PRAGMA EXCEPTION_lNIT( e_too_many _properties, -20000); BEGIN SELECT COUNT(*) lNTO vpCount FROM PropertyForRent WHERE staffNo = vStaffNo; IF vpCount = 100 .. generar una excepción para la restricción empresarial RAISE e_too_many_properties; ENDIF; UPDATE PropertyForRent SET staffNo = vStaffNo WHERE propertyNo
'PG4';
EXCEPTION .. tratar la excepción correspondiente a la restricción empresatial WHEN e_too_many_properties
THEN
dbms_output.puUine('EI
empleado'
11
staftNo
11
'ya gestiona 100 inmuebles');
END;
Figura 8.18.
Ejemplo de tratamiento de excepciones en PL/SQL.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
237
como un puntero que dirige hacia una fila concreta del resultado de la consulta. El cursar puede avanzar una posición para acceder a la siguiente fila. Es necesario declarar y abrir los cursores antes de utilizarlos, y también se los debe cerrar para desactivarlos una vez que no sean necesarios. Después de haber abierto el cursar, pueden extraerse una a una las filas del resultado de la consulta utilizando una instrucción FETCH, en lugar de una instrucción SELECT (en el Apéndice E veremos que SQL también puede integrarse en lenguajes de programación de alto nivel y que, en ese caso, también se utilizan cursores para tratar las consultas que puedan devolver un número arbitrario de filas). La Figura 8.19 ilustra el uso de un cursar para determinar los inmuebles gestionados por el empleado SO 14. En este caso, la consulta puede devolver un número arbitrario de filas, por lo que debe utilizarse un cursar. Los puntos más importantes que hay que observar en este ejemplo son: •
En la sección DECLARE se define el cursar
propertyCursor.
DECLARE vPropertyNo
PropertyForRent.propertyNo%TYPE;
vStreet
PropertyForRent.street%TYPE;
vCity
PropertyForRent.city%TYPE;
vPostcode
PropertyForRent.postcode%TYPE;
CURSOR propertyCursor IS SELECT propertyNo, street, city, postcode FROM PropertyForRent WHERE staftNo = 'SG 14' ORDER by propertyNo; BEGIN -- Abrir el cursor situándolo al principio de la selección y extraer en bucle cada una de las filas de la tabla de resultados OPEN propertyCursor; LOOP h
Extraer la siguiente fila de la tabla de resultados FETCH propertyCursor INTO vPropertyNo, vStreet, vCity, vPostcode; EXIT WHEN propertyCursor%NOTFOUND;
h
Mostrar los datos dbms_output.puUine('Property
number: '
dbms_output.puUine('Street: dbms_output.puUine('City:
'
11
vPropertyNo);
vStreet);
'
11
11
vCity);
IF postcode IS NOT NULL THEN dbms_output.puUine('Post
Code:
'
dbms_output.puUine('Post
Codeo
NULL');
11
vPostcode);
ELSE
ENDIF; ENDLOOP; IF propertyCursor%ISOPEN
THEN CLOSE propertyCursor END IF;
h Condición de error - imprimir el error EXCEPTION
WHEN OTHERS THEN dbms_output.put_line('Error
detected');
IF propertyCursorO/OISOPEN THEN CLOSE propertyCursor; END IF;
END;
Figura 8.19.
Utilización de cursores en PL/SQL para procesar una consulta multifila.
238 •
Sistemas de dats En la seccióndedebases instrucciones~-abre el cursar por primera vez. Entre otros efectos, esto hace que se analice sintácticamente la instrucción SELECT especificada en la declaración del CURSOR, identificando las filas que satisfacen los criterios de búsqueda (lo que se denomina el conjunto activo) y que se posicione el puntero justo antes de la primera de las filas que componen el conjunto activo. Observe que, si la consulta no devuelve ninguna fila, PLlSQL no genera ninguna excepción cuando se abre el cursar.
•
El código recorre entonces en bucle cada fila del conjunto activo y extrae los valores de la fila actual, almacenándolos en una serie de variables de salida mediante la instrucción FETCH INTO. Cada instrucción FETCH hace también que avance el puntero hasta la siguiente fila del conjunto activo.
•
El código comprueba si el cursar no contenía ninguna fila (propertyCursor%NOTFOUND) y sale del bucle en ese caso (EXIT WHEN). Si existe alguna fila, muestra los detalles del inmueble utilizando el paquete DBMS _ OUTPUT y vuelve a comenzar el bucle.
•
El cursar se cierra después de completar las extracciones.
•
Finalmente, el bloque de excepciones se encarga de mostrar las condiciones encontrarse.
de error que puedan
Además de %NOTFOUND, que se evalúa como cierto si la extracción más reciente no ha devuelto ninguna fila, hay algunos otros atributos de los cursores que resultan de gran utilidad: • •
%FOUND Se evalúa como cierto si la extracción más reciente devuelve una fila (es el complementario de %NOTFOUND). %ISOPEN Se evalúa como cierto si el cursar está abierto.
•
%ROWCOUNT Toma como valor el número total de filas devueltas hasta el momento.
Paso de parámetros a los curso res
PLlSQL permite parametrizar los cursores, de modo que una misma definición de cursar pueda reutilizarse con diferentes criterios. Por ejemplo, podríamos cambiar el cursar definido en el ejemplo anterior a: CURSOR propertyCursor(vStaffNoVARCHAR2) IS SELECT propertyNo.street, city,postcode FROM PropertyForRent WHERE staffNo = vStaffNo ORDER BY propertyNo; con lo que podríamos abrir el cursar utilizando las siguientes instrucciones de ejemplo: vStaffNo1PropertyForRent.staffNo%TYPE OPEN propertyCursor('SG14'); OPEN propertyCursor('SA9'); OPEN propertyCursor(vStaffNo1);
:=
'SG14';
Actualización de filas mediante un cursor
Resulta posible actualizar y borrar una fila después de haberla extraído mediante un cursar. En este caso, para garantizar que las filas no sean modificadas entre el momento en que se declara el cursar, el momento en que se lo abre y el momento en que se extraer las filas para incluirlo en el conjunto activo, añadimos la cláusula FOR UPDATE a la declaración del cursar. Esto tiene como efecto bloquear las filas del conjunto activo para impedir cualquier posible conflicto de actualización cuando el cursar se abra (el tema de los bloqueos y los conflictos de actualización se explica en el Capítulo 20). Por ejemplo, podríamos querer reasignar los inmuebles gestionados por SG 14, de modo que pasen a ser gestionados por SG37. El cursar se declararía entonces como: CURSOR propertyCursor IS
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
239
SELECT propertyNo,street, city,postcode FROM PropertyForRent WHERE staffNo = '8814' ORDER BY propertyNo FOR UPDATE NOWAIT; De manera predeterminada, si el servidor Oracle no puede adquirir los bloqueos sobre las filas del conjunto activo especificado en un cursar SELECT FOR UPDATE, se quedará esperando de manera indefinida. Para impedir esto, puede especificarse la palabra clave NOWAIT y realizarse una comprobación para ver si el bloqueo ha tenido éxito. A la hora de recorrer en bucle las filas del conjunto activo, se le añade la cláusula WHERE CURRENT OF a la instrucción SQL UPDATE o DELE TE para indicar que la actualización debe aplicarse a la fila actual del conjunto activo. Par ejemplo: UPDATE PropertyForRent SET staffNo = 'S037' WHERE CURRENT OF propertyCursor; COMMIT;
8.2.6 Subprogramas, procedimientos almacenados, funciones y paquetes Los subprogramas son bloques PLlSQL nominado s que pueden tomar parámetros y ser invocados a voluntad del programador. PLlSQL tiene dos tipos de subprogramas, denominados funciones y procedimientos (almacenados). Los procedimientos y funciones admiten un conjunto de parámetros, que serán especificados por el programa que realice la invocación, y llevan a cabo un conjunto de acciones. Tanto los procedimientos como las funciones pueden modificar y devolver los datos que se les pasan en forma de parámetros. La diferencia entre un procedimiento y una función es que una función siempre devolverá un único valor a quien haya hecho la invocación, mientras que un procedimiento no. Usualmente, se emplean procedimientos, a menos que sólo haga falta un valor de retorno. Los procedimientos y funciones son muy similares a los que pueden encontrarse en la mayoría de los lenguajes de programación de alto nivel, y tienen las mismas ventajas. Proporcionan modularidad y extensibilidad, promueven la reusabilidad y la mantenibilidad y ayudan en el proceso de abstracción de los datos. Los parámetros tienen un nombre distintivo y un tipo de datos, pero también pueden especificarse como: •
IN
el parámetro se utiliza únicamente como valor de entrada.
•
OUT
el parámetro se utiliza únicamente como valor de salida.
•
IN OUT
el parámetro se utiliza como valor tanto de entrada como de salida.
Por ejemplo, podemos cambiar el bloque PLlSQL anónimo dado en la Figura 8.19 y transformado procedimiento añadiendo las siguientes líneas al comienzo: CREATE OR REPLACE PROCEDURE (IN v8taffNoVARCHAR2) AS.
en un
PropertiesFor8taff
Este procedimiento podría entonces ejecutarse en SQL *Plus mediante: SQL> SET SERVEROUTPUT ON; SQL> EXECUTE PropertiesFor8taff('SO 14'); Paquetes
Un paquete es una colección de procedimientos, funciones, variables e instrucciones SQL que se agrupan y almacenan como una única unidad de programa. Un paquete tiene dos partes: una especificación y un cuer-
240
Sistemas de bases de datos
po. La especificación de un paquete declara todas las estructuras únicas del paquete, mientras que el cuerpo define todas las estructuras (públicas y privadas) del paquete, es decir, implementa la especificación. De esta forma, los paquetes proporcionan una forma de encapsulación. Oracle lleva a cabo los siguientes pasos cuando se crea un procedimiento o paquete: •
Compila el procedimiento o paquete.
•
Almacena el código compilado en la memoria.
•
Almacena el procedimiento de paquete en la base de datos.
Para el ejemplo anterior, podemos crear una especificación de paquete de la forma siguiente: CREATE OR REPLACE PACKAGE StaffPropertiesPackage proced ure PropertiesF orStaff(vStaffNo VAR CHAR2); END StaffPropertiesPackage;
AS
y podríamos crear el cuerpo del paquete (es decir, la implementación del paquete) como: CREATE OR REPLACE PACKAGE BODY AS END
StaffPropertiesPackage
StaffPropertiesPackage;
Para hacer referencia a los elementos declarados dentro de la especificación de un paquete, se utiliza la notación de punto. Por ejemplo, podríamos invocar el procedimiento PropertiesForStaff de la forma siguiente: StaffPropertiesPackage
PropertiesForStaff('
SG 14 ');
8.2.7 Disparadores Un disparador define una acción que la base de datos debe llevar a cabo cuando tenga lugar un determinado suceso en la aplicación. Pueden utilizarse los disparadores para imponer ciertas restricciones de integridad referencial, para imponer restricciones empresariales complejas o para auditar los cambios realizados en los datos. El código de un disparador, denominado cuero del disparador, está compuesto por un bloque PLlSQL, un programa Java o por una rutina en 'C'. Los disparadores se basan en el modelo ECA (Event-Condition~ Action, suceso-condición-acción): •
El suceso (o sucesos) que dispara la regla especificada. En Oracle, puede ser: •
una instrucción INSERT, UPDATE o DELETE sobre una tabla especificada (o sobre una vista);
•
una instrucción CREATE, ALTER o DROP ejecutada sobre cualquier objeto del esquema;
•
un arranque de la base de datos o detención de la instancia, o bien el inicio o fin de una sesión por parte del usuario;
•
un mensaje de error específico o cualquier mensaje de error.
También es posible especificar si el disparador debe entrar en acción antes o después del suceso. •
La condición que determina si la acción debe ejecutarse. La condición es opcional, pero si se la especifica, la acción se ejecutará únicamente si la condición se evalúa como verdadera.
•
La acción que hay que llevar a cabo. Este bloque contiene el código y las instrucciones SQL que hay que ejecutar cuando se produce el suceso de disparo y la condición de disparo se evalúa como cierta.
Hay dos tipos de disparador: disparadores de nivel defila que se ejecutan para cada fila de la tabla que se vea afectada por el suceso de disparo y disparadores de nivel de instrucción que se ejecutan únicamente una vez, incluso aunque haya múltiples filas afectadas por el suceso de disparo. Oracle también soporta disparadores INSTEAD-OF, que proporcionan una forma transparente de modificar las vistas que no puedan verificarse directamente mediante instrucciones DML de SQL (INSERT, UPDATE y DELETE). Estos disparadores se denominan disparadores INSTEAD-OF porque, a diferencia de otros tipos de disparador, Oracle ejecuta
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
241
el disparador en lugar de (INSTEAD-OF) ejecutar la instrucción SQL original. Los disparadores también pueden activarse por sí mismos uno detrás de otro. Esto puede suceder cuando la acción de disparo efectúe un cambio en la base de datos que tenga como efecto provocar otro suceso que tenga un disparador asociado. Por ejemplo, DreamHome tiene una regla que impide que un empleado gestione más de 100 inmuebles al mismo tiempo. Podríamos crear el disparador mostrado en la Figura 8.20 para imponer esta restricción empresarial. Este disparador se invoca antes de que se inserte una fila en la tabla PropertyForRent o antes de que se actualice una fila ya existente. Si el empleado ya gestiona 100 inmuebles, el sistema mostrará un mensaje y abortará la transacción. •
La palabra clave BEFORE indica que el disparador debe ejecutarse antes de aplicar una inserción o actualización a la tabla PropertyForRent.
•
La palabra clave FOR EACH ROW indica que se trata de un disparador de nivel de fila, que se ejecutará para cada fila de la tabla PropertyForRent que sea actualizada en la instrucción
•
La palabra clave new se utiliza para hacer referencia al nuevo valor de la columna (aunque no la hemos utilizado en este ejemplo, la palabra clave old puede utilizarse para hacer referencia al antiguo valor de una columna).
Utilización de disparadores para imponer la integridad referencial Hemos mencionado en la Sección 8.2.3 que, de manera predeterminada, Oracle impone las acciones referenciales ON DELETE NO ACTION Y ON UPDATE NO ACTION sobre las claves externas especificadas. También permite especificar la cláusula adicional ON DELETE CASCADE para permitir que los borrados efectuados en la tabla padre se propaguen en cascada a la tabla hija. Sin embargo, no soporta la acción ON UPDATE CASCADE ni las acciones SET DEFAULT ni SET NULL. Si se requiere cualquiera de estas acciones, será necesario implementarlas mediante disparadores o procedimientos almacenados, o dentro del código de la aplicación. Por ejemplo, en el Ejemplo 6.1 del Capítulo 6 la clave externa staffNo de la tabla PropertyForRent debía tener la acción ON UPDATE CASCADE. Esta acción puede implementarse utilizando los disparadores mostrados en la Figura 8.21. Disparador 1 (PropertyForRent_ Check_ Beforel
El disparador
de la Figura 8.21(a) se dispara siempre que se actualice la columna staffNo de la tabla El disparador comprueba, antes de que la actualización tenga lugar, que el nuevo valor especificado existe en la tabla Staff. Si se genera una excepción Invalid _ Staff, el disparador emite un mensaje de error e impide que el cambio tenga lugar. PropertyForRent.
CREATE TRIGGER StaftNotHandlingTooMuch BEFORE INSERT OR UPDATE ON PropertyForRent FOREACHROW DECLARE vpCount BEGIN
NUMBER;
SELECT COUNT(*) INTO vpCount FROM PropertyForRent WHERE staftNo : :new.staftNo; IF vpCount : 100 raise_application_error( -20000, ('Member' ENDIF;
11
:new.staffNo
11
'already managing 100 properties');
END;
Figura 8.20.
Disparador para imponer la restricción de que un empleado no pueda gestionar más de 100 inmuebles al mismo tiempo.
242
Sistemas de bases de datos
-- Antes de que se actualice la columna stafINo en la tabla PropertyForRent, activar este disparador -- para verificar que el nuevo valor de clave externa está presente en la tabla Staff. CREATE TRlGGER PropertyForRent
disparador de tipo anterior
Check Before
BEFORE UPDATE OF1raffNo ON PropertyForRent FOR EACH ROW WHEN (new.staffNo ]S NOT NULL)
~
DECLARE
~
condición para que el disparador se active
dummy CHAR(5); invalid_staff EXCEPTION;
disparador de nivel de fila
valid_staff EXCEPTION; mutating....table EXCEPTION; PRAGMA EXCEPTION_IN]T (mutating....table, -4091); -- Utilizar cursor para verificar que existe el valor de la clave padre. -- Se utiliza FOR UPDATE OF para bloquear la fila de la clave padre con el fin de que no -- pueda ser borrada por otra transacción hasta que esta transacción se complete. CURSOR update_cursor (sn CHAR(5)) IS SELECT stafINo FROM Staff WHERE staffNo = sn FOR UPDATE OF staffNo; BEGIN OPEN update_cursor (:new.staffNo); FETCH update_cursor INTO dummy; -- Verificar clave padre. Generar excepciones según sea apropiado. IF update_cursor%NOTFOUND
THEN
RAISE invalid_staff; ELSE
RAISE valid_staff; ENDIF;
especificado un valor staffNo no válido
CLOSE updatccursor; EXCEPTION WHEN invalid_staffTHEN CLOSE update_cursor; raise_application_error(-20000,
'Invalid StaffNumber'
11
:new.staffNo);
WHEN valid_staff THEN CLOSE update_cursor; -- Una tabla mutante es una tabla que está siendo actualmente modificada por una instrucción -- INSERT, UPDATE or DELETE o una que puede necesitar ser actualizada debido al efecto de -- una restricción de integridad referencial DELETE CASCADE declarativa. -- Este error generaria una excepción, pero en este caso la excepción no tiene importancia, -- por lo que la capturamos, pero no hacemos nada. WHEN mutatíng....table THEN NULL; END; (a)
Figura 8.21. Disparadores Oracle para imponer la acción ON UPDATE CASCADE a la clave externa staffNo en la tabla PropertyForRent cuando se actualiza la clave principal staffNo en la tabla 8taff: (a) disparador para la tabla PropertyForRent. Cambios para soportar disparadores en la tabla Staff Los tres disparadores mostrados en la Figura 8.21(b) se disparan siempre que se actualice la columna staffNo de la tabla 8taff. Antes de la definición de los disparadores, se ha creado un número de secuencia
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
-- Crear un número
de secuencia
CREATE SEQUENCE
updateseq
y una variable pública UPDATESEQ.
updatesequence
CREATE PACKAGE seqpackage
INCREMENT
AS
BY 1 MAXVALUE 500 CYCLE;
••
Paquete para almacenar el número de secuencia
NUMBER;
END seqpackage; CREATE or REPLACE PACKAGE BODY seqpackage
AS END seqpackage;
-- Añadir un nuevo atributo a la tabla PropertyForRent para indicar ALTER TABLE PropertyForRent ADD updateid NUMBER; -- Antes de actualizar -- generar
la tabla Staff utilizando
un nuevo número
CREA TE TRIGGER
de secuencia
Cascade_StaffNo_
BEFORE UPDATE
243
este disparador
y asignárselo
de nivel de instrucción,
a la variable
pública
UPDATESEQ.
0-----------------
Updatel
OF staffNo ON Staff
Añadir columna adicional a la tabla PropertyForRent
las fil~ modificadas.
Disparador anterior de nivelde instrucción
..•••
DECLARE dummy
NUMBER;
BEGIN
INTO dummy FROM dual; SELECT seqpackage.updateseq:= uPdatesequence.NEXTVAL} dummy;
de secuencia para Fijarnuevo la actualización número
4••••••••
END;
-- Crear un disparador
posterior
-- Sólo debe propagarse CREATE TRIGGER
de nivel de fila que propague
en cascada la actualización
en cascada la actualización
si la fila fija no ha sido ya actualizada
a la tabla PropertyForRent. por el disparador.
Cascade_StaffNo_Update2
AFTER UPDATE OF staffNo
ON Staff
FOREACHROW
} ••
Disparador posterior de nivelde fila
BEGIN
UPDATE staffNo PropertyForRent SET AND staffNo = :new.staffNo,} WHERE = :old.staffNo updateid updateid = IS seqpackage.updateseq NULL; END'
Actualizartabla activar PropertyForRent el indicador y de actualización para estas filas
~
,
-- Crear un último CREA TE TRIGGER AFTER UPDATE
disparador
posterior
de nivel de instrucción
para desactivar
los indicadores
de actualización.
Cascade_StaffNo_Update3 OF staffNo ON Staff
..•. ---
_
BEGIN
_ UPDATE WHERE updateid PropertyForRent seqpackage.updateseq; SET updateid
= NULL}
_
END;
Disparador posterior de nivelde instrucción; desactiva los indicadores de actualización de las filas actualizadas
(b)
Figura 8.21.
(b) Disparadores para la tabla Staff.
updateSequence junto con una variable pública updateSeq (a la que pueden acceder los tres disparadores a través del paquete seqpackage). Además, la tabla PropertyForRentse ha modificado para añadir una columna denominada updateld, que se utiliza para indicar si una fila se ha actualizado, con el fin de evitar que sea actualizada más de una vez durante la operación de propagación en cascada. Disparador 2 (Casca de _ StaffNo
Update 1)
Este disparador (de nivel de instrucción) se activa antes de que se actualice la columna staffNode la tabla Staff, con el fin de establecer un nuevo número de secuencia para la actualización.
244
Sistemas de bases de datos
Disparador J (Casca de _ StaffNo
Update2)
Este disparador (de nivel de fila) se dispara para actualizar todas las filas de la tabla PropertyForRent que tengan el antiguo valor de staffNo (:old.staffNo), sustituyéndolo por el nuevo valor (:new.staffNo), y para marcar la fila con el fin de indicar que ha sido actualizada. Disparador 4 (Casca de StaffNo _ UpdateJ)
El último disparador (de nivel de instrucción) se activa después de la actualización para borrar los indicadores de actualización de las filas modificadas.
8.2.8 Oracle Internet Developer Suite Oracle Internet Developer Suite es un conjunto de herramientas que ayudan a los desarrolladores a construir aplicaciones de bases de datos sofisticadas. El conjunto incluye: •
Oracle Forms Developer, un conjunto de herramientas para desarrollar aplicaciones basadas en formularios para su implantación como aplicaciones tradicionales cliente-servidor en dos niveles, o como aplicaciones en tres niveles basadas en explorador.
•
Oracle Reports Developer, un conjunto de herramientas para el desarrollo rápido y la implantación de informes sofisticados en papel y basados en la Web.
•
Oracle Designer, una herramienta gráfica para el desarrollo rápido de aplicaciones (RAD, Rapid Application Development) que cubre todo el ciclo de desarrollo de sistemas de bases de datos, desde el diseño conceptual hasta el diseño lógico (generación del esquema), generación del código de aplicación e implantación. Oracle Designer también permite efectuar la ingeniería inversa de diseños lógicos existentes para obtener los esquemas conceptuales.
•
Oracle IDeveloper, para ayudar en el desarrollo de aplicaciones Java. JDeveloper incluye un asistente de formulario de datos, un asistente para la creación de clases JavaBeans y BeanInfo y un asistente de implantación.
•
Oracle9iAS Portal, una herramienta basada en HTML para el desarrollo de aplicaciones compatibles con la Web y sitios web de contenido dinámico.
En esta sección vamos a analizar los primeros dos componentes de Oracle Developer Suite. El desarrollo basado en la Web se estudiará en el Capítulo 29.
Oracle9i Forms Developer Oracle9i Forms Developer es un conjunto de herramientas que ayudan a los desarrolladores a crear aplicaciones personalizadas de base de datos. En conjunción con Oracle9iAS Forms Services (un componente de Oracle9i Application Server), los desarrolladores pueden crear e implantar formularios Oracle en la Web utilizando OC4J (Oracle Containers for J2EE). El componente Oracle9iAS Forms Services se encarga de llevar a cabo la presentación de la aplicación en forma de applet Java, que puede ampliarse utilizando componentes Java, como JavaBeans y componentes PJC (Pluggable Java Component), por lo que los desarrolladores pueden crear interfaces sofisticadas fácil y rápidamente. Los formularios se construyen como colección de elementos individuales de diseño denominados items. Hay muchos tipos de items, como cuadros de texto para introducir y editar datos, casillas de verificación y botones para iniciar alguna acción del usuario. Un formulario se divide en una serie de secciones, siendo las principales: •
Lienzo. Éste es el área en que se colocan los items (de forma similar al lienzo que un artista utilizaría). Pueden modificarse propiedades tales como la disposición y el color utilizando el editor de diseño (Layout Editor). Hay cuatro tipos de lienzos: un lienzo de contenido es la parte visual de la aplicación y debe siempre incluirse en todos los formularios; un lienzo apilado, que puede solaparse con otros lienzos para mostrar u ocultar partes de la información cuando se esté accediendo a otros datos; un lien-
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
245
zo de fichas, que tiene una serie de páginas, cada una con una pestaña nominada en la parte superior para indicar la naturaleza de la página; y una barra de herramientas, que aparece en todos los formularios y puede personalizarse. •
Marcos. Un grupo de elementos que pueden manipularse y modificarse como un único item.
•
Bloques de datos. El origen de control para el formulario, como por ejemplo una tabla, vista o procedimiento almacenado.
•
Ventanas. Contenedores para todos los objetos visuales que componen un formulario. Cada ventana debe tener al menos un lienzo y cada lienzo debe estar asignado a una ventana.
Al igual que Microsoft Office Access, las aplicaciones Oracle Forms son controladas por sucesos. Un suceso puede ser un suceso de interfaz, como por ejemplo que el usuario presione un botón, se desplace entre los diversos campos o abra/cierre el formulario; o un suceso interno de procesamiento (una acción del sistema), como por ejemplo comprobar la validez de un elemento de acuerdo con ciertas reglas de validación. El código que responde un suceso es un disparador; por ejemplo, cuando el usuario pulsa sobre el botón de cierre de un formulario, se activa el disparador WHEN-WINDOW-CLOSED. El código escrito para tratar este suceso puede, cerrar la aplicación o recordar al usuario que debe guardar su trabajo. Los usuarios experimentados pueden crear los formularios partiendo de cero. Sin embargo, Oracle también proporciona un asistente de bloques de datos (Data Block Wizard) y un asistente de diseño (Layout Wizard) que llevan al usuario a través de una serie de páginas interactivas para determinar: •
la tabla/vista o procedimiento almacenado en el que hay que basar el formulario;
•
las columnas que hay que mostrar en el formulario;
•
si debe crearse/borrarse una relación maestro-detalle
•
el nombre del nuevo bloque de datos;
con otros bloques de datos del formulario;
•
el lienzo en el que hay que situar el bloque de datos;
•
la etiqueta, anchura y altura de cada elemento;
•
el estilo de diseño (formulario o tabular);
•
el título del marco, junto con el número de registros que hay que mostrar y la distancia entre los registros.
La Figura 8.22 muestra algunas pantallas de estos asistentes y el formulario final que presenta Forms Services.
Oracle9i Reports Developer Oracle9i Reports Developer es un conjunto de herramientas que permite el desarrollo rápido y la implantación de informes sofisticados en soporte papel o web que toman sus datos de diversos orígenes de datos, incluyendo la propia base de datos Oracle9i, JDBC, XML, archivos de texto y Oracle9i OLAP. Utilizando tecnologías J2EE como JSP y XML, pueden publicarse los informes en diversos formato s, como HTML, XML, PDF, texto delimitado, Postscript, PCL y RTF, dirigiéndolos a diversos posibles destinos, como por ejemplo el correo electrónico, un explorador web, Oracle9iAS Portal y el sistema de archivos. En conjunción con Oracle9iAS Reports Services (un componente de Oracle9i Application Server), los desarrolladores pueden crear e implantar informes de Oracle Reports a través de la Web. Oracle9i Reports Developer incluye: •
asistentes que guían al usuario a través del proceso de diseño del informe;
•
orígenes de datos conectables (PDS, pluggable data sources, como JDBC y XML, que proporcionan acceso a datos de cualquier tipo de fuente para los informes;
•
un diseñador de consultas con una representación gráfica de la instrucción SQL para obtener los datos del informe;
•
plantillas de informes y estilos de diseño predeterminados
que pueden personalizarse;
246
Sistemas de bases de datos
(a)
(b)
(e)
Figura 8.22. Ejemplo de creación de un formulario en Oracle Forms Builder: (a) una página del asistente de bloques de datos; (b) una página del asistente de diseño; (c) el formulario final mostrado por Forms Services.
Capítulo 8 Bases de datos comerciales:
Office Access y Oracle
247
•
un editor que permite modificar los diseños de informes en papel en modo WYSIWYG (vista Paper Design);
•
un diseñador integrado de gráficos para representar gráficamente los datos del informe;
•
la capacidad de ejecutar instrucciones SQL dinámicas dentro de procedimientos
•
informes controlados por sucesos (ejecución del informe basada en sucesos de la base de datos).
PL/SQL;
Los informes se construyen con una colección de objetos, tales como: •
objetos del modelo de datos (consultas, grupos, columnas de la base de datos, vínculos, parámetros de usuario);
•
objetos de diseño (marcos, marcos repetitivo s, campos, texto estático, anclas);
•
objetos de formularios paramétricos (parámetros, campos, texto estático);
•
objetos PL/SQL (unidades de programa, disparadores).
Las consultas proporcionan los datos para el informe. Las consultas pueden seleccionar datos de cualquier origen de datos, como una base de datos Oracle9i, JDBC, XML o un origen PDS. Normalmente se crean grupos para organizar las columnas en el informe. Los grupos permiten separar los datos de una consulta en una serie de conjuntos y también filtrar dichos datos. Una columna de la base de datos representa una columna seleccionada por la consulta que contiene los valores de datos para un informe. Para cada columna seleccionada en la consulta, el generador de informes crea automáticamente una columna en el modelo de datos del informe. Los resúmenes y cálculos sobre valores de las columnas de la base de datos se pueden crear manualmente en la vista Data Modelo utilizando el asistente de informes (para las columnas de resumen). Un enlace de datos (o relación padre-hijo) relaciona los resultados de múltiples consultas. Los enlaces de datos hacen que la consulta hija se ejecute una vez por cada instancia de su grupo padre. La consulta hija se ejecuta con el valor de la clave principal del padre. Los marcos rodean los objetos e impiden que sean sobreescritos por otros objetos. Por ejemplo, puede utilizarse un marco para rodear todos los objetos propiedad de un grupo, para rodear los encabezados de columna o para rodear los resúmenes. Los marcos repetitivos rodean todos los campos que se crean para las columnas de un grupo. El marco repetitivo se imprime una vez por cada registro del grupo. Estos marcos repetitivos pueden encerrar cualquier objeto de diseño, incluidos otros marcos repetitivos. Los marcos repetitivo s anidados se utilizan normalmente para generar informes maestro-detalle e informes de salto. Los campos son contenedores para los parámetros, columnas y otros datos, como por ejemplo el número de página o la fecha actual. Un objetos de texto estático es cualquier texto, línea o gráfico que aparece en un informe cada vez que se ejecuta éste. Un parámetro es una variable cuyo valor puede configurarse en tiempo de ejecución. Igual que Oracle Forms, Oracle Reports Developer permite a los usuarios experimentados crear informes partiendo de cero, y también proporciona un asistente de bloques de datos (Data Block Wizard) y un asistente de diseño (Layout Wizard) que guían al usuario a través de una serie de páginas interactivas para determillar: •
el estilo del informe (por ejemplo, tabular, de grupo izquierdo, de grupo superior, matricial, matricial con grupos);
•
el origen de los datos (Express Server Query para consultas OLAP, JDBC Query, SQL Query, Text Query, XML Query);
•
la definición del origen de los datos (por ejemplo, una consulta SQL);
•
los campos en los que hay que basar el agrupamiento (para un informe agrupado);
•
los campos que hay que mostrar en el informe;
•
los campos para los cálculos agregados;
•
la etiqueta, la anchura y la largura de cada elemento;
•
la plantilla que hay que utilizar, si se desea utilizar alguna.
248
Sistemas de bases de datos
La Figura 8.23 muestra algunas pantallas de este asistente y el formulario final que mostraría Reports Services. Observe que también se podría construir un informe utilizando SQL *Plus. La Figura 8.24 ilustra algunos de los comandos que pueden emplearse para construir en SQL *Plus un informe: •
El comando COLUMN proporciona un título y un formato para una columna del informe.
•
Pueden utilizarse comandos BREAK para agrupar los datos, saltar líneas entre atributos o separar el informe en diferentes páginas. Estos saltos pueden definirse dependiendo de un atributo, de una expresión, de un alias o del propio informe.
•
El comando COMPUTE realiza un cálculo partiendo de columnas o expresiones seleccionadas en una tabla. El comando BREAK debe acompañar al comando COMPUTE.
8.2.9 Otras funcionalidades de Oracle En capítulos posteriores del libro tendremos oportunidad de examinar Oracle con mayor detalle, incluyendo: • •
los mecanismos de organización de archivos y de indexación de Oracle en el Capítulo 17 y en el Apéndice C; las características básicas de seguridad de Oracle en el Capítulo 19;
• •
cómo gestiona Oracle los problemas de concurrencia y recuperación en el Capítulo 20; cómo lleva a cabo Oracle la optimización de consultas en el Capítulo 21;
•
el mecanismo de distribución de datos de Oracle en el Capítulo 23;
•
el mecanismo de replicación de datos de Oracle en el Capítulo 24;
•
las características objeto-relacionales
•
Oracle9i Application Server en el Capítulo 29;
• •
el soporte de Oracle para XML en el Capítulo 30; las funciones de almacén de datos de Oracle en el Capítulo 32.
8.2.10
de Oracle en el Capítulo 28;
Oracle10g
En el momento de escribir este libro, Oracle acaba de anunciar la siguiente versión de su producto, Oracle 1Og. Mientras que la 'i' de Oracle9i quiere decir 'Internet', la 'g' de la siguiente versión representa la palabra inglesa 'grid' (retícula). La nueva línea de productos se dirige al mercado de la informática reticular, que trata de agrupar servidores y dispositivos modulares de almacenamiento de bajo coste para crear un recurso virtual de procesamiento que poner a disposición de la organización. El sistema distribuye transparentemente la carga de trabajo para utilizar de forma eficiente la capacidad, con un bajo coste y una alta disponibilidad, proporcionando así capacidad de proceso 'a la carta'. De esta forma, la informática pasa a considerarse de forma análoga a cualquier otro tipo de recurso de utilidad, como por ejemplo la red eléctrica o la red telefónica. El cliente no tiene que preocuparse de dónde están almacenados los datos dentro de la retícula o de dónde se realiza el procesamiento; lo único de lo que necesita preocuparse es de obtener los datos necesarios de la forma que prefiera y en el momento que los precise. Oracle ha anunciado tres productos preparados para la informática reticular: •
Oracle Database 10g;
•
Oracle Application Server 10g;
•
Oracle Enterprise Manager 10g Grid Control.
Oracle Oatabase 10g El componente de base de datos de la arquitectura reticular está basado en la función Real Application Clusters, que fue introducida en Oracle9i. Oracle Real Application Clusters permite que una única base de
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
SELECT
249
• FROM Prope¡lyFOIRenlj
(a)
$eveli_mrmlllll
l.;A";;'iu:mDl~:fJf.1
(b)
8RANcH¡i¡o
mOFEATYNO 1YPE ROOM!>
liE
Figura 8.23. Ejemplo de creación de informe en Oracle Reports Builder: (a)-(d) páginas del asistente de bloques de datos y del asistente de diseño; (e) modelo de datos del informe; (f) el formulario final mostrado por Reports Services.
(e)
250
Sistemas de bases de datos x
AvOJk\blo F'~
A Pi'lOPtm'i'No .~. $lll~El A.OTY 1>,.. POSTCODE
(d)
A 'lVf'E ROOMS
'li1ID R\. O'WNEFlIln
A ¡¡lAfflln I>,.ORANCHIln
-
375 COi) PG16 FOOIl PG21
33 5
FH F
<1
350
8003
Total: 1775
P<)4
¡e¡j1' PROI'fRTYNO ~+ TYPE
!ilI + 16+
ROOIIIS RENT
I'roplHtl}F orRent
~+ STRffT ~+ OTY l'J,l+ POSTCOOE ~
Branchno
.•• Cll'lN'RNO
8005
PUl4
•
.0.1;..-
El
103
I'ropertyForRenl:
l:}' lln
Branchno
8007
(e) H
e
_
(f)
Figura 8.23.
(Cant.)
datos se ejecute sobre múltiples nadas agrupados en clúster. En el nuevo producto se ha añadido lo que se denomina clusterware integrado, para simplificar el proceso de gestión de los clústeres, permitiendo la adición y eliminación dinámicas de clústeres Oracle. La función ASM (Automatic Storage Management, gestión automática del almacenamiento) permite al DBA definir un grupo de discos (un conjunto de dispositivos de disco) que Oracle se encargará de gestionar como una unidad lógica. Por ejemplo, si se ha definido un grupo de discos como grupo de discos predeterminado para una base de datos, Oracle asignará automáticamente el espacio necesario y creará/borrará los archivos asociados. Utilizando RAID, ASM puede equilibrar las opera-
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
251
N,~~_¡.t.4~~ji¡¡¡i~¡¡i¡
File Edit
Search" Optiof"lS*, fi~lp
Copyright
(e) 1982,
Connected to: Personal Oracle9i
2002,
Release
Oraele
Corporation.
9.2.0.1.0
********
rights
reserued.
- Production
With the partitioning, OLAP and Oracle JSeruer Release 9.2.0.1.0 - Production SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> 2
All
Data
Mining
options
SEI PAGESIZE 30 COLUMN b,-anehNo FORMAl A8 HEADING 'BranehNo' COLUMN propertyNo FORMAl A10 HEADING 'P"opertyNo' COLUMN type FORMAl A4 HEADING 'lype' COLUMN rooms FORMAl 99 HEADING 'No of Rooms' COLUMN rent FORMAl 9999 HEADING 'Rent' BREAK ON branchNo SKIP 1 ON report SKIP 1 COMPUIE SUM OF rent ON branehNo COMPUIE SUM OF rent ON report SELECI branehNo, propertyNo, type, rooms, rent FROM PropertyForRent;
BranchNo
PropertyNo
lype
B007 sum PG21 PG36 PG16 B003 0005 sum
PG4 PA14 PL94
H
No of Rooms
6
Rent
650 650
F
4
400 400
F F H
F
3
350
3 5 4
375 600 450 1775
2825
6 rows
seleeted.
SQl) .•f :J Figura 8.24.
Ejemplo de creación de informe mediante SOL *Plus.
ciones de E/S de múltiples bases de datos entre todos los dispositivos del grupo de discos y mejorar las prestaciones y la fiabilidad mediante las técnicas de división en bandas y duplicación en espejo (véase la Sección 19.2.6). Además, ASM puede reasignar los discos de un nodo a otro y de un clúster a otro. Además de asignar dinámicamente el trabajo a los múltiples nodos y de dividir los datos entre múltiples discos, Oracle también puede desplazar los datos dinámicamente o compartirlos entre múltiples bases de datos, potencialmente sobre diferentes sistemas operativo s, mediante la función denominada Oracle Streams. Entre las características de autogestión de la base de datos se incluyen el diagnóstico automático de problemas, como, por ejemplo, contiendas debidas a bloqueos inadecuados y consultas SQL lentas, la resolución de algunos problemas y el envío de mensajes de alerta al DBA sobre otros problemas, sugiriendo posibles solucIOnes.
252
Sistemas de bases de datos
Oracle Application Server 10g y Oracle Enterprise Manager 10g Grid Control Oracle9iAS, un conjunto integrado de software de infraestructura para aplicaciones, y el módulo Enterprise Manager han sido mejorados para ejecutar aplicaciones empresariales sobre retículas de computación. Las mejoras incluyen: •
una instalación y configuración del software más sencillas sobre múltiples nodos de la retícula;
•
facilidades de clonación para clonar servidores, sus configuraciones y las aplicaciones implantadas en los mismos;
•
facilidades para automatizar tareas frecuentes en múltiples servidores;
•
mecanismos avanzados de seguridad, incluyendo soporte de seguridad Java2, soporte SSL para todos los protocolos y una infraestructura de seguridad basada en PKI (véase el Capítulo 19);
•
una consola de gestión de seguridad (Security Management Console) para crear usuarios y roles y para definir identidades de usuario y privilegios de control de acceso en toda la retícula (esta información se almacena en Oracle Internet Directory, un servidor de directorio compatible con LDAP que puede integrarse con otros entorno s de seguridad);
•
Oracle Enterprise Single Sign-On Service (servicio de inicio de sesión único), para permitir a los usuarios autenticarse ante una serie de aplicaciones y servicios de la retículas;
•
un conjunto de herramientas para monitorizar y optimizar las prestaciones del sistema; por ejemplo, DMS (Dynamic Monitoring Service) recopila estadísticas de consumo de recursos, como por ejemplo consumo del procesador, memoria o E/S; APM (Application Performance Monitoring) permite a los DBA controlar el uso de recursos efectuado por una transacción a través de los diversos componentes de la infraestructura, como por ejemplo la red, los servidores web, los servidores de aplicación y los servidores de base de datos.
Resumen del capítulo •
Los SGBDR (sistemas de gestión de bases de datos relacionales) se han convertido en el software de procesamiento de datos dominante hoy en día, con una estimación de ventas de nuevas licencias de entre 6.000 y 10.000 millones de dólares por año (25.000 millones de dólares si incluimos las ventas de herramientas).
•
Microsoft Office Access es el SGBD relacional más ampliamente utilizado en los entorno s Microsoft Windows. Se trata de un SGBD típico basado en PC capaz de almacenar, ordenar y extraer datos para diversas aplicaciones. Office Access proporciona una GUI para crear tablas, consultas, formularios e informes, así como herramientas para desarrollar aplicaciones personalizadas de base de datos utilizando ellenguaje de macros de Microsoft Office Access o el lenguaje Microsoft Visual Basic for Applications (VBA).
•
El usuario interactúa con Microsoft Office Access y desarrolla una base de datos y una aplicación utilizando tablas, consultas, formularios, informes, páginas de acceso a datos, macros y módulos. Las tablas se organizan en columnas (denominadas campos) y filas (denominadas registros). Las consultas permiten al usuario visualizar, modificar y analizar los datos de distintas maneras. Las consultas también pueden almacenarse y utilizarse como origen de los registros para formularios, informes y páginas de acceso a datos. Los formularios pueden utilizarse para diversos propósitos, como por ejemplo para crear un formulario de introducción de datos con el fin de añadir datos a una tabla. Los informes permiten presentar los datos de la base de datos de una forma efectiva en un formato impreso personalizado. Una página de acceso a datos es un tipo especial de página web diseñado para visual izar y trabajar con los datos (almacenados en una base de datos Microsoft Office Access database o Microsoft SQL Server) desde Internet o desde una intranet. Las macros son un conjunto de una o más acciones cada una de las cuales lleva a cabo una operación concreta, como abrir un formulario o imprimir un informe. Los módulos son una colección de declaraciones y procedimientos VBA que se almacenan conjuntamente como una unidad.
Capítulo 8 Bases de datos comerciales: Office Access y Oracle
253
•
Microsoft Office Access puede utilizarse como sistema autónomo sobre un único PC o como sistema multiusuario sobre una red de máquinas PC. Desde el lanzamiento de Office Access 2000, existe ]a posibilidad de elegir entre dos motores de datos dentro del producto: el motor Jet original y el nuevo motor MSDE (Microsoft SQL Server Desktop Engine), que es compatible con el servidor corporativo Microsoft SQL Server.
•
Oracle Corporation es el fabricante líder de software para gestión de información y la segunda mayor empresa de software independiente del mundo. Con unos ingresos anuales de unos 10.000 millones de dólares, ]a empresa vende productos de base de datos, herramientas y aplicaciones, junto con sus servicios relacionados, en más de 145 países de todo el mundo. Oracle es el SGBDR multiusuario más vendido, y el 98% de las empresas de la lista Fortune 100 utilizando soluciones Oracle.
•
El usuario interactúa con Oracle y desarrolla una base de datos utilizando una serie de objetos. Los objetos principales en Oracle son las tablas (una tabla está organizada en columnas y filas); objetos (una forma de ampliar el sistema de tipos de datos relacionales de Oracle); clústeres (un conjunto de tablas que se almacenan físicamente juntas como una sola tabla que comparte una columna común); índices (una estructura utilizada como ayuda para extraer los datos de forma más rápida y eficiente); vistas (tablas virtuales); sinónimos (un nombre alternativo para un objeto de la base de datos); secuencias (generan una secuencia unívoca de números en caché); funciones/procedimientos almacenados (un conjunto de instrucciones SQL o PL/SQL que se utilizan en modo conjunto para ejecutar una función concreta); paquetes (una colección de procedimientos, funciones, variables e instrucciones SQL que se agrupan y almacenan como una unidad de programa); y disparadores (código almacenado en la base de datos y que se invoca, es decir, se dispara debido a sucesos que tienen lugar dentro de la aplicación).
•
Oracle está basado en una arquitectura cliente-servidor. El servidor Oracle está compuesto de la base de datos (los datos en bruto, incluyendo archivos de registro y de control) y la instancia (los procesos y la memoria del sistema en el servidor que proporciona el acceso a la base de datos). Una instancia se puede conectar a una sola base de datos. La base de datos está compuesta de una estructura lógica, como puede ser el esquema de la base de datos, y de una estructura fisica, que contiene los archivos que forman una base de datos Oracle.
Cuestiones de repaso 8.1.
Describa los objetos que pueden crearse con Microsoft Office Access.
8.2.
Explique cómo puede utilizarse Office Access en un entorno multiusuario.
8.3. 8.4.
Describa los tipos de datos principales en Office Access y en qué caso se utilizaría cada tipo. Describa dos formas de crear tablas de relaciones en Office Access.
8.5.
Describa tres maneras de crear restricciones empresariales en Office Access.
8.6.
Describa los objetos que pueden crearse en Oracle.
8.7. 8.8.
Describa la estructura lógica de una base de datos Oracle. Describa la estructura física de una base de datos Oracle.
8.9.
Describa los tipos de datos principales en Oracle y en qué caso se utilizaría cada tipo.
8.10.
Describa dos formas de crear tablas y relaciones en Oracle.
8.11.
Describa tres maneras de crear restricciones empresariales en Oracle.
8.12.
Describa loa estructura de un bloque PL/SQL.
arte
Técnicas de análisis y diseño de bases de datos
Capítulo
9 Planificación, diseño y administración de bases de datos
Capítulo 10 Técnicas de determinación de hechos Capítulo 11 Modelado entidad-relación Capítulo 12 Modelado entidad-relación avanzado Capítulo 13 Normalización Capítulo 14 Normalización avanzada
(
Capítulo
Planificación, diseño y administración de bases de datos
Objetivos del capítulo: En este capítulo aprenderá: •
Los componentes principales de un sistema de información.
•
Las etapas principales del desarrollo de sistemas de bases de datos.
•
Las fases principales del diseño de una base de datos: diseño conceptual, lógico y fisico.
•
Las ventajas de las herramientas CASE (Computer-Aided ware asistida por computadora).
•
Los tipos de criterios utilizados para evaluar un SGBD.
•
Cómo evaluar y seleccionar un SGBD.
•
La distinción entre administración de datos y administración de bases de datos.
•
El propósito y las tareas asociados a la administración de datos y la administración de bases de datos.
Software Engineering, ingeniería del soft-
El software ha sobrepasado al hardware como clave principal del éxito de numerosos sistemas informáticos. Desafortunadamente, el éxito de los proyectos de desarrollo de software no resulta particularmente impresionante. En las últimas décadas hemos visto la proliferación de aplicaciones software que van desde pequeñas y relativamente simples aplicaciones compuestas por unas pocas líneas de código, hasta grandes y complejas aplicaciones donde las líneas de código se cuentan por millones. Muchas de estas aplicaciones han requerido a lo largo del tiempo un mantenimiento constante, lo que implicaba corregir los fallos detectados, implementar nuevos requisitos de usuario y modificar el software para que se ejecutara en plataformas nuevas o actualizadas. Poco a poco, el esfuerzo invertido en tareas de mantenimiento comenzó a absorber recursos a una tasa cada vez más alarmante. Como resultado, muchos proyectos de software de gran envergadura se retrasaban, consumían todo el presupuesto disponible o generaban productos que eran poco fiables, difíciles de mantener fue utilizado por primera vez a fina es de la década de los sesenta, la crisis continúa con nosotros cuarenta años ydespués. con prestaciones muy bajas. Esttcondujo lo que se denominó crisis software. Como resultado, algunos utores se arefieren ahora a la crisis del del software con Aunque el nombreeste detérmino depresión del software. Como indicativo de la crisis, un estudio llevado a cabo en el Reino Unido por OASIG, un grupo de trabajo dedicado a los aspectos organizativos de las tecnologías de la información, llegó a las siguientes conclusiones acerca de los proyectos software (OASIG, 1996): •
entre un 80 y un 90% no cumplen con los requisitos de prestaciones establecidos;
• •
cerca de un 80% se retrasan y sobrepasan el presupuesto asignado; alrededor de un 40% fracasan o se abandonan;
•
menos de un 40% de los productos contemplan adecuadamente los requisitos de capacitación y formación;
258
Sistemas de bases de datos
•
menos de un 25% de los proyectos integran adecuadamente lógicos;
los objetivos empresariales
•
sólo entre un 10 y un 20% satisfacen todos los criterios de éxito establecidos.
y tecno-
Son varias las razones a las que atribuir este fracaso de los proyectos software, entre las cuales podemos citar: •
la falta de una especificación de requisitos completa;
•
la falta de una metodología de desarrollo apropiada;
•
una pobre descomposición
del diseño en una serie de componentes manejables.
Como solución a estos problemas, se ha propuesto un enfoque estructurado del desarrollo de software que se denomina ISLC (Information Systems Lifecycle, ciclo de vida de los sistemas de información) o SDLC (Software Development Lifecycle, ciclo de vida del desarrollo software). Sin embargo, cuando el software que se está desarrollando es un sistema de bases de datos, ese ciclo de vida se suele denominar, más específicamente DSDLC (Database System Development Lifecycle, ciclo de vida del desarrollo de sistemas de bases de datos).
Estructura del capítulo En la Sección 9.1 vamos a describir brevemente el ciclo de vida de los sistemas de información y a explicar cómo se relaciona este ciclo de vida con el del desarrollo de sistemas de base de datos. En la Sección 9.2 presentaremos una panorámica de las etapas que componen el ciclo de vida del desarrollo de sistemas de bases de datos. En las Secciones 9.3 a 9.13 describiremos cada una de las etapas de ese ciclo de vida con mayor detalle. En la Sección 9.14 veremos cómo pueden las herramientas CASE (Computer-Aided Software Engineering) proporcionar soporte para el ciclo de vida del desarrollo de sistemas de bases de datos. Concluiremos en la Sección 9.15 con una explicación de propósito y las tareas asociadas con la administración de datos y la administración de bases de datos dentro de una organización.
9.1 El ciclo de vida de los sistemas de información Sistema de información
Los recursos que permiten la recopilación, mación en una determinada organización.
gestión, control y diseminación
de la infor-
Desde la década de 1970, los sistemas de bases de datos han ido sustituyendo de manera gradual a los sistemas basados en archivos como parte de la infraestructura de sistemas de información de las organizaciones. Al mismo tiempo, cada vez se ha hecho más patente que los datos son un recurso comparativo de gran importancia que debe tratarse con respecto, al igual que cualquier otro recurso de la organización. Esto hizo que administración de datos y la administración de bases de datos y qu eran responsables de la gestión y control muchas organizaciones o áreas funciona~s específicos a los que se les atribuyó la de los datos y de la base crearan de datosdepartamentos corporativos, respectivamente. Los sistemas de información incluyen las bases de datos, el software de base de datos, el software de aplicación, el hardware informático y el personal que utiliza y desarrolla el sistema. La base de datos es un componente fundamental de los sistemas de información, y su desarrollo y utilización deben contemplarse desde la perspectiva de los requisitos globales de la organización. Por tanto, el ciclo de vida de los sistemas de información de una organización está inherentemente enlazado con el ciclo de vida del sistema de base de datos que los da soporte. Normalmente, podemos identificar una serie de etapas claras en el ciclo de vida de los sistemas de información: planificación, recopilación y análisis de requisitos, diseño, prototipado, implementación, conversión y manteniendo operativo. En este capítulo vamos a analizar estas etapas desde la perspectiva del desarrollo de un sistema de base de datos. Sin embargo, es importante tener en cuenta que el desarrollo de un sistema de base de datos también debe contemplarse desde la perspectiva más amplia del desarrollo de lo que no es, en definitiva, sino un componente del sistema de información corporativo.
Capítulo 9 Planificación, diseño y administración de bases de datos
259
A lo largo de este capítulo utilizaremos los términos 'área funcional' y 'área de aplicación' para referimos a actividades empresariales concretas dentro de una organización, como por ejemplo marketing, personal o control de almacén.
9.2 El ciclo de vida del desarrollo de sistemas de base de datos Como los sistemas de base de datos son un componente fundamental de los sistemas de información corporativos, el ciclo de vida del desarrollo de sistemas de bases de datos está inherentemente asociado con el de los propios sistemas de información. La Figura 9.1 muestra las etapas del ciclo de vida del desarrollo de sistemas de base de datos. Debajo del nombre de cada etapa se indica la sección de este capítulo donde se la describe. Es importante tener en cuenta que las etapas del ciclo de vida del desarrollo de sistemas de base de datos no son estrictamente secuenciales, sino que existe una cierta repetición de las etapas anteriores a través de lo que se denomina bucles de realimentación. Por ejemplo, los problemas que se encuentren durante el diseño de la base de datos pueden necesitar una nueva labor de recopilación y análisis de requisitos adicionales. Puesto que existen bucles de realimentación entre la mayoría de las etapas, en la Figura 9.1 solamente se muestran alguno de los más obvios. La Tabla 9.1 proporciona un resumen de las actividades principales asociadas con cada etapa del ciclo de vida del desarrollo de sistemas de base de datos. Tabla 9.1. Resumen de las actividades principales asociadas con cada etapa del ciclo de vida del desarrollo de sistemas de base de datos. Actividades
Etapa Planificación
de la base de datos
principales
Planificación del modo en que pueden llevarse a cabo las distintas etapas del ciclo de vida de la forma más eficiente y efectiva.
Definición del sistema
Especificación del ámbito y los límites del sistema de base de datos, incluyendo las principales vistas de usuario, los tipos de usuario y las áreas de aplicación.
Recopilación y análisis de requisitos
Recopilación y análisis de los requisitos del nuevo sistema de base de datos.
Diseño de la base de datos
Diseño conceptual, lógico y físico de la base de datos.
Selección del SGBD (opcional)
Selección de un SGBD adecuado para el sistema de base de datos.
Dise,
Diseño de la interfaz de usuario y de los programas de aplicación que sirvan para utilizar y procesar los datos de la base de datos.
de la aplicación
Prototipado (opcional)
Construcción de un modelo funcional del sistema de base de datos que permite a los diseñadores o usuarios visualizar y evaluar el aspecto y la función del sistema final.
lmplementación
Creación de las definiciones físicas de la base de datos y de los programas de aplicación.
Conversión y carga de los datos
Carga de los datos del antiguo sistema en el nuevo y, siempre que sea posible, conversión de las aplicaciones existentes para que se ejecuten sobre la nueva base de datos.
Pruebas
Prueba de la base de datos en busca de errores y validación de la misma con respecto a los requisitos especificados por los usuarios.
Mantenimiento
operativo
El sistema de base de datos está complemente implementado, después de lo cual se lo monitoriza y mantiene de manera continua. Cuando sea necesario, se incorporarán nuevos requisitos al sistema de base de datos aplicando de nuevo las etapas precedentes del ciclo de vida.
260
Sistemas de bases de datos
Planificación de la base de datos (Sección 9.3)
Definición del sistema (Sección 9.4)
Recopilación y análisis de requisitos (Sección 9.5
Diseño de la base de datos (Sección 9.6
I
Diseño conceptual de la base de datos Selección del SGBD Diseño de la aplicación (Sección 9.8)
(opcional) (Sección 9.7) Diseño lógico de la base de datos
Diseño físico de la base de datos
Prototipado (opcional) (Se~ción 9.9)
Implementación (Sección 9.10)
Conversión y carga de los datos (Sección 9.11)
Pruebas (Sección 9.12)
Mantenimiento operativo (Sección 9.13)
Figura 9.1.
Las etapas
del ciclo de vida del desarrollo
de sistemas
de base de datos.
Capítulo 9 Planificación, diseño y administración de bases de datos
261
Para pequeños sistemas de base de datos, con un número reducido de usuarios, el ciclo de vida necesita ser muy complejo. Sin embargo, cuando se están diseñando sistemas de base de datos de tamaño medio o grande, con decenas o miles de usuarios que utilizan centenares de consultas y programas de aplicación, el ciclo de vida puede llegar a ser extremadamente complejo. A lo largo de este capítulo nos centraremos en las actividades asociadas con el desarrollo de sistemas de base de datos de tamaño medio o grande. En las siguientes secciones se describen con más detalle las actividades principales asociadas con cada etapa del ciclo de vida del desarrollo de sistemas de base de datos.
9.3 Planificación de la base de datos Planificación de la base de datos
Las actividades de gestión que permiten llevar a cabo las distintas etapas del ciclo de vida del desarrollo de sistemas de base de datos de la forma más eficiente y efectiva posible.
La planificación de la base de datos debe estar integrada con la estrategia global de sistemas de información de la organización. Son tres las cuestiones principales que hay que considerar a la hora de formular una estrategia para los sistemas de información: •
identificación de los planes y objetivos de la empresa, con la subsiguiente determinación de las necesidades de los sistemas de información;
•
evaluación de los sistemas de información actuales para determinar las fortalezas y debilidades existentes;
•
aprovechamiento taja competitiva.
de oportunidades en tecnologías de la información que puedan proporcionar una ven-
Las metodologías utilizadas para resolver estas cuestiones caen fuera del alcance de este libro; sin embargo, el lector interesado puede encontrar en Robson (1997) un análisis más detallado. Un paso importante antes de comenzar la planificación de la base de datos consiste en enunciar claramente la misión del sistema de base de datos. El enunciado de la misión define los objetivos principales del sistema. Las personas encargadas de sacar adelante el proyecto de base de datos dentro de la organización (como, por ejemplo, el director y/o el propietario) son quienes definen normalmente cuál es esa misión. Enunciar la misión ayuda a clarificar el propósito del sistema de base de datos y a proporcionar una ruta más clara que conduzca a la creación del sistema de base de datos requerido de forma efectiva y eficiente. Una vez definida la JUisión, identificar losbase objetivos de debe la misión. Cada objetivo misión ®bé identificarla siguiente una tarea actividad concreta aimplica la que el sistema de de datos proporcionar soporte.deLala suposición en que esto se basa es que, si el sistema de base de datos soporta adecuadamente los objetivos de la misión, podrá cumplirse con esa misión de forma satisfactoria. El enunciado y los objetivos de la misión pueden acompañarse de cierta información adicional que especifique en términos generales la tarea que hay que realizar, los recursos con los que hay que llevarla a cabo y el dinero que debe costar. Ilustraremos el proceso de definición de la misión y de los objetivos de la misión para el sistema de base de datos de DreamHome en la Sección 10.4.2. La planificación de la base de datos debe también incluir el desarrollo de estándares que regulen cómo recopilar los datos, cómo especificar el formato, qué documentación hará falta y cómo debe procederse al diseño y la implementación. Puede consumir mucho tiempo desarrollar y mantener los estándares, debiendo asignarse recursos para su definición inicial y para encargarse del mantenimiento posterior. Sin embargo, un conjunto de estándares bien diseñado proporciona una base para formar al personal y para efectuar un control de calidad, y puede garantizar que el trabajo se adapte a unas ciertas normas, independientemente de las capacidades y la experiencia de los empleados. Por ejemplo, una serie de reglas específicas pueden determinar cómo deben asignarse nombres a los elementos que componen el diccionario de datos, lo que a su vez puede impedir la aparición de redundancia o de incoherencias. Es necesario documentar todas las normas legales o empresariales relativas a los datos, como por ejemplo las normas que indican que ciertos tipos de datos deben tratarse de forma confidencial.
262
Sistemas de bases de datos
9.4 Definición del sistema Definición del sistema
Describe el ámbito y los límites de la aplicación de base de datos y las principales vistas de usuario.
Antes de empezar con el diseño de un sistema de base de datos, resulta esencial que identifiquemos primero los límites del sistema que se pretende diseñar y el modo en que éste debe interactuar con otras partes del sistema de información de la organización. Es importante incluir dentro de las fronteras del sistema no sólo los usuarios y áreas de aplicación actuales, sino también los futuros usuarios y aplicaciones. En la Figura 10.10 se presenta un diagrama que ilustra el ámbito y los límites del sistema de base de datos de DreamHome. Dentro de ese ámbito del sistema de base de datos deben estar incluidas las principales vistas de usuario a las que la base de datos deberá dar soporte.
9.4.1 Vista de usuario Vista de usuario
Define qué tiva de un Supervisor) personal o
es lo que se requiere de un sistema de base de datos desde la perspecdeterminado rol de la organización (como, por ejemplo, Gerente o o de un área de aplicación empresarial (como, por ejemplo, marketing, control de almacén).
Un sistema de base de datos puede tener una o más vistas de usuario. La identificación de las vistas de usuario es un aspecto de gran importancia a la hora de desarrollar un sistema de base de datos, porque ayuda a garantizar que no se deje de lado a ninguno de los usuarios principales de la base de datos a la hora de desarrollar los requisitos para el nuevo sistema. Las vistas de usuario también son particularmente útiles en el desarrollo de un sistema de base de datos relativamente complejo, al permitir descomponer los requisitos en una serie de piezas más manejables. Una vista de usuario define lo que se requiere del sistema de base de datos en términos de los datos que hay que almacenar y de las transacciones que hay que ejecutar con dichos datos (en otras palabras, lo que los usuarios harán con los datos). Los requisitos relativos a una vista de usuario pueden diferir de los de otras vistas, o solaparse con ellos. La Figura 9.2 es un diagrama que representa un sistema de base de datos con múltiples vistas de usuario (denominadas vista de usuario 1 a 6). Observe que, mientras que las vistas de usuario (1,2,3) Y (5 Y 6) tienen requisitos solapados (que se muestran como áreas sombreadas), la vista de usuario 4 tiene requisitos completamente independientes.
9.5 RecopiÍación y análisis de requisitos Recopilación y análisis de
requisitos
El proceso de recopilar y analizar la información acerca de la parte de la organización a la que el sistema de base de datos tenga que dar soporte, y utilizar esta información para identificar los requisitos relativos al nuevo sistema.
Esta etapa implica la recopilación y análisis de información acerca de aquella parte de la empresa a la que la base de datos debe dar servicio. Existen muchas técnicas para recopilar esta información, denominadas técnicas de determinación de hechos, de las que hablaremos en detalle en el Capítulo 10. Se recopila información para cada una de las vistas de usuario principal (es decir, para cada uno de los puestos de trabajo o áreas de aplicación empresarial), incluyendo: •
una descripción de los datos utilizados o generados;
•
los detalles acerca de cómo hay que utilizar o generar los datos;
•
cualesquiera otros requisitos que sean aplicables al nuevo sistema de base de datos.
Esta información se analiza a continuación para identificar los requisitos (o características) que hay que incluir en el nuevo sistema de base de datos. Estos requisitos se describen en una serie de documentos a los que se denomina colectivamente especificaciones de requisitos para el nuevo sistema de base de datos.
Capítulo 9 Planificación, diseño y administración de bases de datos
263
Vista de usuario 2
Base de datos Sistema de bases de datos
Figura 9.2. Representación de un sistema de base de datos con múltiples vistas de usuario: las vistas de usuario (1, 2, 3) Y (5 Y 6) tienen requisitos que se solapan (mostrados como áreas sombreadas), mientras que la vista de usuario 4 tiene requisitos completamente independientes.
La recopilación y análisis de requisitos es una de las etapas preliminares en el diseño de base de datos. La cantidad de datos recopilados dependerá de la naturaleza del problema y de las políticas vigentes en la empresa. Un estudio demasiado detallado al principio conduce a lo que se denomina parálisis por el análisis. Un estudio demasiado superficial puede dar como resultado un desperdicio tanto de tiempo como de dinero debido al trabajo dedicado a obtener la solución incorrecta para el problema inapropiado. n~ La¡información requisitos informales, recopilada que en deberán esta etapaserpuede convertidos no estarendemasiado un enunciado estructurada de requisitos y puede másincluir estructurados. determiEsto se consigue empleando técnicas de especificación de requisitos, que incluyen, por ejemplo: técnicas SAD (Structured Analysis and Design, diseño y análisis estructurados), diagramas DFD (Data Flow Diagrams, diagramas de flujo de datos), HIPO (Hierarchical Input Process Output, diagrama jerárquico de entrada, salida y procesamiento), con el correspondiente soporte documental. Como veremos en breve, las herramientas CASE (Computer-Aided Software Engineering) pueden servir como ayuda a la automatización para garantizar que los requisitos sean completos y coherentes. En la Sección 25.7 veremos cómo soporta el lenguaje UML (Unified Modeling Language, lenguaje unificado de modelado) la recopilación y análisis de requisitos. La identificación de la funcionalidad requerida de un sistema de base de datos es una actividad de importancia crítica, ya que los sistemas con una funcionalidad inadecuada o incompleta constituirán una auténtica molestia para los usuarios, lo que puede conducir a un rechazo o a una infrautilización del sistema. Sin embargo, también puede ser problemática una funcionalidad excesiva, ya que puede complicar demasiado un sistema, haciéndolo difícil de implementar, mantener o utilizar o aprender. Otra actividad importante asociada con esta etapa es la de decidir cómo resolver aquellas situaciones en las que haya más de una vista de usuario para el sistema de base de datos. Existen tres técnicas principales para gestionar los requisitos de un sistema de base de datos que tengan múltiples vistas de usuario: •
el enfoque centralizado;
264
Sistemas de bases de datos
• •
el enfoque de integración de vistas; una combinación de ambas técnicas.
9.5.1 Enfoque centralizado Enfoque centralizado
Los requisitos de cada vista de usuario se combinan en un único conjunto de requisitos para el nuevo sistema de base de datos. Durante la etapa de diseño de la base de datos se crea un modelo de datos que representa todas las vistas de usuario.
El enfoque centralizado implica combinar los requisitos de las diferentes vistas de usuario en una única lista de requisitos. A la recopilación de las vistas de usuario se le asigna un nombre que proporciona algún tipo de indicación del área funcional cubierta por esa combinación de vista. En la etapa de diseño de la base de datos (véase la Sección 9.6), se creará un modelo global de los datos que represente todas las vistas de usuario. El modelo global de los datos está compuesto por una serie de diagramas y documentación que describen formalmente los requisitos de datos de los usuarios. En la Figura 9.3 se muestra un diagrama que representa la gestión de tres vistas de usuario mediante el enfoque centralizado. Generalmente se tiende a preferir este enfoque cuando haya un solapamiento significativo de los requisitos de cada vista de usuario y el sistema de base de datos no sea en exceso complejo.
9.5.2 Enfoque de integración de las vistas Enfoque de integración de las vistas
Los requisitos de cada vista de usuario se mantienen en listas separadas. Durante la etapa de diseño de la base de datos se crean y combinan los modelos de datos que representan cada una de las vistas de usuario.
El enfoque de integración de vistas implica mantener los requisitos de cada vista de usuario en una lista separada. En la etapa de diseño de la base de datos (véase la Sección 9.6) se crea primero un modelo de datos para cada vista de usuario. Los modelos de datos que representan una única vista de usuario (o un subconjunto de
CJ
Requisitos de la vista de usuario 1
Modelo ER
CJ
Requisitos de la vista de usuario 2
CJ
Requisitos de la vista de usuario 3
CJ
Requisitos de todas las vistas de usuario
+
o
Relaciones, diccionario de datos y otra documentación de soporte Modelo global de datos
Figura 9.3.
El enfoque centralizado de gestión de múltiples vistas de usuario.
Sistema de base de datos
Capítulo 9 Planificación, diseño y administración de bases de datos
265
todas las vistas de usuario) se denomina modelos de datos locales. Cada modelo está compuesto por una serie de diagramas y de documentación que describe formalmente los requisitos de una o más vistas de la base de datos, aunque no de todas ellas. Después se combinan los modelos de datos locales en una etapa posterior del diseño de la base de datos para producir un modelo global de datos, que representa todos los requisitos de usuario para la base de datos. En la Figura 9.4 se representa un diagrama de la gestión de tres vistas de usuario mediante el enfoque de integración de vistas. Generalmente se tiende a preferir este enfoque cuando haya diferencias significativas entre las vistas de usuario y el sistema de base de datos sea suficientemente complejo como para justificar la división del trabajo en una serie de componentes más manejables. Ilustraremos la utilización del enfoque de integración de vistas en el Paso 2.6 del Capítulo 16. Para algunos sistemas de base de datos complejos, puede resultar apropiado utilizar una combinación de los enfoques centralizado y de integración de vistas, con el fin de gestionar múltiples vistas de usuario. Por
-°1
uisitos de la
I
Ot-w
vista de datos usuario 23 1
-~~_._--.-.-
Modelos
I
11
[KJ---[[]
Vista de de ~ usuario Vista Vista de usuario++ 31 2
locales de
+
-Di
Modelo ER
o +
Sistema de base de datos
Relaciones, diccionario de datos y otra documentación de soporte Modelo global de datos
Figura 9.4.
Enfoque de integración de vistas para la gestión de múltiples vistas de usuario.
266
Sistemas de bases de datos
ejemplo, los requisitos de dos o más vistas de usuario pueden primero combinarse utilizando el enfoque centralizado, lo que resulta útil para construir un modelo lógico local de los datos. Este modelo puede después combinarse con otros modelos lógicos locales de los datos utilizando el enfoque de integración de vistas, con el fin de producir un modelo lógico global de los datos. En este caso, cada modelo lógico local de datos representa los requisitos de dos o más vistas de usuario y el modelo lógico global de los datos representa los requisitos de todas las vistas de usuario del sistema de base de datos. Veremos con más detalle cómo gestionar múltiples vistas de usuario en la Sección 10.4.4 e ilustraremos, utilizando la metodología descrita en este libro, cómo construir una base de datos para el caso de estudio de la base de datos de alquileres de DreamHome utilizando una combinación de los enfoques centralizado y de integración de vistas.
9.6 Diseño de la base de datos Diseño de la base de datos
El proceso de creación de un diseño que dé soporte a la misión y a los objetivos de la misión de la empresa para el sistema de base de datos requerido.
En esta sección se presenta una panorámica de las técnicas principales del diseño de bases de datos. También se analiza el propósito y la utilización del modelado de datos en el diseño de bases de datos. Después se describen las tres fases del diseño de bases de datos, es decir, el diseño conceptual, lógico y físico.
9.6.1 Técnicas de diseño de bases de datos Las dos técnicas principales de diseño de base de datos se denominan técnicas 'de abajo a arriba' y 'de arriba a abajo'. La técnica de abajo a arriba comienza en el nivel fundamental de los atributos (es decir, de las propiedades de las entidades y relaciones) que, mediante análisis de las asociaciones entre los atributos, se agrupan para formar relaciones que representan tipos de entidades y relaciones entre dichas entidades. En los Capítulos 13 y 14 analizaremos el proceso de normalización, que constituye una técnica de abajo a arriba para el diseño de bases de datos. La normalización implica la identificación de los atributos requeridos y su subsiguiente agregación en una serie de relaciones normalizadas basadas en independencias funcionales entre los atributos. La técnica de abajo a arriba resulta apropiada para el diseño de bases de datos simples que tengan un número relativamente pequeño de atributos. Sin embargo, esta técnica se complica si se la intenta aplicar al diseño de bases de datos más complejas con un mayor número de atributos, en las que puede resultar difícil establecer todas las d~encias funcionales entre unos atributos y otros. Puesto que los modelos de datos conceptuales y lógicos para las bases de datos complejas pueden contener cientos o miles de atributos, resulta esencial utilizar una técnica que permita simplificar el proceso de diseño. Asimismo, en las etapas iniciales de establecimiento de los requisitos de datos para una base de datos compleja, puede resultar difícil determinar todos los atributos que hay que incluir en los modelos de datos. Una estrategia más apropiada para el diseño de bases de datos complejas es la técnica de arriba a abajo. Esta técnica comienza con el desarrollo de modelos de datos que contengan unas pocas entidades y relaciones de alto nivel y luego aplica una serie de refinamientos sucesivos de arriba a abajo para identificar entidades y relaciones de nivel inferior, junto con sus atributos asociados. La técnica de arriba a abajo se ilustra utilizando los conceptos del modelo ER (Entidad-Relacción), comenzando con la identificación de las entidades y de las relaciones entre las entidades que sean de interés para la organización. Por ejemplo, podemos comenzar identificando las entidades PrivateOwner (propietario) y PropertyForRent (inmueble) y luego la relación entre dichas entidades, PrivateOwner Posee PropertyForRent, después de lo cual se identificarán los atributos asociados, tales como PrivateOwner (ownerNo, name y address) y PropertyForRent (propertyNo y address). En los Capítulos 11 y 12 se explica cómo construir un modelo de datos de alto nivel utilizando los conceptos del modelo ER. Existen otras técnicas de diseño de bases de datos, como la técnica 'de dentro hacia afuera' y la técnica de estrategia mixta. La técnica de dentro hacia afuera está relacionada con la técnica de abajo a arriba, pero
Capítulo 9 Planificación, diseño y administración de bases de datos
267
difiere en que primero se identifica un conjunto de entidades principales y luego se lo amplía para considerar otras entidades, relaciones y atributos asociados con aquellas que se han identificado en primer lugar. La estrategia mixta utiliza tanto la técnica de abajo a arriba como la técnica de arriba a abajo para diversas partes del modelo, antes de combinar finalmente todas las diferentes partes.
9.6.2 Modelado de datos Los dos propósitos principales del modelado de datos son ayudar a comprender el significado (semintica) de los datos y facilitar la comunicación de los requisitos de información. La construcción de un modelo de datos requiere responder a una serie de preguntas acerca de las entidades, las relaciones y los atributos. Al formular las respuestas, los diseñadores descubren la semántica de los datos empresariales, la cual existe siempre con independencia de si está representada mediante un modelo de datos formal. Las entidades, relaciones y atributos resultan fundamentales para todas las empresas. Sin embargo, su significado puede no ser adecuadamente comprendido hasta que hayan sido correctamente documentadas. Los modelos de datos hacen que sea más fácil comprender el significado de los datos; por tanto, modelamos los datos para estar seguros de comprender: • • •
la perspectiva que cada usuario tiene de los datos; la naturaleza de los propios datos, independiente de su representación física; la utilización de los datos en distintas vistas de usuario.
Los modelos de datos pueden utilizarse para representar la visión que el diseñador tiene de los requisitos de información de la empresa. Si ambas partes están familiarizadas con la notación utilizada en el modelo, éste mejorará la comunicación entre los usuarios y los diseñadores. Las empresas están estandarizando cada vez más la forma de modelar los datos, seleccionando una técnica concreta de modelado de datos y utilizándola en todos sus proyectos de desarrollo de bases de datos. El modelo de datos de alto nivel más popular de los que se utilizan en el diseño de bases de datos (y el que usaremos en este libro) está basado en los conceptos del modelo de entidad-relación (ER). Hablaremos en detalle de los modelos de entidad-relación en los Capítulos 11 y 12.
Criterios relativos a los modelos de datos Un modelo de datos óptimo debe satisfacer los criterios enumerados en la Tabla 9.2 (Fleming y Van Halle, 1989). Sin embargo, en ocasiones estos criterios no son compatibles entre sí, por lo que se hace necesario llegar a ciertos/compromisos. Pordeejemplo, al tratar de mejorar la capacidad de expresión de un modelo de datos podem6S1Íegar a perder algo simplicidad. Tabla 9.2.
Criterios para generar un modelo de datos óptimo.
Validez estructural
Coherencia con la forma en que la empresa define y organiza la información.
Simplicidad
Facilidad de comprensión por parte de los profesionales de los sistemas de información y por parte de los usuarios no técnicos.
Capacidad de expresión
Capacidad de distinguir entre diferentes datos, relaciones entre los datos y restricciones.
No redundancia
Exclusión de la información no pertinente; en particular, la representación de cada elemento de información una única vez.
Capacidad de compartición
No específico de ninguna aplicación o tecnologías concretas y, como consecuencia, utilizable por muchas aplicaciones o tecnologías.
Ampliabilidad
Capacidad de evolucionar para satisfacer nuevos requisitos con un efecto mínimo sobre los usuarios existentes.
Integridad
Coherencia con la forma en que la empresa utiliza y gestiona la información
Representación
diagramática
Capacidad de representar un modelo utilizando una notación diagramática fácilmente comprensible.
268
Sistemas de bases de datos
9.6.3 Fases del diseño de la base de datos El diseño de la base de datos está compuesto de tres fases principales, denominadas diseño conceptual, diseño lógico y diseño físico.
Diseño conceptual de la base de datos Diseño conceptual de la base de datos
El proceso de construcción de un modelo de los datos utilizados en una empresa, de forma independiente de todas las consideraciones fisicas.
La primera fase del diseño de la base de datos se denomina diseño conceptual de la base de datos e implica la creación de un modelo de datos conceptual para aquella parte de la empresa que queramos modelar. El modelo de datos se construye utilizando la información documentada en la especificación de requisitos de los usuarios. El diseño conceptual de la base de datos es enteramente independiente de los detalles de implementación tales como el software SGBD de destino, los programas de aplicación, los lenguajes de programación, la plataforma hardware o cualquier otra consideración física. En el Capítulo 15 presentaremos una guía práctica paso a paso para el diseño conceptual de la base de datos. Durante el proceso de desarrollo de un modelo conceptual de los datos, el modelo se prueba y se valida de acuerdo con los requisitos de usuario. El modelo conceptual de datos de la empresa es una fuente de información para la siguiente fase, la de diseño lógico de la base de datos.
Diseño lógico de la base de datos Diseño lógico de la base de datos
El proceso de construcción de un modelo de los datos utilizados en una empresa basándose en un modelo de datos específico, pero de forma independiente de un SGBD concreto y de cualquier otra consideración física.
La segunda fase del diseño de la base de datos se denomina diseño lógico de la base de datos, el cual tiene como resultado la creación de un modelo lógico de los datos para la parte de la empresa que queramos modelar. El modelo conceptual de datos creado en la fase anterior se refina y se hace corresponder con un modelo lógico de los datos. Este modelo lógico está basado en el modelo de datos objetivo de la base de datos (por ejemplo, el modelo de datos relacional). Mientras que el modelo conceptual de los datos es independiente de todas las consideraciones fisicas, el modelo lógico se construye conociendo el modelo de datos subyacente del SGBD objetivo. En otras palabras, sabemos que el SGBD~r ejemplo, relacional, en red, jerárquico u orientado a objetos. Sin embargo, no tomamos en consideración ningún otro aspecto del SGBD elegido y, en concreto, hacemos caso omiso de todos los detalles físicos, como puedan ser las estructuras de almacenamiento o los índices. Durante el proceso de desarrollo de un modelo lógico de los datos, el modelo se prueba y se valida de acuerdo con los requisitos de los usuarios. Se utiliza la técnica de la normalización para comprobar la corrección de un modelo lógico de los datos. La normalización garantiza que las relaciones extraídas del modelo de datos no presenten redundancia, que podría provocar anomalías de actualización en la implementación. En el Capítulo 13 ilustraremos los problemas asociados con la redundancia de los datos y describiremos en detalle el proceso de normalización. El modelo lógico de los datos debe también examinarse para garantizar que soporta las transacciones especificadas por los usuarios. El modelo lógico de los datos es una fuente de información para la siguiente fase, la del diseño físico de la fase de datos, proporcionando al encargado de efectuar ese diseño físico una herramienta para alcanzar compromisos que tienen una gran importancia para el diseño eficiente de una base de datos. El modelo lógico también cumple un importante papel durante la etapa de mantenimiento operativo del sistema de base de datos, dentro del ciclo de vida del desarrollo. Si el modelo de datos se mantiene adecuadamente y se conserva actualizado, los futuros cambios que se efectúen en los programas de aplicación o en los datos podrán ser representados de forma precisa y eficiente mediante la base de datos. En el Capítulo 16 se presenta una guía práctica paso a paso para el diseño lógico de la base de datos.
Capítulo 9 Planificación, diseño y administración de bases de datos
269
Diseño físico de la base de datos Diseño físico de la base de datos
El proceso de generar una descripción de la implementación de la base de datos en el almacenamiento secundario; describe las relaciones base, la organización de los archivos y los índices utilizados para conseguir un acceso eficiente a los datos, así como cualesquiera medidas de seguridad y restricciones de integridad asociadas.
El diseño físico de la base de datos es la tercera y última fase del proceso de diseño de la base de datos, fase durante la cual el diseñador decide cómo hay que implementar la base de datos. La fase anterior del diseño de la base de datos implicaba el desarrollo de una estructura lógica para la misma, en la que se describieran las relaciones y las restricciones empresariales. Aunque esta estructura es independiente del SGBD, se desarrolla de acuerdo con un modelo de datos concreto, como por ejemplo el modelo relacional, en red o jerárquico. Sin embargo, al llegar a la fase del diseño físico de la base de datos lo primero que debemos hacer es identificar el SGBD de destino. Por tanto, el diseño físico estará adaptado a un sistema SGBD concreto. Existe una cierta realimentación entre el diseño físico y el diseño lógico, porque durante la fase de diseño físico se toman decisiones de mejora de las prestaciones que pueden afectar a la estructura del modelo lógico de los datos. En general, el objetivo principal del diseño físico de la base de datos consiste en describir cómo pretendemos implementar físicamente el diseño lógico de la base de datos. Para el modelo relacional, esto implica: •
crear un conjunto de tablas relacionales y especificar las restricciones relativas a estas tablas, todo ello a partir de la información presentada en el modelo lógico de los datos;
•
identificar las estructuras de almacenamiento específicas y los métodos de acceso a los datos que permitan conseguir unas prestaciones óptimas en el sistema de base de datos;
•
diseñar las medidas de seguridad del sistema.
Idealmente, los diseños conceptual y lógico de la base de datos para los sistemas de gran tamaño deben estar separados del diseño físico por tres razones principales: •
tratan de un tema diferente: el qué no el cómo;
•
se realizan en un momento distinto; el qué debe comprenderse perfectamente nar el cómo;
antes de poder determi-
• ~eren diferentes capacidades, que a menudo se encuentran en personas distintas. El diseño de bases de datos es un proceso iterativo, que tiene un punto de partida y un número indeterminado de pasadas de refinamiento. En cierto modo, se lo puede considerar una especie de proceso de aprendizaje. A medida que los diseñadores comprenden cada vez mejor el funcionamiento de la empresa y el significado de los datos, y a medida que expresan dicha comprensión en los modelos de datos seleccionados, esa información adicional puede requerir cambios en otras partes del diseño. En particular, los diseños conceptual y lógico de la base de datos resultan críticos para el éxito final del sistema. Si esos diseños no constituyen una verdadera representación de la empresa, será difícil, por no decir imposible, definir todas las vistas de usuario requeridas o mantener la integridad de la base de datos. Puede incluso resultar difícil definir la implementación física o conseguir unas prestaciones del sistema aceptables. Por otro lado, la capacidad para adaptarse a los cambios es una de las medidas de calidad de los diseños de bases de datos. Por tanto, merece la pena invertir el tiempo y la energía necesarios para generar el mejor diseño posible. En el Capítulo 2, hemos analizado la arquitectura ANSI-SPARC en tres niveles de un sistema de base de datos, compuesta por los esquemas externo, conceptual e interno. La Figura 9.5 ilustra la correspondencia entre esta arquitectura y los procesos de diseño conceptual, lógico y físico de la base de datos. En los Capítulos 17 y 18 presentaremos una metodología paso a paso para la fase de diseño físico de la base de datos.
9.7 Selección del SGBD Selección del SGBD
La selección de un SGBD apropiado datos.
para soportar el sistema de base de
270
Sistemas de bases de datos
t
Diseño lógico/conceptual
de la base de datos
t
¡
Diseño físico de la base de datos
Figura 9.5. El modelado de datos en la arquitectura ANSI-SPARC. Si no se dispone ya de un SGBD, una parte apropiada del ciclo de vida en la que se puede realizar la selección es entre las fases de diseño conceptual y lógico de la base de datos (véase la Figura 9.1). Sin embargo, dicha selección puede llevarse a cabo en cualquier instante anterior al diseño lógico, supuesto que haya disponible la suficiente información referida a requisitos del sistema tales como las prestaciones, la facilidad de reestructuración, la seguridad y las restricciones de integridad. Aunque el proceso de selección de un SGBD pueda ser infrecuente, a medida que la empresa necesita expandir o sustituir los sistemas existentes, puede que llegue la ocasión de tener que evaluar nuevos productos SGBD. En tales casos, el objetivo consiste en seleccionar un sistema que satisfaga los requisitos actuales y futuros de la empresa, equilibrando esos requisitos con respecto a los costes relevantes, que incluyen la compra del producto SGBD y de cualquier hardware/software adicional requerido para soportar el sistema de base de datos, y los costes asociados con los cambios y con la formación del personal. Una técnica simple de selección consiste en comparar las características de cada SGBD con los requisitos. Al seleccionar un nuevo producto SGBD, se tiene la oportunidad de garantizar que el proceso de selección esté bien garantizado y que el sistema proporcione beneficios reales a la empresa. En la siguiente sección se describe una técnica típica de selección del 'mejor' SGBD.
9.7.1 SelecciQnAel SGBD Los pasos principales para seleccionar un SGBD son los que se indican en la Tabla 9.3. Tabla 9.3.
Pasos principales para seleccionar un SGBD.
Definición de los términos de referencia del estudio Selección de dos o tres productos candidatos Evaluación de los productos Recomendación
de un producto y generación del informe
Definición de los términos de referencia del estudio Los términos de referencia para la selección del SGBD indican los objetivos y el ámbito del estudio y las tareas que hay que llevar a cabo. Este documento puede también incluir una descripción de los criterios (basados en la especificación de requisitos de los usuarios) que habrá que utilizar para evaluar los productos SGBD, junto con una lista preliminar de posibles productos y una especificación de todas las restricciones necesarias y de los plazos disponibles para el estudio.
Capítulo 9 Planificación, diseño y administración de bases de datos
271
Selección de dos o tres productos candidatos Pueden utilizarse los criterios que se consideren 'críticos' para una adecuada implementación con el fin de generar una lista preliminar de productos SGBD para su evaluación. Por ejemplo, la decisión de incluir un determinado producto SGBD puede depender del presupuesto disponible, del nivel de soporte proporcionado por el fabricante, de la compatibilidad con otros programas y software o de si el producto funciona sobre un hardware concreto. Puede recopilarse información adicional de utilidad sobre un producto contactando con usuarios existentes, los cuales pueden proporcionar detalles concretos sobre la calidad del soporte proporcionado por el fabricante, sobre la compatibilidad del producto con determinadas aplicaciones concretas y sobre si ciertas plataformas hardware son más problemáticas que otras. También puede que haya disponibles pruebas comparativas que permitan evaluar las prestaciones de los diferentes productos SGBD. Tras ese estudio inicial de la funcionalidad y de las características de los productos SGBD, puede identificarse una lista de dos o tres productos candidatos. La World Wide Web es una fuente excelente de información que puede utilizarse para identificar productos SGBD candidatos. Por ejemplo, el sitio web www.intelligententerprise.com proporciona un índice bastante completo de productos SGBD. Los sitios web de los fabricantes pueden también proporcionar información de gran valor sobre los diferentes productos.
Evaluación de los productos Hay varias características que pueden utilizarse para evaluar un producto SGBD. Para propósitos de la evaluación, estas características pueden clasificarse en una serie de grupos (por ejemplo, definición de datos) o evaluarse individualmente (por ejemplo, tipos de datos disponibles). La Tabla 9.4 indica una serie de posibles características para la evaluación del un SGBD, clasificadas en una serie de grupos: definición de datos, definición física, accesibilidad, gestión de transacciones, utilidades, desarrollo y otras características. Tabla 9.4.
Características
para la evaluación de un SGBD.
Definición de los datos
Definición física
Imposición de la clave principal
Estructuras de archivo disponibles
Especificación
Mantenimiento
de la clave externa
de las estructuras de archivos
Tipos de datos disponibles
Facilidad de reorganización
Ampliabilidad
de los tipos de datos
Indexación
Especificación
de dominio
Camposlregistros
de longitud variable
Facilidad de reestructuración
Compresión de los datos
Controles de integridad
Rutinas de cifrado
Mecanismos
Requisitos de memoria
de vistas
Diccionario de datos Independencia
Requisitos de almacenamiento
de los datos
Modelo de datos subyacente Evolución del esquema Accesibilidad
Gestión de transacciones
Lenguaje de consulta: compatible con SQL2/SQL: 2003/ ODMG
Rutinas de copia de seguridad y de recuperación Puntos de comprobación
Interfaz con lenguajes 3GL
Registro de actividades (Continúa)
272
Sistemas de bases de datos Tabla 9.4.
Características
para la evaluación de un SGBD. (Cant.)
Multiusuario
Granularidad de la concurrencia
Seguridad
Estrategia de resolución de interbloqueos
- Controles Oflice Access
Modelos de transacciones
- Mecanismo de autorización
Procesamiento
avanzados
paralelo de consultas
Utilidades
Desarrollo
Medida del rendimiento
Herramientas 4GL/5GL
Optimización
Herramientas
CASE
Facilidades de carga/descarga
Capacidades
de gestión de ventanas
Monitorización
Procedimientos
de la utilización por parte de los usuarios
Soporte para la administración
de la base de datos
Herramientas
almacenados,
disparadores y reglas
de desarrollo web
Otras características Capacidad de actualización
Interoperabilidad
Estabilidad empresarial del fabricante
Integración web
Base de usuario
Utilidades de replicación
Soporte de formación y soporte al usuario
Capacidades
Documentación
Portabilidad
Sistema operativo requerido
Hardware requerido
Coste
Soporte de red
Ayuda en línea
Capacidades de orientación a objetos
Estándares uti Iizados
Arquitectura
Gestión de versiones
Prestaciones
Optimización
de consultas ampliables
con otros SGBD y otros sistemas
distribuidas
(cliente/servidor
Tasa de procesamiento
de 2 o 3 niveles)
de transacciones
Escalabilidad
Número máximo de usuarios concurrentes
Soporte para herramie~alíticas
Soporte para XML
Si nos limitamos a comprobar una a una las características, indicando lo bueno o malo que es el producto en ese aspecto, puede resultar difícil realizar comparaciones entre los diferentes productos SGBD. Una técnica más útil consiste en ponderar las características y/o grupos de características teniendo en cuenta su importancia para la organización, y obtener un valor ponderado global que pueda utilizarse para comparar los productos. La Tabla 9.5 ilustra este tipo de análisis para el grupo de 'Definición física' con un producto SGBD de ejemplo. A cada una de la características mencionadas se le da una puntuación entre 1 y 10 con una ponderación entre O y 1 para indicar su importancia relativa con respecto a otras características del grupo, calculándose luego la puntuación total teniendo en cuenta esas puntuaciones individuales y la respectiva ponderación. Por ejemplo, en la Tabla 9.5 la característica 'Facilidad de reorganización' tiene una puntuación de 4 y una ponderación de 0,25, 10 que nos da un total de 1,0 puntos. Esta característica es la que tiene la mayor ponderación de la tabla, 10 que indica su importancia en esta parte de la evaluación. Además, la característica 'Facilidad de reorganización' tiene una ponderación, por ejemplo, cinco veces superior a la de la característica 'Compresión de datos', que tiene la ponderación más baja, de 0,05. Por su parte, las dos características 'Requisitos de memoria' y 'Requisitos de almacenamiento' tienen una ponderación de 0,00, por lo que no se incluyen en esta evaluación.
Capítulo 9 Planificación, diseño y administración de bases de datos Tabla 9.5.
Análisis de las caracteristicas
273
para la evaluación de un producto SGBD.
SGBD: Producto de ejemplo
Fabricante: Fabricante de ejemplo Grupo de definición física Características
Comentarios
Estructuras de archivo disponibles
Existen 4 distintas
8
Mantenimiento de archivos
NO se autorregula
6 0,25 0,2 0,15 0,15 0,05 0,00 1,0 0,25 0,05
de las estructuras
Puntuación
Facilidad de reorganización
4
lndexación
6
Campos/registros variable
Ponderación 0,15
Puntos O 0,9 0,35 0,2 1,2 1,0 5,75 1,44
6
de longitud
Compresión de los datos
Se especifica con la estructura del archivo
7
Rutinas de cifrado
2 posibilidades
4
distintas
Requisitos de memoria
O
Requisitos de almacenamiento
O
Totales
41
Grupo de definición física
5,75
La puntuación del propio grupo se pondera a continuación para indicar su importancia relativa con respecto a otros grupos de características incluidos en la evaluación. Por ejemplo, en la Tabla 9.5, la puntuación total del grupo de 'Definición fisica' es 5,75; sin embargo, esta puntuación tiene una ponderación de 0,25. Finalmente, se suman todas las puntuaciones ponderadas de cada uno de los grupos de características evaluados con el fin de generar una puntuación final para el producto SGBD, la cual se compara con las puntuaciones de otros productos. El producto con la máxima puntuación es el 'ganador'. Además de este tipo de análisis, también podemos evaluar los productos dejando que los fabricantes efecna endemostrationes la em-¡5resaimplica la mismos creación ode un sistema de utilizando los productos Cadainteruno túen de los comprobando lospruebas productos en la propia empresa. candidatos. La evaluación de los productos se comprueba para verificar su capacidad de satisfacer los requisitos de usuario del sistema de base de datos. En el sitio web www.tpc.org podrá encontrar una serie de pruebas comparativas publicadas por la organización Transaction Processing Council.
Recomendación
de un producto y generación del informe
El paso final en la selección del SGBD consiste en documentar el proceso y proporcionar un informe de todo lo que se haya averiguado para cada producto SGBD concreto y las recomendaciones pertinentes.
9.8 Diseño de la aplicación Diseño de la aplicación
El diseño de la interfaz de usuario y de los programas de aplicación que permiten utilizar y procesar la base de datos.
En la Figura 9.1, observe que el diseño de la base de datos y el diseño de la aplicación son actividades que transcurren en paralelo dentro del ciclo de vida del desarrollo de sistemas de bases de datos. En la mayoría de
274
Sistemas de bases de datos
los casos, no resulta posible completar el diseño de la aplicación hasta que el propio diseño de la base de datos haya finalizado. Por otro lado, el propósito de la base de datos consiste precisamente en dar soporte a las aplicaciones, así que deberá existir un flujo de información entre los procesos de diseño de la aplicación y de diseño de la base de datos. Debemos garantizar que toda la funcionalidad expresada en la especificación de requisitos de los usuarios esté presente en el diseño de la aplicación para el sistema de la base de datos. Esto implica diseñar los programas de aplicación que accedan a la base de datos y diseñar las transacciones, es decir, los métodos de acceso a la base de datos. Además de diseñar cómo hay que obtener la funcionalidad requerida, tenemos que diseñar una interfaz de usuario apropiada para el sistema de base de datos. Esta interfaz debe presentar la información requerida de una manera 'amigable'. A menudo se tiende a ignorar la importancia del diseño de la interfaz de usuario o se deja esta interfaz para las últimas etapas de diseño. Sin embargo, es preciso comprender que la interfaz puede ser uno de los componentes más importantes del sistema. Si es fácil de aprender, sencilla de utilizar, lógica y amigable, los usuarios se sentirán inclinados a hacer un buen uso de la información presentada. Por el contrario, si la interfaz no presenta ninguna de estas características, sin ninguna duda, el sistema causará problemas. En las siguientes secciones vamos a examinar brevemente dos aspectos del diseño de aplicaciones: el diseño de las transacciones y el diseño de la interfaz de usuario.
9.8.1 Diseño de las transacciones Antes de analizar el diseño de las transacciones, vamos primero a describir lo que representa una transacción: Transacción
Una acción o serie de acciones llevadas a cabo por un único usuario o programa de aplicación y que acceden al contenido de la base de datos o los modifican.
Las transacciones representan sucesos 'del mundo real', como la introducción de un inmueble en alquiler, la adicción de un nuevo empleado, el registro de un nuevo cliente o la conclusión de un contrato de alquiler de un inmueble. Estas transacciones tienen que aplicarse a la base de datos para garantizar que los datos contenidos en ésta continúen estando actualizados con respecto a la situación del 'mundo real' y para soportar las necesidades de información de los usuarios. Cada transacción puede estar compuesta por varias operaciones, como por ejemplo la transferencia de dinero desde una cuenta a otra. Sin embargo, desde la perspectiva del usuario, estas operaciones continúan viéndose como una única tarea. Desde el punto de vista del SGBD, una transacción hace que la base de datos pase de ununestado ~ otro. Elgarantiza SGBD garantiza la base deuna datos incluso aunque se produzca fallo. coherente El SG~ambién que, una la vezcoherencia que se ha de completado transacción, los cambios realizados se almacenan de forma permanente en la base de datos y no pueden perderse o deshacerse (sin ejecutar otra transacción para compensar el efecto de la primera. Si la transacción no puede completarse por alguna razón, el SGBD debe garantizar que los cambios realizados por dicha transacción se deshagan. En el ejemplo de la transferencia bancaria, si se extrae dinero de una cuenta y la transacción falla antes de que se haya introducido en la otra, el SGBD debe volver a ingresar el dinero en la cuenta original. Si separáramos las operaciones de extracción de una cuenta y de ingreso en la otra como transacciones separadas, una vez que hubiéramos extraído el dinero de la primera cuenta y completado la transacción, no podríamos deshacer dicho cambio (sin ejecutar otra transacción que ingresara en la cuenta original la cantidad referida). El propósito del diseño de las transacciones consiste en definir y documentar las características de alto nivel en las transacciones requeridas en la base de datos, incluyendo la información siguiente: • •
los datos que tiene que utilizar la transacción; las características funcionales de la transacción;
•
la salida de la transacción;
•
la importancia para los usuarios;
•
la frecuencia esperada de uso.
Capítulo 9 Planificación, diseño y administración de bases de datos
275
Esta actividad debe llevarse a cabo en una fase temprana del proceso de diseño, para garantizar que la base de datos que se implemente sea capaz de soportar todas las transacciones requeridas. Hay tres tipos principales de transacciones: transacciones de extracción, transacciones de actualización y transacciones mixtas . •
Las transacciones de extracción se utilizan para extraer datos con el fin de mostrar/os en la pantalla o para emplear/os en la generación de un informe. Por ejemplo, la operación consistente en buscar y visualizar los detalles de un inmueble (dado el número del inmueble) constituye un ejemplo de transacción de extracción.
•
Las transacciones de actualización se utilizan para insertar nuevos registros, borrar registrós anteriores o modificar registros existentes en la base de datos. Por ejemplo, la operación consistente en insertar los detalles de un nuevo inmueble en la base de datos constituye un ejemplo de transacción de actualización .
•
Las transacciones mixtas implican tanto la extracción como la actualización de datos. Por ejemplo, la operación consistente en buscar y visualizar los detalles de un inmueble (dado el número del inmueble) y luego actualizar el valor del alquiler mensual constituye un ejemplo de transacción mixta.
9.8.2 Directrices de diseño de interfaces de usuario Antes de implementar un formulario o informe, resulta esencial que primero diseñemos su aspecto fisico. En la Tabla 9.6 se enumeran una serie de directrices útiles que pueden seguirse a la hora de diseñar formularios o informes (Shneiderman, 1992).
Título significativo La información proporcionada por el título debe identificar de forma clara y no ambigua el propósito del formulario/informe.
Instrucciones comprensibles Debe utilizarse terminología familiar para proporcionar las instrucciones al usuario. Las instrucciones deben ser breves y, cuando se requiera más información, deben proporcionarse pantallas de ayuda. Las instrucciones deben escribirse con un estilo gramatical coherente, utilizando el formato estándar. Tabla 9.6.
Directrices para el diseño de formularios/informes.
Título significativo Instrucciones Agrupamiento
comprensib]es y secuenciamiento
lógicos de los campos
Diseño visua]mente atractivo de] formu]ariolinforme Etiquetas familiares para los campos Termino]ogía y abreviaturas coherentes Utilización coherente del color Espacio y límites visibles para los campos de introducción de datos Movimiento cómodo del cursor Corrección de errores para caracteres individuales y campos completos Mensajes de error para los valores no aceptables Campos opcionales marcados claramente Mensajes explicativos para los campos Señal de terminación
276
Sistemas de bases de datos
Agrupamiento
y secuenciamiento
lógicos de los campos
Los campos que estén relacionados deben situarse juntos en el formulario/informe. campos debe ser lógico y coherente.
El secuenciamiento
de los
Diseño visual mente atractivo del formulario/informe El formulario/informe debe presentar una interfaz atractiva al usuario. El formulario/informe debe aparecer equilibrado, con los campos o grupos de campos situados de forma homogénea a lo largo del formulario/informe. No debe haber áreas del formulario/informe que tengan demasiados campos o demasiado pocos. Los campos o grupos de campos deben estar separados por un espacio suficiente. Cuando sea apropiado, los campos deberán alinearse vertical u horizontalmente. En aquellos casos en los que un formulario en pantalla tenga un equivalente impreso, la apariencia de ambos formularios debe ser coherente.
Etiquetas familiares
para los campos
Las etiquetas de los campos deben ser familiares. Por ejemplo, si se sustituye Sexo por Género, es posible que algunos usuarios se sientan confundidos-
Terminología
y abreviaturas
coherentes
Debe utilizarse de forma coherente una lista previamente acordada de términos y abreviaturas familiares.
Utilización
coherente del color
Debe utilizarse el color para mejorar la apariencia del formulario/informe y para resaltar los campos o mensajes de mayor importancia. Para conseguir esto, debe utilizarse el color de una forma coherente y significativa. Por ejemplo, los campos de un formulario que tengan un fondo blanco pueden indicar campos de introducción de datos, mientras que aquellos que tengan el fondo azul pueden indicar campos utilizados exclusivamente para la presentación de información.
Espacio y límites visibles para los campos de introducción
de datos
El usuario debe ser visualmente consciente de la cantidad total de espacio disponible para cada campo. Esto permite que el usuario reflexione sobre el formato apropiado para los datos, antes de introducir los valores en el campo.
Movimiento
cómodo del cursor
El usuario debe poderDebenjJtilizarse identifico/" fácilmente la operación desplazarde un cursordea tabulación, lo largo de un formulario/informe. mecanismos simples,requerida como lapara utilización la tecla de las flechas o del puntero del ratón.
Corrección de errores para caracteres individuales y campos completos El usuario debe poder identificar fácilmente la operación requerida para efectuar correcciones en los valores de los campos. Deben proporcionarse mecanismos simples, como la utilización de la tecla de retroceso o la sobreescritura de la información anterior.
Mensajes de error para los valores no aceptables Si un usuario intenta introducir datos incorrectos en un campo, debe mostrarse un mensaje de error. El mensaje debe informar al usuario del error e indicar los valores permitidos.
Campos opcionales marcados claramente Los campos opcionales deben estar claramente identificados para el usuario. Esto puede conseguirse utilizando una etiqueta de campo apropiada o mostrando el campo con un color que indique su tipo. Los campos opcionales deben situarse después de los campos obligatorios.
Capítulo 9 Planificación, diseño y administración de bases de datos
Mensajes explicativos
277
para los campos
Cuando un usuario sitúa un cursor sobre un campo, debe aparecer la información sobre el campo en una posición fija de la pantalla, como por ejemplo la barra de estado de la ventana.
Señal de terminación Debe quedar claro para el usuario cuándo se ha completado el proceso de introducción de datos en los campos de un formulario. Sin embargo, la propia opción de completar el proceso no debe ser automática, ya que el usuario puede desear revisar los datos que ha introducido.
9.9 Prototipado En varios puntos del proceso de diseño, tenemos la opción de implementar completamente el sistema de base de datos o construir un prototipo. Prototipado
Construcción
de un modelo operativo de un sistema de base de datos.
Un prototipo es un modelo operativo que no tiene, normalmente, todas las características requeridas ni proporciona toda la funcionalidad del sistema final. El principal propósito de desarrollar un sistema de base de datos prototipo es permitir a los usuarios utilizar el prototipo para identificar las características del sistema que funcionan bien o que son inadecuadas y, si es posible, sugerir mejoras o incluso nuevas características que el sistema de base de datos deba poseer. De esta forma, podemos clarificar enormemente los requisitos de usuario tanto para los usuarios como para los desarrolladores del sistema y evaluar la factibilidad de un diseño concreto del sistema. Los prototipos deben tener la ventaja principal de ser relativamente baratos y rápidos de construir. Hay dos estrategias de prototipo que se utilizan de forma común hoy en día. El prototipado de requisitos y el prototipado evolutivo. El prototipado de requisitos utiliza el prototipo para determinar los requisitos de un sistema de base de datos propuesto y, una vez completados los requisitos, el prototipo se descarta. Por su parte, el prototipado evolutivo se utiliza para el mismo propósito, pero la diferencia fundamental es que el prototipo no se descarta sino que, con un desarrollo interior, se termina transformando en el sistema final de base de datos.
)
9.10 Implementación Implementación
La realización física del diseño de la base de datos y del diseño de las aplicaciones.
Al completar las etapas de diseño (que pueden o no incluir tareas de prototipado) ya nos encontramos en situación de poder implementar la base de datos y los programas de aplicación. La implementación de la base de datos se lleva a cabo utilizando el lenguaje de definición de datos (DDL) del SGBD seleccionado o una interfaz gráfica de usuario (GUl, Graphical User Interface), que proporciona la misma funcionalidad al mismo tiempo que oculta las instrucciones DDL de bajo nivel. Las instrucciones DDL se emplean para crear las estructuras de la base de datos y una serie de archivos de la base de datos vaCÍos. En esta etapa se implementan también las vistas de usuario especificadas. Los programas de aplicación se implementan utilizando el lenguaje de tercera o cuarta generación (3GL o 4GL) que se prefiera. Partes de estos programs de aplicación son las transacciones de la base de datos, que se implementan utilizando el lenguaje de manipulación de datos (DML) del SGBD objetivo, posiblemente integrado dentro de un lenguaje de programación HOST, como Visual Basic (VB), VB.net, Python, Delphi, C, C++, C#, lava, COBOL, Fortran, Ada o Pascal. También se implementan los otros componentes del diseño de la aplicación, como pantallas de menús, formularios de introducción de datos e informes. De nuevo, el SGBD objetivo puede tener sus propias herramientas de cuarta generación que permitan el desarrollo rápido de aplicaciones mediante el uso de lenguajes de consulta no procedimentales, herramientas de generación de informes, generadores de formularios y generadores de aplicaciones.
278
Sistemas de bases de datos
También hay que implementar los controles de seguridad e integridad para el sistema. Algunos de estos controles se implementan utilizando el DDL, pero puede que otros haya que definidos fuera del DDL, utilizando, por ejemplo, una serie de utilidades suministradas por el SGBD o una serie de controles del sistema operativo. Observe que SQL (Structured Query Language) es tanto un DDL como un DML, como se describe en los Capítulos 5 y 6.
9. 11 Conversión y carga de los datos Conversión y carga de los datos
Transferencia de los datos existentes a la nueva base de datos y conversión de las aplicaciones existentes para que se ejecuten con la nueva base de datos.
Esta etapa sólo es necesaria cuando se está sustituyendo un sistema anterior mediante un nuevo sistema de base de datos. Hoy en día, resulta común que los SGBD dispongan de una utilidad para cargar archivos ya existentes en la nueva base de datos. Dicha utilidad, normalmente requiere que se especifique el archivo de origen en la base de datos de destino, después de lo cual convierte automáticamente los datos al formato requerido para los nuevos archivos de base de datos. Cuando sea aplicable, el desarrollador puede convertir y utilizar programas de aplicación del antiguo sistema, para usados en el nuevo. Cuando los procesos de conversión y de carga sean necesarios, dichos procesos deben planificarse de la forma adecuada para garantizar una transición suave a la etapa de plena operación.
9.12 Pruebas
Pruebas El proceso de operar el sistema de base de datos con la intención de localizar posibles errores.
Antes de entrar en producción, el nuevo sistema de base de datos debe comprobarse cuidadosamente. Esto se lleva a cabo utilizando estrategias de prueba cuidadosamente planeadas y datos realistas, de modo que todo el proceso de pruebas se realiza de forma metódica y rigurosa. Observe que no hemos utilizado en nuestra definición de pruebas el concepto común de que las pruebas son el proceso de demostración de que no hay presente ningún fallo. De hecho, las pruebas no pueden demostrar la ausencia de fallos; lo único que pueden demostrar es que existe el fallo software. Si las pruebas se llevan a cabo adecuadamente, se podrán descubrir derivado es ue las pruebas demuestran que la base de datos y los programas de aplicación parecen funcioerrores en ~o de aplicacióny y, estructura deparecen la base satisfacerse. de datos. Otro beneficio nar de acu rdoprogramas con la especificación queposiblemente, los requisitos endelaprestaciones Además, las métricas recopiladas en la etapa de pruebas proporcionan una medida de la fiabilidad y calidad del software. Al igual que sucede con el diseño de la base de datos, los usuarios del nuevo sistema también deben involucrarse en el proceso de pruebas. La situación ideal para las pruebas de un sistema consiste en disponer de una base de datos de prueba sobre un sistema hardware independiente, pero a menudo no se dispone de tantas facilidades. Si hay que utilizar datos reales, resulta esencial que se realicen copias de seguridad, por si acaso se produjera algún error. Las pruebas también deben cubrir los aspectos de usabilidad del sistema de base de datos. Idealmente, debe realizarse una evaluación de acuerdo con una especificación de usabilidad. Como ejemplos de criterios que pueden emplearse para llevar a cabo esa evaluación, podemos citar (Sommerville, 2002): •
Facilidad de aprendizaje. ¿Cuánto tiempo requiere un nuevo usuario para comenzar a ser productivo con el nuevo sistema?
•
Prestaciones. ¿Hasta qué punto se adapta la respuesta del sistema a las prácticas de trabajo del usuario?
•
Robustez. ¿Hasta qué punto es el sistema tolerante a los errores de los usuarios?
•
Capacidad de recuperación. ¿Es capaz el sistema de recuperarse adecuadamente del usuario?
después de un error
Capítulo 9 Planificación, diseño y administración de bases de datos •
Adaptabilidad.
279
¿Hasta qué punto está el sistema ligado a un determinado modelo de trabajo?
Algunos de estos criterios pueden evaluarse en otras etapas del ciclo de vida. Después de completar las pruebas, el sistema de base de datos estará listo para su aceptación y su entrega a los usuarios.
9.13 Mantenimiento operativo Mantenimiento operativo
El proceso de monitorizar y mantener el sistema de base de datos después de la instalación.
En las etapas anteriores, e] sistema de base de datos ha sido completamente implementado y probado. Ahora, el sistema se mueve a la etapa de mantenimiento, que implica las siguientes actividades: •
Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un nivel aceptable, puede que se necesite optimizar o reorganizar la base de datos.
•
Mantenimiento y actualización del sistema de base de datos (cuando sea requerido). Se incorporan nuevos requerimientos al sistema de base de datos recorriendo otra vez las etapas precedentes del ciclo de vida.
Una vez que el sistema de base de datos está completamente operativo, se lleva a cabo una monitorización cuidadosa para garantizar que las prestaciones continúan estando dentro de los niveles aceptables. Un SGBD proporciona normalmente diversas utilidades como ayuda para administración de base de datos, incluyendo utilidades para cargar datos en una base de datos y para monitorizar el sistema. Las utilidades de monitorización del sistema proporcionan información sobre, por ejemplo, ]a utilización de la base de datos, la eficiencia de bloqueo (incluyendo el número de interb]oqueos que se han producido, etc.) y la estrategia de ejecución de consultas. El administrador de la base de datos (DBA) puede utilizar esta información para afinar el sistema con e] fin de obtener mejores prestaciones, por ejemplo creando índices adicionales para acelerar las consu]tas, alterando las estructuras de almacenamiento o combinando o dividiendo tablas. El proceso de monitorización continuará durante toda ]a vida del sistema de base de datos y, a su debido tiempo, puede conducir a la reorganización de la base de datos para satisfacer los cambios en los requisitos. Estos cambios proporcionan, a su vez, información sobre ]a evolución probable de] sistema y los futuros recursos que pueden llegar a ser necesarios. Esto, junto con el conocimiento de las nuevas aplicaciones propuestas, permite al DBA realizar ]a planificación de la capacidad y notificar o alertar a los gerentes de alto nivel para que ajusten sus planes de forma correspondiente. Si el SGBD carece de ciertas utilidades, el DBA tes, si es que están disponibles. Hablaremos con más detalle de la administración de la base de datos en ]a Seccióndesarrollar 9.15. ) puede internamente las utilidades requeridas o comprar herramientas adicionales de otros fabricanCuanto pasa a estar en línea (operativa) una nueva aplicación de base de datos, los usuarios deben utilizarla en paralelo con el antiguo sistema durante un periodo de tiempo. Esto permite que se salvaguarden las operaciones actuales en caso de que se produzcan problemas no previstos con el nuevo sistema. Será necesario realizar comprobaciones periódicas de la coherencia de los datos entre los dos sistemas y sólo debe prescindirse del sistema antiguo cuando ambos sistemas parezcan estar produciendo los mismos resultados de forma coherente. Si el salto de un sistema a otro es demasiado abrupto, el resultado fina] podría ser desastroso. A pesar de la suposición de que el anterior sistema puede eliminarse porque ambos sistemas arrojan ya resultados coherentes, puede haber situaciones en las que se decida mantener ambos sistemas.
9.14 Herramientas CASE La primera etapa del ciclo de desarrollo de un sistema de base de datos, la de planificación de la base de datos, puede también implicar la selección de las adecuadas herramientas CASE (Computer-Aided Software Engineering). En su sentido más amplio, el término CASE puede aplicarse a cualquier herramienta que dé soporte a la ingeniería de software. El personal de administración de datos y de administración de la base de
280
Sistemas de bases de datos
datos necesita las adecuadas herramientas de productividad para que las actividades de desarrollo de la base de datos se lleven a cabo de la forma más eficiente y efectiva posible. El soporte CASE puede incluir: •
un diccionario de datos para almacenar información acerca de los datos del sistema de base de datos;
•
herramientas de diseño para soportar el análisis de datos;
•
herramientas que permitan el desarrollo del modelo de datos corporativo y de los modelos conceptual y lógico de los datos;
•
herramientas que permitan el prototipado de aplicaciones.
Las herramientas CASE se pueden dividir en tres categorías: CASE de alto nivel, CASE de bajo nivel y CASE integrado, como se ilustra en la Figura 9.6. Las herramientas CASE de alto nivel soportan las etapas iniciales del ciclo de desarrollo de los sistemas de base de datos, desde la planificación hasta el diseño de la base de datos. Las herramientas CASE de bajo nivel soportan las últimas etapas del ciclo de vida, desde la implementación a las pruebas y el mantenimiento operativo. Las herramientas CASE integradas soportan todas las etapas del ciclo de desarrollo y proporcionan, por tanto, la funcionalidad de las herramientas CASE de alto y bajo nivel en una única herramienta.
CASE de alto nivel
Diseño de la base de datos
Diseño de la aplicación
CASE integrado
Prototipado
CASE de bajo nivel
Figura 9.6. Aplicación de las herramientas
CASE.
Capítulo 9 Planificación, diseño y administración de bases de datos
Beneficios de las herramientas
281
CASE
El uso de herramientas CASE apropiadas debería mejorar la productividad del desarrollo de un sistema de base de datos. Utilizamos el término 'productividad' para hacer referencia tanto a la eficiencia del proceso de desarrollo como a la efectividad del sistema desarrollado. El término eficiencia hace referencia al coste, en términos de tiempo y de dinero, de llevar a la práctica el sistema de base de datos. Las herramientas CASE tratan de soportar y automatizar las tareas de desarrollo y mejorar así la eficiencia. La efectividad hace referencia al grado con el que el sistema satisface las necesidades de información de los usuarios. Para tratar de conseguir una mayor productividad, mejorar la efectividad del proceso de desarrollo puede ser aún más importante que mejorar su eficiencia. Por ejemplo, no tendría sentido desarrollar un sistema de base de datos extremadamente eficiente si el producto final no es lo que los usuarios desean. De esta forma, la efectividad está relacionada con la calidad del producto final. Puesto que las computadoras son mejores que los seres humanos para realizar ciertas tareas, por ejemplo las tareas de comprobación de coherencia, pueden utilizarse herramientas CASE para mejorar la efectividad de algunas tareas del proceso de desarrollo. Las herramientas CASE proporcionan los siguientes beneficios que permiten mejorar la productividad: •
Estándares. Las herramientas CASE ayudan a imponer los estándares en un producto software o en toda la organización. Fomentan la producción de componentes de prueba estándar que puedan reutilizarse, simplificando así el mantenimiento e incrementando la productividad.
•
Integración. Las herramientas CASE almacenan toda la información generada en un repositorio, o diccionario de datos, como se explica en la Sección 2.7. Así, debería ser posible almacenar los datos recopilados durante todas las etapas del ciclo de desarrollo del sistema de base de datos. Los datos pueden entonces ponerse en relación para garantizar que todas las partes del sistema estén integradas. De esta forma, el sistema de información de la organización no tiene ya por qué estar compuesto por una serie de componentes independientes y desconectados.
•
Soporte para métodos estándar. Las técnicas estructuradas hacen un uso significativo de diagramas, que son difíciles de dibujar y mantener de forma manual. Las herramientas CASE simplifican este proceso, lo que da como resultado una documentación correcta y más actualizada.
•
Coherencia. Puesto que toda la información del diccionario de datos está interrelacionada, mientas CASE pueden comprobar su coherencia.
•
Automatización.
Algunas herramientas CASE puede transformar automáticamente
las herra-
parte de una espe-
implementado, c~cación de diseño y puede en contribuir código ejecutable. a eliminarEsto errores reduce que elaparecen trabajo normalmente requerido paradurante producir el proceso el sistema de codificación. Para obtener más información sobre las herramientas CASE, el lector interesado puede consultar Gane (1990), Batini et al. (1992) y Kendall y Kendall (1995).
9.15 Administración de datos y administración de bases de datos El administrador de datos (DA) y el administrador de la base de datos (DBA) son responsables de gestionar y controlar las actividades asociadas con los datos corporativos y con la base de datos corporativa, respectivamente. El DA se preocupa más de las etapas tempranas del ciclo de desarrollo, desde la planificación hasta el diseño lógico de la base de datos. Por contraste, el DBA está más concentrado en las etapas posteriores, desde el diseño de las aplicaciones y el diseño físico de la base de datos hasta el mantenimiento operativo. En esta sección final del capítulo, hablaremos del propósito y de las tareas asociadas con la administración de datos y la administración de bases de datos.
282
Sistemas de bases de datos
9.15.1
Administración de datos
Administración de datos
La gestión de los recursos de datos, lo que incluye la planificación de la base de datos, el desarrollo y el mantenimiento de estándares, políticas y procedimientos, así como el diseño conceptual y lógico de la base de datos.
El administrador de datos (DA) es responsable de los recursos de datos corporativos, que incluye los datos no informatizados y en la práctica implica a menudo la gestión de los datos compartidos por los distintos usuarios o áreas de aplicación de una organización. El DA es quien tiene la responsabilidad principal de aconsejar a los gerentes de alto nivel y de garantizar que la aplicación de las tecnologías de base de datos continúe dando soporte a los objetivos corporativos. En algunas empresas, la administración de datos es un área funcional independiente, mientras que en otras puede estar combinada con la administración de bases de datos. Las tareas asociadas con la administración de datos se describen en la Tabla 9.7.
9.15.2
Administración de bases de datos
Administración de bases de datos
La gestión de la implementación física de un sistema de bases de datos, lo que incluye el diseño físico de la base de datos y su implementación, la configuración de los controles de seguridad e integridad, la monitorización de las prestaciones del sistema y la reorganización de la base de datos según sea necesario. Tabla 9.7.
Selección de las herramientas de productividad
Tareas de administración
de datos.
apropiadas.
Ayuda en el desarrollo de las estrategias corporativas relativas a las tecnologías de la información y sistemas de información. Realización de estudios de factibilidad y planificación
del desarrollo de la base de datos.
Desarrollo de un modelo de datos corporativo. Determinación Establecimiento
de los requisitos de datos de la organización. de estándares de recopilación de datos y de formatos de los datos.
Estimación de los volúmenes de datos y del crecimiento previsible.
Determinación frecuencias de ladatos utilización los datos. relacionadas Determinación de de los los patrone/> reqursi'tosy de acceso a los y de lasdesalvaguardas riales y legales.
con los requisitos empresa-
Realización del diseño conceptual y lógico de la base de datos. Colaboración con el personal de administración de la base de datos y con los desarrolladores garantizar que las aplicaciones cumplan los requisitos establecidos.
de aplicaciones para
Educación de los usuarios en lo que respecta a los estándares de datos y a las responsabilidades
de carácter legal.
Mantenerse actualizado en lo que respecta a los desarrollos relativos a las tecnologías de la información y sistemas de información. Garantizar que la documentación está actualizada y es completa, incluyendo estándares, políticas, procedimientos, lización del diccionario de datos y controles relativos a los usuarios finales.
uti-
Gestión del diccionario de datos. Colaboración con los usuarios para determinar nuevos requisitos y resolver las dificultades relativas a las prestaciones o al acceso a los datos. Desarrollo de una política de seguridad.
Capítulo 9 Planificación, diseño y administración de bases de datos
283
El personal de administración de la base de datos está más técnicamente orientado que el personal de administración de datos, requiriéndose el conocimiento de productos SGBD específicos y del entorno correspondiente al sistema operativo utilizado. Aunque las responsabilidades principales se centran en el desarrollo y mantenimiento de sistemas utilizando el software SGBD de la mejor forma posible, el DBA también ayuda al DA en otras áreas, como se indica en la Tabla 9.8. El número de personas asignadas al área funcional encargada de la administración de la base de datos es muy variable, estando a menudo determinado por el tamaño de la organización. Las tareas de administración de la base de datos se describen en la Tabla 9.8.
9.15.3
Comparación de las tareas de administración de datos y de administración de la base de datos
En las secciones precedentes hemos examinado el propósito y las tareas asociados con la administración de datos y la administración de la base de datos. En esta sección final vamos a comparar brevemente estas dos áreas funcionales. La Tabla 9.9 resume las principales diferencias en cuanto a tareas de la administración de datos y la administración de la base de datos. Quizá la diferencia más obvia radique en la naturaleza del propio trabajo que se lleva a cabo. El personal de administración de datos tiende a estar mucho más orientado hacia la gestión, mientras que el personal de administración de bases de datos tiende a ser más técnico. Tabla 9.8.
Tareas de administración
de la base de datos.
Evaluación y selección de productos SGBD. Realización del diseño fisico de la base de datos. Implementación
del diseño fisico de la base de datos utilizando un SGBD objetivo.
Definición de las restricciones de seguridad e integridad. Colaboración con los desarrolladores
de aplicaciones de base de datos.
Desarrollo de las estrategias de prueba. Formación de los usuarios. Aprobación final del sistema de base de datos implementado. Monitorización
de las implementaciones
del sistema y optimización de la base de datos, según sea apropiado.
Realización de copias de seguridad rutinarias.
Garantizar la prese~cia de mecanismos y procedimientos de recuperación. Garantizar que 1~6cumentación esté completa, incluyendo el material producido internamente. Mantenerse actualizado en lo que respecta a los desarrollos en el campo del software y el hardware y sus costes correspondientes, e instalar las actualizaciones según sea necesario. Tabla 9.9.
Administración
de datos y administración
de la base de datos:
principales diferencias en cuanto a tareas. Administración
Administración
de datos
Implicado en la planificación de información.
estratégica de los sistemas
de la base de datos
Evalúa nuevos SGBD.
Determina objetivos a largo plazo.
Ejecuta los planes necesarios para conseguir los objetivos.
Impone los estándares, políticas y procedimientos.
Impone los estándares, políticas y procedimientos.
Determina los requisitos relativos a los datos.
Implementa los requisitos relativos a los datos. (Continúa)
284
Sistemas de bases de datos Tabla 9.9.
Administración
Administración de datos y administración de la base de datos: principales diferencias en cuanto a tareas. (Cant.)
de datos
Administración
de la base de datos
Lleva a cabo los diseños conceptual y lógico de la base de datos.
Lleva a cabo los diseños lógico y físico de la base de datos.
Desarrolla y mantiene el modelo de datos corporativo.
Implementa el diseño físico de la base de datos.
Coordina el desarrollo del sistema.
Monitoriza y controla la base de datos.
Orientación de gestión.
Orientación técnica.
Independiente
Dependiente del SGBD.
del SGBD.
Resumen del capítulo •
Un sistema de información está constituido por los recursos que permiten la recopilación, gestión, control y diseminación de la información a lo largo de una organización
•
Un sistema de información basado en computadora incluye los siguientes componentes: base de datos, software de base de datos, software de aplicación, hardware informático (incluyendo los medios de almacenamiento) y el personal que utiliza y desarrolla el sistema.
•
La base de datos es un componente fundamental de los sistemas de información y su desarrollo y utilización deben contemplarse desde la perspectiva de los requisitos globales de la organización. Por tanto, el ciclo de vida de un sistema de información corporativo está inherentemente enlazado con el ciclo de vida de la base de datos que le da soporte.
•
Las etapas principales del ciclo de desarrollo de un sistema de base de datos incluyen: planificación de la base de datos, definición del sistema, recopilación y análisis de requisitos, diseño de la base de datos, selección del SGBD (opcional), diseño de la aplicación, prototipado (opcional), implementación, conversión y carga de los datos, pruebas y mantenimiento operativo.
•
La planificación de la base de datos está compuesta por las actividades de gestión que permiten llevar a cabo las distintas etapas del ciclo de desarrollo de un sistema de base de datos de la forma más eficiente y efectiva posible.
•
La definición del sistema implica identificar el ámbito y las vistas de usuario. Una vista de usuario define lo que perspectiva de un puesto de ~o concreto (como por ción corporativa (como por ejemplo marketing, personal
•
La recopilación y análisis de requisitos es el proceso de recopilar y analizar información acerca de aquella parte de la organización a la que el sistema de base de datos deba dar soporte, así como utilizar esta información para identificar los requisitos del nuevo sistema. Hay tres técnicas principales para gestionar los requisitos de un sistema de bases de datos que tenga múltiples vistas de usuario: el enfoque centralizado, el enfoque de integración de vistas y una combinación de ambos enfoques.
•
El enfoque centralizado implica combinar los requisitos de cada vista de usuario en un único conjunto de requisitos para el nuevo sistema de base de datos. Durante la etapa de diseño de la base de datos se creará un modelo de datos que represente todas las vistas de usuario. En el enfoque de integración de vistas, los requisitos de cada vista de usuario se conservan como listas independientes; durante la etapa de diseño de la base de datos se crean después modelos de datos que representan cada una de las vistas de usuario.
•
El diseño de la base de datos es el proceso de crear un diseño que dé soporte a la misión y a los objetivos de la empresa para el sistema de base de datos requerido. Hay tres fases en el diseño de bases de datos: diseño conceptual, lógico y físico.
los límites del sistema de base de datos, así como se requiere del sistema de base de datos desde la ejemplo Gerente o Supervisor) o de una aplicao control de almacén).
Capítulo 9 Planificación, diseño y administración de bases de datos
285
•
El diseño conceptual de la base de datos es el proceso de construir el modelo de los datos utilizados en una empresa, independientemente de todas las consideraciones físicas.
•
El diseño lógico de la base de datos es el proceso de construir un modelo de los datos utilizados en una empresa basándose en un modelo de datos específico, pero con independencia del SGBD concreto y del resto de consideraciones físicas.
•
El diseño físico de la base de datos es el proceso de generar una descripción de la implementación de la base de datos en almacenamiento secundario; describe las relaciones básicas, la organización de los archivos y los índices empleados para conseguir un acceso eficiente a los datos, así como cualesquiera restricciones de integridad y medidas de seguridad asociadas.
•
La selección del SGBD implica seleccionar un SGBD apropiado para el sistema de base de datos.
•
El diseño de la aplicación implica el diseño de la interfaz de usuario y el diseño de las transacciones, que describen los programas de aplicación que utilizan y procesan la base de datos. Una transacción de base de datos es una acción, o serie de acciones, llevada a cabo por un único usuario o programa de aplicación y que accede al contenido de la base de datos o lo modifica.
•
El prototipado implica la construcción de un modelo operativo de sistema de la base de datos que permita a los diseñadores o usuarios visualizar y evaluar el sistema.
•
La implementación
•
La conversión y carga de los datos implica la transferencia de los datos existentes a la nueva base de datos y la conversión de las aplicaciones existentes para que se ejecuten sobre la nueva base de datos.
•
Las pruebas son el proceso de operar el sistema de base de datos con la intención de localizar posibles errores.
•
El mantenimiento lación.
•
El término CASE (Computer-Aided Software Engineering) se aplica a cualquier herramienta que de soporte a la ingeniería del software y que permita que las actividades de desarrollo del sistema de base de datos se lleven a cabo de la forma más eficiente y efectiva posible. Las herramientas CASE pueden clasificarse en tres categorías: CASE de alto nivel, CASE de bajo nivel y CASE integrado.
•
La administración
•
es la realización física del diseño de la base de datos y del diseño de las aplicaciones.
operativo es el proceso de monitorizar y mantener el sistema después de la insta-
de datos es la gestión de los recursos de datos, incluyendo las tareas de planificación
tual y lógico e la base de datos. de os, desarrollo y mantenimiento estándares, y procedimientos y diseño La base admid~da lstración de la base de datos es ladegestión de la políticas realización física de un sistema de concepbase de datos, incluyendo las tareas de diseño físico de la base de datos e implementación de la misma, configuración de la seguridad y los controles de integridad, monitorización de las prestaciones del sistema y reorganización de la base de datos según sea necesario.
Cuestiones de repaso 9.1.
Describa los componentes principales de un sistema de información.
9.2.
Explique la relación existente entre el ciclo de vida de los sistemas de información desarrollo de los sistemas de bases de datos.
9.3.
Describa el propósito y actividades principales asociados con cada etapa del ciclo de desarrollo de un sistema de base de datos.
9.4.
Explique lo que representa una vista de usuario en el contexto de un sistema de base de datos.
9.5.
Explique las técnicas principales para la gestión del diseño de un sistema de base de datos que tenga múltiples vistas de usuario.
9.6.
Realice una comparación entre las tres fases del diseño de una base de datos.
y el ciclo de
286
Sistemas de bases de datos
9.7.
¿Cuáles son los objetivos principales del modelado de datos? Identifique los criterios aplicables a un modelo de datos óptimo.
9.8.
Identifique la etapa o etapas en las que resulta apropiado seleccionar un SGBD y describa una técnica para elegir el 'mejor' SGBD.
9.9.
El diseño de aplicaciones implica el diseño de las transacciones y el diseño de la interfaz de usuario. Describa el propósito y las actividades principales asociados con cada una de esas tareas.
9.10.
Explique por qué las pruebas no pueden demostrar la ausencia de fallos, sino sólo la presencia de los mIsmos.
9.11.
Describa las principales ventajas de utilizar la técnica de prototipado a la hora de construir un sistema de bases de datos.
9.12.
Defina el propósito y las tareas asociados con la administración de datos y la administración de bases de datos.
Ejercicios 9.13.
Suponga que es responsable de seleccionar un nuevo producto SGBD para un grupo de usuarios de su organización. Para realizar este ejercicio, primero debe establecer una serie de requisitos para el grupo y luego identificar un conjunto de características que el producto SGBD deba presentar con el fin de satisfacer dichos requisitos. Describa un proceso de evaluación y selección del mejor producto SGBD.
9.14.
Describa el proceso de evaluación y selección de un producto SGBD para cada uno de los casos de estudio descritos en el Apéndice B.
9.15.
Averigtie si la administración de datos y la administración de bases de datos existen como áreas funcionales independientes dentro de su organización. Si fuera así, describa la organización, responsabilidades y tareas asociadas con cada una de las dos áreas funcionales.
apltulo
Técnicas de determinación de hechos
Objetivos del capítulo: En este capítulo aprenderá: •
Cuándo se utilizan las técnicas de determinación de hechos a lo largo del ciclo de desarrollo de sistemas de bases de datos.
•
Los tipos de hechos recopilados en cada etapa del ciclo de desarrollo del sistema de bases de datos.
•
Los tipos de documentación producida en cada una de las etapas del ciclo de desarrollo de sistemas de bases de datos.
•
Las técnicas de determinación de hechos más comúnmente utilizadas.
•
Cómo utilizar cada técnica de determinación de hechos y las ventajas y desventajas que cada una tiene.
•
A analizar un caso de estudio: una empresa de alquiler de inmuebles denominada DreamHome.
•
Cómo aplicar las técnicas de determinación de hechos en las primeras etapas del ciclo de desarrollo de sistemas de bases de datos.
En el Capítulo 9 hemos presentado las etapas del ciclo de desarrollo de sistemas de bases de datos. Hay muchas ocasiones, a lo largo de estas etapas, en las que resulta crítico que el desarrollador de la base de datos capture los hechos necesarios para poder construir el sistema de base de datos requerido. Los hechos necesarios incluyen, por ejemplo, la terminología usada dentro de la empresa, los problemas que se han encontrado al utilizar el sistema actual, las oportunidades que se busca aprovechar con el nuevo sistema, las restricciones necesarias sobre los datos y los usuarios del nuevo sistema, y un conjunto de requisitos para el nuevo sistema ordenados según su prioridad. Estos hechos se capturan utilizando las denominadas técnicas de determinación de hechos. Determinación de hechos
El proceso formal de utilizar técnicas tales como entrevistas y cuestionarios recopilar hechos acerca de los sistemas, requisitos y preferencias.
para
En este capítulo veremos cuándo puede un desarrollador de bases de datos utilizar técnicas de determinación de hechos y qué tipos de hechos debe capturar. Presentaremos una panorámica de cómo se emplean estos hechos para generar los tipos principales de documentación utilizada a lo largo del ciclo de desarrollo de sistemas de bases de datos. Describiremos las técnicas de determinación de hechos más comúnmente utilizadas e identificaremos las ventajas y desventajas de cada una. Finalmente, ilustraremos el empleo de algunas de estas técnicas durante las primeras etapas del ciclo de desarrollo de sistemas de bases de datos utilizando una empresa de alquiler de inmuebles denominada DreamHome. El caso de estudio de DreamHome es el que se utiliza a lo largo del libro.
288
Sistemas de bases de datos
Estructura del capítulo En la Sección 10.1 veremos cuándo puede un desarrollador de bases de datos utilizar técnicas de determinación de hechos (a lo largo del libro, utilizamos el término 'desarrollador de bases de datos' para hacer referencia a una persona o grupo de personas responsable del análisis, diseño e implementación de un sistema de bases de datos). En la Sección 10.2 ilustramos los tipos de hechos que deben recopilarse y la documentación que hay que producir en cada etapa del ciclo de desarrollo del sistema de base de datos. En la Sección 10.3 se describen las cinco técnicas de determinación de hechos más comúnmente utilizadas y se identifican las ventajas y desventajas de cada una de ellas. En la Sección lOA se ilustra el empleo de las técnicas de determinación de hechos para desarrollar un sistema de base de datos para un caso de estudio denominado DreamHome, que trata sobre una empresa de alquiler de inmuebles. Comenzaremos dicha sección proporcionando una panorámica del caso de estudio de DreamHome, después de lo cual examinaremos las tres primeras etapas del ciclo de desarrollo de un sistema de base de datos, es decir, la planificación de la base de datos, la definición de sistema y la recopilación y análisis de requisitos. Para cada etapa, ilustraremos el proceso de recopilación de datos utilizando las técnicas de determinación de hechos y describiremos la documentación que se genera.
10.1 ¿Cuándo se utilizan las técnicas de determinación de hechos? Hay numerosas ocasiones en las que realizar una tarea de determinación de hechos durante el ciclo de desarrollo del sistema de base de datos. Sin embargo, la determinación de hechos resulta particularmente crucial en las primeras etapas del ciclo de desarrollo, es decir, durante la planificación de la base de datos, la definición del sistema y la recopilación y análisis de requisitos. Es durante estas primeras etapas cuando el desarrollador de la base de datos captura los hechos esenciales que son necesarios para construir la base de datos requerida. El proceso de determinación de hechos también se emplea durante el diseño de la base de datos y las etapas posteriores del ciclo de desarrollo, aunque en menor medida. Por ejemplo, durante el diseño físico de la base de datos, el proceso de determinación de hechos se hace más técnico a medida que el desarrollador de la base de datos trata de aprender más detalles acerca del SGBD seleccionado para el sistema de base de datos. Asimismo, durante la etapa final, la de mantenimiento operativo, se utiliza un proceso de determinación de hechos para ver si el sistema requiere ser optimizado, con el fin de mejorar las prestaciones, o si son necesarios desarrollos adicionales para incluir nuevos requisitos. Observe que es importante disponer de una estimación del tiempo y el esfuerzo que hay que invertir en el proceso de determinación de hechos para un proyecto de base de datos. Como hemos mencionado en el Capítulo 9, un estudio demasiado detallado demasiado pronto conduce a lo que se conoce como parálisis por el análisis. Sin embargo, un esfuerzo demasiado superficial puede dar como resultado un gasto innecesario tanto de tiempo como de dinero, debido al trabajo invertido en tratar de encontrar la solución incorrecta para el problema erróneo.
10.2 ¿Qué hechos hay que recopilar? A lo largo del ciclo de desarrollo de un sistema de base de datos, el desarrollador de la base de datos necesita capturar hechos diversos acerca del sistema actual y/o futuro. La Tabla 10.1 proporciona ejemplos de los tipos de datos que se capturan y de la documentación producida durante cada etapa del ciclo de desarrollo. Como hemos mencionado en el Capítulo 9, las etapas del ciclo de desarrollo de un sistema de bases de datos no son estrictamente secuenciales, sino que implican cierta cantidad de repetición de las etapas anteriores a través de diversos bucles de realimentación. Esto es cierto también para los datos capturados y para la documentación producida en cada etapa. Por ejemplo, los problemas que se encuentran durante el diseño de la base de datos pueden requerir de una captura de datos adicionales acerca de los requisitos del nuevo sistema.
Capítulo 10 Técnicas de determinación de hechos
289
Tabla 10.1. Ejemplos de los datos capturados y de la documentación producida para cada etapa del ciclo de desarrollo del sistema de base de datos. Etapa del ciclo de desarrollo del sistema de base de datos
Ejemplos de datos capturados
Ejemplos de documentación producida
Planificación de la base de datos
Objetivos del proyecto de base de datos
Enunciado de la misión y objetivos del sistema de base de datos
Definición del sistema
Descripción de las principales vistas de usuario (incluye los puestos de trabajo o las áreas de aplicación empresariales)
Definición del ámbito y de los límites de la aplicación de base de datos; definición de las vistas de usuario que hay que soportar
Recopilación y análisis de requisitos
Requisitos para las vistas de usuario; especificaciones del sistema, incluyendo prestaciones y requisitos de seguridad
Especificación de requisitos de los usuarios y del sistema
Diseño de la base de datos
Respuesta de los usuarios durante la comprobación del diseño lógico de la base de datos; funcionalidad proporcionada por el SGBD objetivo
Diseño conceptual/lógico de la base de datos (incluye modelos ER, diccionario de datos y sistema relacional); diseño fisico de la base de datos
Diseño de la aplicación
Respuesta de los usuarios a las pruebas del diseño de la interfaz
Diseño de la aplicación, incluye la descripción de los programas y de la interfaz de usuario
Selección del SGBD
Funcionalidad proporcionada utilizado
Evaluación de productos SGBD y recomendaciones
Prototipado
Respuesta de los usuarios a las pruebas del prototipo
Implementación
Funcionalidad proporcionada utilizado
Conversión y carga de los datos
Formato de los datos actuales; capacidades de importación de datos del SGBD utilizado
Pruebas
Resultados de las pruebas
Estrategias de pruebas utilizadas; análisis de los resultados de las pruebas
Mantenimiento
Resultados de las pruebas de rendimiento; requisitos de usuario y del sistema nuevos o modificados
Manual de usuario; análisis de los resultados de las pruebas de rendimiento; requisitos de los usuarios y especificaciones del sistema modificados
operativo
por el SGBD
Versión revisada de los requisitos de usuario y de las especificaciones del sistema
por el SGBD
10.3 Técnicas de determinación de hechos El desarrollador de bases de datos normalmente utiliza diversas técnicas de determinación de hechos a lo largo de un mismo proyecto de bases de datos. Existen cinco técnicas de determinación de hechos comúnmente utilizadas: •
examen de la documentación;
•
entrevistas;
•
observación de la operación de la empresa;
•
investigación;
290 •
Sistemas de bases de datos cuestionarios.
En las siguientes secciones vamos a describir estas técnicas de determinación de hechos y a identificar las ventajas y desventajas de cada una.
10.3.1 Examen de la documentación El examen de la documentación puede resultar útil cuando estemos tratando de comprender cómo surgió la necesidad del nuevo sistema de base de datos. También puede que la documentación disponible nos ayude a conseguir información sobre la parte de la empresa con la que se relaciona el problema. Si el problema está relacionado con el sistema actual, debe existir documentación asociada con dicho sistema. Examinando los documentos, formularios, informes y archivos asociados con el sistema actual, podemos llegar rápidamente a tener un cierto conocimiento de dicho sistema. En la Tabla 10.2 se indican ejemplos de los tipos de documentación que debe examinarse.
10.3.2 Entrevistas Las entrevistas son la técnica de determinación de hechos más comúnmente utilizada y la que resulta normalmente más útil. Podemos realizar las entrevistas con las distintas personas para recopilar información cara a cara. Pueden ser varios los objetivos de las entrevistas, como por ejemplo averiguar nuevos hechos, verificar otros, clarificar determinadas cuestiones, generar entusiasmo entre los usuarios, conseguir que el usuario final se involucre, identificar los requisitos y recopilar ideas y opiniones. Sin embargo, la utilización de la técnica de las entrevistas requiere unas buenas dotes de comunicación para poder tratar de forma efectiva con personas que pueden tener diferentes valores, prioridades, opiniones, motivaciones y personalidades. Al igual que sucede con otras técnicas de determinación de hechos, las entrevistas no constituyen siempre el mejor método para todas las situaciones. En la Tabla 10.3 se indican las ventajas y desventajas de la utilización de las entrevistas como técnica de determinación de hechos. Existen dos tipos de entrevistas: no estructuradas y estructuradas. Las entrevistas no estructuradas se llevan a cabo teniendo en mente sólo un objetivo general y con sólo unas pocas cuestiones específicas (si es que hay alguna cuestión preparada de antemano). El entrevistador depende del entrevistado para fijar la base y la dirección de la entrevista. Este tipo de entrevista tiende a perder el foco frecuentemente y, por esta razón, no resulta adecuada para el análisis y diseño de bases de datos. Tabla 10.2.
Ejemplos de los tipos de documentación
que debería examinarse.
Objetivo de la documentación
Ejemplos de fuentes de documentación
Descripción del problema y de la necesidad de disponer de una base de datos
Memorandos
Descripción de la parte de la empresa afectada por el problema
útiles
internos, mensajes de correo electrónico y actas de reuniones.
Quejas de los empleados/clientes y documentos que describan el problema. Análisis/informes de rendimiento. Organigrama, enunciado de la misión y plan estratégico de la empresa. Objetivos de la parte de la empresa objeto del estudio. Descripciones
de las tareas/puesto de trabajo.
Ejemplos de formularios e informes completados de forma manual. Ejemplos de formularios e informes generados mediante un sistema informático. Descripción del sistema actual
Diversos tipos de diagramas de flujo y otros diagramas. Diccionario de datos. Diseño del sistema de base de datos. Documentación del programa. Manuales de usuario/de formación.
Capítulo 10 Técnicas de determinación de hechos Tabla 10.3.
291
Ventajas y desventajas de la utilización de entrevistas como técnica de determinación de hechos.
Ventajas
Desventajas
Permite al entrevistado responder de forma libre y abierta a las preguntas.
Requiere mucho tiempo y es muy costosa, por lo que puede resultar no adecuada.
Permite al entrevistado sentirse parte del proyecto.
El éxito depende de la capacidad de comunicación entrevistador.
Permite al entrevistador profundizar en los comentarios de interés realizados por el entrevistado.
El éxito puede depender de la predisposición vistados a participar en la entrevista.
del
de los entre-
Permite al entrevistador adaptar o reformular las preguntas durante la entrevista. Permite al entrevistador observar el lenguaje corporal del entrevistado.
En las entrevistas estructuradas, el entrevistador tiene un conjunto específico de cuestiones que preguntar al entrevistado. Dependiendo de las respuestas del entrevistado, el entrevistador puede formular cuestiones adicionales para clarificar o ampliar algún aspecto. Las cuestiones abiertas permiten al entrevistado responder de la forma que considere apropiada; un ejemplo de cuestión abierta es: '¿por qué no le satisface el informe sobre registro de clientes?'. Las cuestiones cerradas restringen las respuestas posibles, que deben ceñirse a una serie de opciones específicas o deben ser respuestas cortas y directas. Un ejemplo de tal tipo de cuestión sería: '¿le entregan el informe sobre registro de clientes a tiempo?' o '¿Contiene información precisa el informe sobre registro de clientes?'. Ambas preguntas requieren únicamente una respuesta de tipo 'Sí' o
'No'.
Para garantizar que el proceso de entrevistas tenga éxito es necesario seleccionar adecuadamente las personas que hay que entrevistar, prepararse exhaustivamente para la entrevista y llevar ésta a cabo de una forma eficiente y efectiva.
10.3.3 Observación de la operación de la empresa La observación es una de las técnicas de determinación de hechos más efectivas para tratar de comprender un sistema. Con esta técnica, es posible participar en la realización de una serie de actividades para aprender acerca del sistema u observar a otra persona realizar esas actividades. Esta técnica es particularmente útil cuando resulta cuestionable la validez de los datos recopilados mediante otros métodos o cuando la complejidad de ciertos aspectos del sistema impide obtener una explicación clara por parte de los usuarios finales. Al igual que sucede con las otras técnicas de determinación de hechos, para que el proceso de observación tenga éxito se requiere preparación previa. Así, es importante conocer lo más posible acerca de las personas y de la actividad que hay que observar. Por ejemplo, '¿cuándo se producen los períodos de actividad baja, normal y de pico?' y '¿Pueden sentirse incómodas las personas que realizan una cierta actividad si alguien las observa y graba sus acciones?'. En la Tabla 10.4 se enumeran las ventajas y desventajas de utilizar mecanismos de observación como técnica de determinación de hechos.
10.3.4 Investigación Una técnica útil de determinación de hechos consiste en investigar acerca de la aplicación y del problema. Las revistas de informática, los libros de referencia e Internet (incluyendo los grupos de usuarios y foros de discusión) son buenas fuentes de información. Pueden proporcionar información acerca del modo en que otras personas han resuelto problemas similares, además de indicar si existen o no paquetes software que resuelvan total o parcialmente el problema. En la Tabla 10.5 se enumeran las ventajas y desventajas de utilizar la investigación como técnica de identificación de hechos.
292
Sistemas de bases de datos
Tabla 10.4.
Ventajas y desventajas
de utilizar la observación
como técnica de determinación
de hechos.
Ventajas
Desventajas
Permite comprobar la validez de los hechos y los datos.
Las personas pueden, de forma consciente o inconsciente, comportarse de forma distinta cuando están siendo observadas.
El observador puede ver exactamente qué es lo que se está haciendo.
Puede perderse la observación de tareas con niveles de dificultad o volúmenes diferentes a los experimentados durante el periodo de observación.
El observador puede también obtener datos que describan el entorno fisico de la tarea.
Algunas tareas pueden no siempre llevarse a cabo de la manera observada.
Es un método relativamente barato.
Este método puede ser poco práctico o imposible de llevar a cabo.
El observador puede realizar medidas acerca de la tarea.
Tabla 10.5.
Ventajas y desventajas
de utilizar la investigación
como técnica de identificación
de hechos.
Ventajas
Desventajas
Puede ahorrar tiempo si ya existe una solución.
Requiere disponer de acceso a las fuentes de información apropiadas.
El investigador puede ver cómo otras personas han resuelto problemas similares o han dado respuesta a similares requisitos.
Puede que al final no ayude a resolver el problema debido a que éste no está documentado en ningún otro sitio.
El investigador se mantiene al día en lo que respecta a los desarrollos existentes.
10.3.5 Cuestionarios Otra técnica de determinación de hechos consiste en realizar una serie de encuestas mediante cuestionarios. Los cuestionarios son documentos escritos ex profeso que permiten recopilar hechos de un gran número de personas al mismo tiempo que se mantiene un cierto grado de control sobre sus respuestas. Cuando se tiene que tratar con una audiencia de gran tamaño, ninguna otra técnica de determinación de hechos permite tabular los mismos hechos de forma tan eficiente. En la Tabla 10.6 se enumeran las ventajas y desventajas de la utilización de cuestionarios como técnica de determinación de hechos. Tabla 10.6.
Ventajas y desventajas de la utilización de cuestionarios como técnica de determinación de hechos.
Ventajas
Desventajas
Las distintas personas pueden completar y devolver los cuestionarios según les convenga.
El número de personas que respondan puede ser bajo, posiblemente de sólo entre el 5% y el 10%.
Es una forma relativamente barata de recopilar datos de un gran número de personas.
Puede que algunos cuestionarios se devuelvan incompletos.
La gente puede ser más proclive a decir la verdad, ya que las respuestas pueden mantenerse confidenciales.
Puede no proporcionar la oportunidad de adaptar o reformular cuestiones que hayan sido mal interpretadas.
Las respuestas pueden tabularse y analizarse rápidamente.
No se puede observar y analizar el lenguaje corporal de la persona que responde al cuestionario.
Capítulo 10 Técnicas de determinación de hechos
293
Hay dos tipos de preguntas que pueden hacerse en un cuestionario: preguntas de formato libre y de formato fijo. Las cuestiones de formato libre dan a la persona que está rellenando el cuestionario una mayor libertad a la hora de escribir la respuesta. Se hace una pregunta y la persona indica su respuesta en el espacio proporcionado a continuación. Como ejemplos de cuestiones de formato libre podríamos poner: '¿qué informes recibe actualmente y cómo se utilizan?' y '¿Hay algún problema con estos informes? En caso afirmativo, explique su respuesta'. Los problemas con las cuestiones de formato libre son que las respuestas obtenidas pueden resultar difíciles de tabular y, en algunos casos, pueden no corresponderse adecuadamente con la cuestión que se pregunta. Las cuestiones de formato fijo requieren respuestas específicas de las personas que rellenan el cuestionario. Dada una cuestión, la persona debe elegir entre las respuestas disponibles, lo que hace que los resultados sean mucho más fáciles de tabular. Por otro lado, la persona se ve imposibilitada para proporcionar información adicional que pudiera resultar valiosa. Un ejemplo de cuestión de formato fijo sería: 'El formato actual del informe sobre alquileres de inmuebles es ideal y no debe cambiarse'. La persona que rellena el cuestionario puede tener la opción de responder 'Sí' o 'No' a esta cuestión, o puede dársele la opción de elegir entre una serie de respuestas, como por ejemplo 'Muy de acuerdo', 'De acuerdo', 'No tengo opinión', 'En desacuerdo' y 'Muy en desacuerdo'.
10.4 Ejemplo de utilización de técnicas de determinación de hechos En esta sección, vamos a presentar primero una panorámica del caso de estudio de DreamHome y luego utilizaremos dicho caso para ilustrar cómo establecer un proyecto de base de datos. En particular, ilustraremos el modo en que pueden emplearse las técnicas de determinación de hechos y veremos la documentación que se genera en las primeras etapas del ciclo de desarrollo del sistema de base de datos, es decir, en las etapas de planificación de la base de datos, de definición del sistema y de recopilación y análisis de requisitos.
10.4.1 El caso de estudio de DreamHome: panorámica La primera sucursal de DreamHome fue abierta en 1992 en Glasgow, en el Reino Unido. Desde entonces, la empresa ha crecido de forma continua y ahora tiene diversas sucursales en la mayoría de las principales ciudades del Reino Unido. Sin embargo, la empresa es ahora tan grande que cada vez se requiere más personal administrativo para procesar la cantidad cada vez mayor de papeles e informes. Además, la comunicación y compartición de información entre sucursales, incluso dentro de la misma ciudad, es bastante deficiente. La directora de la empresa, Sally Mellweadows, cree que se están cometiendo demasiados errores y que el éxito de la empresa puede ser muy efímero si no se hace algo para remediar la situación. Sabe que una base de datos podría ayudar en parte a resolver el problema por lo cual ha solicitado que se desarrolle un sistema de base de datos para soportar las operaciones de DreamHome. La directora ha proporcionado la siguiente breve descripción de la forma en que DreamHome actualmente opera. DreamHome está especializada en la gestión de inmuebles, actuando de intermediario entre los propietarios que quieren alquilar sus inmuebles ya amueblados y los clientes de DreamHome que necesitan alquilar esos inmuebles durante un periodo fijo de tiempo. DreamHome cuenta actualmente con unos 2000 empleados que trabajan en cien sucursales. Cuando un nuevo empleado se incorpora a la empresa, se utiliza el formulario de registro de empleado de DreamHome. En la Figura 10.1 se muestra dicho formulario para la empleada Susan Brand. Cada sucursal tiene asignados una serie de empleados, de los tipos adecuados, incluyendo un gerente, supervisores y ayudantes. El gerente (Manager) es responsable de la operación diaria de la sucursal y cada supervisor es responsable de controlar a un grupo de empleados que tiene la categoría de ayudantes (Assistants). En la Figura 10.2 se muestra un ejemplo de la primera página de un informe donde se indican los detalles del personal que trabaja en una sucursal ubicada en Glasgow.
294
Sistemas de bases de datos
-
Número de sucursal Dirección sucursal DreamHome 2350 Fecha de naco 3-Jun-40 B003 Susan Brand Bono del gerente SG5 Manager Número(s) de teléfono como gerente e del supervisor 163 Main St, Glasgow Formulario de 0141-339-2178/0141-339-4439 registro de empleado Salario 24000 Número de empleado Introducir los detalles cuando sea aplicable
Figura 10.1.
e/0141-339-4439 teléfono
Fecha de comienzo
Formulario de registro de empleado de DreamHome
Listado de
01-Jun-90
para Susan Brand.
DreamHome Nombre Dirección sucursal Chris Ann Assistant Lawrence Beech Assistant Susan Brand Sofie David Assistant Walters Ford Categoria Annet Supervisor Manager Longhorn Supervisor G1l9QX empleados 163 Main St, Glasgow Page 1
Número de sucursal B003 Número de empleado
Figura 10.2.
Ejemplo de la primera página de un informe donde se indican los detalles de los empleados que trabajan en una sucursal de DreamHome ubicada en Glasgow.
Cada sucursal ofrece una serie de inmuebles en alquiler. Para ofrecer un inmueble a través de DreamHome, el propietario normalmente contacta con la sucursal de DreamHome que esté situada más cerca del inmueble en alquiler. El propietario suministra los detalles del inmueble y acuerda un precio de alquiler adecuado junto con el gerente de la sucursal. En la Figura 10.3 se muestra el formulario de registro de un inmueble situado en Glasgow.
Capítulo 10 Técnicas de determinación de hechos
Drive, , G12 9AX David Ford
295
--
45012 Flat DreamHome 0141-225-7025 Habitaciones Número de propietario C093 Nombre de4PG16 la persona/empresa Registrado en la sucursal Park Pl, 163Glasgow Main St,G4 Glasgow Tony Shaw Dirección OQR N°Tel Nombre del contacto
(si conoce) Tipo de empresa Formulario aplicable deseregistro de inmueble
Número deIntroducir inmueble detalles cuando sea do por el empleado
Figura 10.3.
Formulario de registro de inmueble de OreamHome para un inmueble situado en Glasgow.
Una vez registrado un inmueble, DreamHome proporciona una serie de servicios para garantizar que el inmueble se alquile de modo que se consiga un beneficio máximo tanto para el propietario como, por supuesto, para DreamHome. Estos servicios incluyen la realización de entrevistas con inquilinos potenciales (denominados clientes), la organización de visitas por parte de los clientes a los inmuebles, el anuncio del inmueble en periódicos locales o nacionales (cuando sea necesario) y la negociación del contrato de alquiler. Una vez alquilado, DreamHome asume la responsabilidad del inmueble, incluyendo el cobro del alquiler. Las personas interesadas en alquilar un inmueble deben primero ponerse en contacto con la sucursal de DreamHome más cercana para registrarse como clientes de DreamHome. Sin embargo, antes de aceptar el registro, normalmente se entrevista a cada cliente potencial para apuntar los detalles y preferencias personales del cliente en lo que respecta al inmueble deseado. En la Figura lOA se muestra el formulario de registro para un cliente denominado Mike Ritchie. Una vez completado el registro, a los clientes se les proporcionan informes semanales que enumeran los inmuebles actualmente disponibles para alquilar. En la Figura 10.5 se muestra un ejemplo de la primera página de un informe que indica las propiedades disponibles para alquilar en una sucursal de Glasgow. Los clientes pueden solicitar visitar uno o más inmuebles de la lista y, después de la visita, normalmente proporcionarán un comentario sobre la adecuación del inmueble a sus preferencias. En la Figura 10.6 se muestra la primera página de un informe que describe los comentarios realizados por los clientes acerca de un inmueble situado en Glasgow. Los inmuebles que resultan difíciles de alquilar normalmente se anuncian en los periódicos locales o nacionales.
Mike Ritchie re completo Rent 750
296
Sistemas de bases de datos
Registrado por B003 CR74 de DreamHome Número sucursal 163 Main St, Glasgow Dirección Annde Beech Fecha de registrosucursal 16-Nov-02 registro cliente Flat
Formulario de
NúmeroIntroducir de cliente preferencias
Figura
10.4.
de inmueble
Formulario de registro de clientes de DreamHome
para Mike Ritchie.
DreamHome
Listado de inmuebles para la semana del 01/06/04 Si está interesado en ver o alquilar cualquiera de los inmuebles de esta lista, póngase en contacto con nuestra sucursal lo antes posible. Dirección de la sucursal
Número(s) de teléfono
163 Main St, Glasgow
0141-339-2178 /0141-339-4439
G119QX
N° inmueble 560 440 465Lawrence 350 375 House Flat Hab. Dirección 600 450 3 Alq. lOOA Apple Tipo Lane, Glasgow 2 18 Manor Dale Road, Rd, Glasgow Glasgow 781 Greentree Dr, Glasgow 6 St, Glasgow 5 Novar Drive, Glasgow
Page 1
Figura
10.5. Primera página del informe de inmuebles en alquiler de DreamHome que enumera los inmuebles disponibles en una sucursal de Glasgow.
property
Una vez un cliente ha identificado un inmueble adecuado, un empleado redacta un contrato de alquiler. En la Figura 10.7 se muestra el contrato suscrito entre un cliente denominado Mike Ritchie y la empresa, para el alquiler de un inmueble situado en Glasgow. Al final del periodo de alquiler, el cliente puede solicitar que éste continúe; sin embargo, esto requiere que se redacte un nuevo contrato. Alternativamente, el cliente puede solicitar ver otros inmuebles para alquilados en lugar del que ya tiene.
Capítulo 10 Técnicas de determinación de hechos
Informe
N° de inmueble
DreamHome de visitas de inmueble
Dirección del inmueble
PG4
6 Lawrence St, Glasgow Tipo
Flat
Alquiler
350
N° cliente Aline Nombre Fecha Mike Ritchie Stewar 11/11/04 11/11/04 20/04/04 26/05/04 Too remote. throughout. Mary Tregea John Kay OK, but needsComentarios redecoration CR62 CR74
Page 1
Figura
10.6.
La primera página del informe de visitas de
inmueble de DreamHome para un inmueble situado en Glasgow.
CR74 PG16 31/05/05 450 DreamHome Sí 01/06/04 Duración 1 año N° de inmueble Cheque Fin alquiler
e completo
Mike Ritchie
Número de alquiler 00345810
Leasealquiler Inicio Dr, Glasgow Dirección 5delNovar inmueble
Firma cliente
(8 o N) N° de cliente
Enter payment details
Figura 10.7. Formulario de alquiler de DreamHome para un cliente denominado Mike Ritchie que está alquilando un inmueble en Glasgow.
297
298
Sistemas de bases de datos
10.4.2 El caso de estudio de DreamHome: planificación de la base de datos El primer paso al desarrollar un sistema de base de datos consiste en definir claramente el enunciado de la misión del proyecto de base de datos, que define los objetivos principales del sistema. Una vez definido el enunciado de la misión, la siguiente actividad implica identificar los objetivos de la misión, que deben indicar las tareas concretas a las que la base de datos debe dar soporte (véase la Sección 9.3).
Creación del enunciado de la misión para el sistema de base de datos de DreamHome Comenzamos el proceso de crear un enunciado de la misión del sistema de base de datos de DreamHome realizando una serie de entrevistas con la directora y con otros empleados relevantes, indicados por ésta. Normalmente, las cuestiones de tipo abierto son las más útiles en esta etapa del proceso. Como ejemplos de cuestiones típicas que podríamos preguntar tendríamos: '¿ Cuál es el propósito de la empresa?' '¿Por qué cree que necesita una base de datos?' '¿ Cómo sabe que una base de datos resolverá su problema?' Por ejemplo el desarrollador de la base de datos puede comenzar la entrevista preguntando a la directora de DreamHome las siguientes cuestiones: Desarrollador
¿Cuál es el propósito de la empresa?
Directora
Ofrecemos un amplio rango de inmuebles de alto estanding para clientes registrados en nuestras sucursales repartidas por todo el Reino Unido. Nuestra capacidad para ofrecer inmuebles de gran calidad depende, por supuesto, de los servicios que proporcionamos a los propietarios. Les proporcionamos un servicio muy profesional para garantizar un beneficio máximo a la hora de alquilar los inmuebles.
Desarrollador
¿Por qué cree que necesita una base de datos?
Directora
Para ser honestos, somos incapaces de adaptamos a nuestro propio éxito. En los últimos años hemos abierto numerosas sucursales en la mayoría de las ciudades principales del Reino Unido y en cada sucursal ofrecemos ahora un mayor número de inmuebles a un conjunto también mayor de clientes. Sin embargo, este éxito ha estado acompañado por una serie de problemas crecientes de gestión de los datos, lo que significa que el nivel de servicio que proporcionamos está cayendo. Asimismo, hay una falta de cooperación y de compartición de la información entre las sucursales, lo que representa una evolución muy preocupante.
Desarrollador
¿ Cómo sabe que una base de datos resolverá su problema?
Directora
Todo lo que sé es que estamos inundados de papeles. Necesitamos algo que acelere nuestra manera de trabajar automatizando buena parte de las tareas cotidianas que parecen alargarse indefinidamente en estos últimos meses. Asimismo, quiero que las sucursales comiencen a cooperar unas con otras. Una base de datos ayudaría a conseguir este objetivo, ¿no cree?
Las respuestas a estos tipos de cuestiones deberían ayudar a formular el enunciado de la misión. En la Figura 10.8 se muestra un enunciado de ejemplo para el sistema de base de datos de DreamHome. Una vez que disponemos de una misión clara y no ambigua con la que el personal de DreamHome esté de acuerdo, podemos pasar a definir los objetivos de la misión.
Capítulo 10 Técnicas de determinación de hechos
299
'El propósito del sistema de base de datos de DreamHome es mantener los datos que se utilizan y generan para soportar el negocio de alquiler de inmuebles con el que se presta servicio a nuestros clientes y a los propietarios y facilitar la cooperación y compartición de información entre sucursales'.
Figura 10.8.
Enunciado de la misión del sistema de base de datos de DreamHome.
Creación de los objetivos de la misión para el sistema de base de datos de DreamHome El proceso de definición de los objetivos de la misión implica realizar entrevistas con una serie de empleados seleccionados. De nuevo, normalmente son las cuestiones de tipo abierto las que resultan más útiles en esta etapa del proceso. Para obtener el rango completo de los objetivos de la misión, entrevistamos a varios empleados con diferentes papeles dentro de DreamHome. Algunos ejemplos de cuestiones típicas que podríamos preguntar son: '¿Cuál es el cometido de su puesto de trabajo?' '¿Qué tipo de tareas realiza en un día normal?' '¿Con qué tipo de datos trabaja?' '¿ Qué tipos de informes utiliza?' '¿Qué tipos de cosas necesita controlar?' '¿ Qué servicio proporciona su empresa a los clientes?' Estas cuestiones (o similares) se le plantean a la directora de DreamHome y a diversos empleados que tienen las categorías de gerente, supervisor y ayudante. Puede ser necesario adaptar las cuestiones, dependiendo de a quién se esté entrevistando. Directora Desarrollador
¿ Qué papel juega en la compañía?
Directora
Controlo las operaciones de la empresa para garantizar que continuemos proporcionando el mejor servicio posible de alquiler de inmuebles tanto a nuestros clientes como a los propietarios de los mismos.
Desarrollador
¿Qué tipo de tareas realiza en un día normal?
Directora
Monitorizo la forma en que cada uno de nuestros gerentes dirige su sucursal. Trato de garantizar que las sucursales colaboren y compartan información importante acerca de los inmuebles y de los clientes. Normalmente trato de mantener un estrecho control de los gerentes, llamando a cada sucursal al menos una o dos veces al mes.
Desarrollador
¿Con qué tipo de datos trabaja?
Directora
Necesito poder acceder a todo, o por lo menos a un resumen de los datos utilizados o generados por DreamHome. Eso incluye datos sobre el personal de las sucursales, sobre todos los inmuebles y sus propietarios, sobre todos los clientes y sobre todos los contratos. También me gusta controlar el grado con el que cada sucursal anuncia los inmuebles en los periódicos.
300
Sistemas de bases de datos
Desarrollador
¿Qué tipos de informes utiliza?
Directora
Necesito saber qué es lo que sucede en cada sucursal y hay un montón de ellas. Dedico buena parte del día a analizar largos informes sobre todos los aspectos de DreamHome. Necesito informes que sean fáciles de acceder y que me proporcionen una buena panorámica de lo que está sucediendo en una determinada sucursal y en el conjunto de todas ellas.
Desarrollador
¿Qué tipos de cosas necesita controlar?
Directora
Como he dicho antes, necesito obtener una panorámica de todo, necesito poder ver la imagen global.
Desarrollador
¿ Qué servicio proporciona su empresa a los clientes?
Directora
Tratamos de proporcionar el mejor servicio posible de alquiler de inmuebles en el Reino Unido.
Gerente Desarrollador
¿ Cuál es el cometido de su puesto de trabajo?
Gerente
Mi categoría es la de Gerente. Me encargo de dirigir el funcionamiento cotidiano de mi sucursal para proporcionar el mejor servicio de alquiler de inmuebles a nuestros clientes y a los propietarios de los mismos.
Desarrollador
¿ Qué tipo de tareas realiza en un día normal?
Gerente
Me encargo de garantizar que la sucursal tenga en todo momento el número adecuado de empleados y que esos empleados tengan la categoría adecuada. Superviso el registro de nuevos inmuebles y nuevos clientes y la actividad de alquiler de nuestros clientes actualmente activos. Entre mis responsabilidades está garantizar que tengamos el nlímero y el tipo correcto de inmueble s disponibles para ofrecer a nuestros clientes. En ocasiones también participo en la negociación de contratos de alquiler para los inmuebles más selectos, aunque debido a mi carga de trabajo normalmente tengo que delegar esta tarea en los supervisores.
Desarrollador
¿ Con qué tipo de datos trabaja?
Gerente
Fundamentalmente trabajo con los datos sobre los inmuebles ofrecidos en mi sucursal y sobre los propietarios, clientes y contratos de alquiler. También necesito saber cuándo un inmueble está resultando dificil de alquilar, para poder disponer lo necesario para que se anuncie en los periódicos. Necesito poder controlar este aspecto del negocio porque los anuncios pueden resultar muy costosos. También necesito acceder a los datos sobre el personal que trabaja en mi sucursal y el personal de otras sucursales locales. Esto se debe a que a veces tengo que contactar con otras sucursales para concertar reuniones de gestión o para pedir prestado personal a otras sucursales de forma temporal con el fin de cubrir bajas debidas a enfermedad o durante periodos de vacaciones. Este intercambio de empleados entre las sucursales locales es informal y no suele tener lugar muy a menudo, afortunadamente. Además de los datos sobre el personal, resultaría bastante útil poder ver otros tipos de datos relativos a las otras sucursales, como por ejemplo datos sobre los inmuebles, los propietarios, los clientes y los contratos, fundamentalmente para poder efectuar comparaciones. De hecho, creo que la Directora confia en que este proyecto de base de datos ayude a promover la cooperación y la compartición de información entre sucursales. Sin embargo, algunos de los gerentes que conozco no van a estar muy de
Capítulo 10 Técnicas de determinación de hechos
301
acuerdo con esto, porque piensan que las distintas sucursales debemos competir unas con otras. Parte del problema es que un cierto porcentaje del salario de los gerentes está compuesto por un bono que está relacionado con el número de inmuebles que somos capaces de alquilar. Desarrollador
¿Qué tipos de informes utiliza?
Gerente
Necesito varios informes sobre el personal, los inmuebles, los propietarios, los clientes y los contratos de alquiler. Necesito poder saber de un solo vistazo qué inmuebles necesitamos alquilar y qué es lo que los clientes están buscando.
Desarro llador
¿Qué tipos de cosas necesita controlar?
Gerente
Necesito controlar los salarios de los empleados. Necesito también saber si se están alquilando de forma efectiva los inmuebles que tenemos en catálogo y en qué momento se aproximan las renovaciones de los contratos de alquiler. También necesito controlar el gasto en anuncios publicados en los periódicos.
Desarrollador
¿Qué servicio proporciona su empresa a los clientes?
Gerente
Recuerde que tenemos dos tipos de clientes, es decir, clientes que quieren alquilar un inmueble y propietarios de inmuebles. Necesitamos aseguramos de que nuestros clientes localicen el inmueble que están buscando rápidamente sin tener que hacer demasiadas visitas y con un precio de alquiler razonable; y por supuesto que nuestros propietarios de inmuebles obtengan un buen beneficio al alquilarlos con unas molestias mínimas.
Supervisor Desarrollador
¿ Cuál es el cometido de su puesto de trabajo?
Supervisor
Mi puesto es el de Supervisor. Paso la mayor parte del tiempo en la oficina tratando directamente con nuestros clientes, es decir clientes que quieren alquilar un inmueble y propietarios de inmuebles. También soy responsable de un pequeño grupo de empleados que tienen la categoría de ayudantes y tengo que mantenerles ocupados, aunque eso no es un problema ya que siempre hay un montón de cosas que hacer; de hecho, el trabajo nunca se acaba.
Desarrollador
¿Qué tipo de tareas realiza en un día normal?
Supervisor
Normalmente comienzo el día asignando personal a tareas concretas, como por ejemplo tratar con los clientes o con los propietarios, organizar visitas a los inmuebles por parte de los clientes y rellenar los informes necesarios. Cuando un cliente localiza un inmueble adecuado, me encargo de procesar el borrador de contrato de alquiler, aunque el Gerente debe ver la documentación antes de que se pueda firmar el contrato. Mantengo actualizado los detalles de los clientes y registro esos otros clientes que acuden por vez primera a la empresa. Cuando se registra un nuevo inmueble, el Gerente asigna la responsabilidad de gestionar dicho inmueble a algunos de los supervisores o ayudantes.
Desarrol\ador
¿Con qué tipo de datos trabaja?
Supervisor
Trabajo con los datos relativos a los empleados de mi sucursal, inmuebles, propietarios, clientes, visitas a los inmuebles y contratos de alquiler.
Desarro llador
¿Qué tipos de informes utiliza?
302
Sistemas de bases de datos
Supervisor
Informes sobre el personal y sobre los inmuebles en alquiler.
Desarrollador
¿Qué tipos de cosas necesita controlar?
Supervisor
Necesito saber qué propiedades están disponibles para alquilar y cuándo van a caducar los contratos que están activos. También tengo que saber qué es lo que están buscando los clientes. Necesito asimismo mantener al día al Gerente acerca de cualesquiera inmueble s que estén resultando difíciles de alquilar.
Ayudante Desarro llador
¿Cuál es el cometido de su puesto de trabajo?
Ayudante
Mi categoría es la de Ayudante. Trato directamente con nuestros clientes.
Desarro!lador
¿ Qué tipo de tareas realiza en un día normal?
Ayudante
Respondo consultas generales de los clientes acerca de los inmuebles en alquiler. Por ejemplo: '¿tiene un inmueble de tal y tal tipo en un área concreta de Glasgow?'. También registro a los nuevos clientes y concierto las visitas de los clientes a los inmuebles. Cuando no estamos demasiado ocupados, me encargo del papeleo, pero odio esta parte del trabajo, ya que resulta enormemente aburrida.
Desarro !lador
¿Con qué tipo de datos trabaja?
Ayudante
Trabajo con datos sobre los inmuebles y las visitas a los inmuebles por parte de los clientes, y en ocasiones también sobre los contratos de alquiler.
Desarrollador
¿Qué tipos de informes utiliza?
Ayudante
Listas de inmuebles disponibles para alquilar. Estas listas se actualizan cada semana.
Desarrollador
¿ Qué tipos de cosas necesita controlar?
Ayudante
Necesito controlar si ciertos inmuebles están disponibles para alquilar y qué clientes continúan buscando activamente un inmueble.
Desarrollador
¿ Qué servicio proporciona su empresa a los clientes?
Ayudante
Tratamos de responder preguntas acerca de los inmuebles disponibles para alquilar, tales como: '¿tiene un piso de dos dormitorios en Hyndland, Glasgow?' y '¿Qué es lo que se paga normalmente por un piso de un dormitorio en el centro de la ciudad?'.
Las respuestas a este tipo de cuestiones deberían poder ayudar a formular los objetivos de la misión. En la Figura 10.9 se muestra un ejemplo de los objetivos de la misión para el sistema de base de datos de DreamHome.
10.4.3 El caso de estudio de DreamHome: definición del sistema El propósito de la etapa de definición del sistema consiste en definir el ámbito y los límites del sistema de base de datos y sus principales vistas de usuario. En la Sección 9.4.1 hemos descrito cómo representa una vista de usuario los requisitos que deben ser soportados por un sistema de base de datos, tal y como están definidos por un puesto de trabajo (como por ejemplo, Director o Supervisor) o por un área de aplicación empresarial concreta (como por ejemplo, alquileres de inmuebles o ventas de inmuebles).
Capítulo 10 Técnicas de determinación de hechos
Mantener Mantener Mantener Mantener Mantener Mantener Mantener Mantener Realizar Realizar Realizar Realizar Realizar Realizar Realizar Realizar
(introducir, (introducir, (introducir, (introducir, (introducir, (introducir, (introducir, (introducir,
búsquedas búsquedas búsquedas búsquedas búsquedas búsquedas búsquedas búsquedas
actualizar actualizar actualizar actualizar actualizar actualizar actualizar actualizar de de de de de de de de
303
y borrar) los datos sobre las sucursales. y borrar) los datos sobre el personal.
y y y y y y
borrar) borrar) borrar) borrar) borrar) borrar)
información información información información información información información información
los datos los datos los datos los datos los datos los datos
sobre sobre sobre sobre sobre sobre sobre sobre
sobre sobre sobre sobre sobre sobre
los inmuebles en alquiler. los propietarios de inmuebles. los clientes. las visitas a los inmuebles. los contratos de alquiler. los anuncios en los periódicos.
las sucursales. el personal. los inmuebles en alquiler. los propietarios de inmuebles. los clientes. las visitas a los inmuebles. los contratos de alquiler. los anuncios en los periódicos.
Controlar el estado de los inmuebles en alquiler. Controlar el estado de los clientes que desean alquilar un inmueble. Controlar el estado de los contratos de alquiler. Generar Generar Generar Generar Generar Generar Generar Generar
informes informes informes informes informes informes informes informes
Figura 10.9.
sobre sobre sobre sobre sobre sobre sobre sobre
las sucursales. el personal. los inmuebles en alquiler. los propietarios de inmuebles. los clientes. las visitas a los inmuebles. los contratos de alquiler. los anuncios en los periódicos.
Objetivos de la misión del sistema de base de datos de DreamHome.
Definición de los límites del sistema para el sistema de base de datos de DreamHome Durante esta etapa del ciclo de desarrollo del sistema de base de datos, pueden utilizarse entrevistas adicionales con los usuarios para clarificar o ampliar los datos capturados en la etapa anterior. Sin embargo, también pueden usarse técnicas adicionales de determinación de hechos, incluyendo examinar la documentación del ejemplo mostrada en la Sección 1004.1. Los datos recopilados hasta ahora se analizan para definir los límites del sistema de base de datos. Los límites del sistema de base de datos de DreamHome se muestran en la Figura 10.10.
Identificación de las principales vistas de usuarios para el sistema de base de datos de DreamHome Ahora analizamos los datos recopilados hasta el momento con el rio del sistema de base de datos. La mayoría de los datos acerca mediante entrevistas con la Directora y con diversos miembros Gerente, Supervisor y Ayudante. Las principales vistas de usuario Home se muestran en la Figura 10.11.
fin de definir las principales vistas de usuade las vistas de usuario fueron recopilados del personal que tenían las categorías de para el sistema de base de datos de Dream-
10.4.4 El caso de estudio de DreamHome: recopilación y análisis de requisitos Durante esta etapa, continuamos recopilando más detalles sobre las vistas de usuario identificadas en la etapa anterior. Para crear una especificación de requisitos de usuario que describe en detalle los datos que
304
Sistemas de bases de datos
Marketing
Nóminas
Gestión de recursos
Servicios a clientes
Límites del sistema
Figura 10.10.
Límites del sistema de base de datos de DreamHome.
hay que almacenar en la base de datos y cómo se los va a utilizar. Al recopilar más información sobre las vistas de usuario, también recopilamos los requisitos generales para el sistema. El propósito de obtener esta información es crear una especificación del sistema que describa cualesquiera características que haya que incluir en el nuevo sistema de base de datos, como por ejemplo los aspectos de interconexión por red y los requisitos de acceso compartido, los requisitos de prestaciones y el nivel de seguridad necesario. A medida que recopilamos y analizamos los requisitos del nuevo sistema, también vamos identificando las características más útiles y más problemáticas del sistema actual. A la hora de construir un nuevo sistema de base de datos, resulta razonable tratar de conservar los buenos aspectos del sistema anterior, al mismo tiempo que se introducen los beneficios derivados de la utilización del nuevo sistema. Una actividad importante asociada con esta etapa es decidir qué hacer en aquellas situaciones en las que haya más que una vista de usuario. Como hemos visto en la Sección 9.6, hay tres técnicas principales para tratar con la existencia de múltiples vistas de usuario: el enfoque centralizado, el enfoque de integración de vistas y una combinación de ambas técnicas. En breve analizaremos cómo pueden emplearse estas técmcas.
Recopilación de más información sobre las vistas de usuario del sistema de base de datos de DreamHome Para averiguar los datos acerca de los requisitos correspondientes a cada vista de usuario, podemos volver a utilizar una combinación de técnicas de determinación de hechos que incluya entrevistas y la observación de la operación de la empresa. Como ejemplos de los tipos de cuestiones que podríamos preguntar acerca de los datos (representados como X) requeridos por una vista de usuario podríamos citar:
'¿ Qué tipo de datos necesita almacenar sobre X?' '¿ Qué tipo de cosas hace con los datos relativos a X?' Por ejemplo, podríamos preguntar a un Gerente las siguientes cuestiones Desarrollador
¿Qué tipo de datos necesita almacenar sobre los empleados?
Gerente
Los tipos de datos almacenados sobre un empleado son el nombre completo, su categoría, el sexo, la fecha de nacimiento y el salario.
Desarrollador
¿Qué tipo de cosas hace con los datos sobre los empleados?
Capítulo 10 Técnicas de determinación de hechos Datos Informe Visitas de
Consulta X X X X Mantener Mantener Mantener Mantener Mantener Mantener Mantener Mantener Mantener Mantener Maintain XXX Gerente Directora Mantener Tipo Supervisor Ayudante de acceso
XX
Informe Consulta Consulta
Figura 10.11.
Principales vistas de usuario para el sistema de base de datos de DreamHome.
305
306
Sistemas de bases de datos
Gerente
Tengo que poder introducir los detalles de los nuevos empleados y borrar los detalles de aquellos que dejan la empresa. Necesito mantener actualizados los detalles sobre los empleados e imprimir informes que indiquen el nombre completo, su categoría y su salario, para cada empleado en mi sucursal. Tengo que poder asignar personal a los supervisores. Algunas veces, cuando necesito comunicarme con otras sucursales, necesito averiguar los nombres y números de teléfono de los gerentes de esas otras sucursales.
Necesitamos preguntar cuestiones similares acerca de todos los datos importantes que hay que almacenar en la base de datos. La respuesta a estas cuestiones ayudará a identificar los detalles necesarios para la especificación de requisitos de los usuarios.
Recopilación de información sobre los requisitos del sistema de base de datos de DreamHome Al mismo tiempo que se realizan las entrevistas relativas a las vistas de usuario, se debe recopilar información de carácter más general sobre los requisitos del sistema. Como ejemplo de los tipos de cuestiones que podríamos preguntar acerca del sistema podríamos citar: '¿Qué transacciones se ejecutan de manera frecuente en la base de datos?' '¿Qué transacciones son críticas para la operación de la organización?' '¿Cuándo se ejecutan las transacciones críticas?' '¿Cuáles son los periodos de carga de trabajo baja, normal y alta para las transacciones críticas?' '¿Qué tipo de seguridad se desea para el sistema de base de datos?' '¿Hay algún dato altamente confidencial al que sólo debieran acceder ciertos empleados?' '¿Qué datos históricos se quieren conservar?' '¿ Cuáles son los requisitos de interconexión por red y acceso compartido para el sistema de base de datos?' '¿Qué tipo de protección frente a fallos o pérdidas de datos debe tener el sistema de base de datos?' Por ejemplo, podríamos preguntar a un Gerente las siguientes cuestiones: Desarrollador
¿Qué transacciones se ejecutan de manera frecuente en la base de datos?
Gerente
Frecuentemente recibimos solicitudes por teléfono o a través de clientes que llaman a la sucursal para buscar un tipo particular de inmueble en un área concreta de la ciudad y que tenga un alquiler no superior a una determinada cantidad. También necesitamos información actualizada sobre los inmuebles y los clientes para poder generar informes que muestren los inmuebles actualmente disponibles para alquilar y los clientes que actualmente están buscando un inmueble.
Desarrollador
¿ Qué transacciones son críticas para la operación del negocio?
Gerente
De nuevo, las transacciones críticas incluyen ser capaz de buscar inmuebles concretos e imprimir informes con listas actualizadas de inmuebles disponibles para alquilar. Nuestros clientes se irían a alguna empresa de la competencia si no pudiéramos proporcionar este servicio básico.
Desarrollador
¿Cuándo se ejecutan las transacciones críticas? Todos los días.
Gerente
Capítulo 10 Técnicas de determinación de hechos
307
Desarrollador
¿Cuáles son los periodos de carga de trabajo baja, normal y alta para las transacciones críticas?
Gerente
Abrimos seis días a la semana. En general, se tiende a estar más o menos tranquilos por las mañanas y a medida que avanza el día se tiene más y más trabajo. Sin embargo, las horas más críticas cada día, en lo que se refiere al trato con los clientes, son entre las 12 y las 2 y entre las 5 y las 7.
Podríamos plantear a la Directora las siguientes cuestiones: Desarrollador
¿Qué tipo de seguridad se desea para el sistema de base de datos?
Directora
No creo que una base de datos que almacene información para una empresa de alquiler de inmuebles contenga datos muy confidenciales, pero no me gustaría que ninguno de nuestros competidores viera los datos sobre los inmuebles, propietarios, clientes y contratos de alquiler. Los empleados sólo deben ver los datos que sean necesarios para hacer su trabajo en la forma que resulte adecuada en cada momento. Por ejemplo, aunque es necesario que los supervisores y ayudantes vean los detalles de los clientes, los registros de clientes sólo deberían visualizarse de uno en uno y en forma de listado.
Desarrollador
¿Hay algún dato altamente confidencial al que sólo debieran acceder ciertos empleados?
Directora
Como ya he dicho antes, los empleados sólo deben ver los datos necesarios para su trabajo. Por ejemplo, aunque los supervisores necesitan poder ver los datos sobre los empleados, no deberían incluirse los detalles salariales.
Desarro llador
¿Qué datos históricos se quieren conservar?
Directora
Quiero conservar los detalles de los clientes y propietarios durante un par de años después del último contacto que hayan tenido con nosotros, para poder efectuar campañas de marketing por correo con las que informarles de nuestras últimas ofertas y generalmente tratar de atraerles de nuevo a nuestra empresa. También quiero mantener la información de contratos durante un par de años para poder averiguar qué tipos de inmuebles y áreas de la ciudad son las más populares para el mercado de alquiler de inmuebles, etc.
Desarrollador
¿ Cuáles son los requisitos de interconexión por red y acceso compartido para el sistema de base de datos?
Directora
Quiero que todas las sucursales estén conectadas en red con nuestra oficina principal en Glasgow, con el fin de que el personal pueda acceder al sistema desde cualquier lugar y en el momento en que lo necesite. En la mayoría de las sucursales, cabe esperar que haya dos o tres empleados accediendo al sistema en cualquier momento concreto, pero recuerde que tenemos unas cien sucursales. La mayor parte del tiempo, los empleados estarán simplemente accediendo a datos relativos a la sucursal local. Sin embargo, no quiero que haya ninguna restricción sobre la frecuencia o los instantes de tiempo en que se puede acceder al sistema, a menos que las implicaciones financieras sean realmente grandes.
Desarro llador
¿Qué tipo de protección frente afallos o pérdidas de datos debe tener el sistema de base de datos?
308
Sistemas de bases de datos
Directora
La mejor que exista, por supuesto. Vamos a llevar todo el negocio utilizando la base de datos, por lo que si ésta se detiene, estamos perdidos. Hablando en serio, creo que probablemente deberíamos hacer una copia de seguridad de los datos todas las tardes, después de cerrar la sucursal. ¿Qué le parece?
Necesitamos plantear cuestiones similares acerca de todos los aspectos importantes del sistema. Las respuestas a estas cuestiones deberían ayudar a identificar los detalles necesarios para elaborar la especificación de requisitos del sistema.
Gestión de las vistas de usuario en el sistema de base de datos de DreamHome ¿Cómo podemos decidir si utilizar la técnica centralizada o la de integración de vistas (o una combinación de ambas) para gestionar los casos donde haya múltiples vistas de usuario? Una forma de facilitar la toma de decisiones consiste en examinar hasta qué punto se solapan los datos utilizados por las distintas vistas de usuario identificadas durante la etapa de definición del sistema. La Tabla 10.7 muestra una referencia cruzada de las vistas de usuario del Director, del Gerente, del Supervisor y del Ayudante, poniéndolas en correspondencia con los tipos de datos utilizados en cada una. Podemos ver en la Tabla 10.7 que existe un solapamiento de los datos utilizados por todas las vistas de usuario. Sin embargo, las vistas de usuario del Director y del Gerente y las del Supervisor y la del Ayudante muestran más similitudes entre sí en términos de los requisitos de datos. Por ejemplo, sólo las vistas de usuario del Director y del Gerente requieren datos sobre las sucursales y los anuncios en los periódicos, mientras que sólo las vistas de usuario del Supervisor y del Asistente requieren datos sobre las visitas a los inmuebles. Basándose en este análisis, utilizamos la técnica centralizada para combinar primero los requisitos de las vistas de usuario del Director y el Gerente (dándoles el nombre colectivo de vistas de usuario de Sucursal) y los requisitos de las vistas de usuario del Supervisor y del Ayudante (dándoles el nombre colectivo de vistas de usuario de los Empleados). Después desarrollamos modelos de datos que representen las vistas de usuario de Sucursal y Empleados y luego empleamos la técnica de integración de vistas para combinar los dos modelos de datos. Por supuesto, para un caso de estudio simple como el de DreamHome, podríamos utilizar fácilmente la técnica centralizada para todas las vistas de usuario, pero en este caso vamos a continuar adelante con nuestra decisión de crear dos vistas de usuario colectivas para poder describir e ilustrar cómo funciona la técnica de integración de vistas en la práctica en el Capítulo 16. Resulta dificil proporcionar reglas precisas sobre cuándo resulta apropiado emplear las técnicas centralizada o de integración de vistas. La decisión debe basarse en una evaluación de la complejidad del sistema de X Tabla 10.7. X Gerente X y los tipos de Referencia cruzada entre las vistas de usuario Supervisor Ayudante datos principales utilizados por cada una. Director
Capítulo 10 Técnicas de determinación de hechos
309
base de datos y en el grado de solapamiento entre las distintas vistas de usuario. Sin embargo, independientemente de si utilizamos la técnica centralizada o la de integración de vistas (o una mezcla de ambas) para construir la base de datos subyacente, al final necesitaremos re-establecer las vistas de usuario originales (es decir, la de Director, Gerente, Supervisor y Ayudante) para el sistema de base de datos final. Describiremos e ilustraremos el establecimiento de las vistas de usuario para el sistema de bases de datos en el Capítulo 17. Toda la información recopilada hasta ahora sobre cada vista de usuario del sistema de base de datos se describe en un documento denominado especificación de requisitos de usuario. Esta especificación describe los requisitos de los datos para cada vista de usuario y proporciona ejemplos de cómo se utilizan los datós en cada una de las vistas. Para facilitar la referencia, las especificaciones de requisitos de usuario para las vistas de usuario Sucursal y Empleados del sistema de base de datos de DreamHome se proporcionan en el Apéndice A. En el resto del capítulo, presentaremos los requisitos generales del sistema para el sistema de base de datos de DreamHome.
Especificaciones DreamHome
del sistema para el sistema de base de datos de
La especificación del sistema debe enumerar todas las características importantes del sistema de base de datos de DreamHome. Los tipos de características que deben describirse en la especificación del sistema incluyen: •
tamaño inicial de la base de datos;
•
tasa de crecimiento de la base de datos;
•
tipos y número promedio de búsquedas de registros;
• •
requisitos de interconexión en red y de acceso compartido; prestaciones;
•
seguridad;
•
copia de seguridad y recuperación;
•
cuestiones legales.
Requisitos del sistema
para la base de datos de DreamHome
Tamaño inicial de la base de datos (1) Hay aproximadamente 2.000 empleados trabajando en más de 100 sucursales. Hay un promedio de 20 y un máximo de 40 empleados en cada sucursal. (2) Hay aproximadamente 100.000 inmuebles disponibles en todas las sucursales. Hay un promedio de 1.000 y un máximo de 3.000 inmuebles en cada sucursal. (3) Hay aproximadamente 60.000 propietarios de inmuebles. Hay una media de 600 y un máximo de 1.000 propietarios en cada sucursal. (4) Hay aproximadamente 100.000 clientes registrados en todas las sucursales. Hay un promedio de 1.000 y un máximo de 1.500 clientes registrados en cada sucursal. (5) Hay aproximadamente 4.000.000 de visitas registradas en todas las sucursales. Hay una media de 40.000 y un máximo de 100.000 visitas en cada sucursal. (6) Hay aproximadamente 400.000 contratos de alquiler entre todas las sucursales. Hay un promedio de 4.000 y un máximo de 10.000 contratos de alquiler en cada sucursal. (7) Hay aproximadamente
50.000 anuncios de periódicos en 100 periódicos entre todas las sucursales.
Tasa de crecimiento de la base de datos (1) Cada mes se añaden a la base de datos aproximadamente tarios.
500 nuevos inmuebles y 200 nuevos propie-
310
Sistemas de bases de datos
(2) Cuando un inmueble deja de estar disponible para alquilar, el registro correspondiente base de datos. Cada mes se borran aproximadamente 100 registros de inmuebles.
se borra de la
(3) Si un propietario no proporciona ningún inmueble en alquiler a lo largo de un periodo de dos años, su registro se borra. Cada mes se borran aproximadamente 100 propietarios de inmuebles. (4) Aproximadamente 20 empleados se incorporan o abandonan la empresa cada mes. Los registros de los empleados que han abandonado la empresa se borran después de un año. Cada mes se borran aproximadamente 20 registros de empleado. (5) Cada mes se registran unos 1000 nuevos clientes entre las distintas sucursales. Si un cliente no visita o alquila un inmueble a lo largo de un periodo de dos años, su registro se borra. Cada mes se borran aproximadamente 100 registros de clientes. (6) Cada día se registran aproximadamente 5000 nuevas visitas entre todas las sucursales. Los detalles de las visitas a los inmuebles se borran un año después de creado el registro. (7) Cada mes se registran aproximadamente 1000 nuevos contratos de alquiler entre todas las sucursales. Los detalles de los contratos de alquiler se borran dos años después de la creación del registro. (8) Cada semana, se insertan unos 1000 anuncios en periódicos. Los detalles sobre los anuncios en los periódicos se borran un año después de creado el registro. Tipos y número medio de las búsquedas de registros (1) Búsqueda de la información relativa a una sucursal: aproximadamente
10 por día.
(2) Búsqueda de la información relativa a un empleado de una sucursal: aproximadamente
20 por día.
(3) Búsqueda de la información relativa a un cierto inmueble: aproximadamente 5000 por día (de lunes a jueves), aproximadamente 10.000 por día (viernes y sábados). Las horas punta de carga de trabajo son entre 12.00-14.00 y 17.00-19.00 diariamente. (4) Búsqueda de información sobre un propietario de un inmueble: aproximadamente
100 por día.
(5) Búsqueda de información sobre un cliente: aproximadamente 1000 por día (de lunes a jueves), aproximadamente 2000 por día (viernes y sábados). Las horas punta de carga de trabajo son entre 12.00-14.00 y 17.00-19.00 diariamente. (6) Búsqueda de información sobre una visita a un inmueble aproximadamente 2000 por día (de lunes a jueves), aproximadamente 52000 por día (viernes y sábados). Las horas punta de carga de trabajo son entre 12.00-14.00 y 17.00-19.00 diariamente. (7) Búsqueda de información sobre un contrato de alquiler: aproximadamente 1000 por día (de lunes ajueves), aproximadamente 2000 por día (viernes y sábados). Las horas punta de carga de trabajo son entre 12.00-14.00 y 17.00-19.00 diariamente. Requisitos de interconexión por red y acceso compartido Todas las sucursales deben estar conectadas por red de manera segura por una base de datos centralizada ubicada en la oficina principal de DreamHome en Glasgow. El sistema debe permitir que al menos dos o tres personas accedan concurrentemente al sistema desde cada sucursal. Es preciso tener en cuenta los requisitos de licencias para este número de accesos concurrentes. Prestaciones (1) Durante las horas de apertura, aunque no durante las horas puntas, debe poder esperarse un tiempo de respuesta inferior a un segundo para todas las búsquedas de un único registro. Durante las horas puntas, puede esperarse un periodo de respuesta inferior a 5 segundos para cada búsqueda. (2) Durante las horas de apertura, aunque no durante las horas puntas, puede esperarse un tiempo de respuesta inferior a 5 segundos para cada búsqueda de múltiples registros. Durante las horas punta, el tiempo de respuesta debe ser inferior a 10 segundos para cada búsqueda múltiple de registros.
Capítulo 10 Técnicas de determinación de hechos
311
(3) Durante las horas de apertura, aunque no durante las horas puntas, el tiempo de respuesta debe ser inferior a un segundo para cada operación de actualización/grabación. Durante las horas puntas, el tiempo de respuesta de estas operaciones debe ser inferior a 5 segundos. Seguridad (1) La base de datos debe estar protegida mediante contraseñas. (2) A cada empleado deben asignárseles los privilegios apropiados de acceso a la base de datos que se correspondan con una vista de usuario concreta, la de Director, Gerente, Supervisor o Ayudante. (3) Cada empleado sólo debe poder ver los datos necesarios para hacer su tarea y una forma que resulte adecuada para lo que esté haciendo. Copia de seguridad y recuperación Debe hacerse una copia de seguridad de la base de datos diariamente a las doce de la noche. Cuestiones legales Cada país tiene una serie de leyes que gobiernan la forma en que pueden gestionarse los datos de carácter personal almacenados en sistemas informáticos. Ya que la base de datos de DreamHome contiene datos sobre los empleados, clientes y propietarios de inmuebles, será preciso destinar e implementar todas las normas legales con las que haya que cumplir.
10.4.5 El caso de estudio de DreamHome: diseño de la base de datos En este capítulo hemos ilustrado cómo se crea la especificación de requisitos de un usuario para las vistas de usuario de Sucursal (Branch) y Empleados (Staff) y la especificación del sistema para la base de datos de DreamHome. Estos documentos son la fuente de información para la siguiente etapa del ciclo de desarrollo, denominada diseño de la base de datos. En los Capítulos 15 a 18 proporcionaremos una metodología paso a paso para el diseño de bases de datos y utilizaremos el caso de estudio de DreamHome y los documentos creados para el sistema de DreamHome en este capítulo con el fin de ilustrar en la práctica dicha metodología.
Resumen del capítulo •
La detección de hechos es el proceso formal de utilizar técnicas tales como entrevistas y cuestionarios para recopilar hechos acerca de los sistemas, los requisitos y las preferencias.
•
La determinación de hechos resulta particularmente crucial en las primeras etapas del ciclo de desarrollo de los sistemas de bases de datos, incluyendo las etapas de planificación de la base de datos, definición del sistema y recopilación y análisis de requisitos. Las cinco técnicas más comunes de determinación de hechos son el examen de la documentación, las entrevistas, la observación de la operación de la empresa, la realización de investigaciones y la utilización de cuestionarios.
•
•
Durante la etapa de recopilación y análisis de requisitos se crean dos documentos principales, que son la especificación de requisitos de usuario y la especificación del sistema.
•
La especificación de requisitos de usuario describe en detalle los datos que hay que almacenar en la base de datos y cómo es necesario utilizados.
•
La especificación del sistema describe las características datos, tal como los requisitos de prestaciones y seguridad.
que hay que incluir en el sistema de base de
Cuestiones de repaso 10.1. Describa brevemente qué es lo que el desarrollador de una base de datos trata de conseguir mediante el proceso de determinación de hechos.
312
Sistemas de bases de datos
10.2.
Describa cómo se utiliza el proceso de determinación desarrollo de un sistema de base de datos.
10.3.
Para cada etapa del ciclo de desarrollo de un sistema de base de datos, proporcione ejemplos de los hechos capturados y de la documentación producida. Un desarrollador de bases de datos utiliza normalmente diversas técnicas de determinación de hechos durante un mismo proyecto de base de datos. Las cinco técnicas más comúnmente utilizadas son el examen de la documentación, las entrevistas, la observación de la operación de la empresa, la realización de investigaciones y la utilización de cuestionarios. Describa cada técnica de determinación de hechos e indique las ventajas y desventajas de las mismas.
IDA.
10.5.
de hechos durante las etapas del ciclo de
Describa el propósito de definir un enunciado de la misión y los objetivos de dicha misión para un sistema de base de datos.
10.6.
¿Cuál es el propósito de identificar los límites del sistema para una base de datos?
10.7.
¿En qué difiere el contenido de una especificación de registros de usuario del de una especificación del sistema?
10.8.
Describa un método para decidir si debe utilizarse la técnica centralizada o la técnica de integración de vistas (o una combinación de ambas) a la hora de desarrollar un sistema de base de datos con múltiples vistas de usuario.
Ejercicios 10.9.
Suponga que está desarrollando un sistema de base de datos para su organización, ya sea ésta una universidad (o facultad) o una empresa (o departamento). Considere qué técnicas de determinación de hechos utilizaría para identificar los hechos de importancia necesarios para desarrollar el sistema de base de datos. Identifique las técnicas que emplearía para cada etapa del ciclo de desarrollo del sistema de base de datos.
10.10. Suponga que está desarrollando un sistema de base de datos para los casos de estudio descritos en el Apéndice B. Considere qué técnicas de determinación de hechos utilizaría para identificar los hechos importantes necesarios para desarrollar un sistema de bases de datos. 10.11. Enuncie la misión y los objetivos de la misión para los sistemas de base de datos descritos en los casos de estudio del Apéndice B. 10.12. Dibuje un diagrama que represente el ámbito y los límites de los sistemas de base de datos descritos en los casos de estudio del Apéndice B. 10.13. Identifique las principales vistas de usuario para los sistemas de base de datos descritos en los casos de estudio del Apéndice B.
Capítulo
Modelos entidad-relación
Objetivos del capítulo: En este capítulo aprenderá: •
Cómo utilizar los modelos entidad-relación
(ER) en el diseño de bases de datos.
•
Los conceptos básicos asociados con el modelo entidad-relación ciones y los atributos.
•
Una técnica diagramática para mostrar un modelo ER utilizando el lenguaje UML (Unified Modeling Language, lenguaje unificado de modelado).
•
Cómo identificar y resolver una serie de problemas de los modelos ER denominados trampas de conexión.
(ER), es decir, las entidades, las rela-
En el Capítulo 10 hemos descrito las técnicas principales de recopilación y captura de información acerca de lo que los usuarios requieren de un sistema de bases de datos. Una vez completada la etapa de recopilación y análisis de requisitos dentro del ciclo de desarrollo del sistema de base de datos, y una vez documentados los requisitos del sistema de base de datos, estaremos listos para comenzar con la etapa de diseño de base de datos. Uno de los aspectos más complicados del diseño de base de datos es el hecho de que los diseñadores, programadores y usuarios finales tienden a contemplar los datos y su utilización de diferentes maneras. Desafortunadamente, al menos que se alcance una compresión común que refleje cómo opera la empresa, el diseño que produzcamos no podrá satisfacer los requisitos de los usuarios. Para garantizar que se obtiene una comprensión precisa de la naturaleza de los datos y del modo en que éstos se utilizan en la empresa, necesitamos disponer de un modelo de comunicación que sea no técnico y que esté libre de ambiguedades. El modelo Entidad-Relación (ER) es un ejemplo de dicho tipo de modelo. El modelado ER es una técnica de diseño de base de datos de tipo arriba a abajo que comienza identificando los datos más importantes, denominados entidades, y las relaciones entre los datos que deben representarse en el modelo. Después se añaden más detalles, como la información que se quiere almacenar acerca de las entidades y relaciones, lo que se denomina atributos y sobre cualesquiera restricciones que haya que aplicar a las entidades, relaciones y atributos. Los modelos ER constituyen una técnica de gran importancia que todos los diseñadores de bases de datos deberían dominar y forma la base de la metodología presentada en este libro. En este capítulo se introducen los conceptos básicos de los modelos ER. Aunque existe un acuerdo general acerca del significado de cada concepto, hay una serie de diferentes notaciones que pueden utilizarse para presentar cada concepto en un diagrama. Hemos elegido una notación diagramática que emplea un lenguaje de modelado orientado a objetos cada vez más popular, que se denomina UML (Unified Modeling Language) (Booch et al., 1999). UML es el suceso de una serie de métodos de análisis y diseño orientados a objetos que se introdujeron en las décadas de 1980 y 1990. La organización OMG (The Object Management Group) trata actualmente de estandarizar UML y la provisión es que este lenguaje sea el estándar de Jacto para modelado a corto plazo. Aunque utilizaremos la notación UML para dibujar modelos ER, continuaremos des-
314
Sistemas de bases de datos
cribiendo los conceptos de esos modelos ER utilizando la terminología tradicional de las bases de datos. En la Sección 27.7 se ofrece un análisis más completo sobre UML. Asimismo, en el Apéndice E hemos incluido un resumen de dos notaciones diagramáticas alternativas para los modelos ER. En el siguiente capítulo hablaremos de los problemas inherentes asociados con la representación de aplicaciones de bases de datos complejas utilizando los conceptos básicos del modelo ER. Para resolver estos problemas, se añadieron conceptos 'semánticos' adicionales al modelo ER original, dando como resultado el desarrollo del modelo EER (Enhanced Entity-Relationship, modelo avanzado entidad-relación). En el Capítulo 12 describiremos los conceptos príncipales asociados con el modelo EER, es decir, los conceptos de especialización/generalización, agregación y composición. También veremos cómo convertir el modelo ER mostrado en la Figura 11.1 en el modelo EER que se muestra en la Figura 12.8.
Estructura del capítulo En las Secciones 11.1, 11.2 Y 11.3 se presentan los conceptos básicos del modelo Entidad-Relación, es decir, las entidades, las relaciones y los atributos. En cada sección se ilustra cómo representar pictóricamente cada uno de los conceptos básicos de los modelos ER en un diagrama ER mediante el lenguaje UML. En la Sección I lA veremos la diferencia entre entidades fuertes y débiles y en la Sección 11.5 hablaremos de cómo pueden asignarse a las relaciones los atributos normalmente asociados con las entidades. En la Sección 11.6 se describen las restricciones estructurales asociadas con las relaciones. Finalmente, en la Sección 11.7 se describe una serie de problemas potenciales asociados con el diseño de un modelo ER, denominados trampas de conexión, y se ilustra cómo resolver estos problemas. El diagrama ER mostrado en la Figura 11.1 es un ejemplo de uno de los posibles productos resultantes de la tarea de modelado ER. Este modelo representa las relaciones entre los datos descritos en la especificación de requisitos para la vista Branch (sucursales) y el caso de estudio de DreamHome dado en el Apéndice A. Esta figura se presenta al principio del capítulo para mostrar al lector un ejemplo del tipo de modelo que puede construirse mediante las técnicas de modelado ER. En esta etapa, el lector no debe preocuparse de entender completamente el diagrama, ya que los conceptos y la notación utilizados en la figura se explican en detalle a lo largo del capítulo.
11.1 Tipos de entidad Tipo de entidad
Un grupo de objetos con las mismas propiedades, poseedores de una existencia independiente.
que la empresa
identifica como
El concepto básico del modelo ER es el tipo de entidad, que representa un grupo de 'objetos' del 'mundo real' que tienen las mismas propiedades. Un tipo de entidad tiene una existencia independiente y puede tratarse de objetos con una existencia física (o 'real') o de objetos con una existencia conceptual (o 'abstracta'), como se indica en la Figura 11.2. Observe que tan solo podemos dar una definición práctica de lo que es un tipo de entidad, ya que no existe una definición formal estricta. Esto quiere decir que los diferentes diseñadores podrían identificar diferentes entidades. Instancia de una entidad
Un objeto identificable de forma unívoca dentro de un tipo de entidad.
Cada objeto unívocamente identificable, dentro de un tipo de entidad, se denomina instancia de entidad. A lo largo del libro, utilizaremos los términos 'tipo de entidad' o 'instancia de entidad'; sin embargo, siempre que podamos emplearemos el término más general 'entidad' cuando el significado sea obvio. Cada tipo de entidad se identifica mediante un nombre y una lista de propiedades. Una base de datos contiene normalmente muchos tipos diferentes de entidades. En la Figura 11.1 se muestran, entre otros, los siguientes ejemplos de tipos de entidad: 8taff, Branch, PropertyForRent y PrivateOwner.
Capítulo 11 Modelos entidad-relación
, I 1.1 dateAdvert POwns Advertisescost 0.100 1 . .* propertyNo
.~
.•• Supervises 1.* Manages ~ , .•• Has Client I.Preference clientNo .* 1.1 1.1 1.1 1.* 0.1 0 .. 1 BusinessOwner PrivateOwner BOwns bName 01.1 1.1 . .*0States ownerNo ~ .•• Holds branchNo 1.* Staff 1.1 1.* Branch PropertyForRent Lease 0.1
1:
~
.•• LeasedBy
I
"
315
mgrStartDate bonus 0 ..*
Offers
1.1
Overs
Figura 11.1. Un diagrama Entidad-Relación de la vista Branch de DreamHome.
(ER)
Representación diagramática de los tipos de entidad Cada tipo de entidad se muestra como un rectángulo etiquetado con el nombre de la entidad, que es normalmente un nombre singular. En UML, la primera línea de cada palabra del nombre de entidad se escribe en mayúscula (por ejemplo, Staff y PropertyForRent). La Figura 11.3 ilustra la representación diagramática de los tipos de entidad Staff y Branch.
316
Sistemas de bases de datos
Existencia física Personal
Componente
Inmueble
Suministrador
Cliente
Producto
Existencia conceptual
Figura 11.2.
Vista
Venta
Inspección
Experiencia laboral
Ejemplo de entidades co~ una existencia física conceptual.
Branch
Staff
Figura 11.3.
Representación
diagramática de los tipos de entidad Staffy Branch.
11.2 Tipos de relación Tipo de relación
Un conjunto de asociaciones
significativas entre tipos de entidad.
Un tipo de relación es un conjunto de asociaciones entre uno o más tipos de entidad participantes. Cada tipo de relación recibe un nombre que describe su función. Un ejemplo de tipo de relación mostrado en la Figura 11.1 es la relación denominada POwns (posee), que asocia las entidades PrivateOwner (propietario) y PropertyForRent (inmueble en alquiler). Al igual que los tipos de entidad y las entidades, es necesario distinguir entre los términos 'tipo de relación' e 'instancia de relación' . Instancia relación
de
Una asociación identificable de forma unívoca que incluye una instancia de cada uno de los tipos de entidad participantes.
Una instancia de relación indica las instancias de entidad concretas que están relacionadas. A lo largo del libro, utilizaremos los términos 'tipos de relación' o 'instancia de relación'. Sin embargo, al igual que sucedía con el término 'entidad', emplearemos el término más general 'relación' cuando el significado sea obvio. Considere un tipo de relación denominado Has (tiene), que represente una asociación entre las entidades Branch (sucursal) y Staff(empleados), es decir Branch Has Staff.Cada instancia de la relación Has asocia una instancia de la entidad Branch con otra instancia de la entidad Staff.Podemos examinar ejemplos de las instancias individuales de la relación Has utilizando una red semántica. Una red semántica es un modelo de nivel de objetos, que utiliza el símbolo. para representar entidades y el símbolo ~ para representar relaciones. La red semántica de la Figura 11.4 muestra tres ejemplos de la relación Has (denominados rl, r2 y r3). Cada
Capítulo 11 Modelos entidad-relación
Entidad Branch (branchNo)
Figura 11.4.
317
Entidad 8taft (staftNo)
Relación Has~
Una red semántica que muestra instancias individuales
relación describe una asociación de una única instancia de la entidad
Branch
del tipo de relación Has.
con una única instancia de la enti-
dad 8taff. Las relaciones se representan mediante líneas que unen cada entidad Branch participante con la entidad 8taff asociada. Por ejemplo, la relación r1 representa la asociación entre la entidad Branch B003 y la entidad 8taff SG37. Observe que representamos cada instancia de las entidades Branch y 8taff utilizando valores para sus atributos de clave primaria es decir, branchNo y staffNo. Los atributos de clave primaria identifican unívocamente cada instancia con la entidad y se explican en detalle en la sección siguiente. Si representáramos una empresa utilizando redes semánticas, sería difícil comprender el modelo debido a la gran cantidad de detalles incluidos. Podemos representar más fácilmente las relaciones entre entidades dentro de una empresa utilizando los conceptos del modelo Entidad-Relación (ER). El modelo ER utiliza un nivel de abstracción más alto que las redes semánticas, al combinar conjuntos de instancias de entidades en tipos de entidades y conjuntos de instancias de relaciones en tipos de relaciones.
Representación
diagramática
de los tipos de relaciones
Cada tipo de relación se muestra como una línea que conecta los tipos de entidad asociados, línea que se etiqueta con el nombre de la relación. Normalmente, una relación se nombra utilizando un verbo (por ejemplo Supervisa o Gestiona) o una corta frase que incluya un verbo (por ejemplo, AlquiladoPor). De nuevo, la primera letra de cada palabra del nombre de relación se muestra en mayúscula. Siempre que sea posible, el nombre de cada relación debe ser único dentro de un modelo ER dado. Una relación sólo se etiqueta en una dirección, lo que normalmente significa que el nombre de la relación sólo tiene sentido en una dirección (por ejemplo, Branch Has 8taff tiene más sentido que 8taff Has Branch). Por tanto, una vez que se ha elegido el nombre de la relación se coloca un símbolo de flecha alIado del nombre para indicar la dirección correcta con la que un lector debe interpretar el nombre de la relación (por ejemplo, Branch Has ~ 8taff) como se muestra en la Figura 11.5 .
Staff
••• Has Branch
'Una sucursal tiene cierto empleado'
Figura 11.5.
Una representación
diagramática
del tipo de relación Branch Has Staff.
318
Sistemas de bases de datos
11.2.1 Grado de un tipo de relación Grado de un
El número de tipos de entidad que participan en una relación.
tipo de relación
Las entidades implicadas en un tipo de relación concreta se denominan participantes en dicha relación. El número de participantes en un tipo de relación se denomina grado de dicha relación. Por tanto, el grado de una relación indica el número de tipos de entidad implicados en la misma. Una relación de grado dos se denomina binaria. Un ejemplo de relación binaria sería la relación Has mostrada en la Figura 11.5, que tiene dos tipos de entidad participantes, que son 8taft y Branch. Un segundo ejemplo de relación binaria sería la relación POwns mostrada en la Figura 11.6, con dos tipos de entidad participantes, que son PrivateOwner y PropertyForRent. Las relaciones Has y POwns también se plUestran en la Figura 11.1, junto con otros ejemplos de relaciones binarias. De hecho, el grado más común para una relación es el binario, como se puede ver en dicha figura. Una relación de grado tres se denomina ternaria. Un ejemplo de relación ternaria sería Registers, que tiene tres tipos de entidad participante, que son 8taft, Branch y Client. Esta relación representa el registro de un cliente por un empleado en una sucursal. Utilizamos el término 'relación compleja' para describir las relaciones con un grado superior a dos.
Representación
diagramática
de relaciones complejas
La notación UML utiliza un rombo para representar relaciones con grado superior a dos. El nombre de la relación se muestra dentro del rombo y, en este caso, la flecha de dirección normalmente asociada con el nombre se omite. Por ejemplo, la relación ternaria denominada Registers se muestra en la Figura 11.7. Esta relación también aparece en la Figura 11.1 Una relación de grado cuatro se denomina cuaternaria. Puesto que no existe ningún ejemplo de dicho tipo de relación en la Figura 11.1, vamos a describir una relación cuaternaria denominada Gestiona con cuatro tipos de entidad participante, denominados Comprador, Agente, InstituciónFinanciera y Oferta en la Figura 11.8. Esta relación representa la situación en que un comprador, aconsejado por un agente y con el soporte de una institución financiera, hace una oferta. 'Propietario privado posee inmueble en alquiler' POwns ~
PrivateOwner
Figura 11.6.
SI,,,
PropertyForRent
Un ejemplo de una relación binaria denominada
~
POwns.
Bme,h 'El empleado registra un cliente en una sucursal'
Client
Figura 11.7.
Un ejemplo de relación ternaria denominada
Registers.
11.2.2 Relación recursiva Relación recursiva
Un tipo de relación en el que el mismo tipo de entidad participa más de una vez en diferentes papeles.
Capítulo 11 Modelos entidad-relación
Agente
319
'Un agente gestiona una oferta por parte de un comprador con el soporte de una institución financiera'
Institución Financiera
Comprador
Oferta
Figura 11.8.
Un ejemplo de relación cuaternaria,
denorninada
Gestiona.
Considere una relación recursiva denominada Supervises (supervisa), que representa una asociación de un empleado con un Supervisor, dándose la circunstancia de que el Supervisor también es un empleado. En otras palabras, el tipo de entidad Staff participa dos veces en la relación Supervises; primero participa como Supervisor y en segundo lugar como empleado supervisado. Las relaciones recursivas se denominan en ocasiones relaciones unarias. Las relaciones pueden recibir nombres de roles para indicar el papel que cada tipo de entidad participante juega en una relación. Los nombres de rol pueden ser importantes en las relaciones recursivas para determinar la función de cada participante. El uso de nombres de rol para describir la relación recursiva Supervises se muestra en la Figura 11.9. La primera participación del tipo de entidad Staff en la relación Supervises recibe el nombre de rol 'Supervisor', mientas que la segunda participación recibe el nombre de rol 'Supervisado'. Los nombres de rol también se pueden utilizar cuando dos entidades están asociadas a través de más de una relación. Por ejemplo, los tipos de entidad Staff y Branch están asociados mediante dos relaciones distintas denominadas Manages y Has. Como se muestra en la Figura 11.10, el uso de nombres de rol clarifica el propósito de cada relación. Por ejemplo, en el caso de Staff Manages Branch, un empleado (entidad Staff) al que se ha dado el nombre de rol 'Gerente' gestiona una sucursal (entidad Branch) a la que se ha dado el nombre de rol 'Sucursal'. De forma similar, para Branch Has Staff, una sucursal, a la que se ha dado el nombre de rol 'Sucursal' tiene una serie de empleados, a los cuales se les da el nombre de rol 'Empleado'. Los nombres de rol normalmente no son necesarios si la función de las entidades participantes en una relación no resulta ambigua. Nombre rol 'Un empleado (Supervisor) supervisa a otro (Supervisado)' .•• Supervises Supervisor
Personal ~
Figura 11.9.
Supervisado
Un ejemplo de relación recursiva, denominada Supervises, con los nombres de rol Supervisor y Supervisado.
11.3 Atributos Atributo
Una propiedad de un tipo de entidad o de relación.
320
Sistemas de bases de datos
'Ungerentegestionauna sucursal'
Sucursal
Gerente Manages ~ Personal
Sucursal
••• Has
Empleado
Sucursal
'Una sucursaltieneempleados' Figura 11.10.
Un ejemplo de entidades asociadas mediante dos relaciones distintas, denominadas Manages y Has, con los nombres del rol.
Las propiedades particulares de los tipos de entidad se denominan atributos. Por ejemplo, el tipo de entidad Staff podría describirse mediante los atributos staffNo(número de empleado), name (nombre), position (categoría) y salary (salario). Los atributos contienen valores que describen cada instancia de la entidad y representan la parte principal de los datos almacenados en la base de datos. Un tipo de relación que asocie entidades también puede tener atributos similares a los de un tipo de entidad, aunque dejaremos la explicación de este caso hasta la Sección n.5. En esta sección, nos vamos a concentrar en las características generales de los atributos. Dominio de atributo
El conjunto de valores permitidos para uno o más atributos.
Cada atributo está asociado con un conjunto de valores, denominado dominio. El dominio define los valores potenciales que un atributo puede tener y es similar al concepto de dominio en el modelo relacional (véase la Sección 3.2). Por ejemplo, el número de habitaciones asociadas con un inmueble está comprendido entre 1 y 15 para cada instancia de la entidad. Por tanto, definimos el conjunto de valores para el atributo de número de habitaciones (rooms) del tipo de entidad PropertyForRent como el conjunto de enteros comprendidos entre 1 y 15. Los atributos pueden compartir un dominio. Por ejemplo, los atributos address de los tipos de entidad Branch, PrivateOwnery BusinessOwner comparten el mismo dominio, formado por todas las posibles direcciones. Los dominios también pueden estar compuestos por otros dominios. Por ejemplo, el dominio del atributo address de la entidad Branch está compuesto de una serie de subdominios: street (calle), city (ciudad) y postcode (código postal). El dominio del atributo name (nombre) es más dificil de definir, ya que está compuesto de todos los nombres posibles. Se trata ciertamente de una cadena de caracteres, pero podría estar compuesto no sólo de letras sino también de guiones u otros caracteres especiales. Un modelo de datos completo debe incluir los dominios de todos los atributos en el modelo ER. Como ahora explicaremos, los atributos pueden clasificarse como: simples o compuestos; univaluados o multivaluados; o derivados.
11.3.1 Atributos simples y compuestos Atributo simple
Un atributo compuesto de un único componente con existencia independiente.
Capítulo 11 Modelos entidad-relación
321
Los atributos simples no pueden subdividirse en componentes más pequeños. Como ejemplos de atributos simples tenemos los atributos position y salary de la entidad 8taff. Los atributos simples se denominan en ocasiones atributos atómicos. Atributo compuesto
Un atributo que está formado por múltiples componentes, existencia independiente.
cada uno de ellos con una
Algunos atributos pueden dividirse para obtener componentes más pequeños con existencia independiente propia. Por ejemplo, el atributo address de la entidad Branch con el valor (163 Main St, Glasgow, GIl 9QX) puede subdividirse en los street (163 MAin St), city (Glasgow) y postcode (GIl 9QX), siendo todos ellos atributos componentes del anterior. La decisión de modelar el atributo address como un atributo simple o subdividido en street, city y postcode depende de si la vista de usuario de los datos hace referencia al atributo address como una sola unidad o mediante sus componentes individuales.
11.3.2 Atributos univaluados y multivaluados Atributo univaluado
Un atributo que contiene un único valor para cada instancia de un tipo de entidad.
La mayoría de los atributos son univaluados. Por ejemplo, cada instancia del tipo de entidad Branch tiene un único valor para el atributo de número de sucursal (branchNo), como por ejemplo B003, y por tanto el atributo branchNo es un atributo univaluado. Atributo multivaluado
Un atributo que contiene múltiples valores para cada instancia de un tipo de entidad.
Algunos atributos tienen múltiples valores para cada instancia de la entidad. Por ejemplo, cada instancia del tipo de entidad Branch puede tener múltiples valores para el atributo telNo que indica el número telefónico (por ejemplo, el número de sucursal B003 tiene los números telefónicos 0141-339-2178 y 0141-339-4439), por lo que el atributo telNo es en este caso multivaluado. Un atributo multivaluado puede tener un conjunto de números con límites inferior y superior. Por ejemplo, el atributo telNo del tipo de entidad Branch tiene entre uno y tres valores. En otras palabras, una sucursal puede tener un mínimo de un único número telefónico y un máximo de tres números telefónicos distintos.
11.3.3 Atributos derivados Atributo derivado
Un atributo que representa un valor que puede derivarse del valor de un atributo o conjunto de atributos relacionados, no necesariamente del mismo tipo de entidad.
Los valores contenidos para algunos atributos pueden ser valores derivados. Por ejemplo, el valor del atributo duration (duración) de la entidad Lease (contrato) se calcula a partir de los atributos rent8tart (inicio del contrato) y rentFinish (fin del contrato), que también pertenecen al tipo de entidad Lease. Diremos en este caso que el atributo duration es un atributo derivado, pudiendo deducirse su valor a partir de los atributos rent8tart y rentFinish. En algunos casos, el valor de un atributo se deriva de las instancias de entidad del mismo tipo de entidad. Por ejemplo, el atributo de número total de empleados (totaI8taff)del tipo de entidad 8taffpuede calcularse contando el número total de instancias de la entidad 8taff. Los atributos derivados también pueden implicar la asociación de atributos de diferentes tipos de entidad. Por ejemplo, considere un atributo denominado deposit (fianza) del tipo de entidad Lease. El valor del atributo deposit se calcula multiplicando por dos el alquiler mensual de un inmueble. Por tanto, el valor del atributo deposit del tipo de entidad Lease se deriva del atributo rent del tipo de entidad PropertyForRent.
322
Sistemas de bases de datos
11.3.4 Claves Clave candidata
El conjunto mínimo de atributos que identifican de forma unívoca cada instancia de un tipo de entidad.
Una clave candidata es el número mínimo de atributos cuyos valores identifican de manera unívoca cada instancia de la entidad. Por ejemplo, el atributo de número de sucursal (branchNo) es la clave candidata para el tipo de entidad Branch, y tiene un valor diferente para cada sucursal. La clave candidata debe contener valores que sean unívocos para cada instancia de un tipo de entidad. Esto implica que una clave candidata no puede contener valores nulos (véase la Sección 3.2). Por ejemplo, cada sucursal tiene un número de sucursal distintivo (por ejemplo, B003) y nunca habrá dos sucur~ales que tengan el mismo número. Clave principal
La clave candidata que se selecciona para identificar de forma unívoca cada instancia de un tipo de entidad.
Un tipo de entidad puede tener más de una clave candidata. De cara a nuestro análisis, consideremos que cada empleado tiene un número de empleado unívoco definido por la empresa (staffNo) y también un número de la Seguridad Social que le asigna el Gobierno. Por tanto, tenemos dos claves candidatas para la identidad 8taff, debiendo seleccionar una de las dos como clave principal. La elección de clave principal para una entidad se basa en consideraciones de la longitud del atributo, del número mínimo de atributos requeridos y de la certidumbre de unicidad futura. Por ejemplo, el número de empleado definido por la empresa contiene un máximo de cinco caracteres (por ejemplo, SG 14) mientras que el número de la Seguridad Social en el Reino Unido contiene un máximo de nueve caracteres (por ejemplo, WL220658D). Por tanto, seleccionamos staffNocomo clave principal del tipo de entidad 8taff, por lo cual NIN (número de la Seguridad Social) se denominará clave alternativa. Clave
Una clave candidata que está formada por dos o más atributos.
compuesta
En algunos casos, la clave de un tipo de entidad está compuesta de varios atributos, cuyos valores, tomados conjuntamente, son unívocos para cada instancia de la entidad, pero no son unívocos si se los considera por separado. Por ejemplo, considere una entidad denominada Advert (anuncio) con los atributos propertyNo (número de inmueble), newspaperName (nombre del periódico) y dateAdvert (fecha del anuncio) y cost (coste). En una fecha determinada, se anuncian numerosos inmuebles en diversos periódicos. Para identificar de forma unívoca cada instancia del tipo de entidad Advert, necesitamos conocer los valores de los atributos propertyNo, newspaperName y dateAdvert. Por tanto, el tipo de entidad Advert tiene una clave primaria compuesta, que está formada por los tres atributos mencionados.
Representación
diagramática
de los atributos
Si queremos mostrar un tipo de entidad con sus atributos, dividimos el rectángulo que representa la entidad en dos. La parte superior del rectángulo muestra el nombre de la entidad y la parte inferior enumera los nombres de los atributos. Por ejemplo, la Figura 11.11 muestra el diagrama ER para los tipos de entidad 8taff y Branch y sus atributos asociados. El primer atributo (o atributos) que hay que enumerar es la clave principal del tipo de entidad, si se conoce. El nombre del atributo o atributos de la clave principal puede etiquetarse con una indicación como {PK} (primary key, clave principal). En UML, el nombre de un atributo se muestra con la primera letra en minúscula y, si el nombre tiene más de una palabra, la primera letra de cada palabra subsiguiente en mayúscula (por ejemplo, address y teINo). Pueden utilizarse etiquetas adicionales, como la de clave primaria parcial {PPK} (partial primary key), cuando un atributo forme parte de una clave primaria compuesta, y clave alternativa {AK} (alternate key). Como se muestra en la Figura 11.11, la clave principal del tipo de entidad 8taff es el atributo staffNoy la clave principal del tipo de entidad Branch es el atributo branchNo. Para algunos sistemas de base de datos más simples, es posible mostrar todos los atributos de cada tipo de entidad en el diagrama ER. Sin embargo, para sistemas de base de datos más complejos, simplemente se
Capítulo 11 Modelos entidad-relación
Figura 11.11.
Staff
Manages ~
Branch
staffNo {PK} name position salary /totalStaff
.••Has
branchNo {PK} address street city postcode telNo [1 ..3]
Representación
diagramática
323
de las entidades Staff y Branch y sus atributos.
muestran el atributo o atributos que fueron la clave principal de cada tipo de entidad. Cuando sólo se muestren los atributos o clave principal en el diagrama ER, puede omitirse la etiqueta {PK}. Para atributos simples y univaluados, no hay necesidad de utilizar etiquetas, por lo que simplemente se muestran los nombres de los atributos en una lista debajo del nombre de la entidad. Para atributos compuestos, se incluye el nombre del atributo compuesto, seguido debajo suyo y con sangrado a la derecha por los nombres de sus atributos componentes simples. Por ejemplo, en la Figura 11.11, el atributo compuesto address de la entidad Branch aparece seguido por los nombres de sus atributos componentes street, city y postcode. Para atributos multivaluados, etiquetamos el nombre del atributo con una indicación del rango de valores disponibles para el mismo. Por ejemplo, si etiquetamos el atributo telNo con el rango [1.. *], esto quiere decir que el atributo telNo puede tener uno o más valores. Si conocemos con precisión el número máximo de valores, podemos etiquetar el atributo con un rango exacto. Por ejemplo, si el atributo telNo contiene entre uno y un máximo de tres valores, podemos etiquetar el atributo como [1..3]. Para los atributos derivados, precedemos el nombre del atributo con un símbolo '/'. Por ejemplo, el atributo derivado del tipo de entidad 8taff se muestra en la Figura 11.11, /totaI8taff.
11.4 Tipos de entidad fuertes y débiles Podemos clasificar los tipos de entidad como fuertes o débiles. Tipo de entidad fuerte
Un tipo de entidad cuya existencia no depende de ningún otro tipo de entidad.
Un tipo de entidad será fuerte si su existencia no depende de la existencia de otro tipo de entidad. En la Figura 11.1 se muestran varios ejemplos de entidades fuertes, entre los que se incluyen 8laff, Branch, PropertyForRent y Client. Una característica de los tipos de entidad fuertes es que cada instancia de la entidad puede identificarse de manera unívoca utilizando los atributos de clave principal de dicho tipo de entidad. Por ejemplo, podemos identificar unívocamente cada empleado utilizando el atributo staffNo, que es la clave principal del tipo de entidad 8taff. Tipo de entidad débil
Un tipo de entidad cuya existencia depende de algún otro tipo de entidad.
Un tipo de entidad débil depende de la existencia de otro tipo de entidad. En la Figura 11.12 se muestra un ejemplo de un tipo de entidad débil denominado Preference (preferencia). Una característica de una entidad
324
Sistemas de bases de datos
Client
States ~
Preference prefType maxRent
c1ientNo {PK} name fName IName telNo
Figura 11.12. Un tipo de entidad fuerte denominado Client y un tipo de entidad débil denominado Preference.
débil es que cada instancia de la entidad no puede identificarse unívocamente utilizando únicamente los atributos asociados con ese tipo de entidad. Por ejemplo, observe que no hay ninguna clave principal para la entidad Preference. Esto significa que no podemos identificar cada instancia del tipo de entidad Preference utilizando sólo los atributos de esta entidad. La única forma de identificar unívocamente cada preferencia es utilizando la relación que las preferencias tienen con los clientes, los cuales sí que son identificables unívocamente utilizando la clave principal del tipo de entidad Client, que es clientNo. En este ejemplo, la entidad Preference se describe diciendo que su existencia depende de la entidad Client, a la que denominaremos entidad propietaria. Los tipos de entidad débiles a veces se denominan entidades hijas, dependientes o subordinadas, mientras que a los tipos de entidad fuertes se les denomina entidades padres, propietarias o dominantes.
11.5 Atributos de las relaciones Como hemos mencionado en la Sección 11.3, también pueden asignarse atributos a las relaciones. Por ejemplo, considere la relación Advertises, que asocia los tipos de entidad Newspaper y PrapertyFarRent como se muestra en la Figura 11.1. Para registrar la fecha en que el inmueble fue anunciado y el coste del anuncio, asociamos esta información con la relación Advertises en forma de atributos denominados dateAdvert y cast, en lugar de asociar esos atributos con las entidades Newspaper o PrapertyFarRent.
Representación
diagramática
de los atributos de las relaciones
Los atributos asociados con un tipo de relación se representan utilizando el mismo símbolo que un tipo de entidad. Sin embargo, para distinguir entre una relación con un atributo y una entidad, el rectángulo que representa el atributo o atributos se asocia con la relación utilizando una línea punteada. Por ejemplo, la Figura 11.13 muestra la relación Advertises con los atributos dateAdvert y casI. Un segundo ejemplo mostrado en la Figura 11.1 es la relación Manages, que tiene los atributos mgrStartDate y banus. La presencia de uno o más atributos asignados a una relación puede indicar que la relación oculta un tipo de entidad aún no identificado. Por ejemplo, la presencia de los atributos dateAdvert y cast en la relación Advertises indica la presencia de una entidad denominada Advert (anuncio)
11.6 Restricciones estructurales Ahora vamos a examinar las restricciones que pueden imponerse a los tipos de entidad que participan en una relación. Las restricciones deben reflejar las restricciones que se perciban en el 'mundo real' para esas relaciones. Como ejemplos de dichas restricciones tendríamos el requisito de que un inmueble en alquiler debe tener un propietario y de que cada sucursal debe tener empleados. El tipo principal de restricción sobre las relaciones se denomina multiplicidad.
Capítulo 11 Modelos entidad-relación
325
'El periódicoanunciaun inmuebleen alquiler'
newspaperName I
Newspaper
PropertyForRent I propertyNo Advertises~
I
dateAdvert cost Figura 11.13. Multiplicidad
Un ejemplo de relación denominada
Advertises con atributos dateAdvert y cosí.
El número (o rango) de posibles instancias de un tipo de entidad que pueden relacionarse con una única instancia de otro tipo de entidad asociado a través de una relación concreta.
La multiplicidad restringe la forma en que las entidades se relacionan. Se trata de una representación de las políticas (o reglas de negocio) establecidas por el usuario o la empresa. Garantizar que se identifiquen y representen todas las restricciones empresariales apropiadas constituye una parte importante de la tarea de modelado de una empresa. Como hemos mencionado anteriormente, el grado más común para las relaciones es el binario. Las relaciones binarias se clasifican a menudo como de tipo uno a uno (1 :1), uno a muchos (1: *) o muchos a muchos (*:*). Vamos a examinar estos tres tipos de relaciones utilizando las siguientes restricciones empresariales: •
un empleado gestiona una sucursal (l: 1);
•
un empleado controla inmuebles en alquiler (1:*);
•
los periódicos anuncian inmuebles en alquiler (*:*).
En las Secciones 11.6.1, 11.6.2 Y 11.6.3 ilustraremos cómo determinar la multiplicidad para cada una de estas restricciones y veremos cómo representar cada tipo dentro de un diagrama ER. En la Sección 11.6.4 examinaremos el tema de la multiplicidad para relaciones cuyo grado sea superior a dos. Es importante observar que no todas las restricciones empresariales pueden representarse fácilmente en un modelo ER. Por ejemplo, el requisito de que un empleado reciba un día de vacaciones adicional por cada año de antiguedad en la empresa puede resultar difícil de representar en un modelo ER.
11.6.1 Relaciones uno a uno (1:1) Considere la relación Manages, que relaciona los tipos de entidad Staff y Branch. La Figura 11. 14(a) muestra dos instancias del tipo de relación Manages (designadas como r1 y r2) utilizando una red semántica. Cada relación (rn) representa la asociación entre una única instancia de la entidad Staffy única instancia de la entidad Branch. Representamos cada instancia de la entidad utilizando los valores de los atributos de clave principal de las entidades Staffy Branch, que son staffNoy branchNo.
Determinación de la multiplicidad Determinar la multiplicidad requiere normalmente examinar las relaciones precisas entre los datos, utilizando datos de ejemplo. Los datos de ejemplo pueden obtenerse examinando informes o formularios rellenos y, si es posible, hablando con los usuarios. Sin embargo, es importante resaltar que para llegar a las conclusiones correctas acerca de una restricción es necesario que los datos de ejemplo examinados o analizados constituyan una representación real de todos los datos que se están modelando.
326
Sistemas de bases de datos
tipo de entidad 5taff (staffNo)
tipo de entidad Branch (branchNo)
tipo de relación Manages
Figura 11.14(a). Red semántica que muestra dos instancias del tipo de relación 8taff Manages Branch (un empleado gestiona una sucursal).
En la Figura 11.14(a) vemos que el empleado con valor del atributo staftNo SGS gestiona la sucursal con valor branchNo B003, mientras que el empleado staftNo SL21 gestiona la sucursal BOOS, pero el empleado SG37 no gestiona ninguna sucursal. En otras palabras, un empleado puede gestionar cero o una sucursales y cada sucursal es gestionada por un empleado. Puesto que hay un máximo de una sucursal por cada empleado implicado en esta relación de un máximo de una sucursal por cada empleado implicado en esta relación y un máximo de un empleado por cada sucursal, nos referimos a este tipo de relación clasificándola como de tipo uno a uno, lo que se suele abreviar como (1: 1).
Representación
diagramática
de las relaciones (1:1)
En la Figura 11.14(b) se muestra un diagrama ER de la relación 8taft Manages Branch. Para representar que un empleado puede gestionar cero o una sucursales, colocamos una indicación '0 ..1' alIado de la entidad Branch. Para representar que una sucursal siempre tiene un gerente, colocamos una indicación' 1..1' alIado de la entidad 8taff (observe que para una relación 1:1, podemos seleccionar un nombre de relación que tenga sentido en cualquiera de las dos direcciones).
11.6.2 Relaciones uno a muchos (1 :*) Considere la relación Oversees (controla) que relaciona los tipos de entidad 8taft y PropertyForRent. La Figura 11.1S(a) muestra tres instancias de la relación 8taff Oversees PropertyForRent (designadas como rl, r2 y r3) utilizando una red semántica. Cada relación (rn) representa la asociación entre una única instancia de la entidad 8taft y una única instancia de la entidad PropertyForRent. Representamos cada instancia de entidad utilizando
'Un empleado puede gestionar cero o una sucursales'
Stall stallNo
Figura 11.14(b).
Branch
Manages ~ 0 .. 1
branchNo
La multiplicidad de la relación uno a uno (1: 1) 8taff Manages Branch.
fNo
Capítulo 11 Modelos entidad-relación relación
entidadStaff (staffNo)
Figura 11.15(a).
Oversees
327
entidadPropertyForRent (propertyNo)
Red semántica que muestra tres instancias del tipo de relación Staff Oversees PropertyForRent.
los valores de los atributos de clave principal de las entidades Staff y PropertyForRent, es decir staffNo y propertyNo.
Determinación
de la multiplicidad
En la Figura 1l.15(a) vemos que el empleado SG37 controla los inmuebles PG2l y PG36 Y que el empleado SA9 controla el inmueble PA14, pero que el empleado SG5 no controla ningún inmueble en alquiler y el inmueble PG4 no es controlado por ningún empleado. En resumen, un empleado puede controlar cero o más inmuebles en alquiler y un inmueble en alquiler es controlado por cero o un empleados. Por tanto, para los empleados que participan en esta relación hay muchos inmuebles en alquiler, y para los inmuebles que participan en esta relación hay un máximo de un empleado. Nos referiremos a este tipo de relación diciendo que es de tipo uno a muchos, que usualmente abreviamos como (1:*).
Representación
diagramática
de las relaciones 1:*
En la Figura 11.15(b) se muestra un diagrama ER de la relación Staff Oversees PropertyForRent. Para representar que un empleado puede controlar cero o más inmuebles en alquiler, colocamos la indicación '0 .. *' aliado de la entidad PropertyForRent. Para representar que cada inmueble en alquiler es controlado por cero o un empleados, colocamos la indicación '0 ..1' aliado de la entidad Staff(observe que con las relaciones 1:*, seleccionamos un nombre de relación que tenga sentido en la dirección 1:*). Si conocemos los valores mínimos y máximos reales de la multiplicidad, podemos mostrar dichos valores. Por ejemplo, si un empleado controla un mínimo de cero y un máximo de 100 inmueble s en alquiler, podemos sustituir la indicación '0 .. *' por '0 ..100'.
0 .. 1
\ J propertyNo Staff PropertyForRent Oversees ~
Figura 11.15(b).
0 ..*
La multiplicidad del tipo de relación uno a muchos (1 :*) Staff Oversees PropertyForRent.
328
Sistemas de bases de datos
11.6.3 Relaciones muchos a muchos (*:*) Considere la relación Advertises, que relaciona los tipos de entidad Newspaper y PropertyForRent. La Figura 11.16(a) muestra cuatro instancias de la relación Advertises (designadas como rl, r2, r3 y r4) utilizando una red semántica. Cada relación (rn) representa la asociación entre una única instancia de la entidad Newspaper y una única instancia de la entidad PropertyForRent.Representamos cada instancia de entidad utilizando los valores de los atributos de clave principal de los tipos de entidad Newspaper y PropertyForRent, que son newspaperName y propertyNo.
Determinación de la multiplicidad En la Figura l1.16(a) podemos ver que el periódico Glasgow Daily anuncia los inmuebles PG21 y PG36. El West News también anuncia el inmueble PG36 y el Aberdeen Express anuncia el inmueble PA14. Sin embargo, el inmueble PG4 no es anunciado en ningún periódico. En otras palabras, un periódico anuncia uno o más inmueble s en alquiler y un inmueble en alquiler se anuncia en cero o más periódicos. Por tanto, para los periódicos hay múltiples inmuebles en alquiler y para cada inmueble en alquiler que participa en esta relación puede haber múltiples periódicos. Nos referiremos a este tipo de relación diciendo que es de tipo muchos a muchos, lo que usualmente abreviamos como (*:*). relación
entidadNewspaper (newspaperName)
entidadPropertyForRent (propertyNo)
Advertises
TheWestNews
Figura 11.16(a).
Red semántica que muestra cuatro instancias del tipo de relación Newspaper Advertises PropertyForRent.
\
0 ..* Newspaper propertyNo
1.,*
I
PropertyForRent
rName La multiplicidad de la relación muchos a muchos (*:*) Newspaper Advertises PropertyForRent.
Figura 11.16(b).
Capítulo 11 Modelos entidad-relación
Representación diagramática
329
de las relaciones *:*
En la Figura 11.16(b) se muestra un diagrama ER de la relación Newspaper Advertises PropertyForRenl. Para representar que cada periódico puede anunciar uno o más inmuebles en alquiler, situamos una indicación '\"*' al lado del tipo de entidad PropertyForRenl. Para representar que cada inmueble en alquiler puede anunciarse en cero o más periódicos, situamos una indicación '0 .. *' alIado de la entidad Newspaper (observe que para una relación *:* podemos seleccionar un nombre de relación que tenga sentido en cualquiera de las dos direcciones).
11.6.4 Multiplicidad para relaciones complejas La multiplicidad para relaciones complejas, que son aquellas cuyo orden es superior a dos, resulta algo más complicada. Multiplicidad (relación compleja)
El número (o rango) de posibles instancias de un tipo de entidad en una relación n-aria cuando los otros (n-1) valores están fijos.
En general, la multiplicidad para relaciones n-aria representa el número potencial de instancias de entidad que pueden aparecer en la relación cuando se fijan (n-l) valores para los otros tipos de entidad participantes. Por ejemplo, la multiplicidad para una relación ternaria representa un rango potencial de instancias de una entidad concreta en la relación cuando los otros dos valores que representan a las otras entidades son fijos. Considere la relación ternaria Registers entre 5taff, Branch y Client mostrada en la Figura 11.7. La Figura 11.l7( a) muestra cinco instancias de la relación Registers (denominadas rl a r5) utilizando una red semántica. Cada relación (rn) representa la asociación de una única instancia de la entidad 5taff, una única instancia de la entidad Branch y una única instancia de la entidad Clienl. Representamos cada instancia de entidad utilizando los valores de los atributos de clave principal de las entidades 5taff, Branch y Client, que son staffNo, branchNo y clientNo. En la Figura 11.17(a) se analiza la relación Registers cuando los valores de las entidades 5taff y Branch son fijos.
Determinación
de la multiplicidad
En la Figura l1.17(a), con los valores staffNo/branchNo fijos, hay cero o más valores clientNo. Por ejemplo, el empleado SG37 de la sucursal B003 registra a los clientes CR56 y CR74, mientras que el empleado en la sucursal SG 14 en la sucursal B003 registra a los clientes CR62, CR84 y CR9l. Sin embargo, el empleado SG5 de la sucursal B003 no registra ningún cliente. En otras palabras, cuando los valores de staffNo y branchNo se fijan, los valores de clientNo correspondientes son cero o más. Por tanto, la multiplicidad de la relación entidad Staff/Branch
relación
entidad Client
(staffNo/branchNo)
Registers
(clientNo)
SG5 / 8003
Figura 11.17(a).
Red semántica que muestra cinco instancias de la relación ternaria Registers con valores fijos para los tipos de entidad 8taft y Branch.
330
Sistemas de bases de datos
Branch
8taff 1..1
1..1
Client
Figura 11.17(b).
La multiplicidad de la relación ternaria Registers.
desde la perspectiva de las entidades 8taft y Branch es 0..*, lo que se representa en el diagrama ER situando la indicación 0.. * alIado de la entidad Client. Si repetimos esta prueba, podemos ver que la multiplicidad cuando se fijan los valores de 8taft/Clientes 1..1, por lo que colocamos dicha indicación al lado de la entidad Branch, mientras que si se fijan los valores de Client/Branchla multiplicidad es 1..1, colocándose la indicación correspondiente alIado de la entidad 8taft. En la Figura 11.17(b) se muestra un diagrama ER de la relación ternaria Registers donde se muestran las etiquetas de multiplicidad. En la Tabla 11.1 se ha incluido un resumen de las posibles formas de representar restricciones de multiplicidad, junto con una descripción de los correspondientes significados. Registers
Tabla 11.1.
Resumen de formas de representar las restricciones de multiplicidad.
Formas alternativas de representar las restricciones de multiplicidad
Significado
0..1
Cero o una instancia de entidad
1..1 (o simplemente 1)
Exactamente una instancia de entidad
0.* (o simplemente *)
Cero o muchas instancias de entidad
1..*
Una o muchas instancias de entidad
5..10
Un mínimo de 5 con un máximo de 10 instancias de entidad
O,3, 6-8
Cero, tres, seis, siete u ocho instancias de entidad
11.6.5 Restricciones de cardinalidad y de participación La multiplicidad está compuesta en realidad de dos restricciones separadas, conocidas como cardinalidad y participación. Cardinalidad
Describe el número máximo de posibles instancias de relación para una entidad que participa en un tipo de relación dado.
La cardinalidad de una relación binaria es aquello a lo que antes nos hemos referido de tipo (1: 1), uno o a muchos 1: *) y muchos a muchos (*: *). La cardinalidad de una relación aparece como los valores máximos de los rangos de multiplicidad en ambos lados de la relación. Por ejemplo, la relación Manages mostrada en la Figura 11.18 tiene una cardinalidad (1: 1) Y esto se representa mediante rangos de multiplicidad con un valor máximo de 1 en ambos lados de la relación. Participación
Determina si todas las instancias hacen algunas.
de entidad participan
en una relación o sólo lo
Capítulo 11 Modelos entidad-relación
331
Cardinalidad
Staff staffNo
Branch
Manages ~ 1.1
0 .. 1
branchNo
'Todas las sucursales son gestionadas' (participación obligatoria para las sucursales)
Participación
Figura 11.18.
La multiplicidad
descrita en función de las restricciones
de cardinalidad
y participación para la relación 8taft Manages Branch (1:1).
La restricción de participación indica si todas las instancias de entidad están implicadas en una relación concreta (lo que se conoce como participación obligatoria) o si sólo participan algunas (lo que se conoce como participación opcional). La participación de entidades en una relación aparece como los valores mínimos de los rangos de multiplicidad en ambos lados de la relación. La participación opcional se representa mediante un valor mínimo de O, mientras que la participación obligatoria se muestra como un valor mínimo de l. Es importante comprobar que la participación de una entidad dada en una relación está representada por el valor mínimo en el lado opuesto de la relación. Es decir, el valor mínimo de la multiplicidad correspondiente a la entidad relacionada. Por ejemplo, en la Figura 11.18, la participación opcional de la entidad Staff en la relación Manages se muestra con un valor mínimo de O para la multiplicidad correspondiente a la entidad Branch, mientras que la participación obligatoria de la entidad Branch en la relación Manages se muestra como un valor mínimo de 1 para la multiplicidad correspondiente a la entidad Staff. En la contraportada del libro se muestra un resumen de los convenios introducidos en esta sección para representar los conceptos básicos de un modelo ER.
11.7 Problemas con los modelos ER En esta sección vamos a examinar los problemas que pueden surgir a la hora de crear un modelo ER. Estos problemas se denominan trampas de conexión y normalmente aparecen debido a una mala interpretación del significado de ciertas relaciones (Howe, 1989). Vamos a examinar dos tipos principales de trampas de conexión, denominados trampas multiplicativas y trampas de corte e ilustraremos cómo identificar y resolver tales problemas en los modelos ER. En general, para identificar las trampas de conexión debemos garantizar que el significado de una relación se entiende perfectamente y está claramente definido. Si no comprendemos las relaciones que estamos manejando, podemos llegar a crear un modelo que no sea una representación veraz del 'mundo real'.
11.7.1 Trampas multiplicativas Trampas multiplicativas
Cuando un modelo representa una relación entre tipos de entidad pero la ruta entre ciertas instancias de entidad es ambigua.
332
Sistemas de bases de datos
1.1 1..*••• Has1..1
Division Branch ~ Operates
Figura 11.19(a). entidades Staff
Un ejemplo de trampa multiplicativa.
relación Has
Figura 11.19(b).
relación Operates
entidades Oivision
entidades Branch
Red semántica del modelo ER mostrado en la Figura 11.19(a).
Una trampa multiplicativa puede existir cuando salen de la misma entidad dos o más relaciones de tipo 1:*. En la Figura 1l.19(a) se ilustra una trampa multiplicativa potencial, que muestra dos relaciones 1:* (Has y Operates) que emanan de la misma entidad denominada Oivision. Este modelo representa los hechos de que una única división opera una o más sucursales y que tiene uno o más empleados. Sin embargo, surge un problema cuando queremos conocer qué empleados trabajan en una sucursal concreta. Para ver el problema, examinamos algunas instancias de las relaciones Has y Operates utilizando valores para los atributos de clave principal de los tipos de entidad Staff, Oivision y Branch, como se muestra en la Figura 11.19(b). Si tratamos de responder la pregunta' ¿En qué sucursal trabaja el empleado SG37?', seremos incapaces de proporcionar una respuesta específica con la estructura actual. Sólo podemos determinar que el empleado SG37 trabaja en la sucursal B003 o B007. La incapacidad de responder a esta cuestión de manera específica es el resultado de la aparición de una trampa multiplicativa asociada con la incorrecta representación de la relación que existe entre las entidades Staff, Oivision y Branch. Para resolver esta trampa multiplicativa, no tenemos más que reestructurar el modelo ER original con el fin de representar la asociación correcta entre estas entidades, como se muestra en la Figura 11.20(a). Si examinamos ahora las instancias de las relaciones Operates y Has, como se muestra en la Figura 11.20(b), vemos que ya podemos responder el tipo de cuestión que habíamos planteado anteriormente. A partir de este modelo de red semántica, podemos determinar que el empleado SG37 trabaja en la sucursal B003, que es parte de la división DI.
Division
Operates ~
1.*
.1
Figura 11.20(a).
Branch
Has ~ 1.1
Staff 1 ..*
El modelo ER mostrado en la Figura 11.19(a),
reestructurado
para eliminar la trampa multiplicativa.
Capítulo 11 Modelos entidad-relación entidades Division
Figura
relación Operates
11.20(b).
entidades Branch
relación Has
333
entidades 8taft
Red semántica del modelo ER mostrado en la Figura 11.20(a).
11.7.2 Trampas de corte Trampas
de
corte
Cuando un modelo sugiere la existencia de una relación entre ciertos tipos de entidad, pero no existe ninguna ruta entre ciertas instancias de entidad.
La trampas de corte pueden ocurrir cuando haya una o más relaciones con una multiplicidad mínima de cero (es decir, participación opcional) formando parte de la ruta que conecta a dos entidades relacionadas. En la Figura 11.21(a) se ilustra una trampa de corte potencial, que muestra las relaciones entre las entidades Branch, 8taffy PropertyForRent. Este modelo representa los hechos de que una única sucursal tiene uno o más empleados que controlan cero o más inmuebles en alquiler. También observamos que no todos los empleados controlan inmueble s y que no todos los inmuebles son controlados por un empleado. El problema puede surgir si queremos conocer qué inmuebles están disponibles en cada sucursal. Para damos cuenta de la naturaleza del problema, examinamos algunas instancias de las relaciones Has y Oversees utilizando valores para los atributos de clave principal de los tipos de entidad Branch, 8taff y PropertyForRent como se muestra en la Figura 11.21 (b).
1. 0..*.*
Has 0.1 ~
Figura 11.21(a).
entidades Branch
Figura 11.21(b).
relación Has
Oversees 8taft ~ PropertyForRent
Un ejemplo de trampa de corte.
entidades 8taff
relación Oversees
entidades PropertyForRent
Red semántica del modelo ER mostrado en la Figura 11.21(a).
334
Sistemas de bases de datos
Si tratamos de responder a la pregunta; '¿En qué sucursal está disponible el inmueble de número PAI4?', no podremos responder a esta pregunta, ya que este inmueble no ha sido todavía asignado a ningún empleado que trabaje en una sucursal. La incapacidad de responder a esta pregunta se considera una pérdida de información (ya que sabemos que todo inmueble debe estar disponible en una sucursal) y es el resultado de una trampa de corte. La multiplicidad de las entidades Staffy PropertyForRent en la relación Oversees tiene un valor mínimo de cero, lo que significa que algunos inmuebles no pueden asociarse con una sucursal a través de un empleado. Por tanto, para resolver este problema, necesitamos identificar la relación que falta, que en este caso es la relación Offers (ofrece) entre las entidades Branch y PropertyForRent. El modelo ER mostrado en la Figura 11.22(a) representa la verdadera asociación entre estas entidades. Este modelo garantiza que se puedan conocer en todo momento los inmuebles asociados con cada sucursal, incluyendo aquellos inmuebles que todavía no hayan sido asignados a ningún empleado. Si ahora examinamos las instancias de los tipos de relación Has, Oversees y Offers, como se muestra en la Figura 11.22(b), vemos que somos capaces de determinar que el inmueble número PAl4 está disponible en la sucursal número B007.
Branch
Has ~ 1 .. 1
1.*
L1
Figura 11.22(a).
Oversees ~
Staff Ou1
0 ..*
PropertyForRent
Offers ~
1 ..*
El modelo ER mostrado en la Figura 11.21 (a) reestructurado para eliminar la trampa de corte.
Resumen del capítulo •
Un tipo de entidad es un grupo de objetos con las mismas propiedades y que son identificados por la organización como poseedores de una existencia independiente. Una instancia de entidad es un objeto unívocamente identificable de un cierto tipo de entidad.
•
Un tipo de relación es un conjunto de asociaciones significativas entre tipos de entidad. Una instancia de relación es una asociación unívocamente identificable que incluye una instancia de cada tipo de entidad participante.
•
El grado de un tipo de relación es el número de tipos de entidad participantes en una relación.
•
Una relación recursiva es un tipo de relación en la que el mismo tipo de entidad participa más de una vez en roles diferentes.
• •
Un atributo es una propiedad de un tipo de entidad o un tipo de relación. Un dominio de atributo es el conjunto de valores permitidos para uno o más atributos.
•
Un atributo simple está formado por un único componente que tiene existencia independiente.
•
Un atributo compuesto está formado por múltiples componentes cada uno de los cuales tiene una existencia independiente.
•
Un atributo univaluado contiene un único valor para cada instancia de un tipo de entidad.
•
Un atributo multivaluado contiene múltiples valores para cada instancia de un tipo de entidad.
•
Un atributo derivado representa un valor que se puede derivar a partir del valor de un atributo o conjunto de atributos relacionados, no necesariamente de la misma entidad.
Capítulo 11 Modelos entidad-relación relación Has
entidades Branch
Figura 11.22(b).
entidades Staff
relación Oversees
335
entidades PropertyForRent
Red semántica del modelo ER mostrado en la Figura 11.22(a).
•
Una clave candidata un tipo de entidad.
es un conjunto mínimo de atributos que identifica unívocamente
cada instancia de
•
Una clave principal es la clave candidata que se selecciona para identificar de forma unívoca cada instancia de un tipo de entidad-
•
Una clave compuesta
•
Un tipo de entidad fuerte es un tipo de entidad cuya existencia no depende de ningún otro tipo de entidad. Un tipo de entidad débil es un tipo de entidad cuya existencia depende de algún otro tipo de entidad.
•
La multiplicidad es el número (o rango) de posibles instancias de un tipo de entidad que pueden estar relacionadas con una única instancia de un tipo de entidad asociado a través de una relación concreta.
•
La multiplicidad para una relación compleja es el número (o rango) de posibles instancias de un tipo de entidad en una relación n-aria cuando los otros (n-l) valores están fijos.
•
La cardinalidad describe el número máximo de posibles instancias de relación para una entidad que participa en un tipo de relación dado.
•
La participación determina si todas las instancias de una entidad participan en una relación dada o si sólo lo hacen algunas de ellas.
•
Las trampas multiplicativas aparecen cuando un modelo representa una relación entre tipos de entidad, pero la ruta que conecta ciertas instancias de entidad es ambigua.
•
Las trampas de corte aparecen cuando un modelo sugiere la existencia de una relación entre tipos de entidad, pero no existe una ruta entre ciertas instancias de entidad.
es una clave candidata que está compuesta de dos o más atributos.
336
Sistemas de bases de datos
Cuestiones de repaso 11.1.
Describa qué es lo que representan los tipos de entidad en un modelo ER y proporcione ejemplos de entidades con existencia fisica o conceptual.
11.2.
Describa qué es lo que representan los tipos de relación en un modelo ER y proporcione ejemplos de relaciones unarias, binarias, tenarias y cuaternarias.
11.3.
Describa qué es lo que representan los atributos en un modelo ER y proporcione ejemplos de atributos simples, compuestos, univaluados, multivaluados y derivados.
11A. Describa qué representa la restricción de multiplicidad para un tipo de relación. 11.5.
¿Qué son las restricciones empresariales y cómo modela la multiplicidad estas restricciones?
11.6.
¿Cómo representa la multiplicidad tanto la cardinalidad como la restricción de participación en un cierto tipo de relación?
11.7.
Proporcione un ejemplo de tipo de relación con atributos.
11.8.
Indique en qué difieren los tipos de entidad fuertes y débiles y proporcione un ejemplo de cada uno.
11.9.
Describa cómo pueden aparecer las trampas multiplicativas y las trampas de corte en un modelo ER y cómo se pueden resolver dichos problemas.
Ejercicios 11.10. Cree un diagrama ER para cada una de las siguientes descripciones: (a)
Cada empresa opera cuatro departamentos y cada departamento pertenece a una empresa.
(b)
Cada departamento del apartado (a) da trabajo a uno o más empleados y cada empleado trabaja para un departamento.
(c)
Cada uno de los empleados del apartado (b) puede o no tener uno o más subordinados y cada subordinado depende de un solo empleado.
(d)
Cada empleado del apartado (c) puede o no tener un historial de empleo.
(e)
Represente todos los diagramas ER descritos en los apartados (a), (b), (c) y (d) como un único diagrama ER.
11.11. Se nos pide que creemos un modelo de datos conceptual de los requisitos de datos de una empresa especializada en la formación en tecnologías de la información. La empresa tiene 30 profesores y puede admitir hasta 10 alumnos por cada sesión de formación. La empresa ofrece cinco cursos avanzados de tecnología, cada uno de los cuales es impartido por un equipo de gente compuesto por dos o más instructores. A cada instructor se le asigna un máximo de dos equipos docentes o puede estar asignado para realizar tareas de investigación. Cada uno de los alumnos cursa un seminario de tecnología avanzada por cada sesión de formación. (a)
Identifique los tipos de entidad principales en esta empresa.
(b)
Identifique los tipos de relación principales y especifique la multiplicidad Indique cualesquiera suposiciones que haga acerca de los datos.
(c)
Utilice las respuesta a los apartados (a) y (b) para dibujar el único diagrama ER que represente los requisitos de datos de la empresa.
de cada relación.
11.12. Lea el siguiente caso de estudio, que describe los requisitos de datos de una empresa de alquiler de películas de vídeo. La empresa tiene diversas sucursales por los Estados Unidos. Los datos almacenados para cada sucursal son la dirección de la sucursal (formada por la cal1e, la ciudad, el estado y el código postal) y el número telefónico. Cada sucursal tiene un número de sucursal, que es unívoco dentro de la empresa. Cada sucursal tiene una serie de empleados asignados entre los cuales hay un Gerente. El Gerente es responsable de la operación diaria de una sucursal determinada. Los datos que se almacenan sobre cada empleado son el nombre, la categoría y el salario. A cada empleado se le asig-
Capítulo 11 Modelos entidad-relación
337
na un número de empleado, que es unívoco dentro de la empresa. Cada sucursal tiene una serie de películas de vídeo. Los datos que se almacenan sobre cada película son el número de catálogo, el número de película, el título, la categoría, el alquiler diario, el coste, el estado y los nombres de los actores principales y del director. El número de catálogo identifica unívocamente cada película de vídeo. Sin embargo, en la mayoría de los casos, hay varias copias de cada película en cada sucursal, por lo que las copias individuales se identifican utilizando el número de película. A cada película de vídeo se le asigna una categoría, como por ejemplo acción, adultos, niños, drama, terror o ciencia ficción, El estado indica si una copia específica de cada película está disponible para alquilar. Antes de alquilar una película en la empresa, el cliente debe registrarse como cliente de la sucursal. Los datos que se almacenan sobre cada cliente son el nombre y el apellido, la dirección y la fecha en que se registró como cliente en la sucursal. A cada cliente se le da un número de cliente, que es unívoco entre todas las sucursales de la empresa. Una vez registrado, el cliente puede alquilar películas libremente, hasta un máximo de 10 simultáneamente. Los datos que se almacenan sobre cada película alquilada son el número de alquiler, el nombre completo y número del cliente, el número de la película, el título y el alquiler diario, así como las fechas en que el vídeo se alquiló y fue devuelto. El número de alquiler es unívoco a lo largo de la empresa. (a)
Identifique los tipos de entidad principales de esta empresa de alquiler de películas de vídeo.
(b) Identifique los tipos de relación principales existentes entre los tipos de entidad descritos en el apartado (a) y represente cada relación como un diagrama ER. (c)
Determine las restricciones de multiplicidad para cada una de las relaciones descritas en el apartado (b). Represente la multiplicidad de cada relación en los diagramas ER creados en dicho apartado.
(d) Identifique los atributos y asócielos con los tipos de entidad o de relación. Represente cada atributo en los diagramas ER creados en el apartado (c). (e)
Determine los atributos de clave candidata y clave principal para cada uno de los tipos de entidad (fuertes).
(f)
Utilizando las respuestas a los apartados (a)-(e), trate de representar los requisitos de datos de la empresa de alquiler de películas de vídeo en un único diagrama ER. Indique las suposiciones que necesite hacer para efectuar el diseño.
Modelado entidad-relación avanzado
Objetivos del capítulo: En este capítulo aprenderá: •
Las limitaciones de los conceptos básicos del modelo entidad-relación (ER) y los requisitos para representar aplicaciones más complejas utilizando conceptos adicionales de modelado de datos.
•
Los conceptos adicionales más útiles para modelado de datos del modelo EER (Enhanced Entity-Relationship, modelo Entidad-Relación avanzado), denominados especialización/generalización, agregación y composición.
•
Una técnica diagramática para mostrar la especialización/generalización, agregación y composición en un diagrama EER utilizando el lenguaje UML (Unified Modeling Language).
En el Capítulo 11 hemos visto los conceptos básicos del modelo entidad-relación (ER). Estos conceptos básicos resultan normalmente adecuados para construir los modelos de datos de sistemas de base de datos tradicionales, de carácter administrativo, como por ejemplo sistemas de control de almacén, de pedidos de productos y facturas de clientes. Sin embargo, desde la década de 1980 se ha producido un rápido incremento en el desarrollo de numerosos nuevos sistemas de bases de datos cuyos requisitos son más exigentes que los de las aplicaciones tradicionales. Como ejemplos de tales aplicaciones de bases de datos podemos citar el diseño asistido por computadora (CAD, Computer-Aided Design), la fabricación asistida por computadora (CAM, Computer-Aided Manufacturing), las herramientas de ingeniería del software asistida por computadora (CASE, Computer-Aided Software Engineering), los sistemas de información ofimáticos (GIS, Office Information Systems), los sistemas multimedia, los sistemas de autoedición y los sistemas de información geográfica (GIS, Geographical Information System). Las principales características de estas aplicaciones se describen en el Capítulo 25. Puesto que los conceptos básicos del modelado ER resultan a menudo insuficientes para representar los requisitos de estas aplicaciones nuevas y más complejas, esto actuó como estímulo para desarrollar conceptos adicionales de modelado 'semántico'. Son numerosos los modelos de datos semánticos distintos que se han propuesto y algunos de los conceptos semánticos más importantes se han incorporado con éxito en el modelo ER original. El modelo ER, complementado con conceptos semánticos adicionales, se denomina modelo EER (Enhanced Entity-Relationship, modelo avanzado entidad-relación). En este capítulo vamos a describir tres de los conceptos adicionales más importantes y útiles del modelo EER, que son la especialización/generalización, la agregación y la composición. También ilustraremos cómo se representan estos conceptos en un diagrama EER utilizando el lenguaje UML (Booch el al., 1998). En el Capítulo 11 hemos presentado UML y hemos mostrado cómo puede utilizarse dicho lenguaje para representar mediante un diagrama los conceptos básicos del modelo ER.
340
Sistemas de bases de datos
Estructura del capítulo En la Sección] 2.1 se explican los conceptos principales asociados con la especialización/generalización y se ilustra cómo representar estos conceptos en un diagrama EER mediante el lenguaje UML (Unified Modeling Language). Concluimos esta sección con un ejemplo resuelto que muestra cómo introducir la especialización/generalización en un modelo ER mediante UML. En la Sección 12.2 se describe el concepto de agregación y en la Sección 12.3 el concepto relacionado de composición. Proporcionaremos ejemplos de agregación y composición y mostraremos cómo representar estos conceptos en un diagrama EER mediante UML.
12.1 Especialización/Generalización El concepto de especialización/generalización está asociado con tipos especiales de entidades conocidos como superclases y subclases, y con el proceso de herencia de atributos. Comenzamos esta sección definiendo lo que son las superclases y las subclases y examinando las relaciones superclase/subclase. Describiremos el proceso de herencia de atributos y veremos cuáles son las diferencias entre el proceso de especialización y el de generalización. Después describiremos "los dos tipos principales de restricciones sobre las relaciones superclase/subclase, denominadas restricciones de participación y de disyunción. Mostraremos cómo representar la especialización/generalización en un diagrama EER (Enhanced Entity-Relationship) utilizando UML y concluiremos la sección con un ejemplo resuelto donde se ilustra cómo introducir la especialización/generalización en el modelo entidad-relación (ER, Entity-Relationship) de las vistas de usuario de tipo Sucursal de tipo del caso de estudio de DreamHome descrito en el Apéndice A y mostrado en la Figura 11.1.
12.1.1 Superelases y subelases Como hemos visto en el Capítulo 11, un tipo de entidad representa un conjunto de entidades del mismo tipo, como por ejemplo 8taft, Branch y PropertyForRent. También podemos formar tipos de entidad creando una jerarquía que contenga superclases y subclases. Superclase
Un tipo de entidad que incluye uno o más subgrupos diferentes de sus instancias, los cuales es preciso representar en un modelo de datos.
Subclase
Un subgrupo diferenciado de instancias de un tipo de entidad, que necesita ser representado en un modelo de datos.
Los tipos de entidad que poseen subclases diferenciadas se denominan superclases. Por ejemplo, las entidades que son miembros del tipo de entidad 8taft podrían clasificarse como Manager, 8alesPersonnel y 8ecretary (gerente, vendedor y administrativo). En otras palabras, la entidad 8taft sería una superclase de las subclases Manager, 8alesPersonnel y 8ecretary. La relación entre una superclase y uno cualquiera de sus subclases se denomina superclase/subclase. Por ejemplo, 8taft/Manager tiene una relación superclase/subclase.
12.1.2 Relaciones superelase y subelase Cada miembro de una subclase es también miembro de la superclase. En otras palabras, la entidad contenida en la subclase es la misma que la contenida en la superclase, aunque tiene un papel distinto. La relación entre una superclase y una subclase es de tipo uno a uno (]: 1) Y se denomina relación superclase/subclase (véase la Sección 11.6.1). Algunas superclases pueden contener subclases solapadas, como por ejemplo si uno de los empleados fuera a la vez gerente y miembro de la fuerza de ventas. En este ejemplo, Manager y 8alesPersonnel son subclases solapadas de la superclase 8taft. Por otro lado, no todo miembro de una superc]ase necesita ser miembro de una subclase; por ejemplo, los empleados que no tengan una categoría laboral distintiva, como por ejemplo la de gerente, y que no sean miembros de la fuerza de ventas de la empresa. Podemos utilizar la superclases y subclase para evitar tener que describir diferentes tipos de empleados, que posiblemente tengan diferentes atributos, utilizando una única entidad. Por ejemplo, los vendedores pue-
Capítulo 12 Modelado entidad-relación avanzado
341
den tener atributos especiales como por ejemplo salesArea (área de ventas) y carAllowance(coche de empresa). Si todos los atributos de los empleados y aquellos atributos que sean específicos de categorías laborales concretas se describen mediante una única entidad Staff, podríamos tener como resultado una gran cantidad de valores nulos para los atributos específicos de las categorías laborales. Claramente, los vendedores tendrán atributos en común con otros empleados, como por ejemplo staffNo, name, position y salary. Sin embargo, son los atributos no compartidos los que causan problemas cuando tratamos de representar todos los empleados con una única entidad. También podemos encontramos con relaciones que sólo estén asociadas con tipos concretos de empleados (subclases) y no con todos los empleados en general. Por ejemplo, los vendedores podrían tener relaciones particulares que no sean apropiadas para todos los empleados, como por ejemplo SalesPersonnel Uses Car (vendedor utiliza coche). Para ilustrar estos puntos, considere la relación denominada AIIStaff(todos los empleados) mostrada en la Figura 12.1. Esta relación almacena los detalles de todos los empleados, independientemente de cuál sea su categoría laboral. Una consecuencia de almacenar todos los detalles de los empleados en una única relación es que aunque los atributos que resultan apropiados para todos los empleados sí tienen asignados valores (es decir, staffNo, name, position y salary), los que sólo son aplicables a categorías laborables completas sólo estarán parcialmente rellenos. Por ejemplo, los atributos asociados con las subclases Manager (mgrStartDate y bonus), SalesPersonnel (salesArea y carAllowance)y Secretary (typingSpeed) tienen valores para los miembros que estén incluidos en dichas subclases. En otras palabras, los atributos asociados con las subclases Manager, SalesPersonnel y Secretary estarán vacíos para todos los empleados que no pertenezcan a dichas subclases. Hay dos importantes razones para introducir los conceptos de superclases y sub clases en un modelo ER. En primer lugar, nos evita describir conceptos similares más de una vez, ahorrando tiempo al diseñador y haciendo que el diagrama ER sea más legible. En segundo lugar, añade más información semántica al diseño en una forma que resulta familiar para muchas personas. Por ejemplo, los enunciados 'Gerente es un tipo de empleado' y 'apartamento es un tipo de inmueble', comunican un contenido semántica significativo de una forma concisa.
12.1.3 Herencia de atributo Como hemos mencionado antes, una entidad de una subclase representa el mismo objeto del 'mundo real' que en la superclase, y además puede poseer atributos específicos de la subclase además de los asociados con la superclase. Por ejemplo, un miembro de la subclase SalesPersonnel hereda todos los atributos de la superclase Staff,como staffNo, name, positiony salary, además de poseer los atributos específicamente asociados con la subclase SalesPersonnel, que son salesArea y carAllowance. Atributos apropiados para todos los empleados
Atributos apropiados para los gerentes de sucursal
Atributos apropiados para los vendedores
Atributo apropiado para los administrativos
I ~
1 j
l staffNo Allowanee Stuart Stern 5000 Ann Beech Assistant 01/06/91 2350 3700 Robert Susan 24000 8500 Brand 17000 Snr ChinSales Asst 27000 9000 12000 01/02/95 30000 2000 ear sales name position bonus John typing Wl1ite Secretary Mary MaryHowe Martinez Sales Manager mgrStartDate Speed salary Manager
SA2B SAlA
100
Area
Figura 12.1.
Relación AllStaff que almacena los detalles de todos los empleados.
342
Sistemas de bases de datos
Una subclase es una entidad por propio derecho, de modo que también ella puede tener una o más subclaseso Una entidad, junto con sus subclases y las subclases de éstas, etc., se denomina jerarquía de tipos. Las jerarquías de tipos reciben diversos nombres, entre los que se incluyen: jerarquía de especialización (por ejemplo, Manager es una especialización de Staff),jerarquía de generalización (por ejemplo, Staffes una generalización de Manager), y jerarquía IS-A (jerarquía ES-UN; por ejemplo, Manager IS-A (member of) Staff, es decir, Manager es un miembro de Staff).Describiremos el proceso de especialización y generalización en la sección siguiente. Una subclase con más de una superclase se denomina subclase compartida. En otras palabras, un miembro de una subclase compartida debe ser miembro de las superclases asociadas. Como consecuencia, la subclase compartida hereda los atributos de todas las superclases, además de poder tener sus propios atributos adicionales. Este proceso se denomina herencia múltiple.
12.1.4 Proceso de especialización Especial ización
El proceso de maximizar las diferencias entre miembros de una entidad identificando sus características distintivas.
La especialización es una técnica arriba-abajo para definir un conjunto de superclases y sus subclases relacionadas. El conjunto de subclases se define basándose en algunas características distintivas de las entidades comprendidas en la superclase. Cuando identificamos un conjunto de subclases de un tipo de entidad, asociamos luego atributos específicos a cada subclase (cuando sea necesario) y también identificamos las relaciones existentes entre cada subclase y otros tipos de entidad o subclases (cuando sea necesario). Por ejemplo, considere un modelo en el que todos los empleados estén representados mediante una entidad denominada Staff. Si aplicamos el proceso de especialización a la entidad Staff, trataremos de identificar diferencias entre los miembros de esta entidad, como por ejemplo miembros que tenga atributos y/o relaciones instintivos. Como hemos descrito anteriormente, los empleados con las categorías laborales de Gerente, Vendedor y Administrativo tienen atributos distintivos, por lo que podemos identificar Manager, SalesPersonnel y Secretary como subclases de una superclase Staffespecializada.
12.1.5 Proceso de generalización Generalización
El proceso de minimizar las diferencias entre entidades identificando sus características comunes.
El proceso de generalización es una técnica abajo-arriba, que da como resultado la identificación de una superclase generalizada a partir de los tipos de entidad originales. Por ejemplo, considere un modelo en el que Manager, SalesPersonnel y Secretary estén representados como tipos de entidad distintos. Si aplicamos el proceso de generalización a estas entidades, trataremos de identificar similitudes entre ellas, como por ejemplo atributos y relaciones comunes. Como hemos indicado anteriormente, estas entidades comparten atributos que son comunes a todos los empleados, de modo que podemos identificar Manager, SalesPersonnel y Secretary como subclases de una superclase Staffgeneralizada. Ya que el proceso de generalización puede considerarse como el inverso del proceso de generalización, haremos referencia a este concepto de modelado mediante el término general 'especialización/generalización'.
Representación
diagramática
de la especialización/generalización
UML dispone de una notación especial para representar la especialización/generalización. Por ejemplo, considere la especialización/generalización de la entidad Staff en una serie de subclases que representen categorías laborales. La superclase Staffy las subclases Manager, SalesPersonnel y Secretary puede representarse en un diagrama EER (Enhanced Entity-Relationship) como se ilustra en la Figura 12.2. Observe que la superclase Staff y sus subclases, siendo entidades, se representan como rectángulos. Las subclases están conectadas
e~ I
Capítulo 12 Modelado entidad-relación avanzado
343
Staft
salesArea SalesPersonne/ carAllowance name position salary Secretary generalización typingSpeed {OpUona/, And} Indica especialización/
1..'{PK} 1 ~ staftNo l-Branch e1..Has -1 .1 Superclases Manager
Figura 12.2.
Especialización/generalización de la entidad 8taff en una serie de subclases que representan categorías laborales.
mediante líneas a un triángulo que apunta hacia la superclase. La etiqueta situada debajo del triángulo de especialización/generalización, mostrada como {Optional, and}, describe las restricciones aplicables a la relación existente entre la superclase y sus subclases. Estas restricciones se explican con mayor detalle en la Sección 12.1.6. Los atributos específicos de una subclase concreta se enumeran en la sección inferior del rectángulo que representa dicha subclase. Por ejemplo, los atributos salesArea y carAllowancesólo están asociados con la subclase SalesPersonnel, y no son aplicables a las subclases Manager o Secretary. De forma similar, también se muestran los atributos específicos de las subclases Manager (mgrStartDate y bonus) y Secretary (typingSpeed). Los atributos comunes a todas las subclases se enumeran en la sección inferior del rectángulo que representa a la subclase. Por ejemplo, los atributos staffNo, name, position y salary son comunes a todos los empleados y se asocian con la superclase Staff. Observe que también podemos mostrar relaciones que sólo sean aplicables a subclases específicas. Por ejemplo, en la Figura 12.2, la subclase Manager está relacionada con la entidad Branch a través de la relación Manages, mientras que la superclase Staff está relacionada con la entidad Branch a través de la relación Has. Podemos tener varias especializaciones de la misma entidad basadas en diferentes características distintivas. Por ejemplo, otra especialización de la entidad Staff podría producir las subclases FullTimePermanent (empleado permanente a tiempo completo) y PartTimeTemporary(empleado temporal a tiempo parcial) que distinguirían entre los tipos de contratos laborales de los empleados. La especialización del tipo de entidad Staff en las subclases relativas a la categoría laboral y al contrato de trabajo se muestra en la Figura 12.3. En esta figura, mostramos los atributos específicos de las subclases FullTimePermanent(salaryScale y holidayAllowance) y PartTimeTemporary(hourlyRate). Como hemos descrito anteriormente, al conjunto formado por una superclase, sus sub clases y todas las subclases derivadas de éstas se les denomina jerarquía de tipos. En la Figura 12.4 se muestra un ejemplo de jerarquías de tipos, en la que se ha expandido la especialización/generalización de las categorías laborales mostradas en la Figura 12.2, para mostrar una sub clase compartida denominada SalesManager (gerente vendedor) y la subclase denominada Secretary con su propia subclase llamada AssistantSecretary (auxiliar adminis-trativo). En otras palabras, un miembro de la subclase compartida SalesManager debe ser miembro de la
344
Sistemas de bases de datos
Branch branchNo address street
Staff
Has ~ {PK}
1..*
11 .. 1
staffNo name
{PK}
position sa/ary
city postcode
1..1 J. Manages
{Optiona/,
And}
1.. 1 Manager
Sa/esPersonne/
Secretary
FuHTimePermanent
mgrStartDate bonus
sa/esArea carAHowance
typingSpeed
sa/arySca/e ho/idayAHowance
PartTime
Temporary
hour/yRate
Subc/ases según tipo de contrato
Figura 12.3.
Especialización/generalización de la entidad Staff en una serie de subclases que representan categorías laborales y tipos de contratos.
subclase SalesPersonnel y Manager, así como de la superclase Staff. Como consecuencia, la subclase SalesManager hereda los atributos de la superclase Staff (staffNo, name, position y salary) y los atributos de las subclases SalesPersonnel (salesArea y carAllowance)y Manager (mgrStartDate y bonus), además de tener su propio atributo adicional, denominado salesTarget (objetivos de ventas). AssistantSecretary es una subclase de Secretary, que a su vez es una subclase de Staff.Esto significa que todo miembro de la subclases AssistantSecretary debe ser miembro de la sub clase 8ecretary y de la superclase 8taff. Como consecuencia, la subclase Assistant8ecretary hereda los atributos de la superclase 8taff(staffNo, name, position y salary) y el atributo de la subclase 8ecretary (typing8peed), además de tener su propio atributo adicional denominado startDate (fecha de incorporación).
12.1.6 Restricciones a la especialización/generalización Hay dos restricciones que pueden aplicarse a la especialización/generalización, tricciones de participación y restricciones de disyunción.
las cuales se denominan res-
Restricciones de participación Restricción participación
de
Determina si todo miembro de la superclase debe participar como miembro de una subclase.
Una restricción de participación puede ser obligatoria u opcional. Una relación superclase/subclase con participación obligatoria especifica que todo miembro de la superclase debe ser también miembro de una subclase. Para representar la participación obligatoria, se sitúa la etiqueta 'Mandatory' entre corchetes debajo del triángulo que apunta hacia la superclase. Por ejemplo, en la Figura 12.3 la especialización/generalización referente al tipo de contrato es de participación obligatoria, lo que quiere decir que todo empleado debe tener asociado un tipo de contrato. Una relación superclase/subclase con participación opcional especifica que un miembro de una superclase no necesita pertenecer a ninguna de sus subclases. Para representar la participación opcional, se sitúa la eti-
Capítulo 12 Modelado entidad-relación avanzado
Branch
Staff
Has ~
branchNo {PK} address street city postcode
11..1
345
1..*
staffNo {PK} name position salary
1..1 {Optional, And}
...
Manages 1 ..1 Manager
SalesPersonnel
Secretary
mgrStartDate bonus
salesArea carAllowance
typingSpeed
AssistantSecretary salesTarget
startDate
Figura 12.4. Especialización/generalización de la entidad Staff en una serie de categorias laborales, incluyendo una subclase compartida denominada SalesManager y una subclase denominada Secretary con su propia subclase llamada AssistantSecretary.
queta 'Optional' entre corchetes debajo del triángulo que apunta hacia la superclase. Por ejemplo, en la Figura 12.3, la especialización/generalización relativa a la categoría laboral es de participación opcional, lo que quiere decir que un empleado no necesita tener asociada una categoría laboral adicional, como por ejemplo la de Gerente, Vendedor o Administrativo.
Restricciones de disyunción Restricción de disyunción
Describe la relación entre miembros de las subclases e indica si es posible que un miembro de una superclase sea miembro de una subclase o de más de una.
La restricción de disyunción sólo se aplica cuando una superclase tiene más de una subclase. Si las sub clase son disjuntas, una instancia de entidad sólo puede ser miembro de una de las subclases. Para representar una relación superclase/subclase disjunta, se sitúa la etiqueta 'Or' a continuación de la restricción de participación, dentro de dos corchetes. Por ejemplo, en la Figura 12.3, las subclases de la especialización/generalización referida al tipo de contrato son disjuntas, lo que quiere decir que un empleado puede tener un contrato permanente a tiempo completo o un contrato temporal a tiempo parcial, pero no ambos tipos de contrato a la vez. Si las subclases de una especialización/generalización no son disjuntas, una instancia de la entidad puede ser miembro de más de una subclase. Para representar una relación superclase/subclase no disjunta, se sitúa la etiqueta 'And' a continuación de la restricción de participación, dentro de los corchetes. Por ejemplo, en la Figura 12.3 la especialización/generalización relativa a la categoría laboral es no disjunta, lo que quiere decir que una instancia de entidad puede ser miembro de varias de las sub clases Manager, SalesPersonnel y Secretary. Esto se confirma por la presencia de las subclase compartida denominada SalesManager y mostrada en la Figura 12.4. Observe que no es necesario incluir la restricción de disyunción en aquellas jerarquías que ten-
346
Sistemas de bases de datos
gan una única subclase en un nivel determinado, lo cual es la razón de que sólo se muestre la restricción de participación para las subclases Sales Manager y AssislanlSecrelary de la Figura 12.4. Las restricciones de disyunción y participación para los procesos de especialización y generalización son independientes, lo que da como resultado cuatro categorías distintas: 'obligatoria y disjunta', 'opcional y disjunta', 'obligatoria y no disjunta' y 'opcional y no disjunta'.
12.1.7 Utilización de las técnicas de especializaciónl generalización para modelar la vista Branch del caso de estudio DreamHome La metodología de diseño de bases de datos descrita en este libro incluye la utilización de las técnicas de especialización/generalización como en el paso opcional (Paso 1.6) a la hora de construir un modelo EER. La decisión sobre si utilizar este paso depende de la complejidad de la organización (o de la parte de la organización) que esté siendo modelada y de si la utilización de conceptos adicionales del modelo EER puede ayudar al proceso de diseño de la base de datos. En el Capítulo 11 hemos descrito los conceptos básicos necesarios para construir un modelo ER con el que representar las vistas de usuario Branch del caso de estudio de DreamHome. Este modelo ya fue mostrado en forma de diagrama ER en la Figura 11.1. En esta sección, veremos cómo pueden usarse la especialización/ generalización para convertir el modelo ER de las vistas de usuario Branch en un modelo EER. Como punto de partida, consideremos primero las entidades mostradas en la Figura 11.1. Vamos a examinar los atributos y relaciones asociados con cada entidad para identificar similaridades o diferencias existentes entre las entidades. En la especificación de requisitos de las vistas de usuario Branch hay varios casos donde existe el potencial de utilizar las técnicas de especialización/generalización, como a continuación se explica. (a) Por ejemplo, considere la entidad Slaff en la Figura 11.1, que representa el conjunto de todos los empleados. Sin embargo, en la especificación de requisitos de los datos para las vistas de usuario Branch del caso de estudio DreamHome dado en el Apéndice A, hay dos categorías laborales clave que se mencionan, la de Gerente y la de Supervisor. Tenemos tres opciones para modelar los empleados. La primera opción consiste en representar todos los empleados mediante una entidad Slaff generalizada (como en la Figura 11.1), la segunda opción es crear tres entidades distintas Slaff, Manager y Supervisor, y la tercera opción es representar las entidades Manager y Supervisor como subclases de una superclase Slaff. La opción que seleccionemos dependerá del grado de compartición de los atributos y relaciones asociados con cada entidad. Por ejemplo, todos los atributos de la entidad Slaff están representados en las entidades Manager y Supervisor, incluyendo la misma clave principal, es decir, slaffNo. Además, la entidad Supervisor no tiene ningún atributo adicional representativo de esa categoría laboral. Por otro lado, la entidad Manager tiene dos atributos adicionales, que son mgrSlartDale y bonus. Además, tanto la entidad Manager como Supervisor están asociadas con sendas relaciones particulares, que son Manager Manages Branch y Supervisor Supervises Slaff. Basándonos en esta información, seleccionamos la tercera de las opciones y creamos las subclases Manager y Supervisor de la superclase Slaff, como se muestra en la Figura 12.5. Observe que en este diagrama EER las subclases se muestran por encima de la superclase. El posicionamiento relativo de las subclases y de la superclase no es significativo; lo que es importante es que el triángulo de especialización/generalización apunte hacia la superclase. La especialización/generalización de la entidad Slaff es de tipo opcional y disjunto (lo que se indica mediante la etiqueta {Optional, Or}), ya que no todos los empleados son gerentes o supervisores y además un mismo empleado no puede ser a la vez Gerente y Supervisor. Esta representación es particularmente útil para mostrar los atributos compartidos asociados con estas sub clases y con la superclase Slaff, y también las relaciones diferenciadas asociadas con cada subclase, es decir, Manager Manages Branch y Supervisor Supervises Slaff.
(b) A continuación, considere la especialización/generalización de la relación entre propietarios de inmuebles. La especificación de requisitos de datos de las vistas de usuario Branch describe dos tipos de pro-
Capítulo 12 Modelado entidad-relación avanzado
name position ssalary affNo {PK}
Staff 1 .. Branch ' {Optional, Or} Supervisor 1..1 1..1 Manager .•• Has branchNo {PK} postcode mgrStartDate Manages I
0 ..1
bonus
address street city
347
'f
1..1
\7 Superv
Figura 12.5.
Superclase
Staff con las subclases
Supervisor
y Manager.
pietarios, que son PrivateOwner (propietario de privado) y BusinessOwner (empresa propietaria), como se muestra en la Figura 11.1. De nuevo, tenemos tres opciones para modelar los propietarios de inmuebles. La primera opción consiste en dejar PrivateOwner y BusinessOwner como dos entidades distintas (como se muestra en la Figura 11.1), la segunda opción es representar ambos de propietario mediante una entidad Owner generalizada y la tercera opción es representar las entidades PrivateOwner y BusinessOwner como subc1ases de una superclase Owner. Antes de tomar una decisión, vamos a examinar los atributos y relaciones asociados con estas entidades. PrivateOwner y BusinessOwner comparten atributos comunes, como son address y telNo y tiene una relación similar con los inmuebles (PrivateOwner POwns PropertyForRent y BusinessOwner BOwns PropertyForRent). Sin embargo, ambos tipos de propietario tienen también atributos distintos; por ejemplo PrivateOwner tiene como atributos distintivos ownerNo y name y BusinessOwner tiene como atributos distintivos bName, bType y contactName (nombre de empresa, tipo de empresa y nombre de contacto). En este caso, creamos una superc1ase denominada Owner con PrivateOwner y BusinessOwner como subc1ases, como se muestra en la Figura
12.6.
telNo name {Mandatory, Or} address ownerNo {PK}
1..1 postcode PropertyForRent Owner 1..' BusinessOwner bType bName {PK}address Owns ~ rent contactName rooms streetpropertyNo {PK} city type
Owner
Figura 12.6.
Superclase
Owner con las subclase
PrivateOwner
y BusinessOwner.
348
Sistemas de bases de datos
La especialización/generalización de la entidad Owner es obligatoria y disjunta (lo que se muestra mediante la etiqueta {Mandatory, Or}), ya que un propietario debe ser una persona física o una empresa, pero no puede ser ambas cosas. Observe que hemos elegido relacionar la superclase Owner con la entidad PropertyForRent utilizando la relación denominada Owns (un propietario, sea del tipo que sea, posee un inmueble). Los ejemplos de especialización/generalización descritos son relativamente sencillos. Sin embargo, el proceso de especialización/generalización puede llevarse un paso más adelante, como se ilustra en el siguiente ejemplo. (c) Hay varias personas con características comunes descritas en la especificación de requisitos de datos de las vistas de usuario Branch del caso de estudio DreamHome. Por ejemplo, los empleados, las personas físicas que son propietarias de inmuebles y los clientes tienen atributos number y name. Podríamos crear una superclase Person que tuviera las subclases Staff (incluyendo las subclases Manager y Supervisor), PrivateOwner y Client, como se muestra en la Figura 12.7. Vamos a considerar ahora hasta qué grado queremos usar las técnicas de especialización/generalización para representar las vistas de usuario Branch del caso de estudio DreamHome. Decidimos utilizar los ejemplos de especialización/generalización descritos en los casos (a) y (b), pero no el del caso (c), como se muestra en la Figura 12.8. Para simplificar el diagrama EER, sólo se muestran los atributos asociados con las claves primarias o con las relaciones. Dejamos fuera del modelo EER final la representación mostrada en la Figura 12.7, porque el uso de la especialización/generalización en este caso pone demasiado énfasis en la relación existente en las entidades que son diferentes tipos de personas en lugar de enfatizar las relación entre estas entidades y algunas de las entidades fundamentales, como Branch y PropertyForRent. La opción de utilizar las técnicas de especialización/generalización, y el grado con el que utilizarlas, constituye una decisión de carácter subjetivo. De hecho, el uso de especialización/generalización se presenta como un paso opcional en nuestra metodología de diseño conceptual de bases de datos, expuesta en el Capítulo 15, dentro del Paso 1.6.
6
Person Client PrivateOwner telNo address telNo
name number{Mandatory, {PK} Or}
salary position Staff
I
Figura 12.7.
Superclase Person con las subclases Staff (incluyendo Supervisor y Manager), PrivateOwner y Client.
las subclases
Capítulo 12 Modelado entidad-relación avanzado
propertyNo Owns Staff 1 011..1 .. ..* .. ' 1Preference Client Branch 1~ .. 1 1..1 Owner bName 1..1 1..1 Supervisor Manager 1 ..* 1 .. 1.•• States Holds 1.•• .BusinessOwner .* Has
branchNo c1ientNo 0 ..* ,.PropertyForRent 1 ..1
cost
- - - ...- - -,. dvertises wspaper ownerNo ewspaperName PrivateOwner dateJoined 1 ..*
,
~
0 ..100
O .. '
.•• LeasedBy ~ I
1.1\
T
349
1..1
... Manages
1..1
{Optional, Or} {Mandat
Oversees
,.
Offers
,.
Figura 12.8.
Un modelo EER (modelo entidad-relación avanzado) de las vistas de usuario Branch de DreamHome, mostrando la jerarquía de especialización/generalización.
Como se describe en la Sección 2.3, el propósito de un modelo de datos consiste en proporcionar los conceptos y notaciones que permiten a los diseñadores de bases de datos y usuarios finales comunicar de forma precisa y no ambigua su comprensión de los datos corporativos. Por tanto, manteniendo estos objetivos en mente, sólo debemos utilizar los conceptos adicionales de especialización/generalización cuando los datos
350
Sistemas de bases de datos
corporativos sean demasiado complejos como para representarlos con facilidad utilizando exclusivamente los conceptos básicos del modelo ER. En esta etapa podemos considerar si es una buena idea la introducción de conceptos de especialización! generalización para representar las vistas de usuario Branch de DreamHome. En otras palabras, ¿es mejor representar la especificación de requisitos de las vistas de usuario Branch mediante el modelo ER mostrado en la Figura 11.1 o mediante el modelo EER mostrado en la Figura 12.8? Dejamos al lector la respuesta a esta pregunta.
12.2 Agregación Agregación
Representa una relación de tipo 'tiene' o 'es parte de' entre tipos de entidad, en la que uno de los tipos de entidad representa el 'todo' y el otro representa la 'parte'.
Una relación representa una asociación entre dos tipos de entidad que se encuentran al mismo nivel conceptual. En ocasiones, deseamos modelar una relación de tipo 'tiene' o 'es parte de', en la que una entidad represente una entidad de mayor tamaño (el 'todo'), compuesta de entidades más pequeñas (las 'partes'). Este tipo especial de relación se denomina agregación (Booch et al., 1998). La agregación no cambia el significado de la navegación a través de la relación entre el todo y las partes, ni tampoco establece ninguna vinculación entre el todo y las partes. Un ejemplo de agregación sería la agregación Has, que relaciona la entidad Branch (el 'todo') con la entidad 81aff (la 'parte').
Representación
diagramática
de la agregación
El lenguaje UML representa la agregación situando un rombo en uno de los extremos de la línea de relación, aliado de la entidad que representa el 'todo'. En la Figura 12.9, hemos redibujado parte del diagrama EER mostrado en la Figura 12.8 para incluir la representación de la agregación. Este diagrama EER muestra dos ejemplos de agregación, Branch Has 81aff y Branch Offers PropertyForRent. En ambas relaciones, la entidad Branch representa el 'todo', por lo que el rombo se coloca aliado de esta entidad.
12.3
Composición
Composición
Una forma especifica de agregación que representa una asociación entre entidades donde hay una pertenencia fuerte y una existencia coincidente entre el 'todo' y la 'parte'.
La agregación es enteramente conceptual y lo único que hace distinguir un 'todo' de una 'parte'. Sin embargo, existe una variante de la agregación denominada composición que representa una pertenencia fuerte y una existencia coincidente entre el 'todo' y la 'parte' (Booch et al., 1998). En una composición, el 'todo' es responsable de la disposición de las 'partes', lo que quiere decir que la composición debe gestionar la creación y destrucción de sus 'partes'. En otras palabras, un objeto sólo puede ser parte de una composición en cada momento. No existe ningún ejemplo de composición en la Figura 12.8. Para facilitar nuestras explicaciones, considere un ejemplo de composición, la relación Displays (muestra) que relaciona la entidad Newspaper con la entidad Advert. Como composición, esto resalta el hecho de que cada entidad Advert (la 'parte') pertenece a exactamente una entidad Newspaper (el 'todo'). Esto contrasta con la agregación, en la que una parte puede ser compartida por muchos todos. Por ejemplo, una entidad 81aff puede ser 'parte de' una o más entidades Branch.
Representación
diagramática
de la composición
El lenguaje UML representa la composición colocando un rombo relleno en uno de los extremos de la línea de relación, al lado de la entidad que representa el 'todo'. Por ejemplo, para representar la composición Newspaper Displays Adver, el rombo relleno se sitúa aliado de la entidad Newspaper, que es el 'todo' de esta relación, como se muestra en la Figura 12.10.
Capítulo 12 Modelado entidad-relación avanzado
Entidad que representa el 'todo' en las relaciones Has y Offers
Entidad que representa la 'parte' en la relación Has
staffNo propertyNo
1.. 1. *
I
"
351
••• Has
••• Offers
Branch
s~
~ Oversees
PropertyForRent
I
*
Entidad que representa la 'parte' en la relación Offers
Figura 12.9.
Ejemplos de agregación:
Branch Has 8taff y Branch Offers PropertyForRent.
Advert
Entidad que representa la 'parte' en la relación Displays
1 .. * .i,
Displays
1..1 Newspaper newspaperName
Figura 12.10.
Un ejemplo de composición:
Newspaper Displays Advert (un periódico muestra un anuncio).
Como hemos indicado al hablar de la especialización/generalización, la opción sobre si utilizar agregación y composición, y en qué grado hacerlo, son también decisiones de carácter subjetivo. La agregación y composición sólo debe usarse cuando exista el requisito de enfatizar relaciones especiales entre tipos de entidades, como por ejemplo el tipo 'tiene' o 'es parte de', lo que puede tener implicaciones en la creación, actualización y borrado de estas entidades estrechamente relacionadas. Hablaremos de cómo representar dichas restricciones entre tipos de entidad cuando expongamos nuestra metodología para el diseño lógico de bases de datos, en el Capítulo 16, dentro del Paso 2.4. Si tenemos en cuenta que el objetivo principal de un modelo de datos consiste en comunicar de forma precisa y no ambigua nuestra comprensión de los datos corporativos, sólo debemos usar los conceptos adicionales de agregación y composición cuando los datos corporativos sean demasiado complejos para representarlos con facilidad utilizando únicamente los conceptos básicos del modelo ER.
352
Sistemas de bases de datos
Resumen del capítulo •
Una superclase es un tipo de entidad que incluye uno o más sub grupos diferenciados de instancias, los cuales es preciso representar en un modelo de datos. Una sub clase es un subgrupo diferenciado de instancias de un tipo de entidad, el cual necesita ser representado en un modelo de datos.
•
La especialización es el proceso de maximizar las diferencias entre miembros de una entidad identificando sus características distintivas.
•
La generalización ticas comunes.
•
Hay dos restricciones que pueden aplicarse a las relaciones de especialización/generalización; tricciones son las restricciones de participación y las restricciones de disyunción.
•
Una restricción subclase.
•
Una restricción de disyunción describe la relación entre miembros de las subc1ases e indica si es posible que un miembro de una superclase sea miembro de una subc1ase o de más de una.
•
La agregación representa una relación de tipo 'tiene' o 'es parte de' entre tipos de entidad, en la que uno de los tipos de entidad representa el 'todo' y el otro la 'parte'.
•
La composición es una forma específica de agregación que representa una asociación entre entidades, en la que existe una pertenencia fuerte y una existencia coincidente entre el 'todo' y la 'parte'.
es el proceso de minimizar las diferencias entre entidades identificando sus caracterís-
de participación
dichas res-
determina si todo miembro de la superclase debe ser miembro de una
Cuestiones de repaso 12.1.
Describa lo que representan una superc1ase y una subc1ase.
12.2.
Describa la relación entre una superc1ase y su subc1ase.
12.3.
Describa el proceso de herencia de atributos e ilústrelo con un ejemplo.
12.4.
¿Cuáles son las razones principales para introducir los conceptos de superclases y subclases en un modelo ER?
12.5.
Describa qué es lo que representa una subc1ase compartida y cómo se relaciona este concepto con el de herencia múltiple.
12.6.
Describa los procesos de especialización y generalización e indique sus diferencias ..
12.7.
Describa las dos restricciones principales que se aplican a las relaciones de especialización/generalización.
12.8.
Describa los conceptos de agregación y composición, indique en qué se diferencian y proporcione un ejemplo de cada uno de esos conceptos.
Ejercicios 12.9.
Considere si sería apropiado introducir los conceptos avanzados de especialización/generalización, agregación y/o composición para los casos de estudio descritos en el Apéndice B.
12.10. Considere si sería apropiado introducir los conceptos avanzados de especialización/generalización, agregación y/o composición en el modelo ER del caso de estudio descrito en el Ejercicio 11.12. Si resulta apropiado, vuelva a dibujar el diagrama ER como un diagrama EER, añadiendo los conceptos adicionales avanzados.
Normalización Objetivos del capítulo: En este capítulo aprenderá: •
El propósito de la normalización.
•
Cómo puede usarse la normalización a la hora de diseñar una base de datos relaciona!.
•
Los problemas potenciales asociados con los datos redundante s en las relaciones de base.
•
El concepto de dependencia funcional, que describe la relación entre los atributos.
•
Las características de las dependencias funcionales usadas en la normalización.
•
Cómo identificar dependencias funcionales para una relación dada.
•
Cómo las dependencias funcionales identifican las claves primarias de una relación.
•
Cómo llevar a cabo el proceso de normalización.
•
Cómo utiliza la normalización las dependencias funcionales para agrupar los atributos en relaciones que estén en una forma normal conocida.
•
Cómo identificar las formas normales más comúnmente utilizadas, que son la primera forma normal (lNF), la segunda forma normal (2NF) y la tercera forma normal (3NF).
•
Los problemas asociados con las relaciones que transgreden las reglas de las formas normales lNF, 2NF o 3NF.
•
Cómo representar los atributos mostrados en un formulario como relaciones 3NF utilizando los procedimientos de normalización.
Cuando diseñamos una base de datos para una organización, el objetivo principal es crear una representación precisa de los datos, de las relaciones entre los datos y de las restricciones aplicables a los datos que sean pertinentes para la organización. Como ayuda para tratar de conseguir este objetivo, podemos emplear una o más técnicas de diseño de bases de datos. En los Capítulos 11 y 12 hemos descrito una técnica denominada modelado entidad-relación (ER). En este capítulo y en el siguiente, vamos a describir otra técnica de diseño de bases de datos denominada normalización. La normalización es una técnica de diseño de bases de datos que comienza examinando las relaciones (denominadas dependencias funcionales) que existen entre los atributos. Los atributos describen alguna propiedad de los datos o de las relaciones entre los datos que sea importante para la organización. La normalización emplea una serie de pruebas (descritas como formas normales) para tratar de identificar el agrupamiento óptimo de estos atributos, con el fin de identificar un conjunto de relaciones que soporten adecuadamente los requisitos de datos de la organización. Aunque el propósito principal de este capítulo es introducir el concepto de dependencias funcionales y describir el proceso de normalización hasta la tercera forma normal (Third Normal Form, 3NF), en el Capítulo 14 examinaremos de modo más formal las dependencias funcionales y también consideraremos otras formas normales posteriores que van más allá de la forma normal 3NF.
354
Sistemas de bases de datos
Estructura del capítulo En la Sección 13.1 se describe el propósito de la normalización. En la Sección 13.2 se explica cómo puede utilizarse la normalización durante el proceso de diseño de bases de datos relacionales. En la Sección 13.3 se identifican e ilustran los problemas potenciales asociados con la redundancia de los datos en una relación base que no esté normalizada. En la Sección 13.4 se describe el concepto principal asociado con la normalización, concepto que se denomina dependencia funcional y describe la relación entre los atributos. También describiremos las características de las dependencias funcionales que se utilizan en el proceso de normalización. En la Sección 13.5 presentamos una panorámica del proceso de la normalización y en las siguientes secciones se describen las tres formas normales más comúnmente utilizadas: la primera forma normal (lNF) en la Sección 13.6, la segunda forma normal (2NF) en la Sección 13.7 y la tercera forma normal (3NF) en la Sección 13.8. Las formas 2NF y 3NF descritas en estas secciones están basadas en la clave principal de una relación. En la Sección 13.9 se presentan definiciones generales para las formas 2NF y 3NF basadas en todas las claves candidatas de una relación. A lo largo de este capítulo utilizamos ejemplos tomados del caso de estudio DreamHome descrito en la Sección 10.4 y documentado en el Apéndice A.
13.1 El propósito de la normalización Normalización
Una técnica para producir un conjunto de relaciones con una serie de propiedades deseables, partiendo de los requisitos de datos de una organización.
El propósito de la normalización es identificar un conjunto adecuado de relaciones que soporte los requisitos de datos de una organización. Las características de un conjunto adecuado de relaciones incluyen: •
el número mínimo de atributos necesario para soportar los requisitos de datos de la organización;
•
los atributos con una relación lógica fuerte (lo que se describe como dependencia funcional) se encuentran en la misma relación;
•
una redundancia mínima, estando cada atributo representado una sola vez, con la importante excepción de aquellos atributos que constituyan o formen parte de claves externas (véase la Sección 3.2.5), los cuales son esenciales para la combinación de relaciones.
Las ventajas de utilizar una base de datos que esté compuesta por un conjunto adecuado de relaciones son que el usuario encontrará más sencillo acceder a la base de datos y mantenerla y que ésta ocupará un espacio de almacenamiento mínimo en la computadora. En la Sección 13.3 se describen los problemas asociados con la utilización de una relación que no esté adecuadamente normalizada.
13.2 Cómo ayuda la normalización al diseño de bases de datos La normalización es una técnica formal que puede utilizarse en cualquier etapa del diseño de bases de datos. Sin embargo, en esta sección resaltaremos dos técnicas principales de utilización de la normalización, como se ilustra en la Figura 13.1. La técnica 1 muestra cómo puede emplearse la normalización como técnica autónoma de tipo abajo-arriba para el diseño de bases de datos, mientras que la técnica dos muestra cómo emplear la normalización como técnica de validación para comprobar la estructura de las relaciones, las cuales pueden haber sido creadas utilizando una técnica arriba-abajo como por ejemplo el modelado ER. Independientemente de qué técnica se utiliza, el objetivo es el mismo: crear un conjunto de relaciones bien diseñadas que satisfagan los requisitos de datos de la organización. La Figura 13.1 muestra ejemplos de fuentes de datos que pueden utilizarse para el diseño de bases de datos. Aunque la especificación de requisitos del usuario (véase la Sección 9.5) es la fuente de datos preferida, resulta posible diseñar una base de datos basándose en la información tomada directamente de otras fuen-
Capítulo 13 Normalización
355
tes de datos como formularios e informes, como se ilustra en este capítulo y en el siguiente. La Figura 13.1 muestra también que una misma fuente de datos puede utilizarse para ambas técnicas. Sin embargo, aunque esto sea cierto en principio, en la práctica la técnica que se adopte estará determinada probablemente por el tamaño, extensión y complejidad de la base de datos que esté siendo descrita por las fuentes de datos, así como por las preferencias y la experiencia del diseñador de la base de datos. La oportunidad de utilizar la normalización como técnica independiente de tipo abajo-arriba (técnica 1) está limitada a menudo por el nivel de detalle que cabe esperar razonablemente que el diseñador de la base de datos sea capaz de manejar. Sin embargo, esta limitación no es aplicable cuando la normalización se utiliza como técnica de validación (técnica 2), ya que el diseñador de la base de datos se centra únicamente en una parte de la base de datos, como por ejemplo, una única relación, en cualquier instante dado. Por tanto, independientemente del tamaño y de la complejidad de la base de datos, las técnicas de normalización siempre pueden resultar útiles.
/-
13.3 Redundancia de los datos y anomalías de actualización Como hemos indicado en la Sección 13.1, uno de los objetivos principales del diseño de bases de datos relacionales es agrupar los atributos en relaciones de modo que se minimice la redundancia de los datos. Si se consigue este objetivo, se pueden obtener diversas ventajas en la implementación de la base de datos: •
las actualizaciones de los datos almacenados en la base de datos pueden llevarse a cabo con un número mínimo de operaciones, reduciendo las posibilidades de que aparezcan incoherencias en los datos almacenados;
•
se reduce el espacio de almacenamiento minimizan los costes.
••.
1
de archivos requerido por las relaciones base, con lo cual se
Utilización de una técnica arriba-abajo, como el modelado ER
Fuentes de datos
El modelo ER se hace corresponder con un conjunto de relaciones
Formularios/informes utilizados o generados por la organización
Fuentes que describan la organización, como el diccionario de datos y el modelo de datos corporativo
Conjunto de relaciones bien diseñadas
Técnica
Técnica
2
Utilización de la normalización como técnica de validación para comprobar la estructura de las relaciones (este enfoque se describe en el Capitulo 16, Paso 2.2)
1
Utilización de la normalización como técnica abajo-arriba para crear un conjunto de relaciones (esta técnica se describe en este capitulo en el siauiente
Figura 13.1.
Cómo puede utilizarse la normalización
para ayudar en el diseño de bases de datos.
356
Sistemas de bases de datos Staff Assistant BOO? B003 BOOS 30000 12000 AnnBeech B00324000 18000 staffNo BOOS sName branchNo 9000 David Susan Ford Brand john White salary position MaryHowe julie Lee Manager Supervisor
SGS SG3? SG14 SL41 SA9 SL21
Branch branchNo
bAddress 22 Deer Rd, London
16 163Ar9Yl1St;J\berdeen ~ain St, Glasgow
BOO? B003 BOOS
Figura 13.2.
Relaciones Staff y Branch.
Por supuesto, las bases de datos relacionales también dependen de la existencia de una cierta cantidad controlada de redundancia en los datos. Esta redundancia aparece en forma de copias de las claves primarias (o claves candidatas), copias que actúan como claves externas en las relaciones correspondientes, para permitir modelar las relaciones entre los datos. En esta sección vamos a ilustrar los problemas asociados con la redundancia indeseada en los datos, comparando las relaciones 8taff y Branch mostradas en la Figura 13.2 con la relación 8taffBranch que se muestra en la Figura 13.3. La relación 8taffBranch es un formato alternativo de las relaciones 8taff y Branch. Las relaciones tienen la forma: 8taff
(staffNo, sName, position, salary, branchNo)
Branch
(branchNo,
8taffBranch
(staffNo, sName, position, salary, branchNo,
bAddress) bAddress)
Observe que está subrayada la clave principal de cada relación. En la relación 8taffBranch hay datos redundantes; la información de las sucursales se repite para cada empleado que trabaja en una sucursal. Por contraste, la información de detalles sobre las sucursales aparece sólo una vez por cada sucursal en la relación Branch, repitiéndose únicamente el número de sucursal (branchNo) en la relación 8taff, con el fin de representar dónde trabaja cada empleado. Las relaciones con datos redundantes pueden presentar problemas que se denominan anomalías de actualización, clasificándose dichos problemas como anomalías de inserción, de borrado o de modificación.
13.3.1 Anomalías de inserción Hay dos tipos principales de anomalía de inserción, que vamos a ilustrar utilizando la relación trada en la Figura 13.3 . •
8taffBranch
mos-
Para insertar los detalles de un nuevo empleado en la relación 8taffBranch, debemos incluir los detalles de la sucursal en la que trabaja el empleado. Por ejemplo, para insertar la información de un nuevo empleado de la sucursal número B007, debemos incluir los detalles correctos de la sucursal B007, de modo que esos detalles sean coherentes con los valores correspondientes a la sucursal B007 que estén contenidos en otras tuplas de la relación 8taffBranch. Las relaciones mostradas en la Figura 13.2 no sufren estas incoherencias potenciales, puesto que sólo se introduce el número de sucursal apropiado para cada empleado de la relación 8taff. Los detalles de la sucursal B007 se registran en la base de datos como una única tupla en la relación Branch.
Capítulo 13 Normalización
357
StaffBranch staffNo
•
B005 B007 B003 Ann Beech B005 18000 David Ford 24000 9000 branchNo 12000 sName bAddress Assistant 30000 Susan Brand Julie 22 Deer Lee Rd, John White MaryHowe salary 163 16 position Argyll Main St, SI, Aberdeen Glasgow Supervisor St,London Manager
Para insertar los detalles de una nueva sucursal que actualmente no tenga Ilingún empleado en la relación StaffBranch, es necesario introducir valores nulos en los atributos relativos al empleado, como por ejemplo staffNo .. Sin embargo, como staffNo es la clave principal de la relación StaffBranch, si tratamos de introducir un valor nulo en staffNo se viola la integridad referencial (véase la Sección 3.3), por lo que esta operación no está permitida. Por tanto, no podemos introducir en la relación StaffBranch una nueva tupla para definir una nueva sucursal con un valor nulo para staffNo. El diseño de las relaciones mostrado en la Figura 13.2 evita este problema, porque los detalles relativos a una sucursal se introducen en la relación Branch de forma separada de los detalles de los empleados. La información de los empleados que posteriormente se asignen a esa sucursal se introducirá en la relación Staff.
13.3.2 Anomalías de borrado Si borramos una tupla de la relación StaffBranch que represente el último empleado de una cierta sucursal, también se perderá la información acerca de dicha sucursal. Por ejemplo, si borramos la tupla del empleado SA9 (Mary Howe) de la relación StaffBranch, perderemos los detalles relativos a la sucursal B007. El diseño de las relaciones que se muestra en la Figura 13.2 evita este problema, porque las tuplas relativas a las sucursales se almacenan independientemente de las tuplas de los empleados, y tan solo el atributo branchNo permite establecer la correspondencia entre las dos relaciones. Si borramos la tupla del empleado SA9 de la relación Staff, los detalles de la sucursal B007 no se ven afectados en la relación Branch.
13.3.3 Anomalías de modificación Si queremos cambiar el valor de uno de los atributos de una sucursal concreta en la relación StaffBranch, por ejemplo la dirección de la sucursal B003, tenemos que actualizar las tuplas de todos los empleados actualizados en dicha sucursal. Si esta modificación no se lleva a cabo en todas las tuplas apropiadas de la relación StaffBranch, la base de datos quedará en un estado incoherente. En este ejemplo, la sucursal B003 podría llegar a tener diferentes direcciones en las tuplas correspondientes a diferentes empleados. Los ejemplos anteriores ilustran que las relaciones Staff y Branch de la Figura 13.2 tienen propiedades más deseables que las de la relación StaffBranch de la Figura 13.3. Esto nos muestra que, mientras que la relación StaffBranch está sujeta a anomalías de actualización, podemos evitar estas anomalías descomponiendo la relación original en las dos relaciones Staff y Branch. Hay dos propiedades importantes asociadas con la descomposición de una relación de mayor tamaño en una serie de relaciones más pequeñas: •
La propiedad de combinación sin pérdidas garantiza que cualquier instancia de la relación original pueda ser identificada a partir de las instancias correspondientes de las relaciones más pequeñas.
•
La propiedad de preservación de la dependencia garantiza que una restricción de la relación original pueda mantenerse simplemente imponiendo alguna restricción a cada una de las relaciones más pequeñas. En otras palabras, no necesitamos combinar las relaciones más pequeñas para comprobar si se viola o no una restricción de la relación original.
358
Sistemas de bases de datos
Posteriormente en este capítulo, veremos cómo puede utilizarse el proceso de normalización para obtener relaciones bien formadas. Sin embargo, primero vamos a presentar el concepto de dependencia funcional, que resulta fundamental para el proceso de normalización.
13.4 Dependencias funcionales Un importante concepto asociado con la normalización es el de dependencia funcional, que describe la relación entre atributos (Maier, 1983). En esta sección vamos a describir las dependencias funcionales y luego nos centraremos en las características concretas de esas dependencias funcionales que resultan útiles para el proceso de normalización.
Después ex~icaremos
cómo se las puede usar para identifi~lave
cómo pueden identificarse
las dependencias
funcionales y
primaria de una relación.
13.4.1 Características de las dependencias funcionales Para nuestra explicación sobre las dependencias funcionales, suponga que un cierto esquema relacional tiene una serie de atributos (A, B, C, , z) y que la base de datos está descrita mediante una única relación uni, Z). Esta suposición implica que todo atributo de la base de datos tiene versal denominada R = (A, B, C, un nombre distintivo. Dependencia funcional
Describe la relación existente entre atributos de una relación. Por ejemplo, si A y B son atributos de la relación R, B será funcional mente dependiente de A (lo que se denota A ---7 B) si cada valor de A está asociado con exactamente un valor de B (A Y B pueden consistir cada uno de ellos de uno o más atributos).
La dependencia funcional es una propiedad del significado o semántica de los atributos de una relación. La semántica indica cómo se relacionan entre sí los atributos y especifica las dependencias funcionales que existen entre ellos. Cuando hay presente una dependencia funcional, la dependencia se especifica como una restricción entre los atributos. Considere una relación con atributos A y B en la que el atributo B es funcionalmente dependiente del atributo A. Si conocemos el valor de A y examinamos la relación que alberga esta dependencia, vemos que el valor de B es el mismo en todas las tuplas que tienen el valor de A dado. Por tanto, cuando dos tuplas tienen el mismo valor de A, tienen también el mismo valor de B. Sin embargo, para un determinado valor de B puede haber varios valores diferentes de A. La dependencia entre los atributos A y B puede representarse en forma de diagrama como se muestra en la Figura 13.4. Una manera alternativa de describir la relación entre los atributos A y B es decir que 'A determina funcionalmente a B' . Algunos lectores pueden preferir esta descripción, ya que sigue de manera más natural la dirección de la flecha de dependencia funcional entre ambos atributos. Determinante
Hace referencia al atributo o grupo de atributos en el lado izquierdo de la flecha que describe una dependencia funcional.
Cuando existe una dependencia funcional, el atributo o grupo de atributos en el lado izquierdo de la flecha se denomina determinante. Por ejemplo, en la Figura 13.4, A es el determinante de B. Vamos a ilustrar la identificación de una dependencia funcional en el siguiente ejemplo. B depende funcionalmente de A
Figura 13.4.
Un diagrama de dependencia
funcional.
Capítulo 13 Normalización
I
Ejemplo 13.1 Un ejemplo
de dependencia
359
funcional
Considere los atributos staffNoy position de la relación 8taff en la Figura 13.2. Para un valor específico de staffNo, por ejemplo SL21, podemos determinar la categoría de dicho empleado, que en este caso concreto resulta ser Manager. En otras palabras, staffNodetermina funcionalmente el valor de position, como se muestra en la Figura 13.5(a). Sin embargo, la Figura 13.5(b) ilustra que la relación opuesta no es cierta, ya que position no determina funcional mente staffNo. Un empleado tiene una categoría'laboral; sin embargo, puede haber varios empleados con la misma categoría. La relación entre staffNoy position es de tipo uno a uno (1: 1), ya que para cada número de empleado sólo hay una categoría laboral. Por el contrario, la relación entre position y staffNo es de tipo uno a muchos (1 :*): hay varios números de empleado asociados con cada categoría laboral concreta. En este ejemplo, staffNoes el determinante de esta dependencia funcional. Para los propósitos de la normalización, lo que nos interesa es identificar dependencias funcionales entre atributos de una relación que tengan una relación uno a uno entre el atributo o atributos que forman el determinante en el lado izquierdo y el atributo o atributos en el lado derecho de la dependencia. Al identificar dependencias funcionales entre atributos de una relación, es importante distinguir claramente entre los valores que toma un atributo en un instante determinado y el conjunto de todos los posibles valores que un atributo puede contener en instantes distintos. En otras palabras, una dependencia funcional es una propiedad de un esquema relacional (intensión) y no de una instancia concreta del esquema (extensión); véase la Sección 3.2.1. Este punto se ilustra en el siguiente ejemplo. positiondetermina funcionalmentestaffNo
Númerode empleadoSL21
Manager
(a)
positionn~rmina funcionalmentestaffNo ~ Manager---
Númerode empleadoSL21
-..~ .• Númerode empleado SG5
(b)
(a) staffNo determina funcionalmente position (staffNo --7 position); (b) position no determina funcionalmente staffNo (position X--7 staffNo).
Figura 13.5.
I
Ejemplo 13.2 Ejemplo de una dependencia
funcional
que se cumple
en cualquier
instante
Considere los valores mostrados en los atributos staffNo y sName de la relación 8taff en la Figura 13.2. Vemos que para un valor de staffNoespecífico, como por ejemplo SL21, podemos determinar el nombre de dicho empleado, que resulta ser lohn White. Además, parece que para un valor de sName espe-
360
Sistemas de bases de datos
cífico, por ejemplo John White, podemos determinar el número de empleado, que en este caso resulta ser SL21. ¿Podemos concluir por tanto que el atributo staffNo determina funcionalmente el atributo sName y/o el atributo sName determina funcionalmente el atributo staffNo? Si los valores mostrados en la relación Staff de la Figura 13.2 representan el conjunto de todos los posibles valores de los atributos staffNo y sName, entonces se cumplen las siguientes dependencias funcionales: staffNo sName
-7 sName -7 staffNo
I Sin embargo, si los valores mostrados en la relación Staff de la Figura 13.2 representan simplemente un conjunto de valores para los atributos staffNo y sName en un instante concreto de tiempo, entonces no nos interesan tanto esas relaciones entre los atributos. La razón es que lo que queremos es identificar dependencias funcionales que se cumplan para todos los posibles valores de los atributos de una relación, ya que estas dependencias son las que representan los tipos de restricciones de integridad que necesitamos identificar. Dichas restricciones indican las limitaciones aplicables a los valores que una relación pueden legítimamente asumir. Una técnica para identificar el conjunto de todos los posibles valores de los atributos de una relación es tratar de comprender más claramente el propósito de cada atributo dentro de la relación. Por ejemplo, el propósito de los valores contenidos en el atributo staffNo es identificar unívocamente cada empleado, mientras que el propósito de los valores contenidos en el atributo sName es almacenar los nombres de los empleados. Obviamente, seguirá el enunciado de que si sabemos el número de empleado (staffNo) podemos determinar el nombre del empleado (sName) seguirá siendo cierto. Sin embargo, puesto que el atributo sName puede contener valores duplicados para empleados que tengan el mismo nombre, entonces para algunos de los empleados podríamos no ser capaces de determinar el número correspondiente (staffNo) a partir de su nombre. La relación entre staffNo y sName es de tipo uno a uno (l: 1), ya que para cada número de empleado sólo hay un nombre. Por el contrario, la relación entre sName y staffNo es uno a muchos (l :*), ya que puede haber varios números de empleados asociados con un nombre concreto. La dependencia funcional que sigue siendo cierta después de considerar todos los posibles valores de los atributos staffNo y sName en la relación Staff es: staffNo -7 sName
~
Una característica adicional de las dependencias funcionales que resulta útil para el proceso de normalización es que sus determinantes deben tener el número mínimo de atributos necesario para mantener la dependencia funcional de los atributos del lado derecho. Este requisito se denomina dependencia funcional completa: Dependencia funcional
Indica que si A y B son atributos de una relación, B depende funcionalmente de manera completa de A si B depende funcionalmente de A pero no de ningún subconjunto propio de A.
completa
Una dependencia funcional A ~ B es una dependencia funcional completa si la eliminación de cualquier atributo de A hace que la dependencia deje de existir. Una dependencia funcional A ~ B es una dependencia parcial si existe algún atributo que puede eliminarse de A y la dependencia continua verificándose. En el Ejemplo 13.3 se muestra cómo derivar una dependencia funcional completa a partir de una dependencia funcional parcial.
I
Ejemplo 13.3 Ejemplo
de dependencia
funcional
completa
Considere la siguiente dependencia funcional existente en la relación staffNo, sName
-7
branchNo
Staff
de la Figura 13.2:
Capítulo 13 Normalización
361
Resulta correcto decir que cada valor de (staffNo, sName) está asociado con un único valor de branchNo. Sin embargo, no se trata de una dependencia funcional completa, porque branchNo también depende funcionalmente de un subconjunto de (staffNo, sName), en concreto de staffNo. En otras palabras, la dependencia funcional mostrada es un ejemplo de dependencia parcial. El tipo de dependencia funcional que nos interesa identificar son las dependencias funcionales completas, como por ejemplos: staffNo
--->
branchNo
En la Sección 13.7 se analiza ejemplos adicionales de dependías funcionales parciales y completas.
~ En resumen, las dependencias funcionales que utilizamos en el proceso de normalización tiene las siguientes características: •
Hay una relación uno a uno entre los atributos del lado izquierdo (determinante) y los del lado derecho de la dependencia funcional. (Observe que la relación en la dirección opuesta, es decir, desde los atributos del lado derecho a los atributos del lado izquierdo, puede ser una relación uno a uno o una relación uno a muchos).
•
Se cumplen en todo instante de tiempo.
•
El determinante tiene el número mínimo de atributos necesario para mantener la dependencia con los atributos del lado derecho. En otras palabras, debe haber una dependencia funcional completa entre los atributos del lado izquierdo y los del lado derecho de la dependencia.
Hasta ahora hemos hablado de las dependencias funcionales que nos interesan para el proceso de normalización. Sin embargo, hay un tipo adicional de dependencia funcional denominado dependencia transitiva que necesitamos poder reconocer, ya que su existencia en una relación podría llegar a causar los tipos de anomalías de actualización explicados en la Sección 13.3. En esta sección, vamos simplemente a describir dichas dependencias para poderlas identificar cuando sea necesario. Dependencia transitiva
Una condición en la que A, B Y C son atributos de una relación tales que si A ~ B Y B ~ C, entonces C depende transitivamente de A a través de B (supuesto que A no sea funcionalmente dependiente de B o C).
En el Ejemplo 13.4 se ilustra el concepto de dependencia transitiva.
I
Ejemplo 13.4 Ejemplo
de dependencia
Considere las siguientes dependencias 13.3: staffNo
--->
branchNo
transitiva
funcionales en la relación
sName. position, salary, branchNo, --->
funcional
StaffBranch
mostrada en la Figura
bAddress
bAddress
La dependencia transitiva branchNo ---7 bAddress existe en staffNo a través de branchNo. En otras palabras, el atributo staffNo determina funcionalmente bAddress a través del atributo branchNo y ni branchNo ni bAddress determinan funcionalmente staffNo. En la Sección 13.8 se explica un ejemplo adicional de dependencia transitiva.
En las secciones siguientes vamos a ilustrar una serie de técnicas para identificar un conjunto de dependencias funcionales y luego explicaremos cómo pueden usarse estas dependencias para identificar una clave primaria para las relaciones de ejemplo.
362
Sistemas de bases de datos
13.4.2 Identificación de dependencias funcionales La identificación de todas las dependencias funcionales entre un conjunto de atributos debería ser bastante simple si se comprende bien el significado de cada atributo y la relaciones existentes entre los atributos. Este tipo de información puede ser proporcionada por la organización en forma de conversaciones con los usuarios y/o de documentación apropiada, como por ejemplo la especificación de requisitos de usuario. Sin embargo, si los usuarios no están disponibles para poder consultarse y/o la documentación es incompleta, entonces prtede ser necesario, dependiendo de la aplicación de base de datos, que el diseñador de la base de datos utilic~ su sentido común y/o su experiencia para suplir la información que falta. El Ejemplo 13.5 ilustra lo fácil qtie es identificar dependencias funcionales entre atributos de una relación cuando se comprenden adecuadamente el propósito de cada atributo y las relaciones existentes entre unos atributos y otros.
I
Ejemplo 13.5 Identificación StaffBranch
de un conjunto
de dependencias
funcionales
para la relación
Comenzamos examinando la semántica de los atributos de la relación StaffBranch mostrada en la Figura 13.3. De cara a nuestra explicación, vamos a suponer que la categoría laboral y la sucursal determinan el salario de cada empleado. Identificamos las dependencias funcionales basándonos en nuestra comprensión de los atributos de la relación, resultando: staffNo --7 sName, position, salary, branchNo,
bAddress
branchNo --7 bAddress bAddress --7 branchNo branchNo,
position --7 salary
bAddress, position --7 salary
Hemos identificado cinco dependencias funcionales en la relación StaffBranch, con staffNo, branchNo, bAddress, (branchNo, position) y (bAddress, position) como determinantes. Para cada dependencia funcional, garantizamos que todos los atributos del lado derecho dependen funcionalmente del determinante del lado izquierdo.
En contraste con este ejemplo, vamos a considerar ahora la situación en la que hay que identificar las dependencias funcionales en ausencia de una información apropiada acerca del significado de los atributos y de sus relaciones. En este caso, puede ser posible identificar las dependencias funcionales si hay disponibles datos de ejemplo que constituyan una representación veraz de todos los posibles valores de datos que la base de datos puede contener. Vamos a ilustrar esta técnica en el Ejemplo 13.6.
I
Ejemplo 13.6 Utilización de datos de ejemplo para identificar funcionales
las dependencias
Considere los datos para los atributos A, B, e, o y E in la relación Sample de la Figura 13.6. Resulta importante comprobar primero que los valores de datos mostrados en esta relación son representativos de todos los posibles valores que puedan contener los atributos A, B, e, o y E. Para los propósitos de este ejemplo, vamos a suponer que esto es cierto, a pesar de la cantidad de datos relativamente pequeña que contiene esta relación. El proceso de identificar las dependencias funcionales (denotadas fdl a fd4) que existen entre los atributos de la relación Sample mostrado en la Figura 13.6 es el que se describe a continuación. Para identificar las dependencias funcionales que existen entre los atributos A, B, e, o y E, examinamos la relación Sample mostrada en la Figura 13.6 e identificamos cuándo los valores en una columna son coherentes con la presencia de valores concretos en otras columnas. Comenzamos con la primera
Capítulo 13 Normalización
Relación
363
Sample A
se8
w w frtqpt bE zdrzD
tI
I
jj
fd1 fd2
fd4 fd3
Figura 13.6. La relación Sample mostrando datos para los atributos A, B, e, D y E Y las dependencias funcionales (fd1 a fd4) que existen entre estos atributos.
columna de la izquierda y vamos recorriendo la tabla hacia la derecha examinando combinaciones de columnas, es decir, si los valores en dos o más columnas son coherentes con la presencia de valores en otras columnas. Por ejemplo, cuando el valor 'a' aparece en la columna A, el valor 'z' aparece en la columna C, y cuando aparece el valor 'e' en la columna A aparece el valor 'r' en la columna c. Podemos por tanto concluir que hay una relación uno a uno (1: 1) entre los atributos A y c. En otras palabras, el atributo A determina funcionalmente el atributo C y esto se muestra como la dependencia funcional 1 (fdl) en la Figura 13.6. Además, ya que los valores de la columna C son coherentes con la aparición de valores concretos en la columna A, podemos concluir que existe una relación (1 :1) entre los atributos C y A. En otras palabras, C determina funcionalmente A y esto se muestra como fd2 en la Figura 13.6. Si ahora consideramos el atributo B, podemos ver que cuando aparece 'b' o 'd' en la columna B, aparece el valor 'w' en la columna O y que cuando aparece 'f' en la columna B, aparece 's' en la columna D. Podemos por tanto concluir que hay una relación (1: 1) entre los atributos O y B. En otras palabras, B determina funcional mente O y esto se muestra como fd3 en la Figura 13.6. Sin embargo, el atributo O no determinajuncionalmente el atributo B, ya que un mismo valor en la columna O (como por ejemplo 'w') no está asociado con un único valor coherente en la columna B. En otras palabras, cuando aparece 'w' en la columna o, aparecen los valores 'b' o 'd' en la columna B. Por tanto, hay una relación uno a muchos entre los atributos O y B. El atributo final a considerar es E, y vemos que los valores en esta columna no están asociados con la aparición coherente de valores concretos en las otras columnas. En otras palabras, el atributo E no determina funcional mente a los atributos A, B, C o D. Ahora consideramos combinaciones de atributos y la aparición de valores coherentes en otras columnas. Concluimos que toda combinación distintiva de valores en las columnas A y B, como por ejemplo (a, b) está asociada con un mismo valor en la columna E, que en este ejemplo es 'q'. En otras palabras, los atributos -eA, B) determinan funcionalmente el atributo E, y esto se muestra como fd4 en la Figura 13.6. Sin embargo, la relación inversa no es cierta, ya que hemos visto que el atributo E no determina funcionalmente ningún otro atributo en la relación. Completamos el examen de la relación mostrada en la Figura 13.6 considerando todas las restantes combinaciones de columnas.
364
Sistemas de bases de datos
En resumen, podemos describir las dependencias funcionales entre los atributos A a Sample mostrada en la Figura 13.6 de la forma siguiente: A~C
(fd1 )
C~A
(fd2)
B~D A, B~
)
E
de la relación
(fd3) E
(fd4)
13.4.3 Identificación de la clave primaria de una relación utilizando las dependencias funcionales El objetivo principal de identificar un conjunto de dependencias funcionales para una relación es el de especificar el conjunto de restricciones de integridad que la relación debe satisfacer. Una restricción de integridad importante que hay que considerar en primer lugar es la identificación de las claves candidatas, una de las cuales será seleccionada como clave principal de la relación. Vamos a ilustrar la identificación de una clave principal de una relación dada en los siguientes dos ejemplos:
I
Ejemplo 13.7 Identificación
de la clave principal de la relación StaffBranch
En el Ejemplo 13.5 se describe la identificación de cinco dependencias funcionales para la relación StaffBranch mostrada en la Figura 13.3. Los determinantes de estas dependencias funcionales son staffNo, branchNo, bAddress, (branchNo, position) y (bAddress, position). Para identificar las claves candidatas de la relación StaffBranch,debemos identificar el atributo (o grupo de atributos) que identifique unívocamente cada tupla de esta relación. Si una relación tiene más de una clave candidata, identificamos la clave candidata que tenga que actuar como clave principal de la relación (véase la Sección 3.2.5). Todos los atributos que no formen parte de la clave principal deben depender funcionalmente de la clave. La única clave candidata de la relación StaffBranch,y por tanto la clave principal, es staffNo,ya que todos los demás atributos de la relación dependen funcionalmente de staffNo. Aunque branchNo, bAddress, (branchNo, position) y (bAddress, position) son determinantes en esta relación, no son claves candidatas de la relación.
I
Ejemplo 13.8 Identificación
de la clave principal para la relación Sample
En el Ejemplo 13.6 hemos identificado cuatro dependencias funcionales para la relación Sample. Vamos a examinar el determinante de cada dependencia funcional para identificar las claves candidatas de la relación. Un determinante adecuado será aquel que determine funcionalmente los demás atributos de la relación. Los determinantes en la relación Sample son A, B, C y (A, B). Sin embargo, el único determinante que determina funcionalmente a todos los demás atributos de la relación es (A, B). En particular, A determina funcionalmente a C, B determina funcionalmente a O y (A, B) determina funcionalmente a E. En otras palabras, los atributos que forman el determinante (A, B) pueden determinar a todos los demás atributos de la relación, bien por separado (como A o B) o juntos (como A, B). Por tanto, vemos que una característica esencial de una clave candidata de una relación es que los atributos de un determinante puedan determinar funcionalmente (individualmente o todos juntos) a todos los demás atributos de la relación. Esta característica no la cumplen los demás determinantes de la relación Sample (es decir, A, B o c) ya que en cada caso determinan uno solo de los atributos restantes de la re la-
Capítulo 13 Normalización ción. Puesto que no hay otras claves candidatas para la relación Sample, identificamos clave principal de esta relación.
365
(A, B) como
~
Hasta ahora, en esta sección, hemos analizado los tipos de dependencia funcional más útiles a la hora de identificar restricciones importantes en una relación y hemos visto cómo pueden usarse estas dependencias para identificar una clave principal (o claves candidatas) para una relación dada. Los conceptos de dependencias funcionales y claves son fundamentales para el proceso de normalización. Continuaremos con el análisis de las dependencias funcionales en el siguiente capítulo, para aquellos lectores a los que les interese un tratamiento más formal de este tema. Sin embargo, en este capítulo, vamos a proseguir con la descripción del proceso de normalización.
13.5. El proceso de normalización La normalización es una técnica formar para analizar relaciones basándose en su clave principal (o claves candidatas) y en las dependencias funcionales (Codd, 1972b). La técnica implica una serie de reglas que pueden utilizarse para probar relaciones individuales, de modo que una base de datos pueda normalizarse hasta cualquier grado deseado. Cuando un requisito no sea satisfecho, la relación que viole dicho requisito deberá ser descompuesta en una serie de relaciones que cumplan individualmente los requisitos de la normalización. Inicialmente se propusieron tres formas normales, denominadas primera forma normal (First Normal Form, lNF), segunda forma normal (2NF) y tercera forma normal (3NF). Posteriormente, R. Boyce y E.F. Codd introdujeron una definición más fuerte de tercera forma normal, denominada forma normal de Boyce-Codd (BCNF) (Codd, 1974). Con la excepción de la forma lNF, todas estas formas normales están basadas en dependencias funcionales entre los atributos de una relación (Maier, 1983). Otras formas normales, que van más allá de la forma BCNF, fueron introducidas posteriormente, como la cuarta forma normal (4NF) y la quinta forma normal (5NF) (Fagin, 1977, 1979). Sin embargo, estas formas normales posteriores tratan con situaciones que son bastante raras. En este capítulo se describen solamente las tres primeras formas normales, dejando el análisis de las formas BCNF, 4NF y 5NF para el siguiente capítulo. El proceso de normalización se suele ejecutar como una serie de pasos. Cada paso corresponde a una forma normal específica, que tiene propiedades conocidas. A medida que avanza el proceso de normalización, las relaciones tienen un formato cada vez más restringido (más fuerte) y son menos vulnerables a las anomalías de actualización. Para el modelo de datos relacional, es importante tener en cuenta que la única forma crítica a la hora de crear relaciones es la primera forma normal (lNF); todas las demás formas normales son opcionales. Sin embargo, para evitar las anomalías de actualización analizadas en la Sección 13.3, resulta recomendable en general continuar con el proceso hasta alcanzar al menos la tercera forma normal (3NF). La Figura 13.7 ilustra la relación entre las diversas formas normales, mostrando que algunas relaciones lNF están también en forma 2NF y que algunas relaciones 2NF están también en forma 3NF, etc.
Figura 13.7.
Diagrama que ilustra la relación entre las formas normales.
366
Sistemas de bases de datos
En las siguientes secciones se describe el proceso de normalización en detalle. La Figura 13.8 proporciona una panorámica del proceso y resalta las principales acciones que se llevan a cabo en cada paso del mismo. También se muestra en la figura el número de la sección donde se explica dicho paso del proceso. En este capítulo, se describe la normalización como una técnica de abajo a arriba que extrae la información acerca de los atributos a partir de una serie de formularios de ejemplo que primero se transforman a formato de tabla, del cual se dice que está en forma no normalizada (Unnormalized Form, UNF). Después, se somete progresivamente esta tabla a las pruebas de los diferentes requisitos asociados con cada forma normal, hasta que los atributos mostrados en los formularios de ejemplo originales están representados como un conjunto de relaciones 3NF. Aunque el ejemplo utilizado en este capítulo pasa de cada forma normal dada a la siguiente de orden superior, esto no tiene por qué ser así con otros ejemplos. Como se muestra en la Figura 13.8, la resolución de un problema concreto con una relación lNF podría resultar, por ejemplo, en que la relación se transformara en una serie de relaciones 2NF o, en algunos casos, directamente en una serie de relaciones 3NF en un solo paso. Para simplificar la descripción del proceso de normalización, vamos a asumir que se nos da un conjunto de dependencias funcionales para cada relación y que cada relación tiene una clave principal designada. En otras palabras, es esencial que se comprenda perfectamente el significado de los atributos y de sus relaciones antes de comenzar con el proceso de normalización. Esta información es fundamental para el proceso y se utiFuentes de datos
Formularios/informes utilizadoso generadospor la organización(comose describeen estecapituio y en el siguiente)
Usuarios
Transferir los atributos a formatos de tabla
Fuentes que describen la organización, como el diccionario de datos y el modelo de datos corporativ
(Descrito en la Sección 13.6)
Forma no normalizada (UNF)
Eliminación de grupos repetidos
(Descrito en la Sección 13.6)
Primera forma normal (1NF)
E/iminación de dependencias parcia/es
(Descrito en la Sección 13.7
Segunda forma normal (2NF)
E/iminación de dependencias transitivas
(Descrito en la Sección 13.8)
Tercera forma normal (3NF)
Figura 13.8.
Diagrama que ilustra el proceso de normalización.
Capítulo 13 Normalización
367
liza para comprobar si cada relación concreta está en una forma normal determinada. En la Sección 13.6 comenzamos describiendo la primera forma normal (lNF). En las Secciones 13.7 y 13.8 se describen la segunda forma normal (2NF) y la tercera forma normal (3NF) basándose en la clave principal de una relación, y luego se presenta una definición más general de cada una de estas formas normales en a Sección 13.9. Las definiciones más generales de las formas 2NF y 3NF toman en consideración todas las claves candidatas de una relación, en lugar de únicamente la clave principal.
13.6 Primera forma normal (1NF) Antes de analizar la primera forma normal, vamos a definir cuál es el estado anterior a dicha primera forma normal. Forma no normalizada (UNF)
Una tabla que contiene uno o más grupos repetitivos.
Primera forma nor-
Una relación en la que la intersección de toda fila y columna contiene un valor y sólo un valor.
mal (1NF)
En este capítulo, comenzamos el proceso de normalización transfiriendo primero los datos desde el material fuente (por ejemplo, un formulario estándar de introducción de datos) a formato de tabla, con filas y columnas. En este formato, la tabla está en forma no normalizada, denominándosela tabla no normalizada. Para transformar la tabla no normalizada a primera forma normal, tenemos que identificar y eliminar los grupos repetitivo s dentro de la tabla. Un grupo repetitivo es un atributo, o grupo de atributos, dentro de una tabla que presentan múltiples valores para un mismo valor de los atributos designados como clave principal de esa tabla. Observe que, en este contexto, el termino 'clave' hace referencia al atributo o atributos que identifican unívocamente cada fila de la tabla no normalizada. Hay dos técnicas principales para eliminar los grupos repetitivos de las tablas no normalizadas: (1) Introduciendo datos apropiados en las columnas vacías de las filas que contienen los datos repetitivos. En otras palabras, llenamos los blancos duplicando los datos no repetitivos siempre que sea necesario. Esta técnica se suele denominar 'aplanamiento' de la tabla. (2) Colocando los datos repetitivos, junto con una copia de los atributos clave originales en una relación independiente. Algunas veces la tabla no normalizada puede contener más de un grupo repetitivo o puede contener grupos repetitivo s dentro de otros grupos repetitivos. En tales casos, se aplica esta técnica de forma sucesiva hasta que no quede ningún grupo repetitivo. Un conjunto de relaciones está en la forma lNF si no contiene ningún grupo repetitivo. Para ambas técnicas, las tablas resultantes se denominarán relaciones lNF que contienen valores atómicos (o simples) en la intersección de cada fila y columna. Aunque ambas técnicas son correctas, la primera de ellas introduce más redundancia en la tabla UNF original, como parte del proceso de 'aplanamiento', mientras que la técnica 2 crea dos o más relaciones con menos redundancia que en la tabla lNF original. En otras palabras, la técnica 2 transforma la tabla INF originalllevándola más adelante en el proceso de normalización que la técnica l. Sin embargo, independientemente de cuál técnica inicial se adopte, la tabla UNF original terminará por ser normalizada en el mismo conjunto de relaciones 3NF. Vamos a ilustrar ambas ,técnicas en el siguiente ejemplo, utilizando el caso de estudio de DreamHome.
I
Ejemplo
13.9
Primera
forma
normal
(1 NF)
En la Figura 13.9 se muestra una colección de contratos de arrendamiento (simplificados) de DreamHome. El primero de los contratos es para un cliente llamada John Kay que está alquilando un
368
Sistemas de bases de datos
mpleto (introducir si se er
-
reamHome
-
350 Número de inmueble C040 31/08/04 PG4 01/07/03 conoce) CR76 Dirección del inmueble I Tina (introducir) Murphy John Kay Número de propietario 6 Lawrence Sto Glasgow Contrato de alquiler de DreamHome Número de cliente Alquiler mensual conoce) Contrato de alquiler de DreamHome Nombre completo
Contrato de alquiler de DreamHome
Figura 13.9.
Colección de contratos de alquiler (simplificados) de DreamHome.
inmueble en Glasgow, cuya propietaria se llama Tina Murphy. Para este ejemplo, vamos a suponer que un cliente alquila un inmueble determinado una única vez y que no puede alquilar más de un inmueble en cada instante determinado. Tomamos datos de ejemplo de dos contratos para dos clientes diferentes llamados John Kay y Aline Stewart y transformamos los datos al formato de tabla con filas y columnas, como se muestra en la Figura 13.10. Este es un ejemplo de tabla no normalizada. Identificamos c1ientNo como atributo clave para la tabla no normalizada ClientRental. A continuación, identificamos el grupo repetitivo en la tabla no normalizada como el formado por los detalles del inmueble alquilado, que se repiten para cada cliente. La estructura del grupo repetitivo es Grupo repetitivo = (propertyNo,
pAddress,
rentStart, rentFinish,
rent, ownerNo,
oName)
Como consecuencia, hay múltiples valores en la intersección de ciertas filas y columnas. Por ejemplo, hay dos valores para los inmuebles con número propertyNo (PG4 y PG 16) para el cliente llamado ClientRental clientNoC040 350 C093 l-Nov-05 1-0ec-04 PG4 Aline 350 375 1O-0ct-03 ownerNo cName rentFinish oName rent 450 1O-)une-03 6 2 LawrenceSt, Manor Rd, )ohn Hul-03 5rentStart Novar IO-Aug-06 TonyShaw propertyNo Tina pAddress 1-Sep-02 Murphy Glasgow I-Sep-05 Tony I-Sep-04 ShawOr, 31-Aug-04 PG36 PG16
Figura 13.10.
Tabla no normalizada ClientRental.
Capítulo 13 Normalización
369
John Kay. Para transformar una tabla en una normalizada a la forma lNF, tenemos que garantizar que haya un único valor en la intersección de cada fila y columna. Esto se consigue eliminando el grupo repetitivo. Con la primera de las dos técnicas mencionadas anteriormente eliminamos el grupo repetitivo (los detalles del inmueble alquilado) introduciendo los apropiados datos del cliente en cada fila. La relación ClientRental resultante en primera forma normal se muestra en la Figura 13.ll. En la Figura 13.12 se presentan las dependencias funcionales (fdl a fd6) para la relación ClientRental. Usamos las dependencias funcionales (como se explica en la Sección 13.4.3) para identificar las claves candidatas de la relación ClientRental, que serán claves compuestas formadas por los atributos (clientNo, propertyNo), (clientNo, rentStart) y (propertyNo, rentStart). Seleccionamos (clientNo, propertyNo) como clave principal de la relación y situamos por claridad los atributos que forman la clave principal juntos en el lado izquierdo de la relación. En este ejemplo, asumimos que el atributo rentFinish no resulta apropiado como componente de una clave candidata ya que puede contener valores nulos (véase la Sección 3.3.1). La relación ClientRental se define como sigue: ClientRental
(c1ientNo, orooertyNo,
cName, pAddress, rentStart, rentFinish,
rent, ownerNo,
oName)
La relación ClientRental está en la forma lNF, ya que hay un único valor en la intersección de cada fila y columna. La relación contiene datos que describen a los clientes, los inmuebles alquilados y los propietarios de los inmuebles, datos que se repiten varias veces. Como resultado, la relación ClientRental contiene una redundancia significativa en los datos. Si se implementara, esta relación lNF estaría sujeta a las anomalías de actualización descritas en la Sección 13.3. Para eliminar algunas de estas anomalías, debemos transformar la relación a segunda forma normal, como explicaremos en breve. Con la segunda de las técnicas, eliminamos el grupo repetitivo (detalles sobre los inmuebles alquilados) situando los datos repetitivo s en una relación separada, junto con una copia del atributo clave original (c1ientNo), como se muestra en la Figura 13.3. Con la ayuda de las dependencias funcionales identificadas en la Figura 13.12, podemos identificar una clave principal para las relaciones. El formato de las relaciones lNF resultantes es el siguiente: Client
(c1ientNo, cName)
PropertyRentalOwner
(c1ientNo, orooertyNo,
pAddress, rentStart, rentFinish,
rent, ownerNo, oName)
Las relaciones Client y PropertyRentalOwner están ambas en forma lNF, ya que hay un único valor en la intersección de cada fila y columna. La relación Client contiene datos que describen a los clientes y la relación PropertyRentalOwner contiene datos que describen los inmuebles alquilados por los clientes y también los propietarios de los inmuebles. Sin embargo, como vemos en la Figura 13.13, esta relación también contiene algo de redundancia, por lo que también puede sufrir de anomalías de actualización similares a las descritas en la Sección 13.3. ClientRental clientNoownerNo C093 450 A line PG36 375 l-Nov-05 PGl6 l-Dec-04 1O-Oct-03 C040 PG4 350 rent Aline cName rentFinish oName John rentStart l-jui-03 John Novar Dr, St, ManorRd, 652pAddress Lawrence 1O-]un-03 lO-Aug-06 TonyShaw Glasgow l-Sep-04 propertyNo 3l-Aug-04 Tina l-Sep-05 Murphy l-Sep-02
Figura 13.11.
Relación ClientRental
en primera forma normal.
370
Sistemas de bases de datos
ClientRental
fd1 I
t
I
t
fd21
(Dependencia
t
(Clave
parcial)
t
lsJ3l~
principal)
t--.-t •
J (Dependencia parcial)
------------
fd4 I
fdSI __
fd6
t
1
t I
t
Figura 13.12.
~(Clave candidata)
I
Dependencias
t transltlva) (Dependencia
funcionales
t
(Clave
candidata)
de la relación ClientRental.
Client c1ientNo
cName A1ine Stewart john Kay
CRS6 CR76
PropertyRentalOwner clientNo C093 ownerNo PGl6 350 PG36 375 10-Oet-03 rentFinish oName rent rentStart 450 C040PG4 l-Oee-04 l-Nov-OS l-jul-03 1O-jun-03 1O-Aug-06 3l-Aug-04 6pAddress St, l-Sep-OS 5 Novar l-Sep-04 Tina MurphyOr, l-Sep-02 Glasgow TonyShaw 2 Lawrenee Manor Rd, Glasgow Glasgow propertyNo
Figura 13.13.
Relaciones 1NF alternativas Client y PropertyRentalOwner.
Para ilustrar el proceso de normalizar relaciones pasándolas de forma lNF a 2NF, vamos a usar únicamente la relación ClientRental mostrada en la Figura 13.11. Sin embargo, recuerde que ambas técnicas son correctas y que al final dan como resultado la producción de las mismas relaciones a medida que continuemos con el proceso de normalización. Dejamos el proceso de completar la normalización de como ejercicio para el lector, como se enuncia al final de este las relaciones Client y PropertyRentalOwner capítulo.
13.7 Segunda forma normal (2NF) La segunda forma normal (2NF) está basada en el concepto de dependencia funcional completa, que hemos descrito en la Sección 13.4. La segunda forma normal se aplica a las relaciones con claves compuestas, es decir, relaciones con una clave principal compuesta de dos o más atributos. Una relación con una clave principal de un único atributo está automáticamente en forma 2NF, al menos. Una relación que no esté en forma 2NF puede sufrir las anomalías de actualizaciones que se explican en la Sección 13.3. Por ejemplo, suponga
Capítulo 13 Normalización
371
que queremos modificar el alquiler del inmueble número PG4. Tendremos que actualizar dos tuplas en la relación ClientRental que se muestra en la Figura 13.ll. Si sólo se actualizara una de las tuplas con el nuevo valor del alquiler, éste daría como resultado una incoherencia en la base de datos. Segunda forma
Una reacción que está en primera forma normal y en la que todo atributo que no sea de clave principal depende funcional mente de manera completa de la clave principal.
nonnal :~
La normalización de las relaciones lNF para transformadas a la forma 2NF implica la eliminación de las dependencias parciales. Si existe una dependencia parcial, se eliminan de la relación los atributos parcialmente dependientes, situándolos en una nueva relación junto con una copia de su determinante. El siguiente ejemplo ilustra el proceso de conversión de relaciones lNF en relaciones 2NF.
I
Ejemplo 13.10 Segunda
forma
normal
(2NF)
Como se muestra en la Figura 13.12, la relación cionales: fdl fd2 fd3 fd4 fd5
elientNo, propertyNo c1ientNo
rentStart, rentFinish
-7 eName -7 pAddress, rent, ownerNo, oName
propertyNo ownerNo
-7
oName
c1ientNo, rentStart rentFinish,
fd6
-7
ClientRental
-7 propertyNo,
rentStart
fun-
(Clave primaria) (Dependencia parcial) (Dependencia parcial) (Dependencia transitiva)
pAddress,
rent, ownerNo, oName
propertyNo,
tiene las siguientes dependencias
-7 c1ientNo,
eN ame, rentFinish
(Clave candidata) (Clave candidata)
Utilizando estas dependencias funcionales, continuamos con el proceso de normalización de la relación ClientRental. Comenzamos comprobando si la relación ClientRental está en forma 2NF, identificando la presencia de dependencias parciales en la clave principal. Observamos que el atributo de cliente (eName) depende parcialmente de la clave principal; en otras palabras, depende sólo del atributo elientNo (lo que está representado como fd2). Los atributos de inmueble (pAddress, rent, ownerNo, oName) dependen parcialmente de la clave principal, es decir, dependen sólo del atributo propertyNo (lo que está representado como fd3). Los atributos del inmueble (rentStart y rentFinish) depende de modo completo de la clave principal, es decir, de los atributos elientNo y propertyNo (lo que está representado como fdl). La identificación de dependencias parciales en la relación ClientRental indica que la relación no se encuentra en forma 2NF. Para transformar la relación ClientRental en una relación 2NF necesitamos crear nuevas relaciones de modo que se eliminen los atributos que no sean de clave principal, situándolos en otra relación junto con una copia de aquella parte de la clave principal de la que dependan funcionalmente de modo completo. Esto da como resultado la creación de tres nuevas relaciones denominadas Client, Rental y PropertyOwner, como se muestra en la Figura 13.14. Estas tres relaciones están en segunda forma normal, ya que todo atributo que no es de clave principal depende funcionalmente de modo completo de la clave principal de la relación. Las relaciones tienen la siguiente forma: Client
(c1ientNo, eName)
Rental
(c1ientNo, propertyNo,
PropertyOwner
(propertvNo,
rentStart, rentFinish)
pAddress, rent, ownerNo, oName)
372
Sistemas de bases de datos
13.8 Tercera forma normal (3NF) Aunque las relaciones 2NF tienen menos redundancia que las que están en forma INF, pueden seguir sufriendo de anomalías de actualización. Por ejemplo, si queremos actualizar el nombre de un propietario, como pueda ser Tony Shaw (ownerNo C093), tenemos que actualizar dos tuplas en la relación PropertyOwner de la Figura 13.14. Si actualizamos una sola tupla y no la otra, la base de datos estará en un estado incoherente. Esta anomalía de acrnali-zación está causada por una dependencia transitiva, concepto que hemos descrito en la Sección 13.4. Necesitamos eliminar dichas dependencias realizando la transformación a la tercera forma normal. Tercera forma
Una relación que está en primera y segunda formas normales y en la que ningún atributo que no sea de clave principal depende transitivamente de la clave principal.
normal (3NF)
La normalización de las relaciones 2NF para pasarlas a forma 3NF implica la eliminación de las dependencias transitivas. Si existe una dependencia transitiva, eliminamos de la relación los atributos que dependen transitivamente, situándolos en una nueva relación junto con una copia del determinante. En el siguiente ejemplo se ilustra el proceso de conversión de relaciones 2NF en relaciones 3NF. Rental
Client clientNo
c1ientNo
Aline Slewarl cName John Kay
PG4 PG36 10-Oel-03 I-Nov-OS PGI6 PG16 rentFinish l-Dee-04 rentStart I-Jul-03 10-Jun-03 I-Sep-02 IO-Aug-06 31-Aug-04 I-Sep-OS I-Sep-04 propertyNo
CR76 CRS6 CRS6 CR76 CR76
PropertyOwner C093 C040 ownerNo oName 375 450 rent 350 propertyNo TonyShaw Tina 2 5 6 pAddress Manor Novar LawreneeSI, Murphy Dr, Rd,Glasgow Glasgow Glasgow
Figura 13.14.
I
Relaciones en segunda forma normal derivadas de la relación ClientRental.
Ejemplo 13.11 Tercera
forma
normal
(3NF)
Las dependencias funcionales para las relaciones 3.10, son las siguientes:
Client, Rental
y
PropertyOwner,
Client
fd2
clientNo ~ cName
(Clave principal)
Rental
fdI
clientNo, propertyNo
fd5' fd6'
clientNo, rentStart ~ propertyNo, propertyNo,
~ rentStart, rentFinish rentFinish
rentStart ~ clientNo, rentFinish
(Clave principal) (Clave candidata) (Clave candidata)
derivadas en el Ejemplo
Capítulo 13 Normalización
373
ProoertvOwner
fd3 fd4
propertyNo ~ pAddress, ownerNo ~ oName
rent, ownerNo,
oName
(Clave principal) (Dependencia transitiva)
Todos los atributos que no son de clave principal dentro de las relaciones Client y Rental dependen funcionalmente tan sólo de sus respectivas claves primarias. Las relaciones Client y Rental no tienen dependencias transitivas y están ya por tanto en forma 3NF. Observe que cuando una dependencia funcional esta etiquetada con una prima (como por ejemplo fd5'), esto indica que la dependencia se ha modificado con respecto a la dependencia funcional original mostrada en la Figura 13.12. Todos los atributos que no son de clave principal dentro de la relación PropertyOwner dependen funcionalmente de la clave principal, con la excepción de oName, que depende transitivamente de ownerNo (lo que se representa como fd4). Esta dependencia transitiva ya fue previamente identificada en la Figura 13.12. Para transformar la relación PropertyOwner a forma 3NF, debemos primero eliminar la dependencia transitiva creando dos nuevas relaciones denominadas PropertyForRent y Owner, como se muestra en la Figura 13.15. Las nuevas relaciones tienen la estructura: PropertyForRent
(orooertyNo,
Owner
(ownerNo,oName)
pAddress, rent, ownerNo)
Las relaciones PropertyForRent y Owner están en forma 3NF, ya que no hay más dependencias transitivas con respecto a la clave principal. Owner
PropertyForRent
ownerNo
C093 C040 ownerNo256pAddress 450 350 rent propertyNo 375 Manor Novar Lawrence Dr, Rd, St, Glasgow Glasgow Glasgow
oName Tony Tina Murphy Shaw
C093 C040
Figura 13.15.
Relaciones en tercera forma normal derivadas de la relación PropertyOwner.
~ La relación ClientRental mostrada en la Figura 13.11 ha sido transformada por el proceso de normalización en cuatro relaciones en forma 3NF. La Figura 13.16 ilustra el proceso mediante el que se ha descompuesto la relación lNF original en relaciones 3NF. Las relaciones 3NF resultantes tienen la estructura: Client
(elientNo, eName)
Rental
(elientNo, propertyNo,
PropertyForRent
(propertyNo,
Owner
(ownerNo,oName)
rentStart, rentFinish)
pAddress, rent, ownerNo)
La relación ClientRental original mostrada en la Figura 13.11 puede volver a crearse combinando las relaciones Client, Rental, PropertyForRent y Owner mediante el mecanismo de clave principal/clave externa. Por ejemplo, el atributo ownerNo es una clave principal en la relación Owner y también está presente como clave externa en la relación PropertyForRent. El atributo ownerNo que actúa como clave principal/clave externa permite la asociación de las relaciones PropertyForRent y Owner para identificar el nombre de los propietarios de los inmuebles. El atributo elientNo es una clave principal de la relación Client y también está presente como clave externa en la relación Renta!. Observe en este caso que el atributo elientNo en la relación Rental actúa tanto como clave externa cuanto como parte de la clave principal de esta relación. De forma similar, el atributo propertyNo es la clave principal de la relación PropertyForRent y también está presente en la relación Rental actuando tanto como clave externa cuanto como parte de la clave principal de esta relación.
374
Sistemas de bases de datos
ClientRental
n PropertyOwner
Client
Figura 13.16.
La descomposición
Rental
PropertyForRent
Owner
de la relación 1NF ClientRental
1NF
2NF
3NF
1NF en las relaciones 3NF.
En otras palabras, el proceso de normalización ha descompuesto la relación ClientRental original utilizando una serie de proyecciones del álgebra relacional (véase la Sección 4.1). Esto da como resultado una descomposición basada en combinación sin pérdidas (también denominada combinación no aditiva), que es reversible utilizando la operación de combinación natural. En la Figura 13.17 se muestran las relaciones Client, Rental, PropertyForRent
y Owner.
13.9 Definiciones generales de las formas 2NF y 3NF Las definiciones de las formas 2NF y 3NF dadas en las Secciones 13.7 y 13.8 prohiben la existencia de dependencias parciales o transitivas con respecto a la clave principal de las relaciones, con el fin de evitar las anomalías de actualización descritas en la Sección 13.3. Sin embargo, estas definiciones no toman en consideración otras claves candidatas de una relación, si es que existe alguna. En esta sección, presentamos definiciones más generales de las formas 2NF y 3NF que toman en consideración las claves candidatas de una relación. Observe que este requisito no altera la definición para la forma lNF, ya que esta forma normal es independiente de las claves y de las dependencias funcionales. Para las definiciones generales, definimos el concepto de atributo de clave candidata como todo atributo que forme parte de una clave candidata y definimos las dependencias parcial, total y transitiva con respecto a todas las claves candidatas de una relación. Segunda forma normal (2NF)
Una relación que está en primera forma normal y en la que todo atributo que no sea de clave candidata depende funcional mente de modo completo de cualquier clave candidata. Client
Rental
c1ientNo
Aline Kay Stewart cName John
c1ientNo
PGI6 I-Nov-Os PG4 PG36 I-Dec-04 1O-0ct-03 rentFinish rentStart 1O-)un-03 I-Jul-03 IO-Aug-06 I-Sep-02 propertyNo l-Sep-Os I-Sep-04 31-Aug-04
CRs6 CRs6 CR76 CR76 CR76
Owner
PropertyForRent C040 ownerNopAddress rent 350 C093 450 375 propertyNo 6 25 LawrenceSt,Glasgow Manor Novar Dr, Rd, Glasgow Glasgow
6 36 4
ownerNo
oName Tina TonyShaw Murphy
C093 C040
Figura 13.17.
Un resumen de las relaciones 3NF derivadas de la relación ClientRental.
Capítulo 13 Normalización Tercera
forma
normal (3NF)
375
Una relación que se encuentra en primera y segunda formas normales y en la que ningún atributo que no sea de clave candidata depende transitivamente de ninguna clave candidata.
Cuando se usan las definiciones generales de las formas 2NF y 3NF, es preciso ser consciente de las dependencias parciales y transitivas con respecto a todas las claves candidatas, y no sólo con respecto a la clave principal. Esto puede hacer más complejo el proceso de normalización, pero las definiciones generales imponen restricciones adicionales a las relaciones y pueden identificar redundancias ocultas en las relaciones que de otro modo podrían pasar desapercibidas. El compromiso al que hay que hacer frente es si resulta mejor mantener la simplicidad del proceso de normalización examinando únicamente las dependencias con respecto a las claves principales, lo que permite la identificación de las redundancias más problemáticas y obvias en las relaciones, o si es mejor usar las definiciones generales e incrementar la probabilidad de identificar redundancias que de otro modo podrían no percibirse. De hecho, a menudo sucede que, independientemente de si usamos las definiciones basadas en las claves principales o las definiciones generales de las formas 2NF y 3NF, la descomposición de las relaciones es la misma. Por ejemplo, si aplicamos las definiciones generales de las formas 2NF y 3NF a los Ejemplos 13.10 y 13.11 descritos en las Secciones 13.7 y 13.8, resulta la misma descomposición de las relaciones mayores en relaciones de menor tamaño. El lector interesado puede verificar por su cuenta este resultado. En el siguiente capítulo volveremos a examinar el proceso de identificación de las dependencias funcionales que resultan útiles para el proceso de normalización y llevaremos a este proceso un paso más allá exponiendo las formas normales más avanzadas que la forma 3NF, como por ejemplo la forma normal de Boyce-Codd (BCNF). Asimismo, en dicho capítulo presentaremos un segundo ejemplo resuelto tomado del caso de estudio DreamHome donde se revisa el proceso de normalización desde la forma UNF hasta la BCNF.
Resumen del capítulo •
La normalización es una técnica para generar un conjunto de relaciones con una serie de propiedades deseables, dados los requisitos de datos de una organización. La normalización es un método formal que . puede utilizarse para identificar relaciones basándose en sus claves y en las dependencias funcionales existentes entre sus atributos.
•
Las relaciones con redundancia en los datos sufren de anomalías se como anomalías de inserción, de borrado y de modificación.
de actualización,
que pueden clasificar-
•
Uno de los conceptos principales asociados con describe la relación entre atributos de una tabla. dependerá funcionalmente de A (lo que se denota te un valor de B. (A Y B pueden estar compuestos,
•
El determinante de una dependencia funcional es el atributo o grupo de atributos situado del lado izquierdo de la flecha que describe la dependencia.
•
Las características principales de las dependencias funcionales que utilizamos para la normalización son que dichas dependencias presentan una relación uno a uno entre los atributos del lado izquierdo y los del lado derecho de la dependencia; que dichas dependencias se cumplen para todo instante de tiempo; y que se trata de dependencias funcionales completas.
•
Una tabla en forma no normalizada grupos repetitivos.
•
Una relación en primera forma normal (First Normal Form, lNF) es una relación en la que la intersección de cada fila y colunma contiene un valor y sólo uno.
•
Una relación en segunda forma normal (2NF) es una relación que está en primera forma normal y en la que todo atributo que no sea de clave principal depende funcionalmente de modo completo de la clave principal. La dependencia funcional completa indica que si A y B son atributos de una relación, B depen-
la normalización es el de dependencia funcional, que Por ejemplo, si A y B son atributos de la relación R, B A -7 B) si cada valor de A está asociado con exactamencada uno de ellos, por uno o más atributos).
(Unnormalized
Form, UNF) es una tabla que contiene uno o más
376
Sistemas de bases de datos
de funcionalmente de modo completo de junto propio de A.
A
si B depende funcionalmente
de A pero no de ningún sub con-
•
Una relación en tercera forma normal (3NF) es una relación que está en primera y segunda formas normales y en la que ningún atributo que no sea de clave principal depende transitivamente de la clave principal. La dependencia transitiva es una condición en la que A, B Y C son atributos de una relación tales que si A -.¿ By B -.¿ C, entonces C depende transitivamente de A a través de B (supuesto que A no dependa funcionalmente de B o c).
•
La definición general de la segunda forma normal (2NF) indica que se trata de una relación que se encuentra en primera forma normal y en la que todo atributo que no sea de clave candidata depende funcionalmente de modo completo de cualquier clave candidata. En esta definición, los atributos de clave candidata son los atributos que forman parte de alguna clave candidata.
•
La definición general encuentra en primera y candidata que dependa clave candidata son los
de la tercera forma normal (3NF) indica que se trata de una relación que se segunda formas normales y en la que no hay ningún atributo que no sea de clave transitivamente de alguna clave candidata. En esta definición, los atributos de que forman parte de alguna clave candidata.
Cuestiones de repaso 13.1.
Describa el propósito del proceso de normalización de los datos.
13.2.
Explique las formas alternativas en que puede usarse la normalización como ayuda al diseño de una base de datos.
13.3.
Describa los tipos de anomalías de actualización tenga datos redundantes.
13.4.
Describa el concepto de dependencia funcional.
13.5.
¿Cuáles son las características principales de las dependencias funcionales que se utilizan para la normalización?
13.6.
Describa cómo identifica normalmente un diseñador de base de datos el conjunto de dependencias funcionales asociadas con una relación.
13.7.
Describa las características de una tabla en forma no normalizada (UNF, Unnormalized Form) y describa cómo puede convertirse dicha tabla en una relación en primera forma normal (1NF).
13.8.
¿Cuál es la mínima forma normal que una relación debe satisfacer? Proporcione una definición para dicha forma normal.
13.9.
Describa las dos técnicas existentes para convertir una tabla en forma no normalizada (UNF) en una relación o relaciones en primera forma normal (lNF).
que puede introducirse en una normalización
que
13.10. Describa el concepto de dependencia funcional completa e indique cómo se relaciona este concepto con la forma 2NF. Proporcione un ejemplo para ilustrar su respuesta. 13.11. Describa el concepto de dependencia transitiva e indique cómo se relaciona este concepto con la forma 3NF. Proporcione un ejemplo para ilustrar su respuesta. 13.12. Explique cómo difieren las definiciones de las formas 2NF y 3NF basadas en las claves principales de las definiciones generales de formas 2NF y 3NF. Proporcione un ejemplo para ilustrar su respuesta.
Ejercicios 13.13. Continúe el proceso de normalización de las relaciones 1NF Client y PropertyRentalOwner mostradas en la Figura 13.13, hasta obtener relaciones 3NF. Al final del proceso, compruebe que las relaciones 3NF resultantes son iguales que las generadas a partir de la relación 1NF alternativa ClientRental mostrada en la Figura 13.16
Capítulo 13 Normalización
377
13.14. Examine el formulario de medicación de pacientes del caso de estudio del Wellmeadows Hospital mostrado en la Figura 13.18. (a)
Identifique las dependencias funcionales representadas por los atributos que se muestran en el formulario de la Figura 13.18. Indique las suposiciones que haga acerca de los datos y de los atributos mostrados en este formulario.
(b) Describa e ilustre el proceso de normalización de los atributos mostrados en la Figura 13.18 para producir un conjunto de relaciones 3NF bien diseñadas. (c)
Identifique las claves principales, alternativas y externas en sus relaciones 3NF.
13.15. La tabla mostrada en la Figura 13.19 enumera una serie de datos de ejemplo de citas de los pacientes con sus dentistas. A los pacientes se les da una cita en una fecha y hora especificadas con un dentista que trabaja en una clínica concreta. En cada día de citas con pacientes, a cada dentista se le asigna a una clínica específica. (a)
La tabla mostrada en la Figura 13.19 es susceptible a las anomalías de actualización. Proporcione ejemplos de anomalías de inserción, borrado y modificación.
(b)
Identifique las dependencias funcionales representadas por los atributos mostrados en la tabla de la Figura 13.19. Indique las suposiciones que haga acerca de los datos y de los atributos mostrados en esta tabla.
(c)
Describa e ilustre el proceso de normalización de la tabla mostrada en la Figura 13.19, hasta conseguir relaciones 3NF. Identifique las claves principales, alternativas y externas en sus relaciones 3NF.
13.16. Una agencia denominada Instant Cover proporciona personal a tiempo parcial/temporal a los hoteles situados en Escocia. La tabla mostrada en la Figura 13.20 muestra una serie de datos de ejemplo en los que se indica el tiempo empleado por el personal de la agencia trabajando en distintos hoteles. El número de la seguridad social (National Insurance Number, NIN) es único para cada empleado. (a)
La tabla mostrada en la Figura 13.20 es susceptible a las anomalías de actualización. Proporcione ejemplos de anomalías de inserción, borrado y modificación.
Hospital Wellmeadows Formulario de medicación de pacientes Número de paciente: Nombre completo: Número de cama:
Número
Robert MacDonald 84
Fecha Método inicio Fecha fin Killer de 10 Nombre Unidades Oral 24/03/04 25/04/05 elOmg/ml 17/04/04 10 Antibiotic IV 24/04/05 50 02/05/06 Pain Descripción por día Dosificaciór Morphine Tetracycle 0.5mg/ml
Figura 13.18.
P10034 Número de departamento:
Ward 11
Nombre del departamento:
OrthoEaedic
admin.
Formulario de medicación de pacientes del Hospital Wellmeadows.
378
Sistemas de bases de datos
staffNo SI3 SI5Robin 18.00 16.30 Plevin SlO 14.00 SI5Helen SI5 GillianWhite Robin P105 Helen P108 Pearson 10.00 12.00 dentistName time P100 John Walker JiUBel! lanMacKay JillBel! patName appointment 15-Sep-04 1P110 4-Sep-04 IanMacKay 14-Sep-04 12-Sep-04 TonySmith patNo surgeryNo date
Figura 13.19.
Tabla que muestra datos de ejemplo para citas de los pacientes con sus dentistas.
(b)
Identifique las dependencias funcionales representadas por los atributos mostrados en la tabla de la Figura 13.20. Indique las suposiciones que haga acerca de los datos y de los atributos mostrados en esta tabla.
(c)
Describa e ilustre el proceso de normalización de la tabla mostrada en la Figura 13.20, hasta conseguir relaciones 3NF. Identifique las claves principales, alternativas y externas en sus relaciones 3NF. NIN
CI024 16D CI025 Hocine hNo 28 24 contractNo hLoc East WhiteT eName Kilbride H4 H25 hours 15 SmithJ Glasgow
1135 1057 1068 1135
Figura 13.20.
Tabla que muestra datos de ejemplo para la agencia Instant Cover.
Capítulo
Normalización avanzada
Objetivos del capítulo: En este capítulo aprenderá: •
Cómo se puede identificar mediante reglas de inferencia el conjunto de todas las dependencias funcionales de una relación.
•
Cómo se puede identificar mediante una serie de reglas de inferencia denominadas axiomas de Armstrong un conjunto mínimo de dependencias funcionales útiles a partir del conjunto de todas las dependencias funcionales de una relación.
•
Formas normales que van más allá de la tercera formal normal (3NF), incluyendo la forma normal de Boyce-Codd (BCNF), la cuarta forma normal (4NF) y la quinta forma normal (5NF).
•
Cómo identificar la forma normal de Boyce-Codd
•
Cómo representar en forma de relaciones BCNF los atributos mostrados en un informe utilizando las técnicas de normalización.
•
El concepto de dependencias multivaluadas y de cuarta forma normal (4NF).
•
Los problemas asociados con las relaciones que no cumplen las reglas de la forma 4NF.
•
Cómo crear relaciones 4NF a partir de una relación que no cumpla las reglas de la cuarta forma normal.
•
El concepto de dependencia de combinación y de quinta forma normal (5NF).
•
Los problemas asociados con las relaciones que no cumplen las reglas de la quinta forma normal.
•
Cómo crear relaciones 5NF a partir de una relación que no cumpla las reglas de la quinta forma normal.
(BCNF).
En el capítulo anterior hemos introducido la técnica de la normalización y el concepto de dependencias funcionales entre los atributos. Allí describimos los beneficios de utilizar la normalización como ayuda durante el diseño de bases de datos y vimos cómo transformar los atributos mostrados en una serie de formularios de ejemplo, con el fin de obtener relaciones en primera forma normal (First Normal Form, INF), segunda forma normal (2NF) y, finalmente, tercera forma normal. En este capítulo, vamos a volver a analizar el tema de las dependencias funcionales y describiremos una serie de formas normales que van más allá de la tercera forma normal, como por ejemplo la forma normal de Boyce-Codd (BCNF), la cuarta forma normal (4NF) Y la quinta forma normal (5NF). Las relaciones en 3NF están normalmente lo suficientemente bien estructuradas como para evitar los problemas asociados con la redundancia de datos, que fueron descritos en la Sección 13.3. Sin embargo, se han creado una serie de formas normales más avanzadas para identificar una serie de problemas relativamente raros que afectan a las relacione y que, si no se corrigen, pueden dar como resultado una redundancia de los datos indeseable.
380
Sistemas de bases de datos
Estructura del capítulo Con la excepción de la primera forma normal, todas las formas normales analizadas en el capítulo anterior y en este se basan en dependencias funcionales entre los atributos de una relación. En la Sección 14.1 vamos a continuar con nuestro análisis del concepto de dependencia funcional que fue presentado en el capítulo anterior. Presentaremos un aspecto más formal y teórico de las dependencias funcionales, explicando las reglas de inferencia que se las pueden aplicar. En el capítulo anterior hemos descrito las tres formas normales más comúnmente utilizadas: lNF, 2NF Y 3NF. Sin embargo, R. Boyce y E.F. Codd identificaron una debilidad inherente a la tercera forma normal e introdujeron (Codd, 1974) una definición más fuerte de 3NF, denominada forma normal de Boyce-Codd (BCNF), que describiremos en la Sección 14.2. En la Sección 14.3 se representa un ejemplo resuelto para ilustrar el proceso de normalización de los atributos originalmente mostrados en un informe, hasta obtener un conjunto de relaciones BCNF. Posteriormente se introdujeron (Fagin, 1977, 1979) formas normales de orden superior que van más allá de la forma normal BCNF, como por ejemplo la cuarta forma normal (4NF) y la quinta forma normal (5NF). Sin embargo, estas últimas formas normales tratan con situaciones bastante infrecuentes. Describiremos la cuarta y la quinta formas normales en las Secciones 14.4 y 14.5. Para ilustrar el proceso de normalización, extraeremos una serie de ejemplos del caso de estudio de DreamHome descrito en la Sección 10.4 Y documentado en el Apéndice A.
14. 1 Más aspectos relativos a las dependencias funcionales Uno de los conceptos principales asociados con la normalización es el de dependencia funcional, que describe la relación existente entre atributos (Maier, 1983). En el capítulo anterior hemos presentado ya este concepto y en esta sección vamos a describirlo de una manera más normal y teórica, explicando las reglas de inferencia aplicables a las dependencias funcionales.
14.1.1 Reglas de inferencia para dependencias funcionales En la Sección 13.4 hemos identificado las características de las dependencias funcionales que más útiles resultan en el proceso de normalización. Sin embargo, aún cuando restrinjamos nuestra atención a las dependencias funcionales con una relación uno a uno (1: 1) entre los atributos que se cumpla en todo momento y tal que la dependencia funcional sea completa, el conjunto de todas las dependencias funcionales para una relación dada puede seguir teniendo un gran tamaño. Es importante encontrar una técnica que nos permita reducir dicho conjunto a un tamaño manejable. Idealmente, lo que queremos es identificar un conjunto de independencias funcionales (representado como x) para una relación que sea más pequeño que el conjunto completo de dependencias funcionales (representado como Y) de esa relación y que tenga la propiedad de que toda dependencia funcional en Y esté implícita en las dependencias funcionales contenidas en x. Es decir, que si imponemos las restricciones de integridad definidas por las dependencias funcionales de x, estaremos imponiendo automáticamente las restricciones de integridad definidas en el conjunto de dependencias funcionales Y, que es de un tamaño mayor. Este requisito sugiere que debe haber dependencias funcionales que puedan inferirse a partir de otras dependencias funcionales. Por ejemplo, las dependencias funcionales A ---7 B Y B ---7 e en una relación implican que la dependencia funcional A ---7 e también se cumple para dicha relación. A ---7 e es un ejemplo de dependencia funcional transitiva, que es un tipo de dependencia funcional del que ya hemos hablado en las Secciones 13.4. y 13.7. ¿Cómo podemos identificar cuáles son las dependencias funcionales útiles dentro de una relación? Normalmente, el diseñador de bases de datos comienza especificando dependencias funcionales que sean semánticamente obvias; sin embargo, usualmente existen numerosas otras dependencias funcionales. De hecho, la tarea de especificar todas las dependencias funcionales posibles en los proyectos 'reales' de bases
Capítulo 14 Normalización avanzada
381
de datos suele ser muy a menudo imposible de abordar. Sin embargo, en esta sección vamos a presentar una técnica que ayuda a identificar el conjunto completo de dependencias funcionales de una relación y luego explicaremos cómo obtener un conjunto mínimo de dependencias funcionales que pueda representar el conjunto completo. El conjunto de todas las dependencias funcionales que pueden derivarse a partir de un conjunto dado de dependencias funcionales X se denomina cierre de X, lo que se escribe como x+. Lo que necesitamos es un conjunto de reglas que nos ayude a calcular x+ a partir de X. Un conjunto de reglas de inferencia, denominadas Axiomas de Armstrong, especifica cómo inferir nuevas dependencias funcionales a partir de otras dadas (Armstrong, 1974). Para nuestra explicación, sean A, B y subconjuntos de los atributos de la relación R. Los Axiomas de Armstrong son los siguientes:
e
(1) Retlexividad:
Si B es un subconjunto de A, entonces A -7 B
(2) Aumentación:
Si A -7 B, entonces A,C -7 B,C
(3) Transitividad:
Si
A -7 B Y B -7
e, entonces
A -7
e
Observe que cada una de estas tres reglas puede demostrarse directamente a partir de la definición de dependencia funcional. Estas reglas son completas en el sentido de que dado un conjunto X de dependencias funcionales, todas las dependencias funcionales derivables de X pueden deducirse a partir de X utilizando estas reglas. Las reglas también son adecuadas, en el sentido de que no puede deducirse ninguna otra dependencia funcional que no sea derivable a partir de X. En otras palabras, estas reglas pueden utilizarse para hallar el cierre de x+. Podemos derivar diversas otras reglas a partir de las tres enunciadas con el fin de simplificar la tarea práctica de calcular x+. En las reglas siguientes, sea D otro subconjunto de los atributos de la relación R; entonces: (4) Autodeterminación:
A -7 A
(5) Descomposición:
Si A -7 B,C, entonces A -7 B Y A -7
(6) Unión:
Si A -7 B Y A -7 e, entonces A -7 B,C
(7) Composición:
Si A -7 B Y e -7 D, entonces A,C -7 B,D
e
La regla 1, de reflexibilidad, y la regla 4, de autodeterminación indican que un conjunto de atributos siempre se determina a sí mismo y a cualquiera de sus subconjuntos. Puesto que estas reglas generan dependencias funcionales que siempre son ciertas, dichas dependencias son triviales y, como hemos indicado anteriormente, generalmente no resultan interesantes ni útiles. La regla 2, de aumentación, indica que si se añade el mismo conjunto de atributos al lado izquierdo y al lado derecho de una dependencia, se obtiene otra dependencia válida. La regla 3, de transitividad, establece que las dependencias funcionales son transitivas. La regla 5, de descomposición, indica que podemos eliminar atributos del lado derecho de una dependencia. Aplicando esta regla repetidamente, podemos descomponer la dependencia funcional A -7 B, e, D en el conjunto de dependencias A -7 B, A -7 e y A -7 D. La regla 6, de unión, indica que podemos hacer la operación inversa: podemos combinar un conjunto de dependencias A -7 B, A -7 e y A -7 D en una única dependencia funcional A -7 B, e, D. La regla 7, de composición, es más general que la regla 6 e indica que podemos combinar un conjunto de dependencias no solapadas con el fin de formar otra dependencia válida. Para comenzar a identificar el conjunto de dependencias funcionales F de una relación, normalmente comenzamos identificando las dependencias que pueden deducirse a partir de la semántica de los atributos de la relación. Después aplicamos los Axiomas de Armstrong (reglas 1 a 3) para inferir dependencias funcionales adicionales que también sean ciertas para esa relación. Una forma sistemática de determinar estas dependencias funcionales adicionales consiste en determinar primero cada conjunto de atributos A que aparezca en el lado izquierdo de alguna dependencia funcional y luego determinar el conjunto de todos los atributos que sean dependientes de A. Así, para cada conjunto de atributos A podemos determinar el conjunto A+ de atributos que están funcionalmente determinados por A basándose en F (A+ se denomina cierre de A bajo F).
382
Sistemas de bases de datos
14.1.2 Conjuntos mínimos de dependencias funcionales En esta sección, vamos a presentar el concepto de equivalencia de conjuntos de dependencias funcionales. Un conjunto de dependencias funcionales y está cubierto por un conjunto de dependencias funcionales x, si toda dependencia funcional de y está también en x+; es decir, si toda dependencia contenida en Y puede inferirse a partir de X. Un conjunto de dependencias funcionales X es mínimo si satisface las siguientes condicIOnes: tiene un único atributo en su lado derecho.
•
Toda dependencia contenida en
•
No podemos sustituir ninguna dependencia A -¿ B de X por la dependencia e -¿ B, donde conjunto propio de A, y continuar obteniendo un conjunto de dependencias equivalente a
•
X
No podemos eliminar ninguna dependencia de valente a X.
X
e es un
sub-
X.
y seguir teniendo un conjunto de dependencias equi-
Un conjunto mínimo de dependencias debe estar en forma estándar, sin ninguna redundancia. Un recubrimiento mínimo de un conjunto de dependencias funcionales X es un conjunto mínimo de dependencias Xmin que sea equivalente a X. Desafortunadamente, puede haber varios recubrimientos mínimos para un conjunto de dependencias funcionales. Vamos a ilustrar la identificación del recubrimiento mínimo para la relación StaffBranch en el siguiente ejemplo.
I
Ejemplo 14.1 Identificación del conjunto relación StaffBranch
mínimo de dependencias
funcionales
para la
Aplicamos las tres condiciones anteriormente descritas al conjunto de dependencias funcionales de la relación StaffBranch enumerado en el Ejemplo 13.5, con el fin de generar las siguientes dependencias funcionales: staffNo
--->
sName
staffNo
--->
position
staffNo
--->
salary
staffNo
--->
branchNo
staffNo
--->
bAddress
branchNo
--->
bAddress
bAddress
--->
branchNo
branchNo,
position
--->
salary
bAddress,
position
--->
salary
Estas dependencias funcionales satisfacen las tres condiciones que debe cumplir un conjunto mínimo de dependencias funcionales para la relación StaffBranch. La condición 1 garantiza que toda dependencia se encuentre en forma estándar, con un único atributo en el lado derecho. Las condiciones 2 y 3 garantizan que no haya redundancias en las dependencias, bien por tener atributos redundantes en el lado izquierdo de una dependencia (condición 2) o por tener una dependencia que pueda deducirse a partir de las restantes dependencias funcionales contenidas en X (condition 3).
En la siguiente sección vamos a volver a considerar el tema de la normalización. Comenzaremos analizando la forma normal de Boyce-Codd (Boyce-Codd Normal Form, BCNF), una forma normal más fuerte que a 3NF.
Capítulo 14 Normalización avanzada
383
14.2 Forma normal de Boyce-Codd (BCNF) En el capitulo anterior hemos visto cómo la segunda y la tercera formas normales prohiben las dependencias parciales y transitivas con respecto a la clave principal de una relación, respectivamente. Las relaciones que tienen estos tipos de dependencias pueden sufrir las anomalías de actualización explicadas en la Sección 13.3. Sin embargo, la definición de 2NF y 3NF que hemos expuesto en las Secciones 13.7 y 13.8, respectivamente, no entran a analizar si siguen existiendo esas dependencias con resp6cto a otras claves candidatas de una relación, si es que existe alguna de dichas claves. En la Sección 13.9 se presentan definiciones generales para las formas normales 2NF y 3NF que prohiben las dependencias parciales y transitivas con respecto a todas las claves candidatas de una relación, respectivamente. La aplicación de las definiciones generales de 2NF y 3NF puede identificar redundancias adicionales causadas por dependencias que violen una o más claves candidatas. Sin embargo, a pesar de estas restricciones adicionales, pueden continuar existiendo dependencias que hagan que exista una cierta redundancia en las relaciones 3NF. Esta debilidad de la forma normal 3NF hizo que se desarrollara una forma normal más fuerte, denominada forma normal de Boyce-Codd (Codd, 1974).
14.2.1 Definición de la forma normal de Boyce-Codd La forma normal de Boyce-Codd (Boyce-Codd Normal Form, BCNF) está basada en dependencias funcionales que toman en consideración todas las claves candidatas de una relación; sin embargo, BCNF tiene también restricciones adicionales, si la comparamos con la definición general de 3NF dada en la Sección 13.9. Forma normal de Boyce-Codd
(BCNF)
Una relación está en BCNF, si y sólo si todo determinante es una clave candidata.
Para comprobar si una relación está en forma BCNF, identificamos todos los determinantes y comprobamos que sean claves candidatas. Recuerde que un determinante es un atributo, o un grupo de atributos, del cual depende funcionalmente de modo completo algún otro atributo. La diferencia entre 3NF y BCNF es que para una dependencia funcional A ---¿ B, 3NF permite que exista esta dependencia en una relación si B es un atributo de clave principal y A no es una clave candidata, mientras que BCNF exige, para que esta dependencia permanezca en una relación, el que A sea una clave candidata. Por tanto, la forma normal de Boyce-Codd es más fuerte que la forma 3NF, de modo que toda relación en BCNF está también en 3NF. Sin embargo, una relación en 3NF no está necesariamente en BCNF. Antes de considerar el siguiente ejemplo, vamos a volver a examinar las relaciones Client, Rental, PropertyForRent y Owner mostradas en la Figura 13.17. Las relaciones Client, PropertyForRent y Owner están en BCNF, ya que cada relación tiene un único determinante, que es la clave candidata. Sin embargo, recuerde que la relación Rental contiene los tres determinantes (clientNo, propertyNo), (clientNo, rentStart) y (propertyNo, rentStart) originalmente identificados en el Ejemplo 13.11, como se muestra a continuación: fd1
clientNo, propertyNo
fd5'
clientNo, rentStart ~ propertyNo,
~ rentStart, rentFinish
fd6'
propertyNo,
rentFinish
rentStart ~ c1ientNo, rentFinish
Como los tres determinantes de la relación Rental son también claves candidatas, la relación Rental está también en BCNF. La violación de la forma normal BCNF es bastante infrecuente, ya que sólo puede producirse bajo condiciones específicas. La posibilidad de violar las condiciones de la forma normal BCNF puede aparecer cuando: •
la relación contenga dos (o más) claves candidatas compuestas; o
•
las claves candidatas se solapen, es decir, tengan al menos un atributo en común.
En el siguiente ejemplo vamos a presentar una situación en la que una relación viola las restricciones BCNF y vamos a ilustrar el proceso de transformación de esta relación a BCNF. Este ejemplo muestra el proceso de convertir una relación lNF en una serie de relaciones en forma normal de Boyce-Codd.
384
I
Sistemas de bases de datos
Ejemplo 14.2 Forma normal de Boyce-Codd En este ejemplo, vamos a ampliar el caso de estudio de DreamHome para incluir una descripción de las entrevistas a los clientes realizadas por los empleados. La información relativa a estas entrevistas se encuentra en la relación Clientlnterviewmostrada en la Figura 14.1. A los empleados que tienen que entrevistar a los clientes se les asigna una sala específica para el día de la entrevista. Una misma sala puede ser asignada a diversos empleados a 10 largo de un mismo día, según sea necesario. Cada cliente sólo es entrevistado una vez en una fecha determinada, pero puede que se le solicite asistir a entrevistas adicionales en fechas posteriores. La relación Clientlnterviewtiene tres claves candidatas: (clientNo, interviewDate), (staffNo, interviewDate, interviewTime)y (roomNo, interviewDate,interviewTime).Por tanto, la relación Clientlnterviewtiene tres claves can didatas compuestas, las cuales se solapan al compartir el atributo común interviewDate(fecha de la entrevista). Seleccionamos (clientNo, interviewDate)para que actúe como clave principal de esta relación. La relación Clientlnterviewtiene la siguiente forma: Clientlnterview
(clientNo,interviewDate,interviewTime,staffNo,roomNo)
Las dependencias funcionales existentes en la relación Clientlnterviewson: fdl fd2 fd3 fd4
c1ientNo,interviewDate~ interviewTime,staffNo, roomNo staffNo, interviewDate,interviewTime~ c1ientNo roomNo, interviewDate,interviewTime--7 staffNo,c1ientNo staffNo, interviewDate~ roomNo
(Clave principal) (Clave candidata) (Clave candidata)
Examinamos las dependencias funcionales para determinar la forma normal de la relación Clientlnterview.Puesto que las dependencias funcionales fdl, fd2 Y fd3 son claves candidatas de esta relación, ninguna de estas dependencias nos causará problemas. La única dependencia funcional que requiere un análisis adicional es (staffNo, interviewDate) --j roomNo (representa como fd4). Aunque (staffNo, interviewDate)no es una clave candidata para la relación Clientlnterview,esta dependencia funcional está permitida en 3NF porque roomNo (número de sala) es un atributo de clave principal, al ser parte de la clave candidata (roomNo, interviewDate, interviewTime).Puesto que no hay dependencias parciales o transitivas con respecto a la clave principal (c1ientNo,interviewDate)y la dependencia funcional fd4 está permitida, la relación Clientlnterviewestá en 3NF. Sin embargo, esta relación no está en BCNF (una forma normal más fuerte que la 3NF) debido a la presencia del determinante (staffNo, interviewDate),que no es una clave candidata de la relación. BCNF requiere que todos los determinantes de una relación sean una clave candidata de dicha relación. Como consecuencia, la relación Clientlnterviewpuede sufrir de anomalías de actualización. Por ejemplo, para cambiar el número de sala para el empleado SG5 el 13 de mayo de 2005, debemos actualizar dos tuplas. Si sólo se actualizara una tupla con el nuevo número de sala, se dejaría la base de datos en un estado incoherente. Para transformar la relación Clientlnterviewa BCNF, debemos eliminar la dependencia funcional problemática, creando dos nuevas relaciones denominadas Interviewy StaffRoom,como se muestra en la Figura 14.2. Las relaciones Interviewy StaffRoomtienen la siguiente forma: Clientlnterview c1ientNoGI02 SG37 GIO] ]2.00 SGS GIOI 10.30 12.00 roomNo interviewDate interviewTime staffNo HuI-OS10.30 l3-May-OS 13-May-OS
46 6
Figura 14.1.
Relación Clientlnterview.
Capítulo 14 Normalización avanzada
385
Interview(c1ientNo,interviewDate,interviewTime,staffNo) StaffRoom(staffNo,interviewDate,roomNo) Interview SGS 12.00 SG37 clientNo interviewDate 10.30 staffNo HuI-OSinterviewTime l3-May-OS CRS6 CR74 CR76
StaffRoom staffNo
Gl02 G101 G l02 interviewDate roomNo l-¡ul-OS l3-May-OS
SGS SG37 SGS
Figura 14.2.
Relaciones BCNF Interview y StaffRoom.
Partiendo de una relación que no esté en BCNF, podemos descomponerla para obtener la forma normal BCNF de la manera que se ilustra en el ejemplo. Sin embargo, puede que no siempre sea deseable transformar una relación a BCNF; por ejemplo, si hay alguna dependencia funcional que no sea preservada al realizar la descomposición (es decir, si el determinante y los atributos que dependen funcionalmente de él quedan ubicados en relaciones distintas). En esta situación, resulta dificil imponer la dependencia funcional en la relación, perdiéndose una restricción importante. Cuando esto sucede, puede que sea más adecuado detenerse en la forma normal3NF, que siempre preserva las dependencias. Observe, en el Ejemplo 14.2, en que al crear las dos relaciones BCNF a partir de la relación Clientlntervieworiginal, hemos 'perdido' la dependencia funcional roomNo,interviewDate,interviewTime-7 staffNo, clientNo(representada como fd3), ya que el determinante correspondiente a esta dependencia ya no se encuentra agrupado en una misma relación. Sin embargo, tenemos que ser conscientes de que si no se elimina la dependencia funcional staffNo, interviewDate -7 roomNo (representada como fd4), la relación Clientlnterviewpresentará una redundancia en los datos. La decisión de si es mejor detener el proceso de normalización en 3NF o continuar hasta BCNF depende de la cantidad de redundancia que resulte de la presencia de fd4 y de la importancia que tenga la 'pérdida' de fd3. Por ejemplo, si resulta que los empleados sólo realizan una entrevista al día, la presencia de fd4 en la relación Clientlnterviewno provocará ninguna redundancia y la descomposición de esta relación en dos relaciones BCNF no resulta, por tanto, ni útil ni necesaria. Por el contrario, si los empleados realizan numerosas entrevistas cada día, la presencia de fd4 en la relación Clientlnterviewprovocará la aparición de redundancia, recomendándose que se nonnalice esta relación para obtener la forma normal BCNF. Sin embargo también debemos tener en cuenta la importancia de perder fd3. En otras palabras, ¿la dependencia funcional fd3 nos transmite información importante acerca de las entrevistas con los clientes que deba ser representada en una de las relaciones resultantes? La respuesta a esta cuestión nos ayudará a determinar si es mejor retener todas las dependencias funcionales o eliminar la redundancia presente en los datos.
14.3 Revisión del proceso de normalización hasta BCNF El propósito de esta sección es revisar el proceso de normalización descrito en el capítulo anterior y en la Sección 14.2. Ilustraremos el proceso de transformar los atributos mostrados en un informe de ejemplo del caso de estudio de DreamHome en un conjunto de relaciones en forma normal de Boyce-Codd. En este ejem-
386 Sistemas de bases de datos plo, utilizaremos las definiciones de 2NF y 3NF basadas en la clave principal de una relación. Dejamos la normalización de este ejemplo mediante las definiciones generales de 2NF y 3NF como ejercicio para el lector.
I
Ejemplo 14.3 De la primera forma normal (1 NF) a la forma normal Boyce-Codd
(BCNF)
En este ejemplo, vamos a ampliar el caso de estudio de DreamHome para incluir los informes de inspección de los inmuebles por parte de los empleados. Cuando se solicita a los empleados que lleven a cabo estas inspecciones, se les asigna un coche de empresa para usado durarrte el día en que tienen lugar las mismas. Sin embargo, un mismo coche puede ser asignado a varios empleados según sea necesario a lo largo de un mismo día de trabajo. Cada empleado puede inspeccionar varios inmuebles en una fecha determinada, pero cada inmueble sólo es inspeccionado una vez dentro de un mismo día. En la Figura 14.3 se muestran ejemplos de los informes de inspección de inmuebles de DreamHome. El informe de la parte superior describe las inspecciones del inmueble PG4, situado en Glasgow, por parte de los empleados.
22-Apr-04 f-
Nombre del Hora Matricula 10.00 Número coche de de PG4 12.00 DreamHome Ann M231 09.00 Beech JGR Ford David N721 HFR Comentarios SG37 M533 HDR SG14 SG14 inspección 6 Lawrence Sto Glasgow Need to replace Inempleado good order empleado Damp rot in de DreamHome Dirección del inmueble Informe de Inspección de Inmuebles Número de inmueble
a de
Página 1
Figura
14.3.
Informes de inspección de inmuebles de DreamHome.
Primera forma normal (1 NF) Primero transferimos los datos de ejemplo contenidos en dos informes de inspección de inmuebles a un formato de tabla con filas y columnas. Denominaremos esta tabla no normalizada StaffPropertylnspection, mostrándose su estructura en la Figura 14.4. Identificamos el atributo clave para esta tabla no normalizada como propertyNo. Los grupos repetitivos en la tabla no normalizada son los detalles relativos a la inspección del inmueble y los detalles de los empleados, que se repiten para cada inmueble. La estructura del grupo repetitivo es: Grupo repetitivo = (iDate, iTime, comments,
staffNo, sName, carReg)
Capítulo 14 Normalización avanzada
387
StaffPropertyl ns pection 10.00 18-0ct-03 staffNo 09.00 13.00 comments iTime propertyNo 12.00 M533HDR Good David 14.00 M533 N721 condition Beech 24-0ct-04 Ford HDR SG14 iDate sName Lawrence St,SG37 M231 JGR 56pAddress Novar Dr, Need to replace crockery Damp InAnn good rot order inHFR bathroom Replace 22-Apr-04 living room carpet carReg
Figura 14.4.
Tabla StaffPropertylnspection
no normalizada.
Como consecuencia, hay múltiples valores en la intersección de ciertas filas y columnas. Por ejemplo, para el inmueble PG4 hay tres valores de iDate (l8-0ct-03, 22-Apr-04, 1-Oct-04). Transformamos la tabla no normalizada a primera forma normal utilizando el primero de los enfoques descritos en la Sección 13.6. Con esta técnica, eliminamos el grupo repetitivo (inspección del inmueble y detalles de los empleados) introduciendo los detalles apropiados de los inmueble s (datos no repetitivos) en cada fila. En la Figura 14.5 se muestra la relación resultante StaffPropertylnspection en primera forma normal. En la Figura 14.6 se presentan las dependencias funcionales (fdl a fd6) para la relación StaffPropertylnspection. Utilizamos estas dependencias funcionales (como se explica en la Sección que serán claves 13.4.3) para identificar las claves candidatas de la relación StaffPropertylnspection, compuestas formadas por los atributos (propertyNo, ¡Date), (staffNo, iDate, iTime) y (carReg, iDate, iTime). Seleccionamos (propertyNo, iDate) como clave principal para esta relación. Para una mayor claridad, vamos a situar juntos los atributos que forman la clave principal, en el lado izquierdo de la relación. quedará definida como sigue: La relación StaffPropertylnspection StaffPropertyl nspection
(prooertvNo,
iDate, iTime, pAddress, comments,
staffNo, sName, carReg)
La relación StaffPropertylnspection está en primera forma normal (lNF) ya que hay un único valor en la intersección de cada fila y columna. La relación contiene datos que describen la inspección de los inmuebles por parte de los empleados, repitiéndose los detalles sobre los inmuebles y los empleados varias veces. Como resultado, la relación StaffPropertylnspection contiene una redundancia considerable. Si se implementara, esta relación lNF estaría sujeta a anomalías de actualización. Para eliminar algunas de estas anomalías, debemos transformar la relación a segunda forma normal.
Segunda forma normal (2NF) La normalización de relaciones lNF a 2NF implica la eliminación de las dependencias parciales con respecto a la clave principal. Si existe una dependencia parcial, eliminamos de la relación los atribuStaffPro pertyl ns pection 09.00 18-0ct-03 propertyNo Ann Beech 13.00 Ford 10.00 sName ¡Time comments staffNo SG37 David 12.00 1-0ct-04 N721 HFR SGl4 14.00 M533HDR 24-0ct-04 Good condition 65pAddress Lawrence St,to iDate Novar Dr, M231 JGR carReg 22-Apr-04 Need replace crockery In good order Damp rot inSG14 bathroom Replace living room carpet
Figura 14.5.
Relación StaffPropertylnspection
en primera forma normal (1 NF).
388
Sistemas de bases de datos
tos funcionalmente dependientes colocándolos en una nueva relación, junto con una copia de su determinante. Como se muestra en la Figura 14.6, las dependencias funcionales (fdl a fd6) de la relación StaffPropertylnspectionson las siguientes: fdl propertyNo, iDate ~ iTime,comments, staffNo, sName, carReg (Clave principal) fd2 (Dependencia parcial) propertyNo~ pAddress staffNo~ sName fd3 (Dependencia transitiva) fd4 staffNo, ¡Date~ carReg fd5 carReg, iDate, iTime~ propertyNo,pAddress, comments, staffNo,sName (Clave candidata) fd6 staffNo, iDate, iTime~ propertyNo,pAddress, comments (Clave candidata) Utilizando las dependencias funcionales, continuamos el proceso de normalización de la relación StaffPropertylnspection. Comenzamos comprobando si la relación está en forma 2NF, identificando la presencia de dependencias parciales con respecto a la clave principal. Podemos observar que el atributo de dirección del inmueble (pAddress) depende de forma parcial de una parte deJa clave principal, en concreto del número de inmueble propertyNo(lo que se representa mediante la dependencia fd2), mientras que los restantes atributos (iTime, comments, staffNo, sName y carReg) dependen de modo completo de la clave principal (propertyNo e iDate), lo que se representa mediante la dependencia funcional fdl. Observe que, aunque el determinante de la dependencia funcional staffNo, iDate -7 carReg (representada como fd4) sólo requiere el atributo iDate de la clave principal, no eliminamos esta dependencia en esta etapa, ya que el determinante incluye también otro atributo que no es de clave principal, staffNo. En otras palabras, esta dependencia no depende completamente de una parte de la clave principal, por lo que no viola las restricciones de la forma 2NF. La identificación de la dependencia parcial (propertyNo -7 pAddress) indica que la relación StaffPropertylnspectionno está en forma 2NF. Para transformar esta relación a 2NF necesitamos crear una nueva relación, de modo que los atributos que no dependen completamente de la clave principal estén sólo asociados con la parte apropiada de dicha clave. La relación StaffPropertylnspection se transforma a segunda forma normal eliminando la dependencia parcial de la relación y creando dos nuevas relaciones, denominadas Property y Propertylnspection, con la siguiente estructura: Property (propertyNo,pAddress) Propertylnspection (propertyNo,iDate, iTime,comments, staffNo,sName, carReg) StaffPropertylnspection
t (Dependenciaparcial)
fd21
(Dependencia L---J• transitiva)
fd3 I I
fd41
t (Clavecandidata)
fd5
fd6t_~LJ __ Figura 14.6.
Dependencias
t__
t__
funcionales
(Clavecandidata)
de la relación StaffPropertylnspection.
Capítulo 14 Normalización avanzada
389
Estas relaciones están en forma 2NF, ya que todo atributo que no es de clave principal depende funcionalmente de la clave principal de la relación.
Tercera forma normal (3NF) La normalización de las relaciones 2NF a 3NF implica la eliminación de las dependencias transitivas. Si existe aún dependencia transitiva, eliminamos de la relación los atributos que dependen transitivamente, situándolos en una nueva relación junto con una copia de su determinante. Las dependencias funcionales dentro de las relaciones Property y Propertylnspection son las siguientes: Relación Prooerty fd2
propertyNo
--7 pAddress
Relación Prooertyl nsoection fd1 fd3
propertyNo, iDate --7 iTime, comments, staffNo --7 sName
staffNo, sName, carReg
fd4
staffNo, ¡Date --7 carReg
fd5'
carReg, iDate, iTime --7 propertyNo,
comments,
fd6'
staffNo, ¡Date, iTime --7 propertyNo,
comments
staffNo, sName
Puesto que la relación Property no tiene dependencias transitivas con respecto a la clave principal, ya está en forma 3NF. Sin embargo, aunque todos los atributos que no son de clave principal dentro de la relación Propertylnspection dependen funcionalmente de la clave principal, sName también depende transitivamente de staffNo (lo que se representa mediante la dependencia fd3). También observamos que la dependencia funcional staffNo, iDate ~ carReg (representada como fd4) tiene un atributo que no es de clave principal, carReg, que depende parcialmente de otro atributo que no es de clave principal, staffNo. No vamos a eliminar esta dependencia en esta etapa, ya que parte del determinante de esta dependencia incluye un atributo de clave principal, iDate. (En otras palabras, esta dependencia no depende completamente de forma transitiva de ningún atributo que no sea de clave principal, por lo que no viola las restricciones de la forma 3NF en otras palabras, como se describe en la Sección 13.9, cuando se consideran todas las claves candidatas de una relación, la dependencia staffNo, iDate ~ carReg es válida en 3NF porque carReg es un atributo de clave principal, ya que es parte de la clave candidata (carReg, iDate, iTime) de la relación Propertylnspection original). Para transformar la relación Propertylnspection a 3NF, eliminamos la dependencia transitiva (staffNo ~ sName) creando dos nuevas relaciones denominadas Staff y Propertylnspect, con la estructura: Staff
(staffNo, sName)
Propertylnspect
(prooertvNo,
iDate, iTime, comments,
staffNo, carReg)
Las relaciones Staff y Propertylnspect están en forma 3NF, ya que no hay ningún atributo que no sea de clave principal y que dependa funcionalmente de modo completo de otro atributo que no sea de clave principal. Así, la relación StaffPropertylnspection mostrada en la Figura 14.5 ha sido transformada mediante el proceso de normalización en tres relaciones 3NF, con la siguiente estructura: Property
(orooertyNo,
Staff
(staffNo, sName)
pAddress)
Propertylnspect
(propertvNo,
iDate, iTime, comments,
staffNo, carReg)
Forma normal de Boyce-Codd (BCNF) Ahora examinamos las relaciones Property, Staff y Propertylnspect para determinar si están en forma BCNF. Recuerde que una relación está en forma BCNF si todo determinante de la relación es una clave candidata. Por tanto, para comprobar si se cumplen las reglas de la forma BCNF, simplemente identificamos todos los determinantes y comprobamos si son claves candidatas. Las dependencias funcionales para las relaciones Property, Staff y Propertylnspect son las siguientes:
390
Sistemas de bases de datos Relación Prooerty fd2 propertyNo -j pAddress Relación Staff fd3 staffNo -j sName Relación Propertylnsoect fd1' propertyNo,iDate -j iTime,comments, staffNo,carReg fd4 staffNo,iDate -j carReg fd5' carReg, iDate, iTime-j propertyNo,comments, staffNo fd6' staffNo,iDate, iTime-j propertyNo,comments
Podemos ver que las relaciones Property y Staff están en forma BCNF, ya que el determinante en cada una de estas relaciones es también la clave candidata. La única relación 3NF que no está en forma BCNF es Propertylnspect, debido a la presencia del determinante (staffNo,iDate), que no es una clave candidata (representado como fd4). Como consecuencia, la relación Propertylnspect puede sufrir anomalías de actualización. Por ejemplo, para cambiar el coche asignado al empleado SG 14 el 22 de abril de 2003, debemos actualizar dos tuplas. Si sólo se actualizara una de ellas con la nueva matrícula de coche, la base de datos quedaría en un estado incoherente. Para transformar la relación Propertylnspect a forma BCNF, debemos eliminar la dependencia que viola las reglas de BCNF creando dos nuevas relaciones denominadas StaffCare Inspection, con la estructura: StaffCar (staffNo,iDate, carReg) Inspection (prooertyNo,iDate, iTime,comments, staffNo) Las relaciones StaffCar e Inspection están en forma BCNF, ya que el determinante de cada una de estas relaciones es también una clave candidata. En resumen, la descomposición de la relación StaffPropertylnspectionmostrada en la Figura 14.5 en una serie de relaciones BCNF es la que se muestra en la Figura 14.7. En este ejemplo, la descomposición de la relación StaffPropertylnspectionoriginal en diversas relaciones BCNF da como resultado la 'pérdida' de la dependencia funcional carReg, iDate, iTime -7 propertyNo, pAddress, comments, staffNo, sName, ya que hay partes del determinante que se encuentran en relaciones distintas (esta dependencia está representada como fd5). Sin embargo, vemos que si no se eliminara la dependencia funcional staffNo, iDate -7 carReg (representada como fd4), la relación Propertylnspect presentaría redundancia en los datos. Las relaciones BCNF resultantes tienen la siguiente estructura: Property (prooertyNo,pAddress) Staff(staffNo,sName) StaffPropertylnspection
Propertylnspection
n
Propertylnspect
Staff Figura 14.7.
StaffCar
Inspection
1NF
I
2NF
I
3NF
Property BCNF
Descomposición de la relación StaffPropertylnspection
en una serie de relaciones BCNF.
Capítulo 14 Normalización avanzada
391
Inspection (prooertyNo,iDate, iTime,comments, staffNo) StaffCar(staffNo,iDate, carReg) La relación StaffPropertylnspectionoriginal mostrada en la Figura 14.5 puede volver a crearse a partir de las relaciones Property, Staff, Inspection y StaffCar utilizando los mecanismos de clave principal/clave externa. Por ejemplo, el atributo staffNo es una clave principal de la relación Staff y también está presente dentro de la relación Inspection en forma de clave externa. La clave externa permite asociar las relaciones Staffe Inspection para identificar el nombre del empleado que lleva a cabo la inspección del inmueble.
14.4 Cuarta forma normal (4NF) Aunque la forma BCNF elimina todas las anomalías debidas a dependencias funcionales, una serie de investigaciones ulteriores condujeron a la identificación de otro tipo de dependencia, denominada dependencia multivaluada (Multi-Valued Dependency, MVD), que también puede provocar que exista redundancia en los datos (Fagin, 1977). En esta sección, vamos a describir brevemente una dependencia multivaluada y la asociación de este tipo de dependencia con la cuarta forma normal (Fourth Normal Form, 4NF).
14.4.1 Dependencia multivaluada La posible existencia de dependencias multivaluadas en una relación se debe a la primera forma normal, que impide que un atributo de una tupla tenga un conjunto de valores diferentes. Por ejemplo, si tenemos dos atributos multivaluados en una relación, es preciso repetir cada valor de uno de los atributos con cada uno de los valores del otro atributo, para garantizar que las tuplas de la relación sean coherentes. Este tipo de restricción se denomina dependencia multivaluada y provoca que aparezca redundancia en los datos. Considere la relación BranchStaffOwnermostrada en la Figura 14.8(a), que muestra los nombres de los empleados (sName) y de los propietarios de inmuebles (oName) en cada sucursal (branchNo). En este ejemplo, suponga que el nombre del empleado (sName) identifica unívocamente a cada empleado y que el nombre del propietario (oName) identifica también unívocamente a cada propietario. En este ejemplo, dos empleados llamados Ann Beech y David Ford trabajan en la sucursal B003, y los propietarios de inmueble s llamados Carol Farrel y Tina Murphy están registrados en esa misma sucursal B003. Sin embargo, puesto que no hay una relación directa entre los empleados y los propietarios en una sucursal concreta, debemos crear una tupla para cada combinación de empleado y propietario, para garantizar que la relación sea coherentes. Esta restricción representa una dependencia multivaluada dentro de la relación BranchStaffOwner.En otras palabras, existe una dependencia multivaluada porque se están representando dos relaciones 1:* independientes dentro de la relación BranchStaffOwner. Dependencia multivaluada (MVD)
Representa una dependencia entre atributos (por ejemplo, A, B Y C) en una relación de modo que para cada valor de A hay un conjunto de valores de B y un conjunto de valores de C. Sin embargo, los conjuntos de valores de B y C son independientes entre sí. BranchStaffOwner branchNo Tina oName David sName Carol Ann Beech Farre! Farrel Ford Murphy
BOO3 BOO3
Figura 14.8(a).
La relación BranchStaffOwner.
392
Sistemas de bases de datos
Representamos ción siguiente:
una dependencia multivaluada entre atributos
A,
B Y e de una relación utilizando la nota-
A~>B A~>C
Por ejemplo, la dependencia multivaluada de la relación BranchStaffOwnermostrada en la Figura 14.8(a) podría especificarse de la forma siguiente: branchNo ~> branchNo ~>
sName oName
Las dependencias multivaluadas pueden ser triviales o no triviales. Una dependencia multivaluada A ~> B = R. Una dependencia multivaluada B en la relación R será trivial si (a) B es un subconjunto de A o (b) A será no trivial si no se satisface ninguna de las condiciones (a) y (b). Una dependencia multivaluada trivial no especifica ninguna restricción que afecte a la relación, mientras que una dependencia multivaluada no trivial sí que especifica una restricción. La dependencia multivaluada de la relación BranchStaffOwnermostrada en la Figura 14.8(a) es no trivial, ya que no se cumplen ni la condición (a) ni (b). La relación BranchStaffOwnerestá por tanto restringida por la dependencia multivaluada no trivial, debiéndose repetir las tuplas para garantizar que la relación continúe siendo coherente en términos de la relación existente entre los atributos sName y oName. Por ejemplo, si quisiéramos añadir un nuevo propietario de inmueble para la sucursal B003, tendríamos que crear dos nuevas tuplas, una para cada empleado, para garantizar la coherencia de la relación. Este es un ejemplo de anomalía de actualización causada por la presencia de la dependencia multivaluada no trivial. Aunque la relación BranchStaffOwnerestá en forma BCNF, esta relación tiene una estructura muy pobre, debido a la redundancia en los datos provocada por la presencia de la dependencia multivaluada no trivial. Obviamente, necesitamos una forma más fuerte de BCNF que impida la definición de estructuras relacionales similares a la relación BranchStaffOwner.
u
14.4.2 Definición de cuarta forma normal Cuarta forma normal (4NF)
Una relación que está en forma normal de Boyce-Codd dencias multivaluadas no triviales.
y no contiene depen-
La cuarta forma normal (4NF) es más fuerte que la forma BCNF, ya que impide que las relaciones contengan dependencias multivaluadas no triviales y, por tanto, redundancia en los datos (Fagin, 1977). La normalización de relaciones BCNF a 4NF implica la eliminación de las dependencias multivaluadas de la relación, colocando los atributos en una nueva relación junto con una copia de los determinantes. Por ejemplo, la relación BranchStaffOwnerde la Figura 14.8(a) no está en forma 4NF debido a la presencia de la dependencia multivaluada no trivial. Podemos descomponer la relación BranchStaffOwneren sendas relaciones BranchStaffy BranchOwner, como se muestra en la Figura 14.8(b). Ambas nuevas relaciones están en forma 4NF, porque la relación BranchStaffcontiene la dependencia multivaluada trivial branchNo -7> sName y la relación BranchOwner contiene la dependencia multivaluada trivial branchNo -7> oName. Observe que las relaciones 4NF no poseen redundancia en los datos, con lo que habremos eliminado la posibilidad de que aparezcan anomalías de actualización. Por ejemplo, para añadir un nuevo propietario de inmueble a la sucursal B003, nos bastará con crear una única tupla en la relación BranchOwner. BranchStaff
BranchOwner
branchNo sName Ann David Beech Ford BOO3
branchNo oName Carol Murphy Farrel Tina
BOO3
Figura 14.8(b). Las relaciones 4NF BranchStaff y BranchOwner.
Capítulo 14 Normalización avanzada El lector interesado puede encontrar un análisis detallado de la forma normal4NF y Navathe (2003) y Hawryszkiewycz (1994).
393
en Date (2003), Elmasri
14.5 Quinta forma normal (5NF) Cada vez que descomponemos una relación en dos relaciones, las relaciones resultantes tienen la propiedad denominada de combinación sin pérdidas. Esta propiedad hace referencia al hecho de que podemos volver a recombinar las relaciones resultantes para producir la relación original. Sin embargo, hay casos en los que se necesita descomponer una relación en más de dos relaciones. Aunque son raros, estos casos están gobernados por la denominada dependencia de combinación y la quinta forma normal (Fifth Normal Form, 5NF). En esta sección, vamos a describir brevemente el concepto de dependencia de combinación sin pérdidas y su relación con la forma normal 5NF.
14.5.1 Dependencia de combinación sin pérdidas Dependencia de combinación sin pérdidas
Una propiedad de la descomposición que garantiza que no se generen tuplas espurias al volver a combinar las relaciones mediante una operación de combinación natural.
Al dividir las relaciones mediante una operación de proyección, estamos siendo muy explícitos acerca del método de descomposición. En particular, tenemos cuidado de utilizar proyecciones que puedan invertirse mediante combinación de las relaciones resultantes, de modo que pueda reconstruirse la relación original. Dicho tipo de descomposición se denomina descomposición de combinación sin pérdidas (también denominada combinación no aditiva), porque preserva todos los datos de la relación original y no provoca la creación de tuplas espurias adicionales. Por ejemplo, las Figuras 14.8(a) y 14.8(b) muestran que la descomposición de la relación BranchStaffOwneren las relaciones BranchStaffy BranchOwnertienen la propiedad de combinación sin pérdidas. En otras palabras, la relación original BranchStaffOwnerpuede reconstruirse llevando a cabo una operación de combinación natural con las relaciones BranchStaffy BranchOwner. En este ejemplo, la relación original se ha descompuesto en dos relaciones. Sin embargo, hay casos en los que necesitamos realizar una descomposición de combinación sin pérdidas en una relación para obtener más de dos relaciones (Aho et al., 1979). Estos casos son el objeto del concepto de dependencia de combinación sin pérdidas y de quinta forma normal (5NF).
14.5.2 Definición de quinta forma normal Quinta forma
Una relación que no tiene dependencias
de combinación.
normal (5NF)
La quinta forma normal (5NF), también denominadaforma normal de proyección-combinación (Project-Join Normal Form, PJNF) especifica que, para que una relación esté en forma 5NF, no debe tener dependencias de combinación (Fagin, 1979). Para examinar el concepto de dependencia de combinación, considere como ejemplo la relación PropertyltemSupplier mostrada en la Figura 14.9(a). Esta relación describe inmuebles (propertyNo) que requieren ciertos elementos (itemDescription) que son proporcionados por suministradores (supplierNo)a los inmuebles (propertyNo). Además, cuando una propiedad (p) requiere un cierto elemento (i) y un suministrador (s) suministra dicho elemento (i) y el suministrador (s) ya está suministrando al menos un elemento a dicho inmueble (p), el suministrador (s) también suministrará el elemento requerido (i) al inmueble (P). En este ejemplo, suponga que la descripción de un elemento (itemDescription) identifica unívocamente cada tipo de elemento. Para identificar el tipo de restricción que se aplica a la relación PropertyltemSupplier en la Figura 14.9(a), considere el siguiente enunciado:
394
Sistemas de bases de datos (a) PropertyltemSupplier
(Estado ilegal)
propertyNo I itemDescription
I supplierNo
PG4
Bed
SI
PG4
Chair
S2
PG16
Bed
S2
(b) PropertyltemSupplier
(Estado legal)
propertyNo I itemDescription
I supplierNo
PG4
Bed
SI
PG4
Chair
S2
PG16
Bed
S2
PG4
Bed
S2
esta nueva tupla también debe añadirse para que el estado de la relación sea legal
(a) Estado ilegal para la relación PropertyltemSupplier (b) estado legal para la relación PropertyltemSupplier.
Figura 14.9.
Si
el el el el
Entonces
inmueble PG4 requiere una suministrador 82 suministra suministrador 82 suministra suministrador 82 suministra
y
cama (Bed) (a partir de los datos de la tupla 1) al inmueble PG4 (a partir de los datos de la tupla 2) camas (Bed) (a partir de los datos de la tupla 3) camas (Bed) al inmueble PG4
Si Este ejemplo ilustra la naturaleza cíclica de la restricción que afecta a la relación PropertyltemSupplier. esta restricción se cumple, la tupla (PG4, Bed, S2) deberá existir en todo estado legal de la relación PropertyltemSupplier, según se muestra en la Figura 14.9(b). Este es un ejemplo de un tipo de anomalía de actualización a la que nos referimos diciendo que la relación contiene una dependencia de combinación (join dependency, JD). Dependencia combinación
Describe un tipo de dependencia. Por ejemplo, para una relación R compuesta por una serie de subconjuntos de los atributos de R denomina A, B, . .. , Z, la relación R exhibirá una dependencia de combinación si y sólo si todo valor legal de R es igual a la combinación de sus proyecciones sobre A,
de
B, ... , Z.
Puesto que la relación PropertyltemSupplier contiene una dependencia de combinación, no se encuentra en forma 5NF. Para eliminar la dependencia de combinación, descomponemos la relación PropertyltemSupplier en tres relaciones 5NF, denominadas Propertyltem (R1), ItemSupplier (R2) y PropertySupplier (R3), como se muestra en la Figura 14.10. Decimos entonces que la relación PropertyltemSupplier con la forma (A, B, e) satisface la dependencia de combinación (R1(A, B), R2(B, e), R3(A, e)). Propertyltem propertyNo
ItemSupplier Bed Chair itemDescription Bed Chair
PG16 PG4 PG4
Bed
Figura 14.10.
itemDescription
PropertySupplier SI S2 supplierNo
propertyNo
SI S2 supplierNo
PG16 PG4 PG4
Relaciones 5NF Propertyltem, ItemSupplier y PropertySupplier.
Capítulo 14 Normalización avanzada
395
Es importante observar que si se realiza una combinación natural con cualesquiera dos de las relaciones se generarán tuplas espurias. Sin embargo, si se realiza la combinación de las tres se obtendrá la relación PropertyltemSupplier original. . El lector interesado puede encontrar un análisis detallado de la forma normal 5NF en Date (2003), Elmasri y Navathe (2003) y Hawryszkiewycz (1994).
Resumen del capítulo •
Pueden usarse reglas de inferencia para identificar el conjunto de todas las dependencias funcionales asociadas con una relación. Este conjunto de dependencias puede ser muy grande para una relación dada.
•
Puede emplearse una serie de reglas de inferencia denominadas axiomas de Armstrong para identificar el conjunto mínimo de dependencias funcionales a partir del conjunto de todas las dependencias funcionales de una relación.
•
La forma normal de Boyce-Codd (Boyce-Codd determinante es una clave candidata.
•
La cuarta forma normal (Fourth Normal Form, 4NF) es una relación que está en forma BCNF y no contiene dependencias multivaluadas no triviales. Una dependencia multivaluada (multi-valued dependency, MVD) representa una dependencia entre atributos (A, B Y e) de una relación tal que para cada valor de A hay un conjunto de valores de B y un conjunto de valores de e, siendo los conjuntos de valores de B y e independientes entre sí.
•
Una dependencia de combinación sin pérdidas es una propiedad de la descomposición que significa que no se generan tuplas espurias cuando se combinan las relaciones mediante una operación de combinación natural.
•
La quinta forma normal (Fifth Normal Form, 5NF) es una relación que no contiene dependencias de combinación. Para una relación R con subconjuntos de atributos denominados A, B, ... , Z, la relación R satisfará una dependencia de combinación si y sólo si todo valor legal de R es igual a la combinación de sus proyecciones sobre A, B, ... , Z.
Normal Form, BCNF) es una relación en la que todo
Cuestiones de repaso 14.1. Describa el propósito de utilizar reglas de inferencia para identificar dependencias funcionales en una relación dada. 14.2. Explique el propósito de los Axiomas de Armstrong. 14.3. Explique el propósito de la forma normal de Boyce-Codd (BCNF) y explique cómo difiere la forma BCNF de la forma 3NF. Proporcione un ejemplo para ilustrar su respuesta. 14.4. Describa el concepto de dependencia multivaluada y explique cómo se relaciona este concepto con la forma 4NF. Proporcione un ejemplo para ilustrar su respuesta. 14.5. Describa el concepto de dependencia de combinación y explique cómo se relaciona este concepto con la forma 5NF. Proporcione un ejemplo para ilustrar su respuesta.
Ejercicios 14.6. Después de completar el Ejercicio 13.14, examine las relaciones 3NF creadas para representar los atributos mostrados en el formulario del Wellmeadows Hospital mostrado en la Figura 13.18. Determine si estas relaciones están también en forma BCNF. Si no es así, transforme a BCNF las relaciones que no lo estén. 14.7. Después de completar el Ejercicio 13.15, examine las relaciones 3NF creadas para representar los atributos mostrados en la relación que contiene los datos de citas de dentistas/pacientes de la Figura 13.19.
396
Sistemas de bases de datos Determine si estas relaciones están también en forma BCNF. Si no es así, transforme a BCNF las relaciones que no lo estén.
14.8.
Después de completar el Ejercicio 13.16, examine las relaciones 3NF creadas para representar los atributos mostrados en la relación que contiene los datos de contratos laborales de los empleados para una agencia denominada Instant Caver, como se muestra en la Figura 13.20. Determine si estas relaciones están también en forma BCNF. Si no es así, transforme a BCNF las relaciones que no lo estén.
14.9.
La relación mostrada en la Figura 14.11 indica los empleados (staffName) que trabajan en un departaasignados a dicho departamento. No exismento determinado (wardName) y los pacientes (patientName) te ninguna relación entre los empleados y los pacientes en cada departamento. En este ejemplo, suponga que el nombre del empleado (staffName) identifica unívocamente a cada empleado y que el nombre del paciente (patientName) identifica unívocamente a cada paciente. (a)
Describa por qué la relación mostrada en la Figura 14.11 no está en forma 4NF.
(b)
La relación mostrada en la Figura 14.11 es susceptible a las anomalías Proporcione ejemplos de anomalías de inserción, borrado y actualización.
(c)
Describa e ilustre el proceso de normalizar a 4NF la relación mostrada en la Figura 14.11. wardName
de actualización.
staffName Brian White Kim Jones Claire Johnson patientName Stephen Ball
Pediatrics Pediatrics
Figura 14.11.
La relación WardStaffPatient.
14.1 O. La relación mostrada en la Figura 14.12 describe hospitales (hospitaIName) que requieren ciertos elementos (itemDescription) que son proporcionados por suministradores (supplierNo) a los hospitales (hospitaIName). Además, siempre que un hospital (h) requiere un cierto elemento (i) y un suministrador (s) suministra dicho elemento (i) y el suministrador (s) ya suministra al menos un elemento a dicho hospital (h), entonces el suministrador (s) también suministrará el elemento requerido (i) al hospital (h). En este ejemplo, suponga que la descripción de un elemento (itemDescription) identifica unívocamente a cada tipo de elemento. (a)
Describa por qué la relación mostrada en la Figura 14.12 no está en forma 5NF.
(b)
Describa e ilustre el proceso de normalizar a 5NF la relación mostrada en la Figura 14.12. hospitalName
SI Towe\s S2 itemDescription Paper supplierNo Antiseptic Wipes
Western Yorkhill General Western General
Figura 14.12.
La relación HospitalltemSupplier.
arte
Metodología
Capítulo 15 Metodología: diseño conceptual de la base de datos Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional Capítulo 17
Metodología: diseño físico de bases de datos relacionales
Capítulo 18
Metodología: monitorización
y optimización
del sistema final
Capítulo
Metodología: diseño conceptual de la base de datos
Objetivos del capitulo: En este capítulo aprenderá: •
El propósito de una metodología de diseño.
•
Las tres fases principales del diseño de bases de datos: conceptual, lógico y físico.
•
Cómo descomponer el diseño en vistas específícas de la organización.
•
Cómo utilizar el modelado de Entidad-Relación (ER) para construir un modelo conceptual local de los datos basado en la información proporcionada en una vista de la organización.
•
Cómo validar el modelo conceptual resultante para garantizar que sea una representación precisa de una vista de la organización.
•
Cómo documentar el proceso del diseño conceptual de bases de datos.
•
Que los usuarios fínales juegan un papel fundamental en todo el proceso de diseño conceptual de la base de datos.
correcta y
En el Capítulo 9 hemos descrito las etapas principales del ciclo de desarrollo de los sistemas de bases de datos, una de las cuales es el diseño de la base de datos. Esta etapa sólo puede dar comienzo después de llevar a cabo un análisis completo de los requisitos de la organización. En este capítulo, y en los Capítulos 16-18 se describe una metodología para la etapa de diseño dentro del ciclo de desarrollo de sistemas de base de datos relaciona!. La metodología se presenta en forma de guía paso a paso de las tres fases principales del diseño de una base de datos, que son el diseño conceptual, lógico y físico (véase la Figura 9.1). Los objetivos principales de cada fase son los siguientes: •
Diseño conceptual de la base de datos: construir la representación conceptual de la base de datos, que incluye la identificación de las entidades, relaciones y atributos más importantes.
•
Diseño lógico de la base de datos: traducción de la representación conceptual a la estructura lógica de la base de datos, lo que incluye diseñar las relaciones.
•
Diseño físico de la base de datos: decidir cómo hay que implementar físicamente la estructura lógica (en forma de relaciones base) en el sistema de gestión de bases de datos (SGBD) seleccionado.
Estructura del capítulo En la Sección 15.1 se define qué es una metodología de diseño de bases de datos y se repasan las tres fases en que el diseño de una base de datos se divide. En la Secciónl5.2 se proporciona una panorámica de la metodología y se describen brevemente las actividades principales asociadas con cada fase de diseño. En la Sección 15.3 nos centramos en la metodología utilizada para el diseño conceptual de la base de datos y presentamos una descripción detallada de los pasos requeridos para construir un modelo conceptual de los datos.
400
Sistemas de bases de datos
Se utilizarán las técnicas de modelado Entidad-Relación (ER) descritas en los Capítulos 11 y 12 para crear el modelo conceptual de los datos. En el Capítulo 16 nos centramos en la metodología del diseño lógico de base de datos para el modelo relacional y presentamos una descripción detallada para los pasos requeridos para convertir un modelo conceptual de los datos en un modelo lógico de los datos. Este capítulo también incluye un paso opcional que describe cómo combinar dos o más modelos lógicos de datos en un único modelo lógico para los casos en que se utilice la técnica de integración de vistas (véase la Sección 9.5) con el fin de abordar el diseño de una base de datos que tenga múltiples vistas de usuario. En los Capítulos 17 y 18 se completa la presentación de la metodología de diseño de base de datos proporcionando una descripción detallada de los pasos asociados con la realización del diseño físico de la base de datos para un SGBD relaciona!. Esta parte de la metodología ilustra que el desarrollo del modelo lógico de datos no es suficiente por sí mismo para garantizar una implementación óptima de un sistema de base de datos. Por ejemplo, puede que sea necesario considerar la modificación del modelo lógico para conseguir unos niveles de prestaciones aceptables. El Apéndice G presenta un resumen de la metodología de diseño de bases de datos para aquellos lectores que ya estén familiarizados con el diseño de bases de datos y simplemente quieran consultar un sumario de los pasos principales. A lo largo de nuestra presentación de la metodología, utilizamos los términos 'entidad' y 'relación' en lugar de 'tipo de entidad' y 'tipo de relación' cuando el significado sea obvio. El término 'tipo' sólo se añadirá, generalmente, para evitar las ambiguedades. En este capítulo utilizaremos principalmente ejemplos de las vistas de usuario Staff de las vistas del caso de estudio de DreamHome, documentado en la Sección lOA y en el Apéndice A.
15.1 Introducción a la metodología de diseño de bases de datos Antes de presentar la metodología, vamos a explicar lo que una metodología de diseño representa ya describir las tres fases del diseño de bases de datos. Finalmente, presentaremos una serie de directrices para realizar de la forma adecuada el diseño de una base de datos.
15.1.1 ¿Qué es una metodología de diseño? Metodología diseño
de
Un enfoque estructurado que utiliza procedimientos, técnicas, herramientas y ayudas para la generación de documentación con el fin de facilitar el proceso de diseño y servirle de soporte.
Una metodología de diseño está compuesta por una serie de fases, cada una de las cuales consta de una serie de pasos; estos pasos sirven de guía al diseñador acerca de las técnicas que resultan apropiadas en cada etapa del proyecto. Una metodología de diseño también ayuda al diseñador a planificar, gestionar, controlar y evaluar proyectos de desarrollo de bases de datos. Además, se trata de una técnica estructurada para el análisis y el modelado de un conjunto de requisitos relativos a una base de datos, los cuales se pueden así expresar de una manera estandarizada y organizada.
15.1.2 Diseño conceptual, lógico y físico de una base datos Al presentar esta metodología de diseño de base de datos, dividiremos el proceso en tres fases principales: diseño conceptual, lógico y físico de la base de datos. Diseño conceptual de la base de datos
El proceso de construcción de un modelo de los datos utilizados en una organización, independientemente de todas las consideraciones fisicas.
La fase de diseño conceptual de la base de datos comienza con la creación de un modelo conceptual de los datos de la organización, modelo que es enteramente independiente de los detalles de implementación, como
Capítulo 15 Metodología: diseño conceptual de la base de datos por ejemplo el SGBD seleccionado, los programas de aplicación, los lenguajes de programación, ma hardware, las cuestiones de rendimiento o cualquier otra consideración física. Diseño lógico de la base de datos
401
la platafor-
El proceso de construir un modelo de los datos utilizados en una organización basándose en un modelo de datos específico, pero con independencia del SGBD concreto que se vaya a utilizar y a cualquier otra consideración física.
La fase de diseño lógico de la base de datos establece una correspondencia entre el modelo conceptual y un modelo lógico, correspondencia que está influida por el modelo de datos que se utilice en la base de datos seleccionada (por ejemplo, el modelo relacional). El modelo lógico de los datos es una fuente de información para la fase de diseño físico, proporcionando al diseñador físico de la base de datos una herramienta con la que llegar a una serie de compromisos que resultan cruciales para el diseño de una base de datos efíciente. Diseño físico de la base de datos
El proceso de generar una descripción de la implementación de la base de datos en almacenamiento secundario; describe las relaciones base, la organización de los archivos y los índices utilizados para conseguir un acceso eficiente a los datos, así como cualesquiera restricciones de integridad asociadas y medidas de seguridad utilizadas.
La fase de diseño físico de la base de datos permite al diseñador tomar decisiones sobre cómo hay que implementar la base de datos. Por tanto, el diseño físico está adaptado a un SGBD específíco. Existe una cierta realimentación entre el diseño físico y el diseño lógico, porque las decisiones tomadas durante el diseño fisico para mejorar las prestaciones pueden afectar al modelo lógico de los datos.
15.1.3 Factores críticos en el diseño de una base de datos Las siguientes directrices suelen resultar críticas a la hora de diseñar de la forma adecuada una base de datos: •
Es necesario trabajar interactivamente
•
Hay que seguir una metodología estructurada durante todo el proceso de modelado de los datos.
con los usuarios lo más posible.
•
Hay que emplear una técnica centrada en los datos.
•
Es preciso incorporar las consideraciones estructurales y de integridad dentro de los modelos de datos.
•
Hay que combinar técnicas de conceptualización, metodología de modelado de los datos.
•
Es necesario emplear diagramas para representar una parte lo mayor posible de los modelos de los datos.
•
Es necesario usar un lenguaje de diseño de bases de datos (Database Design Language, DBDL) para representar información semántica acerca de los datos que no puedan representarse fácilmente en un diagrama.
•
Es preciso construir un diccionario de datos para complementar los diagramas del modelo de datos y el DBDL.
•
Hay que estar dispuestos a repetir diversos pasos en determinadas ocasiones.
normalización
y validación de transacciones
en la
Estos factores han sido tomados en consideración dentro de la metodología de diseño de base de datos que vamos a presentar.
15.2 Panorámica de la metodología de diseño de la base de datos En esta sección, se presenta una panorámica de la metodología de diseño de bases datos. Los pasos que componen la metodología son los siguientes.
402
Sistemas de bases de datos
Diseño conceptual de la base de datos Paso 1
Construir un modelo conceptual de los datos Paso 1.1 Identificar los tipos de entidad Paso 1.2 Identificar los tipos de relación Paso 1.3 Identificar y asociar los atributos con los tipos de entidad y de relación Paso lA Determinar los dominios de los atributos Paso 1.5 Determinar los atributos de clave candidata, principal y alternativa Paso 1.6 Considerar el uso de conceptos de modelado avanzados (paso opcional) Paso 1.7 Comprobar si el modelo tiene redundancia Paso 1.8 Validar el modelo conceptual comprobando las transacciones de los usuarios Paso 1.9 Repasar el modelo de datos conceptual con los usuarios
Diseño lógico de la base de datos para el modelo relacional Paso 2
Construir y validar el modelo lógico de los datos Paso 2.1 Paso 2.2
Determinar las relaciones para el modelo lógico de los datos Validar las relaciones mediante técnicas de normalización
Paso 2.3
Validar las relaciones comprobando las transacciones de los usuarios
Paso 2A
Comprobar las restricciones de integridad
Paso 2.5
Repasar el modelo lógico de los datos con los usuarios
Paso 2.6 Paso 2.7
Combinar los modelos lógicos de los datos en un modelo global (paso opcional) Verificar las consideraciones derivadas del crecimiento futuro
Diseño físico de la base de datos para bases de datos relaciona les Paso 3
Paso 4
Traducir el modelo lógico de los datos al SGBD seleccionado Paso 3.1 Diseñar las relaciones base Paso 3.2
Diseñar la representación de los datos variados
Paso 3.3
Diseñar las restricciones generales
Diseñar la organización de los archivos y los índices Paso 4.1 Analizar las transacciones Paso 4.2 Paso 4.3
Paso 5 Paso 6
Seleccionar la organización de los archivos Seleccionar los índices
Paso 4A Estimar los requisitos de espacio de disco Diseñar las vistas de usuario
Paso 7
Diseñar los mecanismos de seguridad Considerar la introducción de una cantidad controlada de redundancia
Paso 8
Monitorizar y ajustar el sistema final
Esta metodología puede utilizarse para diseñar sistemas de bases de datos relativamente simples o altamente complejos. Al igual que la etapa de diseño de la base de datos, dentro del ciclo de desarrollo de sistemas de bases de datos (véase la Sección 9.6), tiene tres fases (el diseño conceptual, lógico y fisico), también esta metodología tiene tres fases. El Paso 1 crea un diseño conceptual de la base de datos, el Paso 2 crea un diseño lógico de la base de datos y los Pasos 3 a 8 crean el diseño fisico de la base de datos. Dependiendo de la complejidad del sistema de base de datos que se esté construyendo, pueden omitirse algunos de los pasos.
Capítulo 15 Metodología: diseño conceptual de la base de datos
403
Por ejemplo, el Paso 2.6 de la metodología no es necesario en aquellos sistemas de base de datos que tengan una única vista de usuario, ni en aquellos sistemas de base de datos que tengan múltiples vistas de usuario que se estén gestionando mediante la técnica de centralización (véase la Sección 9.5). Por esta razón, sólo nos referimos a la creación de un único modelo conceptual de los datos en el Paso 1 y a un único modelo lógico de los datos en el Paso 2. Sin embargo, si el diseñador de la base de datos está utilizando la técnica de integración de vistas (véase la Sección 9.5) para gestionar las vistas de usuario de un sistema de base de datos, los Pasos 1 y 2 pueden repetirse según sea necesario hasta crear el número de modelos requerido, los cuales se combinan después en el Paso 2.6. En el Capítulo 9, hemos presentado el término 'modelo conceptual local de los datos' o 'modelo lógico local de los datos' para referimos al modelado de una o más vistas de usuario de un sistema de base de datos (pero no todas las vistas) y el término 'modelo lógico global de los datos' para hacer referencia al modelado de todas las vistas de usuario de un sistema de base de datos. Sin embargo, presentaremos nuestra metodología utilizando los términos más generales 'modelo conceptual de los datos' y 'modelo lógico de los datos', con la excepción del Paso 2.6 opcional, que necesita el uso de los términos modelo lógico local de los datos y modelo lógico global de los datos, ya que es este paso el que describe las tareas necesarias para combinar una serie de modelos lógicos locales independientes con el fin de producir un único modelo lógico global de los datos. Un aspecto importante de cualquier metodología de diseño es que debe garantizar que los modelos generados se validen de forma repetida, para que puedan continuar siendo una representación precisa de aquella parte de la organización que está siendo modelada. En esta metodología, los modelos de datos se validan de varias formas, como por ejemplo utilizando técnicas de normalización (Paso 2.2), garantizan que estén soportadas las transacciones críticas (Pasos 1.8 y 2.3) e implicando a los usuarios lo más posible (Pasos 1.9 y 2.5). El modelo lógico creado al final del Paso 2 se utiliza entonces como fuente de información para el diseño físico de la base de datos, descrito en los Pasos 3 a 8. De nuevo, dependiendo de la complejidad del sistema de base de datos que se esté diseñando y/o de la funcionalidad del SGBD seleccionado, pueden omitirse algunos pasos del diseño fisico de la base de datos. Por ejemplo, el Paso 4.2 puede no ser aplicable para ciertos SGBD basados en PC. Los pasos del diseño fisico de la base de datos se describen en detalle en los Capítulos 17 y 18. El diseño de la base de datos es un proceso iterativo, que tiene un punto de partida y una serie de refinamientos sucesivos que prácticamente no tiene fin. Aunque los pasos de la metodología se presentan aquí en forma de procedimiento, es necesario recalcar que esto no implica que deba llevarse a cabo de esta forma. Lo más probable es que el conocimiento ganado durante uno de los pasos pueda alterar las decisiones tomadas en un paso anterior. De forma similar, puede resultar útil examinar brevemente un paso posterior como ayuda para llevar a cabo un paso anterior. Por tanto, la metodología debe más bien actuar como marco de trabajo que sirva de guía y de ayuda para el diseñador a la hora de acometer un diseño de base de datos. Para ilustrar la metodología de diseño de bases de datos utilizaremos el caso de estudio de DreamHome. La base de datos de DreamHome tiene varias vistas de usuario (Director, Manager, Supervisor y Assistant) que se gestionan utilizando una combinación de las técnicas de centralización y de integración de vistas (véase la Sección lOA). Aplicando la técnica de centralización, ya hemos identificado anteriormente dos conjuntos de vistas de usuario, denominadas vistas de usuario Staff(vistas de personal) y Branch (vistas de sucursales). Las vistas de usuario representadas por cada conjunto son las siguientes: •
Vistas de usuario Staff: representan las vistas de usuario Supervisor y Assistant.
•
Vistas de usuario Branch: representan las vistas de usuario Director y Manager.
En este capítulo, se describe el Paso 1 de la metodología, utilizando las vistas de usuario Staff para ilustrar la construcción de un modelo de datos conceptual, y posteriormente, en el siguiente capítulo (que describe el Paso 2), describiremos cómo se traduce este modelo a un modelo lógico de los datos. Puesto que las vistas de usuario Staff representan únicamente un sub conjunto de todas las vistas de usuario de la base de datos de DreamHome, sería más correcto referimos a los modelos de datos como modelos locales de los datos. Sin embargo, como hemos indicado anteriormente, cuando hemos descrito la metodología y los ejemplos resueltos, utilizaremos por simplicidad los términos modelo conceptual de los datos y modelo lógico de los
404
Sistemas de bases de datos
datos hasta que lleguemos al Paso opcional 2.6, que describe la integración de los modelos locales lógicos de los datos para las vistas de usuario Staff y Branch.
15.3 Metodología de diseño conceptual de la base de datos Esta sección proporciona una guía paso a paso para el diseño conceptual de bases de datos. Paso 1 Construcción
de un modelo conceptual
Objetivo
de los datos
Construir un modelo conceptual de los datos de acuerdo con los requisitos de datos de la organización.
El primer paso en el diseño conceptual de una base de datos es construir uno o más modelos conceptuales de los datos, de acuerdo con los requisitos de datos de la organización. Un modelo conceptual de los datos comprende: •
tipos de entidad;
•
tipos de relación;
•
atributos y dominios de los atributos;
•
claves principales y claves alternativas;
•
restricciones de integridad.
El modelo conceptual de los datos está soportado en un conjunto de documentación que incluye diagramas ER y un diccionario de datos, el cual se genera al desarrollar el modelo. Detallaremos los tipos de documentación de soporte que puedan generarse a medida que vamos repasando los distintos pasos. Las tareas que comprende el Paso 1 son: Paso 1.1 Identificar los tipos de entidad Paso 1.2 Identificar los tipos de relación Paso 1.3 Identificar y asociar los atributos con los tipos de entidad y de relación Paso 1.4 Determinar los dominios de los atributos Paso 1.5 Determinar los atributos de clave candidata, principal y alternativa Paso 1.6 Considerar el uso de conceptos de modelado avanzados (paso opcional) Paso 1.7 Comprobar si el modelo tiene redundancia Paso 1.8 Validar el modelo conceptual comprobando las transacciones de los usuarios Paso 1.9 Repasar el modelo de datos conceptual con los usuarios Paso 1. 1 Identificar los tipos de entidad Objetivo
Identificar los tipos de entidad requeridos.
El primer paso a la hora de construir un modelo conceptual local de los datos es definir los objetos principales en los que los usuarios están interesados. Estos objetos son los tipos de entidad del modelo (véase la Sección 11.1). Un método para identificar las entidades consiste en examinar la especificación de requisitos del usuario. A partir de esta especificación, se identifican los nombres o frases nominales mencionados (por ejemplo, número de empleado, nombre de empleado, número de inmueble, dirección del inmueble, alquiler, número de habitaciones, etc.). También se buscan los objetos principales, como personas, lugares o concep-
Capítulo 15 Metodología: diseño conceptual de la base de datos
405
tos de interés, excluyendo aquellos nombres que sean simplemente cualidades de otros objetos. Por ejemplo, podemos agrupar el número de empleado y el nombre del empleado con un objeto o entidad denominado Staff (empleado) y agrupar el número de inmueble, la dirección del inmueble, el alquiler y el número de habitaciones con una entidad denominada PropertyForRent (inmueble en alquiler). Una forma alternativa de identificar las entidades consiste en identificar objetos que tengan existencia propia. Por ejemplo, Staff es una entidad porque los empleados existen independientemente de que conozcamos sus nombres, categoría laboral o fecha de nacimiento. Si es posible, los usuarios deberían ayudamos en esta labor. A veces resulta dificil identificar las entidades debido a la forma en que están presentadas en la especificación de requisitos del usuario. Los usuarios se expresan a menudo en términos de ejemplos o analogías. En lugar de hablar sobre empleados en general, los usuarios pueden mencionar los nombres de las personas. En algunos casos, los usuarios hablan en términos de categorías laborales, particularmente cuando hay personas u organizaciones implicadas. Estos roles pueden ser puestos de trabajo o responsabilidades, como Director, Gerente, Supervisor o Ayudante. Para confundir las cosas todavía más, los usuarios frecuentemente utilizan sinónimos y homónimos. Dos palabras son sinónimas cuando tienen el mismo significado, como por ejemplo 'sucursal' y 'oficina'. Los homónimos se presentan cuando una misma palabra puede tener diferentes significados dependiendo del contexto. Por ejemplo, la palabra 'programa' tiene varios significados alternativos, como por ejemplo una serie de sucesos, la lista de materias de un curso, un plan de trabajo o una obra que se presenta en televisión. No resulta siempre obvio si un determinado objeto es una entidad, una relación o un atributo. Por ejemplo, ¿cómo podemos clasificar el concepto de matrimonio? De hecho, dependiendo de los requisitos, podríamos clasificar un matrimonio como cualquiera de esas tres cosas. La tarea de diseño es subjetiva y los diferentes diseñadores pueden llegar a interpretaciones distintas, pero igualmente válidas. Esta tarea depende por tanto, hasta un cierto punto, del buen juicio y de la experiencia. Los diseñadores de bases de datos deben analizar las cosas con precisión y tratar de establecer categorías dentro del contexto de la organización. Por tanto, puede que no exista un único conjunto de tipos de entidad deducibles a partir de una determinada especificación de requisitos. Sin embargo, las sucesivas iteraciones del proceso de diseño deberían producir un conjunto de entidades que resulten al menos adecuadas para el sistema que se pretende diseñar. Para las vistas de usuario Staff de DreamHome identificamos las siguientes entidades: Staff (empleado)
PropertyForRent
PrivateOwner
BusinessOwner
(persona propietaria)
Client (cliente)
Preference
(inmueble) (empresa propietaria)
(preferencia)
Lease (alquiler)
Documentación
de los tipos de entidad
A medida que se identifiquen los tipos de entidad, hay que asignarles nombres que sean significativos obvios para el usuario. Dichos nombres y sus descripciones deben almacenarse en un diccionario de datos. Si es posible, hay que documentar el número esperado de instancias de cada entidad. Si una instancia se conoce con diferentes nombres, dichos nombres se denominarán sinónimos o alias, registrándoselos también en el diccionario de datos. La Figura 15.1 muestra un extracto del diccionario de datos que documenta las entidades para las vistas de usuario Staff de DreamHome. Paso 1.2 Identificar los tipos de relación Objetivo
Identificar las relaciones importantes existentes entre los tipos de entidad.
Habiendo identificado las entidades, el siguiente paso consiste en identificar todas las relaciones existentes entre dichas entidades (véase la Sección 11.2). Cuando identificamos entidades, un método consiste en buscar los nombres mencionados en la especificación de requisitos del usuario. De nuevo, podemos utilizar consideraciones gramaticales para identificar las relaciones a partir de la especificación de requisitos. Normalmente, las relaciones se indican mediante verbos o expresiones verbales. Por ejemplo:
406
Sistemas de bases de datos
Nombre de
Cada inmueble tieneun Inmueble único Alias Número de instancias sucursalconcreta. Descripción Términogeneralque empleadotrabajaen Término generalque Empleado una describe propietarioy está disponibleen una apleadosde instanteconcreto. ebles en alquiler. estar visitadopor inmueble empleado.Uninmueblepuede sucursalespecifica,dondeel alquilado es muchosclientesy gestionadoporun porun únicocliente puede ser I PropertyForRent 8taft
Figura 15.1.
Extracto del diccionario de datos para las listas de usuario Staff de DreamHome donde se muestra una descripción de las entidades.
•
8taft Manages PropertyForRent (un empleado gestiona un inmueble)
•
PrivateOwner Owns PropertyForRent (una persona propietaria posee un inmueble)
•
PropertyForRent AssociatedWith
Lease (un inmueble está asociado con un contrato de alquiler)
El hecho de que la especificación de requisitos contenga estas relaciones sugiere que son enormemente importantes para la organización y que debe incluírselas en el modelo. Sólo nos interesan las relaciones requeridas entre las entidades. En los ejemplos anteriores, hemos identificado las relaciones 8taft Manages PropertyForRent y PrivateOwner Owns PropertyForRent. También podríamos sentimos tentados de incluir una relación entre 8taft y PrivateOwner(por ejemplo, 8taft Assists PrivateOwner, es decir, un empleado atiende a un propietario). Sin embargo, aunque esta es una posible relación, si analizamos la especificación de requisitos vemos que no se trata de una relación que nos interese modelar. En la mayoría de los casos, las relaciones son binarias; en otras palabras, la relación existe entre exactamente dos tipos de entidad. Sin embargo, debemos tener cuidado para detectar las relaciones complejas que puedan implicar más de dos tipos de entidad (véase la Sección 11.2.1) y las relaciones recursivas que sólo impliquen a un único tipo de entidad (véase la Sección 11.2.2). Debemos tener cuidado también para garantizar que se expresen todas las relaciones enunciadas explícita o implícitamente en la especificación de requisitos del usuario. En principio, debería ser posible comprobar cada par de tipos de entidad, en busca de una relación potencial entre los mismos, pero en un sistema de gran tamaño compuesto por centenares de tipos de entidad sería una tarea enorme. Por otro lado, no resulta muy prudente omitir por completo dichas comprobaciones, y la responsabilidad de esta decisión suele recaer en el analistaldiseñador. De todos modos, las relaciones que falten deberían llegar a resultar aparentes cuando se valide el modelo comprobando las transacciones que hay que soportar (Paso 1.8).
Utilización
de diagramas de Entidad-Relación
(ER)
A menudo resulta más sencillo visualizar un sistema complejo, en lugar de tratar de descifrar una larga descripción textual contenida en la especificación de requisitos del usuario. Se utilizan los diagramas de EntidadRelación (ER) para representar más fácilmente las entidades y el modo en que se relacionan entre sí. Durante la fase de diseño de la base de datos, le recomendamos que utilice diagramas ER siempre que sea necesario como ayuda para construir una imagen de la parte de la organización que se esté modelando. En este libro, hemos utilizado la más reciente notación orientada a objetos, denominada UML (Unified Modeling Language, lenguaje unificado de modelado), pero hay otras notaciones que realizan una función similar (véase el Apéndice F).
Capítulo 15 Metodología: diseño conceptual de la base de datos
Determinación de las restricciones de los tipos de relación
407
de multiplicidad
Habiendo identificado las relaciones que hay que modelar, a continuación determinamos la multiplicidad de cada relación (véase la Sección 11.6). Si se conocen los valores específicos de la multiplicidad, o incluso posibles límites superiores o inferiores, hay que documentar también dichos valores. Las restricciones de multiplicidad se utilizan para comprobar y mantener la calidad de los datos. Estas restricciones son enunciados acerca de las instancias de cada entidad que pueden aplicarse cuando se actualiza la base de datos, con el fin de determinar si las actualización violan las reglas enunciadas por la organización. Un modelo que incluya las restricciones de multiplicidad más explícitamente representa las semánticas de las relaciones y los resultados, proporcionando un mejor modelo de los requisitos de datos de la empresa.
Determinación
de la existencia de trampas multiplicativas
y restrictivas
Habiendo identificado las necesarias relaciones, hay que comprobar cada una de las que se hayan incluido en el modelo ER para verificar que se trata de una representación precisa del 'mundo real' y que no se han creado inadvertidamente trampas muItiplicativas o restrictivas (véase la Sección 11.7). La Figura 15.2 muestra la primera versión del diagrama ER para las vistas de usuario Staff del caso de estudio de DreamHome.
Documentación
de los tipos de relación
A medida que se identifiquen tipos de relación, hay que asignarles nombres que son identificativos y obvios para el usuario. También hay que almacenar las descripciones de las relaciones y las restricciones de multiplicidad en el diccionario de datos. La Figura 15.3 muestra un extracto del diccionario de datos que documenta las relaciones de las vistas de usuario Staff de DreamHome . ••• Supervises
ervisee rRent ..10
-
POwns
-
'fO ..10 O..'fStaff 1' Manages 'f Preference 1..1 O .. 1.. ' 1..1 O ..' 1.1 .. States Supervisor Registers ~ ClientHoldsLease AssociatedWith 1..1 ••• Views 0 ..100
O .. '
Figura 15.2. Primera versión del diagrama ER mostrando los tipos de entidad y la relación para las vistas de usuario Staff de DreamHome.
408
Sistemas de bases de datos
Nombre de 5taft Lease AssociatedWith 0Multiplicidad 0..10 O.. 01..1 ..100 ..1 ' Nombre Relación de Multiplicidad PropertyForRent Manages Supervises
Figura 15.3.
Paso
entidad
Extracto del diccionario de datos para las vistas de usuario 8taff de DreamHome, donde se muestra una descripción de las relaciones.
1.3 Identificar y
Objetivo
-----
asociar los atributos con los tipos de entidad
y
de relación
Asociar atributos con los tipos de entidad o relación apropiados.
El siguiente paso en la metodología consiste en identificar los tipos de hechos acerca de las entidades y relaciones que hemos decidido representar en la base de datos. De forma similar a la identificación de entidades, buscaremos nombres o frases nominales dentro de la especificación de requisitos del usuario. Los atributos pueden identificarse porque el nombre o fase nominal es una propiedad, cualidad, identificador o característica de una de esas entidades o relaciones (véase la Sección 11.3). Lo mejor que podemos hacer cuando hayamos identificado una entidad (x) o una relación (y) en la especificación de requisitos es preguntamos '¿Qué información necesitamos almacenar sobre x o y?'. La respuesta a esta cuestión debería estar descrita en la especificación. Sin embargo, en algunos casos puede que sea necesario pedir a los usuarios que clarifiquen los requisitos. Desafortunadamente, los usuarios pueden dar respuestas a esta cuestión que contengan también otros conceptos, por lo que es preciso evaluar cuidadosamente dichas respuestas.
Atributos
simples/compuestos
Es importante observar si un atributo es simple o compuesto (véase la Sección 11.3.1). Los atributos compuestos están formados por una serie de atributos simples. Por ejemplo, el atributo address (dirección) puede ser simple y contener todos los detalles de una dirección en forma de un único valor, como por ejemplo' 115 Dumbarton Road, Glasgow, GIl 6YG'. Sin embargo, el atributo address podría también representar un atributo compuesto, formado por atributos simples que contengan los detalles de la dirección en forma de valores separados, como por ejemplo mediante los atributos street (' 115 Dumbarton Road'), city ('Glasgow') y postcode ('G 11 6YG'), es decir, representamos por separado la calle, la ciudad y el código postal. La decisión sobre si representar los detalles relativos a la dirección en forma de un atributo simple o compuesto estará determinada por los requisitos de usuario. Si el usuario no necesita acceder a los componentes de una dirección, representaremos el atributo address como un atributo simple. Por el contrario, si el usuario necesita acceder a los componentes individuales de la dirección, representaremos el atributo address como compuesto, formado por los atributos simples que sean necesarios. En este paso, es importante identificar todos los atributos simples que hay que representar en el modelo de datos conceptual, incluyendo aquellos atributos que formen los atributos compuestos.
Atributos
univaluados/multivaluados
Además de simples o compuestos, los atributos pueden ser univaluados o multivaluados (véase la Sección 11.3.2). La mayoría de los atributos que nos encontremos serán univaluados, pero ocasionalmente puede que aparezca algún atributo multivaluado, es decir, un atributo que contenga múltiples valores para una única instancia de entidad. Por ejemplo, podemos identificar el atributo telNo (el número de teléfono) de la entidad Client como un atributo multivaluado.
Capítulo 15 Metodología: diseño conceptual de la base de datos
409
Por otro lado, los números de teléfono de los clientes pueden haber sido identificados como una entidad independiente de Client. Esta es una forma alternativa e igualmente válida de modelar la misma información. Como veremos en el Paso 2.1, los atributos multivaluados se hacen corresponder de todos modos con relaciones, por lo que ambas técnicas producen el mismo resultado final.
Atributos derivados Los atributos cuyos valores están basados en los valores de otros atributos se conocen como atributos derivados (véase la Sección 11.3.3). Como ejemplos de atributos derivados tendríamos: •
la edad de un empleado;
•
el número de inmueble s que un empleado gestiona;
•
la fianza del alquiler (calculada como dos veces la renta mensual).
A menudo, estos atributos no se representan en el modelo de datos conceptual. Sin embargo, en ocasiones el valor del atributo o atributos en los que se basa el atributo derivado puede ser borrado o modificado. En este caso, el atributo derivado debe mostrarse en el modelo de datos para evitar esta pérdida potencial de información. En cualquier caso, si se muestra un atributo derivado en el modelo, es necesario indicar que se trata de un atributo derivado. La representación de los atributos derivados se considerará durante el diseño físico de la base de datos. Dependiendo de cómo se utilice el atributo, los nuevos valores de un atributo derivado pueden calcularse cada vez que se acceda al mismo o cuando cambien los valores de los que deriva. Sin embargo, esta cuestión no es relevante durante la etapa de diseño conceptual de la base de datos, y hablaremos de ella con mayor detalle en el Paso 3.2, en el Capítulo 17.
Problemas potenciales Cuando se identifican las entidades, relaciones y atributos para la vista, no es raro que se detecte que se han omitido una o más entidades, relaciones o atributos en la selección original. En este caso, vuelva a los pasos anteriores, documente las nuevas entidades, relaciones o atributos y examine de nuevo las relaciones asociadas. Puesto que generalmente hay muchos más atributos que entidades y relaciones, puede resultar útil producir primero una lista de todos los atributos a partir de la especificación de requisitos del usuario. A medida que se asocie cada atributo con una entidad o relación concretas, elimine el atributo de la lista. De esta forma, se puede garantizar que un atributo está asociado únicamente con un tipo de entidad o relación y que, cuando la lista esté vacía, todos los atributos están asociados con algún tipo de entidad o relación. También hay que ser consciente de que hay casos en que los atributos parecen estar asociados con más de un tipo de entidad o relación, en cuyo caso esto indicará lo siguiente: (1) Hemos identificado varias entidades que pueden representarse como una única entidad. Por ejemplo, podemos haber identificado las entidades Assistant y Supervisor con los atributos staffNo (el número de empleado), name, sex y DOS (fecha de nacimiento); podríamos haber representado ambas entidades como una única entidad denominada Staff con los atributos staffNo, name, sex, DOS y position (la categoría laboral, cuyos valores serían Assistant o Supervisor). Por otro lado, pudiera ser que estas entidades comparten muchos atributos pero que haya también atributos o relaciones que sean particulares de cada entidad. En este caso, debemos decidir si queremos generalizar las entidades para obtener una única entidad como por ejemplo Staff, o dejarlas como entidades especializadas que representen distintos tipos de empleados. Las consideraciones relativas a si conviene especializar o generalizar las entidades ya fueron explicadas en el Capítulo 12 y hablaremos con más detalles de estas cuestiones en el Paso 1.6. (2) Hemos identificado una relación entre tipos de entidad. En este caso, debemos asociar el atributo con sólo una entidad, la entidad padre, y comprobar que la relación haya sido identificada previamente en el Paso 1.2. Si no es así, habrá que actualizar la documentación con los detalles de la relación que acabamos de identificar. Por ejemplo, podríamos haber identificado las identidades Staff y PropertyForRent con los siguientes atributos:
410
Sistemas de bases de datos Staff PropertyForRent
staffNo, name, position,sex, DOS propertyNo,street, city,postcode, type, rooms, rent, managerName
La presencia del atributo managerName en PropertyForRent trata de representar la relación Staff Manages PropertyForRent (un empleado gestiona un inmueble). En este caso, el atributo managerName debe eliminarse de PropertyForRent y debe añadirse la relación Manages al modelo.
Atributos para las entidades de DreamHome Para las vistas de usuario Staff de DreamHome, identificamos y asociamos los atributos con las entidades de la forma siguiente: Staff PropertyForRent PrivateOwner SusinessOwner Client Preference Lease
staffNo, name (compuesto: fName, IName),position, sex, DOB propertyNo,address (compuesto: street, city,postcode), type, rooms, rent ownerNo, name (compuesto: fName, IName),address, telNo ownerNo, bName, bType,address, telNo, contactName clientNo,name (compuesto: fName, IName),telNo prefType,maxRent leaseNo, paymentMethod,deposit (derivado como PropertyForRentrent*2), depositPaid, rentStart, rentFinish,duration (derivado como rentFinish- rentStart)
Atributos para las relación de DreamHome Algunos atributos no deben asociarse con entidades sino con relaciones. Para las vistas de usuario Staff de DreamHome, podemos identificar y asociar los siguientes atributos con relaciones: Víews
viewDate, comment
Estos atributos indican la fecha en que se ha realizado una visita y el comentario que se ha registrado referido a la misma.
Documentación de los atributos A medida que se identifique a los atributos, hay que asignar los nombres que sean significativos para el usuario. Es necesario almacenar la siguiente información para cada atributo: •
nombre del atributo y descripción;
•
tipo de datos y longitud;
•
alias que el atributo pueda tener;
•
si el atributo es compuesto y, en caso afirmativo, los atributos simples que lo forman;
•
si el atributo es multivaluado;
•
si el atributo es derivado y, en caso afirmativo, cómo hay que calcularlo;
•
los valores predeterminados
que pueda tener el atributo.
La Figura 15.4 muestra un extracto del diccionario de datos que documenta los atributos para las vistas de usuario Staff de DreamHome. Paso 1.4 Determinar Objetivo
los dominios de los atributos Determinar los dominios de los atributos en el modelo conceptual local de los datos.
El objetivo de este paso es determinar los dominios de todos los atributos incluidos en el modelo (véase la Sección 11.3). Un dominio es un conjunto de valores que uno o más atributos pueden tomar. Por ejemplo, podemos definir:
Capítulo 15 Metodología: diseño conceptual de la base de datos
Identifica unívocamente un inmueble ... Atributos Multívaluado Nulos staffNo No 5Tipo 15 caracteres No Apellido Si Fecha Género del Sí empleado Nombre Identifica unívocamente empleado aempleado un empleado del Fecha de nacimiento propertyNo Descripción de- -datos Categoría laboral del del empleado 110caracteres carácter ovariables F) --(Mvariables - - -fName
Figura 15.4.
411 - --
y longitud
Extracto del diccionario de datos para las vistas de usuario Staff de DreamHome, donde se muestra una descripción de atributos.
•
el dominio de atributo de los números de empleado válidos (slaftNo) como compuesto por una cadena de caracteres de longitud variable y un número máximo de cinco caracteres, siendo los dos primeros caracteres letras y los siguientes uno a tres caracteres dígitos en el rango 1-999;
•
los posibles valores para el atributo sex de la entidad 81aft pueden ser 'M' o 'F'. El dominio de este atributo es una cadena formada por un único carácter compuesto de los valores 'M' or 'F'.
Un modelo de datos completamente desarrollado especificará los dominios de cada atributo e incluirá: •
el conjunto de valores permitido para el atributo;
•
los tamaños y formatos del atributo.
Podemos especificar otra información adicional para el dominio, como por ejemplo las operaciones permitidas sobre un atributo y qué atributos pueden compararse con otros atributos o usarse en combinación con otros atributos. Sin embargo, la implementación de estas características de los dominios de los atributos dentro de un SGBD sigue siendo materia de una activa investigación académica.
Documentación
de los dominios de los atributos
A medida que se identifiquen los dominios de los atributos, hay que almacenar sus nombres y características en el diccionario de datos. Actualizaremos las entradas del diccionario de datos correspondientes a los atributos, para registrar su dominio en lugar de la información referida al tipo de datos y su longitud. Paso 1.5 Determinar Objetivo
los atributos de clave candidata, principal
y
alternativa
Identificar las claves candidatas para cada tipo de entidad y, si hay más de una, seleccionar cuál debe ser la clave principal y cuáles las claves alternativas.
En este paso nos ocupamos de la identificación de las claves can didatas de cada entidad y de la selección de una de ellas como clave principal (véase la Sección 11.3.4). Una clave candidata es un conjunto mínimo de atributos de una entidad que identifican unívocamente cada instancia de dicha entidad. Podemos identificar más de una clave candidata, en cuyo caso deberemos seleccionar una de ellas como clave principal; las claves candidatas restantes se denominan claves alternativas. Los nombres de las personas no suelen ser buenas claves candidatas. Por ejemplo, podríamos pensar que una clave candidata adecuada para la entidad 81aft sería el atributo compuesto name, que es el nombre del empleado. Sin embargo, es posible que haya dos personas con el mismo nombre trabajando para DreamHome, lo que invalidaría claramente la elección de name como clave candidata. Podríamos decir lo mismo de los
412
Sistemas de bases de datos
nombres de los propietarios registrados en la base de datos de DreamHome. En tales casos, en lugar de buscar una combinación de atributos que proporcione esa unicidad, puede ser más conveniente utilizar un atributo existente que siempre le garantice la unicidad, como por ejemplo el atributo staffNo(número de empleado) para la entidad Staff y el atributo ownerNo (número de propietario) para la entidad PrivateOwner, o definir un nuevo atributo que garantice la unicidad. A la hora de seleccionar la clave principal de entre las claves candidatas, utilizaremos las siguientes directrices como ayuda para tomar la decisión: •
la clave candidata con el número mínimo de atributos;
•
la clave candidata cuyos valores sea menos probable que cambien;
•
la clave candidata con menor número de caracteres (para aquellas que tengan atributos textuales);
•
la clave can didata que tenga el valor máximo más pequeño (para aquellas que tengan atributos numéricos);
•
la clave candidata que sea más fácil de utilizar desde un punto de vista del usuario.
En el proceso de identificación de las claves principales, observe si cada entidad es fuerte o débil. Si se puede asignar una clave principal a una entidad, diremos que la entidad esfuerte. Por el contrario, si no somos capaces de identificar una clave principal para una entidad, diremos que esa entidad es débil (véase la Sección 11A). La clave principal de una entidad débil sólo podrá ser identificada cuando se haga corresponder la entidad débil y su relación con su entidad propietaria con una relación, mediante la inclusión de una clave externa en dicha relación. El proceso de hacer corresponder entidades y sus relaciones con otras relaciones se describe en el Paso 2.1 y, por tanto, la identificación de las claves principales de las entidades débiles no puede tener lugar hasta que lleguemos a dicho paso.
Claves principales de DreamHome Las claves principales de las vistas de usuario Staff de DreamHome se muestran en la Figura 15.5. Observe que la entidad Preference es una entidad débil y, como hemos dicho anteriormente, que la relación Views tiene dos atributos viewDate y comment.
Documentación
de las claves principales y alternativas
Hay que almacenar la identificación de las claves principales y alternativas en el diccionario de datos. Paso 1.6 Considerar Objetivo
el uso de conceptos de modelado
avanzados
(paso opcionalj
Considerar el uso de conceptos de modelado avanzados, como por ejemplo los conceptos de especialización/generalización, agregación y composición.
En este paso, tenemos la opción de continuar el desarrollo del modelo ER utilizando los conceptos de modelado avanzado explicados en el Capítulo 12, es decir, la especialización/generalización, la agregación y la composición. Si seleccionamos la técnica de especialización, trataremos de resaltar las diferencias entre entidades definiendo una o más subclases de una entidad superclase. Si seleccionamos la técnica de generalización, trataremos de identificar características comunes entre entidades para definir una entidad superclase generalizad ora. Podemos utilizar la agregación para representar una relación del tipo 'tiene' o 'es parte de' entre tipos de entidad, donde una de las entidades representará el 'todo' y la otra la 'parte'. Podemos utilizar la composición (un tipo especial de agregación) para representar una asociación entre tipos de entidad en la que existe una pertenencia fuerte y un tiempo de vida coincidente entre el 'todo' y la 'parte'. Para las vistas de usuario Staff de DreamHome, decidimos generalizar las dos entidades PrivateOwner y BusinessOwner con el fin de crear una superclase Owner que contenga los atributos comunes ownerNo, address y telNo. La relación que la superclase tiene con sus sub clases es obligatoria y disjunta, lo que se denota mediante la etiqueta {Mandatory, Or}; cada miembro de la superclase Owner debe ser miembro de una de las subclases, pero no puede pertenecer a ambas.
Capítulo 15 Metodología: diseño conceptual de la base de datos
413
..••Supervises
"
POwns PrivateOwner
"
viewDate 1 .. 01 ..comment -1..1Client Lease ..1 0Preference .. - Staff 1..1 :c1ientNo 1 Manages .10 ..0 10 ..Supervisor O." Supervisee AssociatedWith 0 ..10 ~ staffNo ..••Views Registers Holds States PropertyForRent 1 ..1
"
O."
leaseNo
0 ..100
Figura 15.5.
Diagrama ER para las vistas de usuario 8taft de DreamHome, después de añadir las claves principales.
Además, identificamos una subclase especializada de 8taff, la clase Supervisor, específicamente con la intención de modelar la relación Supervises. La relación que la superclase Staff tiene con la subclase Supervisor es opcional: un miembro de la superclase Staff no tiene por qué ser necesariamente miembro de la subclase Supervisor. Para mantener la simplicidad del diseño, decidimos no utilizar agregación ni composición. El diagrama ER revisado para las vistas de usuario Staff de DreamHome se muestran en la Figura 15.6. No existen directrices estrictas sobre cuándo debe desarrollarse todavía más el modelo ER utilizando conceptos de modelado avanzados, ya que esta decisión es a menudo subjetiva y depende de las características particulares de la situación que se quiera modelar. Como regla práctica útil a la hora de considerar el uso de estos conceptos, trate siempre de representar las entidades importantes y sus relaciones de la forma más clara posible en el diagrama ER. Por tanto, la utilización de los conceptos de modelado avanzados debe guiarse por la legibilidad del diagrama ER y por la claridad con la que éste modela las entidades importantes y sus relacIOnes. Estos conceptos están asociados con el modelado ER avanzado. Sin embargo, ya que este caso es opcional, simplemente utilizaremos el término 'diagrama ER' en toda esta metodología para referimos a la representación diagramática de los modelos de datos. Paso 1.7 Comprobar Objetivo
si el modelo tiene redundancia Comprobar la presencia de redundancia en el modelo.
En este caso, examinamos el modelo conceptual local de los datos con el objetivo específico de identificar si hay algo de redundancia y eliminar la que pueda existir. Las dos actividades que componen este paso son: (1) Reexaminar a examinar las relaciones uno a uno (1: 1); (2) eliminar las relaciones redundantes; (3) considerar la dimensión temporal.
1'f
414
Sistemas de bases de datos
0 ..1100 Owns 1.. 'f Manages Supervises 0 .. 10 0 .. 1 Owner PrivateOwner I
-
1..10 ..* Preference Lease Client : 'f Slaff comment viewDate Supervisor 1 ..'fHolds 1BusinessOwner 1..1 1 ..Regislers 1V ..•• c1ientNo 0 ..* 0 ..* 0iews ..* ~ 0 ..*leaseNo AssociatedWith ~States {Oplional}
Figura 15.6. Diagrama ER revisado para las vistas de usuario Staff de DreamHome, habiendo procedido a aplicar las técnicas de especialización/generalización.
(1) Reexaminar a examinar las relaciones uno a uno (1: 1) En la identificación de entidades, podemos haber identificado dos entidades que representen el mismo objeto en la organización. Por ejemplo, podemos haber identificado las dos entidades Client (cliente) y Renter (inquilino), siendo las dos entidades realmente la misma. En otras palabras, Client es un sinónimo de Renter. En este caso, las dos entidades deben combinarse. Si las claves principales son distintas, seleccione una de ellas como clave principal y deje la otra como clave alternativa.
(2) Eliminar las relaciones redundantes Una relación es redundante si puede obtenerse la misma información a través de otras relaciones. Estamos tratando de desarrollar un modelo de datos mínimo y, ya que las relaciones redundantes son innecesarias, será preciso que las eliminemos. Resulta relativamente fácil identificar si hay más de un camino entre dos entidades. Sin embargo, esto no implica necesariamente que una de las relaciones sea redundante, ya que ambas relaciones pueden representar asociaciones diferentes entre las entidades. Por ejemplo, considere las relaciones entre las entidades PropertyForRent, Lease y Client que se muestran en la Figura 15.7. Hay dos formas de averiguar qué clientes alquilan cada inmueble. Existe la ruta directa que utiliza la relación Rents entre las entidades Client y PropertyForRent y existe otra ruta indirecta que utiliza las relaciones Holds y AssociatedWith a través de la entidad Lease. Antes de poder verificar si ambas rutas son necesarias, es preciso establecer el propósito de cada relación. La relación Rents indica qué cliente alquila cada inmueble. Por otro lado, la relación
Capítulo 15 Metodología: diseño conceptual de la base de datos
Eliminación de la relación redundante denominada Rents
1•
Lease0 ..0* .. * Client c1ientNo 0.* ..••Rents
1..1 pertyNo With 0 .. *
•
415
1..1
...
Holds
PropertyForRent leaseNo
Assoc
Figura 15.7.
Eliminación de la relación redundante denominada
Rents.
Holds indica qué cliente ha firmado un contrato de alquiler y la relación AssociatedWith indica qué inmueble está asociado con cada contrato. Aunque es cierto que existe una relación entre los clientes y las propiedades que alquilan, no es una relación directa y la asociación se puede representar de manera más precisa a través de un contrato de alquiler. La relación Rents es, por tanto, redundante y no proporciona ninguna información adicional acerca de la relación entre PropertyForRent y Client que no pueda ser determinada más correctamente a través de la entidad Lease. Para garantizar que se cree un modelo mínimo, será necesario eliminar la relación redundante Rents.
(3) Considerar la dimensión temporal La dimensión temporal de las relaciones es importante a la hora de verificar si existe redundancia. Por ejemplo, considere la situación en la que queremos modelar las relaciones entre las entidades Man, Woman y Child, como se ilustra en la Figura 15.8. Claramente, existen dos rutas entre Man (hombre) y Child (hijo): una a través de la relación directa FatherOf (padre) y la otra a través de la relaciones MarriedTo (casado con) y MotherOf (madre). En consecuencia, podríamos pensar que la relación FatherOf es innecesaria. Sin embargo, esto sería incorrecto por dos razones: (1) El padre puede tener hijos de un matrimonio anterior, y nosotros únicamente estamos modelando el matrimonio actual del padre a través de una relación 1:l. (2) El padre y la madre pueden no estar casados, o el padre puede estar casado con alguna otra mujer distinta de la madre (o la madre puede estar casada con algún otro hombre distinto del padre). Woman Man Child MarriedTo •. 0 ..* 0 .. 1
1 .. 1
•
MotherOf
0 1.. ..1 1 0 ..*
Figura 15.8.
Ejemplo de una relación FatherOf no redundante.
416
Sistemas de bases de datos
En cualquiera de los dos casos la relación requerida no podría modelarse sin la relación FatherOf. La conclusión es que resulta importante examinar el significado de cada relación entre las entidades a la hora de verificar si hay redundancia. Al final de este paso, habremos simplificado el modelo conceptual local de los datos eliminando todas las redundancias inherentes. Paso 1.8 Validar el modelo conceptual Objetivo
comprobando
las transacciones
de los usuarios
Garantizar que el modelo conceptual soporte las transacciones
requeridas.
Ahora disponemos de un modelo conceptual local de los datos que representa los requisitos de datos de la organización. El objetivo de este paso es verificar el modelo para garantizar que soporte las transacciones requeridas. Utilizando el modelo, trataremos de realizar la operación manualmente. Si podemos resolver todas las transacciones de esta forma, habremos comprobado que el modelo de datos conceptual soporta las transacciones requeridas. Sin embargo, si no somos capaces de realizar una transacción manualmente, ello querrá decir que existe algún problema con el modelo de datos, problema que habrá que resolver. En este caso, es probable que hayamos omitido alguna entidad, alguna relación o un atributo en el modelo de datos. Vamos a examinar dos posibles técnicas para garantizar que el modelo de datos conceptual soporte las transacciones requeridas (1) descripción de las transacciones; (2) utilización de las rutas de las transacciones.
Descripción de las transacciones Utilizando la primera de las dos técnicas, comprobamos que toda la información (entidades, relaciones y sus atributos) requerida por cada transacción está proporcionada en el modelo, para lo cual documentamos una descripción de los requisitos de cada transacción. Ilustraremos esta técnica para una transacción de ejemplo de DreamHome enumerada en el Apéndice A y correspondiente a las vistas de usuario Staff: Transacción (d) Proporcionar empleado en la sucursal
los detalles de los inmuebles gestionados
por un determinado
Los detalles de los inmuebles se almacenan en la entidad PropertyForRent y los detalles de los empleados que gestionan inmuebles están contenidos en la entidad Staff. En este caso, podemos utilizar la relación Staff Manages PropertyForRent para generar el listado requerido.
Utilización
de las rutas de las transacciones
La segunda técnica para validar el modelo de datos comprobando si soporta las transacciones requeridas implica representar diagramáticamente la ruta tomada por cada transacción, dibujándola directamente en el diagrama ER. En la Figura 15.9 se muestra un ejemplo de esta técnica para las transacciones de consulta utilizadas en las vistas de usuario Staff y enumeradas en el Apéndice A. Claramente, cuantas más transacciones existan, más complejo se volverá este diagrama, así que puede que sea necesario disponer de varios diagramas para cubrir todas las transacciones, con el fin de mantener la legibilidad. Esta técnica permite al diseñador visualizar áreas del modelo que no sean necesarias para las transacciones y aquellas otras áreas que sean críticas para las mismas. Esto nos permite revisar directamente el soporte que el modelo de datos proporciona a las transacciones requeridas. Si hay áreas del modelo que no parecen ser utilizadas por ninguna transacción, podemos cuestionamos el propósito de representar esta información en el modelo de datos. Por otro lado, si hay áreas del modelo que resultan inadecuadas para proporcionar la ruta correcta para una transacción, será preciso investigar la posibilidad de que se hayan omitido identidades, relaciones o atributos críticos. Puede parecer una tarea enormemente laboriosa el comprobar de este modo cada transacción que el modelo tiene que soportar, y efectivamente puede ser así. Como resultado, podríamos sentimos tentados de omitir este paso, pero es muy importante que se realicen estas comprobaciones ahora en lugar de dejadas para más adelante, cuando sería mucho más difícil y más caro resolver los posibles errores que se detectaran en el modelo de datos.
Capítulo 15 Metodología: diseño conceptual de la base de datos
+
,..-(f)
Owns Supervises ent I
-
~
, Client ,States viewDate eomment "(d) c1ientNo Lease leaseNo Preferenee BusinessOwner •(h),-::-l Supervisor Holds (m)" ;:J(b) (i) •••'\7 Views AssoeiatedWith (k) (m) Staff (e) I (j) Registers ~
Figura 15.9.
Paso 1.9 Repasar Objetivo
417
Utilización de las rutas de transacción conceptual soporta las transacciones
el modelo de datos conceptual
para comprobar que el modelo de los usuarios.
con los usuarios
Revisar el modelo conceptual de los datos con los usuario para comprobar si éstos consideran el modelo como una representación 'verdadera' de los requisitos de datos de la organización.
Antes de completar el Paso 1, revisamos el modelo conceptual de los datos con el usuario. El modelo conceptual de los datos incluye el diagrama ER y la documentación de soporte que describe el modelo. Si hay alguna anomalía en el modelo de datos, será necesario realizar los cambios apropiados, lo cual puede requerir que se repitan algunos de los pasos anteriores. Deberemos repetir este proceso hasta que el usuario esté dispuesto a 'autorizar' el modelo, considerándolo como una representación 'verdadera' de la parte de la organización que estamos modelando. Los pasos de esta metodología se resumen en el Apéndice F. El siguiente capítulo describe los pasos relativos a la metodología del diseño lógico de la base de datos.
Resumen del capítulo •
Una metodología de diseño es un enfoque estructurado que utiliza procedimientos, tas y ayudas documentales para facilitar el proceso de diseño y dado soporte.
técnicas, herramien-
418
Sistemas de bases de datos
•
El diseño de una base de datos incluye tres fases principales: diseño conceptual, de datos.
lógico y físico de la base
•
El diseño conceptual de la base de datos es el proceso de construir un modelo de los datos utilizado en una organización, de forma independiente de todas las consideraciones físicas.
•
El diseño conceptual de la base de datos comienza con la creación de un modelo conceptual de los datos de la organización, el cual es enteramente independiente de detalles de implementación tales como el SGBD seleccionado, los programas de aplicación, los lenguajes de programación, la plataforma hardware, cuestiones de rendimiento o cualquier otra consideración física.
•
El diseño lógico de la base de datos es el proceso de construir un modelo de los datos utilizados en una empresa basado en un modelo de datos específíco (como por ejemplo el modelo de datos relacional), pero de forma independiente de cualquier SGBD concreto y de otras consideraciones físicas. El diseño lógico de la base de datos traduce el modelo conceptual de los datos a un modelo lógico de los datos de la organización.
•
El diseño físico de la base de datos es el proceso de producir una descripción de la implementación de la base de datos en el almacenamiento secundario; describe las relaciones base, la organización de los archivos y de los índices utilizados para conseguir un acceso eficiente a los datos y cualesquiera restricciones de integridad asociadas y medidas de seguridad implementadas.
•
La fase de diseño físico de la base de datos permite al diseñador tomar decisiones sobre cómo hay que implementar la base de datos. Por tanto, el diseño físico está adaptado a un SGBD concreto. Existe una cierta realimentación entre el diseño físico y el diseño conceptual/lógico, porque las decisiones que se tomen durante el diseño físico para mejorar las prestaciones pueden afectar a la estructura del modelo conceptual/lógico de los datos.
•
Hay varios factores críticos que determinan el éxito de la etapa de diseño de la base de datos, incluyendo por ejemplo el trabajar interactivamente con los usuarios y estar dispuesto a repetir los pasos cuando sea necesano.
•
El objetivo principal del Paso 1 de la metodología consiste en construir un modelo conceptual adecuado a los requisitos de datos de la organización. Un modelo conceptual de los datos comprende: tipos de entidad, tipos de relación, atributos, dominios de atributos, claves principales y claves alternativas.
•
Un modelo conceptual de los datos está soportado en una serie de documentos, como diagramas ER y un diccionario de datos, que se generan durante el desarrollo del modelo.
•
El modelo conceptual de los datos se valida para garantizar que soporte las transacciones requeridas. Hay dos técnicas posibles para garantizar que el modelo conceptual de los datos soporte las transacciones necesarias: (1) comprobar que toda la información (entidades, relaciones y sus atributos) requerida por cada transacción está incluida en el modelo, documentando una descripción de los requisitos de cada transacción; (2) representar diagramáticamente la ruta que cada transacción toma, dibujándola directamente en el diagrama ER.
Cuestiones de repaso 15.1.
Describa el propósito de una metodología de diseño.
15.2.
Describa las fases principales del diseño de una base de datos.
15.3.
Identifique diversos factores de importancia para que el diseño de una base de datos resulte adecuado.
15.4.
Explique el importante papel que juegan los usuarios en el proceso de diseño de una base de datos.
15.5.
Describa el objetivo principal del diseño conceptual de la base de datos.
15.6.
Identifique los pasos principales asociados con el diseño conceptual de la base de datos.
15.7.
¿Cómo identificaría los tipos de entidad y los tipos de relación a partir de la especificación de requisitos del usuario?
Capítulo 15 Metodología: diseño conceptual de la base de datos
419
15.8. ¿Cómo identificaría los atributos a partir de la especificación de requisitos del usuario y cómo asociaría luego los atributos con los tipos de entidad o de relación? 15.9. Describa el propósito de la técnica de especialización/generalización de los tipos de entidad y explique por qué es un paso opcional en el diseño conceptual de la base de datos. 15.10. ¿Cómo comprobaría si hay redundancia en un modelo de datos? Proporcione un ejemplo para ilustrar su respuesta. 15.11. Explique por qué es conveniente validar el modelo de datos conceptual y describa dos técnicas para validar dicho modelo. 15.12. Identifique y describa el propósito de la documentación base de datos.
generada durante el diseño conceptual de la
Ejercicios El caso de estudio de DreamHome 15.13. Cree un modelo conceptual de los datos para las vistas de usuario Branch de DreamHome que se documentan en el Apéndice A. Compare su diagrama ER con la Figura 12.8 y justifique las diferencias que encuentre. 15.14. Demuestre que todas las transacciones de consulta para las vistas de usuario Branch de DreamHome que se enumeran en el Apéndice A están soportadas por su modelo de datos conceptual. El caso de estudio
University Accommodation Office
15.15. Proporcione una especificación de reqUlsltos de usuario Accommodation Office documentado en el Apéndice B.1.
para el caso de estudio
University
15.16. Cree un modelo conceptual de los datos para el caso de estudio. Indique cualquier suposición necesaria en la que haya basado su diseño. Compruebe que el modelo conceptual de los datos soporta las transacciones requeridas. El caso de estudio EasyDrive School of Motoring 15.17. Proporcione una especificación de requisitos del usuario para el caso de estudio EasyDrive School of Motoring documentado en el Apéndice B.2. 15.18. Cree un modelo conceptual de los datos para el caso de estudio. Indique cualquier suposición necesaria en la que haya basado su diseño. Compruebe que el modelo conceptual de los datos soporta las transacciones requeridas. El caso de estudio Wellmeadows Hospital 15.19. Identifique las vistas de usuario para el Director médico (Medical Director) y la lefa de enfermeras (Charge Nurse) en el caso de estudio Wellmeadows Hospital que se describe en el Apéndice B.3. 15.20. Proporcione una especificación de requisitos del usuario para cada una de estas vistas de usuario. 15.21. Cree modelos de datos conceptuales para cada una de las vistas de usuario. Indique cualquier suposición necesaria en la que haya basado su diseño.
Capítulo
Metodología: diseño lógico de bases de datos para el modelo relacional
Objetivos del capítulo: En este capítulo aprenderá: • •
Cómo derivar un conjunto de relaciones a partir de un modelo conceptual de los datos. Cómo validar estas relaciones utilizando la técnica de normalización.
•
Cómo validar un modelo lógico de los datos para garantizar que soporta las transacciones requeridas.
•
Cómo combinar modelos lógicos locales de los datos basados en una o más vistas de usuario para obtener un modelo lógico global de los datos que represente todas las vistas.
•
Cómo garantizar que el modelo lógico final de los datos sea una representación verdadera y precisa de los requisitos de datos de la organización.
En el Capítulo 9 hemos descrito las etapas principales del ciclo de desarrollo de sistemas de bases de datos, una de las cuales es el diseño de la base de datos. Dicha etapa está compuesta de tres fases: diseño conceptual, lógico y físico de la base de datos. En el capítulo anterior hemos presentado una metodología que describe los pasos que forman las tres fases del diseño de base de datos y luego hemos analizado el Paso 1 de dicha metodología, dedicado al diseño conceptual de la base de datos. En este capítulo se describe e~ Paso 2 de dicha metodología, que traduce a un modelo lógico de los datos el modelo conceptual producido en el Paso l. La metodología de dicho modelo lógico de base de datos que se describe en este libro incluye también un Paso 2.6 opcional, que es necesario cuando la base de datos tenga múltiples vistas de usuario que se gestionen utilizando la técnica de integración de vistas (véase la Sección 9.5). En este caso, repetiremos los Pasos 1 a 2.5 según sea necesario para crear el número requerido de modelos lógicos locales de los datos, que después se combinan finalmente en el Paso 2.6 para formar un modelo lógico global de los datos. Un modelo lógico local de los datos representa los requisitos de datos de una o más vistas del usuario de una base de datos (pero no de todas las vistas), mientras que un modelo lógico global de los datos representa los requisitos de datos de todas las vistas de usuario (véase la Sección 9.5). Sin embargo, una vez que hayamos terminado el Paso 2.6, dejaremos de utilizar el término 'modelo lógico global de los datos' y nos referiremos simplemente al modelo final como un 'modelo lógico de los datos', sin más precisiones. El paso final de la fase de diseño lógico de la base de datos es considerar hasta qué punto el modelo es capaz de soportar los posibles desarrollos futuros del sistema de base de datos. Es el modelo lógico de los datos creado en el Paso 2 lo que constituye el punto de partida para el diseño fisico de la base de datos, que se describe en los Pasos 3 a 8 dentro de los Capítulos 17 y 18. En toda nuestra exposición sobre la metodología, utilizaremos los términos 'entidad' y 'relación' en lugar de 'tipo de entidad' y 'tipo de relación' cuando el significado sea obvio. Sólo añadiremos el términos 'tipo' cuando sea necesario para evitar posibles ambiguedades.
422
Sistemas de bases de datos
16.1 Metodología de diseño lógico de bases de datos para el modelo relacional Esta sección describe los pasos de la metodología de diseño lógico de bases de datos para el modelo relacional. Paso 2 Construir
y validar
Objetivo
el modelo lógico de los datos
Traducir el modelo de datos conceptual en un modelo lógico de los datos y después validar este modelo para comprobar que sea estructural mente correcto y capaz de soportar las transacciones requeridas.
En este paso, el objetivo principal es traducir el modelo conceptual de los datos creado en el Paso 1 a un modelo lógico de los datos que represente los requisitos de datos de la organización. Este objetivo se consigue mediante la siguiente lista de tareas: Paso 2.1 Paso 2.2
Determinar las relaciones para el modelo lógico de los datos. Validar las relaciones mediante técnicas de normalización.
Paso 2.3
Validar las relaciones comprobando las transacciones de los usuarios.
Paso 2.4
Comprobar las restricciones de integridad.
Paso 2.5
Repasar el modelo lógico de los datos con los usuarios.
Paso 2.6 Paso 2.7
Combinar los modelos lógicos de los datos en un modelo global (paso opcional). Verificar las consideraciones derivadas del crecimiento futuro.
Comenzaremos derivando un conjunto de relaciones (esquema relacional) a partir del modelo conceptual de los datos creado en el Paso 1. La estructura del esquema relacional se valida utilizando técnicas de normalización y luego se comprueba para garantizar que las relaciones sean capaces de soportar las transacciones indicadas en la especificación de requisitos del usuario. A continuación comprobamos que estén representadas en el modelo lógico de los datos todas las restricciones de integridad importantes. En esta etapa, se valida el modelo lógico de los datos junto con los usuarios para comprobar que éstos consideran el modelo como una representación precisa de los requisitos de datos de la organización. Presentaremos la metodología correspondiente al Paso 2 de modo que sea aplicable tanto al diseño de sistemas de bases de datos simples como sistemas complejos. Por ejemplo, para crear una base de datos con una única vista de usuario o con múltiples vistas de usuario que se gestionen utilizando el enfoque centralizado (véase la Sección 9.5), se omitirá el Paso 2.6. Por el contrario, si la base de datos tiene múltiples vistas de usuario que se gestionan utilizando la técnica de integración de vistas (véase la Sección 9.5), será necesario repetir los Pasos 2.1 a 2.5 para los distintos modelos de datos, cada uno de los cuales representa diferentes vistas de usuario del sistema de la base de datos. Dichos modelos de datos se combinan en el Paso 2.6. El Paso 2 concluye con una evaluación del modelo lógico de los datos, que puede o no haber requerido llevar a cabo el Paso 2.6; en dicha evaluación se busca garantizar que el modelo final sea capaz de soportar posibles desarrollos futuros. Al completar el Paso 2, dispondremos de un único modelo lógico de los datos que será una representación correcta, completa y no ambigua de los requisitos de datos de la organización. Ilustraremos el Paso 2 utilizando el modelo conceptual de los datos creado en el capítulo anterior para las vistas de usuario Staff del caso de estudio de DreamHome, modelo conceptual que se representa en la Figura 16.1 en forma de diagrama ER. También usaremos las vistas de usuario Branch de DreamHome, que están representadas en la Figura 12.8 en forma de diagrama ER, para ilustrar algunos conceptos que no están presentes en las vistas de usuario Staff y para ilustrar la combinación de modelos de datos en el Paso 2.6. Paso 2. 1 Determinar Objetivo
las relaciones para el modelo lógico de los datos
Crear tablas relacionales para el modelo lógico de los datos que representen entidades, relaciones y atributos que se hayan identificado.
las
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
423
En este paso, vamos a derivar las tablas relacionales para el modelo lógico de los datos con las que representar las entidades, relaciones y atributos. Describiremos la composición de cada tabla relacional utilizando un lenguaje de definición de bases de datos (Database Definition Language, DBDL) para bases de datos relacionales. Empleando el DBDL, especificaremos primero el nombre de la tabla relacional seguido de una lista de los atributos simples de la relación encerrados entre corchetes. Después identificaremos la clave principal y las posibles claves alternativas y/o externas de la relación. Después de identificar una clave externa, se indicará la tabla relacional que contiene la clave principal a la que se hace referencia. También se indican los atributos derivados, junto con las instrucciones para calcular cada uno. Las relaciones que una entidad tenga con otras se representan mediante el mecanismo de clave principal/clave externa. Al decidir dónde situar los atributos de clave externa, debemos primero identificar las entidades 'padre' e 'hija' implicadas en la relación. La entidad padre es la entidad que proporciona su clave principal a la tabla relacional que representa la entidad hija, con el fin de que actúe en ella como clave externa.
Vamos a describir cómo derivar las tablas relacionales para las siguientes estructuras que pueden aparecer en un modelo de datos conceptual: (1) tipos de entidad fuertes; (2) tipos de entidad débiles; (3) tipos de relación binaria uno a muchos (1 :*); (4) tipos de relación binaria uno a uno (1: 1); (5) tipos de relación recursiva uno a uno (1:1); (6) tipos de relación superclase/subclase; (7) tipos de relación binaria muchos a muchos (*:*); (8) tipos de relaciones complejas; (9) atributos multivaluados. Para la mayoría de los ejemplos que vamos a presentar, utilizaremos el modelo conceptual de datos correspondientes a las vistas de usuario Staff de DreamHome, que está representado en forma de diagrama ER en la Figura 16.1.
(1) Tipos de entidad fuertes Para cada entidad fuerte del modelo de datos, crearemos una tabla relacional que incluya todos los atributos simples de dicha entidad. Para los atributos compuestos, como name, incluiremos únicamente en la tabla los atributos simples componentes, que en este caso son fName y IName. Por ejemplo, la composición de la relación 81aff mostrada en la Figura 16.1 es: 513ff (slaffNo, fName,
IName, posilion, sex, DOB)
Clave principal staffNo
(2) Tipos de entidad débiles Para cada entidad débil del modelo de datos, crearemos una tabla que incluya todos los atributos simples de dicha entidad. La clave principal de una entidad débil se deriva parcial o totalmente a partir de cada entidad propietaria, por lo que la identificación de la clave principal de una entidad débil no puede llevarse a cabo hasta que se hayan obtenido las tablas correspondientes a todas las relaciones existentes con las entidades propietarias. Por ejemplo, la entidad débil Preference en la Figura 16.1 se asigna inicialmente a la siguiente tabla relacional: Preference
(prefType, maxRenl)
Clave principal Ninguna (por el momento)
424
Sistemas de bases de datos
l' rentStart /deposit 1..1 , , Staff 0IName ..*bName comment Lease Client viewDate postcode name rent 0Preference ..* Supervisor 1..1 fName 1..1 BusinessOwner maxRent 0 ..* telNo :l' 0 ..*{PK} Holds States bType depositPaid leaseNo {PK}prefType l'contactName paymentMethod ..••Views 0 ..*{Optional} clientNo Registers ~ 1..1 0 ..100 1..1 DOB fName 1..1 .me l' sex IName /duration Manages position rentFinish name 0 ..10 ' Supervises 0..1 e r}
\7
-
Figura 16.1.
Modelo conceptual de los datos para las vistas de usuario Staff, donde se muestran todos los atributos.
En esta situación, la clave principal de la relación la relación States se haya asignado apropiadamente.
Preference
no se puede identificar hasta después de que
(3) Tipos de relaciones binarias uno a muchos (1 :*) Para cada relación binaria 1:*, designamos como entidad padre a la entidad situada en el 'lado uno' de la relación, mientras que la entidad situada en el 'lado muchos' se denomina entidad hija. Para representar esta relación, incluimos una copia de los atributos de clave principal de la entidad padre en la tabla relacional que represente a la entidad hija, con el fin de que actúe como clave externa.
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
425
Por ejemplo, la relación 8taff Registers Client mostrada en la Figura 16.1 es una relación 1:*, ya que un mismo empleado puede registrar a muchos clientes. En este ejemplo, 8taff está en el 'lado uno' y representa la entidad padre, mientras que Client está en el 'lado muchos' y representa la entidad hija. La relación existente entre estas entidades se establece situando una copia de la clave principal de la entidad (padre) 8taff, staffNo, dentro de la tabla relacional (hija) Client. La composición de las tablas 8taff y Client será: Se incluyestaftNo
en Client
para modelarla relación1:* Registers
Staft (staffNo,fName,Name,position,sex, DOS) Clave principal staffNo
Client (c1ientNo, fName,IName,telNo,staffNo) Clave principal c1ientNo Clave alternativa telNo Clave externa
staffNohace
referencia a
StaffNo(staffNo)
En caso de que una relación 1:* tenga uno o más atributos, estos atributos deben también incluirse en la tabla hija junto con la clave principal. Por ejemplo, si la relación Staff Registers Client tuviera un atributo denominado dateRegister que representara la fecha en la que el empleado registra al cliente, este atributo también debería incluirse en la relación Clientjunto con la copia de la clave principal de la relación 8taff, que es el atributo staffNo.
(4) Tipos de relaciones binarias uno a uno (1:1) La creación de tablas relacionales para representar relaciones 1:1 es ligeramente más compleja, ya que no podemos usar la cardinalidad para identificar las entidades padre e hija de la relación. En lugar de ello, se emplean las restricciones de participación (véase la Sección 11.6.5) a la hora de decidir si es mejor representar la relación combinando las entidades implicadas en una única tabla relacional o crear dos tablas relacionales y colocar una copia de la clave principal de la tabla en la otra. Vamos a ver cómo crear tablas que permitan representar las siguientes restricciones de participación: (a) participación obligatoria en ambos lados de la relación 1: 1; (b) participación obligatoria en un lado de la relación 1: 1; (c) participación opcional en ambos lados de la relación 1: 1.
(a) Participación obligatoria en ambos lados de la relación 1: 1 En este caso, debemos combinar las entidades implicadas en una única tabla relacional y elegir una de las claves principales de las entidades originales como clave principal de la nueva tabla, mientras que la otra (si existe) se utiliza como clave alternativa. La relación Client States Preference (el cliente indica una referencia) es un ejemplo de relación 1: 1 con participación obligatoria en ambos lados. En este caso, decidimos combinar las dos tablas para obtener la siguiente tabla relacional Client: Client (c1ientNo,fName, ¡Name,telNo, prefType,maxRent, staffNo) Clave principal clientNo Clave externa staffNohace referencia a (8taff(staffNo)
En el caso en que una relación 1: 1 con participación obligatoria en ambos lados tenga uno o más atributos, dichos atributos deben también incluirse en la tabla relacional combinada. Por ejemplo, si la relación States tuviera un atributo denominado date8tated que indicara la fecha en que la preferencia fue enunciada, dicho atributo aparecería también como atributo en la tabla relacionada Client. Observe que sólo es posible combinar dos entidades en una tabla relacional cuando no haya ninguna otra relación directa entre estas dos entidades que lo impida, como por ejemplo una relación de tipo 1:*. Si existiera dicho tipo de relación, tendríamos que representar la relación States utilizando el mecanismo de clave
426
Sistemas de bases de datos
principal/clave externa. Hablaremos de cómo designar las entidades padre e hija en este tipo de situación en el Apartado (c).
(b) Participación obligatoria en un lado de la relación 1: 1 En este caso, podemos identificar las entidades padre e hija de la relación 1:1 utilizando las restricciones de participación. La entidad que tiene participación opcional en la relación se designa como entidad padre, mientras que la entidad que tiene participación obligatoria se designa como entidad hija. Como hemos descrito anteriormente, se coloca una copia de la clave principal de la entidad padre en la tabla relacional que representa a la entidad hija. Si la relación tiene uno o más atributos, dichos atributos deben también incluirse junto con la clave principal en la tabla relacional hija. Por ejemplo, si la relación 1:1 Client States Preference tuviera participación parcial en el lado Client (en otras palabras, no todos los clientes especificarán cuáles son sus preferencias), designaríamos la entidad Client como entidad padre y la entidad Preference como entidad hija. Por tanto, se incluiría una copia de la clave principal de la entidad (padre) Client, que es c1ientNo, dentro de la tabla (hija) Preference, con lo que se obtendría: Para una relación 1:1 con participación obligatoria en el lado Client, se incluye clientNo en Preference para modelar la relación States
Client (c1ientNo, fName, IName, telNo, staffNo) Clave principal c1ientNo Clave externa staffNo hace referencia a StaffNo(staffNo)
Preference (clientNo, prefType, maxRent) Clave principal c1ientNo Clave externa staffNo hace referencia a StaffNo(staffNo)
Observe que el atributo de clave externa de la tabla Preference también forma la clave principal de la tabla. En esta situación, la clave principal de la tabla Preference no podría haberse identificado hasta incluir en la tabla Preference la clave externa procedente de la tabla Client. Por tanto, al final de este paso debemos identificar las posibles nuevas claves principales o claves candidatas que se hayan formado en el proceso, y actualizar el diccionario de datos correspondientemente.
(e) Participación opcional en ambos lados de la relación 1: 1 En este caso, la designación de las entidades padre e hija es arbitraria, a menos que podamos averiguar más información acerca de la relación que nos ayude a tomar una decisión en un sentido u otro. Por ejemplo, considere cómo representar una relación 1:1 8taff Uses Car (un empleado utiliza un coche) con participación opcional en ambos lados de la relación (observe que las explicaciones que siguen son también relevantes para las relaciones 1:1 con participación obligatoria para ambas entidades cuando no podemos seleccionar la opción de combinar las entidades en una única tabla relacional). Si no hay ninguna información adicional que nos ayude a seleccionar las entidades padre e hija, la elección es arbitraria. En otras palabras, tenemos la opción de incluir una copia de la clave principal de la entidad 8taff en la entidad Car o viceversa. Sin embargo, suponga que la mayoría de los coches, aunque no todos, son utilizados por algún empleado y que sólo una minoría de los empleados utilizan coches. La entidad Car, aunque es opcional, está más cerca de ser obligatoria que la entidad 8taff. Por tanto, designaremos 8taff como entidad padre y Car como entidad hija y colocaremos una copia de la clave principal de la entidad 8taff (staffNo) dentro de la relación Caro
(5) Relaciones recursivas uno a uno (1:1) Para una relación recursiva 1:1, siga las reglas de participación descritas anteriormente para una relación 1:l. Sin embargo, en este caso especial, la entidad en ambos lados de la relación es la misma. Para una relación recursiva 1: 1 con participación obligatoria en ambos lados, representa la relación recursiva como una única tabla con dos copias de la clave principal. Como antes, una de las copias de la clave principal presentará una clave externa y debe renombrarse para indicar la relación de la que deriva.
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
427
Para una relación recursiva 1:1 con participación obligatoria en sólo un lado, tenemos la opción de crear una única tabla con dos copias de la clave principal, como en el caso anterior, o de crear una nueva tabla que represente la relación. La nueva tabla sólo tendría dos atributos, ambos serian copias de la clave principal. Como antes, las copias de las claves principales actúan como claves externas y deben renombrarse para indicar el propósito que cada una de ellas tiene dentro de la tabla relacional. Para una relación recursiva 1:1 con participación opcional en ambos lados, cree de nuevo una tabla relacional como se describe más arriba.
(6) Tipos de relaciones superclase/subclase Para cada relación superclase/subclase del modelo conceptual de datos, identificamos la entidad superclase como entidad padre y la entidad sub clase como entidad hija. Hay varias opciones en lo que se refiere a representar dicha relación en forma de una o más tablas. La selección de la opción más apropiada dependerá de diversos factores, como las restricciones de disyunción y de participación que afecten a la relación superclase/subclase (véase la Sección 12.1.6), de si las subclases están implicadas en relaciones diferentes y del número de participantes en la relación superclase/subclase. En la Tabla 16.1 se proporcionan directrices para la representación de una relación superclase/subclase basándose exclusivamente en las restricciones de participación y disyunción. Por ejemplo, considere la relación superclase/subclase Owner mostrada en la Figura 16.1. Si consultamos la Tabla 16.1, vemos que hay varias formas de representar la relación en forma de una o más tablas, como se muestra en la Figura 16.2. Las opciones van desde situar todos los atributos en una tabla con dos discriminadores pOwnerFlag y bOwnerFlag, que indican si una determinada tupla pertenece a una subclase concreta (Opción 1), hasta dividir los atributos en tres tablas (Opción 4). En este caso, la representación más apropiada de la relación superclase/subclase está determinada por las restricciones que afectan a la relación. En la Figura 16.1 vemos que la relación que la superclase Owner tiene con sus subclases es obligatoria y disjunta, ya que cada miembro de la superclase Owner debe ser miembro de una de las subclases (PrivateOwner o BusinessOwner)pero no puede pertenecer a ambas a la vez. Por tanto, seleccionamos la Opción 3 como mejor representación de esta relación y creamos una tabla independiente para representar cada subclase, incluyendo una copia de los atributos de clave principal de la superclase en cada una de las tablas. Debemos recalcar que la Tabla 16.1 es simplemente una guía, y que puede haber otros factores que influencien la decisión final. Por ejemplo, con la Opción 1 (obligatoria, no disjunta), hemos decidido utilizar dos discriminadores para distinguir si la tupla es un miembro de una sub clase concreta. Otra forma igualmente válida de representar esto sería tener un discriminador que distinguiera si la tupla es un miembro de PrivateOwner,de BusinessOwner o de ambos. Alternativamente, podriamos prescindir de los discriminadores y simplemente comprobar si uno de los atributos particulares de una sub clase concreta tiene un valor asignado, con el fin de determinar si la tupla es un miembro de dicha subclase. En este caso, tendríamos que cerciorarnos de que el atributo que se examine sea un atributo obligatorio (y que por tanto no admita valores nulos). Tabla 16.1.
Directrices para la representación de una relación superclase/subclase basándose en las restricciones de participación y disyunción.
Restricción de participación
Restricción
de disyunción
Obligatoria
No disjunta {And}
Una única tabla (con uno o más discriminadores para distinguir el tipo de cada tupla).
Opcional
No disjunta {And}
Dos tablas: una tabla para la superclase y otra para todas las subclases (con uno o más discriminadores para distinguir el tipo de cada tupla).
Obligatoria
Disjunta {Or}
Muchas tablas: una tabla para cada combinación superclase/subclase.
Opcional
Disjunta {Or}
Muchas tablas: una tabla para cada superclase y otra para cada subclase.
Tabla requerida
428
Sistemas de bases de datos
Opcion 1 - Obligatoria, no disjunta AIIOwner (ownerNo, address, telNo, fName, IName, bName, bType, contactName, pOwnerFlag, bOwnerFlag) Claveprincipal ownerNo Opción 2 - Opcional, no disjunta Owner (ownerNo, address, telNo) Claveprincipal ownerNo OwnerDetails (ownerNo, fName IName, bName, bType, contactName, pOwnerFlag, bOwnerFlag) Claveprincipal ownerNo Claveexterna ownerNohace referenciaa Owner(ownerNo) Opcion 3 - Obligatoria, disjunta PrivateOwner (ownerNo, fName, IName, address, telNo) Claveprincipal ownerNo BusinessOwner (ownerNo, bName, bType, contactName, address, telNo) Claveprincipal ownerNo Opción 4 - Opcional, disjunta Owner (ownerNo, address, telNo) Claveprincipal ownerNo PrivateOwner (ownerNo, fName, IName) Claveprincipal ownerNo Claveexterna ownerNohacereferenciaa Owner(ownerNo) BusinessOwner (ownerNo, bName, bType, contactName) Claveprincipal ownerNo Claveexterna ownerNohacereferenciaa Owner(ownerNo)
Figura 16.2. Diversas representaciones de la relación superclase/subclase Owner basadas en la restricciones de participación y disyunción, según se muestra en la Tabla 16.1. En la Figura 16.1 hay otra relación superclase/subclase entre Staff y Supervisor con participación opcionaL Sin embargo, como la superclase Staff sólo tiene una subclase (Supervisor), no hay restricción de disyunción, En este caso, puesto que hay muchos más 'empleados supervisados' que supervisores, decidimos representar esta relación como una única relación: Staff (staffNo, fName, IName, position, sex, DOB, supervisorStaffNo)
Clave principal staffNo Clave externa supervisorStaffNo hace referencia a (Staff(staffNo) Si hubiéramos dejado la relación superclase/subclase como una relación habíamos definido originalmente en la Figura 15.5 con participación opcional nido la misma representación anterior.
recursiva 1:*, que era como la en ambos lados, se habría obte-
(7) Tipos de relaciones binarias muchos a muchos (*:*) Para cada relación binaria *:* crearemos una tabla que represente la relación e incluiremos los atributos que formen parte de la relación. Habrá que añadir una copia de los atributos de clave principal de las entidades que participan en la relación dentro de la nueva tabla, con el fin de que actúen como claves externas. Una o ambas claves externas formarán también la clave principal de la nueva tabla, posiblemente en combinación
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
429
con uno o más atributos de la relación (si uno o más de los atributos que forman la relación proporcionan la característica de unicidad, querrá decir que se ha omitido una entidad en el modelo de datos conceptual, aunque este proceso de asignación de tablas a las relaciones permite resolver el problema). Por ejemplo, considere la relación *:* Client Víews PropertyForRent (un cliente visita un inmueble) mostrada en la Figura 16.1. En este ejemplo, la relación Views tiene dos atributos denominados dateView y comments. Para representar esta relación, crearemos tablas para las entidades fuertes Client y PropertyForRent y otra tabla Viewing para representar la relación Víews, obteniendo: Client (clientNo, fName, IName, telNo, prefType, maxRent. staffNo) Clave pricipal clienlNo Clave externa staffNo hace referencia a Staff(staffNo)
/
PropertyForRent (propertyNo, street, city, postcode, type, rooms, rent) Clave principal propertyNo
Viewing (c1ientNo, propertyNo, dateView, comment) Clave principal clienlNo, propertyNo Clave externa clienlNo hace referencia a Client( clientNo) Clave externa propertyNo hace referencia a PropertyForRent(propertyNo)
(8) Tipos de relaciones complejas Para cada relación compleja, hay que crear una tabla que represente la relación e incluir en ella los atributos que formen parte de la relación. Añadiremos también una copia de los atributos de clave principal de las entidades que participen en la relación compleja, con el fin de que actúen como claves externas de la nueva tabla. Las claves externas que representen una relación de tipo 'muchos' (por ejemplo, 1..*,0 ..*) generalmente formarán también la clave principal de esta nueva tabla, posiblemente en combinación con algunos de los atributos de la relación. Por ejemplo, la relación ternaria Regísters en las vistas de usuario Branch representa la asociación entre el empleado que registra a un nuevo cliente en una sucursal, como se muestra en la Figura 12.8. Para representar esto, crearemos tablas para las entidades fuertes Branch, 8taff y Client y otra tabla Registration para representar la relación Regísters, obteniendo: 5taft (slaffNo, fName, IName, posilion, sex, DOB, supervisorSlaffNo) Clave principal staffNo Clave externa supervisorSlaffNo hace referencia a Staff(staffNo) Branch (branchNo, slreel, cily, postcode) Clave principal branchNo Client (clienINo, fName, IName, telNo, prefType, maxRent, staffNo) Clave principal clientNo Clave externa StaffNo hace referencia a Staff(staffNo)
Registration (clienINo, branchNo, staffNo, dateJoined) Clave principal c1ientNo Clave externa branchNo hace referencia a Branch(branchNo) Clave externa clientNo hace referencia a Client( c1ientNo) Clave externa StaffNo hace referencia a 8taff(staffNo)
Observe que la relación Regísters se muestra como una relación binaria en la Figura 16.1, lo cual es coherente con su composición en la Figura 16.3. La discrepancia en cuanto al modo en que Regísters está modelada en las vistas de usuario Staffy Branch de DreamHome se explica y resuelve en el Paso 2.6.
430
Sistemas de bases de datos
5taff (staffNo, fName, IName, position, sex, hace OOB,referencia maxRent, Clave staffNo) Clave principal principal externa ownerNo staffNo c1ientNo hace referencia aaStaff(staffNo) Clave principal c1ientNo, propertyNo propertyNo c1ientNo hace referencia Client( c1ientNo) PrivateOwner Client (clientNo, (ownerNo, fName, IName, fName, telNo, IName, prefType, address, telNo) Viewing (clientNo, propertyNo, dateView, comment) a PropertyForRent(propertyNo) c1ientNo, ownerNo) Derivado Clave deposit principalleaseNo Derivado alternativa (PropertyForRent.rent*2) rentFinish, duration hace propertyNo c1ientNo referencia propertyNo, c1ientNo, (rentFinish hace arentStart propertyNo) referencia PropertyForRent(propertyNo) -rentStart rentStart) a Client(c1ientNo) Clave externa supervisorStaffNo hace referencia a Staff(staffNo) Lease (leaseNo, paymentMethod, depositPaid, rentStart, PropertyForRent (propertyNo, street, city, postcode, BusinessOwner (ownerNo, bName, bType,
Figura 16.3.
Tablas para las vistas de usuario 8taff de DreamHome.
(9) Atributos multivaluados Para cada atributo multivaluado de una entidad, hay que crear una nueva tabla que represente el atributo multivaluado e incluir en ella la clave principal de la entidad, con el fin de que actúe como clave externa. A menos que el atributo multivaluado sea él mismo una clara alternativa de la entidad, la clave principal de la nueva tabla será la combinación del atributo multivaluado y de la clave principal de la entidad. Por ejemplo, en las vistas de usuario Branch, para representar la situación en la que una única sucursal tiene tres números telefónicos, se ha definido el atributo telNo de la entidad Branch como un atributo multivaluado, según se muestra en la Figura 12.8. Para representar esto, crearemos una tabla para la entidad Branch y otra nueva tabla denominada Telephone para representar el atributo multivaluado telNo, obteniéndose: Se incluye branchNo en Telephone
Branch (branchNo, street, city, postcode) Clave principal branchNo
Telephone (teINo, branchNo) Clave principal telNo Clave externa branchNo hace referencia a Branch(branchNo)
La Tabla 16.2 resume la asignación de entidades y relaciones a las diferentes tablas.
Documentación de las tablas y de los atributos de clave externa Al final del Paso 2.1, hay que documentar la composición de las tablas derivadas para el modelo lógico de datos utilizando el DBDL. Las tablas para las vistas de usuario Staff de DreamHome se muestran en la Figura 16.3. Ahora que cada tabla tiene su conjunto completo de atributos, estamos en disposición de identificar posibles nuevas claves principales y/o alternativas. Esto es particularmente importante para las entidades débiles
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional Tabla 16.2.
431
Resumen de la asignación de entidades y relaciones a las tablas.
Entidad/Relación
Asignación
Entidad fuerte
Crear una relación que incluya todos los atributos simples.
Entidad débil
Crear una relación que incluya todos los atributos simples (todavía habrá que identificar la clave principal después de haber asignado la relación con cada una de las entidades propietarias) ..
Relación binaria 1: *
Incluir la clave principal de la entidad del lado 'uno' para actuar como clave externa en la tabla que represente la entidad en el lado 'muchos'. Los atributos que tenga la relación también se incluyen en el lado 'muchos'.
Relación binaria
1: 1 :
(a) Participación obligatoria en ambos lados
Combinar las entidades en una tabla.
(b) Participación obligatoria en un lado
Incluir la clave principal de la entidad del lado 'opcional' para que actúe como clave externa en la tabla que represente a la entidad del lado' obligatorio'.
(c) Participación opcional en ambos lados
Arbitraria si no se dispone de información adicional.
Relación superclase/subclase
Véase la Tabla 16.1.
Relación binaria *:*, relación compleja
Crear una tabla para representar la relación e incluir en ella los atributos de la relación. Incluir también una copia de las claves principales de cada una de las entidades propietarias en la nueva tabla, con el fin de que actúen como claves externas.
Atributo multivaluado
Crear una tabla para representar el atributo multivaluado e incluir una copia de la clave principal de la entidad propietaria en la nueva tabla, con el fin de que actúe como clave externa.
que dependen de la inclusión de la clave principal de la entidad padre (o entidades padre) para formar una clave principal propia. Por ejemplo, la entidad débil Viewing ahora tiene una clave principal compuesta formada por una copia de la clave principal de la entidad PropertyForRent (propertyNo) y una copia de la clave principal de la entidad Client (c1ientNo). La sintaxis del lenguaje DBDL puede ampliarse para mostrar las restricciones de integridad que afecten a las claves externas (Paso 2.5). También es preciso actualizar el diccionario de datos para reflejar cualquier nueva clave principal o alternativa que se haya identificado en este paso. Por ejemplo, después de la inclusión de las claves principales, la tabla Lease ha ganado nuevas claves alternativas formadas por los atributos (propertyNo, rentStart) y (c1ientNo, rentStart). Paso
2.2
Validar las relaciones mediante
Objetivo
técnicas de normalización
Validar las relaciones del modelo lógico de datos utilizando las técnicas de normalización.
En el paso anterior hemos derivado un conjunto de tablas relacionales para representar el modelo conceptual de datos creado en el Paso l. En este paso, vamos a validar las agrupaciones de atributos de cada tabla utilizando las reglas de normalización. El propósito de la normalización es garantizar que el conjunto de tablas tenga un número de atributos mínimo, pero suficiente, para soportar los requisitos de datos de la empresa.
432 Sistemas de bases de datos Asimismo, las tablas deben tener una redundancia de datos mínimas con el fin de evitar las posibles anomalías de actualización analizadas en la Sección 13.3. De todos modos, un cierto grado de redundancia resulta esencial para permitir la combinación de las tablas relacionadas. En lo que sigue, utilizaremos el término relación para referimos a las tablas, de acuerdo con la terminología del modelo relaciona\. No hay que confundir esta utilización del término relación con las relaciones existentes entre entidades siempre que exista ambigiiedad, emplearemos el término tabla o tabla relaciona\. El uso de técnicas de normalización requiere que identifiquemos primero las dependencias funcionales existentes entre los atributos de cada relación. Las características de las dependencias funcionales que se utilizan para la normalización ya fueron explicadas en la Sección 13.4 y sólo pueden identificarse si se comprende a la perfección el significado de cada atributo. Las dependencias funcionales indican relaciones importantes entre los atributos de una tabla. Son esas dependencias funcionales y la clave principal de cada relación (tabla) lo que se utiliza durante el proceso de normalización. El proceso de normalización realiza una serie de comprobaciones con cada relación para ver si el conjunto de atributos de la relación cumple con las reglas de una determinada forma normal, como por ejemplo la primera forma normal (First Normal Form, lNF), la segunda forma normal (2NF) o la tercera forma normal (3NF). Las reglas aplicables a cada forma normal ya fueron analizadas en detalle en las Secciones 13.6 a 13.8. Para evitar los problemas asociados con la redundancia de los datos, se recomienda que cada relación esté en forma al menos 3NF. El proceso de derivar las relaciones a partir de un modelo de datos conceptual debería producir relaciones que ya estén en 3NF. Sin embargo, si identificamos alguna que no se encuentre en tercera forma normal, esto puede indicar que una parte del modelo lógico y/o conceptual de los datos es incorrecto, o que hemos introducido un error a la hora de derivar las relaciones a partir del modelo de datos conceptua\. Si es necesario, deberemos reestructurar las relaciones y/o el modelo de datos para garantizar que tanto unas como otros sean una representación correcta de los requisitos de datos de la organización. Algunos autores argumentan que un diseño de base de datos normalizado no proporciona una eficiencia de proceso máxima. Sin embargo, podemos decir lo siguiente a este respecto: •
Un diseño normalizado organiza los datos de acuerdo con sus dependencias funcionales. Consecuentemente, el proceso está a caballo entre el diseño conceptual y el diseño fisico.
•
El diseño lógico puede no ser el diseño fina\. Debería representar la comprensión que el diseñador de la base de datos tiene de la naturaleza y el significado de los datos requeridos por la organización. Si hay criterios específicos de prestaciones, el diseño fisico puede ser diferente del diseño lógico. Una posibilidad es que se desnormalicen algunas relaciones normalizadas, y esta técnica se analiza en detalle en el Paso 7 de la metodología de diseño físico de la base de datos (véase el Capítulo 18).
•
Un diseño normalizado es robusto y está libre de las anomalías de actualización que se explican en la Sección 13.3.
•
Las computadoras modernas son mucho más potentes que las que había disponibles hace unos pocos años. En ocasiones, resulta razonable por ello implementar un diseño donde se aumente la facilidad de uso a expensa de unas necesidades de procesamiento adicionales.
•
Para utilizar las técnicas de normalización, el diseñador de la base de datos debe comprender perfectamente cada atributo que hay que representar en la base de datos. Este beneficio puede ser el más importante de todos.
•
La normalización produce un diseño de base de datos flexible que puede ampliarse fácilmente.
Paso
2.3
Validar las relaciones
Objetivo
comprobando
las transacciones
de los usuarios
Garantizar que las relaciones del modelo lógico de datos soporten las transacciones requeridas.
El objetivo de este paso es validar el modelo lógico de los datos para garantizar que éste soporte las transacciones requeridas, según hayan sido detalladas en la especificación de requisitos del usuario. Este tipo de COlli-
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
433
probación ya fue llevada a cabo en el Paso 1.8 para garantizar que el modelo conceptual de los datos soportara dichas transacciones. En este paso, comprobamos que las relaciones creadas en el paso anterior soportan también estas transacciones, garantizando así que no se haya introducido ningún error durante el proceso de creación de las relaciones. Utilizando las relaciones, los enlaces de clave principal/clave externa mostrados en las relaciones, el diagrama ER y el diccionario de datos, trataremos de realizar las operaciones manualmente. Si podemos resolver todas las transacciones de esta forma, habremos validado el modelo lógico de los datos en lo que respecta a las transacciones que hay que soportar. Sin embargo, si no somos capaces de realizar una transacción manualmente, será indicación de que existe un problema en el modelo de datos, problema que habrá que resolver. En este caso, resulta probable que se haya introducido un error al crear las relaciones, por lo que habrá que retroceder y comprobar las áreas del modelo de datos a las que la transacción está accediendo, con el fin de identificar y resolver el problema. Paso 2.4 Comprobar
las restricciones
Objetivo
de integridad
Comprobar que las restricciones lógico de los datos.
de integridad
están representadas
en el modelo
Las restricciones de integridad son las restricciones que queremos imponer para proteger la base de datos frente a la posibilidad de que llegue a ser incompleta, imprecisa o incoherente. Aunque los SGBD pueden tener o no controles integrados para las restricciones de integridad, pero no es esa la cuestión principal en este punto. Durante esta etapa lo único que nos preocupa es el diseño de alto nivel, es decir, especificar qué restricciones de integridad se necesitan, independientemente de cómo se las pueda llegar a implementar. Un modelo lógico de los datos que incluya todas las restricciones de integridad importantes es una representación 'verdadera' de los requisitos de datos de la empresa. Consideraremos los siguientes tipos de restricciones de integridad: •
datos requeridos;
•
restricciones relativas a los dominios de los atributos;
•
multiplicidad;
•
integridad de las entidades;
•
integridad referencial;
•
restricciones generales.
Datos requeridos Algunos atributos deben siempre contener un valor válido; en otras palabras, no se permite que contengan valores nulos. Por ejemplo, todo empleado debe tener una categoría laboral asociada (como por ejemplo Supervisor o Assistant). Estas restricciones deben haberse identificado a la hora de documentar los atributos en el diccionario de datos (Paso 1.3). I
Restricciones relativas a los dominios de los atributos Todo atributo tiene un dominio, es decir, un conjunto de valores legales. Por ejemplo, el sexo de un empleado puede ser 'M' o 'F', por lo que el dominio del atributo sex será una única cadena de caracteres compuesta de 'M' o 'F'. Estas restricciones deben haber sido identificadas a la hora de seleccionar los dominios de los atributos para el modelo de datos.
Multiplicidad La multiplicidad representa las restricciones que se imponen a las relaciones entre los datos de la base de datos. Como ejemplos de tales restricciones podemos citar el requisito de que una sucursal puede tener
434
Sistemas de bases de datos
muchos empleados y de que cada empleado trabaja en una única sucursal. Garantizar que se identifiquen y representen todas las restricciones de integridad apropiadas es una parte importante del proceso de modelado de los requisitos de datos en una organización. En el Paso 1.2 hemos definido las relaciones entre entidades y todas las restricciones de integridad que puedan representarse de esta forma habrán sido definidas y documentadas en dicho paso.
Integridad de las entidades La clave principal de una entidad no puede contener valores nulos. Por ejemplo, cada tupla de la tabla Staff debe tener un valor para el atributo de clave principal, staffNo. Estas restricciones deben haber sido tomadas en consideración al identificar las claves principales para cada tipo de entidad (Paso 1.5).
Integridad referencial Una clave externa enlaza cada tupla de la tabla hija con la tupla de la tabla padre que contiene el valor de clave candidata correspondiente. El concepto de integridad referencial significa que si la clave externa contiene un valor, dicho valor debe hacer referencia a una tupla existente en la tabla padre. Por ejemplo, considere la relación Staff Manages PropertyForRent. El atributo staffNo de la tabla PropertyForRent enlaza el inmueble en alquiler con la tupla de la tabla Staff que contiene el empleado que la gestiona. Si staffNo tiene un valor no nulo, deberá contener un valor válido existente en el atributo staffNo de la tabla Staff, ya que de lo contrario el inmueble estaría siendo asignado a un empleado inexistente. Son dos los problemas que hay que resolver en lo que respecta a las claves externas. El primero toma en consideración si deben permitirse los valores nulos en la clave externa. Por ejemplo, ¿podemos almacenar los detalles de un inmueble en alquiler sin haber especificado un empleado que lo gestione (es decir, podemos asignar un valor nulo a staffNo)? El problema no es si existe el número de empleado, si no si hay obligación de especificar un número de empleado. En general, si la participación de la tabla hija en la relación es: •
obligatoria, entonces no se permiten los valores nulos;
•
opcional, entonces los valores nulos sí están permitidos.
El segundo problema que debemos resolver es cómo garantizar la integridad referencial. Para hacer esto, especificamos restricciones de existencia que definen las condiciones bajo las cuales puede insertarse, actualizarse o borrarse una clave candidata o una clave externa. Para la relación Staff Manages PropertyForRent de tipo 1:*, considere los siguientes casos.
Caso 1: Inserción de una tupla en la tabla hija (PropertyForRent) Para garantizar la integridad referencial, hay que comprobar que el atributo de clave externa, staffNo, de la nueva tupla de PropertyForRent tenga un valor nulo o un valor que se corresponda con una tupla de Staff existente.
Caso 2: Borrado de una tupla de la tabla hija (PropertyForRent) Si se borra una tupla de un tabla hija, las condiciones de integridad referencial no se ven afectadas.
Caso 3: Actualización de la clave externa de una tupla hija (PropertyForRent) Esto es similar al Caso l. Para garantizar la integridad referencial, hay que comprobar que el valor staffNo de la tupla de PropertyForRent actualizada tenga un valor nulo o un valor que se corresponda con una tupla de Staff existente.
Caso 4: Selección de una tupla en la tabla padre (Staff) Insertar una tupla en la tabla padre (Staff) no afecta a la integridad referencial; simplemente, dicha tupla se convierte en un padre que no tiene ningún hijo asignado: en otras palabras, un empleado que no tiene ningún inmueble que gestionar.
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
435
Caso 5: Borrado de una tupla de la tabla padre (Staff) Si se borra una tupla de la tabla padre, la integridad referencial se pierde si existen tuplas hijas que hagan referencia a la tupla padre borrada. En otras palabras, se pierde la integridad referencial si el empleado que se borra está gestionando actualmente uno o más inmuebles. Son varias las estrategias que podríamos utilizar: •
NO ACTION. Impide el borrado de la tupla de la tabla padre si existen tuplas hijas que la hagan referencia. En nuestro ejemplo, 'No se puede borrar un empleado si está gestionando actualmente algún inmueble'.
•
CASCADE. Cuando se borra la tupla padre, se borran automáticamente todas las tuplas hijas que hacen referencia a ella. Si alguna de las tuplas hijas borradas actúa como padre en otra relación, la operación de borrado debe aplicarse también a las tuplas de esta tabla hija, propagando los borrados en cadena. En otras palabras, las operaciones de borrado en la tabla padre hacen que se borren en cascada las sucesivas tuplas de las tablas hijas. En nuestro ejemplo, 'Si se borra un empleado, se borran automáticamente todos los inmuebles que gestiona'. Claramente, en nuestro ejemplo de gestión de inmuebles, esta estrategia no resultaría adecuada. Si se ha utilizado la técnica avanzada de modelado de composición para poner en relación las entidades padre e hija, es obligatorio especificar la opción CASCADE (véase la Sección 12.3).
•
SET NULL. Cuando se borra una tupla padre, los valores de clave externa en todas las tuplas hijas correspondientes se configuran automáticamente con el valor nulo. En nuestro ejemplo, 'Si se borra un empleado, hay que indicar que la asignación actual de los inmuebles previamente gestionados por ese empleado es desconocida'. Sólo puede emplearse esta estrategia si los atributos que componen la clave externa pueden aceptar valores nulos.
•
SET DEFAULT. Cuando se borra una tupla padre, los valores de clave externa en todas las tuplas hijas correspondientes deben adoptar automáticamente sus valores predeterminados. En nuestro ejemplo, 'Si se borra un empleado, las propiedades que antes gestionaba ese empleado pasan a ser gestionadas por otro empleado (predeterminado), como por ejemplo el Gerente de la sucursal'. Sólo podemos tomar en consideración esta estrategia si los atributos que forman la clave externa tienen valores predeterminados definidos.
•
NO CHECK. Cuando se borra una tupla padre, no hacemos nada para garantizar que se mantenga la integridad referencia!.
Caso 6: Actualización
de la clave principal de la tupla padre (Staff)
Si se actualiza el valor de clave principal en una tabla padre, se pierde la integridad referencial si existe una tupla hija que haga referencia al valor de clave principal antiguo; es decir, si el empleado que está siendo actualizado está gestionando actualmente uno o más inmuebles. Para garantizar la integridad referencial, podemos utilizar las estrategias descritas anteriormente. En el caso de CASCADE, las actualizaciones de la clave principal de la tupla padre se reflejan en todas las tuplas hijas que hagan referencia a ella y si una tupla hija que hace referencia a ella es ella misma una clave principal de una tupla padre, esta actualización también se propagará a las tuplas hijas que la hagan referencia, etc. Lo normal es que las actualizaciones se especifiquen con la opción CASCADE. En la Figura 16.4 se muestran las restricciones de integridad referencial para las tablas creadas para las vistas de usuario Staff de DreamHome.
Restricciones generales Finalmente, vamos a considerar las restricciones denominadas restricciones generales. Las actualizaciones de las entidades pueden estar controladas por una serie de restricciones que gobiernen las transacciones del 'mundo real' representadas por dichas actualizaciones. Por ejemplo, DreamHome tiene una regla que impide que un empleado gestione más de 100 inmuebles al mismo tiempo.
436 Sistemas de bases de datos Staft (staffNo, fName, IName, position, sex, OOB, supervisorStaffNo) Clave principal staffNo Clave externa supervisorStaffNo hace referencia a Staff(staffNo) ON UPDATE CASCADE ON DELETE SET NULL Client (clientNo, fName, IName, telNo, prefType, maxRen!, staffNo) Clave principal c1ientNo Clave externa StaffNo hace referencia a Staff(staffNo) ON UPDATE CASCADE ON DELETE NO ACTION PropertyForRent
(propertyNo, street, city, postcode, type, rooms, ren!, ownerNo, staffNo)
Clave principal propertyNo Clave externa ownerNo hace referencia a PrivateOwner(ownerNo) y BusinessOwner(ownerNo) ON UPDATE CASCADE ON DELETE NO ACTION Clave externa StaffNo hace referencia a Staff(staffNo) ON UPDATE CASCADE ON DELETE SET NULL Viewing (clientNo, propertyNo, dateView, comment) Clave principal c1ientNo, propertyNo Clave externa c1ientNo hace referencia a Client(c1ientNo) ON UPDATE CASCADE ON DELETE NO ACTION Clave externa propertyNo hace referencia a PropertyForRent(propertyNo) ON UPDATE CASCADE ON DELETE CASCADE Lease (leaseNo, paymentMethod, depositPaid, rentStart, rentFinish, clientNo, propertyNo) Clave principalleaseNo Clave alternativa propertyNo, rentStart Clave alternativa c1ientNo, rentStart Clave externa c1ientNo hace referencia a Client(c1ientNo) ON UPDATE CASCADE ON DELETE NO ACTION Clave externa propertyNo hace referencia a PropertyForRent(propertyNo) ON UPDATE CASCADE ON DELETE CASCADE
Figura 16.4.
Documentación
Restricciones de integridad referencial para las tablas de las vistas de usuario Staff de DreamHome.
de las restricciones
de integridad
Hay que documentar todas las restricciones de integridad en el diccionario de datos para poder tenerlas en cuenta durante el diseño fisico. Paso
2.5
Repasar
Objetivo
el modelo lógico de los datos con los usuarios
Revisar el modelo lógico de los datos con los usuarios para asegurarse de que éstos consideran que el modelo es una representación real de los requisitos de datos de la organización.
El modelo lógico de los datos debe estar ahora completo y totalmente documentado. Sin embargo, para confirmar que es así, hay que solicitar a los usuarios que revisen el modelo lógico de los datos y que confirmen que lo consideran como una representación real de los requisitos de datos de la organización. Si a los usuarios no les satisface el modelo, puede que sea necesario repetir algunos de los pasos anteriores de la metodología. Si los usuarios están satisfechos con el modelo, el paso siguiente que hay que dar dependerá del número de vistas de usuario asociadas con las base de datos y, lo más importante, del modo en que se gestionen dichas vistas. Si el sistema de base de datos tiene una única vista de usuario o múltiples vistas de usuario que estén siendo gestionadas mediante la técnica de centralización (véase la Sección 9.5), pasaremos directamente al paso final del Paso 2, es decir, al Paso 2.7. Si la base de datos tiene múltiples vistas de usuario que estén siendo gestionadas mediante la técnica de integración de vistas (véase la Sección 9.5) entonces continuaremos con el Paso 2.6. La técnica de integración de vistas da como resultado la creación de varios modelos lógicos de
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
437
los datos, cada uno de los cuales representan una o más (pero no todas) de las vistas de usuario de una base de datos. El propósito del Paso 2.6 es combinar estos modelos de datos para crear un único modelo lógico de los datos que represente todas las vistas de usuario de la base de datos. Sin embargo, antes de considerar este paso, expliquemos brevemente la relación existente entre los modelos lógicos de los datos y los diagramas de flujo de datos.
Modelo lógico de los datos y los diagramas de flujo de datos Un modelo lógico de los datos refleja la estructura de los datos almacenados para una organización. Un diagrama de flujo de datos (DFD, Data Flow Diagram) muestra cómo se mueven los datos por la organización y cómo se los guarda en almacenes de datos. Todos los atributos deben aparecer dentro de un tipo de entidad si son almacenados dentro de la organización, y probablemente se los pueda ver moverse a través de la organización en forma de flujo de datos. Cuando se utilizan estas dos técnicas para modelar la especificación de requisitos del usuario, podemos emplear cada una de ellas con el fin de comprobar la coherencia y exhaustividad de la otra. Las reglas que controlan la relación entre las dos técnicas son: •
cada almacén de datos debe representar un número entero de tipos de entidades;
•
los atributos reflejados en los flujos de datos deben pertenecer a algún tipo de entidad.
Paso
2.6 Combinar
Objetivo
los modelos lógicos de los datos en un modelo global (paso opcionalj Combinar los modelos lógicos de los datos en un único modelo lógico de datos global que represente todas las vistas de usuario de la base de datos.
Este paso sólo es necesario para el diseño de una base de datos con múltiples vistas de usuario que se están gestionando mediante la técnica de integración de vistas. Para facilitar la descripción del proceso de combinación utilizamos los términos 'modelo lógico de datos local' y 'modelo lógico de datos global'. Un modelo lógico de datos local representa una o más de las vistas de usuario, pero no todas, de la base de datos, mientras que un modelo lógico de datos global represente todas las vistas de usuario de la base de datos. En este paso, combinamos dos o más modelos lógicos de datos locales en un único modelo lógico de datos global. La fuente de información para este caso son los modelos lógicos locales de los datos creados mediante el Paso 1 y los Pasos 2.1 a 2.5 de la metodología. Aunque cada modelo lógico local de los datos debe ser correcto, exhaustivo y no ambiguo, dichos modelos son una representación únicamente de una o más de las vistas de usuario de la base de datos, pero no de todas ellas. En otras palabras, cada modelo representa sólo una parte de la base de datos completa. Esto puede querer decir que puede haber incoherencias y solapamientos cuando se analice el conjunto completo de vistas de usuario. Por tanto, cuando combinemos los modelos lógicos locales de los datos en un único modelo global, deberemos intentar resolver los conflictos entre las vistas y los solapamientos que puedan existir. En consecuencia, al completar el proceso de combinación, el modelo lógico global de los datos resultante estará sujeto a validaciones similares a las realizadas con los modelos locales de los datos. Las validaciones son particularmente necesarias en este caso y deben centrarse en las áreas del modelo que más sujetas a cambios están durante el proceso de combinación. Las actividades de este paso incluyen: •
Paso 2.6.1 Combinación de los modelos lógicos locales de datos en un modelo global
•
Paso 2.6.2 Validación del modelo lógico global de los datos
•
Paso 2.6.3 Revisión del modelo lógico global de los datos con los usuarios
Ilustraremos este paso utilizando el modelo lógico local de los datos desarrollado anteriormente para las vistas de usuario Staff del caso de estudio DreamHome y empleando también el modelo desarrollado en los Capítulos 11 y 12 para las vistas de usuario Branch de ese mismo caso de estudio. La Figura 16.5 muestra las relaciones creadas a partir del modelo ER para la vistas de usuario Branch dadas en la Figura 12.8. Dejamos como ejercicio para el lector demostrar que esta asignación es correcta (véase el Ejercicio 16.6).
438
Sistemas de bases de datos
address, telNo) BusinessOwner (bName, bType, contactName, clientNo hace referencia Client(clientNo) Clave externa staffNo hace referencia aaaStaff(staffNo) Staff(staffNo) Clave externa branchNo hace referencia aa Branch(branchNo) Clave alternativa telNo branchNo hace referencia Branch(branchNo) principal telNo Clave principal Registration Client (c1ientNo, c1ientNo (c1ientNo, name, branchNo, telNo, prefType, staffNo, maxRent) dateJoined) Telephone (teINo, branchNo) principal c1ientNo Clave Clave principal externa staffNo staffNo hace referencia Branch (branchNo, street, city, postcode, magrStaffNo) Clave Newspaper principal (newspaperName, newspaperName address, telNo, contactName) Manager (staffNo, mgrStartDate, bonus) Clave alternativa telNo ownerNo hace referencia aaPrivateOwner(ownerNo) PropertyForRent(propertyNo) bName referencia BusinessOwner(bName) Clave Derivado externa deposit newspaperName Derivado (PropertyForRent.rent*2) duration Newspaper( hace (rentFinish referencia newspaperName) - referencia rentStart) a a Staff(staffNo) staffNo hace referencia bName staffNo) Clave externa branchNo hace referencia Branch(branchNo) propertyNo hace a nchNo) )rtprincipal affNo) Advert (propertyNo, newspaperName, dateAdvert, cost) Staff name, position, salary, supervisorStaffNo, Lease(staffNo, (leaseNo, paymentMethod, depositPaid, pe, PrivateOwner (ownerNo, name, address, telNo) rentStart,
Figura 16.5.
Relaciones para las vistas de usuario Branch de DreamHome.
Paso 2.6.1 Combinación de los modelos lógicos locales de datos en un modelo global Objetivo
Combinar los modelos lógicos locales de los datos en un único modelo lógico global.
Hasta este momento, para cada modelo lógico local de los datos hemos generado un diagrama ER, un esquema relacional, un diccionario de datos y la documentación de soporte que describe las restricciones que afectan a los datos. En este paso, utilizamos estos componentes para identificar las similitudes y diferencias entre los modelos y ayudar así a combinados. Para un sistema de bases de datos simple con un pequeño número de vistas de usuario cada una de las cuales tenga un pequeño número de tipos de identidad y de relación, resulta relativamente sencillo comparar los modelos locales, combinados y resolver las posibles diferencias que existan. Sin embargo, en un sistema de gran tamaño, es necesario emplear un enfoque más sistemático. Presentamos una técnica que puede utilizarse para combinar los modelos locales y resolver las incoherencias que se puedan encontrar. El lector interesado puede consultar otras técnicas alternativas en los artículos de Batini y Lanzerini (1986), Biskup y Convent (1986), Spaccapietra et al. (1992) y Bouguettaya et al. (1998). Algunas de las tareas típicas que hay que realizar a la hora de seguir esta técnica son: J
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
439
(1) Revisar los nombres y el contenido de las entidades/tablas y de sus claves candidatas. (2) Revisar los nombres y los contenidos de las relaciones/claves (3) Combinar las entidades/tablas
externas.
de los modelos de datos locales.
(4) Incluir (sin combinadas) las entidades/tablas exclusivas de cada modelo de datos local. (5) Combinar las relaciones/claves
externas de los modelos de datos locales.
(6) Incluir (sin combinadas) las relaciones/claves
externas exclusivas de cada modelo de datos local.
(7) Verificar si falta alguna entidad/tabla o relación/clave
externa.
(8) Comprobar las claves externas. (9) Comprobar las restricciones de integridad. (10) Dibujar el diagrama ER global. (11) Actualizar la documentación. En algunas de las tareas anteriores, hemos utilizado los términos 'entidades/tablas' y 'relaciones/claves externas'. Esto permite al diseñador decidir si prefiere examinar los modelos ER o las tablas derivadas a partir de esos modelos en conjunción con su documentación de soporte, o incluso utilizar una combinación de ambas técnicas. Puede resultar más sencillo basar el examen en la composición de tablas, ya que esto elimina muchas diferencias sintácticas y semánticas que puedan existir entre los diferentes modelos ER que posiblemente pueden haberse producido por diferentes diseñadores. Quizá la forma más fácil de combinar varios modelos locales de los datos consiste en combinar primero dos de los modelos de datos para generar un nuevo modelo y luego ir combinando sucesivamente los modelos locales restantes hasta que todos ellos estén representados en el modelo global de los datos final. Esto puede resultar más simple que tratar de combinar de una sola vez todos los modelos locales de los datos.
(1) Revisar los nombres y el contenido de las entidades/tablas y de sus claves candidatas Puede resultar útil revisar los nombres y descripciones de las entidades/tablas que aparecen en los modelos locales de los datos, inspeccionando el diccionario de datos. Pueden surgir problemas cuando dos o más entidades/tablas: •
tengan el mismo nombre pero sean, de hecho, diferentes (homónimas);
•
sean iguales pero tengan nombres diferentes (sinónimas).
Puede ser necesario comparar el contenido de datos de cada entidad/relación para resolver estos problemas. En concreto, utilice las claves candidatas como ayuda para identificar las entidades/tablas equivalentes que pueden estar nombradas de forma distinta en las diferentes vistas. La Tabla 16.3 muestra una comparación de las relaciones de las vistas de usuario Branch y Staff de DreamHome. Se resaltan en la figura las tablas comunes a las dos vistas de usuario.
(2) Revisar los nombres y los contenidos de las relaciones/claves externas Esta actividad es igual que la descrita para las entidades/tabla. En la Tabla 16.4 se muestra una comparación de las claves externas de las vistas de usuario Branch y Staff de DreamHome. En la figura se resaltan las claves externas que son comunes a ambas vistas. Observe, en concreto, que de las tablas que son comunes a ambas vistas, Staff y PropertyForRent tienen una clave externa adicional, branchNo. La comparación inicial de los nombres/claves externas de las relaciones incluidas en cada vista nos vuelve a dar una indicación del grado con que dichas vistas se solapan. Sin embargo, es importante reconocer que
440
Sistemas de bases de datos Tabla 16.3.
Una comparación de los nombres de las entidades/tablas
y
de sus claves candidatas en las vistas de usuario Branch y 8taff. Vistas de usuario
Branch
Entidad/tabla
Claves candidatas
Branch
branchNo
Telephone
telNo
5taff
staffNo
Manager
staffNo
PrivateOwner BusinessOwner
Vistas de usuario
Staff
Entidad/tabla
Claves candidatas
5taff
staffNo
ownerNo
PrivateOwner
ownerNo
bName
BusinessOwner
bName
postcode
telNo
telNo
ownerNo Client
c1ientNo
Client
clientNo
PropertyForRent
propertyNo
PropertyForRent
propertyNo
Viewing
c1ientNo,propertyNo
Lease
leaseNo
Lease
leaseNo
propertyNo,
propertyNo,
rentStart
rentStart
c1ientNo,rentStart
clientNo,rentStart
Registration
c1ientNo
Newspaper
newpaperName telNo
Advert
(propertyNo, newspaperName, dateAdvert)
no debemos confiar en exceso en el hecho de que las entidades o relaciones con el mismo nombre jueguen el mismo papel en ambas vistas. Sin embargo, comparar los nombres de las entidades/tablas y de las relaciones/claves externas es un buen punto de partida a la hora de buscar posibles solapamientos entre las vistas; siempre y cuando seamos conscientes de las posibles fuentes de error en este proceso. Es preciso tener cuidado con las entidades o relaciones que tengan el mismo nombre pero que representen, de hecho conceptos diferentes (también denominadas homónimas). Un ejemplo de este paso son las relaciones Staff Manages PropertyForRent (vista Staff) y Manager Manages Branch (vista Branch). Obviamente, la relación Manages tiene en este caso un significado algo distinto en las dos vistas. Debemos por tanto garantizar que las entidades o relaciones que tenían el mismo nombre representan el mismo concepto en el 'mundo real' y que los nombres que difieran entre las distintas vistas representen conceptos distintos. Para conseguir esto, compararemos los atributos (y, en particular, las claves) asociados con cada entidad y también sus relaciones asociadas con otras entidades. También debemos ser conscientes de que las entidades o relaciones en una vista pueden estar representadas simplemente como atributos en otra vista distinta. Por ejemplo, considere el escenario en el que la entidad Branch tenga un atributo denominado managerName en una vista, que se representa como una entidad denominada Manager en otra vista.
e->
Comparación
Viewing
se crea a partir de la relación temaria Registers
telNo
en las vistas
BusinessOwner Client PrivateOwner de usuario Staff
externas
Vistas
de las claves
c La tabla Advert se crea a partir de la relación muchos a muchos (*;*) Advertises
b La tabla Registration
a La tabla Telephone se crea a partir del atributo multivaluado
AdvertC
16.4.
clientNo-> ownerNo-> Lease ownerNo-> staffNo-> clientNo-> Staff staffNo-> Vistas de Branch Claves externas branchNo-> Client(clientNo) Client( Newspaper( BusinessOwner(bName) BusinessOwner( PropertyForRent(propertyNo) staffNo newspaperName) )usuario ownerNo) PropertyForRent(propertyNo) PropertyF PropertyF PrivateOwner( c1ientNo) orRent(propertyNo) orRent(propertyNo) ownerNo) Staff( staffNo) supervisorStaffNo-> Branch(branchNo) Staff(staffNo) mgrStaffNo-> propertyNo-> PrivateOwner(ownerNo) PropertyForRent propertyNo-> Staff(staffNo) Manager(staffNo) Tabla Tabla padre hija
Table
de usuario
Branch
y Staff.
III
n
..•
.¡::.
.¡::.
DI
:l
o'
n
Di
ID
..
O'
ID
O Q.
3
!.
III
.. III
'C
11I
O
..•
DI
Q.
ID
Q.
11I
ID
11I
DI
l:T
ID
O Q.
ñ'
le
O-
O
ID ::11
iij'
Q.
III
le -,
O Q. O O'
..•
ID
s:
..• al
O'
;:¡.'
e
'C
442
Sistemas de bases de datos
(3) Combinar las entidades/tablas
de los modelos de datos locales
Examine el nombre y el contenido de cada entidad/tabla de los modelos que hay que combinar para determinar si las entidades/tablas representan una misma cosa y pueden por tanto combinarse. Las actividades típicas implicadas en esta tarea son: •
combinar las entidades/tablas
que tengan el mismo nombre y la misma clave principal;
•
combinar las entidades/tablas
que tengan el mismo nombre pero diferentes claves principales;
•
combinar las entidades/tablas diferentes.
Combinación
que tengan nombres diferentes y utilicen claves principales iguales o
de las entidades/tablas
con el mismo nombre y la misma clave principal
Generalmente, las entidades/tablas con la misma clave principal representan el mismo objeto del 'mundo real' y deben combinarse. La entidad/tabla combinada incluirá los atributos de las entidades/tablas originales, eliminando los posibles duplicados. Por ejemplo, la Figura 16.6 enumera los atributos asociados con la tabla PrivateOwner definida en las vistas de usuario Branch y Staff. La clave principal de ambas tablas es ownerNo. Combinamos estas dos tablas mezclando sus atributos, de modo que la tabla combinada PrivateOwner tenga ahora todos los atributos originales asociados con las dos tablas PrivateOwner originales. Observe que existe un conflicto entre las vistas en cuanto a cómo debemos representar el nombre de un propietario. En esta situación, debemos (si es posible) consultar a los usuarios de cada vista para determinar la representación final. Observe también, en este ejemplo, que hemos utilizado la versión descompuesta del nombre del propietario, representada por los atributos fName y IName, en la vista combinada global. De forma similar, en la Tabla 16.2 vemos que las tablas 8taff, Client, PropertyForRent y Lease tienen las mismas claves principales en ambas vistas y que, por tanto, podemos combinar las tablas tal como acabamos de explicar. Combinación de las entidades/tablas diferentes claves principales
con el mismo nombre
pero
En algunas situaciones, podemos encontrar dos entidades/tablas con el mismo nombre y similares claves candidatas, pero con diferentes claves principales. En este caso, las entidades/tabla deben combinarse como se acaba de describir. Sin embargo, es necesario seleccionar una de las claves como clave principal, pasando las otras a ser claves alternativas. Por ejemplo, la Figura 16.7 enumera los atributos asociados con las dos tablas BusinessOwner definidas en las dos vistas. La clave principal de la tabla BusinessOwner de las vistas de usuario Branch es bName y la clave principal de la tabla BusinessOwner en las vistas de usuario Staff es ownerNo. Sin embargo, la clave alternativa para BusinessOwner en las vistas de usuario Staff es bName. Aunque las claves principales son diferentes, la clave principal de BusinessOwner en las vistas de usuario Branch es la clave alternativa BusinessOwner en las vistas de usuario Staff. Combinaremos estas dos tablas como se muestra en la Figura 16.7, incluyendo bName como clave alternativa. Vistas de usuario Branch PrivateOwner (ownerNo, name, address, telNo) Clave principal ownerNo
Vistas de usuario 5taff PrivateOwner (ownerNo, fName, IName, address, telNo) Clave principal ownerNo
Vistas de usuario globales PrivateOwner (ownerNo, fName. IName, address, telNo) Clave principal ownerNo
Figura 16.6.
Combinación
de las tablas PrivateOwner
de las vistas de usuario Branch y Staff.
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional Vistas de usuario Branch
443
Vistas de usuario Staff
BusinessOwner
(bName, bType, contactName, address, telNo) Clave principal bName Clave alternativa tel No
BusinessOwner
(ownerNo, bName, bType, contactName, address, telNo) Clave principal ownerNo Clave alternativa bName Clave alternativa telNo
Vistas de usuario globales BusinessOwner (ownerNo, bName, bType, contactName, address, telNo) Clave principal ownerNo Clave alternativa bName Clave alternativa telNo
Figura 16.7.
Combinación
de las tablas BusinessOwner
Combinación de las entidades/tablas con diferentes que utilicen claves principales iguales o diferentes
con diferentes claves principales.
nombres
y
En algunos casos, podemos identificar entidades/tablas que tienen nombres diferentes pero parecen tener el mismo propósito. Estas entidades/tablas equivalentes pueden detectarse simplemente mediante: •
su nombre, que indica que tienen un propósito similar;
• •
su contenido y, en particular, su clave principal; su asociación con relaciones concretas.
Un ejemplo obvio de este caso sería las entidades denominadas Staff y Employee, que en ambos casos harían referencia a empleados y que, si fueran equivalentes, deberían combinarse.
(4) Incluir (sin combinarlas) las entidades/tablas de datos local
exclusivas de cada modelo
Las tareas anteriores deberían permitimos identificar todas las entidades/tablas que sean iguales. Todas las restantes entidades, tablas se incluirán en el modelo global sin ninguna modificación. En la Tabla 16.2 vemos que las tablas Branch, Telephone, Manager, Registration, Newspaper y Advert son exclusivas de las vistas de usuario Branch, mientras que la tabla Viewing es exclusiva de las vistas de usuario Staff.
(5) Combinar las relaciones/claves datos locales
externas de los modelos de
En este paso vamos examinamos el nombre y el propósito de cada relación/clave externa incluida en los modelos de datos. Antes de combinar las relaciones/claves externas, es importante resolver cualquier conflicto que exista entre las relaciones, como por ejemplo las diferencias en las restricciones de multiplicidad. Las actividades en este paso incluyen: •
combinar las relaciones/claves
externas que tengan el mismo nombre y el mismo propósito;
•
combinar las relaciones/claves
externas que tengan diferentes nombres pero el mismo propósito.
Utilizando la Tabla 16.3 y el diccionario de datos, podemos identificar las claves externas con el mismo nombre y el mismo propósito que pueden combinarse en el modelo global. Observe que la relación Registers en las dos vistas representa esencialmente el mismo 'suceso': en las vistas de usuario Staff, la relación Registers modela el acto mediante el que un empleado registra a un cliente; en las vistas de usuario Branch, la situación es ligeramente más compleja debido al modelado adicional de las
444
Sistemas de bases de datos
sucursales, pero la introducción de la relación Registration modela también el acto por el que un empleado registra a un cliente en la sucursal. En este caso, ignoramos la relación Registers de las vistas de usuario Staff e incluimos las relaciones/claves externas equivalentes de las vistas de usuario Branch en el siguiente paso.
(6) Incluir (sin combinarlas) las relaciones/claves cada modelo de datos local
externas exclusivas de
De nuevo, la tarea anterior debería habernos ayudado a identificar las relaciones/claves externas que son equivalentes (por definición, deben estar definidas entre las mismas entidades/tablas, que ya habrán sido combinadas antes). Todas las relaciones/claves externas restantes se incluyen en el modelo global sin ningún cambio.
(7) Verificar si falta alguna entidad/tabla
o relación/clave
externa
Quizás una de las tareas más difíciles a la hora de generar el modelo global es identificar las entidades/tablas y relaciones/claves externas que faltan entre los diferentes modelos de datos locales. Si existe un modelo de datos corporativo para la organización, puede que éste revele entidades y relaciones que no aparecen en ninguno de los modelos de datos locales. Alternativamente, como medida preventiva, cuando se entreviste a los usuarios de cada vista de usuario específica, pídales que presten particular atención a las entidades y relaciones que existan en otras vistas de usuario. Si no lo hace así, examine los atributos de cada entidad/tabla y busque referencias a entidades/tablas que estén contenidas en otros modelos de datos locales. Puede que encuentre que existe algún atributo asociado con una entidad/tabla en uno de los modelos de datos locales y que se corresponde con una clave principal, con una clave alternativa o incluso con un atributo no clave de una entidad/tabla perteneciente a otro modelo de datos local distinto.
(8) Comprobar las claves externas Durante este paso, puede que se hayan combinado entidades/tablas y relaciones/claves externas, puede que se hayan modificado claves principales y puede que se hayan identificado nuevas relaciones. Compruebe que las claves externas de las tablas hijas siguen siendo correctas y realice cualquier modificación necesaria. En la Figura 16.8 se muestran las tablas que representan el modelo lógico global de datos para DreamHome.
(9) Comprobar las restricciones de integridad Compruebe que las restricciones de integridad correspondientes al modelo lógico global de los datos no entran en conflicto con las restricciones originalmente especificadas para cada vista. Por ejemplo, si se ha identificado alguna nueva relación y se han creado nuevas claves externas, asegúrese de que están especificadas las apropiadas restricciones de integridad referencial. Si existe algún conflicto, consulte con los usuarios para resolverlo.
(10) Dibujar el diagrama ER global Ahora dibujamos un diagrama final que represente todos los modelos lógicos de datos locales combinados. Si se han utilizado las tablas como base para la combinación, el diagrama resultante recibirá el nombre de diagrama de tablas global, mostrándose en él las claves principales y claves externas. Si se han utilizado diagramas ER locales, el diagrama resultante será simplemente un diagrama ER global. En la Figura 16.9 se muestra el diagrama global de tablas para DreamHome.
(11) Actualizar
la documentación
Actualice la documentación para reflejar los cambios realizados durante el desarrollo del modelo de datos global. Es muy importante que la documentación esté actualizada y refleje el modelo de datos actual. Si se realizan cambios en el modelo posteriormente, bien durante la implementación de la base de datos o durante el mantenimiento, será necesario actualizar la documentación de forma correspondiente. Si la información está desactualizada, puede ser fuente de confusión en cualquier momento posterior.
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
445
Branch (branchNo, street, city, postcode, magrStaffNo) Claveexterna alternativa telNo Clave externa branchNo hace referencia aatelNo, Branch(branchNo) address, telNo) Clave principal Newspaper newspaperName (newspaperName, address, contactName) Clave Manager Clave principal (staffNo, staffNo staffNo mgrStartDate, hace referencia bonus) abType, BusinessOwner (ownerNo, bName, contactName, Telephone principal (teINo, telNo branchNo) Registration (c1ientNo, c1ientNo branchNo, staffNo, dateJoined) clientNo hace referencia aStaff(staffNo)Client( c1ientNo) Clave PropertyForRent(propertyNo) principal clientNo, Viewing Clave propertyNo externa (c1ientNo, propertyNo propertyNo, hace referencia dateView, comment) wnerName) ranchNo) r(ownerNo) Clave alternativa telNo bName ff(staffNo) alternativa c1ientNo, rentStart staffNo) Clave principal externa ownerNo Clave Derivado newspaperName externa principal duration branchNo c1ientNo PropertyForRent(propertyNo) propertyNo Newspaper( propertyNo, hace (rentFinish hace referencia hace hace newspaperName) referencia newspaperName, referencia -referencia referencia rentStart) a aaaStaff(staffNo) aClient(clientNo) aBranch(branchNo) dateAdvert externa staffNo c1ientNo branchNo hace hace hace referencia referencia a Client(c1ientNo) Branch(branchNo) Derivado deposit (PropertyForRent.rent*2) PrivateOwner (ownerNo, fName,telNo, IName, address,maxRent) telNo) tart, Client (c1ientNo, fName, IName, prefType, type, Advert (propertyNo, dateAdvert, cost) Staff (staffNo, fName, newspaperName, IName, position, sex, DOB, salary,
Figura 16.8.
Tablas que representan el modelo lógico global de datos para DreamHome.
Paso 2.6.2 Validación del modelo lógico global de los datos Objetivo
Validar las tablas creadas a partir del modelo lógico de datos global usando la técnica de normalización y garantizar que soporten las transacciones requeridas, en caso necesario.
446
Sistemas de bases de datos
Manager staffNo
1..1
{PK, FK}
Telephone
0,,1 Manages
1..1
"
1,31. Provides
1..1 Branch
..•• Has 1..*
staffNo {PK} ,1 I supervisorStaffNo branchNo (FK) Processes
telNo {PK} branchNo (FK) 1..1
Staff
°
"
1..1
branchNo (PK) mgrStaffNo (FK)
{FK}
I 1 ,1
1..1
1 ,1 I Registers Registration
0,,*
"
1..*
c1ientNo {PK, FK} branchNo {FK} staffNo {FK} • Agrees
1..1 1..1
Client Oversees
"
c1ientNo
Holds I " 0,,*
Offers {PK}
"
1..1
1..1
Requests 0, * ' "
Lease
Viewing
leaseNo (PK) clientNo (FK) propertyNo {FK}
c1ientNo (PK, FK) propertyNo {PK, FK}
• I 0,,*
0*
LeasedBy
1..1
1..1
O" 100 I
PropertyForRent
1" *
propertyNo {PK} ownerNo (FK) staffNo {FK} branchNo (FK)
1..1
l. Takes
Placedln
" 0,,*
POwns./1..* 0,,1 PrivateOwner ownerNo
{PK}
Advert
BOwns• f1..* 0,,1 BusinessOwner ownerNo
(PK)
propertyNo {PK, FK} newspaperName {PK, FK} dateAdvert {PK}
• Displays
1 * 11..1
Newspaper newspaperName
Figura 16.9.
{PK}
Diagrama de tablas global para DreamHome.
Este paso es equivalente a los Pasos 2.2 y 2.3, en los que hemos validado cada modelo lógico de datos local. Sin embargo, sólo es necesario comprobar aquellas áreas del modelo donde se haya producido algún cambio durante el proceso de combinación. En un sistema de gran tamaño, esto reducirá significativamente la necesidad de efectuar posteriormente comprobaciones adicionales
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional
447
Paso 2.6.3 Revisión del modelo lógico global de los datos con los usuarios Objetivo
Revisar el modelo lógico de datos global con los usuarios para verificar que éstos consideran el modelo como una representación real de los requisitos de datos de la organización.
El modelo lógico global de los datos de la organización debería estar completo y ser lo suficientemente preciso. Es necesario revisar el modelo y la documentación que lo describe con los usuarios para verificar que se trata de una representación real de la organización. Para facilitar la descripción de las tareas asociadas con el Paso 2.6, es necesario utilizar los términos 'modelo lógico de datos local' y 'modelo lógico de datos global'. Sin embargo, al final de este paso, cuando los modelos de datos locales hayan sido combinados en un único modelo de datos global, dejará de ser necesaria la distinción entre los modelos de datos que hacen referencia a algunas de las vistas de usuario o a todas ellas. Por tanto, al completar este paso, utilizaremos el término 'modelo lógico de datos' para hacer referencia al único modelo de datos global, y emplearemos dicho término en lo que resta de la metodología. Paso 2.7 Verificar las consideraciones Objetivo
derivadas del crecimiento futuro
Determinar si cabe prever para el futuro cambios significativos y evaluar si el modelo lógico de datos puede aceptar dichos cambios.
El diseño lógico de la base de dato concluye tomando en consideración si el modelo lógico de datos (que puede o no haber sido desarrollado utilizando el Paso 2.6) es susceptible de ampliación para soportar posibles desarrollos futuros. Si el modelo sólo puede aceptar los actuales requisitos, la vida del modelo puede ser relativamente corta y requerir un trabajo de reconstrucción significativo para satisfacer los nuevos requisitos. Es importante desarrollar un modelo que sea ampliable y que pueda evolucionar para soportar los nuevos requisitos con un efecto mínimo sobre los usuarios existentes. Por supuesto, esto puede ser muy dificil de conseguir, ya que la organización puede no saber lo que desea hacer en el futuro. Incluso si sabe qué quiere hacer en el futuro, puede que sea prohibitivamente caro tanto en tiempo como en dinero prever desde el principio los posibles desarrollos futuros. Por tanto, es posible que sea necesario ser un tanto selectivo en cuanto a qué . funcionalidades soportar. En consecuencia, merece la pena examinar el modelo para comprobar si puede ser ampliado con un impacto mínimo. Sin embargo, no es necesario incorporar ningún cambio en el modelo de datos a menos que el usuario lo solicite. Al final del Paso 2, se utiliza el modelo lógico de dato como fuente de información para el diseño físico de la base de datos, diseño que se describirá en los siguientes dos capítulos y que forma los Pasos 3 a 8 de la metodología. Para los lectores que ya estén familiarizados con el diseño de bases de datos, en el Apéndice G se proporciona un resumen de los pasos de esta metodología.
Resumen del capítulo •
La metodología de diseño de base de datos incluye tres fases principales: diseño conceptual, diseño lógico y diseño fisico de la base de datos.
•
El diseño lógico de la base de datos es el proceso de construir un modelo de los datos utilizados en una empresa basándose en un modelo de datos específico pero sin prestar atención al SGBD concreto que se vaya a utilizar ni a otras consideraciones físicas.
•
Un modelo lógico de los datos incluye diagramas ER, un esquema relacional y la documentación soporte, como por ejemplo el diccionario de datos, que se genera al desarrollar el modelo.
•
El propósito del Paso 2.1 de la metodología de diseño lógico de bases de datos es construir un esquema relacional a partir del modelo de datos conceptual creado en el Paso l.
de
448
Sistemas de bases de datos
•
En el Paso 2.2 se valida un esquema relacional utilizando las reglas de normalización para garantizar que cada tabla sea estructuralmente correcta. La normalización se utiliza para mejorar el modelo de modo que satisfaga diversas restricciones que eviten la innecesaria duplicación de los datos. En el Paso 2.3 se valida también el esquema relacional para garantizar que soporte las transacciones incluidas en la especificación de requisitos del usuario.
•
En el Paso 2.4 se comprueban las restricciones de integridad del modelo lógico de los datos. Las restricciones de integridad son las restricciones que hay que imponer a la base de datos para proteger ésta frente a la posibilidad de llegar a ser incompleta, imprecisa o incoherente. Los tipos principales de restricciones de integridad son: datos requeridos, restricciones relativas a los dominios de los atributos, multiplicidad, integridad de las entidades, integridad referencial y restricciones generales.
•
En el Paso 2.5 se valida el modelo lógico de los datos junto con los usuarios.
•
El Paso 2.6 del diseño lógico de bases de datos es un paso opcional que sólo se necesita si la base de datos tiene múltiples vistas de usuario que están siendo gestionadas mediante la técnica de integración de vistas (véase la Sección 9.5), que hace que se creen dos o más modelos lógicos locales de los datos. Un modelo lógico local de los datos representa los requisitos de datos de una o más de las vistas de usuario de la base de datos, pero no de todas ellas. En el Paso 2.6, estos modelos de datos se combinan en un modelo lógico global de los datos que representa los requisitos de todas las vistas de usuario. Este modelo lógico de los datos se vuelve a validar mediante las técnicas de normalización, comprobándose también si soporta las transacciones requeridas y validándoselo junto con los usuarios.
•
El diseño lógico de base de datos concluye con el Paso 2.7, donde se considera si el modelo es susceptible de ampliación para soportar posibles desarrollos futuros. Al final del Paso 2, el modelo lógico de los datos, que puede o no haber sido desarrollado mediante el Paso 2.6, es la fuente de información para el diseño físico de la base de datos que se describe en los Capítulos 17 y 18 Y que constituye los Pasos 3 a 8 de la metodología.
Cuestiones de repaso 16.1.
Explique el propósito del diseño lógico de bases de datos.
16.2.
Describa las reglas para derivar tablas que representen: (a)
tipos de entidad fuertes;
(b)
tipos de entidad débiles;
(c)
tipos de relaciones binarias uno a muchos (1 :*);
(d)
tipos de relaciones binarias uno a uno (1: 1);
(e)
tipos de relaciones recursivas uno a uno (1 :1);
(f)
tipos de relaciones superclase/subclase;
(g)
tipos de relaciones recursivas muchos a muchos (*:*);
(h)
tipos de relaciones complejas;
(i)
atributos multivaluados.
Proporcione ejemplos para ilustrar sus respuestas. 16.3.
Explique cómo puede utilizarse la técnica de normalización para derivar las tablas derivadas a partir del modelo conceptual de los datos.
16.4.
Explique dos técnicas que pueden usarse para verificar que el esquema relacional es capaz de soportar las transacciones necesarias.
16.5.
Describa el propósito de las restricciones de integridad e identifique los tipos principales de restricciones de integridad existentes en un modelo lógico de los datos.
16.6.
Describa las estrategias alternativas que pueden aplicarse si existe una tupla hija que hace referencia a una tupla padre que queremos borrar.
Capítulo 16 Metodología: diseño lógico de bases de datos para el modelo relacional 16.7. Identifique las tareas normalmente datos en un modelo lógico global.
asociadas con la combinación
449
de modelos lógicos locales de los
Ejercicios 16.8. Derive las tablas a partir del siguiente modelo conceptual de datos:
1..1 1..1 Invoice Packagedln 1.1 OrderOetail Order Shipment 111 ..1 PaymentMethod ..* .** Places PartOf 10 .... 111..1 Product ...* T ..1 productNo T invoiceNo orderNo Has ~ ~~ shipmentNo pMethodFor ~ Prepares sMethodFor ••• 1..1 1 . .* ShipmentMethod sMethodNo
El caso de estudio de DreamHome 16.9. Cree un esquema relacional para la vista de usuario Branch de DreamHome basándose en el modelo conceptual de los datos contemplados en el Ejercicio 15.13 y compare su esquema con las tablas numeradas en la Figura 16.5. Justifique las diferencias que encuentre.
El caso de estudio University Accommodation Office 16.10. Cree y valide un modelo lógico de los datos a partir del modelo conceptual de los datos del caso de estudio University Accommodation Office creado en el Ejercicio 15.16.
El caso de estudio EasyDrive School of Motoring 16.11. Cree y valide un modelo lógico de los datos a partir del modelo conceptual de los datos del caso de estudio EasyDrive School of Motoring creado en el Ejercicio 15.18.
El caso de estudio Wellmeadows Hospital 16.12. Cree y valide el modelo lógico local de los datos para cada uno de los modelos de datos conceptuales locales del caso de estudio Wellmeadows Hospital identificados en el Ejercicio 15.21.
450
Sistemas de bases de datos
16.13. Combine los modelos de datos locales para crear un modelo lógico global de los datos del caso de estudio Wellmeadows Hospital. Indique las suposiciones en las que haya basado su diseño. 16.14. Cree o actualice el modelo lógico global de los datos del caso de estudio de Wellmeadows Hospital.
Metodología: diseño físico de bases de datos relacionales
Objetivos del capítulo: En este capítulo aprenderá: •
El propósito del diseño físico de bases de datos. entre el diseño lógico y el diseño físico de una base de datos.
•
Cómo establecer la correspondencia
•
Cómo diseñar las relaciones base para el SGBD seleccionado.
•
Cómo diseñar restricciones generales para el SGBD seleccionado.
•
Cómo seleccionar las organizaciones de archivos adecuadas basándose en el análisis de transacciones.
• •
Cuándo utilizar índices secundarios para mejorar las prestaciones. Cómo estimar el tamaño de la base de datos.
•
Cómo diseñar listas de usuario.
•
Cómo diseñar mecanismos de seguridad para satisfacer los requisitos del usuario.
En este capítulo y en el siguiente vamos a describir e ilustrar mediante ejemplos una metodología de diseño físico de bases de datos relacionales. El punto de partida para este capítulo es el modelo lógico de datos y la documentación que describe el modelo, creada mediante la metodología de diseño conceptual/lógico de bases de datos descrita en los Capítulos 15 y 16. Dicha metodología comenzaba generando un modelo conceptual de los datos en el Paso 1 y luego deducía una serie de relaciones para obtener un modelo lógico de los datos en el Paso 2. Esas relaciones deducidas se validaban para garantizar que estuvieron correctamente estructuradas, usando la técnica de normalización descrita en los Capítulos 13 y 14, Y para garantizar que soportaban las transacciones requeridas por los usuarios. En la tercera y última fase de la metodología de diseño de bases de datos, el diseñador debe decidir cómo traducir el diseño lógico de la base de datos (es decir, las entidades, atributos, relaciones y restricciones) en un diseño fisico de la base de datos que pueda implementarse mediante el SGBD seleccionado. Puesto que muchas partes del diseño físico de bases de datos son altamente dependientes del SGBD seleccionado, puede haber más de una forma de implementar cualquier parte concreta de la base de datos. En consecuencia, para llevar a cabo esta tarea adecuadamente, el diseñador debe ser plenamente consciente de la funcionalidad del SGBD seleccionado y debe comprender las ventajas y desventajas de cada una de las técnicas alternativas para una implementación particular. Para algunos sistemas, el diseñador puede también poder seleccionar una estrategia de almacenamiento adecuada que tome en consideración la utilización que se pretende hacer de la base de datos.
452
Sistemas de bases de datos
Estructura del capítulo En la Sección 17.1, vamos a comparar el diseño lógico y el diseño físico de una base de datos. En la Sección 17.2 proporcionaremos una panorámica de la metodología de diseño físico de bases de datos y describiremos brevemente las principales actividades asociadas con cada una de las fases del diseño. En la Sección 17.3 nos centraremos en la metodología del diseño físico de bases de datos y presentaremos una descripción detallada de los primero cuatro pasos requeridos para construir un modelo físico de los datos. En estos casos, mostraremos cómo convertir las relaciones deducidas a partir del modelo lógico de los datos en una implementación de bases de datos específica. Proporcionaremos directrices para la selección de las estructuras de almacenamiento para las relaciones base y para el proceso de decisión de si se deben crear índices. En algunos casos, mostraremos detalles físicos de implementación para clarificar las explicaciones. En el Capítulo 18 completaremos nuestra presentación de la metodología del diseño físico de bases de datos y explicaremos cómo monitorizar y optimizar el sistema final y, en particular, veremos cuándo resulta apropiado desnormalizar el modelo lógico de los datos e introducir redundancia. En el Apéndice G se presenta un resumen de la metodología del diseño de bases de datos para aquellos lectores que ya estén familiarizados con el diseño de bases de datos y simplemente quieran consultar una panorámica de los pasos principales.
17.1 Comparación del diseño lógico y del diseño físico de bases de datos Al presentar la metodología de diseño de bases de datos, hemos dividido el proceso de diseño en tres fases principales: diseño conceptual, lógico y físico de la base de datos. La fase anterior al diseño físico, es decir, el diseño lógico de bases de datos, es bastante independiente de los detalles de implementación, como por ejemplo de la funcionalidad específica del SGBD seleccionado y de los programas de aplicación, pero sí que depende del modelo de datos que se haya elegido. La salida de este proceso es un modelo lógico de los datos compuesto por un diagrama ER, un esquema relacional y la documentación de soporte que describe este modelo, como por ejemplo un diccionario de datos. Toda esta información, tomada conjuntamente, representa el punto de partida para el proceso de diseño físico y gracias a ella el diseñador físico de la base de datos dispone de un medio para llegar a compromisos que resultan cruciales a la hora de dotar de eficiencia al diseño de la base de datos. Mientras que el diseño lógico de la base de datos se preocupa de qué, el diseño físico de la base de datos está centrado en el cómo. Se requieren capacidades diferentes para ambos tipos de diseño, capacidades que a menudo se encuentran en personas distintas. En particular, el diseñador físico de la base de datos debe conocer cómo opera el sistema informático que alberga el SGBD y debe ser plenamente consciente de la funcÍonalidad del SGBD seleccionado. Puesto que la funcionalidad proporcionada por los sistemas actualmente disponibles varía ampliamente, el diseño físico debe adaptarse a un SGBD específico. Sin embargo, el diseño físico de la base de datos no es una actividad aislada, ya que a menudo existe cierta realimentación entre el diseño. fís!co, e.ldiseño lóg~co y el diseño ~e las aplicaciones: Por ejemplo~ las decisio?es 9!Le--s~men durante el dIseno fíSICOpara del mejorar prestacIOnes, como lo porque ejemplo comblllar unayfécto se9e-1Íe relaCIOnes, afectar a la estructura modelolas lógico de los datos, a su vez tendrá un sobre el diseñopueden de las aplicaciones.
17.2 Panorámica de la metodología de dis bases de datos Diseño físico de la base de datos
El proceso de generar una descripción de la implementación de la base de datos en almacenamiento secundario; describe las relaciones base, las organizaciones de archivos y los índices utilizados para conseguir un acceso eficiente a los datos, así como cualesquiera restricciones de integridad y medidas de seguridad asociadas.
Capítulo 17 Metodología: diseño físico de bases de datos relacionales
453
Los pasos de la metodología física del diseño de datos son los siguientes: Paso 3
Paso 4
Traducir el modelo lógico de los datos al SGBD seleccionado. Paso 3.1 Diseñar las relaciones base. Paso 3.2
Diseñar la representación de los datos variados.
Paso 3.3
Diseñar las restricciones generales.
Diseñar la organización de los archivos y los índices. Paso 4.1 Analizar las transacciones. Paso 4.2 Paso 4.3
Seleccionar la organización de los archivos. Seleccionar los índices.
Paso 4.4
Estimar los requisitos de espacio de disco.
Paso 5
Diseñar las vistas de usuario.
Paso 6 Paso 7
Diseñar los mecanismos de seguridad. Considerar la introducción de una cantidad controlada de redundancia.
Paso 8
Monitorizar y ajustar el sistema final.
La metodología del diseño fisico de bases de datos presentada en este libro está dividida en seis pasos principales, numerados consecutivamente a partir de 3 para seguir a partir de los pasos de la metodología de diseño conceptual y lógico de la base de datos. El Paso 3 del diseño físico de bases de datos implica el diseño de las relaciones base y de las restricciones generales utilizando la funcionalidad disponible en el SGBD seleccionado. Este paso también considera cómo debemos representar los datos derivados presentes en el modelo de datos. El Paso 4 implica seleccionar las organizaciones de archivo y los índices para las relaciones base. Normalmente, los SGBD para PC tienen una estructura de almacenamiento fijo, pero otros SGBD tienden a proporcionar una serie de organizaciones alternativas de archivo para los datos. Desde el punto de vista del usuario, la representación interna de las relaciones en los dispositivos de almacenamiento debe ser transparente, es decir, el usuario debe poder acceder a las relaciones y a las tuplas sin tener que especificar dónde o cómo están estas tuplas almacenadas. Esto requiere que el SGBD proporcione una independencia física de los datos, de modo que los usuarios no se vean afectados por los cambios que se realicen en la estructura física de la base de datos, como se explica en la Sección 2.1.5. La correspondencia entre el modelo lógico de los datos y el modelo físico de los datos se define en el esquema interno, como ya hemos indicado en la Figura 2.1. El diseñador ten~ que proporcionar detalles diseño físico tanto al SGBD de como al sistema operativo. Para el puede SGBD);pue~ iseñadorlostenga que de especificar las organizaciones archivos utilizadas para representaLCada relación; pa el sistema operativo, el diseñador debe especificar detalles tales como la ubicación y protección de cada a hivo. Recomendamos que el lector revise el Apéndice C, dedicado a las organizaciones de archivos y a las e tructuras de almacenamiento, antes de leer el Paso 4 de la metodOloglíap' ,\ d e b'e lmp 1ementarse ca d a VIsta . d e usuano. . El P aso 6· lmp l·lca E aso 5' lmp l'lca d eCI·d·Ir e 1 mo d o d e como diseñar los mecanismos de seguridad necesarios para proteger los datos frente a accesos no autorizados, incluyendo los controles de acceso requeridos para las relaciones base. El Paso 7 (descrito en el Capítulo 18) considera la posibilidad de relajar las restricciones de normalización impuestas al modelo lógico de los datos, con el fin de mejorar las prestaciones globales del sistema. Este paso sólo debe llevarse a cabo si es necesario, debido a los problemas inherentes al proceso de introducir redundancia mientras se mantiene la coherencia de la base de datos. El Paso 8 (Capítulo 18) es un proceso continuo de monitorización del sistema final, para identificar y resolver los problemas de prestaciones derivados del diseño, y para implementar requisitos nuevos o modificados. El Apéndice G presenta un resumen de la metodología para aquellos lectores que ya están familiarizados con el diseño de bases de datos y simplemente quieran conocer una panorámica de los pasos principales.
454
Sistemas de bases de datos
17.3 Metodología de diseño físico de bases de datos relaciona les Esta sección proporciona una guía paso a paso para los primeros cuatro pasos de la metodología de diseño físico de una base de datos relacional. En algunos casos, ilustraremos la estrecha asociación existente entre el diseño físico de la base de datos y la implementación describiendo cómo pueden implementarse diversos diseños alternativos en distintos sistemas SGBD. Los dos pasos restantes se cubren en el siguiente capítulo. Paso 3 Traducir el modelo lógico de los datos al SGSD Objetivo
seleccionado
Generar un esquema de base de datos relacional a partir del modelo lógico de los datos que pueda implementarse en el SGBD seleccionado.
La primera actividad del diseño físico de la base de datos implica la traducción de las relaciones contenidas en e] modelo lógico de los datos a una forma que pueda implementarse en el SGBD relacional seleccionado. La primera parte de este proceso implica recopilar la información obtenida durante el diseño lógico de la base de datos y que está documentada en el diccionario de datos, junto con la información generada durante la etapa de determinación y análisis de requisitos y que estará documentada en la especificación del sistema. La segunda parte del proceso utiliza esta información para realizar el diseño de las relaciones base. Este proceso requiere un conocimiento profundo de ]a funcionalidad ofrecida por el SGBD seleccionado. Por ejemplo, el diseñadar necesitará saber: •
cómo crear relaciones base;
•
si e] sistema soporta la defínición de claves principales, claves externas y claves alternativas;
•
si el sistema soporta la definición de datos requeridos (es decir, si el sistema permite definir los atributos como NOT NULL);
•
si el sistema soporta ]a definición de dominios;
•
si el sistema soporta las restricciones de integridad relacional;
• si el sistema soporta la definición de restricciones de integridad. Las tres actividades del Paso 3 son: Paso 3.1 Diseñar las relaciones base.
0
Paso 3.2
Diseñar la representación de los datos variados.
Paso 3.3
Diseñar las restricciones generales.
Paso 3.1 Diseñar las relaciones base Objetivo
Decidir cómo representar las relaciones base identificagas los datos dentro del SGBD seleccionado ..
en el modelo lógico de
Para comenzar el proceso físico de diseño, primero recopilamos y asimilamos la información sobre las relaciones definidas durante el diseño lógico de base de datos. La información necesaria puede obtenerse a partir del diccionario de datos y la definición de las relaciones descrita mediante el lenguaje de diseño de bases de datos (DBDL, Database Design Language). Para cada relación identificada en el modelo lógico de los datos, tenemos una definición compuesta por: •
el nombre de la relación;
•
una lista de atributos simples entre corchetes;
•
la clave principal y, cuando sea apropiado, las claves alternativas y las claves externas;
•
las restricciones de integridad referencial para todas las claves externas identificadas.
A partir del diccionario de datos, también conocemos para cada atributo:
Capítulo 17 Metodología:
diseño físico de bases de datos
•
su dominio, compuesto por un tipo de datos, una longitud y posiblemente sobre el dominio;
•
un valor predeterminado
relaciona les
455
una serie de restricciones
opcional para el atributo;
•
si el atributo puede almacenar valores nulos;
•
si el atributo es derivado y, en caso afirmativo, cómo se debe calcular.
Para representar el diseño de las relaciones base, utilizamos una forma ampliada del DBDL para definir los dominios, los valores predeterminados y los indicadores de nulidad. Por ejemplo, para la relación PropertyForRentdel caso de estudio DreamHome, podemos generar el diseño que se muestra en la Figura 17.1.
Implementación
de las relaciones base
El siguiente paso consiste en decidir cómo implementar las relaciones base. Esta decisión depende del SGBD seleccionado; algunos sistemas proporcionan más facilidades que otros para definir relaciones base. Ya hemos ilustrado anteriormente tres formas concretas de implementar relaciones base utilizando el están dar ISO SQL (Sección 6.1), Microsoft Office Access (Sección 8.1.3) y Oracle (Sección 8.2.3).
Documentación
del diseño de las relaciones base
El diseño de las relaciones base debe documentarse completamente, junto con las razones para seleccionar el diseño propuesto. En particular, hay que documentar las razones para seleccionar una alternativa concreta en aquellos casos donde existan muchas alternativas distintas.
Domain PropertyNumber: Domaín Street:
cadena de caracteres de longitud variable, longitud 5
Domaín City: Domain Postcode:
cadena de caracteres de longitud variable, longitud 15
D~rnain PropertyType: Dornain PropertyRooms:
un Único carácter, que debe ser uno de 'B', 'e', 'D', 'E', 'F, 'H', 'M', 'S'
Dornain PropertyRent: Domain OwnerNumber:
valor monetario, en el rango 0.00 - 9999.99
Domaín StaffNumber:
cadena de caracteres de longitud variable, longitud 5
Dornain BranchNumber:
cadena de caracteres de longitud fija, longitud 4
cadena de caracteres de longitud variable, longitud 25 cadena de caracteres de longitud variable, longitud 8 entero, en el rango 1-15 cadena de caracteres de longitud variable, longitud 5
PropertyForRent( propertyNo street
PropertyNumber Street
NOTNULL,
city
City
NOTNULL,
postcode
Postcode,
type rooms
PropertyType
NOT NULL DEFAULT 'F',
PropertyRooms
NOT NULL DEFAULT 4,
rent
NOT NULL DEFAULT 600,
ownerNo
PropertyRent OwnerNumber
staffNo
StaffNumber,
branchNo
BranchNumber
NOTNULL,
NOTNULL, NOTNULL,
PRlMARY KEY (propertyNo), FOREIGN KEY (staffNo) REFERENCES Staff(staffNo) ON UPDATE CASCADE ON DELETE SET NULL, FOREIGN KEY (ownerNo) REFERENCES PrivateOwner(ownerNo) and BusinessOwner(ownerNo) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (branchNo) REFERENCES Branch(branchNo) ON UPDATE CASCADE ON DELETE NO ACTION);
Figura 17.1.
DBDL para la relación PropertyForRent.
456 Paso
Sistemas de bases de datos 3.2 Diseñar
la representación
de los datos derivados
Decidir cómo representar los datos derivados presentes en el modelo lógico de los datos, dentro del SGBD seleccionado.
Objetivo
Los atributos cuyo valor pueda determinarse examinando los valores de otros atributos se conocen como atributos derivados o calculados. Por ejemplo, los siguientes serían atributos derivados: •
el número de empleados que trabajan en una sucursal concreta;
•
el salario mensual total de todos los empleados;
•
el número de inmuebles que un empleado gestiona.
A menudo, los atributos derivados no aparecen en el modelo lógico de los datos, sino que están documentados en el diccionario de datos. Si un atributo derivado se muestra en el modelo, se utiliza un carácter 'j' para indicar que es derivado (véase la Sección 11.1.2). El primero paso consiste en examinar el modelo lógico de los datos y el diccionario de los datos y generar una lista de todos los atributos derivados. Desde la perspectiva del diseño físico de la base de datos, la decisión de si un atributo derivado debe almacenarse en la base de datos o calcularse cada vez que sea necesario es uno de los compromisos a los que hay que llegar. El diseñador debe calcular: •
el coste adicional de almacenar los datos derivados y mantener la coherencia con los datos operativos a partir de los cuales se derivan;
•
el coste de calcular dichos datos derivados cada vez que sean necesarios.
Habrá que elegir la opción menos costosa, teniendo en cuenta las restricciones de prestaciones. Para el último de los ejemplos citados, podríamos almacenar un atributo adicional en la relación Staff que representara el número de inrnuebles gestionados actualmente por cada empleado. En la Figura 17.2 se muestra una relación Staff simplificada basada en la instancia de ejemplo de la base de datos DreamHome que se muestra en la Figura 3.3, con el nuevo atributo derivado noOfProperties. El gasto adicional de espacio de almacenamiento para este nuevo atributo derivado no sería particularmente significativo. El atributo tendría que actualizarse cada vez que se asignara o desasignara uno de los inmuePropertyForRent rent C087 4400 B005 SL41 London Lawrence C046 3350 3375 4450 B007 AB75SU SA9 House Aberdeen Novar 650 600 Holhead 56 B003 Dr St NW2 C040 C093 B003 G12 G129AX SG37 SG14 Flat 265street 18 ManorRd Dale Rd ownerNo rooms branchNo staffNo propertyNo postcode G119QX G324QX 616 Glasgow Argyll St type city Glasgow
Staff staffNo B003 B0051 B0071 Howe Brand Susan O White branchNo IName Lee B0031 BOOS Beech Ford Ann David fName Julieo2noOfProperties John Mary
Figura 17.2.
La relación PropertyforRent y una relación Staff simplificada, con el atributo derivado noOfProperties.
Capítulo 17 Metodología: diseño físico de bases de datos relacionales
457
bles gestionados por un empleado, o cada vez que un inmueble fuera eliminado de la lista de inmuebles disponibles. En cada uno de estos casos, el atributo noOfProperties correspondiente al empleado apropiado se incrementaría o reduciría en uno. Sería necesario garantizar que este cambio se realizara de manera coherente, con el fin de mantener el valor correcto y asegurar por tanto la integridad de la base de datos. Cuando se acceda mediante una consulta a este atributo, el valor estará inmediatamente disponible y no será necesario calcularlo. Por el contrario, si no se almacenara el atributo directamente en la relación 8taff, sería necesario calcularlo cada vez que se requiriera. Esto implica una combinación de las relaciones 8taff y PropertyForRent. Por tanto, si este tipo de consulta es frecuente o se considera crítica de cara al rendimiento del sistema, puede que resulte más apropiado almacenar el atributo derivado en lugar de calcularlo cada vez. También puede ser más apropiado almacenar los atributos derivados siempre que el lenguaje de consultas del SGBD no permita implementar fácilmente el algoritmo necesario para calcular el atributo derivado. Por ejemplo, SQL tiene un conjunto limitado de funciones de agregación y no puede manejar fácilmente las consultas recursivas, como se ha explicado en el Capítulo 5.
Documentación
del diseño de los datos derivados
El diseño de los datos derivados debe documentarse de modo completo, junto con las razones para seleccionar el diseño propuesto. En particular, es necesario documentar las razones para seleccionar una técnica concreta siempre que existan muchas alternativas. Paso
3.3 Diseñar
las restricciones generales
Objetivo
Diseñar las restricciones generales para el SGSD seleccionado.
Las operaciones de actualización de las relaciones pueden estar restringidas mediante una serie de restricciones de integridad que gobiernen las transacciones del 'mundo real' que las actualizaciones representan. En el Paso 3.1 hemos diseñado una serie de restricciones de integridad: datos requeridos, restricciones de dominio e integridad de entidades y referencia\. En este caso, tenemos que tomar en consideración las restantes restricciones generales. El diseño de cada restricción es también dependiente del SGBD elegido; algunos sistemas proporcionan más facilidades que otros para definir restricciones generales. Como en el paso anterior, si el sistema es compatible con el estándar SGL, algunas restricciones pueden ser fáciles de implementar. Por ejemplo, DreamHome tiene una regla que impide a un empleado gestionar más de 100 inmuebles al mismo tiempo. Podríamos incluir esta restricción en la instrncción SQL CREATE TABLE para PropertyForRent utilizando la siguiente cláusula: CONSTRAINT 8taffNotHandlingTooMuch CHECK (NOT EXISTS (SELECT staffNo FROM PropertyForRent GROUP BY staffNo HAVING COUNT(*) > 100)) En la Sección 8.1A hemos visto cómo implementar esta restricción en Microsoft Office Access utilizando un procedimiento de suceso en VBA (Visual Basic for Applications). Alternativamente, podríamos utilizar un disparador para imponer algunas de las restricciones, como hemos ilustrado en la Sección 8.2.7. En algunos sistemas, no habrá soporte para algunas de las restricciones generales, o para todas ellas, y será necesario incluir las restricciones dentro de la aplicación. Por ejemplo, hay pocos SGBD relacionales (si es que hay alguno) que sean capaces de gestionar una restricción temporal tal como 'a las 17:30 del último día laborable de cada año, archivar los registros correspondientes a todos los inmuebles vendidos durante dicho año y borrar los registros asociados'.
Documentación
del diseño de las restricciones
generales
El diseño de las restricciones generales debe documentarse de modo completo. En particular, es necesario documentar las razones para seleccionar una técnica completa cuando existan múltiples alternativas.
458
Sistemas de bases de datos
Paso 4
Diseñar la organización de los archivos y los índices
Objetivo
Determinar las organizaciones óptimas de archivo para almacenar las relaciones base y los índices que se requieren para conseguir unas prestaciones aceptables, es decir, determinar la forma en que se guardarán en almacenamiento secundario las relaciones y tuplas.
Uno de los objetivos principales del diseño físico de bases de datos es almacenar y acceder a los datos de una manera eficiente (véase el Apéndice C). Mientras que algunas estructuras de almacenamiento son eficientes para la carga masiva de datos en la base de datos, puede que sean ineficientes para las operaciones posteriores. Por tanto, puede que tengamos que utilizar una estructura eficiente de almacenamiento para preparar la base de datos y luego seleccionar otra para la operación diaria. De nuevo, los tipos de organizaciones de archivos existentes dependen del SGBD seleccionado; algunos sistemas proporcionan una mayor selección de estructuras de almacenamiento que otros. Es extremadamente importante que el diseñador físico de la base de datos comprenda perfectamente las estructuras de almacenamiento disponibles y el modo en que el SGBD utiliza estas estructuras. Esto puede requerir que el diseñador conozca cómo funciona el optimizador de consultas del sistema. Por ejemplo, puede haber circunstancias en las que el optimizador de consultas no utilice un índice secundario, aún cuando haya uno disponible. En este caso, la adición de un índice secundario no mejoraría la velocidad de la consulta y el coste adicional asociado no estaría justificado. Hablaremos del procesamiento y optimización de consultas en el Capítulo 2l. Al igual que con el diseño lógico de bases de datos, el diseño fisico de la base de datos debe estar guiado por la naturaleza de los datos y por el uso que se pretende hacer de los mismos. En particular, el diseñador de la base de datos debe comprender cuál es la carga de trabajo típica que la base de datos debe soportar. Durante la etapa de recopilación y análisis de requisitos, puede que se hayan documentado requisitos relativos a la velocidad en la que ciertas transacciones deben ejecutarse o al número de transacciones que deben procesarse por segundo. Esta información forma la base para una serie de decisiones que habrá que tomar durante este paso. Con estos objetivos en mente, vamos a analizar ahora las distintas actividades que componen el Paso 4: Paso 4.1 Analizar las transacciones. Paso 4.2 Paso 4.3
Seleccionar la organización de los archivos. Seleccionar los índices.
Paso 4.4
Estimar los requisitos de espacio de disco.
Paso 4. 1 Analizar las transacciones Objetivo
Comprender la funcionalidad de las transacciones que se ejecutarán en la base de datos y analizar las transacciones más importantes.
Para llevar a cabo de manera efectiva el diseño fisico de la base de datos, es necesario tener un conocimiento de las transacciones o consultas que se ejecutarán sobre la base de datos. Esto incluye información tanto cuantitativa como cualitativa. A la hora de analizar las transacciones, trataremos de identificar criterios de rendimiento, tales como: •
las transacciones que se ejecutan frecuentemente y que tendrán un impacto significativo sobre las prestaciones;
•
las transacciones que resultan críticas para la operación de la empresa;
•
los momentos del día y de la semana en los que la demanda de procesamiento de datos (lo que se llama pico de carga).
será mayor en la base
Utilizaremos esta información para identificar las partes de la base de datos que pueden causar problemas de rendimiento. Al mismo tiempo, necesitamos identificar la funcionalidad de alto nivel de las transacciones, como por ejemplo los atributos que son actualizados en una transacción de actualización o los criterios utili-
Capítulo 17 Metodología: diseño físico de bases de datos relacionales
459
zados para restringir las tuplas que se extraen en una consulta. Utilizaremos esta información para seleccionar organizaciones de archivo e índices apropiados. En muchas situaciones, no es posible analizar todas las transacciones esperadas, pero sí que deberemos al menos investigar las más 'importantes'. Se ha sugerido que el 20% de las consultas de usuario más activas representan el 80% del acceso total a los datos (Wiederhold, 1983). Esta regla 80/20 puede utilizarse como directriz a la hora de llevar a cabo el análisis. Como ayuda para la identificación de las transacciones que hay que investigar, podemos utilizar una matriz cruzada de transacciones/relaciones que muestre las relaciones a las que accede cada transacción, y/o un mapa de utilización de las transacciones que indique en un' diagrama cuáles son las relaciones que van a ser potencialmente más utilizadas. Para centrarse en las áreas más problemáticas, una forma de proceder es la siguiente: (1) establecer la correspondencia
entre todas las rutas de las transacciones y las relaciones;
(2) determinar cuáles son las relaciones a las que más frecuentemente
acceden las transacciones;
(3) analizar la utilización de datos por parte de una serie de transacciones seleccionadas que afecten a estas relaciones.
Establecer la correspondencia las relaciones
entre todas las rutas de las transacciones
y
En los Pasos 1.8, 2.3 Y 2.6.2 de la metodología de diseño conceptual/lógico de la base de datos hemos validado los modelos de datos para garantizar que soporten las transacciones requeridas por los usuarios, para lo cual establecíamos una correspondencia entre las rutas de las transacciones y las entidades/relaciones. Si se ha utilizado un diagrama de rutas de transacción similar al que se muestra en la Figura 15.9, puede que podamos utilizar este diagrama para determinar las relaciones a las que más frecuentemente se accede. Por el contrario, si se han validado las transacciones de alguna otra manera, puede que resulte útil crear una matriz cruzada de transacciones/relaciones. La matriz muestra de forma visual las transacciones necesarias y las relaciones a las que acceden. Por ejemplo, la Tabla 17.1 muestra una matriz cruzada de transacciones/relaciones para la siguiente selección de transacciones típicas de introducción de datos, actualización/borrado y consulta para el caso de DreamHome (véase el Apéndice A): (A) Introducir los detalles de un nuevo inmueble y del propietario (como por ejemplo del inmueble PG4 en Glasgow propiedad de Tina Murphy). (B) Actualizar/borrar
los detalles de un inmueble.
Vista Staff
(C) Identificar el número total de empleados de cada categoría en las sucursales de Glasgow. (D) Generar un listado con el número de inmueble, dirección, tipo y alquiler para todos los inmuebles de Glasgow, ordenados según el importe del alquiler. (E) Generar un listado con los detalles de los inmuebles en alquiler gestionados por un cierto empleado.
Vista Branch
(F) Identificar el número total de inmuebles asignados a cada empleado en una cierta sucursal. La matriz indica, por ejemplo, que la transacción (A) lee la tabla Staff y también inserta tuplas en las relaciones PropertyForRent y PrivateOwner/BusinessOwner. Para ser más útil, la matriz debe indicar en cada celda el número de accesos en un cierto intervalo de tiempo (por ejemplo, cada hora, cada día o cada semana). Sin embargo, para no complicar demasiado la matriz, hemos decidido no mostrar esta información. Esta matriz muestra que tanto las relación Staff como PropertyForRent son utilizadas por cinco de las seis transacciones, por lo que un acceso eficiente a estas relaciones puede ser importante para evitar la aparición de problemas de rendimiento. Por tanto, concluiremos que es necesaria una inspección más detallada de estas transacciones y relaciones.
460
Sistemas de bases de datos Tabla 17.1.
Transacción/Relación
Matriz cruzada de transacciones
y relaciones.
(A)
(B)
(C)
(D)
(E)
(F)
LABI
LABI
LABI
LABI
LABI
LAB
x
x
Branch
x
Telephone
x
Staff
x
x
x
x
X
X
Manager PrivateOwner
x
B usinessOwner
X
PropertyForRent
X
X X X
X
Viewing Client Registration Lease Newspaper Advert I = Inserción; L = Lectura; A = Actualización;
B = Borrado
Determinación de la información de frecuencias En la especificación de requisitos para DreamHome dada en la Sección 10.4.4, se estimaba que había unos 100.000 inmuebles en alquiler y unos 2000 empleados distribuidos entre 100 sucursales, con una media de 1000 y un máximo de 3000 inmuebles en cada sucursal. La Figura 17.3 muestra el mapa de uso de las transacciones para las transacciones (C), (D), (E) Y (F), todas las cuales acceden al menos a una de las dos relaciones 8taff y PropertyForRent; en el mapa se muestra la información cuantitativa extraída de la especificación de requisitos. Debido al tamaño de la relación PropertyForRent, es importante que el acceso a esta relación sea lo más eficiente posible. Podemos por tanto decidir que resultaría útil realizar un análisis más detallado de las transacciones que afecten a esta relación concreta. Al considerar cada transacción, es importante conocer no sólo el número máximo y medio de veces que se ejecuta por hora, sino también el día y la hora en que la transacción se ejecuta, incluyendo cuándo se espeprom
(E) 01 2000 0 ..100
= 20
max = 40 ----(D) -..Branch 1.,* PropertyForRent 1..1 100 1..* .•• Has
(F) Stall 100000
(e) 1..1
~
"f
Offers
Manages
prom = 50 max = 100
Figura 17.3.
prom = 1000 max = 3000
Mapa de uso de transacciones para algunas transacciones donde se muestra el número de transacciones esperadas.
de ejemplo
Capítulo 17 Metodología:
diseño físico de bases de datos
relaciona les
461
ran los picos de carga. Por ejemplo, algunas transacciones pueden ejecutarse a la frecuencia media la mayor parte del tiempo, pero tener un pico de carga entre las 14:00 y las 16:00 los jueves, antes de la reunión semanal que se celebra los viernes por la mañana. Otras transacciones puede que sólo se ejecuten en instantes específICOS,por ejemplo de 17:00-19:00 los viernes/sábados, siendo también dichos intervalos los que corresponden a su pico de carga. Cuando las transacciones requieren un acceso frecuente a determinadas relaciones concretas, su patrón de operación es muy importante. Si estas transacciones operan de forma mutuamente exclusiva, el riesgo de que aparezcan problemas de rendimiento se reduce. Sin embargo, si sus patrones de operación entran en conflicto, los problemas potenciales pueden aliviarse examinando las transacciones más en detalle para determinar si pueden hacerse cambios en la estructura de las relaciones con el fin de mejorar la velocidad, como explicaremos en el Paso 7 del siguiente capítulo. Alternativamente, puede que sea posible reprogramar algunas transacciones para que sus patrones de operación no entren en conflicto (por ejemplo, puede que sea posible retrasar algunas transacciones de generación de información de resumen hasta algún momento más tranquilo durante la tarde o por la noche).
Análisis del uso de los datos Habiendo identificado las transacciones más importantes, ahora analizaremos cada una de ellas con mayor detalle. Para cada transacción, debemos determinar: • Las relaciones y atributos a los que accede la transacción y el tipo de acceso; es decir, si se trata de una transacción de inserción, actualización, borrado o extracción (también denominada de consulta). Para una transacción de actualización, anote los atributos que son actualizados, ya que estos atributos pueden ser candidatos para evitar una estructura de acceso (como por ejemplo un índice secundario). •
Los atributos usados en los predicados (en SQL, los predicados son las condiciones especificadas en la cláusula WHERE). Comprobar si los predicados implican: • • •
correspondencia de patrones; por ejemplo: (name LIKE '%Smith%'); búsquedas de rango, por ejemplo: (salary BETWEEN 10000 AND 20000); extracción de claves exactamente especificada; por ejemplo: (salary = 30000).
Esto no se aplica sólo a las consultas, sino también a las transacciones de actualización y borrado, que pueden restringir las tuplas que hay que actualizar/borrar en una relación. Estos atributos pueden ser candidatos para el establecimiento •
de estructuras de acceso.
Para las consultas, los atributos implicados en la combinación de dos o más relaciones. De nuevo, estos atributos pueden ser candidatos para el establecimiento
de estructuras de acceso
•
La frecuencia esperada con la que se ejecutarán dichas transacciones; transacción vaya a ejecutarse aproximadamente 50 veces al día.
por ejemplo, puede que una
•
Los objetivos de rendimiento para la transacción; por ejemplo, que la transacción deba completarse en menos de 1 segundo. Los atributos utilizados en los predicados de las transacciones muy frecuentes tener una mayor prioridad a la hora de establecer estructuras de acceso.
o críticas deben
La Figura 17.4 muestra un ejemplo de formulario de análisis de transacciones para una de las transacciones mencionadas (D). Este formulario muestra que la frecuencia media de esta transacción es de 50 veces por hora, con un pico de carga de 100 veces por hora a diario entre las 17:00 y las 19:00. En otras palabras, normalmente la mitad de las sucursales ejecutan esta transacción una vez por hora y durante los picos de carga todas las transacciones la ejecutan una vez por hora. El formulario también muestra la instrucción SQL requerida y el mapa de utilización de transacciones. En esta etapa, puede que sea demasiado detallada la instrucción SQL completa, pero deben identificarse los tipos de detalles que se muestran aliado de la instrucción SQL, es decir:
462
Sistemas de bases de datos
Formulario Transacción
de análisis de transacción
1-Sept-2004
(O) genera un listado con el número de inmueble, dirección, tipo y alquiler para todos los inmuebles de Glasgow, ordenados según el importe del alquiler
Volumen de transacciones Medio: Pico:
50 por hora 100 por hora (entre las 17.00 y las 19.00 lunes-sábado)
SELECT propertyNo, p.street, p.postcode, type, rent Predicado: p.city '= 'Glasgow' FROM Branch b INNER JOIN PropertyForRent pON Atributos combinación b.branchNo '= p.branchNo b.branchNo '= p.branchNo Atributo ordenación: rent Atributo de agrupación: Ninguno WHERE p.city '= 'Glasgow' Funciones predefinidas: Ninguno OROER BY rent; Atributos actualizados: Ninguno
Mapa de uso de la transacción Branch (100)
1 ••••••
2 prom - 1000 max - 3000
Supone que hay 4 sucursales en Glasgow
1.1
. : Offers : T
.
T
11.*
PropertyForRent (100000)
100Entidad 10000 200000-600000 400000-1200000 Acceso I I 4000-12000 II No. de referencias por 205000-605000 4100-12100 I5000 410000-1210000 Promedio por hora hora Tipo Branch PropertyForRent (entry) LPico Por transacción
Figura 17.4.
I
Formulario de análisis de transacciones
de ejemplo.
•
los predicados que se vayan a usar;
•
los atributos requeridos para combinar relaciones (para las transacciones de consulta);
•
los atributos empleados para ordenar los resultados (para las transacciones de consulta);
•
los atributos utilizados para agrupar los datos (para las transacciones de consulta);
•
las funciones predefinidas que puedan utilizarse (como por ejemplo AVG, SUM);
•
los atributos que serán actualizados por la transacción.
Esta información se utilizará para determinar los índices necesarios, como se explica a continuación. Debajo del mapa de uso de las transacciones, hay un resumen detallado donde se documenta: •
cómo se accede a cada relación (lecturas en este caso);
Capítulo 17 Metodología:
diseño físico de bases de datos
relaciona les
•
a cuántas tuplas se accederá cada vez que se ejecute la transacción;
•
a cuántas tupla se accederá por hora tanto en término medio como durante los picos de carga.
463
La información de frecuencia nos permitirá identificar las relaciones a las que habrá que prestar una cuidadosa atención para garantizar que se utilicen las apropiadas estructuras de acceso. Como hemos mencionado anteriormente, las condiciones de búsqueda utilizadas por las transacciones que estén afectadas por restricciones de tiempo de ejecución tienen una mayor prioridad a la hora de determinar las estructuras de acceso requeridas. Paso
4.2 Seleccionar
Objetivo
la organización
de los archivos
Determinar una organización
de archivo eficiente para cada relación base.
Uno de los principales objetivos del diseño físico de base de datos es el almacenar y acceder a los datos de una manera eficiente. Por ejemplo, si queremos extraer las tuplas de los empleados en orden alfabético, una buena organización del archivo consistiría en ordenarlo mediante el nombre de los empleados. Sin embargo, si queremos extraer todos los empleados cuyo salario se encuentre en un cierto rango, no resultaría particularmente eficiente realizar una búsqueda en un archivo que estuviera ordenado por el nombre del empleado. Para complicar las cosas todavía más, algunas organizaciones de archivo son eficientes para la carga masiva de datos en la base de datos pero ineficientes para la operación cotidiana. En otras palabras, puede que sea necesario utilizar una estructura eficiente de almacenamiento para preparar la base de datos y luego cambiarla para la operación cotidiana normal. El objetivo de este paso es por tanto elegir una organización óptima de archivo para cada relación, si es que el SGBD seleccionado lo permite. En muchos casos, un SGBD relacional puede proporcionar muy pocas opciones, o ninguna, a la hora de seleccionar la organización de los archivos, aunque puede que se establezcan determinadas organizaciones de archivo a medida que se especifiquen los índices. De todos modos, como ayuda para comprender mejor las organizaciones de archivo y los índices, en el Apéndice C.7 se proporcionan directrices para seleccionar una organización de archivo concreta basándose en los siguientes tipos de archivo: •
Cúmulo
•
Hash
• •
ISAM (Indexed Sequential Access Method, método de acceso secuencial indexado) B+-tree
•
Clústeres
Si el SGBD seleccionado no permite elegir la organización de los archivos, puede omitirse este paso.
Documentación
de la selección de organizaciones
de archivos
Debe documentarse completamente la selección de organizaciones de archivos, junto con las razones de la selección realizada. En particular, es necesario documentar las razones por las que se ha elegido una determinada técnica cuando existen muchas técnicas alternativas. Paso
4.3
Seleccionar
Objetivo
los índices Determinar si la adición de índices permitirá mejorar las prestaciones
del sistema.
Una técnica para seleccionar una organización de archivo apropiada para una relación consiste en mantener las tuplas desordenadas y crear tantos índices secundarios como sea necesario. Otra técnica es ordenar las tuplas de la relación especificando un índice principal o de clustering (véase el Apéndice C.S). En este caso, el atributo que se debe seleccionar para ordenar o agrupar en clúster las tuplas será: •
el atributo que se ha utilizado más a menudo para operaciones de combinación, ya que esto hace que la operación de combinación sea más eficiente, o
464
Sistemas de bases de datos
•
el atributo que se ha utilizado más a menudo para acceder a las tuplas de una relación según el orden de dicho atributo.
Si el atributo de ordenación seleccionado es una clave de la relación, el índice será un índice principal; si el atributo de ordenación no es una clave, el índice será un índice de clustering. Recuerde que cada relación sólo puede tener un índice principal o un índice de clustering.
Especificación
de los índices
Hemos visto en la Sección 6.3.4 que un índice puede crearse usualmente en SQL utilizando la instrucción CREATE INDEX. Por ejemplo, para crear un índice principal en la relación PropertyForRent basado en el atributo propertyNo, podríamos utilizar la siguiente instrucción SQL: CREATE UNIQUE INDEX
PropertyNolnd
ON
PropertyForRent(propertyNo);
Para crear un índice de clustering en la relación utilizar la siguiente instrucción SQL: CREATE INDEX
PropertyForRent
StaffNolnd ON PropertyForRent(staffNo)
basado en el atributo
staffNo,
podríamos
CLUSTER;
Como ya hemos mencionado, en algunos sistemas la organización de los archivos es fija. Por ejemplo, hasta hace poco Oracle sólo soportaba las organizaciones tipo B+-tree, pero ahora ha añadido el soporte para clústeres. Por el contrario, INGRES ofrece un amplio conjunto de estructuras de índice entre las cuales se puede elegir utilizando la siguiente cláusula opcional de la instrucción de la opción CREATE INDEX: [STRUCTURE = BTREE
I
ISAM
I
HASH
I
HEAP]
Selección de índices secundarios Los índices secundarios proporcionan un mecanismo para especificar una clave adicional en una relación base con la cual se puedan extraer los datos más eficientemente. Por ejemplo, la relación PropertyForRent puede almacenarse distribuyendo las tupla según el número de inmueble, propertyNo, que es el índice principal. Sin embargo, puede que se realicen frecuentes accesos a esta relación basándose en el atributo rent. En este caso, podemos añadir rent como índice secundario. El mantenimiento y utilización de índices secundarios tiene un cierto coste, que será preciso equilibrar de acuerdo con la mejora de prestaciones que se obtiene a la hora de extraer los datos. Este coste adicional incluye: •
la adición de un registro de índice a todos los índices secundarios cada vez que se inserta una tupla a una relación;
•
la actualización de cada índice secundario cuando se actualiza la correspondiente
•
el incremento en espacio de disco debido a la necesidad de almacenar el índice secundario;
•
la posible disminución de la velocidad durante la optimización de consultas, ya que el optimizador de consultas tendrá que analizar todos los índices secundarios antes de seleccionar una estrategia de ejecución óptima.
Directrices
tupla en la relación;
para la selección de una serie de índices candidatos
Una técnica para determinar los índices secundarios necesarios consiste en generar una serie de atributos 'candidatos' para la indexación y luego analizar el impacto que tiene mantener cada uno de estos índices. Para producir esa lista de índices 'candidatos', tenga en cuenta los siguientes consejos: (1) No indexe las relaciones pequeñas. Puede ser más eficiente realizar una búsqueda de la relación en memoria que almacenar una estructura de índice adicional. (2) En general, indexe la clave principal de una relación si no es una clave utilizada en la organización del archivo. Aunque el estándar SQL proporciona una cláusula para la especificación de claves principa-
Capítulo 17 Metodología: diseño físico de bases de datos relacionales
465
les, como se explica en la Sección 6.2.3, es preciso tener en cuenta que esto no garantiza que se indexe la clave principal. (3) Añada un índice secundario a las claves externas si se accede a éstas frecuentemente. Por ejemplo, puede que tengamos que combinar frecuentemente la relación PropertyForRent y las relaciones PrivateOwner/BusinessOwnersegún el atributo ownerNo, el número de propietario. Debido a ello, puede que sea más eficiente añadir un índice secundario a la relación PropertyForRent basado en el atributo ownerNo.Tenga en cuenta que algunos SGBD pueden indexar automáticamente las claves externas. (4) Añada un índice secundario a cada atributo que se utilice intensamente como clave secundaria (por ejemplo, añada un índice secundario a la relación PropertyForRent basado en el atributo rent, como se explica anteriormente. (5) Añada un índice secundario a los atributos que estén frecuentemente (a) criterios de selección o combinación;
implicados en:
(b)
ORDER BY;
(c)
GROUP BY;
(d)
otras operaciones que implican ordenaciones (como por ejemplo, UNION o DISTINCT).
(6) Añada un índice secundario a los atributos utilizados en funciones de agregación predefinidas, junto con los atributos usados para las funciones predefinidas. Por ejemplo, para averiguar el salario medio de los empleados en cada sucursal, podríamos utilizar la siguiente consulta SQL: SELECT branchNo, AVG(salary) FROM Staft GROUP BY branchNo; Aplicando el consejo mencionado, podríamos pensar en añadir un índice al atributo branchNo debido a la existencia de la cláusula GROUP BY. Sin embargo, puede que sea más eficiente definir un índice tanto sobre el atributo branchNo como sobre el atributo salary. Esto puede permitir al SGBD procesar la consulta completamente a partir sólo de los datos del índice, sin tener que acceder al archivo de datos. Esto es lo que en ocasiones se denomina un plan de sólo índice, ya que puede generarse la respuesta requerida utilizando únicamente los datos almacenados en el índice. (7) Como generalización de la directriz anterior, añada un índice secundario a aquellos atributos que puedan permitir generar planes de sólo índice. (8) Evite indexar un atributo o relación que sean actualizados frecuentemente. (9) Evite indexar un atributo si la consulta devuelve una parte significativa (por ejemplo el 25%) de las tuplas de la relación. En este caso, puede que sea más eficiente explorar la relación completa que realizar la exploración mediante un índice. (10) Evite indexar los atributos que consistan en cadenas de caracteres de gran longitud. Si los criterios de búsqueda implican más de un predicado y uno de los términos contiene una cláusula OR la adición de índices basados en los otros atributos no permitirá mejorar la velocidad de la consulta, porque continuará siendo necesario realizar una búsqueda lineal en la relación. Por ejemplo, suponga que sólo están indexados los atributos type y rent de la relación PropertyForRenty que tenemos que utilizar la siguiente consulta:
y el término no tiene ningún orden de indexación/ordenación,
SELECT * FROM PropertyForRent WHERE (type = 'Flat' OR rent > 500 OR rooms > 5); Aunque podrían utilizarse los dos índices para localizar las tuplas para las que (type = 'Flat o rent > 500), el hecho de que el atributo rooms no esté indexado implica que dichos índices no pueden emplearse para la cláusula WHERE completa. Por tanto, a menos que haya otras consultas que puedan beneficiarse de la indexación de los atributos type y rent, no se tiene ninguna ventaja por indexarlos para esta consulta.
466
Sistemas de bases de datos
Por otro lado, si los predicados de la cláusula WHERE estuvieran combinados mediante AND, podrían utilizarse los dos índices correspondientes a los atributos type y rent para optimizar la consulta.
Eliminación de índices candidatos Habiendo redactado la lista de índices 'candidatos' potenciales, es preciso ahora considerar el impacto que cada uno de ellos tiene sobre las transacciones de actualización. Si resulta posible que el mantenimiento del índice ralentice determinadas transacciones de actualización importantes, puede que convenga eliminar dicho índice de la lista. Tenga en cuenta, sin embargo, que un índice concreto también puede hacer que ciertas operaciones de actualización sean más eficientes. Por ejemplo, si queremos actualizar el salario de un empleado a partir del número del empleado, staffNo, y tenemos un índice sobre staffNo, la tupla que hay que actualizar puede localizarse más rápidamente. Resulta conveniente experimentar siempre que sea posible para determinar si un cierto índice está mejorando las prestaciones, está proporcionando una mejora no suficientemente significativa o está afectando de forma adversa al rendimiento. En este último caso, está claro que debemos eliminar dicho índice de la lista de índices candidatos. Si la mejora observada con la adición del índice no es muy grande, puede que sea necesario realizar más análisis para determinar en qué circunstancias puede ser útil el índice y si estas circunstancias son lo suficientemente importantes como para que merezca la pena implementar el índice. Algunos sistemas permiten a los usuarios inspeccionar la estrategia del optimizador para ejecutar una determinada consulta o actualización, lo que a veces se denomina plan de ejecución de la consulta (QEP, Query Execution Plan). Por ejemplo, Microsoft Office Access tiene un analizador de rendimiento (Performance Analyzer), Oracle tiene una utilidad de diagnóstico denominada EXPLAIN PLAN (véase la Sección 21.6.3), DB2 tiene una utilidad EXPLAIN e INGRES tiene una función de visualización en línea de los planes de ejecución de las consultas. Cuando una consulta se ejecute más lentamente de lo previsto, resulta conveniente utilizar dicho tipo de funciones para determinar la razón de la lentitud y definir una estrategia alternativa que permita mejorar la velocidad de la consulta. Si se está insertando un gran número de tuplas en una relación donde hay definidos uno o más índices, puede que sea más eficiente eliminar primero los índices, realizar las actualizaciones y luego volver a crear los índices. Como regla práctica, si la operación de inserción va a incrementar el tamaño de la relación en al menos un 10%, conviene eliminar temporalmente los índices.
Actualización
de las estadísticas de la base de datos
El optimizador de consultas utiliza las estadísticas de la base de datos que se conservan en el catálogo del sistema con el fin de seleccionar la estrategia óptima. Cada vez que creamos un índice, el SGBD añade automáticamente la presencia del índice al catálogo del sistema. Sin embargo, puede que el SGBD requiera que se ejecute una determinada utilidad para actualizar las estadísticas del catálogo del sistema referidas a la relación y al índice.
Documentación
de la selección de índices
Es necesario documentar completamente la selección de índices, junto con las razones en las que se basa. En particular, si hay razones de rendimiento por las que no pueden indexarse determinados atributos, es necesario que queden documentadas.
Organizaciones de archivo e índices para DreamHome con Microsoft Office Access Al igual que la mayoría de los SGBD para PC, Microsoft Office Access utiliza una organización de archivo fija, por lo que si el SGBD seleccionado es Microsoft Office Access se puede omitir el Paso 4.2. Microsoft Office Access sí soporta, sin embargo, los índices, como ahora veremos. En esta sección vamos a utilizar la terminología de Office Access, que denomina tablas a las relaciones, las cuales están compuestas de campos y registros.
Capítulo 17 Metodología:
diseño físico de bases de datos
relaciona les
467
Directrices relativas a los índices En Oflice Access, la clave principal de una tabla se indexa automáticamente, pero no se puede indexar un campo cuyo tipo de datos sea Memo, Hyperlink u OLE Object. Para el resto de campos el consejo de Microsoft es que se indexe el campo si se cumplen todas las siguientes condiciones: •
el tipo de datos del campo es Text, Number, Currency o Date/Time;
•
se prevé que se van a tener que buscar valores almacenados en dicho campo;
•
se prevé que se van a tener que ordenar los valores de dicho campo;
•
se prevé que se van a tener que almacenar muchos valores diferentes en dicho campo. Si muchos de los valores del campo son iguales, es posible que el índice no permita acelerar las consultas de manera significativa.
Además, Microsoft aconseja: •
indexar los campos situados en ambos lados de una combinación o crear una relación entre estos campos, en cuyo caso Oflice Access creará automáticamente un índice sobre el campo de clave externa, si es que no existe ya uno;
•
cuando se agrupen registros según los valores de un campo de combinación, hay que especificar GROUP BY para el campo que se encuentre en la misma tabla que el campo sobre el que se esté calculando la agregación.
Microsoft Office Access puede optimizar predicados tanto simples como complejos (lo que se denominan expresiones en Office Access). Para ciertos tipos de expresiones complejas, Microsoft Oflice Access utiliza una tecnología de acceso a datos denominada Rushmore para conseguir un mayor nivel de optimización. Una expresión compleja se forma combinando dos expresiones simples mediante los operadores AND y OR, como por ejemplo: branchNo = 'B001' type = 'Flat'
OR
AND rooms > 5 > 300
rent
En Oflice Access, una expresión compleja será total o parcialmente optimizable dependiendo de si una de las expresiones simples o las dos son optimizables y de qué operador se haya utilizado para combinarlas. Una expresión compleja será optimizable mediante Rushmore si se cumplen las siguientes tres condiciones: •
la expresión utiliza AND u OR para combinar dos condiciones;
•
ambas condiciones están formadas por expresiones optimizables simples;
•
ambas expresiones contienen campos indexados. Los campos pueden estar indexados individualmente o formar parte de un índice multicampo.
índices para DreamHome Antes de crear la lista de índices candidatos, vamos a ignorar las tablas de menor tamaño, ya que pueden procesarse usualmente en memoria sin necesidad de utilizar índices adicionales. Para DreamHome, ignoramos las tablas Branch, Telephone, Manager y Newspaper en los análisis que vamos a hacer a continuación. Basándonos en las directrices proporcionadas anteriormente: (1) Creamos la clave principal para cada tabla, lo que hará que Oflice Access indexe automáticamente correspondiente campo. (2) Nos aseguramos de crear unas relaciones en la ventana Relationships, indexe automáticamente los campos de clave externa.
el
lo que hará que Oflice Access
Como ilustración de los otros índices que podríamos crear, consideraremos las transacciones de consulta enumeradas en el Apéndice A para las vistas de usuario Staff de DreamHome. En la Tabla 17.2 se muestra un resumen de interacciones entre las tablas base y dichas transacciones. En esta figura se muestra para cada tabla: la transacción o transacciones que operan sobre la tabla, el tipo de acceso (una búsqueda basada en un
468
Sistemas
de bases de datos
Tabla 17.2.
Tabla
Transacción
Interacciones entre las tablas base y las transacciones de consulta para la vista Staff DreamHome. Frecuencia
Campo
(por día) Staff
(a), (d)
combinación: Client onstaftNo clientNoon propertyNo 20 50 5000-10.000 100 PrivateOwner/BusinessOwner Staff IName on on ownerNo 1000-2000 1000 ordenación: rentFinish position tName, IName tName, predicado: combinación: rent city supervisorStaftNo PropertyForRent
Client
PropertyForRent
Viewing Lease
predicado, una combinación junto con el campo de combinación, los campos de ordenación y los campos de agrupación) y la frecuencia con la que se ejecuta la transacción. Basándonos en esta información, decidimos crear los índices adicionales que se muestran en la Tabla 17.3. Dejamos como ejercicio para el lector la selección de los índices adicionales que habría que crear en Microsoft Office Access para las transacciones enumeradas en el Apéndice A para la vista Branch de DreamHome (véase el Ejercicio 17.5).
Organizaciones
de archivo e índice para DreamHome
con Oracle
En esta sección, vamos a repetir el ejercicio anterior de determinación de las organizaciones de archivo e índices apropiados para las vistas de usuario Staff de DreamHome. Una vez más, utilizaremos la terminología del Índices adicionales que habrá que crear en Microsft Office Access basándose en las transacciones de consulta relativas a la vista Staff de DreamHome.
Tabla 17.3.
Tabla Staff
índice tName,IName position
Client
tName,IName
PropertyF orRent
rentFinish city rent
Capítulo 17 Metodología: diseño físico de bases de datos relacionales
469
SGBD concreto que vamos a emplear; Oracle denomina tablas a las relaciones, estando estas compuestas por columnas y filas. Oracle añade automáticamente un índice por cada clave principal. Además, Oracle recomienda que no se definan explícitamente índices UNIQUE en las tablas, sino que se definan restricciones de integridad UNIQUE en las columnas deseadas. Oracle impone las restricciones de integridad UNIQUE definiendo automáticamente un índice unívoco sobre la clave unívoca. Las excepciones a esta recomendación suelen estar motivadas por razones de rendimiento. Por ejemplo, utilizar una instrucción CREA TE TABLE ...AS SELECT con una restricción UNIQUE es más lento que crear la tabla sin la restricción y luego crear manualmente un índice UNIQUE. Suponga que creamos las tablas con las claves principales, alternativas y externas identificadas. A continuación veremos si se necesita emplear clústeres y si son necesarios índices adicionales. Para mantener la simplicidad del diseño, vamos a suponer que los clústeres no son apropiados. De nuevo, si tenemos en cuenta únicamente las transacciones de consulta enumeradas en el Apéndice A para la vista Staff de DreamHome puede que se obtengan mejoras de rendimiento añadiendo los índices mostrados en la Tabla 17.4. De nuevo, dejamos como ejercicio para el lector la selección de los índices adicionales que habría que crear en Oracle para las transacciones enumeradas en el Apéndice A para la vista Branch de DreamHome (véase el Ejercicio 17.6). Tabla 17.4. índices adicionales que habrá que crear en Oracle basándose en las transacciones de consulta referidas a la vista 8taft de DreamHome. Tabla
índice
Staff
fName,IName supervisorStaffN o position
Client
staffNo fName, IName
PropertyForRent
ownerNo staffNo clientNo rentFinish city rent
Viewing
clientNo
Lease
propertyNo clientNo
Paso 4.4 Estimar los requisitos de espacio de disco Objetivo
Estimar la cantidad de espacio en disco que ocupará la base de datos.
Puede que exista el requisito de que la implementación fisica de la base de datos pueda llevarse a cabo en la configuración de hardware actual. Incluso aunque esto no sea así, el diseñador tendrá que estimar la cantidad de espacio en disco requerida para almacenar la base de datos, por si acaso surgiera la necesidad de adquirir un nuevo hardware. El objetivo de este paso es estimar cuánto espacio en disco se necesita para soportar la implementación de la base de datos en almacenamiento secundario. Al igual que en los pasos anteriores, la estimación del espacio en disco requerido depende en gran medida del SGBD seleccionado y del hardware utilizado para soportar la base de datos. En general, la estimación se basa en el tamaño de cada tupla y en el número de tuplas almacenadas en cada relación. Esta última estimación debe referirse al número máximo de
470
Sistemas de bases de datos
tuplas, aunque también puede que convenga considerar el modo en que la relación irá creciendo y modificar el tamaño de disco resultante según este factor de crecimiento para determinar el tamaño potencial de la base de datos en el futuro. En el Apéndice H (véase el sitio web del libro ) ilustramos el proceso de estimación del tamaño de las relaciones creadas en Oracle. Paso 5 Diseñar las vistas de usuario Objetivo
Diseñar las vistas de usuario identificadas sis de requisitos de la base de datos.
durante la etapa de recopilación
y análi-
El primer paso de la metodología de diseño de la base de datos presentada en el Capítulo 15 implicaba la generación de un modelo conceptual de los datos para la vista de usuario existente, o para las vistas de usuario combinadas que se hubieran identificado durante la etapa de recopilación y análisis de requisitos. En la Sección 10.4.4 hemos identificado cuatro vistas de usuario para DreamHome, denominadas Director, Manager, Supervisor y Assistant. Después de realizar un análisis de los requisitos de datos de estas vistas de usuario, utilizamos el enfoque centralizado para combinar los requisitos de las vistas de usuario de la forma siguiente: •
Branch, compuesta de las vistas de usuario Director y Manager;
•
Staff, compuesta de las vistas de usuario Supervisor y Assistant.
En el Paso 2 establecimos la correspondencia entre el modelo conceptual de los datos y un modelo lógico de los datos basado en un modelo relacional. El objetivo de este paso es diseñar las vistas de usuario identificadas anteriormente. En un SGBD para PC, las vistas de usuario suelen ser una mera comodidad, definiéndolas para simplificar las solicitudes dirigidas a la base de datos. Sin embargo, en un SGBD multiusuario, las vistas de usuario juegan un papel crucial a la hora de definir la estructura de la base de datos y a la hora de imponer los mecanismos de seguridad. En la Sección 6.4.7 hemos expuesto las principales ventajas de las vistas de usuario, como son la independencia de los datos, la reducción de la complejidad y la personalización. También hemos hablado anteriormente de cómo crear vistas utilizando el estándar ISO SQL (Sección 6.4.10) Y cómo crear vistas (consultas almacenadas) en Microsoft Office Access (Capítulo 7) y en Oracle (Sección 8.2.5).
Documentación
del diseño de las vistas de usuario
El diseño de las vistas de usuario individuales debe estar completamente documentado. Paso 6
Diseñar los mecanismos de seguridad
Objetivo
Diseñar los mecanismos de seguridad para la base de datos tal como hayan sido especificados por los usuarios durante la etapa de recopilación y análisis de requisitos de la base de datos.
La base de datos representa un recurso corporativo esencial, por lo que la seguridad de este recurso es de extremada importancia. Durante la etapa de recopilación y análisis de requisitos de la base de datos, deberán haberse documentado los requisitos específicos de seguridad, como parte de la especificación de requisitos del sistema (véase la Sección 10.4.4). El objetivo de este paso es decidir cómo implementar dichos requisitos de seguridad. Los distintos sistemas ofrecen diferentes funciones de seguridad. De nuevo, recalquemos que el diseñador de la base de datos debe conocer perfectamente las funcionalidades ofrecidas por el SGBD seleccionado. Como se explica en el Capítulo 19, los SGBD relacionales proporcionan, con carácter general, dos tipos de mecanismos de seguridad de la base de datos: •
seguridad del sistema;
•
seguridad de los datos.
La seguridad del sistema cubre el acceso y la utilización de la base de datos en el nivel del sistema, como por ejemplo la utilización de nombres de usuario y contraseñas. La seguridad de los datos cubre el acceso y
Capítulo 17 Metodología: diseño físico de bases de datos relacionales
471
la utilización de los objetos de la base de datos (como por ejemplo relaciones y vistas) y las acciones que los usuarios pueden llevar a cabo sobre dichos objetos. De nuevo, el diseño de las reglas de acceso dependerá del SGBD seleccionado; algunos sistemas proporcionan más facilidades que otros para diseñar reglas de acceso. Ya hemos explicado anteriormente tres formas concretas de crear formas de acceso utilizando las instrucciones opcionales GRANT y REVOKE del estándar ISO SQL (Sección 6.6), Microsoft Office Access (Sección 8.1.9) y Oracle (Sección 8.2.5). Hablaremos con más detalle del tema de la seguridad en el Capítulo 19.
Documentación
del diseño de las medidas de seguridad
El diseño de las medidas de seguridad debe estar completamente documentado. modelo lógico de los datos, también será preciso actualizar dicho modelo.
Si el diseño físico afecta al
Resumen del capítulo •
El diseño físico de la base de datos es el proceso de generar una descripción de la implementación de la base de datos en almacenamiento secundario. Describe las relaciones base y las estructuras de almacenamiento y métodos de acceso utilizados para acceder a los datos de manera efectiva, junto con cualesquiera restricciones de integridad y medidas de seguridad asociadas. El diseño de las relaciones base sólo puede llevarse a cabo una vez que el diseñador sea perfectamente consciente de las facilidades ofrecidas por el SGBD seleccionado.
•
El paso inicial (Paso 3) del diseño físico de la base de datos es la traducción del modelo lógico de los datos a una forma que pueda ser implementada en el SGBD relacional seleccionado.
•
El paso siguiente (Paso 4) permite diseñar las organizaciones de archivo y los métodos de acceso que se emplearán. para almacenar las relaciones base. Esto implica analizar las transacciones que se ejecutarán sobre la base de datos, seleccionar organizaciones de archivo adecuadas basándose en este análisis, seleccionar índices y, finalmente, estimar el espacio de disco que la implementación requerirá.
•
Los índices secundarios proporcionan un mecanismo para especificar una clave adicional para una relación base que pueda utilizarse para extraer los datos de manera más eficiente. Sin embargo, hay un cierto coste asociado con el mantenimiento y la utilización de índices secundarios, y será necesario equilibrar dicho coste con las mejoras de prestaciones obtenidas a la hora de extraer los datos.
•
Una técnica para seleccionar una organización de archivo apropiada para una relación consiste en mantener las tuplas desordenadas y crear tantos índices secundarios como sea necesario. Otra técnica consiste en ordenar las tuplas de la relación especificando un índice principal o de clustering. Un posible enfoque para determinar los índices secundarios necesarios consiste en generar una lista de atributos 'candidatos' a la indexación y luego examinar el impacto que tiene mantener cada uno de estos índices.
•
El objetivo del Paso 5 es diseñar cómo implementar las vistas de usuario identificadas durante la etapa de recopilación y análisis de requisitos, como por ejemplo utilizando los mecanismos proporcionados por SQL.
•
Una base de datos representa un recurso corporativo esencial, por lo que la seguridad de este recurso es extremadamente importante. El objetivo del Paso 6 es diseñar cómo pueden implementarse los mecanismos de seguridad realizados durante la etapa de recopilación y de análisis de requisitos.
Cuestiones de repaso 17.1. Explique la diferencia entre diseño conceptual, lógico y físico de la base de datos. ¿Por qué puede ser necesario que estas tareas sean llevadas a cabo por distintas personas? 17.2. Describa las entradas y salidas del proceso de diseño físico de la base de datos. 17.3. Describa el propósito de los pasos principales de la metodología de diseño físico presentada en este capítulo. 17.4. Explique por qué los índices pueden mejorar la eficiencia del sistema.
472
Sistemas de bases de datos
Ejercicios El caso de estudio de DreamHome 17.5.
En el Paso 4.3 hemos seleccionado los índices que había que crear en Microsoft Office Access para las transacciones de consulta enumeradas en el Apéndice A paras la vistas de usuario Staff de DreamHome. Seleccione los índices que habría que crear en Microsoft Office Access para las transacciones de consultas enumeradas en el Apéndice A para la vista Branch de DreamHome.
17.6.
Repita el Ejercicio 17.5 utilizando Oracle como SGBD.
17.7.
Cree un diseño físico de la base de datos para el diseño lógico de DreamHome (descrito en el Capítulo 16), basándose en el SGBD del que disponga.
17.8.
Implemente el diseño físico para DreamHome creado en el Ejercicio 17.7.
El caso de estudio 17.9.
University Accommodation Off ice
Basándose en el modelo lógico de los datos desarrollado en el Ejercicio 16.10, cree un diseño físico de la base de datos para el caso de estudio University Accommodation Office (descrito en el Apéndice B.1), basándose en el SGBD del que disponga.
17.10. Implemente la base de datos para University Accommodation en el Ejercicio 17.9.
Office utilizando el diseño físico creado
El caso de estudio EasyDrive School of Motoring 17.11. Basándose en el modelo lógico de los datos desarrollado en el Ejercicio 16.11, cree un diseño físico de la base de datos para el caso de estudio EasyDrive School of Motoring (descrito en el Apéndice B.2), basándose en el SGBD del que disponga. 17.12. Implemente la base de datos para EasyDrive School of Motoring utilizando el diseño físico creado en el Ejercicio 17.11. El caso de estudio
Wellmeadows Hospital
17.13. Basándose en el modelo lógico de los datos desarrollado en el Ejercicio 16.13, cree un diseño físico de la base de datos para el caso de estudio Wellmeadows Hospital (descrito en el Apéndice B.3), basándose en el SGBD del que disponga. 17.14. Implemente la base de datos para Wellmeadows Hospital utilizando el diseño físico creado en el Ejercicio 17.13.
aplturo
Metodología: monitorización y optimización del sistema final
Objetivos del capítulo: En este capítulo aprenderá: •
El significado de la desnormalización.
•
Cuándo desnormalizar para mejorar el rendimiento.
• •
La importancia de la monitorización y optimización del sistema final. Cómo medir la eficiencia.
•
Cómo afectan a las prestaciones los recursos del sistema.
En este capítulo describimos e ilustramos mediante una serie de ejemplos los últimos dos pasos de la metodología de diseño físico de bases de datos relacionales. Proporcionaremos directrices para determinar cuando normalizar el modelo lógico de los datos e introducir redundancia y a continuación explicaremos la importancia de monitorizar el sistema explicativo y continuar optimizándolo. En algunos casos, mostraremos detalles físicos de implementación para clarificar las explicaciones.
18.1 Desnormalización e introducción de redundancia controlada Paso 7 Considerar Objetivo
la introducción de una cantidad controlada
de redundancia
Determinar si debe introducirse redundancia de una manera controlada relajando las reglas de normalización permitirá mejorar las prestaciones del sistema.
La normalización es una técnica para decidir qué atributos deben estar situados en una misma relación. Uno de los objetivos básicos del diseño de bases de datos relacionales es el de agrupar los atributos en una relación porque existe una dependencia funcional entre los mismos. El resultado de la normalización es un diseño lógico de base de datos estructuralmente coherente y con una redundancia mínima. Sin embargo, en algunas ocasiones se argumenta que un diseño de base de datos normalizado no proporciona una eficiencia máxima de procesamiento. En consecuencia, puede haber circunstancias en las que sea necesario aceptar la pérdida de algunos de los beneficios de un diseño completamente normalizado, con el fin de mejorar las prestaciones. Esto sólo debe tomarse en consideración cuando se estime que el sistema no será capaz de satisfacer los requisitos de prestaciones. No pretendemos decir que se omita la tarea de normalización en el diseño lógico de la base de datos: el proceso de normalización nos fuerza a comprender completamente cada atributo que hay que representar en la base de datos y esto puede ser el factor más importante a la hora de garantizar el éxito del sistema. Además, es necesario tener en cuenta los siguientes factores:
474
Sistemas de bases de datos
•
la desnormalización
hace que la implementación
•
la desnormalización
sacrifica a menudo la flexibilidad;
sea más compleja;
•
la desnormalización
puede acelerar las consultas, pero ralentiza las actualizaciones.
Formalmente, el término desnormalización hace referencia a una optimización del esquema relacional que hace que el grado de normalización para una relación modificada sea inferior al grado de al menos una de las relaciones originales. También utilizamos el término de forma menos estricta para hacer referencia a aquellas situaciones en las que se combinan dos relaciones para formar una única relación y la nueva relación continua estando normalizada, pero contiene más valores nulos que las relaciones originales. Algunos autores denominan a la des normalización optimización de uso. Como regla práctica general, si las prestaciones no son satisfactorias y una relación tiene una baja tasa de actualización y una tasa de consulta muy alta, la desnormalización puede ser una técnica adecuada. La matriz cruzada transacciones/relaciones que podemos haber generado en el Paso 4.1 proporciona información de utilidad para este paso. Dicha matriz resume de forma visual los patrones de acceso de las transacciones que se ejecutarán sobre la base de datos. Puede utilizarse para detectar posibles candidatos a la desnormalización y para evaluar los efectos que esto tendrá en el resto del modelo. Más específicamente, en este paso consideramos la duplicación de ciertos atributos o la combinación de relaciones para reducir el número de combinaciones requeridas para procesar una consulta. Indirectamente, hemos encontrado un ejemplo implícito de desnormalización a la hora de tratar con los atributos de dirección. Por ejemplo, considere la definición de la relación Branch: Branch (branchNo,
street, city, postcode, mgrStaffNo)
Estrictamente hablando, esta relación no está en tercera forma normal: postcode (el código postal) determina funcionalmente el atributo city. En otras palabras, podemos determinar el valor de atributo city a partir del valor del atributo postcode. Por ejemplo, la relación Branch está en segunda forma normal (2NF). Para normalizar la relación a tercera forma normal (3NF), sería necesario dividir la relación en dos, de la forma siguiente: Branch (branchNo,
street, postcode,
mgrStaffNo)
Postcode (Dostcode, city)
Sin embargo, raramente vamos a querer acceder a la dirección de una sucursal sin extraer el atributo city. Esto significa que sería necesario realizar una combinación cada vez que quisiéramos conocer la dirección completa de una sucursal. Como resultado, nos conformamos con la segunda forma normal e implementamos la relación Branch original. Desafortunadamente, no hay reglas fljas en lo que respecta a cuándo desnormalizar relaciones. En este caso, se explican algunas de las situaciones más comunes en las que conviene considerar la desnormalización. Para obtener información adicional, el lector interesado puede consultar Rogers (1989) y Fleming y Von Halle (1989). En particular, consideraremos la desnormalización en las siguientes situaciones, específicamente para acelerar las transacciones frecuentes o críticas: •
Paso 7.1
Combinación de relaciones uno a uno (1:1)
•
Paso 7.2
Duplicación de atributos no clave en las relaciones uno a muchos (1 :*) para reducir las combinaciones
•
Paso 7.3
Duplicación de los atributos de clave externa en las relaciones uno a muchos (1 :*) para reducir las combinaciones
•
Paso 7.4
Duplicación de los atributos en las relaciones muchos a muchos (*:*) para reducir las combinaciones
•
Paso 7.5
Introducción de grupos repetitivo s
•
Paso 7.6
Creación de tablas de extracción
Capítulo 18 Metodología: monitorización y optimización del sistema final •
Paso 7.7
Particionamiento
475
de tablas
Para ilustrar estos pasos, utilizaremos el diagrama de relaciones mostrado en la Figura 18.1(a) y los datos de ejemplo de la Figura 18.1 (b). Paso 7.1 Combinación
de relaciones
uno
a uno
(1:1)
Reexamine las relaciones uno a uno (1: 1) para determinar los efectos de combinar las relaciones en una única relación. Esta combinación sólo debe considerarse para las relaciones a las que frecuentemente se haga referencia de manera conjunta y a las que se haga referencia de forma separada infrecuentemente. Considere, por ejemplo, la relación 1:1 entre Client e Interview, como se muestra en la Figura 18.1. La relación Client contiene información sobre potenciales inquilinos de un inmueble. La relación Interview contiene la fecha de la entrevista y los comentarios realizados por un empleado acerca del cliente contenido en la relación Client. Podemos combinar estas dos relaciones para formar una nueva relación Clientlnterview, como se muestra en la Figura 18.2. Puesto que la relación entre Client e Interview es 1:1 y la participación es opcional, puede haber un número significativo de valores nulos en la relación combinada Clientlnterview, dependiendo de la proporción de tuplas indicadas en la participación, como se muestra en la Figura 18.2(b). Si la relación Client original tiene un gran tamaño y la proporción de tuplas implicadas en la participación es pequeña, habrá un desperdicio significativo de espacio de almacenamiento. 0 ...1 .*Client 0 1 ..1 Branch Interview 1..1 PropertyForRent 1 ..* 1..1 ..••Attends ..••Offers POwns ~ propertyNo branchNo c1ientNo {PK} {PK} rent 'f' {FK} maxRent comment staffNo rooms ownerNo branchNo {FK} prefType O .. ' 1..1 Requests 1 ..1 Viewing
1..3 street IName Provides street telNo fName 1..1 branchNo city type postcode telNo {PK} {FK} postcode city ;. Telephone
(a)
Figura 18.1.
(a) Diagrama de relaciones de ejemplo.
476
Sistemas de bases de datos
Branch
Telephone
branchNo
telNo
163 MainRd St 22 Aberdeen Deer street NW106EU BS991NZ SW14EH AB23SU 56 32 London Bristol Manse Clover Rd Dr postcode city G119QX Glasgow 16 Argyll St
B005 B007 B003 B004 B002 branchNo
0207 -886-1300 0207-886-4100 01224-67125 0141-339-2178 0141-339-4439 0117-916-1170 0208-963-1030 0207-886-1212
PropertyForRent
400 rent C093 B003 SG37 Flat House 56 B003 C040 26street ManorRd C087 SL41 NW2 London C046 SA9 16 Aberdeen 650 Holhead 3375 B00318 B0035 G129AX G12 SG14 Novar 600 Dale Rd Dr St 3350 B0056 Lawrence 44450 ownerNo rooms branchNo staffNo B007 AB75SU Honse propertyNo G324QX G119QX Glasgow Argyll St postcode type city Glasgow
Client c1ientNo telNo Ritchie Mike Aline 425 750 House IName fName maxRent 01224-196720 600 01475-392178 0141-848-1825 0207-774-5632 Stewart 350 Flat )ohn Tregear prefType Kay Mary
Interview clientNo
SA9 SG37 7-Mar-03 staffNo comment datel nterview current lease ends in )une needs property urgently ll-Apr-03
PrivateOwner ownerNo
Farrel Carol Shaw Tina IName fName telNo 01224-861212 0141-357-7419 01410141-943-1728 225-7025 )oe 2Murphy Keogh Fergus Dr, Aberdeen AB2 7SX 6address Achray St,Glasgow Glasgow G32 9DX 63 12 Tony Park Well St, Pl, G42 G4 OQR
Viewing clientNo
PG36 PA14 PG4 toa remate room comment too small 24-May-04 noviewDate 28-Apr-04 dining 20-Apr-04 propertyNo 14-May-04 26-May-04
(b)
Figura 18.1. (b) Relaciones de ejemplo.
Capítulo 18 Metodología: monitorización y optimización del sistema final
477
Clientlnterview c1ientNo {PK} fName IName telNo prefType maxRent staffNo datelnterview comment (a) Clientlnterview c1ientNo telNo 01475-392178 Ritchie 7-Mar-03 Mike SA9 750 House Flat 0207-774-5632 AJine SG37 01224-196720 600 0141-848-1825 Stewart 425 350 IName fName staffNo maxRent comment John datelnterview current lease ends in June Tregear Mary needs property urgently Kay ll-Apr-03 prefType
(b)
Figura 18.2.
Paso 7.2 Duplicación
Combinación de las tablas Client e Interview: (a) extracto revisado del diagrama de relaciones; (b) relación combinada.
de atributos no clave en las relaciones
uno a muchos (1:*)
para reducir las combinaciones
Con el objetivo específico de reducir o eliminar las combinaciones en las consultas frecuentes o criticas, considere las ventajas que podrían obtenerse al duplicar uno o más atributos no clave de la tabla padre en la tabla hijo de una relación 1:*. Por ejemplo, siempre que se acceda a la relación PropertyForRent, resulta bastante común que se tenga que acceder también al mismo tiempo al nombre del propietario. Una consulta SQL típica sería: SELECT p.*, o.IName FROM PropertyForRent WHERE p.ownerNo =
p, PrivateOwner o.ownerNo
AND
o branchNo =
'B003';
basándose en el diagrama de relaciones original y en las relaciones de ejemplo mostradas en la Figura 18.1. Si duplicamos el atributo IName en la relación PropertyForRent, podemos eliminar la relación PrivateOwner de la consulta, con lo que en SQL nos quedaría: SELECT p.* FROM PropertyForRent p WHERE branchNo = 'B003'; basándose en la relación revisada mostrada en la Figura 18.3. Las ventajas resultantes de este cambio tienen que comparase con los problemas que pueden surgir. Por ejemplo, si se cambia el dato duplicado en la tabla padre, deberá actualizarse también en la tabla hija. Además, para una relación 1:* puede haber múltiples apariciones de cada elemento de datos en la tabla hija (por ejemplo, los nombres FaITel y Shaw aparecen dos veces en la tabla PropertyForRent revisada), en cuyo caso es necesario mantener la coherencia de las múltiples copias. Si la actualización del atributo IName en las tablas PrivateOwner y PropertyForRent no puede automatizarse, la posibilidad de pérdida de la integridad será muy alta. Un problema asociado con la duplicación es el tiempo adicional que se requiere para mantener automática-
478
Sistemas de bases de datos PropertyForRent rent 375 600 C093 C087 4450 SG14 B0035 B00318 Plat House Novar 56 Rd Dr St C040 26street ManorRd C046 4400 B0056 SL41 B007 AB75SU Parre! Aberdeen London Lawrence 650 B003 SG37 G129AX G12 Shaw Parrel Dale 33350 B003 NW2 SA9 16 Holhead ownerNo rooms staffNo branchNo IName G1l9QX G324QX propertyNo Glasgow Murphy postcode type city Keogh Argyll St
Figura 18.3.
Relación PropertyForRent revisada con un atributo IName duplicado procedente de la relación PrivateOwner.
mente la coherencia cada vez que se inserta, actualiza o borra una tupla. En nuestro caso, resulta poco probable que cambie el nombre del propietario de un inmueble, por lo que puede que convenga realizar la duplicación. Otro problema que hay que considerar es el aumento del espacio de almacenamiento resultante de la duplicación. De nuevo, siendo relativamente barato el almacenamiento secundario hoy en día, puede que no sea un problema muy importante. Sin embargo, esto no debe entenderse como una justificación para la realización de duplicaciones arbitrarias. Una caso especial de relación uno a muchos (l :*) son las tablas de búsqueda, a veces denominadas tablas de referencia o listas de selección. Normalmente, una tabla de consulta contiene un código y una descripción. Por ejemplo, podemos definir una tabla de consulta (padre) para el tipo de inmueble y modificar la tabla PropertyForRent (hija) como se muestra en la Figura 18.4. Las ventajas de utilizar una tabla de consulta son: •
la reducción en el tamaño de la tabla hija; el código de tipo ocupa 1 byte, en lugar de los 5 bytes que ocupa la descripción del tipo;
•
si la descripción puede cambiar (lo cual no es el caso en este ejemplo concreto), es más fácil cambiarla una sola vez en la tabla de consulta en lugar de cambiada muchas veces en la relación hija;
•
la tabla de consulta puede utilizarse para validar los datos introducidos por el usuario.
Si la tabla de consulta se utiliza en consultas muy frecuentes o críticas y la probabilidad de que cambie la descripción es baja, considere si merece la pena duplicar el atributo description en la tabla hija, como se muestra en la Figura 18.5. La tabla de consulta original no es redundante, ya que puede continuar siendo utilizada para validar los datos introducidos por el usuario. Sin embargo, duplicando la descripción en la tabla hija, hemos eliminado la necesidad de combinar la tabla hija con la tabla de consulta. Paso 7.3 Duplicación
de los atributos de clave externa en las relaciones
uno
a muchos
(1:*) para
reducir las combinaciones
De nuevo, con el objetivo específico de reducir o eliminar las combinaciones ticas, considere las ventajas que podrían obtenerse al duplicar uno o más de una relación. Por ejemplo, una consulta frecuente para el caso DreamHome propietarios privados de inmuebles en una sucursal, utilizando una consulta
en las consultas frecuentes o crílos atributos de clave externa en consiste en enumerar todos los SQL de la forma:
SELECT olName FROM PropertyForRent p, PrivateOwnero WHERE p.ownerNo = o.ownerNoAND branchNo = 'B003'; basada en los datos originales mostrados en la Figura 18.1. En otras palabras, puesto que no existe ninguna relación directa entre PrivateOwnery Branch, para obtener la lista de propietarios tenemos que utilizar la tabla PropertyForRent con el fin de obtener el número de sucursal, branchNo. Podemos eliminar esta combinación duplicando la clave externa branchNo en la tabla PrivateOwner;es decir, introducimos una relación directa entre las tablas Branch y PrivateOwner. En este caso, podemos simplificar la consulta SQL, obteniéndose:
Capítulo 18 Metodología: monitorización y optimización del sistema final
1..1 PropertyForRent 1..* PropertyType propertyNo {PK} TypeFor~ rent staffNo rooms ownerNo city type branchNo postcode {FK} {FK} {FK}
description type {PK}
479
street
(a) PropertyType type
Flat Honse description
F H
PropertyForRent ownerNo C040 C046 4rooms 400 350 650 SL41 SA9 Aberdeen Lawrence Holhead C093 450 375 B00318 SG14 F Novar Dr St C087 536 rent 600 SG37 H street B0056 B007 AB75SU NW2 staffNo London B003 G129AX 2616 ManorRd B0035 G12 Dale B003 Rd branchNo propertyNo G1l9QX Glasgaw Argyll St postcode G324QX type city Glasgow
(b)
Figura 18.4.
Tabla de consulta para el tipo de inmueble: (a) diagrama de relaciones; (b) relaciones de ejemplo.
PropertyForRent rent 350 C093 C040 375 B00318 C087 C046 ownerNo Honse Hanse 600 650 400 B0035 SL41 SA9 H Lawrence 450 SG14 F 452366street rooms Flat ManorRd B003 B005 B007 AB75SU G12 NW2 staffNo SG37 16 Aberdeen London Dale Holhead Rd B003 G129AX Novar Dr St propertyNo branchNo postcode G324QX G1l9QX description type city Glasgow Glasgow Argyll St
Figura 18.5. Tabla PropertyForRent
modificada con el atributo de descripción
duplicado.
SELECT o.IName FROM PrivateOwner o WHERE branchNo = 'B003'; basada en el diagrama de relaciones revisado y en la tabla PrivateOwner mostrados en la Figura 18.6. Si hacemos este cambio, será necesario introducir restricciones adicionales de clave externa, como se explica en el Paso 2.2.
480
branchNo {FK} It. 0 ..1 propertyNo ateOwner {PK}
Sistemas de bases de datos
1..*Branch PropertyForRent 1..11..* ~ Offers branchNo {PK} POwns branchNo {FK} 1 .. * ownerNo {PK}
T 1 ..1
Serves
(a) PrivateOwner ownerNo Keogh B007 01224-861212 Farrel Tina 0141-357-7419 0141-943-1728 Shaw 0141-225-7025 Carol IName address fName branchNo telNo loe Tony 12Fergus Park B003 Pl, G4 OQR 2663 Dr, AberdeenG42 AB2 7SX Murphy Achray Wen St, St,Glasgow Glasgow G32 9DX
(b)
Figura 18.6. Duplicación de la clave externa branchNo en la tabla PrivateOwner: (a) diagrama de relaciones revisado (simplificado) con branchNo incluido como clave externa; (b) tabla PrivateOwner revisada.
Si un propietario puede alquilar inmuebles a través de muchas sucursales, el cambio anterior no sería correcto. En este caso, sería necesario modelar una relación muchos a muchos (*:*) entre Branch y PrivateOwner. Observe también que la tabla PropertyForRent tiene el atributo branchNo porque es posible que un inmueble no tenga todavía asignado un empleado, particularmente durante la etapa inicial, cuando el inmueble acaba de ser tomado a su cargo por la agencia. Si la tabla PropertyForRent no tuviera el número de sucursal, sería necesario combinar la tabla PropertyForRent con la tabla Staff basándose en el atributo staffNo con el fin de obtener el número de sucursal correspondientes. La consulta SQL original sería entonces: SELECT o.IName FROM Staff s, PropertyForRent p, PrivateOwner WHERE s.staffNo = p.staffNo AND p.ownerNo
o = o.ownerNo
AND
s.branchNo
= 'B003';
La eliminación de las dos combinaciones de la consulta puede proporcionar una mayor justificación para crear una relación directa entre FrivateOwner y Branch y, por tanto, para duplicar la clave externa branchNo en la tabla PrivateOwner. Paso 7.4 Duplicación
de los atributos en las relaciones muchos
a muchos (*:*)
para reducir las combinaciones
Durante el diseño lógico de la base de datos, hemos hecho corresponder cada relación *:* a tres tablas: las dos tablas derivadas de las entidades originales y una nueva tabla que representa la relación entre las dos entidades. Ahora, si queremos obtener información a partir de la relación *:*, tenemos que combinar las tres tablas. En algunas circunstancias, puede que sea posible reducir el número de relaciones que hay que combinar duplicando atributos de una de las entidades originales en la tabla intermediaria. Por ejemplo, la relación *:* entre Client y PropertyForRent se ha descompuesto introduciendo la tabla intermediaria Viewing. Considere el requisito de que los empleados de DreamHome tengan que contactar con los clientes que todavía no hayan hecho comentarios sobre los inmuebles que han visitado. En este caso, el em-
Capítulo 18 Metodología: monitorización y optimización del sistema final pleado sólo necesita el atributo rida será:
street
481
del inmueble a la hora de hablar con los clientes. La consulta SQL reque-
SELECT p.street, c.*, v.viewDate FROM Client c, Viewing v, PropertyForRent p WHERE v.propertyNo = p.propertyNo AND c.clientNo
= v.c1ientNo
AND
comment
IS NULL;
basándose en el modelo de relaciones y en los datos de ejemplo que se muestran en la Figura 18.2."Si duplicamos el atributo street en la tabla intermediaria Viewing, podemos eliminar la tabla PropertyForRent de la consulta, obteniéndose la consulta SQL: SELECT c.*, v.street, v.viewDate FROM Client c, Viewing v WHERE c.c1ientNo = v.clientNo AND basándose en la tabla Paso
Viewing
comment 18 NULL;
revisada que se muestra en la Figura 18.7.
7.5 Introducción de grupos repetitivos
Los grupos repetitivos fueron eliminados del modelo lógico de los datos como resultado del requisito de que todas las entidades están en primera forma normal. Los grupos repetitivo s se separaron en una nueva tabla, formando una relación 1:* con la tabla original (padre). Ocasionalmente, la reintroducción de grupos repetitivos es una forma efectiva de mejorar las prestaciones del sistema. Por ejemplo, cada sucursal de DreamHome tiene un máximo de tres número telefónicos, aunque no todas las sucursales tienen necesariamente el mismo número de líneas telefónicas. En el modelo lógico de los datos, creamos una entidad Telephone con una relación tres a uno (3:1) con Branch, lo que nos daba como resultado dos relaciones, como se muestra en la Figura 18.1. Si el acceso a esta información es importante o frecuente, puede que sea más eficiente combinar las tablas y almacenar los detalles relativos a los números telefónicos en la tabla original Branch, utilizando un atributo para cada teléfono, como se muestra en la Figura 18.8. En general, este tipo de desnormalización sólo debe considerarse en las siguientes circunstancias: •
el número absoluto de elementos en el grupo repetitivo es conocido (en este ejemplo, hay un máximo de tres números telefónicos);
•
el número es estático y no cambiará a lo largo del tiempo (el número máximo de líneas telefónicas está fijo y no se espera que cambie);
•
el número no es muy grande, normalmente no superior a las primeras dos condiciones.
la, aunque esto no es tan importante como
En ocasiones puede que lo que se necesite más frecuentemente sea sólo el valor más reciente o actual dentro de un grupo repetitivo, o simplemente el hecho de que haya un grupo repetitivo. En el ejemplo anterior podemos decidir almacenar sólo un número de teléfono en la tabla Branch y dejar los números restantes en la tabla Telephone. Esto eliminaría la presencia de valores nulos en la tabla Branch, ya que cada sucursal debe tener al menos un número de teléfono. Viewing clientNo
PG4 PA14 too 26street 16dining ManorRd remote small Holhead PG36 comment Lawrence viewDate St propertyNo no 14-May-04 20-Apr-04 26-May-04 room 24-May-04 28-Apr-04
CR62
Figura 18.7.
Duplicación del atributo street de la tabla PropertyForRent
en la tabla Viewing.
482
Sistemas de bases de datos
Branch branchNo {PK} street city postcode telNo1 {AK} telNo2 telNo3 (a} Branch branchNo AB23SU 32 Bristol Manse Rd 22 163 Deer 0207-886-4100 MainRd St NW106EU BS991NZ 56 0141-339-2178 0117-916-1170 0208-963-1030 Clover 0141-339-4439 Dr SW14EH 0207-886-1212 01224-67125 Aberdeen London 0207-886-1300 telNo1 street telNo3 telNo2 G119QX 16 Argyll St Glasgow city postcode
(b)
Figura 18.8.
Paso
7.6 Creación
Tabla Branch que incorpora el grupo repetitivo: (a) diagrama de relaciones revisado; (b) tabla revisada.
de tablas de extracción
Puede haber situaciones en las que sea necesario generar informes durante los picos diarios de carga. Estos informes acceden a una serie de datos derivados y realizan combinaciones multitabla sobre un mismo conjunto de tablas base. Sin embargo, los datos en los que el informe se basa pueden ser relativamente estáticos o, en algunos casos, no tienen por qué estar actualizados (es decir, si los datos tienen unas pocas horas de antiguedad, el informe continuaría siendo perfectamente aceptable). En este caso, puede que sea posible crear una única tabla de extracción altamente desnormalizada basándose en las tablas requeridas por los informes, y permitir que los usuarios accedan a la tabla de extracción directamente, en lugar de acceder a las tablas base. La técnica más común para generar tablas de extracción consiste en crear y rellenar las tablas mediante una ejecución por bloques durante la noche, cuando el sistema está sometido a una baja carga. Paso 7. 7 Particionamiento
de tablas
En lugar de combinar las tablas, una técnica alternativa que resuelve el problema fundamental de soportar las tablas (e índices) de muy gran tamaño consiste en descomponerlas en una serie de piezas más pequeñas y manejables denominada particiones. Como se ilustra en la Figura 18.9, hay dos tipos principales de particionamiento: particionamiento horizontal y particionamiento vertical. Particionamiento horizontal
Distribución de las tuplas de una tabla entre una serie de tablas (más pequeñas).
Particionamiento vertical
Distribución de los atributos de una tabla entre una serie de tablas más pequeñas (la clave principal se duplica para poder reconstruir la tabla original).
Las particiones son particularmente útiles en aquellas aplicaciones donde se almacenan y analizan grancon varios des cantidades de datos. Por ejemplo, DreamHome mantiene un la tabla ArchivedPropertyForRent cientos de miles de tuplas, que se conservan indefinidamente para propósitos de análisis. La búsqueda de una tupla concreta de una cierta sucursal podría requerir mucho tiempo; sin embargo, podríamos reducir dicho tiempo realizando un particionamiento horizontal de la tabla, empleando una partición para cada sucursal.
Capítulo 18 Metodología: monitorización y optimización del sistema final
483
Horizontal
Vertical
Figura 18.9.
Particionamiento
horizontal y vertical.
Podemos crear una partición (hash) para estos escenarios de Oracle utilizando la instrucción SQL que se muestra en la Figura 18.10. Además del particionamiento hash, otros tipos comunes de particionamiento son el particionamiento por rango (cada partición se define mediante un rango de valores relativos a uno o más atributos) y el particionamiento por lista (cada partición se define mediante una lista de valores correspondientes a un atributo). También existen particiones compuestas como por ejemplo rango-hash y lista-hash (cada partición se define mediante un rango o una lista de valores y luego cada partición se vuelve a subdividir basándose en una función de hash). Puede haber también circunstancias en las que examinemos frecuentemente atributos concretos de una tabla muy grande y en esos casos puede resultar adecuado particionar verticalmente la tabla almacenando por un lado aquellos atributos a los que se accede frecuente y por otro los restantes atributos (duplicando la clave principal en cada partición para permitir reconstruir la tabla original mediante una combinación).
CREATE TABLE ArchivedPropertyF orRentPartition( propertyNo VARHAR2(5) NOT NULL, street VARCHAR2(25) NOT NULL, city VARCHAR2(15) NOT NULL, postcode VARCHAR2(8), type CHAR NOT NULL, rooms SMALLINT NOT NULL, rent NUMBER(6, 2) NOT NULL, ownerNo VARCHAR2(5) NOT NULL, staffNo VARCHAR2(5), branchNo CHAR( 4) NOT NULL, PRIMARY KEY (propertyNo), FOREIGN KEY (ownerNo) REFERENCES PrivateOwner(ownerNo), FOREIGN KEY (staffNo) REFERENCES Staff(staffNo), FOREIGN KEY (branchNo) REFERENCES Branch(branchNo)) PARTlTlON BY HASH (branchNo) (PARTlTlON b1 TABLESPACE TB01, PARTlTlON b2 TABLESPACE TB02, PARTlTlON b3 TABLESPACE TB03, PARTITION b4 TABLESPACE TB04); Figura
18.10.
Instrucción SQL Oracle para crear una partición hash.
484
Sistemas de bases de datos
El particionamiento
tiene una serie de ventajas:
•
Un mejor equilibrio de carga. A las particiones se les pueden asignar diferentes áreas de almacenamiento secundario, lo que permite el acceso paralelo al mismo tiempo que minimiza la contienda para el acceso a un mismo área de almacenamiento, contienda que se produciría si la tabla no estuviera particionada.
•
Mejores prestaciones. Limitando la cantidad de datos que hay que examinar o procesar y haciendo posible la ejecución paralela, pueden mejorarse las prestaciones.
•
Mayor disponibilidad. Si se asignan las particiones a diferentes áreas de almacenamiento y una de éstas deja de estar disponible, las otras particiones continúan estando accesibles.
•
Mejores posibilidades de recuperación. Las particiones más pequeñas pueden recuperarse más eficientemente (asimismo, puede ser más fácil para el DBA hacer copias de seguridad de las particiones más pequeñas, en lugar de hacer directamente la copia de seguridad de una serie de tablas muy grandes).
•
Seguridad. Los datos de una partición pueden restringirse a aquellos usuarios que necesiten acceder a los mismos, teniendo las diferentes particiones distintas restricciones de acceso.
El particionamiento
puede tener también una serie de desventajas:
•
Complejidad. El particionamiento no suele ser transparente para los usuarios finales y las consultas que utilizan más de una partición pueden resultar complejas de escribir.
•
Reducción de las prestaciones. Las consultas que combinen datos de más de una partición pueden ser más lentas que si se utiliza un técnica no particionada.
•
Duplicación. El particionamiento vertical implica duplicar la clave principal. Esto no sólo conduce a una mayor necesidad de espacio de almacenamiento, sino también a la posible aparición de incoherencias.
Consideración
de las implicaciones
de la desnormalización
Considere las implicaciones que la desnormalización tiene sobre los pasos anteriores de la metodología. Por ejemplo, puede que sea necesario reconsiderar la elección de índices en aquellas tablas que hayan sido desnormalizadas, con el fin de determinar si algunos de los índices existentes debe eliminarse o si deben añadirse índices adicionales. Además, será necesario considerar cómo puede mantenerse la integridad de los datos. Las soluciones comunes son: •
Disparadores. Pueden utilizarse disparadores para automatizar la actualización de los datos derivados o duplicados.
•
Transacciones. Incluya transacciones en cada aplicación que realicen las actualizaciones desnormalizados como una única acción (atómica).
de los datos
•
Reconciliación mediante procesamiento por lotes. Ejecute programas de procesamiento períodos apropiados para asegurar la coherencia de los datos desnormalizados.
por lotes en
Tabla 18.1.
Ventajas y desventajas
Ventajas
Desventajas
Pueden mejorar las prestaciones: •
precalculando
los datos derivados;
•
minimizando la necesidad de efectuar combinaciones;
•
reduciendo el número de claves externas en las tablas;
•
reduciendo el número de índices (y ahorrando así espacio de almacenamiento); reduciendo el número de tablas.
•
de la desnormalización.
Puede acelerar las consultas pero ralentizar las actualizacIOnes. Siempre es específica de la aplicación y tiene que volverse a evaluar si la aplicación cambia. Puede incrementar el tamaño de las tablas. Puede simplificar la implementación en algunos casos pero puede hacerla más compleja en otros. Se pierde flexibilidad.
Capítulo 18 Metodología: monitorización y optimización del sistema final
485
En términos de mantenimiento de la integridad, los disparadores proporcionan la mejor solución, aunque pueden provocar problemas de rendimiento. En la Tabla 18.1 se resumen las ventajas y desventajas de la desnormalización.
Documentación
de la introducción
de redundancia
La introducción de redundancia debe documentarse de modo completo, junto con las razones para introducirla. En particular, es preciso documentar las razones para seleccionar una técnica concreta cuando haya diversas alternativas. Actualiza el modelo lógico de los datos para reflejar los cambios realizados como resultado de la desnormalización.
18.2 Monitorización del sistema para mejorar el rendimiento Paso 8
Monitorización y optimización el sistema final
Objetivo
Monitorizar el sistema final y mejorar las prestaciones del sistema con el fin de corregir las decisiones de diseño inapropiadas o reflejar cambios sufridos por los requisitos.
Para esta tarea debemos recordar que uno de los objetivos principales del diseño físico de la base de datos consiste en almacenar y acceder a los datos de una manera eficiente (véase el Apéndice C). Hay una serie de factores que podemos utilizar para medir la eficiencia: •
Tasa de procesamiento de transacciones. Es el número de transacciones que pueden procesarse en un intervalo de tiempo determinado. En algunos sistemas, como los de reservas de billetes de avión, la alta tasa de procesamiento de transacciones es crítica para el éxito global del sistema.
•
Tiempo de respuesta. Es el tiempo que transcurre para completar el procesamiento de una única transacción. Desde el punto de vista del usuario, es deseable minimizar el tiempo de respuesta lo más posible. Sin embargo, hay ciertos factores que influencian el tiempo de respuesta y sobre los que el diseñador puede no tener ningún control, por ejemplo la carga que tenga el sistema o los tiempos de comunicación. El tiempo de respuesta puede acortarse: • • •
•
reduciendo los tiempos de espera y la contienda, particularmente disco; reduciendo el tiempo durante el que se necesitan los recursos; utilizando componentes más rápidos.
los tiempos de espera para E/S en
Almacenamiento en disco. Es la cantidad de espacio en disco requerida para almacenar los archivos de base de datos. El diseñador puede tratar de minimizar la cantidad de espacio en disco utilizada.
Sin embargo, no hay un único factor que sea siempre el más aplicable. Normalmente, el diseñador tendrá que establecer compromisos entre los distintos factores con el fin de conseguir un adecuado equilibrio. Por ejemplo, si se incrementa la cantidad de datos almacenados, puede reducirse el tiempo de respuesta o incrementarse la tasa de procesamiento de transacciones. El diseño físico inicial de la base de datos no debe considerarse como algo estático, sino como una mera estimación del modo en que puede llegar a funcionar el sistema final. Una vez implementado el diseño inicial, será necesario monitorizar el sistema y optimizarlo como resultado de las medidas de rendimiento realizadas y de los cambios que los requisitos sufran (véase el Paso 8). Muchos SGBD proporcionan al DBA una serie de utilidades para monitorizar la operación del sistema y optimizar éste. Son diversos los beneficios que pueden obtenerse optimizando la base de datos: •
La optimización puede evitar tener que comprar hardware adicional.
•
Puede que sea posible reducir la configuración hardware. Esto hace que se ahorre dinero en hardware y, consecuentemente, que el mantenimiento sea también más barato.
486
Sistemas de bases de datos
•
Un sistema bien optimizado proporciona tiempos de respuesta más rápidos y una mayor tasa de procesamiento, lo que a su vez hace que los usuarios, y por tanto la organización, sean más productivos.
•
Los tiempos de respuesta mejorados pueden hacer que aumente la satisfacción de los usuarios.
•
Los tiempos de respuesta mejorados pueden hacer que aumente la satisfacción de los clientes.
Estos dos últimos beneficios son más intangibles que los otros. Sin embargo, podemos estar seguros de que los tiempos de respuesta lentos desmoralizan a los empleados y pueden hacer que se pierdan clientes. Para optimizar un sistema ya operativo, el diseñador fisico de la base de datos debe ser consciente del modo en que interactúan los diversos componentes hardware y la manera en que cada uno afecta al rendimiento de la base de datos, como a continuación se explica.
Los recursos del sistema Memoria
principal
Los accesos a la memoria principal son significativamente más rápidos que los accesos al almacenamiento secundario, en ocasiones decenas o incluso cientos de miles de veces más rápido. En general, cuanta más memoria principal se ponga a disposición del SGBD y de las aplicaciones de base de datos, más rápidamente se ejecutarán éstas. En cualquier caso, resulta conveniente tener disponible al menos un mínimo de un 5% de memoria principal. También podemos decir que resulta aconsejable no tener disponible más de un 10%, ya que en caso contrario no estaremos usando la memoria principal de forma óptima. Cuando no haya suficiente memoria como para acomodar todos los procesos, el sistema operativo transferirá páginas de los procesos a disco con el fin de liberar memoria. Cuando después se vuelva a requerir una de estas páginas, el sistema operativo tendrá que volverla a transferir a memoria desde el disco. Algunas veces, es necesario intercambiar procesos completos desde memoria a disco y a la inversa, con el fin de liberar memoria. Cuando la transferencia de páginas o el intercambio de procesos resultan excesivos, pueden presentarse problemas con la memoria principal. Para garantizar un uso eficiente de la memoria principal, es preciso comprender el modo en que el SGBD elegido utiliza dicha memoria principal, qué búferes mantiene en memoria principal, qué parámetros existen para ajustar el tamaño de esos búferes, etc. Por ejemplo, Oracle mantiene una caché del diccionario de datos en memoria principal que, idealmente, debería ser lo suficientemente grande como para poder gestionar el 90% de los accesos al diccionario de datos sin tener que extraer información del disco. También es necesario comprender los patrones de acceso de los usuarios: un incremento del número de usuarios concurrentes que accedan a la base de datos dará como resultado un incremento en la cantidad de memoria utilizada. Procesador El procesador controla las tareas de los otros recursos del sistema y ejecuta los procesos del usuario, y es el recurso más costoso del sistema, así que es preciso utilizarlo correctamente. El principal objetivo en lo que respecta a este componente es impedir la contienda de procesador, que es aquella situación en la que hay una serie de procesos esperando a que se les asigne tiempo de procesador. Cuando el sistema operativo o los procesos de usuario impongan una carga excesiva al procesador, pueden aparecer cuellos de botella. Esto se produce a menudo como resultado de un intercambio excesivo de páginas entre memoria principal y disco. Resulta imprescindible comprender cuál es el patrón típico de carga de trabajo en un período de 24 horas y garantizar que haya recursos suficientes disponibles no sólo para la carga de trabajo normal sino también para los picos de carga (por ejemplo, si el sistema tiene un 90% de utilización de procesador y un 10% de tiempo muerto durante la carga normal de trabajo, puede que no haya suficientes recursos como para poder gestionar los picos de carga). Una opción consiste en garantizar que no se ejecute ninguna tarea no imprescindible durante los picos de carga, difiriéndose tales tareas para las horas en que hay una menor carga de trabajo. Otra opción es utilizar múltiples procesadores en paralelo, lo que permite que el procesamiento sea distribuido y que se realicen en paralelo las distintas operaciones. Puede utilizarse el número de millones de instrucciones por segundo (MIPS) del procesado como guía para comparar las distintas plataformas y determinar su capacidad de satisfacer los requisitos de la organización en lo que respecta a la tasa de procesamiento.
Capítulo 18 Metodología: monitorización y optimización del sistema final
487
E/S de disco En cualquier SGBD complejo, se necesita una cantidad significativa de operaciones de E/S de disco para almacenar y extraer los datos. Los discos suelen tener una tasa de E/S recomendada que, cuando se excede, puede hacer que aparezcan cuellos de botella de E/S. Aunque las velocidades de reloj de los procesadores se han incrementado enormemente en los últimos años, la velocidad de E/S no ha aumentado de forma proporcional. La forma en que se organizan los datos en el disco puede tener un impacto significativo sobre el rendimiento de disco global. Uno de los problemas que puede surgir es la contienda de disco. Este fenómeno se produce cuando múltiples procesos tratan de acceder al mismo disco simultáneamente. La mayoría de los discos tienen una serie de límites tanto en el número de accesos como en la cantidad de datos que pueden transferirse por segundo y si se alcanzan estos límites, los procesos pueden tener que esperar para acceder al disco. Para evitar esto, se recomienda que se distribuyan los datos de forma equitativa entre los discos disponibles, para reducir la probabilidad de que se produzcan problemas de rendimiento. La Figura 18.11 ilustra los principios básicos de distribución de los datos entre los discos: •
los archivos del sistema operativo deben estar separados de los de la base de datos;
•
los archivos principales de la base de datos deben estar separados de los archivos de índice;
•
el archivo del registro de recuperación (véase la Sección 20.3.3) debe estar separado del resto de la base de datos.
Si un disco sigue estando sobrecargado, uno o más de los archivos a los que se acceda más frecuentemente pueden desplazarse a un disco menos activo (esta técnica se conoce con el nombre de distribución de E/S). Puede conseguirse un adecuado equilibrado de carga aplicando este principio a cada uno de los discos hasta que todos ellos tengan aproximadamente el mismo número de operaciones de E/S. Una vez más, recalquemos que el diseñador físico de la base de datos necesita comprender a la perfección el modo en que el SGBD opera, las características del hardware y los patrones de acceso de los usuarios. El panorama de la E/S de disco se ha visto revolucionado por la introducción de la tecnología RAID (Redundant Array of Independent Disks, matriz redundante de discos independientes). RAID se basa en disponer de una gran matriz de discos compuesta por una serie de múltiples discos independientes que están organizados de una forma concreta con el fin de mejorar las prestaciones y aumentar al mismo tiempo la fiabilidad. Hablaremos de la tecnología RAID en la Sección 19.2.6. Red Cuando la cantidad de tráfico en la red es excesiva o cuando el número de contiendas de red es grande, pueden producirse cuellos de botella. Cada uno de los recursos anteriores puede afectar a otros recursos del sistema. Asimismo, una mejora de uno de los recursos puede permitir conseguir mejoras correspondientes en otros recursos del sistema. Por ejemplo: •
si se añade más memoria principal, se reducen las operaciones de intercambio de páginas entre memoria y disco, lo que a su vez ayuda a evitar cuellos de botella relacionados con el uso del procesador;
•
un uso más efectivo de la memoria principal puede dar como resultado un menor número de operaciones de E/S de disco.
o
Sistema operativo
O Archivos principales de la base de datos
o o Archivos de índice
Archivos del registro de recuperación
Figura 18.11. Configuración de discos típica.
488
Sistemas de bases de datos
Resumen La optimización es una actividad que nunca se completa. Durante toda la vida del sistema, será necesario monitorizar las prestaciones, particularmente para tener en cuenta los cambios en el entorno y en los requisitos del usuario. Sin embargo, cuando se efectúa un cambio en un área de un sistema para mejorar las prestaciones, puede que ese cambio afecte adversamente a otra área distinta. Por ejemplo, añadir un índice a una tabla puede mejorar la velocidad de una transacción, pero quizá afecte de manera adversa a otra transacción que a lo mejor es más importante. Por tanto, debe tenerse cuidado a la hora de hacerse cambios en un sistema que ya está en funcionamiento. Siempre que sea posible, compruebe los cambios en una base de datos de prueba o, alternativamente, en aquellos instantes en los que el sistema no esté siendo utilizado a pleno rendimiento (como por ejemplo, fuera de las horas de trabajo).
Documentación
de la actividad de optimización
Los mecanismos utilizados para optimizar el sistema deben estar perfectamente documentados, junto con las razones para optimizarlo de la manera elegida. En particular, es necesario documentar las razones por las que se ha seleccionado una técnica concreta cuando existan diversas alternativas.
Definición
de nuevos requisitos en DreamHome
Además de optimizar el sistema para mantener una prestaciones óptimas, también puede que sea necesario gestionar los cambios sufridos por los requisitos. Por ejemplo, suponga que después de unos meses de operación de la base de datos, varios usuarios del sistema de DreamHome sugieren dos nuevos requisitos: (1) La capacidad de almacenar fotografias de los inmuebles en alquiler, junto con comentarios que describan las principales características del ínmueble. En Microsoft Office Access podemos satisfacer este requisito utilizando campos OLE (Object Linking and Embedding), que se utilizan para almacenar datos tales como documentos Microsoft Word o Microsoft Excel, imágenes, sonidos y otros tipos de datos primarios creados en otros programas. Los objetos OLE pueden ser vinculados a un campo o incrustados en él dentro de una tabla Microsoft Office Access y luego visualizarse en un formulario o informe. 11':'1111
PropertyNo Street City PC$tcode T:ype
AOOm~ Aent
Newly decorated throughout. \Vell equipped
kitchen. Close to local amenities.
Rli!cord:
Figura 18.12. Formulario basado en la tabla PropertyForRent nuevos campos de imagen y de comentario.
con los
Capítulo 18 Metodología: monitorización y optimización del sistema final Para implementar este nuevo requisito, reestructuraremos
la tabla
PropertyForRent
489
con el fin de incluir:
(a) un campo denominado picture especificado como de tipo de datos OLE; este campo almacenará imágenes de los inmuebles, creadas escaneando fotografias de los inmueble s en alquiler y guardando las imágenes como archivos gráficos BMP (Bit Mapped); (b) un campo llamado comments especificado como de tipo de datos Memo, capaz de almacenar textos de gran longitud. En la Figura
18.12 se muestra un formulario basado en algunos de los campos de la tabla incluyendo los campos recién definidos. El problema principal asociado con el almacenamiento de imágenes es la gran cantidad de espacio de disco que se requiere para almacenadas. Por tanto, sería necesario continuar monitorizando las prestaciones de la base de datos de DreamHome para garantizar que la satisfacción de este nuevo requisito no comprometa las prestaciones del sistema. PropertyForRent,
(2) La capacidad de publicar en la Web un informe que describa los inmuebles disponibles para alquiler. Este requisito puede satisfacer tanto en Microsoft Office Access como en Oracle, ya que ambos SGBD proporcionan muchas funciones para desarrollar una aplicación web y publicar información a través de Internet. Sin embargo, para utilizar estas funciones, necesitamos un explorador web tal como Microsoft Internet Explorer o Netscape Navigator y un módem u otro tipo de conexión de red con el fin de acceder a Internet. En el Capítulo 29 se describen en detalle las tecnologías usadas para la integración de las bases de datos y la Web.
Resumen del capítulo •
Formalmente, el término desnormalización hace referencia a una utilización del esquema relacional tal que el grado de normalización para una tabla modificada es inferior al grado de al menos una de las tablas originales. El término también se utiliza de manera menos precisa para hacer referencia a aquellas situaciones en las que dos tablas se combinan para formar una nueva tabla y la nueva tabla sigue estando normalizada pero contiene más valores nulos que las tablas originales. • El Paso 7 del proceso de diseño fisico de la base de datos considera la utilización de técnicas de desnormalización del esquema relacional para mejorar las prestaciones. Todas las circunstancias en las que sea necesario aceptar la pérdida de algunas de las ventajas de un diseño completamente normalizado, con el fin de mejorar el rendimiento. Estas técnicas sólo deben tomarse en consideración cuando se estime que el sistema no será capaz de cumplir los requisitos de prestaciones. Como regla práctica, si el rendimiento no es satisfactorio y una tabla tiene la baja tasa de actualización y una tasa de consulta muy alta, la desnormalización puede ser una técnica adecuada. •
El paso final (Paso 8) del diseño fisico de una base de datos es el proceso continuo de monitorización optimización del sistema final con el fin de obtener unas prestaciones máximas.
y
•
Uno de los objetivos principales del diseño fisico de una base de datos es el de almacenar y acceder a los datos de una manera eficiente. Hay una serie de factores que pueden utilizarse para medir la eficiencia, incluyendo la tasa de procesamiento, el tiempo de respuesta y el espacio de almacenamiento en disco.
•
Para mejorar las prestaciones, es necesario ser consciente de cómo interactúan entre sí y de cómo afectan al rendimiento del sistema los siguientes cuatro componentes básicos del hardware: memoria principal, procesador, E/S de disco y red.
Cuestiones de repaso 18.1. Describa el propósito de los pasos principales de la metodología de diseño fisico presentada en este capítulo. 18.2. ¿En qué circunstancias conviene desnormalizar un modelo lógico de datos? Utilice ejemplos para ilustrar su respuesta. 18.3. ¿Qué factores pueden usarse para medir la eficiencia?
490
Sistemas de bases de datos
18.4.
Explique cómo interactúan entre sí y cómo afectan a las prestaciones del sistema los cuatro componentes básicos del hardware.
18.5.
¿Cómo distribuiría los datos entre una serie de discos?
Ejercicio 18.6.
Averigue si su SGBD permite satisfacer los dos nuevos requlSltos para el caso de estudio de DreamHome dados en el Paso 8 de este capítulo. Si es posible, realice un diseño que satisfaga a los dos requisitos e impleméntelo en el SGBD que tenga a su disposición.
Problemas fu ndamentales en las bases de datos
lo
19 Seguridad
lo 2O Gestión de transacciones lo
21
Procesamiento de consultas
Capítulo
Segur¡dad
-:,etivos del capítulo: -:. este capítulo aprenderá:
I I I I I I
EI alcance de los mecanisrnos de seguridad en una base de datos. Por quré la seguridad de una base de datos constituye una preocupación esencial para cualquier organización. Los tipos de amenazas que pueden af-ectar a un sistema de bases de datos. Cómo proteger un sistema infonnático utilizando sistemas de control automatizados. Las medidas de seguridad proporcionadas por los SGBD Microsoft Office Access y Oracle. Las técnicas para dotar de seguridad a un SGBD en la Web.
:llos constituyen un valioso recurso que debe ser estrictamente controlado y gestionado, al igual que - -- --ier otro recurso corporativo. Una parte de los datos corporativos, o todos ellos, pueden tener una impor- : estratégica para la organización y debe, por tanto, garantizarse su seguridad y confidencialidad. -
- el Capítulo 2 hemos analizado el entorno de las bases de datos y en particular las funciones y servicios . de un sistema de gestión de bases de datos (SGBD). Estas funciones y servicios incluyen servicios de
..zación, como por ejernplo que el SGBD debe proporcionar un mecanismo para verificar que sólo los -r.t)S autorizados accedan a la base de datos. En otras palabras, el SGBD debe garanfizar que la base de - : Sea segura. El ténnino seguridad hace referencia a la protección de la base de datos frente a accesos no :.zados, ya sean intencionados o accidentales. Además de los servicios proporcionados por el SGBD, el ::s de la seguridad de una base de datos puede incluir también cuestiones rnás amplias asociadas con la - ,, de dotar de seguridad a la base de datos y a su entorno. Sin embargo, estas cuestiones están fuera del -...-e de este libro, por lo que el lector interesado puede consultar Pfleeger (1997).
Estructura del capítulo , Sección l9.l hablaremos del alcance de los mecanismos de seguridad de la base de datos y examinare- .os tipos de amenazas que pueden afectar a los sistemas informáticos en general. En la Sección 19.2 vere, qué tipos de controles informatizados hay disponibles colno contramedidas a estas amenazas. En las : - ::ones I 9.3 y 19.4 se describen las rnedidas de seguridad proporcionadas por los SGBD Microsoft Office . -:ss 2003 y Oracle9i. En la Sección 19.5 se identifican las medidas de seguridad asociadas con los SGBD - \\ieb. Los ejemplos utilizados a lo largo del capítulo están extraídos del caso de estudio de DreamHome .-rito en la Sección 10.4 y en el Apéndice A.
494
Sistemas de bases de datos
19.1 Seguridad de la base de datos En esta sección se describe el alcance de las rnedidas de seguridad de una base de datos y se explica por qu. las organización deben abordar seriamente el problema de las potenciales amenazas a sus sistemas informát.cos. También se identifican los tipos de amenazas y las consecuencias que tienen en los sistemas.
Seguridad de la base de datos
Los mecanismos que protegen a la base de datos frente a amenazas intencionadas o accidentales.
Las consideraciones de seguridad no se aplican únicamente a los datos almacenados en la base de dat.-= los problemas de seguridad pueden afectar a otras partes del sistema, lo cual puede a su vez afectar a la prrpia base de datos. En consecuencia, el tema de la seguridad de una base de datos abarca tanto el hardware. . software, las personas y los datos. Para implementar de manera ef'ectiva una serie de rnedidas de seguridad -. requiere disponer de los controles apropiados, que se definirán de acuerdo con los objetivos específicos ,j. sistema. Esta necesidad de seguridad, aunque a veces no se le ha prestado la suficiente atención en el pasa,j,es cada vez mejor comprendida por las organizaciones. La razó¡ para este cambio de mentalidad es la can: dad creciente de datos corporativos fundamentales que se almacenan en los sistemas infbrmáticos y el rec.nocimiento de que cualquier pérdida o falta de disponibilidad de estos datos puede llegar a ser desastrosa. Una base de datos representa un recurso corporativo esencial al que debe dotarse de la seguridad aprop:'da utilizando los adecuados controles. Vamos a considerar el tema de la seguridad de las bases de datos = relación con las siguientes situaciones:
I I t I I
robo y fraude; pérdida de cont-rdencialidad; pérdida de privacidad; pérdida de integridad; pérdida de disponibilidad.
Estas situaciones representan de un modo arnplio una serie de áreas en las que las organizaciones debrtratar de reducir el riesgo, es decir, la posibilidad de que se produzcan pérdidas o daños. En algunas situac. nes, estas áreas están estrechamente relacionadas, de modo que una actividad que conduzca a una pérdida =: una de las áreas puede también conducir a pérdidas en otras. Además, los sucesos tales como el fraude .. pérdida de privacidad pueden producirse debido a actos tanto intencionados como no intencionados, r :, necesariamente tienen como resultado la realización de cambios detectables en la base de datos o en el sis:. ma informático. El robo y el fraude no sólo abarcan el entorno de la base de datos, sino a toda la orgarización. Puesto i; son personas las que perpetran tales delitos, la atención debe centrarse en reducir las oportunidades de c -. este tipo de actividades se produzcan. El robo y el fraude no necesariamente implican que se alteren los da:.', igual que sucede con otras actividades que tienen como resultado la pérdida de confidencialidad o la pérd-de privacidad. La confidencialidad hace refbrencia a la necesidad de mantener en secreto ciertos datos, usualmente .. aquellos que son críticos para la organización, mientras que la privacidad hace referencia a la necesida,i ; proteger los datos acerca de las personas. Las rupturas de seguridad que tienen como resultado una pérdid' confidencialidad podrían, por ejemplo, conducir a una pérdida de competitividad de la organización mien:qr.re la pérdida de privacidad podría implicar que alguien iniciara acciones legales contra la organización .-= no ha sabido custodiar sus datos. La pérdida de la integridad de los datos provoca la aparición de datos inválidos o comompidos, lo cpuede afectar seriarnente a la operación de la organización. Muchas organizaciones tratan ahora de mante:.,: una operación prácticamente continua, lo que se conoce corno disponibilidad 2417 (es decir, 24 horas al ¿7 días a la semana). Una pérdida de disponibilidad implica que los datos, o el sistema, o arnbos, dejen de e=-accesibles, lo que puede afectar seriamente a los resultados financieros de la organización. En algunos ca*-.' los mismos sucesos que hacen que un sistema deje de estar disponible provocan tarnbién una corrupción -' los datos.
Capítulo 19 Seguridad 495 -as técnicas de seguridad de la base de datos tratan de minimizar las pérdidas causadas por los eventos -:'. -sros de la forma más barata posible y sin restringir innecesariamente la actividad de los usuarios. En los - -:ros tiempos, el número de delitos informáticos se ha incrementado significativamente y las previsiones . : Jue continúen incrementándose a lo largo de los próximos años.
t 9.1
.1
Amenazas
Amenaza
Cualquier situación o suceso, intencionado o accidental, que pueda afectar adversamente a un sistema y, consecuentemente, a la organización.
-j
3menaza puede estar causada por una situación o suceso que involucre a una persona, acción o circunsa producir daño a la organización. Dicho daño puede ser tangible, como por ejemplo -; perdida de hardware, software o datos, o intangible, como por ejemplo la pérdida de credibilidad o de la -i.anzade los clientes. El problema con el que se encuentra cualquier organización es el de identificar todas - ¡rsibles amenazas. Por tanto, como mínimo, las organizaciones deben invertir el tiempo y esfuerzo necepara identificar las amenazas más serias. --.-rj :n la sección anterior hemos identificado una serie de áreas de pérdida de potencial que pueden ser resul-
-..a que pueda llegar
de actividades intencionadas o no intencionadas. Aunque algunos tipos de amenazas pueden ser tanto amenazas intencionadas son :elacionadas con personas y pueden ser perpetradas tanto por usuarios autorizados como por no autoriza-*:. algunos de los cuales pueden ser externos a la organización. loda amenaza debe verse como una ruptura potencial de seguridad que, si tiene éxito, tendrá un cierto ::¿üto. La Tabla 19.1 presenta una serie de ejemplos de varios tipos de amenazas, indicando el área en la -; pueden tener impacto. Por ejemplo, 'la visualización y divulgación de datos no autorizados'como ame'-: puede tener como resultado el fraude, el robo, la pérdida de confidencialidad y la pérdida de privacidad :.: : ot$?fiizaCíón. rl grado en que una organización sufra como resultado de la materialización de una amenaza dependerá l4 serie de factores, como por ejemplo de la existencia de contramedidas y de planes de contingencia. Por = : ::rplo, si se produce un fallo del hardware que corrompe el almacenamiento secundario, toda la actividad ; rrocesomiento deberá cesar hasta que el problema se resuelva. El grado de recuperación dependerá de una *-.: de factores, entre los que se incluyen cuándo fueron realizadas las últimas copias de seguridad y el tiem-. :recesario para restaurar el sisterna. Una organizaciónnecesita identificar los tipos de amenaza a los que tiene que hacer frente y poner en mar-
-:,-
: .:cionadas como no intencionadas, el impacto continúa siendo el mismo. Las
los planes apropiados y contramedidas, teniendo siempre presente el coste por implementarlos. : , iamente, puede que no tenga sentido desde el punto de vista económico invertir un tiempo, un esfuerzo y jrnero considerables en afrontar amenazas potenciales que sólo pueden tener como resultado una incomo-: -,d de carácter menor. El tipo de negocio al que se dedique la organización puede también tener influencia .
r:
. ,::e los tipos de amenaza que hay que considerar, algunos de los cuales pueden ser excesivamente raros. De .:Lrs modos, esos sucesos raros también deben tenerse en cuenta, particularmente si su impacto puede ser sig'.-:--ativo. En la Figura l9.l se presenta un resumen de las potenciales amenazas a las que se enfrentan los : .3rrraS informáticos.
19.2 Gontramedidas: controles informatizados - -. tipos de contramedidas que pueden aplicarse a las amenazas a las que se enfrentan los sistemas informá. - -rs van desde controles fisicos hasta procedimientos administrativos. A pesar del amplio rango de controles *:¡rmatizados disponibles, es necesario tener en cuenta que, generalmente, la seguridad de un SGBD depen¡ :n buena medida del sistema operativo, debido a lo estrechamente que están asociados. En la Figura 19.2 i :epresenta un entorno informático multiusuario típico. En esta sección nos vamos a centrar en los siguien:: controles de seguridad informatizados para un entorno multiusuario (algunos de esos controles pueden no =,:.r disponibles en un entorno para PC):
496 Sistemas de bases de datos I I I I
aul.orización
controles de acceso 'n,istas
copias de seguridacl y recLrperación
Tabla 19.1. Ejemplos de amenazas. Robo y fraude
Amenaza
Pérdida de
Pérdida de
confidencialidad
privacidad
de integridad Pérdida
Pérdida de
disponibilida:
Utilizar los mcdios clc acccso corrcspondicntcs a otra pcrsona Morliflc¿rcitin o copia no atrtorizaclas dc los datos
Altcración clc un program¿l I)olitieas y ¡troccdirtricrttos inudccrradt)s quc pcrrnitcn sc procluzca la consulta dc
c¡rrc
clatos t¿rnto confldcncialcs
couro nrl confldcncialcs Escuch¿rs
Lntracla ilcgal por partc dc un hackcr
('hantaic Crcaci(rn clc 'pr,re-rlas trascras' crl r"rn sistcnra
Robo clc datos, progranras y
/ r'
cclui¡-xrs
Fallo dc los r-nccanisnros dc scguri rlad. ¡rroporc ior-rando ul-l acccso sr,r¡'lcrior al nonnal
lluclgas tl carcncias tlc pcrst-rnal Fornraci(rn inaclccuada dcl ¡lcrsonal VisLr¿rlización
y divulgacitin dc
drrttls nrl uttrrizatkls
ll
lntcrtercncia elcctrónica dc rrdiaci(rn
fc t:
r.r
Corrurpci(rn clc los clatos dcbido a cortcs clc sttrlrirtistro tl sobrctcnsione
19.2,
s
Fucgo (clóctrico, clcbitlo a un tipo), inundacio-
Autr
r¿lyo o dc otro
ncs. bornbas Duños flsicos it los equipr-rs Ru¡rtura dc dcsconcxión dc cablcs
Introducción de r,'irus
{
.
r'
_-
=:-l-r
eiLr
-'i'.2¿ '.',\a
Capítulo 19 Seguridad 497 Hardware Fuego/inundación/bombas Corrupción de datos debido a un corte de suministro o sobretensión Fallo de los mecanismos de seguridad proporcionando un mayor acceso Robo de equipos Daños físicos a los equipos I nterferencia electrónica y radiación
de
bilidac
SGBD y software de aplicación Fallo de los mecanismos de seguridad que proporcione un acceso mayor Alteración de los programas Robo de los programas
ffi Redes de comunicaciones Escuchas Rupturas o desconexión de cables lnterferencia electrónica y radiación
Usuarios Utilización de los medios de acceso correspondientes a otra persona Visualización y divulgación de datos no autorizados Formación inadecuada del personal Entrada ilegal por parte de un hacker Chantaje lntroducción de virus
Prog ramadores/Ope radores Creación de puertas traseras Alteración de los programas (por ejemplo creando un software que sea inseguro) Formación inadecuada del personal Políticas y procedimientos de seguridad inadecuados Huelgas o carencias de personal Administrador de datos/base de datos Políticas y procedimientos de seguridad inadecuados
Base de datos Modificación o copia no autorizada de los datos Robo de los datos Corrupción de los datos debido a un corte de suministro o sobretensión
Datos/Administrador de base de datos Procedimientos y políticas de seguridad inadecuados
Figura 19.1. Resumen de potenciales amenazas en los sistemas informáticos.
I I r
integridad cifrado tecnología RAID.
19.2.1 Autorización Autorización
La concesión de un derecho o privilegio que perm¡te a una persona acceder legítimamente a un s¡stema o a un objeto del s¡stema.
:--ieden incluirse controles de autorización en el software y dichos controles no sólo regularán a qué sistema - objeto puede acceder un usuario especificado, sino también qué es lo que puede hacer con é1. El proceso de .jrorización implica la autenticación de los sujetos que soliciten acceso a los objetos, donde la palabra 'suje-r' representa tanto a un usuario como a un programa, mientras que 'objeto'representa una tabla de la base
:: datos, una vista, un procedimiento,
un disparador o cualquier otro objeto que pueda crearse en el sistema.
498
Sistemas de bases de datos
Cliente remoto
Et Servidor SGBD
Red
Cliente local
interna segura (intranet)
Figura 19.2. Representación de un entorno informático multiusuario típico. Autenticación
Un mecanismo que determina si un usuario es o no quien pretende ser.
El adrninistrador del sisterra será nonnalmente responsable de pennitir que los usuarios tengan acce>- sisterna infonnático, creando cuentas de usuario individuales. A cada usuario se le asigna una identiflc¿. unívoca, que es utilizada por el sistema operativo para detenninar quién es. Asociada con cada identit-rc"hay una contraseña, seleccionada por el usuario y conocida por el sistema operativo, la cual debe ser sunt-trada para que el sistema operativo pueda verihcar (o autenticar) quién dice el usuario que es. Este procedirniento perrnite un uso autorizado de un sistema intbnnático, pero no necesariamente aL:. za el acceso al SGBD o a cualquier programa de aplicación asociado. Puede que sea necesario llevar a .-: tun procedirniento independiente pero similar para proporcionar a un usuario el derecho a usar el SGBD responsabilidad de autorizar el uso del SGBD usualmente coresponde al adrninistrador de la base de i (DBA), que tarnbién debe cont-rgurar curentas de usuario y contraserias individuales utilizando el pr.: SGBD. Algunos SGBD mantienen una lista de identificadores de usuario válidos jurnto con sus contraseña5 ;: ' ciadas, lista que puede ser distinta de la del sisterna operativo. Sin embargo, otros SGBD mantienen una . -- cuyas entradas se validan de acr¡erdo con la lista del sistema operativo, basándose en el identificador de. cio de sesiór-r del usuario actual. Esto evita que el usuario tenga que iniciar una sesión en el SGBD con ur s :to nombre después de haberse conectado al sistema operativo empleando un nombre distinto.
Capítulo 19 Seguridad
499
'9.2.2 Controles de acceso . típica de proporcionar controles de acceso en un sistema de base de datos se basa en la concesión y =na .¿ción de privilegios. Un privilegio permite a un usuario crear o acceder (es decir, leer, escribir o modi-- .:igúrn objeto de base de datos (como por ejemplo una relación, vista o índice) o ejecutar ciertas utilida* -. SGBD. Los privilegios se conceden a los usuarios para que éstos puedan llevar a cabo las tareas reque- por su trabajo. Una concesión excesiva de privilegios innecesarios puede poner en cuestión los ----,-ismos de seguridad: sólo debe concederse un privilegio a un usuario si dicho usuario no puede llevar a .u labor sin disponer de dicho privilegio. Un usuario que cree un objeto de base de datos tal como una .rn o una vista obtendrá automáticamente todos los privilegios relativos a dicho objeto. El SGBD lleva, -: :ontrol de cómo se conceden subsiguientemente dichos privilegios a otros usuarios, así como de las posi- 13\ocaciones, ) s€ encargará de garantizar qtJe en cada momento sólo los usuarios que dispongan de los -egios necesarios puedan acceder a los distintos objetos.
;
bntrol de acceso discrec¡onal -
(DAC, Discretionary Access Control)
..r'oría de los SGBD comerciales proporciona una técnica para gestionar privilegios que emplea un mecacon el nombre de control de acceso discrecional (DAC, Discretionary Access r,rrrol). El estándar SQL soporta los mecanismos DAC rnediante los comandos GRANT y REVOKE. El - 'rdo GRANT proporciona privilegios a los usuarios, mientras que el comando REVOKE se los quita. En '.-:ción 6.6 hemos explicado cómo soporta el estándar SQL los mecanismos de control de acceso discre:-:. control de acceso discrecional, aunque resulta efectivo, tiene ciertas debilidades. En particular, un usua- -' autorizado puede engañar a otro que sí lo esté para qLre le revele datos conf-rdenciales. Por ejemplo, un - --::.o no autorizado, por ejemplo uno que tenga el papel Assistant en el caso de estudio de DreamHome ---3 cre&r una tabla para capturar detalles de los nuevos clientes y proporcionar privilegios de acceso a un - ::o autorizado, como por ejemplo uno que tenga el papel de Manager, sin conocimiento de éste. La per-- ifl el papel de Assistant puede a continuación alterar algunos programas de aplicación que el usuario -- iSer utilice, incluyendo algunas instrucciones ocultas para copiar datos confidenciales de la relación Client - :.re sólo los usuarios Manager tienen acceso, en la nueva relación creada por el usuario Assistant. El usua-.tr áutorízado, es decir, el usuario Assistant, tendrá ahora una copia de los datos confidenciales, es decir, - - S ruevos cliente s de DreamHome y para no dejar huellas de sus acciones puede volver a modificar los .;amas de aplicación alterados, dejándolos en su forma original. --,aramente, se necesita un mecanismo de seguridad adicional para eliminar tales amenazas, y este requipuede satisfacerse mediante la técnica denominada control de acceso obligatorio (MAC, Mandatory -:ss Control), de la que hablarernos a continuación. Aunque casi todos los SGBD comerciales proporcio-- :recanismos de control de acceso discrecional, sólo algunos de ellos soportan los mecanismos de control - --'ceso obligatorio.
- - de SQL conocido
lontrol de acceso obl¡gatorio (MAC, Mandatory Access Control) - mecanismos de control de acceso obligatorio (MAC, Mandatory Access Control) se basan en políti. Je nivel de sistema que no pueden ser modificadas por los usuarios individuales. Con este tipo de meca:ros, a cada objeto de la base de datos se le asigna Llna clase de seguridad y u cada usuario se le asigna un ... de autorización para cada clase de seguridad, irnponiéndose una serie de reglas a la lectura y escritura -. bjetos de base de datos porparte de los usuarios. El SGBD determina si un usuario concreto puede leer o -..bir un objeto determinado basándose en una serie de reglas relacionadas con la clase de seguridad del - :to y el nivel de seguridad del usuario. Estas reglas tratan de garantizar qtre los datos confidenciales nunca - -Jen ser pasados a otro usuario que no disponga del nivel de seguridad adecuado. El estándar SQL no inclu: :r)porte para los mecanismos MAC. Un tipo popular de modelo MAC es el denominado modelo Bell-LaPadula (Bell y LaPadula, 1974), que . iescribe en términos de objetos (como por ejemplo relaciones, vistas, tuplas y atributos), sujetos (como . ejemplo usuarios y programas), clases de seguridad y niveles de seguridad. A cada objeto de la base de
5OO Sistemas de bases de datos datos se le asigna una clase de seguricla¿l, mientras qLre acadasujeto se le asignaunnivel de seguridadparcada clase de seguridad. Las clases de seguridad dentro de urn sistema están ordenadas, existiendo una cla:; qLle es la rnás segura y otra que es la menos segura. Para nuestro análisis del modelo, vamos a suponer qu. existen cuatro clases: alto secreto (TS, top secref), secreto (S), con/idencial (C) y no clasificado (U, tmclass:Jied), y haremos referencia a la clase de un objeto o sujeto A como c'lass (A).Por tanto, para este sistema, I.. > S > C > U, donde A > B implica que los datos de la clase A tienen un nivel de seguridad más alto que lr.',: datos de la clase B. El r¡odelo Bell-LaPadr"rla irnpone dos restricciones a todas las lecturas y escrituras de objetos de la bas. de datos:
l.
Propiedad de seguridad simple: el sujeto S puede leer el objeto o sólo si class (S) >: class (O). P.: ejemplo, un usuario con nivel de seguridad 7S puede leer una relación con nivel de seguridad C, perun ttsuario con nivel de seguridad C no puede leer una relación cuya clase de seguridad sea 7,S.
f-
2. *-Property: el sujeto S puede escribir el objeto o sólo si class (.f) <:class (O). Por ejemplo, un Lrsu;rio con nivel de seguridad S sólo puede escribir objetos cuya clase de seguridad
sea S
o
E-
I^S.
-
Si se especitican también controles de acceso discrecional, dichas reglas representarán restricciones aci.cionales. Por tanto, para leer o escribir un objeto de la base de datos, un usuario deberá tener los privile_ui,-. necesarios proporcionados mediante el cornando SQL GRANT (véa.se la Sección 6.6) y las clases de segur.dad del usuario y del objeto deben satisfbcer las restricciones antedichas.
..:
--\-
=
Relaciones mult¡n¡vel y poli-instanciación
clientNo
fName
lName
telNo
prefType
maxRent
CR76
John
Kay
0207 -77 4-5632
Flat
4?5
CR56
Aline
Stewarl
0l4r-ri48-1n25
FIat
350
cll74
Mike Mary
Ritchie
0r475-392t78
House
750
ltegar
01224-196720
Flat
600
CR62
securityClass C'
(' s s
g.:
t
Para poder aplicar políticas de control de acceso obligatorio en un SGBD relacional, debe asignarse una cla.. de seguridad a cada objeto de la base de datos. La granularidad de dichos objetos puede estar en el nivel c. las relaciones, de las tuplas o incluso de los valores de los atributos individuales. Suponga que a cada tupla -. le asigna una clase de seguridad. Esta situación conduce al concepto de relación multinivel, que es una rel*ción que revelará diferentes tuplas a los distintos usuarios, según sus respectivos niveles de seguridad. Por ejernplo, en la Figura 19.3(a) se muestra la relación Client con Lrn atributo adicional que indica la ci:.. de seguridad correspondiente a cada tupla. Los usuarios con nivel de seguridad .S y LS podrán ver todas las tuplas de la relación Ctient. Sin er¡bars. un usuario con nivel de seguridad C sólo podrá ver las primeras dos tuplas y un Ltsuario con nivel de segr::dad U no poüá Yer ninguna. Suponga que un usuario con nivel de segurida<1 C quiere introducir una tur (CR74, David, Sinclaire) en la relación Client, donde la clave principal de la relación es clientNo. Esta inserc : no es posible, porque viola la restricción de clave principal (véase la Sección 3.2.5) correspondiente 3 =:relación. Sin embargo, la incapacidad de insertar esta nueva tupla intbrma al usuario de nivel de segurid-: de que existe una tupla con Lln valor de clave principal igual a CR74 y con una clase de seguridad super..' C. Esto pone en cuestión el requisito de seguridad de que los usuarios no deben ser capaces de inferir nrn:-tipo de infbnnación acerca de los objetos que tengan una clasit-rcación de seguridad superior. Este problerna de la intbrencia puede resolverse incluyendo el atributo de clasificación de segurridad ct =, parte de la clave principal de una relación. En el ejernplo anterio¡ la inserción de la nueva tupla en la rela¡ Client será autorizada y la instancia de la relación se modificará como se tnuestra en la Figura 19.3(b). usuarios con nivel de seguridad C verán las primeras dos tuplas y la tupla recién añadida, pero los usua-
tñs
: --_.:: - -r::
t
9.2 coF S€9
: -
i_-E i,_-,:
_
---
:i
_ --
:\
.J
---_ . _\ Regi
Figura 19.3(a). La relación Client con un atributo adicional que muestra la clase de seguridad correspond¡ente a cada tupla.
|
Capítulo 19 Seguridad egur¡dad para ndo una clase a suponer que r
(U, unclassi-
clientNo
fName
lName
telNo
prefType
CR76
Kay
0207-774-s632
Flat
425
Stewart
0l4l-848-1825
Flat
350
C
CR74
Iohn AIine Mike
Ritchie
01475-392t78
House
750
CR62
Mary
Tregar
01224-196720
Flat
600
s s
CR74
Daüd
Sinclaire
CR56
te sistema, 7.S rs alto que los
maxRent
5(}1
securityclass C
C
tos de la base
Figura f 9.3(b). La relación Client con dos tuplas que tienen un valor de clientNo igual a CR74. class (O). Por rridad C, pero sea 7,S.
rplo, un usua7S.
ricciones adios privilegios ses de seguri-
arse una clase en el nivel de cada tupla se e es una rela-
La clave princlpal de esta relación es (clientNo, securityClass). Jon nivel de seguridad S o 7'S verán las cinco tuplas. El resultado es una relación con dos tuplas cuyo valor ,le clientNo es igual aCR74,lo cual puede ser confuso. Esta situación puede resolverse presuponiendo que la rupla con la clasificación de seguridad más alta tiene prioridad sobre la otra, o mostrando sólo una de las tuplas según el nivel de seguridad del usuario. La presencia de objetos de datos que parecen tener diferentes valores a ojos de los distintos usuarios según su nivel de seguridad se denomina poli-instanciación. Aunque el control de acceso obligatorio resuelve una de las principales debilidades del control de acceso discrecional, una desventaja fundamental de las técnicas MAC es larigidez de este tipo de entomos. Por ejemdo, las políticas de segwidad MAC suelen ser establecidas por los administradores de la base de datos o del sistema y los mecanismos de clasificación suelen ser bastante poco flexibles.
19.2.3 Vistas V¡sta
uridad. ndica la clase
Sin embargo. vel de segurircir una tupla lsta inserción rdiente a esta : seguridad C ad superior a n1'erir ningún ;uridad como :n la relación 19.3(b). Los los usuarios
Una vista es el resultado dinámico de una o más operaciones relacionales que operan sobre las relaciones base con el fin de producir otra relación. Una vista es una relación virtual que no existe en realidad en la base de datos, sino que se genera en el momento en que un usuario concreto efectúa una solicitud.
El mecanismo de vista proporciona un sistema de seguridad potente y flexible, al ocultar partes de la base de datos a ojos de ciertos uswrios. El usuario no es consciente de la existencia de ningún atributo o fila que no esté presente en la vista. Las vistas pueden definirse sobre varias relaciones base, pudiendo concederse al usuario el privilegio apropiado para usar la vista, pero no para usar las relaciones base. De esta forma, la utilización de una vista es más restrictiva que conceder simplemente ciertos privilegios al usuario sobre las relaciones base. Hemos hablado en detalle acerca de las vistas en las Secciones 3.4 y 6.4.
19.2.4 Copia de seguridad y recuperac¡ón Copia de seguridad
El proceso de realizar periódicamente una copia de la base de datos del archivo de registro (y posiblemente de los programas), almacenando la copia en un medio de almacenamiento fuera de línea.
Un SGBD debe proporcionar facilidades de copia de seguridad para ayudar a la recuperación de la base de datos en caso de que se produzca un fallo. Resulta siempre aconsejable realizar copias de seguridad de la base de datos y del archivo de registro a intervalos regulares y garantizar que las copias se conserven en una ubicación segura. En caso de que se produzca un fallo que haga que la base de datos deje de ser utilizable, podrán usarse la copia de seguridad y los detalles capturados en el archivo de registro para restaurar la base de datos hasta el estado coherente más reciente. En la Sección 20.3.3 se incluye una descripción de cómo utilizar un archivo de registro para restaurar una base de datos. Registro
El proceso de mantener y almacenar un archivo de registro (o diario) de todos los cambios realizados en la base de datos, con el fin de poder llevar a cabo una recuperación en caso de que se produzca un fallo.
5O2 Sistemas de bases de datos Un SGBD debe proporc ionar facilidades de registro que permiran conocer el estado acfua.l de ias transacciones y de los cambios efectuados en la base de datos, con el fin de proporcionar soporte para los procedimientos de recuperacióir. La ventaja del proceso de registro es que, en caso de f'allo, la base de datos puede recuperarse hasta el último estado coherente conocido, utilizando una copia de seguridad de la base de datos y Ia infbnnación contenida en el archivo de registro. Si no se habilita ningún rnecanismo de registro en un sistema, el único r¡odo de recuperarlo en caso de f-allo es restaurar la base de datos Lrtilizando la úritima versión de copia de seguridad. Sin ernbargo, al no disponer de archivo de registro, cualqr.rier cambio qLre se haya efbctuado después de esta última copia de seguridad de la base de dalos se habrá perdido. El proceso de registro se analiza con más detalle en la Sección 20.3.3.
19.2.5 lntegridad
L¡
-ardv
:ia
es
::cior --:s p =:rnil
,- _r n( :-.ilto: Ot
-: , 3:
113 _
L¿rs restricciones de integridad tanibién contribuyen a rnantener un sistema de base de datos seguro, impidiendo qr"re los datos lleguen a ser inválidos y que puedan condr.rcir a resultados erróneos o susceptibles de ser mal interpretados. Las restricciones de integridad se han explicado en detalle en la Sección 3.3.
19.2.6 Cifrado Cifrado
La codificación de los datos mediante un algoritmo especial que hace que éstos no sean legibles por ningún programa que no disponga de la clave de descifrado.
Si un sistema de base de datos almacena datos particularmente confidenciales. puede que sea necesarir. codiflcarlos como precaución fiente a posibles alrenazas extemas o frente a inlentos de acceder a ellos. Algr-rnos SGBD proporcionan para esto una funcionalidaii de cifrado. El SGBD puede acceder a los datos (después de decodificarlos), aunque existe una cierla degradación del rendimiento debido al tiernpo necesario para la decodificación. El cifrado también protege los datos transmitidos a través de líneas de comunicaciones. Existen diferentes técnicas para cifi'ar los datos con el fin de ocultar la información. Algunas de las técnicas se denominan'irreversibles'y otras'reversibles'. Las técnicas ineversibles, como su nombre indica, uo penniten conocer los datos originales. Sin embargo, dichos datos pueden continuar usándose para obtener información estadíslica válida. Las técnicas reversibles son las que más comúnmente se utilizan. Para lransmitir datos de manera segura a través de redes inseguras se necesita utilizar un criptosistema, que
incluye:
r I I 1
19.' :,,.:3:
-:
az
.-.*..
.-::,--' I-':
una clat,e de cifrado para cifrar ios datos (texto en claro); ttn algorilmo de cifrttdo que, con la clave de citiado, transfon¡a el texto en ciaro en texto cifrado;
d¿ote
una clave de desciJrado para descifrar el texto cifiado;
-::-:
ttn algoritnto de descifi'ado qrre, con la clave de descifrado, transforma el terto cifrado, para obtener de nuevo el texto en claro.
Una de las técnicas disponibles, denorninada cifrado simétrico, r.rtiliza la misma clave tanto para el cifiado como para el descifrado y emplea líneas de comunicación seguras para el intercambio de la clave. Sin etnbargo, ia rnayoría de los usuarios no tienen acceso a una línea de commicación segura y, para ser realmente seguras, las claves tienen que ser tan largas como el propio mensaje (Leiss, 1982). Sin embargo, la rnayoría cle los sistemas prácticos se basan en la utilización de claves de usuario que son más cortas que el propic mensaje. Uno de los esquemas utilizados para este tipo de cifrado es el estándar de cifrado de datos DES (Data Encryption Standard), que es un algoritmo estándar de cifrado desamollado por lBM. Esle esquem; utiliza una rnisma clave para el citiado y el descifiado, clave que es preciso mantener en secreto, aunque e.
propio algoritrno no tiene por qué serlo. Ei algoritrno transfonna cada bioque de 64 bits del texto en claro urilizando una clave de 56 bits. DES no se considera universalmente como un sistema lnuy seguro, y alguno: alltores sosfienen que hace falta una clave de mayor tamaño. Por ejemplo, Lln esquema denorninado PGP (Pretty Good Privacy) Lrtiliza un algoritrno simétrico de 128 bits para el cifrado masivo de los datos transrnitidos.
i!,-:
Capítulo 19 Seguridad 5O3 I as claves de 64 bits son probablemente descifrables en la actualidad por los gobiernos que dispongan del ,--Ju,are especial necesario, aunque a un coste sustancial. En unos pocos años, es posible que esta tecnolo- . isté al alcance de las organizaciones crirninales y de otros gobiemos, así como de las principales corpo-,:ones. Aunque la previsión es que las claves de 80 bits también sean descifrables en el futuro, Ias de 128 . probablemente resultarán seguras y no descifrables en los años sucesivos. Algunas veces se utilizan los :-rinos 'autenticación fuerte'y 'autenticación débil'para distinguir entre aquellos algoritmos que en princi:ro pueden ser rotos con las tecnologías y conocimientos existentes (algoritmos fuertes) de aquellos algo:--os que sí pueden ser rotos (algoritmos débiles). Otro tipo de criptosistema utiliza claves distintas para el cifiado y descifrado, denominándose a este tipo -: recanismos cifrado asimétrico. Un ejemplo son los criptosistemas de clave pública, que utilizan dos cla::. ufl& de las cuales es pública y la otra privada. El propio algoritrno de cifrado tarnbién puede hacerse públile modo que cualquiera que desee enviar un mensaje a un usuario puede utilizar la ciave pública de dicho . -.:rio en conjunción con el algoritmo de cifiado. Sólo el propietario de la clave privada podrá entonces des-
' '
de clave púrblica pueden también utilizarse para enviar una 'frrma digi.on un mensaje, lo que permite demostrar que el mensaje proviene de la persona que dice haberlo enviaEl sistema más conocido de cifrado asimétrico es RSA (el nombre se deriva de las iniciales de las tres
'::r el mensaje. Los criptosistemas
-. ': Soo&s que diseñaron
el algoritmo).
Generalmenle, los algoritmos sirnétricos son mucho más rápidos de ejecutar en una computadora que los -..:rétricos. En la práctica, sin embargo, ambos tipos de algoritmos se utiiizan conjnntamente, empleándose - :igoritmo de clave púrblica para cifiar nna clave de cifrado generada aleatoriarnente, y usándo dicha clave -. ;itiado para cifrar el mensaje mediante un algoritmo sirnétrico. Hablaremos más en detalle de los meca' :nos de cifrado en el contexto de la Web en la Sección 19.5.
19.2.7 RAID (Redundant Array of lndependent Disks) : -
iardware en el que el SGBD se ejecute debe ser tolerante a.fallos,lo que quiere decir qtre el SGBD debe :e¡ continuar operando incluso aunque uno de los componentes del hardware falle. Esta necesidad sugiere
--:
conviene disponer de cornponentes redundantes que pueden integrarse de formatransparente en el siste-
-..
--ü
cada vez que se produzca un fallo de componente. Los principales componentes del hardware que deben .: :olerantes a fallos son los discos duros, las controladoras de disco, el procesador, las fuentes de alimenta. -:r y los ventiladores de refiigeración. Las unidades de disco son los componentes más vulnerables, presen-
un tiempo más corto entre fallos que cualquier otro componente del hardware. Una solución es el uso de la tecnología RAID (Redundant Array of Independent Disks, matriz redun:¡nte de discos independientes). RAID funciona basándose en una rratriz de discos de gran tamaño, com:-3sta por varios discos independientes, que se organiza para mejorar la fiabilidad y al mismo tiempo para : rernentar las prestaciones. Las prestaciones se pueden incrementar mediante la técnica denominada de Jranjas de datos. Los datos se :-:mentan en particiones de igual tamaño (las fi'anjas) que se distribuyen transparentemente entre múltiples - tcos. Esto proporciona al usuario la apariencia de un único disco de gran tarnaño y muy rápido, mientras - -e en la realidad los datos están distribuidos entre varios discos más pequeños. La técnica de franjas mejo'- .as prestaciones globales de E/S permitiendo que se realicen múltiples operaciones de E/S en paralelo. Al -.srno tiempo, la técnica de franjas permite también equilibrar la carga entre los distintos discos. La fiabilidad se mejora almacenando información redundante en los discos, empleando un esquema de ..,idad o de corrección de errores, como por ejemplo los códigos Reed-Solomon (véase, por ejemplo, Pless, -39). En los esquemas de paridad, cada byte puede tener un bit de paridad asociado que indique si el núme-- de bits con valor 1 dentro del byte es par o impar. Si el número de bits del byte se corrompiera, la nueva -,ndad del byte no se correspondería con la paridad almacenada. De forma similaq si el bit de paridad alma--:ado se corrompiera, no se corespondería con los datos contenidos en el byte. Los esquemas de corrección -: errores almacenan dos o más bytes adicionales y penniten reconstruir los datos originales en caso de que --. irnico bit se corrompa. Estos esquemas pueden utilizarse en conjunción con la técnica de distribución de ' :os por franjas. -.=.Jo
L: t-.a
5O4 Sistemas de bases de datos Existen diftrentes tipos posibles de conf-rguración de los discos en RAID, denor¡inándose dichos tipos niveles RAID. A continuación se proporciona una breve descripción de cada nivel RAID, junto con un diagrama que representa cada r¡no de los principales niveles (véase la Figura 19.4). En esta figura, los números representan bloques de datos secuenciales y las letras indican los segmentos de un bloque de datos.
I
RAID 0 - No redundante Este nivel no mantiene ningúur dato redundante, así que proporciona
las
rnejores prestaciones de escritura, ya que no es preciso replicar las actualizaciones. Las tianjas de datos se forman en el nivel de bloque. En la Figura 19.4(a) se muestra un diagrama de RAID 0.
r
RAID I * Espejo - Este nivel rnantiene dos copias idénticas (espejos) de los datos, almacenándolos en diferentes discos. Para manlener la coherencia en caso de f'allos de disco, las escrituras no pueden realizarse simultánearnente. Esta es la solución más cara desde el punto de vista del almacenatniento. En 1a Figura 19.4(b) se rruestra Lrn diagrarna de RAID 1.
r
RAID 0+l
-
No redundante y en espejo Este nivel combina las técnicas de división en fianjas y
de
drrplicación en espejo.
I
RAID 2 - Códigos de conección de errores tipo memoria Con este nivel, la fianja estir compLlest:: por Lln iurico bit y se utilizan Códigos Harnrning como esquerna de redundancia. En la Figura 19.4(c se muestra un diagrarna de
r
RAID
RAID
2.
bit
3 - Paridad con erltrelazado de Este nivel proporciona redundancia ah¡acenando infbmr¡.ción cle paridad en uno de los discos de 1a matriz. Esta infomación de paridad puede r-rtilizarse pari'-
recuperar los datos de otros discos en caso de que éstos fallen. Este nivel utiliza menos espacio d; almacenarniento qLle RAID 1, pero el disco de paridad puede convertirse en trn cuello de botella. E,n 1., Figura 19.4(d) se muestra un diagrama de RAID 3.
I
RAID 4
I
RAID 5 - Paridad distribuida con entrelazado de bloque - Este nivel utiliza datos de paridad comr rnecanismo de introducción de redundancia, de fonna similar a RAID 3, pero distribuye en franjas ic.. datos de paridad entre todos los discos, de forma similar a corno se distribuyen en fianjas los datos ci; origen. Esto reduce la posibilidad de que e1 disco de paridad se convierta en un cuello de botella. E:. la Figura 19.4(0 se lrruestra un diagrarna de RAID 5.
I
RAID 6 - Redundancia P+Q - Este nivel
- Paridad con entrelazado de bloque - En este nivel, la tranja es el bloque de disco, manleniéndose r"rn bloque de paridad en un disco independiente para una serie de bloques correspondientes airnacenados en olros discos. Si uno de los discos talla, puede usarse el bloqure de paridad junto cor'. los bloques correspondientes de los otros discos para restaurar los bloques del disco f'allido. En i, Figura l9. (e) se muestra un diagrama de RAID 4.
es similar a RAID 5, pero se introducen datos redundante. adicionales como protección frente a fallos múltiples de disco. En lugar de emplear esquelnas de pandad, se utilizan códigos de corrección de errores.
Oracie, por ejemplo, recornienda utilizar RAID 1 para los archivos dei registro de rehacer. Para los arch-vos de base de datos, Oracle recomienda RAID 5 (si el coste adicional en escritura es aceptable) o, en cas,. contrario, RAID 1 o RAID 0+1. Un análisis detallado de 1as tecnologías RAID está füera del alcance de esl. libro, por 1o qr,re ei lector interesado puede consuhar los artículos de Chen y Patterson (1990) y Chen el ... (
1
994).
19.3 Seguridad en el SGBD de Microsoft Office Access En la Sección 8.1 hemos proporcionado una panorárnica de1 SGBD Microsoft Off,rce Access 2003. En es:sección vamos a centrarnos en las medidas de seguridad proporcionadas por OtIce Access. En la Sección 6.: se han descrito ias instrucciones SQL GRANT y REVOKE, Microsoft Office Access 2003 no soporta est¿. instnrcciones, sino que en su lugar proporciona los dos rnétodos siguientes para dotar de seguridad a una ba.. de datos: I conf-rgurar una contraseña para la apertura de la base de datos (1o que se denomina seguriclad del s:,tema de Microsoft Ofhce Access);
D
Capítulo 19 Seguridad Lndose
dichos tip_
unto con un diasr,_
igura, los
,rúme"r¡
,
de datos.
Escrituras en
I Disco
I
[tt tl E-l
iiti I
O.
t.l I.l l;l l.l
ón en fianjas y d.
L.-l
L._1
I
I
(a) RAID 0
Disco
3
Disco 4
[,--l
l:ll:lt:ll:t l.ll.ll.ll.l
l:l tl
tltltl +tt+
L_1
I
Lecturas en paralelo
ja está compues:_ la Figr_rra 19.4( u
Disco
l;ll.;ll;.ll;t
tl
E:
2
I:I tr ll;ll.;ll;.ll;l Disco
I ;-l l-r1 l-,;l l;;l t.l l;l
rlmacenándolos ;ras no pueden re,-
;enando infom.ir,de utilizarse par* nenos espacio d. r de botella. En 1,,
I Disco 4
tbt
,
llacenamiento.
I Disco 3
Disco 2
1
ue prOporciona 1., -as franjas de dat¡
AID
505
- No redundante
(b)
Cada escritura abarca todos los discos
RAIDl-Espejo
Cada escritura abarca todos los discos
Disco
1
Disco
2
Disco
3
Disco 4
de disco, mantecorrespondientes aridad junto corr
;o lallido. En
1¡,
le paridad como ye en lianjas los rjas los datos de o de botella. En (c) RAID 2
tos redundanles
-
(d) RAID 3
Códigos de corrección de errores tipo
- Paridad con entrelazado de bit (Bit-lP, B¡t lnterleaved Parity)
-emoria (MSECC, Memory-Style Error-Correcting Code)
quetnas de pariPara los architble) o, en caso
Escrituras en paralelo con escrituras Block-lDP asociadas en unidades distintas
,
alcance cle este t) y Chen er al.
Disco
1
Disco 2 2
Disco 3
Disco 4
)cess 2003. En esra la Sección 6.6 ) soporta estas dad a una base
ffidad del sis-
(e) RAID 4 - Paridad con entrelazado de bloque (Block-lP, Block-lnterleaved Parity)
Disco
1
Disco
2
Disco
3
Disco 4
Figura 19.4.
Niveles RAID. Los números representan bloques de datos secuenciales y las lelras indican los segmentos (f ) RAID 5 - Paridad diskibuida con entrelazado de bloque de un bloque (Block-lDP, Block-lnterleaved Distributed Parity) de datos.
5OO Sistemas de bases de datos
I
seguridad de nivel de usuario, que puede utilizarse para limitar aquellas partes de la base de datos que un usuario puede leer o act¡alizar (1o que se denomina seguridad de los datos en Microsoft Office Access).
,les t-io¡
En esta sección se describe brevemente cómo proporciona Microsoft Office Access estos dos tipos de mecanismos de seguridad.
Configurac¡ón de la contraseña El mecanismo de segr,rridad más simple consiste en establecer una contraseña parala apertura de la base de datos. Una vez configurada una contraseña (en el menú Tools, Security) se mostrará un cuadro de diálogo de solicitud de Ia contraseña cada vez que se abra la base de datos. Sólo los usuarios que escriban la contraseña correcta estarán autorizados a abrir la base de datos. Este método es seguro, ya que Microsoft Office Access cifra 1a contraseña para que nadie pueda acceder a ésta leyendo directamente el archivo de la base de datos. Sin embargo, una vez abierta la base de datos, todos los objetos contenidos en la misma estarán a disposición del usuario. La Figura 19.5(a) muestra el cuadro de diálogo de configuración de la contraseña y la Figura 19.5(b) muestra el cuadro de diáiogo en el que se solicita la contraseña cadavez que se abre la base de datos.
crq
r-ec
Seguridad de nivel e usuario La seguridad de nivel de usuario de Microsoft Office Access es similar a los métodos utilizados en la mayoría de los sistemas de red. Los usuarios deben identificarse y escribir una contraseña cuando inicien Microsoft Offrce Access. Dentro del archivo de información del grupo de trabajo de Microsoft Oft'ice Access, los usuarios se identifican como miembros de un grupo. Access proporciona dos grupos predeterminados: administradores (grupo Admins) y usuarios (grupo Users), pero pueden definirse grupos adicionales. La Figura 19.6 muestra el cuadro de diálogo utilizado para definir el nivel de seguridad para las cuentas de usuario y de grupo. En ellos se muestra un grupo no predeterminado denominado Assistants y un usuario denominado Assistant que es miembro de los grupos Users y Assistants. Los permisos se conceden a los grupos y usuarios para regular el modo en que pueden trabajar con cada uno de los objetos de la base de datos; para ellos se ernplea el cuadro de diálogo User and Group Pennissions. La Tabla 19.2 muestra los permisos que pueden conf,rgurarse en Microsoft Office Access. Por ejemplo, la Figura I9.7 presenta el cuadro de diálogo para un usuario denominadoAssistant que sólo tiene acceso de lectura a una consulta almacenada denominada Staffl_View. De forma similaq el acceso a la tabla base Staff podría
Ferrrl -1tr38
Enlpr databos* pessrdordi :
****+**'l.tt l
,
-lf,ñ
'1.
l..--q{:l r*::l
i-ii }
l
\d.rdif
r,¡EéE
Cuadro de diálogo para establecer una contraseña para controlar el acceso a la base de datos (la contraseña no se muestra en la pantalla)
Cuadro de diálogo que se muestra cadavez que se abre la base de datos,
(a)
(b)
para solicitar Ia contraseña requerida.
Figura 19.5. Cómo dotar de seguridad a la base de datos de DreamHome utilizando una contraseña: (a) el cuadro de diálogo Set Database Password; (b) el cuadro de diálogo Password Required que se muestra en el inicio.
l*i
I
.EEsi ¡n¡cr:rl
:§E
Capítulo 19 Seguridad 5O7 a base de datos qu:
'n Microsoft Offlc.
:esactivarse, para que el usuario Assistant sólo pudiera ver los datos de la tabla Staff utilizando la vista men::onada.
eslos dos tipos d;
:rtura de la base d; radro de diálogo d; riban la contraseñ. rsoft OfIice Acces-. le la base de datos.
El usuar¡o Ass¡stant es miembro de los grupos Users y Assistants
farán a disposició: :raseña y la Figur. re la base de datos. Grupo no predeterminado Assistiants
zados en la rnayor inicien Microsot I Access, los usuaminados; adminises. La Figura 19.ó
de usuario y de uario denominado rs
trabajar con cad¿ roup Permissions.
Figura 19.6. Cuadro de diálogo User and Group Accounts para la base de datos DreamHome.
s. Por ejerrplo, la ene acceso de ieca base Staff podrla
Tabla 19.2. Permisos de Microsoft Office Access.
t: i
rncel
I
Permiso
Descripción
Open/Run
Abrir una base de datos, formulario o informe, o ejecutar una macro
Open Exclusive
Abrir una
Read Desigr
Ver objetos en la vista de diseño
Modiff Design
Ver y modiñcar objetos de la base de datos y borrarlos
Administer
Para las bases de datos, conhgurar la contraseña de la base de datos, replicar la base de datos cambiar las propiedades de arranque
muestra
I
Contraseña:
y
Acceso completo a los objetos de la base de datos, incluyendo la capacidad de asignar permisos
e de datos,
requerida.
base de datos con acceso exclusivo
Read Dat¿
Visualización de los datos
Update Data
Visualización y modificación de los datos (pero no inserción ni borrado de los datos)
Insert Data
Visualización e inserción de los datos (pero no actualización ni borrado de 1os mismos)
Delete Data
Visualización y borrado de los datos (pero no inserción ni actualización de los datos)
Required
5O8 Sistemas de bases de datos
I
sel
Gea
p
t
Fttl Enter Assistant sólo tiene acceso de lectura a
Co¡ft
i*E4
Staffl_View
Figura 19.7. Cuadro de diálogo User and Group Permissions donde se muestra que el usuario Assistant sólo tiene acceso de lectura a la consulta Staffl View.
19.4 Seguridad en el SGBD de Oracle En la Sección 8.2 hemos proporcionado una panorámica del SGBD Oracle9i. En esta sección, vamos a centramos en las medidas de seguridad proporcionadas por Oracle. En la sección anterior hemos examinados dos tipos de mecanismos de seguridad en Microsoft Offrce Access: segtuidad del sistema y seguridad de los datos. En esta sección, vamos a examinar cómo proporciona Oracle estos dos tipos de seguridad. Al igual que con Offce Access, una forma de seguridad dei sistema úllizada por Oracle es el mecanismo estándar de nombre de usuario y contraseña, por e1 cual un usuario debe proporcionar un nombre de usuario y una contraseña válidos antes de poder acceder a la base de datos, aunque la responsabilidad de autenticar a los usuarios puede recaer en el sistema operativo. La Figura 19.8 ilustra la creación de un nuevo usuario denominado Beech para el que se ha seleccionado la autenticación mediante contraseña. Cadavez que el usuario Beech trate de conectarse a la base de datos, se le presentará un cuadro de diálogo Connect or Log On similar al que se ilustra en la Figura 19.9 y en el que se Ie pedirá que introduzca un nombre de usuario y una contraseña para acceder a la base de datos especificada.
Privilegios Como hemos expiicado en la Sección 19.2.2, un privilegio es el derecho a ejecutar un tipo particular de instrucción SQL o a acceder a los objetos de otro risuario. Entre los privilegios que pueden concederse en Oracle estarían los derechos a:
I r
conectarse a Ia base de datos (crear una sesión); crear una tabla;
Figura 19
Capítulo
I E
19 Seguridad
seleccionar filas de una tabla de otro usuario.
GenÉrñl ..,1,...Ii.:i,
.i12 ^ : lf
r::,
El nombre del nuevo usuario
Name. EEECH Prnrito- ñFFAI I
At¡thcnticaticn Fassword
Seleccionada la autenticación por contraseña
Énler Pü§sw0r{f:
ffi
Contirrrr Farsro¡$rd:
¡/ ExFlrB Passwsf
r,
Now
TahlEsÉacɧ
D*fault,
U§ERB
Ternporary: "§ysternAss¡gnedF Sfalus ,sr
Lücked
)]L)S
que se ha activado la autenticación mediante contraseña.
nados .:
los dat,.
:l que
Unlürked
Figura 19.8. Creación de un nuevo usuario denominado Beech para el
a ac. .
c,-
le nornb:, .setla r i:-.-
ios puec. eech pli. de cone.,
rlustra
e-
accecier
.,
rr de in::n Oracle
5O9
§ser Hamel
lBeech
Password:
l*
Host §tring:
lDrcamHomrl OK
Figura 19.9. Cuadro de diálogo Log On donde se solicita el nombre de usuario, la contraseña y el nombre de la base de datos a la que el usuario quiere conectarse.
51O Sistemas de bases de datos En Oracle, hay dos categorías distintas de privilegios:
I r
prir ilegit-rs del sistema: privilegios sobre 1os objetos.
j-
Privilegios del sistema Un privilegio del sistema es el derecho a realizar r-ma acción concreta o a realizar una acción sobre cualesquiera objetos del esquema que perlenezcai a un tipo concreto. Por ejemplo, los privilegios para crear espacios de tabliis y para crear usuarios en Lrna base de dalos son privilegios del sistema. Hay más de ochenta privilegios del sistema distintos en Oracle. Los privilegios del sistema se conceden (o se revocan) a los usuaric,. y roles (de 1os que hablarernos más adelante) utilizando algunos de los métodos siguientes:
I
el cLiadro de diálogo Grant Systern PrivilegesrRoles leges/Roles de la r.rtilidad Oracle Secr-rrity Manager;
I
las instmcciones SQL CRANT y REVOKE (véase la Sección 6.6).
y
eJ cuadro de diálogo Revoke Systern
Prir:-
Sin embargo, sólo aquellos usuarios a los que se les haya concedido r.rn privilegio específico del sisterr, e1 privilegio del sistema GRANT ANY PRIVILEGE
con la opción ADMIN OPTION o los usuarios con podrán conceder o revocar privilegios del sisterna.
Privilegios sobre los objetos Un privilegio sobre un objeto es un privilegio o derecho para reaiizar una acción concreta sobre una tabl:. vista, secttencia, procedimiento, función o paquete especíticos. Los dif-erentes tipos de objeto tienen dispon.bles dilerentes privilegios sobre el objeto. Por ejemplo, el privilegio de borrar filas de 1a tabla staff es un pr-vilegio sobre el objeto. Algunos objetos del esquema (como los clústeres, índices y disparadores) no tienen privilegios sobre objeto asociado; su uso está controlado rnediante privilegios del sisterna. Por ejemplo, para modificar rur clú.ter, un usuario debe ser propietario del clúster o disponer de1 priviiegio del sistema ALTER ANY CLUSTEF Utr usr.rario tendrá autornáticamente todos los privilegios sobre aquellos objetos que estén contenidos ¡r stl esqLlema. Un usuario puede conceder cualquier privilegio sobre un objeto de esquema del cual sea propietario y esa concesión podrá efectr-rarla a cualquier usuario o ro1. Si la concesión incluye la opción WlTlGRANT OPTION (en 1a instrucción GRANT), ei usuario que recibe la concesión puede a su vez conceder ¡ privilegio sobre el objeto a otros usuarios; en caso contrario, el usuario que recibe la concesión puede usar. privilegio pero no concedérselo a su vez a otros usuarios. En la Tabla 19.3 se mllestran 1os privilegios sobr. los objetos paru lus tablas ¡ vistas.
Roles Un usuario puede recibir un privilegio de dos formas distintas:
(1) Los privilegios pueden conceclerse a los usuar.ios explícitarnente. Por ejernplo, un usuario puede cor-ceder explícitamente el pnvilegio de insertar filas en la tabla PropertyForRent al usuario Beech:
GRANT INSERT ON
PropertyForRent
TO
Beech;
(2) Los privilegios tambiénpueden concederse a rrn rol (Lrn grupo deprivilegios al que se le asigna ntr-. bre) y luego conceder el ro1 a uno o rnás usuarios. Por ejemplo, un usuario puede conceder los prir legios de selección y actualización de filas de la tabla PropertyForRent al rol denominaclo Assistant, qL.. a su vez puede concederse al usuario Beech. Un usuario puede tener acceso a diversos roles y Lmismo rol puede asignarse a diversos usuarios. La Figura 19.10 ilustra la concesión de estos priri.., gios al rol Assistant empleando la Lrtilidad Oracle Security Manager. Puesto que 1os roles penniten una mejor y más sencilla gestión de los privilegios, conviene conceder i-,
privilegios a roles y no a los usuarios específicos.
b.--
Gapítulo 19 Seguridad 51f Tabla 19.3. Qué es lo que la persona que recibe un privilegio sobre el objeto puede hacer con las tablas y vistas. Tabla
Vista
\TTER
Cambiar la definición de la tabla mediante la instrucción ALTER TABLE.
No disponible.
IEI,ETE
Eliminar filas de la tabla mediante la instrucción DELETE. Nota: debe concederse e1 privilegio SELECT sobre la tabla junto con el privilegio DELETE.
Eliminar hlas de 1a vista mediante la instrucción DELETE.
NDEX
Crear un índice sobre la tabla mediante la
No disponible.
Privilegio sobre el objeto
cb¡e cuales. crear espaochenta pri-
los usuarios
stem Privi-
instrucción CREATE INDEX.
NSERT
dei sistema
RIVILEGE
REFERENCES
Añadir nuevas filas a la tabla mediante la
Añadir nuevas filas a la vista mediante la
instrucción INSERT.
instrucción INSERT.
Crear una restricción que haga referencia a la tabla. No se puede conceder este privilegio a
No disponible.
un ro1. :
SELECT
Consultar la tabla mediante la instrucción SELECT.
Consultar la vista mediante la instrucción SELECT.
LPDAIE
Modificar los datos de la tabla mediante la instrucción UPDATE. Nota: puede concederse el privilegio SELECT junto con el privilegio
Modificar
una tabla.
:n disponif es un pri-
rs sobre ei
1os datos de la
vista mediante la
instrucción UPDAIE.
IIPDAIE.
ar un clús-
]LUSTER tenidos en ea propieón WITH
Privilegios disponibles para este t¡po de objeto
cnceder ei :de usar e i
¡ios sobre
Nombre de la tabla
rede conh:
Privilegios seleccionados
Ina nomios prir i;tant, que rles y un s
privile-
:eder
1os
Figura 19.10. Asignación de los privilegios Insert, Select y Update al rol Assistant sobre la tabla PropertyForRent.
512
Sistemas de bases de datos
19.5 Seguridad de un SGBD en entornos web En el Capítulo 29 proporcionamos una panorámica general de los SGBD en la Web. En esta sección vamos a centrarnos en cómo dotar de seguridad a un SGBD en un entomo web. Los lectores que no estén familiarizados con los términos y tecnologías asociados con los SGBD en entomos web pueden leer el Capítulo 29 antes de abordar esta sección. Las comunicaciones a través de Intemet utilizan TCP/P como protocolo subyacente. Sin embargo, TCP/IP y HTTP no fueron visionados teniendo presentes los temas de seguridad. Si no se utiliza un software especial, todo el tráfico Internet viaja'en claro'y cualquiera puede monitonzar el tráfico y leerlo. Esta forma de ataque es relativamente fácil de llevar a cabo utilizando un software de monitorización de paquetes fácilmente disponibles, ya que Intemet ha sido tradicionalmente una red muy abierta. Considere, por ejemplo, las implicaciones que tendría que ios números de las tarjetas de crédito fueran interceptados por personas de intenciones dudosas durante la transrnisión, cuando los clientes utilizan sus tarjetas para comprar productos a través de Internet. El desafio consiste en poder transmitir y recibir información a través de Intemet al misrno tiempo que se garantiza que:
I I I r I
a 1a solicitud dos propósito
Mejorar
e
Puesto que un
po, puede me los usuarios A página r ''ierta servidor web < ria caché y qu, misma red que
ejemplo los en
Filtrado
dr
Los servidores
esa
información es inaccesible para todo el mundo salvo para el transmisor y el receptor (confidencialidad);
puede utilizar
la información no ha sido modiñcada durante la transmisión (integridad);
19.5.2
r
C
el receptor puede estar seguro de que la infonnación proviene del transmisor (autenticidad); el transmisor puede estar seguro de que el receptor es el adecuado (no simulación); el transmisor no puede posteriomente negar que ha enviado ia información (no repudio).
Sin embargo, la protección de la transacción sólo resuelve una parte del problema . Una vez que la información ha alcanzado el servidor web, también es preciso protegerla allí. Con las arquitecturas en tres niveles que tan populares son en los entomos web, tenemos además la complejidad de garantizar un acceso seguro a la base de datos. Hoy en día, las distintas partes que componen dichas arquitecturas pueden ser dotadas de seguridad, pero eso requiere generalmente utilizar diferentes productos y mecanismos. Otro aspecto relacionado con la seguridad que es preciso tener en cuenta en los entomos web es que la información transmitida a la máquina del cliente puede incluir contenido ejecutable. Por ejemplo, las páginas HTML pueden contener controles ActiveX, JavaScript/VBScript yio lna o más applets Java. El código ejecutable puede realizar las siguientes acciones rnaliciosas, por lo que habrá que tomar medidas para prevenirlas:
I I I r r
corromper los datos o el estado de ejecución de los programas;
r I
bloquear recursos haciendo que no estén disponibles para los usuarios y programas legítimos;
El consejo hab; con ninguna de
mevitables atac
acceder a la bas autorizados, sie
Un cortafur
da. Los cortafu ambos. Frecuen redes privadas
r
mecanisr:
Además,
apagar el sistema totalmente;
utiliza pa
recopilar y enviar hacia otro sitio lntemet datos confidenciales tales como archivos o contraseñas;
provocar efectos no fatales pero indeseables, especiaimente en los dispositivos de salida.
En las secciones anteriores hemos identificados los mecanismos de seguridad generales para los sistemas de base de datos. Sin embargo, la disponibilidad cada vez mayor de bases de datos en Ia red lntemet pública y en las redes intranet privadas requiere un reanálisis y una extensión de estas técnicas. En esta sección vamos a analizar algunos de los problemas asociados con la seguridad de las bases de datos en estos entornos.
Filtrado ta o rech
reformatear el disco compieto;
usurpar la identidad de un usuario o del sistema de un usuario y hacerse pasar por él para atacar otros objetivos en la red;
c
la intranet pasat los criterios de ¡
mensajes conftanza
I
Pasarela cas, comc
degradar.
f
Pasarela
ce una col
intercamb
I
Servidor, ta las verci
19.5.1 Servidores proxy
En la práctica deran como una
En un entomo web, un servidor proxy es una computadora situada entre un explorador web y un servidor web. El proxy intercepta todas las solicitudes dirigidas al servidor web con el t'in de determinar si puede responder
¡
erado de seguridr tado en la Secciót
Gapítulo 19 Seguridad 513
¡ la solicitud por
sí mismo. Si no es así, reenvía las solicitudes al servidor web. Los servidores proxy tienen Jos propósitos principales: mejorar el rendimiento y filtrar las solicitudes.
)cción vamos
a
én familiariza-
pítulo 29 antes rbargo, TCP/lP tware especial.
forma de ata:tes fácilmen¡e r
rplo,las impliintencioluctos a través I mismo tiemas de
:
(confidencia-
Mejorar el rendimiento Puesto que un servidor proxy guarda los resultados de todas las solicitudes durante un cierto periodo de tiem-
:o, puede mejorar significativamente las prestaciones para una serie de usuarios. Por ejemplo, suponga que .os usuarios A y B acceden a la Web a través de un servidor proxy. En primer lugar, el usuario A solicita una ;ierta página web y, poco después, el usuario B solicita la misma página. En lugar de reenviar la solicitud al oervidor web donde esa página reside, el servidor proxy simplemente devuelve la página que tiene en memoia caché y que ya había cargado para el usuario A. Puesto que el servidor proxy se encuentra a menudo en la misma red que el usuario, se trata de una respuesta mucho más rápida. Los servidores proxy reales, como por :jemplo los empleados por Compuserve y America Online, pueden dar soporte a miles de usuarios.
Filtrado de las solicitudes Los servidores proxy también pueden utilizarse para filtrar las solicitudes. Por ejemplo, una organización puede utilizar un servidor proxy para evitar que sus empleados accedan a conjuntos específicos de sitios web.
19.5,2 Cortafuegos tad);
El consejo habitual en términos de seguridad es el de garanfízar que los servidores web no estén conectados con ninguna de las redes intemas y que se realicen regularmente copias de seguridad para recuperarse de los r).
z que la inforen tres niveles )ceso seguro a ser dotadas de
web es que la lo, las páginas código ejecu:a prevenirlas:
:.nevitables ataques. Cuando el servidor web tenga que estar conectado a una red intema, por ejemplo para ¿cceder a la base de datos de la empresa, la tecnología de cortafuegos puede ayudar a prevenir los accesos no autorizados, siempre que se haya instalado y mantenido correctamente el cortafuegos. Un cortafuegos es un sistema diseñado para impedir el acceso no autorizado hacia o desde una red privada. Los cortafuegos pueden implementarse tanto en hardware como en software, o en una combinación de ambos. Frecuentemente se los utiliza para impedir que los usuarios de lntemet no autorizados accedan a las redes privadas conectadas a Intemet, especialmente a las intranet. Todos los mensajes que entran o salen de ia intranet pasan a través del cortafuegos, que examinará cada mensaje y bloqueará aquellos que no cumplan Los criterios de seguridad especificados. Hay diversos tipos de técnicas cortafuegos:
I
Filtrado de paquetes, mediante el que se examina cada paquete que entra o sale de la red y se acepfa o rechaza basándose en una serie de reglas def,rnidas por el usuario. El filtrado de paquetes es un mecanismo bastante efectivo y transparente a los usuarios, aunque puede ser dificil de configurar. Además, es vulnerable a los mecanismos de suplantación IP. La suplantación lP es una técnica que se utiliza paru obtener acceso no autorizado a sistemas informáticos y mediante la cual el intruso envía mensajes a una computadora con una dirección IP que indica que el mensaje proviene de un puerto de
I
Pasarela de aplicación, mediante la que se aplican mecanismos de seguridad a aplicaciones específlrcas, como por ejemplo los servidores FTP y Telnet. Se trata de un mecanismo muy efectivo, pero puede
ntraseñas; 'a atacar otros
conftanza.
imos;
degradar las prestaciones.
los sistema-. temet pública
I
Pasarela de nivel de circuito, mediante el que se aplican mecanismos de seguridad cuando se establece una conexión TCP o UDP (User Datagram Protocol) . Una vez hecha la conexión, los hosts pueden intercambiar paquetes sin necesidad de efectuar comprobaciones adicionales.
I
Servidor proxy, que intercepta todos los mensajes que entran y salen de la red. El servidor proxy oculta las verdaderas direcciones de red.
e
ección vamos ntornos.
servidor web. :de responder
En la práctica, muchos cortafuegos proporcionan más de una de estas técnicas. Los cortafuegos se consideran como una primera línea de defensa parala protección de la información privada. Para obtener un mayor grado de seguridad, los datos pueden cifrarse, como se explica más adelante y como también hemos comentado en la Sección 19.2.6.
514
Sistemas de bases de datos
19.5.3 Algoritmos de compendio de mensa¡es y firmas digitales
proporcion de datos, lr en servidor de
identificar
(el compendio o hash). Un
combinacii
debe ser imposible desde el punto de vista de la capacidad de proceso encontrar otro mensaje que gene-
19.5.6
Un algoritmo de compendio de mensaje, o función hash unidireccional, toma como entrada una cadena caracteres de tamaño arbitrario (el mensaje) y genera una cadena de longirud compendio tiene las siguientes características:
I
f¡a
re el mismo compendio;
I
Muchos der colo de cifr
el compendio no revela ninguna información irtil acerca del mensaje original.
Una firma digital está compuesta de dos fragmentos de información: una cadena de bits que se calcula a partir de los datos que están siendo 'firmados', junto con la clave privada de ia persona u organización que está efectuando la firma. La firma puede utilizarse para verif,rcar que los datos provienen de dicha persona u organización. Al igual que una firma manuscrita, las firmas digitales tienen muchas propiedades útiles:
r I I
su autenticidad puede verificarse, utiiizando un cálcuio basado en ]a correspondencia de clave pública;
no puede falsificarse (suponiendo que la clave privada se mantiene en secreto); es una
función de los datos firmados y nadie puede sostener que dicha firma corresponda
a
ningún otro
bloque de datos;
I
los datos firmados no pueden modificarse, ya que entonces la firma dejaría de permitir verificar que los datos son auténticos.
Algunos algoritmos de firma digital utilizan algoritmos de cornpendio de mensaje como parte de sus cálcnlos; otros, en aras a Ia eficiencia, calculan el compendio del mensaje y firman dicho compendio en lugar de tinnar el propio mensaje.
19.5.4 Gertificados digitales Un certilrcado digital es un adjunto que se añade a un rnensaje electrónico y que se utrlizapara propósitos de seguridad, normalmente para verificar que el usuario que envía el mensaje es quien dice ser y para proporcionar al receptor un mecanismo con el que codificar su respuesta. Una persona que desee enviar un mensaje cifrado tiene que solicitar un cefiñcado digital a una autoridad de certificación (AC). La AC emitirá un certificado digital cifrado que contendrá Ia clave pública del solicitante y otras inforrnaciones de identificación. La AC pone a disposición de todo el mundo su propia clave pública, distribuyendo la información impresa o a través de Intemet. El receptor de un mensaje privado utiliza la clave pública de la AC para decodit-rcar el certificado digital adjunto al mensaje, verifica que el mensaje ha sido emitido por Ia AC y a continuación obtiene la clave pirbhca del emisor y la información de identificación almacenada en el certificado. Con esta información, el receptor puede enviar una respuesta cifrada. Obviamente, el papel de la AC dentro de este proceso es crítico, ya que actúa como intennediario entre las dos parles. En una red compieja distribuida y de gran tamaño, como Internet, este organismo independiente mediante el cual una autoridad de confianza actúa como intermediario es absolutamente imprescindible, ya que los clientes y servidores pueden no tener una relación de conf,ianza mutua y, a pesar de ello, desear mantener una sesión de comunicación segura. Puesto que ambas pafies confían en la AC y puesto que ésta se encarga de garanfrzar la identidad de cada una de las partes firmando sus certificados, las dos partes pueden conñar la una en la otra de forma implícita. El estándar más ampliamente utilizado para certificados digitales es X.509.
19.5.5 Kerberos r-rn servidor de nombres de usuario y contraseñas segLlros (recibe este nombre por el monstruo de tres cabezas de la mitología griega que guardaba las puertas dei infierno). La importancia de Kerberos es que
Kerberos es
documento¡ que se trans SSL y otros por ejemplo
aplicación
c
la modificac nivel de apl;
Otro pro
versión mot Technologie
ra entre un
S-HTTP
I
esrr
rarse, por ta enviados a II páginas web radores y ser Básicame
autentiquen
I
criptográficar
I I
permii permir
cios
r
cr
permil explor maciót
I
garant.
puedar
Un compo
es el certificar
protocolos cot
1e.5.7
i
El protocolo S to de transacci te por Netscap permitir que la en cualquier
c«
vendedor tiene
Capítulo
19 Seguridad
515
rs/¡). L--
1.'rporciona un servidor de seguridad centralizado para todos los datos y recursos de la red. El acceso a la base = datos, los inicios de sesión, el control de autorización y otras funciones de seguridad están centralizados :: servidores Kerberos de confianza. Kerberos tiene una función similar a la de un servidor de certif,rcados: ;entificar y validar a los usuarios. Las empresas de seguridad están actualmente investigando en la posible :,-rmbinación de los servidores Kerberos y de certificados, con el fin de proporcionar sistemas de red seguros.
¡e gese-
19.5.6 Secure Sockets Layer y Secure HTTP
dena
--=
*,fuchos desarrolladores importantes de productos Internet se han puesto de acuerdo para utilizar un proto:-.lo de cifrado denominado Secure Sockets Layer (SSL), desarrollado por Netscape, parala transmisión de
alcui¿ ¡ :ión ql.; :rsona :S:
púbiic: sún os.
:.rcumentos privados a través de trntemet. SSL funciona utilizando una clave privada para cifrar los datos transfieren a través de la conexión SSL. Tanto Netscape Navigator como Intemet Explorer soportan >SL y otros sitios web utilizan este protocolo para obtener información confidencial de los usuarios, como rrr ejemplo los números de ta{eta de crédito. El protocolo, que está situado entre los protocolos de nivel de ,¡licación como HTTP y el protocolo de nivel de transporte TCP/IP, está diseñado para evitar las escuchas, . modificación de mensajes y su falsificación. Puesto que SSL se encuentra por debajo de los protocolos de ..rr el de aplicación, se puede utilizar para otros protocolos de nivel de aplicación tales como FTP y NNTP. Otro protocolo para la transmisión de datos seguros a través de Ia Web es Secure HTTP (S-HTTP), una :--¡e se
"
icar qu; SUS u'3--
luear Li.
isitos d.
ersión modificada del protocolo HTTP estándar. S-HTTP fue desarrollado por Enterprise Integration
-echnologies (EIT), que fue adquirida por Verifone, Inc. en 1995. Mientras que SSL crea una conexión segur? entre un cliente y un servidor a través de la cual se puede enviar cualquier cantidad de datos seguros, >HTTP está diseñada para transmitir con seguridad mensajes individuales. SSL y S-HTTP pueden conside::rse, por tanto, como tecnologías complementarias, más que competidoras. Ambos protocolos han sido :lviados a IETF (Intemet Engineering Task Force) para que sean aprobados como estándar. Por convenio, las laglnas web que requieren una conexión SSL comienzan con https: en lugar de con http:. No todos los exploy servidores web soportan SSL/S-HTTP. =dores Básicamente, estos protocolos permiten que el explorador y el servidor se autentiquen mútuamente y :utentiquen también la información segura que puedan posteriormente intercambiarse. Mediante técnicas iptográflrcas tales como el cifrado y las hrmas digitales, estos protocolos:
oporcic-
utorid:.;
:l solic,ria clar o
digi*-
e
púbi:-
:l recep entre l¿.
I I
permiten a los exploradores y servidores web autenticarse mutuamente;
I
permiten compartir información confidencial (por ejemplo, números de tarjetas de crédito) entre el explorador y el servidor, al mismo tiempo que se garantiza que nadie más pueda acceder a esa información;
I
garanfizan que los datos intercambiados entre el explorador y el servidor sean fiables, es decir, que no puedan corromperse de forma accidental ni deliberada, sin que esa comrpción sea detectada.
permiten a los propietarios de sitios web controlar el acceso a servidores, directorios, archivos o servicios concretos;
Un componente clave en el establecimiento de sesiones web seguras mediante el protocolo SSL o S-HTTP el certificado digital, del que hemos hablado anteriormente. Sin certificados auténticos y de confianza, los protocolos como SSL y S-HTTP no ofrecen ningún tipo de seguridad.
:ndien:. iible. r
es
:ar matr: ésta st
79.5.7 Secure Electronic Transact¡ons y Secure Transaction
"
puede: ligitales
struo de s es quü
Technology Ei protocolo Secure Electronic Transactions (SET) es un estándar abierto e interoperable para el procesamiento de transacciones basadas en tarjetas de crédito a través de Internet; dicho estándar fue creado conjuntamenie por Netscape, Microsoft, Visa, Mastercard, CTE, SAIC, Terisa Systems y VeriSign. El objetivo de SET es permitir que las transacciones basadas en tarjeta de crédito sean tan simples y seguras en Internet como lo son en cualquier comercio. Para resolver los problemas de privacidad, la transacción se divide de tal forma que el vendedor tiene acceso a la información acerca de lo que está siendo comprado, cuánto cuesta y si el pago está
516
Sistemas de bases de datos
aprobado, pero no puede acceder a ninguna información sobre el método de pago que el cliente esté utilizando. De la misma forma, el emisor de la tarjeta (por ejemplo, Visa) tiene acceso al precio de compra, pero no puede acceder a ninguna infonnación sobre el tipo de producto o servicio que está siendo adquirido. SET utiliza ampliamente el mecanismo de certificados, tanto para cerlificar a la persona poseedora de la tarjeta como para certificar que el vendedor tiene una relación con la institución ñnanciera. El mecanismo se ilustra en la Figura 19.11. Aunque tanto Microsoft corno Visa International participan activamente en las especiflcaciones SET, actualmente proporciona tarnbién el protocolo Secure Transaction Technology (STT), que tarnbién ha sido diseñado para gestionar pagos bancarios de manera segura a través de lntemet. STT utiliza DES para el cifrado de información, RSA para el cifrado de la información de 1a tarjeta de crédito y algoritmos de autenticación fuerte de todos aquellos que intervienen en la transacción.
dos de las Finaliza¡emr
El cargar :1 cargador
«
:o correcto, c
:ación un eq :grupar las c
iue una clasr
19.5.8 Seguridad Java
:lás protegid .T:r'a local, n< ,¡cal. Una m
En la Sección 29.8 se presenta el ienguaje Java como un lenguaje de importancia cada vez mayor para el desarrollo web. Los lectores qLle no estén farniliarizados con Java pueden leer la Sección 29.8 antes de abor-
:¿da uno con =3lmente prc
dar esta sección. Java fue diseñado teniendo presentes las necesidades de seguridad; se utiliza lo qtre se denomina un entorno seguro 'sandbox' para garantizar que las aplicaciones no autorizadas y posiblemente maliciosas no puedan acceder a los recursos del sistema. Para implementar este entorno seguro se utilizan tres componentes: un cargador de clases, un verificador de código intermedio (bytecode) y Lln gestor de seguridad. Las características de seguridad están proporcionadas tanto por el lenguaje Java como por la máquina virtual Java (JVM, Java Virtual Machine) y el compilador y el entorno de ejecución se encargan de imponer dichas medidas de seguridad. Dos de las características de seguridad del lenguaje Java están relacionadas con el sistema de tipos de datos fr"rerte y con los mecanismos de recolección automática de memoria. En esta sección vamos a examinar otras
:endada por -'"'.
-:ermite a los --; de seguri<
El verificr r-:res de que
-:a
Vendedor
:.riostrador
r I I
6. El cliente obtiene el producto o servic¡o y un recibo.
5. El banco autoriza al vendedor y firma la transacción.
la informac¡ón de autor¡zac¡ón. El banco puede desc¡frarla y comprobar el número de la tarjeta de crédito. También puede comprobar la firma mediante un certilicado.
8. El vendedor recibe el pago de acuerdo con el contrato que
debe ser r
.,-iar ia segur
Cómo funciona SET Secure Electronic Transactions 1. El cl¡ente ¡nicia la transacción enviando el formulario de pedido y una autorización firmada y cifrada. El vendedor no puede acceder al número de la tarjeta de créd¡to, porque éste está cifrado
a. Sin emt
d
et códif las pilar
nosep. que las
I r
las instr todos lc
EI gestor r . política de l:,:.oradOr Wet --' de estas a1
¡-trlfle
Java co
-::Lr expiorad(
:;.;ión 4. El emisor de la tarjeta autoriza y firma la transacción.
¿r-eS
I
9. El cliente recibe la factura mensual enviada por el emisor dé Ia
|
descarg
leer y es cenar da den envi
rcalizar
t
pilados. parámerr
Em¡sor de la tarjeta
Figura 19.11. Una transacción SET.
en tien
.- '--iten operac
I
iniciar
or
Capítulo 19 Seguridad 517 z.a*O
OL.)
el cargador de clases y el verificador de código intermedio. Finalizaremos esta sección dedicada a la seguridad Java examinando el gestor de seguridad JVM.
dos de las características de seguridad:
le ia
El cargador de clases
ro se
El cargador de clases, además de cargar cada una de las clases requeridas y comprobar que está en el formato correcto, comprueba que la aplicación/applet no viole la seguridad del sistema, para lo cual asigna a la apli cación tn espacio de nombre. Los espacio de nombres son jerárquicos y permiten a la máquina virtual Java agrupar las clases dependiendo de cuál es su origen (local o remoto). Un cargado de clases no permite nunca que una clase de un espacio de nombres 'menos protegido' sustituya a otra clase de otro espacio de nombres más protegido. De esta forma, las primitivas de E/S del sistema de archivos, que están definidas en una clase Java local, no pueden invocarse ni sobreescribirse mediante clases que tengan su origen fuera de la máquina
speque
iliz¿ t)f]i-
ra ei ,bor1[r-rl-
¡der C¿fi-ULC'
Jal ¿
la¿s§
)trE-.
local. Una máquina virtual Java permite que estén activos múltiples cargadores de clases simultáneamente, cada uno con su propio espacio de nombres. Puesto que los exploradores y las aplicaciones Java pueden normalmente proporcionar su propio cargador de clases, aunque éste siempre estará basado en un plantilla recomendada por Sun Microsystems, esta característica podría parecer una debilidad del modelo de seguridad Java. Sin embargo, algunos expertos argumentan que se trata en realidad de una fortaleza dd lenguaje, que permite a los administradores del sistema impiementar sus propias (y presumiblemente más estrictas) medidas de seguridad.
El verificador de código intermedio Antes de que la máquina virtual Java permita que se ejecute una aplicacióniapplet, el código que compone ésta debe ser verif,rcado. El verificador asume que cualquier código puede hacer que el sistema falle o puede violar la seguridad del sistema, así que realíza una serie de comprobaciones, incluyendo la ejecución de un demostrador de teoremas, para garantizar que esto no sea así. Las comprobaciones típicas incluyen verificar que;
r I I I I
el código compilado está correctamente formateado; las pilas de ejecución intemas no se desbordan
ni subdesbordan;
no se producen conversiones 'legales' de los datos (por ejemplo, de entero a pwrtero); esto garantiza que las variables no puedan acceder a las áreas de memoria restringidas; las instrucciones del código intermedio tienen los tipos de datos apropiados; todos 1os accesos a miembros de clases son válidos.
El gestor de seguridad La política de seguridad de Java es específica de la aplicación. Una aplicación Java, como por ejernplo un explorador web con soporte Java o un servidor web, dehne e implementa su propia política de seguridad. Cada una de estas aplicaciones implementan también su propio gestor de seguridad. Todo explorador web que soporte Java contiene su propia applet gestora de seguridad (Security Manager) y las applets descargadas por dióho explorador estarán sujetas a las políticas que el gestor marque. Generalmente, el gestor tealiza una verif,rcación en tiempo de ejecución en busca de métodos potencialmente 'peligrosos', es decir, no todos los que soliciten operaciones de E/S, acceso a red o que traten de def,rnir un nuevo cargador de clases. En general, las applets descargadas no pueden:
I I I
leer y escribir archivos en el sistema de archivos del cliente. Esto también impide a las applets almacenar datos persistentes (por ejemplo, una base de datos) en el lado del cliente, aunque los datos pueden enviarse de vuelta al host para su almacenamiento; realízar conexiones de red con máquinas distintas del host que proporciona los archivos '.class'compilados. Dicho host de origen es aquel del que proviene la página HTML o el host especificado en el parámetro CODEBASE del marcador del applet, teniendo CODEBASE precedencia;
iniciar otros programas en el cliente;
51a I r
Sistemas de bases de datos
f
cargar bibliotecas;
definir llamadas a rnétodos. Permitir a un applet definir llamadas a métodos nativos proporcionaría al applet acceso directo al sistema operativo subyacente.
Estas restricciones se aplican a las applets descargadas a través de la Intemet pública o de la intranet de la empresa. Sin embargo, no se aplican a las applets contenidas en el disco local del cliente, dentro de un directorio que forme parte de la ruta CLASSPATH del cliente. Las applets locales son cargadas por el cargador del sistema de archivos y, además de poder leer y escribir archivos, pueden salir de la máquina virtr¡al y no pasan a lravés del codificador de código intermedio. El visualizar Appletviewer del sistema de desarrollo JDK (Java Developurent Kit) también rebaja en cierto modo estas restricciones, dejando que ei usuario defina una lista
ción, lor
I
es quién
I
estándar
también
(MAC, modific¿ una clas imponié: usuarios
otras no. Las applets Java cargadas desde ciertas zonas pueden leer y escribir en archivos situados en el disco duro del cliente. Las zonas para las cuales es esto posible son seleccionables mediante el Administrador de red.
I
fir-
19.5.9 Seguridad ActiveX El modelo de seguridad ActiveX es considerablemente distinto del de las applets Java. Java consigue imponer los mecanismos de seguridad restringiendo el comportamiento de las applets y limitándolo a un conjunto de instrucciones. ActiveX, por el contrario, no impone ninguna restricción a lo que un control puede hacer. En lugar de ello, cada control ActiveX puede estar firrnado digitalmente por su autor, utilizando un sisterna denominado Authenticodet'. Las finnas digitales son certiñcadas a continuación por una autoridad de certificación (AC). Este modelo de seguridad sitúa la responsabilidad de la seguridad del sistema en manos del usuario. Antes de que el explorador descargue un controlador ActiveX que no haya sido firmado o no esté certiñcado por una AC conocida, se presentará un cuadro de diálogo advirtiendo al usuario de que dicha acción puede no ser segura. El usuario puede entonces abortar la transferencia o continuar y aceptar las con-
Una vist base, cor
El modelo de entomo seguro fue introducido con la prirnera versión de la API Java para applets en enero de 1996. Aunque este rnodelo protege con carácter general a los sistemas frente a código no fiable obtenido de la red, no contempia otros muchos problemas de seguridad y confidencialidad. Se necesitan mecanismos rnada digitalmente y autenticada, se la puede conceder el estatus de applet de confianza, permitiéndosela entonces ejecutarse con menos restricciones de segundad. La API de seguridad de Java, disponible en JDK l.l, contiene interfaces de programación de aplicaciones para t-rmas digitales, compendios de mensajes, gestión de claves y cifrado/descifrado (con sujeción a las regr,rlaciones de control de exportación de Estados Unidos). Actuaimente se está trabajando para definir una infraestructura que permita disponer de políticas de seguridad flexibles para las applets firmadas.
La mayr
cional (
zay
de autenticación para garantízar que un applet proviene de donde dice provenir. Además, si un applet está
La auto
teauns
explícita de archivos a los que las applets descargadas pueden acceder. De forma similar, el explorador lnternet Explorer 4.0 de Microsoft introdujo el concepto de 'zonas', pudiendo algunas zonas ser de confian-
Seguridad avanzada para las applets
Entre lo mos de
la base c mo de vi a ojos de
I
Los mec datos y miento
d
f
almacent
de maner
I
Las restt datos, in
inducir
r
legibles
I
a
El cifrad
¡
Microso:
ma y seg de datos,
utilizarse
I
Las medi
fuegos, a Sockets
Transacti
secuencias.
Resumen del capítulo T La seguridad de la base de datos son los mecanisrnos que protegen a Ia base de datos tiente a amenazas intencionadas o accidentales.
I
¡
La seguridad de la base de datos se ocupa de evitar las siguientes situaciones: robo y fraude, pérdida de confidencialidad, pérdida de privacidad, pérdida de integridad y pérdida de disponibilidad. Una amenaza es cualquier situación o suceso, intencionado o accidental, que pueda afectar adversamente al sistema y, consecllentemente, ala organización.
Cuestione
19.1. Expli, 19.2. Indiqr
ba, pa
19.3. Explir
(a)
a
(b) c (c) \
Gapítulo 19 Seguridad 519 Entre los controles de seguridad informatizados para un entomo multiusuario se incluyen: los mecanismos de autorización, los controles de acceso, las vistas, los sistemas de copia de seguridad y de recuperación, los mecanismos de integridad, los sistemas de cifrado y la tecnología RAID.
)porcionaría al
La autorización es la concesión de un derecho o privilegio que permite a un sujeto acceder legítimamente a un sistema o a un objeto del sistema. La autenticación es un mecanismo que determina si un usuario es quién dice ser.
¡ intranet de la
'o de un direcll cargador del ual y no pasan
La mayoría de los SGBD comerciales proporcionan un mecanismo denominado control de acceso discrecional (DAC, Discretionary Access Control), que gestiona los privilegios utilizando lenguaje SQL. El estándar SQL sopofa DAC mediante los comandos GRANT y REVOKE. Algunos SGBD comerciales
rllo JDK (Java efina una lista
también proporcionan otra técnica de control de acceso denominada control de acceso obligatorio (MAC, Mandatory Access Control), qu.e está basada en políticas de nivel de sistema que no pueden ser
el explorador er de confiansituados en ei A,dministrador
ts en enero de e obtenido de r rnecanismos rpplet está tirrnnitiéndosela
modificadas por los usuarios individuales. Con esta técnica, a cada objeto de la base de datos se le asigna una clase de segtridad y a cada usuario se le asigna un nivel de seguridad para cada clase de seguridad, imponiéndose una serie de reglas para la lectura y escritura de objetos de la base de datos por parte de sus usuarios. El estándar SQL no incluye soporte para MAC. Una vista es un resultado dinámico de una o más operaciones relacionales sobre una serie de operaciones base, con el fin de producir otra relación. Una vista es una relación virtual que no existe en realidad en la base de datos, sino que se genera cadavez que un usuario concreto efectúa una solicitud. El mecanismo de vistas constituye wr sistema de seguridad potente y flexible para ocultar partes de la base de datos a ojos de ciertos usuarios.
I
Los mecanismos copias de seguridad son el proceso de realizar periódicamente una copia de la base de datos y del archivo de regisffo (y posiblemente de los programas) y almacenarla en soportes de almacenamiento fuera de línea. El registro es el proceso de mantener un archivo de registro (o diario) donde se almacenen todos los cambios realizados en la base de datos, con el fin de permitir realizar la recuperación de manera efectiva en caso de fallo.
I
Las restricciones de integridad también contribuyen a mantener la seguridad de un sistema de base de datos, impidiendo que los datos lleguen a ser inválidos y generen resultados incorrectos o que puedan inducir a enor.
aplicaciones ión a las reguo
'a definir
r.rn¿
1S.
El cifrado es la codificación de los datos mediante un algoritmo especial que hace que los datos no sean )nslgue impoI a un conjun-
legibles por parte de ningún programa que no disponga de la clave de descifrado.
I puede hacer.
ma y seguridad de los datos. La seguridad del sistema permite establecer una contraseña para abrir la base de datos, mientras que la seguridad de los datos proporciona una seguridad de nivel de usuario que puede utilizarse para limitar las partes de una base de datos que un usuario puede leer y actualizat
Jo un sisteme lridad de ceren manos dei ado o no este de que dich;. eptar las con-
Microsoft Office Access y Oracle proporcionan dos tipos de medidas de seguridad: seguridad del siste-
I
Las medidas de seguridad asociadas con los SGBD en entornos web incluyen: servidores proxy, cortafuegos, algoritmos de compendio de mensajes y firmas digitales, certificados digitales, Kerberos, Secrre
Sockets Layer (SSL)
y
Secure HTTP (S-HTTP), Secure Electronic Transactions (SET)
y
Secure
Transaction Technology (SST), seguridad Java y seguridad ActiveX.
Cuestiones de repaso
e a amenazas
19.1. Explique el propósito y el alcance de los mecanismos de seguridad en una base de datos. 19.2. Indique los tipos principales de amenazas que pueden afectar a nn sistema de base de datos y descri-
e, pérdida d=
ba,para cada uno de ellos, los controles que podrían utilizarse para prevenir cada una de ellas. 19.3. Explique los siguientes conceptos en términos de la seguridad de una base de datos:
adversamei-,-
(a) (b)
autorización;
(c)
vistas;
controles de acceso;
52O Sistemas de bases de datos (d) (e)
copias de seguridad y recuperación;
integridad;
(0 citiado; (g) tecnología RAID. 19.4. Describa
I9.5.
las medidas de seguridad proporcionadas por Microsoft Office Access y el SGBD de Oracle.
Describa las técnicas disponibles para dotar de seguridad a un SGBD en la Web.
Ejercicios 1,9.6. Examine
1os
SGBD utilizados por su organización e identifique las rnedidas de seguridad que propor-
cionen. 19.7
.
ldentifique los tipos de mecanismos de seguridad utilizados por su organizació¡ para dotar de seguridad a los SGBD accesibles a través de la Web.
19.8. Considere el caso
t9.9.
0bjetivo
de estudio de DrectmHome descrito en el Capítulo 10. Enumere las potenciales alne-
fiazas a las que tendría que enfrentarse y proponga contramedidas para prevenirlas.
En este
Considere el caso de estudio de Wellmeadows Hospital descrito en el Apéndice B.3. Enumere las potenciales amenazas a las que tendría que enfrentarse y proponga contramedidas para prevenirlas.
¡
r
Elp Elp
1 Laf r Las I Elsi I Cón: ! Cóm I Elsi I Cóm t Cóm r Cóm r Algu r Elpr I El pr, I Cómr I Mode I Cómc En el Capítu,
cionar. Entre base de datos
res; los serv deben mante:
mirltiples usu funciones.
Aunque c ia tanto un co las incoheren, ¡áneas en la b de datos pued ¡ocolo de con
Gestión de transacciones Objetivos del capítulo: En este capítulo aprenderá: •
El propósito del control de concurrencia.
•
El propósito de los mecanismos de recuperación.
•
La función y la importancia de las transacciones.
•
Las propiedades de una transacción.
•
El significado del concepto de serializabilidad y cómo se aplica el control de concurrencia.
•
Cómo pueden utilizarse los bloqueos para garantizar la serializabilidad.
•
Cómo funciona el protocolo de bloqueo en dos fases (2PL).
•
El significado del concepto de interbloqueo y cómo puede resolverse.
•
Cómo pueden usarse las marcas temporales para garantizar la serializabilidad.
•
Cómo funcionan las técnicas de control de concurrencia optimista.
•
Cómo pueden afectar los diferentes niveles de bloqueo a la concurrencia.
•
Algunas causas del fallo de una base de datos.
•
El propósito del archivo de registro de transacciones.
•
El propósito de los puntos de comprobación durante el registro de transacciones.
•
Cómo recuperar la base de datos después de un fallo.
•
Modelos alternativos para transacciones de larga duración.
•
Cómo gestiona Oracle el control de concurrencia y la recuperación.
En el Capítulo 2 hemos visto las funciones que un sistema de gestión de bases de datos (SGBD) debe proporcionar. Entre éstas se encuentran tres funciones estrechamente relacionadas que pretenden garantizar que la base de datos sea fiable y permanezca en une estado coherente; dichas funciones son el soporte de transacciones: los servicios de control de concurrencia y los servicios de recuperación. Esta fiabilidad y coherencia deben mantenerse en presencia de fallos tanto de los componentes hardware como software y mientras que múltiples usuarios tratan de acceder a la base de datos. En este capítulo vamos a concentramos en estas tres funciones. Aunque cada función puede ser analizada por separado, las tres son mutuamente dependientes. Se necesita tanto un control de concurrencia como mecanismos de recuperación para proteger la base de datos frente a las incoherencias y a la pérdida de datos. Muchos SGBD permiten a los usuarios realizar operaciones simultáneas en la base de datos. Si no se controlan estas operaciones, los accesos pueden interferir entre sí y la base de datosdepuede en un estado que no coherente. Paraacces6s resolyera la este problema, SGBD implementa un protocolo controlacabar de concurrencia evita que los base de datos elinterfieran unos con otros.
522 Sistemas de bases de datos Los mecanismos de recuperación de la base de datos constituyen el proceso de restaurar la base de datos al estado correcto después de un fallo. Dicho fallo puede ser el resultado de una parada catastrófica del sistema debido a errores del hardware o del software, a un fallo en el soporte físico de almacenamiento (por ejemplo, debido a un aterrizaje de cabezales de disco) o a un error del software en la aplicación, como por ejemplo un error lógico en e] programa que esté accediendo a la base de datos. También puede ser el resultado de una corrupción o destrucción de datos o de programas por parte de los administradores de] sistema o de los usuarios, corrupción o destrucción que pueden ser intencionadas o accidentales. Sea cual sea ]a causa de] fallo, el SGBD debe ser capaz de recuperarse de] mismo y de restaurar la base de datos a un estado coherente.
Estructura del capítulo Un concepto fundamental para la comprensión de los mecanismos de control de concurrencia y recuperación es la noción de transacción, que se describe en ]a Sección 20.1. En la Sección 20.2 se explican los mecanismos de contra] de concurrencia y se examinan los protocolos que pueden usarse para prevenir los conflictos. En la Sección 20.3 se explican los mecanismos de recuperación de la base de datos y se examinan las técnicas que pueden usarse para garantizar que ésta permanezca en un estado coherente en ausencia de fallos. En la Sección 20A se examinan otros modelos más avanzados de gestión de transacciones que se han propuesto para las transacciones de larga duración (esa larga duración puede ir desde horas hasta incluso meses); el desarrollo de dichas transacciones es incierto, por lo que algunas de las acciones no pueden ser previstas al principio. En la Sección 20.5 se examina el modo en que Oracle gestiona el control de concurrencia y la recuperación. En este capítulo vamos a considerar el soporte de transacciones, el control de concurrencia y la recuperación para un SGBD centralizado, es decir un SGBD compuesto por una única base de datos. Posteriormente, en el Capítulo 23, consideraremos estos servicios para un SGBD distribuido, es decir, un SGBD compuesto por múltiples bases de datos lógicamente relacionadas y distribuidas en una red.
20. 1 Soporte de transacciones Transacción
Una acción o serie de acciones llevada a cabo por un único usuario o por un programa de aplicación y que lee y actualiza el contenido de la base de datos.
Una transacción es una unidad lógica de trabajo de la base de datos. Puede tratarse de un programa completo, de una parte del programa o de un único comando (por ejemplo, el comando SQL INSERT o UPDATE) y puede implicar un número arbitrario de operaciones con la base de datos. En el contexto de las bases de datos, la ejecución de un programa de aplicación puede considerarse como una o más transacciones, teniendo lugar una serie de procesamiento s no relacionados con la base de datos entre una transacción y otra. Para ilustrar los conceptos relacionados con las transacciones, vamos a examinar dos relaciones correspondientes a la instancia de la base de datos de alquileres de DreamHome mostrada en la Figura 3.3: (staffNo,fName, IName, position, sex, 006, salary, branchNo) (DropertyNo,street, city,postcode, type, rooms, rent, ownerNo, staffNo,branchNo) Una tr~cción simple sobre esta base de datos consiste en actualizar el salario de un determinado empleado dado el número de empleado, x. A alto nivel, podemos escribir esta transacción como se muestra en ]a Figura 20.1 (a). En este capítulo denotaremos una operación de lectura o escritura de base de datos sobre el elemento de datos x mediante read(x) o write(x). Pueden añadirse cualificadores adicionales según sea necesario; por ejemplo, en la Figura 20.1(a) hemos utilizado la notación read(staffNo = x, salary) para indicar que queremos leer el elemento de datos salary para la tupla cuyo valor de clave principal es x. En este ejemplo, tenemos compuesta de base
Capítulo 20 Gestión de transacciones
read(staffNo= x, salary) salary= saJary* 1.1 write(staffNo= x, saJary)
(a)
523
delete(staffNo= x) forallPropertyForRent records,pno begin read(propertyNo= pno,staffNo) if (staffNo= x) then begin staffNo= newStaffNo write(propertyNo= pno,staffNo) end end (b)
Figura 20.1. Transacciones de ejemplo.
mas localizar todas las tuplas de PropertyForRent gestionadas por este empleado y reasignarlas a otro empleado distinto, por ejemplo a newStaffNo.Si no se hacen todas estas actualizaciones, se perdería la integridad referencial y la base de datos quedaría en un estado incoherente: habría inmuebles gestionados por empleados que ya no existen en la base de datos. Toda transacción debe transformar la base de datos llevándola de un estado coherente a otro, aunque se acepta que la coherencia se viole temporalmente mientras la transacción está teniendo lugar. Por ejemplo, durante la transacción de la Figura 20.1(b), puede haber algún momento en el que una tupla de PropertyForRent contenga el valor newStaffNoy otra todavía contenga el antiguo valor, x. Sin embargo, al final de la transacción, todas las tuplas necesarias deben tener el nuevo valor newStaffNo. Una transacción puede tener uno de dos resultados. Si se completa con éxito, decimos que la transacción se ha confirmado y la base de datos alcanzará un nuevo estado coherente. Por el contrario, si la transacción no se ejecuta con éxito, entonces la transacción se aborta. Si se aborta la transacción, será necesario restaurar la base de datos al estado coherente en el que se encontraba antes de que la transacción comenzara. Decimos en ese caso que la transacción se deshace. Las transacciones confirmadas no pueden abortarse. Si decidimos que la transacción confirmada era un error, deberemos realizar otra transacción de compensación para invertir los efectos de la transacción anterior (como se explica en la Sección 20A.2.). Por el contrario, una transacción abortada que sea deshecha puede volver a iniciarse posteriormente y, dependiendo de la causa del fallo, es posible que pueda ejecutarse y confirmarse en esa otra ocasión. El SGBD no tiene ninguna forma de saber qué actualizaciones hay que agrupar para formar una única transacción lógica. Por tanto, el SGBD debe proporcionar un método que permita al usuario indicar las fronteras de cada transacción. Muchos lenguajes de manipulación de datos incluyen las palabras clave BEGIN TRANSACTION, COMMIT y ROLLBACK (o sus equivalentes t) con el fin de auto limitar las transacciones. Si no se utilizan estos delimitadores, se considerará usualmente que todo el programa es una única transacción, y el SGBD se encargará de realizar automáticamente una operación de confirmación (COMMIT) cuando el programa termine correctamente o de deshacer la transacción (ROLLBACK) en caso contrario. La Figura 20.2 muestra el diagrama de transiciones de estados para una transacción. Observe que, además de los estados obvios ACTIVE (activa), COMMITTED (confirmada) y ABORTED (abortada), hay otros dos estados: •
PARTIALLY COMMITTED (parcialmente confirmada), que se produce después de ejecutar la instrucción final. En este punto, es posible que nos encontremos que la transacción ha violado la serializabilidad (véase la Sección 20.2) o que ha violado~na restricción y que sea los en datos consecuencia necesario abortar la transacción. Alternativamente, puede que de el integridad sistema falle y que actualizados por la transacción no sean escritos de forma segura en almacenamiento secundario. En tales casos, la transacción iría a un estado fallido (FAILED) y tendría que ser abortada. Si la transacción
t Conel estándarISOSQL,la palabraclaveBEGINTRANSACTlONestáimplícitaen la primerainstrucciónSQLde iniciación
de
524
Sistemas de bases de datos
PARTIALLY COMMITTED
COMMITTED
BEGIN_TRANSACTION
FAILED
Figura 20.2.
ABORTED
Diagrama de transición de estados para una transacción.
tiene éxito, las actualizaciones pueden escribirse con toda seguridad y la transacción puede pasar al estado COMMITTED. •
FAILED (fallida), que tiene lugar si no se puede confirmar la transacción o si la transacción se aborta mientras se encuentra en el estado ACTIVE, quizá debido a que el usuario aborta la transacción o porque el protocolo de control de concurrencia la aborta para garantizar la serializabilidad.
20.1.1
Propiedades de las transacciones
Hay una serie de propiedades que todas las transacciones deben poseer. Las cuatro propiedades básicas, denominadas propiedades ACID (por las iniciales inglesas) son, según (Haerder y Reuter, 1983): •
•
Atomicidad. La propiedad 'todo o nada'. Una transacción es una propiedad indivisible que o bien se realiza en su totalidad o no se realiza en absoluto. Es responsabilidad del sistema de recuperación del SGBD garantizar la atomicidad. Coherencia. Una transacción debe transformar la base de datos llevándola de un estado coherente a otro. Es responsabilidad tanto del SGBD como de los desarrolladores de aplicaciones garantizar la coherencia. El SGBD puede garantizar la coherencia imponiendo todas las restricciones que se hayan especificado en el esquema de la base de datos, como por ejemplo las restricciones empresariales y las restricciones de integridad. Sin embargo, esto por sí mismo no es suficiente para garantizar la coherencia. Por ejemplo, suponga que tenemos una transacción con la que se pretende transferir dinero de una cuenta bancaria a otra y que el programa comete un error en la lógica de la transacción, restando dinero de una cuenta e ingresándolo en otra cuenta errónea. En ese caso, la base de datos quedará en un estado no coherente. Sin embargo, el SGBD no sería responsable de esta incoherencia, al igual que tampoco tendría ninguna posibilidad de detectar el error.
•
Aislamiento. Las transacciones se ejecutan de forma independiente unas de otras. En otras palabras, los efectos parciales de las transacciones incompletas no deben ser visibles por parte de otras transacciones. Es responsabilidad del sub sistema de control de concurrencia garantizar el aislamiento.
•
Permanencia. Los efectos de una transacción completada con éxito (confirmada) se registran de modo permanente en la base de datos y no deben poder perderse debido a un fallo posterior. Es responsabilidad del subsistema de recuperación garantizar la permanencia.
El nombre en inglés de estas propiedades es Atomicity, Consistency, Isolation, Durability; de ahí el nombre de propiedades ACID. ~
20.1.2 Arquitectura de la base de datos En el Capítulo 2 hemos presentado la arquitectura de un SGBD típico. La Figura 20.3 representa un extracto de la Figura 2.8 donde se identifican cuatro módulos de base de datos de alto nivel que se encargan de ges-
Capítulo 20 Gestión de transacciones
525
Base de datos y
catálogo del sistema
Figura 20.3. Subsistema de transacciones
de un SGBD.
tionar las transacciones, el control de concurrencia y la recuperación. El gestor de transacciones coordina las transacciones por cuenta de los programas de aplicación. Se comunica con el planificador (scheduler), que es el módulo responsable de implementar una estrategia concreta de control de concurrencia. Algunas veces se denomina al planificador gestor de bloqueos, si el protocolo de control de concurrencia está basado en bloqueos. El objetivo del planificador es maximizar la concurrencia sin dejar que las transacciones que se ejecutan de modo concurrente interfieran unas con otras, comprometiendo así la integridad o la coherencia de la base de datos. Si se produce un fallo durante la transacción, la base de datos podría llegar a ser incoherente. Es responsabilidad del gestor de recuperación garantizar que se restaure la base de datos al estado en que se encontraba antes del comienzo de la transacción, es decir, a un estado coherente. Finalmente, el gestor de búferes es responsable de la transferencia eficiente de datos entre el disco y la memoria principal.
20.2 Control de concurrencia En esta sección vamos a examinar los problemas que pueden producirse debido al acceso concurrente y las técnicas que pueden emplearse para evitar estos problemas. Comenzamos con la siguiente definición de control de concurrencia. Control de concurrencia
El proceso de gestionar una serie~operaciones de modo que éstas no interfieran unas con otras.
simultáneas en la base de datos
20.2.1 La necesidad del control de concurrencia Uno de los objetivos principales al desarrollar una base de datos es permitir que muchos usuarios puedan acceder de manera concurrente a una serie de datos compartidos. El acceso concurrente es relativamente sencillo si los usuarios se limitan a leer los datos, ya que no hay modo en ese caso de que puedan interferir unos con otros. Sin embargo, cuando dos o más usuarios tratan de acceder simultáneamente a la base de datos y al
526
Sistemas de bases de datos
menos uno de ellos está actualizando los datos, pueden producirse interferencias que den como resultado la aparición de incoherencias. Este objetivo es similar al de los sistemas informáticos multiusuario, que permiten que dos o más programas (o transacciones) se ejecuten al mismo tiempo. Por ejemplo, muchos sistemas tienen subsistemas de entrada/salida (E/S) que pueden gestionar de forma independiente las operaciones de E/S, mientras que la unidad central de proceso (VCP) principal realiza otras operaciones. Dichos sistemas pueden permitir que dos o más transacciones se ejecuten simultáneamente. El sistema comienza ejecutando la primera transacción hasta que alcanza una operación de E/S. Mientras que se realiza la E/S, la VCP suspende la primera transacción y ejecuta comandos correspondientes a la segunda transacción. Cuando la segunda transacción alcanza la operación de E/S, el control vuelve a la primera transacción y continúa con sus operaciones desde el punto en que fue suspendida. La primera transacción continuará hasta que vuelva a alcanzar otra operación de E/S. De esta forma, las operaciones de las dos transacciones están entrelazadas, con lo que se consigue una ejecución concurrente. Además, se mejora la tasa de procesamiento (la cantidad de trabajo que se lleva a cabo en un intervalo de tiempo determinado), ya que la VCP está ejecutando otras transacciones en lugar de quedarse en un estado inactivo mientras espera a que se completen las operaciones de E/S. Sin embargo, aunque las dos transacciones pueden ser perfectamente correctas en sí mismas, el entrelazado de las operaciones de esta forma puede producir un resultado incorrecto, poniendo en cuestión la integridad y la coherencia de la base de datos. Vamos a examinar tres ejemplos de problemas potenciales provocados por la concurrencia: el problema de la actualización perdida, el problema de la dependencia no confirmada y el problema del análisis incoherente. Para ilustrar estos problemas, vamos a utilizar un simple listado de cuentas bancarias que contiene el saldo de las cuentas de los empleados de DreamHome. En este contexto, estamos usando la transacción como unidad de control de concurrencia.
I
Ejemplo 20.1 El problema de la actualización
perdida
Vna operación de actualización que en apariencia haya sido completada con éxito por un usuario puede ser sobreescrita por otro usuario. Esto se conoce con el nombre de problema de la actualización perdida y se ilustra en la Figura 20A, en la que la transacción TI se ejecuta concurrente mente con la transacción T2. TI está extrayendo 10 euros de una cuenta cuyo saldo es bal" inicialmente 100 euros, mientras que T2 está depositando 100 euros en la misma cuenta. Si estas transacciones se ejecutan en serie, una después de la otra sin entrelazado de las operaciones, el saldo final será de 190 euros independientemente de qué transacción se realice primero. Suponga que las transacciones TI y T2 comienzan aproximadamente al mismo tiempo y que ambas leen que el saldo es igual a 100 euros. T2 incrementa balx en 100 euros, dando un total de 200 euros, y almacena el valor actualizado en la base de datos. Mientras tanto, la transacción TI decrementa su copia de balx en 10 euros, obteniéndose un resultado de 90 euros, y almacena este valor en la base de datos, sobreescribiendo la actualización anterior, por lo cual se 'pierden' los 100 euros previamente añadidos al saldo. La pérdida de la actualización de T2 se evita impidiendo que actualización correspondiente a T2 se haya llevado a cabo. Tiempo
10
cornrnit begin_transaction read(balx) commit write(balx) balx TI = balx T2 read(balx) write(balx) balx = balx + 100
TI
lea el valor de
balx
hasta que la
begin_~action 100 100 100 200
90 90
Figura 20.4.
El problema de la actualización
perdida.
Capítulo 20 Gestión de transacciones
I
Ejemplo 20.2 El problema de la dependencia
no confirmada
527
(o de la lectura sucia)
El problema de la dependencia no confirmada se produce cuando se permite a una transacción ver los resultados intermedios de otra transacción antes de que ésta haya sido confirmada. La Figura 20.5 muestra un ejemplo de dependencia no confirmada que provoca un error, utilizando el mismo valor inicial del saldo balx que en el ejemplo anterior. Aquí, la transacción T4 actualiza balx asignándose el valor de 200 euros, pero aborta la transacción, de modo que balx debe restaurarse a su valor original de 100 euros. Sin embargo, llegados a este punto, la transacción T3 ya ha leído el nuevo valor de balx (200 euros) y está usando este valor como base para restar los 10 euros, 10 que da un nuevo saldo incorrecto de 190 euros, en lugar de 90 euros. El valor de balx leído por T3 se denomina datos sucios, lo que da lugar al nombre alternativo de este problema, el problema de la lectura sucia. La razón por la que se produce la anulación de la transacción no es importante; puede que se produjera un error durante la transacción, por ejemplo debido a que se ha ingresado el dinero en la cuenta incorrecta. El efecto se debe a la suposición realizada por T3 de que la actualización de T4 sería completada con éxito, a pesar de que la actualización fuera subsiguientemente deshecha. Este problema se evita impidiendo que T3 lea balx hasta que se haya tomado la decisión de confirmar o abortar los efectos de la transacción T4. Tiempo begin_transaction read(balx) begin_transaction
100
write(balxl
200 200
rollback
write(balxl commit
Figura 20.5.
100
balx = balx + 100 read(balx) balx = balx - 10
100
100 190 190
El problema de la dependencia no confirmada.
Los dos problemas de estos ejemplos se concentran en transacciones que están actualizando la base de datos y cuya interferencia puede corromperla. Sin embargo, las transacciones que sólo leen la base de datos también pueden producir resultados inadecuados si se las permite leer resultados parciales de transacciones incompletas que esté actualizando simultáneamente la base de datos. Vamos a ilustrar este caso con el siguiente ejemplo.
I
Ejemplo 20.3 El problema del análisis incoherent8\ El problema del análisis incoherente surge cuando una transacción lee varios valores de la base de datos mientras que una segunda transacción actualiza uno de ellos durante la ejecución de la primera. Por ejemplo, una transacción que esté totalizando los datos contenidos en una base de datos (por ejemplo, calculando los saldos totales) obtendrá resultados incorrectos si otras transacciones están actualizando la base de datos mientras que la primera se ejecuta. Un ejemplo es el que se ilustra en la Figura 20.6, donde una transacción de totalización T6 se está ejecutando concurrentemente con la transacción Ts· La transacción T6 está calculando los totales de los saldos de las cuentas x (1 00 euros), y (50 euros) y z(25 euros). Sin embargo, mientras que esto se lleva a cabo, la transacción Ts ha transferido 10 euros de balx a bal" por lo que ahora T6 obtendrá un resultado incorrecto (10 euros superior al real). Este problema se evita impidiendo que la transacción T61ea balx y balz hasta que la transacción Ts haya completado sus actualizaciones.
528
commit 150 325 5baly 100 suma 185 O write(balz) 100 50 90sum sum=O 90 50 90problema 2baly begin_transaction begin_transaction write( read(balz) Sistemas read(balx) balx balz ==balx) balx de balz -bases +100 10 10 datos sum =incoherente. sum90+ balz sum+ Ts T6 read(balz) read(balx) sum = del sum de + commit balx balz Elbalx análisis read(baly)
~ Tiempo
Otro problema distinto puede producirse cuando una transacción T vuelve a leer un elemento de datos que había leído previamente pero que, mientras tanto, ha sido modificado por otra transacción. En este caso, T leerá dos valores diferentes para el mismo elemento de datos. Esto se denomina en ocasiones lectura no repetible (o difusa). Un problema similar puede tener lugar si la transacción T ejecuta una consulta que extrae un conjunto de tuplas de una relación que satisface un cierto predicado y vuelve a ejecutar la consulta en un instante posterior, encontrándose con que el conjunto extraído contiene una tupla adicional (fantasma) que ha sido insertada por otra transacción mientras tanto. Este problema se denomina en ocasiones lectura fantasma.
20.2.2
Serializabilidad y recuperabilidad
El objetivo de un protocolo de control de concurrencia es planificar las transacciones de forma tal que se evite cualquier interferencia entre ellas, impidiéndose así que aparezcan los tipos de problemas descritos en la sección anterior. Una solución obvia consiste en permitir que sólo se ejecute una transacción cada vez: cada transacción debe confirmarse antes de que se permita a la siguiente transacción comenzar. Sin embargo, el objetivo de un SGBD multiusuario es también maximizar el grado de concurrencia o paralelismo del sistema, de modo que las transacciones que puedan ejecutarse sin interferir unas con otras puedan hacerlo en paralelo. Por ejemplo, diversas transacciones que accedan a diferentes partes de la base de datos podrán ejecutarse simultáneamente sin interferir entre sí. En esta sección, vamos a examinar el concepto de serializabilidad como medio de ayudar a identificar aquellas ejecuciones de transacciones que está garantizado que protegen la coherencia (Papadimitriou, 1979). Antes de nada, veamos algunas definiciones. Planificación
currentes Una secuencia que preserva de las operaciones el orden derealiz~das las ol:\eraciones por un conjunto en cada una de transacciones de las transaccioconnes individuales. Cada transacción comprende una secuencia de operaciones compuesta de acciones de lectura y/o escritura en la base de datos, seguida de una acción de confirmación o anulación. Una planificación S estará compuesta por una secuencia de las operaciones correspondientes a un conjunto de n transacciones TI' T2' ... , Tm sujeta a la restricción de que el orden de las operaciones para cada transacción se preserve dentro de la planificación. Así, para cada transacción Ti de la planificación S, el orden de las operaciones en Ti debe ser igual que en la planificación S. Planificación serie
Una planificación en la que las operaciones de cada transacción se ejecutan consecutivamente sin que se entrelacen operaciones de otras transacciones.
Capítulo 20 Gestión de transacciones
529
En una planificación serie, las transacciones se realizan en serie, unas detrás de otras. Por ejemplo, si tenemos dos transacciones TI y T2, la ejecución en serie consistiría en ejecutar TI primero y a continuación T2, o bien T2 primero y a continuación TI' De este modo, en una ejecución serie no hay ninguna interferencia entre transacciones, ya que sólo una de ellas se estará ejecutando en cada momento determinado. Sin embargo, no hay ninguna garantía de que los resultados de todas las ejecuciones en serie de un conjunto dado de transacciones sean idénticos. En aplicaciones bancarias, por ejemplo, tiene importancia calcular el interés correspondiente a una cuenta antes o después de efectuar un ingreso considerable. Planificación
Una planificación en la que las operaciones rrentes están entrelazadas.
no serie
de un conjunto de transacciones
concu-
Los problemas descritos en los Ejemplo 20.1-20.3 se producían como resultado de una gestión errónea de la concurrencia, que dejaba a la base de datos en un estado incoherente en los primeros dos ejemplos y presentaba al usuario un resultado erróneo en el tercero. La ejecución serie impide que dichos problemas ocurran. Independientemente de qué planificación serie se elija, la ejecución en serie nunca dejará a la base de datos en un estado incoherente, por lo que todas las ejecuciones en serie se consideran correctas, incluso aunque puedan producirse diferentes resultados. El objetivo de la serializabilidad es encontrar planificaciones no serie que permitan ejecutar concurrentemente las transacciones sin que éstas interfieran entre sí, y produciendo así un estado de la base de datos al que pueda llegarse mediante una ejecución en serie. Si un conjunto de transacciones se ejecuta concurrentemente, decimos que la planificación (no serie) es correcta si produce los mismos resultados que alguna ejecución en serie. Dicho tipo de planificación se denomina serializable. Para evitar que aparezcan incoherencias debido a las interferencias entre transacciones, resulta esencial garantizar la sociabilidad de las transacciones concurrentes. En lo que respecta a la serializabilidad, la ordenación de las transacciones de lectura y escritura es importante: •
Si dos transacciones únicamente leen en un determinado elemento de datos, no entran en conflicto entre sí y el orden no es importante.
•
Si hay dos transacciones que leen o escriben elementos de datos completamente entran en conflicto entre sí y el orden no es importante.
•
Si una de las transacciones escribe un elemento de datos y otra lee o escribe el mismo elemento, el orden de ejecución sí que es importante.
independientes,
no
Considere la planificación SI mostrada en la Figura 20.7(a) y que contiene operaciones de dos transacciones que se están ejecutando concurrentemente, T7 y Ts. Puesto que la operación de escritura en balx en Ts no entra en conflicto con la subsiguiente operación de lectura de baly en T7, podemos cambiar el orden de estas Tiempo
, {
commit commit commit cornmit begin_transaction cornmit read(balx) T7 Ts begin_transaction read(balx) write(balx) write(baly) T7 write(balx) begin_transaction egm_transactlOn begin_transaction (e) (b) write(baly) read(baly) read(balx) read(baly) write(balx) read(baly) read(baly) wríte(baly) write(baly) read(baly) write(balx) write(baly)
Figura 20.7. no serie
write(balx) read(balx) write(balx)
.
Planificaciones 82•
equivalentes:
equivalente a
81;
(a) planificación
(c) planificación serie
83•
no serie
81;
equivalente
(b) planificación a
81
ya
82,
530 Sistemas de bases de datos operaciones para producir la planificación equivalente S2 mostrada en la Figura 20.7(b). Si también cambiamos ahora el orden de las siguientes operaciones que no interfieren entre sí, podemos generar la planificación serie equivalente S3 mostrada en la Figura 20.7(c): •
Cambiar el orden de la operación write(balx) de Ts con la operación write(baly) deT7'
•
Cambiar el orden de la operación read(balx) de Ts con la operación read(baly) de T7'
•
Cambiar el orden de la operación read(balJ deTs con la operación write(baly) de T7'
La planificación S3 es una planificación serie y, puesto que SI y S2 son equivalentes en S3, podemos concluir que SI y S2 son planificaciones serializables. Este tipo de serializabilidad se denomina serializabilidad de conflictos. Una planificación con serial izabilidad de conflictos ordena las operaciones conflictivas de la misma manera que alguna de las posibles eje· . CUClOnessene.
Detección de la serializabilidad de conflictos Utilizando la regla de escritura restringida (es decir, cada transacción actualiza los elementos de datos basándose en su antiguo valor, que deberá ser primero leído por la transacción), puede producirse un grafo de precedencia (o de serialización) para determinar si existe serializabilidad de conflictos. Para una planificación S, un grafo de precedencia es un grafo dirigido G = (N, E) que está compuesto por un conjunto de nodos N y un conjunto de nodos de aristas dirigidas E, que se construye como sigue: •
Se crea un nodo para cada transacción.
•
Se crea una arista dirigida Ti ~ Tj, si Tj lee el valor de un elemento escrito por Ti'
•
Se crea una arista dirigida Ti ~ Tj' si Tj escribe un valor en un elemento después de que éste haya sido leído por Ti'
•
Se crea una arista dirigida Ti ~ Tj, si Tj escribe un valor en un elemento después de Ti haya escrito en él.
Si existe una arista Ti ~ Tj en el grafo de precedencia de S, entonces en cualquier planificación serie S' equivalente a S, Ti debe aparecer antes de Tj' Si el grafo de precedencia contiene un ciclo, dicha planificación no será serializable en términos de conflictos.
I
Ejemplo 20.4 Planificación proyección
no serializable en términos
de conflicto
Operación de
Tiempo begin_transaction read(balx) balx = balx + 100 write(balx)
~egin_transaction read(balx) balx = balx *1.1 write(balx) read(baly) baly = baly * 1.1
read(baly)
write(baly) commit
baly = baly - 100 write(baly) commit
Figura 20.8.
Dos transacciones de actualización concurrentes serializables en términos de conflictos.
que no son
Capítulo 20 Gestión de transacciones
531
x
y
Figura 20.9. Grafo de precedencia para la Figura 20.8 donde se muestra un ciclo, por lo que la planificación no es serializable en términos de conflictos.
Considere las dos transacciones mostradas en la Figura 20.8. La transacción T9 está transfiriendo 100 euros desde una cuenta con saldo balx a otra cuenta con saldo baly, mientras que T 10 está incrementado el saldo de estas dos cuentas en un 10%. El grafo de precedencia de esta planificación, mostrada en la Figura 20.9 tiene un ciclo, por lo que la planificación no es serializable en términos de conflicto~
Serializabilidad
de vistas
Hay diversos otros tipos de serializabilidad que ofrecen definiciones menos restrictivas de la equivalencia entre planificaciones que la que se ofrece para la serializabilidad de conflictos. Una definición menos restrictiva es la que se denomina serializabilidad de vistas. Dos planificaciones SI y S2 compuestas por las mismas operaciones tomadas de n transacciones TI' T2, ... , Tn son equivalentes en términos de vistas si se cumplen las siguientes tres condiciones: •
Para cada elemento de datos x, si la transacción Ti lee el valor inicial de x en la planificación SI' entonces la transacción Ti también debe leer el valor inicial de x en la planificación S2'
•
Para cada operación de lectura sobre el elemento de datos x por parte de la transacción Ti en la planificación S" si el valor leído de x ha sido escrito por la transacción Tj' entonces la transacción Ti también debe leer el valor de x producido por la transacción Tj en la planificación S2'
•
Para cada elemento de datos x, si la última operación de escritura sobre x fue realizada por la transacción Ti en la planificación SI' la misma transacción debe realizar la escritura final del elemento de datos x en la planificación S2'
Una planificación es serializable en términos de vistas si es equivalente en términos de vistas a una planificación serie. Toda planificación serializable en términos de conflictos es serializable en términos de vistas, aunque la inversa no es cierta. Por ejemplo, la planificación mostrada en la Figura 20.10 es serializable en térTiempo
Tl2 begin_transaction read(balx) begin_transaction write(balx) commit write(balx) cornmit begin_transaction write(balx) cornmit
Figura 20.10.
Planificación
serializable en términos de vistas que no es serializable en términos de conflictos.
532
Sistemas de bases de datos
minos de vistas, aunque no es serializable en términos de conflictos. En este ejemplo, las transacciones TI2 y T13 no respetan la regla de escritura restringida; en otras palabras, realizan escrituras a ciegas. Se puede demostrar que toda planificación serializable en términos de vistas que no sea serializable en términos de conflictos contiene una o más escrituras a ciegas.
Detección de la serializabilidad de vistas Detectar la serializabilidad de vistas es mucho más complejo que detectar la serializabilidad de conflictos. De hecho, se ha demostrado que el problema de detección de la serializabilidad de vistas es NP-completo, así que es altamente improbable que se pueda hallar un algoritmo eficiente (Papadimitriou, 1979). Si generamos un grafo de precedencia (de serializabilidad de conflictos) correspondiente a la planificación indicada en la Figura 20.10, obtendremos el grafo mostrado en la Figura 20.11. Este grafo contiene un ciclo que indica que la planificación no es serializable en términos de conflictos; sin embargo, sabemos que es serializable en términos de vistas, ya que es equivalente a la planificación serie TII seguida de Tl2 seguida de T13. Cuando examinamos las reglas para el grafo de precedencia anteriormente indicado, podemos ver que la arista T 12 -7 T II no debería haber sido insertada en el grafo, ya que los valores de bal, escritos por TII y Tl2 nunca han sido utilizados por ninguna otra transacción, debido a las escrituras a ciegas.
Figura 20.11.
Gráfico de precedencia para la planificación en términos de vistas para la Figura 20.10.
serializable
Como resultado, para detectar la serializabilidad de vistas necesitamos un método de decidir si hay que insertar una arista determinada en el grafo de precedencia. El enfoque que adoptaremos consiste en construir un grajo de precedencia etiquetado para la planificación, de la forma siguiente: (1) Creamos un nodo para cada transacción. (2) Creamos un nodo etiquetado Tbw. Tbw, es una transacción ficticia que se inserta al comienzo de la planificación y que contiene una operación de escritura para cada elemento de datos al que se accede en la planificación. (3) Creamos un nodo etiquetado Tjr. TI" es una transacción ficticia que se inserta al final de la planificación y que contiene una operación de lectura para cada elemento de datos al que se accede en la planificación. o
(4) Creamos una arista dirigida T, -7 Ti ' si Tj lee el valor de un elemento escrito por Ti. (5) Eliminamos todas las aristas dirigidas que inciden en las transacciones Ti para las que no haya ninguna ruta desde Ti a Tlr. (6) Para cada elemento de datos leído por Tj, y que haya sido escrito por Ti y que Tk escriba (Tk o
(a) Si Ti = Tbw Y Tj
*-
TI" creamos una arista dirigida Ti
*-
Tbw):
-7 Tk . o
(b) Si Ti *- Tbw Y Tj = TI" creamos una arista dirigida Tk -7T, .
x
x
(c) Si Ti *- Tbw Y Tj *-T/" creamos un par de aristas dirigidas Tk -7T, Y Ti -7Tk donde x es un entero positivo unívoco que no ha sido utilizado para etiquetar una arista dirigida anteriormente. Esta regla
Capítulo 20 Gestión de transacciones
533
es un caso más general de las dos reglas precedentes, e indica que si una transacción Ti escribe un elemento que Tj posteriormente lee, entonces toda transacción Tk que escriba el mismo elemento debe forzosamente preceder a Ti o bien suceder a Tj. Aplicando las primeras cinco reglas a la planificación de la Figura 20.10, obtenemos el grafo de precedencia mostrado en la Figura 20.12(a). Aplicando la regla 6(a), añadimos las aristas T" ~ T'2 Y T" ~ Tu, ambas etiquetadas con O; aplicando las regla 6(b), añadimos las aristas T" ~ Tu (que ya está presente) y T '2 ~ Tu, de nuevo etiquetadas las dos como O. El grafo final se muestra en la Figura 20. 12(b). Basándonos en este grafo de precedencia etiquetado, podemos comprobar si se cumple la serializabilidad de vistas de la forma siguiente: (1) Si el grafo no contiene ningún ciclo, la planificación será serializable en términos de vistas. (2) La presencia de un ciclo, sin embargo, no es condición suficiente para concluir que la planificación es serializable en términos de vistas. La prueba real se basa en la observación de que la regla 6(c) genera m pares distintos de aristas, lo que da como resultado 2m grafos diferentes que contienen sólo una arista de cada par. Si cualquiera de estos grafos es acíclico, entonces la planificación correspondiente será serializable en términos de vistas y el orden de serializabilidad está determinado por la ordenación topológica del grafo, una vez eliminadas las transacciones ficticias Tbw y TJr. Aplicando estas pruebas al grafo de la Figura 20.12(b), que es acíclico, concluimos que la aplicación es serializable en términos de vistas. Como ejemplo adicional, considere la variante ligeramente modificada de la planificación de la Figura 20.10 que se muestra en la Figura 20.13 y que contiene una operación de lectura adicional en la transacción T13A- Aplicando las primeras cinco reglas a esta planificación se genera el grafo de precedencia mostrado en la Figura 20.14(a). Aplicando la regla 6(a), añadimos las aristas T" ~ TI2 Y T" ~ T'3A' ambas de las cuales se etiquetan con O; aplicando la regla 6(b), añadimos las aristas T" ~ T13A (que ya está presente) y T'2 ~ T13A (que también está presente), ambas etiquetadas con O.Aplicando la regla 6(c), añadimos el par de aristas TII ~ T'2 Y T'3A ~ T'I' etiquetando esta vez ambas con 1. El grafo final se muestra en la Figura 20. 14(b). A partir de éste podemos generar dos grafos diferentes que contienen sólo una arista, como se muestra en las Figuras 20.14(c) y 20.14(d). Como la Figura 20.14(c) es acíclica, podemos concluir que esta planificación también es serializable en términos de vistas (correspondiendo a la planificación serie TII ~ T'2 ~ T'3A)· En la práctica, un SGBD no comprueba la serializabilidad de una aplicación. Esto no sería práctico, ya que el entrelazado de las operaciones de las transacciones concurrentes está determinado por el sistema operativo. En lugar de ello, lo que se hace es utilizar protocolos que se sabe que producen planificaciones serializables. Hablaremos de dichos protocolos en la siguiente sección.
(a)
Figura 20.12.
Grafo de precedencia etiquetado para la planificación en términos de vistas de la Figura 20.10.
serializable
534
Sistemas de bases de datos
commit read(balx) begín_transactíon read(balx) write(balx) TI] TJ2 TI3 begin _transaction
Tiempo
commit begín_transaction wríte(balx)
commit begin_transactíon write(balx)
73 t8 t2
Figura 20.13.
Una versión modificada de la planificación de la Figura 20.10 que contiene una operación de lectura adicional.
(a)
Figura 20.14.
Grafo de precedencia etiquetado para otra planificación en términos de vistas, la de la Figura 20.13.
serializable
Capítulo 20 Gestión de transacciones
535
Recuperabilidad La serializabilidad identifica las planificaciones que mantienen la coherencia de la base de datos, suponiendo que ninguna de las transacciones de la planificación falle. Una perspectiva alternativa examina la recuperabilidad de las transacciones dentro de una planificación. Si falla una transacción, la propiedad de atomicidad requiere que deshagamos los efectos de la misma. Además, la atomicidad de permanencia indica que, una vez que se confirma una transacción, sus cambios no pueden deshacerse (sin ejecutar otra transacción de compensación). Considere de nuevo las dos transacciones mostradas en la Figura 20.8, pero suponga que en lugar de la operación de confirmación al final de la transacción T9, esta transacción decide deshacer los cambios realizados. TIO habrá leído la actualización de balx realizada por T9 y habrá ella misma actualizado balx y confirmado el cambio. Estrictamente hablando, deberíamos deshacer la transacción TIO, puesto que ésta ha utilizado un valor de balx que ha sido anulado. Sin embargo, la propiedad de permanencia no nos permite hacer esto. En otras palabras, esta planificación es una planificación no recuperable, lo cual no puede permitirse. Esto nos conduce a la definición de planificación recuperable. Planificación recuperable
Una planificación en la que, para cada par de transacciones Ti y Ti' si Ti lee un elemento de datos previamente escrito por Ti, entonces la operación de confirmación de Ti precede a la operación de confirmación de Ti'
Técnicas de control de concurrencia La serializabilidad puede conseguirse de diversas formas. Existen dos técnicas principales de control de concurrencia que permiten que las transacciones se ejecuten con seguridad en paralelo, sujetas a ciertas restricciones: los métodos de bloqueo y los de marca temporal. El bloqueo y las marcas temporales son esencialmente técnicas conservadoras (o pesimistas), en el sentido de que hacen que las transacciones se vean retardadas por si acaso entran en conflicto con otras transacciones en algún instante futuro. Los métodos optimistas, como veremos posteriormente, están basados en la premisa de que los conflictos son raros, por lo que se permite a las transacciones continuar de manera no sincranizada y sólo confirman los conflictos al final, cuando una transacción se confirma. Hablaremos del bloqueo, de las marcas temporales y de las técnicas de control de concurrencia optimistas en las siguientes seccIOnes.
20.2.3 Métodos de bloqueo Bloqueo
Un procedimiento utilizado para controlar el acceso concurrente a los datos. Cuando una transacción está accediendo a la base de datos, un bloqueo puede denegar el acceso a otras transacciones con el fin de impedir que se produzcan resultados incorrectos.
Los métodos de bloqueo son la técnica más ampliamente utilizada para garantizar la seriabilidad de las transacciones concurrentes. Hay diversas variantes, pero todas ellas comparten la misma característica fundamental, que es que una transacción debe reclamar un bloqueo compartido (lectura) o exclusivo (escritura) sobre un elemento de datos antes de ejecutar la correspondiente operación de lectura o escritura en la base de datos. El bloqueo evita que otra transacción modifique el elemento, o que incluso lo lea, en caso de tener un bloqueo exclusivo. Pueden bloquearse elementos de datos de distintos tamaños, desde toda la base de datos hasta sólo un determinado campo. El tamaño del elemento determina la finura o granularidad del bloqueo. El propio bloqueo puede implementarse en la práctica activando un bit en el elemento de datos que indique que una parte de la base de datos está bloqueada, o manteniendo una lista de partes bloqueadas de la base de datos, o por cualquier otro medio. Examinaremos más en detalle la granularidad de los bloqueos en la Sección 20.2.8. Mientras tanto, continuaremos utilizando el término 'elemento de datos' para hacer referencia a la granularidad del bloqueo. Las reglas básicas del bloqueo son las siguientes: Bloqueo compartido
Si una transacción tiene un bloqueo compartido sobre un elemento de datos, puede leer el elemento, pero no actualizarlo.
536
Sistemas de bases de datos
Bloqueo exclusivo
Si una transacción tiene un bloqueo exclusivo sobre un elemento de datos, puede leer y actualizar el elemento.
Puesto que las operaciones de lectura no pueden entrar en conflicto unas con otras, se permite que varias transacciones mantengan simultáneamente bloqueos compartidos sobre un mismo elemento. Por el contrario, un bloqueo exclusivo proporciona a una transacción acceso exclusivo a dicho elemento. De este modo, mientras que una transacción mantenga el bloqueo exclusivo sobre el elemento, ninguna otra transacción podrá leerlo o actualizarlo. Los bloqueos se utilizan de la siguiente forma: •
Una transacción que necesita acceder a un elemento de datos debe primero bloquear el elemento, solicitando un bloqueo compartido para el acceso de sólo lectura o un bloqueo exclusivo para el acceso tanto de lectura como de escritura.
•
Si el elemento no ha sido ya bloqueado por otra transacción, se concederá el bloqueo.
•
Si el elemento está actualmente bloqueado, el SGBD determina si la solicitud es compatible con el bloqueo existente. Si se solicita un bloqueo compartido sobre un elemento que ya tiene un bloqueo compartido, la solicitud será concedida; en caso contrario, la transacción debe esperar hasta que se libere el bloqueo existente.
•
La transacción continuará manteniendo el bloqueo hasta que lo libere explícitamente, bien durante la ejecución o bien al terminar (abortándose o confirmándose). Sólo cuando se libere el bloqueo exclusivo serán visibles los efectos de la operación de escritura para las demás transacciones.
Además de estas reglas, algunos sistemas permiten que una transacción obtenga un bloqueo compartido sobre un elemento y posteriormente lo mejore a bloqueo exclusivo. Esto, en la práctica, permite que la transacción examine primero los datos y luego decida si desea actualizarlos. Si este procedimiento de mejora del bloqueo no está soportado, las transacciones deberán imponer un bloqueo exclusivo sobre todos los elementos de datos que puedan llegar a actualizarse en algún momento de la ejecución de la transacción, reduciéndose así potencialmente el nivel de concurrencia del sistema. Por la misma razón, algunos sistemas también permiten que una transacción establezca un bloqueo exclusivo y luego lo reduzca a bloqueo compartido. Utilizando bloqueos en las transacciones como hemos descrito no se garantiza la serializabilidad de las planificaciones, como se demuestra en el Ejemplo 20.5.
I
Ejemplo 20.5 Planificación
de bloqueo
incorrecta
Considere de nuevo las dos transacciones mostradas en la Figura 20.8. Una planificación podría utilizarse empleando las reglas de bloqueo anteriores sería:
válida que
S = {write_lock(Tg, balx)' read(Tg, balx), write(Tg, balx)' unlock(Tg, balx)' writeJock(T1Q'balx)' read(T10,balx)' write(T10,balx), unlock(T10,balx)' write_lock(T10, baly), read(T10,baly), write(T10,baly), unlock(T10,baly), commit(T1Q), write_lock(Tg, baly), read(Tg, baly), write(Tg, baly), unlock(Tg,
baly),
commit(Tg)}
Si, antes de la ejecución, balx = 100, baly = 400, el resultado será balx = 220, baly = 330, si T9 se ejecuta antes que T 10, o balx = 210 y baly = 340, si T 10 se ejecuta antes que T 9' Sin embargo, el resultado de ejecutar la planificación S sería balx = 220 Y baly = 340 (S no es una planificación serializable).
El problema en este ejemplo es que la planificación libera los bloqueos mantenidos por una transacción tan pronto como se ejecuta la lectura/escritura asociada, siempre que no se necesite acceder otra vez al elemento bloqueado (por ejemplo balx)' Sin embargo, la misma transacción está bloqueando otros elementos (baly), después de eliminar el bloqueo sobre balx' Aunque pueda parecer que esto permite una mayor concurrencia, en realidad permite que las transacciones interfieran entre sí, lo que da como resultado una pérdida de la atomicidad y del aislamiento.
Capítulo 20 Gestión de transacciones
537
Para garantizar la serializabilidad, debemos seguir un protocolo adicional relativo al posicionamiento de las operaciones de bloqueo y desbloqueo dentro de cada transacción. El protocolo más conocido es el bloqueo en dos fases (2PL, two-phase locking).
Bloqueo en dos fases (2PL) 2PL
Se dice que una transacción cumple con el protocolo de bloqueo en dos fases si todas las operaciones de bloqueo preceden a la primera operación de desbloqueo de la transacción.
De acuerdo con las reglas de este protocolo, toda transacción puede dividirse en dos fases: primero una fase de crecimiento, en la que adquiere todos los bloqueos necesarios y no puede liberar ninguno de ellos, y luego una fase de decrecimiento, en la que libera todos los bloqueos sin poder adquirir ninguno nuevo. No es necesario que todos los bloqueos se obtengan simultáneamente. Normalmente, la transacción adquirirá unos bloqueos, hará algún tipo de procesamiento y continuará adelante adquiriendo bloqueos adicionales según sea necesario. Sin embargo, no eliminará ningún bloqueo hasta que haya alcanzado una etapa en la que no sea necesario adquirir nuevos bloqueos. Las reglas son: •
Una transacción debe adquirir un bloqueo sobre un elemento antes de operar sobre dicho elemento. El bloqueo puede ser de lectura o de escritura, dependiendo del tipo de acceso necesario .
•
Una vez que la transacción libera un bloqueo, ya no puede adquirir ningún bloqueo nuevo.
Si está permitida la mejora de los bloqueos, dicha mejora sólo puede tener lugar durante la fase de crecimiento y puede requerir que la transacción espere hasta que otra transacción libere un bloqueo compartido sobre el elemento. El empeoramiento sólo puede tener lugar durante la fase de decrecimiento. Veamos ahora cómo se utiliza un bloqueo en dos fases para resolver los tres problemas identificados en la Sección 20.2.1.
I
Ejemplo 20.6 Cómo impedir el problema
de la actualización
perdida
utilizando
2PL
En la Figura 20.15 se muestra una solución al problema de la actualización perdida. Para evitar que este problema aparezca, T 2 solicita primero un bloqueo exclusivo sobre balx• Entonces puede proceder a leer el valor de balx de la base de datos, incrementarlo en 100 euros y escribir el nuevo valor en la base de datos. Cuando TI comienza, también solicita un bloqueo exclusivo sobre balx• Sin embargo, puesto que el elemento de datos balx tiene actualmente un bloqueo exclusivo establecido por T2, la solicitud no se ve inmediatamente satisfecha y TI tiene que esperar hasta que T2 libera el bloqueo. Esto sólo sucede cuando se haya completado la confirmación de T2•
T¡
Tiempo
begin_transaction
100
writeJock(balx)
100
write_lock(balx) WAIT
read(balx)
100
balx = balx + 100
100
WAIT
write(balx)
200
WAIT
commit/unlock(balx)
begin_transaction
200
read(balx)
200
balx = balx - 10
200
write(balx)
190
comm;t/unlock(balx)
190
Figura 20.15.
Cómo evitar el problema de la actualización perdida.
538
I
Sistemas de bases de datos
Ejemplo 20.7 Cómo impedir el problema de la dependencia utilizando 2PL
no confirmada
En la Figura 20.16 se muestra una solución al problema de la dependencia no confirmada. Para impedir que este problema surja, T4 solicita primero un bloqueo exclusivo sobre balx• Entonces puede proceder a leer el valor de balx de la base de datos, incrementarlo en 100 euros y escribir el nuevo valor en la base de datos. Cuando se ejecuta la anulación, se deshacen las actualizaciones correspondientes a la transacción T4, devolviéndose el valor de balx a los 100 euros que tenía originalmente. Cuando T3 comienza, también solicita un bloqueo exclusivo sobre balx• Sin embargo, puesto que el elemento de datos balx está actualmente bloqueado de manera exclusiva por T4, la solicitud no se ve inmediatamente satisfecha y T3 tiene que esperar hasta que T4 libera el bloqueo. Esto sólo ocurre después de que se haya completado la anulación de T4. balx
Tiempo
100
begin_transaction
begin_transaction write_lock(balx) WAlT
Figura 20.16.
I
write_lock(balx)
100
read(balx)
100
balx = balx + 100
100
write(balx)
200
100
rollback/unlock(balx)
read(balx)
100
balx = balx - 10
100
write(balx)
90
commit/unlock(balx)
90
Cómo evitar el problema de la dependencia no confirmada.
Ejemplo 20.8 Cómo impedir el problema de análisis incoherente
utilizando
2PL
La Figura 20.17 muestra una solución al problema del análisis incoherente. Para evitar que este problema suceda, Ts debe preceder sus lecturas por bloqueos compartidos. Así, cuando Ts comience, solicitará y obtendrá un bloqueo exclusivo sobre balx• A continuación, cuando T6 trate de establecer un bloqueo compartido sobre bal" la solicitud no será admitida de forma inmediata y T6 tendrá que esperar hasta que se levante el bloqueo, lo cual se producirá cuando Ts se confirme. Véase la Figura ~ Puede demostrarse que si toda transacción de una planificación sigue el protocolo de bloqueo en dos fases, puede garantizarse que la planificación será serializable en términos de conflictos (Eswaran et al., 1976). Sin embargo, aunque el protocolo de bloqueo en dos fases garantiza la serializabilidad, pueden surgir problemas de interpretación en lo que respecta a cuándo pueden liberarse los bloqueos, como muestra el siguiente ejemplo.
I
Ejemplo 20.9 Anulaciones
en cascada
Considere una planificación compuesta por las tres transacciones que se muestran en la Figura 20.18, que se adecua al protocolo de bloqueo en dos fases. La transacción T 14 obtiene un bloqueo exclusivo
Capítulo 20 Gestión de transacciones
50 175 25 25O 3250 55O 140 90O 10 =WAIT 100 90 90 begin_Iransaclion WAIT sum=O WAIT rbalx= w balz wrile(balz) ead(balx) rile_lock(balx) rile(balx) rile_lock(balz) balx balz 10evitar begin_Iransaclion read(balx) commil/unlock(balx' balz) Tiempo suma read(balz) sum read_lock(balz) read(balz) = sum balz balx baly' 100 T6 read_lock(balx) commit/unJock(balx' read_lock(baly) read(baly) baly balz) balz Ts +balx Cómo el100 problema del+ análisis incoherente. baly
Tiempo 12 116
115
rollback rollback begin_Iransaction read(balx) wrile_lock(balx) unlock(balx) Anulación wríle(balx) en+ cascada mediante wrile_lock(balx) wrile(balx) balx read(balx) unlock(balx) 2PL. = balx + 100 balx =T14 read(baly) read_lock(baly) baly balx T1S begín_transaclion T]6
Figura 20.18.
rollback begín_Iransaclion read_lock(balx)
539
540
Sistemas de bases de datos
sobre bal" luego lo actualiza utilizando baly, que ha sido obtenida mediante un bloqueo compartido y escribe el valor de balx en la base de datos antes de liberar el bloqueo sobre balx' La transacción T1S obtiene entonces un bloqueo exclusivo sobre bal" lee el valor de balx de la base de datos, lo actualiza y escribe el nuevo valor antes de liberar el bloqueo. Finalmente, Tl6 establece un bloqueo compartido sobre balx y lee el valor de la base de datos. Llegados a este punto, TI4 ha fallado y ha sido anulada. Sin embargo, puesto que T1Sdepende de Tl4 (ha leído un elemento que ha sido actualizado por TI4), también será necesario anular T1S' De forma similar, Tl6 depende de T1S, así que también tendrá que ser anulada. Esta situación, en la que una única transacción conduce a una serie de anulaciones, se denomina anulación en cascada.
~
Las anulaciones en cascada no resultan deseables, ya que pueden conducir potencialmente a que se tenga que deshacer una cantidad significativa de trabajo. Obviamente, sería útil poder diseñar protocolos que impidieran las anulaciones en cascada. Una forma de conseguir esto con el bloqueo en dos fases consiste en dejar la liberación de todos los bloqueos hasta el final de la transacción, como en los ejemplos anteriores. De esta forma, el problema aquí ilustrado no podría producirse, ya que T1Sno obtendría su bloqueo exclusivo hasta después de que Tl4 completara la anulación. Esto se denomina 2PL riguroso. Puede demostrarse que con el 2PL riguroso, las transacciones pueden serializarse en el mismo orden en que son confirmadas. Otra variante de 2PL, denominada 2PL estricto, sólo mantiene los bloqueos exclusivos hasta el final de la transacción. La mayoría de los sistemas de base de datos implementan una de estas dos variantes de 2PL. Otro problema con el bloqueo en dos fases, que se aplica a todos los esquemas basados en bloqueo, es que puede provocar interbloqueos, debido a que las transacciones pueden tener que esperar a que se liberen los bloqueos que afectan a ciertos elementos de datos. Si dos transacciones están esperando a que se liberen los bloqueos sobre elementos de datos establecidos por la otra transacción, se producirá un intento de bloqueo y será preciso emplear el esquema de detección y recuperación de interbloqueos descrito en la Sección 20.2.4. También es posible que las transacciones queden en lo que se denomina un bloqueo indefinido, es decir, que se queden en un estado de espera indefinidamente, incapaces de adquirir ningún nuevo bloqueo, aunque el propio SGBD no esté experimentando una situación de interbloqueo. Esto puede suceder si el algoritmo de espera de las transacciones no es equitativo y no toma en cuenta el tiempo que las transacciones han estado esperando. Para evitar los bloqueos indefinidos, debe utilizarse un sistema de prioridades en el que la prioridad de una transacción vaya aumentando a medida que lo hace el tiempo de espera; por ejemplo, puede utilizarse una cola de tipo el primero en llegar es el primero en ser servido para las transacciones en espera.
Control de concurrencia
con estructuras
de índice
El control de concurrencia para una estructura de índice (véase el Apéndice C) puede gestionarse tratando cada página del índice como un elemento de datos y aplicando el protocolo de bloqueo en dos fases descrito anteriormente. Sin embargo, puesto que resulta probable que se acceda a los índices de manera frecuente, particularmente a los niveles más altos de los árboles (ya que las búsquedas tienen lugar desde la raíz hacia abajo), esta estrategia simple de control de concurrencia puede conducir a una alta tasa de contienda por los bloqueos. Por tanto, para los índices se requiere un protocolo de bloqueo más eficiente. Si examinamos el modo en que se recorren los índices basados en árbol, podemos hacer las dos siguientes observaciones: •
La ruta de búsqueda comienza a partir de la raíz y se mueve hacia abajo en dirección a los nodos hoja del árbol, pero una búsqueda nunca vuelve a retroceder hacia arriba por el árbol. Por tanto, una vez que se ha accedido a un nodo de nivel inferior, los nodos de nivel superior en dicha ruta no volverán a ser utilizados .
•
Cuando se está insertando un nuevo valor de índice (una clave y un puntero) en un nodo hoja, si el nodo no está lleno la inserción no provocará cambios en los nodos de nivel superior. Esto sugiere que sólo necesitamos establecer un bloqueo exclusivo sobre el nodo hoja en tales casos, y que sólo es necesario establecer bloqueos exclusivos sobre los nodos de nivel superior cuando un nodo está lleno y tiene que ser dividido.
Basándonos en estas observaciones, podemos definir la siguiente estrategia de bloqueo:
Capítulo 20 Gestión de transacciones •
541
Para las búsquedas, obtendremos bloqueos compartidos sobre los nodos, comenzando por la raíz y siguiendo hacia abajo a lo largo de la ruta requerida. Una vez obtenido un bloqueo sobre el nodo hijo, puede liberarse el bloqueo sobre el nodo padre .
•
Para las inserciones, una técnica conservadora sería obtener bloqueos exclusivos sobre todos los nodos que encontremos según vayamos descendiendo por el árbol hasta el nodo hoja que hay que modificar. Esto garantiza que una división en el nodo hoja pueda propagarse hacia arriba por el árbol, hasta alcanzar la raíz. Sin embargo, si un nodo hijo no está lleno, el bloqueo establecido sobre el nodo padre puede liberarse. Una técnica más optimista sería obtener bloqueos compartidos sobre todos los nodós a medida que descendemos hacia el nodo hoja que hay que modificar, donde obtendremos un bloqueo exclusivo sobre el propio nodo hoja. Si el nodo hoja tiene que ser dividido, podemos mejorar el bloqueo compartido del nodo padre, transformándolo en bloqueo exclusivo. Si también este nodo tiene que ser dividido, podemos continuar el proceso de mejora de los bloqueos en el siguiente nivel. En la mayoría de los casos, no se requiere dividir ningún nodo, lo que hace que ésta sea la técnica preferible. La técnica de bloquear un nodo hijo y liberar el bloqueo en el nodo padre si es posible se conoce con el nombre de acoplamiento de bloqueos. El lector interesado en el tema de las prestaciones de los algoritmos de control de concurrencias para estructuras de árbol puede consultar Srinivasan y Carey (1991).
Cerrojos Los SGBD también soportan otro tipo de bloqueos, denominado cerrojo (Iatch), que se mantiene durante un periodo de tiempo mucho más corto que un bloqueo normal. Los cerrojos pueden utilizarse antes de leer o escribir una página en disco, con el fin de garantizar que la operación sea atómica. Por ejemplo, se obtendría un cerrojo para escribir una página desde los búferes de la base de datos al disco, escribiéndose a continuación la página en el disco y eliminando el cerrojo inmediatamente. Puesto que el cerrojo se utiliza simplemente para prevenir conflictos en este tipo de accesos, los cerrojos no necesitan adaptarse al protocolo normal de control de concurrencia, como por ejemplo el de bloqueo en dos fases.
20.2.4 Interbloqueos Interbloqueo
Una situación de impase que puede resultar cuando dos (o más) transacciones están esperando a que se liberen bloqueos establecidos por la otra transacción.
La Figura 20.19 muestra dos transacciones, TI7 y T,S' que están interbloqueadas porque cada una de ellas está esperando a que la otra libere un bloqueo sobre un determinado elemento. En el instante t2, la transacción TI7 solicita y obtiene un bloqueo exclusivo sobre el elemento balx y en el instante t3 la transacción T,S obtiene un bloqueo exclusivo sobre el elemento baly. Entonces, en t6, TI7 solicita un bloqueo exclusivo sobre el elemento baly' Puesto que T1S mantiene un bloqueo sobre baly, la transacción TI7 quedará a la espera. Mientras tanto, en el instante t7, T,S solicita un bloqueo sobre el elemento bal" que ha sido bloqueado por la transacción TI7' Ninguna de las transacciones puede continuar, porque cada una de ellas está esperando a establecer un bloqueo que no puede establecer hasta que la otra se complete. Cuando aparece el interbloqueo, las aplicaciones implicadas no pueden resolver el problema. En lugar de ello, será el SGBD quien tenga que reconocer que existe un interbloqueo y romperlo de alguna manera. Desafortunadamente, sólo hay una forma de romper un interbloqueo: abortar una o más de las transacciones. Esto implica usualmente deshacer todos los cambios realizados por las transacciones abortadas. En la Figura 20.19, podemos decidir abortar la transacción T,s, Una vez completada esta operación, los bloqueos mantenidos por la transacción T1S serán liberados y TI7 será capaz de continuar. El interbloqueo debe ser transparente para el usuario, así que el SGBD debe reiniciar automáticamente las transacciones abortadas. Hay tres técnicas generales para gestionar los interbloqueos: temporizaciones, prevención de interbloqueos y detección y recuperación de interbloqueos. Con las temporizaciones, la transacción que haya solicitado un bloqueo espera durante un periodo máximo especificado de tiempo. Utilizando la técnica de prevención de interbloqueos, el SGBD analiza la situación para determinar si una transacción puede causar un interbloqueo y nunca permite que éste se produzca. Utilizando las técnicas de detección y recuperación de
542
Sistemas de bases de datos
Tiempo
T17
begin_transaction write_lock(balx)
begin_transaction
read(balx)
writeJock(baly)
balx = balx - 10
read(baly)
write(balx)
baly = baly + 100
write_lock(baly) WAIT
write(baly)
WAIT
write_lock(balx) WAIT
WAIT
WAIT WAIT
Figura 20.19.
Interbloqueo entre dos transacciones.
interbloqueos, el SGBD permite que se produzcan interbloqueos, pero reconoce su aparición y los rompe. Puesto que es más dificil prevenir los interbloqueos que utilizar temporizaciones o comprobar la existencia de interbloqueos y romperlos, los sistemas suelen evitar la utilización del método de prevención de interbloqueos.
Temporizaciones Una técnica simple para la prevención de interbloqueos se basa en las temporizaciones de bloqueo. Con esta técnica, una transacción que solicite un bloqueo esperará únicamente durante un periodo de tiempo definido por el sistema. Si no se concede el bloqueo dentro de este periodo, se producirá un fin de temporización. En este caso, el SGBD asume que la transacción puede estar interbloqueada, aunque es posible que no lo esté, y abortará y reiniciará automáticamente la transacción. Se trata de una solución muy simple y práctica para la prevención de interbloqueos y que es utilizada por diversos SGBD comerciales.
Prevención de interbloqueos Otra posible técnica para la prevención de interbloqueos consiste en ordenar las transacciones utilizando marcas temporales de transacción, de las que hablaremos en la Sección 20.2.5. Se han propuesto dos algoritmo s por parte de Rosenkrantz et al. (1978). Uno de los algoritmo s, Espera-Muere, sólo permite que una transacción más antigua espere a una más reciente, y en cualquier otro caso la transacción es abortada (muere) y es reiniciada con ]a misma marca temporal, por lo que terminará por ser en algún momento la transacción activa más antigua y no morirá. E] segundo algoritmo, Ataca-Espera, utiliza e] enfoque simétrico, sólo una transacción más reciente puede esperar por una más antigua. Si una transacción más antigua solicita un bloqueo que ha sido establecido por otra más reciente, la más reciente es abortada (atacada). Una variante de 2PL, denominada 2PL conservador, también puede utilizarse para prevenir los interb]oqueos. Utilizando e] protocolo 2PL conservador, una transacción obtiene todos sus bloqueos cuando comienza o bien espera a que todos sus bloqueos estén disponibles. Este protocolo tiene la ventaja de que si ]a contienda de bloqueos es alta, el tiempo durante el que se mantiene los bloqueos se reduce, porque las transacciones nunca están bloqueadas y nunca tienen, por tanto, que esperar por los bloqueos. Por otro lado, si la contienda de bloqueos es baja, los bloqueos se mantienen durante un tiempo mayor con este protocolo. Además, el gasto adicional para e] establecimiento de bloqueos es alto, porque todos los bloqueos deben obtenerse y liberarse al mismo tiempo. Por tanto, si una transacción no consigue obtener un bloqueo, deberá ]iberar todos los bloqueos que hasta el momento haya obtenido y comenzar de nuevo el proceso de establecimiento de bloqueos. Desde una perspectiva práctica, las transacciones pueden no saber desde e] principio qué bloqueos pueden llegar a necesitar y, por tanto, pueden tener que establecer más bloqueos de los necesarios. Este protocolo no se suele usar en ]a práctica.
Capítulo 20 Gestión de transacciones
543
Detección de interbloqueos La detección de interbloqueos suele gestionarse mediante la construcción de un grafo de espera (WFG, waitfor graph) que muestra las dependencias de las transacciones; es decir, la transacción Ti depende de Tj si la transacción Tj mantiene el bloqueo sobre un elemento de datos por el que Ti está esperando. El WFG es un grafo dirigido G = (N, E) que está compuesto por un conjunto de nodos N y un conjunto de aristas dirigidas E y que se construye de la forma siguiente: •
Se crea un nodo por cada transacción .
Se crea una arista dirigida Ti ~ Tj, si la transacción Ti está esperando para bloquear un elemento que está actualmente bloqueado por Tj' Existirá interbloqueo si y sólo si el WFG contiene un ciclo (Holt, 1972). La Figura 20.20 muestra el WFG para las transacciones en la Figura 20.19. Claramente, el grafo presenta un ciclo (TI? ~ T18 ~ T17), por lo que podemos concluir que el sistema está interbloqueado. •
Frecuencia de la detección de interbloqueos Puesto que la existencia de un ciclo en el grafo de espera es condición necesaria y suficiente para que exista interbloqueo, el algoritmo de detección de interbloqueos genera el WFG a intervalos regulares y lo examina en busca de ciclos. La selección del intervalo temporal entre ejecuciones del algoritmo tiene una gran importancia. Si se elige un intervalo demasiado pequeño, el mecanismo de detección de interbloqueos representará un gasto adicional considerable, si el intervalo es demasiado grande, puede que los interbloqueos no se detecten durante un largo periodo de tiempo. Alternativamente, puede iniciarse un algoritmo dinámico de detección de interbloqueos con un tamaño de intervalo inicial. Cada vez que no se detecte ningún interbloqueo, puede incrementarse el intervalo de detección, por ejemplo haciéndolo igual al doble del intervalo anterior, y cada vez que se detecte un interbloqueo, el intervalo puede reducirse, por ejemplo, a la mitad del intervalo anterior, existiendo algún tipo de límite superior e inferior.
Recuperación cuando se detecta un interbloqueo Como hemos mencionado anteriormente, una vez que se ha detectado un interbloqueo el SGBD necesitará abortar una o más transacciones. Son varias las cuestiones que hay que considerar: (l) Selección de la víctima de interbloqueo. En algunas circunstancias, la elección de las transacciones que hay que abortar puede ser obvia. Sin embargo, en otras situaciones, puede que dicha elección no sea tan clara. En estos casos, lo que queremos es abortar las transacciones que supongan el mínimo coste. Para esto, podemos tomar en consideración: (a) cuánto tiempo lleva ejecutándose la transacción (puede ser mejor abortar una transacción que acaba de empezar en lugar de una que haya estado ejecutándose durante un cierto tiempo); (b) cuántos elementos de datos han sido actualizados por la transacción (es mej or abortar una transacción que haya hecho pocos cambios en la base de datos en lugar de otra que haya hecho un número de cambios significativo); (c) cuántos elementos de datos debe todavía actualizar la transacción (es mejor abortar una transacción que todavía debe hacer muchos cambios en la base de datos en lugar de otra a la que le queden y
x
Figura 20.20.
WFG con un ciclo, mostrando un interbloqueo
entre dos transacciones.
544
Sistemas de bases de datos
pocos cambios por realizar). Desafortunadamente, te esta información.
puede que el SGBD no conozca necesariamen-
(2) Hasta qué punto deshacer la transacción. Habiendo decidido abortar una transacción concreta, debemos también decidir hasta dónde hay que deshacerla. Claramente, la solución más simple es deshacer todos los cambios realizados por una transacción, aunque esta solución no es necesariamente la más eficiente. Puede que sea posible resolver el interbloqueo deshaciendo sólo parte de la transacción. (3) Cómo evitar la inanición. La inanición tiene lugar cuando siempre se elige la misma transacción como víctima y dicha transacción no puede nunca llegar a completarse. La inanición es muy similar al bloqueo indefinido mencionado en la Sección 20.2.3, que tiene lugar cuando el protocolo de control de concurrencia nunca selecciona a una transacción concreta que esté esperando para establecer un bloqueo. El SGBD puede evitar la inanición almacenando una cuenta del número de veces que una transacción ha sido seleccionada como víctima y utilizando un criterio de selección diferente cuando esta cuenta alcance un determinado límite superior.
20.2.5
Métodos de marca temporal
La utilización de bloqueos, combinada con el protocolo de bloqueo en dos fases, garantiza la seriabilidad de las planificaciones. El orden de las transacciones en la planificación serie equivalente está basado en el orden en que las transacciones bloqueen los elementos que necesitan. Si una transacción necesita un elemento que ya está bloqueado, puede que se vea forzado a esperar hasta que se libere el elemento. Otra técnica diferente que también garantiza la serializabilidad utiliza marcas temporales de transacción para ordenar la ejecución de transacciones con el fin de obtener una planificación seria y equivalente. Los métodos de marca temporal para el control de concurrencia son bastante distintos de los métodos de bloqueo. No se necesita ningún tipo de bloqueo y, por tanto, no pueden aparecer interbloqueos. Los métodos de bloqueo evitan generalmente los conflictos haciendo que las transacciones esperen. Con los métodos de marca temporal, no existe ninguna espera: las transacciones implicadas en un conflicto simplemente se anulan y se reinician. Marca temporal
Un identificador unívoco creado por el SGBD y que indica el tiempo de inicio relativo de una transacción.
Las marcas temporales pueden generarse utilizando simplemente el valor del reloj del sistema en el momento de iniciarse la transacción o, más normalmente, incrementando un contador lógico cada vez que se inicia una transacción nueva. Control por marcas temporales
Un protocolo de control de concurrencia que ordena las transacciones de tal manera que las transacciones más antiguas, es decir, las transacciones con marcas temporales más pequeñas, tienen prioridad en caso de conflicto.
Con el control por marcas temporales, si una transacción trata de leer o escribir un elemento de datos, dicha lectura o escritura sólo será permitida si la última actualización sobre ese elemento de datos fue llevada a cabo por una transacción más antigua. En caso contrario, la transacción que solicita la lectura/escritura se reinicia y recibe una nueva marca temporal. Deben asignarse nuevas marcas temporales a las transacciones que se reinician para evitar que sean continuamente abortadas y reiniciadas. Si no se asignaran nuevas marcas temporales, una transacción con una marca temporal antigua podría no ser capaz de efectuar las confirmaciones debido a que otras transacciones más recientes ya hubieran sido confirmadas. Además de las marcas temporales para las transacciones, también hay marcas temporales para los elementos de datos. Cada elemento de datos contiene una marca temporal de lectura (read_timestamp), que proporciona la marca temporal de la última transacción que leyó el elemento y una marca temporal de escritura (write_timestamp), que proporciona la marca temporal de la última transacción que escribió (actualizó) el elemento. Para una transacción T con marca temporal ts(T), el protocolo de ordenación de marcas temporales funciona de la forma siguiente.
Capítulo 20 Gestión de transacciones
545
(1) La transacción T ejecuta un comando read(x)
(a) La transacción T solicita leer un elemento (x) que ya ha sido actualizado por una transacción más reciente (posterior), es decir ts(T) < write _timestamp(x). Esto significa que una transacción anterior está tratando de leer el valor de un elemento que ha sido actualizado por una transacción posterior. La transacción anterior ha llegado demasiado tarde para leer el valor anterior, que ya está desactualizado, y cualesquiera otros valores que haya adquirido serán probablemente incoherentes con el valor actualizado del elemento de datos. En esta situación, la transacción T deberá ser abortada y reiniciada con una marca temporal nueva (posterior). (b) En caso contrario, ts(T):2: write_timestamp(x) y la operación de lectura puede tener lugar. Entonces haremos read_timestamp(x) = max(ts(T), read_timestamp(x)). (2) La transacción T ejecuta un comando write(x)
(a) La transacción T solicita escribir un elemento (x) cuyo valor ya ha sido leído por una transacción más reciente, es decir ts(T) < read_timestamp(x). Esto significa que una transacción posterior está ya utilizando el valor actual del elemento y sería erróneo actualizarlo ahora. Esto sucede cuando una transacción llega tarde para hacer una escritura y otra transacción más reciente ya ha leído el valor antiguo o escrito uno nuevo. En este caso, la única solución es anular la transacción T y reiniciarla utilizando una marca temporal posterior. (b) La transacción T solicita escribir un elemento (x) cuyo valor ya ha sido escrito por otra transacción más reciente, es decir ts(T) < write _timestamp(x). Esto significa que la transacción T está tratando de escribir un valor obsoleto del elemento de datos x. La transacción T debe ser anulada y reiniciada utilizando una marca temporal posterior. (c) En caso contrario la operación write_timestamp(x) = ts(T).
de
escritura
puede
tener
lugar.
Entonces
haremos
Este esquema, denominado ordenación básica de marcas temporales, garantiza que las transacciones sean serializables en términos de conflictos y los resultados serán equivalentes a una planificación serie en la que las transacciones se ejecuten en el orden cronológico de las marcas temporales. En otras palabras, los resultados serán como si toda la transacción 1 se ejecutara completamente, después de lo cual se ejecutaráa la transacción 2, etc., sin ningún tipo de entrelazado. Sin embargo, la ordenación básica de marcas interporales no garantiza la obtención de planificaciones recuperables. Antes de mostrar cómo pueden usarse estas reglas para generar una planificación utilizando marcas temporales, vamos a examinar primero una pequeña variante de este protocolo que proporciona un mayor grado de concurrencia.
Regla de escritura de Thomas Puede utilizarse una modificación del protocolo básico de ordenación de marcas temporales que relaja la serializabilidad de conflictos, con el fin de proporcionar un mayor grado de concurrencia rechazando las operaciones de escritura obsoletas (Thomas, 1979). Esta extensión, denominada regla de Escritura de Thomas, modifica las comprobaciones relativas a una operación de escritura realizada por la transacción T de la forma siguiente: (a) La transacción T solicita escribir un elemento (x) cuyo valor ya ha sido leído por una transacción más reciente, es decir, ts(T) < read _timestamp(x). Como antes, se anula la transacción T y se la reinicia utilizando una marca temporal posterior. (b) La transacción T solicita escribir un elemento (x) cuyo valor ya ha sido escrito por una transacción más reciente, es decir ts(T) < write _timestamp(x). Esto significa que otra transacción posterior ya ha actualizado el valor del elemento y que el valor que la transacción más antigua está escribiendo debe estar basado en un valor obsoleto del elemento. En este caso, puede ignorarse con seguridad la operación de escritura. Esto se conoce en ocasiones como la regla de descarte de las escrituras obsoletas y permite un mayor grado de concurrencia. (c) En caso contrario, como antes, la operación de escritura puede tener lugar. En este caso hacemos write_timestamp(x) = ts(T).
546
Sistemas de bases de datos
La utilización de la regla de escritura de Thomas permite generar planificaciones que no habrían sido posibles con los otros protocolos de concurrencia explicados en esta sección. Por ejemplo, la planificación mostrada en la Figura 20.10 no es serializable en términos de conflictos. La operación de escritura de balx por parte de la transacción T I1 a continuación de la escritura por parte de T 12 sería rechazada y se necesitaría anular T I1 Y reiniciarla con una nueva marca temporal. Por contraste, utilizando la regla de Escritura de Thomas, esta planificación serializable en términos de vista sería válida sin necesidad de que ninguna transacción fuera anulada. En la siguiente sección vamos a examinar otro protocolo de marcas temporales que está basado en la existencia de múltiples versiones de cada elemento de datos.
I
Ejemplo 20.10
Ordenación
básica de marcas temporales
Ejecutamos tres transacciones concurrentemente, como se ilustra en la Figura 20.21. La transacción TI9 tiene una marca temporal tS(TI9), T20 tiene una marca temporal ts(T20) y T21 tiene una marca temporal ts(T21), de modo que tS(TI9) < ts(T20) < ts(T21). En el instante t8, la escritura por parte de la transacción T20 viola la primera regla de escritura, por lo que T20 es abortada y reiniciada en el instante t14. Asimismo, en el instante t14, la escritura por parte de la transacción TI9 puede ignorarse con seguridad utilizando la regla de descarte de escrituras obsoletas, ya que habría sido sobreescrita por la escritura de la transacción T21 en el instante t12•
Tiempo
Op
T20
ti
begin_transaction
t2
read(balx)
t3
balx = balx + 10
balx = balx + 10
t4
write(balx)
write(balx)
t5
read(baly)
read(baly)
t6
baly = baly + 20
baly
t7
read(baly)
t8
write(baly)
read(balx) begin_transaction baly + 20
begin_transaction read(baly)
write(baly)t
t9
baly = baly + 30
baly = baly + 30
tlO
write(baly)
write(baly)
tll
balz = 100
balz= 100
t12
write(balz)
tu
balz = 50
t14
write(balz)
t15
read(baly)
tl6
baly = baly + 20
tI?
write(baly)
write(balz) commit
balz = 50 write(balz)* commit
begin_transaction read(baly) baly = baly + 20 write(baly) commit
tl8
t En el instante t8, la escritura por parte de la transacción T20 viola la primera regla de escritura de marcas temporales descrita anteriormente y por tanto se aborta y se reinicia en el instante t14. En el instante t14, la escritura por parte de la transacción TI9 puede ignorarse con seguridad utilizando la
!
regla de descarte de escrituras obsoletas, ya que habría sido sobreescrita por la escritura de la transacción en el instante t12•
Figura 20.21.
Ejemplo de marcas temporales.
T21
Capítulo 20 Gestión de transacciones
547
Comparación de los métodos La Figura 20.22 ilustra la relación entre la serializabilidad de conflictos (CS, conflict serializability), la serializabilidad de vistas (view serializability), el bloqueo en dos fases (2PL, two-phase locking) y el marcado temporal (TS, timestamping). Como puede verse, la serializabilidad de vistas abarca los otros tres métodos, la serializabilidad de conflictos abarca a 2PL y al marcado temporal y 2PL Y el marcado temporal se solapan. Observe, en este último caso, que hay planificaciones que son comunes tanto a 2PL como al marcado temporal y que asimismo hay otras planificaciones que pueden ser producidas mediante 2PL pero no mediante el marcado temporal y viceversa.
20.2.6 Ordenación de marcas temporales multiversión También pueden usarse versiones de los datos para incrementar la concurrencia, ya que diferentes usuarios pueden trabajar concurrentemente sobre diferentes versiones del mismo objeto en lugar de tener que esperar a que se completen las transacciones de los otros usuarios. En caso de que el resultado parezca incorrecto en cualquier etapa, debe ser posible deshacer el trabajo realizado hasta alcanzar algún estado válido. El mecanismo de versiones ha sido utilizado como alternativa a los protocolos de control de concurrencia anudados y multinivel de los que hablaremos en la Sección 20.4 (por ejemplo, véase Beech y Mahbod, 1988; Chou y Kim, 1986, 1988). En esta sección vamos a examinar brevemente un esquema de control de concurrencia que utiliza las versiones para incrementar la concurrencia basándose en un mecanismo de marcas temporales (Reed, 1978; 1983). En la Sección 20.5 hablaremos brevemente de cómo utiliza Oracle este esquema para el control de concurrencia. El protocolo básico de ordenación de marcas temporales analizado en la sección anterior asume que sólo existe una versión de cada elemento de datos, por lo que sólo una transacción puede acceder al elemento de datos en cualquier momento. Esta restricción puede relajarse si permitimos que múltiples transacciones lean y escriban diferentes versiones del mismo elemento de datos y si garantizamos que cada transacción vea un conjunto coherente de transacciones para todos los elementos de datos a los que acceda. En el control de concurrencia multiversión, cada control de escritura crea una nueva versión de los elementos de datos mientras que retiene la antigua versión. Cuando una transacción trata de leer un elemento de datos, el sistema selecciona una de las versiones de forma que se garantice la serializabilidad. Para cada elemento de datos x, supongamos que la base de datos mantiene n versiones Xl' X2, ... , Xn' Para cada versión i, el sistema almacena tres valores: •
el valor de la versión
•
read_timestamp(x¡), que es la marca temporal de valor más alto de todas las transacciones leído con éxito la versión Xi;
•
write_timestamp(x¡), que es la marca temporal de la transacción que ha creado la versión
Xi;
Figura 20.22. Comparación de la serializabilidad de conflictos (CS), la serializabilidad de vistas (VS), el bloqueo en dos fases (2PL) y el marcado temporal (TS).
que hayan Xi'
548
Sistemas de bases de datos
Sea ts(T) la marca temporal de la transacción actual. El protocolo de ordenación de marcas temporales multiversión utiliza las siguientes dos reglas para garantizar la serializabilidad: (1) La transacción T ejecuta un comando write(x) Si la transacción T quiere escribir el elemento de datos x, debemos garantizar que el elemento de datos no haya sido ya leído por alguna otra transacción Ti tal que ts(T) < ts(T). Si permitimos que la transacción T realice esta operación de escritura, entonces para garantizar la serializabilidad el cambio que realice debería ser visto por Ti' pero resulta obvio que Ti no podrá leer dicho cambio, porque ya ha leído el valor. Por tanto, si la versión Xi tiene la marca temporal de escritura de mayor valor para el elemento de datos x dicho valor es igualo inferior a ts(T) (es decir, write_timestamp(x) :::;ts(T)) y read_timestamp(x) > ts(T), será necesario abortar la transacción T y reiniciarla con una nueva maca temporal. En caso contrario, creamos una nueva versión Xi de x y hacemos read_timestamp(x¡) = write_timestamp(x¡) = ts(T). (2) La transacción T ejecuta un comando read(x) Si la transacción T desea leer el elemento de datos x, debemos devolver la versión Xi que tenga la marca temporal de escritura de mayor valor para el elemento de datos x de tal manera que dicho valor sea igualo inferior a ts(T). En otras palabras, devolvemos write_timestamp(x) de manera que write_timestamp(x) :::;ts(T). A continuación hacemos read_timestamp(x) = max(ts(T), read_timestamp(x)). Observe que con este protocolo las operaciones de lectura nunca fallan. Las versiones pueden borrarse cuando ya no sean necesarias. Para determinar si una versión es necesaria, consultamos la marca temporal de la transacción más antigua que haya en el sistema. Entonces, para cualesquiera dos versiones Xi y Xi del elemento de datos X con marcas temporales inferiores a esta marca temporal más antigua, podremos borrar la versión menos reciente.
20.2.7 Técnicas optimistas En algunos entorno s, los conflictos entre las transacciones son raros y el procesamiento adicional requerido por los protocolos de bloqueo o de marcado temporal es innecesario para muchas de las transacciones. Las técnicas optimistas están basadas en la suposición de que los conflictos son raros y de que resulta más eficiente permitir que las transacciones continúen sin imponer ningún retardo para garantizar la serializabilidad (Kung y Robinson, 1981). Cuando una transacción desea confirmar los cambios realizados, se realiza una comprobación para determinar si se ha producido un conflicto. Si lo ha habido, la transacción deberá ser anulada y reiniciada. Dado que partimos de la suposición de que los conflictos ocurren de forma muy infrecuente, las anulaciones de transacciones serán también infrecuentes. El coste adicional de reiniciar una transacción puede ser considerable, ya que en la práctica implica rehacer la transacción completa. Este coste puede ser tolerable sólo si se incurre en él de manera muy infrecuente, en cuyo caso la mayoría de las transacciones serán procesadas sin verse sometidas a ningún retardo. Estas técnicas permiten potencialmente un mayor grado de concurrencia que los protocolos tradicionales, ya que no se requiere ningún tipo de bloqueo. Existen dos o tres fases en cualquier protocolo de control de concurrencia optimista, dependiendo de si se trata de una operación de sólo lectura o de actualización: •
Fase de lectura. Se extiende desde el inicio de la transacción hasta justo antes de la confirmación. La transacción lee los valores de todos los elementos de datos que necesita y los almacena en valores locales. Las actualizaciones se aplican a las copias locales de los datos, no a la propia base de datos .
•
Fase de validación. A continuación de la fase de lectura, se realizan una serie de comprobaciones para garantizar que la serializabilidad no será violada si se aplican las actualizaciones de la transacción a la base de datos. Para una transacción de sólo lectura, esto consiste en comprobar que los valores de datos leídos siguen siendo los valores actuales de los correspondientes elementos de datos. Si no se ha producido ninguna interferencia, se confirma la transacción. Si se ha producido una interferencia, la transacción se aborta y se re inicia. Para una transacción donde haya actualizaciones, la validación consiste en determinar si la transacción actual va a dejar a la base de datos en un estado coherente, manteniéndose la serializabilidad. Si no es así, la transacción se aborta y se reinicia.
Capítulo 20 Gestión de transacciones •
549
Fase de escritura. Después de la adecuada validación de las transacciones de actualización, entramos en la fase de escritura, durante la cual las actualizaciones realizadas en la copia local se aplican a la base de datos.
La fase de validación examina las lecturas y escrituras de las transacciones que puedan provocar alguna interferencia. A cada transacción T se le asigna una marca temporal al principio de su ejecución, start(T), otra al principio de su fase de evaluación, validation(T), y otra en el momento de finalizarfinish(1), incluyendo su fase de escritura en el caso de que haya una. Para pasar el test de validación, al menos una de las siguientes condiciones debe ser cierta: (1) Todas las transacciones
S con marcas temporales más antiguas deben haber finalizado antes de que la transacción T se iniciara; es decir fin ish (S) < start(T).
(2) Si la transacción T se ha iniciado antes de que terminara otra transacción anterior S entonces: (a) el conjunto de elementos de datos escrito por la transacción anterior no se corresponde con los elementos leídos por la transacción actual; y (b) la transacción anterior completa su fase de escritura antes de que la transacción actual entre en su fase de validación, es decir start(1)
20.2.8 Granularidad de los elementos de datos Granularidad
El tamaño de los elementos de datos seleccionados un protocolo de control de concurrencia.
como unidad de protección por
Todos los protocolos de control de concurrencia que hemos analizado asumen que la base de datos está compuesta por una serie de 'elementos de datos', sin definir explícitamente el término. Normalmente, un elemento de datos será uno de los siguientes objetos, yendo de una granularidad más gruesa a otra más fina, donde el término granularidad fina hace referencia a tamaños de elementos pequeños y el termino granularidad gruesa hace referencia a tamaños de elementos mayores: •
toda la base de datos;
•
un archivo;
•
una página (algunas veces denominada un área o espacio de la base de datos: una sección del disco físico en la que se almacenan las relaciones);
•
un registro;
•
el valor de un campo de un registro.
El tamaño o granularidad del elemento de datos que puede ser bloqueado en una única operación tiene un efecto significativo sobre el rendimiento global del algoritmo de control de concurrencia. Sin embargo, hay diversos compromisos que es posible considerar a la hora de seleccionar el tamaño del elemento de datos. Hablaremos de estos compromisos en el contexto de los mecanismos de bloqueo, aunque podrían utilizarse argumentos similares para otras técnicas de control de concurrencia.
550
Sistemas de bases de datos
Considere una transacción que actualice una única tupla de una relación. El algoritmo de control de concurrencia puede permitir que la transacción sólo bloquee esa única tupla, en cuyo caso el tamaño de gránulo para el bloqueo será un único registro. Por el contrario, el algoritmo podría bloquear toda la base de datos, en cuyo caso el tamaño de gránulo será la base de datos completa. En este segundo caso, la granularidad prevería que no se ejecutara ninguna otra transacción hasta que el bloqueo fuera liberado. Esto es claramente poco conveniente. Por otro lado, si una transacción actualiza el 95% de los registros de un archivo, sería más eficiente permitirla bloquear el archivo completo en lugar de que tenga que bloquear cada registro por separado. Sin embargo, al ir aumentado la granularidad desde el nivel de campo o de registro al nivel de archivo, puede incrementarse la probabilidad de que se produzcan interbloqueos. Por tanto, cuanto más grande sea el tamaño del elemento de datos, menor será el grado de concurrencia permitido. Por otro lado, cuanto más fino sea el tamaño de los datos, más información de bloqueo habrá que almacenar. El tamaño óptimo del elemento dependerá de la naturaleza de las transacciones. Si una transacción típica accede a un pequeño número de registros, será conveniente que la granularidad del elemento de datos se encuentre en el nivel de registro. Por el contrario, si una transacción accede normalmente a muchos registros del mismo archivo, puede que sea mejor disponer de granularidad del nivel de página o de archivo, de modo que la transacción considere todos esos registros como un único elemento de datos (o como un pequeño conjunto de elementos de datos). Se han propuesto algunas técnicas que tienen tamaños dinámicos de elementos de datos. Con estas técnicas, dependiendo de los tipos de transacción que se están ejecutando en cada momento, puede cambiarse el tamaño del elemento de datos para asignarle la granularidad que más apropiada resulte para dicha transacción. Idealmente, el SGBD debe soportar un sistema de granularidad mixta, con bloqueos de nivel de registro, página y archivo. Algunos sistemas mejoran automáticamente los bloqueos de nivel de registro o de página para asignarles nivel de archivo en aquellos casos en que una transacción concreta está bloqueando más de un cierto porcentaje de los registros o páginas del archivo.
Jerarquía de granularidad Podemos representar la granularidad de los bloqueos en una estructura jerárquica en la que cada nodo representa elementos de datos de tamaños diferentes, como se muestra en la Figura 20.23. Aquí, el nodo raíz representa la base de datos completa, los nodos del nivel l representan los archivos, los nodos del nivel 2 representan las páginas, los nodos del nivel 3 representan los registros y los nodos del nivel 4 representan campos individuales. Cada vez que se bloquea un nodo, todos sus descendientes también se ven bloqueados. Por ejemplo, si una transacción bloquea una página, Página2, todos los registros (Registro] y Registro2) así como todos los campos de éstos (Campo I y Campo2) serán también bloqueados. Si otra transacción solicita un bloqueo incompatible sobre el mismo nodo, el SGBD sabrá perfectamente que el bloqueo no puede concederse Si otra transacción solicita un bloqueo sobre cualquiera de los descendientes del nodo bloqueado, el SGBD comprobará la ruta jerárquica desde la raíz hasta el nodo solicitado para determinar si algunos de sus antecesores está bloqueado, antes de decidir si puede conceder el bloqueo. Por tanto, si lo que se solicita es un bloel SGBD comprobará su padre (Página2), su abuelo (Archivo2) y queo exclusivo sobre el registro (Registrol), la propia base de datos para determinar si alguno de ellos está bloqueado. Al encontrarse con que Página2 ya está bloqueada, niega la solicitud. Adicionalmente, una transacción puede solicitar un bloqueo sobre un nodo y encontrar que un descendiente de dicho nodo ya está bloqueado. Por ejemplo, si se solicita un bloqueo sobre Archivo2, el SGBD comprobará todas las páginas del archivo, todos los registros de dichas páginas y todos los campos de dichos registros para determinar si alguno de ellos está bloqueado.
Bloqueos de granularidad
múltiple
Para reducir la cantidad de operaciones de búsqueda implicadas en la ubicación de los bloqueos sobre los descendientes, el SGBD puede utilizar otra estrategia de bloqueo especializada denominada bloqueo de gran ularidad múltiple. Esta estrategia utiliza un nuevo tipo de bloqueo denominado bloqueo de intención (Gray et al., 1975). Cuando se bloquea cualquier nodo, se impone un bloqueo de intención a todos los antecesores del nodo. Así, si algún descendente de Archivo2 (en nuestro ejemplo, Página2) está bloqueado y se realiza
Capítulo 20 Gestión de transacciones
551
NivelO
Nivel 1
Nivel 2
Nivel 3
Nivel 4
Figura 20.23.
Niveles de bloqueo.
una solicitud de bloqueo sobre Archivoz, la presencia de un bloqueo de intención en Archivoz indica que algunos de los descendientes de dicho nodo ya está bloqueado. Los bloqueos de intención pueden ser compartidos (S, Shared), es decir, de lectura, o exclusivos (X, eXclusive), es decir, de escritura. Un bloqueo de intención compartido (IS) sólo entrará en conflicto con un bloqueo exclusivo; un bloqueo de intención exclusivo (IX) entrará en conflicto tanto con un bloqueo compartido como con otro exclusivo. Además, una transacción puede imponer un bloqueo compartido y de intención exclusivo (SIX) que es lógicamente equivalente a mantener tanto un bloqueo compartido como un bloqueo IX. Los bloqueos SIX entran en conflicto con cualquier otro bloqueo que esté en conflicto con un bloqueo compartido o con un bloqueo IX; en otras palabras, un bloqueo SIX sólo es compatible con un bloqueo IS. En la Tabla 20.1 se muestra una matriz de compatibilidad de bloqueos para el mecanismo de bloqueo de granularidad múltiple. Para garantizar la serializabilidad con los niveles de bloqueo, se utiliza un protocolo de bloqueo en dos fases de la forma siguiente: •
No puede concederse ningún bloqueo una vez que se haya desbloqueado algún nodo.
•
No puede bloquearse ningún nodo hasta que su padre haya sido bloqueado mediante un bloqueo de intención.
•
No puede desbloquearse ningún nodo hasta que todos sus descendientes hayan sido bloqueados.
De esta forma, los bloqueos se aplican yendo desde la raíz hacia abajo aplicando bloqueos de intención, hasta alcanzar el nodo que requiere el bloqueo compartido o exclusivo; para levantar los bloqueos, se pro-
552
Sistemas de bases de datos
5./ ./
X IX 5 1X X Tabla 20.1. X Tabla de compatibilidad de bloqueos para los bloqueos de granularidad múltiple. 15
cede de abajo hacia arriba. De todos modos, continúa siendo posible que aparezcan interbloqueos, deberán gestionarse como hemos explicado anteriormente.
y éstos
20.3 Recuperación de la base de datos Recuperación de la base de datos
El proceso de la restauración de la base de datos a un estado correcto en caso de fallo.
Al principio de este capítulo hemos introducido el concepto de recuperación de la base de datos como servicio que el SGBD debe proporcionar para garantizar que la base de datos sea fiable y permanezca en un estado coherente aún cuando se produzcan fallos. En este contexto, el término fiabilidad hace referencia tanto a la resistencia del SGBD a diversos tipos de fallos como a su capacidad de recuperarse de ellos. En esta sección vamos a analizar cómo puede proporcionarse este servicio. Para comprender mejor los problemas potenciales con los que nos podemos encontrar a la hora de proporcionar un sistema fiable, comenzaremos examinando la necesidad de la recuperación y los tipos de fallos que pueden producirse en un entorno de base de datos.
20.3.1
La necesidad de la recuperación
El almacenamiento de los datos incluye generalmente cuatro tipos diferentes de medios, en orden creciente de fiabilidad: memoria principal, disco magnético, cinta magnética y disco óptico. La memoria principal es el almacenamiento volátil que normalmente no sobrevive a las paradas catastróficas del sistema. Los discos magnéticos proporcionan almacenamiento no volátil en línea. Comparados con la memoria principal, los discos son más fiables y mucho más baratos, pero tres o cuatro órdenes de magnitud más lentos. La cinta magnética es un medio de almacenamiento no volátil fuera de línea que es bastante más fiable que los discos y también bastante barato, pero mucho más lento, ya que sólo proporciona acceso secuencia!. Los discos ópticos son más fiables que las cintas, generalmente más baratos, más rápidos y proporcionan acceso aleatorio. La memoria principal también se denomina almacenamiento principal, mientras que los discos y las cintas se considera almacenamiento secundario. El término almacenamiento estable hace referencia a información que ha sido replicada en varios medios de almacenamiento no volátil (usualmente discos) con modos de cable independientes. Por ejemplo, puede ser posible simular un almacenamiento estable utilizando tecnología RAID (Redundant Array of Independent Disks), lo que garantiza que el fallo de un único disco, incluso durante la transferencia de datos, no resulte una pérdida de datos (véase la Sección 19.2.6). Hay muchos tipos diferentes de fallos que pueden afectar al procesamiento de la base de datos, cada uno de los cuales debe ser tratado de una manera distinta. Algunos fallos afectan sólo a la memoria principal, mientras que otros afectan al almacenamiento no volátil (secundario). Entre las causas de fallos se encuentran:
Capítulo 20 Gestión de transacciones
553
•
las paradas catastróficas del sistema debido a errores del hardware o del software, que tienen como resultado la pérdida del contenido de la memoria principal;
•
los fallos de soporte físico, como por ejemplo los aterrizajes de cabezales de disco o los soportes no legibles, lo que produce la pérdida de parte de la información guardada en almacenamiento secunda-
no; •
los errores software de las aplicaciones, como por ejemplo errores lógicos en el programa que está accediendo a la base de datos, que hacen que una o más de las transacciones fallen;
•
los desastres físicos naturales, como incendios, inundaciones, terremotos o apagones;
•
la destrucción negligente o no intencionada de datos o instalaciones por parte de operadores o usua-
nos; •
el sabotaje, o corrupción o destrucción intencionada de los datos, del hardware, del software o de las instalaciones.
Sea cual sea la causa del fallo, son dos los efectos principales que tendremos que considerar: la pérdida del contenido de la memoria principal, incluyendo los búferes de la base de datos, y la pérdida de la copia del disco de la base de datos. En el resto de este capítulo, vamos a hablar de los conceptos de la recuperación y de las técnicas que pueden ayudar a minimizar estos efectos y a permitir que la base de datos se recupere de un fallo.
20.3.2 Transacciones y recuperación Las transacciones representan la unidad de recuperación básica en un sistema de base de datos. Es responsabilidad del gestor de recuperación garantizar dos de las cuatro propiedades ACID de las transacciones, la atomicidad y la permanencia, en presencia de fallos. El gestor de recuperación tiene que garantizar que al recuperarse de un fallo, todos los efectos de una transacción dada sean almacenados permanente en la base de datos o que no se almacene ninguno de ellos. La situación se complica por el hecho de que la escritura en la base de datos no es una acción atómica (de un sólo paso) por lo que es posible que una transacción se haya confinnado y, sin embargo, sus efectos no hayan sido grabados permanentemente en la base de datos, simplemente porque no han llegado a alcanzar ésta. Considere de nuevo el primer ejemplo de este capítulo, en el que estábamos incrementando el salario de un empleado, como se muestra a alto nivel en la Figura 20.1(a). Para implementar la operación de lectura, el SGBD lleva a cabo los siguientes pasos: •
localiza la dirección del bloque de disco que contiene el registro cuyo valor de clave principal es x;
•
transfiere el bloque de disco a un búfer de la base de datos en memoria principal;
•
copia los datos de salario del búfer de la base de datos en la variable salary.
Para la operación de escritura, el SGBD lleva a cabo los siguientes pasos: •
localiza la dirección del bloque de disco que contiene el registro cuyo valor de clave principal es x;
•
transfiere el bloque de disco a un búfer de la base de datos en memoria principal;
• •
copia los datos salariales de la variable salary en el búfer de la base de datos; escribe el búfer de la base de datos en el disco.
Los búferes de la base de datos ocupan un área en la memoria principal desde la cual los datos se transfieren hacia y desde el almacenamiento secundario. Sólo una vez que los búferes hayan sido volcados en el almacenamiento secundario podremos considerar las operaciones de actualización como pennanentes. Este volcado de los búferes de la base de datos puede ser iniciado por un comando específico (por ejemplo, por la confinnación de una transacción) o puede producirse automáticamente cuando los búferes se llenen. La escritura explícita de los búferes en el almacenamiento secundario se conoce con el nombre de escritura forzada. Si se produce un fallo entre la escritura en los búferes y el volcado de los búferes en el almacenamiento secundario, el gestor de recuperación deberá detenninar el estado de la transacción que realizó la escritura en
554
Sistemas de bases de datos
el momento del fallo. Si la transacción ya hubiera ejecutado su confirmación, el gestor de recuperación deberá (para garantizar la permanencia) rehacer las actualizaciones que dicha transacción hubiera efectuado en la base de datos (proceso que se conoce también con el nombre de reaplicación). Por otro lado, si la transacción no hubiera efectuado la confirmación en el momento del fallo, el gestor de recuperación tendrá que deshacer (anular) todos los efectos que dicha transacción hubiera producido en la base de datos, con el fin de garantizar la atomicidad de la transacción. Si sólo hay que deshacer una transacción, esto se denomina anulación parcial. Una anulación parcial puede ser iniciada por el planificador cuando se deshace y reinicia una transacción como resultado de la operación de un protocolo de control de concurrencia, como hemos descrito en la sección anterior. Una transacción también puede ser abortada unilateralmente, por ejemplo por el usuario o por una condición de excepción dentro del programa de aplicación. Cuando todas las transacciones activas tienen que ser deshechas, denominamos a esto anulación global.
I
Ejemplo 20.11
Utilización
de UNDO/REDO
La Figura 20.24 ilustra una serie de transacciones TI' ... , T6 que se ejecutan concurrentemente. El SGBD comienza en el instante tú pero sufre un fallo en el instante tf• Vamos a suponer que los datos de las transacciones T2 y T3 ya han sido escritos en el almacenamiento secundario antes del fallo. Claramente, TI y T6 no han efectuado la confirmación en el momento del fallo, por lo que el gestor de recuperación deberá, después del reinicio, deshacer las transacciones TI y T6' Sin embargo, no está claro hasta qué punto se han propagado a la base de datos o al almacenamiento no volátil los cambios realizados por las otras transacciones (confirmadas) T4 y Ts. La razón de esta incertidumbre es el hecho de que los búferes volátiles de la base de datos pueden o no haber sido escritos en disco. En ausencia de cualquier otra información, el gestor de recuperación se vería forzado a rehacer las transacciones T2, T3,
T3
T2
T4 Y Ts·
I
T1
T4 Ts T6
I
I
Figura 20.24.
Ejemplo de UNDO/REDO.
Gestión de búferes La gestión de los búferes de la base de datos juega un papel importante en el proceso de recuperación y vamos a hablar brevemente de cómo gestionarlos antes de continuar. Como hemos mencionado al principio de este capítulo, el gestor de búferes es responsable de la gestión eficiente de los búferes de la base de datos que se utilizan para transferir páginas hacia y desde el almacenamiento secundario. Esto implica leer páginas de disco en los búferes hasta que los búferes se llenen y luego utilizar una estrategia de sustitución para decidir a qué búferes habrá que aplicar una escritura forzada en disco con el fin de dejar sitio para las nuevas páginas que haya que leer del disco. Como ejemplos de estrategias de sustitución tendríamos la estrategia FIFO
Capítulo 20 Gestión de transacciones
555
(jirst- in-jirst-out, primero en entrar primero en salir) y LRU (least recently used, menos recientemente utilizado). Además, el gestor de búferes debe evitar leer una página del disco si ésta ya se encuentra en el búfer de la base de datos. Una técnica consiste en asociar dos variables con la información de gestión correspondiente a cada búfer de la base de datos: pinCount (recuento de fijación) y dirty (sucio), que inicialmente reciben un valor cero para cada búfer de la base de datos. Cuando se solicita una página de un disco, el gestor de búferes comprueba si la página ya se encuentra en uno de los búferes de la base de datos. En caso contrario, el gestor de búferes hará lo siguiente: (1) utilizar la estrategia de sustitución para seleccionar el búfer que hay que sustituir (al cual denominaremos búfer de sustitución) e incrementar su valor pinCount. La página solicitada estará ahora fija en el búfer de la base de datos y no puede todavía volverse a escribir en disco. La estrategia de sustitución se establece de tal manera que nunca se seleccionará un búfer que haya sido fijado; (2) si la variable
dirty
para el búfer de sustitución está activada, escribirá el búfer en disco;
(3) leerá la página del disco en el búfer de sustitución y reinicializará la variable do la el valor cero.
dirty
del búfer, asignán-
Si se vuelve a solicitar la misma página, se incrementará el valor apropiado de pinCount en l. Cuando el sistema informa al gestor de búferes de que ha terminado con la página, se decrementará el valor pinCount apropiado en l. En este punto, el sistema también informará al gestor de búferes si ha modificado la página, y la variable dirty será configurada de forma correspondiente. Cuando una variable pinCount alcanza el valor cero, la página se libera y puede volver a ser escrita en disco si ha sido modificada (es decir, si la variable dirty está activada). Se utiliza la siguiente terminología en lo que respecta a la recuperación de bases de datos a la hora de escribir páginas del nuevo disco: •
Una política de robo permite al gestor de búferes escribir un búfer en disco antes de que la transacción confirme sus operaciones (se quita al búfer el carácter de fijo). En otras palabras, el gestor de búferes 'roba' una página de la transacción. La política alternativa sería la de no robo.
•
Una política forzada garantiza que todas las páginas actualizadas por una transacción sean inmediatamente escritas en disco cuando la transacción se confirma. La política alternativa es la no forzada.
El enfoque más simple desde una perspectiva de implementación consiste en utilizar una política forzada de no robo: con el no robo no necesitaremos deshacer los cambios de una transacción abortada, porque dichos cambios no habrán sido escritos en disco, mientras que con la política forzada no será necesario rehacer los cambios de una transacción confirmada si posteriormente se produce una parada catastrófica, porque todos esos cambios habrán sido escritos en disco en el momento de la confirmación. El protocolo de recuperación con actualización diferida, del que hablaremos en breve, utiliza una política de no robo. Por el contrario, la política de robo evita tener que utilizar un espacio de búfer muy grande para almacenar todas las páginas actualizadas por un conjunto de transacciones concurrentes, lo que además puede que no sea posible en muchas ocasiones. Además, la política no forzada tiene la ventaja de no tener que reescribir una página en disco para una transacción posterior que haya sido actualizada por una transacción previamente confirmada y que pueda todavía estar en el búfer de la base de datos. Por estas razones, la mayor parte de los SGBD utiliza una política de robo no forzada.
20.3.3 Funcionalidades de recuperación Un SGBD debe proporcionar las siguientes funcionalidades
como ayuda a la recuperación:
•
un mecanismo de copia de seguridad mediante el que se hagan copias de seguridad periódicas de la base de datos;
•
facilidades de registro que mantengan el control del estado actual de las transacciones bios realizados en la base de datos;
y de los cam-
556
Sistemas de bases de datos
•
una funcionalidad de puntos de comprobación que permita que las actualizaciones de la base de datos que estén llevándose a cabo se hagan permanentes;
•
un gestor de recuperación que permita al sistema restaurar la base de datos a un estado coherente después de un fallo.
Mecanismo de copia de seguridad El SGBD debe proporcionar un mecanismo que permita realizar copias de seguridad de la base de datos y del archivo de registro (del que hablaremos a continuación) a intervalos periódicos sin necesidad de detener primero el sistema. La copia de seguridad de la base de datos puede utilizarse en caso de que ésta resulte dañada o destruida. La copia de seguridad puede ser una copia completa de la base de datos o una copia incremental, compuesta sólo por las modificaciones realizadas desde la última copia incremental o completa. Normalmente, las copias de seguridad se guardan en almacenamiento fuera de línea, como por ejemplo en cinta magnética.
Archivo de registro Para controlar las transacciones de la base de datos que se van haciendo, el SGBD mantiene un archivo especial denominado registro (o diario) que contiene información sobre todas las actualizaciones realizadas en la base de datos. El registro puede contener los datos siguientes: •
Registros de transacciones, que contienen: • identificador de la transacción; • tipo de la entrada de registro (inicio de la transacción, inserción, actualización, borrado, aborto de la transacción, confirmación); • identificador del elemento de datos afectado por la operación de base de datos (para las operaciones de inserción, borrado y actualización); • imagen anterior del elemento de datos, es decir, su valor antes de la modificación (sólo para las operaciones de actualización y borrado); • imagen posterior del elemento de datos, es decir, su valor después de la modificación (sólo para las operaciones de actualización y borrado); • información de gestión del registro, como por ejemplo un puntero a las entradas anterior y siguiente del registro correspondientes a dicha transacción (para todas las operaciones).
•
Registros de comprobación, de los que hablaremos en breve.
El registro se utiliza a menudo para otros propósitos distintos de la recuperación (por ejemplo, para auditoría y para monitorización del rendimiento). En este caso, puede que se registre información adicional en el archivo de registro (por ejemplo, las lecturas de la base de datos, los inicios de sesión de usuario, los fines de sesión, etc.), pero todos estos datos no son relevantes para la recuperación y por tanto los omitiremos de nuestras explicaciones. La Figura 20.25 ilustra un segmento y un archivo de registro que muestra tres transacciones TI, T2 Y T3 que se están ejecutando concurrentemente. Las columnas pPtr y nPtr representan punteros a las entradas de registro anterior y siguiente de cada transacción. Debido a la importancia del archivo de registro de transacciones en el proceso de recuperación, es posible que el registro esté duplexado o triplexado (es decir, que se mantengan dos o tres copias independientes) de modo que si una de las copias es dañada pueda utilizarse otra. En el pasado, los archivos de registro se almacenaban en cinta magnética, porque la cinta era más fiable y barata que los discos magnéticos. Sin embargo, hoy en día se espera que los SGBD sean capaces de recuperarse rápidamente de los fallos menores. Esto requiere que el archivo de registro se almacene en línea en un dispositivo de almacenamiento rápido y de acceso directo. En algunos entornos donde se genera a diario una cantidad enorme de información de registro (no resulta nada rara una tasa de registro diaria de 104 megabytes), no es posible mantener en línea todos estos datos en todo momento. El archivo de registro tiene que estar en línea para recuperarse rápidamente de pequeños fallos (por ejemplo, de la anulación de una transacción después de un interbloqueo). Los fallos graves, como por
Capítulo 20 Gestión de transacciones 557 Tid T2
posterior
7 STAFF SA9 11 O 10:14 START 10:13 CHECKPOINT 12 10:21 lNSERT 425UPDATE OOperaciónObjeto COMMIT 10:12 6O INSERT SG37 DELETE PG4 16 (nuevo valor) 10:18 98nptr SL21 Tiempo 10:20 PROPERTY PG4 Imagen 10:19 10:16 10:17 513(nuevo T2, T3valor) Imagen anterior pptr (valor antiguo) (nuevo valor)
Figura 20.25.
11 6OO 2
Un segmento de un archivo de registro.
ejemplo un aterrizaje de cabezales en un disco, exigen, obviamente, un mayor tiempo de recuperación y pueden requerir que se acceda a una parte considerable del registro. En estos casos, resulta aceptable tener que esperar a que partes del registro vuelvan a ser puestas en línea a partir de la información guardada en los soportes fuera de línea. Una técnica para gestionar el paso a fuera de línea del archivo de registro consiste en dividir el registro en línea en dos archivos de registro aleatorio independiente. Las entradas de registro se escriben en el primer, archivo hasta que éste alcanza un límite superior de ocupación, por ejemplo el 70%. Entonces se abre un segundo archivo de registro y todas las entradas de registro correspondientes a las nuevas transacciones se escriben en este segundo archivo. Las transacciones antiguas continúan utilizando el primer archivo hasta que tenuinan, en cuyo momento se cierra el primer archivo y se lo transfiere a un soporte fuera de línea. Esto significa la recuperación de una única transacción, ya que todas las entradas de registro para dicha transacción estarán o bien en línea o bien fuera de línea. Debe observarse que el archivo de registro es un cuello de botella potencial y que la velocidad de las escrituras en el archivo de registro puede ser crítica a la hora de determinar las prestaciones globales del sistema de base de datos.
Puntos de comprobación La información del archivo de registros se utiliza para recuperarse después de un fallo de la base de datos. Una dificultad en este esquema es que cuando se produce un fallo podemos no saber cuánto hay que retroceder en el archivo de registro, por lo que podría llegar a darse el caso de que reiniciáramos transacciones que ya hubieran sido adecuadamente escritas en la base de datos. Para limitar las operaciones de búsqueda en el registro y el subsiguiente procesamiento, podemos utilizar una técnica denomina establecimiento de puntos de comprobación (checkpointing). Punto de comprobación
El punto de sincronización entre la base de datos y el archivo de registro de transacciones. Todos los búferes se escriben de manera forzada en el almacenamiento secundario.
Los puntos de comprobación se programan a intervalos predeterminados cIOnes:
e implican las siguientes opera-
•
escribir en el almacenamiento
secundario todas las entradas de registro de la memoria principal;
•
escribir en el almacenamiento
secundario los bloques modificados de los búferes de la base de datos;
•
escribir una entrada de punto de comprobación en el archivo de registro. Esta entrada contendrá los identificadores de todas las transacciones que estén activas en el punto de comprobación.
Si las transacciones se realizan en serie, cuando se produzca un fallo comprobaremos el archivo de registro para localizar la última transacción que se iniciará antes del último punto de comprobación. Todas las
558
Sistemas de bases de datos
transacciones anteriores ya habrán sido confirmadas y habrán sido escritas en la base de datos en el punto de comprobación, por lo que sólo será necesario rehacer la transacción que estuviera activa en el punto de comprobación y todas las transacciones subsiguientes para las que el registro contenga tanto entradas de inicio como entradas de confirmación. Si una transacción estuviera activa en el momento del fallo, dicha transacción deberá ser anulada. Si las transacciones se ejecutan concurrentemente, tendremos que rehacer todas las transacciones que se hayan confirmado desde el punto de comprobación y deshacer todas las transacciones que estuvieran activas en el momento del fallo.
I
Ejemplo 20.12
Utilización
UNDO/REDO con puntos de comprobación
Volviendo al Ejemplo 20.11, si ahora asumimos que en el instante te se produce un punto de comprobación, sabríamos que los cambios realizados por las transacciones T2 y T3 habrán sido escritos en el almacenamiento secundario. En este caso, el gestor de recuperación podrá omitir la operación de rehacer estas dos transacciones. Sin embargo, el gestor de recuperación sí que tendrá que rehacer las transacciones T4 y Ts, que habían efectuado la confirmación después del último punto de comprobación y deshacer las transacciones TI y
T6,
que estaban activas en el momento del fallo.
---.J
Generalmente, la realización de puntos de comprobación es una operación relativamente poco costosa, y a menudo es posible realizar tres o cuatro puntos de comprobación cada hora. De esta forma, no será necesario recuperar más de 15 o 20 minutos de trabajo.
20.3.4 Técnicas de recuperación El procedimiento de recuperación concreto que haya que utilizar dependerá del nivel de daños que la base de datos haya sufrido. Vamos a considerar dos casos: •
•
Si la base de datos ha sufrido daños considerables, por ejemplo porque se ha producido un aterrizaje de los cabezales de disco y la base de datos ha quedado destruida, será necesario restaurar la última copia de seguridad de la base de datos y volver a aplicar las operaciones de actualización de las transacciones confirmadas utilizando el archivo de registro. Esto supone, por supuesto, que el propio archivo de registro no haya resultado también dañado. En el Paso 8 de la metodología de diseño físico de la base de datos presentada en el Capítulo 18 se recomendaba que se almacenara el archivo de registro, siempre que fuera posible, en un disco independiente del de los archivos principales de la base de datos. Esto reduce el riesgo de que los archivos de base de datos y el archivo de registro resulten dañados al mismo tiempo . Si la base de datos no ha resultado físicamente dañada pero ha quedado en un estado incoherente, por ejemplo porque el sistema sufre una parada catastrófica mientras se estaban ejecutando transacciones, será necesario deshacer los cambios que han provocado dicha incoherencia. Puede que también sea necesario rehacer algunas transacciones para garantizar que las actualizaciones realizadas por éstas alcancen el almacenamiento secundario. En este caso, no necesitamos utilizar la copia de seguridad de la base de datos, sino que podemos restaurar ésta a un estado coherente utilizando las imágenes anteriores y posteriores almacenadas en el archivo de registro.
Vamos a examinar ahora dos técnicas para recuperarse de esta última situación, es decir, del caso en el que la base de datos no haya resultado destruida pero haya quedado en un estado incoherente. Dichas técnicas, denominadas de actualización diferida y de actualización inmediata, difieren en la forma en que se escriben las actualizaciones en almacenamiento secundario. También examinaremos probablemente otra técnica alternativa denominada de páginas en espejo.
Técnicas de recuperación
utilizando actualizaciones
diferidas
Empleando el protocolo de recuperación de actualización diferida, las actualizaciones no se escriben en la base de datos hasta después de que una transacción alcance su punto de confirmación. Si una transacción falla
Capítulo 20 Gestión de transacciones
559
antes de alcanzar este punto, no se habrá modificado la base de datos y no será necesario deshacer el cambio. Sin embargo, sí que puede ser necesario rehacer las actualizaciones de las transacciones confirmadas, ya que su efecto puede no haber alcanzado la base de datos. En este caso, utilizamos el archivo de registro para protegemos frente a fallos del sistema de la siguiente manera: •
Cuando una transacción comienza, se escribe una entrada de inicio de transacción en el registro.
•
Cuando se realiza una operación de escritura, se escribe una entrada de registro que contiene todos los datos de registro anteriormente especificados (excluyendo la imagen anterior de la actualización). La actualización no se escribe ni en los búferes de la base de datos ni en la propia base de datos.
•
Cuando una transacción está a punto de confirmarse, se escribe una entrada de registro de confirmación de transacción, se escriben todas las entradas de registro de la transacción en disco y se confirma la transacción. Se utilizan las entradas de registro para llevar a cabo las actualizaciones en la base de datos.
•
Si la transacción se aborta, se ignoran las entradas de registro de la transacción y no se realizan las escrituras.
Observe que escribimos las entradas de registro en disco antes de que la transacción sea confirmada, por lo que si se produce un fallo del sistema mientras que se están llevando a cabo las propias actualizaciones de la base de datos, las entrada de registro sobrevivirán y las actualizaciones pueden volver a ser aplicadas posteriormente. En caso de fallo, examinamos el registro para identificar las transacciones que estaban llevándose a cabo en el momento del fallo. Comenzando con la última entrada del archivo de registro, recorremos éste hacia atrás hasta alcanzar la entrada más reciente de punto de comprobación: •
Todas las transacciones con entradas de registro de inicio de transacción y de corifirmación de transacción deben rehacerse. El procedimiento de rehacer lleva a cabo todas las escrituras en la base de datos utilizando las entradas de registro de imagen posterior correspondientes a las transacciones, en el orden en que fueron escritas en el registro. Si esta escritura ya ha sido realizada anteriormente, antes del fallo, la escritura no tendrá ningún efecto sobre el elemento de fallos, por lo que no pasa nada por volver a escribir los datos de nuevo (es decir, la operación es idempotente). Sin embargo, este método garantiza que se actualicen todos los elementos de datos que no hubieran sido adecuadamente actualizados antes del fallo.
•
Para todas las transacciones con entradas de registro de inicio de transacción y de aborto de transacción, no tenemos que hacer nada, ya que no se realizó ninguna escritura en la base de datos, por lo que estas transacciones no tienen que ser deshechas.
Si se produce una segunda parada catastrófica del sistema durante la recuperación, se vuelven a utilizar las entradas de registro para restaurar la base de datos. Dada la forma que tienen las entradas de registro de escritura, no importa cuántas veces volvamos a realizar dichas escrituras.
Técnicas de recuperación
utilizando la actualización
inmediata
Utilizando el protocolo de recuperación de actualización inmediata, las actualizaciones se aplican a la base de datos según van teniendo lugar, sin esperar a alcanzar el punto de confirmación. Además de tener que rehacer las actualizaciones de las transacciones confirmadas después de un fallo, puede que ahora fuera también necesario deshacer los efectos de las transacciones que no se hubieran confirmado en el momento del fallo. En este caso, utilizamos el archivo de registro para protegemos frente a los fallos del sistema de la siguiente manera: • •
Cuando comienza una transacción, se escribe una entrada de inicio de transacción en el registro. Cuando se realiza una operación de escritura, se escribe una entrada con los datos necesarios en el archivo de registro.
•
Una vez escrita la entrada de registro, se escribe la actualización en los búferes de la base de datos.
•
Las propias actualizaciones en la base de datos se escriben cuando posteriormente res en el almacenamiento secundario.
se vuelcan los búfe-
560 •
Sistemas de bases de datos Cuando se confirma la transacción, se escribe una entrada de confirmación gistro.
de transacción en el re-
Es esencial que las entradas de registro (o al menos ciertas partes de ellas) se escriban antes de la correspondiente escritura en la base de datos. Esto se conoce con el nombre de protocolo de registro con escritura anticipada. Si se hicieran primero las actualizaciones en la base de datos y ocurriera una fallo antes de escribir la entrada de registro, el gestor de recuperación no tendría forma de deshacer (o rehacer) la operación. Con el protocolo de registro de escritura anticipada, el gestor de recuperación puede dar por supuesto sin ningún problema que si no hay una entrada de confirmación de transacción en el archivo de registro para una transacción concreta, dicha transacción todavía estaba activa en el momento del fallo y debe por tanto ser deshecha. Si una transacción se aborta, puede utilizarse el registro para deshacerla, ya que contiene todos los antiguos valores para los campos actualizados. Puesto que una transacción puede haber realizado varios cambios en un elemento, las escrituras se realizan en orden inverso. Independientemente de si las escrituras de la transacción son aplicadas a la propia base de datos, la escritura de las imágenes anteriores garantiza que se restaure la base de datos a su estado anterior al inicio de la transacción. Si el sistema falla, la recuperación implica utilizar el registro para deshacer o rehacer transacciones: •
Para todas las transacciones en las que el registro contenga tanto una entrada de inicio de transacción como de confirmación de transacción, rehacemos la transacción utilizando las entradas de registro con el fin de escribir la imagen posterior de los campos actualizados como hemos descrito anteriormente. Observe que si los nuevos valores ya han sido escritos en la base de datos, estas otras escrituras, aunque innecesarias, no tendrán ningún efecto. Sin embargo, cualquier escritura que no hubiera llegado a alcanzar a la base de datos será ahora realizada correctamente.
•
Para todas las transacciones para las que el registro contenga una entrada de inicio de transacción pero no una entrada de confirmación de transacción, necesitaremos deshacer esas transacciones. Esta vez, se utilizan las entradas de registro para escribir la imagen anterior de los campos afectados y así restaurar la base de datos a su estado previo al inicio de la transacción. Las operaciones de deshacer se realizan en el orden inverso al que fueron escritas en el registro.
Páginas en espejo Una alternativa a los esquemas de recuperación basados en registro que acabamos de describir son las páginas en espejo (Lorie, 1977). Este esquema mantiene dos tablas de páginas durante la vida de la transacción: una tabla de páginas actuales y una tabla de páginas espejo. Cuando se inicia la transacción, las dos tablas de páginas son iguales. La tabla de páginas en espejo nunca cambia a partir de ahí y se utiliza para restaurar la base de datos en caso de fallo del sistema. Durante la transacción, la tabla de páginas actuales se utiliza para registrar todas las actualizaciones realizadas en la base de datos. Cuando se completa la transacción, la tabla de páginas actuales se convierte en la tabla de páginas en espejo. Las páginas en espejo tienen diversas ventajas sobre los sistemas basados en registro: se elimina el coste adicional de mantener el archivo de registro y la recuperación es significativamente más rápida, ya que no existe la necesidad de deshacer o rehacer operaciones. Sin embargo, también tiene ciertas desventajas, como son la fragmentación de datos y la necesidad de realizar una recolección periódica de memoria para reclamar los bloques inaccesibles.
20.3.5
Recuperación en un SGBD distribuida
En los Capítulos 22 y 23 hablaremos de los SGBD distribuidos (SGBDD), que están compuestos por una colección lógicamente interrelacionada de bases de datos físicamente distribuidas en una red informática y cada una de ellas bajo control de un SGBD local. En un SGBDD, las transacciones distribuidas (transacciones que acceden a datos que están situados en más de una ubicación) se dividen en una serie de subtransacciones, una para cada ubicación a la que haya que acceder. En este tipo de sistemas, la atomicidad debe ser mantenida tanto para las subtransacciones como para la transacción global. Las técnicas descritas anteriormente pueden utilizarse para garantizar la atomicidad de las subtransacciones. Por su parte, garantizar la ato-
Capítulo 20 Gestión de transacciones
561
micidad de la transacción global implica garantizar que o bien todas las subtransacciones se confirmen o bien todas ellas se aborten. Los dos protocolos más comunes para la recuperación distribuida se conocen con el nombre de confirmación en dos fases (2PC, two-phase commit) y confirmación en tres fases (3PC, threephase commit) y los examinaremos en la Sección 23.4.
20.4 Modelos avanzados de transacciones Los protocolos de transacciones que hemos analizado hasta el momento en este capítulo son adecuados para los tipos de transacciones que surgen en las aplicaciones empresariales tradicionales, como por ejemplo las del sector bancario o los sistemas de reservas de las líneas aéreas. Estas aplicaciones se caracterizan por: •
la naturaleza simple de los datos, como por ejemplo enteros, números decimales, cadenas de caracteres cortas y fechas;
•
la corta duración de las transacciones, que normalmente terminan en unos pocos minutos, o incluso en segundos.
En la Sección 25.1 se examinan los tipos más avanzados de aplicaciones de bases de datos que han aparecido en los últimos años. Por ejemplo, aplicaciones de diseño tales como el diseño asistido por computadora, la fabricación asistida por computadora y la ingeniería del software asistida por computadora que tienen algunas características comunes que difieren de las de las aplicaciones tradicionales de bases de datos: •
Un diseño puede ser muy grande, quizás llegando a estar compuesto de millones de componentes y a menudo con muchos diseños de subsistemas interdependientes.
•
El diseño no es estático sino que evoluciona a lo largo del tiempo. Cuando se produce un cambio de diseño, sus implicaciones deben propagarse a todo lo largo de todas las representaciones del diseño. La naturaleza dinámica del diseño implica que algunas de las acciones que habrá que tomar no pueden preverse.
•
Las actualizaciones tienen un largo alcance debido a las relaciones topológicas, a las relaciones funcionales, a las tolerancias, etc. Un cambio puede probablemente afectar a un gran número de objetos de diseño.
•
A menudo, se consideran muchas alternativas de diseño para cada componente y es necesario mantener la versión correcta de cada pieza. Esto implica algún tipo de mecanismo de control de versiones y de gestión de configuración.
•
Puede haber centenares de personas implicadas en el diseño y dichas personas pueden trabajar en paralelo sobre múltiples versiones de un diseño mayor. Aún así, el producto final debe ser coherente y coordinado. Esto se denomina en ocasiones ingeniería cooperativa. La cooperación puede requerir un alto grado de interacción y compartición entre diversas actividades concurrentes.
Algunas de estas características dan como resultado transacciones muy complejas, que acceden a muchos elementos de datos y que son de gran duración, pudiendo durar horas, días o incluso meses. Estos requisitos nos fuerzan a volver a examinar los protocolos tradicionales de gestión de transacciones para resolver los siguientes problemas: •
Como resultado del elemento temporal, una transacción de larga duración es más susceptible a fallos. Sería inaceptable abortar este tipo de transacción y perder potencialmente una cantidad significativa de trabajo. Por tanto, para minimizar la cantidad de trabajo perdida, necesitamos recuperar la transacción a un estado próximo al momento del fallo.
•
De nuevo, como resultado del elemento temporal, una transacción de larga duración puede acceder (por ejemplo, bloquear) a un gran número de elementos de datos. Para presentar el aislamiento de las transacciones, estos elementos de datos son entonces inaccesibles para otras aplicaciones hasta que la transacción se confirme. Pero no resulta deseable que los datos sean inaccesibles durante periodos prolongados de tiempo, ya que esto limita enormemente el grado de concurrencia.
562
Sistemas de bases de datos
•
Cuanto más tiempo se esté ejecutando una transacción, más probable es que ocurran interbloqueos si se utiliza un protocolo basado en bloqueo. Se ha demostrado que la frecuencia de los interbloqueos se incrementa según la cuarta potencia del tamaño de la transacción (Gray, 1981).
•
Una forma de permitir la cooperación entre distintas personas es mediante la utilización de elementos de datos compartidos. Sin embargo, los protocolos tradicionales de gestión de transacciones restringen significativamente este tipo de cooperación requiriendo el aislamiento de las transacciones incompletas.
En el resto de esta sección, vamos a analizar los siguientes modelos avanzados de transacciones: •
modelo de transacciones anidadas;
• •
sagas; modelo de transacciones multinivel;
•
reestructuración
•
modelos de flujo de trabajo.
20.4.1
dinámica;
Modelo de transacciones anidadas
Modelo de transacciones anidadas
Una transacción se contempla como una colección de subtareas relacionadas, o subtransacciones, cada una de las cuales puede a su vez contener cualquier número de subtransacciones.
El modelo de transacciones anidadas fue introducido por Moss (1981). En este modelo, toda la transacción forma un árbol o jerarquía de subtransacciones. Existe una transacción de primer nivel que puede tener una serie de transacciones hijas; cada transacción hija puede a su vez tener transacciones anidadas. En la propuesta original de Moss, sólo las subtransacciones de nivel de hoja (las subtransacciones en el nivel inferior de anidamiento) pueden realizar operaciones en la base de datos. Por ejemplo, en la Figura 20.26 tenemos una transacción para las reservas (T 1) que está compuesta por las transacciones para reserva de billetes de avión (T2) o de hotel (Ts) Y de alquiler de coche (T6). La operación de reserva de billete de avión está dividida, a su vez, en dos subtransacciones: una para reservar un billete de Londres a París (T3) y otra para reservar un vuelo de conexión de París a Nueva York (T4). Las transacciones tienen que confirmarse de abajo hacia arriba. Así, T3 y T4 deberán confirmarse antes que la transacción padre T2 y T2 deberá confirmarse antes que la transacción padre T l' Sin embargo, si una transacción se aborta en un cierto nivel eso no tiene ningún efecto sobre otra transacción en progreso en un nivel superior. En lugar de ello, la transacción padre está autorizada a realizar su propia recuperación de una de las siguientes maneras: •
Volver a intentar ejecutar la subtransacción.
•
Ignorar el fallo, en cuyo caso la subtransacción se considera como no vital. En nuestro ejemplo, el alquiler del coche puede considerarse no vital y la reserva global puede continuar sin que esa operación se complete.
•
Ejecutar una subtransacción alternativa, denominada subtransacción de contingencia. En nuestro ejemplo, si falla la reserva de hotel en el Hilton, podría realizarse una reserva alternativa en otro hotel, como por ejemplo el Sheraton. Abortar.
•
Las actualizaciones de las subtransacciones confirmadas en los niveles intermedios sólo son visibles dentro del ámbito de sus padres inmediatos. Por tanto, cuando la transacción T3 confirme los cambios, éstos sólo serán visibles para T2; no serán visibles para TI ni para ninguna otra transacción externa a TI' Además, la confirmación de una subtransacción está sujeta condicionalmente a la confirmación o al anulación de sus superiores. Utilizando este modelo, las transacciones de primer nivel se ajustan a las propiedades ACID tradicionales de una transacción plana.
Capítulo 20 Gestión de transacciones begin_transaction T ¡
Reserva completa Reserva_avión
begin_transaction T 2 begin_transaction T 3
Primer_ ~elo
reserve_airline_seat(London, commit
563
Paris);
T3;
begin_transaction T 4 reserve_airline_seat(Paris, New York); commit commit
T4;
T2;
begin_transaction T 5
Reserva Jilltel
book_hotel(Hilton); commit Ts; begin_transaction T6
Reserva-::,vehículo
book_carO; cornrnit T6; comrnit T¡;
Figura 20.26.
Transacciones
anidadas.
Moss también propuso un protocolo de control de concurrencia para las transacciones anidadas, basado en un bloqueo estricto en dos fases. Las subtransacciones de las transacciones padre se ejecutan como si fueran transacciones independientes. Una transacción está autorizada a mantener un bloqueo si la única otra transacción que mantiene un bloqueo conflictivo es el padre de la subtransacción. Cuando una subtransacción se confirma, sus bloqueos son heredados por su padre. Al heredar un bloqueo, el padre mantiene el bloqueo en un modo más exclusivo si tanto el hijo como el padre mantienen un bloqueo sobre el mismo elemento de datos. Las principales ventajas del modelo de transacciones anidadas son: •
Modularidad. Una transacción puede descomponerse en una serie de transacciones para propósitos de concurrencia y recuperación.
•
Un nivel más fino de granularidad para el control de concurrencia y la recuperación. Tiene lugar en el nivel de la subtransacción en lugar de en el de la transacción.
•
Paralelismo intra-transacción.
•
Recuperación intra-transacción. Las subtransacciones no confirmadas pueden abortarse y anularse sin que se produzca ningún efecto secundario en las otras subtransacciones.
Las subtransacciones
Emulación de las transacciones puntos de salvaguarda Punto de salvaguarda
pueden ejecutarse concurrentemente.
anidadas utilizando
Un punto identificable en una transacción plana que representa a algún estado parcialmente coherente y que puede utilizarse como punto interno de reinicio para la transacción si se detecta subsiguientemente un problema.
Uno de los objetivos del modelo de transacciones anidadas consiste en proporcionar una unidad de recuperación con un nivel más fino de granularidad que el de la transacción. Durante la ejecución de una transacción, el usuario puede establecer un punto de salvaguarda, por ejemplo utilizando una instrucción SAVE WORKt. Esto genera un identificador que el usuario puede utilizar subsiguientemente para deshacer la transacción, por ejemplo, empleando una instrucción como ROLLBACK WORK t. Sin embargo, a diferencia de las transacciones anidadas, los puntos de salvaguarda no soportan ninguna forma de paralelismo intra-transacción. 1 Esto no es están dar SQL, sino simplemente
una instrucción de ejemplo.
564 Sistemas de bases de datos
20.4.2
Sagas
Saga
Una secuencia de transacciones acciones.
(planas) que pueden entrelazarse
con otras trans-
El concepto de saga fue introducido por García-Molina y Salem (1987) y está basado en el uso de transacciones de compensación. El SGBD garantiza que todas las transacciones de la saga se completen o que se ejecuten transacciones de compensación para recuperarse de una ejecución parcial. A diferencia de las transacciones anidadas, que tienen un nivel arbitrario de anidamiento, las sagas sólo tienen un nivel de anidamiento. Además, para cada subtransacción que se defina, habrá una transacción de compensación correspondiente que deshará semánÍicamente el efecto de la subtransacción. Por tanto, si tenemos una saga compuesta por una secuencia de n transacciones TI' T2, ... , Tm con transacciones de compensación correspondientes CJ, C2, .•. , Cm entonces el resultado final de la saga será una de las siguientes secuencias de ejecución: TI, TI'
T2,
,
Tn
T2,
,
T¡, C¡_J, ... ,
C2,
si la transacción se completa con éxito CJ si la subtransacción T¡ falla y es abortada
Por ejemplo, en el sistema de reservas anteriormente analizado, para producir una saga reestructuramos transacción con el fin de eliminar el anidamiento de las reservas de los vuelos, de la forma siguiente: T3, T4,
la
Ts, T6
Estas subtransacciones representan los nodos hoja de la transacción de nivel superior de la Figura 20.26. Podemos fácilmente definir una serie de subtransacciones de compensación para cancelar las dos reservas de vuelos, la reserva de hotel y la reserva del vehículo de alquiler. Comparado con el modelo de transacciones planas, las sagas relajan la propiedad de aislamiento permitiendo que una saga revele sus resultados parciales a otras transacciones que se estén ejecutando concurrentemente antes de completarse. Las sagas son útiles generalmente cuando sus transacciones son relativamente independientes entre sí y cuando pueden definirse transacciones de compensación, como en nuestro ejemplo. Sin embargo, en algunos casos, puede ser dificil definir una transacción de compensación de antemano, yeso puede exigir que el SGBD interactúe con el usuario para determinar el apropiado efecto de compensación. En otros casos, puede que no sea posible definir en absoluto una transacción de compensación; por ejemplo, puede no ser posible definir una transacción de compensación para una transacción que suministre dinero en efectivo en un cajero automático.
20.4.3
Modelo de transacciones multinivel
El modelo de transacciones anidado presentado en la Sección 20.4.1 requiere que el proceso de confirmación tenga lugar de abajo hacia arriba, hasta llegar a la transacción de primer nivel. Esto se denomina, más precisamente, una transacción anidada cerrada, ya que la semántica de estas transacciones impone la atomicidad en el primer nivel. Por contraste, también existen lo que se llaman transacciones anidadas abiertas, que relajan esta condición y permiten que los resultados parciales de las subtransacciones sean observables fuera de la transacción. El modelo de sagas que hemos explicado en la sección anterior sería un ejemplo de transacción anidada abierta. Una especialización del concepto de transacción anidada abierta es el modelo de transacción multinivel en el que el árbol de subtransacciones está equilibrado (Weikum, 1991; Weikum y Schek, 1991). Los nodos situados en la misma profundidad del árbol se corresponden con operaciones del mismo nivel de abstracción en un SGBD. Las aristas del árbol representan la implementación de una operación mediante una secuencia de operaciones del siguiente nivel inferior. Los niveles de una transacción de n niveles se designan Lo, LI, ... , Lm donde Lo representa el nivel inferior del árbol y Ln la raíz del árbol. Las transacciones tradicionales planas garantizan que no haya conflictos en el nivel inferior (Lo). Sin embargo, el concepto básico en el modelo de transacciones multinivel es que dos operaciones en el nivel Li pueden no entrar en conflicto aun cuando sus implementaciones en el siguiente nivel inferior L¡_Isí que entran en conflicto. Aprovechándose de la información de conflictos específica del nivel, las transacciones multinivel permiten obtener un mayor grado de concurrencia que las transacciones planas tradicionales.
Capítulo 20 Gestión de transacciones
565
Por ejemplo, considere la planificación compuesta por las dos transacciones T7 y Ts que se muestran en la Figura 20.27. Podemos demostrar fácilmente que esta planificación no es serializable en términos de conflictos. Sin embargo, veamos lo que pasa si dividimos T7 y Ts en las siguientes subtransacciones con operaciones de menor nivel: T7:
T71, que incrementa bal, en 5 T71,
TSI,
que resta 5 de baly
TS2,
que incrementa baly en 10 que resta 2 de balx
Conociendo la semántica de estas operaciones, como la suma y la resta son conmutativas, podemos ejecutar estas subtransacciones en cualquier orden y siempre se generará el resultado correcto.
20.4.4 Reestructuración dinámica Al principio de esta sección hemos explicado algunas de las características de las aplicaciones de diseño, como por ejemplo la duración incierta (desde horas hasta meses), la interacción con otras actividades concurrentes y los desarrollos inciertos, de modo que algunas acciones no pueden ser previstas al principio. Para satisfacer las restricciones impuestas por las propiedades ACID de las transacciones planas, se propusieron dos nuevas operaciones: la transacción dividida y la transacción de combinación (Pu el al., 1988). El principio subyacente a las transacciones divididas consiste en dividir una transacción activa en dos transacciones serializables y dividir sus acciones y recursos (por ejemplo, los elementos de datos bloqueados) entre las dos nuevas transacciones. Las transacciones resultantes pueden ejecutarse de forma independiente a partir de dicho punto, quizás controladas por distintos usuarios, y comportarse como si siempre hubieran sido independientes. Esto permite que los resultados parciales de una transacción sean compartidos con otras transacciones, al mismo tiempo que se preserva su semántica; es decir, si la transacción original satisfacía las propiedades ACID, también lo harán las nuevas transacciones. La operación de transacción dividida puede aplicarse sólo cuando sea posible generar dos transacciones serializables entre sí y con todas las demás transacciones que se estén ejecutando concurrentemente. Las condiciones que permiten que una transacción T sea dividida en sendas transacciones A y B son las siguientes: (1) AWriteSet n BWriteSet ~ BWriteLast. Esta condición afirma que si tanto A como B escriben en el mismo objeto, las operaciones de escritura de B deben seguir a las operaciones de escritura de A. Tiempo
Ts begin_transaction read(balx) balx = balx + 5 write(balx) begin_transaction read(baly) baly = baly + 10 write(baly) read(baly) baly = baly - 5 write(baly) commit read(balx) balx = balx - 2 write(balx) commit
Figura 20.27.
Planificación
no serializable.
566
Sistemas de bases de datos
(2) AReadSet deBo
n BWriteSet = 0. Esta condición afirma que A no puede ver ninguno de los resultados
(3) BReadSet
n AWriteSet
= ShareSet. Esta condición afirma que B puede ver los resultados de A.
Estas tres condiciones garantizan que A se serialice antes que B. Sin embargo, si A se aborta, B también deberá abortarse, porque habrá leído datos escritos por A. Si ambos conjuntos BWriteLast y ShareSet están vacíos, entonces A y B podrán serializarse en cualquier orden y ambos podrán confirmarse independientemente. El mecanismo de transacción de combinación realiza la operación inversa de la transacción dividida, mezclando el trabajo en curso de dos o más transacciones independientes como si esas transacciones hubieran sido siempre una única transacción. Una operación de división de transacción seguida de una operación de combinación de transacción sobre una de las nuevas transacciones creadas puede utilizarse para transferir recursos entre transacciones concretas sin tener que poner dichos recursos a disposición de otras transacciones. Las principales ventajas del método de reestructuración dinámico son: •
Recuperación adaptativa, que permite que parte del trabajo realizado por una transacción se confirme, de modo que no se verá afectado por los cambios subsiguientes .
•
Reducción del aislamiento, que permite liberar recursos confirmando parte de la transacción.
20.4.5
Modelos de flujo de trabajo
Los modelos analizados hasta ahora en esta sección se han desarrollado para resolver las limitaciones que el modelo de transacciones planas tiene para las transacciones de larga duración. Sin embargo, algunos autores argumentan que estos modelos siguen sin ser lo suficientemente potentes como para modelar algunas actividades empresariales. Se han propuesto modelos más complejos que son combinación de las transacciones abiertas y anidadas. Sin embargo, puesto que estos modelos dificilmente se adaptan a ninguna de las propiedades ACID, se ha optado por ejemplo por el nombre más apropiado de modelo de flujo de trabajo. Unflujo de trabajo es una actividad que implica la ejecución coordinada de múltiples tareas realizadas por diferentes entidades de procesamiento, que pueden ser personas o sistemas de software, como por ejemplo un SGBD, un programa de aplicación o un sistema de correo electrónico. Un ejemplo extraído del caso de estudio de DreamHome sería el procesamiento de un contrato de alquiler para un inmueble. El cliente que desee alquilar un inmueble contactará con el empleado apropiado al que se le haya asignado la gestión de dicho inmueble. Este empleado contactará con la compañía de verificación de crédito de la empresa, que verificará que el cliente es aceptable utilizando fuentes tales como las bases de datos de calificación de crédito que las entidades bancarias tienen a su disposición. La persona encargada de verificar el crédito decidirá entonces aprobar o rechazar la solicitud e informará al empleado de su decisión final, el cual se la hará saber al cliente. Hay dos problemas de carácter general en los sistemas de flujo de trabajo: la especificación del flujo de trabajo y la ejecución del mismo. Ambos problemas se complican por el hecho de que muchas organizaciones utilizan múltiples sistemas, gestionados de forma independiente, para automatizar las diferentes partes del proceso. Los principales problemas a la hora de especificar un flujo de trabajo son (Rusinkiewicz y Sheth, 1995): •
Especificación de las tareas. La estructura de ejecución de cada tarea se define proporcionando un conjunto de estados de ejecución externamente observables y un conjunto de transiciones entre dichos estados.
•
Requisitos de coordinación de las tareas. Se suelen expresar como dependencias de ejecución intertare as y dependencias de flujo de datos, junto con las condiciones de terminación del flujo de trabajo.
•
Requisitos de ejecución (corrección). Éstos restringen la ejecución del flujo de trabajo con el fin de satisfacer criterios de corrección que son específicos de la aplicación. Estos criterios incluyen requisitos de atomicidad, de ejecución y de fallo y requisitos de control de concurrencia y recuperación para el flujo de trabajo.
Capítulo 20 Gestión de transacciones
567
En términos de ejecución, una actividad tiene una semántica de anidamiento abierto que permite que los resultados parciales sean visibles fuera de sus límites, permitiendo que los distintos componentes de la actividad realicen confirmaciones individuales. Los componentes pueden ser otras actividades con la misma semántica de anidamiento abierto o transacciones anidadas cerradas que sólo harán visibles sus resultados para todo el sistema cuando efectúen la operación de confirmación. Sin embargo, una transacción anidada cerrada sólo puede estar compuesta de otras transacciones anidadas cerradas. Algunos componentes de una actividad pueden definirse como tales y, si se abortan, sus padres también deberán ser abortados. Además, pueden definirse transacciones de compensación y contingencia, como se ha explicado anteriormente. El lector interesado puede encontrar una explicación más detallada de los modelos de transacciones avanzados en Korth et al. (1988), Skarra y Zdonik (1989), Khoshafian y Abnous (1990), Barghouti y Kaiser (1991) y Gray y Reuter (1993).
20.5 Control de concurrencia y recuperación en Oracle Para completar este capítulo, vamos a examinar brevemente los mecanismos de control de concurrencia y recuperación en OracIe9i. OracIe gestiona el acceso concurrente de forma ligeramente distinta de los protocolos descritos en la Sección 20.2. Lo que OracIe utiliza es un protocolo de coherencia de lectura multiversión que garantiza que los usuarios vean una vista coherente de los datos solicitados (OracIe Corporation, 2004a). Si otro usuario modifica los datos subyacentes durante la ejecución de la consulta, OracIe mantiene una versión de los datos tal como existían en el instante en que la consulta se inicio. Si en el momento de empezar la consulta hubiera otras transacciones no confirmadas en progreso, OracIe garantiza que la consulta no pueda ver las modificaciones realizadas por estas transacciones. Además, OracIe no impone ningún bloqueo sobre los datos para las operaciones de lectura, lo que significa que una operación de lectura nunca bloquea a otra de escritura. Hablaremos de estos conceptos en el resto del capítulo. En las páginas siguientes, utilizaremos la terminología del SGBD de OracIe, donde a las relaciones se les denomina tablas, que están compuestas de columnas y filas. El lector puede consultar la introducción a Oracle que hemos proporcionado en la Sección 8.2.
20.5.1 Niveles de aislamiento en Oracle En la Sección 6.5 hemos hablado del concepto de niveles de aislamiento, que describía como se aísla una transacción de las restantes. OracIe implementa dos de los cuatro niveles de aislamiento definidos en el estándar ISO SQL, READ COMMITTED y SERIALIZABLE: •
READ COMMITTED. La serialización se impone en el nivel de instrucción (este es el nivel de aislamiento predeterminado). Así, cada instrucción de una transacción sólo puede ver los datos que hubieran sido confirmados antes de que la instrucción (no la transacción) diera comienzo. Esto indica que los datos pueden ser cambiados por otras transacciones entre sucesivas ejecuciones de la misma instrucción dentro de una misma transacción, lo que hace que sean posibles las lecturas no repetibles y las lecturas fantasma .
•
SERIALIZABLE. La serialización se impone en el nivel de transacción, por lo que cada instrucción de la transacción sólo verá los datos que hubieran sido confirmados antes de que la transacción diera comienzo, así como cualesquiera cambios que la transacción haya realizado mediante las instrucciones INSERT, UPDATE o DELETE.
Ambos niveles de aislamiento utilizan bloqueos de nivel de fila y ambos realizan una espera si la transacción trata de modificar una fila actualizada por una transacción no confirmada. Si la transacción bloqueante se aborta y deshace los cambios, la transacción en espera puede proceder a modificar la fila previamente bloqueada. Si la transacción bloqueante se confirma y libera el bloque, entonces en el modo READ COMMITTED la transacción en espera procederá a realizar su actualización. Sin embargo, con el modo SERIALIZABLE, se devuelve un error indicando que las operaciones no pueden ser serializadas. En este caso, el desarrollador de aplicaciones tiene que añadir la lógica necesaria al programa para volver al comienzo de la transacción y reiniciarla.
568
Sistemas de bases de datos
Además, Oracle soporta un tercer nivel de aislamiento: •
READ ONLY. Las transacciones de sólo lectura únicamente ven los datos que hubieran sido confirmados antes de que la transacción diera comienzo.
El nivel de aislamiento puede seleccionarse en Oracle utilizando los comandos SQL SET TRANSACnON o ALTER SESSION.
20.5.2
Coherencia de lectura multiversión
En esta sección vamos a describir brevemente la implementación Oracle del protocolo de coherencia de lectura multiversión. En particular, vamos a describir el uso de los segmentos de anulación, de los números de cambio de sistema (SCN, system change number) y de los bloqueos.
Segmentos de anulación Los segmentos de anulación son estructuras de la base de datos Oracle que se utilizan para almacenar información de deshacer. Cuando una transacción está a punto de modificar los datos de un bloque, Oracle escribe primero la imagen anterior de los datos en un segmento de anulación. Además de soportar la coherencia de lectura multiversión, los segmentos de anulación también se utilizan para deshacer las transacciones. Oracle mantiene también uno o más registros de rehacer, que registran todas las transacciones que tengan lugar y que se utilizan para recuperar la base de datos en caso de fallo del sistema.
Número de cambio del sistema Para mantener el orden cronológico correcto de las operaciones, Oracle mantiene un número de cambio del sistema (SCN, system change number). El SCN es una marca temporal de nivel lógico que registra el orden en el que tienen lugar las operaciones. Oracle almacena el SCN en el registro de rehacer para poder rehacer las transacciones en su secuencia correcta. Oracle utiliza el SCN para determinar qué versión de un elemento de datos debe utilizarse dentro de una transacción. También utiliza el SCN para determinar cuándo puede limpiarse la información contenida en los segmentos de una relación.
Bloqueos En todas las instrucciones SQL se produce un bloqueo implícito, por lo que el usuario nunca necesita bloquear ningún recurso de manera explícita, aunque Oracle proporciona un mecanismo que permite al usuario adquirir bloqueos manualmente o modificar el comportamiento del bloqueo predeterminado. Los mecanismos predeterminados de bloqueo bloquean los datos en el menor nivel posible de restricción, para garantizar la integridad al mismo tiempo que se consigue el máximo grado posible de concurrencia. Mientras que muchos SGBD almacenan la información sobre bloqueos de fila como una lista de memoria, Oracle almacena la información de bloqueos de fila dentro del propio bloque de datos en el que la fila está almacenada. Como hemos explicado en la Sección 20.2, algunos SGBD también permiten la mejora de los bloqueos. Por ejemplo, si una instrucción SQL necesita acceder a un alto porcentaje de las filas de una tabla para imponer un bloqueo, algunos SGBD mejorarán los bloqueos de las filas individuales, transformándolos en un bloqueo de tabla. Aunque esto reduce el número de bloqueos que el SGBD tiene que gestionar, tiene como resultado que se bloqueen filas no modificadas, reduciendo así potencialmente el grado de concurrencia e incrementando la probabilidad de que se introduzcan interbloqueos. Puesto que Oracle almacena los bloqueos de fila dentro de los bloques de datos, nunca necesita mejorar los bloqueos. Oracle soporta una serie de tipos de bloqueo, incluyendo: •
Bloqueos DDL: se utilizan para proteger los objetos del esquema, como las definiciones de tablas y vistas.
•
Bloqueos DML: se utilizan para proteger los datos base, como por ejemplo bloqueos de tabla para proteger tablas completas y bloqueos de fila para proteger filas seleccionadas. Orac1e soporta los siguientes tipos de bloqueos de tabla (ordenados de menos restrictivo a más restrictivo):
Capítulo 20 Gestión de transacciones • • • • •
569
bloqueo de tabla con compartición de fila (también denominado bloqueo de tabla subcompartido), que indica que la transacción ha bloqueado filas de la tabla y pretende actualizadas; bloqueo de tabla exclusivo de fila (también denominado bloqueo de tabla subexclusivo), que indica que la transacción ha hecho una o más actualizaciones en filas de la tabla; bloqueo de tabla compartido, que permite a otras transacciones consultar la tabla; bloqueo de tabla compartido exclusivo de fila (también denominado bloqueo de tabla subexclusiva-compartido); bloqueo de tabla exclusivo, que concede a la transacción acceso de escritura exclusivo a la tabla.
•
Cerrojos internos: utilizados para proteger las estructuras de datos compartidas en el área global del sistema (SGA, system global area).
•
Bloqueos internos: se utilizan para proteger las entradas del diccionario de datos, los archivos de datos, los espacios de tabla y los segmentos de anulación.
•
Cerrojos distribuidos: se utilizan para proteger los datos en un entorno de seguridad distribuido y/o paralelo.
•
Bloqueos PCM: los bloqueos de gestión paralela de caché (PCM, parallel cache management) se utilizan para proteger la caché de búfer en un entorno de servidor paralelo.
20.5.3 Detección interbloqueos Oracle detecta automáticamente los interbloqueos y los resuelve deshaciendo una de las instrucciones implicadas en el interbloqueo. Se devuelve un mensaje a la transacción cuya instrucción haya sido anulada. Usualmente, la transacción que recibe el mensaje debe ser anulada de forma explícita, aunque puede tratar de . volver a ejecutar la instrucción anidada después de un cierto tiempo de espera.
20.5.4 Copia de seguridad y recuperación Oracle proporciona servicios bastante completos de copia de seguridad y recuperación, así como otros servicios adicionales para soportar los entorno s de alta disponibilidad. Un análisis completo de estos servicios estaría fuera del alcance de este libro, por lo que sólo vamos a repasar algunas de las características más sobresalientes. El lector interesado puede consultar la documentación de Oracle (Oracle Corporation, 2004c).
Gestor de recuperación El gestor de recuperación de Oracle (RMAN) proporciona servicios de copia de seguridad y recuperación gestionados por el servidor. Esto incluye funcionalidades para: •
hacer una copia de seguridad de uno o más archivos de datos en disco o cinta;
•
hacer una copia de seguridad de los registros de rehacer archivados en disco o cinta;
•
restaurar archivos de datos desde disco o cinta;
•
restaurar y aplicar registros de rehacer archivados para llevar a cabo una recuperación.
RMAN mantiene un catálogo de información de copia de seguridad y tiene la capacidad de realizar copias de seguridad completas o incrementales, almacenando en este último caso únicamente aquellos bloques de la base de datos que hayan sido modificados desde la última copia de seguridad.
Recuperación de una instancia Cuando se reinicia una instancia Oracle después de un fallo, Oracle detecta que ha tenido lugar una parada catastrófica utilizando la información del archivo de control y las cabeceras de los archivos de la base de datos. Oracle recuperará la base de datos a un estado coherente utilizando la información contenida en los archivos del registro de rehacer, mediante los métodos de anulación y reaplicación de las transacciones, explicados en la Sección 20.3. Oracle también permite realizar puntos de comprobación a intervalos determinados
570
Sistemas de bases de datos
por un parámetro contenido en el archivo de inicialización (INIT.ORA), aunque se puede desactivar la realización de puntos de comprobación asignando un valor cero al parámetro.
Recuperación hasta un instante determinado En una versión anterior de Oracle, la recuperación hasta un instante determinado permitía restaurar los archivos de datos a partir de las copias de seguridad y de la información de rehacer y aplicar dicha información hasta un instante específico o hasta un número de cambio del sistema (SCN) específico. Este método resultaba útil cuando se producía un error y había que recuperar la base de datos hasta un punto específico (por ejemplo, un usuario podía haber cerrado accidentalmente una tabla). Oracle ha ampliado esta funcionalidad para permitir una recuperación hasta un instante específico en el nivel de espacio de tablas, permitiendo que se restauren uno o más espacios de tablas hasta un punto concreto.
Base de datos de reserva Oracle permite mantener una base de datos de reserva por si acaso fallara la base de datos principal. La base de datos de reserva puede mantenerse en una ubicación alternativa y Oracle enviará los registros de rehacer hasta esa ubicación alternativa a medida que se llenen y los aplicará a la base de datos de reserva. Esto garantiza que la base de datos de reserva esté prácticamente actualizada. Como característica adicional, la base de datos de reserva puede abrirse para acceso de sólo lectura, lo que permite descargar en la base de datos de reserva algunas consultas que de otro modo tendrían que ser respondidas por la base de datos principal.
Resumen del capítulo •
El control de concurrencia es el proceso de gestionar operaciones simultáneas en la base de datos sin que éstas interfieran entre sí. La recuperación de la base de datos es el proceso de restaurar la base de datos hasta un estado correcto después de un fallo. Ambos mecanismos protegen a la base de datos de las incoherencias y de la base de datos.
•
Una transacción es una acción, o serie de acciones, llevada a cabo por un único usuario o programa de aplicación, que accede al contenido de la base de datos o lo modifica. Una transacción es una unidad de trabajo lógica que lleva a la base de datos de un estado coherente a otro. Las transacciones pueden terminar con éxito (confirmación) o sin éxito (se aborta la transacción). Las transacciones abortadas deben ser deshechas o anuladas. La transacción es también la unidad de concurrencia y la unidad de recuperación. Una transacción debe poseer las cuatro propiedades básicas, o propiedades ACID: atomicidad, coherencia, aislamiento y permanencia. La atomicidad y la permanencia son responsabilidad del subsistema de recuperación; el aislamiento y, hasta cierto punto, la coherencia son responsabilidad del subsistema de control de concurrencia.
•
•
El control de concurrencia es necesario cuando se permita a múltiples usuarios acceder a la base de datos simultáneamente. Sin este tipo de mecanismos, pueden producirse los problemas de la actualización perdida, de la dependencia no confirmada y del análisis incoherente. El concepto de ejecución serie significa ejecutar una transacción en cada momento, sin ningún tipo de entrelazado de las operaciones. Una planificación muestra la secuencia de las operaciones de las transacciones. Una planificación será serializable si produce los mismos resultados que alguna planificación serie.
•
Dos métodos que garantizan la serializabilidad son el bloqueo en dos fases (2PL, two-phase locking) y el marcado temporal. Los bloqueos pueden ser compartidos (lectura) o exclusivos (escritura). En el bloqueo en dos fases, una transacción adquiere todos sus bloqueos antes de liberar ninguno de ellos. Con el marcado temporal, las transacciones se ordenan de tal forma que las transacciones más antiguas tienen prioridad en caso de conflicto.
•
Pueden producirse interbloqueos cuando dos o más transacciones estén esperando para acceder a una serie de datos que la otra transacción haya bloqueado. La única forma de romper un interbloqueo una vez que ha sucedido es abortar una o más de las transacciones.
Capítulo 20 Gestión de transacciones
571
•
Puede utilizarse un árbol para representar la granularidad de los bloqueos en un sistema donde se permita bloquear elementos de datos de tamaños distintos. Cuando se bloquea un elemento, también se bloquean todos sus descendientes. Cuando una nueva transacción solicita el bloqueo, resulta fácil comprobar todos los ascendientes del objeto para determinar si ya están bloqueados. Para ver si alguno de los descendientes del nodo están bloqueados, se sitúa un bloqueo de intención en todos los ascendientes de los nadas que estén siendo bloqueados.
•
Algunas posibles causas de fallos son las paradas catastróficas del sistema, los fallos de los soportes físicos, los errores del software de aplicación, los descuidos, los desastres físicos naturales y el sabotaje. Estos fallos pueden tener como resultado la pérdida del contenido de la memoria principal y/o de la copia en disco de la base de datos. Las técnicas de recuperación permiten minimizar los efectos de estos fallos.
•
Para facilitar la recuperación, un método consiste en que el sistema mantenga un archivo de registro que contenga entradas para las distintas transacciones que identifiquen el inicio/fin de las transacciones y las imágenes anterior y posterior de las operaciones de escritura. Utilizando actualizaciones diferidas, las escrituras se realizan inicialmente sólo en el registro, empleándose las entradas del registro para llevar a cabo las propias actualizaciones de la base de datos. Si el sistema falla, examinará el registro para determinar qué transacciones necesita rehacer, pero no será necesario deshacer ninguna escritura. Por el contrario, utilizando actualizaciones inmediatas, cada actualización puede grabarse en la propia base de datos en cualquier momento después de escribir la entrada de registro. Entonces, puede emplearse el registro para deshacer y rehacer las distintas transacciones en caso de fallo.
•
Los puntos de comprobación se utilizan para mejorar los mecanismos de recuperación de la base de datos. En los puntos de comprobación, todos los bloques de búfer modificado, todas las entradas de registro y una entrada de punto de comprobación que identifica todas las transacciones activas se escriben en disco. Si sucede un fallo, la entrada de punto de comprobación identifica las transacciones que tienen que rehacerse.
•
Entre los modelos avanzados de transacción se incluyen las transacciones anidadas, las sagas, las transacciones multinivel, las transacciones de reestructuración dinámica y los modelos de flujo de trabajo.
Cuestiones de repaso 20.1. Explique el concepto de transacción. ¿Por qué son las transacciones unidades de operación tan importantes en un SGBD? 20.2.
Los aspectos de coherencia y fiabilidad de las transacciones se deben a las propiedades ACID de las mismas. Explique cada una de dichas propiedades y cómo se relacionan con los mecanismos de control de concurrencia y de recuperación. Proporcione ejemplos para ilustrar su respuesta.
20.3.
Describa, con ejemplos, los tipos de problemas que pueden producirse en un entorno multiusuario cuando se permite un acceso concurrente a la base de datos.
20.4
Describa en detalle un mecanismo para control de concurrencia que pueda usarse para garantizar que los tipos de problemas enunciados en la Cuestión 20.3 no se produzcan. Muestre cómo dicho mecanismo evita que aparezcan esos problemas. Explique cómo interacciona el mecanismo de control de concurrencia con el mecanismo de transacciones.
20.5.
Explique los conceptos de planificaciones serie, no serie y serializables. Indique las reglas de equivalencia de planificaciones.
20.6.
Explique la diferencia entre serializabilidad de conflictos y serializabilidad de vistas.
20.7.
Explique los tipos de problemas que pueden tener lugar con los mecanismos de control de concurrencia basados en bloqueo y las acciones que el SGBD puede tomar para prevenidos.
20.8.
¿Por qué el bloqueo en dos fases no sería un esquema de control de concurrencia apropiado para los índices? Explique otro esquema de bloqueo más apropiado para índices basados en árbol.
20.9.
¿Qué es una marca temporal? ¿En qué se diferencian los protocolos de control de concurrencia basados en marcas temporales de los basados en bloqueos?
572
Sistemas de bases de datos
20.10. Describa el protocolo básico de ordenación de marcas temporales para control de concurrencia. ¿Qué es la regla de Escritura de Thomas y cómo afecta al protocolo básico de ordenación de marcas temporales? 20.11. Describa cómo pueden usarse las versiones para mejorar el grado de concurrencia. 20.12. Explique la diferencia entre el control de concurrencia pesimista y el optimista. 20.13. Explique los tipos de fallos que pueden tener lugar en un entorno de base de datos. Explique por qué es importante que un SGBD multiusuario proporcione un mecanismo de recuperación. 20.14. Explique por qué el archivo de registro (o diario) es una característica fundamental de cualquier mecanismo de operación. Explique qué es la recuperación hacia adelante y hacia atrás y describa cómo se utiliza el archivo de registro en ambos tipos de recuperación. ¿Cuál es la importancia del protocolo de registro con escritura anticipada? ¿Cómo afectan los puntos de comprobación al protocolo de recuperación? 20.15. Indique las similitudes y diferencias entre los protocolos de recuperación con actualización diferida y con actualización inmediata. 20.16. Explique los siguientes modelos avanzados de transacciones: (a)
transacciones anidadas
(b)
sagas
(c)
transacciones multinivel
(d)
transacciones con reestructuración
dinámica.
Ejercicios 20.17. Analice los SGBD que esté utilizando actualmente. ¿Qué protocolo de control de concurrencia utiliza cada SGBD? ¿Qué tipo de mecanismo de recuperación se utiliza? ¿Qué soporte se proporciona para los modelos avanzados de transacciones analizados en la Sección 20.4? 20.18. Para cada una de las siguientes planificaciones, indique si la planificación es serializable, serializable en términos de conflictos, serializable en términos de vistas, recuperable y si evita tener que realizar anulaciones en cascada: (a) read(T],
balx),
(b) read(T¡,
balJ,
read(T2, balJ, write(T¡, read(T2,
baly), write(T3,
balx), balx),
write(T2, read(T2,
commit(T]), commit(T2)
balJ, balJ,
read(T],
balJ,
commit(T¡), commit(T2),
commit(T3)
(c) read(T¡, (d) write(T], (e) read(T¡,
write(T2,
bal,),
write(T¡,
balx),
abort(T2),
read(T2,
balx),
write(T¡,
balx),
commit(T2),
bal,), write(T2,
baIJ,
write(T],
balx),
read(T3, balJ,
balx),
balJ,
commit(T¡) abort(T¡) commit(T]), commit(T2),
20.19. Dibuje un grafo de precedencia para cada una de las planificaciones
commit(T3)
(a) a (e) del ejercicio anterior.
20.20. (a) Explique qué es la regla de escritura restringida y cómo comprobar si una planificación es serializable en términos de conflictos mediante la regla de escritura restringida. Utilizando el método anterior, determine si la siguiente planificación es serializable:
donde R;(Z)/W;(z) indica una lectura/escritura datos Z.
por parte de la transacción i sobre el elemento de
(b) ¿Tendría sentido diseñar un algoritmo de control de concurrencia basado en la serializabilidad? Razone su respuesta. ¿Cómo se utiliza la serializabilidad en los algoritmos estándar de control de concurrencia? 20.21. (a) Explique cómo podría comprobar la serializabilidad de vistas utilizando un grafo de precedencia etiquetado.
Capítulo 20 Gestión de transacciones (b) Utilizando el método anterior, determine si las siguientes planificaciones minos de conflictos: (i)
573
son serializables en tér-
SI = [R¡(x), W2(x), WI(x)]
Rix), W3(x), W2(x)] (iii) S3 = [W¡(x), R2(x), Rix), Wix), W4(x), W2(x)] (ii)
S2 = [WI(x),
20.22. Dibuje un grafo de espera para el siguiente escenario de transacciones y determine si existen interbloqueos:: Transacción
Elementos de datos bloqueados por la transacción
T¡
Xl' Xs X6 X2 X¡O x), X8 X7 X4, X9
Elementos de datos en los que la transacción está esperando
X7,Xg X¡,xl X¡ Xl X4,Xs X6 Xs
20.23. Escriba un algoritmo para bloqueo compartido y exclusivo. ¿Cómo afecta la granularidad a este algoritmo? 20.24. Escriba un algoritmo que controle si una serie de transacciones que se estén ejecutando concurrentemente están interbloqueadas. 20.25. Utilizando las transacciones de ejemplo dadas en los Ejemplos 20.1, 20.2 Y 20.3, muestre cómo pueden utilizarse las marcas temporales para generar planificaciones serializables. 20.26. La Figura 20.22 proporciona un diagrama de Venn que muestra las relaciones entre la serializabilidad de conflictos, la serializabilidad de vistas, el bloqueo en dos fases y el marcado temporal. Amplíe el diagrama para incluir el control de concurrencia optimista y multiversión. Vuelva a ampliar el diagrama para diferenciar entre 2PL y 2PL estricto, así como entre el marcado temporal sin la regla de escritura de Thomas y el marcado temporal con la regla de Escritura de Thomas. 20.27. Explique por qué no puede implementarse realmente un almacenamiento almacenamiento estable?
estable. ¿Cómo simularía un
20.28. ¿Sería realista que un SGBD mantuviera un grafo de espera dinámica en lugar de creado cada vez que se ejecute el algoritmo de detección de interbloqueos? Razone su respuesta.
Capnulo
Procesamiento de consultas
Objetivos del capítulo: En este capítulo aprenderá: •
Los objetivos del procesamiento de consultas y optimización.
•
Las diferencias entre la optimización de consultas estática y dinámica.
•
Cómo se descompone y se analiza semánticamente
•
Cómo crear un árbol de álgebra relacional para representar una consulta.
•
Las reglas de equivalencia para las operaciones de álgebra relacional.
•
Cómo aplicar reglas de transformación heurística para mejorar la eficiencia de una consulta.
•
Los tipos de estadísticas de bases de datos requeridas para estimar el coste de las operaciones.
•
Las diferentes estrategias para implementar las operaciones de álgebra relacional.
una consulta.
•
Cómo evaluar el coste y el tamaño de las operaciones de álgebra relaciona!.
•
Cómo puede utilizarse el pipelining para mejorar la eficiencia de las consultas.
•
La diferencia entre materialización y pipelining.
•
Las ventajas de los árboles de profundidad izquierda.
•
Las técnicas para determinar una estrategia de ejecución óptima.
•
Cómo gestiona Oracle la optimización de consultas.
Cuando se lanzó por primera vez comercialmente el modelo relacional, una de las principales críticas que se hacían era el pobre rendimiento de las consultas. Desde entonces, se ha dedicado una gran cantidad de esfuerzos de investigación para desarrollar algoritmos altamente eficientes para el procesamiento de consultas. Hay muchas formas en las que se puede ejecutar una consulta compleja y uno de los objetivos de procesamiento de consultas es determinar cuál de esas formas es la menos costosa. En los sistemas de bases de datos en red y jerárquicos de primera generación, el lenguaje de consulta procedimental de bajo nivel está generalmente incrustado en un lenguaje de programación de alto nivel tal como COBOL y es responsabilidad del programador seleccionar la estrategia de ejecución más apropiada. Por contraste, con lenguajes declarativos del tipo de SQL, el usuario especifica qué datos se requieren en lugar de cómo hay que extraerlos. Esto libera al usuario de la responsabilidad de determinar, e incluso de conocer, qué es una buena estrategia de ejecución y hace que el lenguaje sea más universalmente utilizable. Adicionalmente, asignar al SGBD la responsabilidad de seleccionar la mejor estrategia evita que los usuarios seleccionen estrategias que ya se sabe que son ineficientes y proporciona al SGBD un mayor control sobre las prestaciones del sistema. Existen dos técnicas principales de optimización de consultas, aunque en la práctica se suelen combinar ambas estrategias. La primera técnica utiliza reglas heurísticas que ordenan las operaciones de una consulta. La otra técnica compara diferentes estrategias basándose en su coste relativo y selecciona aquella que mini-
576
Sistemas de bases de datos
mice el uso de recursos. Puesto que el acceso a disco resulta lento comparado con el acceso a memoria, los accesos a disco tienden a representar el coste más importante del procesamiento de consultas en un SGBD centralizado, y es en este aspecto en el que nos vamos a concentrar exclusivamente en este capítulo a la hora de proporcionar estimaciones de coste.
Estructura del capítulo En la Sección 21.1 se proporciona una panorámica del procesamiento de consultas y se examinan las fases principales de esta actividad. En la Sección 21.2 se examina la primera fase del procesamiento de consultas, que es la descomposición de la consulta, que transforma una consulta de alto nivel en una consulta de álgebra relacional y comprueba que ésta sea sintáctica y semánticamente correcta. En la Sección 21.3 examinamos la técnica heurística de optimización de consultas, que ordena las operaciones de una consulta utilizando reglas de transformación que se sabe generan buenas estrategias de ejecución. En la Sección 21.4 analizaremos la técnica de estimación de costes para la optimización de consultas, que se basa en comparar diferentes estrategias basándose en sus costes relativos y seleccionar aquella que minimice el uso de recursos. En la Sección 21.5 hablaremos del pipelining, que es una técnica que puede utilizarse para mejorar todavía más el procesamiento de las consultas. El pipelining (o procesamiento en cadena) permite que se realicen diversas operaciones de forma paralela, en lugar de requerir que cada operación se complete antes de que la siguiente pueda comenzar. También explicaremos cómo puede un procesador de consultas típico seleccionar una estrategia de ejecución óptima. En la sección final, examinaremos brevemente cómo lleva a cabo Oracle la optimización de las consultas. En este capítulo nos vamos a concentrar en las técnicas de procesamiento y optimización de consultas en un SGBD relacional centralizado, ya que éste es el área que ha atraído la mayor parte de los esfuerzos de investigación y es el modelo en el que nos centramos a lo largo de todo el libro. Sin embargo, algunas de las técnicas tienen aplicación general en otros tipos de sistemas que dispongan de una interfaz de alto nivel. Posteriormente, en la Sección 23.7, examinaremos brevemente el procesamiento de consultas en un SGBD distribuido. En la Sección 28.5 veremos que algunas de las técnicas examinadas en este capítulo pueden requerir un análisis adicional para un SGBD objeto-relacional, que soporta consultas que contienen tipos definidos por el usuario y funciones definidas por el usuario. El lector debe estar familiarizado con los conceptos tratados en la Sección 4.1 sobre el álgebra relacional y con los del Apéndice e referidos a los tipos de organización de archivos. Los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 Y en el Apéndice A.
21.1 Panorámica del procesamiento de consultas Procesamiento de consultas
Las actividades implicadas en el análisis sintáctico, la validación, la optimización y la ejecución de una consulta.
Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel (implementación de álgebra relacional) y ejecutar la estrategia para extraer los datos requeridos. Optimización de consultas
La actividad de seleccionar una estrategia de ejecución eficiente para el procesamiento de una consulta.
Un aspecto importante del procesamiento de consultas es la optimización de la consulta. Puesto que hay otras transformaciones equivalentes de la misma consulta de alto nivel, el objetivo de la optimización de consultas consiste en elegir aquella que minimice el uso de recursos. Generalmente, lo que intentaremos será reducir el tiempo total de ejecución de la consulta, que es la suma de los tiempos de ejecución de todas las operaciones individuales que componen la consulta (Selinger el al., 1979). Sin embargo, el uso de recursos también podría medirse según el tiempo de respuesta de la consulta, en cuyo caso nos concentraremos en maximizar el núme-
Capítulo 21 Procesamiento de consultas
577
ro de operaciones paralelas (Valduriez y Gardarin, 1984). Puesto que el problema es computacionalmente intratable cuando el número de tablas es grande, la estrategia adoptada se reduce generalmente a encontrar una solución cercana a la óptima (Ibaraki y Kameda, 1984). Ambos métodos de optimización de consultas dependen de las estadísticas de la base de datos para evaluar apropiadamente las diferentes opciones disponibles. La precisión y grado de actualización de dichas estadísticas tienen un gran impacto sobre la eficiencia de la estrategia de ejecución elegida. Las estadísticas recopilan información acerca de las relaciones, atributos e índices. Por ejemplo, el catálogo del sistema puede almacenar estadísticas que proporcionen la cardinalidad de las relaciones, el número de valores distintos que tiene cada atributo y el número de niveles de un índice multinivel (véase el Apéndice C.5A). Mantener las estadísticas actualizadas puede llegar a ser problemático. Si el SGBD actualizara las estadísticas cada vez que se inserta, actualiza o borra una tupla, esto tendría un impacto significativo sobre el rendimiento durante los picos de carga de trabajo. Otra alternativa generalmente preferible, consiste en actualizar las estadísticas de forma periódica, por ejemplo todas las noches, o siempre que el sistema esté inactivo. Otra solución adoptada por algunos sistemas consiste en asignar a los usuarios la responsabilidad de indicar cuándo hay que actualizar las estadísticas. Hablaremos con más detalle de las estadísticas de las bases de datos en la Sección 2104.1. Como ilustración de los efectos que las diferentes estrategias de procesamiento tienen sobre el uso de recursos, vamos a comenzar con un ejemplo.
I
Ejemplo 21.1 Comparación
de diferentes
estrategias
de procesamiento
Hallar todos los gerentes que trabajen en una sucursal de Londres. Podemos escribir esta consulta en SQL como: SELECT * FROM Staff s, Branch b WHERE s.branchNo = b.branchNo AND (s.position = 'Manager'
AND
b.city =
'London');
Tres consultas de álgebra relacional equivalentes a esta instrucción SQL serían: (1) (2)
a(position~'Manager') (cit)='London') (Staff.branchNo~Branch.branchNoiStaff X Branch) a(position~'Manager') (citY~'LOndOn,)(Staff ~ Staff.branchNo~Branch.branchNo Branch) Á
Á
~ Staff.branchNo~Branch.branchNo (acitY~'LOndon,(Branch)) (3) (aposition~'Manager,(Staff)) Para los propósitos de este ejemplo, vamos a suponer que hay 1000 tuplas en Staff, 50 tuplas en Branch, 50 empleados con categoría Manager (uno por cada sucursal) y 5 sucursales en Londres. Vamos a comparar estas tres consultas basándonos en el número de accesos de disco requeridos. En aras a la simplicidad, vamos a suponer que no hay índices ni claves de relación en ninguna de las relaciones y que los resultados de cualquier operación intermedia se almacenan en el disco. El coste de la escritura final se ignorará, ya que es el mismo en los tres casos. Vamos a suponer también que se accede a las tuplas de una en una (aunque en la práctica los acceso a disco se basarían en bloques, cada uno de los cuales contendría normalmente varias tuplas) y que la memoria principal es lo suficientemente grande como para procesar relaciones completas para cada una de las operaciones de álgebra relaciona!. La primera consulta calcula el producto cartesiano de Staff y Branch, que requiere (1000 + 50) accesos a disco para leer las relaciones y crea una relación con (1000 * 50) tuplas. Después tendremos que leer cada una de estas tuplas de nuevo para comprobar si cumplen el predicado de selección, lo que implica otros (1000 * 50) accesos a disco, dándonos un coste total de: (1000 + 50) + 2*(1000 * 50) = 101050 accesos a disco La segunda consulta combina Staff y Branch según el número de sucursal branchNo, lo que de nuevo requiere (1000 + 50) accesos a disco para leer cada una de las relaciones. Sabemos que la combinación de las dos relaciones tiene 1000 tuplas, una por cada empleado (un empleado sólo puede trabajar en
578
Sistemas de bases de datos
una sucursal). En consecuencia, la operación de selección requiere 1000 accesos a disco para leer el resultado de la combinación, lo que nos da un coste total de: 2*1000 + (1000 + 50) = 3050 accesos a disco La última de las consultas lee primero cada tupla de 81aff para determinar si se trata de un empleado con categoría de Manager, lo que requiere 1000 accesos a disco y produce una relación con 50 tuplas. La segunda operación de selección lee cada tupla Branch para determinar cuáles son las sucursales de Londres, lo que requiere 50 accesos a disco y genera una relación con 5 tuplas. La operación final es la combinación de las relaciones 81aff y Branch reducidas, lo que requiere (50 + 5) accesos a disco, dando un coste total de: 1000 + 2*50 + 5+(50 + 5) = 1160 accesos a disco Claramente, la tercera es la mejor de las opciones en este caso, según un factor de 87:1. Si incrementáramos el número de tuplas de 81aff a 10000 y el número de sucursales a 500, la mejora sería según un factor de aproximadamente 870: 1. Intuitivamente, cabía esperar esto desde el principio, ya que el producto cartesiano de las operaciones de combinación es mucho más costoso que la operación de selección y la tercera de las operaciones de consulta reduce significativamente el tamaño de las relaciones que están siendo combinadas. Veremos en breve que una de las estrategias fundamentales del procesamiento de consultas es realizar las operaciones unarias, las de selección y proyección, lo antes posible, reduciendo así el tamaño de los operandos para las subsiguientes operaciones binarias.
El procesamiento de consultas puede dividirse en cuatro partes principales: descomposición (compuesta de análisis sintáctico y validación), optimización, generación de código y ejecución, como se ilustra en la Figura 21.1. En la Sección 21.2 vamos a examinar brevemente la primera de las fases, de descomposición, antes de volver nuestra atención hacia la segunda fase, la de optimización de consultas. Para completar esta panorámica, vamos a hablar brevemente de cuándo puede llevarse a cabo la optimización.
Optimización
dinámica y estática
Existen dos opciones relativas a cuándo llevar a cabo las primeras tres fases del procesamiento de una consulta. Una de las opciones consiste en llevar a cabo dinámicamente la descomposición y la optimización cada vez que se ejecuta una consulta. La optimización dinámica de consultas tiene la ventaja de que toda la información requerida para seleccionar una estrategia óptima estará actualizada. Las desventajas son que la velocidad de la consulta se verá afectada debido a la necesidad de analizar sintácticamente, validar y optimizar la consulta antes de poder ejecutarla. Además, puede que sea necesario reducir el número de estrategias de ejecución que hay que realizar, con el fin de conseguir que ese coste de procesamiento adicional sea aceptable, lo que a su vez puede tener el efecto de que se seleccione una estrategia significativamente inferior a la óptima. La opción alternativa consiste en efectuar una optimización estática de consultas, en la que las consultas son analizadas sintácticamente, validadas y optimizadas una sola vez. Esta técnica es similar a la que se utiliza cuando se ejecuta un compilador de un lenguaje de programación. Las ventajas de la optimización estática son que se elimina el coste adicional de procesamiento en tiempo de ejecución y que puede haber más tiempo disponible para evaluar un mayor número de estrategias de ejecución, incrementándose así las posibilidades de encontrar una estrategia mejor. Para las consultas que se ejecutan muchas veces, tomarse un cierto tiempo adicional para encontrar un plan mejor puede proporcionar muchos beneficios. Las desventajas surgen del hecho de que la estrategia de ejecución que se selecciona como óptima en el momento de compilar la consulta puede haber dejado de ser óptima en el momento de ejecutarla. De todos modos, también puede emplearse una técnica híbrida para evitar esta desventaja, técnica que consiste en reoptimizar la consulta si el sistema detecta que las estadísticas de la base de datos han cambiado significativamente desde la última vez que se compiló la consulta. Alternativamente, el sistema podría compilar la consulta para la primera ejecución de cada sesión y luego almacenar en caché el plan óptimo durante el resto de la sesión, de modo que el coste se distribuya entre toda la sesión del SGBD.
Capítulo 21 Procesamiento de consultas
579
Consulta en un lenguaje de alto nivel (generalmente SQL)
Descomposición de la consulta
Expresión de álgebra relacional
Tiempo de compilación
o
Catálogo del sistema
Optimización de la consulta
Plan de ejecución
Generación de código
Código generado
Ejecución de la consulta
Salida de la consulta
Figura 21.1.
Fases del procesamiento
de consultas.
21.2 Descomposición de consultas La descomposición de consultas es la primera fase del procesamiento de consultas. Los objetivos de la descomposición de consultas son transformar una consulta de alto nivel en una consulta de álgebra relacional y comprobar que la consulta sea sintáctica y semánticamente correcta. Las etapas típicas de la descomposición de consultas son el análisis, la normalización, el análisis semántico, la simplificación y la reestructuración de la consulta.
(1) Análisis En esta etapa, se analiza la consulta léxica y sintácticamente utilizando las técnicas de los compiladores de los lenguajes de programación (véase, por ejemplo Aho y Ullman, 1977). Además, en esta etapa se verifica que las relaciones y atributos especificados en la consulta están definidos en el catálogo del sistema. Se verifica asimismo que todas las operaciones aplicadas a los objetos de la base de datos sean apropiadas para el tipo de objeto. Por ejemplo, considere la siguiente consulta: SELECT staffNumber FROM Staff WHERE position > 10; Esta consulta sería rechazada por dos motivos (1) En la lista de selección, el atributo
staffNumber
no está definido para la relación
8taff
(2) En la cláusula WHERE, la comparación '> 1O' es incompatible con el tipo de datos cadena de caracteres de longitud variable.
(debería ser position,
staffNo).
que es una
580
Sistemas de bases de datos
Completada esta etapa, la consulta de alto nivel habrá sido trasformada en algún tipo de representación interna más adecuada para su procesamiento. La forma interna que se suele elegir es algún tipo de árbol de consulta, que se construye de la forma siguiente: •
Se crea un nodo hoja para cada relación base de la consulta.
•
Se crea un nodo no hoja para cada relación intermedia producida por una operación de álgebra relaciona!.
•
La raíz del árbol representa el resultado de la consulta.
•
La secuencia de operaciones se dirige desde las hojas hacia la raíz.
La Figura 21.2 muestra un ejemplo de un árbol de consulta para la instrucción SQL del Ejemplo 21.1 que utiliza el álgebra relacional en su representación interna. Nos referiremos a este tipo de árbol de consulta denominándolo árbol de álgebra relacional.
(2) Normalización La etapa de normalización del procesamiento de consulta convierte la consulta en una forma normalizada que pueda manipularse más fácilmente. El predicado (en SQL, la condición WHERE), que puede ser arbitrariamente complejo, puede convertirse a una de dos formas aplicando unas pocas reglas de transformación (Jarke y Koch, 1984): •
Forma normal conjuntiva. Una secuencia de conjunciones conectadas mediante el operador /\ (AND). Cada conjunción contiene uno o más términos conectados mediante el operador v (OR). Por ejemplo: (position = 'Manager'
v salary > 20000) /\ branchNo = '8003'
Una selección conjuntiva contiene únicamente aquellas tuplas que satisfacen todas las conjunciones. •
Forma normal disyuntiva. Una secuencia de disyunciones conectadas mediante el operador v (OR). Cada disyunción contiene uno o más términos conectados mediante el operador /\ (AND). Por ejemplo, podríamos reescribir la forma normal conjuntiva anterior como: (position = 'Manager'
/\ branchNo = '8003' ) v (salary > 20000 /\ branchNo
= '8003')
Una selección disyuntiva contiene todas las tuplas formadas por la unión de todas las tuplas que satisfacen las disyunciones.
(3) Análisis semántica El objetivo del análisis semántico es rechazar las consultas normalizadas que estén incorrectamente formuladas o que sean contradictorias. Una consulta estará incorrectamente formulada si sus componentes no contribuyen a la generación del resultado, lo que puede suceder si faltan algunas especificaciones de combinación. Una consulta será contradictoria si su predicado no puede ser satisfecho por ninguna tupla. Por ejemplo, el predicado (position = 'Manager' /\ position = 'Assistant') para la relación Staff será contradictorio, ya que un empleado no puede ser a la vez Manager y Assistant. Sin embargo, el predicado ((position = 'Manager' /\
/~ !>
Raiz
s.branchNo=b.branchNo
i i
0s.position='Manager'
0b.city='London'
Operaciones intermedias
8taft
Branch
Hojas
i
Figura 21.2.
i
Ejemplo de árbol de álgebra relaciona!.
Capítulo 21 Procesamiento de consultas
581
position = 'Assistant') v salary > 20000) podría simplificarse a (salary > 20000) interpretándose la cláusula contradictoria como el valor booleano FALSE. Desafortunadamente, la manera de gestionar las cláusulas contradictorias no es coherente entre un SGBD y otro.
I
Ejemplo 21.2 Comprobación
de la corrección
semántica
Considere la siguiente consulta SQL: SELECT p.propertyNo, p.street FROM Client e, Viewing Y, PropertyForRent WHERE c.c1ientNo = Y.clientNo AND c.maxRent
>= 500
AND
p
c.prefType = 'Flat'
AND
p.ownerNo
=
'C093';
El grafo de conexión de relaciones mostrado en la Figura 21.3(a) no está completamente conectado, lo que implica que la consulta no está correctamente formulada. En este caso, hemos omitido la condición de combinación (Y.propertyNo = p.propertyNo) del predicado.
(a)
8·:·8
s· : ·s (b)
Figura 21.3. (a) Grafo de conexión de relaciones que muestra que la consulta está incorrectamente formulada; (b) grafo de conexión de atributos normalizado que muestra que la consulta es contradictoria.
582
Sistemas de bases de datos
Ahora considere la consulta: p.propertyNo,p.street Client c, Viewingv, PropertyForRent p WHERE c.maxRent > 500 ANOc.clientNo= v.c1ientNoANO v.propertyNo= p.propertyNoANOc.prefType = 'Flat'ANOc.maxRent < 200; SELECT FROM
El grafo de conexión de atributos normalizado para esta consulta se muestra en la Figura 21.3(b), donde podemos ver que tiene un ciclo entre los nodos c.maxRent y O con una suma de evaluación negativa, lo que indica que la consulta es contradictoria. Claramente, no podemos tener un cliente con un alquiler máximo que sea a la vez mayor de 500 euros e inferior a 200 euros.
Sólo existen algoritmos para determinar la corrección para el subconjunto de consultas que no contengan disyunciones y negaciones. Para estas consultas, podemos aplicar las siguientes comprobaciones: (1) Construimos un grajo de conexión de relaciones (Wong y Youssefi, 1976). Si el grafo no está conectado, la consulta estará incorrectamente formulada. Para construir un grafo de conexión de relaciones, creamos un nodo por cada relación y otro nodo para el resultado. Después dibujamos aristas entre dos nodos para representar una combinación y aristas entre los nodos que representen el origen de las operaciones de proyección. (2) Construimos un grajo de conexión de atributos normalizado (Rosenlcrantz y Hunt, 1980). Si el grafo tiene un ciclo para el que la suma de evaluación sea negativa, la consulta sería contradictoria. Para construir un grafo de conexión de atributos normalizado, creamos un nodo por cada referencia a un atributo o para la constante O. Después creamos una arista dirigida entre los nodo s que representen una combinación y una arista dirigida entre un nodo de atributo y un nodo de constante O que represente una operación de selección. A continuación, ponderamos las aristas a ~ b con el valor c, si representa la condición de desigualdad (a ::; b + c), y ponderamos las aristas O ~ a con el valor -c si representa la condición de desigualdad (a :::::c).
(4) Simplificación Los objetivos de la etapa de simplificación son detectar las cualificaciones redundantes, eliminar las subexpresiones comunes y transformar la consulta en otra consulta que sea semánticamente equivalente pero que se pueda calcular de forma más fácil y eficiente. Normalmente, las restricciones de acceso, las definiciones de vista y las restricciones de integridad se toman en consideración en esta etapa, pudiendo algunas de esas restricciones y definiciones introducir redundancia. Si el usuario no dispone de los derechos de acceso apropiados a todos los componentes de la consulta, será necesario rechazar ésta. Suponiendo que el usuario tenga los privilegios de acceso apropiados, una optimización inicial consiste en aplicar las muy conocidas reglas de idempotencia de álgebra booleana, como son: pl\(p)==p
pv(P)==p
P
1\
false ==false
p v false ==p
p
1\
true ==p
p v true ==true
p
1\
(~p) ==false
p v (~p) ==true
pl\(pvq)==p
pv(pl\q)==p
Por ejemplo, considere la siguiente definición de vista y la siguiente consulta realizada sobre la vista: CREATE VIEW Staff3AS SELECT staffNo,fName, IName,salary, branchNo FROM Staff WHERE branchNo = 'B003';
SELECT * FROM Staff3 WHERE (branchNo = 'B003' ANO salary > 20000);
Capítulo 21 Procesamiento de consultas
583
Como hemos explicado en la Sección 6.4.3, durante la resolución de la vista esta consulta se transformará en: SELECT staffNo, fName, IName, salary, branchNo FROM Staff WHERE (branchNo = 'B003' ANO salary > 20000)
ANO branchNo
=
'B003';
y la condición WHERE se reduce a (branchNo = 'B003' AND salary > 20000). También pueden aplicarse las restricciones de integridad para ayudar a simplificar las consultas. Por ejemplo, considere la siguiente restricción de integridad, que garantiza que sólo los empleados con categoría de Manager tengan un salario superior a 20.000 euros: CREATE ASSERTION OnlyManagerSalaryHigh CHECK ((position <> 'Manager' AND salary < 20000) OR (position = 'Manager' AND salary > 20000)); Y considere el efecto sobre la consulta: SELECT * FROM Staff WHERE (position
= 'Manager'
AND
salary
< 15000);
El predicado de la cláusula WHERE, que busca gerentes cuyo salario sea inferior a 15.000 euros, estará ahora en contradicción con la restricción de integridad, por lo que no puede haber ninguna tupla que satisfaga este predicado.
(5) Reestructuración
de la consulta
En la etapa final de la descomposición de una consulta, la consulta se reestructura para obtener una implementación más eficiente. Hablaremos más en detalle de la reestructuración en la sección siguiente.
21.3 Método heurístico de optimización de consultas En esta sección, vamos a examinar el método heurístico de optimización de consultas, que utiliza reglas de transformación para convertir una expresión de álgebra relacional en otra forma equivalente que se sepa que es más eficiente. Por ejemplo, en el Ejemplo 21.1 hemos observado que era más eficiente realizar la operación de selección sobre una relación antes de utilizar dicha relación en una combinación, en lugar de efectuar primero la combinación y luego la selección. Veremos en la Sección 21.3.1 que existe una regla de transformación que permite cambiar el orden de las operaciones de combinación y selección de modo que la selección pueda realizarse primero. Habiendo explicado cuáles son las transformaciones válidas, en la Sección 21.3.2 presentaremos un conjunto de reglas heurísticas que se sabe que producen estrategias de ejecución 'buenas' (aunque no necesariamente óptimas).
21.3.1
Reglas de transformación para las operaciones de álgebra relacional
Aplicando reglas de transformación, el optimizador puede transformar una expresión de álgebra relacional en otra expresión equivalente que se sabe que es más eficiente. Utilizaremos estas reglas para reestructurar el árbol de álgebra relacional (canónico) generado durante la descomposición de la consulta. El lector puede encontrar demostraciones de estas reglas en Aho el al. (1979). Al enumerar estas reglas, utilizaremos tres relaciones R, S Y T, estando R definida sobre los atributos A = {Al, Al, ... , An} Y S definida sobre B = {BI, Bl, ~ ... , Bn}; p, q y r denotan predicados y L, LI, Ll, M, M¡, Ml Y N denotan conjuntos de atributos.
(1) Las operaciones conjuntivas de selección pueden transformarse en una cascada de operaciones individuales de selección (y viceversa).
584 Sistemas de bases de datos
Esta transformación se denomina en ocasiones cascada de selecciones. Por ejemplo: =
U branchNo='B003' ASalarY>15000(Staff)
UbranchNo='B003'(U salary>15000(Staff))
(2) Conmutatividad de las operaciones de selección. =
up(uq(R))
uq(up(R))
Por ejemplo: =
U branchNo='B003'U salary>15000(Staff))
U salary>15000(u branchNo='B003,(Staff))
(3) En una secuencia de operaciones de proyección, sólo se requiere la última proyección de la secuencia. ITLITM' .. ITN(R)
=
ITL(R)
Por ejemplo: ITrNameITbranchNo,IName(Staff)
=
ITrName(Staff)
(4) Conmutatividad de la selección y la proyección. Si el predicado p implica sólo los atributos de la lista de proyección, entonces las operaciones de selección y de proyección son conmutativas: nAf,.Am
=
(up(R))
Up(TlAf,
.,Am (R))
donde
p E {Af, A2' ...
, Am)
Por ejemplo: =
ITfName,IName(UlName='Beech,(Staff))
UIName='Beech,(ITfName, IName(Staff))
(5) Conmutatividad de la combinación Theta (y del producto cartesiano). R [>
Puesto que la equicombinación y la combinación natural son casos especiales de la combinación Theta, entonces esta regla también se aplica a dichas operaciones de combinación. Por ejemplo, utilizando la equicombinación de Staff y Branch: 8taff
Branch
C>
Branch C>
Staff
(6) Conmutatividad de la selección y de la combinación Theta (o del producto cartesiano). Si el predicado de selección implica sólo atributos de una de las relaciones que están siendo combinadas, entonces las operaciones de selección y de combinación (o de producto cartesiano) son conmutativas: up(R
[>
up(R
X S)
=
=
(up(R))
(up(R))
[>
X S
donde
P E {A1' A2' ...
, An}
Alternativamente, si el predicado de selección es un predicado conjuntivo de la forma (p 1\ q), donde p implica sólo atributos de R y q implica sólo atributos de S, entonces las operaciones de selección y combinación Theta son conmutativas de la forma siguiente: upAq(R
[>
upAq(R
X S)
PO~jemplo:
=
=
(up(R))
(up(R))
[>
X (uq(S))
Capítulo 21 Procesamiento de consultas (T position='Manager'
Á
city= 'London,(Staff
(JPOSitiOn='Manager,(Staff))
C>
[>
585
=
Branch)
(T citY='London,(Branch))
(7) Conmutatividad de la proyección y de la combinación Theta (sobre el producto cartesiano). Si la lista de proyección tiene la forma L = L¡ U Lz, donde LI implica sólo atributos de R y Lz implica sólo atributos de s, entonces si la condición de combinación sólo contiene atributos de L, las operaciones de proyección y de combinación Theta son conmutativas: IlL1 v dR
C>
=
(IlL1
(R))
C>
Por ejemplo: Ilposition,
city, branchNo(Staff
(Ilpos;t;on,
bcanchNO(Staff))
[>
Branch) =
C>
Si la condición de combinación contiene atributos adicionales que no estén en L, como, por ejemplo, los atributos M = MI U Mz, donde MI implica sólo atributos de R y Mz implica sólo atributos de S, entonces se requiere una operación final de proyección: IlL1 vL2(R
C>
=
IlL1 vL2
IlL1 vM1
(R))
C>
Por ejemplo: Ilposition,
city(Staff
Ilposition,
city( (Ilposition,
[><]Staff.branchNo=Branch.branchNo
branchNO(Staff))
Branch)
=
C>
(Ilcity,
branchNO(Branch)))
(8) Conmutatividad de la unión y la intersección (pero no de la diferencia de conjuntos). RuS=SuR RnS=SnR
(9) Conmutatividad de la selección y de las operaciones de conjuntos (unión, intersección y diferencia de conjuntos). up(R
u
S)
=
up(S)
u
up(R)
up(R
n
S)
=
up(S)
U
up(R)
up(R
-
S)
=
up(S)
-
up(R)
(10) Conmutatividad de la proyección y la unión. IlL(R
u
S)
=
IlL(S)
u
IlL(R)
(11) Asociatividad de la combinación Theta (y del producto cartesiano). El producto cartesiano y la combinación natural son siempre asociativos: (R
C>
C>
(R x S) x T
=
R C>
C>
R x (S x T)
Si la condición de combinación q implica sólo atributos de las relaciones S and T, entonces la combinación Theta es asociativa de la siguiente forma: (R
C>
C>
=
R C>
C>
Por ejemplo: ~
(Staff Staff
C>
C>
C>
ownecNo Owner)
=
586
Sistemas de bases de datos
Observe que en este ejemplo sería incorrecto simplemente 'mover los paréntesis' ya que esto resultaría en una referencia no definida (Staff.IName)en la condición de combinación entre PropertyForRent y Owner: PropertyForRent
(12) Asociatividad
de la unión y la intersección
u S) u T (R n S) n T (R
I
[>
Á
Staff.IName=Ow[1er.IName
Owner
(pero no de la diferencia
de conjuntos).
u (R u T) = S n (R n T) =
S
Ejemplo 21.3 Utilización de las reglas de transformación Para los inquilinos en perspectiva que estén buscando apartamentos, satisfacen sus requisitos y son propiedad del propietario C093.
localizar los inmuebles que
Podemos escribir esta consulta en SQL como: SELECT p.propertyNo,p.street FROM Clientc, Viewingv, PropertyForRent p WHERE c.prefType = 'Flat' AND c.c1ientNo= v.c1ientNoAND v.propertyNo= p.propertyNoAND c.maxRent >= p.rent AND c.prefType = p.type AND p.ownerNo = 'C093'; Para los propósitos de este ejemplo, vamos a asumir que hay menos inmuebles propiedad del propietario C093 que inquilinos en perspectiva que hayan especificado como tipo preferido de inmueble el de apartamento (flat). Convirtiendo la instrucción SQL en álgebra relacional, tendremos: IIp,propertyNo,
p,street(
(J"
c.prefTyp'Flat'
1\
c.c1ientNo=v.c1ientNo
1\
v.propertyNo=p.propertyNo
1\
c.maxRent>=p.rent
A
c.prefType=p.type
1\
p,ownerNO='C093'(
(e xv) x p))
Podemos representar esta consulta mediante el árbol de álgebra relacional canónico que se muestra en la Figura 21.4(a). A continuación utilizamos las siguientes reglas de transformación para mejorar la eficiencia de la estrategia de ejecución: (1) (a) Regla 1, dividir la conjunción de operaciones de selección en operaciones de selección individuales. (b) Regla 2 y Regla 6, re ordenar las operaciones de selección y luego conmutar las selecciones y los productos cartesianos. El resultado de estas dos primeras etapas se muestra en la Figura 21.4(b). (2) Teniendo en cuenta lo explicado en la Sección 4.1.3, podemos reescribir una selección con un predicado de equicombinación y una operación de producto cartesiano como una operación de equicombinación, es decir: aRa=Sb(R
X S) = R ~Ra=Sb
S
Aplicamos esta transformación en todos los lugares apropiados. El resultado de este paso se muestra en la Figura 21.4(c). (3) Regla 11, re ordenación de las equicombinaciones de modo que la selección más restrictiva sobre (p.ownerNo = 'C093') se realice en primer lugar, como se muestra en la Figura 21.4(d). (4) Reglas 4 y 7, mediante las que movemos las proyecciones hacia abajo más allá de las equicombinaciones y creamos nuevas operaciones de proyección según sea necesario. El resultado de aplicar estas reglas se muestra en la Figura 21.4( e). l.
Capítulo 21 Procesamiento de consultas rr p.propertyNo,
587
p.street
t 0C,maxRent>=p.rent
1\
c.prefType=p.type
II
°v.propertyNo=p.prOpertyNo
TI
i
p.propertyNo,
Dc.prefType='Flaf
t
p.street
v.propertyNo=p.propertyNo
0c.maxRent>=p.rent"
/"x
/\ c.ctientNo=v.clientNo 1\
0c.c1ientNo=v.clientNo
1\
c.maxRent>=p.rent
0p.OwnerNO='C093'
1\
x
!
P
P
t>
V
(a)
I
(e)
i i 1\
rIp.propertyNo,
i i 1\
0c.maxRent>=p.rent
1\
0c,maxRent>""p.rent
p.street
CXlv.propertyNo=p.propertyNo
CXlv.propertyNo=p.propertyNo
!
V
TI
e
! \
IIp.propertyNo, p.street, p.rent, p.type
°p.ownerNo='C093'
I
p
p (e)
(d)
TIv.propertyNo, v.clientNo
v
p.street
°c.maxRent>=p.rent
c.prefTypeo;;;p.type
1\
0c.prefType='Flat'
i i 1\
ITp.propertyNo,
tx1c.clientNo=v.clientNo
c.clientNo,
c.maxRent,
c.preffype
\
1\ 0p.ownerNo='C093'
1\
p.street
~c.clientNo=v.clientNo
c.prefType=p.type
t:x:lc.c1ientNo=v.clientNo
t>
\
IT c.clientNo, c.maxRent
1\
°c.prefType='Flar
\
e
!
\
I1p.propertyNo, p.street Ilv,propertyNo, p.rent v.clientNo
!
0p.ownerNo='C093' p.type='Flat'
1\
0c.prefType='Flat'
\v
P (f)
Figura 21.4. Árbol de álgebra relacional para el Ejemplo 21.3: (a) árbol canónico de álgebra relacional; (b) árbol de álgebra relacional formado al llevar las selecciones hacia abajo; (c) árbol de álgebra relacional formado al cambiar las selecciones/productos cartesianos por equicombinaciones; (d) árbol de álgebra relacional que se forma aplicando la regla de asociatividad de las equicombinaciones; (e) árbol de álgebra relacional que se forma llevando las proyecciones forma susti\uyendo "
p
e
(b)
rr p.propertyNo,
\
v
°c.pretType='Flat'
e
v
°p.ownerNo='C093'
1\
1\
0c.prefType='Flar
1\
e
\
x
tP.ownerNOO'C093'
x
c.pretType=p.type
tx1 v.propertyNo=p.propertyNo
1\
r c.prefTypeop.type
i i 1\
p.propertyNo, p.street
t
hacia abajo; (f) árbol final reducido de álgebra relacional que se c.prefType 'Flat' la enselección la selección sobre p,type y llevando hacia abajo del=árbol resultante.
\e
588
Sistemas de bases de datos
Una optimización adicional en este ejemplo concreto consiste en observar que la operación de selección (c.preIType=p.type)puede reducirse a (p.type='Flat'), ya que sabemos que (c.preIType='Flat') de la primera cláusula del predicado. Utilizando esta sustitución, movemos esta selección hacia abajo en el árbol, lo que da como resultado el árbol final reducido de álgebra relacional que se muestra en la Figura 21.4(f).
21.3.2
~
Estrategias de procesamiento heurística
Muchos SGBD utilizan reglas heurísticas para determinar las estrategias de procesamiento de las consultas. En esta sección vamos a examinar algunas reglas heurísticas convenientes que pueden aplicarse para procesar las consultas.
(1) Realizar las operaciones de selección lo antes posible. La selección reduce la cardinalidad de la relación y el subsiguiente procesamiento de dicha relación. Por tanto, debemos utilizar la regla 1 para conectar en cascada las operaciones de selección y las reglas 2, 4, 6 y 9 referidas a las conmutatividad de la selección con las operaciones unarias y binarias, con el fin de mover las operaciones de selección lo más abajo posible en el árbol. Mantenga juntos los predicados de selección relativos a una misma relación.
(2) Combinar el producto cartesiano con una operación de selección subsiguiente cuyo predicado represente una condición de combinación, para formar una operación de combinación. Ya hemos observado que podemos reescribir una selección con un predicado de combinación Theta y una operación de producto cartesiano como una operación de combinación Theta:
(3) Utilizar la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que los nodos hoja con las operaciones de selección más restrictivas se ejecuten primero. De nuevo, la regla práctica consiste en realizar el máximo posible de reducciones antes de llevar a cabo las operaciones binarias. Así, si tenemos dos operaciones de combinación consecutivas que realizar:
debemos emplear las reglas 11 y 12 relativas a la asociatividad de la combinación Theta (y de la unión e intersección) para reordenar las operaciones de modo que las relaciones que nos de la combinación más pequeña se calculen primero, lo que significa que la segunda combinación también estará basada en un primer operando más pequeño.
(4) Realizar las operaciones de proyección lo antes posible. De nuevo, las operaciones de proyección reducen la cardinalidad de las relaciones y, por tanto, el subsiguiente procesamiento de las mismas. Por tanto, debemos emplear la regla 3 para conectar en cascada las operaciones de proyección y las reglas 4, 7 Y la referidas a la conmutatividad de la proyección y las operaciones binarias con el fin de mover las operaciones de proyección lo más abajo posible en el árbol. Hay que mantener juntos los atributos de proyección correspondientes a una misma relación.
(5) Calcular una única vez las expresiones comunes. Si una expresión común aparece más de una vez en el árbol y el resultado que produce no es excesivamente grande, hay que almacenar el resultado después de haberlo calculado la primera vez y luego reutilizarlo cada vez que se requiera. Esto sólo representará una ventaja si el tamaño del resultado correspondiente a la expresión común es lo suficientemente pequeño como para almacenarlo en memoria principal o como para poder acceder a él en el almacenamiento secundario con un coste inferior al de recalcular el resultado. Esto puede ser especialmente útil cuando se efectúan consultas sobre las vistas, puesto que puede utilizarse la misma expresión para calcular la vista cada vez.
Capítulo 21 Procesamiento de consultas
589
En la Sección 23.7 mostraremos cómo pueden aplicarse estas reglas heurísticas a las consultas distribuidas. En la Sección 28.5 se mostrará que algunas de estas reglas heurísticas pueden requerir un análisis adicional para los SGBD objeto-relacionales, que soportan consultas que contienen tipos definidos por el usuario y funciones definidas por el usuario.
21.4 Estimación de costes para las operaciones de álgebra relacional Un SGBD puede tener muchas formas distintas de implementar las operaciones de álgebra relacional. El objetivo de la optimización de consultas consiste en seleccionar la más eficiente. Para ello, utilice fórmulas que estiman los costes para una serie de opciones y seleccione aquella que tenga el coste menor. En esta sección vamos a examinar las diferentes opciones disponibles para implementar las principales operaciones de álgebra relacional. Para cada una de ellas, proporcionaremos una panorámica de la implementación y daremos un coste estimado. Puesto que el coste dominante en el procesamiento de consultas es usualmente el de los accesos a disco, que son lentos comparados con los accesos a memoria, nos concentraremos exclusivamente en el coste de los accesos a disco dentro de las estimaciones proporcionadas. Cada estimación representa el número requerido de accesos a bloques de disco, excluyendo el coste de escribir la relación que se genera como resultado de la consulta. Muchas de las estimaciones de coste están basadas en la cardinalidad de la relación. Por tanto, puesto que necesitamos poder estimar la cardinalidad de las relaciones intermedias, también mostraremos algunas estimaciones típicas que pueden deducirse para dichas cardinalidades. Comencemos esta sección examinando los tipos de estadísticas que el SGBD almacena en el catálogo del sistema para servir de ayuda durante la estimación de costes.
21.4.1
Estadísticas de la base de datos
El éxito en la estimación del tamaño y el coste de las operaciones de álgebra relacional intermedias depende de la cantidad y grado de actualización de la información estadística guardada por el SGBD. Normalmente, esperamos que el SGBD sea capaz de mantener las siguientes informaciones en su catálogo del sistema: Para cada relación base R •
nTuples(R): el número de tuplas (registros) en una relación R (es decir, su cardinalidad).
•
bFactor(R): el factor de bloqueo de R (es decir, el número de tuplas de R que caben en un bloque).
•
nBlocks(R): el número de bloques requeridos para almacenar R. Si las tuplas de R se almacenan físicamente juntas, se cumplirá que: nBlocks(R) = [nTuples(R)/bFactor(R)] Utilizamos [x] para indicar que el resultado del cálculo se redondea al entero más bajo que sea igualo supenor ax.
Para cada atributo •
A
de la relación base R
nDistinctA(R): el número de valores distintos que aparecen para el atributo
A
en la relación R.
en la relación R.
•
minA(R),maxA(R):los valores mínimo y máximo posibles para el atributo
•
SCA(R): la cardinalidad de selección del atributo A en la relación R. Se trata del número medio de tuplas que satisfacen una condición de igualdad para el atributo A. Si asumimos que los valores de A están uniformemente distribuidos en R y que existe al menos un valor que satisface la condición, entonces: si SCA (R)
=
tI[nTuples(R)
/ DistinctA (R)]
A
A
es un atributo clave de R
en caso contrario
También podemos estimar la cardinalidad de selección para otras condiciones:
590
Sistemas de bases de datos
[nTuples(R) * ((maxA (R) - c) /(maxA (R) - minA (R))]
para la desigualdad
(A
> c)
[nTuples(R) * ((c - maxA (R)) /(maxA (R) - minA (R))]
para la desigualdad
(A
< c)
SCA(R) = i[(nTUPleS(R) / nDistinctA (R)) * n] SC A(R) * SCs (R) SCA(R) + SCs (R) -SCA (R) * SCs (R)
perteneciente a
para
A
para
(A
¡\ B)
para
(A
v
{cl,
c2'··
.,
cn}
B)
Para cada índice multinivel 1 sobre el conjunto de atributos A •
nLevelsA(I): el número de niveles de I.
•
nLfBlocksA(I): el número de bloques hoja de I.
Mantener estas estadísticas actualizadas puede ser problemático. Si el SGBD actualiza las estadísticas cada vez que se inserta, actualiza o borra una tupla, esto tendrá un impacto significativo sobre las prestaciones en los momentos de mayor carga de trabajo. Una alternativa generalmente preferible consiste en que el SGBD actualice las estadísticas de forma periódica, por ejemplo durante la noche o cada vez que el sistema esté inactivo. Otro enfoque adoptado por algunos sistemas es hacer a los usuarios responsables de indicar que las estadísticas deben ser actualizadas.
21.4.2
Operación de selección (S = O"p(R»
Como hemos dicho en la Sección 4.1.1, la operación de selección en el álgebra relacional funciona sobre una única relación R, y define una relación S que contiene únicamente aquellas tuplas de R que satisfacen el predicado especificado. El predicado puede ser simple, implicando la comparación de un atributo de R con un valor constante o con otro valor de atributo, y también puede ser compuesto, implicando más de una condición, combinándose las distintas condiciones mediante las conectivas lógicas ¡\ (AND), v (OR) Y ~ (NOT). Existen diversas implementaciones distintas para la operación de selección, dependiendo de la estructura del archivo en que esté almacenada la relación y de si los atributos implicados en el predicado han sido indexados o se les ha aplicado una función hash. Las principales estrategias que vamos a considerar son: •
búsqueda lineal (archivo desordenado, sin índice);
•
búsqueda binaria (archivo ordenado, sin índice);
•
igualdad de la clave hash;
•
condición de igualdad de la clave principal;
•
condición de desigualdad de la clave principal;
•
condición de igualdad en un índice (secundario) de clústering;
•
condición de igualdad en un índice (secundario) no de clústering;
•
condición de desigualdad en un índice secundario de tipo B+-tree.
Los costes de cada una de estas estrategias se resumen en la Tabla 21.1.
Estimación de la cardinalidad
de la operación de selección
Antes de considerar estas opciones, vamos a presentar primero estimaciones para el número esperado de tuplas y el número esperado de valores distintos de un atributo en la relación resultado S obtenida al efectuar la operación de selección sobre R. Generalmente, es bastante difícil proporcionar estimaciones precisas; sin embargo, si aceptamos las suposiciones tradicionales de simplificación que suponen que los valores de los atributos están uniformemente distribuidos dentro de su dominio y que los atributos son independientes, podemos usar las siguientes estimaciones: nTuples(S)
= SCA(R)
el predicado p es de la forma (A e x)
Capítulo 21 Procesamiento de consultas Tabla 21.1.
591
Resumen del coste estimado de E/S para las estrategias correspondientes a una operación de selección.
Estrategias
Coste
Búsqueda lineal (archivo desordenado,
[nBlocks(R)/2], para una condición de igualdad sobre un atributo clave
sin índice)
nBlocks(R), en caso contrario
Búsqueda binaria (archivo ordenado, sin índice)
[loginBlocks(R»],
para una condición de igualdad sobre un atributo ordenado
[loginBlocks(R»]
+ [SCA(R)/bFactor(R)] - 1, en caso contrario
Igualdad de la clave hash
1, suponiendo que no se produzca desbordamiento
Condición de igualdad de la clave principal
nLevelsA(I) + 1
Condición de desigualdad de la clave principal
nLevelsA(I) + [nBlocks(R)/2]
Condición de igualdad en un índice (secundario) de clústering
nLevelsA(I) + [SCA(R)/bFactor(R)]
Condición de igualdad en un índice (secundario) no de clústering nLevelsA(I) + [nLfBlocksA(I)/2 nTuples(R)/2]
Condición de desigualdad en un índice secundario de tipo B+-tree
Para cualquier atributo
B *- A
de s: si nTuples(S) < nDistinctB (R)/2
nDistinctB (S) = [(nTuples(S) + nDistinctB (R»)/3] nDistinctB (R) {nTUPleS(S)
si nDistinctB (R)/2
:S:
nTuples(s)
:S:
2*nDistinctB (R)
si nTuples(S) > 2*nDistinctB (R)
Podemos calcular estimaciones más precisas si relajamos la suposición de la distribución uniforme de los valores, pero esto requiere el uso de información estadística más detallada, como, por ejemplo, histogramas y pasos de distribución (Piatetsky-Shapiro y Connell, 1984). Hablaremos brevemente de cómo utiliza Oracle los histogramas en la Sección 21.6.2.
(1) Búsqueda lineal (archivo desordenado, sin índice) Con esta técnica, puede se necesario analizar cada tupla de cada bloque para determinar si satisface el predicado, como se ilustra en el algoritmo resumidos que se ilustra en la Figura 21.5. Esto se denomina algunas veces exploración completa de tabla. En el caso de una condición de igualdad sobre un atributo clave, si suponemos que las tuplas están uniformemente distribuidas por el archivo sólo hará falta, por término medio explorar la mitad de los bloques para encontrar una tupla específica, por lo que la estimación de costes será: [nBlocks(R)/2] Para cualquier otra condición, puede que sea necesario explorar el archivo completo, por lo que la estimación más general de coste será: nBlocks(R)
(2) Búsqueda binaria (archivo ordenado, sin índice) Si el predicado tiene la forma (A = x) y el archivo está ordenado según el atributo to clave de la relación R, entonces la estimación de coste para la búsqueda será:
A,
que es también el atribu-
592
Sistemas de bases de datos
// // Búsqueda
lineal
/ / El predicado predicate es la clave de búsqueda. // El archivo no está ordenado. Los bloques están numerados
secuencialmente
a partir de 1.
/ / Devuelve una tabla de resultados que contiene las tuplas de R que satisfacen el predicado.
// for i = 1 to nBlocks(R) {
// recorrer en bucle cada bloque
block = read_bJock(R, i); for j = 1 to nTuples(block) {
/ / recorrer en bucle cada tupla del bloque i
if (block. tuple [j] satisfies predicate) then add tuple to result;
Figura 21.5.
Algoritmo para búsqueda lineal.
[log2(nBlocks(R))] El algoritmo para este tipo de búsqueda está esbozado en la Figura 21.6. Con carácter más general, la estimación de coste será: [log2(nBlocks(R))]
+
[SCA(R)/bFactor(R)] - 1
El primer término representa el coste de encontrar la primera tupla utilizando un método de búsqueda binaria. Esperamos que existan SCA(R)tuplas que satisfagan el predicado, las cuales ocuparán [SCA(R)/bFactor(R)] bloques, de los cuales uno ya ha sido extraído al localizar la primera tupla.
(3) Igualdad de la clave hash Si el atributo A es la clave hash, aplicamos el algoritmo hash para calcular la dirección correspondiente a la tupla. Si no hay ningún desbordamiento, el coste esperado será 1. Si hay desbordamiento, puede que sean necesarios accesos adicionales, dependiendo de la cantidad de desbordamiento y del medio para gestionarlo.
(4) Condición de igualdad de la clave principal Si el predicado implica una condición de igualdad para la clave principal (A = x), podemos utilizar el índice principal para extraer la única tupla que satisface esta condición. En este caso, necesitaremos leer un bloque más que el número de accesos de índice, equivalente al número de niveles del índice, por lo que el coste estimado será: nLevelsA(I)
+ 1
(5) Condición de desigualdad de la clave principal Si el predicado implica una condición de desigualdad para la clave principal A (A < x, A <= x, A > x, A >= x), podemos primero utilizar el índice para localizar la tupla que satisface el predicado A = x. Suponiendo que el índice está ordenado, podrá accederse a las tuplas requeridas leyendo todas las tuplas situadas antes o después de esta tupla que hemos localizado. Suponiendo una distribución uniforme, cabría esperar que la mitad de las tuplas satisfagan la desigualdad, por lo que el coste estimado será: nLevelsA(I)
= [nBlocks(R)/2]
(6) Condición de igualdad en un índice (secundario) de clústering Si el predicado implica una condición de igualdad para el atributo A, que no es la clave principal pero proporciona un índice secundario de clústering, podemos utilizar el índice para extraer las tuplas requeridas. El coste estimado será:
Capítulo 21 Procesamiento de consultas
593
// // Búsqueda
binaria
// El predicado predicate es la clave de búsqueda. // El archivo está ordenado según valores ascendentes de la clave de ordenación, A. // El archivo ocupa nBlocks bloques, numerados secuencialmente
a partir de l.
// Devuelve una variable booleana (found) que indica si se ha encontrado un registro que // se ajuste al predicado y una tabla de resultados en caso afirmativo. // next = 1; last = nBlocks; found = FALSE;keep_searching = TRUE; while (last >= 1 and (not found) and (keep_searching» i = (next + last)/2; block = read_block(R, i) ;
{
// la mitad del espacio de búsqueda
if (predicate < orderinll-key_fie1d(firsCrecord(block») then
// el registro se encuentra en la mitad inferior del área de búsqueda last=i-l;
else if (predicate > orderinll-key_fie1d(last_record(block») then
// el registro se encuentra en la mitad superior del área de búsqueda next= i + 1;
e1se if (check_block_for_predicate(block, then
predicate, result» // el registro requerido se encuentra en el bloque
found = TRUE; e1se
// el registro no está ahí keep _searching = FALSE;
Figura 21.6.
nLevelsA(I)
Algoritmo de búsqueda binaria en un archivo ordenado.
+ [SCA(R)/bFactor(R)]
El segundo término es una estimación del número de bloques que se requerirá para almacenar el número de tuplas que satisfacen la condición de igualdad, que hemos estimado como SCA(R).
(7) Condición de igualdad en un índice (secundario) no de clústering Si el predicado implica una condición de igualdad para el atributo A, que no es la clave principal pero proporciona un índice secundario no de clústering, podemos utilizar el índice para extraer las tuplas requeridas. En este caso, tenemos que asumir que las tuplas se encuentran en diferentes bloques (el índice no tiene estructura de clúster en este caso), por lo que el coste estimado será:
(8) Condición de desigualdad en un índice secundario de tipo B+-tree Si el predicado implica una condición de desigualdad para el atributo A (A < x, A <= x, A > x, A >= x), que proporciona un índice secundario de tipo B+-tree, entonces a partir de los nodos hoja del árbol podemos explorar las claves desde el valor más pequeño hasta x (para condiciones < o <=) o desde x hasta el valor máximo (para condiciones> o >=). Suponiendo una distribución uniforme cabría esperar que haya que acceder a la mitad de los bloques de nodos hoja y a la mitad de las tuplas (a través del índice). El coste estimado será entonces: nLevelsA(I)
+
[nLfBlocksA(I)/2
+ nTuples(R)/2]
El algoritmo para explorar un índice B+-tree en busca de una única tupla se muestra en la Figura 21.7.
594
Sistemas de bases de datos
// // Búsqueda
B+-tree
// La estructura B+-tree está representada como una lista enlazada en la que cada nodo no hoja está estructurado
como:
// un máximo de n elementos, cada uno compuesto por: //
un valor clave (key) y un puntero (P) a un nodo hijo (posiblemente NULL).
//
Las claves están ordenadas: keYl < keY2 < keY3 < ... < keYn_l
// Los nodos hoja apuntan a las direcciones
de los registros reales.
// El predicado predicate es la clave de búsqueda. // Devuelve un valor booleano (jound) que indica si el registro ha sido encontrado y // la dirección (return_address) //
del registro, en caso afirmativo.
nade = gecrooCnodeO; while (node is not a leaf node) { i = 1;
// localizar la clave que sea inferior al predicado
while (not (i > n al' predicate < node[i].key))
i = i + 1;
= gecnexcnode(node[i]
node
{
.pYi node[i].p apunta a un subárbol que puede contener un predicado.
}
// Se ha encontrado un nodo hoja, así que hay que comprobar si existe un registro con este predicado.
i = 1;
found = FALSE; while (not (found
01'
i > n)) {
if (predicate = node[i].key) then { found = TRUE; retufl1_address e\se
= node[i] .p;
i = i + 1;
Figura 21.7.
Algoritmo para explorar un árbol B+-tree en busca de una única tupla que se corresponda con un determinado valor.
(9) Predicados compuestos Hasta ahora, hemos limitado nuestro análisis a predicados simples que sólo implican un atributo. Sin embargo, en muchas-s-itQaciones el predicado puede ser compuesto, consistiendo en varias condiciones relativas a más de un atributo. Ya hemos observado en la Sección 21.2 que podemos expresar un predicado compuesto de dos formas: mediante la forma normal conjuntiva y mediante la forma normal disyuntiva:
~'
•
Una selección conjuntiva contendrá únicamente aquellas tuplas que satisfagan todas las conjunciones .
•
Una selección disyuntiva contendrá aquellas tuplas formadas por la unión de todas las tuplas que satisfagan todas las disyunciones.
Selección conjuntiva sin disyunción Si el predicado compuesto no contiene ningún término de disyunción, podemos considerar las siguientes téclllcas: (1) Si uno de los atributos en una conjunción tiene un índice o está ordenado, podemos utilizar una de las estrategias de selección 2-8 explicadas anteriormente para extraer las tuplas que satisfagan dicha con-
Capítulo 21 Procesamiento de consultas
595
dición. Después podemos comprobar si cada tupla extraída satisface las condiciones restantes del predicado. (2) Si la selección implica una condición de igualdad sobre dos o más atributos y existe un índice compuesto (o clave hash) sobre los atributos combinados, podemos explorar el índice directamente, como se ha explicado anteriormente. El tipo de índice determinará cuál de los algoritmos anteriores hay que utilizar. (3) Si hay índices secundarios definidos sobre uno o más atributos y, de nuevo, estos atributos están implicados únicamente en condiciones de igualdad dentro del predicado, entonces si los índices utilizan punteros de registro (un puntero de registro identifica unívocamente cada tupla y proporciona la dirección de la tupla al disco), en lugar de punteros de bloque, podemos explorar cada índice para encontrar las tuplas que satisfagan una condición individual. Formando a continuación la intersección de todos los punteros extraídos, tenemos el conjunto de punteros que satisfacen las condiciones. Si no hay disponibles índices para todos los atributos, podemos comprobar si las tuplas extraídas cumplen las condiciones restantes. Selecciones
con disyunción
Si uno de los términos de la condición de selección contiene un v (OR) y el término requiere una búsqueda lineal porque no existe ningún índice u ordenación adecuado, toda la operación de selección requerirá una búsqueda lineal. Sólo si existe un índice u ordenación para cada término de la selección podremos optimizar la consulta extrayendo las tuplas que satisfagan cada condición y aplicando la operación de unión, como se explica más abajo en la Sección 21.4.5, operación que también permitirá eliminar los duplicados. De nuevo, pueden utilizarse punteros de registros, si es que existen. Si no puede utilizarse ningún atributo para extraer de manera eficiente las tuplas, empleamos el método de la búsqueda lineal y comprobamos todas las condiciones simultáneamente para cada tupla. A continuación vamos a ver un ejemplo para ilustrar el uso de la estimación con la operación de selección.
I
Ejemplo 21.4 Estimación
de coste para una operación de selección
Para los propósitos de este ejemplo, vamos a hacer las siguientes suposiciones acerca de la relación Staff: • •
Existe un índice hash sin desbordamiento sobre el atributo de clave principal staffNo. Existe un índice de clústering sobre el atributo de clave externa branchNo.
•
Existe un índice B+-tree sobre el atributo salary.
•
La relación Stafftiene las siguientes estadísticas almacenadas en el catálogo del sistema:
~ Staff) =2 3000 30 =6= 10 50 50.000 10.000 nBlocks(Staff) SCbranchNo( Staff) == 100 300 500 SCposition( Staff)= nTuples(Staff) SCsalary( maxsalary(Staff) nLffilockssa'ary(I)
taff) alary(l)
El coste estimado de una búsqueda línea sobre el atributo clave staffNoes 50 bloques y el coste de una búsqueda lineal sobre un atributo no clave es de 100 bloques. A continuación, consideramos las siguientes operaciones de selección y utilizamos las estrategias anteriores para mejorar estos dos costes: SI: S2:
astaffNO='SG5,(Staff) aPosition='Manager,(Staff)
596
Sistemas de bases de datos S3: S4:
abranchNo='B003,(Staff) asalary>2oooo(Staff)
S5:
(J"position='Manager'
A
branchNo='B003,(Staff)
SI: Esta operación de selección contiene una condición de igualdad sobre la clave principal. Por tanto, como el atributo staffNo está almacenado con un método hash, podemos utilizar la estrategia 3 definida anteriormente para estimar el coste, que será de 1 bloque. La cardinalidad estimada de la relación resultante será SCstaffNo(Staff) = 1. S2: El atributo del predicado es un atributo no clave y no indexado, por lo que no podemos mejorar el método de la búsqueda lineal, lo que nos da un coste estimado de 100 bloques. La cardinalidad estimada de la relación resultante será SCposition(Staff) = 300. S3: El atributo del predicado es una clave externa con un índice de clústering, por lo que podemos utilizar la Estrategia 6 para estimar el coste, que será 2 + [6/30] = 3 bloques. La cardinalidad estimada de la relación resultante es SCbranchNO(Staff) = 6. S4: Este predicado implica una búsqueda de rango sobre el atributo salary, que tiene un índice B+-tree, por lo que podemos utilizar la Estrategia 7 y estimar el coste como: 2 + [50/2] + [3000/2] = 1527 bloques. Sin embargo, esto es significativamente peor que la estrategia en búsqueda lineal, por lo que en este caso utilizaríamos el método de búsqueda lineal directamente. La cardinalidad estimada de la relación resultante será SCsalariStaff)= [3000*(50000-20000)/(50000-10000)] = 2250. S5: En el último ejemplo, tenemos un predicado compuesto, pero la segunda condición puede implementarse utilizando el índice de clústering sobre branchNo (el caso S3 anterior), que sabemos que tiene un coste estimado de 3 bloques. Mientras extraemos cada tupla utilizando el índice de clústering, podemos comprobar si satisface la primera condición (position = 'Manager'). Sabemos que la cardinalidad estimada de la segunda condición es SCbranchNO(Staff) = 6. Si denominamos a esta relación intermedia T, podemos estimar el número de valores distintos de position en T, nDistinctposition(T), como: [(6 + 10)/3] = 6. Aplicando ahora la segunda condición, la cardinalidad estimada de la relación resultante será SCposition(T) = 6/6 = 1, que sería correcta si hubiera un único gerente por cada sucursal.
21.4.3
Operación de combinación (T = (R t><1F S))
Hemos mencionado al principio de este capítulo que una de las principales preocupaciones cuando se lanzó por primera vez comercialmente el modelo relacional era el rendimiento de las consultas. En particular, la operación que más preocupación suscitaba era la operación de combinación que, a parte del producto cartesia~o, es la más costosa en términos de tiempo de procesamiento, por lo que será necesario garantizar que se pueda ejecutar de la forma más eficiente posible. Recuerde, de la Sección 4.1.3, que la operación de combinación Theta define una relación que contiene tuplas que satisfacen un predicado específico F dentro del producto cartesiano de dos relaciones, por ejemplo R y s. El predicado F es de la forma R.a e S.b, donde e puede ser uno de los operadores lógicos de comparación. Si el predicado sólo contiene el operador de igualdad (=), la co,binación será una equicombinación. Si la combinación implica todos los atributos comunes de R y S, se denomina combinación natural. En esta sección, vamos a examinar las principales estrategias para implemen&r la operación de combinación: •
combinación mediante bucle anidado por bloques;
•
combinación de bucle anidado indexada;
•
combinación mediante ordenación-mezcla;
•
combinación hash.
Capítulo 21 Procesamiento de consultas Resumen de las estimaciones de coste de E/R de las distintas estrategias para la operación de combinación.
Tabla 21.2.
Coste
Estrategias Combinación
597
mediante
nBlocks(R) + (nBlocks(R) * nBlocks(S)),
bucle anidado por bloques
Combinación mediante bucle anidado indexado
si el búfer sólo tiene un bloque para R y S
nBlocks(R) para R
+
[nBlocks(S)*(nBlocks(R)/(nBuffer
nBlocks(R) de datos
+
nBlocks(S), si todos los bloques de R pueden leerse en el búfer de la base
- 2))], si hay (nBuffer - 2) bloques
Depende del método de indexación, por ejemplo:
Combinación mediante ordenación-mezcla
nBlocks(R) + nTuples(R)*(nLevelsA(I) clave principal
+
1), si el atributo de combinación A en S es la
nBlocks(R) + nTuples(R)*(nLevelsA(I) tering 1 sobre el atributo A
+
[SCiR)IbFactor(R)]),
nBlocks(R)*[log2(nBlocks(R)] nBlocks(R)
Combinación hash
+
3(nBlocks(R)
+ nBlocks(S)*[logz(nBlocks(S)],
para un índice de clúspara las ordenaciones
nBlocks(S), para las mezclas
+
nBlocks(S»,
si el índice hash se almacena en memoria
2(nBlocks(R) + nBlocks(S))*[lognBlllTer_¡(nBlocks(S)) - 1] + nBlocks(R) + nBlocks(S), en caso contrario
El lector interesado puede encontrar un resumen más completo de las estrategias de combinación en Mishra y Eich (1992). Las estimaciones de coste para las diferentes estrategias aplicables a las operaciones de combinación se resumen en la Tabla 21.2. Comenzaremos estimando la cardinalidad de las operaciones de combinación.
Estimación de la cardinalidad
de la operación de combinación
La cardinalidad del producto cartesiano de R y S, R x S, es simplemente: nTuples(R) * nTuples(S) Desafortunadamente, es mucho más difícil estimar la cardinalidad de cualquier combinación, ya que depende de la distribución de los valores de los atributos de combinación. En el caso peor, sabemos que la cardinalidad de la combinación no puede ser superior a la cardinalidad del producto cartesiano, por lo que: nTuples(T) ::; nTuples(R) * nTuples(S) Algunos sistemas utilizan esta cota superior, pero esta estimación es generalmente demasiado pesimista. Si volvemos a asumir una distribución uniforme de valores en ambas relaciones, podemos mejorar esta estimación para las equicombinaciones con un predicado (R.A = S.B) de la forma siguiente: (1) Si A es un atributo clave de R, entonces cada tupla de S sólo podrá ser combinada con una tupla de Por tanto, la cardinalidad de la equicombinación no puede ser superior a la cardinalidad de S: nTuples(T) ::; nTuples(S)
el) De forma similar, si
/
/
nTuples(T)::; (3) Si ni
A
ni
B
nTuples(T)
B es una clave de S, se cumplirá que:
nTuples(R) son claves, podemos estimar la cardinalidad de la combinación como:
= SCA(R)*nTuples(S)
R.
598
Sistemas de bases de datos o nTuples(T)
= SCB(S)*nTuples(R)
Para obtener la primera estimación, usamos el hecho de que para cualquier tupla s en s, podemos esperar como media SCA(R)tuplas con un determinado valor del atributo A y que este mismo número aparezca en la combinación. Multiplicando esto por el número de tuplas de s, se obtiene la primera de las estimaciones anteriores. Para la segunda estimación procederíamos de forma similar.
(1) Combinación
mediante bucle anidado por bloques
El algoritmo de combinación más simple es un bucle anidado que combine las dos relaciones entre sí, una tupla cada vez. El bucle externo recorre todas las tuplas de la relación R y el bucle interno recorre todas las tuplas de la segunda relación, S. Sin embargo, como sabemos que la unidad básica de lectura/escritura es el bloque de disco, podemos mejorar el algoritmo básico teniendo dos bucles adicionales que procesen los bloques, como se indica en el algoritmo resumido de la Figura 21.8. Puesto que cada bloque de R debe ser leído y cada bloque de S debe ser también leído para cada bloque de R, el coste estimado de esta solución será: nBlocks(R)
+ (nBlocks(R) * nBlocks(S))
Con esta estimación, el segundo término es fijo, pero el primer término podría variar dependiendo de cuál relación se elija para el bucle externo. Obviamente, deberemos elegir para el bucle externo la relación que ocupe el número más pequeño de bloques. Otra mejora de esta estrategia consiste en leer tantos bloques como sea posible de la relación más pequeña, por ejemplo R, en el búfer de la base de datos, guardando un bloque para la relación interna y otro para la relación resultante. Si el búfer puede albergar nBuffer bloques, entonces deberemos leer (nBuffer - 2) bloques de R en el búfer cada vez y un bloque de S. El número total de bloques de R al que se accede seguirá siendo nBlocks(R), pero el número total de bloques de S leídos se reduce a aproximadamente [nBlocks(S)* (nBlocks(R)/(nBuffer - 2))]. Con esta técnica, la nueva estimación de costes será: nBlocks(R)
+ [nBlocks(S)*(nBlocks(R)/(nBuffer
- 2))]
Si podemos leer todos los bloques de R y el búfer, esto se reduce a: nBlocks(R)
+ nBlocks(S)
//
// Combinación mediante bucle anidado por bloques // Los bloques en ambos archivos están numerados secuencialmente 1/
Devuelve una tabla de resultados que contiene la combinación
a partir de l.
de R y S.
1/
for iblock = 1 to nBlocks(R) {
1/
bucle externo
1/
bucle interno
Rblock = read_block(R, iblock); for jblock = 1 to nBlocks(S) { Sblock = read_block(S, jblock); fJr i = 1 to nTuples(Rblock) { iE (Rblock.tuple[i]!Sblock.tuple[j] then
match join condition)
add them to result;
for j = 1 to nTuples(Sblock) {
// }
Figura 21.8.
Algoritmo para la combinación
mediante bucle anidado por bloques.
Capítulo 21 Procesamiento de consultas
599
Si los atributos de combinación en una equicombinación (o combinación natural) constituyen una clave de la relación interna, entonces el bucle interno puede terminar en cuanto se encuentre la primera correspondencia.
(2) Combinación
mediante bucle anidado indexado
Si existe un índice (o función hash) sobre los atributos de combinación de la relación interna, podemos sustituir la ineficiente exploracíón del archivo por una búsqueda de índice. Para cada tupla en R, utilizamos el índice para extraer las tuplas correspondientes de s. El algoritmo de combinación por bucle animado indexado se esboza en la Figura 21.9. En aras a la claridad, utilizamos un algoritmo simplificado que procesa el bucle externo, de bloque en bloque. Sin embargo, como hemos indicado anteriormente, debemos leer tantos bloques de R en el búfer de base de datos como sea posible. Dejemos esta modificación del algoritmo como sea posible. Dejamos esta modificación del algoritmo como ejercicio para el lector (véase el Ejercicio 21.19). Este algoritmo es mucho más eficiente para una combinación, evitándose con él la enumeración del producto cartesiano de R y s. El coste de explorar R es nBlocks(R), como antes. Sin embargo, el coste de extraer las tuplas correspondientes en S dependerá del tipo de índice y del número de tuplas correspondientes. Por ejemplo, si el atributo de combinación A de S es la clave principal, la estimación de coste se hará: nBlocks(R)
+ nTuples(R)*(nLevelsA(I) + 1)
Si el atributo de combinación nBlocks(R)
A
en
S
es un índice de clústering, la estimación de coste será:
+ nTuples(R)*(nLevelsA(I) + [SCA(R)/bFactor(R)])
(3) Combinación
mediante ordenación-mezcla
Para las equicombinaciones, la combinación más eficiente se consigue cuando ambas relaciones están ordenadas según los atributos de combinación. En este caso, podemos buscar las tuplas apropiadas de R y S mezclando las dos relaciones. Si no están ordenadas, puede llevarse a cabo una etapa de preprocesamiento para ordenarlas. Puesto que las relaciones están ordenadas, las tuplas con el mismo valor del atributo de combinación estarán necesariamente en orden consecutivo. Si asumimos que la combinación es de tipo muchos a muchos, es decir, que puede haber muchas tuplas tanto de R como de S con el mismo valor de combinación, y si asumimos que de cada conjunto de tuplas con el mismo valor de combinación puede caber en el búfer de la base de datos, entonces cada bloque de cada relación sólo tendrá que ser leído una vez. Por tanto, la estimación de costes para la combinación mediante ordenación-mezcla es: //
// Combinación mediante bucle anidado indexado de R y S utilizando A como atributo de combinación // Suponga que hay un índice 1 sobre el atributo A de la relación S y que // hay m entrada de Úldice 1[1], 1[2], ... , I[m] con el valor indexado de la tupla R[i].A // Los bloques de R están numerados secuencialmente
a partir de 1.
// Devuelve una tabla de resultados que contiene la combinación //
de R y S.
or iblock = 1 to nBlocks(R) { Rblock
read_block(R, iblock);
for i = 1 to nTuples(Rblock) { for j = 1 to m { if (Rblock.tuple[i].A = I[j]) then
Figura 21.9.
add corresponding tuples to result;
Algoritmo para la combinación mediante bucle anidado indexado.
600
Sistemas de bases de datos nBlocks(R)
+ nBlocks(S)
Si es necesario ordenar una relación, por ejemplo R, tendríamos que añadir el coste de la ordenación, que podemos aproximar como: nBlocks(R)* [loglnBlocks(R))] En la Figura 21.10 se muestra un algoritmo resumido para la operación de combinación mediante ordenación-mezcla.
(4) Combinación
hash
Para una combinación natural (o equicombinación) también puede utilizarse un algoritmo de combinación hash para calcular la combinación de dos relaciones R y S según el conjunto de atributos de combinación A. La idea que subyace a este algoritmo consiste en particionar las relaciones R y S utilizando alguna función hash que presente características de uniformidad y aleatoriedad. Cada partición equivalente para R y S debe contener el mismo valor de los atributos de combinación, aunque puede contener más de un valor. Por tanto, el algoritmo tiene que comprobar las particiones equivalentes para ver si tienen el mismo valor. Por ejemplo, // // Combinación mediante ordenación-mezcla de R y S según el atributo de combinación A // El algoritmo presupone que la combinación es de tipo muchos a muchos // Se omiten las lecturas por simplicidad // Primero se ordenan R y S (esto no es necesario si los archivos ya están ordenados según los atributos // de combinación) sort(R); sort(S); // Ahora se realiza la mezcla nextR = 1; nextS = 1; while (nextR <= nTuples(R) and nextS <= nTuples(S)) { join_value = R.tuples[nextR].A; // Se explora S hasta encontrar un valor inferior al valor actual de combinación while (S.tuples[nextS].A < join_value and nextS <= nTuples(S)) { nextS = nextS + 1; }
// // // //
Puede que tengamos tuplas correspondientes de R y S. Para cada tupla de S con el valor join_ value, hay que hacerla corresponder que tenga el valor join_value. (Se asume una combinación M:N) while (S.tuples[nextS].A = join_value and nextS <= nTuples(S)) {
con cada tupla de R
m = nextR; while (R.tuples[m].A = join_value and m <= nTuples(R)) { add matching tuples S.tuples[nextS] and R.tuples[m] to res~lt; m =m+ 1; nextS = nextS + 1;
// Ya ~emos en~respondientes de R y S con el mismo valor join _ value // Ahora localizamos la siguiente tupla de R con un valor diferente de combinación while (R.tuples[nextR].A = join_value and nextR <= nTuples(R)) { nextR = nextR + 1;
Figura 21.10.
Algoritmo para la combinación
meOdianteordenación-mezcla.
Capítulo 21 Procesamiento de consultas
601
si la relación R se particiona en R¡, R2' ... , RM Y la relación S en SI' S2, ... , SMutilizando una función hash hQ, entonces si B y e son atributos de R y S respectivamente y h(RB) *- h(s.e), entonces RB *- s.e. Sin embargo, si h(RB) = h(S.e), esto no implica necesariamente que RB = s.e, ya que puede haber diferentes valores que se asignen al mismo valor hash. La segunda fase, denominadafase de comprobación, lee cada una de las particiones de R por turno y para cada una de ellas trata de combinar las tuplas de la partición con las tuplas de la partición de S equivalente. Si se utiliza una combinación de bucle anidado para la segunda fase, emplearemos la partición más pequeña como bucle externo, por ejemplo R¡.Leeremos la partición completa R¡en memoria y a continuación se leerá cada bloque de la parición S¡ equivalente y se usará cada tupla para comprobar si R¡ contiene tuplas correspondientes. Para mejorar la eficiencia, resulta común construir en memoria una tabla hash para cada partición R¡ utilizando una segunda función hash, diferente de la función hash empleada para el particionamiento. El algoritmo para la combinación hash se esboza en la Figura 21.11. Podemos estimar el coste de la combinación hash como: 3(nBlocks(R)
+ nBlocks(S»
Aquí estamos teniendo en cuenta que hay que leer R y S para particionarlas, escribir cada partición en disco y luego leer cada una de las particiones de R y S de nuevo para encontrar las tuplas correspondientes. Esta estimación es aproximada y no tiene en cuenta los desbordamientos que tengan lugar en una partición. 11
11Algoritmo
de combinación
hash
Se omiten las lecturas por simplicidad.
11 11 11
Se comienza particionando
R y S.
for i = 1 to nTuples(R) { hash_ value = hash_function(R.tuple[i]
.A);
add tuple R.tuple[i].A to the R partition corresponding to hash value, hash_ value; for j = 1 to nTuples(S) { hash_value = hash_function(S.tuple[j).A); add tuple S.tuple[j).A to the S partition corresponding to hash value, hash_value;
11
Ahora se ejecuta la fase de comprobación
(correspondencia).
for ihash = 1 to M { read R partition corresponding to hash value ihash; RP = Rpartition[ihash]; for i = 1 to max_tuples_in_R_partition(RP) 11
{
Construir un índice hash en memoria utilizando la función hash _ function2( ), diferente de hash _ function( ) new_hash = hash_function2(RP.tuple[i].A); add new_hash to in-memory hash index;
11
Exployar la partición S en busca de tuplas de R correspondientes = Spartition[ihash]; for j = 1 to max_tuples_in_S_partition(SP)
{
read S and probe hash table using hash_function2(SP.tuple[j].A); add all matching tuples to output; clear hash table to prepare for next partition;
Figura 21.11.
Algoritmo para una combinación
hash.
602
Sistemas de bases de datos
También presupone que el índice hash se pueda almacenar en memoria. Si no es así, el particionamiento de las relaciones no puede realizarse en una pasada y será necesario utilizar un algoritmo de particionamiento recursivo. En este caso, se puede demostrar que la estimación de costes es: 2(nBlocks(R)
+ nBlocks(S))*[lognBuffer_¡(nBlocks(S)) - 1]
+ nBlocks(R) + nBlocks(S) El lector interesado puede hallar una explicación más completa de los algoritmo s de combinación hash en Valduriez y Gardarin (1984), DeWitt el al. (1984) y DeWitt y Gerber (1985). En Shapiro (1986) se describe una serie de extensiones, incluyendo la combinación hash híbrida, y un estudio más reciente realizado por Davison y Graefe (1994) describe técnicas de combinación hash que pueden adaptarse a la memoria disponible.
I
Ejemplo 21.5 Estimación
de coste
para una operación
de combinación
Para los propósitos de este ejemplo, hacemos las siguientes suposiciones: •
Hay índices hash separados sin desbordamiento para los atributos de clave principal staftNo de 8taft y branchNo de Branch.
•
Hay 100 bloques de búfer de base de datos.
•
El catálogo del sistema contiene las siguientes estadísticas:
=} nBlocks(Staff) nBlocks(Branch) = 200 10 = 50 6000 30 500 100.000 nBlocks(PropertyForRent) = 2000 nTuples(Staff)
ForRent)
En la Tabla 21.3 se muestra una comparación de las anteriores cuatro estrategias para las dos combinaciones siguientes: 11: 8taft [>
Coste de E/S estimado para las operaciones de combinación del Ejemplo 21.5.
510 6030 Desordenadas NIDa J2 J1 La tabla hash hash cabe encaben 6600 memoria Claves 6200 Ordenadas 2010 20,010 25,800 Todos los bloques R el R búfer 24,240 400,200 (nBuffer --'-2) bloques para en Rde EstrategiasComentarios El búfer sólo tiene un bloque y 8 de la base de 4282 2200
datos Combinación mediante
aTodos los bloques de R pueden leerse en el búfer. bNo se pueden leer todos los bloques de R en el búfer.
Capítulo 21 Procesamiento de consultas
603
En ambos casos, sabemos que la cardinalidad de la relación resultante no puede ser mayor que la cardinalidad de la primera relación, ya que estamos realizando una combinación sobre la clave de la primera relación. Observe que ninguna de las estrategias es la mejor para ambas operaciones de combinación. La combinación mediante ordenación-mezcla funciona mejor para la primera combinación, dando por supuesto que ambas relaciones ya están ordenadas. Para la segunda combinación la mejor estrategia es la de combinación mediante bucle anidado indexado.
21.4.4
Operación de proyección (5 =
TIA" Au """, AJR))
La operación de proyección es también una operación unaria que define una relación S que contiene un subconjunto vertical de una relación R, extrayendo los valores de los atributos especificados y eliminando los duplicados. Por tanto, para implementar una proyección, debemos llevar a cabo los siguientes pasos: (l) eliminar los atributos no requeridos; (2) eliminar cualesquiera tuplas duplicadas que hayan resultado del paso anterior. El segundo paso es el más problemático, aunque sólo es necesario si los atributos de proyección no incluyen ninguna clave de la relación. Hay dos técnicas principales para eliminar los duplicados: la ordenación y las funciones hash. Antes de considerar estas dos técnicas, estimemos primero la cardinalidad de la relación resultante.
Estimación de la cardinalidad
de la operación de proyección
Cuando la proyección contiene un atributo clave, como no se requerirá la eliminación de duplicados, la cardinalidad de la proyección será: nTuples(S)
= nTuples(R)
Si la proyección consiste en un único atributo no clave (S la proyección como: nTuples(S)
= IIA(R)), podemos estimar la cardinalidad de
= SCA(R)
En caso contrario, si asumimos que la relación es un producto cartesiano de los valores de sus atributos, lo que en general es poco realista, podemos estimar la cardinalidad como: m
nTuples(s) :::;min(nTuples(R),
II nDistinct AI (R)) i=!
(1) Eliminación de los duplicados mediante ordenación El objetivo de esta técnica es ordenar las tuplas de la relación reducida utilizando todos los atributos restantes como clave de ordenación. Esto tiene el efecto de ordenar las tuplas de tal forma que los duplicados serán adyacentes y podrán eliminarse fácilmente a continuación. Para eliminar los atributos no deseados, tenemos que leer todas las tuplas de R y copiar los atributos requeridos a una relación temporal, lo que representa un coste nBlocks(R). El coste estimado de la ordenación es nBlocks(R)*[10g2(nBlocks(R))], por lo que el coste total será: nBlocks(R)
+ nBlocks(R)*[log2(nBlocks(R))]
En la Figura 21.12 se muestra un resumen del algoritmo correspondiente
a esta técnica.
604
Sistemas de bases de datos
11 11 11 11
Proyección mediante ordenación Suponemos que se está proyectando Devuelve la relación resultante S
la relación R sobre los atributos aJ, a2, ... , 3m.
11 11
Primero, se eliminan los atributos no deseados.
for iblock block for i
= 1 to nBlocks(R) { = read_block(R, iblock); = 1 to nTuples(block) { copy block.tuple[i].a¡,
11
block.tuple[i].a2'
... , block.tuple[i].am,
to output
T
Ahora se ordena T en caso necesario.
if {al' a2' ... , ami contains
a key
then
S =T; else { sort(T); 11
Finalmente,
se eliminan los duplicados.
i = 1; j = 2;
while (i <= nTuples(T)) output 11
{
T[i] to S;
Saltar los duplicados de esta tupla, si es que existen. while (T[i]
= T[j])
{
j = j + 1;
i = j; j = i + 1;
Figura 21.12.
Algoritmo de proyección mediante ordenación.
(2) Eliminación de duplicados mediante funciones hash La técnica de las funciones hash puede ser útil si tenemos un gran número de bloques de búfer en relación con el número de bloques de R. Este método tiene dos fases: particionamiento y eliminación de duplicados. En la fase de particionamiento, asignamos un bloque de búfer para leer la relación R y (nBuffer - 1) bloques de búfer para la salida. Para cada tupla de R, eliminamos los atributos no deseados y luego aplicamos una función hash h a la combinación de los atributos restantes, escribiendo la tupla reducida en el valor hash. La función hash h debe regirse de modo tal que las tuplas estén uniformemente distribuidas entre las (nBuffer - 1) particiones. Dos tuplas que pertenezcan a particiones distintas no serán, evidentemente duplicados, ya que tienen diferentes valores hash, lo que reduce el área de búsqueda para eliminación de duplicados a las particiones individuales. La segunda fase se lleva a cabo de la forma siguiente: •
Se lee por turno cada una de las (nBuffer - 1) particiones.
•
Se aplica una segunda función hash (diferente de la anterior) h20 a cada tupla a medida que se la lee.
•
Se inserta el valor hash calculado en una tabla hash que se conserva en memoria.
•
Si la tupla tiene el mismo valor hash que alguna otra tupla, se comprueba si las dos son iguales y se elimina la nueva en caso de tratarse de un duplicado.
•
Una vez procesada una partición, se escriben las tuplas de la tabla hash en el archivo de resultados.
Capítulo 21 Procesamiento de consultas Si el número de bloques requeridos para la tabla temporal resultante de la proyección de minación de duplicados es nb, el coste estimado será: nBlocks(R)
R
605
antes de la eli-
+ nb
Esto no incluye la escritura de la relación resultante y presupone que la aplicación de la función hash no requiere particiones de desbordamiento. Dejamos el desarrollo de este algoritmo como ejercicio para el lector.
21.4.5
Operaciones de conjuntos de álgebra relacional (T = R
u S,
T = R (\ S, T = R - S)
Las operaciones de conjuntos binarias de unión (R u s), intersección (R n S) y diferencia de conjuntos (R S) sólo se aplican a las relaciones que sean compatibles con respecto a la unión (véase la Sección 4.1.2). Podemos implementar estas operaciones ordenando primero ambas relaciones con respecto a los mismos atributos y luego explorando cada una de las relaciones ordenadas una vez para obtener el resultado deseado. En el caso de la unión, introduciremos en el resultado todas las tuplas que aparezcan en alguna de las dos relaciones originales, eliminando los duplicados según sea necesario. En el caso de la intersección, sólo incluiremos en el resultado aquellas tuplas que aparezcan en ambas relaciones. En el caso de la diferencia de conjuntos, examinaremos cada tupla de R y la incluiremos en el resultado sólo si no tiene ninguna tupla correspondiente en s. Para todas estas operaciones, podríamos desarrollar un algoritmo empleando el algoritmo de combinación mediante ordenación-mezcla como base. El coste estimado en todos los casos es simplemente: nBlocks(R) + nBlocks(S) + nBlocks(R)*[logz(nBlocks(R))]
+ nBlocks(S)*[logz(nBlocks(S))]
También podríamos utilizar un algoritmo hash para implementar estas operaciones. Por ejemplo, para la unión podríamos construir un índice hash en memoria para R y luego añadir las tuplas de S al índice hash sólo si no están ya presentes. Al final de esta fase añadiríamos las tuplas del índice hash al resultado.
Estimación de la cardinalidad
de las operaciones de conjuntos
De nuevo, puesto que los duplicados se eliminan al realizar la operación de unión, generalmente es bastante dificil estimar la cardinalidad de la operación, pero podemos dar sendos límites inferior y superior, que serán: max(nTuples(R),
nTuples(S)) :5 nTuples(T) :5 nTuples(R) + nTuples(S)
Para la diferencia de conjuntos, también podemos dar unos límites superior e inferior: o :5 nTuples(T) :5 nTuples(R) Considere la siguiente consulta SQL, que permite calcular el salario medio de los empleados: SELECT AVG(salary) FROM Staff; Esta consulta utiliza la función de agregación AVG. Para implementar esta consulta, podríamos explorar la relación Staff completa y llevar la cuenta del número de tuplas leídas y de la suma de todos los salarios. Al completar la operación, resulta fácil calcular la media a partir de estos dos valores de totalización. Ahora considere la siguiente consulta SQL, que calcula el salario medio de los empleados en cada sucursal: SELECT AVG(salary) FROM Staff GROUP BY branchNo; De nuevo, esta consulta utiliza la función de agregación AVG pero, en este caso, en conjunción con una cláusula de agrupación. Para las consultas de agrupación, podemos utilizar algoritmos de ordenación o de
606
Sistemas de bases de datos
hash de forma similar para eliminar los duplicados. Podemos estimar la cardinalidad de la relación resultante en presencia de una agrupación utilizando las estimaciones que hemos calculado anteriormente para las operaciones de selección. Dejamos esto como ejercicio para el lector.
21.5 Numeración de las estrategias de ejecución alternativas Un aspecto fundamental para garantizar la eficiencia del proceso de optimización de consultas es el espacio de búsqueda de posibles estrategias de ejecución y el algoritmo de numeración que se utilice para explorar este espacio en búsqueda de una estrategia óptima. Para una consulta dada, este espacio puede ser extremadamente grande. Por ejemplo, para una consulta que esté compuesta de tres combinaciones sobre las relaciones R, S Y T hay 12 diferentes ordenaciones posibles de combinación:
RM(SMT) SM(RMT)
RM(TMS) SM(TMR)
TM(RMS)
TM(SMR)
(SMT)MR (RMT)MS (RMS)MT
(TMS)MR (TMR)MS (SMR)MT
En general, con n relaciones, hay (2(n - l))!/(n - l)! ordenaciones diferentes de las combinaciones. Si n es pequeña, este número es manejable; sin embargo, a medida que se incrementa n, este número se hace extremadamente grande. Por ejemplo, si n = 4 el número de posibilidades es igual a 120; si n = 6 ese número es de 30.240; si n = 8, el número es superior a 17 millones y con n = 10, supera los 176.000 millones. Para agravar todavía más el problema, el optimizador puede también soportar diferentes métodos de selección (por ejemplo, búsqueda lineal o búsqueda basada en índices) y métodos de combinación (por ejemplo, combinación mediante ordenación-mezcla, combinación hash, etc.). En esta sección, vamos a ver cómo puede reducirse el espacio de búsqueda y cómo se lo puede procesar de manera eficiente. Vamos a examinar primero dos cuestiones que tienen relevancia para nuestras explicaciones: el concepto de pipelining y los árboles lineales.
21.5.1
Pipelining
En esta sección vamos a explicar otro concepto adicional que a veces se utiliza para mejorar las prestaciones de las consultas, el concepto de pipelining (algunas veces denominado procesamiento en cadena o procesamiento de flujos). En los análisis que hemos realizado hasta ahora, hemos dado por supuesto que los resultados de las operaciones intermedias de álgebra relacional se escribían temporalmente en el disco. Este proceso se conoce con el nombre de materialización: la salida de una operación se almacena en una relación temporal para ser procesada por la siguiente operación. Una técnica alternativa consiste en procesar en cadena los resultados de las distintas operaciones sin crear una relación temporal para almacenar el resultado intermedio. Obviamente, con esta técnica de pipelining podemos ahorramos el coste de crear relaciones temporales y volver a leer los resultados. Por ejemplo, al final de la Sección 21.4.2, hemos hablado de la implementación de la operación de selección cuando el predicado era compuesto, como por ejemplo en: cr position='Managcr'
Á
salarY>2oo00(Staff)
Si asumimos que hay un índice sobre el atributo salary, podríamos utilizar la regla de conexión en cascada de operaciones de selección para transformar esta selección en dos operaciones: (JPOSitiOn=
(Jsalary>2oo00(Staff))
Ahora, podemos utilizar el índice para procesar de manera eficiente la primera selección sobre salary, almacenar el resultado en una relación temporal y luego aplicar la segunda selección a la relación temporal. La técnica de procesamiento en cadena nos evita tener que crear la relación temporal y aplica en su lugar la segunda selección a cada tupla del resultado de la primera selección a medida que la generamos, añadiendo las tuplas que cumplan los criterios de la segunda operación al resultado final.
Capítulo 21 Procesamiento de consultas
Por regla general, una cadena de procesamiento (pipelining) se implementa como un proceso separado o área de procesamiento dentro del SGBD. Cada cadena de procesamiento toma un flujo continuo de tuplas como entrada y crea un flujo de tuplas como salida. Es necesario crear un búfer para cada pareja de operaciones adyacentes con el fin de almacenar las tuplas que están siendo pasadas de la primera operación a la segunda. Una desventaja de la técnica de pipelining es que las entradas necesarias para las distintas operaciones no necesariamente tienen que estar disponibles simultáneamente para su procesamiento. Esto puede restringir la elección de algoritmos. Por ejemplo, si tenemos una operación de combinación y las tuplas de entrada a la cadena de procesamiento no están ordenadas según los atributos de combinación, no podremos usil[ el algoritmo estándar de combinación mediante ordenación-mezcla. De todos modos, son muchas las oportunidades de aplicación de la técnica de pipelining en las estrategias de ejecución.
21.5.2 Árboles lineales Todos los árboles de álgebra relacional que hemos creado en las secciones anteriores en este capítulo son de la forma que se muestra en la Figura 21.13(a). Este tipo de árbol de álgebra relacional se denomina árbol (de combinación) de profundidad izquierda. El término hace referencia al modo en que las operaciones se combinan para ejecutar la consulta: por ejemplo, sólo se permite que el lado izquierdo de una combinación sea el resultado de otra combinación anterior y de aquí el nombre de árbol de profundidad izquierda. Para un algoritmo de combinación, el nodo hijo de la izquierda es la relación externa y el nodo derecho es la relación interna. Otros tipos posibles de árbol son el árbol de profundidad derecha, mostrado en la Figura 21.13(b) y el arbusto, mostrado en la Figura 21.13(d) (Graefe y DeWitt, 1987). Los arbustos también se denominan árboles no lineales, mientras que los árboles de profundidad izquierda y profundidad derecha se conocen con el nombre de árboles lineales. La Figura 21. 13(c) es un ejemplo de otro árbollíneal que no es ni de profundidad izquierda ni de profundidad derecha. Con los árboles lineales, la relación en uno de los lados en cada operador es siempre una relación base. Sin embargo, como necesitamos examinar la relación interna completa para cada tupla de la relación externa,
\ /\
""
607
"" e
/\ /\ /\
"" ""
D
""B ""
D
/\ /\ /\ ""
e
Figura 21.13.
D
/~
/\ /\
""
A
(e)
e
A(b)
""
B
A
B
e
""
D
(d)
(a) Árbol de profundidad izquierda; (b) árbol de profundidad (c) otro árbol lineal; (d) arbusto (no lineal).
derecha;
608
Sistemas de bases de datos
las relaciones internas deben siempre estar materializadas. Esto es lo que hace atractivos a los árboles de profundidad izquierda, ya que las relaciones internas son siempre relaciones base (y por tanto están ya materializadas). Los árboles de profundidad izquierda tienen las ventajas de reducir el espacio de búsqueda de la estrategia óptima y de permitir, por tanto, que el optimizador de consultas se base en técnicas de procesamiento dinámico, como veremos en breve. Su principal desventaja es que, al reducir el espacio de búsqueda, no se tomen en consideración muchas estrategias de ejecución alternativas, algunas de las cuales pueden tener un coste inferior al que se haya podido determinar utilizando el árbol lineal. Los árboles de profundidad izquierda permiten la generación de todas las estrategias completamente pipelinizadas, es decir, estrategias en las que todas las combinaciones se evalúan mediante la técnica de pipelining.
21.5.3
Operadores físicos y estrategias de ejecución
El término operador físico se utiliza en ocasiones para referirse a un algoritmo específico que implemente una operación lógica de base de datos, como, por ejemplo, una selección o una combinación. Por ejemplo, podemos utilizar el operador físico de combinación mediante relación-mezcla para implementar la operación de combinación de álgebra relacional. Sustituir las operaciones lógicas en un árbol de álgebra relacional para operadores físicos produce una estrategia de ejecución (también denominada plan de evaluación de la consulta o plan de acceso) para la consulta. La Figura 21.14 muestra un árbol de álgebra relacional y una estrategia de ejecución correspondiente. Aunque los SGBD tienen sus propias implementaciones internas, podemos considerar los siguientes operadores abstractos para implementar las funciones correspondientes a las hojas del árbol: (1) TableScan(R): (2) SortScan(R,
exploración de tabla. Todos los bloques de L):
R
se leen en un orden arbitrario.
exploración ordenada. Las tuplas de R se leen por orden, ordenadas de acuerdo con los atributos enumerados en la lista L.
(3) IndexScan(R,
P):
exploración indexada. P es un predicado de la forma A e c, donde A es un atributo de R, e es uno de los operadores normales de comparación y c es un valor constante. La forma de acceder a las tuplas de R es mediante un índice sobre el atributo A.
(4) IndexScan(R,
A):
exploración indexada. A es un atributo de R. Se extrae la relación completa R utilizando el índice definido sobre el atributo A. Es similar a TableScan, pero puede ser más eficiente bajo ciertas condiciones (por ejemplo, si R no utiliza clústeres).
Además, el SGBD soporta usualmente una interfaz iteradora uniforme, ocultando así los detalles internos de implementación de cada operador. La interfaz iteradora está compuesta de las siguientes tres funClOnes:
7~
/~ Staff (a)
Combinación bucle anidado mediante indexado
PropertyForRent
""s.branchNo=b.branchNo
O'~T-"""
Combinación hash
00" plp,!;,I'g Operación pipelining
"""T-
hash sobre position utilizando el índice
Branch
""s.staffNo=p.staffNo
/
/,
B+-tree sobre ~StaffNo
7~
0s.position='Manager"
Pmp'rty,,,",,1
0b.city='London'
r
r
Staff
Branch
(b)
Figura 21.14. (a) Ejemplo de árbol de álgebra relacional; (b) una estrategia de ejecución correspondiente.
Operación utilizando el pipelining índice hash sobre city
Capítulo 21 Procesamiento de consultas
609
(1) Open:
esta función inicializa el estado del iterador antes de extraer la primera tupla y asigna búferes para las entradas y para las salidas. Sus argumentos pueden definir condiciones de selección que modifiquen el comportamiento del operador
(2) GetNext:
esta función devuelve la siguiente tupla del resultado y la coloca en el búfer de salida. GetNext llama a GetNext en cada nodo de entrada y ejecuta algún código específico del operador para procesar las entradas con el fin de generar las salidas. El estado del iterador se actualiza para reflejar cuántas entradas han sido consumidas.
(3) Close:
cuando todas las tuplas de salida han sido generadas (mediante llamadas repetidas a GetNext), la función Close termina el operador y realiza las tareas de limpieza final, desasignando los búferes según sea necesario.
Cuando se utilizan iteradores, puede haber muchas operaciones activas simultáneamente. Las tuplas se pasan entre los operadores según sea necesario, soportando así de forma natural el concepto de pipelining. Sin embargo, la decisión de utilizar una cadena de procesamiento (pipelining) o de materializar los valores intermedios depende del código específico del operador que procese las tuplas de entrada. Si este código permite procesar las tuplas de entrada a medida que se recibe, se utiliza pipelining. Si este código procesa las mismas tuplas de entrada más de una vez, se utiliza la técnica de materialización.
21.5.4
Reducción del espacio de búsqueda
Como hemos mostrado al principio de esta sección, el espacio de búsqueda para una consulta complicada puede ser enorme. Para reducir el tamaño del espacio que la estrategia de búsqueda tiene que explorar, los optimizadores de consultas suelen restringir este espacio de diversas maneras. La primera de las restricciones comunes se aplica a las operaciones unarias de selección y proyección: Restricción
1:
las operaciones unarias se procesan sobre la marcha: las selecciones se procesan a medida que se accede a las relaciones por primera vez; las proyecciones se procesan a medida que se generan los resultados de otras operaciones.
Esto implica que todas las operaciones se tratan como parte de la ejecución de las combinaciones. Considere ahora la siguiente versión simplificada de la consulta del Ejemplo 21.3:
SELECT p.propertyNo, FROM Client e, Viewing WHERE
p.street v, PropertyForRent
c.clientNo =v.clientNo
AND
p
v.propertyNo
= p.propertyNo;
Teniendo en cuenta las explicaciones proporcionadas al principio de esta sección, hay 12 posibles ordenaciones de las combinaciones para esta consulta. Sin embargo, observe que algunas de estas ordenaciones dan como resultado un producto cartesiano en lugar de una combinación. Por ejemplo: Viewing 1><1(Client 1><1PropertyForRent)
da como resultado el producto cartesiano de Client y PropertyForRent. La siguiente reducción elimina los árboles de combinación sub óptimos que incluyen un producto cartesiano: Restricción
2:
nunca se forman productos cartesianos a menos que la propia consulta especifique uno.
La última de las reducciones comunes se refiere a la forma de los árboles de combinación y, como se explica en la Sección 21.5.2, utiliza el hecho de que con los árboles de profundidad izquierda el operando izquierdo es una relación base y, por tanto, ya está materializada: Restricción
3:
el operando interno de cada combinación es siempre una relación base, nunca un resultando intermedio.
Esta tercera restricción es de una naturaleza más heurística que las otras dos y excluye muchas estrategias alternativas, algunas de las cuales pueden tener un coste inferior al del de las que podemos encontrar utilizando el árbol de profundidad izquierda. Sin embargo, se suele considerar que el árbol de profundidad izquierda óptimo no resulta, en la mayoría de las ocasiones, mucho más caro que el árbol óptimo absoluto. Además, la
610
Sistemas de bases de datos
tercera restricción reduce significativamente el número de estrategias de combinación alternativas que hay que considerar, que pasa a ser 0(2") para las consultas con n relaciones y tiene una complejidad asociada en términos de tiempo igual a 0(3"). Usando esta técnica, los optimizadores de consultas pueden manejar eficientemente combinaciones con unas 10 relaciones, lo que permite procesar la mayoría de las consultas que tienen lugar en las aplicaciones empresariales tradicionales.
21.5.5
Enumeración de árboles de profundidad izquierda
La enumeración de árboles de profundidad izquierda mediante programación dinámica se propuso por primera vez para el optimizador de consultas de System R (Selinger et al., 1979). Desde entonces, muchos sistemas comerciales han utilizado esta técnica básica. En esta sección proporcionamos una panorámica del algoritmo, que es esencialmente un algoritmo de búsqueda exhaustiva con poda dinámica. El algoritmo de programación dinámica se basa en la suposición de que el modelo de costes satisface el principio de optirnalidad. Así, para obtener la estrategia óptima para una consulta consistente en n combinaciones, sólo necesitamos considerar las estrategias óptimas para subexpresiones compuestas por (n - 1) combinaciones y extender dichas estrategias con una combinación adicional. Las restantes estrategias sub óptimas pueden descartarse. El algoritmo reconoce, sin embargo, que en esta forma simple podrían llegar a descartarse algunas estrategias potencialmente útiles. Considere la siguiente consulta: SELECT p.propertyNo, p.street FROM Client c, Viewing v, PropertyForRent WHERE c.maxRent < 500 AND c.clientNo v.propertyNo
p = v.clientNo
AND
= p.propertyNo;
Suponga que existen índices B+-tree separados sobre los atributos c1ientNo y maxRent de Client y que el optimizador soporta tanto combinaciones mediante ordenación-mezcla como combinaciones mediante bucles anidados de bloques. Al considerar todas las formas posibles de acceder a la relación Client, calcularíamos el coste de una búsqueda lineal en la relación y el coste de utilizar los dos índices de tipo B+-tree. Si la estrategia óptima implicara utilizar el índice B+-tree sobre maxRent, descartaríamos entonces los otros dos métodos. Sin embargo, la utilización del índice B+-tree sobre c1ientNo daría como resultado que la relación Client se ordenara según el atributo de combinación clientNo, lo que nos daría un coste inferior para una combinación mediante ordenación-mezcla de Client y Viewing (ya que una de las relaciones ya está ordenada). Para garantizar que dichas posibilidades no se descarten, el algoritmo introduce el concepto de ordenaciones interesantes: un resultado intermedio tiene una ordenación interesante si está ordenado según un atributo ORDER BY final, según un atributo GROUP BY o según cualquier atributo que participe en combinaciones subsiguientes. Para nuestro ejemplo anterior, los atributos c.clientNo, v.c1ientNo, v.propertyNo y p.propertyNo son interesantes. Durante la optimización, si algún resultado intermedio está ordenado según alguno de estos atributos, la correspondiente estrategia parcial deberá incluirse en la búsqueda. El algoritmo de programación dinámica lleva a cabo su tarea de abajo hacia arriba y construye todos los árboles de combinación alternativos que satisfacen las restricciones definidas en la sección anterior, operando de la forma siguiente: Pasada 1: enumeramos las estrategias para cada relación base utilizando una búsqueda lineal y todos los índices disponibles para la relación. Estas estrategias parciales (para una única relación) se particionan en clases de equivalencia basándose en las ordenaciones interesantes, como hemos comentado anteriormente. Se crea también una clase de equivalencia adicional para las estrategias parciales que no tengan una ordenación interesante. Para cada clase de equivalencia, retenemos la estrategia de menor coste para tomada en consideración en la siguiente pasada. Si la estrategia de menor coste para la clase de equivalencia que carece de ordenaciones interesantes no es inferior a todas las demás estrategias, no la conservamos. Para una relación R dada, las selecciones que impliquen únicamente atributos de R se procesan sobre la marcha. De forma similar, también se puede procesar en esta etapa los atributos de R que no formen parte de la cláusula SELECT y que no contribuyan a ninguna combinación subsiguiente (véase la Restricción 1 anterior)
Capítulo 21 Procesamiento de consultas
611
Pasada 2: generamos todas las estrategias para dos relaciones considerando cada una de las estrategias para una relación conservada después de la Pasada 1 como relación externa, descartando los productos cartesiano s generados (Restricción 2 anterior). De nuevo, realizamos cualquier procesamiento sobre la marcha que sea necesario y conservamos la estrategia de menor coste de cada clase de equivalencia para un análisis ulterior. Pasada k: generamos todas las estrategias para k relaciones considerando cada una de las estrategias que hayamos retenido después de la Pasada (k ~ 1) como relación externa, descartando de nuevo los productos cartesianos generados y procesando las selecciones y proyecciones sobre la marcha. De nuevo, retenemos la estrategia de menor coste de cada clase de equivalencia para un procesamiento ulterior. Pasada n: generamos todas las estrategias para n relaciones considerando como relación externa cada una de las estrategias que hayamos conservado después de la pasada (n - 1) Y descartando los posibles productos cartesianos que se hayan generado. Después de la poda, tendremos ahora la estrategia global de menor coste para un procesamiento de la consulta. Aunque este algoritmo sigue siendo exponencial, hay algunos tipos de consultas para los que sólo genera estrategias, por lo que para n = 10 el número de estrategias es 1000, lo cual es significativamente mejor que los 176.000 millones de diferentes ordenaciones de combinaciones que habíamos visto al principio de esta sección. O(n3)
21.5.6
Optimización semántica de consultas
Otra técnica diferente para la optimización de consultas se basa en utilizar las restricciones especificadas en el esquema de la base de datos para reducir el espacio de búsqueda. Esta técnica, denominada optimización semántica de consultas, puede utilizarse en conjunción con las técnicas anteriormente explicadas. Por ejemplo, en la Sección 6.2.5 hemos definido la restricción general que evita que un empleado gestione más de 100 inmueble s al mismo tiempo, utilizando la siguiente aserción: CREATE ASSERTION StaffNotHandlingTooMuch CHECK (NOT EXISTS (SELECT staffNo FROM PropertyForRent GROUP BY staffNo HAVING COUNT(*) > 100)) Considere ahora la siguiente consulta: SELECT s.staffNo, COUNT(*) FROM Staff s, PropertyForRent WHERE s.staffNo = p.staffNo GROUP BY s.staffNo
p
HAVING COUNT(*) > 100; Si el optimizador es consciente de esta restricción, puede evitarse tratando de optimizar la consulta, ya que no habrá ningún grupo que satisfaga la cláusula HAVING. Considere ahora la siguiente restricción sobre el salario de un empleado: CREATE ASSERTION ManagerSalary CHECK (salary > 20000 AND
position =
'Manager')
y la siguiente consulta: SELECT s.staffNo, fName, IName, propertyNo FROM Staff s, PropertyForRent p WHERE s.staffNo = p.staffNo AND position = 'Manager'; Utilizando la restricción anterior, podemos reescribir esta consulta como: SELECT
s.staffNo, fName, IName, propertyNo
612
Sistemas de bases de datos
FROM Staff s, PropertyForRent p WHERE s.staffNo" p.staffNo AND
salary
> 20000 AND
position"
'Manager';
Este predicado adicional puede ser muy útil si el único índice para la relación Staff es un índice B+-tree sobre el atributo salary. Por otro lado, este predicado adicional complicaría la consulta si no existiera dicho índice. Para tener información adicional sobre la optimización semántica de consultas, el lector interesado puede consultar King (1981); Malley y Zdonik (1986); Chakravarthy et al. (1990); Siegel et al. (1992).
21.5.7 Técnicas alternativas de optimización de consultas La optimización de consultas es un campo en el que se han llevado a cabo numerosas investigaciones, habiéndose propuesto diversas alternativas al algoritmo de programación dinámica de System R. Por ejemplo, la técnica de templado simulado realiza una búsqueda en un grafo cuyos nodos están constituidos por estrategias de ejecución alternativas (esta técnica modela el proceso de templado mediante el que se pueden recrecer cristales, calentando primero el fluido que los contiene y luego dejándolo enfriarse lentamente). Cada nodo tiene un coste asociado y el objetivo del algoritmo es localizar un nodo con un coste global mínimo. Un movimiento de un nodo a otro se considerará cuesta abajo (cuesta arriba) si el coste del nodo de origen es superior (inferior) al coste del nodo de destino. Un nodo será un mínimo local si para todas las rutas que dan comienzo en ese nodo cualquier movimiento cuesta abajo viene siempre precedido de un movimiento cuesta arriba. Un nodo será un mínimo global si tiene el menor coste de entre todos los nodos. El algoritmo realiza un paseo aleatorio continuo aceptando siempre los movimientos cuesta abajo y aceptando los movimientos cuesta arriba con un cierto valor de probabilidad, para tratar de no quedarse con un mínimo local de alto coste. La probabilidad de aceptar un movimiento cuesta arriba decrece con el tiempo y llega al final a ser cero, en cuyo momento se detiene la búsqueda y se devuelve como estrategia óptima de ejecución el nodo visitado que tenga el menor coste. El lector interesado puede consultar Kirkpatrick et al. (1983) y Ioannidis y Wong (1987). El algoritmo de mejora iterativa realiza una serie de optimizaciones locales, comenzando cada una de ellas en un nodo aleatorio y aceptando repetidamente movimientos cuesta abajo hasta que se alcanza un mínimo local. El lector interesado puede consultar Swami y Gupta (1988) y Swami (1989). El algoritmo de optimización en dos fases es un híbrido del templado simulado y de la mejora iterativa. En la primera fase, se utiliza la mejora iterativa para realizar determinadas optimizaciones locales que dan como resultado algún mínimo local. Este mínimo local se utiliza como entrada para la segunda fase, que está basada en el templado simulado con una baja probabilidad de partida para los desplazamientos cuesta arriba. El lector interesado puede consultar Ioannidis y Kang (1990). Los algoritmo s genéticos, que simulan un fenómeno biológico, también se han aplicado a la optimización de consultas. Los algoritmos comienzan con una población inicial, compuesta por un conjunto aleatorio de estrategias, cada una de ellas con su propio coste. A partir de esta población inicial, se combinan pares de estrategias extraídas de esa población para generar descendientes que heredan las características de ambos padres, aunque esos descendientes pueden sufrir pequeñas modificaciones de forma aleatoria (mutación). Para la siguiente generación, el algoritmo retiene los padres/hijos de mínimo coste. El algoritmo termina cuando toda la población está compuesta por copias de la misma estrategia (óptima). El lector interesado puede consultar Bennett et al. (1991). El algoritmo heurístico A * se ha utilizado en inteligencia artificial para resolver problemas de búsqueda complejos y también se ha empleado en la optimización de consultas (Yoo y Lafortune, 1989). A diferencia del algoritmo de programación dinámica anteriormente explicado, el algoritmo A * expande una estrategia de ejecución cada vez, basándose en su proximidad a la estrategia óptima. Se ha demostrado que A * genera una estrategia completa mucho antes que la programación dinámica y es capaz de realizar la poda del árbol de búsqueda de manera mucho más agresiva.
21.5.8
Optimización distribuida de consultas
En los Capítulos 22 y 23 hablaremos de los SGBD distribuidos (SGBDD), que están compuestos por una colección lógicamente interrelacionada de bases de datos distribuidas físicamente en una red informática y
Capítulo 21 Procesamiento de consultas
613
cada una de ellas bajo control de un SGBD local. En un SGBDD, una relación puede dividirse en una serie de fragmentos distribuidos entre una serie de sistemas; esos fragmentos pueden ser replicados. En la Sección 23.6 veremos el tema de la optimización de consultas en un SGBDD. La optimización de consultas distribuidas es más compleja debido a la distribución de los datos entre los diferentes sitios de la red. En el entorno distribuido, además de los costes de procesamiento local (es decir, costes de procesador y de E/S), es necesario tomar en consideración la velocidad de la red subyacente a la hora de comparar diferentes estrategias. En particular, analizaremos una extensión del algoritmo de programación dinámica de System R que hemos expuesto anteriormente, así como el algoritmo de optimización de consultas de otro proyecto de investigación sobre sistemas SGBDD muy conocido, denominado SDD-l.
21.6 Optimización de consultas en Oracle Para completar este capítulo, vamos a examinar los mecanismos de optimización de consultas utilizados en Oracle9i (Oracle Corporation, 2004b). Restringiremos nuestro análisis en esta sección a las técnicas de optimización basadas en tipos de datos primitivos. Posteriormente, en la Sección 28.5, veremos cómo proporciona Oracle un mecanismo de optimización ampliable para gestionar los tipos definidos por el usuario. En esta sección emplearemos la terminología Oracle, refiriéndonos a las relaciones mediante el término tabla y estando las tablas compuestas de columnas y filas. En la Sección 8.2 el lector puede encontrar una introducción a Oracle.
21.6.1 Optimización basada en reglas y basada en costes Oracle soporta las técnicas de optimización de consultas que hemos expuesto en este capítulo: optimización basada en reglas y optimización basada en costes.
El optimizador
basado en reglas
El optimizador basado en reglas de Oracle tiene 15 reglas, ordenadas según su eficiencia, como se muestra en la Tabla 21.4. El optimizador puede seleccionar la utilización de una ruta de acceso concreta a una tabla sólo si la instrucción contiene un predicado u otro tipo de estructura que haga que esa ruta de acceso esté disponible. El optimizador basado en reglas asigna una puntuación a cada estrategia de ejecución utilizando estas clasificaciones y luego selecciona la estrategia de ejecución con la mejor puntuación (es decir, la más baja). Cuando dos estrategias tienen la misma puntuación, Oracle resuelve el empate tomando una decisión que depende del orden en que aparezcan las tablas dentro de la instrucción SQL, lo que no parece que sea una forma particularmente buena de tomar la decisión final. Por ejemplo, considere la siguiente consulta sobre la tabla PropertyForRent y suponga que tenemos un índice sobre la clave principal, propertyNo, otro índice sobre la columna rooms y otro más sobre la columna city: SELECT propertyNo FROM PropertyForRent WHERE rooms > 7 AND city = 'London'; En este caso, el optimizador basado en reglas considerará las siguientes rutas de acceso: • • •
Una ruta de acceso mono-columna utilizando el índice sobre la columna city de la condición WHERE (city = 'London'). Esta ruta de acceso tiene rango 9. Una exploración de rango no limitado utilizando el índice sobre la columna rooms de la condición WHERE (rooms > 7). Esta ruta de acceso tiene rango 11. Una exploración completa de tabla, que está disponible para todas las instrucciones SQL. Esta ruta de acceso tiene rango 15.
Aunque hay un índice para la columna propertyNo, esta columna no aparece en la cláusula WHERE y el optimizador basado en reglas, como consecuencia, no la toma en consideración. Basándose en estas rutas, el optimizador basado en reglas decidirá utilizar el índice referido a la columna city. En la actualidad, la optimización basada en reglas está desaconsejada por Oracle.
614
Sistemas de bases de datos Tabla 21.4.
Clasificaciones
Rango
Ruta de acceso
de la optimización
basada en reglas.
1
Una sola fila basándose en ROWID (identificador
2
Una sola fila basándose en combinación con clúster
3
Una sola fila basándose en clave hash de clúster con clave unívoca o principal
4
Una sola fila basándose en clave unívoca o principal
5
Combinación clúster
6
Clave hash con clúster
7
Clave indexada con clúster
8
Clave compuesta
9
Índices mono-columna
10
Búsqueda de rango limitado sobre columnas indexadas
11
Búsqueda de rango no limitado sobre columnas indexadas
12
Combinación mediante ordenación-mezcla
13
MAX o MIN de columnas indexadas
14
ORDER BY sobre columnas indexadas
15
Exploración completa de tabla
El optimizador
de fila)
basado en costes
Para mejorar la optimización de las consultas, Oracle introduce el optimizador basado en costes en la versión Oracle 7; dicho optimizador selecciona la estrategia de ejecución que requiera el mínimo uso de recursos necesario para procesar todas las filas a las que accede la consulta (evitando la anomalía de los empates que antes hemos mencionado). El usuario puede seleccionar si el uso mínimo de recursos debe definirse basándose en la tasa de procesamiento (minimización de la cantidad de recursos necesaria para procesar todas las filas a las que accede la consulta) o basándose en el tiempo de respuesta (minimizar la cantidad de recursos necesaria para procesar la primera fila a la que accede la consulta), configurando para ello el parámetro de inicialización OPTIMIZER _MODE. El optimizador basado en costes también toma en consideración las sugerencias que el usuario pueda proporcionar, como explicaremos a continuación.
Estadísticas El optimizador basado en costes depende para su funcionamiento de las estadísticas disponibles para todas las tablas, clústeres e índices a los que accede la consulta. Sin embargo, Oracle no recopila estadísticas automáticamente, sino que deja en manos del usuario la responsabilidad de generar dichas estadísticas y mantenerlas actualizadas. Puede utilizarse el paquete PL/SQL DBMS _ STATS para generar y gestionar las estadísticas de las tablas, columnas, índices, particiones y los demás objetos de esquema de la base de datos. Siempre que sea posible, Oracle utiliza un método de procesamiento paralelo para recopilar las estadísticas, aunque las estadísticas de índice se recopilan en serie. Por ejemplo, podemos recopilar estadísticas para el esquema 'Manager' utilizando la siguiente instrucción SQL: EXECUTE DBMS _ STATS.GATHER_SCHEMA _STATS('Manager', DBMS_STATS. AUTO_SAMPLE_SIZE); El último parámetro le dice a Oracle que debe determinar por sí mismo el mejor tamaño muestral para la obtención de unas buenas estadísticas. Hay una serie de opciones que pueden especificarse a la hora de recopilar estadísticas. Por ejemplo, podemos especificar si las estadísticas deben calcularse para la estructura de datos completa o sólo para una mues-
Capítulo 21 Procesamiento de consultas
615
tra de los datos. En este último caso, se puede también especificar si el muestreo debe estar basado en filas o en bloques: •
El muestreo basado en filas lee las filas ignorando su ubicación fisica en el disco. Como escenario de caso peor, el muestreo de filas podría seleccionar una única fila de cada bloque, requiriendo una exploración completa de la tabla o índice.
•
El muestreo de bloques lee una muestra aleatoria de bloques y genera las estadísticas utilizando todas las filas contenidas en esos bloques.
Generalmente, el muestreo utiliza menos recursos que si se calcula el valor exacto para la estructura completa. Por ejemplo, sí se analiza un 10% o menos de una tabla de tamaño muy grande podemos obtener los mismos porcentajes relativos de espacios no utilizados. También se puede hacer que Oracle recopile estadísticas al crear o reconstruir índices, especificando la opción COMPUTE STATlSTlCS en los comandos CREATE INDEX o ALTER INDEX. Las estadísticas se almacenan en el diccionario de datos de Oracle y pueden ser inspeccionadas mediante las vistas que se muestran en la Tabla 21.5. Cada vista puede estar precedida por tres prefijos: incluye todos los objetos de la base de datos a los que el usuario tiene acceso, incluyendo los objetos de otros esquemas a los que se haya concedido acceso al usuario.
•
ALL_
•
DBA_
•
USER_
incluye todos los objetos de la base de datos. incluye sólo los objetos del esquema del usuario.
Sugerencias Como hemos mencionado anteriormente, el optimizador basado en costes también toma en consideración las sugerencias que el usuario pueda proporcionar. Una sugerencia se especifica como un comentario formateado de manera especial dentro de una instrucción SQL. Hay una serie de sugerencias que pueden emplearse para forzar al optimizador a tomar diferentes decisiones, como por ejemplo forzarle a utilizar: Tabla 21.5.
Vistas del diccionario de datos de Oracle.
Vista
Descripción
ALLJABLES
Información sobre los objetos y tablas relacionales a los que el usuario tiene acceso.
TAB _ HISTOGRAMS
Estadísticas sobre el uso de histogramas.
TAB COLUMNS
Información sobre las columnas de las tablas/vistas.
TAB_COL_STATlSTlCS
Estadísticas utilizadas por el optimizador basado en costes.
TAB ]ARTITTONS
Información sobre las particiones de una tabla particionada.
CLUSTERS
Información sobre los clústeres.
INDEXES
Información sobre los índices.
IND_COLUMNS
Información sobre las columnas de cada índice.
CONS COLUMNS
Información sobre las columnas de cada restricción.
CONSTRAINTS
Información sobre las restricciones de las tablas.
LOBS
Información sobre las columnas con tipo de datos LOB (large object, objeto de gran tamaño).
SEQUENCES
Información sobre los objetos de secuencia.
SYNONYMS
Información sobre los sinónimos.
TRIGGERS
Información sobre los disparadores de las tablas.
VIEWS
Información sobre las vistas.
616
Sistemas de bases de datos
•
el optimizador basado en reglas;
•
una ruta de acceso concreta;
•
un orden de combinación concreto;
•
una operación de combinación concreta, como por ejemplo una combinación mediante ordenaciónmezcla.
Por ejemplo, podemos forzar la utilización de un índice concreto utilizando la siguiente sugerencia: SELECT /*+
INDEX(sexlndex)
*j fName,
IName, position
FROMStaff
WHERE
sex = 'M';
Si hay tantos empleados de sexo masculino como femenino, la consulta devolverá aproximadamente la mitad de las filas de la tabla Staff y es probable que una exploración de tabla completa sea más eficiente que una exploración de índice. Sin embargo, si supiéramos que hay un número significativamente mayor de mujeres que de hombres, la consulta devolvería un pequeño porcentaje de las filas de la tabla Staff y es probable que la exploración mediante índice fuera más eficiente. Si el optimizador basado en costes asume que hay una distribución equitativa de valores en la columna sex, es probable que seleccione una exploración completa de tabla. En este caso, la sugerencia le dice al optimizador que debe utilizar el índice disponible sobre la columna sexo
Planes de ejecución almacenados Hay muchas veces en las que se ha encontrado un plan óptimo y es innecesario o poco conveniente que el optimizador genere un nuevo plan de ejecución cada vez que se vuelva a ejecutar la instrucción SQL. En este caso, es posible crear un esbozo almacenado utilizando la instrucción CREATE OUTLINE, que almacenará los atributos utilizados por el optimizador para generar el plan de ejecución. A partir de ese momento, el optimizador empleará los atributos almacenados para crear el plan de ejecución en lugar de generar un nuevo plan cada vez.
21.6.2
Histogramas
En las secciones anteriores, hemos hecho la suposición de que los valores de datos dentro de las columnas de una tabla estaban uniformemente distribuidos. Un histograma de valores junto con sus frecuencias relativas proporciona al optimizador unas estimaciones de selectividad mejores en presencia de una distribución no uniforme. Por ejemplo, la Figura 21.15(a) ilustra una distribución uniforme estimada para la columna rooms de la tabla PropertyForRent mientras que la Figura 21.15(b) muestra la distribución no uniforme real. La primera distribución puede no almacenarse de forma bastante compacta mediante un valor inferior (1) y un valor superior (10) y un recuento total de todas las frecuencias (en este caso, 100). Para un predicado simple tal como rooms > 9, si nos basamos en una distribución uniforme podemos estimar fácilmente el número de tuplas del resultado, que será (1/10)*100 = 10 tuplas. Sin embargo, esta estimación es bastante imprecisa (como podemos ver en la Figura 21.15(b), sólo hay en realidad una tupla). Un histograma es una estructura de datos que puede utilizarse para mejorar dicha estimación. La Figura 21.16 muestra dos tipos de histograma: •
un histograma con anchuras equilibradas, que divide los datos en un número fijo de rangos de igual anchura (denominados ranuras) y cada uno de los cuales contiene un recuento del número de valores que caen dentro de dicha ranura);
•
un histograma de altura equilibrada, que sitúa aproximadamente el mismo número de valores en cada ranura de modo que los puntos terminales de cada una de ellas se determinan según el número de valores contenidos en la ranura.
Por ejemplo, suponga que tenemos cinco ranuras. La Figura 21.16(a) ilustra el histograma de anchuras equilibradas para la columna rooms. Todas las ranuras tienen igual anchura, comprendiendo dos valores
Capítulo 21 Procesamiento de consultas
6
10
10
10
10
10
10
10
10
10
10
2
3
4
5
6
7
8
9
10
14
20
20
20
8
4
4
3
2
3
4
5
6
7
8
9
10
(b)
(a)
Figura 21.15.
617
Histograma de valores de la columna rooms en la tabla PropertyForRent: (a) distribución uniforme; (b) distribución no uniforme.
(1-2,3-4, etc.), y dentro de cada ranura se asume que la distribución es uniforme. Esta información se puede almacenar de forma bastante compacta escribiendo el valor inferior y superior de cada ranura y el recuento del número de valores contenidos en la ranura. Si consideramos de nuevo el predicado rooms > 9, el histograma de anchuras equilibradas nos permitiría estimar el número de tuplas que satisfacen este predicado, calculándolo como un elemento de rango multiplicado por el número de elementos de rango, es decir 2*1 = 2, lo cual es mejor que la estimación basada en la distribución uniforme. El histograma de alturas equilibradas se ilustra en la Figura 21.16(b). En este caso, la altura de cada columna es 20 (100/5). De nuevo, los datos pueden almacenarse de forma bastante compacta escribiendo los valores inferior y superior de cada ranura, así como la altura de todas las ranuras. Si consideramos el predicado rooms > 9, podemos estimar mediante el histograma de alturas equilibradas el número de tuplas que satisfacen este predicado utilizando la fórmula: (1/5)*20 = 4, que en este caso no es tan buena como la estimación proporcionada por el histograma de anchuras equilibradas. Oracle utiliza histogramas de alturas equilibradas. Otra variante del histograma de alturas equilibradas utiliza una altura uniforme dentro de una ranura pero posiblemente alturas ligeramente distintas entre unas ranuras y otras. Puesto que los histogramas son objetos persistentes, existe un coste asociado al almacenamiento y mantenimiento de los mismos. Algunos sistemas, como SQL de Microsoft, crean y mantienen los histogramas
20
20
20
20
20
3
4
5
20
14 10
4
1
Count
2
3
4
5
6
7
8
9
LJLJLJLJLJ 20
40
28
(a)
Figura 21.16.
8
10 4
1
2
LJ
6
l
7
8
9
10 1
(b)
Histograma de valores de la columna rooms en la tabla PropertyForRent: (a) anchuras equilibradas; (b) alturas equilibradas.
618
Sistemas de bases de datos
automáticamente sin necesidad de que el usuario introduzca ningún dato. Por el contrario, en Orac1e es responsabilidad del usuario crear y mantener los histogramas para las columnas apropiadas, utilizando de nuevo el paquete PL/SQL DBMS_STATS. Las columnas apropiadas son, normalmente, aquellas columnas que se utilicen dentro de la cláusula WHERE de las instrucciones SQL y que tienen una distribución no uniforme, como la columna rooms en el ejemplo anterior.
21.6.3
Visualización del plan de ejecución
Oracle permite visualizar el plan de ejecución que el optimizador va a elegir utilizando el comando EXPLAIN PLAN. Este comando puede ser enormemente útil si la eficiencia de una consulta no es la esperada. La salida de EXPLAIN PLAN se escribe en una tabla de la base de datos (la tabla predeterminada es PLAN_ TABLE). Las columnas principales de esta tabla son: •
STATEMENT _ID, el valor de un parámetro opcional STATEMENT _ID especificado EXPLAIN PLAN.
en la instrucción
•
OPERATION, el nombre de la operación interna realizada. La primera fila sería la propia instrucción SQL: SELECT, INSERT, UPDATE o DELE TE.
•
OPTIONS,
•
OBJECT_NAME,
•
ID, un número asignado a cada paso del plan de ejecución.
el nombre de otra operación interna realizada. el nombre de la tabla del índice.
el identificador del siguiente paso que opera sobre la salida del paso
•
PARENT_ID,
•
POSITION,
•
COST,
•
CARDINALlTY,
ID.
el orden de procesamiento para aquellos pasos que tienen el mismo valor de
PARENT _ID.
una estimación de coste para la operación (null para las instrucciones que utilicen el optimizador basado en reglas). una estimación del número de filas a las que accede la operación.
En la Figura 21.17 se muestra un plan de ejemplo. Cada línea de este plan representa un único paso en el plan de ejecución. Se ha utilizado el sangrado de las líneas para mostrar el orden de las operaciones (observe que el valor ID de columna es insuficiente por sí mismo para mostrar la ordenación). SQL> 2 3 4 5 6
EXPLAIN PLAN SET STATEMENT_IO = 'PB' FOR SELECT b.branchNo, b.city, propertyNo FROM Branch b, PropertyForRent p WHERE b.branchNo = p.branchNo OROER BY b.city;
Explained. SQL> 2 3 4 5
SELECT 1011''IIPARENT_IOII' 'IILPAO(' ',2*(LEVEL - 1)1I10PERATIONII' '1I0PTIONSII ' 'IIOBJECT_NAME "Query Plan" FROM Plan_ Table START WITH ID = O ANO STATEMENT_IO = 'PB' CONNECT BY PRIOR ID = PARENT_IO ANO STATEMENT_ID = 'PB';
Query Plan O 1 2 3 4 5
O 1 2 2 4
SELECT STATEMENT SORT OROER BY NESTEO LOOPS TABLE ACCESS FULL PROPERTYFORRENT TABLE ACCESS BY INOEX ROWIO BRANCH INOEX UNIQUE SCAN SYS_C007455
6
rows selected.
Figura 21.7.
Salida de la utilidad Explain Plan.
Capítulo 21 Procesamiento de consultas
619
Resumen del capítulo •
Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel, como, por ejemplo, el álgebra relacional, y ejecutar dicha estrategia para extraer los datos solicitados.
•
Puesto que hay muchas transformaciones equivalentes para una misma consulta de alto nivel, el SGBD tiene que elegir aquella que minimice el uso de recursos. Este es el objetivo de la optimización de consultas. Puesto que el problema es intratable desde el punto de vista computacional cuando hay un gran número de relaciones, la estrategia adoptada se reduce generalmente a determinar una solución cercada a la óptima.
•
Hay dos técnicas principales de optimización de consultas, aunque las dos estrategias se suelen combinar en la práctica. La primera técnica utiliza reglas heurísticas que ordenan las operaciones de la consulta. La otra técnica compara las diferentes estrategias basándose en sus costes relativos y selecciona aquella que minimiza el uso de recursos.
•
El procesamiento de consultas puede dividirse en cuatro fases principales: descomposición (compuesta de análisis sintáctico y validación), optimización, generación de código y ejecución. Las primeras tres fases pueden realizarse en tiempo de compilación y en tiempo de ejecución.
•
La descomposición de consultas transforma una consulta de alto nivel en una consulta de álgebra cional y comprueba que dicha consulta sea sintáctica y semánticamente correcta. Las etapas típicas descomposición de consultas son el análisis, la normalización, el análisis semántico, la simplificación reestructuración de la consulta. Puede utilizarse un árbol de álgebra relacional para proporcionar representación interna de la consulta transformada.
•
La optimización de consultas puede aplicar reglas de transformación para convertir una expresión de álgebra relacional en una expresión equivalente que se sepa que es más eficiente. Entre las reglas de transformación se incluyen la conexión en cascada de operaciones de selección, la conmutatividad de las operaciones unarias, la conmutatividad de la combinación Theta (y del producto cartesiano), la conmutatividad de las operaciones unarias y de la combinación Theta (y del producto cartesiano) y la asociatividad de la combinación Theta (y del producto cartesiano).
•
Entre las reglas heurísticas se incluyen la realización de las operaciones de selección y proyección lo antes posible; la combinación de un producto cartesiano con una selección subsiguiente cuyo predicado represente una condición de combinación en una operación de combinación; la utilización de la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que aquellos que tengan \las selecciones más restrictivas se ejecuten primero, etc.
•
La estimación de coste depende de la información estadística recopilada del catálogo del sistema. Entre las estadísticas típicas se incluye la cardinalidad de cada relación base, el número de bloques requeridos para almacenar una relación, el número de valores distintos para cada atributo, la cardinalidad de selección de cada atributo y el número de niveles en cada índice multinivel.
•
Las principales estrategias para implementar la operación de selección son: búsqueda lineal (archivo no ordenado y no indexado), búsqueda binaria (archivo ordenado y no indexado), igualdad de clave hash, condición de igualdad de clave principal, condición de desigualdad de clave principal, condición de igualdad de índice (secundario) de clústering, condición de igualdad de índice (secundario) no de clústering y condición de desigualdad en un índice secundario de tipo B+-tree.
•
Las principales estrategias para implementar la operación de combinación son: combinación mediante bucle anidado por bloques, combinación mediante bucle anidado indexado, combinación mediante ordenación-mezcla y combinación hash.
•
Con la técnica de materialización la salida de una operación se almacena en una relación temporal para su procesamiento por parte de la siguiente operación. Otra técnica alternativa consiste en procesar en cadena los resultados de una operación, pasándolos a la operación siguiente sin crear una relación tempo-
relade la y la una
620
Sistemas de bases de datos
ral donde se almacenen los resultados intermedios; esta técnica de pipelining nos permite ahorramos el coste de crear relaciones temporales y de volver a leer los resultados. •
A un árbol de álgebra relacional donde la relación del árbol derecho sea siempre una relación base se le denomina árbol de profundidad izquierda. Los árboles de profundidad izquierda tienen las ventajas de reducir el espacio de búsqueda de la estrategia óptima y de permitir que el optimizador de consulta se base en técnicas de procesamiento dinámico. Su principal desventaja es que, al reducir el espacio de búsqueda, no se toman en cuenta muchas estrategias de ejecución alternativas, algunas de las cuales podrían tener un coste menor que la determinada mediante un árbol lineal.
•
Un aspecto fundamental para la eficiencia de la optimización de consultas es el espacio de búsqueda de las posibles estrategias de ejecución y el algoritmo de enumeración utilizado para buscar en este espacio una estrategia óptima. Para una consulta determinada, este espacio de búsqueda puede ser muy grande; como resultado, los optimizadores de consultas restringen dicho espacio mediante una serie de técnicas. Por ejemplo, las operaciones unarias pueden procesarse sobre la marcha; los productos cartesianos nunca se forman a menos que la propia consulta lo especifique; el operando interno de cada combinación es una relación base, etc.
•
El algoritmo de programación dinámica se basa en la suposición de que el modelo de coste satisface el principio de optimalidad. Para obtener la estrategia óptima para una consulta compuesta por n combinaciones, sólo necesitamos considerar las estrategias óptimas para (n - 1) combinaciones y ampliar dichas estrategias con una combinación adicional. Se crean clases de equivalencias basadas en las ordenaciones interesantes y se retiene la estrategia de menor coste dentro de cada clase de equivalencia para ponerla en consideración en el siguiente paso, hasta construir toda la consulta, momento en que se selecciona la estrategia que tenga el menor coste global.
Cuestiones de repaso 21.1.
¿Cuáles son los objetivos del procesamiento de consultas?
21.2.
¿En qué sentido difiere el procesamiento de consultas en los sistemas relacionales del procesamiento de lenguajes de consultas de bajo nivel para sistemas de red y jerárquicos?
21.3.
¿Cuáles son las fases típicas del procesamiento de consultas?
21.4.
¿Cuáles son las etapas típicas de la descomposición
21.5.
¿Cuál es la diferencia entre las formas normales conjuntiva y disyuntiva?
de consultas?
21.6.
¿Como comprobaría la corrección semántica de una consulta?
21.7.
Indique las reglas de transformación que pueden aplicarse a: (a)
Operaciones de selección
(b)
Operaciones de proyección
(c)
Operaciones de combinación Theta.
21.8.
Indique las reglas heurísticas que deberían aplicarse para mejorar el procesamiento de una consulta.
21.9.
¿Qué tipos de estadísticas debe almacenar un SGBD para poder calcular estimaciones del coste de las operaciones de álgebra relacional?
21.10. ¿En qué circunstancias tendrá que utilizar el sistema una búsqueda lineal a la hora de implementar una operación de selección? 21.11. ¿Cuáles son las estrategias principales para implementar la operación de combinación? 21.12. ¿Cuáles son las diferencias entre materialización y pipelining? 21.13. Explique la diferencia entre árboles de álgebra relacionallineales para ilustrar su respuesta.
y no lineales. Proporcione ejemplos
21.14. ¿Cuáles son las ventajas y desventajas de los árboles de profundidad izquierda?
Capítulo 21 Procesamiento de consultas 21.15. Describa cómo funciona el algoritmo de programación System R.
dinámica del optimizador
621
de consultas de
Ejercicios 21.16. Calcule el coste de las tres estrategias citadas en el Ejemplo 21.1 si la relación 8taff tiene 10000 tuplas, si Branch tiene 500 tuplas, si hay 500 empleados con categoría de Manager (uno por cada sucursal) y si hay 10 sucursales en Londres. 21.17. Utilizando el esquema Hotel dado al principio de los ejercicios del Capítulo 3, determine si las siguientes consultas son semánticamente correctas: (a)
(b)
SELECT rtype, FROM Room r, WHERE
r.hotel_number
SELECT
g.guestNo,
FROM
= h.hotel_number
AND
h.hotel_name
=
'Grosvenor Hotel' AND
r.type
> 100;
g.name
Hotel h, Booking b, Guest 9
WHERE (c)
r.price Hotel h
AND
h.hotelNo = b.hotelNo
SELECT r.roomNo, h.hotelNo FROM Hotel h, Booking b, Room WHERE
h.hotelNo
= b.hotelNo
AND
bhotelNo
h.hotelName
=
'Grosvenor Hotel';
r
AND h.hotelNo 'H22';
=
'H21' AND
b.roomNo
= r.roomNo
AND
type =
'S'
=
21.18. Utilizando de nuevo el esquema Hotel, dibuje un árbol de álgebra relacional para cada una de las siguientes consultas y utilice las reglas heurísticas dadas en la Sección 21.3.2 para transformar las consultas en una forma más eficiente. Explique cada paso y enuncie las reglas de transformación usadas en el proceso. (a)
SELECT
r.roomNo, r.type, r.price
FROM Room r, Booking b, Hotel h WHERE rroomNo = b.roomNo AND h.hotelName
(b)
SELECT FROM
g.guestNo,
=
b.hotelNo
= h.hotelNo
'Grosvenor Hotel' AND
AND
r.price
> 100;
g.guestName
Room r, Hotel h, Booking b, Guest 9
WHERE
h.hotelNo
h.hotelName
AND
dateTo
AND g.guestNo = b.guestNo AND h.hotelNo 'Grosvenor Hotel' AND dateFrom >= '1-Jan-04' <= '31-Dec-04'; = b.hotelNo
= r.hotelNo
AND
=
21.19 Utilizando el esquema Hotel, suponga que existen los siguientes índices: •
un índice hash sin desbordamiento
•
un índice de clústering sobre el atributo de clave externa
sobre los atributos de clave principal,
•
un índice B+-tree sobre el atributo
•
un índice secundario sobre el atributo nTuples(Room) nTuples(Hotel) nTuples(Booking) nDistincthotelNo(Room) nDi sti nct,ype(Room) nDistinctpriceCRoom)
price
= 10.000 = 50 = 100.000 = 50
=
10
= 500
en
type
hotelNo
en
Room;
Room;
en
Room.
bFactor(Room) bFactor(Hotel) bFactor(Booking)
= 200 = 40 = 60
room No/hotel No
en
Room;
622
Sistemas de bases de datos
minprice(Room) nLevelshotelNo(I)
= 200
nLevelspriee(I)
=2
maxprice(Room)
= 50
nLfB lockspriee(I)
= 50
=2
(a) Calcule la cardinalidad y el coste mínimo para cada una de las siguientes operaciones de selección: SI: S2: S3: S4: S5: S6:
(b) Calcule la cardinalidad y el coste mínimo para cada uno de las siguientes operaciones de combinación: Jl: J2: 13: J4: J5: J6:
Hotell>
hotelNoRoom
I>
Room
I>
Room
I>
Booking
I>
Booking
I>
(c) Calcule la cardinalidad y el coste mínimo para cada una de las siguientes operaciones de proyección: P 1:
IIhole'No(Hotel)
P2: P3: P4: P5:
IIhole'No(Room) IIprlee(Room) Uype(Room) IIhote,No,prlee(Room)
21.20, Modifique los algoritmo s de combinación mediante el bucle anidado por bloques y el bucle anidado indexado presentados en la Sección 21.4.3 para leer (nBuffer - 2) bloques de la relación externa R cada vez, en lugar de leer un sólo bloque en cada ocasión.
Parte
Bases de datos distribuidas y replicación
Capítulo 22 Bases de datos distribuidas: conceptos y diseño Capítulo 23 Bases de datos disinbuidas: conceptos avanzados Capítulo 24 Replicación y bases de datos móviles
Bases de datos distribuidas: conceptos y diseño
Objetivos del capítulo: En este capítulo aprenderá: •
La necesidad de las bases de datos distribuidas.
•
Las diferencias entre sistemas de bases de datos distribuidas, procesamiento distribuido y sistemas de bases de datos paralelas.
•
Las ventajas y desventajas de las bases de datos distribuidas.
•
Los problemas de heterogeneidad en un SGBD distribuido.
•
Conceptos básicos de interconexión por red.
•
Las funciones que debe proporcionar un SGBD distribuido.
•
Una arquitectura para los SGBD distribuidos.
•
Los problemas principales asociados con el diseño de bases de datos distribuidas, y en especial los problemas de fragmentación, replicación y asignación.
•
Cómo debe llevarse a cabo la fragmentación.
•
La importancia de la asignación y la replicación en las bases de datos distribuidas.
• •
Los niveles de transparencia que un SGBD distribuido debe proporcionar. Criterios de comparación para los SGBD distribuidos.
La tecnología de bases de datos ha evolucionado desde un paradigma de procesamiento de datos en el que cada aplicación definía y mantenía sus propios datos, hasta otro en el que los datos se definían y administraban de manera centralizada. En los últimos años, hemos visto una serie de rápidos desarrollos en la tecnología de redes y de comunicación de datos, cuyas mejores representaciones son Internet, la comunicación móvil e inalámbrica, los dispositivos inteligentes y la computación reticular. Ahora, con la combinación de estas dos tecnologías, la tecnología de bases de datos distribuidas permite cambiar el modo de trabajo, pasando de un modo centralizado a otro descentralizado. Este tipo de tecnología combinada es uno de los avances principales en el área de los sistemas de base de datos. En los capítulos anteriores nos hemos centrado en los sistemas de bases de datos centralizados, sistemas con una única base de datos lógica ubicada en un determinado lugar bajo control de un único SGBD. En este capítulo, hablaremos de los conceptos y cuestiones asociados con los sistemas de gestión de bases de datos distribuidas (SGBDD) que permiten a los usuarios acceder no sólo a los datos situados en su misma ubicación, sino también a aquellos otros que están almacenados en ubicaciones remotas. Algunos autores sostienen que los SGBD centralizados llegarán a quedar completamente obsoletos a medida que las organizaciones migren hacia sistemas de gestión de base de datos distribuidas.
626
Sistemas de bases de datos
Estructura del capítulo En la Sección 22.1 se presentan los conceptos básicos de los SGBDD y se explican las diferencias entre un SGBDD, el procesamiento distribuido y los SGBD paralelos. En la Sección 22.2 se proporciona una breve introducción a los conceptos de interconexión de red para que resulten más claras algunas de las explicaciones posteriores. En la Sección 22.3 se examina la funcionalidad ampliada que cabe esperar que un SGBDD proporcione. También se analizan posibles arquitecturas de referencia para un SGBDD como extensiones de la arquitectura ANSI-SPARC presentada en el Capítulo 2. En la Sección 22A se explica cómo ampliar la metodología de diseño de bases de datos presentada en la Parte 4 de este libro para tener en cuenta las cuestiones de la distribución de datos. En la Sección 22.5 se explican los mecanismos de transparencia que cabe esperar encontrar en un SGBDD y en la Sección 22.6 concluimos con un breve repaso de las doce reglas de Date para un SGBDD. De nuevo, los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome descrito en la Sección lOA y en el Apéndice A. En el siguiente capítulo examinaremos cómo pueden extenderse los protocolos de control de concurrencia, de gestión de interbloqueos y de control de recuperación explicados en el Capítulo 20 para tener en cuenta las características de un entorno distribuido. En el Capítulo 24 hablaremos de los servidores de replicación, que constituyen una técnica alternativa, y potencialmente más simpl~la implementación de mecanismos de distribución de datos. También hablaremos de las bases de datos móviles y veremos cómo soporta Oracle la movilidad y la replicación de datos.
22.1 Introducción Una de las principales motivaciones para el desarrollo de sistemas de bases de datos es el deseo de integrar los datos operacionales de una organización y proporcionar un acceso controlado a esos datos. Aunque la integración y el acceso controlado pueden implicar la necesidad de utilizar mecanismos de centralización, el objetivo en realidad no es ese. De hecho, el desarrollo de redes informáticas promueve el modo descentralizado de trabajo. Esta técnica descentralizada imita la estructura organizativa de muchas empresas, que están distribuidas de modo lógico en divisiones, departamentos, proyectos, etc., y están distribuidas de modo fisico en oficinas, fábricas e instalaciones, manteniendo cada unidad sus propios datos operacionales. (Date, 2000). La posibilidad de compartir los datos y la eficiencia del acceso a los mismos puede mejorarse mediante el desarrollo de sistemas de bases de datos distribuidas que reflejen esta estructura organizativa, que hagan que los datos de todas las unidades sean accesibles y que almacenen esos datos en algún lugar próximo a aquel donde más frecuentemente se los utilice. Los SGBD distribuidos deberían ayudamos a resolver el problema de las isras de información. Las bases de datos se consideran en ocasiones, islas electrónicas que constituyen lugares diferenciados y generalmente inaccesibles, igual que las islas remotas. Esto puede ser resultado de la separación geográfica, de la incompatibilidad de las arquitecturas informáticas, de la incompatibilidad de los protocolos de comunicaciones, etc. Si se consigue integrar las bases de datos en un todo lógico coherente, podemos resolver el problema.
22.1.1
Conceptos
Para comenzar nuestro análisis de los SGBD distribuidos, veamos primero algunas definiciones. Base de datos Una colección lógicamente interrelacionada de datos compartidos Ounto con una distribuida descripción
de estos datos) físicamente
distribuidos
por una red informática.
SGBD distribuido
El sistema software que permite gestionar la base de datos distribuida y hace que dicha distribución sea transparente para los usuarios.
Un sistema de gestión de bases de datos distribuidas (SGBDD) está compuesto por una única base de datos lógica dividida en una serie de fragmentos. Cada fragmento se almacena en una o más computadoras
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
627
bajo el control de un SGBD independiente, estando dichas computadoras conectadas mediante una red de comunicaciones. Cada una de las instalaciones es capaz de procesar de forma independiente las solicitudes de los usuarios que requieran acceso a los datos locales (es decir, cada instalación tiene un cierto grado de autonomía local) y también es capaz de procesar los datos almacenados en otras computadoras de la red. Los usuarios acceden a la base de datos distribuida a través de una serie de aplicaciones, que podemos clasificar en dos grupos: aquellas que no requieren datos de otras instalaciones (aplicaciones locales) y aquellas que sí requieren datos de esas otras instalaciones (aplicaciones globales). Para que un SGBDD pueda ser considerado como tal, deberá disponer al menos de una aplicación global. Un SGBDD tiene, por tanto, las siguientes características: • una colección de datos compartidos lógicamente relacionados; •
los datos están divididos en una serie de fragmentos;
•
los fragmentos pueden ser replicados;
• •
los fragmentos/réplicas se asignan a distintas instal~iones; las distintas instalaciones están enlazadas mediante una red de comunicaciones;
•
los datos de cada instalación están bajo control de un SGBD;
•
el SGBD de cada instalación puede gestionar las aplicaciones locales de manera autónoma;
•
cada SGBD participa en al menos una aplicación global.
.
No es necesario que todas las instalaciones del sistema tengan su propia base de datos local, como se ilustra mediante la topología de SGBDD mostrada en la Figura 22.1 Instalación 1
BO Instalación 4
Instalación 2
BO
BO Instalación 3
Figura 22.1.
1
Sistema de gestión de bases de datos distribuidas.
Ejemplo 22.1 DreamHome Utilizando tecnología de distribución de base de datos, DreamHome puede implementar su sistema de base de datos en una serie de sistemas informáticos independientes, en lugar de utilizar un único mainframe centralizado. Los sistemas informáticos pueden estar ubicados en cada sucursal local: por ejemplo Londres, Aberdeen y Glasgow. Una red que enlace las distintas computadoras permitirá que las sucursales se comuniquen entre sí y un SGBDD les permitirá acceder a los datos almacenados en las
628
Sistemas de bases de datos
restantes sucursales. Así, un cliente que viva en Glasgow puede acudir a averiguar qué inmuebles hay disponibles en Londres, en lugar de tener sucursal de Londres para conseguir los detalles oportunos. Alternativamente, si cada sucursal de DreamHome tiene ya su propia puede utilizarse un SGBDD para integrar las distintas bases de datos en
la sucursal más próxima para que telefonear o escribir a la base de datos (heterogénea), una única base de datos lógi-
ca, haciendo de nuevo que los datos locales estén disponibles de manera mucho más amplia.
~
A partir de la definición de un SGBDD, podemos esperar que el sistema haga que la distribución de los datos sea transparente (invisible) a ojos del usuario. Así, el hecho de que una base de datos distribuida esté dividida en una serie de fragmentos que puedan estar almacenados en diferentes computadoras y quizás replicados debería ocultarse al usuario. El objetivo de la transparencia consiste en hacer que el sistema distribuido parezca un sistema centralizado. Algunas veces se denomina este concepto como el principio fundamental de los SGBD distribuidos (Date, 1987b). Este requisito proporciona una funcionalidad muy potente al
como explica la Sección 22.5. usuariosefinal pero,en desafortunadamente,
Procesamiento
~ crea muchos problemas ~dici.onales que deberá resolver el SGBDD,
distribuido
Es muy importante entender la diferencia entre un SGBD distribuido y el procesamiento Procesamiento distribuido
distribuido.
Una base de datos centralizada a la que se puede acceder a través de una red informática.
El punto clave en la definición de un SGBD distribuido es que el sistema está compuesto por datos que están físicamente distribuidos entre una serie de nadas de la red. Si los datos están centralizados, aunque otros usuarios estén accediendo a los datos a través de la red, no consideraremos que se trate de un SGBD distribuido, sino simplemente de un sistema de procesamiento distribuido. En la Figura 22.2 se ilustra la topología del procesamiento distribuido; compare esta figura, que tiene una base de datos central en el nodo 2, con la Figura 22.1, que muestra varios nadas o instalaciones, cada uno de ellos con su propia base de datos (BD). Instalación 1
Instalación 4
Instalación 2
BD
Instalación 3
Figura 22.2.
Procesamiento
distribuido.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
629
Bases de datos paralelas También conviene entender la diferencia entre un SGBD distribuido y un SGBD paralelo. SGBD paralelo
Un SGBD que se ejecuta sobre múltiples procesado res y utilizando múltiples discos y que está diseñado para ejecutar las operaciones en paralelo, siempre que sea posible, con el fin de mejorar las prestaciones.
Los SGBD paralelos se basan, de nuevo, en la premisa de que los sistemas monoprocesador no pueden satisfacer los requisitos crecientes de escalabilidad, fiabilidad y prestaciones a precios razonables. Una alternativa potente y atractiva desde el punto de vista económico a los SGBD monoprocesador son los SGBD paralelos que utilizan múltiples procesadores. Los SGBD paralelos enlazan múltiples máquinas de menor tamaño para conseguir la misma capacidad de procesamiento que una única máquina de tamaño mayor, a menudo con una mayor escalabilidad y fiabilidad que los SGBD mofprocesador. Para proporcionar a los múltiples procesadores un aCfeso común a una única base de datos, el SGBD paralelo debe encargarse de la gestión de los recursos compartidos. Qué recursos estén compartidos y cómo se
(a)
(b)
Red de interconexión
(e)
Figura 22.3.
Arquitecturas de bases de datos paralelas: (a) memoria compartida; (b) disco compartido; (c) sin compartición.
630 Sistemas de bases de datos implementen esos recursos compartidos afectará directamente a las prestaciones y a la escalabilidad del sistema, lo que a su vez determinará si resulta apropiado para una determinada aplicación o entorno. Las tres principales arquitecturas de SGBD paralelo, ilustradas en la Figura 22.3, son: •
memoria compartida;
•
disco compartido;
•
sin compartición.
La arquitectura de memoria compartida es una arquitectura fuertemente acoplada en la que una serie de procesadores situados en un mismo sistema comparten la memoria del sistema. Conocida con el nombre de multiprocesamiento simétrico (SMP, symmetric multiprocessing), esta técnica se ha hecho muy popular en diversos tipos de plataformas, desde estaciones de trabajo personales que poseen unos pocos microprocesadores funcionando en paralelo, hasta máquinas RISC (Reduced Instructio~t Computer) de gran tamaño e incluso mainframes. Esta arquitectura proporciona un acceso de datos de alta velocidad para un número limitado de procesadores, pero no puede escalarse esta arquitectura más allá de 64 procesadores, ya que la red de interconexión pasa entonces a convertirse en un cuello de botella. La arquitectura de disco compartido es una arquitectura débilmente acoplada que está optimizada para aplicaciones inherentemente centralizadas y que requiere una alta disponibilidad y unas altas prestaciones. Cada procesador puede acceder directamente a todos los discos, pero cada uno de ellos tiene su propia memoria privada. Al igual que la arquitectura sin compartición, la arquitectura de disco compartido elimina el cuello de botella representado por la memoria compartida. Sin embargo, a diferencia de la arquitectura sin compartición, la arquitectura de disco compartido elimina este cuello de botella sin el engorro de introducir un particionamiento físico de los datos. Los sistemas de disco compartido se denominan en ocasiones clús-
teres. La arquitectura sin compartición, a menudo denominada procesamiento masivamente paralelo (MPP, massively parallel processing), es una arquitectura multiprocesador en la que cada procesador es parte de un sistema completo, con su propia memoria y su propio almacenamiento en disco. La base de datos se particiona entre todos los discos de cada uno de los sistemas asociados con la base de datos, y los datos están disponibles de forma transparente para los usuarios de todos los sistemas. Esta arquitectura es más escalable que la de memoria compartida y permite soportar más fácilmente un mayor número de procesadores. Sin embargo, las prestaciones sólo son óptimas si los datos solicitados están almacenados localmente. Aunque la definición de arquitectura sin compartición incluye en ocasiones a los SGBD distribuidos, la distribución de los datos en un SGBD paralelo está basada únicamente en consideraciones de rendimiento. Además, los nodos de un SGBDD están normalmente distribuidos de manera geográfica, se administran por separado y tienen una red de interconexión más lenta, mientras que los nadas de un SGBD paralelo se encuentran normalmente dentro de una misma computadora o dentro de un mismo nodo. La tecnología paralela se utiliza normalmente para bases de datos de muy gran tamaño, por ejemplo del orden de los terabytes (l 012 bytes) o para sistemas que tengan que procesar miles de transacciones por segundo. Estos sistemas necesitan acceder a grandes volúmenes de datos y deben proporcionar una respuesta rápida a las consultas que se realicen. Un SGBD paralelo puede utilizar la arquitectura subyacente para mejorar la velocidad de ejecución de las consultas complejas, utilizando técnicas paralelas de exploración, de combinación y de ordenación que permiten que los múltiples nodos procesadores compartan de forma automática la carga de trabajo. Hablaremos más en detalle de esta arquitectura en el Capítulo 31, cuando tratemos el tema de los almacenes de datos. Baste decir aquí que todos los principales fabricantes de sistemas de gestión de bases de datos tienen versiones paralelas de sus motores de bases de datos.
22.1.2
Ventajas y desventajas de los SGBDD
La distribución de datos y de aplicaciones presenta ventajas potenciales con respecto a los sistemas centralizados tradicionales de bases de datos. Desafortunadamente, también hay algunas desventajas. En esta sección vamos a analizar tanto las unas como las otras.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
631
Ventajas Refleja la estructura organizativa Muchas organizaciones están distribuidas de forma natural en diversas ubicaciones. Por ejemplo, DreamHome tiene muchas oficinas en diversas ciudades. Resulta natural que las bases de datos utilizadas en dicho tipo de aplicaciones estén distribuidas entre esas diferentes ubicaciones. DreamHome puede mantener una base de datos en cada sucursal donde se contengan los detalles relativos a cosas tales como el personal que trabaja en bles. dicha El oficina, personal los que inmueble trabajes que en una tiene sucurs~uede en ~l~uiler y realizar los clientes consultas que poseen locales o aquieren la base alquilar de datos.dichos Por suinmueparte, el personal de las oficinas centrales puede necesitar realizar consultas globales que requieran acceder a los datos de todas las sucursales o de un número significativo de ellas.
Mejora la compartición de los datos y la autonomía local La distribución geográfica de una organización puede reflejarse en la distribución de los datos; los usuarios de uno de los nadas pueden acceder a los datos almacenados en los otros nadas. Los datos pueden colocarse en el nodo más próximo a los usuarios que normalmente los usan. De esta forma, los usuarios tienen un controllocal de los datos y pueden, en consecuencia establecer e imponer políticas locales relativas al uso de estos datos. Un administrador global de la base de datos será responsable del sistema completo. Generalmente, parte de esta responsabilidad se delega en el nivel local, de modo que el DBA local puede gestionar el SGBD local (véase la Sección 9.15).
Mayor disponibilidad En un SGBD centralizado, un fallo de la computadora hace que se detengan las operaciones del SGBD. Sin embargo, un fallo en uno de los nodos de un SGBDD, o un fallo de un enlace de comunicaciones que haga que algunos nadas sean inaccesibles, no hace que todo el sistema deje de operar. Los SGBD distribuidos están diseñados para continuar funcionando a pesar de tales fallos. Si se produce un fallo en un único nodo, puede que el sistema sea capaz de reencaminar las solicitudes dirigidas al nodo fallido hacia otro nodo.
Mayor fiabilidad Ya que los datos pueden replicarse, de modo que estén almacenados en más de un nodo, el fallo de un nodo o de un enlace de comunicaciones no hace necesariamente que los datos dejen de estar accesibles.
Mayores prestaciones Ya que los datos están localizados cerca del nodo de 'mayor demanda', y dado el inherente paralelismo de un SGBD distribuido, la velocidad del acceso a la base de datos puede ser superior que la que podría alcanzarse utilizando una base de datos centralizada remota. Además, dado que cada nodo gestiona únicamente una parte de la base de datos completa, puede que no haya el mismo grado de contienda por el procesador y por los servicios de E/S que el que se experimenta en un SGBD centralizado.
Economía En la década de ] 960, la potencia de procesamiento se calculaba según el cuadrado del coste de los equipos: multiplicando el coste por tres, se incrementaba por nueve la potencia de procesamiento. Esto se conocía con el nombre de Ley de Grosch. Sin embargo, hoy en día se acepta con carácter general que resulta mucho más barato crear un sistema de pequeñas computadoras con la potencia equivalente de una única computadora de gran tamaño. Esto hace que sea más eficiente en términos económicos que las divisiones y departamentos corporativos adquieran computadoras independientes. También es mucho más barato añadir estaciones de trabajo a una red que actualizar un sistema mainframe. La segunda área potencial de ahorro de costes está relacionada con aquellas situaciones en las que las bases de datos son geográficamente remotas y las aplicaciones necesitan acceder a datos distribuidos. En tales casos, debido al alto coste de transmisión de los datos a través de la red (si lo comparamos con el coste del acceso
632
Sistemas de bases de datos
local), puede ser mucho más económico particionar la aplicación y realizar el procesamiento cada nodo.
localmente en
Crecimiento modular En un entorno distribuido, resulta mucho más sencillo expandir el sistema. Pueden añadirse nuevos nodos a la red sin afectar a las operaciones de otros nodos. Esta flexibilidad permite a una organización expandirse de forma relativamente simple. Para incrementar el tamaño de la base de datos, basta con añadir potencia de procesamiento y espacio de almacenamiento a la red. En un SGBD centralizado, el crecimiento puede necesitar de hardware (la compra de un sis~ema más potente) y en el software (la adquisición de un SGBD máscambios potente en o el más configurable). ~
Integración Al principio de esta sección hemos indicado ya que la integración, no la centralización, es una ventaja clave de los SGBD. La integración de los sistemas herederos constituye un ejemplo concreto que demuestra cómo algunas organizaciones están forzadas a utilizar un procesamiento de datos distribuido para que sus sistemas heredados coexistan con los otros sistemas más modernos. Al mismo tiempo, ningún paquete software puede proporcionar toda la funcionalidad que una organización requiere hoy en día. Por tanto, es importante que las organizaciones puedan integrar componentes software de diferentes fabricantes para satisfacer sus requisitos específicos.
Capacidad de competir Diversos desarrollos relativamente recientes dependen en buena medida de la tecnología de bases de datos distribuidas. Este es el caso, del e-Business, de la gestión de flujos de trabajo y de los sistemas de trabajo en colaboración basados en computadora. Muchas empresas han tenido que reorganizar sus operaciones y utilizar tecnología de bases de datos distribuidas para seguir siendo competitivas. Por ejemplo, aunque no es probable que haya más personas que alquilen inmuebles simplemente debido a la existencia de Internet, DreamHome puede perder parte de su cuota de mercado si no permite a los clientes ver los inmuebles en línea.
Desventajas Complejidad Un SGBD distribuido que oculte la naturaleza distribuida de los datos a ojos del usuario y que proporcione un nivel aceptable de rendimiento, fiabilidad y disponibilidad es inherentemente más complejo que un SGBD centralizado. El hecho de que los datos puedan replicarse añade también un nivel adicional de complejidad al SGBD distribuido. Si el software no gestiona adecuadamente la replicación de los datos, habrá una degradación en la disponibilidad, la fiabilidad y las prestaciones por comparación con un sistema centralizado, y las ventajas que antes hemos citado se transformarán en desventajas.
Coste La mayor complejidad implica que cabe esperar que los costes de adquisición y de mantenimiento de un SGBDD sean mayores que para un SGBD centralizado. Además, un SGBD distribuido requiere un hardware adicional para implantar la red de comunicaciones entre los distintos nodos. Con el uso de esta red, además, existen una serie de costes de comunicación continuados. Por último, tenemos que tener en cuenta los costes adicionales de personal requeridos para gestionar y mantener los SGBD locales y la red subyacente.
Seguridad En un sistema centralizado, el acceso a los datos puede controlarse fácilmente. Por el contrario, en un SGBD distribuido no sólo es necesario controlar el acceso a los datos replicados en múltiples ubicaciones, sino que también es necesario dotar de seguridad a la propia red. En el pasado, las redes se consideraban un medio de comunicación inseguro. Aunque esto continua siendo parcialmente cierto, diversos desarrollos de gran importancia han incrementado considerablemente el nivel de seguridad de las redes.
Capítulo 22 Control de integridad
Bases de datos distribuidas: conceptos y diseño
633
más complicado
La integridad de la base de datos es un término que hace referencia a la validez y coherencia de los datos almacenados. La integridad se expresa normalmente en términos de restricciones, que son reglas de coherencia que no se permite que la base de datos viole. Imponer las restricciones de integridad requiere, generalmente, acceder a una gran cantidad de datos que definen la restricción pero que no están implicados en la propia operación de actualización. En un SGBD distribuido, los costes de comunicaciones y de procesamiento requeridos para imponer las restricciones de integridad pueden ser prohibitivos. Volveremos sobre este problema en la Sección 23.4.5. Carencia
de estándares
Aunque los SGBD distribuidos dependen de que existan unas comunicaciones efectivas, sólo ahora estamos comenzando a ser testigos de la aparición de protocolos de comunicaciones y de acceso a datos estándar. Esta falta de estándares ha inundado considerablemente el potencial de los SGBD distribuidos. Asimismo, tampoco hay herramientas o metodologías que ayuden a los usuarios a convertir un SGBD centralizado en un SGBD distribuido. Falta de experiencia Los SGBD distribuidos de propósito general no han sido aceptados ampliamente, aunque muchos de los protocolos y de los problemas se comprendan a la perfección. En consecuencia, todavía no tenemos el mismo nivel de experiencia en este sector que en el caso de los SGBD centralizados. Para alguien que esté pensando en adoptar esta tecnología, este factor puede ser uno de los obstáculos principales. Diseño de la base de datos más complejo Además de las dificultades normales de diseñar una base de datos centralizada, el diseño de una base de datos distribuida tiene que tener en cuenta la fragmentación de los datos, la asignación de fragmentos en los diferentes nodos y las cuestiones de replicación de los datos. Hablaremos de estos problemas en la Sección 22.4. La Tabla 22.1 resume las ventajas y desventajas de los SGBDD.
22.1.3
Sistemas SGBDD homogéneos y heterogéneos
Los SGBDD pueden c1asificarse como homogéneos o heterogéneos. En un sistema homogéneo todos los nodos utilizan el mismo SGBD. En un sistema heterogéneo, los nodos pueden estar ejecutando diferentes SGBD, los cuales no tienen por qué estar basados en un mismo modelo de datos subyacente, de modo que el sistema puede estar compuesto de diversos SGBD relacionales, en red, jerárquicos u orientados a objetos. Tabla 22.1.
Resumen de ventajas y desventajas
de los SGBDD.
Ventajas
Desventajas
Reflejan la estructura de la organización
Complejidad
Mejoran la compartición y la autonomía local
Costes
Mejoran la disponibilidad
Seguridad
Mejoran la fiabilidad
Control de integridad más complicado
Mejoran las prestaciones
Carencia de estándares
Economía
Falta de experiencia
Crecimiento modular
Diseño de la base de datos más complejo
Integración Capacidad para seguir siendo competitivos
634
Sistemas de bases de datos
Los sistemas homogéneos son mucho más fáciles de diseñar y mantener. Esta técnica permite el crecimiento incremental, haciendo que la adición de un nuevo nodo al SGBDD sea sencilla, y también permite conseguir unas mayores prestaciones, al aprovechar las capacidades de procesamiento paralelo de los múltiples nodos. (\(US Los sistemas crearse lossenodos propias bases heterogéneo de datos y las suelen integración de cuando los nodos pone individuales en marcha enhan unaimplementado fase posterior.por Ensuuncuenta sistema heterogéneo, se requiere una cierta labor de traducción para que los distintos SGBD puedan comunicarse entre sí. Para proporcionar un cierto grado de transparencia con respecto al SGBD, los usuarios deben poder realizar las solicitudes en el lenguaje del SGBD que utilicen en su nodo local. El sistema deberá entonces encargarse de localizar los datos y de realizar toda la labor de traducción necesaria. Puede que el usuario solicite datos de otro nodo que tenga: •
un hardware diferente;
•
productos SGBD diferentes;
•
diferentes hardware y productos SGBD diferentes.
Si el hardware es diferente pero el SGBD es igual, la traducción es bastante sencilla, bastando con modificar los códigos y la longitud de palabra. Si los productos SGBD son distintos, la traducción se complica, ya que es necesario establecer una correspondencia entre las estructuras de datos de un modelo de datos y las estructuras de datos equivalentes en el otro modelo. Por ejemplo, las relaciones dentro del modelo de datos relacional se hacen corresponder con registros y conjuntos en el modelo de red. También es necesario traducir el lenguaje de consulta utilizado (por ejemplo, las instrucciones SELECT de SQL deben traducirse a instrucciones FIND y GET de red). Si tanto el hardware como el software son distintos, hace falta efectuar ambos tipos de traducción, lo que hace que el procesamiento sea extremadamente complejo. Un nivel adicional de complejidad es la necesidad de proporcionar un esquema conceptual común, que se forma mediante la integración de los esquemas conceptuales locales. Como hemos visto ya en el Paso 2.6 de la metodología del diseño lógico de bases de datos presentada en el Capítulo 16, la integración de modelos de datos puede ser muy difícil debido a la heterogeneidad semántica. Por ejemplo, dos atributos con el mismo nombre en sendos esquemas pueden representar diferentes cosas; asimismo, atributos con nombres distintos pueden modelar el mismo concepto. Un análisis completo de los mecanismos de detección y resolución de los problemas derivados de la heterogeneidad semántica cae fuera del alcance de este libro, pero el lector interesado puede consultar el artículo de García-Solaco el al. (1996). La solución típica empleada en algunos sistemas relacionales que forman parte de un SGBDD heterogéneo consiste en utilizar pasarelas, que convierten el lenguaje y el modelo de cada SGBD al lenguaje y el modelo del sistema relacional. Sin embargo, la técnica basada en pasarelas tiene algunas limitaciones importantes. En primer lugar, puede que no soporte la gestión de transacciones, incluso para una simple pareja de sistemas; en otras palabras, la pasarela entre dos sistemas puede ser únicamente un traductor de consultas. Por ejemplo, un sistema puede no coordinar el control de concurrencia y la recuperación de transacciones en las que se incluyen actualizaciones a las dos bases de datos. En segundo lugar, la solución basada en pasarelas se preocupa sólo del problema de traducir una consulta expresada en un lenguaje a otra expresión equivalente en otro lenguaje. Por ello, generalmente no resuelve el problema de homogeneizar las diferencias estructurales y de representación existentes entre los diferentes esquemas.
Acceso abierto a bases de datos e interoperabilidad Open Group formó un grupo de trabajo (SWG, Specification Working Group) para tratar de dar una respuesta a las cuestiones de acceso abierto a bases de datos e interoperabilidad (Gualtieri, 1996). El objetivo de este grupo era proporcionar especificaciones o verificar la existencia de especificaciones que ya hubieran sido desarrolladas o que estuvieran en desarrollo y que permitieran crear una infraestructura de bases de datos con: •
una interfaz de programación de aplicaciones SQL común y suficientemente potente que permitiera escribir aplicaciones cliente que no necesitaran conocer el fabricante del SGBD al que estuvieran accediendo;
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
635
•
un protocolo de base de datos común que permitiera a un SGBD de un fabricante comunicarse directamente con el SGBD de otro fabricante sin necesidad de una pasarela;
•
un protocolo de red común que permitiera la comunicación entre diferentes SGBD.
El objetivo más ambicioso es encontrar una forma de permitir la traducción entre bases de datos gestionadas por sistemas SGBD de diferentes fabricantes, sin necesidad de utilizar una pasarela. Este grupo de trabajo se ha transformado recientemente en el consorcio DBIOP (Database Interoperability) en el momento de escribir este libro, y está trabajando en la versión 3 de la arquitectura DRDA (Distributed Relational Database Architecture), de la que hablaremos brevemente en la Sección 22.5.2.
Sistemas multi-base de datos Antes de completar esta sección vamos a hablar brevemente de un tipo concreto de SGBD distribuido, conocido con el nombre de sistema multi-base de datos. Sistema multibase de datos
Un SGBD distribuido en el que cada nodo mantiene una completa autonomía.
En los últimos años, ha habido un considerable interés en los sistemas multi-base de datos (MDBS, Multidatabase system), que tratan de integrar desde el punto de vista lógico diversos SGBDD independientes, al mismo tiempo que permiten que los SGBD locales mantengan un control completo de sus operaciones. Una consecuencia de esta total autonomía es que no pueden efectuarse modificaciones software en los SGBD locales. Por tanto, un MDBS requiere una capa de software adicional por encima de los sistemas locales para proporcionar la funcionalidad necesaria. Un MDBS permite a los usuarios acceder a los datos y compartidos sin necesidad de que exista una integración completa del esquema de base de datos. Sin embargo, sigue permitiendo que los usuarios administren sus propias bases de datos sin un control centralizado, al igual que sucede con los SGBDD. El DBA de un SGBD local puede autorizar el acceso a partes concretas de su base de datos especificando un esquema de exportación, que define las partes de la base de datos a las que los usuarios no locales pueden acceder. Existen sistemas MDBS no federados (donde no hay usuarios locales) y federados. Un sistema federado es un cruce entre un SGBD distribuido y un SGBD centralizado; se trata de un sistema distribuido para usuarios globales y de un sistema centralizado para los usuarios locales. El lector interesado puede consultar la obra de Sheth y Larson (1990) para ver una taxonomía de los SGBD distribuidos, así como la obra de Bukhres y Elmagarmid (1996). En términos simples, un MDBS es un SGBD que reside transparentemente por encima de los sistemas de archivo y de las bases de datos existentes y que presenta a los usuarios una única base de datos. Un MDBS mantiene únicamente el esquema global de acuerdo con el cual los usuarios plantean sus consultas y actualizaciones, siendo los propios SGBD locales los que se encargan de mantener todos los datos del usuario. El esquema global se construye integrando los esquemas de las bases de datos locales. El MDBS traduce primero las consultas y actualizaciones globales en consultas y actualizaciones dirigidas a los SGBD locales apropiados. A continuación, combina los resultados locales y genera el resultado global final para el usuario. Además, el MDBS coordina las operaciones de confirmación y de aborto de las transacciones globales por parte de los SGBD locales que las procesan, con el fin de mantener la coherencia de los datos entre las distintas bases de datos locales. Un MDBS controla múltiples pasarelas y gestiona las bases de datos locales a través de estas pasarelas. Hablaremos de la arquitectura de un MDBS en la Sección 22.3.3.
22.2 Panorámica de la comunicación por red Red
Una colección interconectada intercambiar información.
de computadoras
autónomas
que son capaces
de
El tema de las redes informáticas constituye un campo complejo y en rápida evolución, pero resulta útil tener algunas nociones de este campo para poder comprender los sistemas distribuidos. Comparando la situación
636
Sistemas de bases de datos
con la existe hace algunas décadas, cuando los sistemas eran completamente autónomos, lo que ahora vemos es que las redes informáticas son ya algo común. Estas redes van desde sistemas que conectan unas pocas computadoras de sobremesa hasta redes de alcance mundial con miles de máquinas y millones de usuarios. En lo que a nosotros respecta, los SGBDD se construyen sobre una red informática de modo tal que la red queda oculta a ojos del usuario. Podemos clasificar las redes de comunicaciones de varias formas. Una de las posibles clasificaciones es la que podemos efectuar de acuerdo a la distancia que separa las distintas computadoras, que puede ser pequeña (red de área local) o grande (red de área extensa). Una red de área local (LAN) conecta una serie de computadoras relativamente próximas entre sí, como por ejemplo dentro de un edificio de oficinas, dentro de una universidad o dentro de un domicilio. En ocasiones, en un mismo edificio puede haber varias redes LAN de pequeño tamaño, mientras que en otros casos una misma LAN puede abarcar varios edificios cercanos. Las redes LAN son normalmente propiedad de una única organización o persona que es quien las controla y las gestiona. Las principales tecnologías de conectividad utilizadas en este tipo de redes son Ethernet y Token Ring. Las redes de área extensa (WAN) se utilizan cuando es necesario conectar una serie de computadoras o redes LAN a larga distancia. La red WAN de mayor tamaño que existe es Internet. A diferencia de una LAN, las redes WAN no son propiedad, generalmente, de una única organización, sino que la propiedad y la gestión de este tipo de redes es colectiva o distribuida. Las redes WAN utilizan tecnologías tales como ATM, FrameRelay y X.25 para la conectividad. Un caso especial de red WAN es la red de área metropolitana (MAN), que cubre generalmente una ciudad o un suburbio. Debido a la gran separación geográfica, los enlaces de comunicaciones en una WAN son relativamente lentos y menos fiables que en una LAN. Las velocidades de transmisión para una WAN van generalmente desde los 33,6 kilobits por segundo (módem de acceso telefónico) a 45 megabits por segundo (línea privada T3 no conmutada). Las velocidades de transmisión de las redes LAN son muy superiores, operando desde 10 megabits por segundo (ethernet compartida) hasta 2500 megabits por segundo (ATM), y son altamente fiables. Obviamente, un SGBDD que utilice una red LAN como medio de comunicación proporcionará un tiempo de respuesta mucho más rápido que otro que utilice una red WAN. Si examinamos el método de selección de rutas, o encaminamiento, podemos clasificar una red como punto a punto o de difusión. En una red punto a punto, si un nodo quiere enviar un mensaje a todos los nodos, deberá enviar varios mensajes independientes. En una red de difusión, todos los nodos recibirán todos los mensajes, pero cada mensaje tiene un prefijo que identifica el nodo de destino, por lo que los demás nodos simplemente ignorarán los mensajes que no vayan dirigidos a ellos. Las redes WAN se basan generalmente en una red punto a punto, mientras que las redes LAN utilizan por regla general mecanismos de difusión. En la Tabla 22.2 se presenta un resumen de las características típicas de las redes WAN y LAN. Tabla 22.2.
Resumen de las características
típicas de las redes WAN y LAN.
WAN
LAN
Distancias de hasta miles de kilómetros
Distancias de unos pocos kilómetros
Enlaza computadoras
Enlaza computadoras que cooperan en aplicaciones distribuidas
autónomas
Red gestionada por una organización independiente (utilizando enlaces telefónicos o vía satélite)
Red gestionada por los usuarios (utilizando cables de propiedad privada)
Velocidad de datos de hasta 33,6 kbit/s (acceso telefónico por módem), 45 Mbit/s (circuito T3)
Velocidad de datos de hasta 2500 Mbit/s (ATM). Actualmente están en desarrollo las redes Ethernet a 10 gigabits (10.000 millones de bits por segundo)
Protocolo complejo
Protocolo más simple
Utiliza encaminamiento
Utiliza encaminamiento
punto a punto
Utiliza topologías de bus o anillo
Utiliza topologías irregulares Tasa de errores de aproximadamente
por difusión
1: 105
Tasa de errores de aproximadamente
1: 109
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
637
La organización ISO (International Organization for Standardization) ha definido un protocolo que gobierna la forma en que los sistemas pueden comunicarse (ISO, 1981). El enfoque adoptado consiste en dividir la red en una serie de niveles, proporcionando cada nivel un servicio concreto al nivel situado por encima suyo, al mismo tiempo que oculta los detalles de implementación. El protocolo, denominado modelo de interconexión de sistemas abiertos (O SI, Open Systems Interconnection) está compuesto por siete niveles independientes. Los niveles se encargan de la transmisión de bits a través de la red, de la gestión de la conexión y de garantizar que el enlace esté libre de errores, del encaminamiento y el control de congestión, de la gestión de sesiones entre diferentes máquinas y de resolver las diferencias de formato y de representación de los datos entre unas máquinas y otras. No es necesario proporcionar una descripción de este protocolo para comprender los tres capítulos que en este libro dedicamos al tema de los SGBD distribuidos y móviles, por lo que el lector interesado puede consultar Halsall (1995) y Tanenbaum (1996). CCITT (International Telegraph and Telephone Consultative Committee) ha elaborado un estándar conocido como X.25 que cumple con los tres niveles inferiores de esta arquitectura. La mayoría de los SGBDD están desarrollados para utilizar X.25. Sin embargo, se están desarrollando ahora nuevos estándares para los niveles superiores que pueden proporcionar servicios útiles para los SGBDD, como por ejemplo RDA (Remote Database Access) para el acceso remoto a bases de datos (ISO 9579) o DTP (Distributed Transaction Processing) para el procesamiento distribuido de transacciones (ISO 10026). Examinaremos el estándar DTP de X/Open en la Sección 23.5. Como información de referencia adicional, vamos a repasar ahora brevemente los principales protocolos de comunicación por red.
Protocolos de red Protocolo de red
Un conjunto de reglas que determina mensajes entre computadoras.
cómo se envían, interpretan y procesan los
En esta sección vamos a describir brevemente los principales protocolos de red.
TCP/IP {Transmission Control Protocol/lnternet Protoco!} Este es el protocolo estándar de comunicaciones para Internet, una colección mundial de redes informáticas interconectadas. TCP es responsable de verificar la correcta entrega de los datos intercambiados entre los clientes y los servidores. IP proporciona el mecanismo de encaminamiento, basado en una dirección de destino de cuatro bytes (la dirección IP). La parte delantera de la dirección IP indica la parte de red, mientras que la parte trasera indica la parte de la dirección correspondiente al host. La línea divisoria entre las partes de red y de host de una dirección IP no es fija. TCP/IP es un protocolo encaminable, lo que significa que los mensajes no sólo contienen la dirección de la estación de destino, sino también la dirección de la red de destino. Esto permite que los mensajes TCP/IP sean enviados a múltiples redes dentro de una organización o distribuidas por todo el mundo, lo cual es la razón de que se utilice este protocolo en Internet.
SPX/IPX (Sequenced Packet Exchange/lnternetwork
Package Exchange)
Novell creó el protocolo SPX/IPX como parte de su sistema operativo NetWare. Similar a TCP, SPX garantiza que un mensaje llegue intacto, aunque difiere de TCP en que utiliza el protocolo IPX de NetWare como mecanismo de entrega. Al igual que IP, IPX se encarga de encaminar los paquetes a través de la red, pero a diferencia de aquél, IPX utiliza un espacio de direcciones de 80 bits, con una parte de red de 32 bits y una parte de host de 48 bits (este espacio de direccionamiento es mucho mayor que los 32 bits usados por IP para las direcciones). Asimismo, a diferencia de IP, IPX no se encarga de la fragmentación de paquetes. Sin embargo, una de las grandes ventajas de IPX es su sistema de direccionamiento automático de host. Los usuarios pueden mover su PC de una ubicación de la red a otra y continuar trabajando simplemente volviendo a conectarse. Esto es particularmente importante para los usuarios móviles. Hasta la aparición de NetWare 5, SPX/IPX era el protocolo predeterminado de las redes de Novell, pero para reflejar la importancia de Internet, NetWare 5 ha adoptado TCP/IP como protocolo predeterminado.
638
Sistemas de bases de datos
NetBIOS
(Network
Basic Input/Output
System)
Es un protocolo de red desarrollado en 1984 por IBM y Sytek como estándar para la comunicación entre aplicaciones basadas en PC. Originalmente NetBIOS y NetBEUI (NetBIOS Extended User Interface) se consideraban un mismo protocolo. Posteriormente, se decidió separar NetBIOS, ya que podía utilizarse con otros protocolos de transporte encaminables, por lo que hoy en día las sesiones NetBIOS pueden transportarse sobre NetBEUI, TCP/IP y SPX/IPX. NetBEUI es un protocolo rápido, eficiente y con poca carga de procesamiento adicional. Sin embargo, tiene la desventaja de que no es encaminable, por lo que una configuración típica utiliza NetBEUI para la comunicación dentro de la LAN y TCP/IP para las comunicaciones que transciendan las fronteras de ésta. APPC (Advanced
Program-to-Program
Communications)
Un protocolo de comunicaciones de alto nivel desarrollado por IBM que permite que un programa interactúe con otro a través de una red. Soporta la arquitectura cliente-servidor y el procesamiento distribuido proporcionando una interfaz de programación común para todas las plataformas IBM. Proporciona comandos para gestionar una sesión, para enviar y recibir datos y para la gestión de transacciones mediante un protocolo de confirmación en dos fases (tema del que hablaremos en el siguiente capítulo). El software APPC forma parte de todos los sistemas operativos IBM y de muchos no IBM, o constituye una opción que puede adquirirse por separado. Puesto que APPC sólo soportaba originalmente la arquitectura SNA (Systems Network Architecture) de IBM, que utiliza el protocolo LU 6.2 para establecimiento de sesiones, APPC y LU 6.2 se consideran a menudo sinónimos. DECnet DECnet es el protocolo de comunicaciones encaminable de Digital, que soporta redes LAN estilo Ethernet y redes WAN de banda base y de banda ancha sobre líneas privadas o públicas. Interconecta máquinas PDP, VAX, PC, Mac y estaciones de trabajo. AppleTalk Es el protocolo encaminable de Apple para redes LAN presentado en 1985, que soporta el método de acceso LocalTalk propietario de Apple, además de Ethernet y Token Ring. El gestor de red AppleTalk y el método de acceso LocalTalk están integrados en todas las computadoras Macintosh y en las impresoras LaserWriters. W AP (Wireless
Application
Protocoll
Un estándar para proporcionar a los teléfonos móviles, buscapersonas y otros dispositivos de mano un acceso seguro a los servicios de correo electrónico y a las páginas web basadas en texto. Introducido en 1997 por Phone.com (antiguamente denominada Unwired Planet), Ericsson, Motorola y Nokia, WAP proporciona un entorno completo para aplicaciones inalámbricas que incluye un equivalente inalámbrico de TCP/IP y un entorno de aplicación para integración telefónica, como por ejemplo para control de llamadas y acceso a listines telefónicos.
Tiempo de comunicación El tiempo necesario para enviar un mensaje depende de la longitud del mensaje y del tipo de red que se esté utilizando. Puede calcularse utilizando la fórmula: Tiempo de comunicación = Ca+ (nO_de_bits_en_mensaje/velocidad_transmisión) donde Ca es un coste fijo de iniciación de un mensaje, denominado retardo de acceso. Por ejemplo, utilizando un retardo de acceso de 1 segundo y una velocidad de transmisión de 10000 bits por segundo, podemos calcular el tiempo necesario para enviar 100000 registros compuestos cada uno de 100 bits: Tiempo de comunicación = 1 + (100000*100/10000)
= 1001 segundos
Si queremos transferir 100000 registros de uno en uno, obtenemos
Capítulo 22
Tiempo de comunicación
Bases de datos distribuidas:
conceptos y diseño
639
= 100000 * [1+(100/10000)] = 100000 * [1.01] = 101000 segundos
Obviamente, el tiempo de comunicación es significativamente mayor si se transfieren 100000 individualmente, debido al retardo de acceso. En consecuencia, un objetivo de un SGBDD es minimizar tanto el volumen de los datos transmitidos a través de la red como el número de transmisiones de red. Volveremos sobre este punto cuando hablemos de la optimización de consultas distribuidas en la Sección 22.5.3.
22.3 Funciones y arquitectura de un SGBDD En el Capitulo 2 hemos examinado las funciones, la arquitectura y los componentes de un mensaje descentralizado. En esta sección, vamos a ver cómo afecta la distribución a la funcionalidad esperada y a la arquitectura de los sistemas de gestión de bases de datos.
22.3.1
Funciones de un SGBDD
Lo que esperamos de un SGBDD es que tenga al menos la funcionalidad de un SGBD centralizado, funcionalidad que hemos expuesto en el Capítulo 2. Además, esperamos que el SGBDD proporcione la siguiente funcionalidad adicional: •
servicios avanzados de comunicaciones para proporcionar acceso a nodos remotos y permitir la transferencia de consultas y de datos entre los nodo s a través de una red;
•
un catálogo ampliado del sistema en el que se almacenen los detalles relativos a la distribución de los datos;
•
procesamiento avanzado de consultas, incluyendo mecanismos de optimización de consultas y de acceso remoto a datos;
•
un control avanzado de seguridad para mantener los apropiados privilegios de autorización/acceso los datos distribuidos;
•
mecanismos avanzados de control de concurrencia para mantener la coherencia de los datos distribuidos y posiblemente replicados:
•
servicios avanzados de recuperación para tener en cuenta los fallos de los nodos individuales y los fallos de los enlaces de comunicaciones.
a
Hablaremos de estos temas con más profundidad en las secciones posteriores, asi como en el Capítulo 23.
22.3.2
Arquitectura de referencia para un SGBDD
La arquitectura en tres niveles ANSI-SPARC para un SGBD presentada en la Sección 2.1 proporciona una arquitectura de referencia para un SGBD centralizado. Debido a la diversidad de sistemas SGBD distribuidos, resulta mucho más difícil presentar una arquitectura equivalente que sea de general aplicación. Sin embargo, puede resultar útil presentar una posible arquitectura de referencia que contemple la distribución de datos. La arquitectura de referencia mostrada en la Figura 22.4 está compuesta de los siguientes esquemas: •
un conjunto de esquemas externos globales;
•
un esquema conceptual global;
•
un esquema de fragmentación y un esquema de asignación;
•
un conjunto de esquemas para cada SGBD local conformes a la arquitectura en tres niveles de ANSISPARC.
Las aristas de esta figura representan correspondencias entres los distintos esquemas. Dependiendo de qué niveles de transparencia estén soportados, puede que algunos niveles no estén presentes en una arquitectura de un sistema concreto.
)640
Sistemas de bases de datos ••• Esquema externo global
Esquema externo global
Esquema externo global
Esquema conceptual global
Esquema de fragmentación
local conceptual local correspondencia Esquema de
=r
Esquema Esquema asignación I
•••
Sn
I I
local local local interno correspondencia Esquema local interno S2 Esquema dede conceptual rsquema
S, L:quema
BD
BD Figura 22.4.
Esquema conceptual
Arquitectura
BD
de referencia para un SGBDD.
global
El esquema conceptual global es una descripción lógica de toda la base de datos, como si ésta no estuviera distribuida. Este nivel se corresponde con el nivel conceptual de la arquitectura ANSI-SPARC y contiene definiciones de entidades, relaciones, restricciones, mecanismos de seguridad e información de integridad. Proporciona independencia física de los datos con respecto al entorno distribuido. Los esquemas externos globales proporcionan independencia lógica de los datos.
Esquemas de fragmentación
y asignación
El esquema de fragmentación es una descripción del modo en que hay que particionar lógicamente los datos. El esquema de asignación es una descripción de dónde hay que ubicar los datos, teniendo en cuenta los mecanismos de replicación utilizados.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
641
Esquemas locales Cada SGBD local tiene su propio conjunto de esquemas. Los esquemas conceptual e interno locales se corresponden con los niveles equivalentes de la arquitectura ANSI-SPARC. El esquema de correspondencia local establece la correspondencia entre los fragmentos del esquema de asignación y los objetos externos de la base de datos local. Este nivel es independiente del SGBD y es la base para el soporte de sistemas SGBD heterogéneos.
22.3.3 Arquitectura de referencia para un MDBS federado En la Sección 22.1.3 hemos hablado brevemente de los sistemas multi-base de datos (MDBS) federados. Los sistemas federados difieren de los SGBDD en el nivel de autonomía local permitido. Esta diferencia se refleja también en la arquitectura de referencia. La Figura 22.5 ilustra una arquitectura de referencia para un sistema multi-base de datos federado estrechamente acoplado, es decir, que tiene un esquema conceptual global. En un SGBDD, el esquema conceptual global es la unión de todos los esquemas conceptuales locales. Por el contrario, en un MDBS federado, el esquema conceptual global es un subconjunto de los esquemas conceptuales locales, compuesto de los datos que cada sistema local decide compartir. El esquema conceptual global en un sistema fuertemente acoplado implica la integración de partes de los esquemas conceptuales locales o de los esquemas externos locales .
••• •
8, Esquema externo global
Esquema externo global
Esquema conceptual global
Esquema externo local
Figura 22.5.
Esquema externo local
Esquema externo local
Esquema externo local
Esquema conceptual local
Esquema conceptual local
Esquema interno local
Esquema interno local
BD
BD
Arquitectura
de referencia para un MDBS federado fuertemente
acoplado.
642
Sistemas de bases de datos
Algunos autores argumentan que un MDBS federado no debe tener un esquema conceptual global (Litwin, 1988), en cuyo caso se dice que el sistema está débilmente acoplado. En este caso, los esquemas externos están compuestos por uno o más esquemas conceptuales locales. Para obtener información adicional sobre los MDBS, el lector interesado puede consultar Litwin (1988) y Sheth y Larson (1990).
22.3.4
Componentes de un SGBDD
Independientemente un SGBDD:
de la arquitectura de referencia, podemos identificar cuatro componentes principales en
•
SGBD local (SGBDL);
•
componente de comunicaciones
• •
catálogo global del sistema (CGS); SGBD distribuido.
de datos (CD);
La arquitectura de componentes de un SGBDD basada en la Figura 22.1 se ilustra en la Figura 22.6. Para una mayor claridad, hemos omitido el Nodo 2 del diagrama, ya que tiene la misma estructura que el Nodo 1.
SGBD local El SGBD local es un SGBD estándar, responsable de controlar los datos locales en cada nodo que tenga una base de datos. Tiene su propio catálogo local del sistema que almacena información acerca de los datos contenidos en dicho nodo. En un sistema homogéneo, todos los SGBD locales serán el mismo producto, replicado en cada nodo. En un sistema heterogéneo, habrá al menos dos nadas con diferentes productos SGBD y/o plataformas.
Componentes
de comunicación
de datos
El componente de comunicación de datos es el software que permite que todos los nodos se comuniquen entre sí. El componente de comunicación de datos contiene información acerca de los nodos y de los enlaces. Nodo 1
CGS
CGS
SGBDD BD
CD
Nodo 3
Figura 22.6.
Componentes
de un SGBDD.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
643
Catálogo global del sistema El catálogo global del sistema tiene la misma funcionalidad que el catálogo del sistema en un sistema centralizado. El catálogo global del sistema mantiene información específica de la naturaleza distribuida del sistema, como por ejemplo los esquemas de fragmentación, replicación y asignación. El propio catálogo puede ser gestionado como una base de datos distribuida, por lo que puede estar fragmentado y distribuido, completamente replicado o centralizado, como cualquier otra relación, según veremos en breve. Un catálogo global del sistema completamente replicado pone en cuestión la autonomía de los nodos, ya que toda modificación del catálogo global del sistema tendrá que ser comunicada a todos los demás nodos. Un catálogo global del sistema centralizado también pone en cuestión la autonomía de los nodos y es vulnerable a los fallos del nodo central. La solución adoptada en el sistema distribuido R * resuelve estos problemas (Williams et al., 1982). En R *, hay un catálogo local en cada nodo que contiene los metadatos relativos a los datos que se almacenan en dicho nodo. Para las relaciones creadas en un cierto nodo (el nodo de creación), es responsabilidad del catálogo local de dicho nodo registrar la definición de cada fragmento y de cada réplica de cada fragmento, así como de registrar la ubicación de cada fragmento o réplica. Cuando un fragmento de réplica se mueve a una ubicación distinta, el catálogo local del correspondiente nodo de creación de la relación deberá ser actualizado. Así, para localizar un fragmento o réplica de una relación, es necesario acceder al catálogo del nodo de creación de dicha relación. El nodo de creación de cada relación global se registra en cada catálogo local del sistema. Volveremos sobre el tema de la denominación de objetos cuando hablemos de la transparencia de denominación en la Sección 22.5.1.
SGBD distribuido El SGBDD es la unidad de control del sistema completo. Ya hemos explicado brevemente la funcionalidad de este componente en la sección anterior y hablaremos más en detalle de dicha funcionalidad en la Sección 22.5 y en el Capítulo 23.
22.4 Diseño de bases de datos relacionales distribuidas En los Capítulos 15 y 16 hemos presentado una metodología para el diseño conceptual y lógico de una base de datos relacional centralizada. En esta sección, vamos a examinar los factores adicionales que hay que tener en cuenta para el diseño de una base de datos relacional distribuida. Más específicamente, vamos a examinar los siguientes conceptos: •
Fragmentación. Una relación puede dividirse en una serie de subrelaciones, denominadas fragmentos, que a continuación se distribuyen. Hay dos tipos principales de fragmentación: horizontal y vertical. Los fragmentos horizontales son subconjuntos de tuplas, mientras que los fragmentos verticales son subconjuntos de atributos.
•
Asignación. ción.
•
Replicación. El SGBDD puede mantener una copia de un fragmento en varios nodos diferentes.
Cada fragmento se almacena en el nodo 'óptimo' desde el punto de vista de la distribu-
La definición y asignación de fragmentos debe estar basada en el modo en que se va a utilizar la base de datos. Esto implica analizar las transacciones. Generalmente, no es posible analizar todas las transacciones, por lo que habremos de concentramos en las más importantes. Como hemos indicado en la Sección 17.2, algunos autores sugieren que el 20% de consultas de usuario más utilizadas representan el 80% de los accesos totales a los datos, y esta regla 80/20 puede utilizarse como guía a la hora de llevar a cabo el análisis (Wiederhold, 1983). El diseño debe estar basado en información tanto cuantitativa como cualitativa. La información cuantitativa se usa para la asignación; la información cualitativa se usa durante la fragmentación. La información cuantitativa puede incluir: •
la frecuencia con la que se ejecuta cada transacción;
644
Sistemas de bases de datos
•
el nodo desde el que se ejecuta una transacción;
•
los criterios de rendimiento para las transacciones.
La información cualitativa puede incluir información acerca de las transacciones por ejemplo: •
las relaciones, atributos y tuplas a las que se accede;
•
el tiempo de acceso (lectura o escritura);
•
los predicados de las operaciones de lectura.
que se ejecutan, como
La definición y asignación de fragmentos se lleva a cabo de manera estratégica para conseguir los siguientes objetivos: •
Localidad de referencia. Siempre que sea posible los datos deben almacenarse en un punto próximo al de su utilización. Si un fragmento se utiliza en varios nadas, puede ser conveniente almacenar copias del fragmento en todos esos nadas.
•
Mayor fiabilidad y disponibilidad. La fiabilidad y la disponibilidad se mejoran gracias a la replicación: hay otra copia del fragmento disponible en otro nodo, en caso de que uno de los nadas falle.
•
Rendimiento aceptable. Una mala asignación puede dar como resultado la aparición de cuellos de botella, es decir, que un nodo se vea inundado de solicitudes procedentes de otros nadas, lo que quizá traiga consigo una degradación significativa en el rendimiento. Alternativamente, una mala asignación puede provocar una infrautilización de los recursos.
•
Equilibrio entre la capacidad de almacenamiento y el coste. Debe prestarse atención a la disponibilidad y coste del almacenamiento en cada nodo, para que puedan utilizarse soportes de almacenamiento masivo de bajo coste, siempre que sea posible. Este criterio debe equilibrarse con el de localidad de referencia.
•
Costes de comunicaciones mínimos. También hay que prestar atención al coste de las solicitudes remotas. Los costes de extracción de datos se minimizan cuando se optimiza la localidad de referencia o cuando cada nodo dispone de su propia copia de los datos. Sin embargo, cuando se actualizan los datos replicados, la actualización debe llevarse a cabo en todos los nadas que mantengan una copia duplicada, incrementándose así los costes de comunicaciones.
22.4.1
Asignación de los datos
Hay cuatro estrategias alternativas en lo que respecta a la ubicación de los datos: centralizada, fragmentada, replicación completa y replicación selectiva. Vamos a comparar estas estrategias utilizando los objetivos que acabamos de identificar.
Centralizada Esta estrategia se basa en un único SGBD y una única base de datos almacenada en un nodo, estando los usuarios distribuidos por toda la red (anteriormente hemos denominado a esta estrategia 'procesamiento distribuido'). La localidad de referencia es pésima, ya que todos los nadas (excepto en el nodo central) tienen que utilizar la red para todos los accesos a datos. Esto significa también que los costes de comunicaciones son altos. La fiabilidad y la disponibilidad son bajas, ya que un fallo en el nodo central tiene como resultado la pérdida de todo el sistema de base de datos.
Fragmentada
(o particionada)
Esta estrategia particiona la base de datos en una serie de fragmentos disjuntos, estando cada fragmento asignado a un nodo. Si los elementos de datos están ubicados en el nodo donde se les usa más frecuentemente, la localidad de referencia será alta. Como no hay ninguna replicación, los costes de almacenamiento son bajos; de forma similar, la fiabilidad y la disponibilidad también son bajas, aunque superiores a las del caso centralizado, ya que el fallo de un nodo hace que sólo se pierdan los datos de dicho nodo. Las prestaciones pueden
Capítulo 22 Bases de datos distribuidas:
conceptos y diseño
645
ser buenas y los costes de comunicación bajos, siempre y cuando los mecanismos de distribución hayan sido diseñados apropiadamente.
Replicación completa Esta estrategia consiste en mantener una copia completa de la base de datos en cada nodo. Como consecuencia, la localidad de referencia, la fiabilidad, la disponibilidad y las prestaciones se maximizan. Sin embargo, los costes de almacenamiento y los costes de comunicaciones para las organizaciones son máximos. Para resolver algunos de estos problemas, se utilizan en ocasiones las denominadas instantáneas. Una instantánea es una copia de los datos en un instante concreto. Dichas copias se actualizan periódicamente, como por ejemplo cada hora o cada semana, así que puede que no siempre estén actualizadas. En ocasiones, las instantáneas se utilizan también para implementar las vistas en una base de datos distribuida, con el fin de mejorar el tiempo que se tarda en realizar una operación de base de datos sobre una vista. Hablaremos de las instantáneas en la Sección 24.6.2.
Replicación selectiva Esta estrategia es una combinación de fragmentación, replicación y centralización. Algunos elementos de datos se fragmentan para conseguir una alta localidad de referencia, mientras que otros, que se utilizan en muchos nodo s y no se actualizan frecuentemente, se replican; todos los demás elementos de datos se centralizan. El objetivo de esta estrategia es conseguir todas las ventajas de las otras técnicas, pero sin ninguna de las desventajas. Esta es la estrategia más comúnmente utilizada, debido a su flexibilidad. La Tabla 22.3 resume las distintas estrategias. Para obtener más detalles sobre el tema de asignación, el lector interesado puede consultar Ozsu y Valduriez (1999) y Teorey (1994).
22.4.2
Fragmentación
¿Por qué fragmentar? Antes de hablar en detalle de la fragmentación, indiquemos cuatro razones para fragmentar una relación: •
Utilización. En general, las aplicaciones funcionan con vistas, en lugar de con relaciones completas. Por tanto, para la distribución de datos, parece apropiado trabajar con subconjuntos de las relaciones como unidad de distribución .
•
Eficiencia. Los datos se almacenan cerca del lugar donde se los utiliza más frecuentemente. los datos que las aplicaciones locales no necesitan no se almacenan en ese nodo. Tabla 22.3. Localidad de referencia
--
un buen Centralizada diseño.
lectura para el sistema
Comparación Fiabilidad y disponibilidad
Además,
de estrategias para la asignación de datos. Prestaciones
lectura Mínimos Mínima Máximos Máximos Alta' Medios Mínima Insatisfactoria Máxima Máxima Satisfactoria' elementos; altabajos para Baja para para lospara zación; Máximas Altos actualiBajos'
Costes de almacenamiento
Costes de comunicaciones
646
Sistemas de bases de datos
•
Paralelismo. Utilizando el fragmento como unidad de distribución, una transacción puede dividirse en varias sub consultas que operan sobre distintos fragmentos. Esto debería permitir incrementar el grado de concurrencia o paralelismo en el sistema, permitiendo así que se ejecuten en paralelo aquellas transacciones que puedan paralelizarse con seguridad.
•
Seguridad. Los datos no requeridos por las aplicaciones locales no se almacenan en ese nodo y, consecuentemente, no están disponibles para los usuarios no autorizados.
La fragmentación tiene dos desventajas principales, que ya hemos mencionado antes: •
Rendimiento. El rendimiento de las aplicaciones globales que requieren datos de diversos fragmentos ubicados en diferentes nadas puede ser menor.
•
Integridad. El control de integridad puede ser más dificil si los datos y las dependencias funcionales están fragmentados y ubicados en nadas distintos.
Corrección de la fragmentación La fragmentación no puede llevarse a cabo descuidadamente. la fragmentación:
Hay tres reglas que es preciso respetar durante
(1) Completud. Si una instancia R de una relación se descompone en fragmentos R¡, Rz, ... , Rm cada elemento de datos que aparezca en R debe aparecer al menos en un fragmento. Esta regla es necesaria para garantizar que no haya pérdida de datos durante la fragmentación. (2) Reconstrucción. Debe ser posible definir una operación relacional que permita reconstruir la relación R a partir de los fragmentos. Esta regla garantiza que se preserven las dependencias funcionales. (3) Disyunción. Si un elemento de datos d¡ aparece en el fragmento R¡, no debe aparecer en ningún otro fragmento. La fragmentación vertical es la excepción a esta regla, ya que los atributos de clave principal deberán estar repetidos para permitir la reconstrucción de la relación. Esta regla garantiza una redundancia mínima de los datos. En el caso de la fragmentación horizontal, el elemento de datos es la tupla; para la fragmentación vertical, el elemento de datos es un atributo.
Tipos de fragmentación Hay dos tipos principales de fragmentación: horizontal y vertical. Los fragmentos horizontales son subconjuntos de tuplas y los fragmentos verticales son subconjuntos de atributos, como se ilustra en la Figura 22.7. Hay también otros dos tipos de fragmentación: mixta, ilustrada en la Figura 22.8, y derivada, un tipo de fragmentación horizontal. Vamos a proporcionar a continuación ejemplos de los diferentes tipos de fragmentación, utilizando la instancia de la base de datos de DreamHome mostrada en la Figura 3.3.
(a)
(b)
Figura 22.7.
(a) Fragmentación
horizontal y (b) fragmentación
vertical.
Capítulo 22
Bases de datos distribuidas: conceptos y diseño
(b)
(a)
Figura 22.8.
Fragmentación
647
Fragmentación mixta: (a) fragmentos verticales fragmentados (b) fragmentos horizontales fragmentados verticalmente.
horizontalmente;
horizontal Está compuesto de un subconjunto
Fragmento horizontal
de las tuplas de una relación.
La fragmentación horizontal agrupa las tuplas de una relación que son utilizadas de manera colectiva por las transacciones de mayor importancia. Los fragmentos horizontales se generan especificando un predicado que imponga una restricción a las tuplas de la relación. Dicho predicado se define utilizando la operación de selección del álgebra relacional (véase la Sección 4.1.1). La operación de selección agrupa tuplas que tengan alguna propiedad común; por ejemplo, las tuplas que sean utilizadas por una misma aplicación o que sean utilizadas en un mismo nodo. Dada una relación R, un fragmento horizontal se define como: (Jp(R)
donde p es un predicado basado en uno o más atributos de la relación.
I
Ejemplo 22.2 Fragmentación
horizontal
Suponiendo que sólo haya dos tipos de inmuebles, Flat (apartamento) y House (casa), la fragmentación horizontal de PropertyForRent de acuerdo con el tipo de inmueble puede obtenerse de la forma siguiente: P 1:
(Jtype='House·(PropertyForRent)
P2:
lTtype='Flar(PropertyForRent)
Esto genera dos fragmentos (p¡ y P2), uno compuesto por aquellas tuplas para las que el valor del atributo type es 'House' y el otro compuesto por aquellas tuplas para las que el valor del atributo type es 'Flat', como se muestra en la Figura 22.9. Esta estrategia de fragmentación concreta puede ser ventajosa si se utilizan aplicaciones distintas para gestionar las casas y los apartamentos. El esquema de fragmentación satisface las reglas de corrección: Fragmento P1 rent B00718 C046 6650 SA9 Aberdeen 16 Holhead Dale Rd C087 5rooms 600 B003 SG37 House AB75SU ownerNo branchNo staffNo street G12 city propertyNo Glasgow postcode type
Fragmento P2 rent 375 B0032 B003 C040 C093 43rooms 350 450 B0035 G129AX SG14 SG37 Flat Novar DI' St C087 400 B0056 NW2 SL41 London ManorRd Lawrence street ownerNo branchNo staffNo G119QX G324QX 6Argyll St Glasgow postcode type city propertyNo
Figura 22.9.
Fragmentación
horizontal de PropertyForRent
de acuerdo con el tipo de inmueble.
648 Sistemas de bases de datos •
Completud. Cada tupla de la relación aparece en el fragmento PI o en el fragmento P2.
•
Reconstrucción. La relación PropertyForRentpuede reconstruirse a partir de los fragmentos utilizando el operador de unión: P,
•
U P2 =
PropertyForRent
Disyunción. Los fragmentos son disjuntos; no puede haber ningún inmueble que sea a la vez de tipo 'House'y
'Flat'.
~
En ocasiones, la elección de la estrategia de fragmentación horizontal resulta obvia. Sin embargo, en otros casos, es necesario analizar la aplicación en detalle. El análisis implica un examen de los predicados (o condiciones de búsqueda) usados por las transacciones o consultas en las aplicaciones. Los predicados pueden ser simples, implicando un solo atributo, o complejos, implicando múltiples atributos. Los predicados para cada atributo pueden ser univaluados o multivaluados. En este último caso, los valores pueden ser discretos o implicar rangos de valores. La estrategia de fragmentación requiere encontrar un conjunto de predicados mínimo (es decir, completo y relevante) que pueda usarse como base para el esquema de fragmentación (Ceri et al., 1982). Un conjunto de predicados es completo si y sólo si cualquiera de las dos tuplas del mismo fragmento se referencian con la misma probabilidad por cualquier transacción. Un predicado es relevante si existe al menos una transacción que acceda de manera distinta a los fragmentos resultantes. Por ejemplo, si el único requisito es seleccionar tuplas de PropertyForRent basándose en el tipo de inmueble, el conjunto {type = 'House', type = 'Flat'} es completo, mientras que el conjunto {type = 'House'} no es completo. Por otro lado, con este requisito, el predicado (city = 'Aberdeen') no sería relevante.
Fragmentación vertical Fragmento vertical
Está compuesto de un subconjunto
de los atributos de una relación.
El mecanismo de fragmentación vertical agrupa los atributos de una relación que son utilizados de manera conjunta por las transacciones de mayor importancia. Un fragmento vertical se define utilizando la operación de proyección del álgebra relacional (véase la Sección 4.1.1). Dada una relación R, un fragmento vertical se define como: Da",
" a/R)
donde al' ... ,
I
an
son atributos de la relación R.
Ejemplo 22.3 Fragmentación vertical La aplicación de nóminas de DreamHome requiere el número de empleado staffNoy los atributos position, sex, DOB y salary de cada empleado; el departamento de personal requiere los atributos staffNo, fName, IName y branchNo. La fragmentación vertical de Staff para este ejemplo puede obtenerse de la forma siguiente: 81:
IIstaffNo, position, sex, 008,
82:
IIstaffNo,
fName,
IName,
salary(Staff)
branchNo(Staff)
Esto produce dos fragmentos (SI y S2), como se muestra en la Figura 22.10. Observe que ambos fragmentos contienen la clave principal, staffNo,para permitir reconstruir la relación original. La ventaja de la fragmentación vertical es que los fragmentos pueden almacenarse en los nodos que los necesitan. Además, las prestaciones se mejoran, ya que el fragmento es más pequeño que la relación base original. Este esquema de fragmentación satisface las reglas de corrección:
Capítulo 22
Bases de datos distribuidas:
Fragmento
conceptos y diseño
649
S1
staffNoDOS Assistant F 19-Feb-70 24-Mar-58 18000 9000 1-0ct-4530000 10-Nov-60 M 12000 3-jun-4024000 13-jun-65 sex Manager salary Supervisor position SL41 SG5 SA9 SG14 SG37 SL21
Fragmento S2 Beech B007 Howe Susan Ford David Ann White IName Lee Brand B003 B005 branchNo fName john julie Mary staffNo
SL41 SG5 SA9 SG14 SG37 SU1
Figura 22.10.
Fragmentación
vertical de 8taff.
•
Completud. Cada atributo de la relación
•
Reconstrucción. La relación Staff puede reconstruirse a partir de dos fragmentos utilizando la operación de combinación natural: S, WS2
•
Disyunción.
Staff
aparece en el fragmento
SI
o
S2·
= Staff
Los fragmentos son disjuntos, salvo por la clave principal, que es necesaria para la
reconstrucción.
~
Los fragmentos verticales se determinan estableciendo la afinidad de un atributo con otro. Una forma de hacer esto es crear una matriz que muestre el número de acceso que se refiere a cada pareja de atributos. Por ejemplo, una transacción que acceda a los atributos al' a2 Y a4 de la relación R con atributos (al, a2, a3, a4) puede representarse mediante la siguiente matriz: al
al a2 a3
a2
a3
a4
l
O
l
O
l O
a4
La matriz es triangular; no es necesario rellenar la diagonal, ya que la mitad inferior es una imagen especular de la superior. Los unos representan un acceso que implica la correspondiente pareja de atributos, y se los puede reemplazar por números que representen la frecuencia de la transacción. Hay que crear una matriz para cada transacción y luego generar una matriz global que muestre la suma de todos los accesos para cada pareja de atributos. Las parejas con una alta afinidad deben aparecer en el mismo fragmento vertical; las parejas con baja afinidad pueden separarse. Claramente, si trabajamos con atributos individuales y con todas las transacciones principales, los cálculos pueden ser muy engorrosos. Por tanto, si se conoce que algunos atributos están relacionados, puede que sea mejor trabajar con grupos de atributos. Esta técnica se conoce con el nombre de división y fue propuesta por primera vez por Navathe et al. (1984). Genera un conjunto de fragmentos no solapados, lo que garantiza el cumplimiento de la regla de disfunción anteriormente definida. De hecho, la característica de no solapamiento se aplica únicamente a los atributos que no forman parte de la clave principal. Los campos de la clave principal aparecen en todos los frag-
650 Sistemas de bases de datos mentos, por lo que pueden omitirse del análisis. Para obtener información adicional sobre esta técnica, el lector puede consultar Ozsu y Valduriez (1999).
Fragmentación mixta Para algunas aplicaciones, la fragmentación horizontal o vertical de un esquema de base de datos pueden ser insuficientes por sí mismas para distribuir los datos adecuadamente. En su lugar, puede que se requiera una fragmentación mixta o híbrida. Fragmento mixto
Está compuesto por un fragmento horizontal que se fragmenta a continuación verticalmente, o por un fragmento vertical que se fragmenta a continuación horizontalmente.
Un fragmento mixto se define utilizando las operaciones de selección y proyección del álgebra relaciona\. Dada una relación R, un fragmento mixto se define como:
o (Da, ..
a/up(R))
donde p es un predicado basado en uno o más atributos de R y al' ... , an son atributos de R.
I
Ejemplo
22.4
Fragmentación
mixta
En el Ejemplo 22.3, hemos fragmentado verticalmente personal, obteniendo: 81:
llstaffNo, position, sex, DOB,
82: IlstaffNo,
fName,
IName,
Staff
para los departamentos
de nóminas y de
sa'ary(Staff)
branchNO(Staff)
Podríamos ahora fragmentar horizontalmente S2 de acuerdo con el número de sucursal (por simplicidad, vamos a suponer que sólo hay tres sucursales): 821: abranchNo
=
'B003,(82)
822:
=
'8005,(82)
=
'8007'(82)
(TbranchNo
823: abranchNo
Fragmento 51
Fragmento
DOSAssistant staffNo24-Mar-S8 19-Feb-70 M 1-0ct-4S 1O-Nov-60 F 18000 9000 13-Jun-6S 30000 12000 sex 3-Jun-4024000 Supervisor salary Manager position
staffNo
522
BOOS Lee White branchNo fName Julie John IName
SL41 SL21
Fragmento staffNo
523
B007 Howe IName fName branchNo Mary
SA9
Fragmento 521 staffNo B003 Beech IName Susan branchNo fName Ford Brand Ann David SGS SG14 SG37
Figura 22.11.
Fragmentación
mixta de Staff.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
651
Esto produce tres fragmentos (S21, S22 y S23), uno de ellos compuesto por tuplas para las que el número de sucursal es B003 (S21), otro compuesto de aquellas tuplas en las que el número de sucursal es B005 (S22) Y el otro compuesto de aquellas tuplas en las que el número de sucursal es B007 (S23)' como muestra la Figura 22.11. El esquema de fragmentación satisface las reglas de corrección: •
Completud. Cada atributo de la relación Staff aparece en los fragmentos SI o en los fragmentos cada tupla aparece (parcialmente) en el fragmento SI y en uno de los fragmentos S21, S22 o S23'
•
Reconstrucción. La relación Staff puede reconstruirse a partir de los fragmentos utilizando las' operaciones de unión y de combinación natural: S, [Xl
•
(S21 U S22 u Sd
S2;
= Staff
Disyunción. Los fragmentos son disjuntos; no puede haber ningún empleado que trabaje en más de una sucursal y
Fragmentación
SI
Y S2 son disjuntos, salvo por la necesaria duplicación de la clave prinCiPal.~
horizontal
derivada
Algunas aplicaciones pueden implicar una combinación de dos o más relaciones. Si las relaciones están almacenadas en diferentes ubicaciones, puede haber una significativa cantidad de procesamiento extra debido a la combinación. En tales casos, puede ser más apropiado garantizar que las relaciones, o fragmentos de relaciones, se encuentren en la misma ubicación. Podemos conseguir esto mediante la fragmentación horizontal derivada. Fragmento derivado
Un fragmento horizontal relación padre.
que está basado en la fragmentación
horizontal
de una
Utilizamos el término hija para referimos a la relación que contiene la clave externa y padre para hacer referencia a la relación que contiene una clave principal de destino. La fragmentación derivada se define utilizando la operación de semicombinación del álgebra relacional (véase la Sección 4.1.3). Dada una relación hija R y otra padre s, la fragmentación derivada de R se define como:
donde w es el número de fragmentos horizontales definidos sobre S y f es el atributo de combinación.
I
Ejemplo 22.5 Fragmentación
horizontal
derivada
Podemos tener una aplicación que combine las relaciones Staff y PropertyForRent. Para este ejemplo, vamos a asumir que Staff está fragmentada horizontalmente de acuerdo con el número de sucursal, de modo que los datos relativos a la sucursal se almacenan localmente: S3 = (TbranchNo = 'B003,(Staff) S4 = (TbranchNo = 'Boos,(Staff) S5 = (TbranchNo = 'BOO7'(Staff)
Vamos a asumir también que el inmueble PG4 está siendo gestionado actualmente por SG 14. Sería útil almacenar los datos de los inmuebles utilizando la misma estrategia de fragmentación. Esto se consigue empleando la fragmentación derivada para fragmentar horizontalmente la relación PropertyForRent de acuerdo con el número de sucursal: p¡ =
PropertyForRent
bs1af1NO S¡
3$
i$ 5
Esto produce tres fragmentos (P3, P4 Y ps), uno compuesto por los inmuebles gestionados por los empleados de la sucursal número B003 (P3), otro compuesto por los inmuebles gestionados por los empleados de la sucursal B005 (P4) y el otro compuesto de los inmuebles gestionados por el per-
652
Sistemas de bases de datos
Fragmento P3 rent C093SG14 C087SG37 C093SG37 C040 6005 Rd 4450 3375 3350 G129AX G12 SG14 Flat House 52street 618 Novar ManorRd Lawrence Dale Dr St propertyNo ownerNo rooms staffNo G324QX G119QX postcode type city Glasgow
Fragmento P4 rent C087SL41 ownerNo rooms staffNo 4400 NW2 Flat London propertyNo postcode type city 6street Argyll St
Fragmento Ps rent C046SA9 6650 16 Holhead AB75SU House Aberdeen ownerNo rooms staffNo street propertyNo postcode type cíty
Figura 22.12.
Fragmentación
derivada de PropertyForRent
basada en Staff.
sonal de la sucursal B007 (ps), como se muestra en la Figura 22.12. Podemos ver fácilmente que este esquema de fragmentación satisface las reglas de corrección. Dejamos esto como ejercicio para el lector. Si una relación contiene más de una clave externa, será necesario seleccionar como padre una de las relaciones referenciadas. La elección puede estar basada en la fragmentación que se utilice más frecuentemente o en la fragmentación que exhiba mejores características de combinación, es decir, la combinación que implique fragmentos más pequeños o la combinación que pueda llevarse a cabo con un mayor grado de paralelismo.
~
Sin fragmentación Una última estrategia consiste en no fragmentar una relación. Por ejemplo, la relación Branch contiene sólo un pequeño número de tuplas y no se actualiza muy frecuentemente. En lugar de tratar de fragmentar horizontalmente la relación de acuerdo con, por ejemplo, el número de sucursal, sería más lógico conservar la relación completa y simplemente replicada en cada uno de los nodos.
Resumen de la metodología
de diseño de una base de datos distribuida
Ahora podemos presentar una metodología resumida para el diseño de bases de datos distribuidas. (1) Utilizar la metodología descrita en los Capítulos 15 y 16 para obtener un diseño de las tablas globales. (2) Adicionalmente, examinar la topología del sistema. Por ejemplo, considerar si DreamHome tendrá una base de datos en cada sucursal, o en cada ciudad, o posiblemente a nivel regional. En el primer caso, puede que resulte apropiado fragmentar las tablas de acuerdo con el número de sucursal. Sin embargo, en los últimos dos casos, sería quizá más apropiado tratar de fragmentar las tablas según la ciudad o la región. (3) Analizar las transacciones más importantes del sistema e identificar si conviene utilizar fragmentación horizontal o vertical. (4) Decidir qué tablas no hay que fragmentar; estas tablas serán replicadas en todos los nodos. A partir del diagrama ER global, eliminar las tablas que no vayan a ser fragmentadas y todas las relaciones en las que estas transacciones están implicadas. (5) Examinar las tablas que se encuentren en el lado uno de una relación y decidir un esquema de fragmentación adecuado para estas tablas, tomando en consideración la topología del sistema. Las tablas
Capítulo 22
correspondientes derivada.
Bases de datos distribuidas:
conceptos y diseño
653
aliado muchos de una relación pueden ser candidatas para aplicar una fragmentación
(6) Durante el paso anterior, comprobar si hay situaciones en las que sería apropiado utilizar fragmentación vertical o mixta (es decir, cuando haya transacciones que requieran acceder a un subconjunto de los atributos de una tabla).
22.5 Transparencia en un SGBDD La definición de SGBDD dada en la Sección 22.1.1 afirma que el sistema debe hacer que la distribución sea transparente para el usuario. La transparencia oculta al usuario los detalles de implementación. Por ejemplo, en un SGBD centralizado, la independencia de los datos es una forma de transparencia: oculta al usuario los cambios en la definición y organización de los datos. Un SGBDD puede proporcionar distintos niveles de transparencia. Sin embargo, todos esos tipos de transparencia tienen el mismo objetivo global: hacer que el uso de una base de datos distribuida sea equivalente al de una base de datos centralizada. Podemos identificar cuatro tipos principales de transparencia en un SGBDD: •
transparencia de distribución;
•
transparencia de transacción;
•
transparencia de rendimiento;
•
transparencia de SGBD.
Antes de hablar de cada uno de estos tipos de transparencias, conviene resaltar que la transparencia completa no es un objetivo universalmente aceptado. Por ejemplo, Gray (1989) argumenta que una transparencia completa hace que la gestión de los datos distribuidos sea muy dificil y que las aplicaciones codificadas con acceso transparente a bases de datos geográficamente distribuidas tienen limitadas posibilidades de gestión, pobre modularidad y un bajo rendimiento en lo que al intercambio de mensajes se refiere. Observe también que sólo en muy raras ocasiones ofrecen los sistemas todos los tipos de transparencia mencionados.
22.5.1 Transparencia de distribución La transparencia de distribución permite al usuario percibir la base de datos como una única entidad lógica. Si un SGBDD exhibe transparencia de distribución, entonces el usuario no necesita saber que los datos están fragmentados (transparencia de fragmentación) o la ubicación de los elementos de datos (transparencia de ubicación). Si el usuario necesita saber que los datos están fragmentados y cuál es la ubicación de los fragmentos, denominamos a esta situación transparencia de asignación local. Estas transparencias están ordenadas, como ahora veremos. Para ilustrar estos conceptos, vamos a considerar la distribución de la relación 81aff dada en el Ejemplo 22.4, de forma tal que: 81:
IlstaffNo, poslt;on, sex,
82: ITstaffNo,
fName,
salarl8laff)
ubicada en el nodo 5
Staff)
'8003,(S2) ubicada en el nodo 3 '8005,(S2) ubicada en el nodo 5 (J"branchNo = '8007'(S2) ubicada en el nodo 7
821:
(J"branchNo
=
822:
(J"branchNo
=
823:
DOS,
IName, branChNO(
Transparencia de fragmentación La fragmentación es el nivel más alto de transparencia de distribución. Si la transparencia de fragmentación es proporcionada por el SGBDD, entonces el usuario no necesita saber que los datos están fragmentados. Como resultado, los accesos a la base de datos se basan en el esquema global, de modo que el usuario no necesita especificar nombres de fragmentos ni ubicaciones de los datos. Por ejemplo, para extraer los nombres de todos los empleados con categoría Manager, si existe transparencia de fragmentación escribiríamos:
654
Sistemas de bases de datos
SELECT fName, FROM 8taff WHERE
IName
position =
'Manager';
Ésta es la misma instrucción SQL que escribiríamos en un sistema centralizado.
Transparencia de ubicación La transparencia de ubicación es el nivel intermedio de la transparencia de distribución. Con la transparencia de ubicación, el usuario debe conocer cómo han sido fragmentados los datos, pero puede ignorar cuál es la ubicación de esos datos. La consulta anterior, si existe transparencia de ubicación, quedaría: SELECT fName, FROM821 WHERE staffNo SELECT fName, FROM 822 WHERE staffNo SELECT fName, FROM 823 WHERE staffNo
IName
IN
(SELECT
staffNo
FROM
81
WHERE
position =
'Manager')
UNION
staffNo
FROM
81
WHERE
position =
'Manager')
UNION
staffNo
FROM
81
WHERE
position =
'Manager');
IName
IN
(SELECT
IName
IN
(SELECT
Ahora tenemos que especificar los nombres de los fragmentos en la consulta. También tenemos que usar una combinación (o subconsulta), ya que los atributos position y fName/IName aparecen en diferentes fragmentos verticales. La principal ventaja de la transparencia de ubicación es que puede reorganizarse físicamente la base de datos sin que ello afecte a los programas de aplicación que acceden a la misma.
Transparencia de replicación Estrechamente relacionada con la transparencia de ubicación está la transparencia de replicación, que quiere decir que el usuario no es consciente de la replicación de los fragmentos. La transparencia de replicación está implícita en la transparencia de ubicación. Sin embargo, es posible que un sistema no tenga transparencia de ubicación y sí que la tenga de replicación.
Transparencia de asignación local Este es el nivel inferior de transparencia de distribución. Con la transparencia de asignación local, el usuario necesita especificar tanto los nombres de los fragmentos como la ubicación de los elementos de datos, tomando en consideración los mecanismos de replicación que puedan existir. Nuestra consulta de ejemplo, si existe transparencia de asignación local, quedaría: SELECT fName, IName FROM 821 AT SITE 3 WHERE staffNo IN (SELECT SELECT fName, IName FROM 822 AT SITE 5 WHERE staffNo IN (SELECT SELECT fName, IName FROM 823 AT SITE 7 WHERE
staffNo IN
(SELECT
staffNo
FROM
81 AT SITE 5
WHERE
position =
'Manager')
UNION
staffNo
FROM
81 AT SITE 5
WHERE
position =
'Manager')
UNION
staffNo
FROM
81 AT SITE 5
WHERE
position =
'Manager');
Para propósitos de ilustración, hemos extendido SQL con la palabra clave AT SITE para expresar el nodo en el que un fragmento concreto está ubicado. Obviamente, esta consulta es más compleja y se tarda más tiempo en escribirla que las dos consultas anteriores. No resulta muy probable que un sistema que proporcione sólo este nivel de transparencia sea aceptable para los usuarios finales.
Capítulo 22 Bases de datos distribuidas: conceptos y diseño
655
Transparencia de denominación Como corolario de los tipos mencionados de transparencias de distribución, tenemos la denominada transparencia de denominación. Al igual que en una base de datos centralizada, cada elemento de una base de datos distribuida debe tener un nombre uní vaca. Por tanto, el SGBDD debe garantizar que dos nadas no creen un objeto de base de datos que tenga el mismo nombre. Una solución a este problema consiste en crear un servidor de nombres centralizado, que tenga la responsabilidad de garantizar la unicidad de todos los nombres del sistema. Sin embargo, este enfoque da como resultado: •
una pérdida de un cierto grado de autonomía local;
•
problemas de rendimiento, si el nodo central se convierte en un cuello de botella;
•
baja disponibilidad; si falla el nodo central, los nadas restantes no pueden crear nuevos objetos de base de datos.
Una solución alternativa consiste en añadir como prefijo a cada objeto el identificador del nodo que lo ha creado. Por ejemplo, la relación Branch creada en el nodo SI puede denominarse S1.Branch. De forma similar, tenemos que poder identificar cada fragmento y cada una de sus copias. Así, la copia 2 del fragmento 3 de la relación Branch creada en el nodo SI puede denominarse S1.Branch.F3.C2. Sin embargo, esto hace que perdamos la transparencia de distribución. Una técnica que resuelve los problemas de estas dos soluciones consiste en utilizar alias (algunas veces denominados sinónimos) para cada objeto de base de datos. Así, S1.Branch.F3.C2 podría ser denominada LocalBranchpor los usuarios del nodo SI. El SGBDD tiene la responsabilidad de establecer la correspondencia entre un alias y el objeto de base de datos apropiado. El sistema distribuido R * distingue entre el nombre imprimible de un objeto y su nombre del sistema. El nombre imprimible es el nombre que los usuarios emplean normalmente para referirse al objeto. El nombre del sistema es un identificador interno globalmente unívoco para el objeto, identificador que el sistema garantiza que nunca será modificado. El nombre del objeto en el sistema está formado por cuatro componentes: •
ID del creador: un identificador unívoco dentro del nodo, asignado al usuario que creó el objeto;
•
Identificador fue creado;
•
Nombre local: un nombre no cualificado para el objeto;
•
ID del nodo de creación: un identificador globalmente unívoco para el nodo en el que el objeto fue inicialmente almacenado (como hemos explicado para el catálogo global del sistema en la Sección 22.3.4).
de nodo creador: un identificador globalmente unívoco para el nodo en el que el objeto
Por ejemplo, el nombre del sistema: [email protected]@Glasgow representa un objeto con nombre local LocalBranch, creado por el usuario Manager en el nodo de Londres y almacenado inicialmente en el nodo de Glasgow.
22.5.2 Transparencia de transacción La transparencia de transacción en un entorno SGBDD garantiza que todas las transacciones distribuidas mantengan la integridad y coherencia de la base de datos distribuida. Una transacción distribuida accede a datos almacenados en más de una ubicación. Cada transacción está dividida en una serie de subtransacciones, una por cada nodo al que haya que acceder; cada transacción está representada por un agente, como se ilustra en el siguiente ejemplo.
I
Ejemplo 22.6 Transacción distribuida Considere una transacción T que imprime los nombres de todos los nombres de todos los empleados, utilizando el esquema de fragmentación definida anteriormente compuesta por SI' S2, S21, S22y S23.
656
Sistemas de bases de datos
Podemos definir tres subtransacciones Ts" Ts, Y Ts, para representar los agentes en los nodos 3, 5 Y 7, respectivamente. Cada subtransacción imprime los nombres de los empleados de su correspondiente nodo. La transacción distribuida se muestra en la Figura 22.13. Observe el paralelismo inherente al sistema: las subtransacciones de cada nodo pueden ejecutarse concurrentemente. Tiempo
Ts, begin_transaction
begin_transaction
begin_transaction
read(fName, lName)
read(fName, lName)
read(fName, lName)
print(fName, lName)
print(fName, lName)
print(fName, lName)
end_transaction
end_transaction
Figura 22.13.
end_transaction
Transacción distribuida.
La atomicidad de la transacción distribuida sigue siendo fundamental para el concepto de transacción, pero además, el SGBDD debe garantizar también la atomicidad de cada subtransacción (véase la Sección 20.1.1). Por tanto, no sólo debe el SGBDD garantizar ]a sincronización de las subtransacciones con las otras transacciones locales que se estén ejecutando concurrentemente en cada nodo, sino que también debe garantizar la sincronización de las subtransacciones con las transacciones globales que se estén ejecutando simultáneamente en el mismo o en diferentes nodos. La transparencia de transacción en un SGBD distribuido se complica debido a los esquemas de fragmentación, de asignación y de replicación. Vamos a considerar dos aspectos adicionales de la transparencia de transacción: transparencia de concurrencia y transparencia de fallos.
Transparencia de concurrencia Decimos que el SGBDD proporciona transparencia de concurrencia si los resultados de todas las transacciones concurrentes (distribuidas y no distribuidas) se obtienen independientemente y son lógicamente coherentes con los resultados que se obtendrían si las transacciones se ejecutaran de una en una, en alguna secuencia serie arbitraria. Estos son los mismo principios fundamentales que ya hemos explicado para los SGBD centralizados en la Sección 20.2.2. Sin embargo, existe la complejidad añadida de que el SGBDD debe garantizar que las transacciones tanto globales como locales no interfieran entre sí. De forma similar, el SGBDD debe garantizar la coherencia de todas las subtransacciones de la transacción global. La replicación hace que el problema de la concurrencia sea todavía más complejo. Si se actualiza una copia de un elemento de datos replicado, dicha actualización deberá propagarse antes o después a todas las copias. Una estrategia obvia consiste en propagar los cambios como parte de la transacción original, haciendo que sea una operación atómica. Sin embargo, si no se puede alcanzar uno de los nodos que almacenan una copia en el momento de procesar la actualización, porque haya fallado el nodo o el enlace de comunicaciones, entonces la transacción completa se verá retardada hasta que el nodo vuelva a ser alcanzable. Si hay muchas copias del elemento de datos, la probabilidad de que la transacción tenga éxito decrece exponencialmente. Una estrategia alternativa consiste en limitar la propagación de la actualización exclusivamente a aquellos nodos que estén actualmente disponibles. Los nodos restantes deberán ser actualizados cuando vuelvan a estar disponibles. Otra estrategia alternativa sería permitir que las actualizaciones de las copias se realicen asincronamente, en algún momento posterior a la actualización original. El retardo necesario para volver a restaurar ]a coherencia puede ir desde unos pocos segundos a varias horas. En el siguiente capítulo hablaremos de cómo gestionar correctamente el control de concurrencia distribuido y la replicación.
Transparencia de fallos En la Sección 20.3.2 hemos dicho que un SGBD centralizado debe proporcionar un mecanismo de recuperación que garantice que las transacciones sean atómicas en presencia de fallos: o bien se llevan a cabo todas las operaciones de la transacción, o no se lleva a cabo ninguna. Además, en cuanto una transacción haya confirmado los cambios, estos cambios serán duraderos. También hemos examinado los tipos de fallos que pue-
Capítulo 22 Bases de datos distribuidas:
conceptos y diseño
657
den producirse en un sistema centralizado, como por ejemplo la parada catastrófica de un sistema, el fallo de un soporte de almacenamiento, errores del software, descuidos, desastres físicos naturales y sabotajes. En un entorno distribuido, el SGBDD deberá tener además en cuenta: • •
la pérdida de mensajes; el fallo de un enlace de comunicaciones;
•
el fallo de un nodo;
•
el particionamiento
de la red.
El SGBDD debe garantizar la atomicidad de la transacción global, lo que quiere decir garantizar que todas las subtransacciones de la transacción global se confirmen, o que todas se aborten. Por tanto, el SGBDD deberá sincronizar la transacción global para garantizar que todas las subtransacciones se hayan completado con éxito antes de registrar la operación COMMIT final para la transacción global. Por ejemplo, considere una transacción global que tenga que actualizar datos en dos nadas, por ejemplo SI y S2' Suponga que la subtransacción del nodo SI se completa con éxito y se confirma, pero que la subtransacción del nodo Sl no puede confirmar las operaciones y deshace los cambios, con el fin de mantener la coherencia local. La base de datos distribuida estará ahora en un estado incoherente: no podemos desconfirmar los datos del nodo SI' debido a la propiedad de durabilidad de la subtransacción de SI' Hablaremos de cómo gestionar correctamente los mecanismos de recuperación de bases de datos distribuidas en el siguiente capítulo.
Clasificación
de las transacciones
Antes de completar nuestro análisis de las transacciones en este capítulo, vamos a presentar brevemente una clasificación de las transacciones definida en la arquitectura DRDA (Distributed Relational Database Architecture) de IBM. En DRDA, hay cuatro tipos de transacciones, con un nivel progresivo de complejidad en la interacción entre los distintos SGBD: (1) solicitud remota; (2) unidad de trabajo remota; (3) unidad de trabajo distribuida; (4) solicitud distribuida. En este contexto, una 'solicitud' es equivalente a una instrucción SQL y una 'unidad de trabajo' es una transacción. Los cuatro niveles están ilustrados en la Figura 22.14. (1) Solicitud remota. Una aplicación en un nodo puede enviar una solicitud (instrucción SQL) a otro nodo remoto para su ejecución. La solicitud se ejecuta por entero en el nodo remoto y puede hacer referencia exclusivamente a datos que se encuentren en el nodo remoto. (2) Unidad de trabajo remota. Una aplicación en un nodo (local) puede enviar todas las instrucciones SQL de una unidad de trabajo (transacción) a algún nodo remoto para su ejecución. Todas las instrucciones SQL se ejecutan enteramente en el nodo remoto y sólo pueden hacer referencia a datos que se encuentren en el nodo remoto. Sin embargo, es el nodo local quien decide si la transacción debe confirmarse o anularse. (3) Unidad de trabajo distribuida. Una aplicación en un nodo (local) puede enviar parte o todas las instrucciones SQL de una transacción a uno o más nadas remotos para su ejecución. Cada instrucción SQL se ejecuta enteramente en el nodo remoto y sólo puede hacer referencia a datos que se encuentren en dicho nodo. Sin embargo, las diferentes instrucciones SQL pueden ejecutarse en nadas distintos. De nuevo, es el sitio local quien decide si hay que confirmar o anular la transacción. (4) Solicitud distribuida. Una aplicación en un SQL de una transacción a uno o más nadas SQL puede requerir acceder a datos de más sitar combinar o unir relaciones/fragmentos
nodo (local) puede enviar parte o todas las instrucciones remotos para su ejecución. Sin embargo, una instrucción de un nodo (por ejemplo, la instrucción SQL puede neceubicados en diferentes nadas).
658
Sistemas de bases de datos
Staff Staff UPDATE
SELECT* FROM Staff WHERE
salary
PropertyForRent Staff
SET salary = salary*1.05; UPDATE PropertyForRent SET rent = rent*1.06; COMMIT;
> 20000
(a)
(b)
Staff
Staff UPDATE
UPDATE
Staff
Staff
SET salary = salary*1.05; UPDATE PropertyForRent SET rent = rent*1.06; SELECT *
SET salary = salary*1.05; UPDATE PropertyForRen SET rent = rent*1.06; COMMIT;
FROM Staff s, PropertyForRent WHERE s.staffNo = pfr.staffNo; COMMIT;
pfr
PropertyForRent
PropertyForRent
(e)
Figura 22.14.
(d)
Clasificación DRDA de las transacciones: (a) solicitud remota; (b) unidad de trabajo remota; (c) unidad de trabajo distribuida; (d) solicitud distribuida.
22.5.3 Transparencia de rendimiento La transparencia de rendimiento requiere que el SGBDD tenga unas prestaciones equivalentes al caso de que se tratara de un SGBDD centralizado. En un entorno distribuido, el sistema no debe sufrir una degradación de rendimiento debido a la arquitectura distribuida, por ejemplo a la presencia de la red. La transparencia de rendimiento también requiere que el SGBDD determine la estrategia más eficiente para ejecutar cada solicitud. En un SGBDD centralizado, el procesador de consultas debe evaluar todas las solicitudes de datos y encontrar una estrategia de ejecución óptima, compuesta por una secuencia ordenada de operaciones sobre la base de datos. En un entorno distribuido, el procesador de consultas distribuido hace corresponder a cada solicitud de datos una secuencia ordenada de operaciones sobre las bases de datos locales. Tiene la complejidad añadida de tener en cuenta los sistemas de fragmentación, replicación y asignación. El procesador de consultas distribuidas tiene que decidir; •
a qué fragmentos acceder;
•
qué copia de cada fragmento utilizar, si el fragmento está replicado;
•
qué indicación emplear.
El procesador de consultas distribuidas genera una estrategia de ejecución que está optimizada con respecto a alguna función de coste. Normalmente, los costes asociados con una solicitud distribuida incluyen: •
el tiempo de acceso (E/S) requerido para acceder a los datos fisicos en disco;
•
el tiempo de procesador necesario para efectuar operaciones sobre los datos contenidos en la memoria principal; los costes de comunicaciones asociados con la transmisión de los datos a través de la red.
•
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
659
Los primeros dos factores son los únicos que se consideran en un sistema centralizado. En un entorno distribuido, el SGBDD debe tener en cuenta los costes de comunicaciones, que pueden ser el factor dominante en las redes WAN que tengan un ancho de banda de unos pocos kilobytes por segundo. En tales casos, la estrategia de optimización puede ignorar los costes de E/S y de procesador. Sin embargo, las redes LAN tienen un ancho de banda comparable al de los discos, por lo que en tales casos los procedimientos de utilización no deben ignorar por completo los costes de E/S y de procesador. Una técnica para la optimización de consultas consiste en minimizar el tiempo total necesario para ejecutar la consulta (Sacco y Yao, 1982). Otra técnica alternativa lo que hace es minimizar el tiempo de respuesta de la consulta, en cuyo caso el procesador de consultas distribuido trata de maximizar la ejecución paralela de las operaciones (Epstein et al., 1978). En ocasiones, el tiempo de respuesta será significativamente inferior al tiempo total. El siguiente ejemplo, adaptado de Rothnie y Goodman (1977), ilustra la amplia variación en tiempos de respuesta que puede surgir debido a la adopción de estrategias de ejecución diferentes, pero plausibles.
I
Ejemplo 22.7 Procesamiento
de consultas
distribuidas
Considere un esquema relacional simplificado para DreamHome relaciones: Property(propertyNo,
10000 registros almacenados en Londres 100000 registros almacenados en Glasgow 1000000 registros almacenados en Londres
city)
Client(c1ientNo, maxPrice) Viewing(propertyNo,
compuesto por las siguientes tres
clientNo)
Para enumerar los inmuebles de Aberdeen que han sido vistos por clientes que hayan indicado un límite de precio máximo superior a 200.000 euros, podemos utilizar la siguiente consulta SQL: SELECT p.propertyNo FROM Property p INNER JOIN (Client e INNER JOIN Viewing ON p.propertyNo
WHERE
v
ON
c.c1ientNo = v.c1ientNo)
= v.propertyNo
p.city = 'Aberdeen'
AND
c.maxPrice
> 200000;
Por s~mplicidad, suponga que cada tupla de cada relación tiene 100 caracteres de longitud, suponga también que hay 10 clientes con un precio máximo superior a 200.000 euros, que hay 100000 visitas a inmueb1es en Aberdeen y que el tiempo de procesamiento es despreciable comparado con el tiempo de comunicación. Vamos a suponer también que el sistema de comunicaciones tiene una velocidad de transmisión de datos igual a 10000 caracteres por segundo y un retardo de acceso de un segundo para enviar un mensaje de un nodo a otro. Rothnie identifica seis posibles estrategias para esta consulta, como se resume en la Tabla 22.4. Utilizando el algoritmo para cálculo del tiempo de comunicación que hemos enunciado en la Sección 22.2, podemos calcular los tiempos de respuesta de estas estrategias de la forma siguiente: Estrategia 1.
Mover la relación
Client
a Londres y procesar la consulta allí:
Tiempo =1 + (100000 * 100/10000) Estrategia 2.
Mover las relaciones
Property
y
Viewing
==
16,7 minutos
a Glasgow y procesar la consulta allí:
Tiempo =2 + [(1000000 + 10000) * 100/10000] Estrategia 3.
==
28 horas
Combinar las relaciones Property y Viewing en Londres, seleccionar las tuplas relativas a inmueble s de Aberdeen y luego, para cada una de estas tuplas, enviarlas por turno a Glasgow para determinar si maxPrice > 200.000 euros para el cliente asociado. La comprobación requerida para cada tupla necesita dos mensajes: una consulta y una respuesta.
660
Sistemas de bases de datos Tabla 22.4.
Comparación
de estrategias de procesamiento
de una consulta distribuida.
Estrategia
Tiempo
(1)
Mover la relación Client a Londres y procesar la consulta alIí
16,7 minutos
(2)
Mover las relaciones Property y Viewinga Glasgow y procesar la consulta alIí
28 horas
(3)
Combinar las relacíones Property y Viewingen Londres, seleccionar las tuplas relativas a inmuebles de Aberdeen y luego, para cada una de estas tuplas, enviarlas por turno a G1asgowpara determinar si maxPrice > 200.000 euros para el cliente asociado
2,3 días
(4)
Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y, para cada 20 segundos cliente que se haya encontrado, comprobar en Londres si hay una visita de ese cliente a un inmueble de Aberdeen
(5)
Combinar las relaciones Property y Viewingen Londres, seleccionar los inmue- 16,7 minutos bles de Aberdeen, proyectar los resultados sobre propertyNoy c1ientNoy mover este resultado a Glasgow para efectuar la comprobación maxPrice > 200.000 euros
(6)
Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y mover el resultado a Londres para efectuar la correspondencia con los inmuebles de Aberdeen
l segundo
Tiempo =100000 * (1 + 100/10000) + 100000 * 1 == 2,3 días Estrategia 4.
Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y, para cada cliente que se haya encontrado, comprobar en Londres si hay una visita de ese cliente a un inmueble de Aberdeen. De nuevo, son necesarios dos mensajes: Tiempo = 1O * (1 + 100/1 0000) + 10* 1 == 20 segundos
Estrategia 5.
Combinar las relaciones Property y Viewingen Londres, seleccionar los inmuebles de Aberdeen, proyectar los resultados sobre propertyNoy clientNoy mover este resultado a Glasgow para efectuar la comprobación maxPrice > 200.000 euros. Por simplicidad, asumimos que el resultado proyectado sigue teniendo 100 caracteres de longitud: Tiempo =1 + (100000 * 100/10000)
Estrategia 6.
==
16,7 minutos
Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y mover el resultado a Londres para efectuar la correspondencia con los inmuebles de Aberdeen: Tiempo = 1 + (10 * 100/1 0000)
==
1 segundo
El tiempo de respuesta varía de 1 segundo a 2,3 días, aunque todas las estrategias constituyen una forma legítima de ejecutar la consulta. Claramente, si se elige la estrategia incorrecta, el efecto sobre el rendimiento del sistema puede ser devastador. Hablaremos más en detalle del procesamiento de consultas distribuidas en la Sección 23.6.
-.-J
22.5.4 Transparencia de SGBD La transparencia de SGBD oculta el hecho de que los SGBD locales puedan ser diferentes, por lo que este tipo de transparencia sólo es aplicable a los SGBDD heterogéneos. Es uno de los tipos de transparencia más difíciles de proporcionar. Hemos hablado de los problemas asociados con la provisión de servicios de base de datos sobre sistemas heterogéneos en la Sección 22.1.3.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
661
22.5.5 Resumen de los conceptos de transparencia en un SGBDD Al principio de esta sección dedicada al concepto de transparencia en un SGBDD hemos mencionado que el objetivo de conseguir una transparencia completa no es universalmente aceptado. Como hemos visto, el concepto de transparencia no es un concepto de 'todo o nada', sino que puede proporcionarse transparencia a diferentes niveles. Cada nivel requiere un tipo concreto de acuerdo entre los nadas participantes. Por ejemplo, con una transparencia completa, los nadas deben ponerse de acuerdo en cosas tales como el modelo de datos, la interpretación de los esquemas, la representación de los datos y la funcionalidad proporcionada por cada nodo. En el otro extremo del espectro, en un sistema no transparente, sólo existe acuerdo sobre el formato de intercambio de los datos y la funcionalidad proporcionada por cada nodo. Desde la perspectiva del usuario, la transparencia completa es altamente deseable. Sin embargo, desde la perspectiva del DBA local, un acceso completamente transparente puede resultar dificil de controlar. Como un mecanismo de seguridad, la facilidad tradicional de vistas puede no ser lo suficientemente potente como para proporcionar una adecuada protección. Por ejemplo, el mecanismo de vistas de SQL permite restringir el acceso a una relación base o a un subconjunto de una relación base a una serie de usuarios, pero no permite restringir fácilmente el acceso basándose en un conjunto de criterios que no estén basados en el nombre del usuario. En el caso de estudio de DreamHome, podemos restringir el acceso de borrado de la relación Lease a una serie de empleados determinados, pero no podemos imponer fácilmente la condición de que un contrato de alquiler no sea borrado si el contrato de alquiler ha finalizado, si todos los pagos pendientes han sido realizados por el inquilino y si el inmueble se encuentra todavía en condiciones satisfactorias. Puede que resulte más fácil proporcionar este tipo de funcionalidad dentro de un procedimiento que se invoque remotamente. De esta forma, los usuarios locales pueden ver los datos que normalmente tienen permitido ver utilizando mecanismos de seguridad estándar del SGBD. Sin embargo, los usuarios remotos sólo verán datos que estarán encapsulados dentro de un conjunto de procedimientos, de forma similar a lo que sucede en un sistema orientado a objetos. Este tipo de arquitectura federada es más simple de implementar que un sistema con transparencia completa, y puede proporcionar un mayor grado de autonomía local.
22.6 Las doce reglas de Date para un SGBDD En esta sección final, vamos a enumerar las doce reglas (u objetivos) de Date para un SGBDD (Date, 1987b). El fundamento de estas reglas es que un SGBDD distribuido debe parecer que no está distribuido a ojos del usuario. Estas reglas son similares a las doce reglas de Codd para los sistemas relacionales que presentamos en el Apéndice D.
Principio fundamental Para el usuario, un sistema distribuido debe parecer exactamente
como si fuera no distribuido.
(1) Autonomía local Los nadas de un sistema distribuido deben ser autónomos. En este contexto, autonomía significa que: •
los datos locales son propiedad local y se gestionan localmente;
•
las operaciones locales siguen siendo puramente locales;
•
todas las operaciones en un nodo concreto son controladas por dicho nodo.
(2) No dependencia de un nodo central No debe haber ningún nodo sin el cual el sistema no pueda operar. Esto implica que no debe haber servidores centralizados para servicios tales como la gestión de transacciones, la detección de interbloqueos, la optimización de consultas y la gestión del catálogo global del sistema.
662
Sistemas de bases de datos
(3) Operación continua Idealmente, nunca debería existir la necesidad de efectuar una detección planificada del sistema para realizar operaciones tales como: • añadir o eliminar un nodo del sistema; •
la creación y borrado de fragmentos dinámicamente en uno o más nodos.
(4) Independencia de ubicación La independencia de ubicación es equivalente a la transparencia de ubicación. El usuario debe poder acceder a la base de datos desde cualquier nodo. Además, el usuario debe poder acceder a todos los datos como si estuvieran almacenados en el nodo del usuario, independientemente de dónde estén físicamente almacenados.
(5) Independencia de fragmentación El usuario debe poder acceder a los datos con independencia de cómo estén fragmentados.
(6) Independencia de replicación El usuario no debe ser consciente de que los datos han sido replicados. Así, el usuario no debe poder acceder a una copia concreta de un elemento de datos directamente, ni tampoco debe tener que actualizar específicamente todas las copias de un elemento de datos.
(7) Procesamiento de consultas distribuidas El sistema debe ser capaz de procesar consultas que hagan referencia a datos situados en más de un nodo.
(8) Procesamiento de transacciones distribuidas El sistema debe soportar el concepto de transacción como unidad de recuperación. El sistema debe garantizar que las transacciones tanto globales como locales se adapten a las reglas ACID de las transacciones, es decir: atomicidad, coherencia, aislamiento y durabilidad.
(9) Independencia del hardware Debe ser posible ejecutar el SGBDD en una diversidad de plataformas hardware.
(10) Independencia del sistema operativo Como corolario de la regla anterior, debe ser posible ejecutar el SGBDD sobre una diversidad de sistemas operativos
(11) Independencia de la red De nuevo, debe ser posible ejecutar el SGBDD sobre una diversidad de redes de comunicaciones
distintas.
(12) Independencia de la base de datos Debe ser posible tener un SGBDD formado por diferentes SGBD locales, que quizá soporten diferentes modelos de datos subyacentes. En otras palabras, el sistema debe admitir la heterogeneidad. Las últimas cuatro reglas son ideales. Ya que las reglas son tan generales, y como hay una falta de estándares en lo que se refiere a las arquitecturas informáticas y de red, cabe esperar que sólo se cumplan estas reglas parcialmente por parte de los fabricantes en el futuro próximo.
Resumen del capítulo •
Una base de datos distribuida es una colección lógicamente interrelacionada de datos compartidos (y una descripción de estos datos), físicamente distribuida en una red informática. El SGBDD es el software que gestiona de manera transparente la base de datos distribuida.
Capítulo 22
Bases de datos distribuidas:
conceptos y diseño
663
•
Un SGBDD es distinto de un sistema de a un SGBD centralizado a través SGBD que se ejecuta sobre múltiples raciones en paralelo siempre que sea
de procesamiento distribuido, que es un sistema en el que se accede una red. También es diferente de un SGBD paralelo, que es un procesadores y discos y que ha sido diseñado para evaluar las opeposible, para así mejorar el rendimiento.
•
Las ventajas de un SGBDD son que refleja mejor la estructura de la organización, que hace que los datos puedan compartirse en mayor medida, que mejora la fiabilidad, la disponibilidad y las prestaci.ones, que puede ser más económico, que permite el crecimiento modular, que facilita la integración y que ayuda a las organizaciones a seguir siendo competitivas. Las principales desventajas son el coste, la complejidad, la falta de estándares y la falta de experiencia.
•
Los SGBDD pueden clasificarse como homogéneos o heterogéneos. En un SGBD homogéneo, todos los nodos utilizan el mismo tipo de SGBD. En un sistema heterogéneo, los nodos pueden ejecutar sistemas SGBD de diferentes fabricantes, los cuales pueden estar basados en modelos de datos distintos, de modo que el sistema pueda estar compuesto de una mezcla de SGBD relacionales, en red, jerárquicos y orientados a objetos.
•
Un sistema multi-base de datos (MDBS) es un SGBD distribuido en el que cada nodo mantiene una completa autonomía. Un MDBS se instala transparentemente por encima de los sistemas de archivos y bases de datos existentes, presentando a los usuarios una única base de datos. Mantiene un esquema global que es el que los usuarios utilizan para realizar las consultas y las actualizaciones. El MDBS se encarga únicamente de mantener el esquema global, mientras que son los SGBD locales los que mantienen los datos de los usuarios.
•
Las comunicaciones tienen lugar a través de una red, que puede ser una red de área local (LAN) o una red de área extensa (WAN). Las redes LAN se suelen utilizar para distancias cortas y proporcionan una comunicación más rápida que las redes WAN. Un caso especial de red WAN es la red de área metropolitana (MAN, metropolitan area network), que generalmente cubre una ciudad o un suburbio.
•
Además de tener la funcionalidad estándar que cabe esperar de un SGBD centralizado, los SGBDD necesitan servicios avanzados de comunicaciones, un catálogo ampliado del sistema, procesamiento distribuido de consultas y servicios avanzados de seguridad, concurrencia y recuperación.
•
Una relación puede dividirse en una serie de subrelaciones denominadas fragmentos, que se asignan a uno o más nodos. Los fragmentos pueden ser replicados para mejorar la disponibilidad y las prestacIOnes.
•
Hay dos tipos principales de fragmentación: horizontal y vertical. Los fragmentos horizontales son subconjuntos de tuplas y los fragmentos verticales son subconjuntos de atributos. Hay otros dos tipos adicionales de fragmentación: mixta y derivada, un tipo de fragmentación horizontal en el que la fragmentación de una relación está basada en la fragmentación de otra relación.
•
La definición y asignación de fragmentos se llevan a cabo estratégicamente para conseguir la localidad de referencia, una mayor fiabilidad y disponibilidad, un rendimiento aceptable, un equilibrio entre la capacidad de almacenamiento y el coste y unos costes de comunicación mínimos. Las tres reglas de corrección aplicables a la fragmentación son: completud, reconstrucción y disyunción.
•
Existen cuatro estrategias de asignación en lo que se refiere a la ubicación de los datos: centralizada (una única base de datos centralizada), fragmentada (se asigna cada fragmento a un nodo), replicación completa (se mantiene una copia completa de la base de datos en cada nodo) y replicación selectiva (combinación de las primeras tres estrategias).
•
El SGBDD debe aparecer como un SGBD centralizado, proporcionando una serie de niveles de transparencia. Con la transparencia de distribución, los usuarios no deben ser conscientes de que los datos han sido fragmentados/replicados. Con la transparencia de transacción, debe mantenerse la coherencia de la base de datos global cuando múltiples usuarios estén accediendo a la base de datos concurrentemente y cuando se produzcan fallos. Con la transparencia de rendimiento, el sistema debe ser capaz de gestionar de manera eficiente las consultas que hagan referencia a datos situados en más de un nodo. Con la transparencia de SGBD, debe ser posible tener sistemas SGBD de diferentes tipos en el sistema.
664
Sistemas de bases de datos
Cuestiones de repaso 22.1.
Explique el concepto de SGBDD y diga cuál es la motivación para proporcionar este tipo de sistemas.
22.2.
Indique las similitudes y diferencias entre un SGBDD y el procesamiento distribuido. ¿En qué circunstancias es preferible un SGBDD a un sistema de procesamiento distribuido?
22.3.
Indique las similitudes y diferencias entre un SGBDD y un SGBD paralelo. ¿En qué circunstancias preferible un SGBDD a un SGBD paralelo?
22.4.
Explique las ventajas y desventajas de un SGBDD.
22.5.
¿Cuál es la diferencia entre un SGBDD homogéneo y otro heterogéneo? len utilizarse ambos tipos de sistemas?
22.6.
¿Cuáles son las principales diferencias entre una LAN y una WAN?
22.7.
¿Qué funcionalidad cabe esperar encontrar en un SGBDD?
22.8.
¿Qué es un sistema multi-base de datos? Describa una arquitectura de referencia para dicho tipo de sistema.
22.9.
Uno de los problemas que afectan a los SGBDD es el diseño de bases de datos distribuidas. Indique los problemas que hay que resolver en el diseño de bases de datos distribuidas. Explique cómo se aplican estas cuestiones al catálogo global del sistema.
¿En qué circunstancias
es
sue-
22.10. ¿Cuáles son los objetivos estratégicos para la definición y asignación de fragmentos? 22.11. Describa diversos esquemas alternativos para fragmentar una relación global. Indique cómo comprobaría la corrección del esquema de fragmentación para garantizar que la base de datos no sufra cambios semánticos durante el proceso de fragmentación. 22.12. ¿Qué niveles de transparencia debe proporcionar un SGBDD? Proporcione ejemplos para ilustrar su respuesta y justifíquela. 22.13. Un SGBDD debe garantizar que no haya dos nodos que creen un objeto de datos con el mismo nombre. Una solución a este problema consiste en disponer de un servidor de nombres centralizado. ¿Cuáles son las desventajas de este enfoque? Proponga un enfoque alternativo que resuelva estas desventajas. 22.14. ¿Cuáles son los cuatro niveles de transacciones definidos en la arquitectura DRDA de IBM? Indique las similitudes y diferencias entre los cuatro niveles. Proporcione ejemplos para ilustrar su respuesta.
Ejercicios Una empresa de ingeniería multinacional ha decidido distribuir su información de gestión de proyectos en el nivel regional dentro de Gran Bretaña. El esquema re1acional centralizado actual es el siguiente:
donde
Employee
(NIN, fName, IName, address, DOB, sex, salary, taxCode, deptNo)
Department
(deotNo, deptName,
managerNIN,
Project
(proiNo, projName,
(NIN, projNo, horasWorked)
Business
(businessAreaNo,
Region
(regionNo,
Employee
contiene detalles de los.empleados y el número de la seguridad social NIN es la clave. contiene detalles de los departamentos y deptNo es la clave. managerNIN identifica el empleado que actúa como gerente del departamento. Sólo hay un gerente en cada departamento. contiene detalles de los proyectos de la empresa y la clave es projNo. El jefe de proyecto se identifica mediante projectManagerNIN y el departamento responsable del proyecto se identifica mediante deptNo.
Project
projectManagerNIN,
regionNo)
WorksOn
Department
contractPrice,
businessAreaNo,
deptNo)
businessAreaName)
regionName)
Capítulo 22
WorksOn Business Region
Bases de datos distribuidas:
conceptos y diseño
665
contiene detalles de las horas que han dedicado los empleados y (NIN, projNo) forma la clave. contiene los nombres de las áreas de negocio y la clave es businessAreaNo. contiene los nombres de las regiones y la clave es regionNo.
Los departamentos están agrupados regionalmente de la forma siguiente: Región 1: Escocia
Región 2: Gales
Región 3: Inglaterra
Se requiere información por área de negocio, lo que cubre: Ingeniería del software, Ingeniería mecánica e Ingeniería eléctrica. No hay Ingeniería del software en Gales y todos departamentos de Ingeniería eléctrica están en Inglaterra. La asignación de personal a los proyectos se hace a partir del personal de los departamentos locales. Además de distribuir los datos regionalmente, hay un requisito adicional, que es que se debe poder acceder a los datos de los empleados bien mediante la información personal (por parte del departamento de recursos humanos) o mediante información relacionada con el trabajo (por parte del departamento de nóminas). 22.15. Dibuje un diagrama de Entidad-Relación
(ER) para representar este sistema.
22.16. Utilizando el diagrama ER del Ejercicio 22.15, realice un diseño de base de datos distribuida para este sistema en el que se incluya: (a)
un esquema de fragmentación
adecuado para el sistema;
(b)
en el caso de una fragmentación horizontal principal, un conjunto mínimo de predicados;
(c)
la reconstrucción de las relaciones globales a partir de los fragmentos.
Indique las suposiciones en las que haya basado su diseño. 22.17. Repita el Ejercicio 22.16 para el caso de estudio de DreamHome documentado en el Apéndice A. 22.18. Repita el Ejercicio 22.16 para el caso de estudio de EasyDrive School 01 Motoring documentado en el Apéndice B.2. 22.19. Repita el Ejercicio 22.16 para el caso de estudio de Wellmeadows documentado en el Apéndice B.3. 22.20. En la Sección 22.5.1, al hablar de la transparencia de nominación, hemos propuesto el uso de alias para identificar de forma unívoca cada réplica de cada fragmento. Realice un esbozo de diseño para la implementación de esta técnica de obtención de la transparencia de denominación. 22.21. Compare un SGBD distribuido al que tenga acceso con las doce reglas enunciadas por Date para los SGBDD. Para cada regla que el sistema no cumpla, indique las razones por las que piensa que el sistema no se adecua a esa regla.
CapítUlo
Bases de datos distribuidas: conceptos avanzados Objetivos del capítulo: En este capítulo aprenderá: •
Cómo afecta la distribución de datos a los componentes de gestión de transacciones.
•
Cómo pueden ampliarse las técnicas de control de concurrencia centralizadas para gestionar la distribución de datos.
• •
Cómo detectar el interbloqueo en los casos en que hay múltiples nodos implicados. Cómo recuperarse de un fallo de la base de datos en un entorno distribuido utilizando: •
confirmación en dos fases (2PC)
•
confirmación en tres fases (3PC).
•
Las dificultades de detectar y mantener la integridad en un entorno distribuido.
•
Algunos conceptos sobre el estándar DTP X/Open.
•
Las técnicas de optimización de consultas distribuidas.
•
La importancia de la operación de semi combinación en los entorno s distribuidos.
•
Cómo gestiona Oracle la distribución de datos.
En el capítulo anterior hemos hablado de los conceptos básicos y de los problemas asociados con los sistemas distribuidos de gestión de bases de datos (SGBDD). Desde la perspectiva del usuario, la funcionalidad ofrecida por un SGBDD es altamente atractiva. Sin embargo, desde la perspectiva de la implementación, los protocolos y algoritmos requeridos para proporcionar esta funcionalidad son bastante complejos y hacen que surjan numerosos problemas que pueden hacer que no merezcan la pena las ventajas ofrecidas por esta tecnología. En este capítulo, continuaremos nuestro análisis de la tecnología de los sistemas SGBDD y examinaremos cómo pueden ampliarse los protocolos de control de concurrencia, de gestión de interbloqueos y de recuperación presentados en el Capítulo 20 para tratar con la distribución de datos y la replicación. Una alternativa, potencialmente más simple, a la distribución de datos es la proporcionada por los servidores de replicación, que gestionan la replicación de datos a nodos remotos. Todos los principales fabricantes de bases de datos disponen de alguna solución de replicación de un tipo u otro y muchos fabricantes de software no especializados en bases de datos ofrecen también métodos alternativos de replicación de los datos. En el capítulo siguiente tomaremos también en cuenta el servidor de replicación como alternativa a un SGBDD.
Estructura del capítulo En la Sección 23.1 se repasan brevemente los objetivos del procesamiento distribuido de transacciones. En la Sección 23.2 se examina cómo afecta la distribución de datos a la definición de serializabilidad proporciona-
668
Sistemas de bases de datos
da en la Sección 20.2.2 y luego se analiza cómo ampliar los protocolos de control de concurrencia presentados en las Secciones 20.2.3 y 20.2.5 a un entorno distribuido. En la Sección 23.3 se examina el incremento de complejidad a la hora de identificar interbloqueos en un SGBD distribuido y se analizan los protocolos de detección de interbloqueos distribuidos. En la Sección 23.4 se examinan los fallos que pueden producirse en un entorno distribuido y se presentan los protocolos que cabe utilizar para garantizar la atomicidad y la durabilidad de las transacciones distribuidas. En la Sección 23.5 se repasa brevemente el modelo X/Open de procesamiento de transacciones distribuidas, que especifica una interfaz de programación para el procesamiento de transacciones. En la Sección 23.6 se proporciona una panorámica de la optimización de consultas distribuidas y en la Sección 23.7 veremos cómo gestiona Oracle la distribución. De nuevo, los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 y en el ApéndiceA.
23.1 Gestión de transacciones distribuidas En la Sección 22.5.2 ya hemos indicado que los objetivos del procesamiento distribuido de transacciones son los mismos que en los sistemas centralizados, aunque resultan más complejos debido a que el SGBDD debe también garantizar la atomicidad de la transacción global, además de la de cada subtransacción componente. En la Sección 20.1.2 hemos identificado cuatro módulos de base de datos de alto nivel encargados de gestionar las transacciones, el control de concurrencia y la recuperación en un SGBD centralizado. El gestor de transacciones coordina las transacciones por cuenta de los programas de aplicación, comunicándose con el planificador, que es el módulo responsable de implementar una estrategia concreta de control de concurrencia. El objetivo del planificador es maximizar la concurrencia impidiendo que las transacciones que se ejecutan simultáneamente interfieran entre sí y pongan en peligro la coherencia de la base de datos. En caso de que se produzca un fallo durante la transacción, el gestor de recuperación garantiza que se restaure la base de datos al estado en el que se encontraba antes del comienzo de la transacción, que por definición es un estado coherente. El gestor de recuperación es también responsable de restaurar la base de datos a un estado coherente después de producirse un fallo del sistema. El gestor de búferes es el encargado de la transferencia eficiente de los datos entre el almacenamiento en disco y la memoria principal. En un SGBD distribuido, estos módulos siguen existiendo en cada SGBD local. Además, hay también un gestor global de transacciones o coordinador de transacciones en cada nodo para coordinar la ejecución de las transacciones globales y locales iniciadas en dicho nodo. La comunicación inter-nodos se sigue produciendo a través del componente de comunicación de datos (los gestores de transacciones de los distintos nodos no se comunican directamente entre sí). El procedimiento para ejecutar una transacción global iniciada en el nodo S¡ es el siguiente: •
El coordinador de transacciones (TC]) en el nodo S¡ divide la transacción en una serie de subtransacciones utilizando la información almacenada en el catálogo global del sistema.
•
El componente de comunicación de datos en el nodo S] envía las subtransacciones a los nodos apropiados, por ejemplo S2 y S3. Los coordinadores de transacciones de los nodos S2 y S3 se encargan de gestionar estas subtransacciones. Los resultados de las subtransacciones se devuelven a TC¡ a través de los componentes de comunicación de datos.
•
Este proceso se ilustra en la Figura 23.1. Ahora que hemos presentado esta panorámica de la gestión de transacciones distribuidas, vamos a analizar los protocolos de control de concurrencia, gestión de interbloqueos y recuperación.
23.2 Control de concurrencia distribuido En esta sección se presentan los protocolos que pueden utilizarse para realizar el control de concurrencia en un SGBD distribuido. Comenzamos examinando los objetivos del control de concurrencia distribuido.
Capítulo 23 Bases de datos distribuidas:
Comunicación de datos
Coordinador
conceptos avanzados
669
Comunicación de datos
Coordinador (TC1)
TM local
TM local
Figura 23.1. Coordinación de una transacción distribuida.
23.2.1 Objetivos Suponiendo que el sistema no haya fallado, todos los mecanismos de control de concurrencia deben garantizar que se preserve la coherencia de los elementos de datos y que cada acción atómica se complete en un tiempo finito. Además, un buen mecanismo de control de concurrencia para un SGBD distribuido debe: •
ser resistente a los fallos de comunicaciones y a los fallos de los nodos;
•
permitir mecanismos de paralelismo para satisfacer los requisitos de prestaciones;
•
no imponer un gasto excesivo de capacidad de proceso y de espacio de almacenamiento;
•
funcionar satisfactoriamente en un entorno de red donde exista un retardo de comunicación significativo;
•
no imponer muchas restricciones a la estructura de las acciones atómicas (Kohler, 1981).
En la Sección 20.2.1 hemos explicados los tipos de problemas que pueden surgir cuando se permite a múltiples usuarios acceder concurrentemente a la base de datos; dichos problemas son el de la actualización perdida, el de la dependencia no confirmada y el del análisis incoherente. Estos problemas también se producen en los entorno s distribuidos, pero en éstos hay problemas adicionales que pueden surgir como resultado de la propia distribución de los datos. Uno de dichos problemas es el problema de la coherencia multicopia, que se produce cuando un elemento de datos está replicado en ubicaciones diferentes. Obviamente, para mantener la coherencia de la base de datos global, cuando se actualice un elemento de datos replicado en un nodo todas las demás copias del elemento de datos deberán ser también actualizadas. Si no se actualiza una copia, la base de datos pasará a ser incoherente. Vamos a suponer en esta sección que las actualizaciones de los elementos replicados se llevan a cabo síncronamente, como parte de la transacción que las engloba. En el Capítulo 24 veremos cómo pueden realizarse asíncronamente estas actualizaciones de los elementos replicados, es decir, cómo pueden realizarse dichas actualizaciones en algún instante posterior al momento en que se completa la transacción donde se actualiza la copia original del elemento de datos.
23.2.2
Serializabilidad distribuida
El concepto de serializabilidad, del que hemos hablado en la Sección 20.2.2, puede ampliarse para el entorno distribuido con el fin de tener en cuenta los problemas inherentes a la distribución de datos. Si la planificación de ejecución de una transacción es serializable en cada nodo, entonces la planificación global (la unión de todas las planificaciones locales) será también serializable, supuesto que los órdenes de serialización locales sean idénticos. Esto requiere que todas las subtransacciones aparezcan en el mismo orden en la planificación serie equivalente en todos los nodos. Así, si denotamos mediante T~ la subtransacción Ti en el nodo SI' debemos garantizar que si T~ < T;entonces:
670
Sistemas de bases de datos
T/ < T/
para todos los nodos Sx en los que Ti y Tj tengan subtransacciones
Las soluciones para el control de concurrencia en un entorno distribuido se basan en las dos técnicas principales de bloqueo y de marcado temporal, que ya hemos considerado para los sistemas centralizados en la Sección 20.2. De esta forma, dado un conjunto de transacciones que haya que ejecutar concurrentemente, tendremos que: • •
el bloqueo garantiza que la ejecución concurrente es equivalente a alguna ejecución serie (impredecible) de dichas transacciones; el marcado temporal garantiza que la ejecución concurrente sea equivalente a una ejecución serie especorrespondiente al orden de las marcas temporales.
cifzca de dichas transacciones,
Si la base de datos es centralizada o fragmentada, pero no replicada, de forma que sólo exista una copia de cada elemento de datos y todas las transacciones sean locales o puedan ser realizadas en un nodo remoto, se podrán usar los protocolos presentados en la Sección 20.2. Sin embargo, si los datos están replicados o las transacciones afectan a datos situados en más de un nodo, será necesario ampliar dichos protocolos. Además, si adoptamos un protocolo basado en bloqueos, tendremos que proporcionar un mecanismo para gestionar los interbloqueos (véase la Sección 20.2.4). Utilizando un mecanismo de detección y recuperación de interbloqueos, esto implica comprobar si hay una situación de interbloqueo no sólo en cada nivel local, sino también en el nivel global, lo que puede requerir combinar los datos de interbloqueo de más de un nodo. Hablaremos de los interbloqueos distribuidos en la Sección 23.3.
23.2.3
Protocolos de bloqueo
En esta sección vamos a presentar los siguientes protocolos basados en el bloqueo en dos fases (2PL, twophase locking), que pueden emplearse para garantizar la serializabilidad en un SGBD distribuido: 2PL centralizado, 2PL de copia principal, 2PL distribuido y bloqueo por mayoría.
2PL centralizado Con el protocolo 2PL centralizado, hay un único nodo que mantiene toda la información de bloqueo (Alsberg y Day, 1976; García-Molina, 1979). Sólo hay un planificador, o gestor de bloqueos, para el conjunto del SGBD distribuido, planificador que se responsabiliza de conceder y liberar los bloqueos. El protocolo 2PL centralizado para una transacción global iniciada en el sitio SI funciona de la forma siguiente: (1) El coordinador de la transacción en el sitio SI divide la transacción en una serie de subtransacciones, utilizando la información almacenada en el catálogo global del sistema. El coordinador es responsable de garantizar que se mantenga la coherencia. Si la transacción implica una actualización de un elemento de datos que está replicado, el coordinador deberá garantizar que también se actualicen todas las copias del elemento de datos. Así, el coordinador solicitará bloqueos exclusivos sobre todas las copias antes de actualizar cada copia y liberar los bloqueos. El coordinador puede elegir utilizar cualquiera de las copias de los elementos de datos para las lecturas, generalmente la copia situada en su propio nodo, si es que existe. (2) Los gestores de transacciones locales implicados en la transacción global solicitan (y liberan) bloqueos al gestor de bloqueos centralizados utilizando las reglas normales del bloqueo en dos fases. (3) El gestor de bloqueos centralizado comprueba si las solicitudes de bloqueos sobre un elemento de datos son compatibles con los bloqueos que existan actualmente. En caso afirmativo, el gestor de bloqueos devuelve un mensaje al nodo de origen confirmándole que se ha concedido el bloqueo. En caso contrario, pone la solicitud en una cola hasta que el bloqueo pueda concederse. Una variación de este esquema consiste en que el coordinador de transacciones realice todas las solicitudes de bloqueo por cuenta de los gestores de transacciones locales. En este caso, el gestor de bloqueos sólo interactúa con el coordinador de transacciones y no con los gestores de transacciones locales individuales. La ventaja del protocolo 2PL centralizado es que la implementación es relativamente sencilla. La detección de interbloqueos no resulta más difícil que para un SGBD centralizado, porque hay un único gestor de
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
671
bloqueos que mantiene toda la información sobre los bloqueos. Las desventajas de la centralización en un SGBD distribuido son la posible aparición de cuellos de botella y la reducción en la fiabilidad. Ya que todas las solicitudes de bloqueos se dirigen a un nodo central, dicho nodo puede convertirse en un cuello de botella. El sistema puede también ser menos fiable, ya que el fallo del nodo central provocará un fallo de gran importancia en el sistema. Sin embargo, los costes de comunicaciones son relativamente bajos. Por ejemplo, una operación de actualización global que tenga agentes (subtransacciones) en n nadas puede requerir intercambiar un mínimo de 2n + 3 mensajes con un gestor de bloqueos centralizado: •
una solicitud de bloqueo;
•
un mensaje de concesión del bloqueo;
•
n mensajes de actualización;
•
n confirmaciones;
•
una solicitud de desbloqueo.
2PL de copia principal Este protocolo trata de resolver las desventajas del 2PL centralizado, distribuyendo los gestores de bloqueos entre una serie de nadas. Cada gestor de bloqueos es entonces responsable de gestionar los bloqueos para un conjunto de elementos de datos. Para cada elemento de datos replicado, se elige una copia para que sea la copia principal llamándose a las demás copias copias esclavas. La elección de qué nodo debe ser el nodo primario es flexible, y el nodo elegido para gestionar los bloqueos para una copia principal no tiene por qué almacenar la copia principal de dicho elemento (Stonebraker y Neuhold, 1977). El protocolo es una extensión sencilla del 2PL centralizado. La principal diferencia es que, a la hora de actualizar un elemento, el coordinador de la transacción debe determinar dónde está la copia principal, para enviar las solicitudes de bloqueo al gestor de bloqueos apropiado. Sólo es necesario imponer un bloqueo exclusivo a la copia principal del elemento de datos que haya que actualizar. Una vez actualizada la copia principal, puede probarse el cambio a las copias esclavas. Esta propagación debe llevarse a cabo lo antes posible para evitar que otras transacciones lean valores desactualizados. Sin embargo, no es estrictamente necesario llevar a cabo las actualizaciones como una operación atómica. Este protocolo sólo garantiza que esté actualizada la copia principal. Esta técnica puede utilizarse cuando los datos se repliquen selectivamente, cuando las actualizaciones sean infrecuentes y cuando los nadas no necesiten siempre la versión más reciente de los datos. Las desventaja de esta técnica son que resulta más complejo gestionar los interbloqueos, debido a la existencia de múltiples gestores de bloqueos, y que sigue existiendo un cierto grado de centralización en el sistema: las solicitudes de bloqueo para una copia principal específica sólo pueden gestionarse en un único nodo. Esta última desventaja puede resolverse parcialmente designando una serie de nadas de reserva para que almacenen la información de bloqueo. Esta técnica tiene menor coste de comunicación y, por tanto, unas mejores prestaciones que el 2PL centralizado, ya que hay menos bloqueos remotos.
2PL distribuido Este protocolo trata, de nuevo, de resolver las desventajas del 2PL centralizado, pero esta vez distribuyendo los gestores de bloqueos entre todos los nadas. Cada gestor de bloqueo será entonces responsable de gestionar los bloqueos correspondientes a los datos situados en dicho nodo. Si no se replican los datos, este protocolo es equivalente al 2PL de copia principal; pero si los datos están replicados, el 2PL distribuido implementa un protocolo de control de réplicas denominado ROWA (Read-One-Write-All, leer una y escribir todas). Esto quiere decir que puede utilizarse cualquier copia de un elemento replicado para las operaciones de lectura, pero que es necesario establecer un bloqueo exclusivo sobre todas las copias antes de poder actualizar un elemento. Este esquema gestiona los bloqueos de forma descentralizada, evitando así las desventajas del control centralizado. Sin embargo, las desventajas de esta técnica son que la gestión de interbloqueo resulta más compleja, debido a la existencia de múltiples gestores de bloqueos, y que los costes de comunicaciones son mayores que en el 2PL de copia principal, ya que es preciso bloquear todos los elementos antes de cada
672
Sistemas de bases de datos
actualización. Una operación de actualización global que tenga agentes en n sitios, puede recibir un mínimo de 5n mensajes con este protocolo: •
n mensajes de solicitud de bloqueo;
•
n mensajes de concesión de bloqueo;
•
n mensajes de actualización;
•
n confirmaciones;
•
n solicitudes de desbloqueos.
Puede reducirse esta cantidad a 4n mensajes si se omiten las solicitudes de desbloqueo y se gestionan éstas mediante la operación final de confirmación. El protocolo 2PL distribuido se utiliza en R * (Mohan et al., 1986).
Bloqueo por mayoría Este protocolo es una extensión del 2PL distribuido que trata de evitar la necesidad de bloquear todas las copias de un elemento replicado antes de la actualización. De nuevo, el sistema mantiene un gestor de bloqueos en cada nodo para gestionar los bloqueos de todos los datos almacenados en el mismo. Cuando una transacción desea leer o escribir un elemento de datos que está replicado en n nodos, debe enviar una solicitud de bloqueos a más de la mitad de los n nodos donde el elemento está almacenado. La transacción no puede continuar hasta que obtenga bloqueos sobre una mayoría de las copias. Si la transacción no recibe una mayoría de confirmación de bloqueos dentro de un cierto periodo de temporización, cancela su solicitud e informa a todos los nodos de la cancelación. Si recibe una mayoría de confirmaciones, informa a todos los nodos de que ha adquirido el bloqueo. Puede haber varias transacciones que mantengan simultáneamente un bloqueo compartido sobre una mayoría de las copias; sin embargo, sólo una transacción puede mantener un bloqueo exclusivo sobre una mayoría de las copias. De nuevo, este esquema resuelve las desventajas del control centralizado. Pero también tiene sus propias desventajas, que consisten en que el protocolo es más complicado, en que la detección de interbloqueos es más compleja y en que el bloqueo requiere al menos [en + 1)/2] mensajes para las solicitudes de bloqueo y [en + 1)/2] mensajes para las solicitudes de desbloqueo. Esta técnica funciona correctamente, pero es excesivamente estricta en el caso de los bloqueos compartidos: en realidad, sólo es necesario bloquear una única copia de un elemento de datos, el elemento de datos leído, pero esta técnica solicita bloqueos sobre una mayoría de las copias.
23.2.4
Protocolos de marcado temporal
Hemos hablado de los métodos de marcado temporal para los métodos SGBD centralizados en la Sección 20.2.5. El objetivo del marcado temporal es ordenar las transacciones globalmente de tal forma que las transacciones más antiguas (las transacciones con marcas temporales más pequeñas) tengan prioridad en caso de conflicto. En un entorno distribuido, seguimos necesitando generar marcas temporales unívocas tanto localmente como globalmente. Claramente, la utilización del reloj del sistema o de un contador incremental de sucesos en cada nodo, como se propone en la Sección 20.2.5, no resultaría adecuada. Los relojes de los diferentes nodos podrían no estar sincronizados; asimismo, si se utilizara un contador de sucesos, sería posible que los diferentes nodos generaran el mismo valor de contador. La técnica general en los SGBD distribuidos consiste en utilizar la concatenación de la marca temporal local con un identificador unívoco de nodo, (Lamport, 1978). El identificador de nodo se coloca en la posición menos significativa para garantizar que los sucesos puedan ordenarse de acuerdo con el instante en que se produjeron, en lugar de ordenarse de acuerdo con su ubicación. Para evitar que un nodo con mucha actividad genere marcas temporales de mayor tamaño que otros nodos menos ocupados los distintos nodos sincronizan sus marcas temporales. Cada nodo incluye su marca temporal en los mensajes intercambiados con los otros nodos. Al recibir un mensaje, el nodo compara su propia marca temporal con la marca temporal del mensaje y, si su propia marca temporal es más pequeña, le asigna algún valor que sea superior a la marca temporal del mensaje. Por ejemplo, si el nodo 1 cuya marca temporal
Capítulo 23 Basesde datos distribuidas: conceptos avanzados
673
actual es <10,1> envía un mensaje al nodo 2 cuya marca temporal es <15, 2>, el nodo 2 no cambiará su marca temporal. Por el contrario, si la marca temporal actual en el nodo 2 fuera <5,2>, el nodo cambiaría su marca temporal a <11, 2>.
23.3 Gestión distribuida de interbloqueos Todo algoritmo de control de concurrencia basado en bloqueos (y algunos algoritmo s basados en marcas temporales que requieren que las transacciones realicen esperas) puede dar lugar a interbloqueos, como se explica en la Sección 20.2.4. En un entorno distribuido, la detección de interbloqueos puede ser más complicada si la gestión de los bloqueos no está centralizada, como se muestra en el Ejemplo 23.l.
I
Ejemplo 23.1 Interbloqueo distribuido Considere tres transacciones TI, T2 Y T3 tales que: •
TI ha sido iniciada en el nodo SI y está creando un agente en el nodo S2;
•
T2 ha sido iniciada en el nodo S2 y está creando un agente en el nodo S3;
•
T3 ha sido iniciada en el nodo S3 y está creando un agente en el nodo SI'
Las transacciones comparten bloqueos compartidos (para lectura) y exclusivos (para escritura), como se ilustra a continuación, donde read _lock(T¡, x) denota un bloqueo compartido por la transacción T¡ sobre el elemento de datos xj y write _lock(T¡, x) denota un bloqueo exclusivo por parte de la transacción T¡ sobre el elemento de datos Xj' Tiempo S¡ S2 S3 ti read_lock(T¡, Xl) write_lock(T2' Y2) read _lock(T3' Z3) t2 write_lock(T¡, Y¡) write_lock(T2, Z2) t3 write_lock(T3, Xl) write_lock(TI' Y2) write_lock(T2' Z3) Podemos construir los grafos de espera para cada nodo, los cuales se muestran en la Figura 23.2. No hay ningún ciclo en los grafos individuales, lo que podría llevamos a pensar que no puede producirse un interbloqueo. Sin embargo, si combinamos los grafos de espera, como se ilustra en la Figura 23.3, podemos ver que sí existe un interbloqueo, debido a la existencia del ciclo:
S,
Figura 23.2. Gratos de espera para los nadas 8" 82 Y 83,
Figura 23.3. Gratos de espera combinados para los nadas 8" 82 Y 83,
674
Sistemas de bases de datos
El Ejemplo 23.1 demuestra que en un SGBDD no es suficiente que cada nodo construya su propio grafo de espera local con el fin de comprobar si existen interbloqueos; también es necesario construir un grafo de espera global que sea la unión de todos los grafos de espera locales. Hay tres métodos comunes para gestionar la detección de interbloqueos en los SGBDD: detección de interbloqueos centralizada, jerárquica y distribuida.
Detección de interbloqueos
centralizada
Con la detección de interbloqueos centralizada, se nomina a un único nodo como coordinación de detección de interbloqueos (DDC, Deadlock Detection Coordinator). El DDC tiene la responsabilidad de construir y mantener el grafo de espera global. Periódicamente, cada gestor de bloqueos transmite su grafo de espera local al DDC. El DDC construye el grafo de espera global y comprueba si existen ciclos en él. Si existen uno o más ciclos, el DDC debe romper cada ciclo seleccionando las transacciones que hay que anular y reiniciar. El DDC debe informar a todos los nadas implicados en el procesamiento de dichas transacciones que las transacciones deben ser anuladas y reiniciadas. Para minimizar la cantidad de datos que hay que enviar, cada gestor de bloqueos sólo necesita enviar los cambios que hayan tenido lugar en el grafo de espera local desde la última vez que lo enviaron. Estos cambios representan la adición o eliminación de aristas en el grafo de espera local. La desventaja de esta técnica centralizada es que el sistema puede ser menos fiable, ya que el fallo del nodo central provocaría problemas de gran envergadura.
Detección de interbloqueos
jerárquica
Con la detección de interbloqueos jerárquica, los nadas de la red están organizados en forma de jerarquía. Cada nodo envía su grafo de espera local al nodo de detección de interbloqueos situado por encima suyo en la jerarquía (Menasce y Muntz, 1979). La Figura 23.4 ilustra una posible jerarquía para ocho nadas, S I a Ss. Las hojas de nivel 1 son los propios nadas, donde se realiza la detección de interbloqueos locales. Los nadas de nivel 2 DDij detectan los interbloqueos en los que estén involucrados los nadas adyacentes ¡y j. Los nadas de nivel 3 detectan los interbloqueos entre cuatro nadas adyacentes. La raíz del árbol es un detector de interbloqueos global que permitirá detectar cualquier interbloqueo, como por ejemplo entre los nadas SI y Ss. La solución jerárquica reduce la dependencia con respecto a un nodo de detección centralizado, abaratando así los costes de comunicaciones. Sin embargo, esta técnica es mucho más compleja de implementar, particularmente si se producen fallos de los nadas o de las líneas de comunicación.
Detección de interbloqueos
distribuida
Se han realizado diversas propuestas de algoritmos de detección de interbloqueos distribuida, pero aquí vamos a considerar uno de los más conocidos, que fue desarrollado por Obermarck (1982). Según este algoritmo, se añade un nodo externo Texta un grafo de espera local para indicar un agente situado en un nodo remoto. Cuando, por ejemplo, una transacción TI en el nodo SI cree un agente en otro nodo S2, se añadirá una arista al grafo de esfera local desde TI hasta el nodo Text.De forma similar, en el nodo S2 se añadirá una arista al grafo de esfera local desde el nodo Tex!hasta el agente de T ¡. Por ejemplo, el grafo de espera global mostrado en la Figura 23.3 se representaría mediante los grafos de espera locales de los nadas SI' S2 y S3 que se muestran en la Figura 23.5. Las aristas del grafo de espera local que enlazan los agentes con Textestán etiquetadas con el nombre del nodo correspondiente. Por ejemplo, la arista que conecta a TI Y Texten el nodo SI está etiquetada como S2, ya que esta arista representa un agente creado por la transacción TI en el nodo S2' Si un grafo de espera local contiene un ciclo que no incluye al nodo Text'dicho nodo y el SGBDD estarán en una situación de interbloqueo y el interbloqueo puede ser roto por el nodo local. Existirá potencialmente un interbloqueo global si el grafo de espera local contiene un ciclo que incluya al nodo Text.Sin embargo, la existencia de dicho ciclo no implica necesariamente que haya un interbloqueo global, ya que los nadas Tex! pueden representar diferentes agentes; sin embargo, la inversa sí es cierta. Si hay un interbloqueo, deberán aparecer ciclos de este tipo en los grafos de espera. Para determinar si hay un interbloqueo, es necesario combinar los grafos. Si un nodo SI tiene un interbloqueo potencial, su grafo de espera local será de la forma:
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
675
Nivel 4
3
2
Figura 23.4.
Detección de interbloqueos jerárquica.
Para evitar que los nadas se transmitan entre sí sus grafos de espera, una estrategia simple consiste en asignar una marca temporal a cada transacción e imponer la regla de que el nodo SI transmita su grafo de espera al nodo para el que la transacción Tk está esperando, Sk>únicamente si ts(T;) < ts(Tk). Si suponemos que ts(T;) < tS(Tk) entonces, para comprobar si existe un interbloqueo, el nodo SI transmitiría su grafo de espera local a Sk' El nodo Skpodrá entonces añadir esta información a su grafo de espera local y comprobar si existen ciclos en el grafo ampliado donde no aparezca Text.Si no existe tal ciclo, el proceso continua hasta que aparezca un ciclo, en cuyo caso habrá que anular y reiniciar algunas transacciones junto con todos sus agentes, o hasta que se construya el grafo de espera global y se compruebe que no existe ningún ciclo. En este caso, no habrá ningún interbloqueo en el sistema. Obermarck demostró que si existe un interbloqueo global, este procedimiento hará que aparezca un ciclo en alguno de los nodos. Los tres grafos de espera locales de la Figura 23.5 contienen ciclos: S1:
Text-7 T3 -7 T1 -7 Text
S2:
Text-7 T1 -7 T2 -7 Text
S3:
Text-7 T2 -7 T3 -7 Text
En este ejemplo, podríamos transmitir el grafo de espera local del nodo SI al nodo para el que la transacción TI está esperando, es decir, el nodo S2' El grafo de espera local en S2 se ampliará para incluir esta información, con lo que nos queda:
Figura 23.5.
Detección de interbloqueos
distribuida.
676
Sistemas de bases de datos
Vemos que este grafo sigue conteniendo un interbloqueo secuencial, por lo que transmitiríamos este grafo de espera al nodo para el que la transacción Tz está esperando, es decir, el nodo S3. Así, ampliamos el grafo de espera local de S3 para obtener:
Este grafo de espera global contiene un ciclo donde no aparece el nodo Text,por lo que podemos concluir que existe interbloqueo y tendremos que invocar un protocolo de recuperación apropiado. Los métodos de detección de interbloqueos distribuidos son potencialmente más robustos que los métodos jerárquicos o centralizados, pero como no hay ningún nodo que contenga toda la información necesaria para detectar los interbloqueos, es posible que se necesite una cantidad considerable de comunicación inter-nodos.
23.4 Recuperación de bases de datos distribuidas En esta sección, vamos a hablar de los protocolos que se utilizan para gestionar los fallos en un entorno distribuido.
23.4.1 Fallos en un entorno distribuido En la Sección 22.5.2 hemos mencionado cuatro tipos de fallos que son propios de los SGBD distribuidos: • •
la pérdida de un mensaje; el fallo de un enlace de comunicaciones;
•
el fallo de un nodo;
•
el particionamiento
de la red.
La pérdida de mensajes, o la ordenación inadecuada de los mensajes, es responsabilidad del protocolo subyacente de la red informática. Por tanto, asumiremos que estos problemas son gestionados de forma transparente por el componente de comunicación de datos del SGBDD y nos vamos a fijar aquí en los restantes tipos de fallos. Un SGBDD depende en gran medida de la capacidad de todos los nodos de la red para comunicarse entre sí de manera fiable. Antiguamente, las comunicaciones no siempre eran fiables. Aunque la tecnología de red ha mejorado significativamente y las redes actuales son mucho más fiables, sigue existiendo la posibilidad de que se produzcan fallos de comunicaciones. En concreto, dichos fallos de comunicaciones pueden tener como resultado que la red quede dividida en dos o más particiones, en las que los nodos situados dentro de una misma partición pueden comunicarse entre sí, pero no pueden comunicarse con los nodos de las otras particiones. La Figura 23.6 muestra un ejemplo de particionamiento de la red donde, después de fallar el enlace que conecta los nodos SI ---¿ Sz, los nodos (S¡, S4, Ss) quedan particionados con respecto a los nodos (Sz, S3)·
(b)
(a)
Figura 23.6.
Particionamiento
de una red: (a) antes del fallo; (b) después del fallo.
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
677
En algunos casos, es difícil distinguir si ha fallado un enlace de comunicaciones o un nodo. Por ejemplo, suponga que el nodo SI no puede comunicarse con el nodo S2 dentro de un determinado periodo de temporización. Podría ser que: •
el nodo S2 haya sufrido un fallo o la red se haya caído;
•
el enlace de comunicaciones
•
la red esté particionada;
•
el nodo S2 tenga actualmente una gran carga de trabajo y no haya tenido tiempo para responder al mensaJe.
haya fallado;
Resulta dificil seleccionar el valor de temporización comunicarse con el nodo S2.
correcto que permita a SI concluir que no puede
23.4.2 Cómo afectan los fallos a la recuperación Al igual que con la recuperación local, la recuperación distribuida trata de mantener la atomicidad y la durabilidad de las transacciones distribuidas. Para asegurar la atomicidad de la transacción global, el SGBDD debe garantizar que todas las subtransacciones de la transacción global se confirmen o que todas se aborten. Si el SGBDD detecta que un nodo ha fallado o es inaccesible, tendrá que llevar a cabo los siguientes pasos: •
Abortar todas las transacciones que se vean afectadas por el fallo.
•
Marcar el nodo como fallido, para evitar que cualquier otro nodo trate de utilizado.
•
Comprobar periódicamente para ver si el nodo se ha recuperado o, alternativamente, nodo fallido difunda un mensaje informando de que se ha recuperado.
•
Al reiniciarse, el nodo fallido debe iniciar un procedimiento de recuperación para abortar cualesquiera transacciones parciales que estuvieran activas en el momento del fallo.
•
Después de la recuperación local, el nodo fallido debe actualizar su copia de la base de datos para hacer que sea coherente con el resto del sistema.
esperar a que el
Si se produce una partición de la red como en el ejemplo anterior, el SGBDD debe garantiza que si hay agentes de una misma transacción global activos en diferentes particiones, entonces no debe ser posible para el nodo SI (y para otros nodos de la misma partición) decidir que se confirme la transacción global, mientras que el nodo S2 (y otros nodos en su partición) deciden abortada. Esto violaría la atomicidad de la transacción global.
Protocolos de recuperación
distribuida
Como hemos mencionado anteriormente, la recuperación en un SGBDD se ve complicada por el hecho de que se requiere mantener la característica de atomicidad tanto para las subtransacciones locales como para la transacción global. Las técnicas de recuperación descritas en la Sección 20.3 garantizan la atomicidad de las subtransacciones, pero el SGBDD necesita garantizar también la atomicidad de una transacción global. Esto implica modificar el procesamiento de las órdenes de confirmar y abortar de modo que una transacción global no se confirme ni aborte hasta que todas sus subtransacciones se hayan confirmado o abortado con éxito. Además, el protocolo modificado debe tener en cuenta tanto los fallos de los nodos como los fallos de los enlaces de comunicaciones, para garantizar que el fallo de un nodo no afecte al procesamiento de otro nodo. En otras palabras, los nodos que están operativos no deben quedar bloqueados. Los protocolos que obedecen esta regla se denominan protocolos no bloqueantes. En las siguientes dos secciones, vamos a analizar dos protocolos comunes de confirmación que resultan adecuados para los SGBD distribuidos: la confirmación en dos fases (2PC, two-phase commit) y la confirmación en tres fases (3PC, three-phase commit), que es un protocolo no bloqueante. Vamos a asumir que toda transacción global tiene un nodo que actúa como coordinador (o gestor de la transacción) para dicha transacción, que será generalmente el nodo en el que la transacción fuera iniciada. Los nodos en los que la transacción global tiene agentes se denominan participantes (o gestores de recur-
678
Sistemas de bases de datos
sos). Vamos a asumir que el coordinador conoce la identidad de todos los participantes y que cada participante conoce la identidad del coordinador, aunque no necesariamente la de los otros participantes.
23.4.3
Confirmación en dos fases (2PC)
Como el nombre indica, 2PC opera en dos fases: una fase de votación y una fase de decisión. La idea básica es que el coordinador pregunte a todos los participantes si están preparados para confirmar la transacción. Si uno de los participantes vota por abortarla o no responde dentro de un cierto periodo de temporización, el coordinador instruye a todos los participantes para que aborten la transacción. Si todos votan en favor de la confirmación, el coordinador instruirá a todos los participantes para que confirmen la transacción. La decisión global debe ser adoptada por todos los participantes. Si un participante vota por abortar la transacción, podrá si quiere abortarla inmediatamente; de hecho todos los nodos son libres de abortar una transacción en cualquier momento, antes de votar por confirmarla. Este tipo de cancelación en la transacción se conoce con el nombre de aborto unilateral. Si un participante vota por confirmar la transacción, deberá esperar a que el coordinador difunda el mensaje de confirmación global o de aborto global. Este protocolo asume que cada nodo tiene su propio registro local y que puede, por tanto, anular o confirmar la transacción de manera fiable. La confirmación en dos fases implica que los procesos tengan que esperar a recibir mensajes de otros nodos. Para evitar que los procesos queden bloqueados de forma innecesaria, se utiliza un sistema de temporizaciones. El procedimiento que debe seguir el coordinador para la confirmación es el siguiente: Fase 1 (1) Escribir un registro begin_commit en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Enviar un mensaje PREPARE a todos los participantes. Esperar a que los participantes respondan dentro de un cierto periodo de temporización. Fase 2 (2) Si un participante devuelve un voto ABORT, escribir un registro abort en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Enviar un mensaje GLOBALfiBORT a todos los participantes. Esperar a que los participantes envíen una confirmación dentro de un cierto periodo de temporización. (3) Si un participante devuelve un voto READY _COMMIT, actualizar la lista de participantes que han respondido. Si todos los participantes han votado COMMIT, escribir un registro commit en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Enviar un mensaje GLOBAL _COMMIT a todos los participantes. Esperar a que los participantes envíen un mensaje de confirmación dentro de un cierto periodo de temporización. (4) Una vez que se han recibido todas las confirmaciones, escribir un mensaje end _transaction en el archivo de registro. Si un nodo no envía su confirmación, se vuelve a enviar la decisión global hasta que se reciba una confirmación. El coordinador debe esperar hasta recibir los votos de todos los participantes. Si uno de los nodos no vota, el coordinador asumirá un valor de voto predeterminado igual aABORT y difundirá un mensaje GLOBAL_ ABORT a todos los participantes. Un poco más adelante veremos qué sucede durante el reinicio con ese participante que ha fallado. El procedimiento que debe seguir un participante durante la confirmación es el siguiente: (1) Cuando el participante recibe un mensaje PREPARE, entonces tiene que hacer una de estas dos cosas: (a) escribir un registro ready Jommit en el archivo de registro y provocar la escritura forzada de todas las entradas del registro correspondientes a la transacción en almacenamiento estable. Enviar un mensaje READY _COMMIT al coordinador o, (b) escribir un registro abort en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Enviar un mensaje ABORT al coordinador. Abortar unilateralmente la transacción. Esperar a que el coordinador responda dentro de un cierto periodo de temporización.
Capítulo 23 Bases de datos distribuidas:
conceptos avanzados
679
(2) Si el participante recibe un mensaje GLOBAL_ABORT, escribir un registro abort en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Abortar la transacción y, al completar la operación, enviar una confirmación al coordinador. (3) Si el participante recibe un mensaje GLOBAL _COMMIT, escribir un registro commit en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Confirmar la transacción, liberando cualesquiera bloqueos que mantuviera y, al completar la operación, enviar una confirmación al coordinador. Si un participante no recibe una instrucción de voto del coordinador, transcurrirá simplemente el periodo de temporización preestablecido y el participante abortará la transacción. Por tanto, cualquier participante podría ya haber abortado y realizado el procesamiento de aborto local correspondiente antes de votar. El procesamiento para el caso en que los participantes voten COMMIT y ABORT se muestra en la Figura 23.7. El participantes tiene que esperar a recibir la instrucción GLOBAL_COMMIT o GLOBAL_ABORT del coordinador. Si el participante no recibe la instrucción del coordinador, o éste no recibe una respuesta de un participante, asumirá que el nodo ha fallado y deberá invocar un protocolo de terminación. Sólo los nodos operativos siguen el protocolo de terminación; los nodos que hayan fallado deberán seguir el protocolo de recuperación durante el reinicio. Coordinador
Participante
Commit: escribir begin _commit en el registro enviar PREPARE a todos los participantes
--
........• ~~
Prepare: escribir ready _commit en el registro
esperar las respuestas
enviar READY _COMMIT al coordinador esperar por GLOBAL_COMMlT o GLOBAL_ABORT
Ready _ commit: si todos los participantes han votado READY: escribir commit en el registro enviar GLOBAL_COMMIT a todos los participantes
~ Global_commit:
esperar las confirmaciones
escribir entrada commit en el registro confirmar transacción
Ack: enviar confirmaciones
si todos los participantes han confirmado: escribir end_oLtransaction
en el registro
(a)
Coordinador
Participante
Commit: escribir begin_commit en el registro enviar PREPARE a todos los participantes esperar las respuestas Abort:
••
Prepare: escribir abort en el registro enviar ABORT al coordinador abortar la transacción
si un participante ha votado ABORT: escribir abort en el registro enviar GLOBAL _ABORT a todos los participantes esperar confirmaciones
(b)
Figura 23.7. Resumen de 2PC: (a) protocolo 2PC para el caso de que un participante vote COMMIT; (b) protocolo 2PC para el caso de que un participante vote ABORT.
680
Sistemas de bases de datos
Protocolos de terminación
para 2PC
Es necesario invocar un protocolo de terminación siempre que un coordinador o un participante no reciba un mensaje esperado y se produzca un fin de temporización. La acción que habrá que tomar dependerá de si el fin de temporización se ha producido en el coordinador o en el participante y de cuándo se haya producido dicho fin de temporización. Coordinador El coordinador puede estar en uno de los cuatro estados durante el proceso de confirmación: INITIAL, WAITINO, DECIDED y COMPLETED, como se muestra en el diagrama de transacción de estados de la Figura 23.8(a), pero sólo puede producirse un fin de temporización en los dos estados intermedios. Las acciones que habrá que tomar son la siguientes: •
Fin de temporización en el estado WAITING El coordinador está esperando a que todos los participantes confirmen si quieren confirmar o abortar la transacción. En este caso, el coordinador no puede coordinar la transacción porque no ha recibido todos los votos. Sin embargo, puede decidir abortar globalmente la transacción .
•
Fin de temporización en el estado DECIDED. El coordinador está esperando a que todos los participantes confirmen si han abortado o confirmado con éxito la transacción. En este caso, el coordinador simplemente envía de nuevo la decisión global a aquellos nodos que no hayan enviado su mensaje de confirmación.
Participante El protocolo de terminación más simple consiste en dejar bloqueado el proceso participante hasta dejar que vuelva a establecerse la comunicación con el coordinador. El participante puede entonces ser informado de la decisión global y continuar con su procesamiento de forma correspondiente. Sin embargo, hay otras acciones que pueden tomarse para mejorar el rendimiento. Un participante puede estar en uno de los cuatro estados durante el proceso de confirmación: INITrAL, PREPARED, ABORTED y COMMITTED, como se muestra en la Figura 23.8(b). Sin embargo, sólo puede producirse un fin de temporización en el participante en los primeros dos estados, como a continuación se explica:
Enviado mensaje de preparación
Enviado mensaje de decisión global
Recibida confirmación
(b)
(a)
Figura 23.8.
Diagrama de transiciones entre estados para 2PC: (a) coordinador; (b) participante.
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
681
•
Fin de temporización en el estado INITIAL. El participante está esperando a recibir el mensaje PREPARE del coordinador, lo que implica que el coordinador debe de haber fallado mientras se encontraba en el estado INITIAL. En este caso, el participante puede abortar unilateralmente la transacción. Si recibe después un mensaje PREPARE, puede ignorado, en cuyo caso el coordinador detectará un fin de temporización y abortará la transacción global, o puede enviar un mensaje ABORT al coordinador.
•
Fin de temporización en el estado PREPARED. El participante está esperando recibir una instrucción de confirmar o abortar globalmente la transacción. El participante debe haber ya abortado para confirmar la transacción, por lo que no puede cambiar su voto y abortar la transacción. Asimismo, tampoco puede continuar y confirmar la transacción, ya que la decisión global podría ser abortada. Sin información adicional, el participante quedará bloqueado. Sin embargo, el participante puede contactar a cada uno de los otros participantes para tratar de localizar a uno que conozca la decisión. Esto se conoce con el nombre de protocolo de terminación cooperativo. Una forma sencilla de informar a los participantes de quiénes son los otros participantes es que el coordinador añada una lista de participantes a la instrucción de voto.
Aunque el protocolo de terminación cooperativo reduce la posibilidad de bloqueo, dicha posibilidad sigue existiendo y el proceso bloqueado tendrá que continuar intentando desbloquearse a medida que se reparen los fallos. Si solamente ha fallado el coordinador y todos los participantes detectan este hecho como resultado de la ejecución del protocolo de terminación, pueden elegir un nuevo coordinador y resolver el bloqueo de esta manera, como explicaremos en breve.
Protocolos de recuperación
para 2PC
Habiendo analizado las acciones que un nodo operativo debe tomar en caso de fallo, vamos a ver ahora las acciones que un nodo fallido debe llevar a cabo durante la recuperación. La acción que haya que tomar durante el re inicio dependerá, de nuevo, del estado que el coordinador o participante hubiera alcanzado en el momento del fallo.
Fallo del coordinador Vamos a considerar tres diferentes estados para el fallo del coordinador: •
Fallo en el estado INITIAL. El coordinador todavía no ha iniciado el procedimiento de confirmación. La recuperación en este caso consiste en iniciar dicho procedimiento de confirmación.
•
Fallo en el estado WAITING. El coordinador ha enviado el mensaje PREPARE y, aunque no ha recibido todas las respuestas, tampoco ha recibido una respuesta indicando que hay que abortar la transacción. En este caso, el procedimiento de recuperación consiste en reiniciar el procedimiento de confirmación.
•
Fallo en el estado DECIDED. El coordinador ha ordenado a todos los participantes que aborten o confirmen globalmente la transacción. Durante el reinicio, si el coordinador ha recibido todas las confirmaciones, puede completar la transacción con éxito. En caso contrario, tiene que iniciar el protocolo de terminación al que antes hemos hecho referencia.
Fallo del participante El objetivo del protocolo de recuperación para un participante consiste en garantizar que el proceso participante realice en el reinicio la misma acción que todos los demás participantes, y que este reinicio pueda ser llevado a cabo de forma independiente (es decir, sin necesidad de consultar ni al coordinador ni a los otros participantes). Vamos a considerar tres estados distintos para el fallo de un participante: •
Fallo en el estado INITIAL. El participante todavía no ha votado sobre la transacción. Por tanto, durante la recuperación, puede abortar unilateralmente la transacción ya que es imposible que el coordinador haya alcanzado una decisión global de confirmación sin el voto de este participante.
•
Fallo en el estado PREPARED. El participante ha enviado su voto al coordinador. En este caso, la recuperación se lleva a cabo mediante el protocolo de terminación que antes hemos explicado.
682
•
Sistemas de bases de datos
Fallo en los estados ABORTED/COMMITTED. El participante ha completado tanto, durante el re inicio no hace falta llevar a cabo ninguna acción adicional.
la transacción.
Por
Protocolos de elección Si los participantes detectan el fallo del coordinador (por el fin de temporización) pueden elegir un nuevo nodo para que actúen como coordinador. Uno de los protocolos de elección consiste en que los nodos dispongan de una ordenación lineal previamente acordada. Vamos a suponer que el nodo S¡ tiene el orden en la secuencia, siendo el coordinador el de menor orden; y vamos a suponer también que cada nodo conoce la identificación y ordenación de los otros nodos del sistema, algunos de los cuales pueden haber fallado también. Uno de los posibles protocolos de elección requiere que cada participante operativo envíe un mensaje a los nodos que tengan un número de identificación mayor que él mismo. Así, el nodo S¡ enviaría un mensaje a los nodos S¡+¡,S¡+2,... , S., en dicho orden. Si un nodo Skrecibe un mensaje de otro participante de menor número, Sk sabrá que él no debe ser el nuevo coordinador, y dejará de enviar mensajes. Este protocolo es relativamente eficiente y la mayoría de los participantes dejan de enviar mensajes rápidamente. Llega un momento en que cada participante sabe si hay otro participante operativo con un número menor. Si no lo hay, ese nodo pasará a ser el nuevo coordinador. Si el coordinador recién elegido también provocara un fallo de temporización durante este proceso, se invocaría de nuevo el protocolo de elección. Después de que se recupere un nodo fallido, éste da comienzo inmediatamente al protocolo de elección. Si no hay ningún otro nodo operativo con un número inferior, el nodo fuerza a todos los nodos con número mayor a dejarle ser el nuevo coordinador, independientemente de si ya había sido elegido un coordinador anteriormente.
i
Topologías de comunicación
para 2PC
Hay varias formas distintas de intercambiar mensajes, o topologías de comunicación, que pueden emplearse para implementar 2PC. La que acabamos de explicar se denomina 2PC centralizado, ya que todas las comunicaciones pasan a través del coordinador, como se muestra en la Figura 23.9(a). Se han propuesto diversas mejoras al protocolo 2PC centralizado que tratan de mejorar su rendimiento global, bien reduciendo el número de mensajes que hay que intercambiar, o bien acelerando el proceso de toma de decisiones. Estas mejoras necesitan que se adopten formas diferentes de intercambiar los mensajes. Una alternativa consiste en utilizar 2PC lineal, en el que los participantes pueden comunicarse entre sí, como se muestra en la Figura 23.9(b). En el2PC lineal, los nodo s están ordenados 1,2, ... , n, donde el nodo 1 es el coordinador y los nodos restantes son los participantes. El protocolo 2PC se implementa mediante una cadena directa de comunicación desde el coordinador hasta el participante n para la fase de votación y una cadena inversa de comunicación desde el participante n hasta el coordinador para la fase de decisión. En la fase de votación, el coordinador pasa la instrucción de voto al nodo 2, que vota y pasa su voto al nodo 3. El nodo 3 combina entonces su voto con el del nodo 2 y transmite el nodo combinado al nodo 4, etc. Cuando el participante n-ésimo añade su voto, se tendrá ya la decisión global, la cual se pasará hacia atrás a los participantes n - ], n - 2-, etc., terminando por llegar al coordinador. Aunque el protocolo 2PC lineal requiere menos mensajes que un protocolo 2PC centralizado, tiene la desventaja de que el secuenciamiento lineal no permite ningún tipo de paralelismo. El protocolo 2PC lineal puede mejorarse si el proceso de votación adopta el encaminamiento lineal hacia adelante de los mensajes, mientras que el proceso de decisión adopta la topología centralizada, de modo que el nodo n puede difundir la decisión global a todos los participantes en paralelo (Bernstein et al., 1987). Una tercera propuesta, conocida con el nombre de 2PC distribuido, utiliza una topología distribuida, como se muestra en la Figura 23.9(c). El coordinador envía el mensaje PREPARE a todos los participantes, que a su vez envían su decisión a todos los demás nodos. Cada participante espera a recibir los mensajes de los demás nodos antes de decidir si confirma o aborta la transacción. En la práctica, esto elimina la necesidad de que exista la fase de decisión del protocolo 2PC, ya que todos los participantes pueden alcanzar una decisión de manera coherente, pero independiente (Skeen, 1981).
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
•
Prepare
Fase 1
RC/Abort
GC/GA
~
Fase 2
683
Com mitted/ Aborted ~
(a)
Fase 1
Prepare
RC/Abort
RC/Abort
D
Nodo 1
GC/GA
Nodo 2
GC/GA
Nodo 3 Fase 2
Nodo 4 ~
(b)
(e)
Figura 23.9.
Topologías 2PC: (a) centralizada; (b) lineal; (c) distribuida. C = coordinador; p¡ = participante; RC = READY _COMMIT; GC = GLOBAL_COMMIT; GA = GLOBAL_ABORT.
23.4.4 Confirmación en tres fases (3PC) Hemos visto que 2PC no es un protocolo no bloqueante, ya que es posible que los nodos queden bloqueados en ciertas circunstancias. Por ejemplo, un proceso en el que se produzca un fin de temporización después de haber votado por la confirmación pero antes de recibir la instrucción global del coordinador quedará bloqueado si sólo puede comunicarse con otros nodos que tampoco se hayan podido enterar de cuál es la decisión global. La probabilidad de que el bloqueo se produzca en la práctica es lo suficientemente baja como para que la mayoría de los sistemas existentes utilicen 2PC. Sin embargo, existe un protocolo alternativo no bloqueante, denominado confirmación en tres fases (3PC) propuesto por (Skeen, 1981). La confirmación en tres fases es no bloqueante con respecto a los fallos de nodo, excepto en el caso de que fallen todos los nodos. Los fallos de comunicación pueden conducir, sin embargo, a que los diferentes nodos alcancen diferentes decisiones, violando por tanto el principio de atomicidad de las transacciones globales. El protocolo requiere que:
684
Sistemas de bases de datos
•
no pueda producirse un particionamiento
•
al menos uno de los nodo s debe estar siempre disponible;
de la red;
•
como máximo K nodos puedan fallar simultáneamente resistente).
(en este caso el sistema se clasifica como K-
La idea básica de 3PC consiste en eliminar el periodo de incertidumbre para aquellos participantes que hallan votado COMMIT y estén esperando la instrucción de confirmación o aborto global procedente del coordinador. La confirmación en tres fases introduce una tercera fase, denominada pre-confirmación, entre la votación y la decisión global. Al recibir los votos de todos los participantes, el coordinador envía un mensaje PRE-COMMIT global. Un participante que reciba la pre-confirmación global sabrá que todos los demás participantes han votado COMMIT y que, a su debido tiempo, el propio participante realizará la confirmación definitiva, a menos que falle. Cada participante confirma la recepción del mensaje PRE-COMMIT y, una vez que el coordinador ha recibido todas las confirmaciones, difunde el mensaje de confirmación global de la transacción. Un voto ABORT de un participante se gestionará exactamente de la misma manera que en 2PC. La Figura 23.10 muestra los nuevos diagramas de transición entre estados para un coordinador y para un participante. Tanto el coordinador como el participante siguen teniendo periodos de espera, pero la característica importante es que todos los procesos operativos habrán sido informados mediante el mensaje PRE-COMMIT de la decisión global de confirmar, antes de que el primer proceso realice la confirmación, por lo que pueden actuar independientemente en caso de fallo. Si el coordinador falla, los nodos operativo s pueden comunicarse entre sí y determinar si la transacción debe confirmarse o abortarse sin necesidad de esperar a que el coordinador se recupere. Si ninguno de los nodos operativo s ha recibido un mensaje PRE-COMMIT, abortarán la transacción. El procesamiento cuando todos los participantes votan COMMIT se muestra en la Figura 23.11. Vamos a analizar ahora brevemente los protocolos de terminación y recuperación para 3PC.
(b)
(a)
Figura 23.10.
Diagrama de transiciones entre estados para 3PC: (a) coordinador; (b) participante.
Capítulo 23 Basesde datos distribuidas: conceptos avanzados 685 Coordinador
Participante
Commit: escribir begin_commit en el registro enviar PREPARE a todos los participantes esperar las respuestas
Prepare: escribir ready_commit en el registro enviar READY_COMMIT al coordinador esperar por PRE_COMMIT o GLOBAL_ABORT
Pre commit: si todos los participantes han votado READY: escribir pre _commit en el registro enviar PRE_COMMIT a todos los participantes esperar las confirmaciones
Pre_commit: escribir entrada pre _commit en el registro enviar confirmación
Ready _ commit: una vez que al menos K participantes han confirmado el PRE_COMMIT: escribir entrada commit en el registro •• enviar GLOBAL_COMMIT a todos los participantes enviar confirmaciones
Global_commit: escribir entrada commit en el registro confirmar transacción enviar confirmación
Ack: si todos los participantes han confirmado: escribir end_of_transaction en el registro
Figura 23.11.
Protocolo 3PC para un participante que vota COMMIT.
Protocolos de terminación
para 3PC
Igual que con 2PC, la acción que haya que tomar dependerá del estado en el que estuviera el coordinador o el participante cuando se produjo el fin de temporización. Coordinador El coordinador puede estar en uno de los cinco estados durante el proceso de confirmación, como se muestra en la Figura 23.1O(a), pero sólo puede producirse un fin de temporización en tres de esos estados. Las acciones que habrá que tomar son las siguientes: •
Fin de temporización en el estado WAITING. Es igual que en 2PC. El coordinador está esperando a que todos los participantes confirmen si quieren confirmar o abortar la transacción, por lo que puede decidir abortar globalmente la transacción.
•
Fin de temporización en el estado PRE-COMMITTED. Ya se ha enviado a los participantes el mensaje PRE-COMMIT, por lo que los participantes estarán en los estados PRE-COMMIT o READY. En este caso, el coordinador puede completar la transacción escribiendo la entrada commit en el archivo de registro y enviando el mensaje GLOBAL-COMMIT a los participantes.
•
Fin de temporización en el estado DECIDED. Es igual que en 2PC. El coordinador está esperando que todos los participantes confirmen si han abortado o confirmado con éxito la transacción, por lo que pueden simplemente enviar la decisión global a todos los nodos que todavía no hayan enviado su mensaje de confirmación.
Participante El participante puede estar en uno de los cinco estados durante el proceso de confirmación, como se muestra en la Figura 23.10(b), pero sólo puede producirse un fin de temporización en tres estados. Las acciones que habrá que tomar son las siguientes: •
Fin de temporización en el estado INITIAL. Es igual que en 2PC. El participante está esperando recibir el mensaje PREPARE, por lo que puede abortar unilateralmente la transacción.
686
Sistemas de bases de datos
•
Fin de temporización en el estado PREPARED. El participante ha enviado su voto al coordinador y está esperando recibir el mensaje PRE-COMMIT o ABORT. En este caso, el participante ejecutará un protocolo de elección para elegir un nuevo coordinador de la transacción y realizará la terminación como se explica más adelante.
•
Fin de temporización en el estado PRE-COMMlTTED. El participante ha enviado la confirmación correspondiente al mensaje PRE-COMMIT y está esperando el mensaje COMMIT. De nuevo, el participante seguirá un protocolo de elección para elegir un nuevo coordinador para la transacción y llevará a cabo el proceso de terminación como se explica más adelante.
Protocolos de recuperación
para 3PC
Al igual que con 2PC, la acción que habrá que realizar durante el inicio dependerá del estado que hubiera alcanzado el coordinador o participante en el momento del fallo.
Fallo del coordinador Consideremos cuatro estados diferentes de fallo de coordinador: •
Fallo en el estado INITIAL. El coordinador todavía no ha dado comienzo al proceso de confirmación. La recuperación consiste, en este caso, en reiniciar el proceso de confirmación.
•
Fallo en el estado WAITING Los participantes pueden haber elegido un nuevo coordinador y haber terminado la transacción. Durante el reinicio, el coordinador deberá contactar a otros nodos para determinar cuál fue el destino de la transacción.
•
Fallo en el estado PRE-COMMITTED. De nuevo, los participantes pueden haber elegido un nuevo coordinador y haber terminado la transacción. Durante el reinicio, el coordinador debe contactar a otros nodos para determinar cuál ha sido el destino de la transacción.
•
Fallo en el estado DECIDED. El coordinador ya ha enviado una instrucción a todos los participantes para abortar o confirmar globalmente la transacción. Durante el reinicio, si el coordinador ha recibido todas las confirmaciones, puede completar la transacción adecuadamente. En caso contrario, tendrá que iniciar el protocolo de terminación correspondiente.
Participante Consideramos cuatro estados distintos para el fallo de un participante: •
Fallo en el estado INIT1AL. El participante no ha votado todavía sobre la transacción. Por tanto, durante la recuperación, puede abortar unilateralmente la transacción.
•
Fallo en el estado PREPARED. El participante ha enviado su voto al coordinador. En este caso, el participante debe contactar a otros nodos para determinar cuál ha sido el destino de la transacción.
•
Fallo en el estado PRE-COMMlTTED. El participante debe contactar a otros nodos para determinar cuál ha sido el destino de la transacción.
•
Fallo en los estados ABORTED/COMMITTED. El participante ha completado tanto, no es necesario llevar a cabo ninguna acción adicional durante el reinicio.
Protocolo de terminación
la transacción.
Por
después de la elección de un nuevo coordinador
Puede utilizarse el protocolo de elección que hemos explicado para 2PC con el fin de que los participantes elijan un nuevo coordinador después de producirse un fin de temporización. El coordinador recién elegido enviará un mensaje STATE-REQ a todos los participantes implicados en la elección, para tratar de determinar cuál es el mejor modo de continuar con la transacción. El nuevo coordinador puede usar las siguientes reglas: (1) Si algún participante ha abortado la transacción, la decisión global será abortar. (2) Si algún participante ha confirmado la transacción, la decisión global será confirmar. (3) Si todos los participantes que respondan todavía no han decidido, la decisión será abortar.
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
687
(4) Si algún participante puede confirmar la transacción (porque está en el estado PRE-COMMIT), la decisión global será confirmar. Para impedir el bloqueo, el nuevo coordinador enviará primero el mensaje PRE-COMMIT y, una vez que todos los participantes hayan confirmado la recepción del mensaje, enviará el mensaje GLOBAL-COMMIT.
23.4.5 Particionamiento de la red Cuando se produce una partición de la red, mantener la coherencia de la base de datos puede ser más dificil, dependiendo de si los datos están replicados o no. Si los datos no están replicados, podemos permitir que la transacción continúe si ésta no requiere ningún dato de un nodo que esté situado fuera de la partición en la que haya sido iniciada. En caso contrario la transacción deberá esperar hasta que los nodos a los que necesite acceder vuelvan a estar disponibles. Si los datos están replicados, el procedimiento es mucho más complicado. Vamos a considerar dos ejemplos de anomalías que pueden surgir con los datos replicados en una red particionada, utilizando como ejemplo una relación simple de cuentas bancarias que contienen el saldo de un cliente.
Identificación de las actualizaciones Las operaciones de actualización adecuadamente completadas por los usuarios de diferentes particiones pueden ser difíciles de observar, como se ilustra en la Figura 23.12. En la partición p¡, una transacción ha retirado 10 euros de una cuenta (con saldo bal,) y en la partición P2, dos transacciones han retirado cada una 5 euros de la misma cuenta. Suponiendo que al principio ambas particiones tuvieran 100 euros como valor de bal" al completar las operaciones ambas tendrán un valor de balx igual a 90 euros. Cuando las particiones se recuperen, no será suficiente comprobar el valor en balx y asumir que los campos son coherentes si los valores son iguales. En este caso, el valor después de ejecutar las tres transacciones debería ser de 80 euros.
Mantenimiento de la integridad Las operaciones de actualización que los usuarios en las diferentes particiones completen con éxito pueden fácilmente violar las restricciones de integridad, como se ilustra en la Figura 23.13. Suponga que un banco impone una restricción a la cuenta de un cliente (con saldo balx), de modo que dicha cuenta no pueda bajar de O euros. En la partición P ¡, una transacción ha retirado 60 euros de la cuenta y en la partición P 2, otra transacción ha retirado 50 euros de la misma cuenta. Suponiendo que al principio ambas particiones tuvieran un saldo balx de 100 euros, al completar las operaciones una de las particiones tendrá un valor de balx igual a 40 euros y la otra tendrá 50 euros. Observe que ninguna de las dos particiones ha violado la restricción de integridad. Sin embargo, al recuperarse las particiones e implementar completamente ambas transacciones, el saldo de la cuenta será de -10 euros y la restricción de integridad habrá sido violada. El procesamiento dentro de una red particionada implica un compromiso entre la disponibilidad y la corrección (Davidson, 1984; Davidson et al., 1985). La forma más fácil de proporcionar una corrección absoluta es no permitiendo ningún procesamiento de los datos replicados mientras dura la situación de particionaTiempo
p¡ begin_transaction balx = balx - la write(balx) commit
begin_transaction balx = balx - 5 write(balx) comlnit begin_transaction balx = balx - 5 write(balx) commit
Figura 23.12.
Identificación de actualizaciones.
688
Sistemas de bases de datos
Tiempo begin_transaction balx = balx - 60 write(balx) commit
Figura 23.13.
begin_transaction balx = balx - 50 write(balxl commit
Mantenimiento de la integridad.
miento. Por otro lado, la disponibilidad se maximizará si no se impone ninguna restricción al procesamiento de los datos replicados durante la condición de particionamiento. En general, no resulta posible diseñar un protocolo de confirmación atómica no bloqueante para redes arbitrariamente particionadas (Skeen, 1981). Puesto que las técnicas de recuperación y de control de concurrencias están tan relacionadas, las técnicas de recuperación que se utilicen después de producirse un particionamiento de la red dependerán de la estrategia concreta de control de concurrencia que se esté utilizando. Los métodos utilizables pueden clasificarse en dos grupos: pesimistas y optimistas. Protocolos
pesimistas
Los protocolos pesimistas priman la coherencia de la base de datos con respecto a la disponibilidad y no permiten, por tanto, que se ejecuten transacciones en una partición si no existe una garantía de que se puede mantener la coherencia. El protocolo utiliza un algoritmo de control de concurrencia pesimista, como por ejemplo el 2PL de copia principal o el protocolo de bloqueo mayoritario, como se explica en la Sección 23.2. Los mecanismos de recuperación, utilizando esta técnica, son mucho más sencillos, ya que las actualizaciones habrán estado confinadas a una única partición perfectamente determinada. Las operaciones de recuperación de la red implicarán, simplemente, propagar todas las actualizaciones a todos los demás nodos. Protocolos
optimistas
Los protocolos optimistas, por el contrario, priman la disponibilidad de la base de datos a expensas de la coherencia, y emplean una técnica optimista de control de concurrencia en la que se permite que las actualizaciones tengan lugar independientemente en las distintas particiones. Por tanto, es posible que se detecten incoherencias cuando los nadas se recuperen. Para determinar si existen incoherencias, pueden utilizarse grafos de precedencia para controlar las dependencias entre los datos. Los grafos de precedencia son similares a los grafos de espera que hemos analizado en la Sección 20.2.4, y muestran qué transacciones han leído y escrito cada elemento de datos. Mientras que la red está particionada, las actualizaciones se llevan a cabo sin ninguna restricción y cada partición mantiene sus propios grafos de precedencia. Una vez que la red se ha recuperado, se combinan los grafos de precedencia de todas las particiones. Las incoherencias se ponen de manifiesto por la existencia de un ciclo en el grafo. La resolución de la incoherencias dependerá de la semántica de las transacciones y no resulta, por tanto, posible de manera general que el gestor de recuperación re-establezca la coherencia sin intervención del usuario.
23.5 El modelo X10pen de procesamiento distribuido de transacciones Open Group es un consorcio internacional de usuarios, fabricantes de software y fabricantes de hardware que tiene como misión contribuir a la creación de una infraestructura global de la información viable. Fue formado en febrero de 1996 por la fusión de X/Open Company Ud (fundada en 1984) y de Open Software Foundation (fundada en 1988). X/Open estableció el grupo de trabajo para procesamiento distribuido de transacciones (DTP, Distributed Transaction Processing) con el objetivo de especificar y promover interfaces de programación apropiadas para el procesamiento de transacciones. En aquella época, sin embargo, los sistemas
Capítulo 23 Basesde datos distribuidas: conceptos avanzados 689 de procesamiento de transacciones eran entornos operativo s completos, que abarcaban desde la definición de las interfaces en pantalla hasta la implementación de la base de datos. En lugar de tratar de proporcionar un conjunto de estándares para cubrir todas las áreas, el grupo se concentró en aquellos elementos de un sistema de procesamiento de transacciones que proporcionaban las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad) que hemos presentado en la Sección 20.1.1. El están dar (de jure) DTP de X/Open que resultó de ese esfuerzo normativo especificaba tres componentes que interactuaban entre sí: una aplicación, un gestor de transacciones (TM, transaction manager) y un gestor de recursos (RM, resource manager) El gestor de recursos puede ser cualquier subsistema que implemente datos transacciones, como por ejemplo un sistema de base de datos, un sistema de archivos transaccional o un gestor de sesión transaccional. El TM es responsable de definir el ámbito de una transacción, es decir, qué operaciones forman parte de la transacción. También es responsable de asignar una identificación unívoca a la transacción que pueda compartirse con otros componentes, así como de coordinar a los otros componentes para determinar el resultado de la transacción. Un TM puede comunicarse también con otros TM para coordinar la finalización de las transacciones distribuidas. La aplicación llama al TM para iniciar una transacción y luego llama a uno o más RM para manipular los datos, de acuerdo con la lógica de la aplicación, para finalmente volver a invocar al TM para terminar la transacción. El TM se comunica con los RM para coordinar la transacción. Además, el modelo X/Open define varias interfaces, como se ilustra en la Figura 23.14. Una aplicación puede utilizar la interfaz TX para comunicarse con un TM. La interfaz TX proporciona llamadas que definen el ámbito de la transacción (algunas veces denominado demarcación de la transacción) y que permiten indicar si hay que confirmar/abortar la transacción. Un TM intercambia información transaccional con los RM a través de la interfaz XA. Finalmente, una aplicación puede comunicarse directamente con los RM mediante una interfaz de programación nativa, como por ejemplo SQL o ISAM. La interfaz TX está compuesta de los siguientes procedimientos: •
tx_open y tx_close, para abrir y cerrar una sesión con un TM;
•
tx_begin, para iniciar una nueva transacción;
•
tx_commit y tx_abort para confirmar y abortar una transacción.
La interfaz XA está compuesta de los siguientes procedimientos: •
xa_open y xa_close, para conectarse y desconectarse con un RM;
•
xa_start y xG_end, para iniciar una nueva transacción con el ID de transacción proporcionado finalizarla;
•
xa Jollback,
para anular la transacción con el ID de transacción indicado;
•
xayrepare, to global;
para preparar la transacción con el ID de transacción indicado para su confirmación/abor-
•
xa_commit, para confirmar globalmente la transacción con el ID de transacción indicado;
•
xa _recover, para extraer una lista de transacciones preparadas, heurísticamente confirmadas o heurísticamente abortadas. Cuando un RM está bloqueado, un operador puede imponer una decisión heurística (generalmente, abortar), permitiendo así que se liberen los recursos bloqueados. Cuando el TM Aplicación
Llamadas nativas (p. e. Sal)
XA
TM
RM Prepare, Commit, Abort
Figura 23.14.
Interfaces X/Open.
y para
690
Sistemas de bases de datos se recupere, esta lista de transacciones puede utilizarse para informar a las transacciones dudosas de cuál es la decisión tomada (confirmar o abortar). A partir de los datos contenidos en el registro, también pueden notificar a la aplicación si existen decisiones heurísticas erróneas .
•
xaJorget,
para permitir a un RM olvidar la transacción heurística con el ID de transacción indicado.
Por ejemplo, considere el siguiente fragmento de código de aplicación: tx_beginO; EXEC SQL UPDATE EXEC SQL UPDATE
8taft SET salary = salary *1.05 8taft SET salary = salary *1.04
WHERE WHERE
position = 'Manager'; position <> 'Manager';
tx_commitO; Cuando la aplicación invoque la función tx_beginO CL! (call-level interface, interfaz de nivel de llamada), el TM marcará en el registro el inicio de la transacción y asignará a ésta una identificación unívoca. Después, el TM utiliza XA para informar al servidor de base de datos SQL de que hay una transacción en progreso. Una vez que un RM ha recibido esta información, asumirá que todas las llamadas que reciba de la aplicación forman parte de la transacción, en este caso las dos instrucciones de actualización SQL. Finalmente, cuando la aplicación invoque la función tx_commitO, el TM interactuará con el RM para confirmar la transacción. Si la aplicación estaba trabajando con más de un RM, el TM utilizará en este punto el protocolo de confirmación en dos fases para sincronizar la confirmación con los RM. En el entorno distribuido, tenemos que modificar el modelo descrito para permitir que una transacción esté compuesta por subtransacciones, cada una de ellas ejecutándose en un nodo remoto y operando sobre una base de datos remota. El modelo DTP X/Open para un entorno distribuido se ilustra en la Figura 23.15. El modelo X/Open se comunica con las aplicaciones a través de un tipo especial de gestor de recursos denominado gestor de comunicaciones (CM, Communications Manager). Como todos los gestores de recursos, el CM recibe la información sobre las transacciones de los TM, y las aplicaciones hacen llamadas a un CM utilizando su interfaz nativa. En este caso, hacen falta dos mecanismos: un mecanismo de invocación remota y un mecanismo de transacciones distribuidas. La invocación remota es proporcionada mediante ROSE (Remote Operations Service, servicio de operaciones remotas) de ISO y mediante mecanismos RPC (Remote Procedure Call, llamada a procedimiento remoto). X/Open especifica el protocolo de comunicaciones OSI- TP (Open Systems Interconnection Transaction Processing, procesamiento de transacciones para interconexión de sistemas abiertos) para coordinar las transacciones distribuidas (la interfaz TM-TM) El X/Open DTP no sólo soporta transacciones planas, sino también transacciones encadenadas y anidadas (véase la Sección 20A). Con las transacciones anidadas, una transacción se abortará si cualquiera de las subtransacciones lo hace.
Begin, Commit, Abort
Iniciar
RM
RM Solicitud remota
Figura 23.15.
Interfaces X/Open en un entorno distribuido.
Capítulo 23 Basesde datos distribuidas: conceptos avanzados
691
El modelo de referencia XlOpen está bastante establecido dentro del sector. Diversos monitores de procesamiento de transacciones soportan la interfaz TX y muchos fabricantes de bases de datos comerciales proporcionan una implementación de la interfaz XA. Entre los principales ejemplos podemos citar CICS y Encina de IBM (que se utiliza principalmente en IBM AIX o Windows NT y que están ahora incluidos en 1MB TXSeries), Tuxedo de BEA Systems, Oracle, Informix y SQL Server.
23.6 Optimización de consultas distribuidas En el Capítulo 21 hemos analizado el tema del procesamiento y optimización SGBD centralizados. Allí vimos dos técnicas para la optimización de consultas:
de consultas para sistemas
•
la primera utilizaba reglas heurísticas para ordenar las operaciones de una consulta;
•
la segunda, comparaba diferentes estrategias basándose en sus costes relativos y seleccionaba aquella que minimizaba el uso de recursos.
En ambos casos, representábamos la consulta mediante un árbol del álgebra relacional para facilitar el procesamiento ulterior. La optimización de consultas distribuidas es más compleja debido a la distribución de los datos. La Figura 23.16 muestra cómo se procesa y optimiza la consulta distribuida en forma de una serie de niveles independientes, que son los siguientes: •
Descomposición de la consulta. Este nivel toma una consulta expresada con respecto a las relaciones globales y realiza una optimización parcial empleando las técnicas explicadas en el Capítulo 21. La salida es algún tipo de árbol del álgebra relacional basado en las relaciones globales. Consulta del cálculo relacional sobre los fragmentos
Esquema global
Consulta de álgebra relacional parcialmente optimizada
Ejecución en el nodo de control
Esquema de fragmentación
Consulta reducida sobre los fragmentos
Datos estadisticos de los fragmentos
Consulta optimizada sobre los fragmentos con primitivas de comunicación
Esquemas locales Ejecución en los nodos locales {
Consultas locales optimizadas
Figura 23.16.
Procesamiento
de consultas distribuidas.
692
Sistemas de bases de datos
•
Localización de los datos. Este nivel toma en consideración el modo en que han sido distribuidos los datos. Se realiza otra iteración de optimización, sustituyendo las relaciones globales de las hojas del árbol de álgebra relacional por sus algoritmos de reconstrucción (algunas veces denominados programas de localización de datos), es decir, las operaciones del álgebra relacional que reconstruyen las relaciones globales a partir de los fragmentos constituyentes.
•
Optimización global. Este nivel toma en consideración la información estadística para determinar un plan de ejecución casi óptimo. La salida de este nivel es una estrategia de ejecución basada en fragmentos a la que se han añadido primitivas de comunicación para enviar partes de la consulta a los SGBD locales con el fin de que se ejecuten allí y poder luego recibir los resultados.
•
Optimización local. Mientras que los primeros tres niveles se ejecutan en el nodo de control (normalmente, el nodo que ha iniciado la consulta), este nivel concreto se ejecuta en cada uno de los nodos locales implicados en la consulta. Cada SGBD local realizará su propia optimización local utilizando las técnicas descritas en el Capítulo 21.
Vamos ahora a analizar los dos niveles intermedios de esta arquitectura.
23.6.1
Localización de los datos
Como hemos dicho antes, el objetivo de este nivel es tomar una consulta expresada en forma de algún tipo de árbol del álgebra relacional y tener en cuenta la distribución de los datos para llevar a cabo alguna optimización ulterior utilizando reglas heurísticas. Para hacer esto, sustituimos las relaciones globales situadas en las hojas del árbol por sus algoritmos de reconstrucción, es decir, las operaciones del álgebra relacional que permiten reconstruir las relaciones globales a partir de los fragmentos constituyentes. Para la fragmentación horizontal, el algoritmo de reconstrucción es la operación de unión; para la fragmentación vertical, es la operación de combinación. El árbol del álgebra relacional formado al aplicar los algoritmo s de reconstrucción se conocen en ocasiones con el nombre de árbol genérico de álgebra relacional. Después, usamos técnicas de reducción para generar una consulta más simple y optimizada. La técnica concreta de reducción que empleemos dependerá del tipo de fragmentación del que estemos hablando. Vamos a considerar las técnicas de reducción para los siguientes tipos de fragmentación: •
fragmentación horizontal primaria;
•
fragmentación vertical;
•
fragmentación horizontal derivada.
Reducción para la fragmentación horizontal primaria Para la fragmentación horizontal primaria, vamos a considerar dos casos: la reducción con la operación de selección y la reducción para la operación de combinación. En el primer caso, si el predicado de selección contradice la definición del fragmento, tendremos como resultado una relación intermedia vacía y las operaciones pueden ser eliminadas. En el segundo caso, primero usamos la regla de transformación que permite conmutar la operación de combinación y la operación de unión: (R,
u
R2)
I>
u (R2
I>
Después examinamos cada una de las operaciones de combinación individuales para determinar si hay alguna combinación redundante que pueda eliminarse del resultado. Existirá una combinación redundante si los predicados de los fragmentos no se solapan. Esta regla de transformación es importante en los SGBDD, permitiendo implementar una combinación de dos relaciones o una unión de combinaciones parciales, pudiendo cada parte de la unión realizarse en paralelo. El uso de estas dos reglas de reducción se ilustra en el Ejemplo 23.2.
Reducción para la fragmentación vertical La reducción para la fragmentación vertical implica eliminar aquellos fragmentos verticales que no tengan atributos en común con los atributos de proyección, excepto la clave de la relación.
Capítulo 23 Bases de datos distribuidas:
I
Ejemplo 23.2 Reducción para la fragmentación
horizontal
conceptos avanzados
693
primaria
Enumerar los apartamentos en alquiler junto con los correspondientes
detalles de la sucursal.
Podemos expresar esta consulta en SQL como:
SELECT * FROM Branch WHERE
b, PropertyForRent
b.branchNo
= p.branchNo
Ahora, supongamos siguiente:
que
p
AND
p.type
y
PropertyForRent
'Flat';
=
Branch
están fragmentados
horizontalmente
ab,.nchNo='B003· A type='House·(PropertyForRent)
8,:
abranchNO='BOO3,(Braneh)
ab,.nchNo='BOO3· A type='Flar(PropertyForRent)
B2:
abranchNo='BOOABranch)
de la forma
abranchNo!='BOO3'( P ro pe rtyF o rRent)
/~
/~
t>
t>
i /~ /i~ 0p.type='Flat'
8,
U
u
U
u
/~ /~
82
i
P2
0p.type='Flat'
P,
8,
B2
(b)
(a)
u ~~ i>
t:xl"b.branchNo=p.branchNo
1\
1\
P2
l>
1\
i
82
0p.type=·Flat' 8,
(e)
I>
1\
i
°p.type='Flat'
82
u ~~ CXJb.branchNo=p.branchNo
1\
P2
(d)
8,
t>
1\
0p.type='Flat'
i
82
Figura 23.17. Árboles del álgebra relacional para el Ejemplo 23.2: (a) árbol genérico; (b) árbol resultante de la reducción por selección; (c) árbol resultante de conmutar la combinación y la unión; (d) árbol reducido.
694 Sistemas de bases de datos El árbol genérico de álgebra relacional para esta consulta se muestra en la Figura 23.17(a). Si conmutamos las operaciones de selección y de unión, se obtiene el árbol de álgebra relacional mostrado en la Figura 23.17(b). Este árbol puede obtenerse observando que la siguiente rama del árbol es redundante (no produce ninguna tupla que contribuya al resultado) y puede ser eliminada:
,)
=
branchNo(Staff)
El árbol genérico de álgebra relacional para esta consulta se muestra en la Figura 23 .18(a). Conmutando las operaciones de proyección y combinación, la operación de proyección sobre SI es redundante, porque los atributos de proyección fName y IName no son parte de SI' El árbol reducido se muestra en la Figura 23.18(b).
0.'1"I><1staffNo
/~ (a)
Figura 23.18.
(b)
Árboles del álgebra relacional para el Ejemplo 23.3: (a) árbol genérico; (b) árbol reducido.
Reducción para la fragmentación
horizontal derivada
La reducción para la fragmentación horizontal derivada utiliza, de nuevo, la regla de transformación que permite conmutar las operaciones de combinación y de unión. En este caso, utilizamos el hecho de que la fragmentación para una relación está basada en la otra relación y, al efectuar la conmutación, algunas de las combinaciones parciales deben ser redundantes.
Capítulo 23 Basesde datos distribuidas: conceptos avanzados
I
Ejemplo
23.4
Reducción
para la fragmentación
horizontal
695
derivada
Enumerar los clientes registrados en la sucursal B003 junto con los detalles de la sucursal. Podemos expresar esta consulta en SQL como:
SELECT * FROM Branch b, Client e WHERE
b.branchNo = c.branchNo AND b.branchNo = 'B003';
Vamos a asumir que Branch está fragmentada horizontalmente mentación de Client está derivada de Branch:
como en el Ejemplo 23.2 y que la frag-
B1 = O'sbranchNo='B003,(Branch) B2 = O'sbranchNol='B003,(Branch) C¡ = Client~branchNo B¡ i = 1, 2
El árbol genérico del álgebra relacional se muestra en la Figura 23.19(a). Si conmutamos las operaciones de selección y de unión, la selección sobre el fragmento B2será redundante y esta rama del árbol puede eliminarse. Toda la operación de selección puede eliminarse, ya que el fragmento BI está definido sobre la sucursal B003. Si ahora conmutamos las operaciones de combinación y de unión, se obtiene el árbol mostrado en la Figura 23.19(b). La segunda operación de combinación entre BI y c2 produce una relación nula y puede eliminarse, lo que nos deja el árbol reducido de la Figura 23 .19( c).
/~
u
/\
lXIb.branchNo=c.branchNo
(a)
(b)
/\
t>
/\
t>
No
(e)
Figura 23.19. Árboles del álgebra relacional para el Ejemplo 23.4: (a) árbol genérico; (b) árbol resultante de conmutar la combinación y la unión; (c) árbol reducido.
23.6.2
Combinaciones distribuidas
La combinación es una de las operaciones más caras del álgebra relaciona!. Una técnica utilizada en la optimización de consultas distribuidas consiste en sustituir las combinaciones por una serie de semicombinaciones (véase la Sección 4.1.3). La operación de semicombinación tiene la importante propiedad de reducir el tamaño de la relación operando. Cuando el principal componente de coste es el tiempo de conmutación, la operación de semicombinación resulta particularmente útil para mejorar el procesamiento de las consultas distribuidas, ya que reduce la cantidad de datos que hay que transferir entre unos nodos y otros. Por ejemplo, suponga que queremos evaluar la expresión de combinación RI ~x R2 en el nodo S2' donde RI y R2 son fragmentos almacenados en los nodos SI y S2' respectivamente, RI y R2 están definidas sobre los atributos A = (x, al' a2, ••• , an) y B = (x, b], b2, ... , bm), respectivamente. Podemos cambiar esto para utilizar, en su lugar, la operación de semi combinación. En primer lugar, observe que podemos reescribir una combinación como:
696
Sistemas de bases de datos
R, ~x
R2 =
(R, ~x
R2)
~x
R2
Por tanto, podemos evaluar la operación de combinación de la forma siguiente: (1) Evaluar R' = IllR2) en S2 (sólo se necesitan atributos de combinación en SI)' (2) Transferir R' al nodo SI' (3) Evaluar R" = R¡ ~x R' en SI' (4) Transferir R" al nodo Sz. (5) Evaluar R" I>
23.6.3
Optimización global
Como hemos explicado antes, nivel de localización de datos ción de consultas centralizada rentes estrategias de ejecución
el objetivo de este nivel consiste en tomar el plan de consulta reducido para el y hallar una estrategia de ejecución casi óptima. Al igual que con la optimizaque hemos analizado en la Sección 21.5, esto implica evaluar el coste de difey seleccionar la estrategia óptima en dicho espacio de búsqueda.
Costes En un SGBD centralizado, el coste de ejecución es una combinación de los costes de E/S y de procesador. Puesto que el acceso a disco es lento comparado con el acceso a memoria, el acceso a disco tiende a ser el coste dominante en el procesamiento de consultas para un SGBD centralizado, y es en él, precisamente, donde nos hemos concentrado exclusivamente a la hora de proporcionar estimaciones de costes en el Capítulo 21. Sin embargo, en el entorno distribuido es necesario tomar en consideración la velocidad de la red subyacente a la hora de comparar las diferentes estrategias. Como hemos mencionado en la Sección 22.5.3, una red de área extensa (WAN) puede tener un ancho de banda de sólo unos pocos kilobytes por segundo, en cuyo caso podríamos ignorar los costes del procesamiento local. Por otro lado, una red de área local (LAN) es normalmente mucho más rápida que una WAN, aunque sigue siendo más lenta que el acceso a disco, pero en este caso no hay ningún coste que domine sobre los demás y será preciso tener en cuenta todos ellos. Además, para un SGBD centralizado hemos considerado un modelo de costes basado en el coste total (tiempo) de todas las operaciones de la consulta. Otro modelo de coste alternativo se basa en el tiempo de respuesta, es decir, en el tiempo transcurrido desde el inicio de la consulta hasta su terminación. Este otro modelo toma en consideración el paralelismo inherente a los sistemas distribuidos. Los dos modelos de coste pueden producir resultados diferentes. Por ejemplo, considere la transferencia de datos ilustrada en la Figura 23.20, donde se transfieren x bits de datos desde el nodo 1 al nodo 2 e y bits de datos desde el nodo 2 al nodo 3. Utilizando una fórmula de coste total, el coste de estas operaciones será: ybits
~ Nodo 3
Tiempo total ~ 2*Co + (x + y)/tasa_transmisión Tiempo de respuesta = max{Co + (x/tasa_transmisión), Co + (y/tasa_transmisión))
Nodo 1
Figura 23.20.
Ejemplo del efecto de los diferentes modelos de coste cuando se transfieren datos entre nadas.
Capítulo 23 Basesde datos distribuidas: conceptos avanzados Tiempo total
= 2*Co+
(x
697
+ y)/tasa_transmisión
Utilizando la fórmula del tiempo de respuesta, el coste de estas operaciones será: Tiempo de respuesta
= max
{Co
+ (x/tasa_transmisión),
Co
+ (y/tasa_transmisión)}
En lo que resta de esta sección, vamos a analizar dos algoritmos de optimización de consultas distribuidas: •
algoritmo R *;
•
algoritmo SDD-l.
Algoritmo R* R * era un SGBD distribuido experimental desarrollado en IBM Research a principios de la década de 1980 y . que incorporaba muchos de los mecanismos del anterior proyecto System R, adaptados a un entorno distribuido (Williams et al., 1982). Los principales objetivos de R * eran la transparencia de ubicación, la autonomía de los sitios y un mínimo sacrificio de las prestaciones. Las principales ampliaciones a System R para soportar la distribución de datos estaban relacionadas con la definición de los datos, la gestión de transacciones, el control de autorización y la compilación, optimización y ejecución de consultas. Para la distribución de consultas distribuidas R * utiliza un modelo de costes basado en el coste total y un mecanismo de optimización de consultas estático (Selinger y Abida, 1980; Lohman et al., 1985). Al igual que el optimizador centralizado de System R, el algoritmo de optimización está basado en una búsqueda exhaustiva de todas las ordenaciones de las combinaciones, de todos los métodos de combinación (bucle anidado o combinación de ordenación-mezcla) y de todas las rutas de acceso para cada relación, como se explica en la Sección 21.5. Cuando se requiere llevar a cabo una combinación que implique relaciones almacenadas en diferentes nodos, R * selecciona los nodos que tienen que efectuar la combinación y el método de transferir los datos entre los nodos. Para una combinación (R b
nodo 1, donde está ubicada la relación R;
•
nodo 2, donde está ubicada la relación S;
•
algún otro nodo (por ejemplo, el nodo de una relación de R y S).
T
que haya que combinar con la combinación
En R * hay dos métodos para transferir datos entre los nodos: (1) Transmitir toda la relación. En este caso, se transfiere la relación completa al nodo de combinación, donde se la almacena temporalmente antes de ejecutar la combinación o donde se la combina tupla a tupla según éstas van llegando. (2) Extraer las tuplas según sea necesario. En este caso, el nodo correspondiente a la relación externa coordina la transferencia de las tuplas y las utiliza directamente sin almacenadas de manera temporal. El nodo coordinador explora secuencialmente la relación externa y solicita, para cada valor, las tuplas correspondientes del nodo donde se encuentra la relación interna (lo que equivale en la práctica a efectuar una semicombinación de tupla en tupla, aunque hace falta enviar más mensajes que con la semicombinación). El primer método requiere una mayor transferencia de datos, pero un menor número de mensajes que el segundo método. Aunque podría utilizarse cualquier método de combinación con cada uno de los métodos de transmisión, R* considera que merecen la pena los siguientes: (1) Bucle anidado, enviando toda la relación externa al nodo donde está almacenada la relación interna En este caso, no hay necesidad de utilizar ningún almacenamiento temporal y las tuplas pueden combinarse a medida que van llegando al nodo de la relación interna. El coste es: Coste total = coste (bucle anidado) + [Co + (nTuples(R)*nBitslnTuple(R)/tasa_transmisión)]
698
Sistemas de bases de datos
(2) Combinación de ordenación-mezcla, enviando toda la relación interna al nodo donde está almacenada la relación externa En este caso, las tuplas no pueden combinarse a medida que llegan y es preciso almacenadas en una relación temporal. El coste es: Coste total = coste(almacenando S en el nodo 1) + coste (ordenación-mezcla) + [Co + (nTuples(s)*nBitsInTuple(S)/tasa _transmisión)] (3) Bucle anidado, extrayendo las tuplas de la relación interna según vaya siendo necesario para cada tupla de la relación externa De nuevo, las tuplas pueden combinarse a medida que llegan. El coste es: Coste total = coste (bucle anidado) + nTuples(R)*[Co + (nBitsInAttribute(A)/tasa _transmisión)] + nTuples(R)*[Co + (AVG(R, S)*nBitsInTuple(S)/tasa_transmisión)] donde AVG(R, S) denota un número de tuplas de S que (como promedio) se corresponden tupla de R, es decir AVG(R, S) = nTuples(S
1>
con cada
A R)/nTuples(R)
(4) Combinación de ordenación-mezcla, extrayendo las tuplas de la relación interna según vaya siendo necesario para cada tupla de la relación externa De nuevo, pueden combinarse las tuplas a medida que vayan llegando. El coste es similar al anterior y se deja como ejercicio para el lector. (5) Enviar ambas relaciones a un tercer nodo La relación interna se transfiere al tercer nodo y se almacena en una relación temporal. La relación externa se transfiere entonces al tercer nodo y sus tuplas se combinan con la relación temporal a medida que van llegando. Puede utilizarse tanto la combinación de bucle anidado como la de ordenación-mezcla en este caso. El coste puede deducirse a partir de los costes que antes hemos proporcionado y se deja como ejercicio para el lector. Aunque R * se ve obligado a evaluar muchas estrategias utilizando este enfoque, esta forma de actuar puede merecer la pena si la consulta se ejecuta frecuentemente. Aunque el algoritmo descrito por Selinger y Abida tiene en cuenta la fragmentación, la versión del algoritmo implementada en R * sólo trata con relaciones completas."
Algoritmo SDD-1 SDD-l fue otro SGBD distribuido experimental desarrollado por la división de investigación de Computer Corporation de América a finales de la década de 1970 y principios de la de 1980, que se ejecutaba en una red de computadoras PDP-l1 de DEC conectadas a través de Arpanet (Rothnie et al., 1980). Proporcionaba una independencia completa con respecto a la ubicación, fragmentación y a la replicación. El optimizador del SDD-l estaba basado en un método anterior conocido con el nombre de algoritmo de 'escalada de la colina', un algoritmo que comienza con una solución factible inicial que luego se va mejorando iterativamente (Wong, 1977). Fue modificado para hacer uso del operador de semicombinación con el fin de reducir la cardinalidad de los operandos de combinación. Al igual que el algoritmo R * el objetivo del optimizador SDD-l consiste en minimizar el coste total, aunque a diferencia de R * ignora los costes de procesamiento local y se concentra en el tamaño de los mensajes de comunicaciones. De nuevo igual que el R *, la temporización de procesamiento de las consultas que se utiliza es estática. El algoritmo está basado en el concepto de 'semicombinaciones beneficiosas'. El coste de comunicación de una semicombinación es simplemente el coste de transferir el atributo de combinación del primer operando al nodo del segundo operando, es decir: Coste de comunicación (R 1>AS) = Co + [size(TIA(S))/tasa_transmisión] = Co + [nTuples(S)*nBitsInAttribute(A)/tasa_transmisión] El 'beneficio' de la semicombinación que la combinación permite evitar:
(A es una clave de S)
se toma como el coste de transferir tuplas irrelevantes de R, coste
Capítulo 23 Bases de datos distribuidas: conceptos avanzados 699 Beneficio(R ~A s) = (1 - SFA(S)) * [nTup1es(R)*nBitslnTuple(R)/tasa_transmisión] donde SFA(S) es el factor de selectividad de la combinación (la fracción de tuplas de R que se combinan con tuplas de S), que puede estimarse como: SFA(S) = nTuples(IlA(S))/nDistinct(A) donde nDistinct(A) es el número de valores distintos en el dominio del atributo A. El algoritmo funciona de la forma siguiente: (1) Fase l. Inicialización. Se realizan todas las reducciones locales mediante operaciones de selección y proyección. Se ejecutan semicombinaciones dentro del mismo nodo para reducir el tamaño de las relaciones. Se genera el conjunto de todas las semicombinaciones beneficiosas entre nodos (la semicombinación es beneficiosa si su coste es inferior a su beneficio). (2) Fase 2. Selección de semicombinaciones beneficiosas. Se seleccionan iterativamente las semicombinaciones más beneficiosas a partir del conjunto generado en la fase anterior y se las añade a la estrategia de ejecución. Después de cada operación, se actualizan las estadísticas de la base de datos para reflejar la incorporación de la semicombinación y se actualiza el conjunto con nuevas semicombinaciones beneficiosas. (3) Fase 3. Selección de nadas para las operaciones. Se selecciona, entre todos los nodos, el nodo para el que la transmisión de todas las relaciones a las que hace referencia la consulta tiene un mínimo coste. Se selecciona el nodo que contenga la mayor cantidad de datos después de la fase de reducción, de modo que la cantidad total de datos transferidos desde otros nodos sea mínima. (4) Fase 4. Postoptimización. Se descartan las semicombinaciones inútiles. Por ejemplo, si la relación R reside en el nodo donde se realizan las operaciones y R va a ser reducida por una semicombinación, pero no se utiliza para reducir otras relaciones después de la ejecución de la semi combinación, entonces como R no necesita ser transferida a otro nodo durante la fase de operación final, la semicombinación sobre R es inútil y puede descartarse. El siguiente ejemplo ilustra las anteriores explicaciones.
I
Ejemplo 23.5 Algoritmo SDD-1 Enumerar los detalles de las sucursales junto con los inmuebles gestionados y los detalles del empleado que los gestiona. Podemos expresar esta consulta en SQL como: SELECT * FROM Branch b, PropertyForRent p, Staffs, WHERE b.branchNo = p.branchNo AND p.staffNo = s.staffNo; Suponga que la relación Branch se encuentra en el nodo 1, que la relación PropertyForRent se encuentra en el nodo 2 y que la relación Staff se encuentra en el nodo 3. Suponga, asimismo, que el coste de iniciar un mensaje, Co, es Oy que la tasa de transmisión, tasa_transmisión, es 1. La Figura 23.21 proporciona el conjunto inicial de estadísticas de la base de datos para estas relaciones. El conjunto inicial de semicombinaciones es: SJ 1: PropertyForRent ~branchNo Branch SJ2: Branch ~branchNo PropertyForRent SJ3: PropertyForRent ~slaffNo Staff SJ4: Staff ~SlaffNo PropertyForRent
El El El El
beneficio beneficio beneficio beneficio
es es es es
(1 (1 (1 (1 -
1)*120,000 = O; el coste es 1600 0.1)*10,000 = 9000; el coste es 640 0.9)* 120,000 = 12,000; el coste es 2880 0.2)*50,000 = 40,000; el coste es 1280
En este caso, las semicombinaciones beneficiosas son SJ2, SJ3 y SJ4, por lo que añadiremos SJ4 (la que tiene la mayor diferencia) a la estrategia de ejecución. Ahora actualizamos las estadísticas basándonos en esta semicombinación, con la cual la cardinalidad de Staff' pasa a ser 100*0.2 = 20, el tamaño pasa
700
Sistemas de bases de datos
attribute
relation 100 500 relation 50 200 600 3 size site 120,000 50,000 10,000 tu pie1 size 200 cardinality
0.9 0.1 0.2 1 1600 1280 640 2880 size(ITattribute) SFattribute
s.staffNo p.staffNo p.branchNo b.branchNo
Figura 23.21.
Conjunto inicial de estadísticas de la base de datos para Branch, PropertyForRent y Staff.
a ser 50,000*0.2 = 10,000 Y el factor de selectividad puede estimarse como 0.9*0.2 = 0.18. En la siguiente iteración vemos que SJ3: PropertyForRent [>staffNoStaff' es beneficiosa con un coste de 3720 y la añadimos a la estrategia de ejecución. De nuevo, actualizamos las estadísticas, con lo que la cardinalidad de PropertyForRent' pasa a ser 200*0.9 = 180 Y el tamaño pasa a ser 120,000*0.9 = 108,000. Otra iteración nos permite determinar la semicombinación SJ2: Branch [>braochNoPropertyForRent como beneficiosa, por lo que la añadimos a la estrategia de ejecución y actualizamos las estadísticas de Branch, quedando la cardinalidad igual a 40*0.1 = 4 Y el tamaño 10,000*0.1 = 1000. Después de la reducción, la cantidad de datos almacenados es igual a 1000 en el nodo 1, 108,000 en el nodo 2 y 10,000 en el nodo 3. Seleccionamos el nodo 2 como el nodo para las operaciones finales. Durante la postoptimización, eliminamos la estrategia SJ3. La estrategia seleccionada consistirá en enviar
Staff
[>SlaffNoPropertyForRent
y
Branch
[>braochNoPropertyForRent
al nodo 3.
~
Otros algoritmo s de optimización de consultas distribuidas muy conocidos son AHY (Apers et al., 1983) y Distributed Ingres (Epstein et al., 1978). El lector interesado puede consultar asimismo diversas publicaciones dentro de este campo, como por ejemplo Yu y Chang (1984), Steinbrunn et al. (1997) y Kossmann (2000).
23.7 Distribución en Oracle Para completar este capítulo, vamos a examinar la funcionalidad de SGBD distribuido de Oracle9i (Oracle Corporation, 2004d). En esta sección, utilizaremos la terminología de este SGBD; Oracle utiliza el término tabla para referirse a las relaciones, estando las tablas compuestas por columnas y filas. En la Sección 8.2 hemos proporcionado ya una introducción general a Oracle.
23.7.1
Funcionalidad del SGBDD de Oracle
Al igual que muchos SGBDD comerciales, Oracle no soporta el tipo de mecanismo de fragmentación que hemos analizado en el Capítulo 22, aunque el DBA puede distribuir manualmente los datos para conseguir un efecto similar. Sin embargo, esto coloca sobre el usuario final la responsabilidad de saber cómo se ha fragmentado una tabla y de incluir dicho conocimiento dentro de la aplicación. En otras palabras, el SGBDD de Oracle no soporta la transparencia de fragmentación, aunque sí que soporta la transparencia de ubicación, como veremos en breve. En esta sección, proporcionamos una panorámica de la funcionalidad del SGBDD de Oracle, donde cubriremos: • conectividad; •
nombres globales de las bases de datos;
•
enlaces de la base de datos;
•
transacciones;
•
integridad referencial;
•
bases de datos distribuidas heterogéneas;
•
optimización de consultas distribuidas.
Capítulo 23 Bases de datos distribuidas: conceptos avanzados
701
En el siguiente capítulo hablaremos de los mecanismos de replicación en Oracle
Conectividad Oracle Net Services es la aplicación de acceso a datos que Oracle proporciona para soportar la comunicación entre clientes y servidores (las versiones anteriores de Oracle utilizaban SQL *Net o Net8). Oracle Net Services permite comunicaciones tanto de tipo cliente-servidor como servidor-servidor a través de cualquier red, soportando tanto el procesamiento distribuido como las capacidades del SGBD distribuido. Incluso si un proceso se está ejecutando en la misma máquina que la instancia de la base de datos sigue requiriéndose Net Services para establecer la conexión con la base de datos. Net Services es responsable también de traducir entre unos conjuntos de caracteres y otros y entre unas representaciones de datos y otras que puedan existir en el nivel del sistema operativo. Net Services establece una conexión basando la solicitud de conexión a la capa TNS (Transparent Network Substrate, substrato de red transparente), que determina qué servidor debe gestionar la solicitud y envía ésta utilizando el protocolo de red apropiado (por ejemplo, TCP/IP). Net Services también puede gestionar la comunicación entre máquinas que utilizan protocolos de red diferentes, mediante Connection Manager, este tema era anteriormente gestionado por MultiProtocol Interchange en Oracle 7. El producto Oracle Names almacena información en una ubicación centralizada acerca de las bases de datos de un entorno distribuido. Cuando una aplicación efectúa una solicitud de conexión, se consulta el repositorio de Oracle Names para determinar la ubicación del servidor de base de datos. Una alternativa a la utilización de Oracle Names consiste en almacenar esta información en un archivo local tnsnames.ora en todas las máquinas cliente. En futuras versiones, dejará de soportarse Oracle Names para pasar a utilizar un servidor de directorio compatible con LDAP.
Nombres globales de las bases de datos A cada base de datos distribuida se le asigna un nombre, denominado nombre global de la base de datos, que es distinto del de las demás bases de datos del sistema. Oracle forma el nombre global de la base de datos anteponiendo como prefijo al nombre local de la base de datos el nombre del dominio de red al que corresponde. El nombre de dominio debe seguir los convenios estándar de Internet, debiendo estar los niveles separados por puntos y ordenados desde la hoja a la raíz, de izquierda a derecha. Por ejemplo, la Figura 23.22 ilustra una posible disposición jerárquica de las bases de datos para DreamHome. Aunque hay dos bases de datos denominadas Rentals en esta figura, podemos utilizar el nombre del dominio de red LONDON.SOUTH.COM para diferenciar la base de datos de Londres de la situada en Glasgow. En este caso, los nombres globales de las bases de datos serán: RENTALS.LONDON.SOUTH.COM RENTALS.GLASGOW.NORTH.COM
Figura 23.22.
Estructura de la red de DreamHome.
702
Sistemas de bases de datos
Enlaces de la base de datos Las bases de datos distribuidas en Oracle están construidas sobre enlaces de la base de datos, que definen una ruta de comunicación desde una base de datos Oracle a otra base de datos (posiblemente no Oracle). El propósito de los enlaces de base de datos es hacer que los datos remotos estén disponibles para su consulta y actualización, actuando en esencia como una especie de inicio de sesión almacenado para la base de datos remota. A un enlace de base de datos hay que darle el mismo nombre de base de datos global que tenga la base de datos remota a la que hace referencia, en cuyo caso los enlaces de base de datos serán esencialmente transparentes a los usuarios de una base de datos distribuida. Por ejemplo, la siguiente instrucción crea un enlace de base de datos en la base de datos local, enlace que apunta a la base de datos remota situada en Glasgow: CREATE PUBLIC DATABAS E LINK RENTALS.GLASGOWNORTH.COM; Una vez creado un enlace de base de datos, puede utilizarse para hacer referencia a tablas y vistas de la base de datos remota, añadiendo @enlacebasedatos al nombre de tabla o de vista utilizado en una instrucción SQL. Puede efectuarse una consulta sobre una tabla o vista remotas mediante la instrucción SELECT. Con la opción distribuida de Oracle, también puede accederse a las tablas y vistas remotas mediante instrucciones INSERT, UPDATE y DELETE. Por ejemplo, podemos utilizar las siguientes instrucciones SQL para consultar y actualizar la tabla Staff en el modo remoto: SELECT * FROM [email protected]; UPDATE [email protected] SET salary = salary*1.05; Un usuario puede acceder también a tablas que sean propiedad de otros usuarios en la misma base de datos, precediendo el nombre de la base de datos con el nombre del esquema. Por ejemplo, si suponemos que el usuario actual tiene acceso a la tabla Viewingdel esquema Supervisor, podemos utilizar la siguiente instrucción SQL: SELECT
* FROM [email protected];
Esta instrucción se conecta a la base de datos remota en nombre del usuario actual y consulta la tabla Viewingdel esquema Supervisor. Puede crearse un sinónimo para esconder el hecho de que la tabla Viewingde Supervisor está en una base de datos remota. La:'siguiente instrucción haría que todas las referencias futuras a Viewingaccedieran a una tabla Viewingremota propiedad de Supervisor: CREATE SYNONYM ViewingFOR [email protected]; SELECT * FROM Viewing; De esta forma, el uso de sinónimos proporciona tanto independencia de los datos como transparencia con respecto a la ubicación.
Transacciones Oracle soporta las transacciones sobre datos remotos, incluyendo: •
Instrucciones SQL remotas. Una consulta remota es una consulta que selecciona información de una o más tablas remotas, todas residen en el mismo nodo remoto. Una instrucción de actualización remota es una actualización que modifica los datos en una o más tablas, todas las cuales están ubicadas en el mismo nodo remoto .
•
Instrucciones SQL distribuidas. Una consulta distribuida extrae información de dos o más nadas. Una instrucción de actualización distribuida modifica datos de dos o más nadas. Puede realizarse una actualización distribuida utilizando un subprograma PL/SQL, como por ejemplo un procedimiento o disparador, que incluya dos o más actualizaciones remotas que accedan a datos situados en nadas diferentes. Oracle envía las instrucciones del programa a los nadas remotos y su ejecución se completa adecuadamente o falla como una única unidad.
Capítulo 23 Basesde datos distribuidas: conceptos avanzados
703
•
Transacciones remotas. Una transacción remota contiene una o más instrucciones remotas, todas las cuales hacen referencia a un único nodo remoto .
•
Transacciones distribuidas. Una trucciones que, individualmente de una base de datos distribuida. tribuidas utilizando el protocolo
transacción distribuida es una transacción que incluye una o más inso como grupo, actualizan datos situados en dos o más nodos distintos En tales casos, Oracle garantiza la integridad de las transacciones disde confirmación en dos fases (2PC) presentado en la Sección 23.4.3.
Integridad referencial Oracle no permite definir restricciones de integridad referencial declarativas entre las distintas bases de un sistema distribuido (es decir, una restricción de integridad referencial declarativa sobre una puede especificar una clave externa que haga referencia a una clave principal o unívoca de una tabla Sin embargo, las relaciones de tablas padre-hijo entre bases de datos pueden mantenerse utilizando dores.
Bases de datos distribuidas
de datos tabla no remota). dispara-
heterogéneas
En un SGBDD heterogéneo de Oracle, al menos uno de los SGBD es un sistema no Oracle. Utilizando Heterogeneous Services y un agente Heterogeneous Services específico para un sistema no Oracle, Oracle puede ocultar los aspectos de distribución y heterogeneidad a ojos del usuario. El agente de Heterogeneous Services se comunica con el sistema no Oracle y con el componente Heterogeneous Services del servidor Oracle. El agente ejecuta, por cuenta del servidor Oracle, instrucciones SQL, procedimientos y solicitudes transacciones en el sistema no Oracle. Puede accederse a Heterogeneous Services mediante las siguientes herramientas: •
Transparent Gateways, que proporciona acceso SQL a un SGBD no Oracle incluyendo DB2/400, DB2 para OS/390, Informix, Sybase, SQL Server, Rdb, RMS y Non-Stop SQL. Estas pasarelas (gateway) se ejecutan normalmente sobre la máquina con el SGBD no Oracle, en lugar de en la máquina donde reside el servidor Oracle. Sin embargo, la pasarela Transparent Gateway para DRDA (véase la Sección 22.5.2), que proporciona acceso SQL a bases de datos compatibles DRDA, como DB2, SQL/DS y SQL/400, no requiere utilizar ningún software de Oracle en el sistema de destino. La Figura 23.23(a) ilustra la arquitectura de Transparent Gateway.
•
Generic Conectivity, que es un conjunto de agentes que están enlazados con controladores proporcionados por el cliente. Actualmente, Oracle proporciona agentes para ODBC y OLE DB. La funcionalidad de estos agentes es más limitada que la de las pasarelas Transparent Gateway. La Figura 23.23(b) ilustra la arquitectura de Generic Conectivity.
Las principales características de Heterogeneous Services son: •
Transacciones distribuidas. Una transacción pueden abarcar tanto sistemas Oracle como no Oracle utilizando confirmación en dos fases (véase la Sección 23.4.3).
•
Acceso SQL transparente. Las instrucciones SQL ejecutadas por la aplicación se transforman de manera transparente en instrucciones SQL que pueda reconocer el sistema no Oracle.
•
Acceso procedimental. Puede accederse a los sistemas procedimentales, como los sistemas de mensajería y la gestión de colas desde un servidor Oracle9i utilizando llamadas a procedimientos remotos PL/SQL. Traducción del diccionario de datos. Para hacer que el sistema no Oracle aparezca como otro servidor Oracle, las instrucciones SQL que contienen referencias a las tablas del diccionario de datos de Oracle se transforman en instrucciones SQL con referencias a las tablas del diccionario de datos del sistema no Oracle.
•
•
SQL de paso directo y procedimientos almacenados. Una aplicación puede acceder directamente a un sistema no Oracle utilizando el dialecto SQL de dicho sistema. Los procedimientos almacenados en un sistema no Oracle basado en SQL se tratan como si fueran procedimientos remotos PL/SQL.
704
Sistemas de bases de datos
Servidor Oracle
Oracle9í
Oracle Net
Heterogeneous Services
Oracle Net Servidor no Oracle
(a)
Servidor Oracle
Oracle9í Oracle Net
Heterogeneous Services
Componentes no Oracle
1 4 4 2 4 4
: -Gesto-r-de coñirolador : ODBC ,..-----------------------~ : Controlador ODBC : : Cliente del sistema
3 :_09_Q[élG.I!?
-- --: ' : ~ : :
Servidor no Oracle
Sistema no Oracle
(b)
Figura 23.23. Oracle Heterogeneous Services: (a) utilizando una pasarela Transparent Gateway en el sistema no Oracle; (b) utilizando Generic Conectivity a través de ODBC .
•
Soporte de idioma nacional. Heterogeneous Services soporta conjuntos de caracteres multibyte y se encarga de efectuar la traducción de conjuntos de caracteres entre OracIe y el sistema no OracIe.
Capítulo 23 Bases de datos distribuidas: •
conceptos avanzados
705
Optimización. Heterogeneous Services puede recopilar ciertas estadísticas sobre tablas e índices en el sistema no Oracle y transferir esa información al optimizador basado en costes de Oracle.
Optimización de consultas distribuidas El SQBD local de Oracle descompone cada consulta distribuida en su correspondiente serie de consultas remotas, que se envían a los SGBD remotos para su ejecución. Los SGBD remotos ejecutan las consultas y devuelven los resultados al nodo local. El nodo local realiza entonces cualquier procesamiento que sea necesario y devuelve los resultados al usuario o a la aplicación. Sólo se extraen de las tablas remotas los datos necesarios, reduciendo así la cantidad de datos que hace falta transferir. La optimización de consultas distribuidas utiliza el optimizador basado en costes de Oracle, del que hemos hablado en la Sección 21.6
Resumen del capítulo •
Los objetivos del procesamiento de transacciones distribuidas son los mismos que en los sistemas centralizados, aunque la complejidad aumenta debido a que el SGBDD debe garantizar la atomicidad tanto de la transacción global como la de cada una de las subtransacciones.
•
Si la planificación de ejecución de la transacción en cada nodo es serializable, entonces la planificación global (la unión de todas las planificaciones locales) es también serializable, siempre y cuando los órdenes de serialización locales sean idénticos. Esto requiere que todas las subtransacciones aparezcan en el mismo orden en las planificaciones serie equivalente de todos los nodos.
•
Dos métodos que pueden utilizarse para garantizar la serializabilidad distribuida son el bloqueo y el marcado temporal. En el bloqueo en dos fases (2PL), una transacción adquiere todos los bloqueos antes de liberar ninguno de ellos. Los protocolos de bloqueo en dos fases pueden utilizar gestores de bloqueo centralizados, de copia principal o distribuidos. También puede usarse la técnica de votación mayoritaria. Con el marcado temporal, las transacciones se ordenan de tal forma que las más antiguas tengan prioridad en caso de conflicto.
•
El bloqueo distribuido implica la combinación de los grafos de espera locales, para comprobar si existen ciclos. Si se detecta un ciclo, deberá abortarse y reiniciarse una o más transacciones hasta que el ciclo quede roto. Hay tres métodos comunes de detección de interbloqueos en un SGBD distribuido: detección de interbloqueos centralizada, jerárquica y distribuida.
•
Las principales causas de fallo en un entorno distribuido son la pérdida de mensajes, los fallos en los enlaces de comunicaciones, las detecciones catastróficas de los nodos y el particionamiento de red. Para facilitar la recuperación, cada nodo mantiene su propio archivo de registro. El registro puede utilizarse para deshacer y rehacer transacciones en caso de fallo.
•
El protocolo de confirmación en dos fases (2PC) comprende una fase de votación y otra de decisión, mediante las que el coordinador pregunta a todos los participantes si están listos para confirmar la transacción. Si uno de los participantes vota por abortada, deberán abortarse tanto la transacción global como cada una de las subtransacciones. Sólo si todos los participantes votan por la confirmación podrá confirmarse la transacción global. El protocolo 2PC puede hacer que algunos nodos queden bloqueados en caso de que se produzcan fallos de nodos.
•
Un protocolo no bloqueante es la confirmación en tres fases (3PC), que requiere que el coordinador envíe un mensaje adicional entre las fases de votación y decisión a todos los participantes, pidiéndose que preconfirmen la transacción.
•
X/Open DTP es una arquitectura de procesamiento de transacciones distribuidas para un protocolo 2PC distribuido, basada en OSI-TP. La arquitectura define una serie de interfaces de programación de aplicaciones y un conjunto de interacciones entre las aplicaciones transaccionales, los gestores de transacciones, los gestores de recursos y los gestores de comunicaciones.
•
El procesamiento de consultas distribuidas puede dividirse en cuatro fases: descomposición de la consulta, localización de los datos, optimización global y optimización local. La descomposición de la consul-
706
Sistemas de bases de datos
ta toma una consulta expresada sobre las relaciones globales y realiza una optimización parcial utilizando las técnicas explicadas en el Capítulo 21. La localización de datos toma en consideración cómo se han distribuido los datos y sustituye las relaciones globales de las hojas del árbol de álgebra relacional por sus algoritmos de reconstrucción. La optimización global tiene en cuenta la información estadística para hallar un plan de ejecución cercano al óptimo. La optimización local se realiza en cada nodo implicado en la consulta . •
El modelo de costes para la optimización de consultas distribuidas puede basarse en el coste total (como en el caso centralizado) o en el tiempo de respuesta, es decir, el tiempo transcurrido desde el inicio hasta la terminación de la consulta. Este último modelo tiene en cuenta el paralelismo inherente en un sistema distribuido. Los cálculos de coste necesitan tomar en consideración los costes de procesamiento local (E/S y procesador) así como los costes de interconexión por red. En una red WAN, los costes de comunicación por red serán el factor dominante que habrá que reducir .
•
Cuando el principal componente del coste es el tiempo de comunicación, la operación de semicombinación resulta particularmente útil para mejorar el procesamiento de las combinaciones distribuidas, al reducir la cantidad de datos que hay que transferir entre unos nodos y otros.
Cuestiones de repaso 23.1.
En un entorno distribuido, los algoritmo s basados en bloqueo pueden clasificarse como centralizados, de copia principal o distribuidos. Indique las similitudes y diferencias entre estos algoritmos.
23.2.
Uno de los métodos más conocidos para la detección de interbloqueos distribuidos fue desarrollado por Obermarck. Explique cómo funciona el método de Obermarck y cómo se detecta y resuelve una situación de interbloqueo.
23.3.
Esboce dos topologías alternativas de confirmación en dos fases que puedan considerarse como alternativas a la topología centralizada.
23.4.
Explique el término 'protocolo no bloqueante' e indique por qué el protocolo de confirmación en dos fases no es un protocolo no bloqueante.
23.5.
Explique por qué el protocolo de confirmación en tres fases es un protocolo no bloqueante a menos que fallen todos los nodos.
23.6.
Indique los niveles de la optimización de consultas distribuidas y detalle la función de cada nivel.
23.7.
Diga cuáles son los costes que hay que tomar en consideración durante la optimización de consultas distribuidas y exponga dos modelos de costes diferentes.
23.8. 23.9.
Describa los algoritmos de optimización de consultas distribuidas usados por R* y SDD-1. Describa brevemente la funcionalidad distribuida de Oracle9i.
Ejercicios 23.10. El Director Gerente de DreamHome nos pide que investiguemos los requisitos de distribución de datos de la organización y que preparemos un informe del uso potencial de un SGBD distribuido. El informe debe comparar la tecnología del SGBD centralizado con la del SGBD distribuido, indicar las ventajas y desventajas de implementar un SGBDD dentro de la organización y señalar las posibles fuentes de problemas. Finalmente, el informe debe contener un conjunto de recomendaciones adecuadamente justificadas que detallen la solución apropiada que se propone. 23.11. Explique en detalle cómo funciona el protocolo de confirmación en dos fases centralizado en un entorno distribuido. Esboce los algoritmos correspondientes tanto al coordinador como a los participantes. 23.12. Explique en detalle cómo funciona el protocolo de confirmación en tres fases en un entorno distribuido. Esboce los algoritmos correspondientes tanto al coordinador como a los participantes. 23.13. Analice los SGBD que esté utilizando actualmente y determine qué soporte proporciona cada uno para el modelo DTP de X/Open y para la replicación de datos.
os
Capítulo 23 Basesde datos distribuidas: conceptos avanzados
707
23.14. Considere cinco transacciones TI, T2, T3, T4 Y Ts tales que: • • • •
•
TI se T2 se T3 se T 4 se
inicia inicia inicia inicia Ts se inicia
en en en en en
el el el el el
nodo nodo nodo nodo nodo
SI y S3 y SI y S2 y S3'
crea crea crea crea
un un un un
agente agente agente agente
en en en en
el el el el
nodo nodo nodo nodo
S2 SI S3 S3
La información de bloqueo para estas transacciones se muestra en la tabla siguiente. Transacción
XI Xs S3 Xg x2 x7 SI S2 S] la las transacción Elementoslos de datos x3 x7 XI Xs x3 x2 x4 x6 x8 Elementos que operaciones estádeesperando datos por
S2 S3 Nodo
implicado en
por la
(a) Construya los grafos de espera locales para cada uno de los nodos. ¿Qué conclusiones puede sacar a partir de los grafos de espera locales? (b) Utilizando las transacciones anteriores, muestre cómo funciona el método de Obermarck para detección de interbloqueos distribuidos. ¿Qué conclusiones puede sacar del grafo de espera global?
Replicación y bases de datos móv'iles
Objetivos del capítulo: En este capítulo aprenderá: •
En qué se diferencia una base de datos replicada de una base de datos distribuida.
•
Las ventajas de la replicación de bases de datos.
•
Ejemplos de aplicaciones que utilizan la replicación de la base de datos.
•
Componentes básicos de un sistema de replicación.
•
Las diferencias entre la replicación síncrona y la asíncrona.
•
Los tipos principales de modelos de propiedad de los datos, que son maestro/esclavo, y actualización ubicua.
•
La funcionalidad de un servidor de replicación de bases de datos.
•
Los principales problemas de implementación
• •
El modo en que la informática móvil soporta a los trabajadores móviles. La funcionalidad de un SGBD móvil.
•
Cómo soporta el SGBD de Oracle la replicación de bases de datos.
flujo de trabajo
asociados con la replicación de bases de datos.
En el capítulo anterior hemos presentado los conceptos y problemas básicos asociados con los sistemas de gestión de bases de datos distribuidas (SGBDD). Desde la perspectiva del usuario, la funcionalidad ofrecida por un SGBDD es muy atractiva. Sin embargo, desde el punto de vista de la implementación, los protocolos y algoritmo s requeridos para proporcionar esta funcionalidad son muy complejos y dan lugar a diversos problemas que pueden hacer que no merezcan la pena las ventajas ofrecidas por esta tecnología. En este capítulo se presenta una técnica alternativa, y potencialmente más simple, a la distribución de datos, técnica alternativa que se basa en un servidor de replicación que se encarga de replicar los datos en los nodos remotos. Todos los principales fabricantes de bases de datos disponen de una solución de replicación de un tipo u otro y muchos fabricantes no especializados en bases de datos ofrecen métodos alternativos para la replicación de los datos. Posteriormente en el capítulo nos centraremos en una aplicación concreta de la replicación de bases de datos, denominada bases de datos móviles, y veremos cómo presta soporte esta tecnología a los trabajadores móviles.
Estructura del capítulo En la Sección 24.1 se presentan los conceptos de replicación de bases de datos y en la Sección 24.2 se examinan las ventajas asociadas con esta tecnología. En la Sección 24.3 se identifican las aplicaciones típicas de la replicación de bases de datos. En la Sección 24.4 se exponen algunos de los componentes más importantes de los entorno s de replicación de bases de datos y en la Sección 24.5 se analizan las opciones más relevantes
710
Sistemas de bases de datos
para el entorno de replicación, como por ejemplo si utilizar replicación síncrona o asíncrona. En la Sección 24.6 se identifica la funcionalidad requerida del servidor de aplicación y se repasan los principales problemas de implementación asociados con esta tecnología. En la Sección 24.7 analizaremos las bases de datos móviles y la funcionalidad que cabe exigir a un SGBD móvil. En la Sección 24.8 se incluye una panorámica del modo en que Oracle9i gestiona la replicación. Los ejemplos en este capítulo están, de nuevo, extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 Y en el Apéndice A.
24.1 Introducción a la replicación de bases de datos La replicación de bases de datos es un mecanismo de gran importancia, porque permite a las organizaciones proporcionar a los usuarios acceso a datos actualizados en todo lugar y en todo momento. Replicación de bases de datos
El proceso de copiar y mantener objetos de la base de datos, como por ejemplo relaciones, en múltiples bases de datos que forman un sistema de bases de datos distribuido.
Los cambios aplicados en un nodo se capturan y almacenan localmente antes de reenviarlos y aplicarlos a cada una de las ubicaciones remotas. La replicación utiliza tecnología de bases de datos distribuidas para compartir datos entre múltiples sitios, pero no es lo mismo una base de datos replicada y una base de datos distribuida. En una base de datos distribuida, los datos están disponibles en muchas ubicaciones, pero cada relación concreta sólo reside en una ubicación. Por ejemplo, si DreamHome dispusiera de una base de datos distribuida, la relación que describe los inmuebles en alquiler, es decir PropertyForRent, sólo estaría almacenada en un único servidor de base de datos, como por ejemplo el servidor de Londres, y no en los servidores de Glasgow o de Edimburgo. Por el contrario, la replicación significa que los mismos datos están disponibles en múltiples ubicaciones. Así, si DreamHome dispusiera de una base de datos replicada, la relación PropertyForRent podría estar disponible en los servidores de base de datos de Londres, Glasgow y Edimburgo.
24.2 Beneficios de la replicación de base de datos La Tabla 24.1 enumera algunos de los beneficios principales asociados con la replicación de bases de datos. E! término disponibilidad hace referencia al modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones, mediante la provisión de opciones alternativas de acceso a los datos. Si uno de los nadas deja de estar disponible, los usuarios pueden continuar consultando o incluso actualizando las ubicaciones restantes. Fiabilidad hace referencia al hecho de que, al haber múltiples copias de los datos disponibles en el sistema, se dispone de un mecanismo excelente de recuperación en caliente para el caso en el que se produzcan fallos en uno o más nadas. El rendimiento se mejora sobremanera para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de una sobrecarga significativa de los recursos centralizados. La Tabla 24.1.
Ventajas de la replicación.
Disponibilidad Fiabilidad Rendimiento Reducción de la carga Procesamiento
desconectado
Soporta muchos usuarios Soporta aplicaciones avanzadas
Capítulo 24 Replicación y bases de datos móviles
711
replicación proporciona un acceso rápido y local a los datos compartidos, ya que equilibra la actividad entre múltiples nodos. Algunos usuarios pueden acceder a un servidor, mientras que otros usuarios acceden a servidores distintos, manteniendo así los niveles de rendimiento en todos los servidores. El término reducción de la carga hace referencia al modo en el que puede utilizarse la replicación para distribuir los datos entre múltiples ubicaciones remotas. Con ello, los usuarios pueden acceder a varios servidores remotos en lugar de acceder a un servidor centralizado. Esta configuración permite así reducir significativamente el tráfico de red. Asimismo, los usuarios pueden acceder a los datos almacenados en eLnodo de replicación cuyo coste de acceso sea menor, el cual será normalmente el nodo que esté geográficamente más próximo al usuario. Al hablar de procesamiento desconectado nos referimos al modo en el que la replicación puede implementarse mediante el llamado mecanismo de instantáneas. Una instantánea es una copia (réplica) completa o parcial de una relación determinada en un instante temporal concreto. Las instantáneas permiten que los usuarios trabajen sobre un subconjunto de la base de datos corporativa mientras están desconectados del servidor de base de datos principal. Posteriormente, al restablecer una conexión, los usuarios pueden sincronizar (refrescar) las instantáneas en la base de datos corporativa según sea necesario. Esto puede implicar que la instantánea reciba actualizaciones de la base de datos corporativa o que la base de datos corporativa reciba actualizaciones de la instantánea. Independientemente de cuál sea la acción que se lleve a cabo, los datos de la instantánea y de la base de datos corporativa volverán a ser coherentes. Cuando afirmamos que la replicación soporta a muchos usuarios estamos haciendo referencia a que las organizaciones necesitan implantar cada día más aplicaciones que requieren la posibilidad de utilizar y manipular datos. La replicación puede crear múltiples instantáneas personalizadas que satisfagan los requisitos de cada usuario o grupo de usuarios del sistema. Finalmente, decir que la replicación soporta aplicaciones avanzadas está relacionado con el modo en que las organizaciones necesitan cada vez más hacer que los datos corporativos estén disponibles no sólo para los sistemas tradicionales OLTP (Online Transaction Processing, procesamiento de transacciones en línea) sino también para aplicaciones avanzadas de análisis de los datos, como los almacenes de datos OLAP (Online Analytical Processing, procesamiento analítico en línea) y la minería de datos (véanse los Capítulos 31 a 34). Además, gracias a la replicación, los datos corporativos también pueden utilizarse para soportar la cada vez más popular tendencia de la informática móvil (véase la Sección 24.7). Por supuesto, un sistema de base de datos replicado que proporcione los beneficios indicados en la Tabla 24.1 será más complejo que un sistema de base de datos centralizado. Por ejemplo, las prestaciones pueden verse significativamente reducidas para las transacciones de actualización, porque será necesario realizar una misma actualización lógica en cada copia de la base de datos, con el fin de mantener la coherencia de las copias. Asimismo, las técnicas de control de concurrencia y de recuperación son más complejas y más caras, si las comparamos con un sistema donde no exista replicación.
24.3 Aplicaciones de la replicación La replicación permite soportar diversas aplicaciones con requisitos muy distintos. Algunas aplicaciones no necesitan más que una sincronización limitada entre las distintas copias de la base de datos y el sistema de base de datos corporativo, mientras que otras aplicaciones exigen una sincronización continua entre todas las copias de la base de datos. Por ejemplo, el soporte para un equipo de ventas remoto requiere normalmente la sincronización periódica de un gran número de pequeños nadas móviles remotos con el sistema de base de datos corporativo. Además, dichos nadas son a menudo autónomos, estando desconectados de la base de datos corporativa durante periodos de tiempo relativamente largos. A pesar de esto, los miembros del equipo de ventas deben poder completar una venta, independientemente de si están conectados a la base de datos corporativa o no. En otras palabras, los nadas remotos deben poder soportar todas las transacciones necesarias asociadas con una venta. En este ejemplo, la autonomía de un nodo se considera más importante que garantizar la coherencia de los datos. Por otro lado, las aplicaciones financieras que implican la gestión de acciones bursátiles requieren que los datos de los múltiples servidores se sincronicen de manera continua y prácticamente instantánea, para garan-
712
Sistemas de bases de datos
tizar que el servicio proporcionado esté disponible y sea homogéneo en todo momento. Por ejemplo, los sitios web que muestran los precios de las acciones deben garantizar que los clientes vean la misma información en cada sitio. En este ejemplo, la coherencia de los datos es más importante que la autonomía de los nodos. En la Sección 24.5.2 se proporcionan más ejemplos de aplicaciones que requieren la replicación. Asimismo, en este capítulo nos centraremos en una aplicación concreta de la replicación, denominada base de datos móviles, y explicaremos en la Sección 24.7 cómo soporta esta tecnología a los trabajadores móviles.
24.4 Componentes básicos de la replicación de bases de datos Esta sección describe con más detalle algunos de los componentes básicos del entorno de replicación de bases de datos, incluyendo los objetos de replicación, los grupos de replicación y los sitios de replicación. Un objeto de replicación es un objeto de base de datos tal como una relación, un índice, una vista, un procedimiento o una función que existe en múltiples servidores en un sistema de base de datos distribuido. En un entorno de replicación, cualesquiera actualizaciones realizadas en un objeto de replicación en un sitio o nodo se aplican a las copias de todos los demás sitios. En un entorno de replicación, los objetos de replicación se gestionan mediante los denominados grupos de replicación. Un grupo de replicación es una colección de objetos de replicación que están lógicamente relacionados. La organización de los objetos relacionados de la base de datos en un grupo de replicación facilita la administración de dichos objetos. Cada grupo de replicación puede existir en múltiples sitios de replicación. Los entorno s de replicación soportan dos tipos básicos de sitios: sitios maestros y sitios esclavos. Un grupo de replicación puede estar asociado con uno o más sitios maestros y con uno o más sitios esclavos. Un sitio concreto puede ser tanto un sitio maestro para un grupo de replicación como un sitio esclavo para otro sitio de replicación distinto. Sin embargo, un mismo sitio no puede ser a la vez el sitio maestro y el sitio esclavo para el mismo grupo de replicación. Un sitio maestro controla un grupo de replicación y los objetos pertenecientes a dicho grupo. Esto se consigue manteniendo una copia completa de todos los objetos del grupo de replicación y propagando los cambios realizados en el grupo a todas las demás copias almacenadas en los sitios esclavos. Un sitio esclavo puede contener todos los objetos de un grupo de replicación o sólo un subconjunto de los mismos. Sin embargo, los sitios esclavos únicamente contienen una instantánea del grupo de replicación, como por ejemplo los datos contenidos en una relación en un instante concreto de tiempo. Normalmente, los sitios de instantáneas se refrescan periódicamente para sincronizarlos con su sitio maestro. Para un entorno de replicación con múltiples sitios maestros, todos esos sitios se comunican directamente entre sí para propagar continuamente los cambios realizados en el grupo de replicación. En la siguiente sección vamos a analizar los tipos de problemas asociados con el mantenimiento de la coherencia entre los sitios maestros y los sitios esclavos.
24.5 Entornos de replicación de bases de datos En esta sección se analizan características importantes de los entorno s de replicación de bases de datos, como por ejemplo si la replicación de los datos se mantiene utilizando mecanismos síncronos o asíncronos o si uno o más sitios tienen la propiedad de una copia maestra de los datos replicados.
24.5.1
Replicación síncrona y asíncrona
En el capítulo anterior hemos examinado los protocolos para actualización de datos funcionaban sobre la base de que todas las actualizaciones se llevaran a cabo como las engloba. En otras palabras, los datos replicados se actualizan inmediatamente zar los datos de origen. Normalmente, utilizando el protocolo 2PC (confirmación
replicados, protocolos que parte de la transacción que en el momento de actualien dos fases) analizada en
Capítulo 24 Replicación y bases de datos móviles
713
la Sección 23.4.3. Este tipo de replicación se denomina replicación sÍncrona. Aunque este mecanismo puede resultar apropiado para los entorno s que deban por necesidad mantener todas las réplicas completamente sincronizadas (como por ejemplo para las aplicaciones financieras, también tiene diversas desventajas). Por ejemplo, la transacción no podrá completarse si uno o más de los nodos que almacenan las réplicas no están disponibles. Además, el número de mensajes requeridos para coordinar la sincronización de los datos impone una carga significativa a las redes corporativas. Un mecanismo alternativo a la replicación síncrona es la denominada replicación aSÍncrona. Con este mecanismo, la base de datos de destino se actualiza después de que la base de datos de origen haya sido modificada. El retardo que se experimenta antes de volver a restaurar la coherencia puede ir desde unos pocos segundos a varias horas o incluso días. Sin embargo, los datos terminarán por sincronizarse y adoptar el mismo valor en todos los sitios. Aunque esto viola el principio de la independencia de los datos distribuidos, parece ser un compromiso práctico entre la integridad y la disponibilidad de los datos, compromiso que puede resultar más apropiado para aquellas organizaciones que puedan trabajar con réplicas que no necesariamente tengan que estar siempre sincronizadas y actualizadas.
24.5.2
Propiedad de los datos
El término propiedad hace referencia a cuál es el sitio que tiene el privilegio de poder actualizar los datos. Los tipos principales de propiedad son maestro/esclavo, flujo de trabajo y actualización ubicua (algunas veces denominada replicación igualitaria o replicación simétrica).
Propiedad maestro/esclavo Con la propiedad maestro/esclavo, los datos asíncronamente replicados son propiedad de un sitio, el sitio maestro (o principal) y sólo pueden ser actualizados por dicho sitio. Utilizando una metáfora de publicación y subscripción, el sitio maestro (el publicador) hace que los datos estén disponibles en los sitios esclavos (los subscriptores). Los sitios esclavos se 'subscriben' a los datos propiedad del sitio maestro, lo que significa que reciben copias de sólo lectura en sus sistemas locales. Potencialmente, cada sitio puede ser el maestro de una serie de conjuntos de datos no solapados. Sin embargo, sólo puede existir un único sitio que actualice la copia maestra de un conjunto de datos concreto, por lo cual no pueden aparecer conflictos de actualización entre los distintos sitios. He aquí algunos ejemplos que muestran los usos potenciales de este tipo de replicación: •
Análisis para sistemas de soporte a la toma de decisiones (DSS, decision support system). Los datos de una o más bases de datos distribuidas pueden descargarse a un DSS local separado para análisis de sólo lectura. En el caso de DreamHome podríamos recopilar toda la información de ventas y alquileres de inmuebles, junto con los detalles de los clientes, y realizar análisis para determinar tendencias, como por ejemplo qué tipo de persona es más probable que compre o alquile un inmueble de un rango de precios o de una zona geográfica concretos. Hablaremos de las tecnologías que requieren este tipo de replicación de datos para el análisis de los datos, incluyendo OLAP (Online Analytical Processing) y la minoría de datos, en los Capítulos 33 y 34.
•
Distribución y diseminación de iriformación centralizada. La diseminación de los datos describe un entorno en el que los datos se actualizan en una ubicación central y luego se replican a sitios de sólo lectura. Por ejemplo, la información de producto tal como las listas de precios puede mantenerse en el sitio correspondiente a la serie corporativa y replicarse mediante copias de sólo lectura que se almacenen en las sucursales remotas. Este tipo de replicación se muestra en la Figura 24.1(a).
•
Consolidación de la información remota. La consolidación de datos describe un entorno en el que los datos pueden actualizarse localmente y luego combinarse en un repositorio de sólo lectura situado en una determinada ubicación. Este método permite que la propiedad de los datos resida en cada sitio y que los distintos sitios sean autónomos. Por ejemplo, los detalles de los inmuebles que se mantienen en cada sucursal podrían replicarse a una copia de sólo lectura consolidada residente en la sede corporativa. Este tipo de replicación se muestra en la Figura 24.1 (b).
714
Sistemas de bases de datos
Sitio esclavo (sólo lectura)
Sitio esclavo (sólo lectura)
Sitio esclavo (sólo lectura) Sitio maestro (lectura/escritura)
(a)
o o Sitio maestro (lectura/escritura)
(b)
Figura 24.1.
•
Sitio maestro (lectura/escritura) Sitio esclavo (sólo lectura)
Propiedad maestro/esclavo: (a) diseminación (b) consolidación de los datos .
de los datos;
Informática móvil. La informática móvil ha pasado a ser mucho más accesible en los últimos años y en la mayoría de las organizaciones hay personas que trabajan fuera de la oficina. Hoy en día existen
Capítulo 24 Replicación y bases de datos móviles
715
distintos métodos para proporcionar datos a una fuerza de trabajo móvil, uno de los cuales es la replicación. En este caso, los datos se descargan a voluntad desde un servidor local del grupo de trabajo. Las actualizaciones realizadas por el cliente móvil en los datos del grupo de trabajo o en los datos centralizados, como por ejemplo la información de nuevos clientes o pedidos, se gestionan de forma similar. Más adelante en el capítulo hablaremos con mayor detalle de esta aplicación de la replicación de datos (véase la Sección 24.7). Un sitio maestro puede ser el propietario de todos los datos de una relación, en cuyo caso los demás sitios se subscribirán a copias de sólo lectura de dicha relación. Alternativamente, puede que haya múltiples sitios que sean propietarios de distintos fragmentos de la relación, y los demás sitios se subscribirán entonces a copias de sólo lectura de dichos fragmentos. Este tipo de replicación se conoce también con el nombre de replicación asimétrica. Para DreamHome, podría implementarse un SGBD distribuido para permitir que cada sucursal fuera la propietaria de diferentes particiones horizontales de las relaciones PropertyForRent, Client y Lease. El sitio correspondiente a la sede central podría subscribirse a los datos propiedades de cada sucursal, con el fin de mantener una copia consolidada de sólo lectura de todos los inmuebles, clientes y contratos de alquiler de toda la organización.
Propiedad tipo flujo de trabajo Al igual que la propiedad maestro/esclavo, el modelo de propiedad tipo flujo de trabajo impide los conflictos de actualización, proporcionando al mismo tiempo un modelo de propiedad más dinámico. La propiedad tipo flujo de trabajo permite que el derecho de actualizar los datos replicados se vaya transfiriendo de un sitio a otro. Sin embargo, en cada momento concreto, sólo hay un único sitio que pueda actualizar ese conjunto de datos concreto. Un ejemplo típico de propiedad tipo flujo de trabajo sería un sistema de procesamiento de pedidos, en el que el procesamiento de los pedidos sigue una serie de pasos, como introducción del pedido, aprobación del crédito, facturación, envío, etc. En un SGBD centralizado, las aplicaciones de esta naturaleza acceden y actualizan los datos en una base de datos integrada: cada aplicación actualiza los datos de los pedidos en secuencia, únicamente cuando el estado del pedido indique que el paso anterior ya ha sido completado. Con un modelo de propiedad de tipo flujo de trabajo, las aplicaciones pueden distribuirse entre los distintos sitios y cuando los datos se repliquen y se reenvíen al siguiente sitio de la cadena, el derecho de actualizarlos también se transferirá, como se ilustra en la Figura 24.2.
Propiedad de tipo actualización ubicua (replicación simétrica) Los dos modelos anteriores comparten una propiedad común: en cada momento determinado, sólo uno de los sitios puede actualizar los datos; todos los demás sitios dispondrán de acceso de sólo lectura a las réplicas. En
Relación status leaseNo Facturable Facturado LN34 LN76 Billing Sucursal I I(facturación)
Figura 24.2.
C087 C040 ownerNo I
Sede central
...
-1
Propiedad tipo flujo de trabajo.
716
Sistemas de bases de datos
algunos entornas, esto es demasiado restrictivo. El modelo de actualización ubicua crea un entorno igualitario en el que los múltiples nadas disponen de iguales derechos para actualizar los datos replicados. Esto permite que los sitios locales funcionen autónomamente incluso en el caso de que otros sitios no estén disponibles. Por ejemplo, DreamHome puede decidir poner en marcha una línea de atención a los clientes que permita a los clientes potenciales telefonear a un número gratuito para indicar su interés en una cierta zona o en un cierto inmueble, para concertar una visita o, básicamente, para hacer cualquier otra cosa que pudieran llevar a cabo visitando una sucursal. Suponga que la empresa establece centros de llamada en cada sucursal. Las llamadas serán encaminadas a la sucursal más cercana; por ejemplo, alguien interesado en los inmuebles de Londres y que esté telefoneando desde Glasgow será encaminado a una oficina de Glasgow. El sistema de telecomunicaciones intentará equilibrar la carga y, si Glasgow está particularmente ocupada, puede reenviar las llamadas a Edimburgo. Cada centro de llamadas tiene que poder acceder a los datos, y actualizados, situados en cualquiera de las otras sucursales y hacer que las tuplas actualizadas se repliquen en los restantes sitios, como se ilustra en la Figura 24.3 La propiedad compartida puede conducir a escenarios de conflicto y la arquitectura de replicación tiene que poder emplear una metodología de detección y resolución de conflictos. Volveremos a este problema en la sección siguiente.
24.6 Servidores de replicación Hasta la fecha, los sistemas de gestión de bases de datos distribuidas (SGBDD) de propósito general no han tenido una amplia aceptación. Esta falta de actividad comercial se produce a pesar de que muchos de los protocolos y problemas asociados con la gestión de una base de datos distribuida se comprenden bastante bien (véase la Sección 22.1.2). Es la replicación de datos, es decir, la copia y mantenimiento de datos en múltiples servidores, la que parece ser la solución preferida. Todos los principales fabricantes de bases de datos, como Microsoft Office Access y Oracle proporcionan una solución de replicación de un tipo u otro y muchos fabricantes no especializados en bases de datos también ofrecen métodos alternativos para replicar los datos. El servidor de replicación es una técnica alternativa y potencialmente más simple para la distribución de datos. En esta sección, vamos a examinar la funcionalidad que cabe esperar de un servidor de replicación y luego hablaremos de algunos de los problemas de implementación asociados con esta tecnología.
Aberdeen
Glasgow (lectura/escritura)
(1ectu ra/ escritu ra)
Londres
Edimburgo (Iectu ra/ escritu ra)
(lectura/escritura)
Figura 24.3.
Propiedad de tipo actualización
ubicua (igualitaria).
Capítulo 24 Replicación y bases de datos móviles
24.6.1
717
Funcionalidad del servidor de replicación
En su nivel básico, esperamos que un servicio de replicación de datos distribuido sea capaz de copiar los datos de una base de datos a otra, síncrona o asíncronamente. Sin embargo, hay muchas otras funciones que hay que proporcionar, como por ejemplo (Buretta, 1997): •
Escalabilidad. El servicio debe ser capaz de gestionar la replicación tanto de pequeños como de grandes volúmenes de datos.
•
Mapeado y transformación. El servicio debe ser capaz de gestionar la replicación entre diversos SGBD y plataformas heterogéneos. Como hemos indicado en la Sección 22.1.3, esto puede implicar el mapeado y la transformación de los datos de un modelo de datos a otro distinto, o de un tipo de datos a otro tipo de datos correspondiente en otro SGBD.
•
Replicación de objetos. Debe ser posible replicar objetos, además de los datos. Por ejemplo, algunos sistemas permiten replicar los índices y los procedimientos almacenados (o disparadores).
•
Especificación del esquema de replicación. El sistema debe proporcionar un mecanismo para permitir que un usuario privilegiado especifique los datos y los objetos que hay que replicar.
•
Mecanismo de subscripción. El sistema debe proporcionar un mecanismo que permita a un usuario privilegiado subscribirse a los datos y objetos disponibles para replicación.
•
Mecanismo de inicialización. El sistema debe proporcionar un mecanismo que permita la inicialización de una réplica de destino.
•
Fácil administración. Debe ser sencillo para el DBA administrar el sistema y comprobar el estado y monitorizar el rendimiento de los componentes del sistema de replicación.
24.6.2
Problemas de implementación
En esta sección vamos a examinar algunos problemas de implementación cación de datos por parte del servidor de replicación, incluyendo: •
actualizaciones transaccionales;
•
instantáneas y disparadores de la base de datos;
•
detección y resolución de conflictos.
Actualizaciones
asociados con la provisión de repli-
transaccionales
Una técnica utilizada al principio por algunas organizaciones para proporcionar un mecanismo de replicación era descargar los datos apropiados en un soporte de copia de seguridad (por ejemplo, cinta) y luego enviar dicho soporte por mensajero a un segundo sitio, donde se lo cargaba en otro sistema informático. El segundo sitio tomaba entonces decisiones basándose en estos datos, que podían tener varios días de antigiledad. Las principales desventajas de esta técnica son que las copias pueden no estar actualizadas y que se requiere una intervención manual. Otros intentos posteriores para proporcionar un mecanismo de replicación automático eran no transaccionales por naturaleza. Los datos se copiaban sin mantener la atomicidad de la transacción, perdiéndose así potencialmente la integridad de los datos distribuidos. Esta técnica se ilustra en la Figura 24.4(a), que muestra una transacción consistente en múltiples operaciones de actualización de diferentes relaciones en el sitio de origen, las cuales se transformarán durante el proceso de replicación en una serie de transacciones independientes, cada una de las cuales es responsable de actualizar una relación concreta. Si algunas de las transacciones en el sitio de destino tienen éxito mientras que las otras fallan, la coherencia entre las bases de datos de origen y de destino se habrá perdido. Por contraste, la Figura 24.4(b) ilustra un mecanismo de replicación de tipo transaccional, en el que la estructura de la transacción original en la base de datos de origen también se mantiene en el sitio de destino.
718
Sistemas de bases de datos
Base de datos de origen
ate Relation A
Transaction
Base de datos de destino violada Transaction Update Relation A eo commit; Transaction Update Relation B commit; Integridad transaccional
(a)
Transaction
conservada Integridad transaccional Relation A UpdateUpdate Relation B
Commit Transaction Update Relation
oe
(b)
Figura 24.4.
(a) Actualizaciones de replicación no transaccionales; de replicación transaccionales.
(b) actualizaciones
Instantáneas y disparadores de la base de datos En esta sección, vamos a examinar cómo pueden utilizarse las instantáneas para proporcionar un mecanismo de replicación transaccional. También compararemos este método con otro mecanismo que utiliza disparadores de base de datos. Instantáneas Las instantáneas permiten la distribución asíncrona de cambios realizados en relaciones individuales, colecciones de relaciones, vistas o fragmentos de relaciones, de acuerdo con una planificación predefinida, por ejemplo una vez por día a las 23:00. Veamos un caso: podemos almacenar la relación Staff en un sitio (el sitio maestro) y crear una instantánea que contenga una copia completa de la relación Staff en cada sucursal. Alternativamente, podríamos crear una instantánea de la relación Staffpara cada sucursal que contuviera únicamente los detalles de los empleados que trabajan en dicha sucursal concreta. Proporcionaremos un ejemplo de cómo crear instantáneas en OracIe en la Sección 24.8. Una técnica común para gestionar las instantáneas utiliza el archivo de registro de recuperación de la base de datos, imponiendo así una mínima carga adicional al sistema. La idea básica es que el archivo de registro es la mejor fuente para capturar los cambios realizados en los datos de origen. De esa forma, puede crearse un mecanismo que utilice el archivo de registro para detectar las modificaciones en los datos de origen y propaguen los cambios a las bases de datos de destino, sin interferir con las operaciones normales del sistema de origen. Los distintos productos de bases de datos difieren en el modo de integrar este mecanismo con el SGBD. En algunos casos, el proceso es parte del propio servidor SGBD, mientras que en otros se ejecuta como un servidor externo independiente. También es necesario un proceso de gestión de colas para enviar las actualizaciones a los demás sitios. En caso de fallo de la red o de un sitio, la cola puede almacenar las actualizaciones hasta que se restaure la conexión. Para garantizar la integridad, el orden de las actualizaciones debe mantenerse durante la entrega.
Disparadores de la base de datos Otra técnica alternativa permite a los usuarios construir sus propias aplicaciones de replicación utilizando disparadores de la base de datos. Con este método, es responsabilidad del usuario crear el código dentro de un disparador que se ejecute cada vez que tenga lugar el suceso apropiado, como por ejemplo cada vez que se
Capítulo 24 Replicación y bases de datos móviles
719
cree una nueva tupla o cada vez que se actualice una tupla ya existente. Por ejemplo, en Oracle podemos utilizar el siguiente disparador para mantener una copia duplicada de la relación Staff en otro sitio, determinado por el enlace de base de datos denominado RENTALS.GLASGOW.NORTH.COM (véase la Sección 23.9): CREATE TRIGGER StaffAfterlnsRow BEFORE INSERT ON Staff FOREACHROW BEGIN INSERT INTO [email protected] VALUES (:new.staffNo,:new:fName,:new:IName,:new.position.:new:sex, :new.DOB,:new:salary, :new:branchNo); END; Este disparador será invocado para cada tupla que se inserte en la copia principal de la relación Staff. Aunque ofrece más flexibilidad que las instantáneas, esta técnica tiene las siguientes desventajas: •
La gestión y ejecución de los disparadores consume recursos adicionales, reduciendo las prestaciones.
•
Los disparadores transfieren los elementos de datos cuando son modificados, pero no tienen ningún conocimiento sobre la naturaleza transaccional de las modificaciones.
•
Los disparadores se ejecutan cada vez que cambia una tupla en la relación maestra. Si la relación maestra se actualiza frecuentemente, esto puede imponer una sobrecarga significativa a la aplicación y a la red. Por contraste, las instantáneas recopilan todas las actualizaciones en una única transacción.
•
Los disparadores no pueden planificarse; se ejecutan cada vez que tiene lugar una actualización de la relación maestra. Las instantáneas, por el contrario, pueden planificarse o ejecutarse manualmente. Sin embargo, ambos métodos deben evitar que se produzca una gran carga de transacciones de replicación durante los picos de utilización del sistema.
•
Si se están replicando múltiples tablas relacionadas, la sincronización de las replicaciones puede llevarse a cabo utilizando mecanismos tales como los grupos de refresco. Tratar de hacer esto con los disparadores es mucho más' complejo.
•
La activación de los disparadores no puede deshacerse fácilmente en caso de que haya que abortar o anular una transacción.
Detección y resolución de conflictos Cuando se permite a múltiples sitios actualizar los datos replicados, debe emplearse un mecanismo para detectar las actualizaciones conflictivas y restaurar la coherencia de los datos. Un mecanismo simple para detectar los conflictos dentro de una única relación consiste en que el sitio de origen envíe tanto los valores antiguos como los nuevos (imagen anterior e imagen posterior) de las tuplas que hayan sido actualizadas desde la última operación de refresco. En el sitio de destino, el servidor de replicación puede comprobar cada tupla de la base de datos de destino que haya sido también actualizada y comparada con esos valores. Sin embargo, es necesario tener también en cuenta otros posibles tipos de conflictos que habrá que detectar, como la violación de la integridad referencial entre dos relaciones. Se han propuesto muchos mecanismos para la resolución de conflictos, pero algunos de los más comunes son los siguientes: •
Marcas temporales inferiores y superiores. Se aplica la actualización correspondiente tengan la marca temporal inferior (más antigua) o superior (más moderna).
•
Prioridad de los sitios. Se aplica la actualización del sitio que tenga la mayor prioridad.
•
Actualizaciones aditivas y promediadas. Se aplican conmutativamente las actualizaciones. Este tipo de resolución de conflictos puede utilizarse cuando los cambios efectuados en un atributo sean de naturaleza aditiva, como por ejemplo salary = salary + x
a los datos que
720
Sistemas de bases de datos
•
Valores mínimo y máximo. Se aplican las actualizaciones mínimo o máximo.
correspondientes
a un atributo con el valor
•
Definida por el usuario. Se permite al DBA especificar un procedimiento definido por el usuario para resolver el conflicto. Pueden existir diferentes procedimientos para distintos tipos de conflicto.
•
Guardar para resolución manual. Se almacena el conflicto en un registro de errores para que el DBA lo revise en un instante posterior y lo resuelva de forma manual.
Algunos sistemas también resuelven los conflictos resultantes del uso distribuido de restricciones de clave primaria o unívoca; por ejemplo: •
Agregar el nombre de sitio al valor duplicado Se añade el nombre global de base de datos del sitio origen de la actualización al valor del atributo replicado. Añadir un número de secuencia al valor duplicado Se añade un número de secuencia al valor del atributo.
• •
Descartar el valor duplicado
Se descarta el registro del sitio de origen que provoca los errores.
Claramente, si la resolución de conflictos se basa en marcas temporales, resulta vital que las marcas temporales de los distintos sitios que participan en la replicación incluyan un elemento indicativo de la zona horaria o que todos los sitios empleen la misma zona horaria. Por ejemplo, los servidores de bases de datos pueden utilizar la hora GMT (Greenwich Mean Time) o alguna otra zona horaria preacordada, preferiblemente una donde no se produzcan cambios debido a la entrada en vigor del horario de verano.
24.7 Introducción a las bases de datos móviles Estamos asistiendo actualmente a un incremento de la demanda de informática móvil, para proporcionar el tipo de soporte requerido por un número cada vez mayor de trabajadores móviles. Dichas personas necesitan trabajar como si estuvieran en la oficina, pero en realidad están haciendo su labor en ubicaciones remotas, como sus casas, las instalaciones del cliente o simplemente mientras están de viaje hacia una ubicación remota. La 'oficina' puede acompañar al trabajador remoto, en forma de una computadora portátil, un PDA (personal digital assistant, asistente digital person
Una base de datos que es portable y físicamente independiente del servidor corporativo de base de datos, pero es capaz de comunicarse con ese servidor desde sitios remotos, permitiendo la compartición de datos corporativos.
Con las bases de datos móviles, los usuarios tienen acceso a datos corporativos desde su computadora portátil, PDA o algún otro dispositivo de acceso a Internet que las aplicaciones requieran utilizar en los sitios remotos. En la Figura 24.5 se muestra la arquitectura típica de un entorno de base de datos móvil. Los componentes de un entorno de base de datos móvil incluyen: • •
servidor de base de datos corporativo y SGBD que gestiona y almacena los datos corporativos y proporciona aplicaciones corporativas; base de datos remota y SGBD que gestiona y almacena los datos móviles y gestiona los datos móviles;
•
plataforma de base de datos móvil, que puede ser una computadora portátil, un PDA u otro dispositivo de acceso a Internet;
•
enlaces de comunicación bidireccionales entre el SGBD corporativo y el SGBD móvil.
Capítulo 24 Replicación y bases de datos móviles
Base de datos móvil Enlace de comunicaciones
721
Plataforma de Usuario final base de datos móvil
Aplicaciones de base de datos móvil
Base de datos corporativa Servidor de datos corporativo
Base de datos móvil
Plataforma de base de datos móvil
t
Usuario final
Aplicaciones de base de datos móvil
Figura 24.5.
Arquitectura
típica para un entorno de base de datos móvil.
Dependiendo de los requisitos concretos de las aplicaciones móviles, en algunos casos el usuario de un dispositivo móvil puede conectarse a un servidor de base de datos corporativo y trabajar allí con los datos, mientras que en otros el usuario puede descargar los datos y trabajar con ellos en un dispositivo móvil o cargar en la base de datos corporativa los datos capturados en el sitio remoto. La comunicación entre las bases de datos corporativa y móvil es usualmente intermitente y suele establecerse durante periodos cortos de tiempo a intervalos irregulares. Aunque no resulta muy común, hay algunas aplicaciones que requieren una comunicación directa entre las bases de datos móviles. Los dos problemas principales asociados con las bases de datos móviles son la gestión de las bases de datos móvil y la comunicación entre las bases de datos móvil y corporativa. En la siguiente sección se identifican los requisitos de los SGBD móviles.
24.7.1
Sistemas SGBD móviles
Todos los principales fabricantes de sistemas SGBD ofrecen ahora un SGBD móvil. De hecho, este desarrollo es en parte responsable del increíble crecimiento actual de ventas experimentado por los principales fabricantes de sistemas SGBD. La mayoría de los fabricantes promocionan sus SGBD móviles como capaces de comunicarse con muchos de los principales SGBD relacionales y capaces también de proporcionar servicios de base de datos que requieran recursos de procesamiento s limitados, para adaptarse a los recursos que actualmente proporcionan los dispositivos móviles. La funcionalidad adicional requerida de los SGBD móviles incluye la capacidad de: •
comunicarse con el servidor centralizado de base de datos utilizando técnicas tales como la comunicación inalámbrica o el acceso a Internet;
•
replicar los datos en el servidor de base de datos centralizado y en el dispositivo móvil;
• •
sincronizar los datos del servidor de base de datos centralizado y del dispositivo móvil; capturar datos de varias fuentes, como por ejemplo, de Internet;
•
gestionar los datos en el dispositivo móvil;
•
analizar los datos almacenados en un dispositivo móvil;
722 •
Sistemas de bases de datos crear aplicaciones móviles personalizadas.
Los fabricantes de sistemas SOBD están bajando los precios por usuario a tales niveles que ahora resulta atractivo para las organizaciones ampliar las aplicaciones a los dispositivos móviles, mientras que antes las aplicaciones sólo estaban disponibles dentro de la oficina. Actualmente, la mayoría de los SOBD móviles sólo proporcionan funciones SQL pre-empaquetadas para la aplicación móvil, en lugar de soportar mecanismos amplios de consulta de la base de datos o de análisis de los datos. Sin embargo, la previsión es que a corto plazo los dispositivos móviles ofrezcan funcionalidad que sea cuando menos tan amplia como la actualmente disponible en la sede corporativa.
24.8 Replicación en Oracle Para completar este capítulo, vamos a examinar la funcionalidad de replicación de Oracle9i (Oracle Corporation, 2004e). En esta sección, utilizaremos la terminología de este SOBD concreto; Oracle hace referencia a las relaciones con el término tablas, estando las tablas compuestas por columnas y filas. Hemos proporcionado una introducción al SOBD Oracle en la Sección 8.2.
24.8.1
Funcionalidad de replicación de Oracle
Además de proporcionar una capacidad de SOBD distribuido, Oracle también proporciona Oracle Advanced Replication para soportar tanto la replicación síncrona como la asíncrona. La replicación en Oracle permite replicar tanto las tablas como los objetos de soporte, como por ejemplo vistas, disparadores, paquetes, índices y sinónimos. En la edición estándar de Oracle, sólo puede haber un sitio maestro que replique los cambios a los sitios esclavos. En la edición empresarial, puede haber múltiples sitios maestros y las actualizaciones pueden tener lugar en cualquiera de esos sitios. En esta sección, vamos a analizar brevemente el mecanismo de replicación de Oracle. Comenzaremos definiendo los tipos de replicación que Oracle soporta.
Tipos de replicación Oracle soporta cuatro tipos de replicación: •
Instantáneas de sólo lectura. Algunas veces se las denomina vistas materializadas. Con este mecanismo, se copia una tabla maestra a una o más bases de datos remotas. Los cambios en la tabla maestra se reflejan en las tablas instantáneas siempre que la instantánea se refresca, a voluntad del sitio donde la instantánea reside.
•
Instantáneas actualizables. Es un mecanismos similar al de las instantáneas de sólo lectura, pero difiere en que los sitios que almacenan las instantáneas pueden verificar los datos y enviar los cambios al sitio maestro. De nuevo, quien determina la frecuencia de las operaciones de refresco es el sitio que almacena la instantánea. También determina la frecuencia con la que se envían las actualizaciones al sitio maestro.
•
Replicación multimaestro. Una tabla se copia en una o más bases de datos remotas, pudiendo la tabla ser actualizada. Las modificaciones son enviadas a las otras bases de datos a intervalos que puede configurar el DBA para cada grupo de replicación.
•
Replicación procedimental. o más bases de datos.
Una llamada a una función o procedimiento empaquetado se replica a una
Analicemos ahora con más detalles estos tipos de replicación.
Grupos de replicación Para simplificar la administración, Oracle gestiona los objetos de replicación utilizando grupos de replicación. Nonnalmente, los grupos de replicación se crean para organizar los objetos del esquema requeridos por una aplicación concreta. Los objetos de un grupo de replicación pueden provenir de diversos esquemas y un esquema puede contener objetos de diferentes grupos de replicación. Sin embargo, cada objeto de replicación sólo puede ser miembro de un único grupo.
Capítulo 24 Replicación y bases de datos móviles
723
Sitios de replicación Un entorno de replicación Orac1e puede tener dos tipos de sitio: •
Sitio maestro. Mantiene una copia completa de todos los objetos de un grupo de replicación. Todos los sitios maestros de un entorno de replicación multimaestro se comunican directamente entre sí para propagar las actualizaciones de los datos correspondientes a un grupo de replicación (que en un entorno de replicación multimaestro se denomina grupo maestro). Cada grupo maestro correspondiente de cada sitio debe contener el mismo conjunto de objetos de replicación, basado en un único sitio de definición maestro.
•
Sitio de instantánea. Soporta instantáneas de sólo lectura e instantáneas actualizables de los datos de las tablas almacenadas en un sitio maestro asociado. Mientras que en la replicación multimaestro las tablas son actualizadas de manera continua por otros sitios maestros, las instantáneas se actualizan a partir de una o más tablas maestras mediante lotes de actualización individuales, conocidos con el nombre de refrescos, a partir de un único sitio maestro. Los grupos de replicación almacenados en un sitio de instantáneas se denominan grupos de instantáneas.
Grupos de refresco Si es necesario refrescar dos o más instantáneas al mismo tiempo, por ejemplo para preservar la integridad entre tablas, Orac1e permite definir grupos de refresco. Después de refrescar todas las instantáneas, los datos de todas las instantáneas del grupo se corresponderán con el mismo instante temporal transaccionalmente coherente. El paquete DBMS _REFRESH contiene procedimientos para mantener los grupos de refresco desde PL/SQL. Por ejemplo, podríamos agrupar las instantáneas LocalStaff, LocalClient y LocalOwner en un grupo de instantáneas de la forma siguiente:
DECLARE vSnapshotList DBMS _UTILITY.UNCL _ARRAY; BEGIN vSnapshotList(l) = 'LocaIStaff'; vSnapshotList(2) = 'LocaIClient'; vSnapshotList(3) = 'LocaIOwner'; DBMS_REFRESH.MAKE (name =} 'LOCAL_INFO', tab =} vSnapshotList, next_date =} TRUNC(sysdate) + 1, interval + 'sysdate + 1');
END;
Tipos de refresco Orac1e puede refrescar una instantánea en una de las siguientes formas: •
COMPLETA. El servidor que gestiona la instantánea ejecuta la consulta que define la instantánea. El conjunto de resultados de la consulta sustituye a los datos de instantánea existente, con el fin de refrescar la instantánea. Orac1e puede realizar refrescos completos para cualquier instantánea. Dependiendo de la cantidad de datos que satisfaga la consulta de definición, una operación completa de refresco puede tardar bastante más tiempo que un refresco rápido.
•
RÁPIDO. El servidor que gestiona la instantánea identifica primero los cambios que han tenido lugar en la tabla maestra desde la operación más reciente de refresco de la instantánea y luego aplica a la instantánea dichos cambios. Los refrescos rápidos son más eficientes que los refrescos completos cuando son pocos los cambios realizados en la tabla maestra, porque el servidor y la red tienen que replicar menos datos. Los refrescos rápidos sólo están disponibles para las instantáneas cuando la tabla maestra disponga de un registro de instantánea. Si no es posible realizar un refresco rápido, se genera un error y la instantánea no se refrescará.
•
FORZADA. El servidor que gestiona la instantánea trata primero de realizar un refresco rápido. Si no es posible realizar el refresco rápido, Oracle realiza un refresco completo.
724
Sistemas de bases de datos
Creación de instantáneas El procedimiento básico para crear una instantánea de sólo lectura es el siguiente: (1) Identificar la tabla o tablas del sitio o sitios maestros que hay que replicar al sitio de instantánea y el esquema del que son propiedad las instantáneas. (2) Crear uno o más enlaces de base de datos desde el sitio de instantánea a los sitios maestros. (3) Crear registros de instantánea (véase más abajo) en la base de datos maestra para cada tabla maestra, si se necesita realizar refrescos rápidos. (4) Usar la instrucción CREA TE SNAPSHOT para crear la instantánea. Por ejemplo, podemos definir una instantánea que contenga los detalles del personal que trabaja en la sucursal B003 de la siguiente forma: CREATE SNAPSHOT Staff REFRESH FAST START WITH sysdate NEXT sysdate + 7 WITH PRIMARY KEY AS SELECT * FROM [email protected] WHERE branchNo = 'B003'; En este ejemplo, la cláusula SELECT define las filas de la tabla maestra (ubicada en RENTALS.LONDON.SOUTH.COM; véase la Sección 23.9) que hay que duplicar. La cláusula START WITH indica que la instantánea debe refrescarse cada siete días, a partir de hoy. En el sitio de la instantánea, Oracle crea una tabla denominada SNAP$_Staff que contiene todas las columnas de la tabla maestra Staff. Oracle también crea una vista denominada Staffdefinida sobre una consulta sobre la tabla SNAP$_Staff. También planifica un trabajo en la cola de trabajos para refrescar la instantánea. (5) Opcionalmente, crear uno o más grupos de refresco en el sitio de instantánea y asignar cada instantánea a un grupo.
Registros de instantánea Un registro de instantánea es una tabla que controla los cambios realizados en una tabla maestra. El registro de instantánea puede crearse utilizando la instrucción CREATE SNAPSHOT LOG. Por ejemplo, podríamos crear un registro de instantánea para la tabla Staffde la siguiente forma: CREATE SNAPSHOT LOG ON Staff WITH PRIMARY KEY TABLESPACE DreamHome Data STORAGE (INITIAL 1 NEXT 1M PCTINCREASE
O);
Esto crea una tabla denominada DreamHome.mlog$_Staffque contiene la clave principal de la tabla Staff,que es el atributo staffNoy diversas otras columnas, como por ejemplo el instante en que la fila fue actualizada por última vez, el tipo de actualización y los valores antiguo/nuevo. Oracle también crea un disparador posterior de fila para la tabla Staff que rellena el registro de instantánea después de cada operación de inserción, actualización o borrado. Los registros de instantánea también pueden ser creados interactivamente por Oracle Replication Manager.
Instantáneas
actualizables
Como hemos indicado al principio de esta sección, las instantáneas actualizables son similares a las instantáneas de sólo lectura, pero los sitios de instantánea son capaces de modificar dos datos y de devolver los datos al sitio maestro. El sitio de instantánea determina la frecuencia de los refrescos y la frecuencia con la que se devuelven las actualizaciones al sitio maestro. Para crear una instantánea actualizable, simplemente especificamos la cláusula FOR UPDATE antes de la subselección en la instrucción CREATE SNAPSHOT. En el caso de crear una instantánea actualizable para la tabla Staff, Oracle crearía los siguientes objetos:
Capítulo 24 Replicación y bases de datos móviles (1) Una tabla ción.
SNAP$ _ STAFF
725
en el sitio de instantánea que contiene los resultados de la consulta de defini-
(2) Una tabla USLOG$ _ STAFF en el sitio de instantánea que captura la información acerca de las filas modificadas. Esta información se utiliza para actualizar la tabla maestra. (3) Un disparador USLOG$_STAFF tabla USLOG$_STAFF.
sobre la tabla
(4) Un disparador STAFF$RT sobre la tabla al paquete STAFF$TP.
en el sitio de instantánea, que rellene la
SNAP$_STAFF
SNAP$_STAFF
en el sitio de instantánea, que realice llamadas
(5) El paquete STAFF$TP en el sitio de instantánea, que construye las llamadas diferidas a procedimiento remoto para invocar el paquete STAFF$RP en el sitio maestro. (6) El paquete STAFF$RP que realiza las actualizaciones en la tabla maestra. (7) El paquete STAFF$RR que contiene rutinas para resolución de conflictos en el sitio maestro. (8) La vista
Slaff
definida sobre la tabla
SNAP$ _ STAFF.
(9) Una entrada en la cola de trabajos que llama al paquete DBMS_REFRESH.
Resolución de conflictos Hemos hablado de la resolución de conflictos en los entornos de replicación al final de la Sección 24.5.2. Oracle implementa muchos de los mecanismos de resolución de conflictos explicados en dicha sección utilizando grupos de columnas. Un grupo de columnas es una agrupación lógica de una o más columnas en una tabla replicada. Cada columna no puede pertenecer más que a un grupo de columnas y las columnas que no sean explícitamente asignadas a ningún grupo de columnas serán miembros de un grupo de columnas fantasma que utilizará métodos predeterminados para la resolución de conflictos. Pueden crearse grupos de columnas y pueden asignársele métodos de resolución de conflictos, utilizando el paquete DBMS _REPCAT. Por ejemplo, para usar sobre la tabla Slaff un método de resolución basado en la marca temporal más reciente con el fin de resolver los cambios realizados en el salario almacenado en slaff, necesitaríamos almacenar uná columna de marca temporal en la tabla slaff, que podríamos denominar salaryTimeslamp, y usar las siguientes dos llamadas a procedimiento:
-
EXECUTE DBMS REPCAT.MAKE
--COLUMN
GROUPS
(gname => 'HR', oname => 'STAFF', column_group => 'SALARY_GP', list_ oC column _names 'slaffNo, salary, salaryTimeslamp'); EXECUTE DBMS - REPCAT.ADD --UPDATE RESOLUTION (sname => 'HR', oname => 'STAFF', column_group => 'SALARY_GP', sequence_no => 1, method => 'LATEST_TIMESTAMP', parameter_column_name => 'salaryTimestamp', comment => 'Method 1 added on' sysdate); 11
El paquete DBMS_REPCAT también contiene rutinas para crear grupos de prioridad y sitios de prioridad. Los grupos de columnas, los grupos de prioridad y los sitios de prioridad también pueden ser creados interactivamente por Oracle Replication Manager.
Replicación multimaestro Como se explica al principio de esta sección, con la replicación multimaestro se copia una tabla a una o más bases de datos remotas, en las que la tabla puede ser actualizada. Las modificaciones se envían a las otras bases de datos a intervalos que el DBA configura para cada grupo de replicación. En muchos aspectos, la implementación de la replicación multimaestro es más simple que la de las instantáneas actualizables, ya que no hay distinción entre los sitios maestros y los sitios esclavos. El mecanismo que subyace a este tipo de replicación está compuesto por disparadores definidos sobre las tablas replicadas y que invocan procedimientos empaquetados que ponen en cola las llamadas RPC diferidas a la base de datos maestra remota. La resolución de conflictos se lleva a cabo como hemos descrito anteriormente.
726
Sistemas de bases de datos
Resumen del capítulo •
La replicación de bases de datos es un mecanismo de gran importancia, porque permite a las organizaciones proporcionar a los usuarios acceso a datos actualizados desde cualquier sitio y en cualquier momento.
•
La replicación de bases de datos es el proceso de copiar y mantener objetos de la base de datos, como por ejemplo relaciones, en múltiples bases de datos que conforman un sistema de base de datos distribuido.
•
Las ventajas de la duplicación de la base de datos son una mayor disponibilidad, una mayor fiabilidad, unas mayores prestaciones, una reducción de la carga y el soporte para el procesamiento desconectado, para un número mayor de usuarios y para aplicaciones avanzadas.
•
Un objeto de replicación es un objeto de la base de datos, como por ejemplo una relación, índice, vista, procedimiento o función, que existe en múltiples servidores dentro de un sistema de base de datos distribuido. En un entorno de replicación, las actualizaciones realizadas a un objeto de replicación en un sitio se aplican a las copias de todos los demás sitios.
•
En un entorno de replicación, los objetos de replicación se gestionan utilizando grupos de replicación. Un grupo de replicación es una colección de objetos de replicación lógicamente relacionados.
•
Los grupos de replicación pueden existir en múltiples sitios de replicación. Los entorno s de replicación soportan dos tipos básicos de sitios: sitios maestros y sitios esclavos. Un sitio maestro controla un grupo de replicación y todos los objetos pertenecientes a dicho grupo. Esto se consigue manteniendo una copia completa de todos los objetos del sitio del grupo de replicación y propagando los cambios realizados a las demás copias del grupo de replicación ubicadas en los sitios esclavos.
•
•
Un sitio esclavo contiene sólo una instantánea de un grupo de replicación, como por ejemplo los datos que una tabla tenía en un cierto instante temporal. Normalmente, las instantáneas se refrescan periódicamente para sincronizarlas con el sitio maestro.
•
La replicación síncrona es la actualización inmediata de los datos replicados de destino, después de efectuarse una actualización en los datos de origen. Esta se lleva a cabo normalmente mediante el protocolo 2PC (confirmación en dos fases).
•
La replicación asíncrona es el proceso por el cual la base de datos replicada de destino se actualiza en algún instante posterior a la actualización de la base de datos de origen. El retardo necesario para volver a establecer la coherencia entre la base de datos de origen y la de destino puede ir desde unos pocos segundos a varias horas o incluso días. Sin embargo, los datos terminarán por sincronizarse y por adoptar los mismos valores en todos los sitios.
•
Los modelos de propiedad de los datos para la replicación son el modelo maestro/esclavo, el modelo de flujo de trabajo y el modelo de actualización ubicua (igualitario). En los primeros dos modelos, las réplicas son de sólo lectura. Con el modelo de actualización ubicua, todas las copias deben ser actualizadas, por lo que es necesario proporcionar un mecanismo de detección y resolución de conflictos para mantener la integridad de los datos.
•
Los mecanismos típicos de replicación son las instantáneas y los disparadores de la base de datos. La propagación de las actualizaciones entre las distintas réplicas puede ser transaccional o no transaccional. Una base de datos móvil es una base de datos portable y que está fisicamente separada del servidor de base de datos corporativo pero que es capaz de comunicarse con dicho servidor de sitios remotos, permitiendo así la compartición de los datos corporativos. Con las bases de datos móviles, los usuarios tienen acceso a las datos corporativos desde su computadora portátil, su PDA o cualquier otro dispositivo de acceso a Internet que las aplicaciones requieran en los sitios remotos.
•
Cuestiones de repaso 24.1.
Explique en qué se diferencia una base de datos distribuida de una base de datos replicada.
Capítulo 24 Replicación y bases de datos móviles
727
24.2.
Indique las ventajas de utilizar la replicación en un sistema distribuido.
24.3.
Proporcione algunos ejemplos de aplicaciones típicas que utilicen la replicación.
24.4.
Describa qué es lo que representa los conceptos de objeto replicado, grupo de replicación, sitio maestro y sitio esclavo en un entorno de replicación de bases de datos.
24.5.
Indique las similitudes y diferencias entre la replicación síncrona y la asíncrona.
24.6.
Indique las similitudes y diferencias entre los distintos modelos de propiedad de los datos disponibles en un entorno de replicación. Proporcione un ejemplo de cada modelo.
24.7.
Explique la funcionalidad requerida de un servidor de replicación.
24.8.
Indique los problemas de implementación
24.9.
Explique cómo dan soporte las bases de datos móviles a los trabajadores móviles.
asociados con la replicación.
24.10. Describa la funcionalidad requerida de un SGBD móvil.
Ejercicios 24.11. Se nos pide realizar una labor de consultoría por cuenta del Director Gerente de DreamHome para investigar los requisitos de distribución de datos de la organización y preparar un informe del uso potencial de un servidor de replicación de bases de datos. El informe debe comparar la tecnología del SGBD centralizado con la del servidor de replicación e indicar las ventajas y desventajas de implementar mecanismos de replicación de la base de datos en la organización, así como las áreas previstas donde puedan aparecer problemas. El informe debe también contemplar la posibilidad de utilizar un servidor de replicación para satisfacer los requisitos de distribución. Finalmente, el informe debe contener un conjunto de recomendaciones adecuadamente justificadas donde se proponga un curso apropiado de acción para DreamHome. 24.12. Se nos pide realizar una labor de consultoría por cuenta del Director Gerente de DreamHome para investigar cómo podría utilizarse la tecnologia de bases de datos móviles en la organización. El resultado de la investigación debe presentarse como un informe donde se analicen los beneficios potenciales asociados con Hi informática móvil y los problemas que pueden surgir al tratar de utilizar la tecnologia de bases móviles en la organización. El informe debe también contener un conjunto de recomendaciones adecuadamente justificado donde se proponga una solución apropiada para DreamHome.
Bases de datos orientadas a objetos
Capítulo 25 Introducción
a los SGBD orientados a objetos
Capítulo 26 Bases de datos orientadas a objetos: conceptos Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas Capítulo 28 Bases de datos objeto-relaciona les
Introducción a los SGBD orientados a objetos Objetivos del capítulo: En este capítulo aprenderá: •
Los requisitos para las aplicaciones avanzadas de bases de datos.
•
Por qué los SGBD relacionales no están actualmente bien adaptados para soportar las aplicaciones avanzadas de bases de datos.
•
Los conceptos asociados con la orientación a objetos: • •
abstracción, encapsulación y ocultación de información; objetos y atributos;
•
identidad de los objetos;
•
métodos y mensajes;
•
clases, subclases, superclase y herencia;
•
sobrecarga;
•
polimorfismo y enlace dinámico.
•
Los problemas asociados con el almacenamiento
de objetos en una base de datos relacional.
•
Qué constituye la siguiente generación de sistemas de bases de datos.
•
Los conceptos básicos del análisis y diseño de bases de datos orientadas a objetos mediante UML.
La orientación a objetos es una técnica de desarrollo software que ha mostrado considerables capacidades para resolver algunos de los problemas clásicos de la ingeniería del software. El concepto subyacente a la tecnología de objetos es que todo el software debe construirse utilizando componentes estándar y reutilizables siempre que sea posible. Tradicionalmente, la ingeniería del software y la gestión de bases de datos eran disciplinas separadas. La tecnología de bases de datos se ha concentrado en los aspectos estáticos del almacenamiento de la información, mientras que la ingeniería del software lo ha hecho en modelar los aspectos dinámicos del software. Con la llegada de la tercera generación de sistemas de gestión de bases de datos, los denominados sistemas de gestión de bases de datos orientados a objetos (SGBDOO) y sistemas de gestión de bases de datos objeto-relacionales (SGBDOR), las dos disciplinas se han combinado para permitir el modelado concurrente tanto de los datos como de los procesos que actúan sobre los mismos. Sin embargo, existe actualmente una importante discusión en lo que respecta a esta siguiente ge.neración de sistemas SGBD. El éxito de los sistemas relacionales en las dos décadas anteriores es evidente y los tradicionalistas consideran que es suficiente ampliar el modelo relacional con capacidades adicionales (de orientación a objetos). Otros piensan que un modelo relacional subyacente resulta inadecuado para gestionar aplicaciones complejas, como el diseño asistido por computadora, la ingeniería del software asistida por computadora y los sistemas de información geográfica. Para tratar de entender estos nuevos tipos de SGBD y los argumentos utilizados por ambos bandos, hemos dedicado cuatro capítulos a explicar la tecnología y los problemas relacionados con la misma.
732
Sistemas de bases de datos
En el Capítulo 26, se analiza la aparición de los SGBDOO y se examinan algunos de los problemas que afectan a estos sistemas. En el Capítulo 27 se examina el modelo de objetos propuesto por el ODMG (Object Data Management Group), que se ha convertido en un estándar defacto para los SGBDOO, y ObjectStore, un SGBDOO comercial. En el Capítulo 28 se analiza la aparición de los SGBDOR y se examinan algunos de los problemas relacionados con ellos. En particular, examinaremos SQL:2003, la última versión del estándar ANSI/ISO para SQL, así como algunas de las características de orientación a objetos de Oracle. En este capítulo veremos diversos conceptos comunes tanto a los SGBDOO como a los SGBDOR.
Estructura del capítulo En la Sección 25.1 se examinan los requisitos para una serie de tipos avanzados de aplicaciones de bases de datos que están siendo cada vez más comunes, y en la Sección 25.2 se analiza por qué los SGBDR tradicionales no están bien adaptados para soportar estas nuevas aplicaciones. En la Sección 25.3 se proporciona la introducción a los principales conceptos de orientación a objetos y en la Sección 25.4 se examinan los problemas asociados con el almacenamiento de objetos en una base de datos relacional. En la Sección 25.5 se proporciona una breve historia de los sistemas de gestión de bases de datos desde su aparición hasta la tercera generación, formada por los SGBD orientados a objetos y objeto-relacionales. En la Sección 25.6 se examina brevemente cómo puede ampliarse la metodología de diseño conceptual lógico de bases de datos presentada en los Capítulos 15 y 16 para gestionar el diseño de bases de datos orientadas a objetos. Los ejemplos de este capítulo están, de nuevo, extraídos del caso de estudio de DreamHome documentado en la Sección 10.4 y en el Apéndice A.
25.1 Aplicaciones avanzadas de bases de datos La industria informática ha visto cambios muy significativos en esta última década. En los sistemas de bases de datos, hemos podido asistir a la universal aceptación de los SGBDR para aplicaciones tradicionales de carácter empresarial, como el procesamiento de pedidos, el control de almacén, aplicaciones bancarias y reserva de billetes de líneas aéreas. Sin embargo, los SGBD existentes han demostrado ser inadecuados para aplicaciones cuyas necesidades son completamente distintas de aquellas de las aplicaciones empresariales de bases de datos tradicionales. Estas aplicaciones incluyen: •
diseño asistido por computadora (CAD);
•
fabricación asistida por computadora (CAM);
•
ingeniería del software asistida por computadora (CASE);
•
sistema de gestión de red;
•
sistemas de información de oficina (OIS) y sistemas multimedia;
•
autoedición digital;
•
sistemas de información geográfica (GIS);
•
sitios web interactivos y dinámicos.
Diseño asistido por computadora
(CAD)
Una base de datos CAD (computer-aided design) almacena datos relativos a diseños mecánicos y eléctricos de, por ejemplo, edificios, aeronaves y circuitos integrados. Los diseños de este tipo tienen algunas características comunes: ' •
Los datos de diseño se caracterizan por un gran número de tipos, cada uno con un pequeño número de instancias. Las bases de datos convencionales presentan normalmente características opuestas. Por ejemplo, la base de datos de DreamHome está compuesta de aproximadamente una docena de relaciones, aunque relaciones tales como PropertyForRent, Client y Viewing pueden contener miles de tuplas.
Capítulo 25 Introducción a los SGDB orientados a objetos
733
•
Los diseños pueden ser muy grandes, quizás compuestos de millones de componentes, a menudo con muchos diseños de subsistemas interdependientes.
•
El diseño no es estático, sino que evoluciona a lo largo del tiempo. Cuando se produce un cambio de diseño, sus implicaciones deben propagarse a través de todas las representaciones del diseño. La naturaleza dinámica del diseño puede implicar que algunas acciones no se hayan previsto desde el principio.
•
Las actualizaciones tienen un largo alcance, debido a las relaciones topológicas o funcionales, a las tolerancias, etc. Resulta bastante común que un cambio afecte a un gran número de objetos de diseño.
•
A menudo, se consideran muchas alternativas de diseño para cada componente y es preciso mantener la versión correcta de cada pieza. Esto implica que hace falta algún tipo de control de versiones y de mecanismo de gestión de configuración.
•
Puede haber cientos de personas implicadas en el diseño y esas personas pueden tener que trabajar en paralelo sobre múltiples versiones de un diseño de gran tamaño. Aún así, el producto final debe ser coherente y estar coordinado. Esto se denomina en ocasiones ingeniería cooperativa.
Fabricación asistida por computadora
(CAM)
Una base de datos CAM (computer-aided manufacturing) almacena datos similares a un sistema CAD, además de datos relativos a la producción de elementos discretos (como por ejemplo coches en una línea de montaje) y a la producción de carácter continuo (por ejemplo una síntesis química). Por ejemplo, en las industrias químicas hay aplicaciones que monitorizan la información acerca del estado del sistema, como las temperaturas de las vasijas de reacción, las tasas de flujo y los datos de rendimiento. También hay aplicaciones que controlan diversos procesos físicos, como la apertura de válvulas, la aplicación de más calor a las vasijas de reacción o el incremento del flujo en los sistemas de refrigeración. Estas aplicaciones están a menudo organizadas en una jerarquía, existiendo una aplicación de nivel superior que monitoriza toda la fábrica y una serie de aplicaciones de niveles inferiores que monitorizan procesos individuales de fabricación. Estas aplicaciones deben responder en tiempo real y son capaces de ajustar los procesos para mantener un rendimiento óptimo, con unas tolerancias mínimas. Dichas aplicaciones utilizan una combinación de algoritmos estándar y reglas personalizadas para responder a diferentes condiciones. Los operadores pueden modificar estas reglas ocasionalmente para optimizar el rendimiento basándose en datos históricos complejos que el sistema debe mantener. En este ejemplo, el sistema tiene que mantener grandes volúmenes de datos que son jerárquicos por naturaleza y mantener también diversas relaciones complejas entre los datos. También debe permitir navegar rápidamente por los datos para revisados y poder responder a los cambios.
Ingeniería del software asistida por computadora
(CASE)
Una base de datos CASE (computer-aided software engineering) almacena datos relativos a las etapas del ciclo de desarrollo del software: planificación, recopilación y análisis de requisitos, diseño, implementación, pruebas, mantenimiento y documentación. Al igual que sucede con el CAD, los diseños pueden ser extremadamente grandes y la ingeniería cooperativa es la norma. Por ejemplo, las herramientas de gestión de configuración software permiten compartir de forma concurrente el diseño del proyecto, el código y la documentación. También controlan las dependencias entre dichos componentes y ayudan a la gestión de cambios. Las herramientas de gestión de proyectos facilitan la coordinación de diversas actividades de gestión de proyectos, como la planificación de tareas interdependientes potencialmente muy complejas, la estimación de costes y la monitorización del progreso.
Sistemas de gestión de red Los sistemas de gestión de red coordinan la provisión de servicios de comunicaciones en una red informática. Estos sistemas realizan sistemas tales como la gestión de las rutas de red, la gestión de problemas y la planificación de red. Al igual que con el ejemplo de la industria química que hemos presentado anteriormente, estos sistemas también gestionan datos complejos y requieren un funcionamiento en tiempo real y una opera-
734
Sistemas de bases de datos
ción continua. Por ejemplo, una llamada telefónica puede implicar que se utilice una cadena de dispositivos de conmutación de red para encaminar los mensajes desde el emisor al receptor, como por ejemplo: Nodo
<=>
Enlace
<=>
Nodo
<=>
Enlace
<=>
Nodo
<=>
Enlace
<=>
Nodo
donde cada Nodo representa un puerto en un dispositivo de red y cada Enlace representa un fragmento de ancho de banda reservado para dicha conexión. Sin embargo, un nodo puede participar en muchas conexiones diferentes y cualquier base de datos que se cree tendrá que gestionar un grafo complejo de relaciones. Para encaminar las conexiones, diagnosticar los problemas y equilibrar las cargas, los sistemas de gestión de red tienen que ser capaces de desplazarse a través de este grafo complejo en tiempo real.
Sistemas de información
de oficina (OIS) y sistemas multimedia
Una base de datos GIS (office information systems) almacena datos relativos al control informatizado de la información en una empresa, incluyendo el correo electrónico, los documentos, las facturas, etc. Para proporcionar un mejor soporte para esta tarea, necesitamos gestionar un rango más amplio de tipos de datos, y no sólo nombres, direcciones, fechas y dinero. Los sistemas modernos gestionan hoy en día texto libre, fotografias, diagramas y secuencias de audio y de vídeo. Por ejemplo, un documento multimedia puede contener texto, fotografias, hojas de cálculo y comentarios de voz. Los documentos pueden tener una estructura específica, quizá descrita mediante un lenguaje de composición tal como SGML (Standardized Generalized Markup Language, lenguaje estándar generalizado de composición), HTML (HyperText Markup Language, lenguaje de composición de hipertexto), o XML (eXtended Markup Language, lenguaje de composición ampliado), como comentaremos en el Capítulo 30. Los documentos pueden ser compartidos entre muchos usuarios que utilicen sistemas tales como el correo electrónico y los foros basados en tecnología Internet.t De nuevo, dichas aplicaciones necesitan almacenar datos que tienen una estructura mucho más rica que la de unas tuplas consistentes en números y en cadenas de texto. También existe una creciente necesidad de capturar notas manuscritas utilizando dispositivos electrónicos. Aunque muchas notas pueden transcribirse en texto ASCII utilizando técnicas de análisis de la estructura manual, la mayor parte de esos datos no pueden transformarse. Además de palabras, los datos manuscritos incluyen dibujos, diagramas, etc. En el caso de estudio de DreamHome, podemos encontrar los siguientes requisitos para la gestión de datos multimedia: •
Datos de imagen. Un cliente puede consultar una base de datos con imágenes de los inmuebles en alquiler. Algunas consultas pueden utilizar simplemente una descripción textual para identificar imágenes de inmuebles de interés. En otros casos, puede resultar útil para el cliente consultar utilizando imágenes gráficas de las características que pueden encontrarse en los inmuebles de interés (como por ejemplo una piscina o ventajas en la buhardilla).
•
Datos de vídeo. Un cliente puede consultar una base de datos de secuencias de vídeo de los inmuebles en alquiler. De nuevo, algunas consultas pueden simplemente utilizar una descripción textual para identificar las imágenes de vídeo de los inmuebles deseados. En otros casos, puede resultar útil que el cliente efectúe la consulta utilizando características del vídeo de los inmuebles deseados (como por ejemplo vistas del mar o de las colinas circundantes).
•
Datos de audio. Un cliente puede consultar una base de datos de audio que describa las características de los inmuebles en alquiler. De nuevo, algunas consultas pueden utilizar simplemente una descripción textual para identificar el inmueble deseado. En otros casos, puede resultar útil que el cliente utilice características de audio relativas a esos inmuebles (como por ejemplo el nivel de ruido derivado del tráfico en las proximidades).
t Una crítica bastante seria de los sistemas
de bases de datos, como se han ocupado de resaltar diversos observadores, es que la mayor 'base de datos' del mundo, la World Wide Web, se desarrolló inicialmente sin hacer a penas uso de la tecnología de base de datos. Hablaremos de la integración de la World Wide Web y de los SGBD en el Capítulo 29.
Capítulo 25 Introducción a los SGDB orientados a objetos •
735
Datos manuscritos. Un empleado puede tomar una serie de notas mientras que realiza inspecciones de los inmuebles en alquiler. En una fecha posterior, puede querer consultar dichos datos para ver todas las notas realizadas acerca de un apartamento determinado.
Autoedición
digital
La industria editorial va a sufrir profundos cambios en sus prácticas empresariales a lo largo de la próxima década. Ya es posible almacenar libros, revistas, artículos y periódicos electrónicamente y distribuirlos a través de redes de alta velocidad a los consumidores. Al igual que sucede con los sistemas de información de oficina, la edición digital está ampliándose para gestionar documentos multimedia compuestos de texto, audio, imágenes, datos de vídeo y animaciones. En algunos casos, la cantidad de información disponible para poner en línea es enorme, del orden de los petabytes (1015 bytes), lo que convertiría a estas bases de datos en las mayores que un SGBD ha tenido nunca que gestionar.
Sistemas de información
geográfica
(GIS)
Una base de datos GIS (geographic information systems) almacena diversos tipos de información espacial y temporal, como por ejemplo la utilizada en la gestión catastral y en la exploración submarina. Buena parte de los datos de estos sistemas están derivados de las fotografías vía satélite y la cantidad de información tiende a ser muy grande. Las búsquedas pueden implicar la identificación de características basándose, por ejemplo, en la forma, el color o la textura, utilizando técnicas avanzadas de reconocimiento de patrones. Por ejemplo, EOS (Earth Observing System) es una colección de satélites lanzados por la NASA en la década de 1990 para recopilar información científica relativa a las tendencias a largo plazo que pueden observarse en la atmósfera terrestre, en los océanos y en la superficie de la Tierra. Las previsiones son que estos satélites devuelvan 0,3 petabytes de información por año. Estos datos serán integrados con otras fuentes de datos y se almacenarán en EOSDIS (EOS Data and Information System). EOSDIS permitirá satisfacer las necesidades de información tanto de los científicos como de los no científicos. Por ejemplo, los niños en edad escolar podrán acceder a EOSDIS para ver una simulación de los patrones climáticos. El inmenso tamaño de esta base de datos y la necesidad de soportar miles de usuarios con solicitudes de enormes volúmenes de información planteará numerosos desafíos a los SGBD.
Sitios web interactivos
y dinámicos
Considere un sitio web que tenga un catálogo en línea para la venta de prendas de vestir. El sitio web mantiene un conjunto de preferencias para los visitantes anteriores del sitio y permite al visitante: •
ojear una serie de imágenes en miniatura de los elementos del catálogo y seleccionar una de ellas para obtener una imagen a tamaño completo junto con detalles adicionales;
•
buscar elementos que se correspondan con una serie de criterios definidos por el usuario;
•
obtener una visualización en 3D de cualquier prenda de ropa basándose en una especificación personalizada (por ejemplo, color, tamaño, tela);
•
modificar dicha visualización para tener en cuenta el movimiento, la iluminación, diversos escenarios, etc.;
•
seleccionar accesorios que complementen a las prendas de vestir, a partir de una serie de elementos presentados en una barra de herramientas lateral;
•
seleccionar la reproducción de un comentario de voz que proporcione detalles adicionales sobre el elemento;
•
ver un total actualizado de la factura, con los descuentos apropiados;
•
concluir la compra mediante una transacción en línea segura.
Los requisitos de este tipo de aplicación no son muy diferentes de algunas de las otras aplicaciones avanzadas que ya hemos visto: existe la necesidad de gestionar contenido multimedia (texto, audio, imágenes, datos de vídeo y animaciones) y de modificar interactivamente la visualización basándose en las preferencias
736
Sistemas de bases de datos
y selecciones del usuario. Además de gestionar datos complejos, el sitio web tiene la complejidad añadida de tener que proporcionar visualizaciones 3D. Algunos argumentan que en dicha situación la base de datos no está simplemente presentando información al visitante, sino que está activamente implicada en la venta, proporcionando dinámicamente una información personalizad a y una cierta atmósfera de compra al visitante (King, 1997). Como se explica en los Capítulo 29 y 30, la Web proporciona ahora un paradigma relativamente nuevo para la gestión de datos, y lenguajes tales como XML resultan muy prometedores, particularmente para el mercado del comercio electrónico. Forrester Research Group predice que las transacciones interempresariales alcanzarán los 2,1 billones de dólares en Europa y los 7 billones de dólares en los Estados Unidos en 2006. En conjunto, se espera que el comercio electrónico represente 12,8 billones de dólares para los ingresos corporativos en todo el mundo en 2006, lo que representa un 18% de las ventas en la economía global. A medida que se incremente el uso de Internet y que la tecnología se vuelva más sofisticada, podremos ver a los sitios web y a las transacciones interempresariales gestionar datos mucho más complejos e interrelacionados. Otras aplicaciones avanzadas de bases de datos son: •
Aplicaciones científicas y médicas, que pueden almacenar datos complejos que representan sistemas tales como modelos moleculares para compuestos químicos sintéticos y material genético.
•
Sistemas expertos, que pueden almacenar bases de datos de conocimientos y de reglas para aplicaciones de inteligencia artificial (lA).
•
Otras aplicaciones con objetos complejos e interrelacionados
y datos procedimentales.
25.2 Debilidades de los SGBDR En el Capítulo 3 hemos visto cómo el modelo relacional tiene una fuerte base teórica, basada en la lógica de predicados de primer orden. Esta teoría fue la base para el desarrollo de SQL, un lenguaje declarativo que se ha llegado a convertir en el lenguaje estándar para la definición y manipulación de bases de datos relacionales. Otras fortalezas del modelo relacional son su simplicidad, que resulta adecuado para el procesamiento de transacciones en línea (OLTP) y su soporte de la independencia de los datos. Sin embargo, el modelo de datos relacional, y los SGBD relacionales en particular, no carecen de desventajas. La Tabla 25.1 enumera algunas de las debilidades más significativas que a menudo suelen citar los componentes de la técnica orientada a objetos. Vamos a hablar de estas debilidades en esta sección y dejaremos que sean los lectores los que juzguen hasta qué punto son aplicables dichas debilidades.
Pobre representación
de las entidades del 'mundo real'
El proceso de normalización conduce generalmente a la creación de relaciones que no se corresponden con entidades del 'mundo real'. La fragmentación de una entidad del 'mundo real' en muchas relaciones, con una Tabla 25.1.
Resumen de debilidades
de los SGBD relacionales.
Debilidades
Pobre representación de las entidades del 'mundo real' Sobrecarga semántica Soporte inadecuado para las restricciones de integridad y empresariales Estructura de datos homogénea Operaciones limitadas Dificultades para gestionar las consultas recursivas Desadaptación de impedancias Otros problemas de los SGBDR asociados con la concurrencia, los cambios en los esquemas y el inadecuado acceso navegacional
Capítulo 25 Introducción a los SGDB orientados a objetos
737
representación física que refleja esta estructura, es ineficiente y conduce a que sea necesario realizar muchas combinaciones durante el procesamiento de las consultas. Como ya hemos visto en el Capítulo 21, las combinaciones están entre las operaciones más costosas de realizar.
Sobrecarga semántica El modelo relacional tiene una única estructura para representar los datos y las relaciones entre los datos, la estructura de relación o tabla. Por ejemplo, para representar una relación muchos a muchos (*:*) entre dos entidades A y B, creamos tres tablas, una para representar cada una de las entidades A y B, Y otra para representar la relación. No hay ningún mecanismo para distinguir entre entidades y relaciones, o para distinguir entre diferentes tipos de relaciones que puedan existir entre las entidades. Por ejemplo, una relación 1:* puede ser Has, Owns, Manages, etc. Si pudieran realizarse tales distinciones, podría ser posible incluir los aspectos semánticos dentro de las operaciones. Por ello se suele decir que el modelo relacional está semánticamente sobrecargado. Ha habido muchos intentos de resolver este problema utilizando modelos de datos semánticos, es decir, modelos que representan en mayor medida el significado de los datos. El lector interesado puede consultar los artículos de Hull y King (1987) y Peckham y Maryanski (1988). Sin embargo, el modelo relacional no carece completamente de características semánticas. Por ejemplo, dispone de dominios y claves (véase la Sección 3.2) y de dependencias funcionales, multivaluadas y de combinación (véanse los Capítulos 13 y 14).
Soporte inadecuado para las restricciones
de integridad y empresariales
El término integridad hace referencia a la validez y coherencia de los datos almacenados. La integridad suele expresarse en términos de restricciones, que son reglas de coherencia que no se permite que la base de datos viole. En la Sección 3.3 hemos presentado los conceptos de integridad de identidades e integridad referencial, y en la Sección 3.2.1 hemos introducido los dominios, que también son un tipo de restricción. Desafortunadamente, muchos sistemas comerciales no soportan completamente estas restricciones y es necesario incluir1as dentro de las aplicaciones. Esto, por supuesto, resulta peligroso y puede conducir a una duplicación de esfuerzos o, todavíao'peor, a la aparición de incoherencias. Además, no hay soporte para las restricciones empresariales dentro del modelo relacional, lo que de nuevo significa que dichas restricciones tienen que incluirse en el SGBD o en la aplicación. Como hemos visto en los Capítulos 5 y 6, el estándar SQL ayuda a resolver en parte esta supuesta deficiencia permitiendo especificar algunos tipos de restricciones como parte del lenguaje DDL (Data Definition Language).
Estructura de datos homogénea El modelo relacional asume una homogeneidad tanto horizontal como vertical. La homogeneidad horizontal significa que cada tupla de una relación debe estar compuesta por los mismos atributos. La homogeneidad vertical significa que los valores de una columna concreta de una relación deben provenir todos ellos del mismo dominio. Además, la intersección de una fila y de una columna debe ser un valor atómico. Esta estructura fija es demasiado restrictiva para muchos objetos del 'mundo real', que tienen una estructura compleja, y conduce a combinaciones poco naturales, que son muy ineficientes, como ya hemos mencionado. En defensa del modelo de datos relacional podría también argtiirse que su estructura simétrica es una de las fortalezas del modelo. Entre los ejemplos clásicos de datos complejos y relaciones interrelacionadas estaría el despiece con el que se representaría algún tipo de objeto, como por ejemplo una aeronave; dicho despiece está compuesto de piezas y piezas compuestas, que a su vez están formadas por otras piezas y por otras piezas compuestas, etc. Esta debilidad ha conducido a que se realicen numerosas investigaciones sobre sistemas de bases de datos para objetos complejos o sistemas que no están en primera forma normal (NF2), investigaciones reflejadas, por ejemplo, en los artículos de Jaeschke y Schek (1982) y Bancilhon y Khoshafian (1989). En este último artículo, los objetos se definen recursivamente de la siguiente forma: (1) Cada valor atómico (como, por ejemplo, un entero, un número en coma flotante o una cadena) es un objeto.
738
Sistemas de bases de datos
(2) Si
al' a2,
a2:02, ...
(3) Si
.••
,
an
, an:on]
01, O2, ...
, 0n
son nombres de atributos diferenciados y es un objeto tupla.
0\, O2,
son objetos, entonces S =
es un objeto conjunto.
{O\,
O2, ...
, on}
.•.
,
0n
son objetos, entonces
[al :0\,
En este modelo, tendríamos que los siguientes serían objetos válidos: Objetos atómicos Conjunto Tupla Tupla jerárquica Conjunto de tuplas Relación anidada
B003, John, Glasgow {SG37, SG14, SGS} [branchNo: B003, street: 163 Main St, city: Glasgow] [branchNo: B003, street: 163 Main St, city: Glasgow, staff: {SG37, SG14, SGS}] {[branchNo: B003, street: 163 Main St, city: Glasgow], [branchNo: BOOS, street: 22 Deer Rd, city: London]} {[branchNo: B003, street: 163 Main St, city: Glasgow, staff: {SG37, SGI4, SGS}], [branchNo: BOOS, street: 22 DeerRd, London, staff: {SL21, SL41}]}
city:
Muchos SGBDR ahora permiten almacenar Objetos binarios de gran tamaño (BLOB, Binary Large Object). Un BLOB es un valor de datos que contiene información binaria que contiene una imagen, una secuencia de vídeo o de audio digitalizada, un procedimiento o algún tipo de objeto de gran tamaño no estructurado. El SGBD no tiene ningún conocimiento en lo que respecta al contenido del BLOB o a su estructura interna. Esto impide al SGBD realizar consultas y operaciones sobre tipos de datos que son inherentemente ricos y estructurados. Normalmente, la base de datos no gestiona esta información directamente, sino que simplemente contiene una referencia a un archivo. La utilización de objetos BLOB no es una solución elegante y almacenar esta información en archivos externos hace que se deniegue a esa información muchas de las protecciones que el SGBD proporciona de forma natural. Además, y más importante, los objetos BLOB no pueden contener otros objetos BLOB, así que no pueden adoptar la forma de objetos compuestos. Asimismo, los objetos BLOB ignoran generalmente los aspectos comportamentales de los objetos. Por ejemplo, podemos almacenar una imagen como un BLOB en algún SGBD relacional; sin embargo, la imagen únicamente puede almacenarse y visualizarse. No resulta posible manipular la estructura interna de la imagen ni es posible visualizar o manipular partes de la misma. En la Figura 18.12 se proporciona un ejemplo de la utilización de objetos BLOB.
Operaciones limitadas El modelo relacional sólo tiene un conjunto fijo de operaciones, como por ejemplo operaciones de conjuntos y orientadas a tuplas, las cuales se detallan en la especificación del lenguaje SQL. Sin embargo, SQL no permite especificar nuevas operaciones. De nuevo, esto es demasiado restrictivo para modelar el comportamiento de muchos objetos del 'mundo real'. Por ejemplo, una aplicación GIS utiliza normalmente puntos, líneas, grupos de líneas y polígonos, y necesita operaciones que permitan determinar cosas como la distancia, la intersección o el hecho de que un objeto esté contenido en otro.
Dificultades
para gestionar las consultas recursivas
La atomicidad de los datos implica que no se permite que existan grupos repetitivo s en el modelo relacional. Como resultado, resulta extremadamente difícil gestionar consultas recursivas, es decir, consultas sobre relaciones que una tabla tenga consigo misma (directa o indirectamente). Considere la tabla simplificada Staff que se muestra en la Figura 2S.1(a), que almacena los números de empleados y el número de empleado del correspondiente jefe. ¿Cómo podemos encontrar todos los jefes que supervisan, directa o indirectamente, al número de empleado SOOS?Para encontrar los primeros dos niveles de la jerarquía, utilizaríamos: SELECT managerStaffNo FROM Staff WHERE staffNo = 'SOOS' UNION
Capítulo 25 Introducción a los SGDB orientados a objetos
739
SELECT manager8taffNo FROM 8taff WHERE staffNo =
(SELECT manager8taffNo FROM 8taff WHERE staffNo = '8005'); Podemos ampliar fácilmente esta técnica para hallar la respuesta completa a esta consulta. Para este ejemplo concreto, esta técnica funciona porque sabemos cuántos niveles de jerarquía hay que procesar. Siñ embargo, si quisiéramos realizar una consulta de carácter más general, como por ejemplo 'para cada empleado, hallar todos los jefes que supervisan directa o indirectamente a esa persona', esta técnica sería imposible de implementar utilizando SQL interactivo. Para resolver este problema, podemos incrustar SQL en un lenguaje de programación de alto nivel, que proporciona estructuras para facilitar la iteración (véase el Apéndice E). Adicionalmente, muchos SGBDR proporcionan una herramienta de escritura de informes con estructuras similares. En cualquiera de los dos casos, es la aplicación, más que las capacidades inherentes del sistema, lo que proporciona la funcionalidad requerida. Una ampliación del álgebra relacional que ha sido propuesta para gestionar este tipo de consulta es la operación unaria de cierre transitivo o cierre recursivo (Merrett, 1984): Cierre transitivo
El cierre transitivo de una relación R con atributos (A1, A2) definidos sobre el mismo dominio es la relación R ampliada con todas las tuplas que pueden reducirse por transitividad; es decir, si (a, b) y (b, e) son tuplas de R, la tupla (a, e) también se añade al resultado.
Esta operación no puede realizarse con sólo un número fijo de operaciones del álgebra relacional, sino que requiere efectuar un bucle, además de utilizar las operaciones de combinación, proyección y unión. El resultado de esta operación sobre nuestra tabla 8taff simplificada se muestra en la Figura 25.1 (b).
Desadaptación
de impedancias
En la Sección 5.1 hemos resaltado que SQL-92 carecía de completud computacional. Esto es cierto con la mayoría de los lenguajes de manipulación de datos (DML) de los SGBDR. Para resolver este problema y proporcionar flexibilidad adicional, el estándar SQL proporciona lo que se denomina SQL incrustado para ayudar a desarrollar aplicaciones de bases de datos más complejas (véase el Apéndice E). Sin embargo, esta técnica produce una des adaptación de impedancias porque estamos mezclando diferentes paradigmas de programación: •
SQL es un lenguaje declarativo que gestiona filas de datos, mientras que un lenguaje de alto nivel tal como 'c' es un lenguaje procedimental que sólo puede gestionar una fila de datos cada vez. staffNo 5002 S004 5003 SOOI 5005
staffNo
NULL 5003 5004 5002 5001 managerstaffNo
NULL 5003 5002 SOOI 5001 5004 S003 managerstaffNo
S003 5005 5004 5002 5001 S004 5003 S005
(a)
(b)
Figura 25.1.
(a) Relación Staff simplificada;
(b) cierre transitivo de la relación Staff.
740 •
Sistemas de bases de datos SQL y los lenguajes 3GL utilizan modelos distintos para representar los datos. Por ejemplo, SQL proporciona los tipos de datos predefinidos Date e Interval, que no están disponibles en los lenguajes de programación tradicionales. Por tanto, es necesario que el programa de aplicación efectúe la conversión entre las dos representaciones, lo que resulta ineficiente tanto en términos del esfuerzo de programación como el uso de recursos de procesamiento. Se ha estimado que se invierte hasta un 30% del esfuerzo de programación y del espacio de código en este tipo de conversiones (Atkinson et al., 1983). Además, puesto que estamos utilizando dos sistemas de tipado distintos, no es posible efectuar una comprobación automática de tipos de toda la aplicación.
Algunos argumentan que la solución a estos problemas no es sustituir los lenguajes relacionales por lenguajes orientados a objetos de nivel de fila, sino introducir funcionalidades de nivel de conjuntos en los lenguajes de programación (Date, 2000). Sin embargo, el objetivo de los SGBDOO es proporcionar una integración mucho más perfecta entre el modelo de datos del SGBD y el lenguaje de programación host. Volveremos sobre este tema en el siguiente capítulo.
Otros problemas de los SGBDR •
Las transacciones en las aplicaciones de procesamiento empresarial son generalmente de corta duración y las primitivas y protocolos de control de concurrencia, como el bloqueo en dos fases, no resultan particularmente adecuados para las transacciones de larga duración, que suelen ser mucho más comunes para los objetos de diseño complejos (véase la Sección 20.4).
•
Los cambios en los esquemas son difíciles. Es necesario que intervengan los administradores de bases de datos para cambiar las estructuras de la base de datos y, normalmente, los programas que acceden a estas estructuras deben ser modificados para ajustarse a la nueva definición. Estos son procesos lentos y pesados incluso con las tecnologías actuales. Como resultado, la mayoría de las organizaciones se encuentran prisioneras de sus propias estructuras de base de datos. Aunque quieran cambiar la forma en que actúan empresarialmente con el fin de adaptarse a nuevos requisitos, y aunque sean capaces de hacerlo, no pueden llevar a cabo estos cambios porque no pueden permitirse el tiempo y los costes requeridos para modificar sus sistemas de información (Taylor, 1992). Para satisfacer los requisitos de una mayor flexibilidad, necesitamos un sistema que permita una evolución natural de los esquemas.
•
Los SGBDR fueron diseñados para utilfzar un acceso asociativo basado en el contenido (es decir, instrucciones declarativas con selecciones basadas en uno o más predicados) y no son demasiado adecuados para el acceso navegacional (es decir, el acceso basado en el movimiento entre registros individuales). El acceso navegacional es importante para muchas de las aplicaciones complejas de las que hemos hablado en la sección anterior.
De estos problemas, los dos primeros son aplicables a muchos SGBD, no sólo a los sistemas relacionales. De hecho, no hay ningún problema subyacente al modelo relacional que impida que dichos mecanismos se implementen. La última versión del estándar SQL, SQL:2003, trata de resolver algunas de las deficiencias anteriores introduciendo muchas nuevas características, como la posibilidad de definir nuevos tipos de datos y operaciones como parte del lenguaje de definición de datos, y mediante la adición de nuevas estructuras para hacer que el lenguaje sea computacionalmente completo. Hablaremos de SQL:2003 en detalle en la Sección 28.4.
25.3 Conceptos de orientación a objetos En esta sección vamos a hablar de los conceptos principales de la orientación a objetos. Comenzaremos con una breve revisión de los conceptos subyacentes de abstracción, encapsulación y ocultación de la información.
25.3.1
Abstracción, encapsulación de la información
y ocultación
La abstracción es el proceso de identificar los aspectos esenciales de una entidad e ignorar las propiedades no importantes. En la ingeniería del software, esto significa que nos concentramos en lo que un objeto es y en
Capítulo 25 Introducción a los SGDB orientados a objetos
741
lo que hace antes de decidir cómo debe implementarse. De esta forma, diferimos los detalles de implementación lo más posible, evitando así asumir compromisos que puedan resultar demasiado restrictivos en una etapa posterior. Hay dos aspectos fundamentales dentro de la abstracción: la encapsulación y la ocultación de información. El concepto de encapsulación significa que un objeto contiene tanto la estructura de los datos como el conjunto de operaciones que pueden usarse para manipular el objeto. El concepto de ocultación de la información significa que separamos los aspectos externos de un objeto de sus detalles internos, que quedan ocultos a ojos del mundo exterior. De esta forma, podemos modificar los detalles internos de un objeto sin afectar a las aplicaciones que lo utilizan, siempre y cuando los detalles externos sigan siendo iguales. Esto impide que una aplicación sea tan interdependiente que un pequeño cambio tenga enormes efectos en cascada. En otras palabras, la ocultación de la información proporciona un cierto tipo de independencia de los datos. Estos conceptos simplifican la construcción y mantenimiento de aplicaciones mediante el mecanismo de modularización. Un objeto es una 'caja negra' que puede construirse y modificarse independientemente del resto del sistema, supuesto que la interfaz externa no se modifique. En algunos sistemas, por ejemplo Smalltalk, las ideas de encapsulación y de ocultación de la información están combinadas. En Smalltalk, la estructura de los objetos siempre está oculta y sólo es visible la interfaz de operación con los objetos. De esta manera, la estructura de los objetos puede modificarse sin afectar a ninguna aplicación que utilice el objeto. Existen dos formas de contemplar la encapsulación: el punto de vista de los lenguajes de programación orientados a objetos (OOPL, object-oriented programming language) y la adaptación a las bases de datos de dicho paradigma. En algunos OOPL, la encapsulación se consigue mediante los denominados tipos abstractos de datos (ADT, Abstract Data Types). Desde este punto de vista, un objeto tiene una interfaz y una implementación. La interfaz proporciona una especificación de las operaciones que pueden realizarse sobre el . objeto; la implementación está compuesta por la estructura de datos del ADT y las funciones que implementa la interfaz. Lo único que resulta visible para otros objetos o usuarios es la interfaz. Desde el punto de vista de base de datos, se consigue una encapsulación apropiada garantizando que los programadores sólo tengan acceso a la interfaz. De este forma, la encapsulación proporciona un cierto tipo de independencia lógica de los datos. Podemos cambiar la implementación interna de un ADT sin cambiar ninguna de las aplicaciones que utilicen dicho ADT (Atkinson et al., 1989).
25.3.2 Objetos y atributos Muchos de los conceptos importantes de orientación a objetos surgen del lenguaje de programación Simula desarrollado en Noruega a mediados de la década de 1960 para soportar la simulación de procesos del 'mundo real' (Dahl y Nygaard, 1966), aunque la programación orientada a objetos no emergió como nuevo paradigma de programación hasta el desarrollo del lenguaje Smalltalk (Goldberg y Robson, 1983). Los módulos de Simula no están basados en procedimientos, como sucede en los lenguajes de programación convencionales, sino en los objetos fisicos que hay que modelar en la simulación. Este enfoque parecía particularmente adecuado, ya que los objetos eran la clave de la simulación: cada objeto debe mantener una cierta información acerca de su estado actual, y además tiene una serie de acciones (comportamiento) que es preciso modelar. Podemos tomar de Simula la definición del concepto de objeto. Objeto
Una entidad unívocamente identificable que contiene tanto los atributos que describen el estado de un objeto del 'mundo real' como las acciones asociadas con él.
En el caso de estudio de DreamHome, las sucursales, los empleados y los inmuebles serían ejemplos de objetos que nos gustaría poder modelar. El concepto de objeto es simple, pero al mismo tiempo muy potente: cada objeto puede definirse y mantenerse independientemente de los demás. Esta definición de un objeto es muy similar a la definición de una entidad proporcionada en la Sección 11.1.1. Sin embargo, un objeto encapsula tanto un estado como un comportamiento, mientras que una entidad sólo modela el estado. El estado actual de un objeto se describe mediante uno o más atributos (variables de instancia). Por ejemplo, la sucursal situada en 163 Main St puede tener unos atributos que se muestran en la Tabla 25.2. Los atributos pueden clasificarse como simples o complejos. Un atributo simple puede ser un tipo primitivo,
742
Sistemas de bases de datos
como un entero, cadena, número real, etc., que adopte valores literales; por ejemplo, branchNo en la Tabla 25.2 es un atributo simple con el valor literal 'B003'. Un atributo complejo puede contener colecciones y/o referencias. Por ejemplo, el atributo SalesStaff es una colección de objetos Staff. Un atributo de referencia representa una relación entre objetos y contiene un valor, o una colección de valores, que son ellos mismos objetos (por ejemplo SalesStaff es, para ser exactos, una colección de referencia a objetos Staff). Un atributo de referencia es conceptualmente similar a una clave externa del modelo de datos relacional o a un puntero de un lenguaje de programación. Un objeto que contenga uno o más atributos complejos se denomina objeto complejo (véase la Sección 25.3.9). Tabla 25.2.
Atributos de objeto para una instancia de sucursal.
Atributo
B003 163 Main St David Ford Valor Susan Brand Ann Beech; Olasgow 011 9QX
street SalesStaff branchNo city postcode Manager
Para hacer referencia a los atributos se utiliza generalmente la notación 'de puntos'. Por ejemplo, para hacer referencia al atributo street de un objeto branch se utilizaría: branch Obj ect. street
25.3.3
Identidad de los objetos
Una parte clave de la definición de un objeto es que debe poseer una identidad unívoca. En un sistema orientado a objetos, a cada objeto se le asigna un identificador de objetos (OID, Object Identifier) en el momento de su creación; dicho identificador: •
es generado por el sistema;
•
es exclusivo de dicho objeto;
•
es invariante, en el sentido de que no puede alterarse durante la vida del objeto. Una vez que se crea el objeto, no se reutilizará este OID para ningún otro objeto, ni siquiera después de borrar el objeto;
•
es independiente de los valores de sus atributos (es decir, de su estado). Dos objetos podrían tener el mismo estado pero seguirían teniendo diferentes identidades;
•
es invisible al usuario (idealmente).
De este modo, la identidad de los objetos garantiza que un objeto pueda ser siempre unívocamente identificado, proporcionando así automáticamente una integridad de las entidades (véase la Sección 3.3.2). De hecho, como la identidad de los objetos garantiza la unicidad en todo el sistema, proporciona una restricción más fuerte que la integridad de entidades empleada en el modelo de datos relacional, que sólo requiere la unicidad dentro de una relación. Además, los objetos pueden contener, o hacer referencia a, otros objetos utilizando las correspondientes identidades. Sin embargo, para cada OID al que se haga referencia dentro del sistema deberá siempre haber presente un objeto que se corresponda con dicha OID, es decir, no debe haber ninguna referencia colgando. Por ejemplo, en el caso de estudio de DreamHome tenemos la relación Branch Has Staff. Si incrustamos cada objetos sucursal en el objeto de empleado correspondiente, nos encontraremos con los problemas de la redundancia de la información y de las anomalías de actualización que hemos analizado en la Sección 13.2. Sin embargo, si lo que hacemos es incrustar la OID del objeto sucursal en el objeto de empleado correspondiente, continuará habiendo una sola instancia de cada objeto sucursal en el sistema y podrá mantenerse la coherencia mucho más fácilmente. De esta forma, los objetos pueden compartirse y las
Capítulo 25 Introducción a los SGDB orientados a objetos
743
OID pueden usarse para mantener la integridad referencial (véase la Sección 3.3.3). Hablaremos de la integridad referencial en los SGBDOO en la Sección 25.6.2. Hay distintas maneras en las que puede implementarse la identidad de los objetos. En un SGBDR, la identidad de los objetos está basada en un valor. Se utiliza la clave principal para garantizar la unicidad de cada tupla de una relación. Las claves principales no proporcionan el tipo de identidad de objeto que se necesita en los sistemas orientados a objeto. En primer lugar, como ya hemos indicado, la clave principal sólo es unívoca dentro de una relación, no en todo el sistema. En segundo lugar, la clave principal se elige generalmente a partir de los atributos de la relación, lo que hace que sea dependiente del estado del objeto. Si una clave potencial está sujeta a cambios, la identidad tendrá que ser simulada mediante identificadores unívocos, como por ejemplo el número de sucursal branchNo, pero como éstos no están bajo control del sistema, no existe ninguna garantía de protección frente a violaciones de la identidad. Además, las claves simuladas tales como BOO1, B002, B003, tienen escaso significado semántico para el usuario. Otras técnicas frecuentemente utilizadas en los lenguajes de programación para soportar la definición de identidades son los nombres variables y los punteros (o direcciones de memoria virtuales), pero estos sistemas también ponen en riesgo la identidad de los objetos. Por ejemplo, en 'C' y C++, una OID es una dirección física dentro del espacio de memoria de un proceso. Para la mayoría de los propósitos para los que se utiliza una base de datos, este espacio de direcciones es demasiado pequeño: las consideraciones de escalabilidad requieren que las OID sean válidas para los distintos volúmenes de almacenamiento y posiblemente para las distintas computadoras que componen un SGBD distribuido. Además, cuando se borra un objeto, la memoria anteriormente ocupada por el mismo debe reutilizarse, por lo que podría crearse un nuevo objeto y asignársele el mismo espacio que ocupaba el objeto borrado. Todas las referencias al antiguo objeto, que habían dejado de ser válidas después del borrado, pasan de nuevo a ser válidas, pero desafortunadamente hacen referencia al objeto equivocado. De forma similar, si se mueve un objeto de una dirección a otra, se invalida su identidad. Lo que necesitamos es un identificador lógico del objeto que sea independiente tanto del estado como de la ubicación. Hablaremos de las OID lógicas y físicas en la Sección 26.2. La utilización de identificadores OID como mecanismo de definición de la identidad de los objetos presenta varias ventajas: •
Son eficientes. Las OID.requieren un espacio mínimo de almacenamiento dentro de un objeto complejo. Normalmente, son más pequeñas que los nombres textuales, que las claves externas o que otras referencias de carácter semántico.
•
Son rápidas. Las OID apuntan a una dirección real o a una ubicación dentro de una tabla que proporciona la dirección del objeto referenciado. Esto significa que pueden localizarse los objetos rápidamente, con independencia de si están almacenados actualmente en memoria local o en disco.
•
No pueden ser modificadas por el usuario. Si las OID son generadas por el sistema y se mantienen invisibles, o al menos de sólo lectura, el sistema puede garantizar más fácilmente la integridad de entidades y la integridad referencia!. Además, esto evita que el usuario tenga que mantener la integridad por sí mismo.
•
Son independientes del contenido. Las OID no dependen de ninguna manera de los datos contenidos en el objeto. Esto permite que se modifique el valor de cada atributo de un objeto, pero que el objeto siga siendo el mismo objeto con la misma OrD.
Observe la potencial ambiguedad que puede surgir debido a esta última propiedad: dos objetos pueden parecer iguales a ojos del usuario (todos los valores de los atributos son iguales) pero tienen diferentes OID, por lo que se tratará de diferentes objetos. Si las OID son invisibles, ¿cómo distingue el usuario entre estos dos objetos? Podemos concluir de esto que seguirán siendo necesarias las claves principales para permitir que los usuarios distingan entre los objetos. Con esta técnica de designación de un objeto, podemos distinguir entre dos conceptos diferentes: identidad de los objetos (algunas veces denominada equivalencia de objetos) e igualdad de los objetos. Dos objetos serán idénticos (equivalentes) si y sólo si son el mismo objeto (lo que se denota mediante '='), es decir, si sus OID son iguales. Dos objetos serán iguales, si sus estados son iguales (lo que se denota mediante '= ='). También podemos distinguir entre igualdad somera e igualdad profunda: los objetos tienen una igualdad somera si sus estados contienen los mismos valores cuando excluimos las
744
Sistemas de bases de datos
referencias a otros objetos; los objetos mostrarán una igualdad profunda, si sus estados contienen los mismos valores y si los objetos relacionados también contienen los mismos valores.
25.3.4
Métodos y mensajes
Un objeto encapsula tantos datos como funciones en un paquete autocontenido. En la tecnología de orientación a objetos, las funciones se suelen denominar métodos. La Figura 25.2 proporciona una representación conceptual de un objeto, con los atributos interiores protegidos del exterior mediante los métodos: los métodos definen el comportamiento del objeto. Pueden utilizarse para cambiar el estado del objeto modificando los valores de sus atributos, o para consultar los valores de una serie de atributos seleccionados. Por ejemplo, podemos tener métodos para añadir un nuevo inmueble en alquiler en una sucursal, para actualizar el salario de un empleado o para imprimir los detalles relativos a un empleado.
Figura 25.2.
Un objeto que muestra tantos atributos como métodos.
Un método está compuesto de un nombre y de un cuerpo que implementa el comportamiento asociado con el nombre del método. En un lenguaje orientado a objetos, el cuerpo está compuesto de un bloque de código que implementa la funcionalidad requerida. Por ejemplo, la Figura 25.3 representa el método para actualizar el salario de un empleado. El nombre del método es updateSalary, con un parámetro de entrada increment, que se añade a la variable de instancia salary para generar el nuevo salario.
method yoid updateSalary(f1oat increment) salary = salary + increment;
Figura 25.3.
Ejemplo de método.
Los mensajes son los medios por los que los objetos se comunican. Un mensaje es simplemente una solicitud que un objeto (el emisor) envía a otro objeto (el receptor) pidiendo ese segundo objeto que ejecute uno de sus métodos. El emisor y el receptor pueden ser el mismo objeto. De nuevo, se utiliza generalmente la notación de puntos para acceder a los métodos. Por ejemplo, para ejecutar el método updateSalary sobre un objeto Staff, staffObject, y pasar al método un valor de incremento igual a 1000, escribiríamos: staffObject.updateSalary(lOOO) En un lenguaje de programación tradicional, un mensaje se escribiría como una llamada a función: updateSalary(staffObject, 1000)
Capítulo 25 Introducción a los SGDB orientados a objetos
745
25.3.5 Clases En Simula, las clases son patrones que sirven para definir conjuntos de objetos similares. Así, los objetos que tienen los mismos atributos y responden a los mismos mensajes pueden agruparse para formar una clase. Los atributos y métodos asociados se definen una única vez para la clase, en lugar de definirlos separadamente para cada objeto. Por ejemplo, todos los objetos sucursal se describirían mediante una única clase Branch. Los objetos en una clase se llaman instancias de la clase. Cada instancia tiene su propio valor o valores para cada atributo, compartiendo los mismos nombres de atributos y los mismos métodos con las demás instancias de la clase, como se ilustra en la Figura 25.4. En la literatura, a menudo se usan como sinónimos los términos 'clase' y 'tipo', aunque algunos autores hacen una distinción entre los dos términos, como a continuación se describe. Un tipo corresponde a la noción de un tipo abstracto de datos (Atkinson y Buneman, 1989). En los lenguajes de programación, las variables se declaran como de un tipo concreto. El compilador puede usar dicho tipo para comprobar que las operaciones realizadas con la variable son compatibles con el tipo, ayudando así a garantizar la corrección del software. Por el contrario, una clase es un patrón para la creación de objetos y proporciona métodos que pueden aplicarse a dichos objetos. Así, las referencias a las clases se realizan en tiempo de ejecución, en lugar de hacerse en tiempo de compilación. En algunos sistemas orientados a objetos, las clases son también objetos y tienen sus propios atributos y métodos, a los que se denomina atributos de clase y métodos de clase, respectivamente. Los atributos de clase describen las características generales de la clase, como los valores totales o promedios; por ejemplo, en la clase Branch podemos tener un atributo de clase que nos dé el número total de sucursales. Los métodos de clase se utilizan para cambiar o consultar el estado de los atributos de clase. También hay métodos de clase especiales para crear nuevas instancias de la clase y destruir aquellas que ya no sean necesarias. En un DEFINICiÓN DE LA CLASE
INSTANCIAS DE LA CLASE
branchNo = 8005 street = 22 Deer Rd city = London postcode = SW1 4EH BRANCH Atributos branchNo street city postcode Métodos print( ) getPostCode( ) numberOfStaff( )
branchNo = 8003 street = 163 Main St city = Glasgow postcode = G 11 90X
Figura 25.4.
Las instancias de una clase comparten los atributos y los métodos.
746
Sistemas de bases de datos
lenguaje orientado a objetos, las nuevas instancias se crean normalmente mediante un método denominado new. Dichos métodos se denominan habitualmente constructores. Los métodos para destruir objetos y reclamar el espacio ocupado por los mismos se suelen denominar destructores. Los mensajes enviados a un método de clase se envían a la clase, en lugar de a una instancia de la misma, lo que implica que la clase es una instancia de nivel superior, denominada metaclase.
25.3.6
Subclases, superclases y herencia
Algunos objetos pueden tener atributos y métodos similares, pero no idénticos. Si hay un alto grado de similaridad, sería útil poder compartir las propiedades comunes (atributos y métodos). La herencia permite definir una clase como un caso especial de otra clase más general. Estos casos especiales se conocen con el nombre de subclases, mientras que los casos más generales se llaman superclases. El proceso de formar una superclase se denomina generalización y el proceso de formar una subclase, especialización. De manera predeterminada, las subclases heredan todas las propiedades de sus superclases, definiendo adicionalmente sus propias propiedades distintivas. Sin embargo, como veremos en breve, las sub clases también pueden redefinir las propiedades heredadas. Todas las instancias de las subclases son también instancias de la superclase. Además, el principio de sustitubilidad dice que podemos utilizar una instancia de la sub clase en todos aquellos casos en que un método o una estructura de programación esté esperando una instancia de la superclase. Los conceptos de superclase, subclase y herencia son similares a los que hemos presentado para el modelo EER (Enhanced Entity-Relationship) en el Capítulo 12, salvo porque en el paradigma de orientación a objetos la herencia cubre tanto el estado como el comportamiento. La relación entre la sub clase y la superclase se denomina en ocasiones relación A KIND OF (AKO, UN TIPO DE), pudiéndose decir por ejemplo que Manager es AKO Staff. La relación entre una instancia y su clase se denomina en ocasiones IS-A; por ejemplo, Susan Brand IS-A Manager. Hay diversas formas de herencia: herencia simple, herencia múltiple, herencia repetida y herencia selectiva. La Figura 25.5 muestra un ejemplo de herencia simple, en el que las subclases Manager y SalesStaff heredan las propiedades de la superclase Staff. El término 'herencia simple' hace referencia al hecho de que las subclases heredan sus atributos de una única superclase. La superclase Staff podría ser a su vez una subclase de otra superclase, Person, formándose así una, jerarquía de clases. La Figura 25.6 muestra un ejemplo de herencia múltiple, en el que la subclase SalesManager hereda propiedades tanto de la superclase Manager como de SalesStaff. La provisión de un mecanismo de herencia múltiple puede ser bastante problemática, ya que se necesita proporcionar una manera de tratar con los conflictos que surgen cuando las superclases contienen los mismos atributos o métodos. No todos los lenguajes orientados a objetos y sistemas SGBD soportan la herencia múltiple en principio. Algunos autores afirman que la herencia múltiple introduce un nivel de complejidad dificil de gestionar de manera segura y coherente.
Person
Figura 25.5. Herencia simple.
Capítulo 25 Introducción a los SGDB orientados a objetos
Figura 25.6.
747
Herencia múltiple.
Otros argumentan que es absolutamente necesaria para modelar el 'mundo real', como en este ejemplo. Los lenguajes que soportan la herencia múltiple, tratan de resolver los conflictos de diversas formas, como, por ejemplo: •
Incluir ambos nombres de atributos/métodos y utilizar el nombre de la superclase como cualificador. Por ejemplo, si bonus es un atributo tanto de Manager como de SalesStaff, la subclase SalesManager podría heredar bonus tanto de ambas superc1ases y cualificar la instancia de bonus en SalesManager como Manager.bonus o SalesStaff.bonus.
•
Linearizar la jerarquía de herencias y utilizar la herencia simple para evitar conflictos. Con esta técnica, la jerarquía de herencia de la Figura 25.6 se interpretaría como: SalesManager
-7
Manager
SalesManager
-7
SalesStaff
-7 SalesStaff
o -7
Manager
Con el ejemplo anterior, SalesManager heredaría una instancia del atributo Manager en el primer caso y de SalesStaff en el segundo caso. •
Requerir al usuario que,Jedefina los atributos o métodos conflictivos
•
Generar un error y prohibir la definición hasta que el conflicto se resuelva.
bonus,
que provendría de
La herencia repetida es un caso especial de herencia múltiple en el que las superclases heredan de otra superclase común. Ampliando el ejemplo anterior, las clases Manager y SalesStaff pueden heredar propiedades de una superclase común Staff, como se ilustra en la Figura 25.7. En este caso, el mecanismo de herencia debe garantizar que la clase SalesManager no herede propiedades de la clase Staff dos veces. Los conflictos pueden resolverse como hemos explicado para el caso de la herencia múltiple.
Figura 25.7.
Herencia repetida.
748
Sistemas de bases de datos
La herencia selectiva permite que una subclase herede un número limitado de propiedades de la superclase. Esta característica puede proporcionar una funcionalidad similar al mecanismo de vistas explicado en la Sección 6.4, al restringir el acceso a ciertos detalles, pero no a otros.
25.3.7 Anulación y sobrecarga Como acabamos de mencionar, las superclases heredan automáticamente las propiedades (atributos y métodos) de sus superclases. Sin embargo, es posible re definir una propiedad dentro de la superclase. En este caso, se utilizará la definición de la propiedad efectuada en la subclase. Este proceso se denomina anulación. Por ejemplo, podemos definir un método en la clase 8taff para incrementar el salario según una cierta comisión: method void giveCommission(float branchProfit) salary = salary + 0.02 * branchProfit; }
{
Sin embargo, puede que queramos realizar un cálculo diferente para determinar las comisiones dentro de la sub clase Manager. Podemos hacer esto redefiniendo, o anulando, el método giveCommission en la subclase Manager: method void giveCommission(float branchProfit) salary = salary + 0.05 * branchProfit; }
{
La capacidad de extraer las propiedades comunes de varias clases y agruparIas en una superclase que pueda ser compartida por las distintas subclases puede eliminar en gran medida la redundancia dentro de los sistemas y se considera como una de las principales ventajas de la orientación a objetos. El proceso de anulación es una característica importante de los mecanismos de herencia, ya que permite gestionar fácilmente los casos especiales, con un impacto mínimo sobre el resto del sistema. La anulación es un caso especial del concepto más general de sobrecarga. La sobrecarga permite utilizar el nombre de un método dentro de una definición de clase o entre varias definiciones de clase. Esto significa que un mismo mensaje puede realizar diferente,S funciones dependiendo del objeto que lo recibe y, en su caso, dependiendo de qué parámetros sean pasados al método. Por ejemplo, muchas clases dispondrán de un método printpara imprimir los detalles relevantes de un objeto, como se muestra en la Figura 25.8. La sobrecarga puede simplificar enormemente las aplicaciones, ya que permite utilizar el mismo nombre para la misma operación, independientemente de la clase en la que aparezca, con lo que se puede utilizar el contexto para determinar qué significado es el apropiado en cada momento. Esto nos evita tener que proporcionar nombres distintivos para los métodos, como por ejemplo printBranchDetailso print8taffDetails,para denominar lo que es en esencia la misma operación funcional.
method void prínt( )
method voíd print( ) printf("Branch
number: %s\n», branchNo);
1
printf("Staff number: %s\n", staffNo);
príntf("Street: %s\n", street);
printf("First name: %s\n», fName);
príntf("City: %sln», city);
printf¡U¡:.ast name: %s\n", lName);
príntf("Posteode: %sIn», posteode);
printf("Posítion:
%s\n", position);
printf("Se:x: %eln", se:x); printf("Date ofbirth: %sln", DOB); príntf\"Salary: %f\n», salary); 1
(a)
(b)
Figura 25.8.
Método de impresión sobrecargado: (a) para el objeto Branch; (b) para el objeto Staff.
Capítulo 25 Introducción a los SGDB orientados a objetos
749
25.3.8 Polimorfismo y enlace dinámico La sobrecarga es un caso especial del concepto más general de polimorfismo, que proviene de la palabra griega que significa 'tener múltiples formas'. Hay tres tipos de polimorfismo: de operación, de inclusión y paramétrico (Cardelli y Wegner, 1985). La sobrecarga, como en el ejemplo anterior es un tipo de polimorfismo de operación (o polimorfismo ud hoc). Un método definido de una superclase y heredado por sus subclases es un ejemplo de polimorfismo de inclusión. Finalmente, el polimorfismo paramétrico o gen~ricidad, como algunas veces se le denomina, utiliza tipos como parámetros en las declaraciones genéricas de tipos o de clases. Por ejemplo, la siguiente definición patrón: templa te T max(x:T,y:T){ if(x> y) else
return x; return y;
define una función genérica max que toma dos parámetros de tipo T y devuelve el máximo de los dos valores. Este fragmento de código no define en la práctica ningún método. En lugar de ello, esta descripción genérica actúa como plantilla para el posterior establecimiento de uno o más métodos diferentes con tipos distintos. Los métodos reales se distanciarían de la siguiente forma: int max(int, int); real max(real, real);
// instanciar la función max para dos tipos enteros // instanciar la función max para dos tipos reales
El proceso de seleccionar el método apropiado basándose en el tipo de objeto se denomina enlace. Si la determinación del tipo de un objeto puede diferirse hasta el momento de la ejecución (en lugar de hacerla en tiempo de compilación), esta selección se denomina enlace dinámico (o tardío). Por ejemplo, considere la jerarquía de clases de Staff,con las subclases Manager y SalesStaff, como se muestra en la Figura 25.5, y suponga que cada clase tiene su propio método print para imprimir los detalles relevantes. Suponga también que tenemos una lista compuesta por un número arbitrario de objetos, por ejemplo n objetos, pertenecientes a esta jerarquía. En un lenguaje de programación convencional, necesitaríamos una instrucción CASE o una instrucción IF anidada para imprimir los detalles correspondientes: FOR i = 1 TO n DO SWITCH (list[i]. type) { CASE staff: printStaffDetails(1ist[i].object); break; CASE manager: printManagerDetails(1ist[i].object); break; CASE salesPerson: printSalesStaffDetails(1ist[i].object); break; } Si se añadiera un nuevo tipo a la lista, tendríamos que ampliar la instrucción CASE para gestionar el nuevo tipo, lo que nos obligaría a recompilar este fragmento de software. Si el lenguaje soporta los mecanismos de enlace dinámico y de sobrecarga, podemos sobrecargar los métodos printutilizando un único nombre y sustituir la instrucción CASE por la línea: list[i].printO Además, con esta técnica podemos añadir cualquier número de nuevos tipos a la lista y, siempre y cuando continuemos sobrecargando el método print, no hará falta volver a compilar este fragmento de código. Por tanto, el concepto de polimorfismo es ortogonal a (es decir, es independiente de) la herencia.
25.3.9
Objetos complejos
Hay muchas situaciones en las que un objetos está compuesto de subobjetos o componentes. Un objeto complejo es un elemento que se ve como un único objeto en el 'mundo real' pero que se combina con otros objetos en un conjunto de relaciones complejas de tipo A-PART-OF (APO, UNA PARTE DE). Los objetos
750
Sistemas de bases de datos
contenidos pueden ser a su vez objetos complejos, lo que da como resultado una jerarquía A-PART-OF. En un sistema orientado a objetos, un objeto contenido puede gestionarse de dos maneras distintas. La primera consiste en que pueda encapsularse e] objeto contenido dentro del objeto complejo y hacer que forme parte del objeto complejo. En este caso, ]a estructura de] objeto contenido es parte de ]a estructura del objeto comp]ejo y sólo puede accederse al objeto contenido utilizando los métodos de] objeto complejo. Una segunda alternativa consiste en considerar que e] objeto contenido tiene una existencia independiente de la del objeto complejo. En este caso, e] objeto no se almacena directamente dentro del objeto padre, sino que únicamente se almacena su OID. Esto se conoce con el nombre de compartición referencial (Khoshafian y Valduriez, 1987). El objeto contenido tiene su propia estructura y sus propios métodos, y puede ser propiedad de varios objetos padre. Estos tipos de objetos complejos se denominan en ocasiones objetos complejos estructurados, ya que el sistema conoce la composición. E] término objeto complejo no estructurado se utiliza para referirse a un objeto complejo cuya estructura sólo puede ser interpretada por el programa de aplicación. En el contexto de las bases de datos, los objetos complejos no estructurado s se denominan en ocasiones objetos binarios de gran tamaño (BLOB, Binary Large Object), de los que hemos hablado en la Sección 25.2.
25.4 Almacenamiento de objetos en una base de datos relacional Una técnica para conseguir la persistencia en un lenguaje de programación orientado a objetos como C++ o lava consiste en utilizar un SGBDR como motor de almacenamiento subyacente. Esto requiere establecer una correspondencia entre las instancias de las clases (es decir, los objetos) y una o más tuplas distribuidas entre una o más relaciones. Esto puede ser problemático, como veremos en esta sección. Para los propósitos de nuestras explicaciones, considere la jerarquía de herencia que se muestra en la Figura 25.9, que tiene una superclase Slaff y tres subclases: Manager, SalesPersonnel y Secrelary. Para gestionar este tipo de jerarquías de clases, tenemos que realizar dos tareas básicas: •
Diseñar las relaciones que habrán de representar la jerarquía de clases .
•
Diseñar el modo en que se accederá a ló'Sobjetos, lo que significa: •
escribir el código para descomponer los objetos en tuplas y almacenar los objetos descompuestos en relaciones;
•
escribir el código para leer las tuplas de las relaciones y reconstruir los objetos.
Vamos a describir ahora estas dos tareas con mayor detalle.
25.4.1 Asignación de las clases a relaciones Hay diversas estrategias para asignar las clases a relaciones, aunque todas ellas tienen como resultado una pérdida de información semántica. E] código necesario para dotar de persistencia a los objetos y para volver a leer los objetos de la base de datos dependerá de la estrategia que se elija. Vamos a considerar tres alternativas: (1) Asignar cada clase o subclase a una relación. (2) Asignar cada sub clase a una relación. (3) Asignar la jerarquía a una única relación.
Asignar cada clase o subclase a una relación Una de las técnicas consiste en asignar cada clase o subclase a una relación. Para la jerarquía presentada en la Figura 25.9, esto nos daría las siguientes cuatro relaciones (en las que se indica mediante un subrayado la clave principal):
Capítulo 25 Introducción a los SGDB orientados a objetos
751
Staff staffNo{PK} name fName IName position sex DOS
salary {Mandatory,Or}
Manager
SalesPersonnel
Secretary
bonus mgrStartDate
salesArea carAllowance
typingSpeed
Figura 25.9.
Jerarquía de herencia de ejemplo para Staff.
Staff (staffNo,fName, IName, position, sex, 008, salary) Manager (staffNo,bonus, mgrStartDate) SalesPersonnel (staffNo,salesArea, carAllowance) Secretary (staffNo,typingSpeed) Vamos a suponer que el tipo de datos subyacente de cada atributo está soportado en el SGBDR, aunque puede que esto no sea así (en cuyo caso necesitaríamos escribir código adicional para gestionar la transformación de un tipo de datos a otro), Desafortunadamente, con e~te esquema relacional hemos perdido información semántica: ya no está claro qué relación representa la superclase y qué relaciones representan las subclases. Tendríamos por tanto que incluir este conocimiento dentro de cada aplicación, lo que conduciría, como ya hemos dicho en otras ocasiones, a una duplicación de código y a la posibilidad de que surgieran incoherencias.
Asignar cada subclase a una relación Una segunda técnica consiste en asignar cada subclase a una relación. Para la jerarquía proporcionada Figura 25.9, esto nos daría las siguientes tres relaciones:
en la
Manager (staffNo,fName, IName, position, sex, 008, salary, bonus, mgrStartDate) SalesPersonnel (staffNo,fName, IName, position, sex, 008, salary, salesArea, carAllowance) Secretary (staffNo,fName, IName, position,sex, 008, salary, typingSpeed) De nuevo, con esta asignación hemos perdido información semántica: deja de estar claro que estas relaciones son subclases de una única clase genérica. En este caso, para generar una lista de todo el personal tendríamos que seleccionar las tuplas de cada relación y luego efectuar la unión de todos los resultados.
Asignar la jerarquía a una única relación Un tercer método consiste en asignar toda la jerarquía de herencia a una única relación, lo que nos daría en este caso: Staff (staffNo,fName, IName, position, sex, 008, salary, bonus, mgrStartDate, salesArea, carAllowance,typingSpeed, typeFlag) El atributo typeFlag es un indicador que nos permite distinguir a qué tipo pertenece cada tupla (por ejemplo, podría contener el valor 1 para una tupla Manager, 2 para una tupla SalesPersonnel y 3 para tupla Secretary).
752
Sistemas de bases de datos
De nuevo, habremos perdido información semántica con este tipo de información. Además, esta asignación producirá un número excesivo de valores nulos para los atributos que no sean de aplicación a cada tupla concreta. Por ejemplo, para una tupla Manager, los atributos salesArea, carAllowancey typing8peed tendrían un valor nulo.
25.4.2 Acceso a los objetos en la base de datos relacional Habiendo diseñado la estructura de la base de datos relacional, necesitamos ahora insertar los objetos en la base de datos y proporcionar un mecanismo para leer, actualizar y borrar los objetos. Por ejemplo, para insertar un objeto en el primer esquema relacional de la sección anterior (es decir, el esquema en el que hemos creado una relación para cada clase), el código sería parecido al siguiente, utilizando SQL programático (véase el Apéndice E): Manager* pManager = new Manager; // crear un nuevo objeto Manager ... código para prepara el objeto ... EXEC SQL INSERT INTO 8taffVALUES (:pManager->staffNo, :pManager->fName, :pManager->IName, :pManager->position, :pManager->sex, :pManager->DOB, :pManager->salary); EXEC SQL INSERT INTO Manager VALUES (:pManager->bonus, :pManager->mgr8tartDate); Por otro lado, si Manager hubiera sido declarado como una clase persistente, la siguiente instrucción (indicativa) haría que el objeto fuera persistente en un SGBDOO: Manager*pManager
=
new Manager;
En la Sección 26.3, examinamos diferentes técnicas para declarar clases persistentes. Si ahora quisiéramos extraer datos de la base de datos relacional, como por ejemplo los detalles relativos a todos los gerentes que tuvieran un bono superior a 1000 euros, el código podría ser similar al siguiente: Manager* pManager = new Manager; // crear un nuevo objeto Manager EXEC SQL WHENEVER NOT FOUND GOTO done; // preparar el tratamiento de errores EXEC SQL DECLARE managerCursor ~ // crear cursor para SELECT CURSORFOR SELECT staffNo,fName, IName,salary, bonus FROM 8taff s, Manager m // Hace falta combinar Staffy Manager WHERE s.staffNo = m.staffNoAND bonus > 1000; EXEC SQL OPEN managerCursor; for ( ; ; ) { EXEC SQL FETCH managerCursor // extraer el siguiente registro del resultado INTO :staffNo,:fName, :IName, :salary, :bonus; pManager->staffNo = :staffNo; // transferir los datos al objeto Manager pManager->fName = :fName; pManager->IName = :lName; pManager->salary = :salary; pManager->bonus = :bonus; strcpy(pManager->position,"Manager"); } // cerrar el cursor antes de terminar EXEC SQL CLOSE managerCursor; Por otro lado, para extraer el mismo conjunto de datos en un SGBDOO, podríamos escribir el código siguiente: os_Set &highBonus = managerExtent->query("Manager*",
"bonus > 1000", dbl);
Capítulo 25 Introducción a los SGDB orientados a objetos
753
Esta instrucción consulta la extensión de la clase Manager (managerExtent) para hallar las instancias requeridas (bonus > 1000) de la base de datos (en este ejemplo, db1). El SGBDOO comercial ObjectStore tiene una plantilla de clase para colecciones os_Set, que ha sido instanciada en este ejemplo para que contenga punteros a los objetos Manager . En la Sección 27.3 se proporcionan detalles adicionales relativos a la persistencia de objetos y a la extracción de objetos mediante ObjectStore. Los ejemplos anteriores tenían por objeto ilustrar la complejidad inherente a la operación de establecer la correspondencia entre un lenguaje orientado a objetos y una base de datos relaciona\. La técnica basada en SGBDOO de la que hablaremos en los siguientes dos capítulos trata de proporcionar una integración más fluida del modelo de datos del lenguaje de programación y del modelo de datos de la base de datos, eliminando así la necesidad de efectuar transformaciones complejas que, como ya hemos indicado antes, podrían representar hasta un 30% del esfuerzo de programación.
25.5 Sistemas de bases de datos de nueva generación A finales de la década de 1960 y principios de la de 1970 había dos líneas principales de trabajo para el desarrollo de sistemas SGBD. La primera estaba basada en el modelo de datos jerárquico, tipificado por IMS (Information Management System) de IBM, en respuesta a los enormes requisitos de almacenamiento de información que tenía el programa espacial Apollo. La segunda línea de trabajo estaba basada en el modelo de datos de red, que trataba de crear un estándar de bases de datos y resolver algunas de las dificultades del modelo jerárquico, como su incapacidad para representar de manera efectiva relaciones complejas. Juntos, estas dos líneas de trabajo representaban la primera generación de sistemas SGBD. Sin embargo, estos dos modelos tenían algunas desventajas fundamentales: •
era necesario escribir programas complejos para resolver hasta las más simples de las consultas, programas que utilizaban un acceso navegacional orientado a registros;
•
había una independencia mínima con respecto a los datos;
•
no había una base teórica ampliamente aceptada.
En 1970, Codd escribió su"artículo pionero sobre el modelo de datos relaciona. Este artículo resultó ser muy oportuno y analizaba las desventajas de las líneas de trabajo anteriores, en particular su falta de independencia con respecto a los datos. A raíz de esto, se implementaron muchos SGBD relacionales experimentales, apareciendo los primeros productos comerciales a finales de la década de 1970 y principios de la de 1980. Hoy en día, hay más de cien SGBD relacionales tanto para entorno s mainframe como para PC, aunque algunos van más allá de la definición del modelo relaciona\. Los SGBD relacionales se denominan en ocasiones SGBD de segunda generación. Sin embargo, como hemos explicado en la Sección 25.2, los SGBDR tienen también sus desventajas, concretamente sus limitadas capacidades de modelado. Se ha realizado un gran esfuerzo de investigación tratando de resolver este problema y en 1976 Chen presentó el modelo Entidad-Relación, que hoy en día es una técnica ampliamente aceptada para el diseño de bases de datos y constituye el fundamento de la metodología presentada en los Capítulos 15 y 16 de este libro (Chen, 1976). En 1979, el propio Codd trató de resolver algunas de las debilidades de su trabajo original con una versión ampliada del modelo relacional denominada RM/T (Codd, 1979) y posteriormente RMN2 (Codd, 1990). Los intentos de proporcionar un modelo de datos que representara el 'mundo real' más fielmente se han clasificado, de manera general, con el nombre de modelado semántico de datos. Algunos de los modelos más famosos son: •
el Modelo Semántico de Datos (Hammer y McLeod, 1981);
•
el Modelo Funcional de Datos (Shipman, 1981), que examinaremos
•
el Modelo Semántico de Asociación (Su, 1983).
en la Sección 26.1.2;
En respuesta a la creciente complejidad de las aplicaciones de bases de datos, han surgido dos 'nuevos' modelos de datos: el modelo de datos orientado a objetos y el modelo de datos objeto-relacional, anteriormente denominado modelo de datos relacional ampliado. Sin embargo, a diferencia de los modelos anterio-
754
Sistemas de bases de datos
Modelos de Datos Objeto-Relaciona les
Figura 25.10.
Historia de los modelos de datos.
res, la composición real de estos modelos no está clara. Esta evolución representa los SGBD de tercera generación, como se ilustra en la Figura 25.10. Existe actualmente un considerable debate entre los que proponen los SGBDOO y los que apoyan el modelo relacional, debate que recuerda al que)la se produjo entre los modelos de red y relacional en la década de 1970. Ambos bandos coinciden en que los SGBDR tradicionales resultan inadecuados para ciertos tipos de aplicaciones. Sin embargo, difieren en cuál es la mejor solución. Los que proponen los SGBDOO afirman que los SGBDR son adecuados para las aplicaciones empresariales más normales, pero carecen de la capacidad para soportar aplicaciones más complejas. Aquellos que se encuadran en el bando relacional afirman que la tecnología relacional es una parte necesaria de cualquier SGBD real y que las aplicaciones complejas pueden manejarse mediante extensiones del modelo relacional. Actualmente, los SGBD relacionales/objeto-relacionales constituyen los sistemas dominantes y los SGBD orientados a objeto tienen su propio nicho particular dentro del mercado. Si los SGBDOO quieren llegar a ser dominantes, deberán cambiar su imagen y pasar de ser sistemas que sólo parecen adecuados para aplicaciones complejas a ser sistemas que también puedan soportar aplicaciones empresariales normales, con las mismas herramientas y la misma facilidad de uso que sus equivalentes relacionales. En particular, deberán soportar un lenguaje de consulta declarativo compatible con SQL. Dedicaremos los Capítulos 26 y 27 al análisis de los SGBDOO y el Capítulo 28 a los SGBDOR.
25.6 Diseño de bases de datos orientadas a objetos En esta sección, vamos a ver cómo adaptar la metodología presentada en los Capítulos 15 y 16 al caso de un SGBDOO. Comenzaremos nuestro análisis con una comparación de la base en la que se asienta nuestra metodología, es decir, el modelo Entidad-Relación ampliado (EER), y los principales conceptos de la orientación a objetos. En la Sección 25.6.2 examinaremos las relaciones que pueden existir entre objetos y cómo puede gestionarse la integridad referencial. Concluiremos esta sección con algunas directrices para la identificación de métodos.
Capítulo 25 Introducción a los SGDB orientados a objetos
755
25.6.1 Comparación del modelado de datos orientado a objetos y del modelado de datos conceptual La metodología de diseño conceptual y lógico de base de datos presentada en los Capítulos 15 y 16, que estaba basada en el modelo Entidad-Relación ampliado (EER), tiene similitudes con el modelado de datos orientado a objetos (OODM, Object-Oriented Data Modeling). La Tabla 25.3 compara el OODM con el modelado de datos conceptual (CDM, Conceptual Data Modeling). La principal diferencia es la encapsulación janto del estado como del comportamiento en un objeto, mientras que CDM sólo captura el estado y no tiene ningún conocimiento del comportamiento. De esta manera, CDM no incluye ningún concepto similar al de mensajes y, consecuentemente, no incluye ninguna medida para proporcionar características de encapsulación. Tabla 25.3.
Comparación de OOOM y COMo
OODM
CDM
Diferencia
Objeto
Entidad
El objeto incluye el comportamiento
Atributo
Atributo
Ninguna
Asociación
Relación
Las asociaciones son iguales, pero la herencia en OODM incluye tanto el estado como el comportamiento
Mensaje
No hay un concepto correspondiente en CDM
Clase
Tipo de entidad/Supertipo
Ninguna
Instancia
Entidad
Ninguna
Encapsulación
No hay un concepto correspondiente en CDM
La similitud entre los dos enfoques hace que la metodología de modelado conceptual y lógico de los datos presentada en los Capítulos 15 y 16 sea una base razonable para desarrollar una metodología para el diseño de bases de datos orientadas a objetos. Aunque esta metodología está dirigida fundamentalmente al diseño de bases de datos relacionales, el modelo puede ponerse en correspondencia de manera relativamente simple con los modelos en red y jerárquico. En el modelo lógico de datos generado se habían eliminado las relaciones de tipo muchos a muchos y las relaciones recursivas (Paso 2.1). Estos cambios no son necesarios para el modelado orientado a objetos y pueden omitirse, ya que fueron introducidos debido a la limitada potencia de modelado de los modelos de datos tradicionales. El uso de la normalización dentro de esta metodología continúa siendo importante y no debe omitirse para el diseño de base de datos orientados a objetos. La normalización se utiliza para mejorar el modelo de modo que satisfaga diversas restricciones que eviten la innecesaria duplicación de los datos. El hecho de que estemos tratando con objetos no implica que la redundancia sea aceptable. En términos de orientación a objetos, la segunda y la tercera formas normales deben interpretarse como: 'Todo atributo de un objeto depende de la identidad del objeto'. El diseño de bases de datos orientadas a objetos requiere que el esquema de la base de datos incluya tanto una descripción de la estructura de datos del objeto y sus restricciones, como del comportamiento del objeto. Hablaremos del modelado del comportamiento en la Sección 25.6.3.
25.6.2
Relaciones e integridad referencial
Las relaciones se representan en un modelo de datos orientado a objetos utilizando atributos de referencia (véase la Sección 25.3.2), que normalmente se implementan mediante identificadores OID. En la metodología presentada en los Capítulos 15 y 16, habíamos descompuesto todas las relaciones no binarias (por ejemplo, relaciones temarias) en relaciones binarias. En esta sección vamos a ver cómo representar relaciones binarias basándose en su cardinalidad: uno a uno (1:1), uno a muchos (1:*) y muchos a muchos (*:*).
~
756
Sistemas de bases de datos
Relaciones 1: 1 Una relación 1:1 entre los objetos A y B se representa añadiendo un atributo de referencia al objeto A y, para mantener la integridad referencial, un atributo de referencia al objeto B. Por ejemplo, en la Figura 25.11 vemos que hay una relación 1: 1 entre Manager y Branch.
Relaciones 1:* Una relación 1:* entre los objetos A y B se representa añadiendo un atributo de referencia al objeto B y un atributo que contenga un conjunto de referencias al objeto A. Por ejemplo, en la Figura 25.12 se representan relaciones 1:*, una de ellas entre Branch y SalesSlaff, y la otra entre SalesSlaff y PropertyForRent. Branch: 0101 branchNo: street: city: postcode: slaft: property: manager:
B003 163 Main SI Glasgow G11 9QX {0104, 0105, {0102, 0103, 0106
Figura 25.11.
.--tName: IName: slaft: L..-- rooms: posilion: salary: property: manager: type:
Manager: 0106 staftNo: SG5 fName: Susan IName: Brand position: Manager sex: F OOB: 3-Jun-40 salary: 24000 branch: 0101
} }
Una relación 1: 1 entre Manager y Branch.
.--....-
rent: ~0106 1+PropertyForRent: PropertyForRent: 1'0103 0102 M 4 3 Ford 1-1--SI rooms: rent: SG14 Oavid 18000 0101 branch: 163 5 Novar Main Or ... 0101 350 0104 450 6Flat Lawrence SI property: branch: 14---" {0104, 0105, }} {0102, 0103, ... Glasgow branch: street: sex: street: propertyNo: PG16 Supervisor {0102, 0103, ... propertyNo:
PG4
staft: ~type:
SalesStaff: 0104
...••.
Figura 25.12.
Relaciones 1:* entre Branch, SalesStaff y PropertyForRent.
Capítulo 25 Introducción a los SGDB orientados a objetos
757
Relaciones *:* Una relación *:* entre los objetos A y B se representa añadiendo a cada objeto un atributo que contenga un conjunto de referencias. Por ejemplo, en la Figura 25.13 se muestra una relación *:* entre Client y PropertyForRen!. Para el diseño de bases de datos relacionales, descompondríamos la relación *: * en dos relaciones 1:* enlazadas mediante una entidad intermedia. También resulta posible representar este modelo en un SGBDOO, como se muestra en la Figura 25.14. Client: 0109 c1ientNo: fName: IName: telNo: prefType: maxRent:
CR56 Alíne Stewart 0141-848-1825 Flat 350
Viewing PropertyForRent: property: viewOate: comment:
0107 28-Apr-04
property: viewOate: comment:
0102 26-May-04
propertyNo: city: type: rooms: rent: staff: branch: viewers:
0107
PG36 2 Manar Rd Flat
3 375 0108 0101 {0109}
Client: 01010 clientNo: fName: IName: telNo: prefType: maxRent:
CR74 Mike ~ Ritchie 01475-392178 House 750
PropertyForRent:
propertyNo: PG4 6 Lawence St city: Fíat type: rooms: 3 rent: 350 staff: 0104 branch: 0101 viewers: {0109,01010}
Viewing property: viewDate: comment:
0102 20-Apr-04 toa remate
Figura 25.13.
0102
Una relación
*:* entre Client y PropertyForRent.
Integridad referencial En la Sección 3.3.3 hemos hablado de la integridad referencial en términos de las claves principales y externas. La integridad referencial requiere que exista todo objeto referenciado. Por ejemplo, considere la relación 1:1 entre Manager y Branch que se muestra en la Figura 25.11. La instancia de Branch, OID 1, hace referencia a una instancia de Manager, OID6. Si el usuario borra esta instancia de Manager sin actualizar la instancia de Branch correspondientemente, se habrá perdido la integridad referencial. Hay varias técncias que pueden utilizarse para gestionar la integridad referencial: •
No permitir que el usuario borre explícitamente objetos. En este caso, el sistema es responsable de efectuar la 'recolección de memoria'; en otras palabras, el sistema borrará automáticamente los objetos cuando ya dejen de ser accesibles por parte del usuario. Esta es la técnica utilizada por GemStone.
758
Sistemas de bases de datos
Client: 0109 clientNo: fName: IName: telNo: prefType: maxRent: viewings:
Viewing: 01021 dient: 0109 property: 0107 viewOate: 28-Apr-04 comment:
CR56 Aline Stewart 0141-848-1825 Flat 350 {01021, 01022}
PropertyForRent:
0107
propertyNo: PG36 2 Manor Rd Flat
3 375 0108 0101 {01021}
Viewing: 01022 client: 0109 property: 0102 viewOate: 26-May-04 comment: PropertyForRent:
Client: 01010
propertyNo: dientNo: fName: IName: telNo: prefType: maxRent: viewings:
CR74 Mike Ritchie 01475-392178 House 750 {01023}
Figura 25.14.
Viewing: 01023
0102
PG4 6 Lawrence St Flat
3 dient: property: viewOate: comment:
01010 0102 20-Apr-04 toa remate
Diseño alternativo de-una relación
350 0104 0101 {01022, 01023}
*:* con una clase intermedia.
•
Permitir al usuario borrar los objetos cuando ya no sean necesarios. En este caso, el sistema puede detectar automáticamente las referencias inválidas y asignar el valor NULL (un puntero nulo) a esas referencias o prohibir el borrado. El SGBDOO Versant utiliza esta técnica para forzar la integridad referencia!.
•
Permitir al usuario modificar y borrar objetos y relaciones cuando ya no sean requeridas. En este caso, el sistema mantienen automáticamente la integridad de los objetos, posiblemente utilizando atributos inversos. Por ejemplo, en la Figura 25.11 tenemos una relación de Branch a Manager y una relación inversa de Manager a Branch. Cuando se borra un objeto Manager, resulta fácil para el sistema utilizar esta relación inversa para ajustar correspondientemente la referencia del objeto Branch. Los SGBDOO Ontos, Objectivity/DB y ObjectStore proporcionan este tipo de integridad, al igual que lo hace el modelo de objetos del ODMG (véase la Sección 27.2).
25.6.3
Diseño comportamental
La técnica EER es insuficiente por sí misma para completar el diseño de una base de datos orientada a objetos. Es necesario complementar dicha técnica con otra que identifique y documente el comportamiento de cada clase de objetos. Esto implica un análisis detallado de los requisitos de procesamiento de la empresa. En una técnica convencional de flujo de datos que utilice diagramas DFD (Data Flow Diagram), por ejemplo, los requisitos de procesamiento del sistema se analizan por separado del modelo de datos. En el análisis orientado a objetos, los requisitos de procesamiento se ponen en correspondencia con un conjunto de métodos que son exclusivos de cada clase. Los métodos que son visibles para el usuario o para otros objetos (métodos públicos) deben distinguirse de los métodos que son puramente internos de una clase (métodos privados). Podemos identificar tres tipos de métodos públicos y privados: •
constructores y destructores;
• •
métodos de acceso; métodos de transformación.
Capítulo 25 Introducción a los SGDB orientados a objetos
Constructores
759
y destructores
Los métodos constructores generan nuevas instancias de una clase y a cada nueva instancia se le proporciona un OID unívoco. Los métodos destructores borran las instancias de las clases que ya no son necesarias. En algunos sistemas, la destrucción es un proceso automático. Cada vez que un objeto deja de estar accesible para otros objetos, se le borra automáticamente. Anteriormente hemos denominado a esta técnica 'recolección de memoria'.
Métodos de acceso Los métodos de acceso devuelven el valor de un atributo o de un conjunto de atributos de una instancia de una clase. El método puede devolver un único valor de atributo, múltiples valores de atributo o una colección de valores. Por ejemplo, podemos tener un método getSalary para una clase SalesStaff que devuelva el salario de un empleado, o podemos tener un método getContactDetails para una clase Person que devuelve la dirección y el número telefónico de una persona. Un método de acceso puede también devolver datos relativos a la clase. Por ejemplo, podemos tener un método getAverageSalary para una clase SalesStaff que calcule el salario promedio de todos los empleados de ventas. Un método de acceso también puede calcular datos derivados de un atributo. Por ejemplo, podemos tener un método getAge para una persona que calcule la edad de una persona a partir de la fecha de nacimiento. Algunos sistemas generan automáticamente un método para acceder a cada atributo. Este es el enfoque adoptado en el estándar SQL:2003, que proporciona un método observador (get) automático para cada atributo de cada nuevo tipo de datos (véase la Sección 28.4).
Métodos de transformación Los métodos de transformación cambian (transforman) el estado de una instancia de una clase. Por ejemplo, podemos tener un método incrementSalary para la clase SalesStaff que incremente el salario de un empleado en una cantidad especificada. Algunos sistemas generan automáticamente métodos para actualizar cada atributo. De nuevo, este es el enfoque adoptado en el estándar SQL:2003, que proporciona un método muladar (put) automático para cada atributo de cada nuevo tipo de datos (véase la Sección 28.4).
Identificación
de méfodos
Existen diversas metodologías para la identificación de métodos, las cuales combinan normalmente las técnicas siguientes: •
identificar las clases y determinar los métodos que pueden resultar útiles para cada una de ellas;
•
descomponer la aplicación de arriba a abajo y determinar los métodos requeridos para proporcionar la funcionalidad necesaria.
Por ejemplo, en el caso de estudio de DreamHome hemos identificado las operaciones que hay que realizar en cada sucursal. Estas operaciones garantizan que la información apropiada esté disponible de forma eficiente y efectiva para gestionar la sucursal y para soportar los servicios proporcionados a los propietarios de inmuebles y a los clientes (véase el Apéndice A). Esta es una técnica de arriba a abajo: entrevistamos a los usuarios relevantes y, a partir de ello, determinamos las operaciones requeridas. Utilizando el conocimiento de estas operaciones requeridas y el modelo EER, con el que se identifican las clases necesarias, podemos comenzar la determinación de los métodos requeridos y ver a qué clase debe pertenecer cada método. Una descripción más completa del proceso de identificación de métodos caería fuera del alcance de este libro. Existen múltiples metodologías para el análisis y el diseño orientados a objetos, y el lector interesado puede consultar las contribuciones de Rumbaugh el al. (1991), Coad y Yourdon (1991), Graham (1993), Blaha y Premerlani (1997) y Jacobson el al. (1999).
25.7 Análisis y diseño orientados a objetos con UML En este libro defendemos el uso de UML (Unified Modeling Language) para el modelado ER y para el diseño conceptual de bases de datos. Como hemos indicado al principio del Capítulo 11, un UML representa una
760
Sistemas de bases de datos
unificación y evolución de diversos métodos de análisis y diseños orientados a objetos que aparecieron a finales de la década de 1980 y principios de las de 1990, particularmente el método Booch de Grady Booch, la técnica de modelado de objetos OMT (Object Modeling Technique) de James Rumbaugh et al. y la ingeniería del software orientada a objetos (OOSE, Object-Oriented Software Engineering) de Ivar Jacobson et al. UML ha sido adoptado como estándar por el OMG (Object Management Group) y ha sido aceptado por la comunidad software como principal notación para el modelado de objetos y de componentes. UML se define comúnmente como 'un lenguaje estándar para la especificación, construcción, visualización y documentación de los componentes de un sistema software'. De forma análoga a la utilización de planos en la industria de la construcción, UML proporciona un lenguaje común para describir modelos software. El lenguaje UML no prescribe ninguna metodología concreta, sino que es flexible y personalizable para adaptarse a cualquier posible técnica y puede utilizarse en conjunción con un amplio rango de procesos de desarrollo y de modelos de ciclo de vida del software. Los objetivos principales en el diseño del lenguaje UML eran: •
Proporcionar a los usuarios un lenguaje de modelado visual expresivo fácil de utilizar para que pudieran desarrollar e intercambiar modelos suficientemente significativos.
•
Proporcionar mecanismos de ampliación y de especialización para extender los conceptos fundamentales. Por ejemplo, UML proporciona los denominados estereotipos, que permiten definir nuevos elementos ampliando y refinando la semántica de los elementos existentes. Un estereotipo se encierra entre dobles corchetes angulares «< ... »).
•
Ser independiente de cualquier lenguaje de programación o proceso de desarrollo concretos.
• •
Proporcionar una base formal para la comprensión del lenguaje de modelado. Promover el crecimiento del mercado de las herramientas orientadas a objetos.
•
Soportar conceptos de desarrollo de mayor nivel, como los de colaboraciones, patrones y componentes.
marcos de trabajo,
• Incorporar las prácticas recomendadas. En esta sección se examinan brevemente algunos de los componentes de UML.
25.7.1
Diagramas UML
UML define una serie de diagramas, los principales de los cuales pueden dividirse en las siguientes dos categorías: • Diagramas estructurales, que describen las relaciones estáticas entre los componentes. Entre éstos se incluyen:
•
•
diagramas de clases,
•
diagramas de objetos,
•
diagramas de componentes,
•
diagramas de implantación.
comportamentales, éstos se incluyen:
Diagral11as
•
diagramas de casos de uso,
•
diagramas de secuencia,
•
diagramas de colaboración,
•
diagramas de estados,
•
diagramas de actividades.
que describen las relaciones dinámicas entre los componentes. Entre
Ya hemos utilizado la notación de diagramas de clases para el modelado ER anteriormente en el libro. En el resto de esta sección, vamos a analizar brevemente los restantes tipos de diagramas y a proporcionar ejemplos de su uso.
Capítulo 25 Introducción a los SGDB orientados a objetos
761
Diagramas de objetos Los diagramas de objetos modelan instancias de las clases y se utilizan para describir el sistema en un instante concreto de tiempo. Al igual que un objeto es una instancia de una clase, podemos considerar los diagramas de objetos como instancias de los diagramas de clases. En el Capítulo 11 hemos denominado a este tipo de diagrama' diagrama de red semántica'. Utilizando esta técnica, podemos validar el diagrama de clases (diagrama ER en nuestro caso) con datos del 'mundo real' y registrar los casos de prueba. Muchos diagramas de objetos se construyen utilizando únicamente entidades y relaciones (objetos y asociaciones en la terminología UML). La Figura 25.15 muestra un ejemplo de diagrama de objetos para la relación Staff Manages PropertyForRent.
Diagramas de componentes Los diagramas de componentes describen la organización y las dependencias entre los componentes software físicos, como el código fuente, el código de ejecución (binario) y los archivos ejecutables. Por ejemplo, un diagrama de componentes puede ilustrar la dependencia entre los archivos fuente y los archivos ejecutables de forma similar a la información contenida en los archivos makefile, que describen las dependencias existentes entre los archivos fuentes y que pueden usarse para compilar y montar una aplicación. Un componente se representa mediante un rectángulo con dos pestañas en el borde izquierdo. Una dependencia se denota mediante una flecha de puntos que va desde un componente hasta el componente del cual depende.
Diagramas de implantación Los diagramas de implantación muestran la configuración del sistema en tiempo de ejecución, indicando los nadas hardware, los componentes que se ejecutan sobre dichos nadas y las conexiones entre nadas. Cada nodo se representa mediante un cubo tridimensional. Los diagramas de componentes y de implantación pueden combinarse, como se ilustra en la Figura 25.16.
Diagramas de casos de uso El lenguaje UML permite y px:pmueve (aunque no obliga a ello y ni siquiera lo requiere) una técnica basada en casos de uso para el modelado de objetos y componentes. Los diagramas de casos de uso modelan la funPG36: PropertyForRent
8G37: 8taff staffNo = 8G37 fName =Ann IName = Beech position = Assistant sex= F DOB = 10-Nov-60 salary = 12000 branchNo = B003
propertyNo = PG36 street = 2 Manor Rd city = Glasgow postcode = G32 4QX type = Flat rooms = 3 rent = 375 ownerNo = C093 staffNo = 8G37 branchNo = B003
PG21: Pro~ForRent propertyNo = PG21 street = 18 Dale Rd city = Glasgow postcode = G12 type = House rooms=5 rent = 600 ownerNo = C087 staffNo = 8G37 branchNo = B003
Figura 25.15. Diagrama de objetos de ejemplo que muestra instancias de la relación Staff Manages PropertyForRent.
762
Sistemas de bases de datos
Máquina cliente
Explorador web
, , ,
, PHP:
I TCPIIP Servidor web
Servidor Apachel~
Figura 25.16.
LAN
.oose
Servidor de base de datos
~
Diagrama combinado de componentes
SGBD
y de implantación.
cionalidad proporcionada por el sistema (casos de uso), los usuarios que interactúan con el sistema (actores) y la asociación entre los usuarios y la funcionalidad. Los casos de uso se emplean durante las fases de recopilación y análisis de requisitos dentro del ciclo de desarrollo del software, para representar los requisitos de alto nivel del sistema. Más específicamente, cada caso de uso especifica una secuencia de acciones, incluyendo las correspondientes variantes, que el sistema puede llevar a cabo y que proporciona un resultado observable que resulta valioso para un actor concreto (Jacobson et al., 1999). Cada caso de uso individual se representa mediante una elipse, los actores mediante una figura de un muñeco y las asociaciones mediante una línea entre el actor y el caso de uso. El papel del actor se indica debajo del icono. Los actores no tienen por qué ser necesariamente humanos: si un sistema se comunica con otra aplicación y espera una cierta entrada o proporciona una cierta salida, dicha aplicación puede también considerarse un actor. Los casos de uso se representan normalmente mediante un verbo seguido de un objeto, como por ejemplo Ver inmueble, Alquilar inmueble. En la Figura 25.17(a) se muestra un diagrama de casos de uso de ejemplo para Client con cuatro casos de uso y la Figura 25.l7(b) muestra un diagrama de casos de uso para 8taff. La notación de casos de uso es simple y resulta, por tanto, un vehículo muy adecuado para la comunicación.
Diagramas de secuencias Un diagrama de secuencia modela las interacciones entre los objetos a lo largo del tiempo, capturando el comportamiento de un caso de uso individual. Muestra los objetos y los mensajes que los objetos intercambian como parte de ese caso de uso. En un diagrama de secuencia, los objetos y los actores se muestran como columnas, con líneas de vida verticales que indican el tiempo de vida del objeto. Una activación/foco de control, que indica cuándo el objeto está realizando una acción, se modela como una caja rectangular dentro de la línea de vida; la propia línea de vida se representa mediante una línea de puntos vertical que sale del objeto. La destrucción de un objeto se indica mediante una X en el punto apropiado de su línea de vida. La Figura 25.18 proporciona un ejemplo de diagrama de secuencia para el caso de uso de Buscar inmuebles que puede haberse definido durante el diseño (puede haberse producido un diagrama de secuencia anterior sin parámetros en los mensajes).
Diagramas de colaboración Un diagrama de colaboración es otro tipo de diagrama de interacción, que en este caso muestra las interacciones entre objetos en forma de series de mensajes secuenciados. Este tipo de diagrama es una mezcla entre un diagrama de objetos y un diagrama de secuencia. A diferencia del diagrama de secuencia, que modela la inter-
Capítulo 25 Introducción a los SGDB orientados a objetos
763
Caso de uso Frontera del sistema
EmPleado~
Alquilar inmueble (a)
Mantener Lease
Ver Lease
(b)
Figura 25.17.
(a) Diagrama de caso de uso con un actor (Client) y cuatro casos de uso; (b) diagrama de casos de uso para Staff.
acción en un formato de filas y columnas, el diagrama de colaboración utiliza una disposición libre de objetos, lo que hace más fácil la visualización de todas las interacciones que afectan a un objeto concreto. Los mensajes se etiquetan con un número cronológico para mantener la información de orden. La Figura 25.19 proporciona un ejemplo de diagrama de colaboración para el caso de uso Buscar inmuebles.
Diagramas de estados Los diagramas de estados muestran cómo pueden cambiar los objetos en respuesta a los sucesos externos. Mientras que otros diagramas comportamentales modelan normalmente la interacción entre múltiples objetos,
764
Sistemas de bases de datos
:DreamHome Controller
:Lease
:Pro~ForRent
I
:aClient
:Viewing
I
SearchProperties()
~
L..,.J : , relurnAvailability() , * malchPreferences(prefType, :
checkAvailabilily(pfrNo)
:
, ..,..-J
PFRA va ilabilíty()
. : arrangeView(aClíenlNo, viewDate)
arrangeViewing()
Figura 25.18.
Diagrama de secuencia para el caso de uso Buscar inmuebles.
1. SearchPropertíesO 2. arrangeViewing()
•• :aClíent
pfrNo,
1.1 malchPreferences(prefType,
~
I
:Pro~ForRent
•
:DreamHome Controller
1.2 returnResults()
maxRent)
1.1.2 relurnPFRAvailabilily()
viewDate) 2.1 arrangeView(aClienlNo,
PfrNo'l
1.1.1 ,hockA.,i1,b;!;Mp1,No)
:Lease
:Viewing
Figura 25.19.
Diagrama de colaboración
1 f 1.1.1 "tomA"i1";!;tyO
para el caso de uso Buscar inmuebles.
los diagramas de estados usualmente modelan las transiciones de un objeto específico. La Figura 25.20 proporciona un ejemplo de diagrama de estados para PropertyForRent. De nuevo, la notación es muy simple, estando compuesta de unos pocos símbolos: •
Los estados están representados por recuadros con esquinas redondeadas.
•
Las transiciones están representadas por flechas continuas entre estados, etiquetadas con el 'nombresuceso/acción' (el suceso provoca la transición y la acción es el resultado de la transición). Por ejemplo, en la Figura 25.20, la transición del estado Pending a Available es provocada por un suceso approveProperty y da lugar a la acción denominada makeAvailableO.
•
El estado inicial (el estado del objeto antes de que se produzca ninguna transición) mediante un círculo relleno con una flecha que lleva al estado inicial.
•
El estado final (el estado que marca la destrucción del objeto) está representado por un círculo relleno rodeado por otro círculo y con una flecha que proviene del estado precedente.
se representa
Capítulo 25 Introducción a los SGDB orientados a objetos
approveProperty / makeAvailableO
leaseProperty / makeUnavailableO
765
removeProperty / makeUnavailableO
leaseCompletion / makeAvailableO
deleteProperty
createProperty
•••
@ removeProperty / makeUnavailableO
rejectProperty
Figura 25.20.
Diagrama de estados para PropertyForRent.
Diagramas de actividad Los diagramas de actividad modelan el flujo de control de una actividad a otra. Un diagrama de actividad representa normalmente la invocación de una operación, un paso dentro de un proceso de negocio o un proceso de negocio completo. Está compuesto de estados de actividad y de transiciones entre dichos estados. El diagrama muestra el flujo de control y las distintas ramas (pequeños rombos) pueden utilizarse para especificar rutas de transiciones alternativas. Los flujos de ejecución paralelos se representan mediante estructuras de bifurcación y de combinación (rectángulos rellenos). Las calles (similares a las calles utilizadas en una piscina de competición) pueden utilizarse para separar áreas independientes. La Figura 25.21 muestra un esbozo de diagrama de actividad para "breamHome.
25.7.2
Utilización de UML en la metodología de diseño de bases de datos
Muchos de los tipos de diagramas que hemos descrito resultan útiles durante el ciclo de desarrollo de un sistema de base de datos, particularmente durante la etapa de recopilación y análisis de requisitos y durante la de diseño de la base de datos y de las aplicaciones. He aquí unas cuantas directrices útiles (McCready, 2003): • Generar diagramas de casos de uso a partir de la especificación de requisitos o mientras se esté elaborando ésta, para representar las funciones principales requeridas del sistema. Los casos de uso pueden ampliarse con descripciones textuales de los mismos. •
Generar un primer esbozo del diagrama de clases (modelo ER).
•
Generar un diagrama de secuencia para cada caso de uso o para cada grupo de casos de uso relacionados. Esto mostrará la interacción entre las clases (entidades) necesaria para soportar la funcionalidad definida en cada caso de uso. Los diagramas de colaboración pueden generarse fácilmente a partir de los diagramas de secuencia (por ejemplo, la herramienta CASE Rational Rose puede generar automáticamente un diagrama de colaboración a partir del correspondiente diagrama de secuencia).
•
Puede resultar útil añadir una clase de control al diagrama de clases para representar la interfaz entre los actores y el sistema (las operaciones de la clase de control se deducen a partir de los casos de uso).
•
Actualizar el diagrama de clases para mostrar los métodos requeridos en cada clase.
•
Crear un diagrama de estados para cada clase que muestre cómo cambia de estado la clase en respuesta a los mensajes que reciba. Los mensajes apropiados pueden identificarse a partir de los diagramas de secuencias.
766 •
Sistemas de bases de datos Revisar los diagramas anteriores basándose en los nuevos conocimientos obtenidos durante este proceso (por ejemplo, la creación de diagramas de estado puede ayudar a identificar métodos adicionales para el diagrama de clases). Cliente
Ventas
Propietario
Registrar nuevo inmueble
Inmueble adecuado
Acordar visita
Inmueble aceptable
Inmuebles no adecuados
Inmueble no aceptable
Acordar contrato
Renovar contrato
Figura 25.21.
Buscar otro inmueble
Diagrama de actividad de ejemplo para DreamHome.
Resumen del capítulo •
Entre las aplicaciones avanzadas de las bases de datos podemos citar el diseño asistido por computadora (CAD), la fabricación asistida por computadora (CAM), la ingeniería del software asistida por computadora (CASE), los sistemas de gestión de red, los sistemas de información de oficina (OlS) y sistemas multimedia, la edición digital, los sistemas de información geográfica (GIS) y los sitios interactivos y dinámicos, así como cualquier otra aplicación con objetos complejos e interrelacionados y datos procedimentales.
Capítulo 25 Introducción a los SGDB orientados a objetos
767
•
El modelo relacional, y los sistemas relacionales en particular, presentan debilidades tales como la inadecuada representación de las entidades de] 'mundo rea]', ]a sobrecarga semántica, e] inadecuado soporte para las restricciones de integridad y las restricciones empresariales, e] conjunto limitado de operaciones y ]a denominada desadaptación de impedancias. Las capacidades de modelado limitadas de los SGBD relacionales hacen que éstos no resulten adecuados para las aplicaciones avanzadas de bases de datos.
•
E] concepto de encapsulación significa que un objeto contiene tanto una estructura de base de datos como el conjunto de operaciones que pueden usarse para manipu]arla. El concepto de ocultación de la información significa que se separan los aspectos externos de un objeto de sus detalles internos, que están ocultos a ojos del mundo exterior.
•
Un objeto es una entidad unívocamente identificable que contiene tanto los atributos que describen el estado de un objeto de] 'mundo real' como las acciones (comportamientos) asociadas con él. Los objetos pueden contener otros objetos. Una parte fundamenta] de la definición de un objeto es que debe tener una identidad unívoca. En un sistema orientado a objetos, cada objeto tiene un identificador uní vaca dentro de] sistema (el OID) que es independiente de los valores de sus atributos y que, idealmente, resulta invisible para e] usuario. Los métodos definen el comportamiento de] objeto. Pueden utilizarse para cambiar el estado del objeto modificando los valores de sus atributos o para consultar el valor de una serie de atributos seleccionados. Los mensajes son e] medio por el que los objetos se comunican. Un mensaje es simplemente una solicitud que un objeto (el emisor) dirige a otro objeto (el receptor), pidiendo al segundo objeto que ejecute uno de sus métodos. El emisor y e] receptor pueden ser un mismo objeto.
•
•
Los objetos que tienen los mismos atributos y responden a los mismos mensajes pueden agruparse para formar una clase. Los atributos y los métodos asociados pueden entonces definirse una única vez para la clase en lugar de definirlos por separado para cada objeto. Una clase es también un objeto y tiene sus propios atributos y métodos, a los que se denomina, atributos de clase y métodos de clase, respectivamente. Los atributos de clase describen las características generales de la clase, como los totales o promedios.
•
La herencia permite definir una clase como caso especial de otra clase más general. Estos casos especiales se conocen con el nombre de subclases y los casos más generales se llaman superclases. El proceso de formar una superclase se denomina generalización, mientras que e] de formar una subclase se llama especialización. Una subclase hereda todas las propiedades de su superclase y puede definir, adicionalmente, sus propias propiedades exclusivas (atributos y métodos). Todas las instancias de la subclase serán también instancias de la superclase. El principio de sustituibilidad indica que una instancia de la subclase puede utilizarse siempre que un método o una estructura de programación espere una instancia de ]a superclase.
•
La sobrecarga permite reutilizar e] nombre de un método dentro de una definición de clase o entre varias definiciones. La anulación, un caso especial de sobrecarga, permite redefinir el nombre de una propiedad dentro de una subclase. E] enlace dinámico permite diferir hasta el momento de la ejecución ]a determinación del tipo de un objeto y de los métodos que hay que utilizar.
•
En respuesta a ]a creciente complejidad de las aplicaciones de bases de datos, han surgido dos 'nuevos' modelos de datos: el modelo de datos orientado a objetos y el modelo de datos objeto-relacional. Sin embargo, a diferencia de los modelos anteriores, la composición actual de estos modelos no está todavía clara. Esta evolución representa la tercera generación de sistemas SGBD.
Cuestiones de repaso 25.1.
Explique las características generales de las aplicaciones avanzadas de bases de datos.
25.2.
Explique por qué las debilidades del modelo de datos relaciona y de los SGBD relacionales pueden hacer que resulten inadecuados para las aplicaciones avanzadas de bases de datos.
25.3.
Defina cada uno de los siguientes conceptos en el contexto de un modelo de datos orientado a objetos: (a)
abstracción, encapsulación y ocultación de la información;
768
Sistemas de bases de datos (b)
objetos y atributos;
(c)
identidad de los objetos;
(d)
métodos y mensajes;
(e)
clases, subclases, superclases y herencia;
(f)
anulación y sobrecarga;
(g)
polimorfismo y enlace dinámico.
Proporcione ejemplos utilizando los datos del ejemplo DreamHome de la Figura 3.3. 25.4.
Explique las dificultades implicadas al asignar los objetos creados en un lenguaje de programación orientado a objetos a una base de datos relacional.
25.5.
Describa las tres generaciones de sistemas SGBD.
25.6.
Describa cómo pueden modelarse las relaciones en un SGBDOO.
25.7.
Describa las diferentes notaciones de modelado del lenguaje UML.
Ejercicios 25.8.
Investigue una de las aplicaciones avanzadas de base de datos analizadas en la Sección 25.1 u otra similar que tenga que gestionar datos complejos interrelacionados. En particular, examine su funcionalidad y los tipos de datos y operaciones que utiliza. Asigne los tipos de datos y las operaciones a los conceptos orientados a objetos expuestos en la Sección 25.3
25.9.
Analice uno de los SGBDR que esté actualmente utilizando. Explique las características de orientación a objetos proporcionadas por el sistema. ¿Qué funcionalidad adicional proporcionan estas características?
25.10. Para el caso de estudio de DreamHome documentado en el Apéndice A, sugiera los atributos y métodos que serían apropiados para las clases Branch, Staff y PropertyForRent. 25.11. Dibuje los diagramas de casos de uso y un conjunto de diagramas de secuencia asociados para el caso de estudio de DreamHome documentado en el Apéndice A.
"
25.12. Dibuje los diagramas de casos de uso y un conjunto de diagramas de secuencia asociados para el caso de estudio de University Accommodation Office documentado en el Apéndice B.l. 25.13. Dibuje los diagramas de casos de uso y un conjunto de diagramas de secuencia asociados para el caso de estudio de Easy Drive School 01 Motoring documentado en el Apéndice B.2. 25.14. Dibuje los diagramas de casos de uso y un conjunto de diagramas de secuencia asociados para el caso de estudio de Wellmeadows Hospital documentado en el Apéndice B.3.
Bases de datos orientadas a objetos: conceptos
Objetivos del capítulo: En este capítulo aprenderá: • •
El marco conceptual para un modelo de datos orientado a objetos. Los fundamentos del modelo de datos funcional.
•
Los fundamentos de los lenguajes de programación persistentes.
•
Los puntos principales del Manifiesto SGBDOO.
•
Las estrategias principales para desarrollar un SGBDOO.
•
La diferencia entre el modelo de almacenamiento en dos niveles utilizado por los SGBD convencionales y el modelo de un único nivel empleados por los SGBDOO.
•
Cómo funciona la técnica de transformación de punteros.
•
La diferencia entre el modo que accede a un registro un SGBD convencional y la forma en que un SGBDOO accede a un objeto en almacenamiento secundario.
•
Los diferentes mecanismos para proporcionar persistencia en los lenguajes de programación.
•
Las ventajas y desventajas de la persistencia ortogonal.
•
Diversas cuestiones de importancia relacionadas con los SGBDOO, incluyendo los modelos extendidos de transacciones, la gestión de versiones, la evolución de esquemas, las arquitecturas de los SGBDOO y los bancos de pruebas.
•
Las ventajas y desventajas de los SGBDOO.
En el capítulo anterior hemos visto las debilidades del modelo de datos relaciona], comparándo]o con los requisitos que tienen los tipos de aplicaciones avanzadas de bases de datos que han surgido en los próximos años. También hemos introducido los conceptos de orientación a objetos, que resuelven algunos de los problemas clásicos del desarrollo software. Algunas de las ventajas que a menudo se citan en favor de ]a orientación a objetos son: •
La definición de un sistema en términos de objetos facilita la construcción de componentes software que semejan estrechamente el dominio de aplicación, lo que sirve de ayuda en e] diseño de los sistemas y contribuye a que sean más fácilmente comprensibles.
•
Gracias a la encapsulación y a la ocultación de información, la utilización de objetos y mensajes promueve el diseño modular: la implementación de un objeto no depende de los detalles internos de otro, sino sólo de cómo responde éste a los mensajes. Además, la modularidad se refuerza y el software puede llegar a ser más fiable.
•
La utilización de clases y de herencia promueve el desarrollo de componentes reutilizables y ampliables en la construcción de sistemas nuevos o actualizados.
770
Sistemas de bases de datos
En este capítulo vamos a considerar las cuestiones asociadas con una de las técnicas para integrar conceptos de orientación a objetos en los sistemas de bases de datos, la técnica de los sistemas de gestión de bases de datos orientados a objetos (SGBDOO). Los SGBDOO surgieron en los campos de la ingeniería y el diseño y también han llegado a convertirse recientemente en los sistemas favoritos para aplicaciones financieras y de telecomunicaciones. El mercado de los SGBDOO es pequeño en comparación con el mercado de los SGBD relacionales y, aunque la tasa estimada de crecimiento era del 50% a finales de la década de 1990, el mercado no ha sido capaz de mantener dicho crecimiento. En el siguiente capítulo examinaremos el modelo de objetos propuesto por ODMG (Object Data Management Group), que se ha convertido en el estándar defacto para los SGBDOO. También analizaremos ObjectStore, un SGBDOO comercial. Este alejamiento del modelo de datos relacional tradicional a menudo se denomina como la técnica revolucionaria de integración de los conceptos de orientación a objetos en los sistemas de bases de datos. Por contraste, en el Capítulo 28 examinaremos una técnica evolucionaria de integrar los conceptos de orientación a objetos en los sistemas de bases de datos, técnica que se basa en una extensión del modelo relacional. Estos sistemas evolucionarios suelen denominarse ahora sistemas SGBD objeto-relacionales (SGBDOR), aunque anteriormente se utilizaba el término SGBD relacional ampliado.
Estructura del capítulo En la Sección 26.1 se proporciona una introducción al modelo de datos orientados a objetos y a los lenguajes persistentes, y se explica cómo, a diferencia del modelo de datos relacional, no existe ningún modelo de datos orientado a objetos universalmente aceptado. También se expone brevemente el Manifiesto de los sistemas de base de datos orientados a objetos, que propuso trece características obligatorias para un SGBDOO, y examinaremos las distintas técnicas que puedan emplearse para desarrollar un SGBDOO. En la Sección 26.2 se examina la diferencia entre el modelo de almacenamiento en dos niveles utilizado por los SGBD convencionales y el modelo de un único nivel empleado en los SGBDOO y se explica cómo afecta esto al acceso a los datos. En la Sección 26.5 se explican las distintas técnicas para proporcionar persistencia en los lenguajes de programación y los diferentes mecanismos de transformación de punteros. En la Sección 26A se examinan algunas otras cuestiones relacionadas con los SQBDOO, que son los modelos extendidos de transacciones, la gestión de versiones, la evolución de esquemas, las arquitecturas de los SGBDOO y los bancos de pruebas. En la Sección 26.6 se analizan las ventajas y desventajas de los SGBDOO. Para sacar el máximo provecho de este capítulo, el lector debe estar familiarizado con el contenido del Capítulo 25. De nuevo, los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome documentado en la Sección lOA y en el Apéndice A.
26. 1 Introducción a los modelos de datos orientados a objetos y a los SGBDOO En esta sección se analizan algunos conceptos básicos de los SGBDOO, incluyendo el modelo de datos funcional y los lenguajes de programación persistentes. Comenzaremos echando un vistazo a la definición de un SGBDOO.
26.1.1
Definición de un SGBD orientado a objetos
En esta sección se examinan algunas de las diferentes definiciones que han sido propuestas para un SGBD orientado a objetos. Kim (1991) define un modelo de datos orientado a objetos y una base de datos orientada a objetos y un SGBD orientado a objetos (SGBDOO) de la forma siguiente: Modelo de datos orientado a objetos
Un modelo de datos (lógico) que captura la semántica de los objetos soportados en la programación orientada a objetos.
Capítulo 26 Basesde datos orientadas a objetos: conceptos Base de datos orientada a objetos
Una colección persistente y compartible de datos orientado a objetos.
SGBDOO
El gestor de una base de datos orientada a objetos.
771
de objetos definida por un modelo
Estas definiciones no son muy descriptivas y tienden a reflejar el hecho de que no existe ningún modelo de datos orientado a objetos que sea equivalente al modelo de datos subyacente a los sistemas relacionales. Cada sistema proporciona su propia interpretación de la funcionalidad básica. Por ejemplo, Zdonik y Maier (1990) presentan una serie de umbrales que un SGBDOO debe como mínimo satisfacer: (1) debe proporcionar funcionalidad de base de datos; (2) debe soportar el concepto de identidad de los objetos; (3) debe proporcionar un mecanismo de encapsulación; (4) debe soportar objetos con estado complejo. Los autores argumentan que, aunque la herencia puede ser útil, no resulta esencial para la definición, y un SGBDOO podría existir sin dicho mecanismo. Por el contrario, Khoshafian y Abnous (1990) definen un SGBDOO como: (1) orientación a objetos = tipos abstractos de datos + herencia + identidad de los objetos; (2) SGBDOO = orientación a objetos + capacidades de base de datos. Otra definición más de un SGBDOO es la que proporciona Parsaye el al. (1989): (1) un lenguaje de consulta de alto nivel con capacidades de optimización de las consultas en el sistema subyacente; (2) soporte para la persistencia, transacciones atómicas y control de concurrencia y recuperación; (3) soporte para el almacenamiento de objetos complejos, índices y métodos de acceso para una extracción rápida y eficiente de los datos; (4) SGBDOO = sistema ori~ntado a objetos + (1) + (2) + (3). Estudiando algunos de los SGBDOO comerciales actuales, como GemStone de Gemstone Systems Inc. (anteriormente Servio Logic Corporation), Objectivity/DB de Objectivity Inc., ObjectStore de Progress Software Corporation (anteriormente Object Design Inc.), 'FastObjects by Poet' de Poet Software Corporation, Jasmine Object Database de Computer Associates/Fujitsu Limited y Versant (VDS) de Versant Corporation, podemos ver que los conceptos de los modelos de datos orientados a objetos están extraídos de áreas distintas, como se muestra en la Figura 26.1. En la Sección 27.2 se examina el modelo de datos propuesto por ODMG (Object Data Management Group), que muchos de estos fabricantes afirman soportar. El modelo de objetos ODMG es importante porque especifica un modelo estándar para la semántica de los objetos de la base de datos y soporta la interoperabilidad entre los SGBDOO compatibles. El lector interesado puede ver una panorámica de los conceptos básicos de los modelos de datos orientados a objetos en Dittrich (1986) y Zaniola el al. (1986).
26.1.2
Modelos de datos funcionales
En esta sección se presenta el modelo de datos funcional (FDM, functional data model), que es uno de los más simples dentro de la familia de modelos de datos semánticos (Kerschberg y Pacheco, 1976; Sibley y Kerschberg, 1977). Este modelo es interesante porque comparte ciertas ideas con la técnica basada en objetos, incluyendo los conceptos de identidad de los objetos, herencia, sobrecarga y acceso navegacional. En el FDM, cualquier tarea de extracción de datos puede verse como el proceso de evaluar y devolver el resultado de una función con cero, uno o más argumentos. El modelo de datos resultante es conceptualmente simple, al mismo tiempo que muy expresivo. En el FDM, las primitivas principales de modelado son las entidades y relaciones funcionales.
772
Sistemas de bases de datos
Sistemas de bases de datos tradicionales
Modelos de datos semánticos
Programación orientada a objetos
Requisitos especiales
• Persistencia • Comparlición • Transacciones • Control de concurrencia • Control de recuperación • Seguridad • Integridad • Consultas
• Generalización • Agregación
• Identidad de los objetos • Encapsulación • Herencia • Tipos y clases • Métodos • Objetos complejos • Polimorfismo • Ampliabilidad
• Control de versiones • Evolución del esquema
Modelo de datos orientado a objetos
Figura 26.1.
Orígenes del modelo de datos orientado a objetos.
Entidades Las entidades se descomponen en tipos de entidad (abstractos) y tipos de entidad imprimibles. Los tipos de entidad se corresponden con las clases de los objetos del 'mundo real' y se declaran como funciones con cero argumentos que devuelven el tipo ENTITY. Por ejemplo, podemos declarar los tipos de entidad Staff y PropertyForRent de la forma siguiente: Staff O ~
ENTITY
PropertyForRentO
~
ENTITY
Los tipos de entidad imprimibles son análogos a los tipos base en un lenguaje de programación e incluyen: INTEGER, CHARACTER, STRING, REAL y DATE. Un atributo se define como una relaciónfuncional, que toma el tipo de entidad como argumento y devuelve un tipo de entidad imprimible. Algunos de los atributos del tipo de entidad Staff podrían declararse de la forma siguiente: staffNo(Staff) sex(Staff) ~ salary(Staff)
~ STRING CHAR ~ REAL
Así, aplicando la función staffNo a una entidad de tipo Staff entidad, que es un valor imprimible de tipo STRING. Podemos mero el atributo como un tipo de entidad y luego declarando de dicho tipo de entidad. Por ejemplo, podemos declarar el siguiente: NameO ~
se devolvería el número de empleado de dicha declarar un atributo compuesto declarando prisus componentes como relaciones funcionales atributo compuesto Name de Staff de la forma
ENTITY
Name(Staff) ~ NAME fName(Name)
~
IName(Name)
~
STRING STRING
Relaciones Las funciones con argumentos no sólo modelan las propiedades (atributos) de los tipos de entidad sino también las relaciones entre los tipos de entidad. Así, el FDM no realiza ninguna distinción entre atributos y rela-
Capítulo 26 Bases de datos orientadas a objetos: conceptos
773
ciones. Para cada relación puede definirse una relación inversa. Por ejemplo, podemos modelar la relación uno a muchos Staff Manages PropertyForRent de la forma siguiente: --+~PropertyForRent
Manages(Staff)
ManagedBy(PropertyForRent)
--+ Staff
INVERSE OF
Manages
En este ejemplo, la flecha de doble cabeza se utiliza para representar una relación uno a muchos. Esta notación también puede utilizarse para representar atributos multivaluados. Las relaciones muchos a muchos pueden modelarse utilizando la flecha de doble cabeza en ambas direcciones. Por ejemplo, podemos modelar la relación *:* Client Views PropertyForRent de la forma siguiente: Views(Client)
--+~PropertyForRent
--+~Client INVERSE OF Views
ViewedBy(PropertyForRent)
Observe que una entidad (instancia) es una especie de símbolo que identifica un objeto unívoco de la base de datos y que típicamente representa un objeto unívoco del 'mundo real'. Además, una función establece una correspondencia entre una entidad dada y una o más entidades de destino (por ejemplo, la función Manages establece una correspondencia entre una entidad Staff concreta y un conjunto de entidades PropertyForRent). Así, todas las relaciones entre objetos se modelan asociando las correspondientes instancias de entidad y no sus nombres ni sus claves. De este modo, la integridad referencial constituye una parte implícita del modelo de datos funcional y no requiere ningún tipo de exposición explícita, a diferencia del modelo de datos relaciona!. El FDM también soporta funciones multivaluadas. Por ejemplo, podemos modelar el atributo la relación Views anterior de la forma siguiente: viewDate(Client,
PropertyForRent)
~
viewDate
de
DATE
Herencia y expresiones de ruta El FDM soporta los mecanismos de herencia mediante los tipos de entidad. Por ejemplo, la función StaffO devuelve un conjunto de entidades de empleados que se forma como un subconjunto del tipo ENTITY. Así, el tipo de entidad Staff es un subtipo del tipo de entidad ENTITY. Esta relación subtipo/supertipo puede ampliarse hasta cualquier nivel deseado. Como cabría esperar, los subtipos heredan todas las funciones definidas para todos sus supertipos. El FDM también soporta el principio de sustituibilidad (véase la Sección 25.3.6), de modo que una instancia de un subtipo es también instancia de sus supertipos. Por ejemplo, podríamos declarar el tipo de entidad Supervisor como un subtipo del tipo de entidad Staff de la forma siguiente: StaffO ~
ENTITY ~ ENTITY
SupervisorO
IS-A-STAFF(Supervisor)
~ Staff
El FDM permite definir funciones derivadas mediante la composición de múltiples funciones. Así, podemos definir las siguientes funciones derivadas (observe la sobrecarga de los nombres de las funciones): fName(Staff)
~ fName(Name(Staff))
fName(Supervisor)
~ fName(IS-A-STAFF(Supervisor))
La primera función derivada devuelve un conjunto de nombres de los empleados evaluando la función compuesta que aparece en el lado derecho de la definición. Teniendo esto en cuenta, en el segundo caso se Esta evalúa el lado derecho de la definición como la función compuesta fName(Name(IS-A-STAFF(Supervisor))). composición se denomina expresión de ruta y puede ser más reconocible si utilizamos para escribirla la notación de puntos: Supervisor.IS-A-STAFF.
Name. fname
La Figura 26.2(a) proporciona una declaración para parte del caso de estudio de DreamHome en forma de esquema FDM, mientras la Figura 26.2(b) proporciona la correspondiente representación gráfica.
774
Sistemas de bases de datos
Declaraciones de tipos de entidad StaffO > ENTITY
PropertyForRentO
SupervisorO
ClientO
ENTITY
>
Declaraciones
Name
ENTITY
>
ENTITY
de atributos
fName(Name)
>
STRING
staffNo(Staff)
IName(Name)
>
STRING
position(Staff)
fName(Staff) IName(Staff)
>
ENTITY
>
>
>
fName(Name(Staff))
sex(Staff)
IName(Name(Staff))
salary(Staff)
STRlNG
>
>
>
fName(Name(Client))
c1ientNo(Client)
IName(Client)
>
IName(Name(Client))
teINo(Client)
>
city(PropertyForRent)
REAL
>
STRING
>
maxRent(Client)
>
>
STRlNG
>
STRING
>
rooms(PropertyForRent) rent(PropertyForRent)
STRING
>
STRING
>
type(PropertyForRent)
STRlNG
prefType(Client)
>
>
INTEGER
REAL
STRING REAL
de tipos de relación
Manages(Staff)
PropertyForRent
>
ManagedBy(PropertyForRent) Views(Client)
street(PropertyForRent)
CHAR
>
fName(Client)
Declaraciones
propertyNo(PropertyForRent)
STRING
>
Staff INVERSE OF Manages
PropertyForRent
>
ViewedBy(PropertyForRent)
>
Glient INVERSE OF Views
viewDate(Client, PropertyForRent) comments(Client, PropertyForRent) Declaraciones
>
DATE STRlNG
>
de herencia
IS-A-STAFF(Supervisor) staffNo(Supervísor) fName(Supervísor)
>
IName(Supervisor)
>
position(Supervisor) sex(Supervisor)
Staff
>
staffNo(IS-A-STAFF(Supervisor))
>
fName(IS-A-STAFF(Supervisor)) IName(lS-A-STAFF(Supervisor)) >
position(IS-A-STAFF(Supervisqj;))
sex(IS-A-STAFF(Supervisor))
>
salary(Supervisor)
>
salary(IS-A-STAFF(Supervisor))
(a)
Figura 26.2.
(a) Declaración de una parte del caso de estudio de DreamHome como esquema FDM.
Lenguajes de consulta funcionales Las expresiones
de ruta también
nar los lenguajes de esta sección.
de consulta En lugar
para extraer los apellidos mos escribir:
se utilizan
en detalle;
dentro
el lector
de un lenguaje interesado
de ello, proporcionaremos de los clientes
un ejemplo
que han visto
de consulta
puede
consultar
simple
un inmueble
funcional.
para ilustrar
gestionado
No vamos
los artículos
a exami-
que se citan
el lenguaje.
por el empleado
al final
Por ejemplo, SO
14, podría-
RETRIEVE IName(Name(ViewedBy(Manages(Staff)))) WHERE staffNo(Staff) = 'SO 14' Si comenzamos Manages(Staff) tado
se devuelve
devuelve nocible:
por
devuelve un
los apellidos
el interior un conjunto
conjunto de estos
de la expresión de entidades
de entidades clientes.
de ruta
y
PropertyForRent.
Client.
De nuevo,
Finalmente, la notación
vamos
progresando
Aplicando
la función
hacia
fuera,
ViewedBy
aplicando
las funciones
de puntos
equivalente
Name puede
la función a este resul-
y
IName,
se
ser más reco-
Capítulo 26 Basesde datos orientadas a objetos: conceptos
ManagedBy
775
Manages
(b)
Figura 26.2.
(Cant.).
RETRIEVE 8taff. Manages. ViewedBy. WHERE 8taff.staffNo = 'SG 14' Observe que la correspondiente intuitiva que la instrucción FDM:
(b) Representación
diagramática
correspondiente.
Name.IName
instrucción SQL requeriría tres operaciones de combinación y es menos
SELECT c.IName FROM 8taff s, PropertyForRent p, Viewing v, Client c WHERE s.staffNo = p.staffNo AND p.propertyNo = v.propertyNo AND v.clientNo = c.clientNo AND s.staffNo = '8G14'
Ventajas Entres las ventajas del FDM podemos citar: •
Soporte para algunos conceptos de orientación a objetos. El FDM es capaz de soportar los conceptos de identidad de los objetos, herencia (a través de jerarquías de clases de entidades), sobrecarga de los nombres de funciones y acceso navegacional.
776
Sistemas de bases de datos
•
Soporte para la integridad referencial. El FDM es un modelo de datos basado en entidades que soporta implicitamente la integridad referencial.
•
lrreducibilidad. El FDM está compuesto de un pequeño número de conceptos simples que representan unidades de información semánticamente irreducibles. Esto permite dibujar gráficamente un esquema de base de datos con relativa facilidad, simplificándose así el diseño conceptual.
•
Fácil ampliabilidad. Pueden añadirse/borrarse car los objetos del esquema existentes.
•
Adecuación para la integración de esquemas. La simplicidad conceptual de FDM implica que puede utilizarse para representar diversos modelos de datos diferentes, incluyendo los modelos relacional, en red, jerárquico y orientado a objetos. Esto hace que FDM sea un modelo adecuado para la integración de esquemas heterogéneos dentro de sistemas multi-base de datos como los presentados en la Sección 22.1.3.
•
Lenguaje de consulta declarativo. El lenguaje de consulta es declarativo, con una semántica bien estudiada (basada en el cálculo lambda). Esto hace que el lenguaje sea fácil de transformar y optimizar.
clases de entidad y funciones sin necesidad de modifi-
Se han realizado muchas propuestas de lenguajes y modelos de datos funcionales. Las dos primeras fueron FQL (Buneman y Frankel, 1979) y, quizás la más conocida DAPLEX (Shipman, 1981). El atractivo del estilo funcional de estos lenguajes ha dado lugar a muchos sistemas, como por ejemplo GDM (Batory et al., 1988), FDM Extendido (Kulkarni y Atkinson, 1986, 1987), FDL (Poulovassilis y King, 1990), PFL (Poulovassilis y Small, 1991) y P/FDM (Gray et al., 1992). Los lenguajes de datos funcionales también se han utilizado con modelos de datos no funcionales, como PDM (Manola y Dayal, 1986), IPL (Annevelink, 1991) y LIFOO (Boucelma y Le Maitre, 1991). En la sección siguiente examinaremos otra área de investigación que ha jugado un papel de importancia en el desarrollo de los SGBDOO.
26.1.3
Lenguajes de programación persistentes
Antes de comenzar a examinar los SGBDOO en detalle, vamos a introducir otra área interesante, aunque independiente, de desarrollo conocida con el nombre de lenguajes de programación persistentes.
~
Lenguaje de programación persistente
Un lenguaje que proporciona a sus usuarios la capacidad de preservar los datos (transparentemente) entre ejecuciones sucesivas de un programa, e incluso permite que dichos datos sean utilizados por muchos programas diferentes.
Los datos en un lenguaje de programación persistente son independientes de los programas, y pueden existir después de terminar la ejecución y el ciclo de vida del código que los creó. Dichos lenguajes no tenían como intención original proporcionar ni una funcionalidad completa de base de datos ni mecanismos de acceso a los datos desde múltiples lenguajes (Cattell, 1994). Lenguaje de programación de base de datos
Un lenguaje que integra ciertas ideas del modelo de programación de bases de datos con características de los lenguajes de programación tradicionales.
Por contraste, un lenguaje de programación de base de datos se diferencia de un lenguaje de programación persistente porque incorpora características adicionales a la persistencia, como por ejemplo mecanismos de gestión de transacciones, de control de concurrencia y de recuperación (Bancilhon y Buneman, 1990). El estándar SQL de ISO especifica que SQL puede incrustarse en los lenguajes de programación C, Fortran, Pascal, COBOL, Ada, MUMPS y PUl (véase el Apéndice E). La comunicación se lleva a cabo mediante un conjunto de variables en el lenguaje host y un preprocesador especial modifica el código fuente para sustituir las instrucciones SQL por llamadas a rutinas del SGBD. El código fuente puede entonces compilarse y montarse de la forma normal. Alternativamente, puede proporcionarse una API, lo que elimina la necesidad de la precompilación. Aunque la técnica de incrustación es algo pesada, se trataba de una técnica útil y necesaria,
Capítulo 26 Basesde datos orientadas a objetos: conceptos
777
ya que el estándar SQL2 no era computacionalmente completot. Los problemas al utilizar dos paradigmas del lenguaje diferente, recibe, colectivamente, el nombre de des adaptación de impedancias entre el lenguaje de programación de la aplicación y el lenguaje de consulta de la base de datos (véase la Sección 25.2). Algunos autores afirman que se dedica hasta un 30% del esfuerzo de programación y del espacio de código a convertir datos de los formatos del archivo o de la base de datos a los formatos internos del programa (Atkinson et al., 1983). La integración de la persistencia dentro del lenguaje de programación libera al programador de esta responsabilidad. Los investigadores que trabajan en el desarrollo de lenguajes de programación persistentes se han visto motivados principalmente por los siguientes objetivos (Morrison et al., 1994): •
mejorar la productividad de la programación utilizando una semántica más simple;
•
eliminar los mecanismos ad hoc para traducción de los datos y para almacenamiento largo plazo;
•
proporcionar mecanismos de protección para todo el entorno.
de los datos a
Los lenguajes de programación persistentes tratan de eliminar la desadaptación de impedancias ampliando el lenguaje de programación con capacidades de base de datos. En un lenguaje de programación persistente, el sistema de tipos del lenguaje proporciona el modelo de datos, que usualmente contiene mecanismos muy ricos de estructuración. En algunos lenguajes, por ejemplo PS-algol y Napier88, los procedimientos son objetos de 'primera clase' y se los trata como a cualquier otro objeto de datos del lenguaje. Por ejemplo, los procedimientos pueden asignarse, pueden ser el resultado de una expresión o de otros procedimientos o bloques y pueden ser elementos de tipos constructores. Entre otras cosas, los procedimientos pueden utilizarse para implementar tipos abstractos de datos. El acto de importar un tipo abstracto de datos desde el almacenamiento persistente y enlazado dinámicamente en un programa es equivalente al montaje de módulos en los lenguajes más tradicionales. El segundo objetivo de importancia de un lenguaje de programación persistente es mantener la misma representación de los datos en el espacio de memoria de la aplicación que en el almacenamiento secundario persistente. Esto elimina las dificultades y el gasto necesario de recursos que se derivan de la necesidad de establecer una correspondencia entre los dos tipos de representación, como veremos en la Sección 26.2. La adición de mecanismos de persistencia (transparentes) a un lenguaje de programación constituye una importante mejora para los entornas de desarrollo interactivos, y la integración de los dos paradigmas proporciona una mayor funcionalidad y una mayor semántica. La investigación en lenguajes de programación persistentes ha tenido una gran influencia sobre el desarrollo de los SGBDOO, y muchas de las cuestiones de las que hablaremos en las Secciones 26.2, 26.3 Y 26.4 se aplican tanto a los lenguajes de programación persistentes como a los SGBDOO. En ocasiones se utiliza el término más general sistema de aplicación persistente en lugar del término 'lenguaje de programación persistente' (Atkinson y Morrison, 1995).
26.1.4
El Manifiesto de los sistemas de base de datos orientados a objetos
En 1989, el Manifiesto de los sistemas de base de datos orientados a objetos propuso trece características obligatorias para un SGBDOO, basados en dos criterios: debía tratarse de un sistema orientado a objetos y debía ser un SGBD (Atkinson et al., 1989). Las reglas se resumen en la Tabla 26.1. Las primeras ocho reglas se aplican a las características de orientación a objetos.
(1) Deben soportarse objetos complejos Debe ser posible construir objetos complejos aplicando constructores a una serie de objetos básicos. El conjunto mínimo de constructores está formado por SET, TUPLE y LIST (o ARRAY). Los primeros dos son importantes porque han obtenido una amplia aceptación como constructores de objetos en el modelo relaciotLa versión de 1999 del estándar SQL, SQL:1999, añadió nuevas estructuras
al lenguaje para hacerla computacionalmente
completo.
778
Sistemas de bases de datos Tabla 26.1.
Características
Características
de orientación
obligatorias en el Manifiesto de los sistemas de base de datos orientados a objetos.
a objetos
Características
de OBMS
Deben soportarse objetos complejos
Debe proporcionarse
persistencia a los datos
Deben soportarse mecanismos de identidad de los objetos
El SGBD debe ser capaz de gestionar bases de datos de muy gran tamaño
Debe soportarse la encapsulación
El SGBD debe soportar a usuarios concurrentes
Deben soportarse los tipos o clases
El SGBD debe ser capaz de recuperarse de fallos hardware y software
Los tipos o clases deben ser capaces de heredar de sus ancestros
El SGBD debe proporcionar los datos
una forma simple de consultar
Debe soportarse el enlace dinámico El DML debe ser computacionalmente
completo
El conjunto de todos los tipos de datos debe ser ampliable
nal. Por su parte, la importancia del último se deriva de que permite modelar las ordenaciones. Además, el manifiesto requiere que los constructores de objetos sean ortogonales: cualquier constructor debe poder aplicarse a cualquier objeto. Por ejemplo, no sólo debemos poder usar SET(TUPLE()) y LIST(TUPLE()) sino también TUPLE(SET()) y TUPLE(LIST()).
(2) Deben soportarse mecanismos de identidad de los objetos Todos los objetos deben tener una identidad unívoca que sea independiente tos.
de los valores de sus atribu-
(3) Debe soportarse la encapsulación En un SGBDOO, se consigue una adecuada encapsulación garantizando que los programadores sólo tengan acceso a la especificación de la interfaz de los métodos, y que los datos y la implementación de dichos métodos estén ocultos dentro de los objetos. Sin embargo, puede haber casos en los que no sea necesario imponer la encapsulación: por ejemplo, con las consultas ad hoc (en la Sección 25.3.1 ya hemos indicado que la encapsulación se considera como una de las mayores fortalezas de la técnica de orientación a objetos, en cuyo caso ¿por qué debería haber situaciones en las que fuera preciso anular la encapsulación? El argumento típico que se suele proporcionar es que no es un usuario ordinario el que está examinando el contenido de los objetos, sino el SGBD. En segundo lugar, el SGBD podría invocar el método 'get' asociado con cada atributo de cada clase, pero el examen directo es más eficiente. Dejamos estos argumentos para la reflexión del lector).
(4) Deben soportarse los tipos o clases Ya hemos mencionado la diferencia entre tipos y clases en la Sección 25.3.5. El manifiesto requiere que se soporte uno sólo de estos conceptos. El esquema de la base de datos en un sistemas orientado a objetos comprende un conjunto de clases o un conjunto de tipos. Sin embargo, no es imprescindible que el sistema mantenga automática mente la extensión de un tipo, es decir, el conjunto de objetos de un tipo dado en la base de datos; y si el sistema mantiene la extensión, no es imprescindible que haga que ésta sea accesible por parte del usuario.
(5) Los tipos
O
clases deben ser capaces de heredar de sus ancestros
Un subtipo o subclase debe heredar los atributos y métodos de su supertipo o superclase, respectivamente.
Capítulo 26 Basesde datos orientadas a objetos: conceptos
779
(6) Debe soportarse el enlace dinámico Los métodos deben poder aplicarse a objetos de diferentes tipos (sobrecarga). La implementación de un método dependerá del tipo del objeto al que se aplique (anulación). Para proporcionar esta funcionalidad, el sistema no puede enlazar los nombres del método hasta el momento de la ejecución (enlace dinámico).
(7) El DML debe ser computacionalmente completo En otras palabras, el lenguaje de manipulación de datos (DML, Data Manipulation Language) del SGBDOO debe ser un lenguaje de programación de propósito general. Esto no era, obviamente así en el estándar SQL2 (véase la Sección 5.1), aunque con el lanzamiento del estándar SQL: 1999 el lenguaje ha pasado a ser computacionalmente completo (véase la Sección 28.4).
(8) El conjunto de todos los tipos de datos debe ser ampliable El usuario debe ser capaz de construir nuevos tipos a partir del conjunto de tipos predefinidos por el sistema. Además, no debe haber ninguna distinción de uso entre los tipos definidos por el sistema y los tipos definidos por el usuario. Las cinco reglas obligatorias finales del manifiesto se aplican a las características de SGBD del sistema.
(9) Debe proporcionarse persistencia a los datos Al igual que un SGBD convencional, los datos deben permanecer (persistir) después de que termine la aplicación que los ha creado. El usuario no debe tener que mover o copiar explícitamente los datos para hacerlos persistentes.
(10) El SGBD debe ser capaz de gestionar bases de datos de muy gran tamaño En un SGBD convencional, existen mecanismos para gestionar de manera eficiente el almacenamiento secundario, como por ejemplo 19s índices y búferes. Un SGBDOO debe tener mecanismos similares que sean invisibles al usuario, proporcionando así una clara independencia entre los niveles lógico y físico del sistema.
(11) El SGBD debe soportar a usuarios concurrentes Un SGBDOO debe proporcionar mecanismos de control de concurrencia similares a los de los sistemas convencionales.
(12) El SGBD debe ser capaz de recuperarse de fallos hardware y software Un SGBDOO debe proporcionar nales.
mecanismos
de recuperación
similares a los de los sistemas convencio-
(13) El SGBD debe proporcionar una forma simple de consultar los datos Un SGBDOO debe proporcionar un mecanismo de consulta ad hoc que sea de alto nivel (es decir, razonablemente declarativo), eficiente (adecuado para la optimización de consultas) e independiente de la aplicación. No es necesario que el sistema proporcione un lenguaje de consulta; podría, por ejemplo, proporcionar en su lugar un explorador gráfico. El manifiesto propone las siguientes características opcionales: herencia múltiple, comprobación de tipos e inferencia de tipos, distribución a través de una red, transacciones de diseño y control de versiones. Resulta interesante que no se mencione de manera directa el soporte de los mecanismos de seguridad, de integridad o de vistas; ni siquiera se considera obligatorio un lenguaje de consulta completamente declarativo.
780
Sistemas de bases de datos
26.1.5
Estrategias alternativas para el desarrollo de un SGBDOO
Existen diversas técnicas para desarrollar un SGBDOO, que podemos resumir como sigue (Khoshafian y Abnous, 1990): •
Ampliar un lenguaje de programación orientado a objetos existente con capacidades de base de datos. Esta técnica añade capacidades de base de datos tradicionales a un lenguaje de programación orientado a objetos ya existente como Smallta1k, C++ o Java (véase la Figura 26.1). Este es el enfoque adoptado por GemStone, que amplía estos tres lenguajes.
•
Proporcionar bibliotecas SGBD orientadas a objetos ampliables. Esta técnica también añade capacidades tradicionales de base de datos a un lenguaje de programación orientado a objetos existente. Sin embargo, en lugar de emplear el lenguaje, se proporcionan bibliotecas de clases que soportan la persistencia, la agregación, los tipos de datos, las transacciones, la concurrencia, la seguridad, etc. Esta es la técnica adoptada por los productos Ontos, Versant y ObjectStore. Hablaremos de ObjectStore en la Sección 27.3.
•
Incrustar estructuras de un lenguaje de base de datos orientado a objetos en un lenguaje host convencional. En el Apéndice E se describe cómo puede incrustarse SQL en un lenguaje de programación host convencional. Esta estrategia utiliza la misma idea de incrustar un lenguaje de base de datos orientado a objetos en un lenguaje de programación host. Éste es el enfoque adoptado por O2, que proporcionaba extensiones incrustadas para el lenguaje de programación C.
•
Ampliar un lenguaje de base de datos existente con capacidades de orientación a objetos. Debido a la amplia aceptación de SQL, los fabricantes tratan de ampliado para proporcionar estructuras orientadas a objetos. Este enfoque ha sido adoptado por fabricantes tanto de sistemas SGBDR como de sistemas SGBDOO. La versión de 1999 del están dar SQL, SQL: 1999, soporta características de orientación a objetos (veremos estas características en la Sección 28.4). Además, el estándar ODMG (Object Data Management Group) especifica un estándar para Object SQL, del que hablaremos en la Sección 27.2.4. Los productos Ontos y Versant proporcionan una versión de Object SQL y muchos fabricantes de SGBDOO son compatibles con el estándar ODMG.
•
Desarrollar un lenguaje de datos/mod;lo de datos novedoso para base de datos. Éste es un enfoque radical que trata de partir de cero y desarrollar un lenguaje de base de datos y un SGBD completamente nuevos con capacidades orientadas a objetos. Este es el enfoque adoptado por SIM (Semantic Information Manager), que está basado en el modelo de datos semántico y tiene unos novedosos lenguajes DML/DDL (Jagannathan et al., 1988).
26.2 Perspectivas de los SGBDOO Los SGBD se ocupan principalmente de la creación y mantenimiento de colecciones de datos de gran tamaño y larga duración. Como hemos visto en capítulos anteriores, los SGBD modernos se caracterizan por soportar las siguientes características: •
Un modelo de datos. Una forma particular de describir los datos, las relaciones entre los mismos y las restricciones que les son aplicables.
•
Persistencia de los datos. La capacidad de que los datos pervivan a la ejecución de un programa y, posiblemente, al ciclo de vida del propio programa.
•
Compartición de los datos. La capacidad de que múltiples aplicaciones (o instancias de una misma aplicación) accedan a una serie de datos comunes, posiblemente al mismo tiempo.
•
Fiabilidad. La garantía de que los datos de la base de datos estén protegidos frente a fallos hardware y software.
•
Escalabilidad.
La capacidad de operar con grandes cantidades de datos de manera simple.
Capítulo 26 Basesde datos orientadas a objetos: conceptos
781
•
Seguridad e integridad. La protección de los datos frente a accesos no autorizados y la garantía de que los datos sean conformes con las reglas especificadas de corrección y coherencia.
•
Distribución. La Jcapacidad de distribuir fisicamente una colección lógicamente interrelacionada de datos compartidos a través de una red informática, preferiblemente haciendo que dicha distribución sea transparente para el usuario.
Por contraste, los lenguajes de programación tradicionales proporcionan estructuras para el control procedimental y para la abstracción de datos y funcional, pero carecen de soporte predefinido para muchas de las anteriores características de las bases de datos. Aunque tanto los lenguajes como las bases de datos resultan útiles en sus respectivos dominios, hay un creciente número de aplicaciones que requieren funcionalidad tanto de un SGBD como de un lenguaje de programación. Dichas aplicaciones se caracterizan por la necesidad de almacenar y extraer grandes cantidades de datos compartidos y estructurado s, como se explica en la Sección 25.1. Desde 1980 se ha invertido un considerable esfuerzo en desarrollar sistemas que integren los conceptos de estos dos dominios. Sin embargo, ambos dominios tienen perspectivas ligeramente distintas que es necesario considerar, debiéndose resolver las diferencias. Quizá dos de las más importantes preocupaciones desde la perspectiva del programador son las prestaciones y la facilidad de uso, las cuales pueden mejorarse si existe una integración más fluida entre el lenguaje de programación y el SGBD que la que proporcionan los SGBD tradicionales. Con un SGBD tradicional, vemos que: Es responsabilidad del programador decidir cuándo deben leerse y actualizarse los objetos (registros). •
El programador tiene que escribir un código para traducir entre el modelo de objetos de la aplicación y el modelo de datos del SGBD (por ejemplo, relaciones), pudiendo ser ambos modelos bastante diferentes. Con un lenguaje de programación orientado a objetos, en el que un objeto puede estar compuesto de muchos subobjetos representados por punteros, la traducción puede ser particularmente compleja. Como hemos indicado anteriormente, algunos autores afirman que hasta un 30% del esfuerzo de programación y del espacio de código está dedicado al establecimiento de este tipo de correspondencias. Si este proceso de establecimiento de correspondencias puede eliminarse o al menos reducirse, el programador quedará liberado de esta responsabilidad, el código resultante será más fácil de entender y de mantener y las prestaciones pueden, como consecuencia, mejorarse.
•
Es responsabilidad del programador realizar comprobaciones adicionales de tipos cuando se lee un objeto de la base de datos. Por ejemplo, el programador puede crear un objeto en el lenguaje orientado a objetos lava, que es fuertemente tipado, y almacenarlo en un SGBD tradicional. Sin embargo, otra aplicación escrita en un lenguaje distinto, podría modificar el objeto, sin que exista la garantía de que el objeto continúe siendo conforme con su tipo original.
Estas dificultades surgen del hecho de que los SGBD convencionales tienen un modelo de almacenamiento en dos niveles: el modelo de almacenamiento de la aplicación en la memoria principal o virtual, y el modelo de almacenamiento de la base de datos en disco, como se ilustra en la Figura 26.3. Por contraste, un SGBDOO trata de proporcionar la ilusión de que existe un modelo de almacenamiento de un único nivel, teniendo una representación similar tanto en memoria como en la base de datos almacenada en el disco, como se ilustra en la Figura 26.4. Aunque el modelo de memoria de un único nivel parece intuitivamente simple, el SGBDOO tiene que gestionar de manera inteligente las representaciones de los objetos en memoria y en disco para producir esta ilusión. Como hemos explicado en la Sección 25.3, los objetos (y las relaciones entre objetos) se identifican mediante identificadores de objetos (OID). Hay dos tipos de OID: •
identificadores OID lógicos que son independientes de la ubicación física del objeto en disco;
•
identificadores OID físicos que codifican la ubicación.
En el primer caso, se requiere un nivel de indirección para consultar la dirección física del objeto en disco. En ambos casos, sin embargo, el OID tendrá un tamaño distinto a los punteros estándar de memoria, que sólo necesitan ser lo suficientemente grandes como para poder direccionar toda la memoria virtual. Así, para conseguir las prestaciones requeridas, un SGBDOO debe ser capaz de convertir los OID en punteros de memo
782
Sistemas de bases de datos
M,mod, prloopal o ,irt,,1
~
no
no
u
no
no
no
no
no
no
J
no
no
no
no
no
no
no
no
no
Transformación y comprobación de
SOL
Almacenamiento secundario
Figura 26.3.
Modelo en almacenamiento
en dos niveles para un SGBD convencional (relacional).
Memoria principal o virtual
Almacenamiento secundario
Figura 26.4.
Modelo de almacenamiento
de un único nivel para un SGBDOO.
ria y viceversa. Esta técnica de conversión se denomina transformación de punteros o localización de objetos, y los métodos utilizados para implementarla son muy variados, yendo desde comprobaciones basadas en software hasta esquemas de intercambio de páginas utilizados por el hardware subyacente (Moss y Eliot, 1990), como se explica a continuación.
26.2.1
Técnicas de transformación de punteros
Transformación punteros
de
La acción de convertir los identificadores de objetos en punteros de memoria principal y viceversa.
El objetivo de la transformación de punteros es optimizar el acceso a los objetos. Como acabamos de mencionar, las referencias entre objetos se representan normalmente mediante los OID. Si leemos un objeto de almacenamiento secundario y lo almacenamos en la caché de páginas, debemos poder localizar en almacenamiento secundario todos los objetos a los que hace referencia utilizando sus OID. Sin embargo, una vez que se leen esos objetos referenciados en la caché, es necesario tener en cuenta que ahora esos objetos están en memoria principal, para evitar que vuelvan a ser extraídos del almacenamiento secundario. Una solución con-
Capítulo 26 Basesde datos orientadas a objetos: conceptos
783
siste en mantener una tabla de búsqueda que establezca la correspondencia entre los OID y los punteros de memoria principal. Podemos implementar los mecanismos de búsqueda en la tabla de forma razonablemente eficiente utilizando técnicas de hash, pero este mecanismo sigue siendo lento comparado con la operación de des-referenciar un puntero, particularmente si el objeto ya se encuentra en memoria. Sin embargo, la técnica de transformación de punteros trata de proporcionar una estrategia más eficiente almacenando los punteros de memoria principal en lugar de los OID referenciados, y a la inversa, cuando el objeto debe volverse a escribir en disco. En esta sección se describen algunas de las cuestiones relacionadas con la transformación incluyendo las diversas técnicas que se pueden emplear.
de punteros,
Sin transformación La implementación más simple de los mecanismos de movimiento de los objetos hacia y desde memoria consiste en no efectuar ningún tipo de transformación. En este caso, se leen los objetos en memoria por parte del gestor de objetos subyacente y se devuelve a la aplicación un descriptor que contiene el OID del objeto (White, 1994). El OID se utiliza cada vez que hay que acceder al objeto. Esto requiere que el sistema mantenga algún tipo de tabla de búsqueda para poder localizar el puntero del objeto en memoria virtual y utilizarlo para acceder al objeto. Puesto que es necesario realizar una búsqueda para cada acceso al objeto, esta técnica puede ser poco eficiente cuando se accede a un mismo objeto repetidamente. Por el contrario, si una aplicación tiende a acceder una sola vez a cada objeto, esta técnica puede ser aceptable. La Figura 26.5 muestra el contenido de la tabla de búsqueda, que en ocasiones se denomina tabla de objetos residentes (ROT, Resident Object Table); en el ejemplo, ya se han leído cuatro objetos del almacenamiento secundario. Si ahora queremos acceder al objeto Staff con identidad de objeto OID5 desde el objeto Branch OIDI, una búsqueda en la tabla ROT nos indicaría que el objeto no se encuentra en memoria principal, por lo que sería necesario leer el objeto desde el almacenamiento secundario e introducir su dirección de memoria en la tabla ROT. Por el contrario, si tratamos de acceder al objeto Staff con identidad de objeto OID4 desde el objeto Branch, la búsqueda en la tabla ROT nos indicaría que el objeto ya se encuentra en memoria principal y nos proporcionaría su dirección de memoria. Moss propuso un modelo
B003 163 Main St Glasgow G11 9QX {OID4, OlD5, {OID2, OID3, OlD6
Staff: OlD4 staffNo: fName: IName: position: sex: salary: branch:
Figura 26.5.
SG14 David Ford Supervisor M 18000 OlD1
PropertyForRent:
} }
propertyNo: street: type: rooms: rent: staff: branch:
PG4 6 Lawrence SI Flal
3 350 OlD4 OlD1
PropertyForRent: propertyNo: street: type: rooms: rent: staff: branch:
OlD2
OlD3
PG16 5 Novar Dr Flal
4 450 OlD4 OlD1
Tabla de objetos residentes que hace referencia a cuatro objetos en memoria principal.
784
Sistemas de bases de datos
Referencias a objetos Para ser capaz de transformar el OID de un objeto persistente en un puntero de memoria virtual, se requiere un mecanismo para distinguir entre objetos residentes y no residentes. La mayoría de las técnicas utilizadas son variaciones de dos técnicas fundamentales: marcación de aristas y marcación de nodos (Hoskings y Moss, 1993). Si consideramos la memoria virtual como un grafo dirigido compuesto de objetos, que son los nodos, y de referencias, que son las aristas dirigidas, la marcación de aristas marca todos los punteros objetos con un bit indicador. Si el bit está activado, la referencia es a un puntero de memoria virtual; en caso contrario, sigue apuntando a una OID y será preciso transformarlo cuando el objeto al que hace referencia sea reclamado para cargarlo en el espacio de memoria de la aplicación. La marcación de nodos requiere que todas las referencias a objetos se conviertan inmediatamente en punteros de memoria virtual cuando se carga el objeto en memoria. La primera de las técnicas está basada en software, pero la segunda puede implementarse utilizando tanto software como hardware. En nuestro ejemplo anterior, el sistema sustituye el valor OID4 del objeto Branch OIDl por su dirección en memoria principal cuando se lee el objeto 81aft OID4 en memoria. Esta dirección de memoria proporciona un puntero que conduce a la ubicación de memoria del objeto 81aft identificado mediante OID4. Así, al recorrer la referencia del objeto Branch OIDl al objeto 81aft OID4 no hace falta realizar ninguna búsqueda en la tabla ROT, sino que basta con efectuar una operación de des-referenciación de puntero.
Esquemas basados en hardware Las transformaciones de punteros basadas en hardware utilizan las violaciones de la protección de acceso a memoria virtual para detectar los accesos a objetos no residentes (Lamb et al., 1991). Estos esquemas utilizan el hardware estándar de memoria virtual para provocar la transferencia de datos persistentes de disco a memoria principal. Una vez que se detecta que falta una página y que esa página se carga, se accede a los objetos de dicha página mediante los punteros normales de memoria virtual y no hace falta efectuar ningún tipo adicional de comprobación de si un objeto está residente en memoria. La técnica hardware se ha utilizado en diversos sistemas comerciales y experimentales, incluyendo ObjectStore y Texas (Singhal et al., 1992). La principal ventaja de la técnica basada en hardware es que acceder a los objetos persistentes residentes en memoria es igual de eficiente que acceder a,..losobjetos transitorios, porque la técnica hardware evita el trabajo adicional de comprobar si un objeto está residente en memoria, trabajo que sí que tienen que realizar las técnicas software. Una desventaja de la técnica basada en hardware es que hace que sea mucho más difícil la provisión de distintos tipos de funcionalidad de base de datos, como por ejemplo los bloqueos de granularidad fina, la integridad referencial, los mecanismos de recuperación y las políticas flexibles de gestión de búferes. Además, la técnica hardware limita la cantidad de datos a los que puede accederse durante una transacción, no pudiendo dichos datos superar el tamaño de la memoria virtual. Esta limitación puede suavizarse utilizando algún tipo de mecanismo de recolección de memoria para reclamar el espacio de memoria utilizado, aunque esto añade una mayor carga de procesamiento y una mayor complejidad al sistema.
Clasificación
de las técnicas de transformación
de punteros
Las técnicas de transformación de punteros pueden clasificarse de acuerdo con las tres dimensiones siguientes: (1) Transformación de copia y transformación real. (2) Transformación temprana y tardía. (3) Transformación directa e indirecta.
Transformación
de copia y transformación
real
Al cargar en memoria un objeto que falte, los datos pueden copiarse en la caché de objetos local de la aplicación o puede accederse directamente a los datos dentro de la caché de páginas del gestor de objetos (White, 1994). Como se explica en la Sección 20.6.4, la unidad de transferencia del almacenamiento secundario a la caché es la página, que normalmente contendrá muchos objetos. La transformación de punteros basada en copia puede ser más eficiente, ya que en el peor caso sólo será necesario transformar de nuevo a sus OID los
Capítulo 26 Basesde datos orientadas a objetos: conceptos
785
objetos modificados, mientras que la técnica de transformación real puede necesitar tener que transformar de vuelta una página entera de objetos si uno de los objetos de la página se modifica. Por otro lado, con la técnica de copia, cada objeto debe ser copiado explícitamente en la cache de objeto local, aunque esto permite la reutilización de la página de la caché.
Transformación
temprana y tardía
Moss y Eliot (1990) definen la transformación temprana como la transformación de todas las OID d-e objetos persistentes en todas las páginas de datos usadas por la aplicación antes de que se pueda acceder a ningún objeto. Este enfoque resulta algo extremo, mientras que Kemper y Kossman (1993) proporcionan una definición más relajada, restringiendo la transformación a todas las OID persistentes dentro del objeto al que la aplicación quiera acceder. La técnica de transformación tardía transforma los punteros únicamente a medida que se los descubre o a medida que se accede a ellos. La transformación tardía implica una menor carga de procesamiento cuando se carga un objeto en memoria, pero a cambio requiere que se gestionen dos tipos diferentes de punteros para cada acceso a un objeto: un puntero transformado y otro sin transformar.
Transformación
directa e indirecta
Esta diferenciación sólo tienen sentido cuando sea posible que un puntero transformado haga referencia a un objeto que ya no se encuentre en memoria virtual. Con la transformación directa, el puntero de memoria virtual del objeto referenciado se coloca directamente en el puntero transformado; con la transformación indirecta, el puntero de memoria virtual se coloca en un objeto intermedio, que actúa como contenedor para el objeto real. Así, con la técnica indirecta, los objetos pueden ser eliminados de la caché sin que sea necesario que a los punteros transformados que hacen referencia al objeto se les aplique la transformación inversa. Estas técnicas pueden combinarse para dar ocho posibilidades (por ejemplo, real/temprana/directa, real/tardía/directa o copia/tardía/indirecta).
26.2.2 Acceso a un objeto Otro aspecto importante que puede tener un impacto significativo sobre las prestaciones de un SGBDOO es el modo en que se accede a un objeto en almacenamiento secundario. De nuevo, si examinamos el enfoque adoptado en un SGBD relacional convencional con un modelo de almacenamiento en dos niveles, vemos que los pasos ilustrados en la Figura 26.6 son bastante típicos: •
El SGBD determina la página de almacenamiento secundario que contiene el registro deseado utilizando índices o exploraciones de tablas, según sea apropiado (véase la Sección 21.4). El SGBD lee entonces dicha página del almacenamiento secundario y la copia en su caché.
•
El SGBD transfiere subsiguientemente las partes requeridas del registro desde la caché al espacio de memoria de la aplicación. Puede ser necesario realizar algunas conversiones para transformar los tipos de datos SQL en los tipos de datos requeridos por la aplicación.
•
La aplicación puede a continuación actualizar los campos del registro en su propio espacio de memonao
•
La aplicación transfiere los campos modificados a la caché del SGBD utilizando SQL, lo que de nuevo requiere efectuar conversiones entre tipos de datos.
•
Finalmente, en el momento apropiado, el SGBD escribe la página actualizada de la caché en almacenamiento secundario.
Por contraste, con un modelo de almacenamiento de un único nivel, el SGBDOO utiliza los siguientes pasos para extraer un objeto del almacenamiento secundario, como se ilustra en la Figura 26.7: •
El SGBDOO detennina la página del almacenamiento secundario que contiene el objeto requerido, utilizando su 010 o un índice, según sea apropiado. El SGBDOO lee entonces dicha página del almacenamiento secundario y la copia en la caché de páginas de la aplicación dentro de su espacio de memona.
786
Sistemas de bases de datos
Memoria de la aplicación
3. Acceso al objeto campos Leerrelevantes página 2. 1. Copia de los
Registro I
campos modificados
I
.:
Registro
Registro
I
1
Página Página 4. Copia 5. Guardar de lospágina
Caché del SGBD
Almacenamiento secundario
Figura 26.6.
Pasos para acceder a un registro utilizando un SGBD convencional.
inversa etc. de punteros, Memoria de la aplicación
de puntero , 2. Transform1. eLeer página
Página
4. Transformación 3. Acceso al objeto Objeto
~
5. Guardar página
ión etc.
P";"'8 Almacenamiento secundario
Figura 26.7.
•
Pasos para acceder a un objeto utilizando un SGBDOO .
El SGBDOO puede entonces realizar una serie de conversiones, como por ejemplo • •
transformar las referencias (punteros) entre objetos; añadir determinada información a la estructura de datos del objeto para hacer que sea conforme con la requerida por el lenguaje de programación;
Capítulo 26 Basesde datos orientadas a objetos: conceptos
787
•
• •
modificar las representaciones de los datos que provengan de una plataforma hardware diferente o de un lenguaje de programación distinto . La aplicación puede entonces acceder directamente al objeto y actualizarlo, según sea necesario . Cuando la aplicación desee que los cambios pasen a ser persistentes, o cuando el SGBDOO necesite extraer la página de la caché de páginas, el SGBDOO puede tener que llevar a cabo una serie de conversiones similar a la que hemos indicado anteriormente, antes de copiar de nuevo la página en almacenamiento secundario.
26.3 Persistencia Un SGBD debe proporcionar soporte para el almacenamiento de objetos persistentes, es decir, objetos que sobreviven después de que termine la sesión de usuario o programa de aplicación que los ha creado. Esto contrasta con los objetos transitorios, que sólo existen durante la invocación del programa. Los objetos persistentes se retienen hasta que dejen de ser necesarios, en cuyo momento se los borra. Además de la técnica de lenguaje incrustado que se explica en la Sección 26.1.3, pueden utilizarse los esquemas que vamos a presentar a continuación para proporcionar consistencia en los lenguajes de programación. El lector interesado pueden ver un resumen completo de los esquemas de persistencia en Atkinson y Buneman (1989). Aunque podríamos considerar intuitivamente que la persistencia está limitada al estado de los objetos, la persistencia también puede aplicarse al código (de los objetos) y al estado de ejecución de los programas. Incluir el código en el almacenamiento persistente puede proporcionar una solución más completa y elegante. Sin embargo, sin un entorno de desarrollo completamente integrado, hacer que el código persista conduce a problemas de duplicación, ya que el código estará almacenado en el sistema de archivos. También resulta atractivo hacer que el estado de los programas y de los hilos de ejecución persista pero, a diferencia del código (para el que existe una definición de formato estándar), el estado de ejecución de un programa no puede generalizarse fácilmente. En esta sección, vamos a limitar nuestro análisis a la persistencia de los objetos.
26.3.1
Esquemas de persistencia
En esta sección se van a exami';;ar brevemente tres esquemas para la implementación de la persistencia dentro de un SGBDOO: puntos de comprobación, serialización e intercambio explícito de páginas.
Puntos de comprobación Algunos sistemas implementan la persistencia copiando todo el espacio de direcciones de un programa, o parte del mismo, en almacenamiento secundario. En aquellos casos en que se guarda el espacio de direcciones completo, el programa puede volver a comenzar a partir del punto de control. En otros casos, sólo se salva el contenido del cúmulo de memoria del programa. La técnica de puntos de control tiene dos desventajas principales: normalmente, un punto de control sólo puede ser utilizado por el programa que lo creó; en segundo lugar, un punto de control puede contener una gran cantidad de datos que no sean de ninguna utilidad en subsiguientes ejecuciones.
Serialización Algunos sistemas implementan la persistencia copiando lo que se denomina 'cierre' de una estructura de datos en disco. Según este esquema, la operación de escritura de un valor de datos implicaría normalmente recorrer el grafo de objetos alcanzable a partir de dicho valor y escribir una versión aplanada de esa estructura en el disco. Al leer de nuevo esas estructuras de datos aplanada podemos generar una nueva copia de la estructura de datos original. Este proceso se denomina serialización. La serialización tiene dos problemas inherentes. En primer lugar, no preserva la identidad de los objetos, por lo que si dos estructuras de datos que comparten una subestructura común se serializan por separado, al leer la subestructura ésta ya no estará compartida en las nuevas copias. Además, la serialización no es incremental, por lo que no resulta eficiente guardar pequeños cambios realizados en una estructura de datos de gran tamaño.
788
Sistemas de bases de datos
Intercambio explícito de páginas Algunos esquemas de persistencia requieren que el programador de aplicaciones realice un intercambio explícito de las páginas de objetos entre el cúmulo de memoria de la aplicación y el almacenamiento persistente. Como hemos explicado anteriormente, esto requiere usualmente la conversión de los punteros a objetos, transformándolos desde el esquema basado en disco a un esquema basado en memoria. Con el mecanismo de intercambio explícito de páginas, hay dos métodos comunes para crear/actualizar objetos persistentes: mecanismos basados en la alcanzabilidad y mecanismos basados en la asignación. La persistencia basada en la alcanzabilidad significa que un objeto será persistente si es alcanzable desde otro objeto raíz persistente. Este método tiene algunas ventajas, incluyendo la noción de que el programador no necesita decidir en el instante de crear un objeto si dicho objeto debe ser persistente. En cualquier instante posterior a la creación, un objeto puede llegar a ser persistente añadiéndolo al árbol de alcanzabilidad. Dicho modelo se corresponde bastante bien con lenguajes tales como Smalltalk o Java, que contienen algún tipo de mecanismo de recolección de memoria, que borra automáticamente los objetos cuando dejan de ser accesibles desde los demás objetos. La persistencia basada en la asignación significa que un objeto se hace persistente sólo si se lo declara explícitamente como tal dentro del programa de aplicación. Esto puede hacerse de varias maneras, por ejemplo: • Por clase. Una clase se declara estáticamente como persistente y todas las instancias de la clase serán hechas persistentes en el momento de su creación. Alternativamente, una clase puede ser una subclase de otra clase persistente suministrada por el sistema. Esta es la técnica utilizada en los productos Ontos y Objectivity/DB. •
Mediante una llamada explícita. Un objeto puede especificarse como persistente en el momento de crearlo o, en algunos casos, dinámicamente en tiempo de ejecución. Esta es la técnica utilizada por el producto ObjectStore. Alternativamente, el objeto puede ser añadido dinámicamente a una colección persistente. En ausencia de unos adecuados mecanismos de recolección de memoria, los objetos existirán en el almacenamiento persistente hasta que sean explícitamente borrados por la aplicación. Esto conduce, en potencia, a fugas de espacio de almacenamiento y a la aparición de problemas debidos a la existencia de punteros colorantes. Con cualquiera de estas técnicas de implementación de la persistencia, el programador necesita gestionar dos tipos distintos de punteros a objetos, lo que reduce la fiabilidad y la mantenibilidad del software. Estos problemas pueden evitarse si se integra completamente el mecanismo de persistencia dentro del lenguaje de programación de aplicaciones, lo cual es el enfoque que vamos a explicar a continuación.
26.3.2
Persistencia ortogonal
Un mecanismo alternativo para proporcionar persistencia en un lenguaje de programación es el que se conoce con el nombre de persistencia ortogonal (Atkinson et al., 1983; Cockshott, 1983), que está basada en los siguientes tres principios fundamentales. Independencia
de la persistencia
La persistencia de un objeto de datos es independiente del modo en que el programa manipule dicho objeto de datos y, a la inversa, cada fragmento de programa se expresa independientemente de la persistencia de los datos que manipula. Por ejemplo, debe ser posible invocar una función con parámetros que en ocasiones sean objetos con persistencia a largo plazo y en otras ocasiones sean transitorios. Así, el programador no necesita (de hecho no puede) efectuar ninguna labor de programación para controlar el movimiento de los datos entre el almacenamiento a largo plazo y el almacenamiento a corto plazo. Ortogonalidad
con respecto
a los tipos de datos
Todos los objetos de datos deben poder disponer del rango completo de opciones de persistencia, independientemente de su tipo. No hay ningún caso especial en el que no se permita a un objeto ser de larga duración
Capítulo 26 Bases de datos orientadas a objetos: conceptos
789
o en el que no se le permita ser transitorio. En algunos lenguajes persistentes, la persistencia es una cualidad únicamente atribuible a un subconjunto de los tipos de datos del lenguaje. Este enfoque es el que adoptan, por ejemplo, Pascal/R, Amber, Avalon/C++ y E. El enfoque ortogonal ha sido adoptado por diversos sistemas, incluyendo PS-algol, Napier88, Galileo y GemStone (Connolly, 1997). Persistencia
transitiva
La elección de cómo identificar y proporcionar objetos persistentes en el nivel del lenguaje es independiente de la selección de tipos de datos de dicho lenguaje. La técnica que más ampliamente se utiliza ahora para la identificación está basada en la alcanzabilidad, como se explica en la sección anterior. Este principio fue denominado originalmente 'identificación de persistencia', pero aquí preferimos utilizar el término más sugestivo de 'persistencia transitiva', que es el que usa ODMo.
Ventajas y desventajas de la persistencia ortogonal El tratamiento uniforme de los objetos que se realiza en un sistema basado en el principio de la persistencia ortogonal es más cómodo tanto para el programador como para el sistema: •
no hay ninguna necesidad de definir los datos persistentes en un lenguaje de esquema separado;
•
no se requiere ningún código de aplicación especial para acceder o actualizar los datos persistentes;
•
no hay ningún límite a la complejidad de las estructuras de datos que pueden hacerse persistentes.
En consecuencia, la persistencia ortogonal proporciona las siguientes ventajas: •
una mayor productividad del programador a partir de una semántica más simple;
•
un mantenimiento más fácil: los mecanismos de persistencia están centralizados, dejando que los programadores se concentren en la provisión de la funcionalidad de carácter empresarial.
•
mecanismos de protección coherentes en todo el entorno;
•
soporte para la evolución incremental;
•
integridad referencial automática.
Sin embargo, existe un cierto gasto de recursos en tiempo de procesamiento en aquellos sistemas en los que cada puntero puede estar haciendo referencia a un objeto persistente, ya que el sistema deberá comprobar si es necesario cargar el objeto desde el almacenamiento secundario. Además, aunque la persistencia ortogonal promueve la transparencia, un sistema que tenga soporte para la compartición de datos por parte de procesos concurrentes no puede ser completamente transparente. Aunque los principios de la persistencia ortogonal resultan muy convenientes, muchos SGBDOO no los implementan de modo completo. Hay algunas áreas que requieren una consideración cuidadosa y aquí vamos a analizar brevemente dos de ellas: las consultas y las transacciones. ¿A qué objetos se aplican las consultas? Desde la perspectiva de un SGBD tradicional, las consultas declarativas se aplican a objetos persistentes, es decir, a objetos que están almacenados en la base de datos. Sin embargo, con la persistencia ortogonal debemos tratar los objetos persistentes y los objetos transitorios de la misma manera. Por tanto, las consultas deben poder aplicarse tanto a objetos persistentes como transitorios. ¿Pero cuál es el ámbito para los objetos transitorios? ¿Debemos restringir el ámbito a los objetos transitorios contenidos en la unidad de ejecución del usuario actual o deben incluirse también las unidades de ejecución de otros usuarios concurrentes? En cualquiera de los dos casos, será necesario para mejorar la eficiencia mantener índices tanto sobre los objetos transitorios como sobre los persistentes. Esto puede requerir algún tipo de procesamiento de consultas dentro del proceso cliente, además del procesamiento tradicional de consultas que se efectúa dentro del servidor.
¿ Qué objetos forman parte de la semántica
de una transacción?
Desde la perspectiva de un SGBD tradicional, las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad) de una transacción se aplican a los objetos persistentes (véase la Sección 20.1.1). Por ejemplo,
790
Sistemas de bases de datos
cuando se aborta una transacción, es necesario deshacer las actualizaciones que se hayan aplicado a los objetos existentes. Sin embargo, con la persistencia ortogonal debemos tratar de la misma manera a los objetos persistentes y a los transitorios. Por tanto, ¿debe la semántica de las transacciones aplicarse también a los objetos transitorios? En nuestro ejemplo, cuando deshagamos las actualizaciones a los objetos persistentes, ¿debemos también deshacer los cambios a objetos transitorios que hayan sido realizados dentro del ámbito de la transacción? Si este fuera el caso, el SOBDOO tendría que registrar tanto los cambios realizados en objetos persistentes como los cambios realizados en objetos transitorios. Si se destruye un objeto transitorio dentro de una transacción, ¿cómo volvería a crear el SOBDOO este objeto dentro de la unidad de ejecución del usuario? Son muchos los problemas que es necesario resolver si la semántica de las transacciones se aplica a ambos tipos de objetos. No resulta sorprendente, por tanto, que sólo unos pocos SOBDOO garanticen la coherencia de transacción para los objetos transitorios.
26.4 Cuestiones relativas a los SGBDOO En la Sección 25.2 hemos mencionado tres áreas problemáticas para los SOBD relacionales, que son: •
las transacciones de larga duración;
•
el control de versiones;
• la evolución de los esquemas. En esta sección vamos ver cómo se abordan estas cuestiones en los SOBDOO. También examinaremos posibles arquitecturas para los SOBDOO y analizaremos brevemente el tema de los bancos de pruebas.
26.4.1 Transacciones Como se ha explicado en la Sección 20.1, una transacción es una unidad lógica de trabajo, que debe siempre transformar la base de datos llevándola de un estado coherente a otro. Los tipos de transacciones que habitualmente suelen encontrarse en las aplicaciones empresariales son de corta duración. Por contraste, las transacciones que implican objetos concretos, como los que pueden encontrarse en las aplicaciones de ingeniería y de diseño, pueden continuar durante varias horas o incluso durante varios días. Obviamente, para soportar las transacciones de larga duración necesitamos utilizar protocolos distintos que los empleados para las aplicaciones tradicionales de base de datos, en las que las transacciones son normalmente de muy corta duración. En un SOBDOO, la unidad de control de concurrencia y recuperación es, desde el punto de vista lógico, un objeto, aunque por razones de rendimiento puede utilizarse una granularidad más gruesa. Los protocolos basados en bloqueo son los mecanismos de control de concurrencia más habituales en los SOBDOO para evitar que se produzcan conflictos. Sin embargo, sería totalmente inaceptable para un usuario que hubiera iniciado una transacción de larga duración encontrarse con que la transacción se ha abortado debido a un conflicto de bloqueo y que todo el trabajo se ha perdido. Dos de las soluciones que se han propuesto son: •
Protocolos de control de concurrencia multiversión, de los que hemos hablado en la Sección 20.2.6.
•
Modelos avanzados de transacciones, como las transacciones anidadas, las saga s y las transacciones multinivel, modelos de los que hemos hablado en la Sección 20A.
26.4.2
Versiones
Hay muchas aplicaciones que necesitan acceder al estado anterior de un objeto. Por ejemplo, el desarrollo de un diseño particular es a menudo un proceso experimental e incremental, cuyo ámbito cambia a lo largo del tiempo. Es necesario, por tanto, que las bases de datos que almacenan diseños controlen la evolución de los objetos de diseño y que los cambios realizados en el diseño por las diversas transacciones (véase la pareja Atwood, 1985; Katz et al., 1986; Banerjee et al., 1987a). El proceso de controlar la evolución de los objetos se conoce con el nombre de gestión de versiones. Una versión de un objeto representa un estado identificable de un objeto; una historia de versiones representa la
Capítulo 26 Bases de datos orientadas a objetos: conceptos
791
Configuración
Esquema de objeto
Figura 26.8.
Versiones y configuraciones.
evolución de un objeto. El control de versiones puede permitir gestionar los cambios en las propiedades de los objetos de tal forma que las referencias de los objetos apunten siempre a la versión correcta de cada objeto. La Figura 26.8 ilustra el problema de la gestión de versiones para tres objetos: 0A' 08 Y Oc. Por ejemplo, podemos determinar que el objeto 0A está compuesto por las versiones VI' V2, V3; VIA se deriva de VI y V2A y V28 se derivan de V2. Esta figura muestra también un ejemplo de configuración de los objetos, compuesta por V28 de 0A' V2Ade 08 y VI8 de 0c· Los productos comerciales Ontos, Versant, ObjectStore, Objectivity/DB e !tasca proporcionan algún tipo de mecanismo de control de versiones. !tasca identifica tres tipos de versiones (Kim y Lochovsky, 1989): •
Versiones transitorias. Una versión transitoria se considera inestable y puede actualizarse y borrarse. Puede crearse una nueva versión desprotegiendo una versión ya introducida en una base de datos pública o derivándola de una versión de trabajo o transitoria contenida en una base de datos privada. En este último caso, la-versión transitoria utilizada como base se promociona, considerándola entonces una versión de trabajo. Las versiones transitorias están almacenadas en el espacio de trabajo privado del creador.
•
Versiones de trabajo. Una versión de trabajo se considera estable y no puede actualizarse, pero puede ser borrada por su creador. Se almacena en el espacio de trabajo privado del creador.
•
Versiones publicadas. Una versión publicada se considera estable y no puede actualizarse o borrarse. Se almacena en una base de datos pública protegiendo una versión de trabajo extraída de una base de datos privada.
Estos procesos se ilustran en la Figura 26.9. Debido a la disminución de prestaciones y al incremento en las necesidades de almacenamiento que se derivan del soporte de versiones, !tasca obliga a que la aplicación indique cuáles clases son versionables. Cuando se crea una instancia de una clase versionable, además de crear la primera versión de dicha instancia se crea también un objeto genérico para dicha instancia, objeto que está compuesto por la información de gestión de versiones.
26.4.3
Evolución de los esquemas
El diseño es un proceso incremental y evoluciona con el tiempo. Para dar soporte a este proceso, las aplicaciones requieren una considerable flexibilidad en lo que respecta a definir y modificar dinámicamente el esquema de la base de datos. Por ejemplo, debe ser posible modificar las definiciones de clases, la estructura de herencia y las especificaciones de atributos y métodos sin requerir un reinicio del sistema. Las modificaciones del esquema están estrechamente relacionadas con el concepto de gestión de versiones al que antes hemos aludido. Los problemas que surgen con la evolución de los esquemas son complejos y no todos ellos
792
Sistemas de bases de datos
@ Versión transitoria
®
Versión de trabajo
•
Versión publicada
crear desde cero
Base de datos pública
Espacio de trabajo privado
Figura 26.9.
Tipos de versiones en Itasca.
se han investigado con la suficiente profundidad. Entre los cambios típicos a un esquema podemos citar (Banerjee et al., 1987b): (1) Cambios en las definiciones de las clases: (a)
modificación de los atributos;
(b)
modificación de los métodos.
(2) Cambios en la jerarquía de herencia: (a)
hacer que una clase S sea la superclase de otra clase C;
(b)
eliminar una clase S de la lista de superclases de C;
(c)
modificar el orden de las superc!ases de C.
(3) Cambios en el conjunto de clases, como por ejemplo crear y borrar clases y modificar los nombres de las clases. Los cambios de esquema propuestos no deben dejar el esquema en un estado incoherente. !tasca y GemStone definen una serie de reglas para la coherencia del esquema, denominadas invariantes del esquema, que deben respetarse a medida que se modifiquen los esquemas. Por poner un ejemplo, consideremos el esquema mostrado en la Figura 26.10. En esta figura, los atributos y métodos heredados están representados por un rectángulo. Por ejemplo, en la clase Staff los atributos name y DOS Y el método getAge han sido heredados de Persono Las reglas pueden dividirse en cuatro grupos, con las siguientes responsabilidades: (1) La resolución de los conflictos provocados por la herencia múltiple y por la redefinición de los atributos y métodos de una subclase. 1.1 Regla de precedencia de las subclases sobre las superclases Si se define un atributo/método de una clase con el mismo nombre que otro atributo/método de una superclase, la definición especificada en la subclase tiene precedencia sobre la definición de la superclase. 1.2 Regla de precedencia entre superclases de distinto origen Si varias superclases tienen atributos/métodos con el mismo nombre pero con un origen distinto, la sub clase hereda el atributo/método de la primera superclase. Por ejemplo, considere la subclase SalesStaffClient de la Figura 26.10, que hereda de SalesStaff y de Client. Ambas superclases tienen un atributo telNo, que no se hereda de una superclase común (que en este caso es person). En este caso, la definición del atributo telNo de SalesStaffClient se hereda de la primera superclase, SalesStaff.
1.3 Regla de precedencia entre superclases del mismo origen Si varias superclases tienen atributos/métodos con el mismo nombre y el mismo origen, el atributo/método se hereda una sola vez. Si el dominio del atributo ha sido redefinido en algunas de las
No {PK}
Capítulo 26 Bases de datos orientadas a objetos: conceptos ---........ ...... -
I getAge DOB IName addCommission name getMonthlySalary - fName name getAge L(- {Mandatc
..........
6-
Figura 26.10.
II
793
l
-maxRent commission getAge -SalesStaffClient salary position telNo sex maxRent name sex --IName staffNo c1ientNo {AK} IName{PK} prefType DOB fName PrivateOwner address telNo telNo commission IName DOB fName IName DOB DOB addCommission Client prefType name position salary ownerNo c1ientNo {PK} {PK} Person staffNo {PK} {Optional} Iname I I getAge
getAge
Esquema de ejemplo con herencia tanto simple como múltiple.
superclases, la sub clase heredará el atributo que tenga el dominio más especializado. Si los dominios no pueden comparase, el atributo se heredará de la primera superclase. Por ejemplo, SalesStaffClient hereda name y DOB tanto de SalesStaff como de Client; sin embargo, puesto que estos atributos están a su vez heredados de Person, SalesStaffClient sólo los hereda una vez.
794
Sistemas de bases de datos
(2) Propagación de las modificaciones a las subclases. 2.1 Regla de propagación de las modificaciones Las sub clases heredan siempre las modificaciones de los atributos/métodos de una clase, excepto aquellas subclases en las que el propio atributo/método haya sido redefinido. Por ejemplo, si borráramos el método getAge de Person, este cambio se reflejaría en todas las subclases del esquema. Observe que no podemos borrar el método getAge directamente de una subclase, ya que está definido en la superclase Persono Por poner otro ejemplo, si borráramos el método getMonthSalary de Staff, este cambio también se propagaría a Manager, pero no afectaría a SalesStaff ya que el método ha sido redefinido en esta subclase. Si borráramos el atributo telNo de SalesStaff, esta versión del atributo telNo también se borraría de SalesStaffClient, pero SalesStaffClient heredaría telNo de Client (véase la regla 1.2 anterior). 2.2 Regla para la propagación de modificaciones en caso de conflictos La introducción de un nuevo atributo/método o la modificación del nombre de un atributo/método se propaga únicamente a aquellas subclases para las que no se pueda producir como resultado un conflicto de nombres. 2.3 Regla para la modificación de dominios El dominio de un atributo sólo puede modificarse mediante generalización. El dominio de un atributo heredado no puede hacerse más general que el dominio del atributo general en la superclase. (3) Adición y borrado de relaciones de herencia entre clases y creación y eliminación de clases. 3.1 Regla para la inserción de superclases Si se añade una clase C a la lista de superclases de una clase cs, C pasa a ser la última de las superclases de Cs. Cualquier conflicto de herencia resultante se resuelve mediante las reglas 1.1, 1.2 Y 1.3. 3.2 Regla para la eliminación de superclases Si una clase C tiene una única superclase Cs y Cs se borra de la lista de superclases de C, entonces C pasará a ser una subclase directa.ge cada superclase directa de Cs. La ordenación de las nuevas superclases de C será la misma que la de las superclases de Cs. Por ejemplo, si quisiéramos borrar la superclase Staff, las subclases Manager y SalesStaff pasarían a ser subclases directas de Persono 3.3 Regla para insertar una clase en un esquema Si C no tuviera ninguna superclase especificada, esquema).
C
será subclase de
OBJECT
(la raíz de todo el
3.4 Regla para eliminar una clase de un esquema Para borrar una clase C de un esquema, se aplica sucesivamente la regla 3.2 para eliminar C de la lista de superclases de todas sus subclases. OBJECT no puede borrarse. (4) Gestión de objetos compuestos. El cuarto grupo se relaciona con aquellos modelos de datos que soportan el concepto de objetos compuestos. Este grupo tiene una regla, que está basada en diferentes tipos de objetos compuestos. Vamos a omitir aquí los detalles de esta regla, pudiendo el lector interesado consultar los artículos publicados por Banerjee et al. (1987b) y Kim et al. (1989).
26.4.4 Arquitectura En esta sección vamos a hablar de dos cuestiones relativas a la arquitectura: cuál es la mejor forma de aplicar la arquitectura cliente-servidor a los entorno s SGBDOO y los temas relativos al almacenamiento de métodos.
Cliente-servidor Muchos SGBDOO comerciales se basan en la arquitectura cliente-servidor para proporcionar datos a los usuarios, aplicaciones y herramientas en un entorno distribuido (véase la Sección 2.6). Sin embargo, no todos los
Capítulo 26 Basesde datos orientadas a objetos: conceptos
795
¡::=: r::::: SERVIDOR Páginas obietos objetos Servidor de Objetos Direcciones objetos Solicitudes SQL Servidor de de objetos -1 -, Almacén Almacén -1 Gestor de objeto
Tablas
1 .•
(e)
Figura 26.11.
Almacén de objetos
Arquitecturas
cliente-servidor: (a) servidor de objetos; (b) servidor de páginas; (e) servidor de bases de datos.
sistemas utilizan el mismo modelo cliente-servidor. Podemos distinguir tres arquitecturas básicas para un SGBD cliente-servidor, arquitecturas que difieren en la funcionalidad que se asigna a cada componente (Loomis, 1992), como se muestra en la Figura 26.11 : •
Servidor de objetos. Esta técnica trata de distribuir el procesamiento entre los dos componentes. Normalmente, el proceso servidor es responsable de gestionar el almacenamiento, los bloqueos, las confirmaciones de envío en almacenamiento secundario, las tareas de registro y recuperación, los mecanismos de seguridad e integridad, la optimización de consultas y la ejecución de procedimientos almacenados. El cliente-es responsable de la gestión de transacciones y de establecer la interfaz con el lenguaje de programación. Esta es la mejor arquitectura para el procesamiento cooperativo entre objetos en un entorno abierto y distribuido.
•
Servidor de páginas. Con este enfoque, la mayor parte del procesamiento de la base de datos se realiza en el cliente. El servidor es responsable del almacenamiento secundario y de proporcionar las páginas a solicitud del cliente.
•
Servidor de base de datos. Con este enfoque, la mayor parte del procesamiento de base de datos se realiza en el servidor. El cliente se limita a pasar consultas al servidor, recibir los resultados y devolvérselos a la aplicación. Este es el enfoque adoptado por muchos SGBDR.
En cada caso, el servidor reside en la misma máquina que la base de datos fisica, el cliente puede residir en la misma máquina o en otra distinta. Si el cliente necesita acceder a bases de datos distribuidas entre múltiples máquinas, se comunicará con un servidor en cada una de las máquinas. También puede haber varios clientes comunicándose con un mismo servidor, como por ejemplo un cliente por cada usuario o aplicación.
Almacenamiento
y ejecución de métodos
Hay dos técnicas para gestionar los métodos: almacenar los métodos en archivos externos, como se muestra en la Figura 26.12(a), almacenar los métodos en la base de datos, como se muestra en la Figura 26.12(b). La primera técnica es similar a las bibliotecas de funciones o interface s de programación de aplicaciones (API, Application Programming Interface) que podemos encontrar en los SGBD tradicionales, en los que un programa de aplicación interactúa con el SGBD utilizando las funciones suministradas por el fabricante del SGBD. Con la segunda de las técnicas, los métodos se almacenan en la base de datos y se enlazan dinámicamente con la aplicación en tiempo de ejecución. Esta segunda técnica presenta varias ventajas:
796
Sistemas de bases de datos Almacén de objetos Solicitudes Gestor de objetos
SERVIDOR Servidor de objetos
Objetos
Métodos en archivos (se enlazan en tiempo de compilación y de montaje) (a) Almacén de objetos Solicitudes Gestor de objetos
SERVIDOR Servidor de objetos
Objetos Los métodos se enlazan dinámica mente con la aplicación (b)
Estrategias para la gestión de métodos: (a) almacenamiento de métodos fuera de la base de datos; (b) almacenamiento de métodos en la base de datos.
Figura 26.12.
•
Elimina el código redundante. En lugar de colocar una copia de un método que accede a un elemento de datos en cada programa que tenga que manejar esos datos, el método se almacena una única vez en la base de datos.
•
Simplifica las modificaciones. La modificación de un método requiere cambiarlo en un único lugar. Todos los programas utilizarán automáticamente el método actualizado. Dependiendo de la naturaleza del cambio, puede que no sea necesario reconstruir, probar y redistribuir los programas. Los métodos son más seguros. Almacenar los métodos en la base de datos les proporciona todos los beneficios de seguridad que el SGBDOe> garantiza de manera automática. Los métodos pueden compartirse concurrentemente. De nuevo, el acceso concurrente es proporcionado de manera automática por el SGBDOO. Esto impide también que múltiples usuarios hagan cambios diferentes en un mismo método simultáneamente.
• •
•
Mayor integridad. Almacenar los métodos en la base de datos implica que el SGBDOO puede imponer las restricciones de integridad de manera coherente en todas las aplicaciones.
Los productos GemStone e !tasca permiten almacenar y activar los métodos desde dentro de la base de datos.
26.4.5
Bancos de pruebas
A lo largo de los años, se han desarrollado diversos bancos de pruebas de bases de datos como herramienta para comparar las prestaciones de los SGBD, y dichos bancos de pruebas se mencionan frecuentemente en la literatura académica, técnica y comercial. Antes de examinar dos bancos de pruebas orientados a objeto, vamos a comentar primero algunos conceptos básicos. Proporcionar una descripción completa de estos bancos de pruebas caería fuera del alcance de este libro, pero el lector interesado puede encontrar los detalles completos en Gray (1993).
Banco de pruebas Wisconsin Quizá el primero de los bancos de pruebas para sistemas SGBD fuera el banco de pruebas Wisconsin, desarrollado para permitir la comparación de determinadas características concretas de los SGBD (Bitton et al., 1983). Está compuesto por una serie de tests en modo monousuario que cubren:
Capítulo 26 Basesde datos orientadas a objetos: conceptos
797
•
actualizaciones y borrado que implican tanto atributos clave como atributos no clave;
•
proyecciones que implican diferentes grados de duplicación de los atributos y diferentes selecciones, con diferentes selectividades sobre atributos indexados, no indexados y agrupados;
•
combinaciones con diferentes selectividades;
•
funciones de agregación.
El banco de pruebas Wisconsin original estaba basado en tres relaciones: una relación denominada Onektup con 1000 tuplas y otras dos llamadas Tenktup 1/Tenktup2 con 10000 tuplas cada una. Este banco de pruebas resulto útil, con carácter general, aunque no tiene en cuenta las distribuciones de atributos altamente sesgadas y las consultas de combinación que se emplean son relativamente simplistas. Debido a la importancia que tiene poder disponer de información precisa sobre los bancos de pruebas, un consorcio de fabricantes formó el Transaction Processing Council (TPC) en 1988 para formular una serie de conjuntos de pruebas basados en transacciones con los que medir los entorno s de base de datos/TP. Cada una de las pruebas tiene una especificación impresa y está acompañada por un código fuente ANSI C, código que sirve para rellenar una base de datos con información de acuerdo con una estructura estandarizada predeterminada.
Bancos de pruebas TPC-A y TPC-B TPC-A y TPC-B están basados en una transacción bancaria simple. TCP-A mide el rendimiento para procesamiento de transacciones en línea (OLTP), cubriendo el tiempo consumido por el servidor de base de datos, por la red y por los demás componentes del sistema, pero excluyendo la interacción con el usuario. TPC-B sólo mide las prestaciones del servidor de base de datos. Una transacción simula la transferencia de dinero hacia o desde una cuenta mediante las siguientes acciones: •
actualización del registro de la cuenta (la relación
Account
tiene 100.000 tuplas); tiene 10 tuplas);
•
actualización del registro del cajero automático (la relación
•
actualización del registw de la sucursal (la relación
Branch
tiene una tupla);
• •
actualización de un registro de historial (la relación devolución del saldo de la cuenta.
History
tiene 2.592.000 tuplas);
Teller
Las cardinalidades indicadas son para una configuración mínima, pero puede escalarse la base de datos en múltiples de dicha configuración. Puesto que estas acciones se realizan sobre tuplas únicas, hay muchos aspectos importantes del sistema que no se miden (por ejemplo, la planificación de consultas y la ejecución de combinaciones).
Banco de pruebas TPC-C TPC-A y TPC-B se consideran obsoletos y están siendo sustituidos por TPC-C, que está basado en una aplicación de introducción de pedidos. El esquema de base de datos subyacente y el rango de consultas son más complejos que los de TPC-A, proporcionando así una prueba mucho más exhaustiva del rendimiento de un SGBD. Hay definidas cinco transacciones que cubren la introducción de un nuevo pedido, un pago, una consulta sobre el estado de un pedido, un suministro del pedido y una consulta de la cantidad existente en el almacén.
Otros bancos de pruebas La organización Transaction Processing Council ha definido diversos otros bancos de pruebas, como: •
TPC-H, para entornas ad hoc, de ayuda a la toma de decisiones en los que los usuarios no conocen qué consultas van a ejecutarse;
•
TPC-R, para generación de informes empresariales dentro de entornas de ayuda para la toma de decisiones, en los que los usuarios ejecutan un conjunto estándar de consultas sobre un sistema de base de datos;
798
Sistemas de bases de datos
•
TPC- W, un banco de pruebas web transaccional para comercio electrónico, en el que la carga de trabajo tiene lugar en un entorno controlado de comercio electrónico a través de Internet que simula las actividades de un servidor web transaccional de carácter comercial.
Transaction (www.tpc.org).
Processing
Council publica
los resultados
de los bancos de pruebas en su sitio web
Banco de pruebas 001 El banco de pruebas 001 (Object Operations Version 1) pretende ser una medida genérica del rendimiento de los SGBDOO (Cattell y Skeen, 1992). Fue diseñado para reproducir una serie de operaciones comunes en las aplicaciones avanzadas de ingeniería que hemos repasado en la Sección 25.1, como por ejemplo localizar todas las piezas conectadas a un determinado componente aleatoriamente seleccionado, determinar todas las piezas conectadas a una de dichas piezas, etc., hasta una profundidad de siete niveles. El banco de pruebas implica: •
la extracción aleatoria de 1000 piezas basándose en la clave principal (el número de pieza);
•
la inserción aleatoria de 100 nuevas piezas y 300 conexiones seleccionadas aleatoriamente nuevas piezas, confirmando todas las operaciones como una única transacción;
•
con hasta siete niveles de profundidad a partir de un componente, extrayendo hasta 3280 piezas.
con estas
En 1989 y 1990, el banco de pruebas 001 fue ejecutado sobre los SGBDOO GemStone, Ontos, ObjectStore, Objectivity/DB y Versant, así como sobre los SGBDR INGRES y Sybase. Los resultados mostraban una mejora promedio de 30 veces para los SGBDOO con respecto a los SGBDR. La crítica principal que se le hace a este banco de pruebas es que los objetos están conectados de tal manera que se impide su agrupación (el cierre transitivo para cualquier objeto es toda la base de datos). Debido a ello, los sistemas que disponen de un buen acceso navegacional a expensas de las demás operaciones obtienen una buena puntuación de acuerdo con este banco de pruebas.
Banco de pruebas 007 En 1193, la Universidad de Wisconsin publicó el banco de pruebas 007, basado en un conjunto de pruebas más exhaustivo y una base de datos más compleja. 007 fue diseñado para efectuar comparaciones detalladas de productos SGBDOO (Carey el al., 1993). Simula un entorno CAD/CAM y prueba el rendimiento del sistema en el área de la navegación entre objetos para datos en caché, para datos residentes en discos y para recorridos tanto densos como dispersos. También prueba las actualizaciones indexadas y no indexadas de objetos, las actualizaciones repetidas y la creación y borrado de objetos. El esquema de base de datos de 007 está basado en una jerarquía compleja de piezas, en la que cada pieza tiene una documentación asociadas y los módulos (objetos situados en el nivel superior de lajerarquía) tienen un manual. Las pruebas están divididas en dos grupos. El primero de los grupos está diseñado para probar: •
la velocidad de recorrido (una prueba simple de rendimiento navegacional similar a las medidas realizadas en 001).
•
recorrido con actualizaciones (similar a la primera prueba, pero con actualizaciones de cada una de las piezas atómicas visitadas, de una de las piezas de cada pieza compuesta y de todas las piezas de una pieza compuesta cuatro veces);
•
operaciones con la documentación.
El segundo grupo contiene consultas declarativas que cubren los casos de correspondencia exacta, de búsquedas por rango, de búsqueda de rutas, de exploración, una simulación de la utilidad make y de combinación. Para facilitar su uso, hay disponibles diversas implementaciones de ejemplo a través de ftp anónimo en el sitio ftp.cs.wisc.edu.
Capítulo 26 Basesde datos orientadas a objetos: conceptos
799
26.5 Ventajas y desventajas de los SGBDOO Los SGBDOO pueden proporcionar soluciones apropiadas para muchos tipos de aplicaciones avanzadas de base de datos. Sin embargo, también hay desventajas. En esta sección vamos a examinar las ventajas y desventajas de este tipo de sistemas.
26.5.1 Ventajas Las ventajas de los SGBDOO se enumeran en la Tabla 26.2. Tabla 26.2.
Ventajas de los SGBDOO.
Capacidades más ricas de modelado Ampliabilidad Eliminación de la desadaptación de impedancias Lenguaje de consulta más expresivo Soporte para la evolución del esquema Soporte para transacciones
de larga duración
Adecuación a las aplicaciones avanzadas de base de datos Mayores prestaciones
Capacidades más ricas de modelado El modelado de datos orientado a objetos permite modelar el 'mundo real' de manera más fiel. El objeto, que encapsula tanto un estado como un comportamiento, es una representación más natural y realista de los objetos de un mundo real. Un objeto puede almacenar todas las relaciones que tenga con otros objetos, incluyendo relaciones muchos a much..9s, y los objetos pueden agruparse para formar objetos complejos con los que los modelos de datos tradicionales no pueden tratar fácilmente.
Ampliabilidad Los SGBDOO permiten construir nuevos tipos de datos a partir de los tipos existentes. La capacidad de agrupar las propiedades comunes de diversas clases e incluidas en una superclase, con lo que pueden ser compartidas con las subclases, pueden reducir enormemente la redundancia dentro de los sistemas y, como se ha indicado al principio de este capítulo, se considera una de las principales ventajas de la orientación a objetos. El mecanismo de anulación es una característica importante de ]a herencia, ya que permite gestionar con sencillez los casos especiales, con un mínimo impacto sobre el resto del sistema. Además, la reusabilidad de las clases promueve un desarrollo más rápido de un mantenimiento más fácil de ]a base de datos y de sus aplicacIOnes. Merece la pena mencionar que si los dominios estuvieran adecuadamente implementados, los SGBDR serían capaces de proporcionar la misma funcionalidad que los SGBDOO dicen tener. Un dominio puede contemplarse como un tipo de datos de complejidad arbitraria con valores esca]ares que están encapsulados y con los que sólo puede operarse mediante una serie de funciones predefinidas. Por tanto, un atributo definido sobre un dominio en el modelo relacional puede contener cualquier cosa, como por ejemplo dibujos, documentos, imágenes, matrices, etc. (Date, 2000). A este respecto, se podría argumentar que los dominios y las clases de objetos son una misma cosa. Volveremos sobre este punto en la Sección 28.2.2.
Eliminación de la desadaptación
de impedancias
Al disponer de una única interfaz de lenguaje entre el lenguaje de manipulación de datos (DML) y e] ]enguaje de programación, se resuelve la desadaptación de impedancias. Esto elimina muchas de las ineficiencias que tienen lugar a la hora de establecer la correspondencia entre un lenguaje declarativo como SQL y un len-
800
Sistemas de bases de datos
guaje imperativo como C. También vemos que la mayoría de los SGBDOO proporcionan un DML que es computacionalmente completo si lo comparamos con SQL, el lenguaje estándar de los SGBDR.
Lenguaje de consulta más expresivo El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en un SGBDOO. Esto contrasta con el acceso asociativo propio de SQL (es decir, instrucciones declarativas con selecciones basadas en uno o más predicados). El acceso navegacional es más adecuado para gestionar operaciones tales como los despieces, las consultas recursivas, etc. Sin embargo, algunos autores argumentan que la mayoría de los SGBDOO están ligados a un lenguaje de programación concreto que, aunque resulta cómodo para los programadores, no es fácilmente utilizable por los usuarios finales, que lo que piden es un lenguaje declarativo. Teniendo en cuenta esta necesidad, el estándar ODMG especifica un lenguaje de consulta declarativo basado en una variante de SQL orientada a objetos (véase la Sección 27.2.4).
Soporte para la evolución del esquema El estrecho acoplamiento entre los datos y las aplicaciones en un SGBDOO hace que la evolución del esquema resulte más factible. Los mecanismos de generalizacíón y de herencia permiten estructurar mejor el esquema, hacer que sea más intuitivo y capturar mucha más información semántica de la aplicación.
Soporte para transacciones
de larga duración
Los SGBD relacionales actuales imponen la serializabilidad sobre las transacciones concurrentes para mantener la coherencia de la base de datos (véase la Sección 20.2.2). Algunos SGBDOO utilizan un protocolo distinto para gestionar los tipos de transacciones de larga duración que resultan comunes en muchas aplicaciones avanzadas de bases de datos. Esta ventaja no resulta demasiado clara: como ya hemos mencionado en la Sección 25.2, no hay ninguna razón estructural por la que dichas transacciones no pudieran ser proporcionadas por un SGBDR.
Adecuación
a las aplicaciones avanzadas de base de datos
Como hemos explicado en la Sección 25.1, hay muchas áreas en las que los SGBD tradicionales no han tenido excesivo éxito, como por ejemplo el diseño asistido por computadora (CAD), la ingeniería del software asistida por computadora (CASE), los sistemas de información de oficina (OIS) y los sistemas multimedia. Las capacidades de modelado más ricas de los SGBDOO han hecho que estos sistemas sí resulten adecuados para dichas aplicaciones.
Mayores prestaciones Como hemos mencionado en la Sección 26.4.5, a lo largo del tiempo se han propuesto diversos bancos de pruebas. Los SGBDOO proporcionan mejoras significativas de rendimiento con respecto a los SGBD relacionales. Por ejemplo, en 1989 y 1990, se ejecutó el bando de pruebas 001 sobre los SGBDOO GemStone, Ontos, ObjectStore, Objectivity/DB y Versant y sobre los SGBDR INGRES y Sybase. Los resultados mostraron una mejora promedio de rendimiento de 30 veces para los SGDOO con respecto a los SGBDR, aunque algunos autores argumentan que esta diferencia de rendimiento puede atribuirse a diferencias dependientes de la arquitectura, más que diferencias dependientes del modelo. Sin embargo, el enlace dinámico y los mecanismos de recolección de memoria en los SGBDOO pueden comprometer este incremento de las prestaciones. También se ha argumentado que estos bancos de pruebas están dirigidos a las aplicaciones de ingeniería, que son más adecuadas para los sistemas orientados a objetos. Por contraste, se ha sugerido que los SGBDR tienen un rendimiento mejor que los SGBDOO en las aplicaciones tradicionales de base de datos, como por ejemplo en el procesamiento de transacciones en línea (OLTP).
26.5.2
Desventajas
Las desventajas de los SGBDOO se enumeran en la Tabla 26.3.
Capítulo 26 Basesde datos orientadas a objetos: conceptos Tabla 26.3.
801
Desventajas de los SGBDOO.
Carencia de un modelo de datos universal Carencia de experiencia Carencia de estándares Competencia La optimización de consultas compromete la encapsulación El bloqueo en el nivel de objeto puede degradar el rendimiento Complejidad Carencia de soporte para las vistas Carencia de soporte para la seguridad
Carencia de un modelo de datos universal Como hemos explicado en la Sección 26.1, no hay ningún modelo de datos universalmente aceptado para los SGBDOO, y la mayoría de los modelos carecen de una base teórica. Esta desventaja se considera bastante significativa y la situación es comparable a la de los sistemas pre-relacionales. Sin embargo, el ODMG propuso un modelo de objetos que ha llegado a convertirse en el estándar deJacto para los SGBDOO. Hablaremos del modelo de objetos del SGBDOO en la Sección 27.2.
Carencia de experiencia Por comparación con los SGBDR, la utilización de los SGBDOO es todavía relativamente limitada. Esto significa que no tenemos todavía el nivel de experiencia del que sí disponemos con los sistemas tradicionales. Los SGBDOO están todavía dirigidos, en buena medida, a los programadores, más que a los usuarios finales inexpertos. Además, la curva de aprendizaje para el diseño y gestión de sistemas SGBDOO puede ser muy abrupta, dando como resultado una cierta resistencia a la aceptación de la tecnología. Mientras que los SGBDOO estén limitados a pequeños mercados nicho, este problema continuará existiendo.
Carencia de estándares Hay una carencia general de estándares para los SGBDOO. Ya hemos mencionado que no existe ningún modelo de datos universalmente aceptado. De forma similar, tampoco hay un lenguaje de consulta orientado a objetos estándar. De nuevo, el ODMG ha especificado el lenguaje OQL (Object Query Language, lenguaje de consulta de objetos) que se ha convertido en un estándar de Jacto (véase la Sección 27.2.4). Esta carencia de estándares puede ser el factor que más retarde la adopción de los SGBDOO.
Competencia Quizá uno de los problemas más significativos a los que se enfrentan los fabricantes de sistemas SGBDOO es la competencia planteada por los SGBDR y por los productos SGBDOR que han aparecido recientemente. Estos productos tienen una base de usuarios establecidas, existiendo una experiencia de uso considerable. SQL es un estándar aprobado y ODBC es un estándar de Jacto; además, el modelo de datos relacional tiene una sólida base teórica y los productos relacionales disponen de muchas herramientas de soporte que sirven de ayuda tanto para los usuarios finales como para los desarrolladores.
La optimización
de consultas compromete
la encapsulación
La optimización de consultas requiere una comprensión de la implementación subyacente, para poder acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el concepto de encapsulación. El Manifiesto de los SGBDOO, del que hemos hablado en la Sección 26.1.4, sugiere que este aspecto puede ser aceptable, aunque ya dijimos allí que esta apreciación resulta cuestionable.
802
Sistemas de bases de datos
El bloqueo en el nivel de objeto puede degradar el rendimiento Muchos SGBDOO utilizan los bloqueos como base para un protocolo de control de concurrencia. Sin embargo, si se aplican los bloqueos en el nivel de objeto, el bloqueo de la jerarquía de herencia puede resultar problemático, además de degradar el rendimiento. Ya hemos visto cómo bloquear jerarquías en la Sección 20.2.8.
Complejidad La mayor funcionalidad proporcionada por un SGBDOO, como por ejemplo la ilusión de que existe un modelo de almacenamiento de un único nivel, la transformación de punteros, las transacciones de larga duración, la gestión de versiones y la evolución del esquema, es inherentemente más compleja que la de los SGBD tradicionales. En general, esta complejidad conduce a productos que son más caros y más dificiles de utilizar.
Carencia de soporte para las vistas Actualmente, la mayoría de los SGBDOO no proporcionan un mecanismo de vistas, mecanismo que, como hemos visto anteriormente, proporciona numerosas ventajas, como la independencia con respecto a los datos, la seguridad, la menor complejidad y la posibilidad de personalización (véase la Sección 6.4).
Carencia de soporte para la seguridad Actualmente, los SGBDOO no proporcionan mecanismos de seguridad adecuados. La mayoría de los mecanismos tienen una granularidad excesivamente gruesa y el usuario no puede conceder derechos de acceso sobre objetos o clases individuales. Para que los SGBDOO puedan desembarcar con éxito en el campo empresarial, es necesario que esta deficiencia sea corregida.
Resumen del capítulo •
Un SGBDOO es un gestor de una base de datos orientada a objetos. Una base de datos orientada a objetos es un repositorio persistente y compartido de objetos definidos en un modelo de datos orientado a objetos. Un modelo de datos orientado a objetos es un modelo de datos que captura la semántica de los objetos soportados en la programación orientada a objetos. No hay ningún modelo de datos orientado a objetos universalmente aceptado.
•
El modelo de datos funcional (FDM) comparte ciertas ideas con la técnica de orientación a objetos, incluyendo la de identidad de los objetos, la herencia, la sobrecarga y el acceso navegacional. En el FDM, cualquier tarea de extracción de datos puede considerarse como el proceso de evaluar y devolver el resultado de una función con cero, uno o más argumentos. En el FDM, las principales primitivas de modelado son las entidades (bien tipos de entidad o tipos de entidad imprimibles) y las relaciones funcionales.
•
Un lenguaje de programación persistente es un lenguaje que proporciona a sus usuarios la capacidad de preservar los datos (transparentemente) entre sucesivas ejecuciones de un programa. Los datos en un lenguaje de programación persistente son independientes de los programas y pueden existir después de que ha terminado la ejecución del programa e incluso después de que se ha completado el ciclo de vida del código que lo ha creado. Sin embargo, dichos lenguajes no pretendían originalmente proporcionar una funcionalidad completa de base de datos ni tampoco mecanismos de acceso a los datos desde múltiples lenguaJes.
•
El Manifiesto de los sistemas de bases de datos orientados a objetos propuso las siguientes características obligatorias de orientación a objetos: objetos complejos, identidad de los objetos, encapsulación, tipos! clases, herencia, enlace dinámico, un lenguaje DML computacionalmente complejo y tipos de datos ampliables.
•
Entre las distintas técnicas para el desarrollo de un SGBDOO se incluyen: ampliar un lenguaje de programación orientado a objetos existente con capacidades de base de datos, proporcionar bibliotecas SGBDOO ampliables, incrustar estructuras de un lenguaje de base de datos orientado a objetos en un lenguaje host
Capítulo 26 Basesde datos orientadas a objetos: conceptos
803
convencional; ampliar un lenguaje de base de datos existente con capacidades de orientación a objetos; y desarrollar un lenguaje de datos/modelo de datos novedoso para bases de datos. •
Quizás dos de las preocupaciones más importantes desde el punto de vista del programador son las prestaciones y la facilidad de uso. Ambas características pueden mejorarse si se consigue una integración más fluida entre el lenguaje de programación y el SGBD que la que proporcionan los sistemas de bases de datos tradicionales. Los SGBD convencionales tienen un modelo de almacenamiento en dos niveles: el modelo de almacenamiento de la aplicación en la memoria principal o virtual y el modelo de almacenamiento de la base de datos en disco. Por contraste, un SGBDOO trata de proporcionar la ilusión de que hay ún modelo de almacenamiento de un único nivel, utilizando una representación similar tanto en memoria como en la base de datos almacenada en disco.
•
Hay dos tipos de identificador OID: identificadores OID lógicos que son independientes de la ubicación física del objeto en disco, e identificadores OID físicos que codifican la ubicación. En el primer casos, se requiere un nivel de indirección para buscar la dirección física del objeto en disco. En ambos casos, sin embargo, los OID difieren en tamaño de los punteros de memoria estándar, que sólo necesitan ser lo suficientemente grandes como para poder direccionar toda la memoria virtual.
•
Para conseguir las prestaciones deseadas, un SGBDOO debe ser capaz de convertir los OID a punteros de memoria y viceversa. Esta técnica de conversión se denomina transformación de punteros y las técnicas utilizadas para implementarla son muy diversas, yendo desde comprobaciones de existencia de los objetos basadas en software a esquemas de carga de páginas utilizados por el hardware subyacente.
•
Los esquemas de persistencia incluyen los puntos de control, la serialización, el intercambio explícito de páginas y la persistencia ortogonal. La persistencia ortogonal está basada en tres principios fundamentales: independencia de la persistencia, ortogonalidad con respecto a los tipos de datos y persistencia transitiva.
•
Entre las ventajas de los SGBDOO podemos citar: capacidades más ricas de modelado, ampliabilidad, eliminación de la desadaptación de impedancias, un lenguaje de consulta más expresivo, soporte para la evolución del esquema, soporte para las transacciones de larga duración, adecuación a las aplicaciones avanzadas de base de datos y un mejor rendimiento. Entre sus desventajas podemos mencionar la falta de un modelo de datos universal,-ta falta de experiencia, carencia de estándares, el hecho de que la optimización de consultas comprometa la encapsulación, el hecho de que el bloqueo en el nivel de objetos degrade el rendimiento, la complejidad y la falta de soporte para las vistas y para los mecanismos de seguridad.
Cuestiones de repaso 26.1.
Comente las similitudes y diferencias entre los diversos modelos de datos orientados a objetos.
26.2.
Describa el principal componente de modelado en el modelo de datos funcional.
26.3.
¿Qué es un lenguaje de programación persistente y en qué se diferencia de un SGBDOO?
26.4.
Explique la diferencia entre el modelo de almacenamiento en dos niveles utilizado por los SGBD convencionales y el modelo de almacenamiento de un único nivel utilizado por los SGBDOO.
26.5.
¿Cómo afecta al acceso a datos este modelo de almacenamiento
26.6.
Describa las estrategias principales que pueden utilizarse para crear objetos persistentes.
26.7.
¿Qué es la transformación de punteros.
26.8.
Describa los tipos de protocolos de transacciones que pueden resultar útiles en las aplicaciones de diseño.
26.9.
Explique por qué los mecanismos de gestión de versiones pueden resultar muy útiles para algunas aplicaClOnes.
en un único nivel?
de punteros? Describa las diferentes técnicas existentes de transformación
26.10. Explique por qué los mecanismos de control del esquema pueden resultar muy útiles para algunas aplicaClOnes.
804
Sistemas de bases de datos
26.11. Describa las diferentes arquitecturas para un SGBDOO. 26.12. Enumere las ventajas y desventajas de los SGBDOO.
Ejercicios 26.13. El Director Gerente de DreamHome nos pide que investiguemos y preparemos un informe sobre la aplicabilidad de un SGBDOO a la organización. El informe debe comparar la tecnología de los SGBDR con la de los SGBDOO y debe enumerar las ventajas y desventajas de implementar un SGBDOO en la organización, así como los problemas potenciales previstos. Finalmente, el informe debe contener un conjunto de conclusiones plenamente justificado sobre la aplicabilidad de un SGBDOO al caso de DreamHome. 26.14. Para el esquema relacional Hotel descrito en los Ejercicios del Capítulo 3, sugiera diversos métodos que pudieran ser aplicables al sistema. Construya un esquema orientado a objetos para el sistema. 26.15. Realice un diseño de base de datos orientado a objetos para el caso de estudio de DreamHome documentado en el Apéndice A. Indique las suposiciones necesarias en las que ha basado su diseño. 26.16. Realice un diseño de base de datos orientado a objetos para el caso de estudio de University Accommodation Office presentado en el Apéndice B.l. Indique las suposiciones necesarias en las que ha basado su diseño. 26.17. Realice un diseño de base de datos orientado a objetos para el caso de estudio de EasyDrive School 01 Motoring presentado en el Apéndice B.2. Indique las suposiciones necesarias en las que ha basado su diseño. 26.18. Realice un diseño de base de datos orientado a objetos para el caso de estudio de Wellmeadows Hospital presentado en el Apéndice B.3. Indique las suposiciones necesarias en las que ha basado su diseño. 26.19. Repita los Ejercicios 26.14 a 26.18, pero genere un esquema utilizando el modelo de datos funcional. Ilustre con un diagrama cada esquema. 26.20. Utilizando las reglas de coherencia de esquemas proporcionadas en la Sección 26.4.3 y el esquema de ejemplo dado en la Figura 26.10, considere cada una de las siguientes modificaciones e indique cuál sería el efecto del cambio en el esquema: (a)
añadir un atributo a una clase;
(b)
borrar un atributo de una clase;
(c)
renombrar un atributo ;
e;
(d)
hacer que una clase S sea una superclase de otra clase
(e)
eliminar una clase S de la lista de superclases de la clase e;
e;
(f)
crear una nueva clase
(g)
borrar una clase;
(h)
modificar los nombres de las clases.
Bases de datos orientadas a objetos: estándares y sistemas
Objetivos del capítulo: En este capítulo aprenderá: •
Acerca de OMG (Object Management Group) y la arquitectura OMA (Object Management Architecture ).
•
Las principales características de la arquitectura CORBA (Common Object Request Broker Architecture)
•
Las principales características de los otros estándares OMG, incluyendo UML, MOF, XMI, CWM y la arquitectura controlada por modelos (MDA, Model-Driven Architecture).
•
Las principales características Group):
•
del nuevo estándar de objetos de ODMG (Object Data Management
•
modelo de objetos;
•
lenguaje de definición de objetos (ODL, Object Definition Language);
•
lenguaje de consultáae
•
formato de intercambio de objetos (OIF, Object Interchange Format);
•
enlaces con los lenguajes.
objetos (OQL, Object Query Language);
Las principales características de ObjectStore, un SGBDOO comercial: •
la arquitectura de ObjectStore;
•
la definición de datos en ObjectStore;
•
la manipulación de datos en ObjectStore.
En el capítulo anterior hemos examinado algunas de las cuestiones asociadas con los sistemas de gestión de bases de datos orientadas a objetos (SGBDOO). En este capítulo vamos a continuar nuestro estudio de estos sistemas y a examinar el modelo de objetos y los lenguajes de especificación propuestos por ODMG (Object Data Management Group). El modelo de objetos ODMG es importante porque especifica un modelo estándar para la semántica de los objetos de base de datos y soporta la interoperabilidad entre todos los sistemas compatibles. Se ha convertido en el estándar defacto para los SGBDOO. Para poner la discusión de los SGBDOO en un contexto comercial, examinaremos también la arquitectura y la funcionalidad de ObjectStore, uno de los productos SGBDOO más populares.
Estructura del capítulo Puesto que el modelo ODMG es un superconjunto del modelo soportado por OMG (Object Management Group), vamos a proporcionar una panorámica de OMG y de la arquitectura OMG en la Sección 27.1. En la
~
806
Sistemas de bases de datos
Sección 27.2 hablaremos del modelo de objetos y de los lenguajes de especificación de ODMG. Finalmente, en la Sección 27.3, para ilustrar la arquitectura y la funcionalidad de los SOBDOO comerciales, vamos a examinar uno de tales sistemas en detalle, en concreto ObjectStore. Para poder sacar el máximo provecho de este capítulo, el lector debe estar familiarizado con los contenidos de los Capítulos 25 y 26. Los ejemplos de este capítulo están extraídos, de nuevo, del caso de estudio de DreamHome documentado en la Sección lOA y en el Apéndice A.
27.1 Object Management Group Para poner en perspectiva el modelo de objetos ODMO, vamos a comenzar con una breve presentación de la función del consorcio Object Management Oroup y de la arquitectura y algunos de los lenguajes de especificación que este consorcio ha propuesto.
27.1.1 Preliminares OMO es un consorcio internacional sin ánimo de lucro formado por diversas empresas y fundado en 1989 para tratar con las cuestiones de estándares relativos a objetos. El grupo tiene más de 400 miembros, incluyendo casi todos los fabricantes de plataformas y los principales fabricantes software, como Sun Microsystems, Borland, AT&T/NCR, HP, Hitachi, Computer Associates, Unisys y Oracle. Todas estas empresas han acordado trabajar juntas para crear una serie de estándares que puedan ser aceptados por todas. Los objetivos principales de OMO son la promoción de las técnicas orientadas a objeto para la ingeniería del software y el desarrollo de estándares en los que la ubicación, el entorno, el lenguaje y otras características de los objetos sean completamente transparentes para los restantes objetos del sistema. OMO no es un grupo de estandarización reconocido, a diferencia de ISO (International Organization for Standardization) y a diferencia de otros organismos de normalización nacionales como ANSI (American National Standards lnstitute) o IEEE (Institute of Electrical and Electronics Engineers). El objetivo de OMO
Correo Ayuda I I Facilidades cálculo electrónico Hoja de comunes Objetos de aplicación L. CAD Navegador
Almacenamiento
Gestión de transacciones
RJIUl~
\II{
Consultas
Control de versiones
Seguridad
Servicios de objetos
Figura 27.1.
Modelo de referencia de objetos.
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
807
es desarrollar estándares de Jacto que puedan ser aceptados por ISO/ ANSI. OMO no desarrolla ni distribuye productos, sino que se limita a certificar el cumplimiento con los estándares OMo. En 1990, OMO publicó por primera vez su arquitectura OMA (Object Management Architecture, arquitectura de gestión de objetos), la cual ha sufrido diversas revisiones desde entonces (Soley, 1990, 1992, 1995). La guía publicada en 1999 especifica una terminología unificada para los lenguajes, sistemas, bases de datos y entorno s de aplicación orientados a objetos; un marco de trabajo abstracto para los sistemas orientados a objetos; un conjunto de objetivos técnicos y arquitectónicos; y un modelo de referencia para aplicaciones distribuidas utilizando técnicas de orientación a objetos. Para el modelo de referencia, se identificaron cuatro áreas de estandarización: el modelo de objetos (OM, Object Model), el gestor de solicitudes de objetos ORE (Object Request Broker), los servicios de objetos y las facilidades comunes, como se ilustra en la Figura 27.1.
El modelo de objetos El modelo de objetos es un modelo abstracto independiente del diseño, que se utiliza para comunicarse con sistemas orientados a objetos compatibles con OMO (véase la Figura 27.2). Un solicitante envía una solicitud de servicios de objetos al ORE (Object Request Broker, gestor de solicitudes de objetos), que controla todos los objetos del sistema y los tipos de servicios que pueden proporcionar. El ORE reenvía a continuación el mensaje a un proveedor que actúa de acuerdo con el mismo y devuelve una respuesta al solicitante a través del ORE. Como veremos en breve, el modelo de objetos de OMO es un subconjunto del modelo de objetos ODMo.
Gestor de solicitudes de objetos El gestor de solicitudes de objetos (ORE) gestiona la distribución de mensajes entre los objetos de aplicación de una forma altamente interoperable. En la práctica, el ORE es una especie de 'bus software' (o centralita) distribuido que permite que los objetos (solicitantes) generen y reciban solicitudes y respuestas de un proveedor. Al recibir una respuesta del proveedor, el ORE traduce la respuesta a un formato que el solicitante original pueda entender. El ORE es análogo al estándar de comunicaciones X500 para correo electrónico, en el que un solicitante puede enviar una solicitud a otra aplicación o nodo sin tener un conocimiento detallado de su estructura de servicios de directorio. De esta forma, el ORE elimina buena parte de la necesidad de utilizar llamadas RPC (Remote Procedu";e Call) complejas, al proporcionar los mecanismos mediante los que los objetos generan y reciben solicitudes y respuestas de forma transparente. El objetivo es proporcionar interoperabilidad entre las aplicaciones en un entorno distribuido heterogéneo y conectar de forma transparente múltiples sistemas de objetos.
Los servicios de objetos Los servicios de objetos proporcionan las funciones principales para implementar la funcionalidad de objetos básica. Muchos de estos servicios están orientados a bases de datos, como se indica en la Tabla 27.1.
Las facilidades
comunes
Las facilidades comunes comprenden un conjunto de tareas que muchas aplicaciones deben realizar y que tradicionalmente se suelen duplicar dentro de cada aplicación, como por ejemplo las funciones de impresión y Proveedores
Solicitante GESTOR DE SOLICITUDES DE OBJETOS Solicitud Mensaje
Figura 27.2.
Modelo de objetos OMG.
808
Sistemas de bases de datos Tabla 27.1.
Servicios de objetos de OMG.
Servicio de objetos
Descripción
Colección
Proporciona una manera uniforme de crear y manipular las colecciones más comunes de manera genérica. Como ejemplos podríamos citar los conjuntos, las colas, las pilas, las listas y los árboles binarios.
Control de concurrencia
Proporciona un gestor de bloqueos que permite a múltiples clientes coordinar su acceso a los recursos compartidos.
Gestión de sucesos
Permite a los componentes registrar y des-registrar dinámicamente específicos.
Extemalización
Proporciona protocolos y convenios para extemalizar e internalizar los objetos. La ex ternalización registra el estado de un objeto en forma de flujo de datos (por ejemplo en memoria, en disco o a través de una red) y luego la internalización crea un nuevo objeto a partir de ese flujo de datos, dentro del mismo proceso o en otro diferente.
Licencia
Proporciona operaciones para medir el uso de los componentes, con el fin de garantizar una adecuada compensación por su uso y proteger la propiedad intelectual.
Ciclo de vida
Denominación
su interés en sucesos
Proporciona operaciones para crear, copiar, mover y borrar grupos de objetos relacionados. Proporciona una serie de funciones para enlazar un nombre con un objeto, en relación con un contexto de denominación.
Persistencia
Proporciona interfaces con los mecanismos de almacenamiento sistentes.
Propiedades
Proporciona operaciones para asociar valores nominados (propiedades) componente (externo).
Consulta
Relación
Seguridad
Hora Intermediario
Transacciones
y gestión de objetos per-
con cualquier
Proporciona instrucciones de consulta declarativa con predicados e incluye la capacidad de invocar operaciones y otros servicios de objetos. Proporciona una manera para crear asociaciones dinámicas entre componentes que no saben nada el uno del otro. Proporciona servicios tales como la identificación y autenticación, la autorización y el control de acceso, la auditoría, la seguridad de las comunicaciones, el no repudio y la administración. Mantiene una noción unificada de la información horaria entre diferentes máquinas. Proporciona un servicio de emparejamiento para los objetos. Permite a los objetos publicar dinámicamente sus servicios y permite a otros objetos registrarse ante esos servicios. Proporciona una coordinación basada en el protocolo de combinación en dos fases (2PC) entre componentes recuperables, utilizando transacciones planas o anidadas.
de correo electrónico. En el modelo de referencia OMO, estas funciones se ponen a disposición de las aplicaciones mediante interfaces de clases compatibles con la arquitectura OMA. En el modelo de referencia de objeto, las facilidades comunes se dividen enfacilidades comunes horizontales y facilidades de dominio ver-
ticales. Actualmente, sólo hay cuatro facilidades comunes: impresión, servicio horario seguro, internacionalización y el agente móvil. Las facilidades de dominio son interfaces específicas para dominios de aplicación concretos, como por ejemplo finanzas, salud pública, fabricación, telecomunicaciones, comercio electrónico o transporte.
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
809
27.1.2 La arquitectura CORBA La arquitectura COREA (Common Object Request Broker Architecture, arquitectura común para gestión de solicitudes de objetos) define la arquitectura de los entornos basados en ORE. Esta arquitectura es la base de todo componente OMG, definiendo las partes que forman el ORE y sus estructuras asociadas. Utilizando los protocolos de comunicaciones GIOP (General Inter-Object Protocol, protocolo general inter-objetos) o IIOP (Internet Inter-Object Protocol, que es GIOP sobre TCP/IP), un programa basado en COREA puede interoperar con otro programa basado en COREA sobre una diversidad de plataformas, sistemas operativos, lenguajes de programación y redes de distintos fabricantes. COREA 1.1 fue presentado en 1991 y especificaba un lenguaje de definición de interface s (IDL, Interface Definition Language) y una serie de interfaces de programación de aplicaciones que permitían una interacción de tipo cliente-servidor con una implementación específica de un ORE. COREA 2.0 fue presentado en diciembre de 1994 y proporcionaba una mejor interoperabilidad, al especificar cómo podían trabajar conjuntamente diversos ORE de diferentes fabricantes. COREA 2.1 fue presentado a finales de 1997, COREA 2.2 en 1998 y COREA2.3 en 1999 (OMG, 1999). Entre los principales elementos de COREApodemos citar: •
Un lenguaje de definición de interface s (IDL, Interface Definition Language) neutral con respecto a la implementación, que permite la descripción de interfaces de clases independientemente del SGBD concreto o del lenguaje de programación elegido. Hay un compilador de IDL para cada lenguaje de programación soportado, lo que permite a los programadores utilizar las estructuras con las que están familiarizados.
•
Un modelo de tipos que definen los valores que pueden pasarse a través de la red.
•
Un repositorio de interface s que almacena las definiciones IDL persistentes. El repositorio de interfaces puede ser consultado por una aplicación cliente para obtener una descripción de todas las interfaces de objetos registradas, de los métodos que soportan, de los parámetros que requieren y de las excepciones que pueden generarse.
•
Métodos para obtener las interfaces y las especificaciones
•
Métodos para transformar los identificadores OID en cadenas de caracteres y viceversa.
de los objetos.
Como se ilustra en la Figura 27.3, COREA proporciona dos mecanismos enviar solicitudes a los objetos: • •
para que los clientes puedan
invocaciones estáticas utilizando enganches y esqueletos específicos de la interfaz; invocaciones dinámicas utilizando la interfaz dinámica de invocación (DII, Dynamic Interface).
Gestor de solicitudes de objetos (ORS) GIOP/IIOP
Figura 27.3.
Arquitectura
de un ORB en CORBA.
Invocation
810
Sistemas de bases de datos
Invocación estática de métodos A partir de las definiciones IDL, pueden asignarse los objetos CaREA a lenguajes de programación o sistemas de objetos específicos, como C, C++, Smalltalk y Java. El compilador IDL genera tres archivos: • un archivo de cabecera, que se incluye tanto en el cliente como en el servidor; •
un archivo fuente del cliente, que contiene enganches de interfaz que se utilizan para transmitir las solicitudes al servidor para las interfaces definidas en el archivo IDL compilado;
•
un archivo fuente del servidor, que contiene esqueletos que se completan en el servidor para proporcionar el compartimento requerido.
Invocación dinámica de métodos La invocación estática de métodos requiere que el cliente tenga un enganche IDL para cada interfaz que utilice en el servidor. Obviamente, esto impide que el cliente pueda utilizar los servicios de un objeto de nueva creación si no conoce su interfaz, ya que en ese caso carece de los enganches de interfaz necesarios para generar la solicitud. Para resolver este problema, la interfaz de invocación dinámica (DDI, Dynamic Invocation Interface) permite al cliente identificar objetos y sus interfaces en tiempo de ejecución y construir e invocar a continuación estas interfaces y recibir los resultados de esas invocaciones dinámicas. Las especificaciones de los objetos y los servicios que proporcionan se almacenan en el repositorio de interfaces. El análogo de DII en el lado del servidor son los esqueletos de interfaz dinámicos (DSI, Dynamic Skeleton Interface), que constituyen una manera de enviar las solicitudes desde el ORE a una implementación del objeto que no tienen conocimiento en tiempo de compilación del objeto que está implementando. Con DSI, no se accede a la operación a través de un esqueleto específico de la operación generado a partir de una especificación de interfaz IDL, sino que en su lugar se accede a través de una interfaz que proporciona los detalles del nombre de la operación y de los parámetros necesarios utilizando la información extraída del repositorio de interfaces.
Adaptador de objetos También incluido en la arquitectura se encuentra el adaptador de objetos, que es la forma principal en que una implementación de un objeto (del lado del servidor) puede acceder a los servicios proporcionados por el ORE. E! adaptador de objetos es responsable del registro de las implementaciones de los objetos, de la generación e interpretación de las referencias a objetos, de la invocación estática y dinámica de los métodos, de la activación y desactivación de objetos y de implementaciones y de la coordinación de seguridad. CaREA exige que se utilice un adaptador estándar, denominado adaptador básico de objetos. En 1999, OMG anunció la versión 3 de CaREA, que añade estándares de cortafuego s para la comunicación a través de Internet, parámetros de calidad de servicio y componentes CaREA. Los componentes CaREA permiten a los programadores activar servicios fundamentales en un nivel superior y fueron diseñados como middleware de componentes independiente del lenguaje e independiente también de los distintos fabricantes, aunque ahora OMG ha adoptado otra especificación para el nivel intermedio Enterprise JavaBeans (EJB), que sólo permite utilizar Java como lenguaje de programación en el nivel intermedio (véase la Sección 29.9). En la literatura técnica, CaREA 2 hace referencia generalmente a la interoperabilidad CaREA y el protocolo IIOP, mientras que CaREA 3 se refiere al modelo de componentes de CaREA. Hay muchos fabricantes de sistemas ORE CaREA comerciales, siendo Orbix de lONA y Visibroker de Inprise dos de los más populares productos.
27.1.3
Otras especificaciones de OMG
OMG ha desarrollado también una serie de especificaciones para modelar arquitecturas y sistemas de software distribuido, junto con sus interfaces CaREA. Actualmente, hay disponibles cuatro especificaciones complementarias: (1) El lenguaje unificado de modelado (UML, Unified Modeling Language) proporciona un lenguaje común para describir modelos software. Se define normalmente como 'un lenguaje estándar para espe-
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
811
cificar, construir, visualizar y documentar las partes componentes de un sistema software'. Ya hemos utilizado en el libro la notación de diagramas de clases de UML como base para los modelos ER que hemos creado en la Parte 4, y también hemos explicado los otros componentes de UML en la Sección 25.7. (2) Lafuncionalidad de meta-objetos (MOF, Meta~Object Facility) define un lenguaje común de carácter abstracto para la especificación de metamodelos. En el contexto de MOF, un modelo es una colección de metadatos relacionados y los metadatos que describen otros metadatos se denominan meta~metadatos, mientras que un modelo que está compuesto de meta-metadatos se denomina metamodelo. En otras palabras, MOF es un meta-metamodelo o modelo de un metamodelo (lo que en ocasiones se denomina ontología). Por ejemplo, UML soporta diversos diagramas diferentes, como por ejemplo diagramas de clases, diagramas de casos de uso y diagramas de actividad. Cada uno de estos tipos de diagrama constituye un tipo distinto de metamodelo. MOF también define un marco de trabajo para implementar repositorios donde almacenar los metadatos descritos por los metamodelos. Dicho marco de trabajo proporciona correspondencias para transformar los metamodelos MOF en interfaces de programación de aplicaciones para los metadatos. Así, MOF permite utilizar de manera interoperable diversos metamodelos distintos que representan diferentes dominios. COREA, UML y CWM (véase más adelante) son metamodelos compatibles con MOF. El marco de trabajo para metadatos de MOF se suele mostrar como una arquitectura de cuatro niveles, como se muestra en la Tabla 27.2. MOF tiene una gran importancia para el lenguaje UML, ya que permite garantizar que cada tipo de modelo UML se defina de una manera coherente. Por ejemplo, MOF garantiza que una 'clase' dentro de un diagrama de clases presente una relación exacta con un 'caso de uso' en un diagrama de casos de uso o con una 'actividad' en un diagrama de actividad. (3) El estándar de intercambio metadatos XML (XMI, XML Metadata lnterchange) establece la correspondencia entre MFO y XML. XMI define el modo en que se utilizan las etiquetas XML para representar en XML modelos compatibles con MOF. Un metamodelo basado en MOF puede traducirse a una definición de tipo de documento (DTD, Document Type Definition) o a un Esquema XML, mientras que un modelo se traduce a un documento XML que sea coherente con su DTD o con su Esquema XML. XMI es un formato de '.flujo' por lo que se lo puede almacenar en un sistema de archivos tradicional o se lo puede mandar a través de Internet desde una base de datos o repositorio. Hablaremos de XML, de los DTD y de los Esquemas XML en el Capítulo 30. (4) El metamodelo común de almacenes de datos (CWM, Common Warehouse Metamodel) define un metamodelo que representa los metadatos tanto empresariales como técnicos que pueden encontrarse normalmente en el campo de los almacenes de datos y de los sistemas de inteligencia empresarial. OMO era consciente de que la integración y gestión de los metadatos constituyen un significativo desafio en estos campos, donde cada producto tiene su propia definición y su propio formato para los metadatos. CWM estandariza la manera de representar los modelos de base de datos (esquemas), los modelos de transformación de esquemas, los modelos OLAP y los modelos de minería de datos. Se utiliza como base para el intercambio de instancias de metadatos entre sistemas software heterogéTabla 27.2.
Arquitectura
de metadatos de OMG.
Meta-nivel
Términos MOF
Ejemplos
M3
meta-metamodelo
El 'Modelo MOF'
M2
metamodelo, meta-metadatos
Metamodelo
UML
Metamodelo
CWM
MI
modelo, metadatos
Modelos UML Metadatos CWM
MO
objeto, datos
Sistemas modelados Datos del almacén de datos
812
Sistemas de bases de datos
Gestión Proceso de almacén datos OLAP Multidimensional XML deTipos datos deindices software de tipos Operación de almacén de datos empresarial Registro Relacional Nomenclatura Expresión Implantación de (Fundamental, datos de información Visualización Claves eI Icorrespondencia Comportamiento_Común,Minería Gestión_Modelos) UML 1.3 Información Análisis ransformación Recurso
Nivel fundamental
Figura 27.4.
Niveles de CWM y estructura de los paquetes.
neos multi-fabricante. CWM se define en términos del estándar MOF, utilizándose el lenguaje UML como notación de modelado (y como metamodelo de base) y XMI como mecanismo de intercambio. Como se indica en la Figura 27.4, CWM está compuesto por una serie de sub-metamodelos dos en 18 paquetes que representan metadatos comunes para almacenes de datos:
organiza-
(a) los metamodelos de recursos de datos soportan la capacidad de modelar recursos de datos heredados y no heredados, incluyendo recursos de datos orientados a objetos, relacionales, basados en registros, multidimensionales y XML (la Figura 27.5 muestra el Metamodelo de datos relacionales CWM); (b) los metamodelos de análisis de datos representan cosas tales como transformaciones de datos, OLAP (OnLine Analytical Processing), minería de datos y visualización de la información; (c) los metamodelos de gestión de almacenes de datos representan procesos estándar de los almacenes de datos y los resultados de las operaciones efectuadas en el almacén de datos. (d) el metamodelo fundam,ental soporta la especificación de diversos servicios generales, como tipos de datos, índices y operaciones de implantación de software basado en componentes.
27.1.4 Arquitectura basada en modelos Aunque OMG esperaba que la arquitectura OMA fuera adoptada como estándar común de middleware orientado a objetos, desafortunadamente otras organizaciones desarrollaron sus propias alternativas. Microsoft elaboró su modelo DCOM (Distributed Common Object Model) propietario, Sun desarrolló lava, que incluía su propio ORB, denominado RMI (Remote Method Invocation), y más recientemente ha surgido otro conjunto de estándares de middleware basado en XML y SOAP (Simple Object Office Access Protocol), que ha sido endosado por Microsoft, Sun e IBM. Al mismo tiempo, la transición hacia el e-Business ha incrementado la presión sobre las organizaciones para integrar sus bases de datos corporativas. Esta integración, que ahora se denomina integración de aplicaciones empresariales (EAI, Enterprise Application Integration), es uno de los principales desafíos actuales a los que las organizaciones se enfrentan y, en lugar de ayudar, algunos argumentan que el middleware forma parte del problema. En 1999, OMG comenzó a trabajar para ir más allá de OMA y CORBA y definir un nuevo enfoque para el desarrollo de sistemas distribuidos. Este trabajo condujo a la introducción de la arquitectura basada en modelos (MDA, Model-Driven Architecture) como método para la especificación e interoperabilidad de sistemas, basándose en las cuatro especificaciones de modelado que hemos mencionado en la sección anterior. La arquitectura se basa en la premisa de que los sistemas deberían especificarse de manera independiente de los detalles hardware y software. Así, aunque el software y hardware puedan cambiar con el tiempo, la especificación seguirá siendo aplicable. El aspecto más importante es que MDA contempla todo el ciclo de vida de los sistemas, desde el análisis y el diseño hasta la implementación, las pruebas, el ensamblado de componentes y la implantación. Para crear una aplicación basada en MDA, se genera un modelo independiente de la plataforma PIM (Platform Independent Model) que representa únicamente la funcionalidad empresarial y el comportamiento.
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
scale : Integer 1 precision SQLDataType numericPrecision Integer SQLDistinctType length : *QueryColumnSet Integer View : ::Integer isNullable : characterSetName NullableType IconstrainedElement numericPrecisionRadix Iconstraint ColumnnumericScale :: String : Integer : Integer isReadOnly checkOption :Boolean Boolean collationName typeNumber : Integer: Integer queryExpression : characterMaximumLength QueryExpression sqlSimpleType *String characterOctetLength : Integer Ifeature length : Integer IstructuralFeature 1 Itype lusingTrigger scale ISQLSimpleType: Integer : Trigger SQLSimpleType Itype :: SQLStructuredType IreferencedTableType loptionScopeColumnSet : SQLStructuredType : NamedColumnSet Type {ordered} d}
* Iconstraint sqlDistinctType : Column : Integer loptionScopeColumn
*
Figura 27.5.
1
{ordered}
Metamodelo
para datos relacionales
813
SQLSimpleType dateTimePrecision : Integer
T
CWM.
El modelo PIM puede entonces hacerse corresponder con uno o más modelos específicos de la plataforma (PSM, Platform Specific Model) para utilizar plataformas tales como el modelo de componentes de CORBA (CCM, CORBA Component Model), Enterprise JavaBeans (EJB) o Microsoft Transaction Server (MTS). Tanto el modelo PIM como el modelo PSM se expresan utilizando el modelo UML. La arquitectura comprende el rango completo de servicios ya especificados por OMG, como los de persistencia, transacciones y seguridad (véase la Tabla 27.1). Lo más importante es que MDA permite la generación de modelos de dominio estandarizados para sectores industriales verticales específicos. OMG va a tratar de definir una serie de perfiles para garantizar que un modelo UML dado pueda generar de manera coherente todas las interfaces de programación de aplicaciones para middleware más populares. La Figura 27.6 ilustra el modo en que se relacionan los diversos componentes de la arquitectura MDA.
27.2 Estándar de objetos de datos ODMG 3.0, 1999 En esta seCClOn vamos a revisar el nuevo estándar del modelo de datos orientado a objeto OODM (Object~Oriented Data Model) propuesto por ODMG (Object Data Management Group). Está compuesto de un modelo de objetos (véase la Sección 27.2.2), un lenguaje de definición de objetos equivalente al lenguaje de definición de datos (DDL) de un SGBD convencional (véase la Sección 27.2.3) y de un lenguaje de consulta de objetos con una sintaxis parecida a la de SQL (Sección 27.2.4). Comenzamos con una introducción a ODMa.
814
Sistemas de bases de datos
Metamodelo MOF (definido en UML)
Modelo CORBA IDL
Especificación UML Modelo de clases UML
Modelo de casos de uso UML
*
Modelo de secuencias UMLI
CJCJCJ
XMI
Metamodelo común de almacén de datos (CWM)
~
Modelo independiente de la plataforma (PIM)
Modelo especifico de la plataforma (PSM)
Modelo especifico de la plataforma (PSM) XMI
Perfil CORBAIDL
Código IDL
Perfil EJB
Los perfiles amplían UML y proporcionan una forma coherente de generar código a partir de un modelo UML. Además, MDA debe soportar mecanismos de ingenieria inversa para generar un modelo PIM a partir del código subyacente.
Código IDL
Figura 27.6.
Diseño de base de datos relacional específico
La arquitectura MDA.
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
815
27.2.1 Object Data Management Group Diversos fabricantes importantes decidieron unirse para formar el consorcio Object Data Management Group con el fin de definir estándares para los SGBDOO. Entre estos fabricantes se incluyen Sun Microsystems, eXcelon Corporation, Objectivity Inc., POET Software, Computer Associates y Versant Corporation. ODMG definió un modelo de objetos que especificaba un modelo estándar para la semántica de los objetos de base de datos. Este modelo tiene una gran importancia, porque determina la semántica predefinida que los SGBDOO comprenden y pueden imponer. Como resultado, el diseño de bibliotecas de clases y de aplicaciones que utilicen esta semántica debería poder ser portable entre los diversos SGBDOO que soporte ese modelo de objetos (Connolly, 1994). Los principales componentes de la arquitectura ODMG para un SGBDOO son: •
el modelo de objetos (OM, Object Model);
•
el lenguaje de definición de objetos (ODL, Object Definition Language);
•
el lenguaje de consulta de objetos (OQL, Object Query Language);
•
enlaces con los lenguajes C++, Java y Smalltalk.
Hablaremos de estos componentes en el resto de esta sección. La versión inicial del estándar ODMG fue publicada en 1993. Ha habido una serie de actualizaciones de menor importancia desde entonces, pero en septiembre de 1997 se adoptó una nueva versión, ODMG 2.0, con una serie de mejoras que incluían: •
un nuevo enlace para el lenguaje de programación Java Sun;
•
una versión completamente revisada del modelo de objetos, con un nuevo metamodelo que soporta la semántica de los objetos de base de datos en diversos lenguajes de programación;
•
una forma externa estándar para los datos y para los esquemas de datos, que permite el intercambio de datos entre bases de datos.
A finales de 1999, se publicó la versión ODMG 3.0, que incluía una serie de mejoras al modelo de objetos y a los enlaces Java. EntreJas versiones 2.0 y 3.0, ODMG decidió ampliar su ámbito de actuación, para cubrir la especificación de estándares universales de almacenamiento de objetos. Al mismo tiempo, ODMG cambió su nombre, pasando de llamarse Object Database Management Group a adoptar la denominación Object Data Management Group, para reflejar la ampliación de sus objetivos más allá de los meros estándares de almacenamiento para objetos de base de datos. Los enlaces Java de ODMG fueron propuestos a la organización Java Community Process como base para la especificación IDO (Java Data Object), aunque ahora IDO está basado en una técnica que utiliza el lenguaje nativo, en lugar de un enlace. Ya hay disponible una versión pública de la especificación IDO, de la que hablaremos en el Capítulo 29. ODMG completó su trabajo en 2001 y después se deshizo como organización.
Terminología De acuerdo con la última definición de sus objetivos, la especificación ODMG cubre tanto sistemas SGBDOO que almacenan los objetos directamente como las denominadas asignaciones objeto-base de datos (Object-to~Database Mappings, ODM) que convierten y almacenan los objetos a una representación relacional o a algún otro tipo de sistema de base de datos. Ambos tipos de productos se suelen denominar, genéricamente, sistemas de gestión de objetos de datos (Object Data Management Systems, ODMS). Los ODMS hacen que los objetos de base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación existentes (orientados a objetos), y también amplían el lenguaje de programación con mecanismos de transparencia persistente de los datos, control de concurrencia, recuperación, consulta asociativa y otras capacidades de base de datos (Cattell, 2000).
27.2.2
El modelo de objetos
El modelo de objetos de ODMG es un superconjunto del modelo de objetos de OMG, que permite portar tanto los diseños como las implementaciones entre diversos sistemas compatibles. Especifica las siguientes primitivas básicas de modelado:
816
Sistemas de bases de datos
•
Las primitivas básicas de modelado son el objeto y el literal. Sólo los objetos tienen identificadores unívocos.
•
Los objetos y literales pueden clasificarse en tipos. Todos los objetos y literales de un tipo dado exhiben un comportamiento y un estados comunes. Un tipo es en sí mismo un objeto. A los objetos se les denomina en ocasiones instancias del tipo al que pertenecen.
•
El comportamiento se define mediante un conjunto de operaciones que pueden realizarse sobre o por el objeto. Las operaciones pueden tener una lista de parámetros de entrada/salida, cada uno de un tipo concreto, y pueden devolver un resultado de otro tipo determinado.
•
El estado se define mediante los valores que el objeto tiene para una serie de propiedades. Una propiedad puede ser un atributo del objeto o una relación entre el objeto y uno o más objetos distintos. Normalmente, los valores de las propiedades del objeto pueden cambiar a lo largo del tiempo.
•
Un ODMS almacena objetos, permitiendo que múltiples usuarios y aplicaciones los compartan. Un ODMS está basado en un esquema que está definido en el lenguaje de definición de objetos (ODL) y contiene instancias de los tipos definidos por el esquema.
Objetos Un objeto está descrito mediante cuatro características: estructura, identificador, nombre y ciclo de vida, como a continuación se explica.
Estructura del objeto Los tipos de objetos se pueden clasificar como atómicos, colecciones y tipos estructurados, como se ilustra en la Figura 27.7. En esta estructura, los tipos mostrados en cursiva son tipos abstractos; los tipos mostrados en letra normal son directamente instanciables. Sólo podemos utilizar como tipos base los tipos que sean directamente instanciables. Los tipos con corchetes angulares « » indican generadores de tipos. Todos los objetos atómicos son definidos por el usuario, mientras que también existen diversos tipos de colección predefinidos, como veremos en breve. Como muestra la Figura 27.7, los tipos estructurado s son tal como se define en la especificación SQL de ISO (véase la Sección 6.1). Los objetos se crean utilizando el método new de la correspondiente interfazfactoría proporcionada por la implementación de enlace con el lenguaje. La Figura 27.8 muestra la interfaz ObjectFactory, que tiene un método new para crear una nueva instancias del tipo Object. Además, todos los objetos tienen la interfaz ODL mostrada en la Figura 27.8, que es implícitamente heredada por las definiciones de todos los tipos de objetos definidos por el usuario.
Identificado res de objetos y nombres de objetos El ODMS proporciona a cada objeto una identidad unívoca, el identificador del objeto, que no varía y que no se reutiliza después de que el objeto haya sido borrado. Además, a cada objeto puede dársele también uno o más nombres que sean significativos para el usuario, siempre y cuando cada nombre identifique a un único objeto de la base de datos. Los nombres de los objetos pretenden actuar como objetos 'raíz' que proporcionan puntos de entrada a la base de datos. Por ello, en la clase Database (de la que hablaremos en breve) es donde se proporcionan los métodos para denominar los objetos, en lugar de proporcionar dichos métodos dentro de la clase del objeto.
Ciclo de vida de los objetos El estándar especifica que el ciclo de vida de un objeto debe ser ortogonal a su tipo, es decir, que la persistencia sea independiente de los tipos (véase la Sección 26.3.2). El ciclo de vida se especifica en el momento de crear el objeto y puede ser: •
transitorio: la memoria correspondiente al objeto es asignada y desasignada por el sistema de ejecución del lenguaje de programación. Normalmente, la asignación estará basada en un pila de memoria para los objetos declarados en la cabecera de un procedimiento y utilizará almacenamiento estático o
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
817
LiteraUype Atomic_literal
long long long short unsigned long unsigned short float double boolean octet char string enum<>
11
enumeración
Collection_literal
set<> bag<> list<> array<> dictionary<> Structured_literal
date time timestamp interval structure<> Object_type Atomic_object Collection_object
Set<> Bag<> List<> Array<> Dictionary<> Structured_object
Date Time Timestamp lnterval
Figura 27.7.
Conjunto completo de tipos predefinidos
para el modelo de objetos ODMG.
el cúmulo de memoria del programa para los objetos dinámicos (cuyo ámbito sea un determinado proceso); •
persistente: el espacio de almacenamiento
del objeto es gestionado por el ODMS.
Literales Un literal es, básicamente, un valor constante, posiblemente con una estructura compleja. Siendo una constante, los valores de sus propiedades no pueden cambiar. Por ello, los literales no tienen sus propios identificadores y no son objetos en sí mismos: están incluidos dentro de los objetos y no se puede hacer referencia a ellos individualmente. Los tipos literales pueden clasificarse como atómicos, colecciones, estructurado s o
818
Sistemas de bases de datos
interface ObjectFactory { Object
newO;
interface Object { enum
Lock_Type{read, write, upgrade);
void
lock(in Lock_Type mode) rai8es (LockNotGranted);11 obtener bloqueo - esperar si es necesario
boolean
try _lock(in Lock_Type mode);
boolean
same_as(in Object anObject);
Object
copyO;
11
copiar objeto - el objeto copiado no es 'el mismo'
yoid
deleteO;
11
borrar objeto de la base de datos
11 11
obtener bloqueo - no esperar si no se concede inmediatamente
comparación de identidad
};
Figura 27.8.
Interfaz ODL para los tipos de objetos definidos por el usuario.
nulos. Los literales estructurado s contienen un número fijo de elementos heterogéneo s con un determinado nombre. Cada elemento es una pareja , donde valor puede ser cualquier tipo literal. Por ejemplo, podríamos definir una estructura Address de la forma siguiente: struct Address string string string
{ street; city; postcode;
};
attribute
Address
branchAddress;
A este respecto, una estructura es similar al tipo struct o record de algunos lenguajes de programación. Puesto que las estructuras son literales, pueden aparecer como valor de un atributo en la definición de un objeto. En breves momentos veremos un ejemplo de esto.
Colecciones predefinidas En el modelo de objetos ODMG, una colección contiene un número arbitrario de elementos homogéneos carentes de nombre, cada uno de los cuales puede ser una instancia de un tipo atómico, otra colección o un tipo literal. La única diferencia entre los objetos colección y los literales colección es que los objetos colección tienen una identidad. Por ejemplo, podríamos definir el conjunto de todas las sucursales como una colección. La iteración a través de una colección se realiza utilizando un iterador que mantiene la posición actual dentro de la colección especificada. Existen colecciones tanto ordenadas como desordenadas. Las colecciones ordenadas deben recorrerse desde el primer elemento al último, o viceversa; las colecciones desordenadas no tienen un orden fijo de iteración. Los iteradores y las colecciones tienen las operaciones que se muestran en las Figuras 27.9 Y 27.1 0, respectivamente. La estabilidad de un iterador determina si la iteración es segura con respecto a los cambios que puedan realizarse en la colección durante la iteración. Un objeto iterador dispone de métodos para posicionar el puntero del iterador en el primer registro, para obtener el elemento actual y para incrementar el iterador de modo que apunte al siguiente elemento, entre otros métodos. El modelo especifica cinco subtipos de colección predefinidos: •
Se!: colecciones desordenadas
•
Bag:
colecciones desordenadas que permiten duplicados;
•
Lis!:
colecciones ordenadas que permiten duplicados;
•
Array:
•
Dictionary:
matriz unidimensional
que no permiten duplicados;
de longitud dinámicamente variable;
secuencia desordenada de parejas clave-valor sin claves duplicadas.
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
819
interface Iterator { exception
NoMoreElements{};
exception
InvalidCollectionType{};
boolean
is_stableC);
boolean
acendC);
void
resetC);
Object
gecelementC) raises(NoMoreElements);
void
nexcpositionC) raises(NoMoreElements);
void
replace3lement(in
Object element) raises(InvalidCollectionType);
); interface BidirectionalIterator : Iterator { boolean
acbeginningC);
void
previous_positionC) raises(NoMoreElements);
);
Figura 27.9.
Interfaz OOL para los iteradores.
interface Collection: Object { exception
InvalidCollection{};
exception
ElementNotFound{Object
unsigned long
cardinalityC);
// devolver número de elementos
boolean
is_emptyC);
// comprobar si colección vacía
element;l;
boolean
is_orderedC);
// comprobar si colección ordenada
boolean
allows_duplicatesO;
// comprobar si duplicados permitidos
boolean
contains_element(in Object element); // comprobar si existe elemento especificado
void
insert_element(in Object element);
void
remove_element(in Object element) "'" raises (ElementNotFound);
Iterator BidirectionalIterator
Object
// eliminar elemento especificado
create_iterator(in boolean stable); create_bidirectionaLiterator(in raises (InvalidCollectionType);
// insertar elemento especificado
// crear iterador de avance directo
boolean stable) // crear iterador bidireccional
select_element(in string OQL-predicate);
Iterator
select(in string OQL-predicate);
boolean
query(in string OQL-predicate, inout Collection result);
boolean
exists3lement(in
string OQL-predicate);
1;
Figura 27.10.
Interfaz OOL para las colecciones.
Cada subtipo tiene operaciones que permiten crear una instancia de dicho tipo e insertar un elemento en la colección. Las colecciones de tipo Set y Bag tienen las habituales operaciones de conjuntos: unión, intersección y diferencia. Las definiciones de interfaz para las colecciones Set y Dictionary se muestran en la Figura 27.11.
Objetos atómicos Todo objeto definido por el usuario que no sea un objeto colección se denomina objeto atómico. Por ejemplo, para DreamHome podríamos crear tipos de objetos atómicos para representar Branch y Staff. Los objetos atómicos se representan en forma de una clase, que comprende un estado y un comportamiento. El estado se define mediante los valores que el objeto tiene para un conjunto de propiedades, que puede ser atributos del objeto o relaciones entre el objeto y uno o más objetos distintos. El comportamiento se define mediante un conjunto de operaciones que pueden ser realizadas sobre o por el objeto. Además, los objetos atómicos pue-
820
Sistemas de bases de datos
interface SetFactory : ObjectFactory { Set
11
new_oCsize(in long size);
crear un nuevo objeto set
};
elass Set : Collection { attribute set value; Set
create_union(in
Set
create_intersection(in
11
unión de dos conjuutos
11
Set
intersección de dos conjuntos
create_difference(in Set other_set);
11
diferencia de dos conjuntos
boolean
is_subseCof(in Set othecset);
11
comprobar si un conjunto es subconjunto de otro
boolean
is_propecsubsecof(in
11
comprobar si un conjunto es un subconjunto propio de otro
boolean
is_superset_of(in Set other_set);
11
comprobar si un conjunto es un snperconjunto de otro
boolean
is_propecsuperset_of(in
11
comprobar si un conjunto es un superconjunto propio de otro
Set other_set); Set other_set);
Set other_set); Set other_set);
};
interface DictionaryFactory : ObjectFactory { Dictionarynew_oCsize(in
long size);
};
elass Dictionary : Collection { exception DuplicateName{string key;}; exception KeyNotFound{Object
key;);
attribute
dictionary value;
void
bind(in Object key, in Object value) raises(DuplicateName);
void
unbind(in Object key) raises(KeyNotFound);
void
lookup(in Object key) raises(KeyNotFound);
void
contains_key(in Object key);
};
Figura 27.11.
Interfaz ODL para las colecciones
Set y Dictionary.
den estar relacionados según una retícula de s!t-pertipos/subtipos. Como cabría esperar, los subtipos heredan todos los atributos, relaciones y operaciones definidos sobre el supertipo, pudiendo además definir propiedades y operaciones adicionales y redefinir las propiedades y operaciones heredadas. Vamos a ver ahora los atributos, relaciones y operaciones, con mayor detalle.
Atributos Un atributo se define sobre un único tipo de objeto. Un atributo no es un objeto de 'primera clase', es decir, no es un objeto y no tiene un identificador de objeto, sino que toma como valor un literal o un identificador de objeto. Por ejemplo, la clase Branch tiene atributos para el número de sucursal, la calle, la ciudad y el código postal.
Relaciones Las relaciones se definen entre tipos. Sin embargo, el modelo sólo soporta relaciones binarias con cardinalidad 1:1, 1:* y *:*. Una relación no tiene un nombre y, de nuevo, no es un objeto de 'primera clase'; en lugar de ello, lo que se hace es definir rutas de recorrido para cada dirección de recorrido de la relación. Por ejemplo, la relación entre sucursales y empleados podría definirse como Branch Has o como Staff WorksAt Branch, pudiéndose representar de la forma siguiente: class
Branch
{
relationship }; c1ass
Has inverse
8taff::WorksAt;
8taff {
relationship };
set
Branch
WorksAt
inverse
Branch::Has;
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
821
En el lado múltiple de las relaciones uno a muchos, los objetos pueden estar desordenados (una colección o Bag) u ordenados (List). El ODMS mantiene automáticamente la integridad referencial de las relaciones y se generará una excepción (es decir, un error) si se trata de recorrer una relación en la que uno de los objetos participantes haya sido borrado. El modelo especifica operaciones predefinidas para formar (form) y eliminar (drop) miembros de las relaciones y para gestionar las restricciones de integridad referencial requeridas. Por ejemplo, la relación 1:1 Staff WorksAt Branch daría como resultado las siguientes definiciones en la clase Staff para la relación con Branch: Set
attribute void void
Branch WorksAt;
form_ WorksAt(in drop _WorksAt(in
La relación 1:* relación con Staff:
Branch Branch
Branch Has Staff
aBranch) raises(IntegrityError); aBranch) raises(IntegrityError);
daría como resultado las siguientes definiciones en la clase
Branch
para la
readonly attribute set Has; void form _Has(in Staff aStaff) raises(IntegrityError); void drop _Has(in Staff aStaff) raises(IntegrityError); void add _Has(in Staff aStaff) raises(IntegrityError); void remove _Has(in Staff aStaff) raises(IntegrityError); Operaciones Las instancias de un tipo de objeto tienen un comportamiento que está especificado mediante un conjunto de operaciones. La definición del tipo de objeto incluye una signatura de operación para cada operación donde se especifica el nombre de la operación, los nombres y tipos de cada argumento, los nombres de las excepciones que puedan generarse y los tipos de los valores devueltos, si es que hay alguno. Una operación sólo puede definirse en el contexto de un único tipo de objeto. Está permitida la sobrecarga de los nombres de las operaciones. El modelo asume una ejecución secuencial de las operaciones y no requiere soporte para operaciones concurrentes, paralelas o remotas, aunque tampoco excluye dicho soporte.
Tipos, clases, interfaces y herencia En el modelo de objetos de ODMG hay dos formas de especificar los tipos de los objetos: interfaces y clases. También hay dos tipos de mecanismos de herencia, como ahora veremos. Una interfaz es una especificación que define únicamente el comportamiento abstracto de un tipo de objeto, utilizando signaturas de las operaciones. La herencia del comportamiento permite que las interfaces sean heredadas por otras interfaces y clases, utilizando el símbolo':'. Aunque una interfaz puede incluir propiedades (atributos y relaciones), éstas no pueden ser heredadas a partir de la interfaz. Las interface s son, asimismo, no instanciables; en otras palabras, no podemos crear objetos a partir de una interfaz (de forma similar a lo que sucede en C++, donde no podemos crear objetos a partir de una clase abstracta). Normalmente, las interface s se utilizan para especificar operaciones abstractas que pueden ser heredadas por las clases o por otras interfaces. Por el contrario, una clase define tanto el estado abstracto como el comportamiento de un tipo de objeto y además es instanciable (es decir, la interfaz es un concepto abstracto, mientras que la clase es un concepto relacionado con la implementación). También podemos utilizar la palabra clave extends para especificar una herencia simple entre clases. La herencia múltiple no está permitida utilizando extends aunque sí que se permite mediante herencia del comportamiento. Más adelante veremos ejemplos de ambos tipos de herencia.
Extensiones y claves Una definición de clase puede especificar una extensión y sus claves: •
La extensión es el conjunto de todas las instancias de un tipo dado dentro de un ODMS concreto. El programador puede solicitar que el ODMS mantenga un índice a los miembros de este conjunto. Si se borra un objeto, se elimina el objeto de la extensión del tipo del cual es una instancia.
822
Sistemas de bases de datos
•
Una clave identifica de forma unívoca las instancias de un tipo (de forma similar al concepto de clave candidata definida en la Sección 3.2.5). Un tipo debe tener una extensión para poder tener una clave. Observe también que la clave es diferente del nombre del objeto: una clave está compuesta de propiedades especificadas en la interfaz del tipo de objeto, mientras que el nombre del objeto está definido dentro del tipo de base de datos.
Excepciones El modelo ODMG soporta la utilización de rutinas de tratamiento de excepciones dinámicamente anidadas. Como ya hemos indicado, las operaciones pueden generar excepciones y éstas pueden comunicar resultados de la excepción. Las excepciones son objetos de 'primera clase' que pueden formar una jerarquía de generalización-especialización, proporcionando en ODMS el tipo raíz Exception.
Metadatos Como hemos explicado en la Sección 2.4, los metadatos son 'datos acerca de los datos': es decir, datos que describen los objetos del sistema, como por ejemplo clases, atributos y operaciones. Muchos ODMS existentes no tratan a los metadatos como objetos en sí mismos. Por lo que el usuario no puede consultar los metadatos de la misma manera que haría con otros objetos. El modelo ODMG define metadatos para: •
ámbitos, que definen una jerarquía de denominación para los meta-objetos del repositorio;
•
meta-objetos, que consisten en módulos, operaciones, excepciones, constantes, propiedades (consistentes en atributos y relaciones) y tipos (consistentes en interface s, clases, colecciones y tipos construidos);
•
especificadores, que se utilizan para asignar un nombre a un tipo en ciertos contextos;
•
operandos, que forman el tipo base para todos los valores constantes del repositorio.
Transacciones El modelo de objetos ODMG soporta el conceRto de transacciones como unidades lógicas de trabajo que llevan a la base de datos de un estado coherente a otro (véase la Sección 20.1). El modelo asume una secuencia lineal de transacciones que se ejecutan dentro de una hebra de control. La concurrencia está basada en bloqueos de lectura/escritura estándar, con un protocolo de control de concurrencia pesimista. Los accesos, la creación, la modificación y el borrado de objetos persistentes deben llevarse a cabo dentro de una transacción. El modelo especifica operaciones predefinidas para iniciar, confirmar y abortar las transacciones, así como una operación de punto de control, como se muestra en la Figura 27.12. Los puntos de control confirman todos los objetos modificados en la base de datos, sin liberar ningún bloqueo, antes de continuar la transacción. El modelo no precluye el soporte de transacciones distribuidas, pero sí que exige que, en caso de que se proporcione, sea compatible con XA (véase la Sección 23.5)
Bases de datos El modelo de objetos ODMG soporta el concepto de bases de datos como áreas de almacenamiento para objetos persistentes de un conjunto de tipos determinados. Una base de datos tiene un esquema que contiene un conjunto de definiciones de tipos. Cada base de datos es una instancia de tipo Database con las operaciones predefinidas open y c1ose,así como lookup, que comprueba si una base de datos contiene un objeto especificado. Los objetos nominado s constituyen puntos de entrada a la base de datos, enlazándose el nombre con el objeto mediante la operación bindpredefinida, y desenlazándose mediante la operación unbind, como se muestra en la Figura 27.13.
Módulos Partes del esquema pueden ser empaquetadas juntas para formar módulos nominados. Los módulos tienen dos usos principales:
Bases de datos orientadas a objetos: estándares y sistemas
Capítulo 27
interface TransactionFactory Transaction
new();
Transaction
current();
823
{
};
interface Transaction
{
void
begin() raises(TransactionlnProgress,
void
commit() raises(TransactionNotInProgress);
DatabaseClosed);
void
abort() raises(TransactionNotInProgress);
void
checkpoint() raises(TransactionNotInProgress);
void
join() raises(TransactionNotInProgress);
void
leave() raises(TransactionNotInProgress);
boolean
isOpen();
};
Figura 27.12.
Interfaz ODL para las transacciones.
interface DatabaseFactory { Database
new();
};
interface Database{ exception
DatabaseOpen{};
exception
DatabaseNotFound{};
exception
ObjectNameNotUnique{};
exception
ObjectNameNotFound{};
void
open(in string odms_name) raises(DatabaseNotFound,
void
close() raises(DatabaseClosed, TransactionlnProgress);
void
bind(in 2bject
void
unbind(in string name) raises(DatabaseClosed,
void
lookup(in string objecCname) raises(DatabaseClosed,
DatabaseOpen);
an_object, in string name) raises(DatabaseClosed, ObjectNameNotU nique, TransactionNotInProgress); Obj ectN ameN otFound, TransactionN otlnProgress); ObjectN ameN otFound, TransactionNotInProgress);
ODLMetaObjects::Module schema() raises(DatabaseClosed, TransactionNotInProgress); };
Figura 27.13.
Interfaz ODL para objetos de base de datos .
•
pueden utilizarse para agrupar información relacionada, de modo que se la pueda gestionar como una única entidad no minada;
•
pueden utilizarse para establecer el ámbito de las declaraciones, ver los conflictos de denominación que puedan surgir.
27.2.3
lo que puede resultar útil para resol-
El lenguaje de definición de objetos
El lenguaje de definición de objetos (ODL, Object Definition Language) es un lenguaje para definir las especificaciones de los tipos de objetos en los sistemas compatibles con ODMG; se trata de un lenguaje equivalente al lenguaje de definición de datos (DDL, Data Definition Language) de los SGBD tradicionales. Su principal objetivo es facilitar la portabilidad de los esquemas entre sistemas compatibles al mismo tiempo que proporciona interoperabilidad entre distintos ODMS. El ODL define los atributos y relaciones de los tipos y especifica la signatura de las operaciones, pero no contempla la implementación de las signaturas. La sintaxis de ODL es una ampliación del lenguaje de definición de interfaces (IDL, Interface Definition Language)
eet
824
Sistemas de bases de datos
de CORBA. ODMG esperaba que ODL fuera la base para la integración de esquemas de múltiples fuentes y aplicaciones. Una especificación completa de la sintaxis de ODL cae fuera del alcance de este libro, pero el Ejemplo 27.1 ilustra alguno de los elementos del lenguaje. El lector interesado puede consultar Cattell (2000) para ver una definición completa.
I
Ejemplo 27.1 El lenguaje de definición
de objetos
Considere el esquema simplificado de inmuebles en alquiler para DreamHome que se muestra en la Figura 27.14. En la Figura 27.15 incluimos una definición ODL de ejemplo para parte de este esquema. Person name fName IName
"
branchNo {PK} propertyNo {PK}
"
Branch rent Has PropertyForRent type 1.*~ ownerNo Views address SalesStaff telNo ManagedBy IsOwnedBy ~"Offers ... 1.1 PrivateOwner Client IsViewedBy maxRent clientNo {PK} {PK}0.. * 1. .* 1..1 0.* ..••IsOfferedBy rooms street 1..1 city .* 1. postcode Owns .•.
4
prefType
Staff {Mandatory, Or}
Figura 27.14.
Esquema de ejemplo para inmuebles en alquiler en el caso DreamHome.
Bases de datos orientadas a objetos: estándares y sistemas
Capítulo 27
module DreamHome { class Braneh
11
(extent branehOffiees
1*
Definir clase para Brancb
key branehNo)
Definir atributos *1
attribute string branehNoi attribute struet BranchAddress {string street, string city, string posteode] address¡ 1*
Definir relaciones *1
relationship Manager ManagedBy inverse Manager::Manages¡ relationship set Has inverse SalesStaff::WorksAt¡ relationship set
Offers inverse PropertyForRent::IsOfferedBy¡
1*Definir operaciones *1 void takeOnPropertyForRent(in
string propertyNo) raises(propertyAlreadyForRent)¡
};
class Person {
11Definir clase para Person
1*Definir atributos *1 attribute struet PName {string fName, string lNamel name;
l¡ class Staff extends Person
11Definir clase para Staff que berede de Person
(extent staff key staffNo) 1*
Definir atributos *1
attribute string staffNo¡ attribute enum SexType {M, Bl sex¡ attribute enum PositionType {Manager, Supervisor, Assistant) position¡ attribute date DOB¡ attribute flo.at salary; 1*
Definir operaciones
short getAgeOi
.".
void increaseSalary(in float increment); };
cIass Manager extends Staff
11
Definir clase para Manager que herede de Staff
(extent managers) 1*Definir relaciones
*1
relationship Braneh Manages inverse Braneh::ManagedBy; }¡
cIass SalesStaff extends Staff
/lDefinir clase para SalesStaff que berede de Staff
(extent salesStaffl
1*
Definir relaciones
*1
relationship Branch WorksAt inverse Branch::Has¡ Definir operaciones */ void transferStaff(in string fromBranchNo, in string toBranehNo) raises(doesNotWorkInBranch)¡
1*
};
l¡
Figura 27.15.
Definición ODL para parte del esquema de DreamHome
para inmuebles en alq~
825
826
Sistemas de bases de datos
27.2.4
El lenguaje de consulta de objetos
El lenguaje de consulta de objetos (OQL, Object Query Language) proporciona un acceso declarativo a la base de datos de objetos utilizando una sintaxis parecida a la de SQL. No proporciona operaciones explícitas de actualización, sino que deja esta tarea a las operaciones definidas sobre los tipos de objetos. Al igual que con SQL, OQL puede utilizarse como lenguaje autónomo y como lenguaje incrustado en otro lenguaje para el que se haya definido un lenguaje ODMo. Los lenguajes soportados son Smalltalk, C++ y Java. OQL también puede invocar operaciones programadas en estos lenguajes. OQL puede usarse tanto para acceso asociativo como navegacional: •
Una consulta asociativa devuelve una colección de objetos. Cómo se localicen estos objetos es responsabilidad del ODMS, en lugar de sedo del programa de aplicación.
•
Una consulta navegacional accede a los objetos individuales, utilizándose las relaciones entre los objetos para navegar de un objeto a otro. Es responsabilidad del programa de aplicación especificar el procedimiento para acceder a los objetos requeridos.
Una consulta OQL es una función que devuelve un objeto cuyo tipo puede ser inferido del operador que contribuye a la expresión que define la consulta. Antes de explicar qué quiere decir esto, veamos primero cómo se realiza la composición de las expresiones. Para esta sección, asumimos que el lector está familiarizado con la funcionalidad de la instrucción SQL SELECT que se ha explicado en la Sección 5.3.
Expresiones Expresión
de definición
de una consulta
Una expresión de definición de consulta tiene la forma: DEFINE Q AS e. Esto define una consulta nominada (es decir, una vista) de nombre Q, dada una expresión de consulta e. Expresiones
elementales
Una expresión puede ser: •
un literal atómico, como por ejemplo 1<1,16.2, 'x', 'abcde', true, nil, date'2004-l2-0l';
•
un objeto nominado; por ejemplo, la extensión de la clase Branch, branchOffices en la Figura 27.15, es una expresión que devuelve el conjunto de todas las sucursales;
•
una variable iteradora extraída de la cláusula FROM de una instrucción SELECT-FROM-WHERE, como por ejemplo,
eASx
o
ex
o
x IN e
donde e es del tipo colección (T), por lo que x es de tipo T. Hablaremos de la instrucción SELECT OQL en breves momentos. •
una expresión de definición de la consulta (como por ejemplo Q, como antes hemos visto).
Expresiones •
de construcción
Si T es un nombre de tipo con propiedades Pl, ... ,PnY el' ... ,en son expresiones, entonces T(Pl :e1, . Pn:en) es una expresión de tipo T. Por ejemplo, para crear un objeto Manager, deberíamos utilizar la siguiente expresión: ••
Manager(staffNo: "SL2l", fName: "John", IName: "White", address: "19 Taylor St, London", position:"Manager", sex: "M", OOB:date'1945-l0-0l', salary: 30000) •
De forma similar, podemos construir expresiones utilizando 8et, List, Bag y Array. Por ejemplo: struct(branchNo: "B003", street: "163 Main St") es una expresión que crea dinámicamente una instancia de este tipo.
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
827
Expresiones de tipo atómico Pueden formarse expresiones utilizando las operaciones estándar unarias y binarias con otras expresiones. Además, si S es una cadena de caracteres, pueden formarse expresiones utilizando: •
operadores estándar unarios y binarios, como por ejemplo not, abs, +, -, =, >, andthen,
and, orelse,
or; 0+);
•
la operación de concatenación de cadenas
•
un desplazamiento de cadena Si (donde i es un entero), lo que hace referencia al carácter i+1 de la cadena;
•
S[primero:último ], lo que hace referencia a la subcadena de S que va del carácter primero+ 1 al carácter último+ 1;
•
'c in S' (donde c es un carácter), lo que devuelve una expresión booleana de valor true si el carácter c está en S;
•
'S like patrón', donde patrón contiene los caracteres '?' o '_', que hacen referencia a cualquier carácter, o los caracteres comodín ,*, o '%', que representan cualquier sub cadena, incluyendo la cadena vacía. Esto devuelve una expresión booleana igual a true si S se corresponde con el patrón.
(11
Expresiones de objetos Pueden formarse expresiones utilizando las operaciones de igualdad y desigualdad ('=' y '!='), que devuelven un valor booleano. Si a es una expresión de un tipo que tiene un atributo o una relación p de tipo T, podemos extraer el atributo o recorrer la relación utilizando las expresiones e.p y e ---7 p, que son de tipo T. De la misma forma, pueden invocarse métodos para devolver una expresión. Si el método no tiene parámetros, pueden omitirse los parámetros en la llamada al método. Por ejemplo, el método getAgeO de la clase 8taft puede invocarse mediante getAge (sin los paréntesis).
Expresiones de colecciones Pueden formarse expresiones utilizando operadores de cuantificación universal (FOR ALL), de cuantificación existencial (EXISTS), de comprobación de pertenencia (IN), de cláusula de selección (SELECT FROM WHERE), de ordenación (ORDER BY), operadores unarios de conjuntos (MIN, MAX, COUNT, SUM, AVG) y el operador de agrupación (GROUP BY). Por ejemplo, FOR ALL
x
IN
managers: x.salary
> 12000
devuelve true para todos los objetos de la extensión La expresión: EXISTS
x
IN
managers.manages:
x.address.city
managers
que tengan un salario superior a 12.000 euros.
= "London";
devuelve true si hayal menos una sucursal en Londres (managers.manages devuelve un objeto Branch y luego comprobamos si el atributo city de este objeto contiene el valor London). El formato de la cláusula SELECT es similar al del lenguaje la instrucción SELECT estándar de SQL (véase la Sección 5.3.1): SELECT FROM
[DISTINCT]
[WHERE [GROUPBY [ORDERBY donde:
] ] ]
... >]
828
Sistemas de bases de datos
::= IN I IN , AS I AS ,
I
El resultado de la consulta es de tipo Sel para SELECT DISTINCT, Lislsi se utiliza ORDER BY Y Bag en cualquier otro caso. Las cláusulas ORDER BY, GROUP BY y HAVING tienen su significado SQL usual (véanse las Secciones 5.3.2 y 5.3.4). Sin embargo, en OQL la funcionalidad de la cláusula GROUP BY se ha ampliado para proporcionar una referencia explícita a la colección de objetos dentro de cada grupo (lo que en OQL se denomina partición) como se ilustra más adelante en el Ejemplo 27.6. Expresiones
de conversión
•
Si e es una expresión, entonces element(e) es una expresión que comprueba si e genera un único objeto y generando una excepción en caso contrario.
•
Si e es una expresión de lista, entonces listtoset( e) es una expresión que convierte la lista en un conjunto.
•
Si e es una expresión que tiene como valor una colección, entonces flatten( e) es una expresión que convierte una colección de colecciones en una colección, es decir, que aplana la estructura.
•
Si e es una expresión y c es un nombre de tipo, entonces cee) es una expresión que comprueba si e es un objeto de tipo c, generando una excepción en caso contrario.
Expresiones
de colecciones
Si el' ez son listas o matrices y expresiones. Por ejemplo:
indexadas
e3,
e4
son enteros, entonces
el[e3],
e¡[e3:
e4],
first(e¡), last(e¡) y (el + ez) son
first( element(SELECT b FROM b IN branchOffices WHERE bbranchNo = "BOOl").Has); devuelve el primer miembro del conjunto de vendedores que trabajan en la sucursal BOOl. Expresiones
de conjuntos
binarios
Si el' ez son conjuntos o bolsas (bags), entonces los operadores de conjuntos union, except e intersect de el
Y
ez son expresIOnes.
Consultas Una consulta está compuesta de un conjunto (posiblemente vacío) de expresiones de definición de consulta, seguido de una expresión. El resultado de una consulta es un objeto con o sin identidad.
I
Ejemplo 27.2 Lenguaje de consulta de recorrido
de objetos: utilización
de extensiones
y de rutas
(1) Obtener el conjunto de todos los empleados (con identidad). En general, se requiere un punto de entrada a la base de datos para cada consulta, pudiendo ser ese punto de entrada cualquier objeto persistente nominado (es decir, una extensión o un objeto nominado). En este caso, podemos utilizar la extensión de la clase Slaffpara generar el conjunto requerido, utilizando la siguiente expresión simple: slaff (2) Obtener el conjunto de todos los gerentes de sucursal (con su identidad).
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
829
branchOffices.ManagedBy En este caso, podemos utilizar el nombre de la extensión de la clase Branch (branchOffices) como punto de entrada a la base de datos y luego emplear la relación ManagedBypara extraer el conjunto de gerentes de sucursal. (3) Localizar todas las sucursales de Londres. SELECT b.branchNo FROM b IN branchOffices WHERE b.address.city = "London"; De nuevo, podemos utilizar la extensión branchOfficescomo punto de entrada a la base de datos y luego enviar la variable de iteración b para recorrer los objetos de esta colección (de forma similar a una variable de tupla que nos permite recorrer las tuplas en el cálculo relacional). El resultado de esta consulta es de tipo bag, ya que la lista de selección sólo contiene el atributo branchNo, que es de tipo cadena de caracteres. (4) Suponga que londonBranches es un objeto nominado (correspondiente al objeto devuelto por la consulta anterior). Utilice este objeto nominado para extraer todo el personal que trabaja en esa sucursal. Podemos expresar esta consulta como: londonBranches.Has que devuelve un resultado de tipo set. Para acceder a los salarios de los vendedores, intuitivamente podemos pensar que esto podría expresarse como: londonBranches.Has.salary Sin embargo, esto no está permitido en OQL, porque hay una ambiguedad sobre cuál es el resultado que hay que devolver: puede ser de tipo set o bag (es más probable que sea bag, porque puede que haya más de uñ empleado con el mismo salario). Debido a ello, tenemos que expresar la consulta como: SELECT [DISTINCT] s.salary FROM s IN londonBranches.Has; La especificación de DISTINCT haría que se devolviera un resultado de tipo set, mientras que si se omite la cláusula DISTINCT se devolvería un resultado de tipo bag.
I
Ejemplo 27.3 Lenguaje de consulta de objetos:
utilización
~
de DEFINE
Obtener el conjunto de todos los empleados que trabajan en Londres (sin identidad). Podemos expresar esta consulta como: DEFINE Londoners AS SELECT s FROM s IN salesStaff WHERE s.worksAt.address.city = "London"; SELECT s.name.IName FROM s IN Londoners; que devuelve un literal de tipo set. En este ejemplo, hemos utilizado la instrucción DEFINE para crear una vista en OQL y luego hemos consultado esta vista para obtener el resultado requerido. En OQL, el nombre de la vista debe ser un nombre unívoco entre todos los objetos, clases, métodos o nombres de función del esquema. Si el nombre especificado en la instrucción DEFINE es igual que el
830
Sistemas de bases de datos
de otro objeto del esquema ya existente, la nueva definición mite que una vista tenga parámetros, por lo que podemos siguiente:
sustituirá a la anterior. OQL también pergeneralizar la vista anterior de la forma
DEFINE CityWorker(cityname) AS SELECT s FROM s IN staffStaff WHERE s.worksAt.address.city Ahora podemos siguiente:
utilizar
=
cityname;
esta consulta
para localizar
los empleados
de Londres
y Glasgow
de la forma
CityWorker("London"); CityWorker("G las gow");
I
Ejemplo 27.4 Lenguaje de consulta
de objetos: utilización
de estructuras
(1) Obtener el conjunto estructurado (sin identidad) que contiene el nombre, sexo y edad de todos los empleados de ventas que trabajen en Londres. Podemos
expresar
esta consulta
como:
SELECT struct (IName: s.name.IName, sex: s.sex, age: s.getAge) FROM s IN saleStaff WHERE s.worksAt.address.city
= "London";
que devuelve un literal de tipo set. sula SELECT.
Observe
en este caso el uso del método
getAge en la cláu-
(2) Obtener el conjunto estructurado (con identidad) que contiene el nombre, sexo y edad de todos los gerentes sustitutos de más de 60 años. -~ Podemos
expresar
esta consulta
como:
class Deputy {attribute string IName; attribute sexType sex; attribute integer age;}; typedef bag Deputies; Deputies (SELECT Deputy (IName: s.name.lname, sex: s.sex, age: s.getAge) FROM s IN staffStaff WHERE position = "Deputy" AND s.getAge > 60); que devuelve
un objeto mutable
de tipo Deputies.
(3) Obtener un conjunto estructurado (sin identidad) que contenga el número de sucursal y el conjunto de todos los asistentes de las sucursales de Londres. Esta consulta
que devuelve
un literal de tipo set,
sería:
SELECT struct (branchNo: x.branchNo, assistants: (SELECT y FROM y IN x.worksAt WHERE y.position = "Assistant")) FROM x IN (SELECT b FROM b IN branchOffices WHERE b.address.city = "London");
I
Ejemplo 27.5 Lenguaje de consulta
de objetos:
¿Cuántos empleados trabajan en Glasgow?
utilización
de agregados
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
831
En este caso, podemos utilizar la operación de agregación COUNT y la vista CityWorkerdefinida anteriormente para expresar esta consulta como: COUNT(s IN CityWorker("Glasgow")); Las funciones de agregación OQL pueden aplicarse dentro de la cláusula de selección o aplicarse al resultado de la operación de selección. Por ejemplo, las siguientes dos expresiones son equivalentes en OQL: SELECT COUNT(s) FROM s IN salesStaffWHERE s.worksAt.branchNo = "B003"; COUNT(SELECT s FROM s IN salesStaff WHERE s.worksAt.branchNo = "B003"); Observe que OQL permite aplicar las operaciones de agregación a cualquier colección del tipo apropiado y, a diferencia de SQL, puede utilizarse en cualquier parte de la consulta. Por ejemplo, la siguiente sintaxis está permitida en OQL (pero no en SQL): SELECTs FROM s IN salesStaff WHERE
I
Ejemplo
COUNT(s.worksAt) > 10;
27.6
Cláusulas
GROUP
BY y HA VING
Determinar el número de empleados de ventas en cada sucursal. SELECT struct(branchNumber, numberOfStaff:COUNT(partition)) FROM s IN salesStaff GROUP BY branchNumEer:s.worksAt.branchNo; El resultado de la especificación de agrupación es de tipo set
p.s.salary FROM p IN partition)
> 10;
Observe el uso de la instrucción SELECT dentro de la operación de agregación AVo. En esta instrucción, la variable de iteración p itera sobre la colección de la partición (de tipo bag
832
Sistemas de bases de datos
27.2.5
Otras partes del estándar ODMG
En esta sección, vamos a analizar brevemente otras dos partes del estándar ODMG 3.0: •
el formato de intercambio de objetos;
•
los enlaces de lenguaje de ODMG.
Formato de intercambio
de objetos
El formato de intercambio de objetos (OIF, Object Interchange Format) es un lenguaje de especificación utilizado para volcar y cargar el estado actual de un ODMS hacia o desde uno o más archivos. OIF puede utilizarse para intercambiar objetos persistentes entre diferentes ODMS, para introducir unos datos iniciales, para proporcionar documentación o para controlar conjuntos de pruebas (Cattell, 2000). OIF fue diseñado para soportar todos los posibles estados de un ODMS compatibles con el modelo de objetos ODMG y con las definiciones de esquema ODL. También fue diseñado de acuerdo con NCITS (National Committee for Information Technology Standards) y PDES/STEP (Product Data Exchange using STEP, STandard for the Exchange ofProduct model data) para CAD mecánico, en la medida de lo posible. Un archivo OIF está formado por una o más definiciones de objetos, donde una definición de objeto es un identificador de objeto (con un indicador opcional de agrupación física) y un nombre de clase (con información opcional de inicialización). Algunos ejemplos de definiciones de objetos serían: John
John (Mary)
John
se crea una instancia de la clase
{SalesSlaff}
de nombre John.
se crea una instancia de la clase SalesSlaff de nombre John y que está situada físicamente cerca del objeto persistente Mary. En este contexto, 'físicamente cerca' depende de la implementación.
{SalesSlaff}
SalesSlaff{WorksAI
SalesSlaff
BOO l}
crea una relación denominada clase
SalesSlaff
WorksAI
entre la instancia John de la
y el objeto nominado BOOl.
Una descripción completa del lenguaje de especificación OIF cae fuera del alcance de este libro, pero el lector interesado puede consultar Cattell (2000}
Enlaces de lenguaje de ODMG Los enlaces de lenguaje especifican cómo se asignan las estructuras ODL/OML a las estructuras de un lenguaje de programación. Los lenguajes soportados por ODMG son C++, Java y Smalltalk. El principio básico de diseño para los enlaces de lenguaje es que el programador debe poder pensar que sólo se está utilizando un lenguaje, no dos lenguajes separados. En esta sección vamos a analizar brevemente cómo funciona el enlace con C++. Se proporciona una biblioteca de clases C++ que contiene clases y funciones que implementan las estructuras ODL. Además, se utiliza el lenguaje de manipulación de objetos (OML) para especificar cómo se extraen y manipulan los objetos de la base de datos dentro del programa de aplicación. Para crear una aplicación funcional, se pasan las declaraciones ODL C++ a través de un preprocesador ODL C++ que tiene el efecto de generar un archivo de cabecera C++ que contiene la definición de los objetos de base de datos y almacena además los metadatos ODMS en la base de datos. La aplicación C++ del usuario, que contiene OML, se compila entonces en la forma normal junto con el archivo de cabecera C++ generado que contiene la definición de los objetos de base de datos. Finamente, el código objeto generado por el compilador se monta con la biblioteca de ejecución ODMS para obtener la imagen ejecutable requerida, como se ilustra en la Figura 27 .16. Además de los enlaces ODL/OML, dentro de ODL y OML el programador puede utilizar una serie de estructuras, denominadas pragmas físicos, para controlar algunas características físicas del almacenamiento, como la agrupación de los objetos en disco, los índices y la gestión de memoria. En la biblioteca de clases C++, las características que implementan la interfaz con el modelo de objetos ODMG tiene un prefijo d_. Como ejemplos podríamos citar d_Float, d_String, d_Short para los tipos de datos base y d_Lisl, d_Sel y d_Bag para los tipos de colección. También hay una clase d_lleralor para la clase Ileralor
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
833
Archivos fuente y de cabecera C++
de la aplicación con OML
Rutinas de ejecución
ODMS
Metadatos
ODMS
Base de datos de objetos
Imagen ejecutable Rutinas de ejecución
ODMS
Figura 27.16.
Compilación
y montaje de una aplicación C++ ODLlOML.
y una clase d_Extent para las extensiones de clases. Además, se define una clase plantilla d_Ref(T)
para cada clase T del esquema de base de datos, que puede hacer referencia a objetos de clase T tanto persistentes como transitorios. Las relaciones se gestionan incluyendo una referencia (para las relaciones 1:1) o una colección (para las relaciones 1:*). Por ejemplo, para representar 1:* Has en la clase Branch, escribiríamos: d_Rel_Set
const char
_WorksAt>
_WorksAt[]
Has;
= "WorksAt";
y para representar la misma relación en la clase SalesStaff escribiríamos: d_Rel_Ref
_Has> WorksAt;
const char
=
_Has[]
"Has";
Lenguaje de manipulación de objetos Para el lenguaje de manipulación de objetos (OML, Object Manipulation Language), el operador new está sobrecargado, para poder crear objetos tanto persistentes como transitorios. Para crear un objeto persistente, es necesario proporcionar un nombre de base de datos y un nombre para el propio objeto. Por ~jemplo, para crear un objeto transitorio, escribiríamos:
834
Sistemas de bases de datos
d_ReftempSalesStaff = new SalesStaff; mientras que para crear un objeto persistente usaríamos: d_Database *myDB; d_RefsI Lenguaje
=
new(myDb, "John White") SalesStaff;
de consulta
de objetos
Las consultas OQL pueden ejecutarse desde programas C++ ODLlOML en una de las siguientes formas: • utilizando la función miembro query de la clase d_Collection; •
utilizando la interfaz d_OQL _ Query.
Como ejemplo del primer método, para obtener el conjunto de vendedores (weIlPaidStaff)con un salario mayor de 30.000 euros, escribiríamos: d_Bagquery(weIlPaidStaff,"salary > 30000"); Como ejemplo del segundo método, para localizar las sucursales con vendedores que ganan un salario superior a un umbral especificado, escribiríamos: d_OQL_Queryq("SELECT
s.worksAt FROM s IN SalesStaff WHERE salary > $1 ");
Éste es un ejemplo de consulta parametrizada, donde $1 representa el parámetro de ejecución. Para especificar un valor para este parámetro y ejecutar la consulta, escribiríamos: d_Bag
27.2.6
Correspondencia entre el diseño conceptual y el diseño lógico (orientado a objetos)
En la Sección 25.7.2 hemos explicado brevemente cómo utilizar los diversos tipos de diagrama UML dentro de una metodología de diseño de bases de datos. En esta sección vamos a analizar cómo establecer la correspondencia entre el esquema conceptual y ODL. Vamos a suponer que se ha producido un diagrama de clases como parte del diseño conceptual de la base de datos, diagrama que estará compuesto por clases (tipos de entidad), subclases, atributos, métodos y un conjunto de relaciones.
Paso 1 Asignación de las clases Se asigna cada clase o subclase a una clase ODL, incluyendo todos los atributos y métodos apropiados. Los atributos compuestos se asignan a un constructor de tuplas utilizando la declaración struct. Los atributos multivaluados se asignan de la forma siguiente: • si los valores están ordenados se asignan a un constructor list; •
si los valores contienen duplicados, se asignan a un constructor bag;
•
en caso contrario, se asignan a un constructor set.
Se crea una extensión para cada clase sobre la que se vayan a realizar iteraciones. Se especifica EXTENDS para cada clase ODL que represente una sub clase que deba heredar los atributos y métodos de la superclase.
Paso 2 Asignación de relaciones binarias Para cada relación binaria, se añade una propiedad de relación (o atributo de referencia) a cada clase que participe en la relación. Si el SGBDOO las soporta, se utilizan relaciones inversas siempre que sea posible para
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
835
garantizar que el sistema mantenga automáticamente la integridad referencial. Si el sistema no soporta este mecanismo, será necesario programar esta funcionalidad dentro de los métodos de clase. Si la multiplicidad es 1: 1, cada propiedad de relación será univaluada; si es de tipo 1:*, la propiedad de relación tendrá un único valor en uno de los lados y un tipo de colección (list o set, dependiendo de los requisitos concretos de la relación) en el otro; si es de tipo *: *, cada lado de la relación será un tipo de colección (véase la Sección 25.6). Se crea un constructor de tuplas (struct) para los atributos de relación, con la forma . Este constructor se utiliza en lugar de la propiedad de la relación. Desafortunadamente, esto impide que se utilicen relaciones inversas. Además, existirá redundancia si la propiedad de relación se crea en ambas direcciones.
Paso 3 Asignación de relaciones n-arias Para cada relación con grado superior a 2 (por ejemplo, ternarias o cuaternarias), se crea una clase separada para representar la relación y se incluye una propiedad de relación (basada en una relación 1:*) en cada clase participante.
Paso 4 Asignación de categorías Para cada categoría (tipo union) presente en el diagrama de clases, se crea una clase que represente la categoría y se define una relación 1:1 entre la clase de categoría y cada una de sus superclases. Alternativamente, puede utilizarse un tipo union si el SGBDOO lo soporta.
27.3 ObjectStore En esta sección vamos a hablar de la arquitectura y funcionalidad de ObjectStore, un SGBDOO comercial.
27.3.1 Arquitectura ObjectStore está basado en una-arquitectura multi-cliente/multi-servidor, siendo cada servidor responsable de controlar el acceso a un almacén de datos y de gestionar el control de concurrencia (basado en bloqueo), la recuperación de datos y el registro de transacciones, entre otras tareas. Un cliente puede contactar al servidor ObjectStore situado en su propio host o a cualquier otro servidor ObjectStore en cualquier host de la red. Para cada máquina host que esté ejecutando una o más aplicaciones cliente, hay un proceso de gestor de caché asociado cuya función principal es facilitar el acceso concurrente a los datos gestionando los mensajes de retrollamada que el servidor hace a las aplicaciones cliente. Además, cada aplicación cliente tiene su propia caché de cliente, que actúa como área de almacenamiento para los datos mapeados (o que están a la espera de ser mapeados) en memoria física. La Figura 27.17 muestra una arquitectura típica. Vamos a describir ahora brevemente las principales responsabilidades de cada uno de estos procesos.
Servidor ObjectStore El servidor ObjectStore es el proceso que controla el acceso a las bases de datos ObjectStore situadas en un host y es responsables de lo siguiente: •
almacenamiento y extracción de datos persistentes;
•
gestión del acceso concurrente por parte de múltiples aplicaciones cliente;
•
recuperación de la base de datos.
Aplicación cliente La biblioteca de cliente ObjectStore se monta con cada aplicación cliente, permitiendo a ésta: •
mapear objetos persistentes a direcciones virtuales;
•
asignar y desasignar espacio de almacenamiento para objetos persistentes;
836
Sistemas de bases de datos Nodo 2
Nodo 1
Nodo 3
Figura 27.17.
Arquitectura de ObjectStore.
•
mantener una caché de las páginas recientemente utilizadas y el estado de bloqueo de dichas páginas;
•
gestionar los fallos de páginas relativos a las direcciones que se refieran a objetos persistentes.
Gestor de cliente El gestor de caché es un demonio UNIX/servicio Windows que se ejecuta sobre la misma máquina que la aplicación cliente. Su función es responder a las solicitudes del servidor por cuenta de la aplicación cliente y gestionar la caché de cliente de la aplicación, que tiene por objeto mejorar el rendimiento de acceso a los objetos persistentes. La caché de cliente es el búfer local para los datos mapeados, o a la espera de ser mapeados, en memoria virtual. Cuando una aplicación cliente necesita acceder a un objeto persistente, se genera un fallo de páginas en las siguientes situaciones: • el objeto no se encuentra en memoria física y no está en la caché de cliente; •
el objeto está en la caché de cliente pero todavía no se ha accedido a él;
•
el objeto está en la caché de cliente pero se ha accedido anteriormente a él con unos permisos de lectura/escritura diferentes.
En estos casos, el cliente ObjectStore solicita la página del servidor, la copia en la caché de cliente y reanuda la ejecución. Si no se cumplen ninguna de estas condiciones, el objeto en la caché estará disponible y la aplicación se limitará a acceder a él.
Propiedad, bloqueo y gestor de caché Para comprender la función del gestor de caché, primero es necesario entender los mecanismos de propiedad y de bloqueo de ObjectStore. Un cliente puede solicitar permiso de lectura o de escritura para una página del servidor. La propiedad de lectura puede ser concedida a tantos clientes como la soliciten, siempre y cuando ningún cliente tenga propiedad de escritura, pero sólo puede haber un único cliente con propiedad de escritura en cada momento. Cuando un cliente quiere leer o escribir una página durante una transacción, coloca un bloqueo de lectura o escritura sobre dicha página, impidiendo así que otros clientes reciban permiso de escritura en dicha página. Un cliente debe tener propiedad de lectura o escritura para poder convocar un bloqueo de lectura o escritura sobre una página. Una vez completada una transacción, el cliente libera el bloqueo (aunque puede retener la propiedad). Observe la distinción entre propiedad y bloqueos: la propiedad da al cliente permiso para leer o actualizar una página, mientras que el bloqueo permite al cliente realizar la propia operación de lectura o actualización de la página. Con la propiedad de una página, un cliente puede bloquear una página sin comunicarse primero con el servidor.
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
837
Cuando un cliente solicita permiso para leer una página y ningún otro cliente tiene permiso para actualizarla, el servidor puede conceder una propiedad de lectura y el gestor de caché no se ve implicado en la operación. Sin embargo, el gestor de caché sí se verá implicado cuando: •
un cliente solicite un permiso de lectura o escritura sobre una página y otro cliente tenga un permiso de escritura sobre dicha página;
•
un cliente solicite un permiso de escritura sobre una página y al menos haya otro cliente que tenga un permiso de lectura en dicha página.
En este caso, el servidor envía un mensaje de retrollamada al gestor de caché asociado con el cliente que tiene el permiso. Esto permite al cliente concentrarse en ejecutar la aplicación y le libera de tener que estar a la escucha de mensajes de retrollamada. En lugar de ello, el gestor de caché determina si el permiso de lectura o escritura puede liberarse o si el cliente solicitante debe esperar.
Arquitectura de mapeado en memoria virtual Una de las características originales de ObjectStore es la forma en que gestiona la persistencia. ObjectStore almacena un objeto C++ en la base de datos en el disco en su formato nativo, con todos los punteros intactos (en lugar de transformarlos en identificadores ODI, como se explicó en la Sección 26.2.1). Una explicación completa de cómo funciona este proceso cae fuera del alcance de este libro, por lo que nos limitaremos a presentar una panorámica general del mecanismo. La idea básica de la arquitectura de mapeado en memoria virtual de ObjectStore es igual a la que se utiliza para la gestión de memoria virtual en los sistemas operativos. Las referencias a los objetos se realizan mediante direcciones de memoria virtual. Si hay que des-referenciar un objeto y la página en la que el objeto reside ya se encuentra en memoria principal, no existirá ningún gasto adicional de procesamiento para desreferencia el objeto y dicha operación es tan rápida como para cualquier programa C o C++. Si la página requerida no está en memoria principal, se produce un fallo de página y se trae la página a la misma dirección de memoria virtual que ocupaba originalmente. De esta forma, los punteros a este objeto que haya en otros objetos ya transferidos serán punteros válidos de memoria virtual que estarán apuntando a su destino original. ObjectStore gestiona este m;oceso reservando un rango de memoria virtual no mapeada para los objetos persistentes, garantizando así que dicho rango sólo será usado para páginas de la base de datos. Cuando un programa accede a su primer objeto, ObjectStore transfiere la página que contiene este objeto a memoria virtual. Cuando el programa trate de navegar desde este objeto inicial a otro objeto utilizando el puntero que apunta al segundo objeto, ObjectStore garantiza que este puntero se dirigirá hacia una porción no mapeada de la memoria virtual. Esto hace que el sistema operativo genere un fallo de página, que ObjectStore atrapa y utiliza para cargar en memoria virtual la página de base de datos que contiene ese segundo objeto. Cuando un programa trate por primera vez de actualizar una página, se generará otra excepción del sistema operativo (un fallo de escritura) de nuevo, ObjectStore captura esta excepción, transfiere la página a memoria virtual, si es necesario, y cambia la protección de la página a lectura/escritura. Entonces, el programa continúa con la actualización. Cuando el programa quiera guardar las actualizaciones, ObjectStore copiará en la base de datos todas las páginas que hayan sido marcadas para actualización y volverá a reinicializar su protección como de sólo lectura. Cuando se cierra una base de datos, ObjectStore quita todas sus páginas de memoria virtual y cancela la reserva del rango de memoria virtual para la base de datos. Con esta técnica, el programador no ve ninguna diferencia entre datos persistentes y transitorios.
27.3.2
Desarrollo de una aplicación ObjectStore
El proceso de desarrollo de una aplicación C++ ObjectStore es ligeramente distinto del que hemos descrito para los enlaces del lenguaje C++ de ODMG en la Sección 27.2.5, como vamos a ver. Una aplicación ObjectStore se construye a partir de una serie de archivos: •
archivos fuentes C++ que contienen el código principal de la aplicación;
•
archivos de cabecera C++ que contienen las clases persistentes;
•
los archivos de cabecera ObjectStore necesarios (por ejemplo, ostore.hh);
838 •
Sistemas de bases de datos un archivo fuente de esquema que define las clases persistentes para el generador de esquemas.
Construir una aplicación ObjectStore requiere la generación de la información de esquema necesaria, es decir, información acerca de las clases que la aplicación almacena en memoria persistente o lee de dicha memoria. El archivo fuente del esquema es un archivo C++ que contiene una lista de clases persistentes y de todas las clases alcanzables, que se identifican utilizando la macro ObjectStore OS _MARK _ SCHEMA_ TYPE (una clase es alcanzable si es la clase base o la clase de un miembro de un objeto persistente). Por ejemplo: #include #include #include "myClasses.hh" OS_MARK_SCHEMA_TYPE(Branch); OS _MARK _ SCHEMA _ TYPE(SalesStaft);
/* define clases persistentes */ /* incluir Branch en el esquema */ /* incluir SalesStaff en el esquema */
El generador de esquemas ObjectStore (ossg) se ejecuta con este archivo para crear dos archivos de salida: •
una base de datos de esquema de la aplicación (por ejemplo mySchema.adb), que contiene información de tipos acerca de los objetos que la aplicación pueda almacenar de manera persistente;
•
un archivo objeto del esquema de la aplicación (por ejemplo, mySchema.obj), aplicación.
que se monta con la
La aplicación se compila de la forma normal, al igual que la salida del generador de esquemas. Los archivos objeto resultantes se montan entonces para crear la imagen ejecutable, como se ilustra en la Figura 27.18.
Bases de datos ObjectStore Una base de datos ObjectStore almacena objetos persistentes y puede crearse utilizando la función se::create. ObjectStore soporta dos tipos de base de datos: Proceso normal de construcción
Proceso de construcción
Ejecutable
Figura 27.18.
os_databa-
específico de ObjectStore
Base de datos de esquema de la aplicación
Desarrollo de una aplicación ObjectStore.
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
839
•
base de datos de archivo, que es un archivo del sistema operativo nativo que contiene una base de datos ObjectStore;
•
base de datos rawfs (raw file system, sistema de archivos en bruto), que es un sistema de archivos privado gestionado por el servidor ObjectStore independiente del sistema de archivos gestionado por el sistema operativo.
Cada base de datos ObjectStore está dividida en clústeres y segmentos. Un clúster es la unidad básica de asignación de espacio en una base de datos ObjectStore. Cuando se crea un objeto persistente, se le asigna espacio de un clúster. Los clústeres están divididos en segmentos. Cuando se crea una base de datos, se suelen crear dos segmentos: •
el segmento del esquema, que contiene las raíces de la base de datos y la información de esquema acerca de los objetos almacenados en la base de datos;
•
el segmento predeterminado, new.
que almacena entidades creadas con la versión persistente del operador
Pueden crearse segmentos adicionales utilizando la función os_database::create_segment. Observe que la aplicación del usuario no puede acceder directamente al segmento de esquema. A los segmentos se les asigna espacio de un clúster predeterminado. Cuando una aplicación crea un objeto en almacenamiento persistente, especifica la base de datos que debe contener el objeto y el objeto se crea en el clúster predeterminado del segmento predeterminado de esta base de datos. Alternativamente, la aplicación puede especificar un segmento, en cuyo caso el objeto será creado en el clúster predeterminado del segmento especificado. Por último, la aplicación puede también especificar un clúster, en cuyo caso el objeto se crea en el clúster especificado.
27.3.3
Definición de datos en ObjectStore
ObjectStore puede gestionar la persistencia para objetos creados en los lenguajes de programación C, C++ y lava mediante bibliotecas de clases independientes, y hay un mecanismo para poder acceder desde un lenguaje a los objetos creados en otro. En esta sección describimos la biblioteca de clases C++, que contiene miembros de datos, funciones miembro y enumeradores que proporcionan acceso a la funcionalidad de base de datos . .". ObjectStore utiliza C++ como lenguaje de esquema, por lo que todo debe definirse mediante una clase C++ en una base de datos ObjectStore. En ObjectStore, la persistencia es ortogonal a los tipos (véase la Sección 26.3.2) y el soporte de objetos persistentes se consigue mediante sobrecarga del operador new, lo que permite una asignación dinámica de la memoria persistente para cualquier tipo de objeto. También hay una versión del operador C++ delete, que puede utilizarse para borrar objetos persistentes y liberar la memoria persistente. Una vez que la memoria persistente ha sido asignada, los punteros a esta memoria pueden usarse de la misma forma que los punteros a la memoria virtual. De hecho, los punteros en memoria persistente siempre toman la forma de punteros de memoria virtual. La Figura 27.19 ilustra un posible conjunto de declaraciones de clases C++ ObjectStore (en un archivo de cabecera' .h') para parte del esquema de base de datos de DreamHome, concentrándose en las clases Branch y SalesStaff y en las relaciones existentes entre ellas (Branch Has SalesStaff y SalesStaff WorksAt Branch). Buena parte de la sintaxis de este esquema resultará familiar para los lectores que tengan conocimiento de C++. Sin embargo, vamos a comentar algunos detalles de implementación concretos: la creación de objetos persistentes, relaciones y extensiones de clases.
Creación de objetos persistentes
mediante sobrecarga del operador new
Como hemos mencionado antes, la persistencia se consigue sobrecargando el operador new. La Figura 27.19 presenta dos ejemplos de sobrecarga de este operador en los constructores correspondientes a las clases Branch y SalesStaff. Por ejemplo, en el constructor de Branch, tenemos una instrucción: branchNo = new(dreamhomeDB, os_typespec::get_charO, 4) char[4]; En este caso, el operador new tiene tres parámetros:
840
Sistemas de bases de datos
e1ass SalesStaff; extern os_Set extern os_database enum PositionType enum SexType
*salesStaffExtent;
*dreamhomeDB; {Manager,
Supervisor,
AssistantJ;
{M, P};
struct Date { int year; int month; int day;
e1ass Branch
{
11
Definir clase para Branch
char branchNo[4J; struct
{ char* street; string* city; string* postcode}
address;
os_relationship_m_l(Branch, Branch(char
b[4])
Has, SalesStaff, WorksAt,
= new(dreamhomeDB,
{branchNo
strcpy(branchNo, 11
Proporcionar
os_Set
Has; 4) char[4J;
b); ]
una interfaz funcional para crear la relación; observe que esto también configura
lIla relación inversa WorksAt. void addStaff(SalesStaff
*s) {Has.insert(s);}
void removeStaff(SalesStaff static os_typespec*
e1ass Person
*s) {Has.remove(s);}
gecos_typespeeO;
{
11
Definir clase para Person
11
Definir clase para Staff que hereda de Person
struet { ehar* fName, char* lName} name;
-e1ass Staff: public Person
{
char staffNo[5]; SexType sex; PositionType
position;
Date DOB; float salary; int getAgeO: void increaseSalary(float
eJass SalesStaff:
increment)
Staff {
11
oSjelationship_l_m(SalesStaff, SalesStaff(ehar
-SalesStaff() /1
{salary += increment:
s[5]) {staffNo
WorksAt,
Definir clase para SalesStaff que hereda de Staff Branch,
Has, Branch*)
= new(dreamhomeDB,
strcpy(staffNo,
s);
salesStaffExtent
- > inserte this);}
{salesStaffExtent->remove(
}
WorksAt;
os_typespec::get_eharO,
5) char[5];
this );}
Proporcionar una interfaz funcional para crear la relación; observe que esto también configura
lIla relación inversa Has. void setBraneh(Braneh* Braneh*
getBranchO
statie os_typespec*
b) {WorksAt.setvalue(b);} {WorksAt.getvalueO;}
gecos_typespecO;
Figura 27.19.
Declaraciones de clases C++ en ObjectStore para parte del esquema de base de datos de DreamHome.
Bases de datos orientadas a objetos: estándares y sistemas
Capítulo 27
841
•
un puntero a una base de datos ObjectStore (dreamhomeDB);
•
un puntero a una especificación de tipo para el nuevo objeto, que hemos obtenido invocando el método sobrecargado get_char de la clase os_typespec (de la que hablaremos más adelante);
•
el tamaño del objeto.
Como es usual, esta versión del operador new devuelve un puntero a la memoria recién asignada. Una vez creado un objeto como persistente, ObjectStore lo extraerá automáticamente cada vez que se des-referencie un puntero a dicho objeto. Los ejemplos proporcionados en la Figura 27.19 son sólo ilustrativos; obviamente, en una implementación completa tendríamos que asignar espacio para todos los atributos de Branch y SalesStaff, en lugar de simplemente a los atributos de clave principal. Observe que si hubiéramos omitido estos parámetros y hubiéramos usado la versión estándar del operador new, es decir: branchNo = new char[4];
lo que se habría creado es un objeto transitorio.
Utilización de especificaciones de tipo Las especificaciones de tipo, que son instancias de la clase os_typespec, se utilizan como argumentos para la versión persistente del operador new con el fin de ayudar a mantener la coherencia de los tipos cuando se manipulen las raíces de la base de datos (hablaremos de las raíces de la base de datos en la Sección 27.3.3). Una especificación de tipo representa un tipo concreto, como por ejemplo char, int o Branch*. ObjectStore proporciona algunas funciones especiales para extraer especificaciones para diversos tipos. La primera vez que dicha función es invocada por un proceso concreto, ObjectStore asigna la especificación de tipo y devuelve un puntero a la misma. Las llamadas subsiguientes a la función dentro del mismo proceso no provocan ninguna asignación de espacio adicional; en lugar de ello, se devuelve un puntero al mismo objeto os_typespec. En la Figura 27.19 hemos añadido miembros a las clases Branch y SalesStaff utilizando una función miembro get_ os_ typespec.
static
os_typespec
*get_os_typespecO;
El generador de esquemas d~ ObjectStore suministra automáticamente viendo un puntero a una especificación de tipo para la clase.
un cuerpo para esta función, devol-
Creación de relaciones en ObjectStore La relación entre Branch y SalesStaff se gestiona declarando dos miembros de datos que son inversos entre sí. Con estos enlaces bidireccionales, ObjectStore puede mantener automáticamente la integridad referencial de esta relación. ObjectStore proporciona macros para definir relaciones; en la Figura 27.19 se usan dos de estas macros: os_relationship_1_m y os_relationship_m_1 (también hay otras macros denominadas os_relationship_1_1 y os_relationship_m_m). Estas macros definen funciones de acceso para configurar y consultar las relaciones. Cada uso de una macro para definir uno de los lados de una relación debe estar emparejado con otra macro que defina el otro lado (inverso) de la relación. En todos los casos, estas macros toman cinco parámetros: •
class
es la clase que define el miembro de datos que se está declarando;
•
member es el nombre del miembro que se está declarando;
•
inv_class
•
inv_member es el nombre del miembro inverso;
•
value_type es el tipo de valor aparente del miembro que se está declarando, como explicaremos breve.
es el nombre de la clase que define el miembro inverso; en
Para instanciar funciones de relación, hay un conjunto asociado de macros de 'cuerpo' de relación que toman los mismos primeros cuatro parámetros (y que deben invocarse desde un archivo fuente). Por ejemplo, para emparejar las dos macros de relación de la Figura 27.19, necesitamos las siguientes dos instrucciones: os_rel_m_1
_body(Branch,
os_rel_1_m
_body(SalesStaff,
Has, SalesStaff, WorksAt); WorksAt, Branch, Has);
842
Sistemas de bases de datos
También hemos proporcionado una interfaz funcional a estas relaciones a través de los métodos addStaff y removeStaffen Branch, y setBranch y getBranch en Staff. Observe también la transparencia de las relaciones bidireccionales. Por ejemplo, cuando invocamos el método addStaffpara especificar que esta sucursal (por ejemplo, b 1) tiene (Has) el empleado indicado (por ejemplo, sI), también se configura la relación inversa WorksAt (es decir, sI WorksAt b 1).
Creación de extensiones en ObjectStore En la Figura 27.15 hemos especificado una extensión para la clase SalesStaff utilizando la palabra clave ODMG extent. En la segunda línea de la Figura 27.19 también hemos especificado una extensión para SalesStaff utilizando el tipo de colección de ObjectStore os_Se!. En el constructor SalesStaff, hemos utilizado el método insert para insertar el objeto dentro de la extensión de la clase y en el destructor hemos empleado el método remove para eliminar el objeto de la extensión de la clase.
27.3.4
Manipulación de datos en ObjectStore
En esta sección se analiza brevemente la manipulación de objetos en una base de datos ObjectStore. Es necesario llevar a cabo las siguientes operaciones antes de poder acceder a la memoria persistente: • es necesario crear o abrir una base de datos; •
hay que iniciar una transacción;
•
hay que extraer o crear una raíz de la base de datos.
Raíces y objetos de punto de entrada Como hemos mencionado en la Sección 27.2.2, una raíz de la base de datos proporciona una forma de dar a un objeto un nombre persistente, lo que permite que el objeto sirva como punto de entrada inicial a la base de datos. A partir de ahí, puede extraerse cualquier objeto relacionado con él utilizando la navegación (es decir, siguiendo los punteros de los objetos) o mediante una consulta (es decir, seleccionando todos los elementos de una colección determinada que satisfagan un predicado específico). La Figura 27.20 ilustra varios de estos puntos: •
Apertura de la base de datos utilizandoel
•
Inicio y detección de una transacción utilizando las macros OS_BEGIN_TXN y OS_END_TXN (el primer parámetro es un identificador tx1, que simplemente sirve como etiqueta para la transacción). La creación de una extensión para SalesStaff utilizando el método create de la clase de colección os_Se!.
•
método open de la clase de base de datos os_database.
•
La creación de dos raíces nominadas (una para la extensión SalesStaff y otra que corresponde a la sucursal B003) utilizando el método create_root de la clase de base de datos os_database. Este método devuelve un puntero a la nueva raíz (de tipo os_database _roo!), que a continuación se utiliza para especificar el nombre que hay que asociar con la raíz utilizando el método set_value.
•
La creación de una instancia Branch que representa una sucursal B003, seguida de dos instancias de SalesStaff, SG37 y SG14, que luego se añaden como personal de la sucursal B003 utilizando el método addStaff de la clase Branch.
Consultas ObjectStore proporciona diversas formas de extraer objetos de la base de datos, formas que cubren tanto el acceso navegacional como el asociativo. La Figura 27.21 ilustra algunos métodos para extraer objetos: •
Acceso basado en una raíz nominada. En el ejemplo anterior, hemos creado una raíz nominada para la sucursal B003 y ahora podemos utilizar esta raíz para extraer el objeto sucursal B003 y mostrar su número de sucursal, branchNo. Esto se lleva a cabo utilizando los métodos find_rooty get_value, de forma análoga a los métodos create_root y set_value usados en la Figura 27.20.
•
Iteración de colecciones mediante cursores. Habiendo encontrado el objeto de sucursal B003, podemos ahora usar la relación Has para iterar sobre el personal de ventas asignado a dicha sucursal (la
Capítulo 27
Bases de datos orientadas a objetos: estándares y sistemas
843
os_Set *salesStaffExtent = o; mainO { Inicializar ObjectStore e inicializar el uso de colecciones
11
objectstore::initialize(); os_ collection: :initialize(); os_typespec *WorksAtType = Branch::gecos_typespecO; os_typespec *salesStaffExtentType = os_Set::geCos_typespecO; 11
Abrir la base de datos DreamHome
11
os_database *dbl = os_database::open("dreamhomeDB"); Iniciar una transacción OS_BEGIN_TXN(txl,
11
O,
os_transaction::update)
Crear la extensión SalesStaff en esta base de datos y luego crear una raíz nominada salesStaffExtent = &os_Set::create( db 1); db 1->crea tejoot(" salesStaffExtenCRoot") ->set_value( salesStaffExtent, salesStaffExtentType);
11
Crear la sucursal B003 con dos empleados, S037 y S014 Branch* bl("B003"); SalesStaff* sI("SG37"), s2("SG14");
11
Crear una raíz para B003 e indicar que los dos empleados trabajan en esta sucursal db 1->create_root("Branch3JZoot")bl->addStaff(sl);
11
>seC value(b 1, W orksAtType);
b1->addStaff(s2);
Fin de la transacción y cierre de la base de datos
OS_END3XN(txl) db1->closeO; delete dbl; objectstore:: shutdown ();
l
Figura 27.20.
Creación de objetos persistentes y relaciones en ObjectStore.
relación Has fue definida en la Figura 27.19 como una colección, os_Set). El mecanismo de colecciones de ObjectStore prop9Iciona diversas clases para ayudar en la navegación dentro de una colección. En este ejemplo, hemos utilizado el mecanismo de cursor, que se utiliza para designar una posición dentro de una colección (de forma similar al mecanismo de cursor de SQL que se explica en el Apéndice E.1A). Los cursores pueden utilizarse para recorrer colecciones, así como para extraer, insertar, eliminar y sustituir elementos. Para hallar los empleados que trabajan en la sucursal B003, hemos creado una instancia de la clase de plantilla parametrizada os_Cursar, c, utilizando la colección de empleados que se ha definido mediante la relación Has, en este caso aBranch->Has. Podemos a continuación iterar sobre esta colección utilizando los métodos de cursor first(que nos sitúa en el primer elemento del conjunto), next (que nos desplaza al siguiente elemento del conjunto) y more (que determina si hay más elementos en el conjunto). Estos dos primeros ejemplos están basados en el acceso navegacional, mientras que los dos restantes ilustran el acceso asociativo . •
Búsqueda de un único objeto basándose en el valor de uno o más miembros de datos. ObjectStore soporta el acceso asociativo a objetos persistentes. Ilustramos el uso de este mecanismo utilizando la extensión de SalesStaff y, como primer ejemplo, extraemos un elemento de esta extensión empleando el método querLpick, que toma tres parámetros: •
una cadena de caracteres que indica el tipo de elemento de la colección que se está consultando (en este caso, SalesStaff*);
•
una cadena de caracteres que indica la condición que los elementos deben satisfacer para ser seleccionados por la consulta (en este caso, el elemento para el que el miembro de datos staffNotoma el valor SG37);
•
un puntero a la base de datos que contiene la colección que se está consultando (en este caso, db 1).
844
Sistemas de bases de datos
os_Set mainO
Braneh*
= o;
aBranch;
SalesStaft" 11
*salesStaffExtent
{
p;
Inicializar ObjectStore objeetstore:
e inicializar el uso de colecciones
:initialize();
os_typespee
os_ colleetion: :initializeO;
= Braneh::gecos_typespecO;
*WorksAtType
os_typespee *salesStaffExtentType = os_Set::gecos_typespecO; 11 Abrir la base de datos e iniciar una transacción os_database
= os_database::open("dreamhomeDB");
*dbl
OS_BEG1N_TXN(txl,
O,
os_transaetion::update)
11
Consulta
l. Hallar la raíz nominada Branch3 y utilizar un cursor para localizar todos los empleados
11
Consulta 2. Localizar ahora todos los empleados
« cout aBraneh
"Retrieval of branch B003 root:" « aBranch->branchNo « "In"; = (Branch*)(dbl->find_root("Branch3_Root")->geCva1ue(WorksAtTYPe);}
os_ Cursor count
«
for (p
= c.firstO;
with branch
e.moreO;
p->staftNo
«
Consulta 3. Localizar raíz nominada
=
salesStaffExtent
p
cout
«
nominada Iteración de colecciones mediante cursores
B003:
= e.next())
"In"; SalesStaffExtent
y realizar una consulta sobre esta expresión
(os_Set*)
(db 1- >findjoot("salesStaffExtenCRoot")aSalesPerson
>get_ value( salesStaffExtentType);
= salesStaffExtent->query_pick("SalesStaft"",
"Retrieval
of speeifie member
of sales staff: "
"!strcmp(staftNo,
«
aSalesPerson.staftNo
11
Consulta 4. Llevar a cabo otra consulta sobre esta extensión para hallar los empleados
11
(utilizar cursor para recorrer conjunto devuelto) os_Set
&highlyPaidStaff
salesStaffExtent cout «
"Retrieval
= e.firstO;
of highly paid staff:
«
de objetos
"In";
muy bien pagados
In";
"salary > 30000",
Extracción de una colección de objetos
e(highlyPaidStaff);
c.moreO;
cout staftNo OS_END_TXN(
Búsqueda
I"SG371")",
=
- >query("SalesStaff*",
os_Cursor for (p
en una ralZ Acceso b~sado
de esta sucursal
c( aBranch- > Has);
"Staff associated
eout« 11
de esta sucursal
«
p
= c.next())
"In";
xI)
dbl->closeO; delete dbl; o bjectstore::
sh utdown O;
Figura 27.21.
•
Consultas en ObjectStore .
Extracción de una colección de objetos basándose en el valor de uno o más miembros de datos. Para ampliar el ejemplo anterior, utilizamos el método query para devolver una serie de elementos de la colección que satisfacen una condición (en este caso, los empleados cuyo salario sea superior a 30.000 euros). Esta consulta devuelve otra colección y de nuevo utilizamos un cursor para iterar sobre los elementos de la colección y mostrar el número de empleado staffNo.
En esta sección sólo hemos realizado un breve esbozo de las características del SGBDOO ObjectStore. El lector interesado puede consultar la documentación del sistema ObjectStore para obtener más información.
Resumen del capítulo •
Object Management Group (OMG) es un consorcio internacional sin ánimo de lucro fundado por diversas empresas en 1989 para abordar el desarrollo de estándares aplicables a objetos. Los principales obje-
Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas
845
tivos de OMO son la promoción de las técnicas de orientación a objetos en la ingeniería del software y el desarrollo de estándares en los que la ubicación, el entorno, el lenguaje y otras características de los objetos sean completamente transparentes para los demás objetos. •
En 1990, OMO publicó su primer documento sobre la arquitectura OMA (Object Management Architecture). Dicha arquitectura especificaba una terminología unificada para los lenguajes, sistemas, bases de datos y entornos de aplicación orientados a objetos. Un marco de trabajo abstracto para los sistemas orientados a objetos; un conjunto de objetivos técnicos y arquitectónicos; y un modelo de referencia Nra aplicaciones distribuidas que utilizaran técnicas de orientación a objetos. Se identificaron cuatro áreas de estandarización para el modelo de referencia: el modelo de objetos (OM, Object Model), el gestor de solicitudes de objeto (ORB, Object Request Broker), los servicios de objetos y las facilidades comunes.
•
CORBA define la arquitectura de los entorno s basados en un ORB. Esta arquitectura es la base de todo componente OMO, definiendo las partes que forman el ORB y sus estructuras asociadas. Utilizando OIOP o IIOP, un programa basado en CORBA puede interoperar con otro programa basado en CORBA en diversas plataformas, sistemas operativos, lenguajes de programación y redes de distintos fabricantes. Entre los elementos de CORBA podemos citar un lenguaje de definición de interfaces (IDL, Interface Definition Language) que es neutral con respecto a la implementación, un modelo de tipos, un repositorio de interfaces, métodos para obtener las interfaces y las especificaciones de los objetos y métodos para transformar hacia y desde cadenas de caracteres los identificadores OID.
•
OMO también ha desarrollado diversas otras especificaciones, incluyendo el lenguaje UML (Unified Modeling Langliage), que proporciona un lenguaje común para describir modelos software; MOF (MetaObject Facility), que define un lenguaje abstracto común para la especificación de metamodelos (CORBA, UML y CWM son metamodelos compatibles con MOF); XMI (XML Metadata Interchange), que establece la correspondencia entre MOF y XML; Y CWM (Common Warehouse Metamodel), que define un metamodelo para los metadatos que se suelen encontrar en los campos de los almacenes de datos y de los sistemas de inteligencia empresarial.
•
OMO ha introducido también la arquitectura MDA (Model-Driven Architecture) como técnica para la especificación e interoperabilidad de sistemas, técnica que se apoya sobre las cuatro anteriores especificaciones de modelado. Está basada en la premisa de que los sistemas deberían poder identificarse independientemente de los detalles hardware y software. Así, mientras que el hardware y el software pueden cambiar a lo largo del tiempo, la especificación continuaría siendo aplicable. Lo más importante es que MDA contempla el ciclo de vida completo de los sistemas, desde el análisis y el diseño hasta la implementación, las pruebas, el ensamblado de componentes y la implantación.
•
Object Data Management Group (ODMG) fue formado por varios de los principales fabricantes para definir estándares para sistemas SOBDOO. ODMO generó un modelo de objetos que especifica un modelo estándar para la semántica de los objetos de base de datos. Este modelo tiene una gran importancia, porque determina la semántica predefinida que los SOBDOO comprenden y pueden imponer. El diseño de bibliotecas de clases y de aplicaciones que utilicen esta semántica debería ser portable entre los diversos SOBDOO que soporten dicho modelo de objetos.
•
Los principales componentes de la arquitectura ODMO para un SOBDOO son: un modelo de objetos (OM, Object Model), un lenguaje de definición de objetos (ODL, Object Definition Language), un lenguaje de consulta de objetos (OQL, Object Query Language) y una serie de enlaces de lenguajes con C++, Java y Smalltalk.
•
El modelo de objetos de ODMO es un superconjunto del modelo de objetos de OMO, permitiendo portar tanto los diseños como las implementaciones entre diversos sistemas compatibles. Las primitivas básicas de modelado son el objeto y el literal. Sólo los objetos tienen identificadores unívocos. Los objetos y literales pueden clasificarse en tipos. Todos los objetos y literales de un mismo tipo exhiben un comportamiento y un estado comunes. El comportamiento se define mediante un conjunto de operaciones que pueden realizarse sobre o por el objeto. El estado se define mediante los valores que el objeto tiene para una serie de propiedades. Las propiedades pueden ser atributos del objeto o relaciones entre el objeto y uno o más objetos distintos.
846
Sistemas de bases de datos
•
El lenguaje de definición de objetos (ODL) es un lenguaje para definir las especificaciones de los tipos de objetos para los sistemas compatibles con ODMG, lenguaje equivalente al lenguaje de definición de datos (DDL) de un SGBD tradicional. El ODL define los atributos y relaciones de los tipos y especifica la signatura de las operaciones, pero no contempla ningún detalle sobre la implementación de las signaturas .
•
El lenguaje de consulta de objetos (ODL) proporciona acceso declarativo a la base de datos de objetos utilizando una sintaxis parecida a la de SQL. No proporciona operadores explícitos de actualización, sino que deja esto a las operaciones definidas sobre los tipos de objetos. Una consulta OQL es una función que devuelve un objeto cuyo tipo puede inferirse del operador que contribuye a formar la expresión de consulta. OQL puede utilizarse para acceso tanto asociativo como navegación.
Cuestiones de repaso 27.1.
Explique los conceptos principales del modelo de objetos ODMG. Proporcione un ejemplo para ilustrar cada uno de estos conceptos.
27.2.
¿Cuál es la función del lenguaje de definición de objetos de ODMG?
27.3.
¿Cuál es la función del lenguaje de manipulación de objetos de ODMG?
27.4.
¿En qué se diferencia la cláusula GROUP BY de ODMG de la cláusula GROUP BY de SQL?
27.5.
¿En qué se diferencian las funciones de agregación de ODMG de las SQL? Proporcione un ejemplo para ilustrar su respuesta.
27.6.
¿Cuál es la función del formato de intercambio de objetos de ODMG?
27.7.
Explique brevemente cómo funciona el enlace con el lenguaje C++ de ODMG.
Ejercicios 27.8.
Realice un mapeado del diseño de base de datos orientado a objetos para el caso de estudio Hotel que hemos generado en el Ejercicio 26.14 y luego muestre cómo se escribirían las siguientes consultas en OQL: (a)
Enumerar todos los hoteles.
(b)
Enumerar todas las habitaciones individuales con un precio inferior a 20 euros por noche.
(c)
Enumerar los nombres y ciudades de todos los huéspedes.
(d)
Enumerar el precio y el tipo de todas las habitaciones del Hotel Grosvenor.
(e)
Enumerar todos los clientes actualmente alojados en el Hotel Grosvenor.
(f) Enumerar los detalles de todas las habitaciones del Hotel Grosvenor, incluyendo el nombre del huésped que está alojado en la habitación, si es que la habitación está ocupada. (g) Enumerar los detalles de los huéspedes que estén alojados en el Hotel Grosvenor.
(guestNo,
guestName
y
guestAddress)
para todos los huéspedes
Compare las respuestas escritas para OQL con las expresiones equivalentes de álgebra relacional y cálculo relacional escritas en el Ejercicio 4.12. 27.9.
Realice un mapeado del diseño de base de datos orientado a objetos para el caso de estudio DreamHome generado en el Ejercicio 26.15 en el lenguaje ODL de ODMG.
27.10. Realice un mapeado del diseño de base de datos orientado a objetos para el caso de estudio University Accommodation Office generado en el Ejercicio 26.16 en el lenguaje ODL de ODMG. 27 .11. Realice un mapeado del diseño de base de datos orientado a objetos para el caso de estudio EasyDrive School of Motoring generado en el Ejercicio 26.17 en el lenguaje ODL de ODMG. 27.12. Realice un mapeado del diseño de base de datos orientado a objetos para el caso de estudio Wellmeadows generado en el Ejercicio 26.18 en el lenguaje ODL de ODMG.
Capítulo
Bases de datos objeto-relacionales Objetivos del capítulo: En este capítulo aprenderá: •
Cómo se ha ampliado el modelo relacional para soportar aplicaciones avanzadas de base de datos.
•
Las características propuestas en los manifiestos sobre sistemas de base de datos de tercera generación presentados por CADF y Darwen y Date.
•
Las ampliaciones al modelo de datos relacional introducidas en Postgres.
•
Las características incluyen:
de orientación a objetos en el nuevo estándar SQL, denominado
SQL:2003, que
•
tipos de filas;
•
tipos definidos por el usuario y rutinas definidas por el usuario;
• •
polimorfismo; herencia;
•
tipos de referencia e identidad de los objetos;
•
tipos de colección (ARRAY, MULTISET, SET
•
ampliaciones al lenguaje SQL para hacerlo computacionalmente
•
disparadores;
•
soporte para objetos de gran tamaño: objetos binarios de gran tamaño BLOB (Binary Large Object) y objetos de carácter de gran tamaño CLOB (Character Large Objects); recursión.
•
Y
LIST); completo;
•
Ampliaciones requeridas en el procesamiento los tipos de consultas avanzadas.
y optimización de consultas relacionales para soportar
•
Algunas ampliaciones orientadas a objetos de Oracle.
•
Las similitudes y diferencias de los SGBDOO y LOS SGBDOR en términos de modelado de datos, acceso a datos y compartición de datos.
En los Capítulos 25 a 27 hemos examinado algunos de los conceptos básicos de la orientación a objetos y de los sistemas de gestión de bases de datos orientada a objetos (SGBDOO). En el Capítulo 25 hemos examinado también los tipos de aplicaciones avanzadas de bases de datos que están surgiendo y las debilidades de los SGBDR actuales que hacen que éstos no resulten adecuados para dichos tipos de aplicaciones. En los Capítulos 26 y 27 hemos hablado de los SGBDOO en detalle y de los mecanismos que hacen que éstos sí que resulten más adecuados en esos entornos de aplicación. En respuesta a las debilidades de los sistemas relacionales y como defensa frente a la potencial amenaza que constituye el ascenso de los SGBDOO, la comunidad de fabricantes de SGBDR ha ampliado estos sistemas con características de orientación a objetos, lo que ha
848
Sistemas de bases de datos
hecho surgir los denominados SGBDR objeto-relacionales (SGBDOR). En este capítulo vamos a examinar algunas de estas ampliaciones y vamos a ver cómo ayudan a resolver muchas de las debilidades citadas en la Sección 25.2. También examinaremos algunos de los problemas que se derivan de estas nuevas ampliaciones.
Estructura del capítulo En la Sección 28.1 se examinan los fundamentos de los SGBDOR y los tipos de aplicaciones para los que pueden resultar adecuados. En la Sección 28.2 veremos los manifiestos de tercera generación basados en el modelo de datos generacional, los cuales proporcionan ideas ligeramente distintas sobre cómo será la siguiente generación de sistemas SGBD. En la Sección 28.3 se analiza uno de los primeros SGBDR en ser ampliados, a lo cual sigue en la Sección 28A una visión detallada de las principales características del estándar SQL: 1999 y del estándar SQL:2003. En la Sección 28.5 presentaremos parte de la funcionalidad que un SGBDOR requiere y que no está cubierta por SQL. En la Sección 28.6 se realiza un repaso de algunas de las ampliaciones orientadas a objetos que han sido añadidas a Oracle, uno de los más conocidos SGBDOR. Finalmente, en la Sección 28.7 se incluye un resumen de las diferencias entre los SGBDOR y los SGBDOO. Para poder sacar el máximo provecho de este capítulo, el lector debe estar familiarizado con el contenido del Capítulo 25. De nuevo, los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome que se documenta en la Sección lOA y en el Apéndice A.
28.1 Introducción a los sistemas de bases de datos objeto-relacionales Los SGBD relacionales son la tecnología dominante de base de datos en la actualidad, con unas ventas estimadas de entre 6 y 10.000 millones de dólares por año (25.000 millones si incluimos las ventas de herramientas). Los SGBDOO, de los que hemos hablado en los Capítulos 26 y 27 comenzaron su andadura en los dominios de la ingeniería y del diseño y también se han convertido recientemente en el tipo de sistema favorito para aplicaciones financieras y de telecomunicaciones. Aunque el mercado de los SGBDOO continúa siendo pequeño, este tipo de sistemas sigue encontrando cada día nuevas áreas de aplicación, como por ejemplo la Web (como veremos en detalle en el Capítulo 29). Algunos analistas del sector esperan que el mercado de los SGBDOO crezca a una tasa superior a la del mercado total de bases de datos. Sin embargo, es bastante improbable que sus ventas lleguen a igualar a las de los sistemas relacionales, debido a la cantidad de empresas para las que los SGBDR resultan aceptables y debido a que estas empresas han invertido tanto dinero y recursos en el desarrollo de este tipo de bases de datos que cualquier cambio resulta prohibitivo. Hasta hace poco, las dos únicas elecciones de SGBD parecían ser el SGBD relacional y el SGBD orientado a objetos. Sin embargo, muchos fabricantes de sistemas SGBDR son conscientes de las amenazas y del potencial inherentes a los SGBDOO. Estos fabricantes están de acuerdo en que los SGBD relacionales tradicionales no son adecuados para los tipos de aplicaciones avanzadas de los que hemos hablado en la Sección 25.1, Y que hace falta añadir determinadas funcionalidades. Sin embargo, afirman que basta con ampliar los SGBDR con la suficiente funcionalidad para cubrir las demandas de esas aplicaciones, y rechazan los argumentos de quienes dicen que ese tipo de sistemas ampliados no tendrían funcionalidad suficiente o serían demasiado lentos para poder tratar adecuadamente con aplicaciones tan complejas. Si examinamos las aplicaciones avanzadas de base de datos que están surgiendo, podemos ver que hacen un uso intensivo de muchas características de orientación a objetos, como por ejemplo la existencia de un sistema de tipos ampliable por el usuario, la encapsulación, la herencia, el polimorfismo, el enlace dinámico de métodos, la existencia de objetos complejos (incluyendo objetos que no están en primera forma normal) y los mecanismos de identidad de los objetos. La forma más obvia de remediar las carencias del modelo relacional consiste en ampliar el modelo con este tipo de características. Este es el enfoque que ha sido adoptado por muchos SGBD relacionales que han sido ampliados en los últimos años, aunque cada uno de estos sistemas ampliados implementa diferentes combinaciones de características. Por tanto, no hay un único modelo relacional ampliado, sino una diversidad de dichos modelos, cuyas características dependen de la forma y del
Capítulo 28 Bases de datos objeto-relacionales
849
grado en que se han llevado a cabo las ampliaciones funcionales. Sin embargo, todos los modelos si que comparten las mismas tablas relacionales básicas y el mismo lenguaje de consulta, todos ellos incorporan algún tipo de concepto de 'objeto' y algunos de ellos tienen la capacidad de almacenar métodos (o procedimientos, o disparadores) en la base de datos, además de almacenar los datos propiamente dichos. Son varios los términos que se han utilizado para designar a ese tipo de sistemas que amplían el modelo de datos relaciona!. El término original empleado para describir tales sistemas era el de: SGBD relacional extendido (SGBDRE). Sin embargo, en los últimos años se ha impuesto el término más descriptivo SGBD objeto-relacional, para indicar que el sistema incorpora una cierta noción de 'objeto', y también el término servidor universal o SGBD universal (SGBDU), aunque esta denominación ha tenido menos éxito. En este capítulo vamos a usar el término SGBD objeto-relacional (SGBDOR). Tres de los principales fabricantes de sistemas SGBDR (Oracle, Microsoft e IBM) han ampliado sus sistemas para obtener un SGBDOR, aunque la funcionalidad proporcionada por cada uno de los productos es ligeramente distinta. El concepto de SGBDOR, como híbrido entre un SGBDR y un SGBDOO, resulta muy atractivo, ya que preserva los conocimientos y las experiencias adquiridos con los sistemas relacionales tradicionales. Hasta tal punto es así, que algunos analistas dicen que los SGBDOR tendrán una cuota de mercado un 50% superior que los SGBDR convencionales. Como cabía esperar, la actividad de estandarización en este área está basada en ampliaciones del estándar SQL. Las organizaciones de normalización nacionales han estado trabajando en extensiones orientadas a objetos de SQL desde 1991. Estas extensiones se han convertido en parte del estándar SQL, habiéndose publicado dos versiones, SQL:1999 y 2003. Estas versiones del estándar SQL son un intento, que todavía continua, de estandarizar las ampliaciones al modelo relacional y al lenguaje de consulta. Hablaremos de las extensiones orientadas a objetos de SQL con un cierto detalle en la Sección 28.4. En este libro, generalmente utilizaremos el término SQL:2003 para referimos tanto a la versión de 1999 como a la de versión de 2003 del estándar.
El punto de vista de Stonebraker Stonebraker (1996) ha propuesto una imagen del mundo de las bases de datos dividido en cuatro cuadrantes, como se ilustra en la Figura 28.1. En el cuadrante inferior izquierdo vemos esas aplicaciones que procesan datos simples y no tienen ningún requisito para la consulta de los datos. Este tipo de aplicación, como por ejemplo de los procesadores de texto estándar de tipo Word, WordPerfect y Framemaker, puede utilizar el sistema operativo subyacente para obtener la funcionalidad esencial de persistencia típica de los SGBD. En el cuadrante inferior derecho vemos aquellas aplicaciones que procesan datos complejos pero que, de nuevo, no tienen necesidades significativas de consultar los datos. Para estos tipos de aplicaciones, como por ejemplo paquetes de diseño asistidos por computadora, un SGBDOO puede resultar apropiado. En el cuadrante superior izquierdo se encuadran las aplicaciones que procesan datos simples, pero que también necesitan efectuar
Capacidades de búsqueda/soporte multiusuario
SGBD relacional
SGBD objeto-relacional
Sistemas de archivos
SGBD orientado a objetos
Complejidad de los datos/ampliabilidad
Figura 28.1
-
850
Sistemas de bases de datos
consultas complejas. Muchas aplicaciones empresariales tradicionales caen dentro de este cuadrante y para ellas un SGBDR puede ser lo más apropiado. Finalmente, en el cuadrante superior derecho vemos aquellas aplicaciones que procesan datos complejos y tienen necesidades complejas de consultas. Este es el cuadrante donde encajan muchas de las aplicaciones avanzadas de base de datos que hemos examinado en la Sección 25.1, y para estas aplicaciones es posible que los SGBDOR sean el tipo de SGBD más apropiado. Aunque se trata de una visión interesante, esta aplicación es muy simplista y desafortunadamente muchas aplicaciones de base de datos no se pueden compartimentalizar tan fácilmente. Además, con la introducción del modelo de datos y del lenguaje de consulta de ODMG, del que hemos hablado en la Sección 27.2, y con la adición a SQL de las características de gestión de datos orientada a objetos, la diferencia entre los SGBDOR y los SGBDOO es cada vez menos clara.
Ventajas de los SGBDOR Además de la ventaja de que resuelven muchas de las debilidades citadas en la Sección 25.2, las principales ventajas de ampliar el modelo de datos relacional provienen de la reutilización y de la compartición. La reutilización surge de la capacidad de ampliar el servidor SGBD para implementar funcionalidad estándar de manera central, en lugar de codificar dicha funcionalidad en cada aplicación. Por ejemplo, las aplicaciones pueden requerir tipos de datos espaciales que representen puntos, líneas y polígonos, con una serie de funciones asociadas que calculen la distancia entre dos puntos, la distancia entre un punto y una línea; que comprueben si un punto está contenido dentro de un polígono o que verifique si dos regiones poligonales se solapan, entre otras muchas funciones. Si pudiéramos incrustar esta funcionalidad en el servidor, nos evitaríamos tener que definida en cada aplicación donde esa funcionalidad fuera necesaria, lo que permitiría que la funcionalidad fuera compartida por todas las aplicaciones. Estas ventajas también hacen que aumente la productividad tanto del desarrollador como del usuario final. Otra ventaja obvia es que la técnica relacional ampliada preserva todo el cuerpo de conocimiento y de experiencia que se ha ganado con el desarrollo de aplicaciones relacionales en las últimas décadas. Se trata de una ventaja muy significativa, ya que para muchas organizaciones sería prohibitivamente caro efectuar un cambio. Si se diseña apropiadamente la nueva funcionalidad, esta técnica debería permitir a las organizaciones aprovechar las nuevas aplicaciones de manera evolutiva, sin perder los beneficios derivados de las características y funciones de las bases de datos actlJ.l;lles.Así, los SGBDOR pueden introducirse de forma gradual, como proyectos que permitan verificar las posibles ventajas. El estándar SQL:2003 está diseñado para ser compatible en sentido descendente con el estándar SQL2, por lo que cualquier SGBDOR que cumpla con SQL:2003 podrá implementarse de manera evolutiva sobre los sistemas ya existentes.
Desventajas de los SGBDOR La utilización de un SGBDOR tiene dos desventajas obvias: la complejidad y el incremento de coste. Además, algunos partidarios del método relacional creen que con este tipo de ampliaciones se pierden la simplicidad y la pureza esenciales que constituían las grandes ventajas del modelo relacional. También hay otros autores que creen que los SGBDR se están ampliando para cubrir una minoría de aplicaciones, que son las que no pueden conseguir un rendimiento óptimo con la tecnología relacional actual. Por otro lado, los puristas de la orientación a objetos tampoco se sienten complacidos con este tipo de ampliaciones. Argumentan que la terminología de los sistemas objeto-relacionales es muy reveladora: en lugar de hablar de modelos de objetos, se utilizan términos como 'tipos de datos definidos por el usuario'. La terminología de la orientación a objetos está plagada de términos como 'tipos abstractos', 'jerarquías de clases' y 'modelos de objetos'. Sin embargo, los fabricantes de sistemas SGBDOR están tratando de contemplar los modelos de objetos como meras extensiones del modelo relacional, al que se añaden algunas complejidades adicionales. Esto tiene el peligro de que se pierda el verdadero objetivo de la orientación a objetos, lo que pone de manifiesto que existe una gran diferencia semántica entre estas dos tecnologías. Las aplicaciones de objetos no están tan centradas en los datos como las aplicaciones relacionales. Los modelos y programas orientados a objetos combinan de manera profunda las relaciones y los objetos encapsulados para hacer que el modelo se asemeje más estrechamente al 'mundo real'. Esto define un conjunto más amplio de relaciones que las que puede expresarse en SQL, e implica que una serie de programas funcionales se imbriquen en las propias
Capítulo 28 Bases de datos objeto-relaciona les
851
definiciones de los objetos. De hecho, los objetos no son extensiones de los datos, sino un concepto completamente distinto con una mayor capacidad de expresar relaciones y comportamientos del 'mundo real'. En el Capítulo 5 hemos señalado que entre los objetos de un lenguaje de base de datos se incluía la capacidad de poder utilizar con un mínimo esfuerzo, y de tener una sintaxis y una estructura de comandos que fueran relativamente sencillos de aprender. El estándar SQL inicial, publicado en 1989, satisfacía aparentemente estos objetivos. La versión de 1992 se incrementó en tamaño, pasando de 120 a aproximadamente 600 páginas, y resulta cuestionable si cumplía con esos objetivos mencionados. Desafortunadamente, el tamaño del estándar SQL:2003 es todavía mayor, por lo que cabría pensar que estos dos objetivos ya no están siendo conseguidos, o a lo mejor es que ya ni siquiera están siendo tomados en consideración por los organismos de estandarización.
28.2 Los manifiestos de las bases de datos de tercera generación El éxito de los sistemas relacionales en la década de 1990 es evidente. Sin embargo, existe una importante discusión en lo que concierne a la siguiente generación de sistemas SGBD. Los tradicionalistas creen que basta con ampliar el modelo relacional con capacidades adicionales. Por un lado, un influyente grupo ha publicado el manifiesto de los sistemas de base de datos orientados a objetos basado en el paradigma de la orientación a objetos, manifiesto que hemos presentado en la Sección 26.1.4 (Atkinson et al., 1989). Por otro lado, el comité CADF (Committee for Advanced DBMS Function) ha publicado el manifiesto de los sistemas de bases de datos de tercera generación, que define una serie de principios que un SGBD debería cumplir (Stonebraker et al., 1990). Más recientemente, Darwen y Date (1995, 2000) han publicado el Tercer manifiesto en defensa del modelo de datos relacional. En esta sección vamos a examinar estos dos últimos manifiestos.
28.2.1 El manifiesto de los sistemas de bases de datos de tercera-generación El manifiesto publicado por CADF propone las siguientes características para un sistema de bases de datos de tercera generación: (1) Un SGBD de tercera generación debe contar con un sistema de tipos suficientemente rico. (2) La herencia resulta muy conveniente. (3) Las funciones, incluyendo los procedimientos y métodos de base de datos y la encapsulación, adición deseable.
son una
(4) Los identificadores unívocos para los registros deben ser asignados por el SGBD sólo cuando no esté disponible una clave principal definida por el usuario. (5) Las reglas (disparadores, restricciones) constituirán una característica de gran importancia en los sistemas futuros. No deben estar asociadas con una colección o función específicas. (6) Esencialmente, todo el acceso programático a una base de datos debe realizarse a través de un lenguaje de acceso no procedimental y de alto nivel. (7) Debe haber al menos dos formas de especificar colecciones, una que utilice una enumeración de los miembros y otra que utilice el lenguaje de consulta para especificar la pertenencia. (8) Las vistas actualizables son esenciales. (9) Los indicadores de rendimiento no tienen prácticamente debe aparecer en éstos.
nada que ver con los modelos de datos y no
(10) Los SGBD de tercera generación deben ser accesibles desde múltiples lenguajes de alto nivel. (11) Resulta conveniente utilizar formas persistentes de un lenguaje de alto nivelo de una diversidad de lenguajes de alto nivel. Esos lenguajes serán soportados sobre un mismo SGBD mediante extensiones del compilador y mediante un sistema de ejecución complejo.
852
Sistemas de bases de datos
(12) Para bien o para mal, SQL es ya un lenguaje universal. (13) Las consultas y sus correspondientes entre un cliente y un servidor.
respuestas deben constituir el nivel de comunicación más bajo
28.2.2 El Tercer manifiesto El Tercer manifiesto de Darwen y Date (1995, 2000) trata de defender el modelo de datos relacional que los autores habían descrito en su libro de 1992 (Date y Darwen, 1992). Reconocen que ciertas características de orientación a objetos son deseables, pero creen que dichas características son ortogonales al modelo relacional, por lo que 'el modelo relacional no necesita ninguna extensión, ni corrección ni ampliación ni, por encima de todo, ninguna perversión'. Sin embargo, los autores rechazan inequívocamente SQL como una perversión del modelo y proponen, en su lugar, un leguaje denominado D. Los autores sugieren que se añada un módulo de interfaz a D que permita utilizar SQL, proporcionando así una ruta de migración para los usuarios de SQL existentes. El manifiesto propone que el lenguaje D esté sujeto a: (1) una serie de prescripciones que surgen del modelo relacional, denominadas prescripciones (2) una serie de prescripciones que no surgen del modelo relacional, denominadas ortogonales' (prescripciones 00);
RM;
'otras prescripciones
(3) una serie de proscripciones que surgen del modelo relacional, denominadas proscripciones
RM;
(4) una serie de proscripciones que no surgen del modelo relacional, denominadas proscripciones
OO.
Además, el manifiesto enumera una serie de sugerencias basadas en el modelo relacional y otra serie de sugerencias basadas en consideraciones ortogonales. Las propuestas se enumeran en la Tabla 28.1. El objetivo principal de la propuesta es el dominio, definido como un conjunto nominado de valores encapsulados, de complejidad arbitraria, equivalente a un tipo de datos o a una clase de objetos. Los valores de dominio se denominan genéricamente escalares, los cuales sólo pueden manipularse mediante operadores definidos para ese dominio. El lenguaje D incluye algunos dominios predefinidos, como el dominio de los valores de verdad con los operadores booleanQ.s normales (AND, OR, NOT, etc.). El operador de comparación de igualdad (=) está definido para todo dominio, devolviendo el valor booleano TRUE si y sólo si los dos miembros del dominio son el mismo. Se propone que exista tanto herencia simple como múltiple en los domimos. Las relaciones, las tuplas y los encabezados de tupla tienen su significado normal, introduciéndose sendos constructores de tipos RELATION y TUPLE para estos objetos. Además, se definen las siguientes variables: •
Variable escalar de tipo V Variable cuyos valores permitidos son escalables de un dominio especificado V.
•
Variable de tupla de tipo H. Variable cuyos valores permitidos son tuplas con un encabezado de tupla especificado H.
•
Variable de relación (relvar) de tipo H. Variable cuyos valores permitidos son relaciones con un encabezado de relación especificado H.
•
Variable de base de datos (dbvar). Un conjunto nominado de relvars. Cada dbvar está sujeto a un conjunto de restricciones-de integridad nominadas y tienen un catálogo auto-descriptivo asociado.
Cada transacción está restringida a interactuar con sólo un dbvar, pero puede añadir/eliminar relvars dinámicamente de dicha dbvar. Es obligatorio que se soporten transacciones anidadas. También se propone que el lenguaje D: •
Represente el álgebra relacional 'sin excesivos circunloquios'.
•
Proporcionar operadores para crear/destruir funciones nominadas, cuyo valor es una relación definida por medio de una expresión relacional especificada.
•
Soportar los operadores de comparación: (= y ?) para las tuplas;
Capítulo 28 Bases de datos objeto-relacionales
853
(=,
of-, 'es un subconjunto de', E para comprobar la pertenencia de una tupla a una relación) para las relaciones . Ser construido de acuerdo con los principios aceptados de diseño de un lenguaje.
•
Tabla 28.1 Prescripciones
Propuestas del Tercer manifiesto. (7) No hay operaciones de nivel de tupla
RM
Tipos escalares
(8)
(2)
Los valores escalares están tipados
(9) No hay anulación de las comprobaciones
(3)
Operadores escalares
(10)
(1)
(4)
Representación
(5)
Exponer representaciones
real y representación
(6)
Generador de tipos TUPLE
(7)
Generador de tipos RELATION
(8)
Igualdad
{9)
Tuplas
posible
posibles
No hay columnas compuestas
No se utiliza SQL
Prescripciones (1)
de dominio
00
Comprobación
de tipos en tiempo de compilación
(2)
Herencia simple (condicional)
(3)
Herencia múltiple (condicional)
(4)
Completud computacional
(5)
Fronteras de transacción explícitas
(6)
Transacciones
(10)
Relaciones
(11)
Variables escalares
(12)
Variables de tupla
(13)
Variables de relación (relvars)
Proscripciones
(14)
Relvars base y relvars virtuales
(1 ) Las relvars no son dominios
(15)
Claves candidatas
(2) No hay identificadores
(16)
Bases de datos
Sugerencias
(17)
Transacciones
(1)
(18)
Álgebra relacional
(2)
Claves externas
(19)
Nombres de relvars, selecto res de relación y recursión
(3)
Inferencia de claves candidatas
(4)
Restricciones
(20)
Operadores cuyo valor es una relación
(5)
(21)
Asignación
Consultas de cuota (por ejemplo, 'encontrar los tres empleados más jóvenes')
(22)
Comparadores
(6)
Cierre transitivo generalizado
(23)
Restricciones de integridad
(7)
Parámetros de tupla y de relación
(24)
Predicados de relación y de base de datos
(8)
Valores especiales ('predeterminados')
(25)
Catálogo
(9)
Migración desde SQL
(26)
Diseño del lenguaje RM
00 de objetos
RM
Claves del sistema
Sugerencias Proscripciones
anidadas
(7) Agregados y conjuntos vacíos
de transición
00
(1)
Herencia de tipos
(1)
No hay ordenación de los atributos
(2)
No inclusión de tipos y operadores
(2)
No hay ordenación de las tuplas
(3)
Generadores de tipos de colección
(3) No hay tuplas duplicadas
(4)
Conversión aldesde relaciones
(4)
(5) Almacenamiento
No hay valores nulos
en un único nivel
(5) No hay errores nulológicos' (6)
No hay estructuras de nivel interno
'Darwen
define la nulología como el 'estudio de nada en absoluto',
lo que quiere decir el estudio del conjunto vacío. Los conjuntos
son un aspecto importante de la teoría relacional y el manejo correcto del conjunto vacío se considera fundamental ciona!.
(
para la teoría rela-
854
Sistemas de bases de datos
28.3 Postgres: un SGBDOR pionero En esta sección vamos a examinar un SGBD objeto-relacional pionero, Postgres ('Post INGRES '). El objetivo de esta sección es proporcionar detalles sobre el modo en que algunos investigadores han tratado de ampliar los sistemas relacionales. Sin embargo, lo que se espera es que muchos SGBDOR comerciales de gran popularidad se adapten al estándar SQL:2003 (al menos hasta un cierto punto). Postgres es un sistema desarrollado como proyecto de investigación por parte de los diseñadores de INGRES, como intento de ampliar el modelo relacional con tipos abstractos de datos, procedimientos y reglas. Postgres tuvo una gran influencia en el desarrollo de las extensiones orientadas a objetos efectuadas en el producto comercial INGRES. Uno de sus principales diseñadores, Mike Stonebraker, diseñó posteriormente el SGBDOR para Illustra.
28.3.1
Objetivos de Postgres
Postgres es un sistema de base de datos experimental diseñado como potencial sucesor del SGBDR INGRES (Stonebraker y Rowe, 1986). Los objetivos del proyecto eran: (1) proporcionar un mejor soporte para objetos complejos; (2) proporcionar ampliabilidad para tipos de datos, operadores y métodos de acceso por parte del usuario; (3) proporcionar funcionalidades mos de inferencia;
activas a la base de datos (alertas y disparadores) y soporte de mecanis-
(4) simplificar el código SGBD de cara a la recuperación en caso de errores catastróficos; (5) realizar un diseño que pudiera aprovechar las ventajas ofrecidas por los discos ópticos, las estaciones de trabajo multiprocesador y por los chips VLSI de propósito especial; (6) realizar los menos cambios posibles (preferiblemente
ninguno) en el modelo relaciona!.
Postgres amplió el modelo relacional para incluir los siguientes mecanismos: •
tipos abstractos de datos;
•
datos de tipo 'procedimiento';
•
reglas.
Estos mecanismos se utilizan para soportar diversas estructuras semánticas y de modelado de datos orientados a objetos, incluyendo mecanismos de agregación, generalización, objetos complejos con subobjetos compartidos y atributos que hacen referencia a tuplas de otras relaciones.
28.3.2 Tipos abstractos de datos El tipo de un atributo en una relación puede ser atómico o estructurado. Postgres proporciona un conjunto de tipos atómicos predefinidos: int2, int4, float4, float8, bool, char y date. Los usuarios pueden añadir nuevos tipos atómicos y tipos estructurados. Todos los tipos de datos se definen como tipos abstractos de datos (TAD). La Definición de un TAD incluye un nombre de tipo, su longitud en bytes, los procedimientos para convertir un valor entre la representación interna y la externa (y viceversa) y un valor predeterminado. Por ejemplo, el tipo int4 se define internamente como: DEFINE TYPE int4 IS (InternalLength = 4, InputProc = CharToInt4, OutputProc = Int4 ToChar, Default = "O") Las procedimientos de conversión CharToInt4 y Int4ToChar se implementan en algún lenguaje de programación de alto nivel tal como C y se los da a conocer al sistema utilizando una instrucción DEFINE PROCEDURE. Un operador para los TAD se define especificando el número y el tipo de los operandos, el tipo de retorno, la precedencia y asociatividad del operador y el procedimiento que lo implementa. La definición del operador también puede especificar procedimientos a los que invocar, por ejemplo, para ordenar la relación cuando se seleccione la estrategia de ordenación-mezcla para implementar la consulta (Sort) y para negar el operador en un predicado de consulta (Negator). Por ejemplo, podríamos definir un operador '+' para sumar dos enteros de la forma siguiente:
Capítulo 28 Bases de datos objeto-relacionales
855
OPERATOR "+" (int4, int4) RETURNS int4 IS (Proc = Plus, Precedence = 5, Associativity = "left")
DEFINE
De nuevo, el procedimiento Plus que implementa el operador '+' se programaría en un lenguaje de alto nivel. Los usuarios pueden definir sus propios tipos atómicos de forma similar. Los tipos estructurados se definen utilizando constructores de tipo para matrices y procedimientos. Una matriz de longitud variable o de longitud fija se define utilizando un constructor de matriz. Por ejemplo, char[25] define una matriz de caracteres de longitud fija igual a 25. Si se omite el tamaño, la matriz tendrá longitud variable. El constructor de procedimientos permite asignar valores de tipo 'procedimiento' a un atributo, donde un procedimiento es una serie de comandos escritos en Postquel, el lenguaje de consulta de Postgres (el tipo correspondiente se denomina tipo de datos postquel).
28.3.3 Relaciones y herencia Una relación (tabla) en Postgres se declara utilizando el siguiente comando: CREATE
NombreTabla (Nombrecolumna1 = typel,
Nombrecolumna2 = type2, ...)
[KEY (listaDeNombresColumnas)] [INHERITS(listaDeNombresTablas)
]
Una relación hereda todos los atributos de sus padres, a menos que un cierto atributo sea sustituido en la propia definición. Se soporta la herencia múltiple, pero si puede heredarse el mismo atributo de más de un padre y los tipos de los atributos son diferentes, la declaración será ilegal. Las especificaciones de clave también se heredan. Por ejemplo, para crear una entidad 8taff que herede los atributos de Person, escribiríamos:
= char[15],
IName = char[15], sex
=
char, dateOfBirth
KEY(IName, dateOfBirth) CREATE 8taff (staffNo = char[5], position = char[lO], salary branchNo ="char[4], manager = postquel)
=
float4,
CREATE
Person (fName
=
date)
INHERITS(Person)
La relación 8taff incluye los atributos declarados explícitamente, además de los atributos declarados para PersonoLa clave es la heredada de PersonoEl atributo manager se define como de tipo postquel para indicar que se trata de una consulta Postquel. Para añadir una tupla a la relación 8taff se utiliza el comando APPEND: APPEND
8taff (staffNo = "8837", fName = "Ann", IName = "Beech", sex = "F", dateOfBirth = "10-Nov-60", position = "Assistant", salary = 12000, branchNo = "B003", manager = "RETRIEVE (s.staffNo) FROM s IN 8taffWHERE
position
=
'Manager' AND branchNo
=
'B003"')
Una consulta que haga referencia al atributo manager devolverá la cadena de caracteres que contiene el comando Postquel, que en general puede ser una relación, en lugar de un único valor. Postgres proporciona dos formas de acceder al atributo manager. La primera utiliza una notación de puntos anidada para ejecutar implícitamente una consulta: RETRIEVE
(s.staffNo, s.IName, s.manager.staffNo) FROM s IN 8taff
Esta consulta genera un listado con el número, nombre y número de empleado del jefe para cada uno de los empleados de la empresa. El resultado de la consulta en manager se combina implícitamente con la tupla especificada por el resto de la lista de extracción. La segunda forma de ejecutar la consulta consiste en usar el comando EXECUTE: EXECUTE
(s.staffNo, s.IName, s.manager.staffNo) FROM
s IN 8taff
Pueden utilizarse tipos de proced~mientos parametrizados cuando los parámetros de la consulta puedan tomarse de otros atributos de la tupla. ~tiliza el signo $ para hacer referencia a la tupla en la que la consul-
856
Sistemas de bases de datos
ta está almacenada. Por ejemplo, podríamos redefinir la consulta anterior utilizando un tipo de procedimiento parametrizado: DEFINE TYPE Manager IS RETRlEVE (staffNumber = s.staffNo) FROM s IN position = "Manager" AND branchNo
Staff
WHERE
= $.branchNo
y utilizar este nuevo tipo en la creación de la tabla: CREATE
Staff(staffNo
=
branchNo
char[5], position = char[IO], salary = char[4], manager = Manager)
=
float4,
INHERITS(Person)
La consulta para extraer los detalles de los empleados sería ahora: RETRlEVE
(s.staffNo, s.IName, s.manager.staffNumber)
FROM s IN
Staff
El mecanismo de tipos abstractos de datos de Postgres es bastante limitado, si lo comparamos con los SGBDOO. En Postgres, los objetos se componen a partir de tipos abstractos de datos, mientras que en un SGBDOO todos los objetos se tratan como tipos abstractos de datos. Esto no satisface completamente el concepto de encapsulación. Además, no hay un mecanismo de herencia asociado con los tipos abstractos de datos, sino sólo con las tablas.
28.3.4
Identidad de los objetos
Cada relación tiene un atributo implícitamente definido, denominado oid, que contiene el identificador unívoco de la tupla, siendo cada valor oid creado y mantenido por Postgres. El atributo oid puede ser consultado por el usuario, pero esas consultas no pueden actualizarlo. Entre otros usos, el oid puede emplearse como mecanismo para simular tipos de atributos que hagan referencia a tuplas de otras relaciones. Por ejemplo, podemos definir un tipo que haga referencia a una tupla de la relación Staff de la forma siguiente: DEFINE TYPE Staff(int4) IS RETRlEVE (Staff.all) WHERE
Staff.oid = $1
Puede utilizarse el nombre de la relación como nombre del tipo porque las relaciones, tipos y procedimientos tienen espacios de nombres separados. El argumento real se suministrará cuando se asigne un valor a un atributo de tipo Staff. Ahora podemos crear una relación que utilice este tipo de referencia: CREATE
= char[5], street = char[25], city = char[15], char[l], rooms = int2, rent = float4, branchNo = char[ 4], staffNo = Staff)
PropertyForRent(propertyNo postcode = ownerNo =
char[8], char[ 5],
type =
KEY(propertyNo)
El atributo staffNo representa el empleado que se encarga de gestionar el alquiler del inmueble. La siguiente consulta añade un inmueble a la base de datos: APPEND
"PAI4", street = "16 Holhead", "AB7 5SU", type = "H", rooms = 6, "C046", branchNo = "B007", staffNo = Staff(s.oid))
PropertyForRent(propertyNo city = "Aberdeen",
=
postcode =
rent = 650, ownerNo FROM s IN Staff WHERE s.staffNo = "SA9")
=
28.4 SOL:1999 y SOL:2003 En los Capítulos 5 y 6 hemos proporcionado una amplia introducción a las características del estándar ISO SQL, concentrándonos principalmente en las caracterí~s presentes en la versión de 1992 del estándar,
Capítulo 28 Bases de datos objeto-relacionales
857
comúnmente denominada SQL2 o SQL-92. ANSI (X3H2) y ISO (ISO/lEC JTC1/SC21/WG3) han añadido características a la especificación SQL para soportar la gestión de datos orientada a objetos, versiones del estándar que se denominan SQL:1999 (ISO, 1999a) y SQL:2003 (ISO, 2003a). Como hemos mencionado anteriormente, el estándar SQL:2003 es extremadamente grande y completo, estando dividido en las siguientes partes: (1) ISO/lEC 9075-1
SQLlMarco de trabajo.
(2) ISO/lEC 9075-2 SQL/Bases, que incluye nuevos tipos de datos, tipos definidos por el usuario, reglas y disparadores, transacciones, rutinas almacenadas y métodos de enlace (SQL incrustado, SQL dinámico e invocación directa de SQL). (3) ISO/lEC 9075-3 SQLlCLI (Call-Level Interface, interfaz de nivel de llamada), que especifica la provisión de una interfaz de programación de aplicaciones para la base de datos, como se explica en el Apéndice E, basada en los trabajos de SQL Office Access Group y en las definiciones CLI de X/Open. (4) ISO/lEC 9075-4 SQLlPSM (Persistent Stored Modules, módulos persistentes almacenados), que permiten escribir procedimientos y funciones definidas por el usuario en un lenguaje 3GL o SQL y almacenados en la base de datos, haciendo así que el lenguaje SQL sea computacionalmente completo. (5) ISO/lEC 9075-9 SQL/MED (Management ofExternal Data, gestión de datos externos), que define extensiones a SQL para soportar la gestión de datos externos mediante el uso de tablas externas y de tipos de datos de enlace. (6) ISO/lEC 9075-10 SQLlOLB (Object Language Bindings, enlaces de lenguaje de objetos), que define funcionalidades para incrustar instrucciones SQL en programas lava. (7) ISO/lEC 9075-11 SQLlEsquemas (esquemas de información y de definición), que define dos esquemas INFORMATION _ SCHEMA y DEFINITION _ SCHEMA. El esquema de información define vistas sobre los objetos de la base de datos, como por ejemplo tablas, vistas y columnas. Estas vistas se definen en términos de las tablas base en el esquema de definición. (8) ISO/lEC 9075-13 SQLlJRT (lava Routines and Types, tipos y rutinas lava), que define extensiones a SQL para permitir la"'¡nvocación de métodos estáticos escritos en lava, y utilizar clases definidas en lava como tipos estructurado s SQL. (9) ISO/lEC 9075-14 SQLlXML, que define extensiones a SQL para permitir la creación y manipulación de documentos XML. En esta sección vamos a examinar algunas de estas características, incluyendo: •
constructores de tipos para tipos de fila y tipos de referencia;
•
tipos definidos por el usuario (tipos diferenciados y tipos estructurado s) que pueden participar en relaciones supertipo/subtipo.
•
procedimientos,
funciones, métodos y operadores definidos por el usuario;
constructores para tipos de colección (matrices, conjuntos, listas y multiconjuntos); • •
soporte para objetos de gran tamaño: objetos binarios de gran tamaño (BLOB) y objetos de carácter de gran tamaño (CLOB); recursión.
Muchos de los conceptos de orientación a objetos que hemos explicado en la Sección 25.3 se incluyen en esta propuesta. La versión definitiva del estándar SQL: 1999 se retrasó bastante con respecto a la fecha prevista y algunas de las características quedaron aplazadas para una versión posterior del estándar.
28.4.1 Tipos de filas Un tipo de fila es una secuencia de_parejas nombre de campo/tipo de datos que proporcionan un tipo de datos para representar los tipos de lasiías de la tablas, de modo que pueden almacenarse filas completas en variables, pueden pasarse esas filas como argumentos a rutinas y pueden devolverse filas como valores de retorno
858
Sistemas de bases de datos
de las llamadas a función. También puede utilizarse un tipo de fila para permitir que una columna de una tabla contenga valores de fila. En esencia, la fila es una tabla anidada dentro de otra tabla.
I
Ejemplo 28.1 Utilización del tipo de fila Para ilustrar el uso de los tipos de filas, vamos a crear una tabla Branch simplificada compuesta del número de sucursal y de la dirección, y vamos a insertar un registro en la nueva tabla: CREATE TABLE Branch ( branchNo CHAR(4), address ROW(street city postcode
VARCHAR(25), VARCHAR(15), ROW( cityldentifier subPart
VARCHAR(4), VARCHAR(4))));
INSERT INTO Branch VALUES ('B005', ROW('22
Deer Rd', 'London',
ROW('SWl',
'4EH')));
" 28.4.2
Tipos definidos por el usuario
SQL:2003 permite la definición de tipos definidos por el usuario (UDT, user-defined types), a los que antes nos hemos referido con el nombre de tipos abstractos de datos. Pueden utilizarse de la misma forma que los tipos predefinidos (por ejemplo, CHAR, INT, FLOAT). Los UDT se subdividen en dos categorías: tipos diferenciados y tipos estructurados. El tipo más simple de UDT es el tipo diferenciado, que permite diferenciar entre los mismos tipos base subyacentes. Por ejemplo, podríamos crear los dos tipos distintos siguientes: CREATE TYPE OwnerNumberTypeAS VARCHAR(5) FINAL; CREATE TYPE StaffNumberTypeAS VARCHAR(5) FINAL; Si ahora intentáramos tratar una instancia de-un tipo como una instancia del otro tipo, se generaría un error. Observe que, aunque SQL también permite la creación de dominios para distinguir entre los diferentes tipos de datos, el propósito del dominio SQL es, exclusivamente, restringir el conjunto de valores válidos que pueden almacenarse en una columna que tenga dicho dominio. En un caso más general, una definición de UDT está compuesta de una o más definiciones de atributo, cero o más declaraciones de rutinas (métodos) y, en una versión posterior, declaraciones de operadores. Utilizaremos la palabra rutinas para referimos genéricamente tanto a las rutinas como a los operadores. Además de lo anterior, también podemos definir las relaciones de igual y de ordenación para el UDT utilizando la instrucción CREATE ORDERING FOR. Puede accederse al valor de un atributo utilizando la notación de puntos común (.). Por ejemplo, suponiendo que p es una instancia del UDT PersonType, que tiene un atributo fName de tipo VARCHAR, podemos acceder al atributo fName de la forma siguiente: p.fName p.fName =
'A.
Smith'
Encapsulación y funciones observadoras y mutadoras SQL encapsula cada atributo de los tipos estructurados, proporcionando una pareja de rutinas predefinidas que se invocan cada vez que un usuario quiera hacer referencia al atributo: una función observardora (get) y una función mutadora (set). La función observadora devuelve el valor actual del atributo; la función mutadora establece el valor del atributo, asignándole el valor especificado como parámetro. Estas funciones pueden ser redefinidas por el usuario en la definición de la UDT. De esta forma, los valores de los atributos están encapsulados y el usuario solamente puede acceder a elloyrnvocando observadora para el atributo fName de PersonType serí~:
estas funciones. Por ejemplo, la función
Capítulo 28 Bases de datos objeto-relaciona les FUNCTlON fName(p PersonType) RETURNS RETURN p.fName; y la función mutadora correspondiente
859
VARCHAR(15)
para configurar el atributo y asignarle el valor new Value sería:
FUNCTlON fName(p PersonType RESULT, newValue VARCHAR(15)) RETURNS PersonType BEGIN p.fName = newValue; RETURNp; END;
Funciones constructoras
y la expresión NEW
El sistema define automáticamente una función constructora (pública) para crear nuevas instancias del tipo. La función constructora tiene el mismo nombre y tipo que el UDT, toma cero argumentos y devuelve una nueva instancia del tipo, asignando a los atributos sus valores predeterminados. El usuario puede definir métodos constructores para inicializar una instancia recién creada y un tipo estructurado. Cada método debe tener el mismo nombre que el tipo estructurado, pero los parámetros deben ser distintos de los del constructor suministrado por el sistema. Además, cada constructor definido por el usuario debe diferir en el número de parámetros o en los tipos de datos de los parámetros. Por ejemplo, podríamos inicializar un constructor para el tipo PersonType de la forma: CREATE CONSTRUCTOR METHOD PersonType (fN VARCHAR(15), IN VARCHAR(15), sx CHAR) RETURNS PersonType BEGIN SET SELFfName = fN; SET SELFIName = IN: SET SELFsex = sx; RETURN SELF; END; La expresión NEW puede utilizarse para invocar la función constructora como por ejemplo:
suministrada por el sistema,
SET p = NEW PersonTypeO; Los métodos constructores definidos por el usuario deben invocarse en el contexto de la expresión NEW. Por ejemplo, podemos crear una nueva instancia de PersonType e invocar el método constructor definido por el usuario que antes hemos visto utilizando la siguiente instrucción: SET p = NEW PersonType('John', 'White', DATE'1945-10-01'); Esto se traduce en la práctica a: SET p = PersonTypeO.PersonType('John', 'White', DATE'1945-1O-01 ');
Otros métodos de un UOT Las instancias de los UDT pueden restringirse para que muestren propiedades de ordenación especificadas. Las cláusulas EQUALS ONLY BY Y ORDER FULL BY pueden emplearse para especificar funciones específicas de ese tipo que permitan comparar las distintas instancias del UDT. La ordenación puede realizarse utilizando métodos con los siguientes métodos: •
RELATIV~1 relativo una función un Opara igualdad, un valor negativo para indic~ método menor que y unesvalor positivo que paradevuelve indicar mayor queindicar .
•
MAP El método de mapeado utiliza una función que toma un único argumento del tipo UDT y devuelve un tipo de datos predefinido. La comparación de dos UDT se lleva a cabo comparando los dos valores de mapeo asociados con ellos.
860
•
Sistemas de bases de datos
STATE El método de estado compara los atributos de los operando s para determinar la ordenación.
También pueden definirse funciones CAST (de transformación de tipos) para proporcionar funciones de conversión entre diferentes UDT definidas por el usuario. En una futura versión del estándar puede que también sea posible anular y sustituir algunos de los operadores predefinidos:
I
Ejemplo 28.2 Definición de un nuevo UDT Para ilustrar la creación de un nuevo UDT, vamos a crear un UDT para CREATE TYPE dateOfBirth fName IName
PersonType.
AS ( DATE, VARCHAR( 15), VARCHAR(15), CHAR)
PersonType
sex INSTANTIABLE NOTFINAL REF IS SYSTEM GENERATED
INSTANCE METHOD age O RETURNS INTEGER, INSTANCE METHOD age (DOB DATE) RETURNS PersonType; CREATE INSTANCE METHOD age O RETURNS INTEGER FOR PersonType BEGIN RETURN /* edad calculada a partir de SELEdateOfBirth */; END; CREATE INSTANCE METHOD age (DOB DATE) RETURNS PersonType FOR PersonType BEGIN SELF.dateOfBirth
RETURN
=
/* código para calcular dateOfBirth a partir de DOB*/;
SELF;
END; Este ejemplo también ilustra la utilización de atributos almacenados y atributos virtuales. Un atributo almacenado es el tipo predeterminado, con un nombre de atributo y un tipo de datos. El tipo de datos puede ser cualquier tipo de datos conocido, incluyendo otros UDT. Por contraste, los atributos virtuales no se corresponden con datos almacenados, sino con datos derivados. Hay un atributo virtual implícito age, que se calcula utilizando la función (observadora) age y cuyo valor se puede cambiar utilizando la función (mutadora) aget. Desde la perspectiva del usuario, no hay ninguna diferencia distinguible entre un atributo almacenado y un atributo virtual: se puede acceder a ambos utilizando las correspondientes funciones observadora y mutadora. Sólo el diseñador del UDT será consciente de la diferencia. La palabra clave INSTANTIABLE indica que pueden crearse instancias de este tipo. Si se hubiera especificado NOT INSTANTIABLE, no seríamos capaces de crear instancias de este tipo, sino sólo de sus subtipos. La palabra clave NOT FINAL indica que podemos crear subtipos de este tipo definido por el usuario. Hablaremos de ~ la cláusula REF IS SYSTEM GENERATED en la Sección 28.4.6~
t Observe que el nombre de función age está sobrecargado.
dos funciones.
En la Sección 28.4.5 se explica el modo en el que SQL distingue entre estas
Capítulo 28 Bases de datos objeto-relaciona les
28.4.3
861
Subtipos y supertipos
SQL:2003 permite que los UDT participen en una jerarquía de subtipo/supertipos utilizando la cláusula UNDER. Un tipo puede tener más de un subtipo, pero en la actualidad sólo está permitido que tenga un supertipo (es decir, no se soporta la herencia múltiple). Los subtipos heredan todos los atributos del comportamiento (métodos) de su supertipo y pueden definir atributos y métodos adicionales, al igual que cualquier otro UDT, y pueden también sustituir los métodos heredados.
I
Ejemplo 28.3 Creación de un subtipo utilizando
la cláusula UNDER
Para crear un subtipo StaffTypedel supertipo PersonType, podríamos escribir: CREATE TYPE StaffTypeUNDER PersonType AS ( staffNo VARCHAR(5), position VARCHAR(lO) DEFAULT 'Assistant', salary DECIMAL(7,2), branchNoCHAR( 4)) INSTANTIABLE NOTFINAL INSTANCE METHOD isManager O RETURNSBOOLEAN; CREATE INSTANCE METHOD isManagerO RETURNS BOOLEAN FOR StaffType BEGIN IF SELF.position= 'Manager' THEN RETURN TRUE; EL SE END IF
RETU~
FALSE;
END) StaffType,además de tener los atributos definidos dentro de CREATE TYPE, también incluye los atributos heredados de PersonType, junto con las funciones observadoras y mutadoras asociadas y cualesquiera métodos especificados. En particular, la cláusula REF IS SYSTEM GENERATED también se hereda en el subtipo. Además, hemos definido un método de instancia isManager que comprueba si el empleado especificado tiene la categoría Manager. En la Sección 28.4.8 mostraremos cómo puede uti-
--.J
lizarse este método.
Una instancia de un subtipo se considera también instancia de todos sus supertipos. SQL:2003 soporta el concepto de sustituibilidad, es decir: allí donde se espere una instancia de un supertipo, puede utilizarse en su lugar una instancia del subtipo. El tipo de un UDT puede determinarse utilizando el predicado TYPE. Por ejemplo, dado un UDT, como por ejemplo Udt1, podemos utilizar las siguientes comprobaciones: TYPE Udt1IS OF (PersonType) TYPE
// Comprobar se Udt1 pertenece a PersonType o a
/ de sus subtipos Udt1IS OF (O~LY PersonType) // algunos Comprobar si Udt1 pertenece a PersonType
En SQL:2003, como en la mayoría de los lenguajes de programación, toda instancia de un UDT debe estar asociada con exactamente un tipo más específico, que será el subtipo de nivel inferior asignado a la instancia. Así, si el UDT tiene más de un supertipo directo, debe haber un único tipo al que la instancia pertenezca, y dicho único tipo debe ser un subtipo de todos los tipos a los que la instancia pertenezca. En algunos casos, esto puede requerir la creación de un gran número de tipos. Por ejemplo, una jerarquía de tipos podría consistir de un supertipo de nivel superior Person, con Student y Staff como subtipos; Student podría tener tres sub
862
Sistemas de bases de datos
Undergraduate
Postgraduate
Undergraduate
Postgraduate
(a)
PTStudentStaff
(b)
Figura 28.2.
(a) Jerarquía inicial SttldenUStaff; (b) jerarquía modificada Student/Staff.
tipos directos: Undergraduate, Postgraduate y PartTimeStudent, como se ilustra en la Figura 28.2(a). Si una instancia tiene el tipo Person y Student, entonces el tipo más específico será en este caso Student, un tipo que no es nodo hoja de la jerarquía, ya que Student es un subtipo de Persono Sin embargo, con la jerarquía de tipo indicada una instancia no podría tener el tipo PartTimeStudent además de staff, a menos que creáramos un tipo PTStudentStaff, como se ilustra en la Figura 28.2(b). El nuevo nodo hoja, PTStudentStaff, será entonces el tipo más específico de esta instancia. De forma similar, algunos de los estudiantes normales (undergraduate) y de los de doctorado (postgraduate) pueden trabajar a tiempo parcial (part-time student), en lugar de tener empleados a tiempo completo que sean estudiantes a tiempo parcial (PTStudentStaff), por lo que también deberíamos añadir subtipos para FTUGStaff y FTPGStaff. Generalizando este enfoque, podríamos llegar a crear un número muy grande de subtipos. En algunos casos, puede ser mejor utilizar los mecanismos de herencia en el nivel de tablas en lugar de en el nivel de tipos, como veremos en breve.
Privilegios Para crear un subtipo, un usuario debe tener el privilegio UNDER sobre el tipo definido sobre el usuario que haya sido especificado como supertipo en la definición del subtipo. Además, un usuario debe tener el privilegio USAGE (privilegio de utilización) sobre todos los tipos definidos por el usuario a los que se haga refe·· rencia dentro del nuevo tipo. ~ Antes de SQL:1999, el privilegio SELECT sólo se aplicaba a las columnas de las tablas y vistas. En SQL: 1999, el privilegio SELECT también se aplica a los tipos estructurados, pero sólo cuando las instancias de dichos tipos estén almacenadas en tablas tipadas y sólo cuando el operador de des-referencia se utilice a partir de un valor REF que apunte a la fila referenciada y luego invoque un método sobre dicha fila referen-
Capítulo 28 Bases de datos objeto-relaciona les
863
ciada. Cuando se invoque un método sobre un valor estructurado que esté almacenado en una columna de cualquier tabla SQL ordinaria, será necesario tener el privilegio SELECT sobre dicha columna. Si el método es una función mutadora, también se requerirá tener el privilegio UPDATE sobre esa columna. Por último, se requiere el privilegio EXECUTE para todos los métodos que se invoquen.
28.4.4
Rutinas definidas por el usuario
Las rutinas definidas por el usuario (UDR, user-defined routine) definen métodos para manipular datos y son un importante complemento de los UDT, que proporciona el comportamiento requerido para éstos. Un SGBDOR debe proporcionar bastante flexibilidad en este área, permitiendo por ejemplo que los UDR devuelvan valores complejos que puedan manipularse ulteriormente (por ejemplo tablas), o como por ejemplo proporcionar soporte para la sobrecarga de los nombres de función con el fin de simplificar el desarrollo de las aplicaciones. En SQL:2003, los UDR pueden definirse como parte de un UDT, o definirse independientemente como parte de un esquema. Una rutina invocada desde SQL puede ser un procedimiento, función o método. Puede ser proporcionado externamente en un lenguaje de programación estándar como C, C++ o lava, o puede definirse completamente en SQL utilizando extensiones que hagan que el lenguaje sea computacionalmente completo, como veremos en la Sección 28.4.10. Un procedimiento invocado desde SQL se invoca mediante una instrucción CALL SQL. Puede poner cero o más parámetros, cada uno de los cuales puede ser un parámetro de entrada (IN), un parámetro de salida (OUT) o un parámetro tanto de entrada como de salida (INOUT), y tiene un cuerpo si está definido completamente dentro de SQL. Unafunción invocada desde SQL devuelve un valor; los parámetros que especifiquen deben ser parámetros de entrada. Uno de los parámetros de entrada puede designarse como resultado (utilizando la palabra clave RESULT), en cuyo caso el tipo de datos del parámetro debe corresponderse con el tipo de RETURNS. Dichas funciones se denominan preservado ras del tipo porque siempre devuelven un valor cuyo tipo en tiempo de ejecución es igual al tipo más específico (véase la Sección 28.4.3) del parámetro RETURN (es decir, no es ningún subtipo de dicho tipo). Las funciones mutadoras son siempre preservadoras del tipo. Un método invocado"1iesde SQL es similar a una función, pero tiene algunas diferencias importantes: • •
un método está asociado con un único UDT; la signatura de todo método asociado con un UDT debe ser especificada en dicho UDT y la definición . del método debe especificar dicho UDT (y debe también aparecer en el mismo esquema que el UDT).
Hay tres tipos de métodos: •
métodos constructores, que inicializan una instancia recién creada de un UDT;
•
métodos de instancia, que operan sobre instancias específicas de un UDT;
•
métodos estáticos, que son análogos a los métodos de clase que se utilizan en algunos lenguajes de programación orientados a objetos y que operan en el nivel de UDT, en lugar de en el nivel de instancia.
En los primeros dos casos, los métodos incluyen un primer parámetro adicional implícito, denominado SELF, cuyo tipo de datos es el del UDT asociado. Hemos visto un ejemplo del parámetro SELF en el método constructor definido por el usuario para PersonType. Un método puede invocarse de tres formas distintas: •
un método constructor se invoca utilizando la expresión NEW, como hemos visto anteriormente;
•
un método de instancia se invoca utilizando la notación de puntos estándar, como por ejemplo p.fName o utilizando el formato gineralizado de invocación, como por ejemplo, (p AS StaffType).fNameO;
•
un método estático se invoca utilizando ::; por ejemplo, si totalStaffes un método estático para StaffType, podríamos invocarlo escribiendo StaffType::totaIStaffO.
Una rutina externa se define especificando una cláusula externa que identifique el correspondiente 'código compilado' dentro del sistema de archivos del sistema operativo. Por ejemplo, podríamos utilizar una función que creara una imagen miniatura para un objeto almacenado en la base de datos. Esta funcionalidad no
864
Sistemas de bases de datos
puede proporcionarse en SQL, por lo que deberemos utilizar una función externa, empleando la siguiente instrucción CREATE FUNCTION con una cláusula EXTERNAL: CREATE FUNCTlON thumbnail(IN myImage ImageType) RETURNS EXTERNAL NAME '/usr/dreamhome/binJimages/thumbnail' LANGUAGEC PARAMETER STYLE GENERAL DETERMINISTlC
BOOLEAN
NO SQL; Esta instrucción SQL asocia la función SQL denominada thumbnail con un archivo externo, 'thumbnail'. Es responsabilidad del usuario proporcionar esta función compilada. A partir de ahí, el SGBDOR proporcionará un método para enlazar dinámicamente este archivo objeto con el sistema de archivo de datos, para poderlo invocar siempre que sea necesario. El procedimiento para llevar esto a cabo no está especificado por el estándar SQL, por lo que se deja al arbitrio de la implementación. Una rutina es determinista si siempre devuelve los mismos valores de retorno para un conjunto de entradas dado. La cláusula NO SQL indica que esta función no contiene instrucciones SQL. Las otras opciones son READS SQL DATA, MODIFIES SQL DATA y CONTAINS SQL.
28.4.5 Polimorfismo En la Secciones 25.3.7 y 25.3.8, hemos hablado de los conceptos de la anulación, sobrecarga y, más generalmente, polimorfismo. Puede haber diferentes rutinas con el mismo nombre, es decir, los nombres de las rutinas pueden estar sobrecargados, por ejemplo para permitir a un subtipo de UDT re definir un método heredado de un supertipo, lo cual está sujeto a las siguientes restricciones: •
No puede haber dos funciones en un mismo esquema que tengan la misma signatura, es decir, el mismo número de argumentos, los mismos tipos de datos para cada argumento y el mismo tipo de retorno.
•
No puede haber dos procedimientos número de parámetros.
en el mismo esquema que tengan el mismo nombre y el mismo
El mecanismo de anulación se aplica únicamente a los métodos, y sólo basándose en el valor en tiempo de ejecución del argumento implícito SELF (observe que una definición de método tiene parámetros, mientras que una invocación de método tiene argumentos). SQL utiliza un modelo de objetos generalizado, de modo que se toman en consideración los tipos de todos los argumentos de una rutina a la hora de determinar qué rutina hay que invocar, considerándose esos argumentos por orden, de izquierda a derecha. Cuando no exista una correspondencia exacta entre el tipo de dato de un argumento y el tipo de dato del parámetro especificado, se utilizan listas de precedencia de tipos para determinar la correspondencia más parecida. Las reglas exactas para la determinación de la rutina apropiada para una invocación determinada son muy complejas y no vamos a entrar aquí a analizar todos los detalles, sino que nos limitaremos a ilustrar el mecanismo para los métodos de instancia.
Invocación de métodos de instancia El mecanismo para determinar la invocación apropiada de un método de instancia se divide en dos fases, que representan el análisis estático y la ejecución. En esta sección vamos a proporcionar una panorámica de estas fases. La primera fase se lleva a cabo de la forma siguiente: •
Se identifican todas las rutinas con el nombre apropiado (eliminándose todas las rutinas restantes).
•
Se eliminan todos los procedimientos/funciones el privilegio EXECUTE.
•
Se eliminan todos los métodos que ~én to SELF implícito.
•
Se eliminan todos los métodos cuyos parámetros no sean iguales al número de argumentos utilizados en la invocación del método.
y todos los métodos para los que el usuario no tenga
asociados con el tipo (o subtipo) declarado del argumen-
Capítulo 28 Bases de datos objeto-relacionales •
865
Para los métodos restantes, el sistema comprueba que el tipo de dato de cada parámetro se corresponda con la lista de precedencia del argumento correspondiente, eliminándose aquellos métodos que no se correspondan.
• Si no hay ningún método candidato restante, se produce un error sintáctico. Para los restantes métodos candidatos, la segunda fase (en tiempo de ejecución) se lleva a cabo de la forma siguiente: •
Si el tipo más específico del valor en tiempo de ejecución del argumento implícito de la invocación del método tiene una definición de tipo que incluya uno de los métodos candidatos, se selecciona ese método para ejecución.
•
Si el tipo más específico del valor en tiempo de ejecución del argumento implícito de la invocación del método tiene una definición de tipo que no incluye ninguno de los métodos candidatos, el método seleccionado para ejecución será el método candidato cuyo tipo asociado sea el supertipo más próximo de todos los supertipos que tengan tal método.
Los valores de los argumento se convierten a los tipos de datos de los parámetros, en caso necesario, y a continuación se ejecuta el cuerpo del método.
28.4.6 Tipos de referencia e identidad de los objetos Como hemos explicado en la Sección 25.3.3, la identidad de los objetos es ese aspecto de los objetos que nunca cambia y que distingue a cada objeto de todos los demás objetos. Idealmente, la identidad de un objeto es independiente de su nombre, de su estructura y de su ubicación. La identidad de un objeto persiste incluso después de que el objeto haya sido borrado, para que nunca pueda llegar a ser confundida con la identidad de cualquier otro objeto. Los demás objetos pueden utilizar la identidad de un objeto como forma distintiva de referirse a él. Hasta SQL: 1999, la única forma de definir relaciones entre tablas era utilizar el mecanismo de clave principal/clave externa, que en SQL2 puede expresarse utilizando la cláusula de restricción referencial de tabla REFERENCES, como se explíta en la Sección 6.2.4. A partir de SQL: 1999, pueden utilizarse tipos de referencia para definir relaciones entre tipos de fila e identificar unívocamente una fila dentro de una tabla. Un valor de tipo de referencia puede almacenarse en una tabla y usarse como una referencia directa a una fila específica en alguna tabla base que haya sido definida como de dicho tipo (de forma similar a la noción de un tipo puntero en C o C++). A este respecto, un tipo de referencia proporciona una funcionalidad similar a la del identificador de objeto (OIO) en los SGBD orientados a objetos (véase la Sección 25.3.3). Así, las referencias permiten que una fila sea compartida entre múltiples tablas y permiten a los usuarios sustituir las definiciones de combinaciones complejas en las consultas por otras expresiones de ruta mucho más simples. Las referencias también proporcionan al optimizador una manera alternativa para navegar por los datos, en lugar de utilizar combinaciones basadas en valores. REF IS SYSTEM GENERATED en una instrucción CREA TE TYPE indica que los valores reales del tipo REF asociado son proporcionados por el sistema, como en el tipo PersonType creado en el Ejemplo 28.2. Hay disponibles otras opciones, aunque no vamos a tratar de ellas aquí; la opción predeterminada es REF IS SYSTEM GENERATED. Como veremos en breve, puede crearse una tabla base que tenga un determinado tipo estructurado. Pueden especificarse otras columnas para la tabla, pero al menos deberá especificarse una columna, que tiene que ser una columna del tipo REF asociado, utilizando la cláusula REF IS SYSTEM GENERATED. Esta columna se utiliza para contener identificadores unívocos de las filas de la tabla base asociada. El identificador para una fila determinada se asigna en el momento de insertar la fila en la tabla y perm~n='7asociado
28.4.7
con dicha fila hasta que se la borra.
Creación de tablas
Para mantener la compatibilidad descendente con el estándar SQL2, sigue siendo necesario utilizar la instrucción CREA TE TABLE para crear una tabla, incluso aunque la tabla esté compuesta por un único UDT. En
866
Sistemas de bases de datos
otras palabras, una instancia de un UDT sólo puede ser persistente si se la almacena como valor de columna dentro de una tabla. Hay diversas variantes de la instrucción CREATE TABLE, como ilustran los Ejemplos 28.4-28.6.
I
Ejemplo 28.4 Creación de una tabla basada en un UDT Para crear una tabla utilizando el UDT PersonType, podemos escribir: CREATE TABLE Person ( info PersonType CONSTRAINT DOB_Check CHECK(dateOfBirth
> DATE '1900-01-01'));
o CREATE TABLE Person OF PersonType ( dateOfBirthWITH OPTlONS CONSTRAINT DOB _Check CHECK (dateOfBirth> DATE' 1900-01-01 ') REF IS PersonlD SYSTEM GENERATED); En el primer caso, accederíamos a las columnas de la tabla Person utilizando una expresión de ruta tal como 'Person.info.fName'; en la segunda versión, accederíamos a las columnas utilizando una expresión de ruta tal como 'Person.fName'.
I
~
Ejemplo 28.5 Utilización de un tipo de referencia para definir una relación En este ejemplo, modelamos la relación entre PropertyForRent y 8taff utilizando un tipo de referencia: CREATE TABLE PropertyForRent( propertyNo PropertyNumber street 8treet city postcode type rooms rent stafflD PRIMARY
NOTNULL, NOTNULL, NOTNULL,
City PostCode, PropertyType NOT NULL DEFAULT 'F', PropertyRooms NOT NULL DEFAULT4, PropertyRent NOT NULL DEFAULT 600, REF(8taffType) SCOPE 8taff REFERENCES ARE CHECKED ON DELE TE CASCADE, KEY (propertyNo));
En el Ejemplo 6.1 hemos modelado la relación entre PropertyForRenty 8taffutilizando el mecanismo tradicional de clave principal/clave externa. Aquí, sin embargo, hemos empleado un tipo de referencia, REF(8taffType), para modelar la relación. La cláusula SCOPE especifica la tabla referenciada asociada. REFERENCES ARE CHECKED indica que es necesario mantener la integridad referencial (la alternativa sería REFERENCES ARE NOT CHECKED).). ON DELETE CASCADE se corresponde con la acción referencial normal existente en SQL2. Observe que no es necesaria una cláusula ON UPDA-
TE, ya que la columna stafflDen la tabla 8ta)PUede
ser actualizada.
~
SQL:2003 no puede ser un mecanismo para almacenar todas las instancias de un UDT dado, a menos que el usuario cree explícitamente una única tabla en la que se almacenen todas esas instancias. Así, en SQL:2003
Capítulo 28 Bases de datos objeto-relacionales
867
puede que no sea posible aplicar una consulta SQL a todas las instancias de un UDT determinado. Por ejemplo, si creáramos una segunda tabla tal como: CREATE TABLE Client ( info PersonType, prefType CHAR, maxRent DECIMAL(6,2), branchNo VARCHAR(4) NOT NULL); entonces las instancias de PersonType estarían ahora distribuidas entre dos tablas: Staff y Client. Este problema puede resolverse en este caso concreto utilizando el mecanismo de herencia de tablas, que permite crear una tabla que herede todas las columnas de otra tabla existente, utilizando la cláusula UNDER. Como cabría esperar, la subtabla heredará todas las columnas de su supertabla. Observe que todas las tablas de una jerarquía de tablas deben tener tipos correspondientes que se encuentren dentro de la misma jerarquía de tipos, y que las tablas de la jerarquía de tablas deben estar en las mismas posiciones relativas que los tipos correspondientes dentro de la jerarquía de tipos. Sin embargo, no todo tipo de la jerarquía de tipos tiene que estar obligatoriamente representado en la jerarquía de tablas, siempre y cuando el rango de tipos para los que se definan las tablas sea contiguo. Por ejemplo, si hacemos referencia a la Figura 28.2(a), sería legal crear tablas para todos los tipos excepto Staff; sin embargo, algo que no se podría es crear tablas para Person y Postgraduate sin crear una para Student. Observe también que no pueden definirse columnas adicionales como parte de la definición de la subtabla.
I
Ejemplo 28.6 Creación de una subtabla utilizando
la cláusula UNDER
Podemos crear una tabla para Staffutilizando herencia de tablas: CREATE TABLE Staff OF StaffTypeUNDER Person; Cuando insertemos filas en la tabla Staff,los valores de las columnas heredadas se insertarán en la tabla PersonoDe forma similar, cuando borramos filas de la tabla Staff,las filas desaparecerán tanto de la tabla Staff como de la tabla Persono Como resultado, cuando accedamos a todas las filas de Person, se incluirán también todos los detalles de Staff.
~
Existen una serie de restricciones que afectan a la manera de rellenar una jerarquía de tablas: •
Cada fila de la supertabla Person puede corresponderse con como máximo una fila de Staff.
•
Cada fila de Staff debe tener exactamente una fila correspondiente
en Persono
La semántica que se trata de conservar es la de contenido: una fila de una subtabla está, en la práctica, 'contenida' en sus supertablas. Cabría esperar que las instrucciones SQL INSERT, UPDATE y DELETE mantengan esta coherencia cuando se modifiquen las filas de las subtablas y supertablas (al menos conceptualmente); el mecanismo funciona de la forma siguiente: • Cuando se inserta una fila en una subtabla, los valores de todas las columnas heredadas de la tabla se insertan en las correspondientes supertablas, propagándose en cascada los cambios hacia arriba en la jerarquía de tablas. Por ejemplo, si volvemos a fijamos en la Figura 28.2(b), al insertar una fila en PTStudentStaff, los valores de las columnas heredadas se insertarán en Student y Staff y a continuación los valores de las col,\mnas heredadas de StudentlStaff se insertarán en Persono •
Cuando se los actualice upa fila en una subtabla, se lleva a cabo un procedimiento similar al anterior, para actualizar valores/de las columnas heredadas en las supertablas.
•
Cuando se actualiza una fila en una supertabla, los valores de todas las columnas heredadas en todas las correspondientes filas de sus subtablas directas e indirectas también se actualizan correspondientemente. Puesto que la supertabla puede ser, ella misma, una subtabla, también habrá que aplicar la condición anterior para garantizar la coherencia.
868
Sistemas de bases de datos
•
Cuando se borra una fila en una subtabla/supertabla, se heredan también las correspondientes filas dentro de la jerarquía de tablas. Por ejemplo, si borráramos una fila de Student, las filas correspondientes de Person y Undergraduate/Postgraduate/PartTimeStudentlPTStudentStaffse borrarían.
Privilegios Al igual que con los privilegios requeridos para crear un nuevo subtipo, un usuario debe tener el privilegio UNDER sobre la supertabla referenciada. Además, el usuario debe tener el privilegio USAGE sobre todos los tipos definidos por el usuario a los que se haga referencia dentro de la nueva tabla.
28.4.8
Consulta de datos
SQL:2003 proporciona la misma sintaxis que SQL2 para consultar y actualizar las tablas, con diversas extensiones para poder manejar los objetos. En esta sección, vamos a ilustrar algunas de estas extensiones.
I
Ejemplo 28.7 Extracción de una columna específica de una serie de filas específicas Hallar los nombres de todos los empleados con categoría de Manager. SELECT s.IName FROMStaffs WHERE
s.position = 'Manager';
Esta consulta invoca, en la cláusula WHERE, la función observadora position implícitamente definida, para acceder a la columna position.
I
~
Ejemplo 28.8 Invocación de una función definida por el usuario Hallar los nombres y las edades de todos los empleados con categoría de Manager. SELECT s.IName, s.age FROM Staffs WHERE s.isManager; Este método alternativo para hallar los empleados con categoría de Manager emplea el método isManager definido por el usuario como predicado de la cláusula WHERE. Este método devuelve el valor booleano TRUE si el empleado tiene categoría de Manager (véase el Ejemplo 28.3). Además, esta consulta también invoca como elemento de la lista SELECT la función (observadora) virtual heredadaage.
I
~
Ejemplo 28.9 Utilización de ONLY para restringir la selección Hallar los nombres de todas las personas de la base de datos que tengan más de 65 años. SELECT p.IName, p.fName FROM Person p WHERE p.age > 65; Esta consulta no sólo muestra los detalles de las filas que hayan sido explícitamente insertadas en la tabla Person, sino también los nombres correspondientes a todas las filas que hayan sido insertadas en cualquier subtabla directa o indirecta de Person, en este caso, Staffy Client.
Capítulo 28 Bases de datos objeto-relaciona les
869
Suponga, sin embargo, que en lugar de querer extraer los detalles de todas las personas, sólo quisiéramos los detalles de las instancias específicas de la tabla Person, excluyendo todas las subtablas. Esto puede llevarse a cabo utilizando la palabra clave ONLY: SELECT p.IName, p.fName FROM ONLY (Person) p WHERE p.age > 65;
I
Ejemplo 28.10
Utilización
del operador de des-referencia
Hallar el nombre del empleado que gestiona el inmueble 'PG4 '. SELECT p.staffID->fNameAS fName, p.stafflD->INameAS IName FROM PropertyForRent p WHERE p.propertyNo= 'PG4'; Las referencias pueden utilizarse en expresiones de ruta que permiten recorrer las referencias a objetos para navegar desde una fila a otra. Para recorrer una referencia, se utiliza el operador de des-referencia (-». En la instrucción SELECT, p.stafflDes la forma normal de acceder a una columna de una tabla. Sin embargo, en este caso concreto, la columna es una referencia a una fila de la tabla 8taff, por lo que debemos usar el operador de des-referencia para acceder a las columnas de la tabla des-referenciada. En SQL2, esta consulta habría requerido una combinación o una sub consulta anidada. Para extraer el empleado para el inmueble PG4, en lugar de extraer solamente el nombre y el apellido, utilizaríamos en su lugar la siguiente consulta: SELECT
DEREF(p.staffID)AS 8taff
FROM PropertyForRent p~ WHERE p.propertyNo= 'PG4';
Aunque los tipos de referencia son similares a las claves externas, hay diferencias significativas. En SQL:2003, la integridad referencial se mantiene únicamente utilizando una definición de restricción referencial especificada como parte de la definición de la tabla. Por sí mismos, los tipos de referencia no proporcionan integridad referencial. Por ello, el tipo de referencia de SQL no debe confundirse con el que se proporciona en el modelo de objetos de ODMG. En el modelo ODMG, se utilizan los OID para modelar las relaciones entre los tipos y la integridad referencial se define de manera automática, como se explica en la Sección 27.2.2.
28.4.9 Tipos de colección Las colecciones son constructores de tipos que se utilizan para definir colecciones de otros tipos. Las colecciones se usan para almacenar múltiples valores en una única columna de una tabla, y pueden dar origen a tablas anidadas en las que una columna de una tabla contenga en la práctica otra tabla. El resultado puede ser una única tabla que represente múltiples niveles maestro-detalle. De este modo, las colecciones añaden una gran flexibilidad al diseño de la estructura fís~ de la base de datos. SQL:1999 introdujo un tipo de colección ARRAY y SQL:2003 añadió el tipo de colección MULTISET, mientras que una versión subsiguiente del estándar podría introducir tipos de colección LIST y SET parametrizados. En ambos casos, el parámetro, denominado tipo de elemento, puede ser un tipo predefinido, un UDT, un tipo de fila u otra colección, pero no puede ser un tipo de referencia ni un UDT que contenga un tipo de referencia. Además, todas las colecciones deben ser homogéneas: todos los elementos deben ser del mismo tipo, o al menos de la misma jerarquía de tipos. Los tipos de colección tienen el siguiente significado:
870
Sistemas de bases de datos
•
ARRAY: matriz unidimensional
con un número máximo de elementos;
•
MULTISET: colección desordenada que permite duplicados;
•
LIST: colección ordenada que permite duplicados;
•
SET: colección desordenada que no permite duplicados.
Estos tipos son similares a los definidos en el estándar ODMG 3.0 del que hemos hablado en la Sección 27.2, aunque el nombre Bag ha sido sustituido en SQL por MULTISET.
Tipo de colección ARRAV Una matriz es una colección ordenada de valores no necesariamente distintos, a cuyos elementos se hace referencia mediante su posición ordinal dentro de la matriz. Una matriz se declara especificando un tipo de datos y, opcionalmente, una cardinalidad máxima, como por ejemplo: VARCHAR(25)
ARRAY[ 5]
Puede accederse a los elementos de esta matriz mediante un índice que vaya desde 1 hasta la cardinalidad máxima (la función CARDINALITY devuelve el número de elementos que hay actualmente en la matriz). Dos matrices de tipos comparables serán consideradas idénticas si y sólo si tienen la misma cardinalidad y cada par ordinal de elementos es idéntico. Los tipos de matriz se especifican mediante un constructor de tipos de matriz que puede definirse enumerando los elementos mediante una lista separada por comas y encerrada entre corchetes o utilizando una expresión de consulta de grado 1; por ejemplo: ARRAY ['Mary White', 'Peter Beech', 'Anne Ford', 'John Howe', 'Alan Brand'] ARRAY (SELECT rooms FROM PropertyForRent) En estos casos, el tipo de dato de la matriz está determinado por los tipos de datos de los diversos elementos de la matriz.
I
Ejemplo 28.11 Utilización de la colesción ARRAY Para modelar el requisito de que una sucursal tenga hasta tres números telefónicos, podemos implementar la columna como un tipo de colección ARRAY: telNo
VARCHAR(13)
ARRAY[3]
Ahora extraeríamos el primer número telefónico de la sucursal B003 utilizando la siguiente consulta: SELECT teINo[1] FROM Branch WHERE branchNo = 'B003';
Tipo de colección MULTISET Un multiconjunto es una colección desordenada de elementos, todos del mismo tipo, en la que está permitido que haya duplicados. Puesto que un multiconjunto está desordenado, no hay ninguna posición ordinal con la que hacer referencia a los elementos individuales de un multiconjunto. A diferencia de las matrices, un multiconjunto es una colección no acotada para la que no se declara una cardinalidad máxima (aunque sí que habrá un límite definido por la implementación). Aunque los multiconjuntos son análogos a las tablas, no se consideran iguales a éstas, proporcionándose operador~a convertir un multiconjunto en una tabla (UNNEST) y una tabla en un multiconjunto (MULTISET). En la actualidad, no hay ningún tipo independiente propuesto para los conjuntos. En lugar de ello, un conjunto es simplemente un tipo especial de multiconjunto, concretamente uno en el que no haya elementos
Capítulo 28 Bases de datos objeto-relacionales
871
duplicados. El estándar proporciona un predicado para comprobar si un determinado multiconjunto es un conjunto normal (sin duplicados). Dos multiconjuntos con tipos de elementos comparables, por ejemplo A y B, se considerarán idénticos si y sólo si tienen la misma cardinalidad y para cada elemento x de A, el número de elementos de A que son idénticos a x, incluyendo el propio x, es igual al número de elementos de B que son iguales a x. De nuevo, al igual que con los tipos de matriz, puede definirse un constructor de tipos multiconjunto enumerando los elementos en una lista separada por comas y encerrada entre corchetes, o utilizando una expresión de consulta con grado 1, o utilizando un constructor de valores de tabla. Entre las operaciones que pueden realizarse sobre los multiconjuntos están: •
La función SET para eliminar duplicados de un multiconjunto, con el fin de generar un conjunto.
•
La función CARDINALITY para devolver el número actual de elementos.
•
La función ELEMENT para devolver el elemento de un multiconjunto cuando éste sólo tiene un elemento (o el valor nulo si el multiconjunto no tiene ningún elemento). Se generará una excepción si el multiconjunto tiene más de un elemento.
•
MULTISET UNION, que calcula la unión de dos multiconjuntos; ALL o DISTINCT para conservar los duplicados o eliminarlos.
•
MULTISET INTERSECT, que calcula la intersección de dos multiconjuntos; puede especificarse la palabra clave DISTINCT para eliminar los duplicados; puede especificarse la palabra clave ALL para incluir en el resultado un número de instancias de cada valor igual al número mínimo de instancias de dicho valor en ambos operandos.
•
MULTISET EXCEPT, que calcula la diferencia de dos mUlticonjuntos; de nuevo, puede especificarse la palabra clave DISTINCT para eliminar los duplicados o la palabra clave ALL para incluir en el resultado un número de instancias de cada valor que sea igual al número de instancias de dicho valor en el primer operando menos el número de instancias del segundo operando.
pueden especificarse
las palabras
Hay tres nuevas funciones de agregación para los multiconjuntos: •
COLLECT, que crea un multiconjunto a partir del valor del argumento en cada fila de un grupo;
•
FUSION, que crea una unión de multiconjuntos para el valor de multiconjunto de todas las filas de un grupo;
•
INTERSECTION, que crea la intersección de multiconjuntos para el valor de multiconjunto las filas de un grupo.
de todas
Además, hay diversos predicados que pueden usarse con los multiconjuntos:
I
•
predicado de comparación (sólo igualdad y desigualdad);
•
predicado DISTINCT;
•
predicado MEMBER;
•
predicado SUBMULTISET, que comprueba si un multiconjunto es un submulticonjunto
•
predicado IS A SET/IS NOT A SET, que comprueba si un determinado multiconjunto es un conjunto.
Ejemplo 28.12
Utilización
de una colección
de otro;
MUL TISET
Ampliar la tabla Staff para incluir los detalles de una serie de parientes y luego hallar los nombres y los apellidos de los parientes de John White. Incluimos la definición de una columna atributo fName y otro IName): nextOfKin
NameType
La consulta será:
MULTISET
nextOfKin
en
Staff
de la forma siguiente
(NameType
contiene un
872
Sistemas de bases de datos SELECT
n.fName, n.IName
FROM
Staff s, UNNEST (s.nextOfKin) AS n(fName, IName) WHERE s.IName = 'White' AND s.fName = 'John';
Observe que podemos utilizar como referencia de tabla en la cláusula FROM el campo s.nextOfKin, que tiene como valor un multiconjunto.
I
Ejemplo 28.13
Utilización
~
de las funciones
de agregación
Considere la siguiente tabla, PropertyViewDates, que proporciona las fechas en que una serie de inmuebles han sido visitados por los inquilinos potenciales: propertyNo
viewDates
PA14
MULTISET['14-May-04',
'24-May-04']
PG4
MULTISET['20-Apr-04',
'14-May-04',
PG36
MULTISET['28-Apr-04',
'14-May-04']
PL94
Null
'26-May-04']
La siguiente consulta basada en la agregación de multiconjuntos: SELECT FROM
FUSION(viewDates) AS viewDateFusion, INTERSECTION(viewDates) AS viewDatelntersection PropertyViewDates;
produce el siguiente conjunto de resultados: ""
wDateFusion
04',
FUSION e INTERSECTION
'20-Apr-04', '14-May-04',
'26-May-04',
viewDatelntersection MULTISET[' 14-May-04']
'28-Apr-04']
La fusión se calcula descargando primero las filas que tengan un valor nulo (en este caso, la fila del inmueble PL94) y copiando luego cada miembro de cada uno de los restantes tres multiconjuntos en el conjunto de resultados. La intersección se calcula descartando de nuevo las filas que tengan un valor nulo y luego localizando los duplicados en los multiconjuntos de entrada.
~
28.4.10 Vistas tipadas SQL:2003 también soporta las vistas tipadas, en ocasiones denominadas vistas de objetos o vistas referenciables. Una vista tipada se crea basándose en un tipo estructurado particular y también puede crearse una subvista basándose en esta vista tipada. El siguiente ejemplo ilustra el uso de vistas tipadas.
I
Ejemplo 28.14
Creación de vistas tipadas
Las siguientes instrucciones crean dos vistas basada~s
tipos estructurados PersonType y StaffType.
CREATE VIEW FemaleView OF PersonType (REF IS personlD DERIVED)
AS SELECT
fName, IName
Capítulo 28 Basesde datos objeto-relacionales 873 FROM ONLY (Person) WHERE sex = 'F'; CREATE VIEW FemaleStaff3ViewOF StaffTypeUNDER FemaleView AS SELECT fName, IName, staffNo,position FROM ONLY (Staff) WHERE branchNo = 'B003';
h
La cláusula (REF IS personlD DERIVED) es la especificación de columna auto-referencial de que hemos hablado anteriormente. Cuando se define una subvista, esta cláusula no puede especificarse. Cuando se define una supervista máxima, sí que puede especificarse esta cláusula, aunque no puede utilizarse la opción SYSTEM GENERATED, sino sólo USER GENERATED o DERIVED. Si se especifica USER GENERATED, entonces el grado de la vista es uno más que el número de atributos del tipo estructurado asociado; si se especifica DERIVED, entonces el grado es igual al número de atributos del tipo estructurado asociado y no se incluye ninguna columna de auto-referencia adicional. Al igual que sucede con las vistas normales, pueden especificarse nuevos nombres de columnas e
---.J
incluirse la cláusula WITH CHECK OPTION.
28.4.11
Módulos almacenados persistentes
Se han añadido varios tipos nuevos de instrucciones a SQL para hacer que el lenguaje sea computacionalmente completo, de modo que pueda almacenarse y ejecutarse desde la base de datos el comportamiento de los objetos (métodos) en forma de instrucciones SQL (ISO, 1999b; 2003b). Las instrucciones pueden agruparse en una instrucción compuesta (bloque), con sus propias variables locales. Algunas de las instrucciones adicionales proporcionadas son: •
Una instrucción de asignación que permite asignar el resultado de una expresión SQL a una variable local, a una columna o a un atributo de un UDT. Por ejemplo: DECLARE b BOOtEAN; DECLARE staffMember StaffType; b = staffMember.isManager;
•
Una instrucción IF...THEN ...ELSE ...END IF que permite el procesamiento un ejemplo de esta instrucción en el método isManager del Ejemplo 28.3.
•
Una instrucción CASE que permite la selección de una ruta de ejecución basada en un conjunto de alternativas. Por ejemplo: CASE lowercase(x) WHEN 'a' WHEN'b'
THEN SET x THEN SET x SET y WHEN 'default' THEN SET x END CASE; •
condicional. Hemos visto
= 1; = 2; = O; = 3;
Un conjunto de instrucciones que permite la ejecución repetida de un bloque de instrucciones Las instrucciones iterativas son FOR, WHILE y REPEAT, ejemplos de las cuales serían: FOR x, y AS SELECT a, b FROM Table1 WHERE ENDFOR; WHILE b <> TRUE DO ENDWHILE;
CondicionBusqueda
DO
SQL.
874
Sistemas de bases de datos REPEAT UNTIL b <> TRUE ENDREPEAT;
•
Una instrucción CALL que permite invocar procedimientos y una instrucción RETURN que permite usar una expresión SQL como valor de retorno de un método o función SQL.
Gestión de condiciones El lenguaje SQL/PSM (SQL Persistent Stored Module) incluye mecanismos de gestión de condiciones para el tratamiento de las excepciones y condiciones de terminación. La gestión de condiciones funciona definiendo primero una rutina de tratamiento, especificando su tipo, la excepción y las condiciones de terminación que puede resolver, asi como la acción que lleva a cabo para ello (una instrucción de procedimiento SQL). La gestión de condiciones también proporciona la capacidad para señalizar explícitamente condiciones de terminación y excepciones, utilizando la instrucción SIGNAL/RESIGNAL. Puede declararse una rutina de tratamiento para una excepción o condición de terminación asociadas utilizando la instrucción DECLARE ...HANDLER:
DECLARE
{CONTINUEIEXITIUNDO}HANDLER FOR SQLSTATE {sqlstateValue IconditionName ISQLEXCEPTION SQLWARNING
I
I
NOT FOUND} handlerAction;
Pueden declararse un nombre de condición y un valor SQLSTATE correspondiente
opcional utilizando:
DECLARE conditionName CONDITION [FOR SQLSTATE sqlstateValue] y una excepción de condición puede ser señalizada o reseñalizada utilizando: SIGNAL sqlstateValue; o RESIGNAL sqlstateValue; Cuando se ejecuta una instrucción compuesta que contiene una declaración de rutina de tratamiento, se crea una rutina de tratamiento para las condiciones asociadas. Una rutina de tratamiento se activa cuando es la rutina de tratamiento más apropiada para la condición que haya sido generada para la instrucción SQL. Si la rutina de tratamiento ha especificado CONTINUE, al activarse ejecutará la acción de tratamiento antes de devolver el control a la instrucción compuesta. Si el tipo de rutina de tratamiento es EXIT, entonces después de ejecutar la acción de tratamiento, la rutina de tratamiento abandona la instrucción compuesta. Si el tipo de rutina de tratamiento es UNDO, entonces la rutina de tratamiento deshace todos los cambios realizados dentro de la instrucción compuesta, ejecuta la acción de tratamiento asociada y devuelve el control a la instrucción compuesta. Si la rutina de tratamiento no se completa con una condición de compleción con éxito, se ejecuta una reseñalización explícita, que determina si hay otra rutina de tratamiento que pueda resolver la condición.
28.4.12
Disparadores
Como hemos explicado en la Sección 8.2.7, un disparador es una instrucción SQL (compuesta) que es ejecutada automáticamente por el SGBD como efecto secundario de una modificación realizada en una tabla nominada. Es similar a una rutina SQL, en el sentido de que se trata de un enfoque SQL nominado con sendas secciones declarativa, ejecutable y de tratamiento de condiciones. Sin embargo, a diferencia de una rutina, el disparador se ejecuta implícitamente siempre que tenga lugar el suceso de disparo, y los disparadores no tienen ningún argumento. El acto de ejecutar un disparador se conoce en ocasiones con el nombre de disparo o activación del disparador. Los disparadores pueden utilizarse para diversos propósitos, incluyendo: •
la validación los datos de entrada y el mantenimJnto de restricciones de integridad complejas que serían dificiles,de sino imposibles, de imponer median~estricciones de tablas;
Capítulo 28 Bases de datos objeto-relacionales
875
•
soporte de alertas (por ejemplo, utilizando correo electrónico) para señalizar que es necesario tomar una cierta acción cuando se actualiza una tabla de alguna forma concreta;
•
mantenimiento de información de auditoría, registrando los cambios realizados y la identidad de quien los ha realizado;
•
soporte de replicación, como se explica en el Capítulo 24.
El formato básico de la instrucción CREATE TRIGGER es el siguiente:
CREATE TRIGGER NombreDisparador BEFORE
I
AFTER
[REFERENCING
ON
]
[FOR EACH {ROW
I
STATEMENT}]
[WHEN (CondicionDisparador)] Los sucesos de disparo incluyen la inserción, el borrado y la actualización de las filas de una tabla. En este último caso (la actualización) también puede configurarse un suceso de disparo para cubrir columnas nominadas específicas de una tabla. Los disparadores tienen una temporización asociada, con las dos opciones BEFORE y AFTER. Un disparador previo BEFORE se activa antes de que tenga lugar el suceso asociado, mientras que un disparador posterior AFTER se activa después de que haya ocurrido el suceso asociado. La acción desencadenada por el disparador es una instrucción de procedimiento SQL, que puede ejecutarse en una de dos formas: •
para cada fila afectada por el suceso (FOR EACH ROW). Esto se conoce con el nombre de disparador de nivel de fila;
•
sólo una vez para el suceso completo (FOR EACH STATEMENT), que es la opción predeterminada. Esto se denomina disparador de nivel de instrucción.
La lista
puede referirse a:
•
una fila antigua o nueva (OLD/NEW o OLD ROW/NEW ROW), en el caso de un disparador de nivel de fila;
•
una tabla antigua o nueva (OLD TABLE/NEW TABLE), en el caso de un disparador AFTER.
Claramente, los valores antiguos no son aplicables para los sucesos de inserción y los valores nuevos no son aplicables para los sucesos de borrado. El cuerpo de un disparador no puede contener: • instrucciones SQL de transacción, como COMMIT o ROLLBACK; •
instrucciones SQL de conexión, como CONNECT o DISCONNECT;
•
instrucciones SQL de definición o manipulación de esquemas, como la creación o borrado de tablas, tipos definidos por el usuario u otros disparadores;
•
instrucciones ZONE.
SQL de sesión, como SET SESSION CHARACTERISTICS,
SET ROLE, SET TIME
Además, SQL no permite disparadores mutantes, es decir, disparadores que provoque un cambio que haga que vuelva a ser invocado el mismo disparador, generándose así un bucle posiblemente infinito. Ya que puede definirse más de un disparador sobre una misma tabla, el orden de activación de los disparadores es importante. Los disparadores se activan al ejercitarse el suceso de disparo (INSERT, UPDATE, DELETE). El orden que se observa es el siguiente: (1) Ejecución de los disparadores BEFORE de nivel de instrucción sobre la tabla. (2) Para cada fila afectada por la instrucción: (a) ejecución de los disparadores BEFé>~
de nivel de fila;
876
Sistemas de bases de datos (b) ejecución de la propia instrucción; (c) aplicación de las restricciones referenciales; (d) ejecución de los disparadores AFTER de nivel de fila.
(3) Ejecución de los disparadores AFTER de nivel de instrucción sobre la tabla. Observe en esta ordenación que los disparadores BEFORE se activan antes de haber comprobado la restricción de integridad referencia\. Por tanto, es posible que el cambio solicitado que ha hecho activarse al disparador viole las restricciones de integridad de la base de datos y tenga que ser prohibido. Por tanto, los disparadores BEFORE no deben efectuar modificaciones adicionales en la base de datos. Si hubiera más de un disparador en una tabla con el mismo suceso de disparo y la misma temporización (BEFORE o AFTER), el estándar SQL especifica que los disparadores se ejecuten en el orden en que fueron creados. Vamos a ilustrar ahora la creación de disparadores con algunos ejemplos.
I
Ejemplo 28.15
Utilización
de un disparador AFTER INSERT
Crear un conjunto de registros para envío de correspondencia para cada fila PropertyForRent. Para los propósitos de este ejemplo, vamos a suponer que hay un tabla denominada Mailshot donde se guardan los detalles de los inquilinos prospectos y los detalles de los inmuebles. CREATE TRIGGER
InsertMailshotTable
AFTER INSERT ON PropertyForRent REFERENCING NEW ROW AS pfr BEGIN ATOMIC INSERT INTO Mailshot VALUES (SELECT
c.fName, c.IName, c.maxRent, pfr.city, pfr.postcode,
FROM
pfr.propertyNo,
pfr.street,
pfr.type, pfr.rooms, pfr.rent
Client e
WHERE
c.branchNo = pfr.branchNo AND (c.preffype = pfr.type AND c.maxRent <= pfr.rent))
END; Este disparador se ejecuta después de haber EACH, lo que hace que se adopte la opción instrucción INSERT sólo inserta una fila cada basado en una subconsulta que localiza todas
I
Ejemplo 28.16
Utilización
insertado la nueva fila. Se ha omitido la cláusula FOR predeterminada FOR EACH STATEMENT, ya que una vez. El cuerpo del disparador es una instrucción INSERT las filas de clientes correspondientes.
de un disparador
AFTER INSERT con una condición
Crear un disparador que modifique todos los registros de envío de correspondencia bia el precio del alquiler de un inmueble. CREATE TRIGGER UpdateMailshotTable AFTER UPDATE OF rent ON PropertyForRent REFERENCING NEW ROW AS pfr FOREACHROW BEGIN ATOMIC DELE TE FROM Mailshot WHERE maxRent UPDATE Mailshot SET rent = pfr.rent
> pfr.rent;
actuales si cam-
Capítulo 28 Bases de datos objeto-relacionales WHERE
propertyNo
877
= pfr.propertyNo;
END; Este disparador
se ejecuta después de que haya sido actualizado el campo rent de una fila de Se ha especificado la cláusula FOR EACH ROW, ya que puede perfectamente haberse incrementado el valor de todos los alquileres mediante una única instrucción UPDATE, por ejemplo para reflejar el aumento anual del coste de la vida. El cuerpo del disparador tiene dos instrucciones SQL: una instrucción DELETE para borrar los registros de envío de correspondencia para los· que el nuevo precio de alquiler cae fuera del rango de precios deseado por el cliente, y una instrucción PropertyForRenl.
UPDATE para registrar el nuevo precio de alquiler en todas las filas relacionadas con dicho inmueble.
I
Los disparadores pueden ser un mecanismo muy potente si se los usa apropiadamente. La principal ventaja es que pueden almacenarse funciones estándar dentro de la base de datos e imponer su ejecución de manera coherente con cada actualización que en la base de datos se efectúe. Esto puede reducir enormemente la complejidad de las aplicaciones. Sin embargo, puede haber algunas desventajas: • •
•
Complejidad. Cuando la funcionalidad se mueve desde la aplicación a la base de datos, las tareas de diseño, implementación y administración de ésta se hacen más complejas. Funcionalidad oculta. Mover funcionalidad a la base de datos y almacenada en forma de uno o más disparadores puede tener el efecto de ocultar determinada funcionalidad a ojos del usuario. Aunque esto puede simplificar las cosas para el usuario, desafortunadamente también puede tener efectos colaterales que pueden ser no previstos, y potencialmente indeseables y erróneos. El usuario deja de tener el control sobre lo que sucede con la base de datos. Reducción de las prestaciones. Cuando el SGBD está a punto de ejecutar una instrucción que modifica la base de datos, tiene ahora que evaluar la condición de disparo para comprobar si es necesario activar un disparador para la instrucción. Esto tiene un impacto sobre las prestaciones del SGBD. Obviamente, a medida que se incrementa el número de disparadores, esta reducción del rendimiento también es mayor. En los. momentos de mayor carga del sistema, esta reducción puede causar problemas significativos.
Privilegios Para crear un disparador, el usuario debe tener el privilegio TRIGGER sobre la tabla especificada, el privilegio SELECT sobre todas las tablas a las que se haga referencia en la condición de disparo de la cláusula WHEN y todos los privilegios requeridos para ejecutar las instrucciones SQL incluidas en el cuerpo del disparador.
28.4.13
Objetos de gran tamaño
Un objeto de gran tamaño es un tipo de dato que contiene una gran cantidad de información, como por ejemplo un largo archivo de texto o un archivo gráfico. Hay tres tipos distintos de objetos de gran tamaño definidos en SQL:2003: •
Objetos binarios de gran tamaño (BLOB, Binary Large Object), una cadena de caracteres binaria que no tiene asociado ningún conjunto de caracteres ni ningún tipo de intercalación;
•
Objetos de caracteres de gran tamaño (CLOB, Character Large Object) y objetos de caracteres nacionales de gran tamaño (NCLOB, National Character Large Object), siendo ambos cadenas de caracteres.
Los objetos de gran tamaño en SQL son ligeramente distintos del tipo BLOB original presente en algunos sistemas de bases de datos. En tales sistemas, el BLOB era un flujo de bytes no interpretado y el SGBD no tenía ningún conocimiento del contenido del BLCSBo de su estructura interna. Esto evita que el SGBD pueda realizar consultas y operaciones sobre tipos de dat?s que son inherentemente ricos y estructurados, como por
878
Sistemas de bases de datos
ejemplo imágenes, vídeo, documentos de procesamiento de textos o páginas web. Generalmente, esto requiere que todo el BLOB sea transferido a través de la red desde el servidor SGB hasta el cliente, antes de poder realizar ningún procesamiento. Por contraste, los objetos SQL de gran tamaño sí que permiten realizar ciertas operaciones en el servidor SGBD. Los operadores estándar de cadenas, que pueden utilizarse sobre cadenas de caracteres y devuelven cadenas de caracteres, también sirven para las cadenas de caracteres de gran tamaño; entre sus operadores podemos citar: string2), que devuelve la cadena de caracteres que se forma al • El operador de concatenación (stringl unir las dos cadenas de caracteres que actúan como operandos en el orden especificado. 11
•
La función de subcadena de caracteres, SUBSTRING(string FROM startpos FOR length), que devuelve una cadena extraída de otra cadena especificada, empezando en una cierta posición inicial y utilizando una cierta longitud.
•
La función de sustitución de caracteres, OVERLAY(stringl PLACING string2 FROM startpos FOR length), que sustituye una sub cadena de stringl, especificada mediante una posición de inicio y una longitud, por string2. Esto es equivalente a: SUBSTRING(stringl FROM 1 FOR length - 1) string2 SUBSTRING (stringl FROM startpos + length). 11
11
•
Las funciones de control de mayúsculas y minúsculas, UPPER(string) y LOWER(string), ten todos los caracteres de una cadena a mayúsculas/minúsculas.
•
TRAILING BOTH stringl FROM] string2), que devuelLa función de recorte, TRlM([LEADING ve string2 después de eliminar todos los caracteres stringl iniciales y/o finales. Si no se especifica la cláusula FROM, se eliminan los espacios iniciales y finales de string2. 1
que convier-
1
•
La función de longitud, CHAR_LENGTH(string),
•
La función de posición, POSITION(stringl dentro de string2.
que devuelve la longitud de la cadena especificada.
IN string2), que devuelve la posición de inicio de stringl
Sin embargo, las cadenas CLOB no pueden participar en la mayoría de los operadores de comparación, aunque sí pueden hacerla en un predicado LIKE o en predicado o en una comparación o predicado de comparación cuantificado que utilice los operadores igual (=) o distinto «». Como resultado de estas restricciones, no se puede hacer referencia a una columna que haya sido definida como cadena CLOB en lugares tales como una cláusula GROUP BY, una cláusula ORDER BY, una definición de restricción de unicidad o referencial, una columna de combinación o en las operaciones de conjuntos (UNION, INTERSECT y EXCEPT). Una cadena BLOB se define como una secuencia de objetos. Todas las cadenas BLOB son comparables, comparándose entre sí los octetos que tengan la misma posición ordinal. Los siguientes operadores se aplican a cadenas BLOB y devuelven cadenas BLOB, teniendo una funcionalidad similar a los que antes hemos definido: •
el operador de concatenación de BLOB
•
la función de sub cadena BLOB (SUBSTRING);
•
la función de sustitución BLOB (OVERLAY);
•
la función de recorte BLOB (TRIM).
(JI)
Además, también pueden utilizarse con las cadenas BLOB las funciones BLOB _LENGTH y el predicado LIKE.
I
Ejemplo 28.17 Ampliar la tabla
Utilización Staff
ALTER TABLE
de objetos binarios y de caracteres
de gran tamaño
para almacenar un CV y una fotogrcifía del empleado. Staff
ADD COLUMN ALTER TABLE Staff
resume
ADD COLUMN
picture
CLOB(50K); BLOB(l2M);
Y
POSITION
Capítulo 28 Bases de datos objeto-relaciona les
879
Se han añadido dos nuevas columnas a la tabla 8taff: resume, que se ha definido como un CLOB de longitud 50K y picture, que se ha definido como un BLOB de longitud 12M. La longitud de un objeto de gran tamaño se proporciona en forma de valor numérico, con una especificación opcional de K, M o G, indicado kilobytes, megabytes o gigabytes, respectivamente. La longitud predeterminada, si se deja sin especificar, depende de la implementación.
28.4.14
~
Recursión
En la Sección 25.2 hemos hablado de la dificultad que tienen los SGBDR para gestionar consultas recursivas. Una de las principales nuevas operaciones introducidas en SQL para especificar dichas consultas es la recursión lineal. Para ilustrar esta nueva operación, usamos el ejemplo proporcionado en la Sección 25.2 con la relación 8taff simplificada que se muestra en la Figura 25.1(a), que almacena los números de empleados y el número de empleado del correspondiente jefe. Para hallar todos los jefes de todos los empleados, podemos utilizar la siguiente consulta recursiva en SQL:2003: WITH RECURSIVE AIIManagers(staffNo,manager8taffNo)AS (SELECT staffNo,manager8taffNo FROM 8taff UNION SELECT in.staffNo,out.manager8taffNo FROM AIIManagersin, 8taff out WHERE in.manager8taffNo = out.staffNo); SELECT * FROM AIIManagers ORDER BY staffNo, manager8taffNo; Esta consulta crea una tabla de resultados AIIManagerscon dos columnas staffNoy manager8taffNo que contienen todos los jefes de todos"'los empleados. La operación UNION se lleva a cabo realizando la unión de todas las filas producidas por el bloque interno, hasta que no se generen nuevas filas. Observe que si hubiéramos especificado UNION ALL, todos los valores duplicados se guardarían en la tabla de resultados. En algunas situaciones, una aplicación puede requerir que los datos se inserten en la tabla de resultados en un cierto orden. La instrucción de recursión permite especificar dos tipos de ordenación: •
en profundidad, donde cada 'padre' o elemento 'contenedor' aparece en el resultado antes que los elementos que contiene, así como antes de sus 'hermanos' (elementos con el mismo padre o contenedor);
•
en anchura, en la que los elementos siguen a sus 'hermanos', sus hermanos.
estando situados delante de los hijos de
Por ejemplo, al final de la instrucción WITH RECURSIVE podríamos añadir la siguiente cláusula: SEARCH BREADTH FIRST BY staffNo, manager8taffNo SET orderColumn La cláusula SET identifica un nuevo nombre de columna (orderColumn), que SQL utiliza para ordenar los resultados de acuerdo con el tipo de recorrido en profundidad solicitados. Si los datos pueden ser recursivos, y no sólo es recursiva la estructura de datos, puede producirse un bucle infinito, a menos que se pueda detectar la aparición de ciclos. La instrucción recursiva tiene una cláusula CYCLE que ordena a SQL que registre un valor especificado para indicar que una nueva fila ya ha sido añadida a la tabla de resultados. Cada vez que se encuentra una nueva fila, SQL comprueba que la fila no haya sido si esa fila estánuevas -m~cada valor especificado. SQL asumeañadida que sepreviamente, ha encontradodeterminando un ciclo y deja de buscar filascon de el resultados. Un ejemploSidelo laestá, cláusula CYCLE sería: CYCLE staffNo, manager8taffNo
880
Sistemas de bases de datos
SET cycleMarkTO 'Y' DEFAULT 'N' USING cyclePath cycleMarky cyclePath son nombres de columna definidos por el usuario que SQL usará internamente. cyclePath es de tipo ARRAY con una cardinalidad suficientemente grande como para contener todas las filas del resultado y cuyo tipo de elemento es un tipo de fila con una columna para cada columna de la lista de columnas de ciclo (staffNo y managerStaffNo,en nuestro ejemplo). Las filas que satisfacen la consulta se almacenan temporalmente en cyclePath. Cuando se encuentra por primera vez una fila que satisface la consulta (lo que puede determinarse porque dicha fila está ausente de cyclePath), el valor de la columna cycleMarkse configura como 'N'. Cuando se vuelve a encontrar la misma fila (lo que puede determinarse por su presencia en cyclePath), la columna cycleMarkde la fila existente en la tabla de resultados se modifica para asignarle el valor 'Y', con el fin de indicar que la fila es el comienzo de un ciclo.
28.5 Procesamiento y optimización de consultas En la sección anterior hemos introducido algunas características del nuevo estándar SQL, aunque determinadas características, como las colecciones, han sido pospuestas para una versión posterior del estándar. Estas características resuelven muchas de las debilidades del modelo relacional que hemos expuesto en la Sección 25.2. Desafortunadamente, el estándar SQL:2003 no contempla determinadas áreas de ampliación, por lo que la implementación de características tales como el mecanismo para definir nuevas estructuras de índice y para proporcionar al optimizador de consultas información de costes acerca de las funciones definidas por el usuario, variará entre unos productos y otros. La carencia de una forma estándar para que los fabricantes de software integren sus productos con múltiples SGBDOR demuestra que existe la necesidad de estándares adicionales, más allá de las áreas cubiertas por SQL:2003. En esta sección vamos a explorar por qué estos mecanismos son importantes para un verdadero SGBDOR, empleando para ello una serie de ejemplos ilustrativos.
I
Ejemplo 28.18 Utilización de funcion!:s definidas por el usuario Enumerar los apartamentos que se ofrezcan en alquiler en la sucursal B003. Podemos decidir implementar esta consulta utilizando una función, definida de la forma siguiente: CREATE FUNCTION flatTypesORETURNS SET(PropertyForRent) SELECT * FROM PropertyForRentWHERE type = 'Flat'; y la consulta quedará: SELECT propertyNo,street, city,postcode FROM TABLE (flatTypes()) WHERE branchNo = 'B003'; En este caso, lo que esperaríamos es que el procesador de consultas pudiera 'aplanar' esta consulta utilizando los siguientes pasos: (1) SELECT propertyNo, street, city, postcode FROM TABLE (SELECT WHERE
* FROM PropertyForRent WHERE type = 'Flat')
branchNo = 'B003';
(2) SELECT propertyNo, street, city, postcode FROM PropertyForRent WHERE
type
=
'Flat' AND branchNo = 'B003';
Capítulo 28 Bases de datos objeto-relaciona les
881
Si la tabla PropertyForRent tuviera un índice de tipo B-tree sobre la columna branchNo, por ejemplo, el procesador de consultas debería poder utilizar una exploración indexada sobre branchNo para extraer de forma eficiente las fila apropiadas, como se explica en la Sección 21.4.
~
En este ejemplo vemos que una de las capacidades requeridas es que el procesador de consultas del SGBDOR aplane las consultas siempre que sea posible. En este caso sí lo era, porque nuestra función definida por el usuario había sido implementada en SQL. Sin embargo, suponga que la función hubiera sido definida como una función externa. ¿Cómo sabría el procesador de consultas cómo optimizar esta consulta? La respuesta a esta pregunta descansa en un mecanismo de optimización de consultas ampliable. Este mecanismo puede requerir que el usuario proporcione una serie de rutinas específicas para que el optimizador de consultas las utilice en la definición de un nuevo tipo abstracto de datos. Por ejemplo, el SGBDOR Illustra, que ahora es parte de Informix, requiere la siguiente información cuando se define una función definida por el usuario (externa): A El coste de procesador de la función por cada llamada. B El porcentaje esperado de bytes del argumento que la función leerá. Este factor trata de tener en cuenta la situación en que una función toma un objeto de gran tamaño como argumento, pero sin utilizar necesariamente todo el objeto en su procesamiento. C El coste de procesador por cada lectura de byte. El coste de procesador de una invocación de función estará entonces dado por el algoritmo A + C* (B * tamaño esperado del argumento) y el coste de E/S será (B * tamaño esperado del argumento). Por tanto, en un SGBDOR nos gustaría poder proporcionar información para poder optimizar la ejecución de las consultas. El problema con esta técnica es que puede resultar difícil para un usuario proporcionar estos valores. Otra alternativa más atractiva es que el SGBDOR calcule estos valores basándose en la experimentación, después de gestionar funciones y objetos de tamaños y complejidades diferentes.
I
Ejemplo 28.19
Heurísti€os
de procesamiento
de consultas
potencialmente
distintos
Calcular todos los inmuebles de Glasgow que estén situados a menos de dos millas de una escuela elemental y estén gestionados por Ann Beech. SELECT * FROM PropertyForRent p, Staff s WHERE p.staffNo = s.staffNo AND p.nearPrimarySchool(p.postcode) s.fName = 'Ann'
AND
< 2.0
AND
p.city = 'Glasgow'
AND
s.IName = 'Beech':
Para los propósitos de esta consulta, vamos a suponer que hemos creado una función definida por el usuario externa nearPrimarySchool, que toma un código postal y determina a partir de una base de datos interna de edificios conocidos (por ejemplo edificios residenciales, comerciales, industriales) la distancia a la escuela elemental más cercana. Traduciendo esto a un árbol de álgebra relacional, como se explica en la Sección 21.3, obtenemos el árbol mostrado en la Figura 28.3(a). Si ahora utilizamos las heurísticas generales de procesamiento de consultas, normalmente situaríamos las operaciones de selección después del producto cartesiano y transformaríamos el producto cartesiano/selección en una operación de combinación, como se muestra en la Figura 28.3(b). En este caso concreto, puede que esta no sea la mejor estrategia. Si la función definida por el usuario nearPrimarySchool tiene una cantidad significativa de procesamiento que realizar en cada invocación, puede que sea mejor realizar primero la selección sobre la tabla Staff y luego efectuar la operación de combinación sobre staffNo, antes de llamar a la función definida por el usuario. En este caso, también podremos utilizar la regla de la conmutatividad de las combinaciones para reordenar los nodos hoja, de modo que se realice primero la operación de selección más restrictiva (como relación externa en un árbol de combinación de pro-
~
882
Sistemas de bases de datos
fundidad izquierda), como se muestra en la Figura 28.3(c). Asimismo, si el plan de consulta para la operación de selección sobre (nearPrimarySchoolO < 2.0 AND city = 'Glasgow') se evalúa en el orden indicado, de izquierda a derecha, y no hay índices u ordenaciones definidos, de nuevo será poco probable que esto sea tan eficiente como evaluar primero la operación de selección sobre (city = 'Glasgow') y luego la selección sobre (nearPrimarySchooIO< 2.0), como se ilustra en la Figura 28.3(d). Sp.nearPrimarySchool{p.postcode)<2.0
3staffNo
n p.city='Glasgow'
r Ss.fName='Ann'
o s.IName='Beech'
/
/~
s.IName='Beech'
L' p.city=,,'Glasgow'
r Sp.staffNo=:os.staffNo
\
Ss.fName='Ann'
Sp.nearPrimarySchool(p.postcode)<2.0
s
P
r
/\ x
P
s
(a)
(b)
Sp. nearPrimarySchool(p.postcode)<2.0 [ p.city='Glasgow'
Sp.nearPrimarySchool(p.postcode)<2.0
r
r
3staffNo
/
Ss.fName='Ann'
/~
rJ s.IName='Beech'
/
P
Ss.fName='Ann'
s
s (e)
Figura 28.3.
/~
3staffNo
ti s.IName='Beech'
\
Sp.City='Glasgow'
P
(d)
(a) Árbol de álgebra relacional canónico; (b) árbol de álgebra relacional optimizado en
el que se han bajado todas las selecciones en el árbol; (c) árbol de álgebra relacional optimizado en el que sólo se ha bajado la selección sobre Staff; (d) árbol de álgebra relacional optimizado en el que se separarán las selecciones sobre PropertyForRent.
--.J
En el Ejemplo 28.19, el resultado de la función definida por el usuario nearPrimarySchool es un valor en coma flotante que representa la distancia entre un inmueble y la escuela elemental más cercana. Una estrategia alternativa para mejorar el rendimiento de esta consulta consiste en añadir un índice no sobre la propia función, sino sobre el resultado de la función. Por ejemplo, en Illustra podemos crear un índice del resultado de este UDF utilizando la siguiente instrucción SQL: CREATE INDEX nearPrimarySchoolindex ON PropertyForRent USING B-tree (nearPrimarySchool(postcode)); na
Ahora, cada vez que se inserte un registro en la tabla PropertyForRent, o cada vez que se actualice la columde un registro existente, el SGBDOR calculará la función nearPrimarySchool e indexará el resulta-
postcode
Capítulo 28 Bases de datos objeto-relaciona les
883
do. Cuando se borre un registro de PropertyForRent, el SGBDOR volverá a calcular esta función para borrar el correspondiente registro de indice. Después de eso, cada vez que aparezca el UDF en una consulta, Illustra podrá usar el índice para extraer el registro y mejorar así el tiempo de respuesta. Otra estrategia que debería ser posible es permitir que un UDF sea invocado no desde el servidor SGBDOR, sino desde el cliente. Esta estrategia puede ser apropiada cuando la cantidad de procesamiento del UDF sea grande y el cliente tenga la potencia y la capacidad de ejecutar el UDF (en otras palabras, si el cliente es una máquina relativamente potente). Esto descarga de procesamiento al servidor y ayuda a mejorar las prestaciones y la tasa de procesamiento del sistema global. Esto resuelve otro problema asociado con los UDF del que todavía no hemos hablado y que tiene que ver con la seguridad. Si el UDF causa algún error fatal en tiempo de ejecución, y si el código del UDF está montado con el del servidor SGBDOR, dicho error puede tener como consecuencia que el servidor se pare. Obviamente, el SGBDOR tiene que protegerse frente a esta eventualidad. Una posible solución consiste en hacer que todos los UDF se escriban en un lenguaje interpretado, como SQL o lava. Sin embargo, ya hemos visto que SQL:2003 permite invocar como UDF rutinas externas escritas en un lenguaje de programación de alto nivel, como C o C++. En este caso, una técnica alternativa consiste en ejecutar el UDF en un espacio de direcciones distinto al del servidor SGDOR, y que el UDF y el servidor se comuniquen mediante algún mecanismo IPC (interprocess communication, comunicación interprocesos). En este caso, si el UDF provoca un error fatal en tiempo de ejecución, el único proceso afectado será el del propio UDF.
28.5.1
Nuevos tipos de índices
En el Ejemplo 28.19 hemos visto que un SGBDOR puede calcular e indexar el resultado de una función definida por el usuario que devuelva datos escalares (tipos de datos numéricos y de caracteres). Los SGBD re lacionales tradicionales utilizan índices B-tree para acelerar el acceso a los datos escalares (véase el Apéndice C). Sin embargo, un árbol binario (B-tree) es un método de acceso unidimensional que resulta inapropiado para los accesos multidimensionales, como los que resultan habituales en los sistemas de información geográfica, en los sistemas de telemetría o en los de captura de imágenes. Al tener la capacidad de definir tipos de datos complejos en un SGBDOR, se requieren estructuras de índice especializadas para tener un acceso eficiente a los datos. Algunos SGBDOR están comenzando a soportar tipos de índices adicionales tales como: •
árboles binarios genéricos que permiten que los árboles binarios se construyan sobre cualquier tipo de datos, no sólo alfanumérico;
•
árboles cuaternarios (Finkel y Bentley, 1974);
•
árboles K-D-B (Robinson, 1981);
•
árboles R (árboles de región) para acceso rápido a datos bidimensionales 1984);
•
árboles de cuadrícula (Nievergelt el al., 1984);
•
árboles D, para soporte de texto.
y tridimensionales
(Gutman,
El máximo grado de flexibilidad se obtiene si se dispone de un mecanismo mediante el que incluir cualquier estructura de índice definida por el usuario. Esto requiere que el SGBDOR publique una interfaz de método de acceso que permita a los usuarios proporcionar sus propios métodos de acceso apropiados a sus necesidades concretas. Aunque esto suene relativamente sencillo, el programador que se encargue de programar el método de acceso tiene que tener en cuenta mecanismos del SGBD tales como el bloqueo, la recuperación y la gestión de páginas. Un SGBDOR podría proporcionar una plantilla genérica de estructura de índice que fuera lo suficientemente general como para abarcar la mayoría de las estructuras de índice que los usuarios pudieran diseñar y conectar a los mecanismos normales del SGBD. Por ejemplo, GiST (Generalized Search Tree) es una plantilla de estructura de índice basada en árboles binarios que permite utilizar muchas estructuras de índice basadas en árbol con un esfuerzo dtf codificación mínimo (Hellerstein el al., 1995).
\
884
Sistemas de bases de datos
28.6 Extensiones orientadas a objetos en Oracle En la Sección 8.2 hemos examinado algunas de las funcionalidades estándar de Oracle, incluyendo los tipos de datos básicos soportados por Oracle, el lenguaje de programación procedimental PL/SQL, los procedimientos y funciones almacenados y los disparadores. Muchas de las características de orientación a objetos incluidas en el nuevo estándar SQL:2003 aparecen en Oracle de una forma u otra. En esta sección vamos a analizar brevemente algunas de esas características de orientación a objetos de Oracle.
28.6.1 Tipos de datos definidos por el usuario Además de soportar los tipos de datos predefinidos que hemos analizado en la Sección 8.2.3, Oracle soporta dos tipos de datos definidos por el usuario: •
tipos de objetos;
•
tipos de colección.
Tipos de objetos Un tipo de objeto es un objeto del esquema que tiene un nombre, un conjunto de atributos basado en los tipos de datos predefinidos o posiblemente en otros tipos de objetos y un conjunto de métodos, de forma similar a lo que hemos visto para un tipo de objetos SQL:2003. Por ejemplo, podríamos crear los tipos Address, Staff y Branch de la forma siguiente: CREATE TYPE AddressType AS OBJECT ( street VARCHAR2(25), city VARCHAR2(15), postcode VARCHAR2(8)); CREATE TYPE StaffType AS OBJECT ( staffNo VARCHAR2(5), fName VARCHAR2(l5), IName VARCHAR2(l5), "" position VARCHAR2(lO), sex CHAR, DOB DATE, salary DECIMAL(7,2), MAP MEMBER FUNCTION age RETURN INTEGER, PRAGMARESTRICT_REFERENCES(age, WNDS, WNPS, RNPS)) NOTFINAL; CREATE TYPE BranchTypeAS OBJECT ( branchNoVARCHAR2(4), address AddressType, MAP MEMBER FUNCTION getbranchNo RETURN VARCHAR2(4), PRAGMA RESTRICT_REFERENCES(getbranchNo, WNDS, WNPS,RNDS,
RNPS));
Entonces, podemos crear una tabla de (objetos) Branch mediante la siguiente instrucción: CREATE TABLE Branch OF BranchType(branchNoPRIMARY
KEY);
Esto crea una tabla Branch con columnas branchNo y address de tipo AddressType. Cada fila de la tabla Branch es un objeto de tipo BranchType.La cláusula pragma es una directiva del compilador que deniega a las funciones miembro el acceso de lectura/escritura a las tablas de la base de datos y/o a las variables de paquete (WNDS significa no modifica las tablas de la base de datos, WNPS significa no modifica las variables de paquete, RNDS significa no consulta las tablas de la base de datos y RNPS significa no hace referencia a
/
Capítulo 28 Bases de datos objeto-relaciona les variables del paquete). Este ejemplo ilustra también otra característica objeto-relacional ficación de métodos.
885
de Oracle, la especi-
Métodos Los métodos de un tipo de objetos se clasifican como métodos miembro, métodos estáticos y métodos de comparación. Un método miembro es una función o procedimiento que tiene siempre un parámetro SELF implícito como primer parámetro, cuyo tipo es el tipo de objeto contenedor. Dichos métodos son útiles como funciones observadoras y mutadoras y se invocan con el denominado estilo egoísta, como por ejemplo object.methodO, donde el método encuentra todos sus argumentos entre los atributos del objeto. Hemos definido un método miembro observador getbranchNo en el nuevo tipo BranchType. En breve veremos la implementación de este método. Un método estático es una función o procedimiento que no tiene un parámetro SELF implícito. Dichos métodos son útiles para especificar constructores definidos por el usuario o métodos de transformación de tipos y pueden invocarse cualificando el método con el nombre de tipo, como en typename.methodO. Un método de comparación se utiliza para comparar instancias de tipos de objetos. Oracle proporciona dos formas de definir una relación de orden entre objetos de un cierto tipo: •
un método de mapeo utiliza la capacidad de Oracle para comparar tipos predefinidos. En nuestro ejemplo, hemos definido un método de mapeo para el nuevo tipo BranchType, que compara dos objetos de sucursal basándose en los valores del atributo branchNo. En unos momentos veremos una implementación de este método.
•
un método de ordenación utiliza su propia lógica interna para comparar dos objetos de un cierto tipo de objeto. Devuelve un valor que codifica la relación de orden. Por ejemplo, puede devolver -1 si el primero de los dos operando s es más pequeño, cero si son iguales y 1 si el primero es mayor.
Para un tipo de objeto, puede definirse un método de mapeo o un método de ordenación, pero no ambos. Si un tipo de objeto no tiene métodos de comparación, Oracle no puede determinar una relación mayor que o menor que entre objetos de dicho tipo. Sin embargo, sí que puede tratar de determinar si dos objetos de dicho tipo son iguales, utilizando las"siguientes reglas: •
si todos los atributos son no nulos e iguales, los objetos se consideran iguales;
•
si hay un atributo para el que los dos objetos tienen valores no nulos distintos, los objetos se consideran distintos;
•
en caso contrario, Oracle informa de que la comparación no es posible (nula).
Pueden implementarse métodos en PL/SQL, Java y e y está permitida la sobrecarga siempre que los parámetros formales difieran en número, orden o tipo de dato. Para el ejemplo anterior, podríamos crear el cuerpo para las funciones miembro especificadas para los tipos BranchType y StaffType de la forma siguiente: CREATE OR REPLACE TYPE BODY BranchType AS MAP MEMBER FUNCTION getbranchNo RETURN VARCHAR2(4) BEGIN RETURN branchNo; END; END; CREATE OR REPLACE TYPE BODY StaffType AS MAP MEMBER FUNCTION age RETURN INTEGER IS varNUMBER; BEGIN var := TRUNqMONTHS_BETWEEN(SYSDATE, RETURNvar; END; END;
IS
DOB)/12);
886
Sistemas de bases de datos
La función miembro getbranchNo actúa no sólo como método observador para devolver el valor del atributo branchNo, sino también como método de comparación (mapeo) para este tipo. Veremos un ejemplo de uso de este método en breve. Como en SQL:2003, las funciones definidas por el usuario también pueden declararse al margen de la instrucción CREA TE TYPE. En general, las funciones definidas por el usuario pueden emplearse en: •
la lista de selección de una instrucción SELECT;
•
una condición en la cláusula WHERE;
•
las cláusulas ORDER BY o GROUP BY;
•
la cláusula VALUES de una instrucción INSERT;
•
la cláusula SET de una instrucción UPDATE.
Oracle también permite crear operadores definidos por el usuario mediante la instrucción CREATE OPERATOR. Al igual que los operadores predefinidos, los operadores definidos por el usuario toman un conjunto de operandos como entrada y devuelven un resultado. Una vez definido un nuevo operador, puede utilizarse en las instrucciones SQL al igual que cualquier otro operador predefinido.
Métodos constructores Todo tipo de objeto tiene un método constructor definido por el sistema que genera un nuevo objeto de acuerdo con la especificación de tipo del objeto. El método constructor tiene el mismo nombre que el tipo de objeto y tiene una serie de parámetros con los mismos nombres y tipos que los atributos del tipo de objeto. Por ejemplo, para crear una nueva instancia de BranchType,podríamos utilizar la siguiente expresión: BranchType('B003', AddressType('163 Main St', 'Glasgow',
'GIl 9QX'));
Observe que la expresión AddressType(' 163 Main St', 'Glasgow', ción del constructor para el tipo AddressType.
Identificadores
de objetos
'G 11 9QX') es en sí misma una invoca-
""
Todo objeto fila en una tabla de objetos tiene un identificador lógico de objeto asociado (OID), que de forma predeterminada es un identificador unívoco generado por el sistema que se asigna a cada objeto de fila. El propósito del OID es identificar unívocamente cada objeto de fila dentro de una tabla de objetos. Para hacer esto, Oracle crea y mantiene implícitamente un índice sobre la columna OID de la tabla de objetos. La columna OID está oculta a los usuarios y no existe forma de acceder a su estructura interna. Aunque los valores OID no son muy significativos en sí mismos, dichos valores pueden usarse para extraer objetos y navegar de unos objetos a otros (observe, que los objetos que aparecen en las tablas de objetos se denominan objetos de fila y que los objetos que ocupan columnas de tablas relacionales o que son atributos de otros objetos se denominan objetos de columna). Oracle requiere que todo objeto de fila tenga un OID unívoco. El valor del OID unívoco puede ser especificado de forma que se genere a partir de la clave principal del objeto de fila y que sea generado por el sistema, utilizando la cláusula OBJECT IDENTIFIER PRIMARY KEY o la cláusula OBJECT IDENTIFIER SYSTEM GENERATED (opción predeterminada) dentro de la instrucción CREATE TABLE. Por ejemplo, podríamos haber creado la tabla Branch de la forma siguiente: CREATE TABLE Branch OF BranchType(branchNoPRIMARY KEY) OBJECT IDENTIFIER PRlMARY KEY;
Tipo de dato REF Oracle proporciona un tipo de dato predefinido denominado REF para encapsular las referencias a los objetos de fila y un tipo de objeto especificado. En la práctica, un REF se utiliza para modelar una asociación entre dos objetos de fila. Los REF pueden usarse para examinar o actualizar el objeto al que hacen referencia y para obtener una copia de dicho objeto. Los únicos cambios que pueden realizarse en un valor REF son sustituir
Capítulo 28 Bases de datos objeto-relacionales
887
su contenido por una referencia a otro objeto distinto del mismo tipo de objeto, o asignarle un valor nulo. En el nivel de implementación, Oracle utiliza los identificadores de objetos para construir los valores REF. Al igual que en SQL:2003, puede restringirse un valor REF para que sólo contenga referencias a una tabla de objetos especificada, utilizando una cláusula SCOPE. Ya que es posible que el objeto identificado con un valor REF deje de estar disponible, por ejemplo debido al borrado del objeto, Oracle SQL tiene un predicado IS DANGLING para comprobar los valores REF para ver si no apuntan a ningún objeto válido. Oracle también proporciona un operador de des-referencia, DEREF, para acceder al objeto al que hace referencia un valor REF. Por ejemplo, para modelar el gerente de una sucursal, podríamos cambiar la definición del tipo BranchTypepor: CREATE TYPE BranchTypeAS OBJECT ( branchNo VARCHAR2(4), address AddressType, manager REF StaffType, MAP MEMBER FUNCTION getbranchNo RETURN PRAGMA RESTRICT_REFERENCES(getbranchNo,
VARCHAR2(4), WNDS, WNPS,RNDS,
RNPS));
En este caso, hemos modelado el gerente mediante el tipo de referencia, REF StaffType.En unos momentos veremos un ejemplo de cómo acceder a esta columna.
Herencia de tipos Oracle soporta la herencia simple permitiendo derivar un subtipo de un único tipo padre. El subtipo hereda todos los atributos y métodos del supertipo y puede añadir adicional mente nuevos atributos y métodos, así como sustituir cualquiera de los métodos heredados. Al igual que con SQL:2003, se utiliza una cláusula UNDER para especificar el supertipo.
Tipos de colección Oracle soporta actualmente dos tipos de colección: tipos de matriz y tablas anidadas.
Tipos de matriz Una matriz es un conjunto ordenado de elementos de datos que son todos del mismo tipo de dato. Cada elemento tiene un índice, que es un número correspondiente a la posición del elemento dentro de la matriz. Una matriz puede tener tamaño fijo o variable, aunque en este último caso es necesario especificar un tamaño máximo en el momento de declarar el tipo de matriz. Por ejemplo, una sucursal puede tener hasta tres números telefónicos, lo que podríamos modelar en Oracle declarando el nuevo tipo siguiente: CREATE TYPE TelNoArrayTypeAS VARRAY(3) OF VARCHAR2(13); La creación de un tipo de matriz no asigna espacio, sino que simplemente define un tipo de dato que puede utilizarse como: •
el tipo de dato de una columna de una tabla relacional;
•
un atributo de un tipo de objeto;
•
una variable, parámetro o tipo de retorno de una función PLlSQL,
Por ejemplo, podríamos modificar el tipo BranchTypepara incluir un atributo de este nuevo tipo: phoneList TelNoArrayType, Una matriz se almacena normalmente incrustada, es decir, en el mismo espacio de tablas que los demás datos de su fila. Sin embargo, si es suficientemente grande, Oracle la almacena como un BLOB.
Tablas anidadas Una anidada ~ un que conjunto de elementos datos son Si todos del mismo tipoundetipo dato. Tienetabla una única c~~na es de desordenado un tipo predefinido o de undetipo de que objeto. la columna es de de
888
Sistemas de bases de datos
objeto, la tabla puede también considerarse como una tabla multicolumna, existiendo una columna para cada atributo del tipo de objeto. Por ejemplo, para modelar los parientes de los empleados, podríamos definir un nuevo tipo de la forma siguiente: CREATE TYPE NextOfKinTypeAS OBJECT ( fName VARCHAR2(l5), /Name VARCHAR2(l5), te/No VARCHAR2(13)); CREATE TYPE NextOfKinNestedTypeAS TABLE OF NextOfKinType; Podemos modificar ahora el tipo StaffTypepara incluir este nuevo tipo en forma de tabla anidada: nextOfKin NextOfKinNestedType, y crear una tabla para los empleados utilizando la instrucción siguiente: CREATE TABLE Staff OF StaffType( PRIMARY KEY staffNo) OBJECT IDENTlFIER IS PRIMARY
KEY
NESTED TABLE nextOfKinSTORE AS NextOfKinStorageTable( (PRIMARY KEY(Nested_ Table_ld,IName, teINo)) ORGANIZATlON INDEX COMPRES S) RETURN AS LOCATOR; Las filas de una tabla anidada se almacenan en una tabla de almacenamiento separada que no puede ser consultada directamente por el usuario, pero a la que sí se puede hacer referencia en instrucciones DDL para propósitos de mantenimiento. Una columna oculta de esta tabla de almacenamiento, Nested_Table_ld, establece la correspondencia entre las filas y su correspondiente fila padre. Todos los elementos de la tabla anidada de una fila determinada de Staff tendrán el mismo valor de Nested_Table_ld y los elementos que pertenezcan a una fila distinta de Stafftendrán un valor de Nested_Table_ld diferente. Ya hemos indicado que las filas de la tabla-ªnidada nextOfKinpueden almacenarse en una tabla de almacenamiento separado denominada NextOfKinStorageTable.En la cláusula STORE AS hemos especificado también que la tabla de almacenamiento tiene una organización mediante índice (ORGANIZATION INDEX), para agrupar las filas que pertenezcan al mismo padre. Hemos especificado también la opción COMPRESS, para que la parte Nested_Table_ld de la clave de índice sólo se almacene una vez para cada fila correspondiente a una fila padre, en lugar de repetirla para cada fila que dependa de la fila padre. La especificación de Nested_Table_ld y de los atributos indicados como clave primaria para la tabla de almacenamiento sirve a dos propósitos: sirve como clave para el índice e impone la unicidad de las columnas (IName, telNo) de una tabla anidada dentro de cada fila de la tabla padre. Al incluir estas columnas en la clave, la instrucción garantiza que las columnas contengan valores distintos dentro del conjunto de valores correspondientes a cada empleado. En Oracle, los valores de tipo colección están encapsulados. En consecuencia, los usuarios deben acceder al contenido de una colección a través de las interfaces proporcionadas por Oracle. Generalmente, cuando el usuario accede a una tabla anidada, Oracle devuelve el valor de colección completo al proceso de cliente del usuario. Esto puede tener un impacto sobre el rendimiento, por lo que Oracle soporta la capacidad de devolver un valor de tabla anidada en forma de localizador, que es como una especie de descriptor del valor colección. La cláusula RETURN AS LOCATOR indica que la tabla anidada puede devolverse en forma de localizador cuando sea extraída. Si no se especifica esta opción, la opción predeterminada es VALUE, que indica que debe devolverse toda la tabla anidada, en lugar de devolver un localizador de la misma. Las tablas anidadas difieren de las matrices de la forma siguiente: •
Las matrices tienen un tamaño máximo, mientras que la tablas anidadas no .
•
Las matrices son siempre densas, mientras que las tablas anidadas pueden ser dispersas, de modo que pueden borrarse elementos individuales de una tabla anidada, pero no de una matriz.
~
Capítulo 28 Bases de datos objeto-relaciona les •
•
889
Oracle almacena los datos de las matrices de manera incrustada (en el mismo espacio de tablas), mientras que los datos de las tablas anidadas se almacenan en un tabla de almacenamiento separada, que es una tabla de base de datos generada por el sistema y que está asociada con la tabla anidada . Cuando se las almacena en la base de datos, las matrices retienen su ordenación y sus subíndices, mientras que la tablas anidadas no.
28.6.2
Manipulación de tablas de objetos
En esta sección vamos a ver brevemente cómo manipular tablas de objetos utilizando los objetos de ejemplo que antes hemos creado como ilustración. Por ejemplo, podemos insertar objetos en la tabla 8taff de la forma siguiente: INSERT INTO StaffVALUES ('SG37', 'Ann', 'Beech', 'Assistant', '1O-Nov-1960', 12000, NextOfKinNestedType()); INSERT INTO StaffVALUES ('SG5', 'Susan', 'Brand', 'Manager', '3-Jun-1940', 24000, NextOfKinNestedType());
'F', 'F',
La expresión NextOfKinNestedTypeOinvoca el método constructor para este tipo, con el fin de crear un atributo nextOfKinvacío. Podemos insertar datos en la tabla anidada utilizando la siguiente instrucción: INSERT INTO TABLE (SELECT s.nextOfKin FROM 8taffs WHERE s.staffNo = 'SG5') VALUES ('John', 'Brand', '0141-848-2000'); Esta instrucción utiliza una expresión TABLE'para identificar la tabla anidada como destino de la inserción, en concreto la tabla anidada de la columna nextOfKindel objeto de fila de la tabla 8taff que tiene un valor de staffNoigual a 'SG5'. Finalmente, podemos insertar un objeto en la tabla Branch: INSERT INTO Branch ~ SELECT 'B003', AddressType('163 Main St', 'Glasgow', 'Gll 9QX'), REF(s), TeINoArrayType('0141-339-2178', '0141-339-4439') FROM 8taffs WHERE s.staffNo = '8G5'; o alternativamente: INSERT INTO Branch VALUES ('B003',AddressType('163 Main St', 'Glasgow', (SELECT REF(s) FROM 8taff s WHERE s.staffNo = 'SG5'), TeINoArrayType('0141-339-2178', '0141-339-4439'));
'Gll
9QX'),
Consulta de las tablas de objetos En Oracle, podemos devolver una lista ordenada de números de sucursal utilizando la siguiente consulta: SELECT b.branchNo FROM Branch b ORDER BY VALUE(b); Esta consulta invoca implícitamente el método de comparación getbranchNo que hemos definido como método de mapeo para el tipo BranchType,con el fin de ordenar los datos de forma ascendente según el valor de branchNo. Podemos devolver todos los datos para cada sucursal utilizando la siguiente consulta: SELECT b.branchNo, b.address, DEREF(b.manager), b.phoneList FROM Branch b WHERE b.address.city = 'Glasgow' ORDERBYVALU~
890
Sistemas de bases de datos
Observe el uso del operador DEREF para acceder al objeto que representa al jefe de un empleado. Esta consulta escribe los valores para la columna branchNo, todas las columnas de la dirección postal, todas las columnas del objeto que representa al jefe (que es de tipo StaffType) y todos los números telefónicos relevantes. Podemos extraer los datos de los parientes de los empleados de una sucursal específica utilizando la consulta siguiente: SELECT FROM
b.branchNo, b.manager.staffNo, n.' Branch b, TABLE(b.manager.nextOfKin)
WHERE
b.branchNo =
n
'B003';
Muchas aplicaciones no pueden gestionar los tipos de colección y requieren, en su lugar, que se les proporcione una vista aplanada de los datos. En este ejemplo, hemos aplanado (o desanidado) el conjunto anidado utilizando la palabra clave TABLE. Observe también que la expresión b.manager.staffNo es una abreviatura de y.staffNo, donde y = DEREF(b.manager).
28.6.3 Vistas de objetos En las Secciones 3.4 y 6.4 hemos examinado el concepto de vistas. De igual manera que una vista es una tabla virtual, una vista de objetos es una tabla de objetos virtual. Las vistas de objeto permiten personalizar los datos para diferentes usuarios. Por ejemplo, podemos crear una vista de la tabla Staff para evitar que algunos usuarios vean datos confidenciales de carácter personal o relativos al salario. En Oracle, ahora podemos crear una lista de objetos que no sólo restrinja el acceso a algunos datos, sino que también impida que ciertos métodos sean invocados, como por ejemplo los métodos de borrado. También argumentan algunos autores que las vistas de objetos proporcionan una ruta simple de migración desde una aplicación de tipo relacional pura a otra aplicación orientada a objetos, permitiendo así a las empresas experimentar con esta nueva tecnología. Por ejemplo, suponga que hemos creado los tipos de objeto definidos en la Sección 28.6.1 y suponga que hemos creado y rellenado el siguiente esquema relacional para DreamHome con los tipos estructurados asociados BranchType y StaffType: Branch
(branchNo. street, city, postoode, mgrStaffNo) (teINo, branchNo)
Telephone Staff
(staffNo, fName, IName, position, sex, DOB, salary, branchNo)
NextOfKin
(staffNo, fName, IName, telNo)
Podríamos crear un esquema objeto-relacional siguiente: CREATE SELECT
VIEW
StaffView OF StaffType WITH
utilizando el mecanismo de vistas de objeto, de la forma OBJECT
IDENTIFIER
(staffNo) AS
s.staffNo, s.fName, s.IName, s.sex, s.position, s.DOB, s.salary, CAST (MULTISET FROM
(SELECT
n.fName, n.IName, n.telNo
n.staffNo = s.staffNo) AS NextOfKinNestedType) AS nextOfKin
FROM
NextOfKin n WHERE
Staff s;
CREATE VIEW BranchView OF BranchType WITH OBJECT IDENTIFIER SELECT b.branchNo, AddressType(b.street, b.city, b.postcode) AS address,
(branchNo) AS
MAKE_REF(StaffView, b.mgrStaffNo) AS manager, CAST (MULTISET (SELECT telNo FROM Telephone t FROM
WHERE Branch b;
t.branchNo
=
b.branchNo) AS TelNoArrayType) AS phoneList
En cada caso, la subconsulta SELECT dentro de la expresión CAST/MULTISET requeridos (en el primer caso, una lista de par¡s
selecciona los datos
para el empleado, y en el segundo caso, una lista de núme-
Capítulo 28 Bases de datos objeto-relaciona les
891
ros telefónicos para la sucursal). La palabra clave MULTISET indica que se trata de una lista, en lugar de ser un valor único, mientras que el operador CAST transforma esta lista, para que sea del tipo requerido. Observe también el uso del operador MAKE _REF, que crea un valor REF a una fila de una vista de objetos o a una fila de una tabla de objetos cuyo identificador de objetos esté basado en la clave principal. La cláusula WITH OBJECT IDENTIFIER especifica los atributos del tipo de objeto que se utilizarán como clave para identificar cada fila de la vista de objetos. En la mayoría de los casos, estos atributos se corresponden con las columnas de clave principal de la tabla base. Los atributos especificados deben ser unívocos e identificar exactamente una fila de la vista. Si la vista de objetos está definida sobre una tabla de objetos o sobre otra vista de objetos, esta cláusula puede omitirse o bien especificarse la cláusula WITH OBJECT IDENTIFIER DEFAULT. En ambos casos, habremos especificado la clave principal de la tabla base correspondiente como mecanismo para proporcionar la unicidad.
28.6.4 Privilegios Oracle define los siguientes privilegios del sistema para los tipos definidos por el usuario: •
CREA TE TYPE: para crear tipos definidos por el usuario dentro del esquema del usuario;
•
CREA TE ANY TYPE: para crear tipos definidos por el usuario en cualquier esquema;
•
ALTER ANY TYPE: para modificar tipos definidos por el usuario en cualquier esquema;
•
DROP ANY TYPE: para eliminar tipos nominado s en cualquier esquema;
•
EXECUTE ANY TYPE: para utilizar y referenciar tipos nominado s en cualquier esquema.
Además, el privilegio EXECUTE sobre objetos del esquema permite al usuario utilizar el tipo para definir una tabla, para definir una columna en una tabla relacional, para declarar una variable o parámetro de dicho tipo nominado y para invocar los métodos del tipo.
28.7 Comparación de los SGBDOR y de los SGBDOO Vamos a concluir nuestro trai;miento de los SGBD objeto-relacionales y de los SGBD orientados a objetos con una breve comparación de los dos tipos de sistemas. Para propósitos de comparación, examinaremos los sistemas desde tres perspectivas distintas: modelado de datos (Tabla 28.2), acceso a los datos (Tabla 28.3) y compartición de datos (Tabla 28.4). Asumimos que los SGBDOR futuros será compatibles con el estándar SQL: 1999/2003. Tabla 28.2.
Comparación
de los SGBDOR y los SGBDOO en términos de modelado de datos.
Característica
SGBDOR
SGBDOO
Identidad de los objetos (OID)
Soportada mediante el tipo REF.
Soportada
Encapsulación
Soportada mediante los UDT.
Soportada, pero se rompe para las consultas
Herencia
Soportada (jerarquías separadas para los Soportada UDT y las tablas). Soportada (invocación de los UDP basada Soportada como en un lenguaje modelo de programación orientada a objetos. en la función genérica).
Polimorfismo
Objetos complejos Relaciones
Soportados mediante los UDT.
Soportados.
Soporte completo con restricciones de integridad referencial definidas por el usuano.
Soportadas (por ejemplo, utilizando bibliotecas de clases).
892
Sistemas de bases de datos Tabla 28.3.
Comparación
de los SGBDOR y los SGBDOO en términos de acceso a los datos.
SGBDOR
Característica
SGBDOO
Creación y acceso a datos persistentes Soportado, pero no de forma transparente
Soportado, pero el grado de transparencia difiere entre los distintos productos
Funcionalidad de consulta ad hoc
Soportada completamente
Soportada mediante ODMG 3.0
Navegación
Soportada mediante tipo REF
Soportada completamente
Restricciones de integridad
Soportadas completamente
No soportadas
Servidor de objetos/páginas
Servidor de objetos
Ambos
Evolución del esquema
Soporte limitado
Soportado, pero el grado de soporte difiere entre los distintos productos
Tabla 28.4.
Comparación
de los SGBDOR y los SGBDOO en términos de compartición
de los datos.
Característica
SGBDOR
SGBDOO
Transacciones ACID
Soportadas completamente
Soportadas
Recuperación
Soportada completamente
Soportada, pero el grado de soporte difiere entre unos productos y otros
Modelos avanzados de transacción
No soportados
Soportados, pero el grado de soporte difiere entre unos productos y otros
Seguridad, integridad y vistas
Soporte completo
Soporte limitado
Resumen del capítulo •
No hay un único modelo de datos relacional ampliado que sea de general aceptación; en lugar de ello, existen diversos modelos, cuyas características dependen de la forma y el grado en que se han realizado las ampliaciones al modelo relacional. Sin embargo, todos los valores comparten las mismas tablas relacionales básicas y el mismo lenguaje de consulta, todos incorporan algún tipo de concepto de 'objeto' y algunos de ellos tienen la capacidad de almacenar métodos o procedimientos/disparadores, además de datos, dentro de la base de datos.
•
Se han utilizado diversos términos para designar a los sistemas que amplían el modelo de datos relacional. El término original utilizado para describir dichos sistemas era SGBDRE (SGBD relacional extendido). Sin embargo, en los años recientes se ha impuesto el término más restrictivo SGBn objeto-relacional (SGBDOR), que trata de indicar que el sistema incorpora algún tipo de noción de 'objeto'; también se ha empleado en ocasiones el término servidor universal o SGBD universal (SGBDU).
•
Las extensiones de SQL: 1999 y SQL:2003 incluyen: tipos de fila, tipos definidos por el usuario (UDT) y rutinas definidas por el usuario (UDR), polimorfismo, herencia, tipos de referencia e identidad de los objetos, tipos de colección (ARRAY), nuevas estructuras del lenguaje que hacen que SQL sea computacionalmente completo, disparadores y soporte para objetos de gran tamaño: objetos binarios de gran tamaño (BLOB) y objetos de caracteres de gran tamaño (CLOB), así como soporte para los mecanismos de recursión.
•
El optimizador
de consultas resulta fundamental
para el rendimiento
de un SGBDR y también debe
ampliárselo con el necesario conocim~cerca de cómo ejecutar de manera eficiente las funciones definidas del usuario, cómo aprovechar las nuevas estructuras de índice, cómo transformar las consultas de
Capítulo 28 Bases de datos objeto-relacionales
•
893
nuevas maneras y cómo navegar entre los datos utilizando las referencias. Si se abre adecuadamente un componente tan crítico y optimizado de los SGBD y se enseña a otras empresas a utilizar las técnicas de optimización, los fabricantes de sistemas SGBD podrían beneficiarse enormemente . Los SGBDR tradicionales utilizan índices basados en árboles binarios para tratar de acelerar el acceso a los datos escalares. Con la capacidad de definir tipos de datos complejos en un SGBDOR, se requieren estructuras de índice especializadas para poder acceder de manera eficiente a los datos. Algunos SGBDOR están comenzando a soportar tipos de índice adicionales, como árboles binarios genéricos, árboles R (árboles de región) para acceso rápido a datos bidimesionales y tridimensionales y también la capacidad de realizar indexaciones de acuerdo con el resultado de una función. El más alto grado de flexibilidad se consigue cuando se dispone de un mecanismo para poder utilizar cualquier estructura de índice que el usuario defina.
Cuestiones de repaso 28.1.
¿Qué funcionalidad típica proporcionaría un SGBDOR?
28.2.
¿Cuáles son las ventajas y desventajas de ampliar el modelo de datos relacional?
28.3.
¿Cuáles son las principales características del estándar SQL:2003?
28.4.
Explique cómo pueden utilizarse los tipos de referencia y las identidades de los objetos.
28.5.
Explique las similitudes y diferencias entre los procedimientos,
28.6.
¿Qué es un disparador? Proporcione un ejemplo de disparador.
funciones y métodos.
28.7.
Explique los tipos de colección disponibles en SQL:2003.
28.8.
Explique cómo soporta SQL:2003 las consultas recursivas. Proporcione un ejemplo de consulta recursiva en SQL.
28.9.
Explique las extensiones requeridas en el procesamiento completamente los objetivos de un SGBDOR.
y optimización
de consultas para soportar
28.10. ¿Cuáles son los proble"~as de seguridad asociados con la introducción de métodos definidos por el usuario? Sugiera algunas soluciones para estos problemas.
Ejercicios 28.11. Analice los SGBDR que esté actualmente utilizando. Explique las funcionalidades orientadas a objetos que esos sistemas proporcionan. ¿Qué función adicional proporcionan estos mecanismos? 28.12. Considere el esquema relacional del caso de estudio de un hotel presentado en los ejercicios del Capítulo 3. Rediseñe este esquema para aprovechar las nuevas características de SQL:2003. Añada las funciones definidas por el usuario que considere apropiadas. 28.13. Cree instrucciones SQL:2003 para las consultas dadas en los Ejercicios 5.7-5.28 del Capítulo 5. 28.14. Cree un disparador de inserción que rellene una tabla de envío de correspondencia en la que se guarden los nombres y direcciones de todos los huéspedes que hayan permanecido en el hotel durante los días anteriores y posteriores al día de Año Nuevo en los últimos dos años. 28.15. Repita el Ejercicio 28.7 para el caso de estudio de ingeniería presentado en los ejercicios del Capítulo 22.
28.16. Cree un esquema objeto-relacional para el caso de estudio de DreamHome documentado en el Apéndice A. Añada las funciones definidas por el usuario que considere apropiadas. Implemente las consultas enumeradas en el Apéndice A utilizando SQL:2003. " 28.17. Cree un esquema objeto-relacional para el caso de estudio Un iversity Accommodation
Office documen-
tado en el Apéndi~BJ.. Añada las funciones definidas por el usuario que considere apropiadas. 28.18. Cree un esquema objeto-relacional para el caso de estudio EasyDrive School o/ Motoring documentado en el Apéndice B.2. Añada las funciones definidas por el usuario que considere apropiadas.
894
Sistemas de bases de datos
28.19. Cree un esquema objeto-relacional para el caso de estudio Wellmeadows documentado en el Apéndice B.3. Añada las funciones definidas por el usuario que considere apropiadas. 28.20. El Director Gerente de DreamHome nos pide que investiguemos y preparemos un informe sobre la aplicabilidad de un SGBD objeto-relacional para la organización. El informe debe comparar la tecnología del SGBDR con la del SGBDOR y debe contemplar las ventajas y desventajas de implementar un SGBDOR dentro de la organización, así como los problemas potenciales que se prevean. El informe debe también considerar la aplicabilidad de un SGBD orientado a objetos y hay que incluir una comparación de los dos tipos de sistemas para el caso de DreamHome. Finalmente, el informe debe proporcionar un conjunto de conclusiones convenientemente justificadas sobre la aplicabilidad de la tecnología de los SGBDOR al caso de DreamHome.
arte
Inteligencia empresarial Capítulo 31 Conceptos de almacenes de datos Capítulo 32 Diseño de almacenes de datos Capítulo 33 OLAP Capítulo 34 Minería de datos
Conceptos de almacenes de datos
Objetivos del capítulo: En este capítulo aprenderá: •
Cómo han evolucionado los almacenes de datos.
•
Los principales conceptos y las principales ventajas de los almacenes de datos.
•
Cuál es la diferencia entre los sistemas de procesamiento de transacciones en línea (OLTP) y los almacenes de datos.
•
Los problemas asociados con los almacenes de datos.
•
La arquitectura y los componentes principales de un almacén de datos.
•
Los principales flujos de datos o procesos en un almacén de datos.
•
Las herramientas y tecnologías principales asociadas con los almacenes de datos.
•
Los problemas relativos.a la integración de un almacén de datos y la importancia de la gestión de los metadatos.
•
El concepto de un mercado de datos y las principales razones para implementar este tipo de sistemas.
•
Los problemas principales asociados con el desarrollo y gestión de los mercados de datos.
•
La funcionalidad de almacenes de datos ofrecida por Oracle.
Ya hemos recalcado en anteriores capítulos que los sistemas de gestión de bases de datos se utilizan en todo tipo de sectores: siendo los sistemas de gestión de bases de datos relacionales el tipo de sistema dominante. Estos sistemas han sido diseñados para gestionar una alta tasa de transacciones, realizando cada transacción normalmente pequeños cambios en los datos operacionales de la organización, es decir, en los datos que la organización requiere para gestionar sus operaciones cotidianas. Este tipo de sistemas se denominan sistemas de procesamiento de transacciones en línea (OLTP, Online Transaction Processing). El tamaño de las bases de datos OLTP puede ir desde bases de datos de pequeño tamaño, tan sólo unos pocos megabytes (MB), a bases de datos de tamaño medio con varios gigabytes (GB), y bases de datos de gran tamaño que requieren terabytes (TB) o incluso petabytes (PB) de capacidad de almacenamiento. Las personas encargadas de la toma de decisiones dentro de una organización requieren acceder a todos los datos de la organización, independientemente de dónde estén ubicados. Para poder realizar un análisis exhaustivo de la organización, de su negocio, de sus requisitos y de las tendencias subyacentes, se debe poder acceder no sólo a los valores actualmente almacenados en la base de datos, sino también a los valores históricos. Para facilitar este tipo de análisis, se creó el concepto de almacén de datos para contener datos extraídos de diversas fuentes, mantenidos por diferentes unidades operativas, junto con las transformaciones históricas y los correspondientes resúmenes. Los almacenes de datos basados en tecnología de base de datos ampliada proporcionan los mecanismos para gestionar todo este cúmulo de información. Sin embargo, las personas encargadas de la toma de decisiones también necesitan disponer de herramientas potentes de análisis.
1038
Sistemas de bases de datos
A lo largo de los últimos años han surgido dos tipos de herramientas de análisis: las herramientas de procesamiento analítico en línea (OLAP, Online Analytical Processing) y las herramientas de minería de datos. Puesto que el tema de los almacenes de datos es enormemente complejo, hemos dedicado cuatro capítulos a diferentes aspectos de este tema. En este capítulo, describiremos los conceptos básicos asociados con los almacenes de datos. En el Capítulo 32 se describe cómo diseñar y construir un almacén de datos y en los Capítulos 33 y 34 hablaremos de las herramientas más importantes para el acceso a los almacenes de datos por parte de los usuarios finales.
Estructura del capítulo En la Sección 31.1 se esboza el concepto de almacén de datos y se analiza el modo en el que este concepto ha evolucionado, describiéndose también los potenciales beneficios y los problemas asociados con esta técnica. En la Sección 31.2 se describe la arquitectura y los principales componentes de un almacén de datos. En las Secciones 31.3 y 31.4 se identifican y analizan los procesos o flujos de datos más importantes dentro de un almacén de datos, así como las tecnologías y herramientas asociadas con un almacén de datos, respectivamente. En la Sección 31.5 se introducen los mercados de datos y los problemas asociados con el desarrollo y la gestión de este tipo de sistemas. Finalmente, en la Sección 31.6 se presenta una panorámica de la solución que OracIe proporciona para el soporte de los almacenes de datos. Los ejemplos de este capítulo están tomados del caso de estudio de DreamHome que se describe en la Sección lOA y en Apéndice A.
31.1 Introducción a los almacenes de datos En esta sección vamos a hablar del origen y la evolución del concepto de almacenes de datos. Después veremos las principales ventajas asociadas con los almacenes de datos e identificaremos las características principales de los sistemas de almacenes de datos, comparándolos con los sistemas OLTP (Online Transaction Processing). Concluiremos esta sección examinando los problemas asociados al desarrollo y la gestión de un almacén de datos.
31.1.1
Evolución de los almacenes de datos
Desde la década de 1970, las organizaciones han dirigido principalmente sus inversiones a adquirir nuevos sistemas informático s que automatizaran los procesos de negocio. De esta forma, las organizaciones ganaban ventajas competitivas al utilizar sistemas que ofrecían servicios más eficientes y baratos a los clientes. Durante este periodo, las organizaciones han ido acumulando una creciente cantidad de datos en sus bases de datos operativas, sin embargo, en tiempos recientes, cuando tales sistemas ya resultan bastante habituales, las organizaciones se están centrando en nuevas maneras de utilizar esos datos operacionales para soportar los procesos de toma de decisiones, como método para volver a obtener una ventaja competitiva. Los sistemas operacionales no fueron diseñados para soportar dichas actividades de negocio por lo que utilizar estos sistemas para la toma de decisiones puede no resultar sencillo. El hecho es que una organización típica puede tener numerosos sistemas operacionales con definiciones solapadas y a veces contradictorias, como por ejemplo discrepancias en los tipos de datos. El desafío para una organización consiste en transformar sus archivos de datos en una fuente de conocimiento, de forma que se pueda presentar al usuario una vista integrada/consolidada de los datos de la organización. El concepto de almacén de datos intenta proporcionar una solución que satisfaga la necesidad de disponer de un sistema capaz de soportar el proceso de toma de decisiones, recibiendo datos de múltiples fuentes de datos operacionales.
31.1.2
Conceptos de almacenes de datos
El concepto original de almacén de datos fue desarrollado por IBM, denominándolo 'almacén de información' y fue presentado como una solución para acceder a los datos almacenados en sistemas no relacionales. Los almacenes de información fueron propuestos para permitir a las organizaciones utilizar sus archivos de datos
Capítulo 31 Conceptos de almacenes de datos
1039
con el fin de obtener una ventaja comercial. Sin embargo, debido a la enorme complejidad y a los problemas de rendimiento asociados con la implementación de dichas soluciones, los primeros intentos de crear un almacén de información fueron en su mayor parte rechazados. Desde entonces, el concepto de almacenes de datos ha surgido en diversas ocasiones pero sólo recientemente han comenzado a verse los almacenes de datos como una solución valiosa y viable. El más reciente y más exitoso defensor de los almacenes de datos es Bill Inmon, que ganó el título de 'padre de los almacenes de datos' gracias a su activa promoción de dicho conQepto. Almacén de datos
Una colección de datos clasificada por temas, integrada, variable en el tiempo y no volátil que se utiliza como ayuda al proceso de toma de decisiones por parte de quienes dirigen una organización.
En esta definición de Inmon (1993), los datos: •
Están clasificados por temas, ya que el almacén de datos está organizado de acuerdo con los temas que más importancia tienen para la organización (como por ejemplo clientes, productos y ventas) en lugar de organizarse por áreas de aplicación (como por ejemplo facturación, control de almacén y pedidos). Esto se refleja en la necesidad de almacenar datos de ayuda a la toma de decisiones, en lugar de datos orientados a las aplicaciones.
•
Están integrados debido a la mezcla de datos procedentes de diferentes sistemas de aplicación utilizados dentro de la organización. Los datos de origen son a menudo incoherentes, utilizando, por ejemplo, diferentes formatos. El almacén integrado de datos debe volver a dotarse de coherencia, para presentar una vista unificada de los datos a los usuarios.
•
Son variables en el tiempo porque los datos del almacén de datos sólo son precisos y válidos en algún instante temporal o a lo largo de un cierto intervalo de tiempo. La variación con respecto al tiempo del almacén de datos también se refleja en el gran intervalo de tiempo durante el que se almacenan los datos, en la asociación implícita o explícita de la variable temporal con todos los datos y en el hecho de que los datos repres~ntan una serie de instantáneas.
•
Son no volátiles, ya que los datos no se actualizan en tiempo real sino que se refrescan en forma periódica a partir de los sistemas operacionales. Los nuevos datos se añaden siempre para aumentar la base de datos, en lugar de para sustituir la información ya existente. La base de datos absorbe continuamente estos nuevos datos, integrándolos incrementalmente con los datos anteriores.
Hay numerosas definiciones del concepto de almacén de datos, las primeras de las cuales se centraban en las características de los datos, obtenidos en el almacén. Otras definiciones alternativas amplían el alcance del concepto de almacén de datos, para incluir el procesamiento asociado con el acceso a los datos contenidos en las fuentes originales y el suministro de datos de los responsables de la toma de decisiones (Anahory y Murray, 1997). Sea cual sea la definición, el objetivo final de los almacenes de datos es integrar todos los datos corporativos en un único repositorio en el cual los usuarios puedan ejecutar consultas con facilidad, generar informes y realizar análisis. En resumen, un almacén de datos es una tecnología de gestión y de análisis de los datos. En los últimos años, ha surgido también otro nuevo término asociado con los almacenes de datos, que son los denominados 'almacenes web de datos'. Almacén web de datos
Un almacén de datos distribuido que se implementa utilizando la Web, sin que exista un repositorio central de los datos.
La Web es una inmensa fuente de datos de comportamiento, ya que las personas interactúan con sitios web remotos desde sus exploradores web. Los datos generados por este comportamiento se denominan flujos de clics. Utilizar un almacén de datos en la Web para analizar los datos relativos a los flujos de clics conduce al concepto de almacén web de datos. Como un análisis del desarrollo de esta nueva variante de los almacenes de datos está fuera del análisis de este libro, recomendamos al lector interesado que consulte la obra de Kimball et al. (2000).
1040
Sistemas de bases de datos
31.1.3 Ventajas de los almacenes de datos Una adecuada implementación nización, incluyendo:
de un almacén de datos puede proporcionar numerosos beneficios a una orga-
•
Un alto retorno de inversión. Una organización debe invertir una cantidad de recursos para garantizar la adecuada implementación de un almacén de datos, y dicho coste puede variar enormemente, desde 50.000 a más de 10 millones de euros, debido a la diversidad de soluciones técnicas disponibles. Sin embargo, un estudio realizado por lntemational Data Corporation (IDC) en 1996 informaba de que los retornos de inversión (ROl, retums on investment) promedio a lo largo de tres años en sistemas de almacenes de datos alcanzaban el401 %, consiguiendo un 90% de las empresas un ROl de un 40%, la mitad de las empresas un ROl del 160% y la cuarta parte de ellas un ROl del 600% (IDC, 1996).
•
Ventajas competitivas. Los altos retornos de inversión para aquellas empresas que han conseguido implementar con éxito un almacén de datos constituyen una prueba de la enorme ventaja competitiva que puede derivarse de esta tecnología. Dicha ventaja competitiva se obtiene permitiendo que las personas responsables de la toma de decisiones tengan acceso a unos datos que pueden revelar informaciones previamente no disponibles, desconocidas u ocultas, como por ejemplo informaciones relativas a los clientes, a la demanda y a las tendencias.
•
Mayor productividad de los responsables de la toma de decisiones. Los almacenes de datos mejoran la productividad de los responsables de la toma de decisiones, al crear una base de datos integrada de informaciones coherentes, clasificadas por temas e históricas. El almacén de datos integra la información procedente de múltiples sistemas incompatibles en una forma que proporciona una única vista coherente de la organización. Transformando los datos en información significativa, un almacén de datos permite que los responsables de la toma de decisiones realicen análisis más relevantes, precisos y coherentes.
31. 1.4 Comparación de los sistemas OLTP Y los almacenes de d... atos Un SGBD construido para aplicaciones OLTP (Online Transaction Processing) se considera generalmente poco adecuado para los almacenes de datos, ya que ambos tipos de sistemas están diseñados con un conjunto de requisitos diferente. Por ejemplo, los sistemas OLTP están diseñados para maximizar la capacidad de procesamiento de transacciones, mientras que los almacenes de datos están diseñados para soportar el procesamiento de consultas (ad hoc). La Tabla 31.1 proporciona una comparación de las principales características de los sistemas OLTP y de los almacenes de datos (Singh, 1997). Una organización tendrá normalmente diferentes sistemas OLTP para procesos de negocio tales como el control de almacén, facturación o puntos de venta. Estos sistemas generan datos operacionales detallados, actuales y sujetos a cambios. Los sistemas OLTP están optimizados para un alto número de transacciones que son predecibles, repetitivas y que ejecutan actualizaciones intensivas en la base de datos. Los datos OLTP están organizados de acuerdo con los requisitos de las transacciones asociadas con las aplicaciones de negocio y soportan los procesos de toma de decisiones cotidianas por parte de un gran número de usuarios concurrentes de tipo operacional. Por contraste, una organización tendrá normalmente un único almacén de datos, que almacena datos históricos, detallados y resumidos a distintos niveles; además, esos datos raramente están sujetos a cambios (dejando de lado la adición de nuevos datos). El almacén de datos está diseñado para soportar un número relativamente bajo de transacciones que son impredecibles por su propia naturaleza, y requiere poder responder a consultas ad hoc, no estructuradas y heurísticas. Los datos del almacén se organizan de acuerdo con los requisitos de las consultas potenciales y sirven de ayuda para la toma de decisiones estratégicas a largo plazo por parte de un número relativamente bajo de usuarios de carácter gerencial. Aunque los sistemas OLTP y los almacenes de datos tienen diferentes características y se construyen con diferentes propósitos, estos sistemas también están estrechamente relacionados, en el sentido de que los sis-
Capítulo 31 Conceptos de almacenes de datos Tabla 31.1.
Comparación
1041
de los sistemas OLTP Y de los almacenes de datos.
Sistemas OLTP
Almacenes
de datos
Almacena datos actuales
Almacena datos históricos
Almacena datos detallados
Almacena datos resumidos en poca o gran medida
Los datos son dinámicos
Los datos son principalmente estáticos
Procesamiento repetitivo
Procesamiento ad hoc, no estructurado y heurístico
Alta tasa de transacciones
Tasa media o baja de transacciones
Patrón de uso predecible
Patrón de uso impredecible
Dirigido por transacciones
Dirigido por análisis
Orientado a la aplicación
Orientado a los temas
Soporta las decisiones cotidianas
Soporta las decisiones estratégicas
Sirve a un gran número de usuarios administrativos/ operacionales
Sirve a un número relativamente bajo de usuarios de tipo gerencial
temas OLTP proporcionan los datos de origen para el almacén de datos. Un problema fundamental de esta relación es que los datos almacenados en los sistemas OLTP pueden ser incoherentes, estar fragmentados y estar sujetos a cambios, conteniendo datos duplicados o faltando en ocasiones otros datos. Por ello, los datos operacionales deben ser 'limpiados' antes de poderIos usar en el almacén de datos. Hablaremos de las tareas asociadas con este proceso en la Sección 31.3.1. Los sistemas OLTP no se construyen para responder de forma rápida consultas ad hoc. Asimismo, tampoco suelen usarse para almacenftr datos históricos, lo cual es una absoluta necesidad si lo que queremos es analizar tendencias. Básicamente, los sistemas OLTP ofrecen grandes cantidades de datos en bruto, que no pueden analizarse fácilmente.. El almacén de datos permite responder consultas más complejas que una simple agregación como por ejemplo' ¿Cuál es el precio medio de alquiler de un inmueble en las principales ciudades del Reino Unido?'. Los tipos de consultas que un almacén de datos debe responder van desde consultas relativamente simples a otras extremadamente complejas, y esas consultas dependen de los tipos de herramientas de acceso que los usuarios finales utilicen (véase la Sección 31.2.10). Algunos ejemplos de consultas que el almacén de datos de DreamHome debería poder responder san: •
¿Cuáles fueron los ingresos totales para Escocia en el tercer trimestre de 2004?
•
¿Cuál fue el ingreso total por ventas de inmuebles para cada tipo de inmueble en Gran Bretaña en 2003?
•
¿Cuáles fueron las tres áreas más populares de cada ciudad para el alquiler de inmuebles en 2004 y cómo se comparan estos resultados con los de los dos años anteriores?
•
¿Cuál es el ingreso mensual por venta de inmuebles en cada sucursal, comparado can el promedio de los 12 meses anteriores?
•
¿Cuál sería el efecto sobre las ventas de inmuebles en las diferentes regiones de Gran Bretaña si los gastos de carácter legal se incrementaran un 3,5% y los impuestos se redujeran un 1,5% para los inmuebles de más de 100.000 euros?
•
¿Qué tipos de inmuebles tienen un precio de venta superior a la media en las ciudades principales de Gran Bretaña y qué correlación existe can los datos demográficos?
•
¿Cuál es la relación entre los ingresos anuales totales generados por cada sucursal y el número total de empleados asignados a cada sucursal?
1042
Sistemas de bases de datos
31.1.5
Problemas de los almacenes de datos
En la Tabla 31.2 se enumeran los problemas asociados con el desarrollo y gestión de un almacén de datos (Greenfield, 1996). Tabla 31.2. Subestimación
Problemas de los almacenes de datos.
de los recursos necesarios para la carga de datos
Problemas ocultos de los sistemas de origen No se capturan los datos requeridos Incremento de la demanda por parte de los usuarios finales Homogeneización
de datos
Alta demanda de recursos Propiedad de los datos Altos costes de mantenimiento Proyectos de larga duración Complejidad de la integración
Subestimación
de los recursos necesarios para la carga de datos
Muchos desarrolladores subestiman el tiempo requerido para extraer, limpiar y cargar los datos en el almacén. Este proceso puede representar una parte significativa del tiempo total de desarrollo, aunque la mejora en las herramientas de gestión y limpieza de datos debería terminar por reducir el tiempo y el esfuerzo invertidos.
Problemas ocultos de los sistemas de origen Pueden identificarse en ocasiones los problemas ocultos asociados con los sistemas de origen que suministran los datos para el almacén, posiblemente después de haber pasado inadvertidas durante años. El desarrollador debe decidir si solucionar el problema en el almacén de datos y/o modificar los sistemas de origen. Por ejemplo, a la hora de introducir los detalles de un nuevo inmueble, ciertos campos pueden permitir que se introduzcan valores nulos, lo que tiene como resultado que los empleados introduzcan datos incompletos de los inmuebles, a pesar de que esos datos están disponibles y son relevantes.
No se capturan los dato$ requeridos Los proyectos de almacenes de datos a menudo hacen que las organizaciones se percaten de que hay datos que no están siendo capturados por los sistemas de origen existentes. La organización debe decidir si hay que modificar los sistemas OLTP o si debe crearse un sistema dedicado a la captura de los datos que faltan. Por ejemplo, al considerar el caso de estudio de DreamHome, podemos querer analizar las características de ciertos sucesos, como las tareas de registro de nuevos clientes e inmuebles en cada sucursal. Sin embargo, actualmente no es posible hacer esto, ya que no se facturan los datos que dicho análisis requiere, como por ejemplo la fecha de registro de los nuevos clientes o los nuevos inmuebles.
Incremento
de la demanda por parte de los usuarios finales
Después de poner a disposición de los usuarios finales las herramientas de consulta y de generación de informes, las solicitudes de soporte por parte del personal de sistemas de información pueden incrementarse, en lugar de reducirse. Esto se debe a que los usuarios pasan a ser más conscientes de las capacidades y del valor del almacén de datos. Este problema puede aliviarse parcialmente invirtiendo en herramientas más potentes y más sencillas de utilizar, o proporcionando una mejor formación a los usuarios. Una razón adicional para que se incrementen las demandas dirigidas al personal de sistemas de información es que, una vez que un alma-
Capítulo 31 Conceptos de almacenes de datos
1043
cén de datos está en línea, el número de usuarios y de consultas tiende a incrementarse, así como también se incrementan las solicitudes de respuesta a consultas cada vez más complejas.
Homogeneización
de datos
Los almacenes de datos a gran escala pueden convertirse en un ejercicio de homogeneización de los datos que haga que disminuya el valor de éstos. Por ejemplo, al generar una vista consolidada e integrada de los datos de la organización, el diseñador del almacén de datos puede verse tentado a enfatizar las similitudes entre los datos usados por las diferentes áreas de aplicación, como por ejemplo las de ventajas de inmuebles y de alquiler de inmuebles, en lugar de prestar la suficiente atención a las diferencias.
Alta demanda de recursos El almacén de datos puede utilizar una gran cantidad de espacio en disco. Muchas bases de datos relacionales utilizadas como ayuda para la toma de decisiones se diseñan con esquemas de tipo de estrella, copo de nieve y copo de estrella (véase el Capítulo 32). Estas técnicas dan como resultado la creación de tablas de hechos de muy gran tamaño. Si los datos factuales tienen muchas dimensiones, la combinación de tablas agregadas e índices a las tablas de hechos puede ocupar más espacio que los propios datos en bruto.
Propiedad de los datos Los almacenes de datos pueden cambiar la actitud de los usuarios finales en lo que respecta a la propiedad de los datos. Datos confidenciales que antes sólo eran vistos y utilizados por un área de negocio o un departamento concretos, como por ejemplo ventas o marketing, pueden ser ahora accesibles por parte de otras personas en la organización.
Altos costes de mantenimiento Los almacenes de datos son sistemas que requieren una labor intensiva de mantenimiento. Cualquier reorganización de los procesos de ne.a;ocio y de los sistemas de origen puede afectar al almacén de datos. Para que éste continúe siendo un recurso valioso, el almacén de datos debe continuar siendo coherente con las soluciones adoptadas por la organización a la que da soporte.
Proyectos de larga duración Un almacén de datos representa un recurso de datos centralizado para la organización. Sin embargo, la construcción del almacén de datos puede requerir hasta tres años, lo cual es la razón de que algunas organizaciones hayan optado por construir mercados de datos (véase la Sección 31.5). Los mercados de datos soportan únicamente los requi"sitos de un área funcional o departamento concretos y pueden, por tanto, construirse más rápidamente.
Complejidad
de la integración
El área más importante para la gestión de un almacén de datos es la relativa a las capacidades de integración. Esto quiere decir que una organización debe invertir una cantidad significativa de tiempo en determinar hasta qué punto pueden integrarse las diferentes herramientas de almacén de datos disponibles dentro de la solución global que se pretende poner en marcha. Esta tarea puede resultar muy dificil, ya que hay diversas herramientas para cada operación del almacén de datos, todas las cuales deben integrarse adecuadamente para que el almacén suponga un beneficio para la organización.
31.2 Arquitectura de un almacén de datos En esta sección vamos a presentar una panorámica de la arquitectura y de los componentes principales de un almacén de datos (Anahory y Murray, 1997). Los procesos, herramientas y tecnologías asociados con los almacenes de datos se describen con más detalle en las siguientes secciones del capítulo. La arquitectura típica de un almacén de datos se muestra en la Figura 31.1.
1044
Sistemas de bases de datos
Gestor del almacén de datos
•
Herramientas de informes, consulta, desarrollo y aplicaciones y EIS
Fuente de datos operacionales 1 Datos altamente resumidos
Metadatos
Datos poco resumidos
Fuente de datos operacionales 2
Herramientas OLAP SGBD
Gestor del almacén de datos Herramientas de minería de datos Herramientas de acceso para usuarios finales
Repositorio de datos operacionales (ODS)
Datos de archivo/copia de seguridad
Figura 31.1.
31.2.1
Arquitectura
típica de un almacén de datos.
Datos operacionales
Las fuentes de los datos para el almacén de datos son: •
Datos operacionales procedentes de los sistemas mainframe utilizados en las bases de datos jerárquicas y en red de primera generación. Se calcula que la mayoría de los datos operacionales de las corporaciones se almacenan en este tipo de sistemas.
•
Datos departamentales alma<;enados en sistemas de archivo propietarios, como YSAM, RMS y sistemas SGBD relacionales como Informix y Oracle.
• •
Datos privados conservados en estaciones de trabajo y servidores privados. Sistemas externos como Internet, bases de datos comercialmente disponibles o bases de datos asociadas con los proveedores o clientes de una organización.
31.2.2
Repositorio de datos operacionales
Un repositorio de datos operacionales (ODS, Operational Data Store) es un repositorio de datos operacionales actuales e integrados que se utiliza para el análisis. A menudo está estructurado y se alimenta con datos de la misma forma que al almacén de datos, pero en la práctica puede actuar simplemente como un área de escala para los datos que hay que introducir en el almacén. El ODS se suele construir a menudo cuando los sistemas operacional es heredados dejan de ser capaces de satisfacer los requisitos de generación de informes. El ODS proporciona a los usuarios la facilidad de uso de una base de datos relacional, sin llegar a ofrecerles las funciones de ayuda a la toma de decisiones que un almacén de datos sí que proporciona.
Capítulo 31 Conceptos de almacenes de datos
1045
La construcción de un ODS puede ser un paso muy útil hacia la implantación de un almacén de datos, porque un ODS puede suministrar datos que ya han sido extraídos de los sistemas de origen y subsiguientemente limpiados. Esto significa que se simplifica la tarea restante de integración y reestructuración de los datos para el almacén (véase la Sección 32.3).
31.2.3 Gestor de carga El gestor de carga (también llamado componente de interfaz) realiza todas las operaciones asociadas con la extracción y carga de los datos en el almacén. Los datos pueden extraerse directamente de los orígenes de datos o, más comúnmente, del repositorio de datos operacionales. Las operaciones realizadas por el gestor de carga pueden incluir transformaciones simples de 10E; datos para prepararlos para su introducción en el almacén. El tamaño y la complejidad de este componente variará de unos almacenes de datos a otros y puede construirse utilizando una combinación de herramientas comerciales de carga de datos y de programas personalizados.
31.2.4
Gestor del almacén de datos
El gestor del almacén de datos realiza todas las operaciones asociadas con el gestor de los datos del almacén. Este componente se construye utilizando herramientas comerciales de gestión de datos y programas personalizados. Las operaciones realizadas por el gestor del almacén de datos incluyen: •
análisis de los datos para garantizar la coherencia;
•
transformación y combinación de los datos de origen, extrayéndolos temporal y almacenándolos en las tablas del almacén de datos;
•
creación de índices y vistas sobre las tablas base;
•
generación de desnormalizaciones
•
generación de agregaciones (en caso necesario);
•
copia de seguridad y archivado de los datos.
del espacio de almacenamiento
(en caso necesario);
En algunos casos, el gestor,Jiel almacén de datos genera también perfiles de consulta para determinar qué índices y agregaciones resultan apropiados. Puede generarse un perfil de consulta para cada usuario, grupo de usuarios o para todo el almacén de datos, y dichos perfiles se basan en información que describe las características de las consultas, como la frecuepcia, las tablas de destino y el tamaño de los conjuntos de resultados.
31.2.5
Gestor de consultas
El gestor de consultas (también denominado componente de servicio) realiza todas las operaciones asociadas con la gestión de las consultas de los usuarios. Este componente se construye típicamente utilizando herramientas comerciales de acceso a datos por parte de los usuarios finales, herramientas de monitorización del almacén de datos, utilidades de base de datos y programas personalizados. La complejidad del gestor de consultas está determinada por la funcionalidad proporcionadas por la base de datos y por las herramientas de acceso por parte de los usuarios finales. Las operaciones realizadas por este componente incluyen dirigir las consultas a las tablas apropiadas y planificar la ejecución de las consultas. En algunos casos, el gestor de consultas también genera perfiles de consulta para permitir al gestor del almacén de datos determinar qué índices y agregaciones resultan apropiados.
31.2.6
Datos detallados
Este área del almacén de datos almacena todos los datos detallados contenidos en el esquema de la base de datos. En la mayoría de los casos, los datos detallados no se almacenan en línea, sino que se puede acceder a ellos realizando agregaciones con un menor nivel de detalle. Sin embargo, de forma periódica se añaden nuevos datos detallados al almacén de datos para complementar los datos agregados.
1046
Sistemas de bases de datos
31.2.7
Datos poco resumidos y muy resumidos
Este área del almacén de datos guarda todos los datos poco o muy resumidos (agregados) que el gestor del almacén de datos haya establecido como resúmenes predefinidos. Este área del almacén de datos es transitoria, ya que estará sujeta a cambios de modo continuo con el fin de responder a las variaciones en los perfiles de las consultas. El propósito de la información de resumen consiste en acelerar la complejidad de las consultas. Aunque los costes operacionales se incrementan debido a la necesidad de resumir inicialmente los datos, estos costes se compensan al eliminarse la necesidad de realizar operaciones de resumen de manera continua (como por ejemplo ordenaciones o agrupaciones) a la hora de responde a las consultas de los usuarios. Los datos de resumen se actualizan de modo continuo a medida que se cargan nuevos datos en el almacén.
31.2.8
Datos de archivo/copia de seguridad
Este área del almacén de datos guarda los datos detallados y resumidos con el propósito de mantener un archivo y disponer de copias de seguridad. Aunque los datos de resumen se generan a partir de los datos detallados, puede ser necesario realizar una copia de seguridad de los datos de resumen en línea en todas aquellas ocasiones en que éstos datos se mantengan más allá del periodo de retención de los datos detallados. Los datos se transfieren a soportes de almacenamiento permanente, como por ejemplo disco óptico o cinta magnética.
31.2.9
Metadatos
Este área del almacén de datos guarda todas las definiciones de metadatos (datos acerca de los datos) utilizadas por todos los procesos del almacén. Los metadatos se utilizan para diversos propósitos, incluyendo: •
los procesos de extracción y de carga: los metadatos se emplean para mapear las fuentes de datos sobre una vista común de los datos utilizada dentro del almacén;
•
el proceso de gestión del almacén de datos: los metadatos se utilizan para automatizar la producción de tablas de resumen;
•
como parte del proceso de gestión de oonsultas: los metadatos se usan para dirigir una consulta a la fuente de datos más apropiada.
La estructura de los metadatos difiere entre unos procesos y otros, porque el propósito es distinto en cada caso. Esto significa que en el almacén de datos se conservan múltiples copias de los metadatos que describen un mismo elemento de datos. Además, la mayoría de las herramientas comerciales para gestión de copias y para el acceso a los datos por parte de los usuarios finales utilizan sus propias versiones de metadatos. Específicamente, las herramientas de gestión de copias utilizan los metadatos para comprender las reglas de mapeo que hay que quitar con el fin de convertir los datos de origen a un formato común. Las herramientas de acceso de usuario final utilizan los metadatos para comprender cómo construir una consulta. La gestión de los metadatos dentro del almacén de datos es una tarea muy compleja que no hay que subestimar. Los problemas asociados con la gestión de los metadatos dentro de un almacén de datos se analizan en la Sección 31.4.3.
31.2.10
Herramientas de acceso para usuarios finales
El propósito principal de los almacenes de datos es proporcionar información a los usuarios para la toma de decisiones estratégicas. Estos usuarios interaccionan con el almacén de datos utilizando herramientas de acceso para el usuario final. El almacén de datos debe soportar de manera eficiente las consultas ad hoc y el análisis de los datos. Se consigue un adecuado rendimiento analizando por adelantado los requisitos de realización de combinaciones, resúmenes e informes periódicos por parte de los usuarios finales. Aunque las definiciones de las distintas herramientas de acceso para usuarios finales pueden solaparse, para facilitar su análisis vamos a clasificar estas herramientas en cinco grupos principales (Berson y Smith, 1997): •
herramientas de consulta y generación de informes;
Capítulo 31 Conceptos de almacenes de datos •
herramientas de desarrollo de aplicaciones;
•
sistemas de información ejecutiva (EIS, Executive Information System)
• •
herramientas de procesamiento analítico en línea (OLAP, Online Analytical Processing) herramientas de minería de datos.
Herramientas
1047
de consulta y generación de informes
Las herramientas de generación de informes incluyen herramientas de generación de informes de producción y escritores de informes. Las herramientas de generación de informes de producción se utilizan para generar informes periódicos de carácter operacional o para soportar altos volúmenes de lotes de tareas, como por ejemplo pedidos/facturas de clientes y cheques de pago de nóminas. Las herramientas de escritura de informes, por otro lado, son herramientas de escritorio de bajo coste diseñadas para los usuarios finales. Las herramientas de consulta para los almacenes de datos relacionales están diseñadas para aceptar SLQ o generar instrucciones SQL con el fin de consultar los datos que se conservan en el almacén. Estas herramientas evitan a los usuarios finales el contacto con las complejidades de SQL y de las estructuras de la base de datos, incluyendo un metanivel entre los usuarios y la base de datos. Este metanivel es el software que proporciona las vistas orientadas a temas de la base de datos y que soporta la creación de código SQL mediante procedimientos de tipo 'apuntar y hacer clic'. Un ejemplo de herramientas de consultas sería QBE (QueryBy-Example). En el Capítulo 7 ya hemos hablado de la funcionalidad QBE del SGBD Microsoft Office Access. Las herramientas de consulta son muy populares entre los usuarios de aplicaciones empresariales tales como las de análisis demográfico y las de gestión de listas de clientes para distribución de correo. Sin embargo, a medida que las cuestiones se hacen más complejas, estas herramientas pasan rápidamente a ser poco eficientes.
Herramientas
de desarrollo de aplicaciones
Los requisitos de los usuarios finales pueden ser tales que las capacidades predefinidas de las herramientas de consulta y de generación de informes resulten inadecuadas, bien porque no puedan llevarse a cabo los análisis requeridos o bien porque laínteracción del usuario requiera un nivel de conocimientos demasiado alto por parte del usuario. En esta situación, el acceso por parte de los usuarios puede requerir el desarrollo de aplicaciones personalizadas utilizando herramientas gráficas de acceso a los datos diseñadas principalmente para entornos cliente-servidor. Algunas de estas herramientas de desarrollo de aplicaciones se integran como herramientas OLAP populares, y permiten acceder a los principales sistemas de base de datos, incluyendo Oracle, Sybase e Informix.
Sistemas de información ejecutiva (EIS) Los sistemas de información ejecutiva fueron desarrollados originalmente como ayuda para la toma de decisiones estratégicas de alto nivel. Sin embargo, el objetivo de estos sistemas se amplió para incluir soporte para todos los niveles de gestión. Las herramientas EIS se asociaron originalmente con sistemas mainframe que permitían a los usuarios construir aplicaciones gráficas personalizadas de ayuda a la toma de decisiones que proporcionaron una panorámica de los datos de la organización y un acceso a fuentes de datos externas. Actualmente, la frontera entre las herramientas EIS y otras herramientas de ayuda a la toma de decisiones es todavía más difusa, ya que los desarrolladores de herramientas EIS añaden funciones de consulta adicionales y proporcionan aplicaciones personalizadas para áreas de negocio tales como ventas, marketing y finanzas.
Herramientas
de procesamiento
analítico en línea (OLAP)
Las herramientas de procesamiento analítico en línea (OLAP, Online Analytical Processing) están basadas en el concepto de bases de datos multidimensionales y permiten a los usuarios avanzados analizar los datos utilizando vistas complejas de carácter mu]tidimensional. Las aplicaciones empresariales típicas para estas herramientas incluyen la verificación de la efectividad de una campaña de marketing, la previsión de ventas de productos y la planificación de la capacidad de producción. Estas herramientas asumen que los datos están organizados según un modelo multidimensional apoyado en una base de datos multidimensional especial
1048
Sistemas de bases de datos
(MDDB, multi-dimensional database) o en una base de datos relacional diseñada para permitir la realización de consultas multidimensionales. Hablaremos de las herramientas OLAP con más detalle en el Capítulo 33.
Herramientas de minería de datos La minería de datos es el proceso de descubrir nuevas correlaciones, patrones y tendencias significativas procesando grandes cantidades de datos mediante técnicas estadísticas, matemáticas y de inteligencia artificial. La minería de datos tiene el potencial de superar las capacidades de las herramientas OLAP, ya que el principal atractivo de la minería de datos es su capacidad de construir modelos predictivos en lugar de retrospectivos. Hablaremos de la minería de datos con más detalle en el Capítulo 34.
31.3 Flujos de datos en un almacén de datos En esta sección vamos a examinar las actividades asociadas con el procesamiento (o flujo) de los datos en un almacén de datos. Los almacenes de datos se centran en la gestión de cinco flujos de datos principales: el flujo de entrada, el flujo ascendente, el flujo descendente, el flujo de salida y el metaflujo (Hackathom, 1995). En la Figura 31.2 se muestran los flujos de datos existentes en un almacén de datos. Los procesos asociados con cada flujo de datos incluyen: •
Flujo de entrada: extracción, limpieza y carga de los datos de origen.
•
Flujo ascendente: adición de valor a los datos del almacén mediante procesos de resumen, empaquetado y distribución de los datos.
•
Flujo descendente: archivado y copia de seguridad de los datos del almacén.
Gestor del almacén de datos Metaflujo etadatosl Fuente de datos operacionales 1 Datos altamente resumidos Fluío delsalida
Flujo de entrada Datos poco resumidos
Gestor del almacén de datos Herramientas de minerías de datos (véase Capitulo 34) Flujo descendente
Datos de archivo/copia de seguridad
Repositorio de datos operacionales (OD8)
Figura 31.2.
Flujos de información en un almacén de datos.
Herramientas de acceso para usuarios finales
Capítulo 31 Conceptos de almacenes de datos
•
Flujo de salida: puesta de los datos a disposición de los usuarios finales.
•
Metaflujo: gestión de los metadatos.
31.3.1
1049
Flujo de entrada
Flujo de entrada
Los procesos asociados con la extracción, limpieza y carga de los datos de los sistemas de origen en el almacén de datos.
El flujo de entrada es el proceso de tomar los datos de los sistemas de origen y cargados en el almacén de datos. Alternativamente, los datos pueden primero cargarse en el repositorio de datos operacional es (ODS, operational data store) (véase la Sección 31.2.2) antes de transferidos al almacén de datos. Como los datos de origen son generados principalmente por sistemas OLTP, es necesario reconstruir los datos antes de introducidos en el almacén. La reconstrucción de los datos implica: •
la limpieza de los datos;
•
la reestructuración de los datos para ajustados a los nuevos requisitos del almacén de datos, incluyendo por ejemplo la adición y/o eliminación de campos y la desnormalización de los datos;
•
garantizar que los datos de origen sean coherentes entre sí y con los datos que ya se encuentran en el almacén.
Para gestionar de manera adecuada el flujo de entrada, es necesario identificar una serie de mecanismos para determinar cuándo hay que comenzar a extraer los datos con el fin de llevar a cabo las necesarias transformaciones y realizar las oportunas comprobaciones de coherencia. Cuando se extraen los datos de los sistema de origen, es importante garantizar que los datos estén en un estado coherente, con el fin de generar una vista coherente y unificada de los datos corporativos. La complejidad del proceso de extracción está determinada por el grado con el que los sistemas de origen estén 'ajustados' entre sí. Una vez extraídos los datos, estos se suelen cargar en un repositorio temporal con el propósito de limpiarlos y de verificar la coherencia. Como este proceso es muy complejo, es importante automatizado en el mayor grado posible y disponer de lal~apacidad de informar de cualquier problema o fallo que se produzca. Hay disponibles diversas herramientas comerciales para soportar la gestión del flujo de entrada. Sin embargo, a menos que se trate de un proceso relativamente sencillo, dichas herramientas pueden requerir una cierta personalización.
31.3.2
Flujo ascendente
Flujo ascendente
Los procesos asociados con la adición de valor a los datos del almacén, mediante los procesos de resumen, empaquetado y distribución de los datos.
Las actividades asociadas con el flujo ascendente incluyen: •
El resumen de los datos seleccionando, proyectando, combinando y agrupando los datos relacionales .en una serie de vistas que sean más cómodas y útiles para los usuarios finales. Los resúmenes van más allá de las simples operaciones relacionales, para incorporar análisis estadísticos sofisticado s que incluyen la identificación de tendencias, la agrupación y el muestreo de los datos.
•
El empaquetado de los datos, convirtiendo los datos de detalle o de resumen a otros formatos más útiles, como por ejemplo hojas de cálculo, documentos de texto, diagramas, otras representaciones gráficas, bases de datos privadas y animaciones.
•
La distribución de los datos a los grupos de usuarios apropiados, para incrementar su disponibilidad y accesibilidad.
Al mismo tiempo que se añade valor a los datos, también hay que tener en cuenta que deben satisfacerse los requisitos de prestaciones del almacén de datos y minimizarse los costes de operación continuada. Ambos tipos de requisitos empujan el diseño en direcciones opuestas, forzando a la reestructuración del mismo con el fin de mejorar las prestaciones de las consultas o reducir los costes de operación. En otras palabras, el admi-
1050
Sistemas de bases de datos
nistrador del almacén de datos debe identificar el diseño de base de datos más apropiado para satisfacer todos los requisitos, lo que en ocasiones requiere llegar a ciertos compromisos.
31.3.3
Flujo descendente
Flujo descendente
Los procesos asociados con el archivado y la realización de copias de seguridad de los datos en el almacén.
El archivado de los datos antiguos juega un importante papel en el mantenimiento, la efectividad y las prestaciones del almacén de datos, al transferir los datos antiguos de menor valor a un archivo permanente, como la cinta magnética o los discos ópticos. Sin embargo, si se selecciona para la base de datos el esquema de particionamiento correcto, la cantidad de datos en línea no debería afectar a las prestaciones. El particionamiento es una útil opción de diseño para bases de datos de muy gran tamaño, que permite fragmentar una tabla que almacene un gran número de registros en otras tablas más pequeñas. La regla para el particionamiento de una tabla determinada puede basarse en las características de los datos, como por ejemplo su rango temporal o el área de un país. Por ejemplo, la tabla PropertySale de DreamHome podría particionarse de acuerdo con las distintas regiones del Reino Unido. El flujo descendente de los datos incluye los procesos para garantizar que pueda reconstruirse el estado actual del almacén de datos después de producirse una pérdida de datos o un fallo software/hardware. Los datos archivados deben almacenarse de tal forma que puedan restablecerse en el almacén siempre que sea necesano.
31.3.4
Flujo de salida
Flujo de salida
Los procesos asociados finales.
con la puesta de los datos a disposición
de los usuarios
El flujo de salida representa el lugar donde la organización puede extraer el máximo beneficio del almacén de datos. La adecuada gestión de este flujo puede requerir la re ingeniería de los procesos de negocio con el fin de conseguir una ventaja competitiva (Hackathorn, 1995). Las dos actividades clave implicadas en el flujo de salida son: •
El acceso, que se preocupa de satisfacer las solicitudes que los usuarios finales realizan en lo referente a los datos que necesitan. El problema principal consiste en crear un entorno que permita a los usuarios emplear de manera efectiva las herramientas de consulta para acceder al origen de datos más apropiado. La frecuencia de los accesos de los usuarios pueden variar desde la realización de consultas ad hoc, a la realización de consulta periódicas o incluso en tiempo real. Es importante garantizar que los recursos del sistema se utilicen de forma más efectiva a la hora de planificar la ejecución de las consultas de los usuarios .
•
El suministro, que se ocupa de suministrar proactivamente la información a las estaciones de trabajo de los usuarios finales y consiste en un proceso de tipo 'publicación y subscripción'. El almacén de datos público diversos 'objetos de negocio' que se revisan periódicamente monitorizando los patrones de uso. Los usuarios se subscriben al conjunto de objetos de negocio que mejor satisfacen sus necesidades.
Una cuestión importante a la hora de gestionar el flujo de salida es la de realizar un marketing activo del almacén de datos entre los usuarios, lo que contribuirá a sacar el máximo provecho del almacén para las operaciones de la organización. Hay toda una serie de actividades operacionales adicionales relacionadas con la gestión del flujo de salida, incluyendo dirigir las consultas a las tablas de destino apropiadas y capturar la información sobre los perfiles de consulta asociados con los grupos de usuario, con el fin de determinar qué agregaciones hay que generar. Los almacenes de datos que contienen datos de resumen proporcionan potencialmente diferentes orígenes de datos para responder a cada consulta específica, incluyendo los propios datos de detalle y diversas agregaciones que satisfacen las necesidades de datos de las consultas. Sin embargo, la velocidad de la consulta varia-
Capítulo 31 Conceptos de almacenes de datos
1051
rá considerablemente dependiendo de las características de los datos solicitados, siendo la más obvia de dichas características el propio volumen de los datos que hay que leer. Como parte de la gestión del flujo de salida, el sistema debe determinar la forma más eficiente de responder a cada consulta.
31.3.5
Metaflujo
Metaflujo
Los procesos asociados con la gestión de los metadatos.
Los flujos anteriores describen la gestión del almacén de datos en lo que respecta a la transferencia de datos hacia y desde el almacén. El metaflujo es el proceso encargado de la transferencia de metadatos (datos acerca de los otros flujos). Los metadatos son una descripción de los datos contenidos en el almacén: qué datos hay, de dónde provienen y qué se ha hecho con ellos en términos de limpieza, integración y resumen. Hablaremos de las cuestiones asociadas con la gestión de los metadatos dentro de un almacén de datos en la Sección 31.4.3. Para responder a las cambiantes necesidades de las empresas, los sistemas heredados están cambiando constantemente. Por tanto, el almacén de datos debe responder a estos cambios continuos, reflejando las modificaciones experimentadas por los sistemas heredados de origen y por los cambios sufridos por el entorno empresarial. El metaflujo (metadatos) debe actualizarse continuamente para reflejar dichos cambios.
31.4 Herramientas y tecnologías de almacén de datos En esta sección vamos a examinar las herramientas y tecnologías asociadas con la construcción y gestión de un almacén de datos, centrándonos en particular en los problemas asociados con la integración de estas herramientas. Para obtener más información sobre las tecnologías y herramientas para almacenes de datos, el lector interesado puede consultar la obra de Berson y Smith (1997).
31.4.1
Herramientas de extracción, limpieza y transformación
La selección de las herramientas correctas de extracción, limpieza y transformación constituye un paso crítico en la construcción de un almacén de datos. Cada vez hay más fabricantes centrados en satisfacer los requisitos de las implementaciones de almacenes de datos, en lugar de limitarse a proporcionar herramientas para simplemente transferir datos entre unas plataformas hardware y otras. Las tareas de capturar los datos de un sistema de origen, limpiados y transformados y luego cargar los resultados en un sistema de destino puede llevarse a cabo utilizando productos independientes o una solución integrada. Las soluciones integradas pueden clasificarse en tres categorías principales: •
generadores de código;
• •
herramientas de replicación de datos; motores de transformación dinámica.
Generadores de código Los generadores de código crean programas de transformación 3GL/4GL personalizado s basándose en las definiciones de los datos de origen y de destino. El principal problema con esta técnica es la gestión del gran número de programas requeridos para dar soporte a un almacén de datos complejo de carácter corporativo. Los fabricantes son conscientes de este problema y algunos de ellos están desarrollando componentes de gestión empleando técnicas tales como mecanismos de control de flujo de trabajo y sistemas automatizados de planificación.
Herramientas
de replicación de datos
Las herramientas de replicación de datos emplean disparadores de base de datos o utilizan el registro de actividades de la base de datos para capturar los cambios efectuados en un origen de datos y aplicar dichos cam-
1052
Sistemas de bases de datos
bios a una copia de esos datos de origen que esté ubicada en un sistema diferente (véase el Capítulo 24). La mayoría de los productos de replicación no soportan la captura de cambios realizados en bases de datos y archivos no relacionales, y a menudo no proporcionan funcionalidades para realizar transformaciones y mejoras significativas de los datos. Estas herramientas pueden utilizarse para reconstruir una base de datos después de un fallo o para crear una base de datos para un mercado de datos (véase la Sección 31.5), siempre que el número de orígenes de datos sea pequeño y el grado requerido de transformación de los datos sea relativamente bajo.
Motores de transformación
dinámica
Los motores de transformación dinámica dirigidos por reglas capturan datos de un sistema de origen a intervalos definidos por el usuario, transforman esos datos y luego envían y cargan los resultados en un entorno de destino. Hasta la fecha, la mayoría de los productos de esta categoría sólo soportan los orígenes de datos relacionales, pero están empezando a surgir productos que permiten gestionar también bases de datos y archivos de origen de carácter no relacional.
31.4.2
Sistemas SGBD para almacenes de datos
No hay demasiados problemas de integración relacionados con la base de datos del almacén de datos. Debido al a madurez de tales producto, la mayoría de las bases de datos relacionales se integran perfectamente con otros tipos de software. Sin embargo, sí que hay problemas asociados con el tamaño potencial de la base de datos del almacén de datos. El paralelismo de la base de datos pasa a cobrar una gran importancia, además de las cuestiones habituales de prestaciones, escalabilidad, disponibilidad y capacidad de gestión, todas deben tomarse en consideración a la hora de seleccionar un SGBD. Vamos a identificar primero los requisitos para un SGBD para almacenes de datos y luego hablaremos brevemente de cómo soportan las tecnologías de procesamiento en paralelo los requisitos de un almacén de datos.
Requisitos para un SGBD para almacenes de datos Los requisitos especializados que debe satisfacW" un SGBD relacional adecuado para aplicaciones de almacén de datos están publicados en un informe técnico (Red Brick Systems, 1996) y se enumeran en la Tabla 31.3. Buena velocidad
de carga
Los almacenes de datos requieren la carga incremental de nuevos datos de manera periódica, con unas ventanas temporales muy cortas. La velocidad del proceso de carga debe medirse en cientos de millones de filas o en gigabytes de datos por hora, y no debe haber un límite máximo que restrinja las necesidades de información de la organización. Tabla 31.3.
Los requisitos para un SGBDR para almacenes de datos.
Buena velocidad de carga Procesamiento
de carga
Gestión de la calidad de los datos Velocidad de las consultas Escalabilidad
en el rango de los terabytes
Escalabilidad
en cuanto a número de usuarios
Almacén de datos en red Administración
del almacén de datos
Análisis dimensional integrado Funcionalidad
avanzada de consultas
Capítulo 31 Conceptos de almacenes de datos
1053
Procesamiento de carga Deben llevarse a cabo diversos pasos para cargar datos nuevos o actualizados en el almacén de datos, incluyendo la conversión de los datos, el filtrado, el reformateo, las comprobaciones de integridad, el almacenamiento fisico, la indexación y la actualización de los metadatos. Aunque cada caso puede ser en la práctica atómico, el proceso de carga debe ejecutarse como si fuera una única unidad de trabajo integrada.
Gestión de la calidad de los datos La tendencia a utilizar una gestión de los datos basada en hechos requiere disponer de la mayor calidad de datos posible. El almacén de datos debe garantizar la coherencia local, la coherencia global y la integridad referencial a pesar del enorme tamaño de la base de datos y a pesar de que los orígenes de los datos sean 'sucios'. Aunque la carga y la preparación de los datos son pasos necesarios, no son sin embargo suficientes. La capacidad de responder a las consultas de los usuarios finales es lo que determina el éxito de una aplicación de almacén de datos. A medida que se responden más preguntas, los analistas tienden a formular cuestiones más creativas y complejas.
Velocidad de las consultas Las técnicas de gestión basadas en hechos y en análisis ad hoc no deben ser ralentizadas o inhibidas por las prestaciones del SGBDR del almacén de datos. Las consultas complejas de gran tamaño para las operaciones clave del negocio deben completarse en periodos de tiempo razonables.
Escalabilidad en el rango de los terabytes Los tamaños de los almacenes de datos están creciendo a una velocidad enorme, yendo dichos tamaños desde unos pocos gigabytes a terabytes (1012 bytes) e incluso petabytes (1015 bytes). El SGBDR no debe tener limitaciones de arquitectura en lo que respecta al tamaño de la base de datos y debe soportar la gestión modular y paralela. En caso de fallo, el SGBDR debe soportar una disponibilidad continua y proporcionar mecanismos para la recuperación. El SGBDR debe permitir utilizar dispositivos de almacenamiento masivo, como discos ópticos, y dispositivos de gestión jerárquica del almacenamiento. Por último, la velocidad de las consultas no debe depender del tamaño de la base de datos, sino sólo de la complejidad de éstas.
Escalabilidad en cuanto a número de usuarios Actualmente se considera que el acceso a los almacenes de datos está limitado a un número de usuarios relativamente bajo y de carácter gerencia!. Sin embargo, a medida que las empresas vayan descubriendo el valor de los almacenes de datos, cabe esperar que esto deje de ser así. Las previsiones son que los SGBDR para almacenes de datos deben ser capaces de soportar centenares e incluso miles de usuarios concurrentes, sin que por ello se sufra una degradación en la velocidad de procesamiento de las consultas.
Almacén de datos en red Los sistemas de almacenes de datos deben ser capaces de cooperar en una red de almacenes de datos. El almacén de datos debe incluir herramientas que coordinen la transferencia de subconjuntos de datos entre unos almacenes y otros. Los usuarios deben poder examinar múltiples almacenes de datos desde una única estación de trabajo cliente y trabajar con los datos en ellos contenidos.
Administración del almacén de datos El gran volumen de los datos y la naturaleza cíclica (desde el punto de vista temporal) de los almacenes de datos requieren una gran facilidad y flexibilidad de administración. El SGBDR debe proporcionar controles para implementar límites de utilización de los recursos, contabilidad de costes para asignar dichos costes a los usuarios y mecanismos de asignación de prioridad a las consultas para satisfacer las necesidades de diferentes actividades y clases de usuarios. El SGBDR debe también proporcionar mecanismos para optimización y control de la carga de trabajo, con el fin de poder optimizar los recursos del sistema y obtener unas prestacio-
1054
Sistemas de bases de datos
nes y una tasa de procesamiento máximas. El valor más obvio y mensurable de un almacén de datos es el acceso creativo e ilimitado a los datos por parte de los usuarios finales.
Análisis dimensional integrado Todo el mundo es consciente de la potencia que encierran las vistas multidimensionales, y el SGBDR del almacén de datos debe integrar el soporte dimensional con el fin de proporcionar las máximas prestaciones a las herramientas OLAP relacionales (véase el Capítulo 33). El SGBDR debe soportar la creación rápida y simple de los tipos de resúmenes precalculados que resultan comunes en los grandes almacenes de datos, y debe proporcionar también herramientas de mantenimiento que automaticen la creación de estos agregados precalculados. Los cálculos dinámicos de agregados deben ser coherentes con las prestaciones de procesamiento interactivos que los usuarios finales esperan.
Funcionalidad avanzada de consultas \
Los usuarios finales requieren cálculos analíticos avanzados, análisis secuenciales y comparativos y un acceso coherente a datos detallados y de resumen. Utilizar SQL mediante una herramienta de tipo cliente-servidor con un paradigma de 'apuntar y hacer clic' puede no resultar práctico en algunas ocasiones o puede ser incluso imposible debido a la complejidad de las consultas de los usuarios. El SGBDR debe proporcionar un conjunto completo y avanzado de operacionales analíticas.
Sistemas SGBD paralelos Los almacenes de datos requieren procesar enormes cantidades de datos, por lo que la tecnología de bases de datos paralelas ofrece una solución para escalar las prestaciones de la forma necesaria. El éxito de los SGBD paralelos depende de la eficiente operación de muchos tipos de recursos distintos, incluyendo los operadores, la memoria, los discos y las conexiones de red. A medida que crece la popularidad de los almacenes de datos, muchos fabricantes están construyendo sistemas SGBD de gran tamaño para ayudar a la toma de decisiones utilizando tecnologías de procesamiento paralelo. El objetivo es resolver los problemas que afectan a los sistemas de ayuda a la toma de decisiones, utilizando múltiples nodos que trabajen en paralelo sobre el mismo problema. Las principales características de 10~SGBD paralelos son la escalabilidad, la operabilidad y la disponibilidad. Un SGBD paralelo realiza muchas operaciones de base de datos simultáneamente, dividiendo las tareas individuales en partes más pequeñas que pueden distribuirse entre múltiples procesadores. Un SGBD paralelo debe ser capaz de ejecutar consultas paralelas, es decir, debe ser capaz de descomponer las consultas complejas de gran tamaño en una serie de subconsultas, ejecutar simultáneamente todas esas subconsultas y recomponer los resultados al final. La funcionalidad ofrecida por uno de estos SGBD debe también incluir la carga de datos en paralelo, la exploración de tablas en paralelo y el archivado y copia de seguridad de los datos en paralelo. Son dos los tipos principales de arquitecturas hardware paralelas que se utilizan comúnmente como plataformas de servidor de base de datos para los almacenes de datos: •
Multiprocesamiento simétrico (SMP, Symmetric Multi-Processing): un conjunto de procesadores fuertemente acoplados que comparten la memoria y el almacenamiento en disco;
•
Procesamiento masivamente paralelo (MPP, Massively Parallel Processing): un conjunto de procesadores débilmente acoplados, cada uno de los cuales tiene su propia memoria y su propio almacenamiento en disco.
En la Sección 22.1.1 hemos descrito en detalle las arquitecturas SMP y MPP para procesamiento en paralelo.
31.4.3
Metadatos de un almacén de datos
Son diversos los problemas asociados con la integración de almacenes de datos, pero en esta sección nos vamos a centrar en la integración de los metadatos, es decir, los 'datos acerca de los datos' (Darling, 1996).
Capítulo 31 Conceptos de almacenes de datos
1055
La gestión de los metadatos del almacén es una tarea extremadamente compleja y difícil. Los metadatos se utilizan para diversos propósitos y la gestión de los metadatos resulta crítica para conseguir una plena integración del almacén de datos. El principal objetivo de los metadatos es mostrar cuál es el camino que lleva hasta el origen de esos datos, de modo que los administradores del almacén de datos conozcan la historia de cualquier elemento albergado en el almacén. Sin embargo, el problema es que los metadatos cumplen varias funciones dentro del almacén de datos relacionadas con los procesos requeridos para la transformación y carga de los datos, para la gestión del almacén de datos y para la generación de consultas (véase la Sección 31.2.9). Los metadatos asociados con la transformación y carga de los datos deben describir los datos de origen, así como cualesquiera cambios que se hayan realizado en dichos datos. Por ejemplo, para cada campo de origen debe haber un identifícador unívoco y debe indicarse el nombre de campo, el tipo de datos de origen y la ubicación original, incluyendo el sistema y el nombre del objeto, junto con el tipo de datos de destino y el nombre de la tabla de destino. Si el campo se somete a algún tipo de transformación, por ejemplo cambiando un tipo de campo simple por un complejo conjunto de procedimientos y funciones, también es necesario registrar este hecho. Los metadatos asociados con la gestión de datos describen los datos tal como están almacenados en el almacén. Es necesario describir cada objeto de la base de datos, incluyendo los datos de cada tabla, índice y vista, junto con sus restricciones asociadas. Esta información se almacena en el catálogo del sistemas del SGBD; sin embargo, hay otros requisitos adicionales derivados de los propios objetivos del almacén de datos. Por ejemplo, los metadatos deben describir también todos los campos asociados con las agregaciones, incluyendo una descripción de la operación de agregación que se ha realizado. Además, hay que describir las particiones de las tablas, incluyendo información sobre la clave de partición y el rango de datos asociado con cada partición. Los metadatos descritos también son necesarios para que el gestor de consultas genere las consultas apropiadas. A su vez, el gestor de consultas genera metadatos adicionales acerca de las consultas utilizadas, los cuales pueden usarse para generar una historia de todas las consultas y un perfil de consulta para cada usuario, para cada grupo de usuarios o para todo el almacén de datos. También hay metadatos asociados con los usuarios de esas consultas, enlos que se incluyen por ejemplo información que describe qué es lo que significa el término 'precio' o 'cliente' en una base de datos concreta y si ese significado ha cambiado a lo largo del tiempo.
Sincronización
de los metadatos
El principal problema de integración consiste en sincronizar los diversos tipos de metadatos utilizados en el almacén de datos. Las diversas herramientas del almacén de datos generan y utiliza sus propios metadatos, y para conseguir una adecuada integración es necesario que estas herramientas sean capaces de compartir dichos metadatos. El desafío consiste en sincronizar los metadatos entre diferentes productos de diferentes fabricantes que utilicen diferentes archivos de metadatos. Por ejemplo, es necesario identificar el elemento de metadatos correcto con el grado adecuado de detalle en un producto y establecer la correspondencia con el elemento correcto de metadatos con el grado adecuado de detalle en otro producto, resolviendo después las posibles diferencias de codificación que existan. Esta tarea debe repetirse para todos los demás metadatos que los dos productos tengan en común. Asimismo, los cambios que se realicen a los metadatos (o incluso a los metametadatos) en un producto deben comunicarse al otro producto. La tarea de sincronizar dos productos es altamente compleja, por lo que repetir este proceso para seis o más productos que forman el almacén de datos puede requerir una enorme cantidad de recursos. Sin embargo, esa integración de los metadatos es absolutamente imprescindible. Al principio, había dos estándares principales para los metadatos y para el modelado en el campo de los almacenes de datos y del desarrollo de software basado en componentes. Estos dos estándares eran los propuestos por MDC (Meta Data Coalition) y por OMG (Object Management Group). Sin embargo, estos dos consorcios de organizaciones anunciaron conjuntamente que MDC iba a integrarse en OMo. Como resultado, MDC interrumpió sus esfuerzos de estandarización y el trabajo ha continuado en OMG para integrar los dos estándares.
1056
Sistemas de bases de datos
La integración de MDC dentro de OMO fue el resultado de un acuerdo entre los principales fabricantes de almacenes de datos y de sistemas de gestión de metadatos para converger en un único están dar que incorporara lo mejor del modelo OIM (Open Information Model) de MDC y del metamodelo CWM (Common Warehouse Metamodel) de OMo. Esta tarea de integración se ha completado ya y la especificación resultante elaborada por OMO como siguiente versión de CWM se analiza en la Sección 27.1.3. La existencia de un único estándar permitirá a los usuarios intercambiar libremente metadatos entre diferentes productos de diferentes fabricantes. La especificación CWM de OMO está construida sobre diversos estándares, incluyendo UML (Unified Modeling Language), XMI (XML Metadata Interchange) y MOF (Meta Object Facility) de OMO, así como el modelo OIM de MDC. CWM fue desarrollado por un conjunto de empresas entre las que se incluyen IBM, Oracle, Unisys, Hyperion, Oenesis, NCR, UBS y Dimension EDI.
31.4.4
Herramientas de administración y gestión
Un almacén de datos requiere una serie de herramientas para soportar la administración y gestión de un entorno tan complejo. No existen demasiadas herramientas de este estilo, especialmente herramientas que estén bien integradas con los diversos tipos de metadatos y con las operaciones cotidianas del almacén de datos. Las herramientas de administración y gestión del almacén de datos deben ser capaces de soportar las siguientes tareas: •
monitorizar la carga de datos desde múltiples fuentes;
•
comprobar la calidad y la integridad de los datos;
•
gestionar y actualizar los metadatos;
•
monitorizar el rendimiento de la base de datos para garantizar unos tiempos de respuesta cortos a las consultas y una eficiente utilización de los recursos;
•
auditar la utilización del almacén de datos para atribuir los costes a los distintos usuarios;
•
replicar, dividir y distribuir los datos;
• •
gestionar de manera eficiente el almac~amiento purgar los datos;
de los datos;
•
archivar los datos y realizar copias de seguridad;
•
implementar mecanismos de recuperación de fallos;
•
gestionar adecuadamente
la seguridad.
31.5 Mercados de datos En paralelo con la rápida adopción de los almacenes de datos, ha surgido el concepto relacionado de los denominados mercados de datos. En esta sección se describe qué son los mercados de datos, las razones para construir uno de estos sistemas y los problemas asociados con el desarrollo y utilización de los mercados de datos. Mercado de datos
Un subconjunto de un almacén de datos que soporta los requisitos de un departamento o área de negocio concretos.
Un mercado de datos almacena un subconjunto de los datos del almacén, normalmente en la forma de datos de resumen relativos a un departamento o área de negocio concretos. El mercado de datos puede funcionar de manera autónoma o estar enlazado al almacén de datos corporativos central. A medida que crece un almacén de datos, la capacidad para satisfacer las diversas necesidades de la organización puede verse afectada. La popularidad de los mercados de datos surge del hecho de que los almacenes de datos de ámbito corporativo están demostrando ser difíciles de construir y de utilizar. En la Figura 31.3 se muestra la arquitectura típica de un almacén de datos y de un mercado de datos asociado. Las principales características que diferencian a los mercados de datos de los almacenes de datos son:
Capítulo 31 Conceptos de almacenes de datos
1057
•
un mercado de datos se centra únicamente en los requisitos de los usuarios asociados con un departamento o área de negocio concretos;
•
los mercados de datos no contienen normalmente datos operacionales detallados, a diferencia de lo que sucede con los almacenes de datos;
•
como los mercados de datos contienen menos información que un almacén de datos, son m~s fáciles de comprender y de utilizar.
•
Gestor del almacén de datos
Fuente de datos operacionales 1 Datos altamente resumidos
Metadatos
Datos poco resumidos
Fuente de datos operacionales 2
SGBD
Gestor del almacén de datos Herramientas de minerias de datos (véase Capítulo 34)
(Primer nivel)
• • •
Herramientas de acceso para usuarios finales
Repositorio de datos operacionales (ODS)
Datos de archivolcopia de seguridad
o
Mercados de datos
Datos de resumen (base de datos relacional)
Herramientas de informes, consulta, desarrollo y aplicaciones y EIS
Herramientas OLAP
Datos de resumen (base de datos multidimensional)
(Segundo nivel)
Figura 31.3.
Arquitectura
Herramientas de mineria de datos (Tercer nivel)
típica de un almacén de datos y de un mercado de datos.
1058
Sistemas de bases de datos
Hay diversas técnicas para construir mercados de datos. Una de ellas es construir varios mercados de datos con el objetivo último de integrados en un almacén de datos; otra técnica consiste en construir la infraestructura para un almacén de datos corporativo al mismo tiempo que se construyen uno o más mercados de datos para satisfacer las necesidades inmediatas de los usuarios. Las arquitecturas de los mercados de datos pueden construirse como aplicaciones de base de datos en dos o en tres niveles. El almacén de datos es el primer nivel opcional (si el almacén de datos proporciona la información para el mercado de datos), el mercado de datos es el segundo nivel y la estación de trabajo del usuario final es el tercer nivel, como se muestra en la Figura 31.3. Los datos están distribuidos entre los distintos niveles.
31.5.1
Razones para crear un mercado de datos
Hay muchas razones para crear un mercado de datos, como por ejemplo: •
Proporcionar a los usuarios acceso a los datos que necesiten analizar de manera más frecuente.
•
Proporcionar los datos en una forma que se adapte a la vista colectiva que de los datos tiene un grupo de usuarios perteneciente a un departamento o área de negocio concretos.
•
Mejorar el tiempo de respuesta a las consultas del usuario final, gracias a la reducción en el volumen de los datos a los que hay que acceder.
•
Proporcionar datos apropiadamente estructurado s, según dicten los requisitos de las herramientas de acceso para usuarios finales, como las herramientas OLAP (Online Analytical Processing) y las de minería de datos, las cuales pueden requerir sus propias estructuras de base de datos internas. En la práctica, estas herramientas crean a menudo su propio mercado de datos diseñado para soportar su funcionalidad específica.
•
Los mercados de datos utilizan normalmente menos datos, por lo que las tareas de limpieza, carga, transformación e integración de los datos son mucho más sencillas, lo que tiene como resultado que la implementación y puesta en marcha de un mercado de datos sea más simple que el establecimiento de un almacén de datos corporativo. ~ El coste de implementación de los mercados de datos es normalmente inferior al que se requiere para establecer un almacén de datos corporativo.
• •
Los usuarios potenciales de un mercado de datos están más claramente definidos y se les puede convencer más fácilmente de que presenten su soporte para un proyecto de mercado de datos, en lugar de para un proyecto de almacén de datos corporativo.
31.5.2
Cuestiones fundamentales en los mercados de datos
La Tabla 31.4 enumera las cuestiones fundamentales asociadas con el desarrollo y gestión de los mercados de datos (Brooks, 1997). Tabla 31.4.
Principales cuestiones asociadas con los mercados de datos.
Funcionalidad del mercado de datos Tamaño del mercado de datos Velocidad de carga del mercado de datos Acceso de los usuarios a múltiples mercados de datos Acceso Internet/intranet al mercado de datos Administración del mercado de datos Instalación del mercado de datos
Capítulo 31 Conceptos de almacenes de datos
1059
Funcionalidad del mercado de datos Las capacidades de los mercados de datos se han incrementado a medida que lo hacía su popularidad. En lugar de ser simplemente bases de datos de pequeño tamaño y de fácil acceso, algunos mercados de datos son ahora escalables hasta el rango de los cientos de gigabytes (GB) y proporcionan herramientas sofisticadas de análisis de tipo OLAP (Online Analytical Processing) y/o de minería de datos. Además, centenares de usuarios deben poder acceder de manera remota al mercado de datos. La complejidad y el tamaño de algunos mercados de datos están empezando a ser comparables con las de algunos almacenes de datos corporativos de baja gama.
Tamaño del mercado de datos Los usuarios esperan que los mercados de datos tengan tiempos de respuesta más cortos que los almacenes de datos; sin embargo, las prestaciones se degradan a medida que los mercados de datos crecen en tamaño. Diversos fabricantes de mercados de datos están investigando distintas formas de reducir el tamaño de éstos con el fin de mejorar las prestaciones. Por ejemplo, las dimensiones dinámicas permiten calcular las agregaciones en el momento necesario en lugar de precalcularlas y almacenarlas en el cubo de la base de datos multidimensional (MDDB); véase el Capítulo 33.
Velocidad de carga del mercado de datos Un mercado de datos tiene que equilibrar dos componentes críticos: el tiempo de respuesta a las consultas del usuario final y la velocidad de carga de los datos. Un mercado de datos diseñado para obtener tiempos de respuesta cortos tendrá un gran número de tablas de resumen y de valores agregados. Desafortunadamente, la creación de tales tablas y valores incrementa enormemente el tiempo de los procedimientos de carga. Los fabricantes están investigando una serie de mejoras de los procedimientos de carga, proporcionando índices que se adaptan de forma automática y continua a los datos que se están procesando, o soportando la actualización incremental de la base de datos, de modo que sólo se actualicen las celdas afectadas por el cambio y no toda la estructura de la MDDB.
Acceso de los usuarios a múltiples mercados de datos Una técnica consiste en replicar los datos entre diferentes mercados de datos o, alternativamente, construir mercados de datos virtuales. Los mercados de datos virtuales son vistas de varios mercados de datos físicos o del almacén de datos corporativo que se adoptan para satisfacer los requisitos de grupos de usuarios específicos. Ya hay disponibles productos comerciales que permiten gestionar mercados de datos virtuales.
Acceso Internetlintranet
al mercado de datos
La tecnología Internet/intranet ofrece a los usuarios un acceso a bajo coste a los mercados de datos y al almacén de datos, utilizando exploradores web como Netscape Navigator y Microsoft Internet Explorer. Los productos Internet/intranet para mercados de datos normalmente se conectan entre un servidor web y la herramienta de análisis de los datos. Los fabricantes están desarrollando productos con capacidades web cada vez más avanzadas, entre las que se incluyen las funcionalidades lava y ActiveX. Hemos hablado en detalle de la integración de las bases de datos y la Web en el Capítulo 29.
Administración
del mercado de datos
A medida que se incrementa el número de mercados de datos en una organización, también lo hace la necesidad de gestionar y coordinar centralizadamente las actividades de los mercados de datos. Una vez copiados los datos en los mercados de datos, la información puede volverse incoherente a medida que los usuarios modifiquen sus propios mercados de datos con el fin de poder analizar los datos de diferentes formas. Resulta complicado para las organizaciones administrar múltiples mercados de datos, lo que hace que surjan los problemas relacionados con las versiones de los mercados de datos, con la coherencia e integridad de los datos y de los metadatos, con la seguridad de nivel corporativo y con los ajustes de rendimiento. También hay disponibles herramientas comerciales para la administración de mercados de datos.
1060
Sistemas de bases de datos
Instalación del mercado de datos Los mercados de datos cada vez son más complejos de construir. Hay fabricantes que ofrecen productos de mercado de datos empaquetados, que constituyen una fuente de herramientas de bajo coste para la implementación de mercados de datos.
31.6 Almacenes de datos en Oracle En el Capítulo 8 hemos visto una panorámica general de las principales características del SGBD Oracle. En esta sección vamos a describir las características de Oracle9i Enterprise Edition que están especialmente diseñadas para mejorar las prestaciones y la capacidad de gestión de los almacenes de datos.
31.6.1 Oracle9i Oracle9i Enterprise Edition es uno de los SGBD relacionales más utilizados para almacenes de datos. Oracle ha conseguido semejante éxito centrándose en los requisitos básicos fundamentales de los almacenes de datos: prestaciones, escalabilidad y capacidad de gestión. Los almacenes de datos albergan mayores volúmenes de datos, dan soporte a más usuarios y requieren unas mayores prestaciones, por lo que estos requisitos fundamentales constituyen aspectos clave para la adecuada implementación de un almacén de datos corporativo. Sin embargo, Oracle va más allá de estos requisitos clave, proporcionando la primera auténtica 'plataforma de almacén de datos'. Las aplicaciones de almacén de datos requieren técnicas de procesamiento especializadas que proporcionen soporte para las consultas complejas ad hoc que analicen grandes cantidades de datos. Para satisfacer estos requisitos especiales, Oracle ofrece diversas técnicas de procesamiento de consultas, mecanismos sofisticado s de optimización de consultas para seleccionar las rutas de acceso a los datos más eficientes y una arquitectura escalable que aprovecha al máximo las configuraciones de hardware paralelo. Las aplicaciones de almacén de datos necesitan unas prestaciones sin igual a la hora de acceder a las enormes cantidades de datos almacenados. Oracle proporciona una amplia variedad de esquemas integrados de indexación, de métodos de combinación y funciones de gestión de datos de resumen para poder suministrar rápidamente las respuestas a los usuarios de almacén de datos. Oracle también contempla las necesidades de las aplicaciones que tienen cargas de trabajo de tipo mixto y de aquellas situaciones en las que los administradores quieren controlar qué usuarios o grupos de usuarios tienen prioridad a la hora de ejecutar transacciones o consultas. En esta sección vamos a proporcionar una panorámica de las principales características de Oracle dirigidas a soportar en concreto las aplicaciones de almacén de datos. Estas características incluyen: • gestión de resúmenes; •
funciones analíticas;
•
índices de mapa de bits;
•
métodos de combinación avanzados;
•
optimizador SQL sofisticado;
•
gestión de recursos.
Gestión de resúmenes En una aplicación de almacén de datos, los usuarios realizan a menudo consultas en las que se resumen los datos de detalle mediante dimensiones comunes, como el mes, el producto o la región. Oracle proporciona un mecanismo para almacenar múltiples dimensiones y cálculos de resumen en una tabla. Así, cuando una consulta solicita un resumen de los registros de detalle, la consulta se reescribe transparentemente para acceder a los agregados almacenados, en lugar de sumar los registros de detalle cada vez que se realiza la consulta. Esto proporciona una gran mejora en la velocidad de procesamiento de las consultas. Estos resúmenes se mantienen de forma automática a partir de los datos contenidos en las tablas base. Oracle también proporciona funciones de asistencia a la elaboración de resúmenes que ayudan a los administradores de base de datos a elegir qué tablas de resumen son las más efectivas, dependiendo de la carga de trabajo actual y de las estadísticas
Capítulo 31 Conceptos de almacenes de datos
1061
del esquema. Oracle Enterprise Manager soporta la creación y gestión de vistas materializadas y de sus dimensiones y jerarquías relacionadas, utilizando para ello una interfaz gráfica, lo que simplifica enormemente la gestión de estas vistas materializadas.
Funciones analíticas Oracle9i incluye diversas funciones SQL para sistemas de inteligencia empresarial y aplicaciones de almacén de datos. Estas funciones se denominan, colectivamente, 'funciones analíticas' y proporcionan unas mayores prestaciones a las consultas de análisis, simplificando además la tarea de codificación. Como ejemplos de las nuevas capacidades podemos citar: •
ordenaciones Bretaña?);
(por ejemplo, ¿cuáles son los diez vendedores
de más éxito en la región de Gran
•
agregados móviles (por ejemplo, ¿cuál es la media móvil trimestral de ventas de inmuebles?);
•
otras funciones, incluyendo agregados acumulados, expresiones de adelanto/retraso, entre periodos e informes de tasas.
comparaciones
Oracle también ha incluido los operadores CUBE y ROLLUP para análisis OLAP desde SQL. Estas funciones analíticas amplían significativamente las capacidades de Oracle para las capacidades de proceso analítico en línea (véase el Capítulo 33).
índices de mapa de bits Los índices de mapa de bits permiten mejorar las prestaciones de las aplicaciones de almacén de datos. Pueden coexistir con otros esquemas de indexación disponibles, a los que complementan, incluyendo índices estándar de árbol binario, tablas agrupadas y agrupaciones hash. Mientras que un índice de árbol binario puede ser la forma más eficiente de extraer datos utilizando un identificador unívoco, los índices de mapa de bits son especialmente eficientes a la hora de extraer datos basándose en criterios mucho más amplios, como por ejemplo '¿Cuántos apartamentos fueron vendidos en el último mes?'. En las aplicaciones de almacén de datos, los usuarios finales consultan a menudo los datos basándose en este tipo de criterios más amplios. Oracle permite el almacenamiento eficiente de índices de mapa de bits gracias al uso de técnicas avanzadas de compresión de datos.
Métodos de combinación avanzados Oracle permite realizar combinaciones basadas en las particiones existentes, lo que incrementa enormemente la velocidad de las operaciones de combinación de aquellas tablas que han sido particionadas según las claves de combinación:Al combinarse los registros en las correspondientes particiones, se incrementa la velocidad, evitando procesar particiones donde no es posible que existan registros con claves correspondientes. Asimismo, se utiliza menos cantidad de memoria, ya que son necesarias operaciones de ordenación en memoria de menor envergadura. Las combinaciones hash proporcionan unas prestaciones mayores que otros métodos de combinación en muchas consultas complejas, especialmente en aquellas donde no se pueden aprovechar los índices existentes para el procesamiento de las consultas, lo cual es una situación que aparece con frecuencia en las consultas ad hoc. Este tipo de combinación elimina la necesidad de realizar combinaciones, al utilizarse una tabla hash en memoria que se construye en tiempo de ejecución. Las combinaciones hash también se adaptan muy bien a los mecanismos escalables de ejecución paralela.
Optimizador
SOL sofisticado
Oracle proporciona numerosas y potentes técnicas de procesamiento de consultas que son completamente transparentes para el usuario final. El optimizador basado en costes de Oracle determina dinámicamente las rutas de acceso más eficientes y las combinaciones más adecuadas para cada consulta. Incorpora tecnologías de transformación que reescriben automáticamente las consultas generadas por las herramientas de usuario final, para aumentar la eficiencia de ejecución de la consulta.
1062
Sistemas de bases de datos
Con el fin de elegir la estrategia de ejecución de consultas más eficiente, el optimizador basado en costes de Oracle tiene en cuenta diversas estadísticas, como el tamaño de cada tabla y la selectividad de cada condición de consulta. Los histogramas proporcionan al optimizador basado en costes unas estadísticas más detalladas que se apoyan en una distribución de datos sesgada y no uniforme. El optimizador basado en costes optimiza la ejecución de las consultas realizadas sobre un esquema en estrella, que es un tipo de esquema común en las aplicaciones de almacén de datos (véase la Sección 32.2). Utilizando un sofisticado algoritmo de optimización de consultas para esquemas en estrella y empleando índices de mapa de bits, Oracle puede reducir enormemente la velocidad de las consultas que antes requerían la realización de operaciones de combinación tradicionales. El procesamiento de consultas de Oracle no sólo incluye un conjunto completo de técnicas especializadas en todas las áreas (optimización, métodos de acceso y de combinación y ejecución de consultas) sino que esas diversas técnicas están integradas de forma perfecta y cooperan entre sí para permitir sacar el máximo provecho del motor de procesamiento de consultas.
Gestión de recursos La gestión del procesador y de los recursos de disco en un almacén de datos o aplicación OLTP multiusuario resulta muy complicada. A medida que aumenta el número de usuarios que acceden a los datos, lo hace también la contienda por los recursos existentes. Oracle tiene funciones de gestión de recursos que permiten controlar los recursos del sistema asignados a los usuarios. Los usuarios de mayor importancia, como los encargados de la introducción de pedidos, pueden tener una alta prioridad, mientras que a otros usuarios (por ejemplo los que ejecutan tareas de procesamiento por lotes) se les asigna una prioridad más baja. A los usuarios se les asignan las denominadas clases de recursos, como por ejemplo 'introducción de pedidos' o 'procesamiento por lotes', y a cada clase de recursos se le asigna un porcentaje apropiado de recursos de la máquina. De esta forma, los usuarios de mayor prioridad pueden hacer un mayor uso de los recursos del sistema que los usuarios de prioridad más baja.
Características
adicionales para soporte de almacenes de datos
Oracle incluye también muchas características que mejoran la gestión y las prestaciones de las aplicaciones de almacén de datos. Las reconstrucciones de~Ios índices pueden hacerse en línea sin interrumpir las operaciones de inserción, actualización o borrado que puedan estar teniendo lugar sobre la tabla base. Pueden utilizarse índices funcionales para indexar expresiones, como por ejemplo expresiones aritméticas, o funciones que modifiquen los valores de las columnas. La funcionalidad de muestreo de tablas permite ejecutar consultas que sólo accedan a un porcentaje especificado de las filas o bloques de una tabla. Esto resulta útil para obtener valores agregados significativos, como por ejemplo un promedio, sin necesidad de leer cada fila de un tabla.
Resumen del capítulo •
Los almacenes de datos son colecciones de datos clasificados por temas, integrados, variables en el tiempo y no volátiles que sirven de ayuda al proceso de toma de decisiones en una organización. Un almacén de datos es una tecnología de gestión y análisis de los datos.
•
Los almacenes web de datos son almacenes de datos distribuidos que se implementan sobre la Web, no existiendo ningún repositorio de datos centralizado.
•
Las ventajas potenciales de los almacenes de datos son los altos retornos de inversión, la ventaja competitiva que se puede derivar de su utilización y la mayor productividad de las personas responsables de la toma de decisiones en el nivel corporativo.
•
Un SGBD construido para el procesamiento de transacciones en línea (OLTP) se considera por regla general poco adecuado para los almacenes de datos, porque ambos tipos de sistemas están diseñados con una serie de requisitos distintos. Por ejemplo, los sistemas OLTP están diseñados para maximizar la capacidad de procesamiento de transacciones, mientras que los almacenes de datos se construyen para soportar el procesamiento de consultas ad hoc.
Capítulo 31 Conceptos de almacenes de datos
1063
•
Los principales componentes de un almacén de datos son las fuentes de datos operacionales, el repositorio de datos operacionales, el gestor de carga, el gestor del almacén de datos, el gestor de consultas, los datos detallados, los datos de resumen poco o muy totalizados, los datos de archivado/copia de seguridad, los metadatos y las herramientas de acceso para usuarios finales.
•
Las fuentes de datos operacionales para el almacén de datos son los datos operacionales almacenados en sistemas mainframe típicos de las bases de datos jerárquicas y en red de primera generación; los datos departamentales almacenados en sistemas de archivos propietarios; los datos privados almacenados en estaciones de trabajo y servidores primarios; y los sistemas externos, como por ejemplo Internet, bases de datos comerciales o bases de datos dependientes de los proveedores o clientes de la organización.
•
El repositorio de datos operacionales (ODS) es un almacén de datos operacionales actuales e integrados que se utilizan para el análisis. A menudo está estructurado y se alimenta con datos de la misma forma que se hace con un almacén de datos. Aunque en la práctica puede que actúe simplemente como un área de escala en la que se almacenan los datos durante el proceso de transferencia al almacén de datos.
•
El gestor de carga (también llamado componente de interfaz) realiza todas las operaciones asociadas con la extracción y carga de datos en el almacén de datos. Estas operaciones incluyen transformaciones simples de los datos con el fin de prepararlos para su introducción en el almacén.
•
El gestor del almacén de datos realiza todas las operaciones asociadas con la gestión de los datos dentro del almacén. Las operaciones realizadas por este componente incluyen el análisis de los datos para garantizar su coherencia; la transformación y combinación de los datos de origen; la creación de índices y vistas; la generación de desnormalizaciones y agregaciones; y el archivado y copia de seguridad de los datos.
•
El gestor de consultas (también denominado componente de servicio) realiza todas las operaciones asociadas con la gestión de las consultas de usuario. Las operaciones realizadas por este componente incluyen el dirigir las consultas hacia las tablas apropiadas y la planificación de la ejecución de las consultas.
•
Las herramientas de acceso para usuario final pueden clasificarse en cinco grupos principales: herramientas de consulta y de generación de informes, herramientas de desarrollo de aplicaciones, sistemas de información ejecutiva (EISj, herramientas de procesamiento analítico en línea (OLAP) y herramientas de minería de datos.
•
Los almacenes de datos se centran en la gestión de cinco flujos principales de datos: el flujo de entrada, el flujo ascendente, el flujo descendente, el flujo de salida y el metaflujo.
•
El flujo de entrada está constituido por los procesos asociados a la extracción, limpieza y carga en el almacén de los datos procedentes de los sistemas de origen.
•
El flujo ascendente está constituido por los procesos asociados a la adición de valor a los datos del almacén, mediante operaciones de resumen, empaquetado y distribución de los datos.
•
El flujo descendente son los procesos asociados con el archivado y realización de copias de seguridad de los datos del almacén.
•
El flujo de salida son los procesos asociados con la puesta de los datos a disposición de los usuarios finales.
•
El metaflujo está formado por los procesos asociados con la gestión de los metadatos (datos acerca de los datos).
•
Los requisitos para un SGBDR para almacenes de datos incluyen la velocidad de carga, el procesamiento de la carga, la gestión de la calidad de los datos, la velocidad de las consultas, la escalabilidad en el rango de los terabytes, la escalabilidad en cuanto al número de usuarios, la interconexión de almacenes de datos por red, la administración del almacén de datos, el análisis dimensional integrado y la funcionalidad de consultas avanzadas.
•
Un mercado de datos es un subconjunto de un almacén de datos que soporta los requisitos de un departamento o área de negocio concretos. Las cuestiones principales asociadas con los mercados de datos incluyen su funcionalidad, el tamaño, la velocidad de carga, el acceso de los usuarios a múltiples merca-
1064
Sistemas de bases de datos
dos de datos, el acceso a través de Internet/intranet, ción de éste.
la administración del mercado de datos y la instala-
Cuestiones de repaso 31.1.
Explique qué quieren decir los siguientes términos a la hora de describir las características de los datos contenidos en un almacén de datos: (a)
clasificados por temas;
(b)
integrados;
(c)
variables en el tiempo;
(d)
no volátiles.
31.2.
Explique las diferencias entre los sistemas OLTP (Online Transaction Processing) y los almacenes de datos.
31.3.
Explique los beneficios y los problemas principales asociados con los almacenes de datos.
31.4.
Haga un diagrama de la arquitectura típica y de los componentes principales de un almacén de datos.
31.5.
Describa las características y las funciones principales de los siguientes componentes de un almacén de datos:
31.6.
(a)
gestor de carga;
(b)
gestor del almacén de datos;
(c)
gestor de consultas;
(d)
metadatos;
(e)
herramientas de acceso para usuario final.
Explique las actividades asociadas con cada uno de los cinco principales procesos o flujos de datos que tienen lugar dentro de un almacén de d~tos: (a) flujo de entrada; (b)
flujo ascendente;
(c)
flujo descendente;
(d)
flujo de salida;
(e)
metaflujo.
31.7.
¿Cuáles son las tres técnicas principales que los fabricantes de software utilizan para implementar herramientas de extracción, limpieza y transformación de los datos?
31.8.
Describa los requisitos especializados que se aplican a un sistema de gestión de bases de datos relacionales que sea adecuado para su utilización en un entorno de almacén de datos.
31.9.
Explique cómo pueden ayudar las tecnologías de procesamiento paralelo a satisfacer los requisitos de un almacén de datos.
31.10. Explique la importancia de la gestión de los metadatos y qué relación tiene con la integración del almacén de datos. 31.11. Explique las tareas principales asociadas con la administración y gestión de un almacén de datos. 31.12. Explique las diferencias entre un mercado de datos y un almacén de datos e indique las razones principales para implementar un mercado de datos. 31.13. Identifique las cuestiones principales asociadas con el desarrollo y la gestión de mercados de datos. 31.14. Describa las características de Oracle que permiten soportar los requisitos fundamentales de los almacenes de datos.
Capítulo 31 Conceptos de almacenes de datos
1065
Ejercicio
31.15. El Director Gerente de DreamHome nos pide que investiguemos y escribamos un informe sobre la aplicabilidad de los almacenes de datos para la organización. El informe debe comparar la tecnología de los almacenes de datos con la de los sistemas OLTP e identificar las ventajas y desventajas de cada tecnología, así como los potenciales problemas que pueden surgir a la hora de implementar un almacén de datos. El informe debe contener un conjunto plenamente justificado de conclusiones acerca de la aplicabilidad de un almacén de datos al caso de DreamHome.
Diseño de almacenes de datos
Objetivos del capítulo: En este capítulo aprenderá: • •
Los principales problemas asociados al diseño de una base de datos para un almacén de datos. Una técnica de diseño de una base de datos para almacén de datos denominada modelado de dimensionalidad.
•
La diferencia entre un modelo dimensional y un modelo de entidad-relación
•
Una metodología paso a paso para diseñar una base de datos para un almacén de datos.
(ER).
•
Los criterios para verificar el grado de dimensionalidad
•
Cómo utilizar Oracle Warehouse Builder para construir un almacén de datos.
proporcionado por un almacén de datos.
En el Capítulo 31 hemos descrito los conceptos básicos de los almacenes de datos. En este capítulo, vamos a centramos en los problemas asociados con el diseño de bases de datos para funcionar como almacenes de datos. Desde la década de 1980, los almacenes de datos han desarrollado sus propias técnicas de diseño distintas de las de los de los sistemas de procesamiento de transacciones. Las técnicas de diseño dimensional se han convertido en el enfoque dominante para la mayoría de las bases de datos de almacenes de datos.
Estructura del capítulo En la Sección 32.1 se mencionan los principales problemas asociados con el diseño de almacenes de datos. En la Sección 32.2 se describen los conceptos básicos asociados con el modelado de dimensionalidad y luego se compara esta técnica con el modelado tradicional entidad-relación. En la Sección 32.3 se describe e ilustra una metodología paso a paso para el diseño de la base de datos de un almacén de datos, utilizando ejemplos tomados de una versión ampliada del caso de estudio de DreamHome que se describe en la Sección 10.4 Y en el Apéndice A. En la Sección 32.4 se describen los criterios para verificar la dimensionalidad de un almacén de datos. Finalmente, en la Sección 32.5 se indica cómo diseñar un almacén de datos utilizando un producto de Oracle denominado Oracle Warehouse Builder.
32.1 Diseño de la base de datos para un almacén de datos Diseñar una base de datos para un almacén de datos es una tarea muy compleja. Para comenzar un proyecto de almacén de datos, necesitamos responder a una serie de preguntas tales como: ¿qué requisitos de usuario son los más importantes y qué datos debemos considerar en primer lugar? Asimismo, ¿debemos reducir el alcance del proyecto para que sea más manejable y al mismo tiempo proporcionar una infraestructura que
1068
Sistemas de bases de datos
pueda posteriormente crecer hasta convertirse en un almacén de datos completo de ámbito corporativo? Este tipo de preguntas resaltan algunas de las cuestiones principales relacionadas con el diseño de almacenes de datos. Para muchas empresas, la solución son los mercados de datos, de los que hemos hablado en la Sección 31.5. Los mercados de datos permiten a los diseñadores construir algo mucho más simple y factible para un grupo específico de usuarios. Pocos diseñadores estarían dispuestos a comprometerse con un diseño de ámbito corporativo que deba satisfacer todos los requisitos de todos los usuarios de una vez. Sin embargo, aunque se implemente la solución provisional de construir mercados de datos, el objetivo continúa siendo el mismo: la creación en último término de un almacén de datos que soporte los requisitos de toda la organización. La etapa de recolección y análisis de requisitos (véase la Sección 9.5) de un proyecto de almacén de datos implica entrevistar a los empleados apropiados, como por ejemplo usuarios del departamento de marketing, de finanzas, de ventas, de operaciones y de gestión, para poder identificar un conjunto priorizado de requisitos para toda la organización, requisitos que el almacén de datos debe satisfacer. Al mismo tiempo, deberán realizarse entrevistas con los empleados responsables de los sistemas de procesamiento de transacciones en línea (OLTP, Online Transaction Processing) para identificar qué fuentes de datos pueden proporcionar datos limpios, válidos y coherentes que vayan a continuar siendo soportados a lo largo de los próximos años. Estas entrevistas proporcionan la información necesaria para la vista arriba-abajo (requisitos de usuario) y la vista abajo-arriba (qué orígenes de datos hay disponibles) del almacén de datos. Con estas dos vistas definidas, estaremos listos para comenzar el proceso de diseño de la base de datos del almacén de datos. El componente de base de datos de un almacén de datos se describe utilizando una técnica denominada modelado de dimensionalidad. En las siguientes secciones, vamos a definir primero los conceptos asociados con un modelo dimensional y compararemos este modelo con el tradicional modelo entidad-relación (ER); véanse los Capítulos 11 y 12. Después presentaremos una metodología paso a paso para la creación de un modelo dimensional, utilizando ejemplos resueltos extraídos de una versión ampliada del caso de estudio de DreamHome.
32.2 Modelado de la dimensionalidad Modelado de la dimensionalidad
Una técnica de diseño lógico que trata de presentar los datos de una manera estándar e intuitiva que permita un acceso de alta velocidad.
El modelado de la dimensionalidad utiliza los conceptos del modelado entidad-relación (ER), con algunas restricciones importantes. Todo modelo dimensional (DM, dimensional model) está compuesto de una tabla con una clave principal compuesta, denominada tabla de hechos, y un conjunto de tablas más pequeñas denominadas tablas de dimensión. Cada tabla de dimensión tiene una clave principal simple (no compuesta) que se corresponde con exactamente uno de los componentes de la clave compuesta de la tabla de hechos. En otras palabras, la clave principal de la tabla de hechos está formada por dos o más claves externas. Esta estructura en 'estrella' característica se denomína esquema en estrella o combinación en estrella. La Figura 32.1 muestra un esquema en estrella de ejemplo para el área de venta de inmuebles de DreamHome. Observe que las claves externas (etiquetadas {FK}) se incluyen en el modelo dimensional. Otra característica muy importante de un modelo DM es que todas las claves naturales se sustituyen por claves subrogadas. Esto significa que toda combinación entre la tabla de hechos y las de dimensión está basada en claves subrogadas, no en las claves naturales. Cada clave subrogada debe tener una estructura generalizada basada en enteros simples. El uso de claves subrogadas permite que los datos del almacén de datos tengan una cierta independencia con respecto a los datos utilizados y producidos por los sistemas OLTP. Por ejemplo, cada sucursal tiene una clave natural, branchNo, y también una clave subrogada, branchlD. Esquema en estrella
Una estructura lógica que tiene una tabla de hechos que contiene datos factuales en el centro, rodeada por tablas de dimensión que contienen datos de referencia (que pueden estar desnormalizados).
El esquema en estrella aprovecha las características de los datos factuales, como por ejemplo que los hechos se generan mediante sucesos que han tenido lugar en el pasado y que no es probable que cambien,
Capítulo 32 Diseño de almacenes de datos
1069
independientemente de cómo se analicen. Puesto que el grueso de los datos en un almacén de datos está representado en forma de hechos, las tablas de hechos pueden ser extremadamente grandes, si las comparamos con las tablas de dimensión. Por ello, es importante tratar los datos factuales como datos de referencia de sólo lectura que no varíen con el tiempo. Las tablas de hechos más útiles contienen una o más medidas numéricas, o 'hechos', relativas a cada registro. En la Figura 32.1, los hechos son offerPrice (precio de oferta) sellingPrice (precio de venta), saleCommission (comisión de venta) y saleRevenue (beneficio de la venta). Los hechos más útiles de una tabla de hechos son numéricos y aditivos, porque las aplicaciones de almacenes de datos no acceden casi nunca a un único registro, sino que acceden a centenares, miles o incluso millones de registros cada vez y lo más útil que se puede hacer con tantos registros es agregados de alguna manera. Las tablas de dimensión, por contraste, contienen generalmente información textual descriptiva. Los atributos de dimensión se utilizan como restricciones para las consultas dirigidas al almacén de datos. Por ejemplo, el esquema de estrella mostrado en la Figura 32.1 puede soportar consultas que requieran acceder a los registros de venta de inmuebles en Glasgow utilizando el atributo city de la tabla PropertyForSale, y a los registros de ventas de inmuebles de tipo apartamento utilizando el atributo type de la tabla PropertyForSale. De hecho, la utilidad de un almacén de datos está en relación directa con lo adecuados que sean los datos que se almacenen en las tablas de dimensión. Tablas de dimensión Tablas de dimensión ownerlD {FK} saleRevenue country propertyNo city region
PropertySale
city country region c1ientlD promotionlD stafflD {FK} {FK} position region timelD {FK} branchlD {FK}{FK} c1ientName c1ientNo country c1ientType ClientBuyer Tabla deOwner hechos city region c1ientlD {PK} offerPrice sellingPrice Staff
street city PropertyForSale staffName staffNo sex propertylD postcode type {PK} stafflD {PK}
Tabla de dimensión
Figura 32.1.
Esquema de estrella para las ventas de inmuebles en DreamHome.
1070
Sistemas de bases de datos
Los esquemas en estrella pueden utilizarse para acelerar la velocidad de las consultas, desnormalizando la información de referencia en una única tabla de dimensión. Por ejemplo, en la Figura 32.1 podemos observar que varias tablas de dimensión (concretamente PropertyFor8ale, Branch, ClientBuyer, 8taft y Owner) contienen datos de ubicación (city, region y country), que se repiten para cada una de las tablas. La desnormalización resulta apropiada cuando se accede a menudo a diversas entidades relacionadas con la tabla de dimensión; al desnormalizar, evitamos el gasto de procesamiento extra que habría que realizar para combinar tablas adicionales con el objetivo de acceder a esos atributos. La desnormalización no resulta apropiada si no se accede muy a menudo a los datos adicionales, porque el gasto asociado a la exploración de la tabla de dimensiones expandida puede no verse compensado por ninguna mejora en la velocidad de procesamiento de las consultas. Esquema en copo de nieve
Una variante del esquema en estrella en el que las tablas de dimensión no contienen datos desnormalizados.
Existe una variante del esquema en estrella que se denomina esquema en copo de nieve, que permite que las dimensiones tengan dimensiones. Por ejemplo, podríamos normalizar los datos de ubicación (atributos (city, region y country) en la tabla de dimensión Branch de la Figura 32.1 para crear dos nuevas tablas de dimensión denominadas City y Region. En la Figura 32.2 se muestra una versión normalizada de la tabla de dimensión Branch del esquema para ventas de inmuebles. En un esquema en copo de nieve, los datos de ubicación de las tablas de dimensión PropertyFor8ale, ClientBuyer, 8taft y Owner también se eliminarían y las nuevas tablas de dimensión City y Region serían compartidas con estas tablas. Esquema en copo de estrella
Una estructura híbrida que contiene una mezcla de esquemas en estrella y en copo de nieve.
Los esquemas de base de datos más apropiados utilizan una mezcla de esquemas en estrella desnormalizados y esquemas en copo de nieve normalizados. Esta combinación de esquemas en estrella y en copo de nieve se denomina esquema en copo de estrella. Algunas dimensiones pueden estar presentes en ambas formas para tomar en cuenta los diferentes requisitos de los distintos tipos de consultas. Pero independientemente de si el esquema es en estrella, en copo de E.ieve o en copo de estrella, la forma predecible y estándar del Tablas de dimensión Branch branchNo city{FK} branchType branchlD city Cíty {PK} {PK} I
Figura 32.2.
offerPrice saleRevenue country sellingPrice ownerlD region {FK} {FK} region {PK} Region I
Tabla de hechos stafflD {FK} PropertySale saleCommission branchlD {FK} clientlD propertylD {FK} {FK} promotionlD {FK} timelD {FK}
Parte del esquema en estrella para el área de ventas de inmuebles de DreamHome, con una versión normalizada de la tabla de dimensión Branch.
Capítulo 32 Diseño de almacenes de datos
1071
modelo dimensional subyacente ofrece importantes ventajas para un entorno de almacén de datos, entre las que podemos citar: •
Eficiencia. La coherencia de la estructura de base de datos subyacente permite un acceso más eficiente a los datos por parte de las diversas herramientas, incluyendo las herramientas de consulta y de generación de informes.
•
Posibilidad de gestionar requisitos cambiantes. El esquema de estrella puede adaptarse a los cambios en los requisitos de los usuarios, ya que todas las dimensiones son equivalentes en términos de proporcionar acceso a la tabla de hechos. Esto significa que el diseño está mejor adaptado para soportar las consultas de usuario ad hoc.
•
Ampliabilidad. El modelo dimensional es ampliable; por ejemplo, los cambios típicos qu~ un modelo DM debe soportar incluyen: (a) adición de nuevos hechos, siempre que sean coherentes con la granularidad fundamental de la tabla de hechos existente; (b) adición de nuevas dimensiones, siempre y cuando haya un único valor de dicha dimensión definido para cada registro de hechos existente; (c) adición de nuevos atributos dimensionales; y (d) descomposición de los registros de dimensión existentes para tener un menor nivel de granularidad a partir de un cierto instante temporal.
•
Capacidad de modelar situaciones empresariales comunes. Hay un creciente número de técnicas estándar para tratar situaciones comunes de modelado en el mundo empresarial. Cada una de estas situaciones tiene un conjunto de alternativas bien comprendido que puede programarse específicamente en las herramientas de escritura de informes, en las herramientas de consulta y en otras interfaces de usuario; por ejemplo, el caso en que existen dimensiones que cambian de manera lenta, un caso en que una dimensión 'constante' como Branch o Staff evoluciona en la práctica de forma lenta y asíncrona. Hablaremos con más detalle de las dimensiones lentamente cambiantes en la Sección 32.3, Paso 8.
•
Procesamiento de consultas predecible. Las aplicaciones de almacén de datos que se basan en la profundización simplemente añadirán más atributos de dimensión a partir de un único esquema en estrella. Las aplicaciones que, por el contrario, tratan de relacionar informaciones en un mismo nivel intentarán enlazar tablas de hechos separadas a través de una serie de dimensiones compartidas. Aún cuando el conjunto global de esquemas en estrella del modelo dimensional de la empresa sea complejo, el procesamiento de las consllltas es muy predecible, porque en el nivel más bajo cada tabla de hechos debe ser consultada de manera independiente.
32.2.1
Comparación de los modelos DM y ER
En esta sección vamos a indicar las similitudes y diferencias entre el modelo dimensional (DM, dimensional model) y el modelo entidad-relación (ER). Como hemos dicho en la sección precedente, los modelos DM se utilizan normalmente para diseñar el componente de base de datos de un almacén de datos, mientras que los modelos ER se han utilizado tradicionalmente para describir la base de datos para sistemas de procesamiento de transacciones en línea (OLTP). El modelado ER es una técnica para identificar relaciones entre entidades. Uno de los objetivos principales del modelado ER es eliminar la redundancia de los datos. Esto es enormemente beneficioso para el procesamiento de transacciones, porque las transacciones resultantes son muy simples y deterministas. Por ejemplo, una transacción que actualice la dirección de un cliente normalmente accederá a un único registro de la tabla Client. Este acceso es extremadamente rápido, ya que utiliza un índice sobre la clave principal clientNo. Sin embargo, al hacer eficiente el procesamiento de las transacciones, dichas bases de datos no pueden soportar de forma fácil y eficiente las consultas ad hoc de los usuarios finales. Las aplicaciones tradicionales de carácter empresarial, como el procesamiento de pedidos, el control de almacén y la facturación requieren muchas tablas, efectuándose numerosas combinaciones entre ellas. Un modelo ER para una organización puede tener centenares de entidades lógicas, que pueden corresponderse con cientos de tablas físicas. El modelado ER tradicional no soporta la principal característica de los almacenes de datos, es decir, la extracción de datos intuitiva y de altas prestaciones. La clave para comprender la relación entre los modelos dimensionales y los modelos entidad-relación es comprender que un modelo ER se descompone normalmente en múltiples modelos DM. Los múltiples mode-
1072
Sistemas de bases de datos
los DM se asocian a continuación mediante tablas de dimensión' compartidas'. Vamos a describir la relación entre los modelos ER y los modelos DM con mayor detalle en la siguiente sección, en la que presentaremos una metodología de diseño de bases de datos para almacenes de datos.
32.3 Metodología de diseño de bases de datos para almacenes de datos En esta sección vamos a describir una metodología paso a paso para el diseño de la base de datos de un almacén de datos. Esa metodología fue propuesta por Kimball y se denomina 'Metodología de los nueve pasos' (Kimball, 1996). Los pasos de esta metodología se muestran en la Tabla 32.1. Hay diversas técnicas que ofrecen rutas alternativas para la creación de un almacén de datos. Una de las técnicas de más éxito consiste en descomponer el diseño del almacén de datos en una serie de partes más manejables, denominadas mercados de datos (véase la Sección 31.5). En una etapa posterior, la integración de los mercados de datos, más pequeños, conduce a la creación del almacén de datos de ámbito corporativo. Así, un almacén de datos es la unión de un conjunto de mercados de datos separados implementados a lo largo de un periodo de tiempo, posiblemente por diferentes equipos de diseño y posiblemente sobre diferentes plataformas hardware y software. La metodología de los nueve pasos especifica los pasos requeridos para el diseño de un mercado de datos. Sin embargo, la metodología también enlaza los mercados de datos independientes de modo que, con el tiempo, se combinen para crear un almacén de datos globalmente coherente. Vamos ahora a describir los pasos mostrados en la Tabla 32.1 con un cierto grado de detalle, utilizando ejemplos resueltos tomados de una versión ampliada del caso de estudio de DreamHome. Tabla 32.1.
Metodología de los nueve pasos de Kimball (1996).
Paso
Actividad
1
Selección del proceso
2
Selección de la gra1'1ularidad
3
Identificación y conformación de las dimensiones
4
Selección de los hechos
5
Almacenamiento
6
Terminación de las tablas de dimensión
7
Selección de la duración de la base de datos
8
Control de las dimensiones lentamente cambiantes
9
Selección de las prioridades de consulta y de los modos de consulta
de los valores precalculados
en la tabla de hechos
Paso 1: Selección del proceso El proceso (función) hace referencia al tema objetivo de un mercado de datos concreto. El primer mercado de datos que hay que construir debe ser aquel que resulte más probable acabar en el tiempo previsto, con el presupuesto asignado, y que permita responder a las cuestiones que más importancia tengan desde el punto de vista comercial. La mejor elección como primer mercado de datos suele ser alguna relacionada con las ventas. Esta fuente de datos es probable que resulte accesible y de alta calidad. Al seleccionar el primer mercado de datos para DreamHome, vemos primero que los distintos procesos de negocio de DreamHome incluyen: • venta de inmuebles; • •
alquiler de inmuebles (leasing); visitas a inmuebles;
--
Capítulo 32 Diseño de almacenes de datos • •
1073
anuncios de inmuebles; mantenimiento de inmuebles.
Los requisitos de datos asociados con estos procesos se muestran en el diagrama ER de la Figura 32.3. Observe que este diagrama ER forma parte de la documentación de diseño, que describe los sistemas de procesamiento de transacciones en línea (OLTP) requeridos para soportar los procesos de negocio de DreamHome. El diagrama ER de la Figura 32.3 se ha simplificado etiquetando únicamente las principales entidades y relaciones, y ha sido creado siguiendo los Pasos 1 y 2 de la metodología de diseño de bases de datos descrita anteriormente en los Capítulos 15 y 16. Las entidades sombreadas representan los hechos fundamentales para cada proceso de negocio de DreamHome. El proceso de negocio seleccionado para generar el primer mercado de datos es el de ventas de inmuebles. La parte del diagrama ER original que representa los requisitos de datos de proceso de negocio de ventas de inmuebles se muestran en la Figura 32.4.
Paso 2: Selección de la granularidad La selección de la granularidad implica decidir exactamente qué es lo que va a representar cada registro de la tabla de hechos. Por ejemplo, la entidad PropertySale que se muestra sombreada en la Figura 32.4 representa los hechos acerca de cada venta de inmueble y se convertirá en la tabla de hechos del esquema en estrella para ventas de inmuebles que hemos mostrado anteriormente en la Figura 32.1. Por tanto, la granularidad de la tabla de hechos PropertySale será la correspondiente a las ventas de inmuebles individuales .
Oversees IsFor ClíentBuyer
-
•••~Views••Takes Requires ~ T T~ Requests Offers Owner Staff••• Promotes Promotion ••• Provides PropertyForRent Manages ~ ILeasedBy I ~Attends Property ••• OwnsPropertyForSale Newspaper PropertyViewing I Selis I ~ Displays •• ••
-
Placedln Uses ~
I
••• Recommends Advert
••• Describes
••
Figura 32.3.
Diagrama ER de una versión ampliada de DreamHome.
Branch
1074
Sistemas de bases de datos
" IsFor
~"Has Owns ~ Owner Staff ~ Promotes Manages PropertyForSale
Promotion
I
...
ClientBuyer
Figura 32.4. Parte del diagrama ER de la Figura 32.3 que representa los requisitos de datos del proceso de negocio de ventas de inmuebles de DreamHome.
Sólo después de seleccionar la granularidad de la tabla de hechos podremos identificar las dimensiones de dicha tabla. Por ejemplo, las entidades Branch, Staff,Owner, ClientBuyer,PropertyForSale y Promotionde la Figura 32.4 se utilizarán para hacer referencia a los datos relativos a una venta de inmuebles y se convertirán en las tablas de dimensión del esquema en estrella para ventas de inmuebles que hemos mostrado anteriormente en la Figura 32.1. También incluiremos el tiempo (Time) como dimensión fundamental, la cual está presente en todos los esquemas en estrella. La decisión sobre la granularidad de la tabl1i de hechos determina también la granularidad de cada una de las tablas de dimensión. Por ejemplo, si la granularidad de la tabla de hechos PropertySale es la de las ventas de inmuebles individuales, entonces la granularidad de la dimensión ClientBuyerserán los detalles del cliente que compró un inmueble concreto.
Paso 3: identificación
y conformación
de las dimensiones
Las dimensiones establecen el contexto para realizar preguntas acerca de los hechos contenidos en la tabla de hechos. Un conjunto bien construido de dimensiones hace que el mercado de datos sea comprensible y fácil de utilizar. Identificaremos las dimensiones con el suficiente detalle como para describir cosas tales como los clientes y los inmuebles con la granularidad correcta. Por ejemplo, cada cliente de la tabla de dimensión ClientBuyer está descrito por los atributos c1ientlD,c1ientNo,c1ientName,c1ientType,city, region y country, como hemos visto anteriormente en la Figura 32.1. Un conjunto de dimensiones incompleto o que no se presente adecuadamente reducirá la utilidad que el mercado de datos tiene para la organización. Si alguna dimensión aparece en dos mercados de datos, deberá ser exactamente la misma dirección, o una de ellas tendrá que ser un subconjunto matemático de la otra. Sólo de esta manera podrán dos mercados de datos compartir una o más dimensiones en la misma aplicación. Cuando se utilice una dimensión en más de un mercado de datos, diremos que la dimensión está conformada. Como ejemplos de dimensiones que deben conformarse entre las áreas de ventas de inmuebles y de anuncio de inmuebles tenemos Time, PropertyForSale, Branch y Promotion. Si estas dimensiones no están sincronizadas o si se les permite des-sincronizarse entre unos mercados de datos y otros, el almacén de datos global no podrá funcionar, porque no será posible utilizar conjuntamente los dos mercados de datos. Por ejemplo, en la Figura 32.5 mostramos los esquemas en estrella para ventas de inmuebles y para anuncios de inmuebles con las dimensiones Time, PropertyForSale, Branch y Promotionconformadas (esas dimensiones se indican mediante un sombreado ligero)
Capítulo 32 Diseño de almacenes de datos
1075
Tablas de dimensión conformadas
.--
entNo ek
-- f--.--
propertyNo city {FK} Branch '---~ sellingPrice branchNo advertCost 1-111-i-newspaperlD r- type f-Promotion ~1---yearTime {PK} promotionlD clientlD ownerNo {FK} {FK} promotionName timelD stafflD day {FK} {FK} promotionType city branchType region promotionNo promotionlD country {PK} ownerlD postcode {FK} newspaperName newspaperNo newspaperlD propertylD city {FK} {PK} Newspaper saleRevenue region country branchlD {FK} PropertyForSale PropertySale propertylD offerPrice Advert{PK} distribution branchlD street month country position region c1ientType timelD {PK}
region newspaperType
Tabla de dimensión Figura 32.5.
Esquemas en estrella para las ventas de inmuebles y los anuncios de inmuebles, mostrándose las tablas de dimensión conformadas (compartidas) Time, Property For Sale, Branch y Promotion.
Paso 4: Selección de los hechos La granularidad de la tabla de hechos determina qué hechos pueden usarse en el mercado de datos. Todos los hechos deben expresarse según el nivel de granularidad elegido. En otras palabras, si la granularidad de la tabla de hechos es la de las ventas individuales de inmuebles, entonces todos los hechos numéricos deben referirse a cada venta concreta. Además, los hechos deben ser numéricos y aditivos. En la Figura 32.6 utilizamos el esquema en estrella del proceso de alquiler de inmueble s de DreamHome para ilustrar una tabla de hechos inadecuadamente estructurada. Esta tabla de hechos no es utilizable, ya que tiene hechos no numéricos (promotionName y staffName), un hecho no aditivo (monthlyRent) y un hecho (lastYearRevenue) con un nivel de granularidad distinto al de los restantes hechos de la tabla. La Figura 32.7 muestra cómo podría corregirse la tabla de hechos Lease mostrada en la Figura 32.6 para que la tabla de hechos estuviera apropiadamente estructurada.
1076
Sistemas de bases de datos
Tablas de dimensión country citystaffName region type lastYearRevenue monthlyRent totalRevenue Promotion ownerlD staffName {FK} {FK} {PK} c1ientAllowance clientlD branchlD {FK} {FK} de los otros hechos incoherente con Hecho numérico ownerNo Hecho promotionName promotionNo promotionType promotionlD no aditivo con una granularidad Tabla de hechos Time 8taff Owner country region city Hechos no la timeID{FK} promotionName {FK} totalRent c1ientNo staffCommission week city country region postcode
-
¡-c
staffNo position stafflD {PK}
Tablas de dimensión sex street propertyNo PropertyForRent propertylD {PK}
Tabla de dimensión
Figura 32.6. Esquema en estrella para los alquileres de inmuebles en DreamHome. Este es un ejemplo de tabla de hechos inadecuadamente estructurada, con hechos no numéricos, un hecho no aditivo y un hecho numérico que tiene una granularidad
incoherente con la de los otros hechos de la tabla.
Pueden añadirse hechos adicionales a cualquier tabla de hechos en un instante posterior, siempre y cuando los nuevos hechos sean coherentes con la granularidad de la tabla.
Paso 5: Almacenamiento de los valores precalculados en la tabla de hechos Una vez seleccionados los hechos, es necesario re-examinados para determinar si existe la posibilidad de utilizar valores precalculados. Un ejemplo común de la necesidad de almacenar valores precalculados es el que se produce cuando los hechos comprenden algún tipo de enunciado sobre pérdidas y ganancias. Esta situación surge a menudo cuando la tabla de hechos está basada en facturación o ventas. La Figura 32.7 muestra la tabla de hechos con los atributos rentDuration, totalRent, c1ientAllowance, staffCommission y totalRevenue. Estos tipos de hechos son útiles porque se trata de cantidades aditivas, de las que podemos derivar información muy útil, como el valor clientAllowance promedio basado en agregar un cierto número de registros de la tabla de hechos. Para calcular los ingresos totales (totaIRevenue) generados por cada alquiler de inmueble, restamos los valores clientAllowance y staffCommission de totalRent. Aunque el valor totalRevenue siempre puede deducirse a partir de estos atributos, seguimos necesitando almacenar dicho valor totalRevenue. Esto es particularmente cierto para un valor que resulta fundamental para una empresa, como por ejemplo totalRevenue, o si existe la posibilidad de que un usuario calcule el valor totalRevenue incorrectamente. El coste de que un usuario represente inco-
Capítulo 32 Diseño de almacenes de datos
1077
Tablas de dimensión Tablas de dimensión ownerlD {FK} ownerType totalRevenue staffCommission country propertyNo region
sex staffName country city region rentDuration -- timelD ClientRenter c1ientName clientNo region branchlD {FK} clientlD {FK} stafflD promotionlD {FK} {FK} city country {FK} c1ientlD {PK} country c1ientType position Owner
street reglon type postcode propertylD {PK} {PK} city PropertyForRent 8taff staffNo stafflD
Tabla de dimensión
Figura 32.7. Esquema en estrella para los alquileres de inmuebles de DreamHome. Este es el esquema mostrado en la Figura 32.6, en el que se han corregido los problemas detectados.
rrectamente el valor totalRevenue es mucho mayor que el pequeño coste de introducir un poco de redundancia en el almacenamiento de los datos.
Paso 6: terminación
de las tablas de dimensión
En este paso, yolvemos a las tablas de dimensión y añadimos tantas descripciones textuales a las dimensiones como sea posible. Las descripciones textuales deben ser intuitivas y comprensibles para los usuarios. La utilidad de un mercado de datos está determinada por el ámbito y la naturaleza de los atributos de las tablas de dimensión.
Paso 7: selección de la duración de la base de datos La duración mide hasta qué momento del pasado debe retroceder la tabla de hechos. En muchas empresas, existe el requisito de examinar el mismo periodo temporal uno o dos años antes. Para otras empresas, como las compañías de seguros, puede existir el requisito legal de almacenar los datos de los cinco años anteriores, o incluso más. El disponer de tablas de hechos de muy gran tamaño hace que surjan dos problemas muy significativos en el diseño de los almacenes de datos. En primer lugar, a menudo resulta más difícil obtener los
1078
Sistemas de bases de datos
datos cuanto mayor sea su antiguedad. Cuanto más antiguos son los datos, más probable es que existan problemas a la hora de leer e interpretar los archivos o cintas antiguos. En segundo lugar, es obligatorio que se utilicen las versiones antiguas de las dimensiones importantes, no las versiones más actualizadas. Este es el denominado problema de las 'dimensiones lentamente cambiantes' que se describen con más detalle en el siguiente paso.
Paso 8: control de las dimensiones lentamente
cambiantes
El problema de las dimensiones lentamente cambiantes significa, por ejemplo, que debe utilizarse la descripción antigua de los clientes y de las sucursales a la hora de interpretar el historial de transacciones antiguas. A menudo, el almacén de datos debe asignar una clave generalizada a estas dimensiones importantes con el fin de distinguir entre múltiples instantáneas de los clientes y de las sucursales a lo largo de un periodo de tiempo. Hay tres tipos básicos de dimensiones lentamente cambiantes: el Tipo 1, en el que se sobrescribe un atributo de dimensión modificado; el Tipo 2, en el que un atributo de dimensión modificado hace que se cree un nuevo registro de dimensión; y el Tipo 3, en el que un atributo de dimensión modificado hace que se cree un atributo alternativo, de modo que tanto el valor antiguo como el nuevo del atributo son simultáneamente accesibles mediante el mismo registro de dimensión.
Paso 9: selección de las prioridades de consulta y de los modos de consulta En este paso consideramos las cuestiones de diseño físico. Los problemas de diseño físico más críticos que afectan a la percepción que el usuario final tiene del mercado de datos son la ordenación física de la tabla de hechos en el disco y la presencia de resúmenes o agregaciones preca1culados. Además de estas cuestiones, hay muchos otros problemas adicionales de diseño físico que afectan a la administración, a la realización de copias de seguridad, a la velocidad de indexación y a la seguridad. El lector interesado en obtener más información sobre las cuestiones relativas al diseño físico de almacenes de datos puede consultar la referencia Anahory y Murray (1997). Completada esta metodología, dispondremos de un diseño de un mercado de datos que soporten los requisitos de un proceso de negocio concreto y que también permita la fácil integración con otros mercados de datos relacionados, para formar en último extremo el almacén de datos corporativo. La Tabla 32.2 enumera las tablas de hechos y de dimensión asociadas con el esquema en estrella de cada proceso de negocio de DreamHome (identificados en el Paso 1 de la metodología). La integración de los esquemas en estrella para los procesos de negocio de DreamHome se lleva a cabo utilizando las dimensiones conformadas. Por ejemplo, todas las tablas de hechos comparten las dimensiones Time y Branch como se muestra en la Tabla 32.2. Un modelo dimensional que contenga varias tabla de hechos Tabla 32.2.
Tabla de hechos de dimensión para cada proceso de negocio de DreamHome.
Proceso de negocio
Tabla de hechos
Tablas de dimensión
Ventas de inmuebles
PropertySale
Time, Branch, Staff, PropertyForSale, ClientBuyer,
Alquileres de inmuebles Visitas a inmuebles Anuncios de inmuebles
Mantenimiento
de inmueble s
Lease
PropertyViewing
Advert
PropertyMaintenance
Owner,
Promotion
Time, Branch, Staff, PropertyForRent, ClientRenter, Promotion
Owner,
Time, Branch, PropertyForSale, PropertyForRent,
ClientBuyer,
ClientRenter
Time, Branch, PropertyForSale, PropertyForRent,
Promotion,
Newspaper
Time, Branch, Staff, PropertyForRent
Capítulo 32 Diseño de almacenes de datos
-
=
-
1079
-
.•••Manages ClientRental I .•••Describes .•••Holds .•••Oraanizes Time~ Agrees ClientBuyer Promotion.•••Displays Advert UndertakenOn Newspaper PropertyViewing SettledOn ~ .•••Attends .•••Requests Lease PropertySale CompletedOn ~ Determines ~ Staff 'f 'f .•••Seeks Administers LeasedBy ~ AssociatedWith ~ ce Supports ~ OccurredOn ~I I ~ .•••Promotes I Property •IsFor
-f--
--
DisplayedOn ~
Figura 32.8.
Modelo dimensional
(constelación
de hechos) para el almacén de datos de DreamHome.
que comparten una o más tablas de dimensión conformadas se denomina constelación de hechos. La constelación de hechos para el almacén de datos de DreamHome se muestra en la Figura 32.8. El modelo se ha simplificado para mostrar únicamente los nombres de las tablas de hechos y de dimensión. Observe que las tablas de hechos se muestran con sombreado oscuro y que las tablas de dimensión conformadas se muestran con sombreado claro.
32.4 Criterios para verificar la dimensionalidad de un almacén de datos Desde la década de 1980, los almacenes de datos han desarrollado sus propias técnicas de diseño, distintas de las de los sistemas OLTP. Las técnicas de diseño dimensional se han consolidado como el enfoque principal
1080
Sistemas de bases de datos
para la mayoría de los almacenes de datos. En esta sección se describen los criterios propuestos por Ralph Kimball para medir el grado con el que un sistema soporta las vistas dimensionales del almacén de datos (Kimball, 2000a,b). A la hora de evaluar un almacén de datos concreto, recuerde que son pocos los fabricantes que tratan de proporcionar una solución completamente integrada. Sin embargo, como el almacén de datos es un sistema completo, los criterios sólo deben usarse para evaluar sistemas completos extremo a extremo, y no una colección de paquetes disjuntos que nunca puedan llegar a integrarse. Hay veinte criterios divididos en tres amplios grupos: arquitectura, administración y expresión como se muestra en la Tabla 32.3. El propósito de establecer estos criterios consiste en fijar un estándar objetivo para evaluar hasta qué punto soporta un sistema las vistas dimensionales del almacén de datos, y fijar un umbral lo suficientemente alto como para que los fabricantes tengan una razón para mejorar sus sistemas. La manera en que debe usarse esta lista consiste en calificar el sistema según cada criterio con un simple O o l. Un sistema merecerá un 1 sólo si cumple con la definición completa de soporte de dicho criterio. Por ejemplo, un sistema que ofrezca mecanismos de navegación de agregados (el cuarto criterio) que sólo estén disponibles para una única herramienta de interfaz obtendrá un O, porque esos mecanismos de navegación de agregados no son abiertos. En otras palabras, no puede considerarse que un criterio sólo se cumple parcialmente. Si se cumple parcialmente, entonces el criterio no se cumple. Los criterios de arquitectura son características fundamentales de la forma en que el sistema completo está organizado. Estos criterios usualmente abarcan desde el módulo de servicio a la plataforma de escritorio del usuario, pasando por el SGBD y el módulo de interfaz. Los criterios de administración son más tácticos que los criterios de arquitectura, pero se consideran esenciales para la adecuada operación de un almacén de datos dimensionalmente orientado. Estos criterios afectan generalmente al personal de los departamentos de tecnología de la información encargado de construir y mantener el almacén de datos. Tabla 32.3.
Criterios para evaluar la dimensionalidad
proporcionada
por un almacén de datos (Kimball, 2000a,b). Grupo
Criterios
Arquitectura
Declaración ~plícita Hechos y dimensiones conformadas Integridad dimensional Navegación abierta de los agregados Simetría dimensional Escalabilidad
dimensional
Tolerancia relativa a la densidad
Administración
Modificación
sencilla
Replicación dimensional Notificación
de cambios de dimensión
Administración de claves subrogadas Coherencia intemacional
Expresión
Jerarquías multidimensión Jerarquías de dimensiones intercaladas Dimensiones multivaluadas Dimensiones
lentamente cambiantes
Papeles de una dimensión Dimensiones
intercambiándose
en caliente
Dimensiones
de rangos de hechos generales sobre la marcha
Dimensiones
de comportamiento
generales sobre la marcha
Capítulo 32 Diseño de almacenes de datos
1081
Los criterios de expresión son principalmente capacidades analíticas que resultan necesarias en las situaciones reales. La comunidad de usuarios finales es la que experimenta directamente los resultados del cumplimiento de los criterios de expresión. Los criterios de expresión para los sistemas dimensionales no son las únicas características que los usuarios buscan en un almacén de datos, pero todos ellos constituyen capacidades que necesitan aprovechar la potencia ofrecida por un sistema dimensional. Un sistema que soporte la mayoría de estos criterios dimensionales, o todos ellos, será adaptable, más fácil de administrar y capaz de soportar muchas aplicaciones del mundo real. La principal ventaja de los sistemas dimensionales es que están dirigidos por las necesidades del negocio y de los usuarios finales. Para obtener más detalles sobre los criterios de la Tabla 32.3 el lector interesado puede consultar Kimball (2000a,b).
32.5 Diseño de almacenes de datos con Oracle En la Sección 8.2 hemos presentado el SGBD Oracle. En esta sección, vamos a describir Oracle Warehouse Builder (OWB) como uno de los componentes clave de la solución para almacenes de datos de Oracle. Este componente permite el diseño e implantación de almacenes de datos, mercados de datos y aplicaciones de inteligencia empresarial. OWB es una herramienta de diseño y también una herramienta de extracción, transformación y carga (ETL; extraction, transformation and loading). Un aspecto importante de OWB desde la perspectiva de las empresas es que permite la integración de los entornos tradicionales de almacenes de datos con los nuevos entornos de e-Business (Oracle Corporation, 2000). En esta sección vamos a proporcionar primero una panorámica de los componentes de OWB y de sus tecnologías subyacentes y luego veremos cómo puede aplicarse OWB a las tareas típicas de diseño de un almacén de datos.
32.5.1
Componentes de Oracle Warehouse Huilder
OWB proporciona los siguientes componentes funcionales principales: •
Un repositorio compuesto de un conjunto de tablas en una base de datos Oracle al que se accede a través de un nivel de acceso basado en Java. El repositorio está basado en el estándar CWM (Common Warehouse Model), queJlermite que los metadatos de OWB sean accesibles por parte de otros productos que soporten este estándar (véase la Sección 31.4.3).
•
Una interfaz gráfica de usuario (GUI) que permite acceder al repositorio. La interfaz incluye editores gráficos y un amplio conjunto de asistentes. Esta interfaz está escrita en Java, lo que hace que sea portable.
•
Un generador de código, también escrito en Java, genera un código que permite la implantación de almacenes de datos. Posteriormente en esta sección veremos los diferentes tipos de código generados porOWB
•
Integradores, que son componentes dedicados a extraer datos de un tipo concreto de fuente. Además del soporte nativo para Oracle y para otros orígenes de datos relacionales, no relacionales y basados en archivos sin estructura, los integradores OWB permiten acceder a información de aplicaciones de planificación de recursos empresariales (ERP, enterprise resource planning) tales como Oracle y SAP RJ3. El integrador SAP proporciona acceso transparente a las tablas de SAP utilizando código PLlSQL generador por OWB.
•
Una interfaz abierta que permite a los desarrolladores ampliar las capacidades de extracción de OWB y aprovecharse de los beneficios que proporciona la arquitectura OWB. Esta interfaz abierta está a disposición de los desarrolladores como parte del kit de desarrollo software de OWB.
•
Runtime (entorno de ejecución), que es un conjunto de tablas, secuencias, paquetes y disparadores que se instalan en el esquema de destino. Estos objetos de base de datos son la base para las capacidades de auditoría y de detección/corrección de errores de OWB. Por ejemplo, pueden reiniciarse los procesos de carga basándose en la información almacenada en las tablas de ejecución. OWB incluye un visualizador de auditoría para acceder a las tablas de ejecución y a los informes de ejecución.
1082
Sistemas de bases de datos
I
API
I
r
Repo,''''o Figura 32.9.
J
Arquitectura
Almacén de datos
de Oracle Warehouse
Builder.
La arquitectura de Oracle Warehouse Builder se muestra en la Figura 32.9. Oracle Warehouse Builder es uno de los componentes clave de los almacenes de datos Oracle. Los otros productos con los que OWB debe integrar dentro del almacén de datos incluyen: •
Oracle: el motor de OWB (ya que no hay servidor externo);
•
Oracle Enterprise Manager: para planificación;
•
Oracle Workflow: para gestión de dependencias;
•
Oracle Pure'Extract:
•
Oracle Pure'Integrate:
•
Oracle Gateways: para acceso a datos almacenados en sistemas relacionales y tipos mainframe.
32.5.2
para acceso a mainframes MVS; para control de calidad de los datos;
Utilización de Oracle Warehouse Builder
En esta sección vamos a describir cómo ayuda".oWB al usuario en algunas tareas típicas de los almacenes de datos, como la definición de las estructuras de origen de los datos, el diseño del almacén de datos, la asignación de los orígenes de datos a sus correspondientes destinos, la generación de código, la instanciación del almacén de datos, la extracción de datos y el mantenimiento del almacén.
Definición
de los orígenes de datos
Una vez determinados los requisitos e identificados todos los orígenes de datos, puede utilizarse una herramienta como OWB para construir el almacén de datos. OWB puede gestionar un conjunto de orígenes de datos diversos gracias a los integradores. OWB incluye también el concepto de módulo, que es una agrupación lógica de objetos relacionados. Hay dos tipos de módulos: origen de datos y almacén de datos. Por ejemplo, un módulo de origen de datos puede contener todas las definiciones de las tablas de una base de datos OLTP que esté actuando como fuente de datos para el almacén. Y un módulo de tipo almacén de datos puede contener definiciones de las tablas de hechos, de dimensión y de escala que forman el almacén de datos. Es importante observar que los módulos simplemente contienen definiciones, es decir, metadatos, acerca de los orígenes de datos o de los almacenes de datos, y no contienen objetos que pueden ser rellenados o consultados. El usuario debe identificar los integradores que resultan adecuados para cada origen de datos y cada integrador accederá a uno de esos orígenes e importará los metadatos que describen la información.
Orígenes de datos Oracle Para conectarse a una base de datos Oracle, el usuario debe solucionar el integrador para bases de datos Oracle. A continuación, tendrá que suministrar información más detallada acerca de la conexión, como por ejemplo el nombre de usuario, la contraseña y la cadena de conexión SQL *Net. Esta información se utiliza para definir un enlace de base de datos dentro del repositorio OWB. OWB utiliza este enlace de base de datos
Capítulo 32 Diseño de almacenes de datos
1083
para consultar el catálogo del sistema de la base de datos de origen y extraer los metadatos que describen las tablas y vistas que sean de interés para el usuario. El usuario puede inspeccionar visualmente el origen de datos y seleccionar los objetos que le interesen. Orígenes
de datos no Oracle
A las bases de datos no Oracle se accede exactamente de la misma manera que a las bases de datos Oracle. Lo que hace que esto sea posible es la tecnología de pasarelas transparentes de Oracle. En esencia, una pasarela transparente permite tratar una base de datos no Oracle de la misma manera que si fuera Oracle. En el nivel SQL, una vez definido el enlace de base de datos que apunta a la base de datos no Oracle, puede consultarse ésta mediante instrucciones SELECT exactamente igual que cualquier otra base de datos Oracle. En OWB, todo lo que el usuario tiene que hacer es identificar el tipo de la base de datos, para que OWB pueda seleccionar la pasarela transparente apropiada para la definición del enlace de base de datos. En el caso de orígenes de datos de tipo mainframe MVS, OWB y Oracle PureoExtract proporcionan mecanismos de extracción de datos de orígenes tales como IMS, DB2 y VSAM. El plan es que Oracle PureoExtract termine por integrarse con la tecnología OWB. Archivos
sin estructura
OWB soporta dos tipos de archivos sin estructura: delimitados por caracteres y de longitud fija. Si el origen de los datos es un archivo sin estructura, el usuario selecciona el integrador para archivos sin estructura y especifica la ruta y el nombre del archivo. El proceso de creación de los metadatos que describen un archivo es diferente del que se utiliza para una tabla de la base de datos. Con una tabla, la base de datos propietaria almacena una amplia información acerca de la tabla, como por ejemplo el nombre de la misma, los nombres de las columnas y los tipos de datos. Esta información puede extraerse fácilmente del catálogo. Con un archivo, por el contrario, el usuario tiene que ayudar en el proceso de creación de los metadatos, aunque OWB realiza algunas deducciones inteligentes acerca de los datos. En OWB, este proceso se denomina muestreo. Datos web Con la cada vez mayor utilización de Internet, el nuevo desafío al que se enfrentan los almacenes de datos es capturar datos procedentes de sitios web. Hay diferentes tipos de datos en los entornas de e-Business: datos web transaccionales almacenados en las bases de datos subyacentes; datos de flujos de clics almacenados en los archivos de registro de los servidores web; datos de registro en las bases de datos o en los archivos de registro; y datos consolidados de flujos de clics en los archivos de registro de las herramientas de análisis web. OWB puede utilizar como fuente todos estos orígenes de datos, gracias a sus funciones predefinidas para el acceso a bases de datos y a archivos sin estructura.
Calidad de los datos Una solución para el desafío que representa garantizar la calidad de los datos es utilizar OWB con Oracle PureoIntegrate. Oracle PureoIntegrate es un software de integración de datos de consumidores que automatiza la creación de perfiles consolidados de consumidores y de los datos de negocio relacionados para soportar las aplicaciones de e-Business y de gestión de relaciones con los clientes. PureoIntegrate complementa OWB proporcionando funciones avanzadas de transformación y limpieza de los datos diseñadas específicamente para satisfacer los requisitos de las aplicaciones de bases de datos. Dichas funciones incluyen: •
un procesamiento integrado de los nombres y direcciones para estandarizar, corregir y mejorar la repre-
sentación de los nombres y ubicaciones de los clientes; •
técnicas avanzadas de correspondencia probabilística para identificar consumidores, empresas, domicilios, grupos de domicilios u otras entidades para las cuales no existan identificadores comunes;
•
potentes procesos de combinación basados en reglas para resolver los conflictos entre los datos y crear el 'mejor posible' resultado integrado a partir de las correspondencias detectadas.
1084
Sistemas de bases de datos
Diseño del almacén de datos Una vez identificados y definidos los sistemas de origen, la siguiente tarea consiste en diseñar el almacén de datos basados en los requisitos del usuario. Uno de los tipos de diseño más populares para almacenes de datos es el esquema en estrella y sus diversas variantes, presentadas en la Sección 32.2. Asimismo, muchas herramientas de inteligencia empresarial como Oracle Discoverer están optimizadas para este tipo de diseño. OWB soporta todas las variantes de diseño de esquemas en estrella. Incluye asistentes y editores gráficos para las tablas de hechos y de dimensiones. Por ejemplo, en el editor de dimensiones el usuario puede definir lógicamente los atributos, niveles y jerarquías de una dimensión.
Establecimiento
de la correspondencia
entre fuentes y destinos
Una vez que se han definido adecuadamente tanto los orígenes de los datos como las tablas de destino, el siguiente paso consiste en establecer la correspondencia entre ambos. Recuerde que hay dos tipos de módulos: módulos de origen de datos y módulos de almacén de datos. Los módulos pueden reutilizarse muchas veces en diferentes mapeos. Los módulos de almacén de datos pueden también usarse como módulos de origen de datos. Por ejemplo, en una arquitectura donde tengamos una base de datos OLTP que alimente a un almacén de datos central, que a su vez alimente a un almacén de datos, el almacén de datos será un destino (desde la perspectiva de la base de datos OLTP) y una fuente (desde la perspectiva del mercado de datos). Los mapeos de OWB se definen en dos niveles. Un mapeo de alto nivel indica los módulos de origen y de destino, mientras que por debajo de él se encuentra el mapeo de detalle que permite a un usuario establecer la correspondencia entre las columnas de origen y las columnas de destino y definir las transformaciones. OWB incluye una biblioteca predefinida de transformaciones en la que el usuario puede seleccionar transformaciones ya existentes. Los usuarios pueden también definir sus propias transformaciones en PL/SQL y lava.
Generación de código El generador de código es el componente de OWB que lee las definiciones de destino y los mapeos fuentedestino y genera el código para implementar el almacén de datos. El tipo de código generado varía dependiendo del tipo de objeto que el usuario quiera impls.mentar. Diseño lógico y físico Antes de generar el código, el usuario ha estado trabajando principalmente en el nivel lógico, es decir, en el nivel de las definiciones de los objetos. En dicho nivel, lo que al usuario le preocupa es capturar todos los detalles y relaciones (la semántica) de un objeto, pero todavía no le preocupa definir ninguna característica de implementación. Por ejemplo, considere una tabla que haya que implementar en una base de datos Oracle. En el nivel lógico, lo que al usuario le preocupa es el nombre de la tabla, el número de las columnas, los nombres y tipos de datos de las columnas y las relaciones que esa tabla pueda tener con otras tablas. Sin embargo, en el nivel físico, la cuestión es: ¿cómo puede implementarse esta tabla óptimamente en una base de datos Oracle? El usuario debe ahora preocuparse de cosas tales como los espacios de tablas, índices y parámetros de almacenamiento (véase la Sección 8.2.2). OWB permite al usuario ver y manipular un objeto tanto en el nivel lógico como en el físico. La definición lógica y los detalles fisicos de implementación se sincronizan automáticamente. Configuración En OWB, el proceso de asignar características fisicas a un objeto se denomina configuración. Las características específicas que puedan definirse dependerán del objeto que se esté configurando. Estos objetos incluyen, por ejemplo, parámetros de almacenamiento, índices, espacios de tablas y particiones. Validación Resulta conveniente comprobar que las definiciones de los objetos son completas y coherentes antes de comenzar a generar el código. OWB ofrece una función de validación para automatizar este proceso. Entre
Capítulo 32 Diseño de almacenes de datos
1085
los errores detectables por el proceso de validación están, por ejemplo, los desajustes de tipos de datos entre un origen y un destino, y los errores de claves externas. Generación Entre los tipos principales de código que OWB puede generar se incluyen: •
Comandos DDL Data Definition Language de SQL. Un módulo de almacén de datos, con sus definiciones de tablas de hechos y dimensiones, se implementa como un esquema relacional dentro de una base de datos Oracle. OWB genera scripts DDL SQL para crear este esquema. Los scripts pueden ejecutarse desde OWB o guardarse en el sistema de archivos para su ejecución manual posterior.
•
Programas PL/SQL. Un mapeo fuente-destino da como resultado un programa PL/SQL siempre que el origen de datos sea una base de datos, ya sea Oracle o no Oracle. El programa PL/SQL accede a la base de datos origen a través de un enlace de base de datos, realiza las transformaciones definidas en el mapeo y carga los datos en la tabla de destino.
•
Archivos de control de SQL *Loader. Si el origen de datos en un mapeo es un archivo sin estructura, OWB genera un archivo de control para utilizado con SQL *Loader.
•
Scripts TeZ.OWB también genera scripts Tc\. Estos pueden utilizarse para planificar mapeos PL/SQL y SQL *Loader como trabajos en Oracle Enterprise Manager, por ejemplo para refrescar el almacén de datos a intervalos periódicos.
Instanciación del almacén de datos y extracción de los datos Antes de poder transferir los datos del origen a la base de datos de destino, el desarrollador tiene que instanciar el almacén de datos, es decir, ejecutar los scripts DDL generados para crear el esquema de destino. OWB denomina a este paso implantación. Una vez implantado el esquema de destino, pueden usarse los programas PL/SQL para transferir los datos desde el origen de datos. Observe que el mecanismo básico de transferencia de datos es INSERT ... SELECT ... con la utilización de un enlace de base de datos. Si se produce un error, una rutina de uno de los paquetes de ejecución de OWB registra el error en una tabla de auditoría.
Mantenimiento del atmacén de datos Una vez instanciado el almacén de datos y completada la carga inicial, es necesario mantener el almacén. Por ejemplo, habrá que refrescar la tabla de hechos a intervalos regulares, para que las consultas devuelvan resultados actualizados. Las tablas de dimensiones tendrán que ser ampliadas y actualizadas, aunque de forma mucho menos frecuente que las tablas de hechos. Un ejemplo de tabla de dimensión lentamente cambiante es la tabla Customer, en la que la dirección, el estado civil o el nombre de un cliente pueden cambiar a lo largo del tiempo. Además de la operación INSERT, OWB también soporta otras formas de manipular el almacén de datos: . •
UPDATE
•
DELETE
•
INSERTIUPDATE (insertar una fila; si ya existe, actualizada)
•
UPDATE/INSERT
(actualizar una fila; si no existe, insertada)
Estas características ponen a disposición de los usuarios de OWB una diversidad de herramientas para llevar a cabo las tareas continuas de mantenimiento. OWB se comunica con Oracle Enterprise Manager para las tareas de mantenimiento repetitivas, como por ejemplo para refrescar una tabla de hechos de forma planificada, a intervalos regulares. Para las dependencias complejas, OWB puede integrarse con Oracle Workflow.
Integración de los metadatos OWB está basado en el estándar CWM (Common Warehouse Model); véase la Sección 31.4.3. Puede intercambiar fácilmente metadatos con Oracle Express y Oracle Discoverer, así como con otras herramientas de inteligencia empresarial que cumplan con el estándar.
1086
Sistemas de bases de datos
Resumen del capítulo •
El modelado de dimensionalidad es una técnica de diseño que trata de presentar los datos en una forma estándar e intuitiva que permita un acceso de alto rendimiento.
•
Cada modelo dimensional (DM, dimensional model) está compuesto de una tabla con una clave principal compuesta, denominada tabla de hechos y un conjunto de tablas más pequeñas denominadas tablas de dimensión. Cada tabla de dimensión tiene una clave principal simple (no compuesta) que se corresponde exactamente con uno de los componentes de la clave compuesta de la tabla de hechos. En otras palabras, la clave principal de la tabla de hechos está formada por dos o más claves externas. Esta estructura característica en estrella se denomina esquema en estrella o combinación en estrella.
•
El esquema en estrella es una estructura lógica que tiene una tabla de hechos que contiene datos factuales en el centro, rodeada por tablas de dimensión que contienen datos de referencia (las cuales pueden estar desnormalizadas ).
•
El esquema de estrella aprovecha las características de los datos factuales, como por ejemplo que los hechos son generados por sucesos que han ocurrido en el pasado y que es improbable que cambien, independientemente de cómo se analicen. Puesto que el grueso de los datos del almacén se representa mediante hechos, las tablas de hechos pueden ser extremadamente grandes, si las comparamos con las tablas de dimensión.
•
Los hechos más útiles de una tabla de hechos son numéricos y aditivos, porque las aplicaciones de almacén de datos casi nunca acceden a un único registro, sino que acceden a centenares, miles o incluso millones de registros cada vez y lo más útil que puede hacerse con tantos registros es calcular algún tipo de agregado.
•
Las tablas de dimensión contienen casi siempre información textual descriptiva. Los atributos de dimensión se utilizan como restricciones en las consultas dirigidas al almacén de datos.
•
El esquema en copo de nieve es una variante del esquema en estrella en la que las tablas de dimensión no contienen datos desnormalizados ...•
•
El esquema en copo de estrella es una estructura híbrida que contiene una mezcla de esquemas en estrella y en copo de nieve.
•
La clave para comprender la relación entre los modelos dimensionales y los modelos ER es ser consciente de que un modelo ER normalmente se descompone en múltiples modelos DM. Después, los múltiples modelos DM se asocian mediante tablas de dimensión conformadas (compartidas).
•
Hay muchas técnicas que ofrecen rutas alternativas para la creación de un almacén de datos. Una de las técnicas de más éxito consiste en descomponer el diseño del almacén de datos en una serie de partes más manejables, denominadas mercados de datos. En una fase posterior, la integración de estos mercados de datos, más pequeños, conduce a la creación del almacén de datos de ámbito corporativo.
•
La metodología de los nueve pasos especifica los pasos requeridos para el diseño de un mercado de datos/almacén de datos. Los pasos son: Paso 1 Selección del proceso, Paso 2 Selección de la granularidad, Paso 3 Identificación y conformación de las dimensiones, Paso 4 Selección de los hechos, Paso 5 Almacenamiento de los valores precalculados en la tabla de hechos, Paso 6 Terminación de las tablas de dimensión, Paso 7 Selección de la duración de la base de datos, Paso 8 Control de las dimensiones lentamente cambiantes y Paso 9 Selección de las prioridades de consulta y de los modos de consulta.
•
Hay criterios que permiten medir el grado con el que un sistema soporta las vistas dimensional es del almacén de datos. Los criterios se dividen en tres grandes grupos: arquitectura, administración y expresión.
•
Oracle Warehouse Builder (OWB) es un componente clave de la solución Oracle para almacenes de datos, que permite el diseño e implantación de almacenes de datos, mercados de datos y aplicaciones de inteligencia empresarial. OWB es a la vez una herramienta de diseño y una herramienta de extracción, transformación y carga (ETL).
Capítulo 32 Diseño de almacenes de datos
1087
Cuestiones de repaso 31.1.
Identifique las cuestiones principales asociadas con el diseño de una base de datos para un almacén de datos.
31.2.
Describa las diferencias entre un modelo dimensional (DM) y un modelo entidad-relación
(ER).
31.3.
Haga un diagrama que represente un esquema en estrella típico.
31.4.
Describa las diferencias entre las tablas de hechos y las tablas dimensionales en un esquema en estrella.
31.5.
Indique las diferencias entre los esquemas en estrella, en copo de nieve y en copo de estrella.
31.6.
Describa las ventajas que proporcionan los esquemas en estrella, en copo de nieve y en copo de estrella en un entorno de almacén de datos.
31.7.
Describa las principales actividades asociadas con cada paso de la metodología de los nueve pasos para el diseño de bases de datos para almacenes de datos.
31.8.
Describa el propósito de evaluar la dimensionalidad
31.9.
Describa brevemente los grupos de criterios utilizados para evaluar la dimensionalidad de datos.
de un almacén de datos. de un almacén
31.10. Describa cómo soporta Oracle Warehouse Builder el diseño de un almacén de datos.
Ejercicios 31.11. Utilice la metodología de los nueve pasos para el diseño de bases de datos para almacenes de datos con el fin de producir modelos dimensionales para los casos de estudio descritos en el Apéndice B. 31.12. Utilice la metodología de los nueve pasos para el diseño de bases de datos para almacenes de datos con el fin de producir un modelo dimensional para toda la organización para la que trabaje, o para parte de la misma.
Capítulo
OLAP
Objetivos del capítulo: En este capítulo aprenderá: •
El propósito del procesamiento analítico en línea (OLAP, Online Analytical Processing).
•
Las relaciones entre OLAP y los almacenes de datos.
•
Las características clave de las aplicaciones OLAP.
•
Los beneficios potenciales asociados con la implementación
•
Cómo representar datos multidimensionales.
•
Las reglas para las herramientas OLAP.
•
Las principales categorías de las herramientas OLAP.
• •
Las extensiones OLAP al. estándar SQL. El soporte para OLAP en Oracle.
de aplicaciones OLAP.
En el Capítulo 31 hemos comentado la creciente popularidad de los almacenes de datos como medio de obtener una ventaja competitiva. Allí vimos que los almacenes de datos combinan grandes volúmenes de dato con el propósito de analizarlos. Hasta hace poco, las herramientas de acceso para grandes sistemas de bases de datos sólo proporcionaban mecanismos de análisis de datos limitados y relativamente simplistas. Sin embargo, junto al crecimiento de los almacenes de datos también se está incrementando la demanda de los usuarios para disponer de herramientas de acceso más potentes que proporcionen capacidades analíticas avanzadas. Hay dos tipos principales de herramientas de acceso disponibles para satisfacer estas demandas: las herramientas de procesamiento analítico en línea (OLAP, Online Analytical Processing) y las herramientas de minería de datos. Estas herramientas difieren en lo que ofrecen a los usuarios, debido a lo cual se trata de tecnologías complementarias. Un almacén de datos (o, más comúnmente, uno o más mercados de datos) junto con herramientas OLAP y/o de minería de datos constituye una tecnología denominada de inteligencia empresarial. En este capítulo vamos a describir las tecnologías OLAP y en el siguiente veremos el tema de la minería de datos.
Estructura del capítulo En la Sección 33.1 introduciremos el tema del procesamiento analítico en línea (OLAP) y hablaremos de la relación entre OLAP y los almacenes de datos. En la Sección 33.2 describiremos las aplicaciones OLAP e identificaremos las características clave y los potenciales beneficios asociados con estas aplicaciones. En la Sección 33.3 se explica cómo representar datos multidimensionales y se describen los principales conceptos asociados con el análisis multidimensional. En la Sección 33.4 se describen las reglas que deben cumplir las herramientas OLAP y se resaltan las características y problemas asociados con estas herramientas. En la
1090
Sistemas de bases de datos
Sección 33.5 se explica cómo se ha ampliado el estándar SQL para incluir funciones OLAP. Finalmente, en la Sección 33.6, se describe el soporte para OLAP de Oracle. Los ejemplos en este capítulo están tomados del caso de estudio de DreamHome que se describe en la Sección lOA y en el Apéndice A.
33.1 Procesamiento analítico en línea En las últimas décadas, hemos sido testigos de la creciente popularidad y prevalencia de los SGBD relacionales, de modo que ahora podemos ver que una parte significativa de los datos corporativos se almacena en dicho tipo de sistemas. Las bases de datos relacionales se han estado utilizando principalmente para soportar sistemas de procesamiento de transacciones en línea (OLTP, Online Transaction Processing). Para proporcionar un soporte apropiado a los sistemas OLTP, los SGBD relacionales se han desarrollado de forma que permitan la ejecución eficiente de un gran número de transacciones relativamente simples. En los últimos años, los fabricantes de sistemas SGBD relacionales han tratado de dirigirse al mercado de los almacenes de datos y han promocionado sus sistemas como herramientas para construir este tipo de almacenes. Como se explica en el Capítulo 31, un almacén de datos almacena datos operacionales y puede soportar un amplio rango de consultas, que van desde las muy simples hasta las enormemente complejas. Sin embargo, la capacidad de responder a consultas concretas depende de los tipos de herramientas de acceso que los usuarios puedan utilizar en el almacén de datos. Las herramientas de propósito general, como por ejemplo las de consulta y generación de informes, pueden responder fácilmente a preguntas de tipo' ¿quién?' y '¿qué?' acerca de sucesos pasados. Por el contrario, una consulta típica enviada directamente a un almacén de datos sería del estilo: '¿Cuáles fueron los ingresos totales en Escocia en el tercer trimestre de 2004?'. En esta sección, vamos a centramos en una herramienta que permite soportar consultas más avanzadas; nos referimos a las herramientas de procesamiento analítico en línea (OLAP, Online Analytical Processing) Procesamiento analítico en línea
La síntesis, análisis y consolidación multidimensionales.
dinámicas de grandes volúmenes de datos
(OLAP)
OLAP es un término que describe una tecnología que utiliza una vista multidimensional de datos agregados para proporcionar un rápido acceso a la información estratégica, con el propósito de realizar un análisis avanzado (Codd el al., 1995). OLAP permite a los usuarios comprender mejor diversos aspectos de los datos corporativos, gracias a un acceso rápido, coherente e interactivo a una amplia variedad de posibles vistas de los datos. OLAP permite al usuario ver los datos corporativos de una forma tal que constituye un mejor modelo de la verdadera dimensionalidad de la empresa. Mientras que los sistemas OLAP pueden también responder fácilmente a las preguntas del estilo de '¿quién?' y '¿qué?', es su capacidad para responder las preguntas de tipo' ¿qué pasaría si?' y '¿por qué?' lo que los distingue de las herramientas de consulta de propósito general. OLAP permite tomar decisiones acerca de acciones futuras. Un cálculo OLAP típico puede ser mucho más complejo que de unain~le m~agregación de datos, regiones como pordeejemplo 'Comparar número de inmuebles vendidos por cada tipo en las diferentes Gran Bretaña para elcada año desde 2000'. Por tanto, los tipos de análisis disponibles en las herramientas OLAP van desde las funciones básicas de navegación y de exploración hasta la realización de cálculos y la realización de análisis más complejos, como series temporales y modelados de gran complejidad.
33.1 1 Baterías de prueba OLAP La organización OLAP Council ha publicado una batería de pruebas para procesamiento analítico que se denomina APB-1 (OLAP Council, 1998). El objetivo de APB-1 es medir las prestaciones OLAP globales de un servidor, más que las prestaciones de las tareas individuales. Para garantizar la relevancia de APB-l para las aplicaciones de negocio reales, las operaciones realizadas sobre la base de datos se basan en las operaciones de negocios comunes, que incluyen las siguiente: •
carga masiva de datos desde fuentes de datos internas o externas;
Capítulo 33 OLAP •
carga incremental de datos desde sistemas operacionales;
•
agregación de datos de entrada de acuerdo con determinadas jerarquías;
•
cálculo de nuevos datos basándose en los modelos de negocio;
•
análisis de series temporales;
•
consultas con un alto grado de complejidad;
•
profundización
•
consultas ad hoc;
•
múltiples sesiones en línea.
1091
en las jerarquías;
Las aplicaciones OLAP también se juzgan de acuerdo con su capacidad para proporcionar información just-in-time (lIT), lo cual se considera como un requisito fundamental para el soporte de procesos efectivos de toma de decisiones. Evaluar la capacidad de un servidor para satisfacer este requisito va más allá de la simple medida de la velocidad de procesamiento e incluye la capacidad del servidor para modelar relaciones de negocio complejas y para responder a requisitos de negocio cambiantes. Para permitir la comparación de prestaciones entre diferentes combinaciones de hardware y software, se ha definido una métrica estándar denominada AQM (Analytical Queries per Minute, consultas analíticas por minuto). El valor AQM representa el número de consultas analíticas procesadas por minuto, incluyendo la carga de datos y el tiempo de cálculo. Por tanto, AQM incorpora la velocidad de carga de datos, la velocidad de cálculo y la velocidad de consulta en una única métrica. La publicación de los resultados de aplicar el banco de pruebas APB-l a un sistema debe incluir tanto el esquema de la base de datos como todo el código requerido para ejecutar el banco de pruebas. Esto permite evaluar una solución determinada en términos de su adecuación tanto cualitativa como cuantitativa a una determinada tarea.
33.2 Aplicaciones OLAP Hay numerosos ejemplos de aplicaciones OLAP en diversas áreas funcionales, como se enumera en la Tabla 33.1 (OLAP Council, 2001). "" Un requisito esencial para todas las aplicaciones OLAP es la capacidad de proporcionar a los usuarios información JIT, que es necesaria para tomar decisiones efectivas acerca de las direcciones estratégicas de la organización. La información lIT son datos calculados que usualmente reflejan relaciones complejas y que a menudo se calculan sobre la marcha. El análisis y el modelado de relaciones complejas sólo resultan prácticas si los tiempos de respuesta son siempre suficientemente cortos. Además, como la naturaleza de las relaciones entre los datos puede no ser conocida de antemano, el modelo de datos debe ser flexible. Un modelo de datos verdaderamente flexible garantiza que los sistemas OLAP puedan responder a los requisitos cambiantes del negocio, tal como se necesita para realizar una toma de decisiones efectiva. Aunque podemos encontrar aplicaciones OLAP en áreas funcionales muy distintas, todas ellas requieren las siguientes características clave, como se describe en un informe técnico de OLAP Council (2001): Tabla 33.1.\
---1. ,--/
Ejemplos de aplicaciones
OLAP en diversas áreas funcionales.
Área funcional
Ejemplos de aplicaciones
Finanzas
Presupuestos, desgloses de costes por actividad, análisis de rendimiento financiero y modelado financiero
Ventas
Análisis de ventas y previsiones de ventas
Marketing
Análisis de investigación de mercados, previsiones de ventas, análisis de promociones, análisis de clientes y segmentación de mercados/clientes
Fabricación
Planificación de la producción y análisis de defectos
OLAP
1092
Sistemas de bases de datos
•
vistas multidimensionales
de los datos;
•
soporte para cálculos complejos;
•
inteligencia temporal.
Vistas multidimensionales
de los datos
La capacidad de representar vistas multidimensionales de los datos corporativos es un requisito fundamental para la construcción de un modelo de negocio 'realista'. Por ejemplo, en el caso de DreamHome, los usuarios pueden necesitar ver los datos de ventas de inmuebles clasificados según el tipo de inmueble, según la ubicación del inmueble, según la sucursal, según el vendedor y según el tiempo. Una vista multidimensional de los datos proporciona la base para el procesamiento analítico, al permitir un acceso flexible a los datos corporativos. Además, el diseño de base de datos subyacente que proporciona la vista multidimensional de los datos debe tratar todas las dimensiones de manera equitativa. En otras palabras, el diseño de la base de datos debe: •
no influenciar los tipos de operaciones permitidos sobre una determinada dimensión ni la tasa a la que estas operaciones se realicen;
•
permitir a los usuarios analizar los datos según cualquier dimensión y en cualquier nivel de agregación, manteniendo una misma funcionalidad y facilidad de uso;
•
soportar todas las vistas multidimensionales
de los datos en la forma más intuitiva posible.
Los sistemas aLAP deben ocultar lo más posible a ojos de los usuarios la sintaxis de las consultas complejas y proporcionar unos tiempos de respuesta siempre cortos para todas las consultas, independientemente de su complejidad. La mayoría de pruebas APB-I de aLAP Council permite comprobar la capacidad de un servidor para proporcionar una vista multidimensional de los datos, al incluir consultas de complejidad y ámbito diversos. Un tiempo de respuesta suficientemente corto en todos los casos es una medida fundamental de la capacidad de un servidor para satisfacer este requisito.
Soporte para cálculos complejos El software aLAP debe proporcionar diversos métodos de cálculo suficientemente potentes, como los requeridos para realizar previsiones de ventas, qué utilizan algoritmos de cálculo de tendencias tales como las medias móviles y los crecimientos porcentuales. Además, los mecanismos para implementar métodos de cálculo deben ser claros y no procedimentales. Esto debe permitir a los usuarios de aLAP trabajar de una forma más eficiente y autosuficiente. La batería de pruebas APB-I de aLAP contiene una selección representativa de cálculos, tanto simples (como cálculos de presupuestos) como complejos (como por ejemplo previsiones).
Inteligencia
temporal
La inteligencia temporal es una caraCterística clave de casi todas las aplicaciones analíticas, ya que el comportamiento de una organización siempre suele juzgarse a lo largo del tiempo, por ejemplo comparando el mes actual con el anterior o con el mes correspondiente del año pasado. La jerarquía temporal no siempre se utiliza de la misma fo~
que otras jerarquías. Por ejemplo, un usuario puede pedir las ventas para el mes de
mayo o lascon ventas para lqs primerostales cinco meses 2004. En consecuencia, en un del sistema deben poderse definir facilida~onceptos como losde cálculos acumulados a lo largo año oaLAP las comparaciones de un periodo con otro. La batería de pruebas APB-I de aLAP Council contiene ejemplos del modo en que se utiliza el tiempo en las aplicaciones aLAP, como por ejemplo para el cálculo de medias móviles trimestrales, o para la realización de previsiones, que utiliza comparaciones de los datos de este año con respecto a los del anterior.
33.2.1
Beneficios de OLAP
Los beneficios que pueden derivarse de una adecuada implementación •
de una aplicación aLAP incluyen:
Una mayor productividad de los usuarios finales de la organización, de los desarrolladores de los departamentos de tecnologías de la información y, consecuentemente, de toda la organización. Un
Capítulo 33 OLAP
1093
acceso más controlado y oportuno a la información de carácter estratégico permite realizar un proceso de toma de decisiones más efectivo. •
Una reducción en la carga de trabajo de desarrollo de aplicaciones para el personal de los departamentos de tecnologías de la información, al hacer que los usuarios finales sean lo bastante auto suficientes como para poder realizar sus propios cambios de esquema y construir sus propios modelos.
•
Se conserva el control por parte de la organización de la integridad de los datos corporativos, ya que las aplicaciones OLAP dependen de los almacenes de datos y de los sistemas OLTP para refrescar sus datos de origen.
•
Menor frecuencia de consultas y menor tráfico de red en los sistemas OLTP o en el almacén de datos.
•
Mayores ingresos y beneficios potenciales, al permitir a la organización responder más rápidamente a las demandas del mercado.
33.3 Representación de datos multidimensionales En esta sección, vamos a considerar las distintas formas de representar datos multidimensionales. Por ejemplo, cómo deberíamos representar de la mejor forma posible la consulta' ¿Cuál es el ingreso total generado por ventas de inmuebles en cada ciudad, para cada trimestre de 2004?'. Estos datos de ingresos pueden almacenarse en una tabla relacional formada por tres campos, como se muestra en la Figura 33.1(a). Sin embargo, estos datos encajan de manera mucho más natural en una matriz bidimensional, siendo las dimensiones City y Time (trimestres), como se muestra en la Figura 33.1(b). Lo que diferencia los requisitos para estas representaciones son las consultas que el usuario final pueda realizar. Si el usuario simplemente realiza consultas del estilo de '¿Cuáles fueron los ingresos para Glasgow en el primer trimestre?' y otras consultas que extraen un único valor, no habría ninguna necesidad de estructurar estos datos en una base de datos multidimensional. Sin embargo, si el usuario hace preguntas del estilo de '¿Cuáles son los ingresos anuales totales para cada ciudad?' o '¿Cuáles son los ingresos medios para cada ciudad?', entonces se necesita extraer múltiples valores y agregados. Si consideramos bases de datos "de gran tamaño, compuestas por miles de ciudades, el tiempo que necesitaría un SGBD relacional para realizar este tipo de cálculos resulta significativo. Un SGBDR típico puede explorar unos cuantos centenares de registros por segundo. Un SGBD multidimensional típico puede realizar agregaciones a una velocidad de 10000 por segundo o más. Considere los datos de ingresos con una dimensión adicional, el tipo de inmueble. En este caso, los datos representan los ingresos totales generados por las ventas de cada tipo de inmueble (por simplicidad sólo utilizamos los tipos Flat y House), según la ciudad y según el tiempo (trimestres). De nuevo, estos datos pueden encajar en una tabla de cuatro campos como se muestra en la Figura 33.1(c), pero es más natural representarlos mediante un cubo tridimensional, como se muestra en la Figura 33.1(d). El cubo representa los datos como celdas dentro de una "matriz, asociando los ingresos totales con las dimensiones Property Type, City y Time. La tabla en un SGBDR sólo puede representar los datos multidimensionales en dos dimensiones. Los servidores de base de datos OLAP utilizan estructuras multidimensionales para almacenar los datos y las relaciones existentes entre los mismos. La mejor forma de visualizar las estructuras multidimensionales es como cubos de datos y G.~bosdentro de otros cubos de datos. Cada lado de un cubo es una dimensión. Las bases de datos mujtidimensionales son una forma compacta y fácil de entender para visualizar y manipular elementos de datos que tengan múltiples interrelaciones. El cubo puede expandirse para incluir otra dimensión, como por ejemplo el número de vendedores en cada ciudad. El cubo soporta la aritmética de matrices, lo que permite presentar mediante el cubo los ingresos medios por cada vendedor simplemente realizando una única operación matricial sobre todas las ventas apropiadas del cubo (Ingreso medio por vendedor = Ingreso total/Número de vendedores). El tiempo de respuesta de una consulta multidimensional depende de cuántas celdas tengan que sumarse sobre la marcha. A medida que se incrementa el número de dimensiones, el número de celdas del cubo se incrementa también exponencialmente. Sin embargo, la mayoría de las consultas multidimensionales tratan con datos resumidos de alto nivel. Por tanto, la solución para construir una base de datos multidimensional eficiente consiste en pre-agregar (consolidar) todos los totales y subtotales lógicos según todas las dimensio-
1094
City Revenue
..en nw ow gow
Sistemas de bases de datos ........ ........ 45632 31390 50056 45677 34567 53210 56222 48244 43555 30582 30443 29726 Time Total Q4 Q3 Q2 Ql Q4 Q3 Q2 Ql Q4 Q3 Q2 Ql
..
City ............. ............. 45632 50056 56222 45677 48244 34567 31390 30582 Aberdeen London 30443 43555 29726 53210 Glasgow
Quarter
~
Ql
Q4 Q3 Q2
(a)
(b)
........ ...... ........ ....... 14670 15056 14555 15888 14578 16004 28677 15500 19678 15890 19567 London Property 23877 Time Total London Q2 Q3City Q2 Ql Q4 Glasgow Glasgow
Revenue
i
"" oo :r: 6:: OJ
E €
OJ
••
1
¡i; :s
Q3 Q2 Q4
OJ
~
Time
'"'
Ql
(e)
Figura 33.1.
Datos~tidimensionales
vistos en: (a) una tabla de tres campos;
(b) una m~idimensional; (e) una tabla de cuatro campos; (d) un cubo tridimensional. nes. Esta pre-agregación puede ser especialmente valiosa, ya que las dimensiones típicas son de naturaleza jerárquica. Por ejemplo, la dimensión temporal puede contener jerarquías para los años, trimestres, meses, semanas y días, y la dimensión de la ubicación puede contener una jerarquía formada por las sucursales, las áreas, las ciudades y el país. Imponer la jerarquía predefinida dentro de cada dimensión permite la pre-agregación lógica y, a la inversa, permite una 'profundización' lógica; por ejemplo, a partir de los ingresos anuales, podemos pasar a consultar los ingresos trimestrales y luego los ingresos mensuales. La tecnología OLAP multidimensional soporta las operaciones analíticas comunes, como por ejemplo la consolidación, la profundización y la navegación.
Capítulo 33 OLAP
1095
•
La consolidación implica la agregación de datos, como por ejemplo totalizaciones simples o expresiones complejas que impliquen datos interrelacionados. Por ejemplo, pueden totalizarse los datos de las sucursales según la ciudad y los datos de las ciudades según el país.
•
La profundización es la operación inversa de la consolidación, e implica mostrar los datos de detalle comprendidos en los datos consolidados.
•
La navegación (también denominada pivotaje) hace referencia a la capacidad de examinar los datos desde diferentes puntos de vista. Por ejemplo, una parte de los datos de ingresos puede mostrar los ingresos generados por cada tipo de inmueble dentro de las distintas ciudades. Otra parte puede mostrar todos los ingresos generados por cada sucursal dentro de cada ciudad. Las técnicas de pivotaje se realizan a menudo a lo largo de un eje temporal, con el fin de analizar tendencias y encontrar patrones.
Los servidores OLAP multidimensionales tienen la capacidad de almacenar datos multidimensionales en forma comprimida. Esto se lleva a cabo seleccionando dinámicamente la organización del almacenamiento físico y las técnicas de compresión que permitan maximizar la utilización del espacio. Los datos densos, es decir, datos que existan para un alto porcentaje de las celdas) pueden almacenarse independientemente de los datos dispersos (es decir, aquellos en los que un porcentaje significativo de las celdas están vacías). Por ejemplo, ciertas sucursales pueden vender únicamente tipos concretos de inmuebles, por lo que un cierto porcentaje de las celdas que relacionan el tipo de inmueble con la sucursal pueden estar vacías, con lo que tendremos datos dispersos. Otro tipo de datos dispersos aparecen cuando muchas celdas contienen datos duplicados. Por ejemplo cuando haya un gran número de sucursales en cada una de las principales ciudades del país, las celdas que almacenan los valores city estarán duplicadas muchas veces. La capacidad de un SGBD multidimensional para omitir las celdas vacías o repetitivas contribuye enormemente a reducir el tamaño del cubo y la cantidad de procesamiento. Optimizando la utilización del espacio, los servidores OLAP pueden minimizar las necesidades de almacenamiento físico, haciendo así posible el análisis de cantidades enormemente grandes de datos. También permite cargar más datos en la memoria de la computadora, lo que ayuda a incrementar significativamente las prestaciones, al minimizarse las operaciones de E/S de disco. En resumen, la pre-agregación, la jerarquización de las dimensiones y la gestión de los datos dispersos pueden reducir significativamente el tamaño de la base de datos y las necesidades de calcular valores. Este tipo de diseño elimina la necesidad de efectuar combinaciones multitabla y proporciona un acceso rápido y directo a matrices de datos, acelerando así significativamente la ejecución de las consultas multidimensionales. Aunque los argumentos a favor de la utilización de servidores OLAP especializados son bastante convincentes, en la siguiente sección vamos a describir también cómo satisfacen los sistemas de bases de datos re lacionales las demandas de OLAP.
33.4 Herrélmientas OLAP Hay disponibles muchos tipos de herramientas OLAP en el mercado. Esta diversidad ha dado como resultado una cierta confusión, existiendo un considerable debate sobre lo que significa en realidad el término OLAP para un comprador potencial, y en particular sobre cuáles son las arquitecturas disponibles para las herramientas OLAP. En esta sección vamos a describir en primer lugar las reglas genéricas aplicables a las herramientas OLAP, siIL¡:¿cer referencia a ninguna arquitectura concreta, y luego veremos las características, arquitecturas y cuestiones más importantes asociadas con cada una de las cuatro categorías principales de herramientas OLAP comerciales.
33.4.1
Reglas de Codd para las herramientas OLAP
En 1993, E.F. Codd formuló doce reglas como base para la selección de herramientas OLAP. La publicación de estas reglas fue el resultado de una investigación realizada por cuenta de Arbor Software (los creadores de Essbase) y permitió una redefinición formalizada de los requisitos relativos a las herramientas OLAP. Las Reglas de Codd para las herramientas OLAP se enumeran en la Tabla 33.2 (Codd el al., 1993).
1096
Sistemas de bases de datos
Tabla 33.2.
Reglas de Codd para las herramientas
l.
Vista conceptual multidimensional
2.
Transparencia
3.
Accesibilidad
4.
Prestaciones coherentes en la generación de informes
5.
Arquitectura cliente-servidor
6.
Dimensionalidad
7.
Gestión dinámica de matrices dispersas
8.
Soporte multi-usuario
9.
Operaciones
OLAP.
genérica
interdimensionales
no restringidas
lO.
Manipulación de datos intuitiva
11.
Generación flexible de informes
12.
Dimensiones y niveles de agregación ilimitados
(1) Vista conceptual multidimensional Las herramientas OLAP deben proporcionar a los usuarios un modelo multidimensional que se corresponda con las vistas que los usuarios tengan de la empresa, y que sea intuitivamente analítico y fácil de usar. Resulta interesante observar que esta regla es soportada en diferente grado por varios fabricantes de herramientas OLAP, que argumentan que puede proporcionarse una vista conceptual multidimensional de los datos sin utilizar un almacenamiento multidimensional.
(2) Transparencia La tecnología OLAP, la arquitectura y la base de datos subyacente, y la posible heterogeneidad de las fuentes de datos de entrada pueden ser transparentes a10s usuarios. Este requisito se debe a que es necesario preservar la productividad del usuario empleando herramientas y entornas de interfaz que le resulten familiares.
(3) Accesibilidad La herramienta OLAP debe poder acceder a los datos requeridos para el análisis desde múltiples orígenes de datos empresariales heterogéneos, como por ejemplo sistemas relacionales, no relacionales y heredados.
(4) Prestaciones coherentes en la generación de informes A medida que se incrementan el número de dimensiones, los niveles de agregación y el tamaño de la base de datos, los usuarios no deben percibir ninguna degradación significativa en el rendimiento. No debe haber ninguna alteración en la forma de calcular los principales valores de rendimiento. Los modelos del sistema deben ser lo suficientemente robustos como pa~der
(5) Arquitectura cliente-servidor
adaptarse a los cambios en el modelo empresarial.
El sistema OLAP debe ser capaz de operar de manera eficiente en un entorno cliente-servidor. La arquitectura debe proporcionar unas prestaciones, una flexibilidad, una adaptabilidad, una escalabilidad y una interoperabilidad óptimas.
(6) Oimensionalidad genérica Todas las dimensiones de datos deben ser equivalentes tanto en su estructura como en las capacidades de operación. En otras palabras, la estructura básica, las fórmulas y las capacidades de generación de informes no deben estar sesgadas hacia ninguna dimensión concreta.
Capítulo 33 OLAP (7) Gestión
dinámica
de matrices
1097
dispersas
El sistema OLAP debe poder adaptar su esquema físico al modelo analítico específico que optimice la gestión de matrices dispersas, con el fin de conseguir y mantener el nivel de prestaciones requerido. Los modelos multidimensionales típicos pueden contener fácilmente millones de referencias de celdas, muchas de las cuales no tendrán datos apropiados en determinados instantes temporales. Estos valores nulos deben almacenarse de una manera eficiente y no afectar de forma adversa ni a la precisión ni a la velocidad del acceso a los datos. (8) Soporte
multiusuario
El sistema OLAP debe poder soportar grupos de usuarios trabajando concurrentemente lo de los datos de la empresa, o sobre modelos distintos. (9) Operaciones
interdimensionales
sobre el mismo mode-
no restringidas
El sistema OLAP debe poder reconocer las jerarquías de las dimensiones y realizar automáticamente culos de totalización asociados dentro de una dimensión y entre diversas dimensiones.
(10) Manipulación
los cál-
de datos intuitiva
El pivotaje, la profundización y la consolidación, así como otras manipulaciones, deben realizarse mediante acciones de tipo 'apuntar y hacer clic' y 'arrastrar y soltar' sobre las celdas del cubo. ( 11) Generación
flexible
de informes
Debe existir la capacidad de disponer las filas, las columnas y las celdas de modo tal que se facilite el análisis mediante una presentación visual intuitiva de los informes analíticos. Los usuarios deben poder establecer cualquier vista de los datos que necesiten. (12)
Dimensiones
y niveles de agregación
ilimitados
Dependiendo de los requisitos de la organización, un modelo analítico puede tener numerosas dimensiones, cada una de las cuales puede disponer de múltiples jerarquías. El sistema OLAP no debe imponer ninguna restricción artificial sobre el número de dimensiones ni sobre los niveles de agregación. Desde la publicación de las Reglas de Codd para OLAP, se han realizado muchas propuestas para redefinir o ampliar estas reglas. Por ejemplo, algunas propuestas afirman que además de las doce reglas, las herramientas OLAP comerciales también deberían incluir herramientas suficientemente completas de gestión de la base de datos, la capacidad de profundizar hasta el nivel de detalle (nivel de registro), mecanismos de refresco incremental de la base de datos y una interfaz SQL con el entorno corporativo existente. El lector interesado en consultar una explicación sobre las reglas/características de OLAP que han sido propuestas después de la publicación inicial en 1993 de Codd, puede consultar Thomsen (1997) y Pendse (2000).
33.4.2
C~gOríaS
de herramientas OLAP
Las herramientas OLAP puede clasificarse de acuerdo con la arquitectura utilizada para almacenar y procesar los datos multidimensionales. Hay cuatro categorías principales de herramientas OLAP, según las definen Berson y Smith (1997) y Pendse y Creeth (2001), que son: •
OLAP multidimensional
(MOLAP);
•
OLAP relacional (ROLAP);
•
OLAP híbrido (HOLAP);
•
OLAP de escritorio (DOLAP, Desktop OLAP).
1098
Sistemas de bases de datos
OLAP multidimensional
(MOLAP)
Las herramientas MOLAP utilizan estructuras de datos especializadas y sistemas de gestión de bases de datos multidimensionales para organizar, navegar y analizar los datos. Para mejorar la velocidad de las consultas, los datos se suelen agregar y almacenar de acuerdo con el uso esperado. Las estructuras de datos MOLAP utilizan tecnología matricial y técnicas eficientes de almacenamiento que minimizan las necesidades de espacio de disco, gracias a la gestión de los datos dispersos. Las herramientas MOLAP proporcionan unas excelentes prestaciones cuando los datos se utilizan de la forma prevista, y se suelen centrar en datos para una aplicación específica de ayuda a la toma de decisiones. Tradicionalmente, las herramientas MOLAP requieren un fuerte acoplamiento del nivel de aplicación y del nivel de presentación. Sin embargo, recientemente se está tendiendo a segregar la herramienta OLAP de las estructuras de datos, mediante el uso de interfaces de programación de aplicaciones publicadas. La arquitectura típica de las herramientas MOLAP se muestra en la Figura 33.2. Los principales problemas de desarrollo asociados con las herramientas MOLAP son los siguientes: •
•
•
Sólo pueden almacenarse y analizarse de manera eficiente una cantidad limitada de datos. Las estructuras de datos subyacentes están limitadas en cuanto su capacidad para soportar múltiples temas y para proporcionar acceso a datos detallados (algunos productos resuelven este problema utilizando mecanismos que permiten a las herramientas MOLAP acceder a datos de detalle mantenidos en un SGBDR). La navegación y el análisis de los datos están limitados, porque los datos se diseñan de acuerdo con requisitos previamente determinados. Para soportar de modo óptimo nuevos requisitos, puede ser necesario reorganizar fisicamente los datos. Los productos MOLAP requieren un conjunto diferente de capacidades y herramientas para construir y mantener la base de datos, incrementándose así el coste y la complejidad de las tareas de soporte.
OLAP relacional (ROLAP) Las herramientas de OLAP relacional (ROLAP) son las que más rápidamente se están extendiendo. Este crecimiento se debe a la demanda de los usuarios para analizar cantidades crecientes de datos y debido a que resulta patente que los usuarios no pueden almacenar todos los datos necesarios en bases de datos MOLAP. Las herramientas ROLAP soportan los productOs SGBDR mediante el uso de un nivel de metadatos, evitando así la necesidad de crear una estructura de datos multidimensional estática. Esto facilita la creación de múltiples vistas multidimensionales de la relación bidimensional. Para mejorar las prestaciones, algunos productos ROLAP disponen de motores SQL mejorados para soportar la complejidad del análisis multidimensional, mientras que otros productos recomiendan, o incluso requieren, la utilización de diseños de bases de datos altamente des-normalizados, como el esquema en estrella (véase la Sección 32.2). La arquitectura típica de las herramientas ROLAP se muestra en la Figura 33.3. Los problemas de desarrollo asociados con la tecnología ROLAP son: •
Problemas de rendimiento asociados con el procesamiento de consultas complejas que requieran efectuar múltiples pasadas a través de los datos relacionales.
Servidor de base d~
Servidor MOLAP
Herramientas de acceso de usuario final
sistemas datos relaci<6'nal her'eEla€!ós Y/9
-..--------
------~.-L1J
Conjunto de resulta!os Solicitud de datos
Carga
Figura 33.2.
Arquitectura
para las herramientas
MOLAP.
Capítulo 33 OLAP Servidor de base de datos relacional
1099
Herramientas de acceso de usuario final
Servidor ROLAP
SOL
••
•
•
Conjunto de resultados SoliCitud de datos
Conjunto de resultados •••
Figura 33.3.
Arquitectura
de las herramientas
ROLAP.
•
Desarrollo de middleware para facilitar el desarrollo de aplicaciones multidimensionales, ware que convierta la relación bidimensional en una estructura multidimensional.
•
Desarrollo de una opción para crear estructuras multidimensionales nes para ayudar en la administración de estas estructuras.
es decir, soft-
persistentes, junto con las funcio-
OLAP híbrido (HOLAP) Las herramientas OLAP híbrido (HOLAP) proporcionan capacidades limitadas de análisis, bien directamente sobre productos SGBDR o bien utilizando un servidor MOLAP intermedio. Las herramientas HOLAP suministran a la máquina de escritorio los datos seleccionados directamente desde el SGBD o a través de un servidor MOLAP (o un servidor local) en la forma de un cubo de datos, el cual se almacena, analiza y mantiene localmente. Los fabricantes promueven esta tecnología como relativamente fácil de instalar y de administrar, con un coste y un mantenimiento reducidos. La arquitectura típica de las herramientas HOLAP se muestra en la Figura 33.4. Los problemas asociados con las herramientas HOLAP son los siguientes: •
La arquitectura provoca_una significativa redundancia de los datos y puede causar problemas en las redes que soporten muchos usuarios.
•
La capacidad de cada usuario para construir un cubo de datos personalizado puede provocar una falta de coherencia entre los datos de los diferentes usuarios.
•
Sólo puede mantenerse de manera eficiente una cantidad limitada de datos.
OLAP de escritorio (DOLAP) Un tipo cada vez más popular de herramientas OLAP es la tecnología denominada OLAP de escritorio (DOLAP, Desktop OLAP). Las herramientas DOLAP almacenan los datos OLAP en archivos situados en la Herramientas de acceso de usuario final
Servidor de base de datos relacional SOL
..
Conjunto de resultados Servidor MOLAP
••
Solicitud de datos
•
Conjunto de resultados
Figura 33.4.
Arquitectura
para las herramientas
HOLAP.
1100
Sistemas de bases de datos DOlAP
Servidor de base de datos relacional
la distribución de los datos OlAP desde una base de datos relacional o desde un servidor MOlAP hasta el pe de escritorio o portátil se realiza utilizando correo electrónico, la Web o una arquitectura tradicional cliente-servidor.
Figura 33.5.
Arquitectura
para las herramientas
DOLAP.
plataforma del cliente y soportan el procesamiento multidimensional utilizando un motor multidimensional del lado del cliente. DOLAP requiere que se almacenen en las máquinas cliente extractos relativamente pequeños de los datos. Estos datos pueden distribuirse por adelantado o bajo petición (posiblemente a través de la Web). Al igual que sucede con las bases de datos multidimensionales en el servidor, los datos DOLAP pueden mantenerse en disco o en la memoria RAM; sin embargo, algunos productos DOLAP sólo permiten acceso de lectura. La mayoría de los fabricantes de productos DOLAP aprovechan la potencia de los PC de escritorio para realizar algunos de los cálculos multidimensionales, o en ocasiones todos los cálculos. La administración de una base de datos DOLAP se realiza normalmente mediante una rutina de procesamiento o servidor centralizado que prepara los cubos de datos o los conjuntos de datos para cada usuario. Una vez realizado el procesamiento básico, cada usuario puede acceder a su parte de los datos. La arquitectura típica de las herramientas DOLAP se muestra en la Figura 33.5. Los problemas de desarrollo asociados con DOLAP son: • La provisión de controles de seguridad apropiados para soportar todas las partes del entorno DOLAP. Puesto que los datos se extraen físicamente del sistema, la seguridad suele implementarse limitando la información que se compila en cada cubo. Una vez cargado cada cubo en la máquina de escritorio del usuario, todos los metadatos adicionales pasan a ser propiedad del usuario local. • Hace falta reducir el esfuerzo necesario para implantar y mantener las herramientas DOLAP. Algunos fabricantes de productos DOLAP proporcionan ahora diversas formas alternativas para implantar los datos OLAP, como por ejemplo a través de correo electrónico, de la Web o utilizando una arquitectura tradicional cliente-servidor. •
Las te~ias
actuales apuntan hacia la utilización de máquinas cliente simples.
33.5 Extensiones OlAP al estándar SQl En los Capítulos 5 y 6 hemos visto que las ventajas de SQL son que se trata de un lenguaje fácil de aprender, no procedimental, de formato libre, independiente del SGBD y que está aceptado como un estándar interna-
Capítulo 33 OLAP
1101
cional. Sin embargo, una de las principales limitaciones de SQL para los analistas empresariales es la dificultad de utilizar dicho lenguaje para responder a consultas muy habituales en los entorno s empresariales, como por ejemplo calcular el porcentaje de cambio en una serie de valores entre el mes actual y el mes correspondiente del año anterior, o calcular una serie de medias móviles, sumas acumulativas y otras funciones estadísticas. Como respuesta a esta limitación, ANSI ha adoptado un conjunto de funciones OLAP como extensión a SQL que permitirán realizar estos cálculos y muchos otros que antes eran poco prácticos o incluso imposibles de realizar desde SQL. IBM y Oracle propusieron conjuntamente estas extensiones a principios de 1999 y ahora forman parte del estándar SQL actual, SQL:2003. Dichas extensiones se denominan colectivamente 'paquete OLAP' e incluyen las siguientes características del lenguaje SQL, tal como se especifica en el anexo de taxonomía de características de SQL de las distintas partes de ISO/IEC 9075-2 (ISO, 2003a): • Característica T43l, 'Capacidades de agrupación ampliadas'; •
Característica T611, 'Operadores OLAP ampliados'.
En esta sección vamos a analizar las capacidades de agrupación ampliadas del paquete OLAP proporcionando dos ejemplos de funciones que forman parte de esta característica: ROLLUP y CUBE. Después hablaremos de los operadores OLAP ampliados incluidos en el paquete OLAP, proporcionando otros dos ejemplos de funciones que forman parte de dicha característica: la función de creación de clasificaciones ordenadas y las agregaciones de ventana móvil. Para ilustrar más fácilmente la utilidad de estas funciones OLAP, es necesario utilizar ejemplos tomados de una versión ampliada del caso de estudio de DreamHome. Para obtener detalles completos sobre el paquete OLAP del estándar SQL actual, el lector interesado puede consultar el sitio web de ANSI, en www.ansi.org.
33.5.1
Capacidades de agrupación ampliadas
La agregación constituye una parte fundamental de OLAP. Para mejorar las capacidades de agregación, el estándar SQL proporciona extensiones a la cláusula GROUP BY tales como las funciones ROLLUP y CUBE. ROLLUP permite realizar cálculos utilizando agregación del tipo de SUM, COUNT, MAX, MIN y AVG con niveles crecientes de agregación, desde el más detallado hasta un total general. CUBE es similar a ROLLUP, pero permite calcular mediante una única instrucción todas las posibles combinaciones de agregaciones. CUBE puede generar la información necesaria en informes de tablas cruzadas, utilizando una única consulta. Las extensiones ROLLUP y CUBE especifican exactamente las agrupaciones de interés en la cláusula GROUP BY y producen un único conjunto de resultados que es equivalente a una operación UNION ALL de diferentes filas agrupadas. En las siguientes secciones vamos a describir e ilustrar las funciones de agrupación ROLLUP y CUBE con mayor detalle.
Extensión ROLLUP a GROUP BY ROLLUP permite calcular mediante una instrucción SELECT múltiples niveles de subtotales según un grupo especificado de dimensiones. ROLLUP aparece en la cláusula GROUP BY de la instrucción SELECT utilizando el siguiente formato: SELECT ... GROUP BY ROLLUP(listaColumnas) ROLLUP crea subtotales que van desde el nivel más detallado hasta un total general, según una lista de columnas especificaga en la cláusula ROLLUP. ROLLUP calcula primero los valores agregados estándar especificados en la clá~a GROUP BY y luego crea subtotales de nivel progresivamente más alto, desplazándose a través de la li~ de columnas hasta que finalmente se calcula el total general. ROLLUP crea subtotales de n + 1 niveles, donde n es el número de columnas de agrupación. Por ejemplo, si una consulta especifica ROLLUP sobre las columnas de agrupación propertyType,yearMonthy city (n = 3), el conjunto de resultados incluirá filas con cuatro niveles de agregación. Vamos a demostrar la utilidad de ROLLUP en el siguiente ejemplo.
1102
I
Sistemas de bases de datos
Ejemplo
33.1
Utilización
de la función
de agrupación
ROLLUP
Mostrar los totales de las ventas de apartamentos o viviendas unifamiliares para las distintas sucursales ubicadas en Aberdeen, Edimburgo o Glasgow y para los meses de septiembre y octubre de 2004. En este ejemplo, tenemos primero que identificar las sucursales ubicadas en las ciudades de Aberdeen, Edimburgo y Glasgow y luego sumar las ventas totales de apartamentos y viviendas unifamiliares en cada una de estas oficinas y para cada una de las ciudades, para los meses de septiembre y octubre de 2004. Para responder a esta consulta, debemos ampliar el caso de estudio de DreamHome para incluir una nueva tabla denominada PropertySale, que tiene cuatro atributos, branchNo, propertyNo, yearMonth y saleAmount. Esta tabla representa la venta de cada inmueble en cada sucursal. Esta consulta también requiere acceder a las tablas Branchy PropertyForSale que hemos descrito anteriormente en la Figura 3.3. Observe que tanto la tabla Branch como PropertyForSale tienen una columna denominada city. Para simplificar este ejemplo y los otros que veremos a continuación, vamos a cambiar el nombre de la columna city de la tabla PropertyForRent y la llamaremos pcity.El formato de la consulta utilizando la función ROLLUP es: SELECT propertyType,yearMonth,city,SUM (saleAmount)AS sales FROM Branch, PropertyForSale. PropertySale WHERE Branch.branchNo = PropertySale.branchNo AND PropertyForSale.propertyNo= PropertySale.propertyNo AND PropertySale.yearMonthIN ('2004-08', '2004-09') AND Branch.cityIN ('Aberdeen', 'Edimburgo', 'Glasgow') GROUP BY ROLLUP(propertyType, yearMonth, city); 76321 135670 Aberdeen 236573 115432 8755 de resultados para el455635 2004-09 123780 166503 4765 4889 218422 247713 77987 7664 2004-08 323100 sales 359669 G1asgow Edimburgo yearMonth Glasgow Tabla 33.3. Tabla Ejemplo 33.1. city propertyType
1281439
466135 815304
Capítulo 33 OLAP
1103
La salida de esta consulta se muestra en la Tabla 33.3. Observe que los resultados no siempre se suman para dar el valor correcto, debido al redondeo. Esta consulta devuelve los siguientes conjuntos de filas: •
Filas normales de agregación, que son las que se habrían producido mediante la cláusula GROUP BY sin utilizar ROLLUP.
•
Subtotales de primer nivel, que realizan la agregación según el valor de city, para cada combinación de propertyTypey yearMonth.
•
Subtotales de segundo nivel que realiza la agregación según el valor yearMonthy citypara cada valor de propertyType.
•
Una fila con el total general.
~
Extensión CUBE para GROUP BY CUBE toma un conjunto especificado de columnas de agrupamiento y crea subtotales para todas las posibles combinaciones. CUBE aparece en la cláusula GROUP BY de una instrucción SELECT utilizando el siguiente formato: SELECT ... GROUP BY CUBE(listaColumna) En términos del análisis multidimensional, CUBE genera todos los subtotales que podrían calcularse para un cubo de datos que tuviera las dimensiones especificadas. Por ejemplo, si especificáramos CUBE(propertyType, yearMonth, city), el conjunto de resultados incluiría todos los valores incluidos en una instrucción ROLLUP equivalente más otras combinaciones adicionales. Por ejemplo, en el Ejemplo 33.1, los totales para cada valor de city en donde se combinen los distintos tipos de inmueble no son calculados por una cláusula ROLLUP(propertyType, yearMonth, city), pero sí que lo son por una cláusula CUBE(propertyType, yearMonth, city). Si se especifican n columnas para una cláusula CUBE, se devolverán 2" combinaciones de subtotales. El Ejemplo 33.1 constituye un caso de cubo tridimensional.
Cuando utilizar CUBE CUBE puede usarse en cualquier situación donde hagan falta informes de tablas cruzadas. Los datos necesarios para esos informes de tablas cruzadas pueden generarse mediante una única instrucción SELECT utilizando la cláusula CUBE. Al igual que ROLLUP, CUBE puede resultar muy útil para generar tablas de resumen. CUBE es especialmente adecuado en aquellas consultas que utilicen columnas de múltiples dimensiones, en lugar de columnas que representen diferentes niveles de una misma dirección. Por ejemplo, una tabla cruzada comúnmente solicitada puede necesitar que se calculen subtotales para todas las combinaciones de propertyType, yearMonthy city. Hay tres dimensiones independientes y el análisis de todas las posibles combinaciones de subtotales resulta bastante común. Por contraste, una tabla cruzada que muestre todas las posibles combinaciones de year, month y day tendrían muchos valores poco interesantes, porque existe una jerarquía natural en la dimensión time. Vamos a ilustrar la utilidad de la función CUBE en el siguiente ejemplo.
I
Ejemplo 33.2 Utilización de la función de agrupamiento CUSE Mostrar todos los posibles subtotales para las ventas de inmuebles de cada sucursal de Aberdeen, Edimburgo y Glasgow, para los meses de septiembre y octubre de 2004. Sustituimos la función ROLLUP mostrada en la consulta SQL del Ejemplo 33.1 por la función CUBE. El formato de esta consulta sería: SELECT propertyType,yearMonth,city,SUM (saleAmount)AS sales FROM Branch, PropertyForSale, PropertySale
1104
.". 2004-09 236573 323100 123780 115432 154308 77987 76321 4765 4889 7664 8755 9654 sales Sistemas Aberdeen de bases 2004-08 Aberdeen 302173 372243 200101 489603 861846 393520 559673 135670 166503 193419 26073 12429 13644 de datos 239212 16419 Glasgow Edimburgo yearMonth city
359669 455635 247713 218422 578091 Aberdeen 703348 Glasgow Edimburgo
1281439 PropertyForSale.propertyNo = PropertySale.propertyNo AND PropertySale.yearMonth IN ('2004-08', GROUP BY CUBE (propertyType, yearMonth,'2004-09') city); Branch.city IN ('Aberdeen', 'Edimburgo', 'Glasgow')
tyTypeLa salida se muestra en la Tabla Tabla 33.4. 33.4. Tabla de resultados para el Ejemplo 33.2. WHERE Branch.branchNo = PropertySale.branchNo
466135 815304
Capítulo 33 OLAP 1105 Las filas mostradas en negrita son las filas que tienen en común las tablas de resultados producidas por las funciones ROLLUP (véase la Tabla 33.3) y CUBE. Sin embargo, la cláusula CUBE(propertyType, yearMonth, city) donde n = 3, produce 23 = 8 niveles de agregación, mientras que en el Ejemplo 33.1, la cláusula ROLLUP(propertyType, yearMonth, city), donde n = 3, produce Únicamente 3 + 1 = 4 niveles de agregación.
33.5.2 Operadores OLAP elementales Los operadores OLAP elementales del paquete OLAP del estándar SQL soportan diversas operaciones, como por ejemplo la de generación de clasificaciones ordenadas y cálculos de ventana deslizante. Las funciones de clasificación ordenada incluyen distribuciones acumulativas, clasificaciones segÚn rangos porcentuales y los denominados N-mosaicos. Las funciones de ventana deslizante permiten calcular agregaciones acumulativas y móviles utilizando funciones tales como SUM, AYG, MIN Y COUNT. En las siguientes secciones vamos a describir e ilustrar los cálculos de clasificaciones ordenadas de ventanas móviles con mayor detalle.
Funciones de clasificación
ordenada
Una función de clasificación ordenada calcula la posición de un registro en relación con los restantes registros del conjunto de datos, basándose en los valores de un conjunto de medidas. Hay distintos tipos de funciones de clasificación ordenada, incluyendo RANK y DENSE_RANK. La sintaxis de cada una de estas funcIOnes es: RANK() OYER (ORDER BY listaColumna) DENSE_RANK() OYER (ORDER BY IistaColumna) La sintaxis que se muestra es incompleta, pero se muestra suficiente para explicar e ilustrar la utilidad de estas funciones. La diferencia entre RANK y DENSE_RANK es que DENSE_RANK no deja ningún hueco en la secuencia de clasificacióu. cuando existen empates para un cierto puesto. Por ejemplo, si tres sucursales empatan por el segundo lugar en términos de las ventas totales de inmuebles, DENSE_RANK identificará las tres sucursales en ese segundo lugar, situando la siguiente sucursal en tercer lugar. La función RANK también identifica las tres sucursales en segundo lugar, pero la siguiente sucursal estará en quinto lugar. Yamos a ilustrar la utilidad de las funciones RANK y DENSE_RANK en el siguiente ejemplo.
I
Ejemplo 33.3 Utilización
de las funciones
RANK y DENSE_RANK
Realizar una clasificación ordenada de las ventas totales de inmuebles para las distintas sucursales de Edimburgo. Primero calculamos las ventas totales de inmuebles en cada sucursal en Edimburgo y luego clasificamos los resultados. Esta consulta accede a las tablas Branch y PropertySale. Ahora vamos a ilustrar la diferencia entre las funciones RANK y DENSE_RANK mediante la siguiente consulta: SELECT branchNo, SUM(saleAmount) AS sales, RANKO OVER (ORDER BY SUM(saleAmount)) DESC AS ranking, DENSE_RANKO OVER (ORDER BY SUM(saleAmount)) DESC AS dense_ranking FROM Branch, PropertySale WHERE Branch.branchNo = PropertySale.branchNo AND Branch.city = 'Edimburgo' GROUP BY(branchNo); La salida se muestra en la Tabla 33.5.
1106
Sistemas de bases de datos Tabla 33.5. Tabla de resultados para el Ejemplo 33.3. branchNo
265 1ranking 4213 sales 120.000,000 92.000,000 45.000,000 42.000,000 dense_ranking
Cálculos de ventana móvil Los cálculos de ventana móvil pueden utilizarse para calcular agregados acumulativos, móviles y centrados. Se devuelve un valor para cada fila de una tabla, valor que dependerá de otras filas dentro de la correspondiente ventana. Por ejemplo, el mecanismo de ventana deslizante permite calcular sumas acumulativas, sumas móviles, medias móviles, valores min/máx móviles y otras medidas estadísticas. Estas funciones de agregación proporcionan acceso a más de una fila de una tabla sin necesidad de efectuar una autocombinación y sólo pueden usarse en las cláusulas SELECT y aRDER BY de la consulta. Vamos a ilustrar en el siguiente ejemplo cómo puede utilizarse el mecanismo de ventanas móviles para generar sumas y promedios móviles.
I
Ejemplo 33.4 Utilización de cálculos de ventana móvil Mostrar las ventas mensuales y las sumas y medias móviles trimestrales para las ventas de inmuebles en la sucursal B003, durante los primeros.,seis meses de 2004. Primero sumamos las ventas de inmuebles para cada uno de los seis primeros meses de 2004 en la sucursal B003, y luego utilizamos estos valores para determinar las medias móviles trimestrales y las sumas móviles trimestrales. En otras palabras, calculamos la media móvil y la suma móvil para las ventas de inmuebles en la sucursal B003 para el mes actual y para los dos meses anteriores. Esta consulta accede a la tabla PropertySale. Vamos a ilustrar la creación de una ventana móvil trimestral utilizando la función ROWS 2 PRECEDING en la siguiente consulta: SELECT yearMonth, SUM(saleAmount) AS monthlySales, AVG(SUM(saleAmount)) OVER (ORDER BY yearMonth,ROWS 2 PRECEDING) AS 3-month movingavg, SUM(SUM(salesAmount)) OVER (ORDER BY yearMonth ROWS 2 PRECEDING) AS 3-month movingsum FROM PropertySale WHERE branchNo = 'B003' AND yearMonthBETWEEN GROUP BY yearMonth ORDER BY yearMonth;
('2004-01' AND '2004-06')
La salida se muestra en la Tabla 33.6. Observe que las primeras dos filas de los cálculos de la suma y la media móviles trimestrales en la tabla de resultados están basados en un tamaño de intervalo más pequeño del especificado, porque los cálculos de ventana móvil no pueden ir más atrás que los datos extraídos por la consulta. Por tanto, es necesario considerar los diferentes tamaños de ventana que se utilizan en los bordes de los conjuntos
Capítulo 33 OLAP
1107
de resultados. En otras palabras, puede que necesitemos modificar la consulta para incluir exactamente lo que queremos. Tabla 33.6.
Tabla de resultados para el Ejemplo 33.4.
yearMonth
monthlySales
3-Month Moving Avg
2004-01
210000
210000
210000
2004-02
350000
280000
560000
2004-03
400000
320000
960000
2004-04
420000
390000
1170000
2004-05
440000
420000
1260000
2004-06
430000
430000
1290000
3-Month Moving Sum
Oracle juega un importante papel en el desarrollo y mejora continuados del estándar SQL. De hecho, muchas de las nuevas características OLAP de SQL:2003 ya eran soportadas por Oracle desde la versión 8/8i. En la siguiente sección, vamos a describir brevemente el soporte para OLAP que Oraele9i proporciona.
33.6 Aplicaciones OLAP en Oracle En los grandes entorno s de almacén de datos, pueden realizarse muchos tipos de análisis como parte de la construcción de una plataforma para soportar sistemas de inteligencia empresarial. Además de las consultas SQL tradicionales, los usuarios necesitan realizar operaciones analíticas más avanzadas con los datos. Dos de los tipos principales de análisis son el procesamiento analítico en línea (OLAP, Online Analytical Processing) y la minería de datos. Esta sección describe la manera en que Oracle proporciona la tecnología OLAP como uno de los componentes más ilJ;!portantes de su plataforma de inteligencia empresarial (Oraele Corporation, 2004h, i). En el siguiente capítulo describiremos el modo en que Oracle soporta las técnicas de minería de datos.
33.6.1
Entorno OLAP de Oracle
La principal ventaja de un almacén de datos es su capacidad para dar soporte a los sistemas de inteligencia empresarial. Hasta la fecha, las aplicaciones estándar de generación de informes y de realización de consultas ad hoc se ejecutaban directamente a partir de tablas relacionales, mientras que las aplicaciones más sofisticadas de inteligencia empresarial utilizaban bases de datos analíticas especializadas. Estas bases de datos analíticas especializadas proporcionan normalmente soporte para cálculos multidimensionales complejos y para funciones predictivas; sin embargo, dependen de la replicación de grandes volúmenes de datos en bases de datos propietarias. La replicación de los datos en bases de datos analíticas propietarias es extremadamente cara. Se necesita un hardware adicional para ejecutar esas bases de datos analíticas y para almacenar los datos replicados. Se necesitan también administradores adicionales de bases de datos para gestionar el sistema. El proceso de replicación provoca a menudo un retraso significativo entre el momento en que los datos están disponibles en el almacén de datos y el momento en el que se almacenan para su análisis en la base de datos analítica. Este retraso causado por la replicación de datos puede afectar significativamente al valor de los datos. La tecnología OLAP de Oracle proporciona soporte para las aplicaciones de inteligencia empresarial sin necesidad de replicar grandes volúmenes de datos en bases de datos analíticas especializadas. La tecnología OLAP de Oracle permite a las aplicaciones soportar directamente los cálculos multidimensionales complejos basándose en los datos contenidos en el almacén de datos. El resultado es que se dispone de una única base de datos que es más gestionable, más escalable y a la que puede acceder un mayor número de aplicaciones.
1108
Sistemas de bases de datos
Las aplicaciones de inteligencia empresarial sólo son útiles cuando se puede acceder a ellas fácilmente. Para soportar el acceso por grandes comunidades de usuarios distribuidos, Oracle OLAP está diseñado específicamente para Internet. La API OLAP Java de Oracle9i proporciona un mecanismo compatible con Internet que permite a los desarrolladores de aplicaciones construir aplicaciones, applets, servlets y páginas JSP Java que pueden implantarse mediante una diversidad de dispositivos, como máquinas PC, estaciones de trabajo, exploradores web, dispositivos PDA y teléfonos móviles con acceso web.
33.6.2
Plataforma para aplicaciones de inteligencia empresarial
La base de datos Oracle9i proporciona una plataforma para las aplicaciones de inteligencia empresarial. Los componentes de esta plataforma incluyen la base de datos Oracle9i y Oracle OLAP como utilidad especializada dentro de la base de datos. Esta plataforma proporciona: •
un rango completo de funciones analíticas, incluyendo funciones multidimensionales
•
soporte para la obtención de tiempos cortos de respuesta a las consultas, similares a los que normalmente se asocian con las bases de datos analíticas especializadas;
•
una plataforma escalable para almacenar y analizar conjuntos de datos multiterabyte;
•
una plataforma abierta para aplicaciones multidimensionales
•
soporte para aplicaciones basadas en Internet.
33.6.3
y predictivas;
y aplicaciones basadas en SQL;
Base de datos Oracle9i
La base de datos Oracle9i es el fundamento de la tecnología Oracle OLAP, ya que proporciona un mecanismo de almacenamiento de datos escalable y seguro, además defunciones de gestión de resúmenes, un sistema de metadatos, funciones analíticas SQL y características de alta disponibilidad. Entre las características de escalabilidad que proporcionan soporte para almacenes de datos multiterabyte podemos citar: •
el particionamiento, que permite descomponer los objetos del almacén de datos en componentes fisicos más pequeños que pueden gestionarse de forma independiente y en paralelo;
•
la ejecución paralela de consultas, que permite a la base de datos utilizar múltiples procesos para responder a una determinada consulta que se curse a través de la API Java OLAPI;
•
soporte para NUMA y para sistemas en clúster, lo que permite a las organizaciones utilizar y gestionar de manera efectiva sistemas hardware de gran envergadura;
•
el gestor de recursos de la base de datos de Oracle, que ayuda a gestionar comunidades de usuarios diversas y de gran tamaño, controlando la cantidad de recursos que se permite utilizar a cada tipo de usuano.
Seguridad La seguridad resulta crítica para el almacén de datos. Para proporcionar el mayor grado posible de seguridad y para minimizar las tareas administrativas, todas las políticas de seguridad se imponen dentro del almacén de datos. Los usuarios se autentican ante la base de datos Oracle utilizando los mecanismos de autenticación de base de datos u Oracle Internet Directory. El acceso a los elementos del modelo de datos multidimensional se controla mediante concesiones y privilegios en la base de datos Oracle. El acceso del nivel de celda a los datos se controla en la base de datos Oracle mediante la característica de base de datos privada virtual (Virtual Private Database) de Oracle.
Gestión de resúmenes Las vistas materializadas proporcionan facilidades para gestionar de manera efectiva los datos del almacén. Si las comparamos con las tablas de resumen, las vistas materializadas ofrecen diversas ventajas:
Capítulo 33 OLAP •
son transparentes para las aplicaciones y los usuarios;
•
permiten gestionar la obsolescencia de los datos;
•
pueden actualizarse automáticamente
1109
cuando cambien los datos de origen.
Al igual que las tablas Oracle, las vistas materializadas pueden particionarse y mantenerse en paralelo. A diferencia de los cubos multidimensionales propietarios, los datos de las vistas materializadas son accesibles por cualquier aplicación que utilice el almacén de datos.
Metadatos Todos los metadatos se almacenan en la base de datos Oracle. Los objetos de bajo nivel, como las dimensiones, tablas y vistas materializadas se definen directamente a partir del diccionario de datos Oracle, mientras que los objetos OLAP de mayor nivel se definen en el catálogo OLAP. Este catálogo contiene objetos tales como carpetas de cubos y de medidas, así como extensiones a las definiciones de otros objetos, como por ejemplo las dimensiones. El catálogo OLAP define completamente las dimensiones y hechos, por lo que determina completamente el esquema en estrella del almacén de datos.
Funciones analíticas SOL Oracle ha mejorado las capacidades de procesamiento analítico de SQL introduciendo una nueva familia de funciones analíticas SQL. Estas funciones analíticas permiten calcular: •
clasificaciones ordenadas y percentiles;
•
valores basados en ventanas móviles;
•
análisis de adelanto/retraso;
•
análisis de tipo primero/último;
•
estadísticas de regresión lineal.
Las funciones de clasificación ordenada incluyen distribuciones acumulativas, clasificaciones porcentuales y N-mosaicos. Los cálculos basados en ventana móvil identifican agregados móviles y acumulativos, como por ejemplo sumas y promedios. El análisis de adelanto/retardo permite la realización de referencias directas y inter-filas para realizar cálculos de cambios periodo a periodo. El análisis de tipo primero/último Tabla 33.7.
Funciones analiticas SQL de Oracle.
Tipo
Utilizadas para
Clasificación ordenada
Cálculo de clasificaciones ordenadas, percentiles y N-mosaicos para los valores de un conjunto de resultados.
Ventanas móviles
Cálculo de agregados acumulativos y móviles. Pueden aplicarse a las siguientes funciones: SUM, AVG, MIN, MAX, COUNT, VARIANCE, STDDEV, FIRST_ VALUE, LAST_ VALUE y a las nuevas funciones estadísticas.
Generación de informes
Cálculo de cuotas, como por ejemplo cuotas de mercado. Pueden utilizarse con las siguientes funciones: SUM, AVG, MIN, MAX, COUNT (con o sin DISTINCT), VARIANCE, STDDEV, RATIO _ TO _ REPORT y a las nuevas funciones estadísticas.
LAG/LEAD
Localización de un valor en una fila que esté situada a una distancia especificada de la fila actual.
FIRST/LAST
Primero o último valor en un grupo ordenado.
Regresión lineal
Cálculo de regresiones lineales y otras estadísticas (pendiente, punto de corte, etc.).
Percentil inverso
El valor de un conjunto de datos que se corresponde con un percentil especificado.
Distinción y clasificación hipotética
La clasificación o percentil que una fila tendría si se la insertara en un conjunto de datos especificado.
1110
Sistemas de bases de datos
identifica el primer o último valor de un grupo no ordenado. Las funciones de regresión lineal soportan el ajuste de una línea de regresión ordinaria por mínimos cuadrados a un conjunto de parejas de números. Esto puede utilizarse como funciones agregadas y también como funciones de ventana móvil o de generación de informes. La Tabla 33.7 clasifica y describe brevemente las funciones analíticas SQL soportadas por Oracle. Para mejorar las prestaciones, las funciones analíticas pueden ejecutarse en paralelo: puede haber múltiples procesos ejecutando simultáneamente todas estas instrucciones. Estas capacidades hacen que los cálculos sean más fáciles y eficientes, mejorando así las prestaciones, la escalabilidad y la simplicidad de la base de datos.
Recuperación de fallos Las características de recuperación de fallos de Oracle protegen los datos del almacén de datos. Las características clave incluyen: •
Oracle Data Guard, una solución completa de recuperación de fallos que utiliza una base de datos de reserva;
•
los registros de rehacer y el catálogo de recuperación;
•
operaciones de copia de seguridad y restauración completamente integradas con las características partición de Oracle;
•
soporte para copia de seguridad y recuperación incrementales.
33.6.4
de
Oracle OLAP
Oracle OLAP, una parte integrante de la base de datos Oracle9i, proporciona soporte para cálculos multidimensionales y funciones productivas. Oracle OLAP soporta tanto las tablas relacionadas de Oracle como los denominados espacios de trabajo analíticos (un tipo de dato multidimensional). Las características clave de Oracle OLAP incluyen: •
la capacidad de soportar cálculos multidimensionales
complejos;
• •
soporte para funciones predictivas tales-..como modelos, predicciones, asignaciones y agregados no aditivos y gestión de escenarios; unaAPI OLAP Java;
•
administración OLAP integrada.
Los cálculos multidimensionales permiten al usuario analizar datos a lo largo de una serie de dimensiones. Por ejemplo, un usuario podría pedir que se le indiquen 'Los diez productos más vendidos para cada uno de los diez mejores clientes durante un periodo consecutivo de seis meses, calculando el crecimiento de las ventas en dólares'. En esta consulta, se realiza una clasificación ordenada de productos anidada dentro de una clasificación ordenada de clientes, se analizan los datos a lo largo de una serie de periodos temporales y se lleva a cabo una medida virtual. Estos tipos de consultas se resuelven directamente en la base de datos relacional. Las funciones predictivas permiten a las aplicaciones responder a preguntas tales como' ¿Hasta qué punto será rentable la empresa en el siguiente trimestre?' y '¿Cuántas unidades deberíamos fabricar este mes?'. Las funciones predictivas se resuelven dentro de un tipo de dato multidimensional, denominado espacio de trabajo analítico, utilizando el lenguaje DML de Oracle OLAP. Oracle OLAP utiliza un modelo de datos multidimensional que permite a los usuarios expresar sus consultas en términos del negocio (qué productos, qué clientes, qué periodos temporales y qué hechos). El modelo multidimensional incluye medidas, cubos, dimensiones, niveles, jerarquías y atributos.
API OLAP Java La API OLAP de OracIe9i está basada en Java. Como resultado, se trata de una API orientada a objetos, independiente de la plataforma y segura, que permite a los desarrolladores de aplicaciones construir aplicaciones
Capítulo 33 OLAP
1111
Java, applets Java, servlets Java y páginas JSP (Java Server Pages) que pueden implantarse para grandes comunidades de usuarios distribuidas a través de Internet. Las características clave de la API OLAP Java son: •
encapsulación;
•
soporte para cálculos multidimensionales;
• •
construcción incremental de consultas; cursores multidimensionales.
33.6.5
Prestaciones
La base de datos Oracle9i elimina la necesidad de establecer compromisos entre la complejidad analítica y el soporte para grandes bases de datos. Con conjuntos de datos pequeños (para los que las bases de datos analíticas especializadas están muy bien adaptadas), Oracle9i proporciona un rendimiento de procesamiento de consultas que puede competir con los de las bases de datos multidimensionales especializadas. A medida que crece el tamaño de las bases de datos y hace falta acceder a más datos para resolver las consultas, Oracle9i sigue proporcionando un rendimiento excelente en el procesamiento de consultas, mientras que las prestaciones de las bases de datos analíticas especializadas comienzan normalmente a degradarse. La base de datos Oracle9i consigue unas excelentes prestaciones y una excelente escalabilidad mediante un código SQL que está altamente optimizado para las consultas multidimensionales y para la base de datos Oracle. El acceso a las cuentas de datos dentro del modelo multidimensional es un factor crítico a la hora de proporcionar unas prestaciones en el procesamiento de las consultas que puedan competir con las de las bases de datos analíticas especializadas. Entre las nuevas características de la base de datos Oracle que proporcionan soporte para un acceso aleatorio y de altas prestaciones a las celdas y para la realización de consultas multidimensionales podemos cit.ar: •
índices de combinación de tipo mapa de bits que se utilizan en el almacén de datos para pre-combinar las tablas de dimensión y las tablas de hechos y almacenar los resultados en un único índice de mapa de bits; ~
•
conjuntos de agrupación, que permiten a Oracle seleccionar datos correspondientes les de resumen utilizando una única inst.rucción de selección;
•
la cláusula WITH, que permite a Oracle crear resultados temporales y usar estos resultados dentro de la consulta, eliminado así la necesidad de crear tablas temporales;
•
las funciones SQL OLAP, que proporcionan un modo muy confuso de expresar numerosas funciones OLAP;
•
funciones de gestión de memoria automática, que proporcionan la cantidad correcta de memoria durante las tareas que tienen un consumo de memoria alto;
•
compartición mejorada de los cursores, que elimina la necesidad de recompilar las consultas cuando ya se ha ejecutado otra consulta similar.
33.6.6
a múltiples nive-
Gestión del sistema
Oracle Enterprise Manager (OEM) proporciona una herramienta de gestión centralizada y completa. OEM permite a los administradores monitorizar todos los aspectos de la base de datos, incluyendo Oracle OLAP. Oracle Enterprise Manager proporciona diversos servicios de gestión a Oracle OLAP, incluyendo: •
gestión de instancias, de sesiones y de configuración;
• •
modelado de datos; monitorización del rendimiento:
•
planificación de trabajos.
1112
Sistemas de bases de datos
33.6.7
Requisitos del sistema
Oracle OLAP se instala como parte de la base de datos Oracle9i y no impone ningún requisito de sistema adicional. Oracle OLAP puede también instalarse en un sistema de nivel intermedio. Cuando se instala en un sistema de nivel intermedio, hacen falta 128 MB de memoria. Si se utilizan intensamente los espacios de trabajo analíticos, se recomienda añadir memoria adicional. La cantidad de memoria que habrá que usar para los espacios de trabajo analíticos dependerá de la aplicación.
Resumen del capítulo •
El procesamiento analítico en línea (OLAP, Online Analytical Processing) consiste en la síntesis, análisis y consolidación dinámicas de grandes volúmenes de datos multidimensionales.
•
Las aplicaciones OLAP se utilizan en áreas funcionales muy distintas, incluyendo el cálculo de presupuesto, el análisis del rendimiento financiero, el análisis y previsión de ventas, el análisis e investigación de mercados y la segmentación de mercados/clientes.
•
Las características clave de las aplicaciones OLAP incluyen las vistas multidimensionales soporte para cálculos complejos y los mecanismos de inteligencia temporal.
•
Los servidores de base de datos OLAP utilizan estructuras multidimensionales para almacenar datos y relaciones entre los datos. Las estructuras multidimensionales pueden visualizarse como cubos de datos y como cubos dentro de cubos de datos. Cada lado del cubo se denomina dimensión.
•
La pre-agregación, las jerarquías dimensionales y la gestión de los datos dispersos pueden reducir significativamente el tamaño de la base de datos y las necesidades de cálculo. Estas técnicas eliminan la necesidad de efectuar combinaciones multitabla y proporcionan un acceso rápido y directo a las matrices de datos, acelerando así significativamente la ejecución de las consultas multidimensional.
•
E.F. Codd formuló doce reglas como base para la selección de herramientas OLAP.
•
Las herramientas OLAP pueden clasificarse de acuerdo con la arquitectura de la base de datos que proporcionan los datos para procesamiento analítico. Hay cuatro categorías principales de herramientas OLAP: OLAP multidimensional (MOLAP), OLAP relacional (ROLAP), OLAP híbrido (HOLAP) y OLAP de escritorio (DOLAP).
•
El estándar SQL:2003 soporta la funcionalidad OLAP al proporcionar una serie de extensiones para capacidades de agrupamiento, como las funciones CUBE y ROLLUP, así como operadores elementales para el cálculo de valores basados en ventanas móviles y para la determinación de funciones de clasificación ordenada de los datos.
de los datos, el
Cuestiones de repaso 33.1.
Explique el concepto de procesamiento analítico en línea (OLAP).
33.2.
Explique las relaciones entre los almacenes de datos y OLAP.
33.3.
Describa una serie de aplicaciones OLAP e identifique las características de tales aplicaciones.
33.4.
Describa las características estos datos.
33.5.
Indique las Reglas de Codd para las herramientas OLAP.
33.6.
Describa la arquitectura, características y principales problemas asociados con cada uno de los siguientes tipos de herramientas OLAP: (a)
MOLAP,
(b)
ROLAP,
(c)
HOLAP,
(d)
DOLAP.
de los datos multidimensionales
y explique cómo pueden representarse
Capítulo 33 OLAP la funcionalidad
1113
33.7.
Explique cómo proporcionan SQL.
OLAP las funciones ROLLUP y CUBE del estándar
33.8.
Explique cómo proporcionan la funcionalidad OLAP los operadores elementales del estándar SQL, como las ventanas móviles y las funciones de clasificación ordenada.
Ejercicios 33.9.
El Director Gerente de DreamHome nos pide que investiguemos y elaboremos un informe' sobre la aplicabilidad de la tecnología OLAP para la organización. El informe debe describir dicha tecnología y proporcionar una comparación con las herramientas tradicionales de consulta y de generación de informes de los SGBD relacionales. El informe debe asimismo identificar las ventajas y desventajas, así como cualquier problema asociado con la implementación de OLAP. El informe debe proporcionar un conjunto justificado de conclusiones en lo que respecta a la aplicabilidad de OLAP para el caso de DreamHome.
33.10. Verifique si su organización (su universidad o su empresa) ha invertido en tecnologías OLAP y, en caso afirmativo, investigue si estas herramientas OLAP forman parte de una inversión de mayor envergadura en tecnologías de inteligencia empresarial. Si fuera posible; determine las razones por las que su organización está interesada en la tecnología OLAP, verifique cómo se están aplicando las herramientas y compruebe si se han obtenido ventajas al aplicar dicha tecnología.
Capítulo
Minería de datos
Objetivos del capítulo: En este capítulo aprenderá: •
Los conceptos asociados con la minería de datos.
•
Las principales características de las operaciones de minería de datos, incluyendo el modelado predictivo, la segmentación de la base de datos, el análisis de enlaces y la detección de desviaciones.
•
Las técnicas asociadas con las operaciones de minería de datos.
•
El proceso de la minería de datos.
•
Las características más importantes de las herramientas de minería de datos.
•
La relación entre la minería de datos y los almacenes de datos.
•
El soporte que Oracle proporciona para la minería de datos.
En el Capítulo 31 hemos visto que la creciente popularidad de los almacenes de datos (o, más comúnmente, de los mercados de datos) ha estado acompañada por un incremento similar en las demandas de los usuarios dirigidas a poder disponer de herramientas de acceso más potentes que proporcionen capacidades analíticas avanzadas. Hay disponibles dos tipos principales de herramientas de acceso para satisfacer estas demandas, que son las herramientas de procesamiento analítico en línea (OLAP, Online Analytical Processing) y las herramientas de minería de datos. En el capítulo anterior hemos descrito OLAP y en este capítulo vamos a centramos en la minería de datos.
Estructura del capítulo En la Sección 34.1 se explica lo que es la minería de datos y se presentan ejemplos de aplicaciones típicas de minería de datos. En la Sección 34.2 se describen las principales características de las operaciones de minería de datos y sus técnicas asociadas. En la Sección 34.3 se analiza el proceso de la minería de datos. En la Sección 34.4 se explican las características más importantes de las herramientas de minería de datos y en la Sección 34.5 se examina la relación existente entre la minería de datos y los almacenes de datos. Finalmente, en la Sección 34.6 se describe el soporte que Oracle proporciona para las técnicas de minería de datos.
34.1 Minería de datos Limitarse a almacenar información en un almacén de datos no proporciona los beneficios que las organizaciones buscan a la hora de implantar este tipo de sistemas. Para conseguir sacar el máximo provecho de un
1116
Sistemas de bases de datos
almacén de datos, es necesario extraer el conocimiento oculto dentro del almacén. Sin embargo, a medida que crece la cantidad y la complejidad de los datos contenidos en un almacén de datos, se hace cada vez más difícil, si no imposible, para los analistas de negocio identificar las tendencias y relaciones en los datos utilizando herramientas simples de consulta y de generación de informes. La minería de datos es una de las mejores maneras de extraer patrones y tendencias significativos de entre un enorme conjunto de datos. La minería de datos descubre información dentro de los almacenes de datos que las consultas e informes no pueden revelar de manera efectiva. Existen numerosas definiciones sobre lo que es la minería de datos, desde definiciones muy amplias que describen la minería de datos como cualquier herramienta que permite a los usuarios acceder directamente a grandes cantidades de datos, hasta definiciones más específicas, como la que afirma que se trata de herramientas y aplicaciones que realizan análisis estadísticos sobre los datos. En este capítulo, vamos a utilizar una definición más centrada de la minería de datos que fue acuñada por Simoudis (1996): Minería de datos
El proceso de extraer información válida, previamente desconocida, comprensible y útil de bases de datos de gran tamaño y utilizar dicha información para tomar decisiones de negocio cruciales.
La minería de datos se preocupa del análisis de los datos y de la utilización de técnicas software para localizar patrones y relaciones ocultos e inesperados dentro de una serie de conjuntos de datos. El enfoque de la minería de datos consiste en revelar información que esté oculta y sea inesperada, ya que no tiene mucho sentido tratar de encontrar patrones y relaciones que resulten intuitivos por sí mismos. Para identificar los patrones y relaciones ocultos se examinan las reglas y características subyacentes a los datos. El análisis de minería de datos tiende a trabajar comenzando por los propios datos y progresando hacia arriba, y las técnicas que producen los resultados más precisos requieren, normalmente, grandes volúmenes de datos para poder ofrecer conclusiones fiables. El proceso de análisis comienza desarrollando una representación óptima de la estructura de una serie de datos de ejemplo, adquiriéndose unos ciertos conocimientos durante esta fase. Dichos conocimientos se amplían posteriormente a conjuntos de datos de mayor tamaño, trabajando con la suposición de que esos conjuntos de datos de mayor tamaño tienen una estructura similar a la de los datos de muestra. La minería de datos puede reportar enormeS"'beneficios a las empresas que hayan hecho una inversión significativa en tecnologías de almacén de datos. Aunque la minería de datos es una tecnología relativamente nueva, ya se utiliza en diversos sectores. La Tabla 34.1 indica diversos ejemplos de aplicaciones de la minería de datos en comercio al por menor/marketing, banca, seguros y medicina. Tabla 34.1. Ejemplos de aplicaciones de la minería de datos. Comercio al por menor/marketing Identificación de patrones de compra de los clientes Determinación de asociaciones entre las características demográficas de los clientes Predicción de la respuesta a las campañas de publicidad por correo Análisis de cestas de la compra Banca Detección de patrones de uso fraudulento de tarjetas de crédito Identificación de clientes leales Predicción de clientes que tienen probabilidad de cambiar de suministrador de tarjeta de crédito Determinación de los gastos realizados por ciertos grupos de clientes con la tarjeta de crédito Seguros Análisis de partes Predicción de los clientes que suscribirán nuevas pólizas Medicina Caracterización del comportamiento de los pacientes para predecir las visitas quirúrgicas Identificación de terapias médicas adecuadas para diferentes enfermedades
Capítulo 34 Minería de datos
1117
34.2 Técnicas de minería de datos Hay cuatro operaciones principales asociadas con las técnicas de minería de datos, que son el modelado predictivo, la segmentación de la base de datos, el análisis de enlaces y la detección de desviaciones. Aunque puede utilizarse cualquiera de estas cuatro operaciones principales para implementar las aplicaciones enumeradas en la Tabla 34.1, existen ciertas asociaciones conocidas entre las distintas aplicaciones y las operaciones correspondientes. Por ejemplo, las estrategias de marketing directo se implementan formalmente utilizando la operación de segmentación de la base de datos, mientras que la detección de fraudes puede implementarse empleando cualquiera de las cuatro operaciones. Además, muchas aplicaciones funcionan particularmente bien cuando se emplean varias operaciones. Por ejemplo, una técnica común para realizar perfiles de clientes consiste en segmentar primero la base de datos y luego aplicar el modelado predictivo a los segmentos de datos resultantes. Las técnica son implementaciones específicas de las operaciones de minería de datos. Sin embargo, cada operación tiene sus propias debilidades y fortalezas. Teniendo esto presente, las herramientas de minería de datos suelen ofrecer una serie de opciones de operaciones para implementar cada técnica. En la Tabla 34.2 se enumeran las principales técnicas asociadas con cada una de las cuatro operaciones principales de minería de datos (Cabena et al., 1997). El lector interesado en ver una exposición más detallada de las técnicas de la minería de datos y de sus aplicaciones puede consultar Cabena et al. (1997).
34.2.1
Modelado predictivo
El modelador predictivo es similar a la experiencia de aprendizaje humana, ya que se utilizan observaciones para formar un modelo de las características más importantes de algún tipo de fenómeno. Esta técnica utiliza generalizaciones del 'mundo real' y la capacidad de encajar nuevos datos dentro de un marco general. El modelado predictivo puede emplearse para analizar una base de datos existente con el fin de determinar ciertas características esenciales (modelo) acerca del conjunto de datos. El modelo se desarrolla utilizando una técnica de 'aprendizaje super)jsado', que tiene dos fases: entrenamiento y prueba. La fase de entrenamiento construye un modelo utilizando una gran muestra de datos históricos, denominada 'conjunto de entrenamiento', mientras que las pruebas implican comprobar el modelo utilizando datos nuevos, previamente no empleados, para determinar su precisión y las características de rendimiento físico. Entre las aplicaciones del modelado predictivo podemos citar la gestión de las tasas de retención de clientes, las aprobaciones de límites de crédito, la realización de ventas cruzadas y las campañas de marketing directo. Hay dos técnicas asociadas con el modelado predictivo: la clasificación y la predicción de valores, que se distinguen por la naturaleza de la variable que se trata de predecir. Tabla 34.2.
Operaciones
de minería de datos y sus técnicas asociadas.
Operaciones
Técnicas de minería de datos
Modelado predictivo
Clasificación Predicción de valores
Segmentación de la base de datos
Agrupaciones demográficas Agrupaciones neuronales
Análisis de enlaces
Descubrimiento de asociaciones Descubrimiento de patrones secuenciales Descubrimiento de similitudes en secuencias temporales
Detección de desviaciones
Estadística Visualización
1118
Sistemas de bases de datos
Clasificación La técnica de clasificación se emplea para establecer una clase predeterminada específica para cada registro de una base de datos, de entre un conjunto finito de posibles valores de clases. Hay dos tipos de técnicas de clasificación: inducción en árbol e inducción neuronal. Un ejemplo de técnica de clasificación utilizando la inducción en árbol se muestra en la Figura 34.l. En este ejemplo, nos interesa predecir si un cliente que está actualmente alquilando un inmueble podría estar interesado en comprar otro inmueble. Un modelo predictivo ha determinado que sólo hay dos variables de interés: la cantidad de tiempo que el cliente ha estado alquilando el inmueble y la edad del cliente. El árbol de decisión presenta el análisis de una forma intuitiva. El modelo predice que los clientes que han estado viviendo de alquiler durante más de dos años y tienen más de 25 años de edad son los que más probablemente estén interesados en comprar un inmueble. En la Figura 34.2 se muestra un ejemplo de clasificación mediante inducción neuronal, utilizando el mismo ejemplo que en la Figura 34.1. En este caso, la clasificación de los datos se realiza mediante una red neuronal. Una red neuronal contiene colecciones de nodos conectados, con entradas, salidas y un cierto procesamiento en cada nodo. Entre las capas visibles de entrada y de salida puede haber una serie de capas ocultas de procesamiento. Cada unidad de procesamiento (círculo) de una capa está conectada a cada unidad de procesamiento de la capa siguiente mediante un valor ponderado, que expresa la intensidad de la relación. La red trata de asemejarse a la forma en que funciona el cerebro humano al reconocer patrones, combinando aritméticamente todas las variables asociadas con un determinado punto de datos. De esta forma, es posible desarrollar modelos predictivos no lineales capaces de 'aprender' estudiando combinaciones de variables y viendo cómo las diferentes combinaciones de variables afectan a los distintos conjuntos de datos.
Si
No
No
Figura 34.1.
Si
Un ejemplo de clasificación
usando la inducción en árbol.
¿Cliente alquilando inmueble> 2 años? Clase (alquilar o comprar inmueble) ¿Edad cliente > 25 años? Entrada
Figura 34.2.
Capa oculta de procesamiento
Un ejemplo de clasificación
Salida
utilizando inducción neuronal.
Capítulo 34 Minería de datos
1119
Predicción de valores La predicción de valores se utiliza para estimar un valor numérico continuo que esté asociado con un registro de base de datos. Esta técnica utiliza las técnicas estadísticas tradicionales de la regresión lineal y de la regresión no lineal. Dado que estas técnicas son bien conocidas resultan fáciles de comprender y de utilizar. La regresión lineal trata de encajar una línea recta entre una serie de puntos de datos, de modo que la línea sea la mejor representación de la media de todas las observaciones en cada punto de la gráfica. El problema de la regresión lineal es que esta técnica sólo funciona bien con datos lineales y es sensible a la presencia de excepciones (es decir, de valores de datos que no se adaptan a la norma esperada). Aunque la regresión no lineal resuelve los principales problemas de la regresión lineal, sigue sin ser lo suficientemente flexible como para poder tratar todas las posibles formas de la gráfica de los datos. Aquí es donde empiezan a divergir los métodos de análisis estadístico tradicionales y los métodos de minería de datos. Las medidas estadísticas son adecuadas para construir modelos lineales que describan puntos de datos predecibles; sin embargo, la mayoría de los datos tiene una naturaleza no lineal. La minería de datos requiere métodos estadísticos que puedan aceptar no linealidades, excepciones y datos no numéricos. Entre las aplicaciones de la predicción de valores podemos citar la detección de fraudes con tarjetas de crédito y la identificación de listas de correo de potenciales clientes.
34.2.2
Segmentación de la base de datos
El objetivo de la segmentación de la base de datos consiste en particionar una base de datos en un número desconocido de segmentos o clústeres de registros similares, es decir, registros que compartan una serie de propiedades y que por ello se consideren homogéneos (los segmentos tienen una alta homogeneidad interna y una alta heterogeneidad externa). Esta técnica utiliza métodos de aprendizaje no supervisado para descubrir subconjuntos homogéneos dentro de la población de una base de datos, con el fin de mejorar la precisión de los perfiles. La segmentación de la base de datos es menos precisa que otras operaciones y, por tanto, menos sensible a las características redundante s e irrelevantes. La sensibilidad puede reducirse ignorando un subconjunto de los atributos que describen a cada instancia, o asignado un factor de ponderación a cada variable. Las aplicaciones de la técnica de segmentación de la base de datos incluyen la realización de perfiles de clientes, el marketing directo y las ventas cruzadas. En la Figura 34.3 se muestra un ejemplo de segmentación de la base de datos utilizando una gráfica de dispersión.
u o
o
0% O O
o óJD
O O
O
X
o X
I
Figura 34.3.
X Moneda legal
Un ejemplo de segmentación
o
Moneda falsa
I
de la base de datos utilizando una gráfica de dispersión.
1120
Sistemas de bases de datos
En este ejemplo, la base de datos está compuesta por 200 observaciones: 100 que representan billetes legítimos y 100 que representan billetes falsos. Los datos son hexadimensionales. Correspondiendo cada dimensión a una medida concreta del tamaño de los billetes. Utilizando técnicas de segmentación de la base de datos, identificamos los c1ústeres que corresponden a billetes legales y falsos. Observe que hay dos grupos de billetes falsos, lo que puede atribuirse a la operación de al menos dos bandas de falsificadores de billetes (Girolami et al., 1997). La segmentación de la base de datos está asociada con las técnicas de agrupación neuronal o demográfica, que se distinguen por los tipos permitidos de datos de entrada, los métodos utilizados para calcular la distancia entre los registros y la presentación de los segmentos resultantes para su análisis.
34.2.3 Análisis de enlaces El análisis de enlaces trata de establecer vínculos, denominados asociaciones, entre los registros individuales o entre los conjuntos de registros de una base de datos. Hay tres tipos de análisis de enlaces: descubrimiento de asociaciones, descubrimiento de patrones secuenciales y descubrimiento de secuencias temporales similares. El descubrimiento de asociaciones trata de encontrar elementos que impliquen la presencia de otros elementos en el mismo suceso. Estas afinidades entre los elementos se representan mediante reglas de asociación. Por ejemplo, cuando un cliente alquila un inmueble durante más de dos años y tiene más de 25 años de edad, en el 40% de los casos, el cliente comprará un inmueble. Esta asociación se produce para el 35% de todos los clientes que alquilan inmuebles. La técnica de descubrimiento de patrones secuenciales trata de encontrar patrones entre sucesos tales que la presencia de un conjunto de elementos es seguida por otro conjunto de elementos en una base de datos de sucesos a lo largo de un periodo de tiempo. Por ejemplo, esta técnica puede utilizarse para comprender el comportamiento de compra a largo plazo de los clientes. El descubrimiento de secuenciales temporales similares se utiliza, por ejemplo, para descubrir enlaces entre dos conjuntos de datos que sean dependientes del tiempo, y está basado en el grado de similaridad entre los patrones exhibidos por ambas series temporales. Por ejemplo, dentro de los tres meses siguientes a la compra de un inmueble, los nuevos propietarios de.,l1iviendas comprarán productos tales como cocinas, refrigeradores y lavadoras. Entre las aplicaciones de la técnica del análisis de enlaces se incluyen el análisis de afinidad por productos, el marketing directo y el cálculo de movimientos de los valores versátiles.
34.2.4
Detección de desviaciones
La detección de desviaciones es una técnica relativamente nueva en lo que respecta a la disponibilidad de herramientas comerciales de minería de datos. Sin embargo, la detección de desviaciones suele ser una fuente de verdaderos descubrimientos, porque identifica las excepciones, que expresa la desviación con respecto a una cierta expectativa o a una norma previamente conocida. Esta operación puede realizarse utilizando técnicas estadísticas y de visualización, o como subproducto de la minería de datos. Por ejemplo, la regresión lineal facilita la identificación de excepciones en los datos, mientras que las técnicas de visualización modernas muestran resúmenes y representaciones gráficas que hacen que sea fácil detectar las desviaciones. En la Figura 34.4 se ilustra la técnica de visualización para los datos mostrados en la Figura 34.3. Entre las aplicaciones de la detección de desviaciones podemos incluir la detección de fraudes en el uso de tarjetas de crédito y en los partes enviados a las compañías de seguros, el control de calidad y el seguimiento de defectos.
34.3 El proceso de minería de datos Dándose cuenta de que la utilización de una técnica sistemática resulta esencial para poder llevar a cabo con éxito un proceso de minería de datos, muchos fabricantes y empresas de consultaría han especificado un modelo de proceso diseñado para guiar al usuario (especialmente a alguien que no tenga experiencia en la
Capítulo 34 Minería de datos
1121
300
200
100
o 45
50
o
Figura 34.4.
Un ejemplo de visualización
para los datos mostrados en la Figura 34.3.
construcción de modelos predictivos) a través de una secuencia de pasos mediante los que pueda obtener un buen resultado. En 1996, un consorcio de fabricantes y usuarios compuesto por NCR Systems Engineering Copenhagen (Dinamarca), Daimler-Benz AG (Alemania), SPSS/Integral Solutions Ud (Inglaterra) y OHRA Verzekeringen en Bank Groep.,.BV (Holanda) desarrolló una especificación denominada CRISP-DM (Cross Industry Standard Process for Data Mining, proceso estándar intersectorial para la minería de datos). CRISP-DM especifica un modelo de proceso de minería de datos que no es específico de ningún sector ni herramienta concretos. CRISP-DM ha evolucionado a partir de los procesos de descubrimiento de conocimientos utilizados ampliamente en la industria y como respuesta directa a los requisitos de los usuarios. Los objetivos principales de CRISP-DM son hacer que los grandes proyectos de minería de datos funcionen de manera más eficiente y que sean también más baratos, más fiables y mejor gestionables. La versión actual de CRISP-DM es la versión 1.0 y en esta sección vamos a describir brevemente dicho modelo (CRISP-DM, 1996).
34.3.1
El modelo CRISP-DM
La metodología CRISP-DM es un modelo de proceso jerárquico. En el nivel superior, el proceso se divide en seis fases genéricas distintas, que van desde la comprensión del negocio hasta la implantación de los resultados del proyecto. El siguiente nivel refina cada una de estas fases, que están compuestas de diversas tareas genéricas. En este nivel, la descripción es lo suficientemente genérica como para abarcar todos los escenarios de minería de datos. El tercer nivel especializa dichas tareas para situaciones específicas. Por ejemplo, la tarea genérica puede ser la de limpieza de los datos, y la tarea especializada sería la limpieza de valores numéricos o de valores de categorías. El cuarto nivel es la instancia de proceso, es decir, un registro de acciones, decisiones y resultados de una ejecución real de un proyecto de minería de datos. El modelo también analiza las relaciones entre las diferentes tareas de minería de datos. Proporciona una secuencia idealizada de acciones que deben tener lugar durante un proyecto de minería de datos; sin embargo, no trata de dar todas las posibles rutas que pueden seguirse para llevar a cabo esas tareas. En la Tabla 34.3 se muestran las diferentes fases del modelo.
1122
Sistemas de bases de datos Tabla 34.3.
Fases del modelo CRISP-DM.
Fase Comprensión del negocio Comprensión
de los datos
Preparación de los datos Modelado Evaluación Implantación
A continuación vamos a describir brevemente el objetivo de cada fase del modelo CRISP-DM y las tareas asociadas con cada una de ellas.
Comprensión del negocio Esta fase se centra en comprender los requisitos y objetivos del proyecto desde la perspectiva del negocio. Esta fase convierte el problema de negocio en una definición de problema de minería de datos y prepara el plan preliminar para el proyecto. Las principales tareas implicadas son: determinar los objetivos del negocio, evaluar la situación, determinar el objetivo de la minería de datos y generar un plan de proyecto.
Comprensión de los datos Esta fase incluye las tareas de recopilación inicial de los datos y se preocupa de establecer las principales características de estos. Dichas características incluyen las estructuras de datos, la calidad de los datos y la identificación de los posibles subconjuntos de interés de los datos. Las tareas incluidas en esta fase son: recolección de los datos iniciales, descripción de los datos, exploración de los datos y verificación de la calidad de los datos.
Preparación de los datos Esta fase implica todas las actividades para construir el conjunto de datos final al que puedan aplicarse directamente las herramientas de modelado. Las tareas que componen esta fase son: selección de los datos, limpieza de los datos, construcción de los datos, integración de los datos y formateo de los datos.
Modelado Esta fase es la operación de minería de datos propiamente dicha e implica seleccionar las técnicas de modelado, seleccionar los parámetros de modelado y evaluar el modelo creado. Las tareas de esta fase son: seleccionar la técnica de modelado, generar el diseño de prueba, construir el modelo y evaluar el modelo.
Evaluación Esta fase valida el modelo desde el punto de vista del análisis de los datos. El modelo y las etapas seguidas durante el modelado se verifican dentro del contexto de la consecución de los objetivos de negocio. Las tareas incluidas en esta fase son: evaluación de los resultados, revisión del proceso y determinación de los pasos siguientes.
Implantación El conocimiento obtenido y reflejado en el modelo tiene que organizarse y presentarse de una forma que sea comprensible por parte de los usuarios de la organización. La fase de implantación puede ser tan simple como generar un informe o tan compleja como implementar procesos repetidos de minería de datos por toda la empresa. El usuario de la empresa es quien se encarga normalmente de ejecutar la fase de implantación. Los
Capítulo 34 Minería de datos
1123
pasos correspondientes son: planificación de la implantación, planificación de la monitorización y el mantenimiento, producción del informe final y revisión del informe. El lector interesado en ver una descripción completa del modelo CRISP-DM puede consultar CRISP-DM (1996).
34.4 Herramientas de minería de datos Cada vez hay más herramientas comerciales de minería de datos en el mercado. Las características más importantes de las herramientas de minería de datos son la preparación de los datos, la selección de las operaciones de minería de datos (algoritmos), la escalabilidad y prestaciones del producto y las funcionalidades disponibles para comprender los resultados. Preparación
de los datos
La preparación de los datos es el aspecto de la minería de datos que más tiempo requiere. Toda función que una herramienta pueda proporcionar para facilitar este proceso permitirá acelerar en gran medida el desarrollo del modelo. Entre las funciones que una herramienta puede proporcionar para dar soporte a la preparación de los datos podemos citar: limpieza de los datos, como por ejemplo solucionar el problema de la falta de determinados datos; destrucción de los datos, como por ejemplo la distribución de los valores; transformación de los datos, como por ejemplo realizar cálculos partiendo de columnas existentes; el muestreo de los datos, para la creación de conjuntos de datos para entrenamiento y validación. Selección
de las operaciones
de minería de datos (algoritmosl
Es importante comprender las características de las operaciones (algoritmo s) utilizados por una herramienta de minería de datos, con el fin de asegurarse de que cumplen los requisitos del usuario. En particular, es importante establecer cómo tratan los distintos algoritmo s los tipos de datos de las variables de respuesta y variables predictoras, la rapidez con la que llevan a cabo la fase de entrenamiento y la velocidad con la que operan sobre los nuevos datos (una variable predictora es la columna de una base de datos que puede utilizarse para construir un modelo predictor, con el fin de predecir los valores de otra columna). Otra característica importante de un algoritmo es su sensibilidad al ruido (el ruido es la diferencia entre un modelo y sus predicciones. En ocasiones, decimos que los datos son ruidosos cuando contienen errores tales como muchos valores incorrectos e inexistentes, o cuando hay columnas irrelevantes). Es importante establecer la sensibilidad a la falta de datos de un algoritmo dado y ver lo robustos que son los patrones que dicho algoritmo descubre en presencia de datos irrelevantes o incorrectos. Escalabilidad
y prestaciones
del producto
La escalabilidad y las prestaciones son consideraciones de gran importancia a la hora de seleccionar una herramienta que sea capaz de tratar con cantidades de datos crecientes, en términos del número de filas y del número de columnas, posiblemente con sofisticado s controles de validación. La necesidad de proporcionar escalabilidad al mismo tiempo que se mantienen unas prestaciones satisfactorias puede requerir investigar si una herramienta es capaz de soportar el procesamiento paralelo utilizando tecnologías tales como SMP o MPP. Ya hemos hablado del procesamiento paralelo mediante tecnologías SMP y MPP en la Sección 23.1. Funcionalidades
para comprender
los resultados
Una buena herramienta de minería de datos debería ayudar al usuario a comprender los resultados, proporcionando medidas que describan la precisión y lo significativo de los datos, en formatos útiles (por ejemplo, matrices de confusión) y permitiendo al usuario realizar análisis de sensibilidad sobre el resultado; también deben presentarse los resultados en formas alternativas (utilizando, por ejemplo, técnicas de visualización). Una matriz de confusión muestra el número real de valores de una clase, comparándolo con el número predicho. No sólo ilustra la capacidad predictiva del modelo, sino que también presenta los detalles necesarios para ver exactamente dónde pueden estar fallando las cosas.
1124
Sistemas de bases de datos
El análisis de sensibilidad determina la sensibilidad de un modelo predictivo con respecto a pequeñas fluctuaciones de un valor predictor. Mediante esta técnica, los usuarios finales pueden evaluar los efectos que el ruido y los cambios ambientales tienen sobre la precisión del modelo. Las técnicas de visualización permiten mostrar los datos gráficamente para facilitar una mejor comprensión de su significado. Las capacidades gráficas de las herramientas van de la elaboración de simples gráficas de dispersión hasta representaciones multidimensionales complejas.
34.5 Minería de datos y almacenes de datos Uno de los desafíos principales para las organizaciones que pretendan aprovechar las técnicas de minería de datos es identificar los datos más adecuados para aplicarles estas técnicas. La minería de datos requiere una fuente de datos unificada, independiente, limpia, integrada y auto-coherente. Un almacén de datos está bien preparado para proporcionar los datos que la minería de datos requiere, por las siguientes razones: •
La calidad y coherencia de los datos son prerrequisitos para la minería de datos, con el fin de garantizar la precisión de los modelos predictivos. Los almacenes de datos albergan datos limpios y coherentes.
•
Resulta conveniente aplicar la minería de datos a datos procedentes de múltiples fuentes, con el fin de descubrir el máximo número posible de interrelaciones. Los almacenes de datos contienen datos procedentes de diversas fuentes.
•
La selección de los subconjuntos de registros y campos relevantes para la minería de datos requiere disponer de las capacidades de consulta de un almacén de datos.
•
Los resultados de un estudio de minería de datos son útiles si existe alguna manera de continuar investigando los patrones no descubiertos. Los almacenes de datos proporcionan la capacidad de acudir de nuevo al origen de los datos.
Dada la naturaleza complementaria de las técnicas de minería de datos y de los almacenes de datos, muchos fabricantes están investigando formas de integrar ambos tipos de tecnologías.
34.6 Oracle Data Mining (ODM) En los grandes entornos de almacén de datos pueden realizarse muchos tipos diferentes de análisis. Además de consultas SQL, también se pueden aplicar operaciones analíticas más avanzadas a los datos. Los dos tipos principales de análisis son el procesamiento analítico en línea (OLAP, Online Analytical Processing) y la minería de datos. En lugar de disponer de dos motores independientes para OLAP y para minería de datos, Oracle ha integrado las capacidades OLAP y de minería de datos directamente en el servidor de base de datos. Oracle OLAP y Oracle Data Mining (ODM) son opciones de la base de datos Oracle9i. En la Sección 33.6.7 hemos presentado una introducción al soporte que Oracle proporciona para OLAP, mientras que en esta sección veremos una introducción al soporte de Oracle para la minería de datos (Oracle Corporation, 2004(j)).
34.6.1
Capacidades de minería de datos
Oracle permite realizar la minería de datos dentro de la base de datos, por razones de prestaciones y escalabilidad. Algunas de la capacidades del producto son: •
una API que permite el control programático y la integración con las aplicaciones;:
•
capacidades analíticas que incluyen mecanismos OLAP y funciones estadísticas en la base de datos;
•
múltiples algoritmos: Bayes simple, árboles de decisión, agrupamientos y reglas de asociación;
•
modos de puntuación en tiempo real y por lotes;
• •
múltiples tipos de predicción; detalles de asociaciones.
Capítulo 34 Minería de datos
34.6.2
1125
Soporte para aplicaciones de minería de datos
Oracle9i Data Mining proporciona unaAPI Java para aprovechar la funcionalidad de minería de datos incluida en la base de datos Oracle9i. Al permitir un control programático completo de la base de datos durante la minería de datos, Oracle Data Mining (ODM) permite un modelado potente y escalable e incluye mecanismos de puntuación en tiempo real. Esto permite a las empresas incorporar predicciones y clasificaciones en todos los procesos y puntos de decisión, a lo largo de todo el ciclo de negocio. ODM está diseñado para poder procesar enormes cantidades de datos, proporcionando conocimientos precisos que están completamente integrados en las aplicaciones de e-Business. Este tipo de inteligencia empresarial integrada permite la automatización y la velocidad de decisión que este tipo de empresas necesitan para poder competir en los entornos de mercado actuales.
34.6.3
Predicciones y asociaciones
Oracle Data Mining utiliza algoritmo s de minería de datos para analizar los grandes volúmenes de datos generados por las empresas, con el fin de producir, evaluar e implantar modelos predictivos. También aumenta la potencia de las aplicaciones de misión crítica en el campo de la gestión de relaciones con los clientes (CRM, customer relationship management), control de fabricación, gestión de almacén, servicio y soporte al cliente, portales web, dispositivos móviles y otros campos, proporcionando recomendaciones específicas del contexto y una monitorización predictiva de los procesos críticos. ODM proporciona respuestas en tiempo real a preguntas tales como: •
¿Qué N elementos comprará más probablemente la persona A?
•
¿Cuál es la probabilidad de que este producto sea devuelto para ser reparado?
34.6.4
Entorno de Oracle Data Mining
El entorno de Oracle Data Mining soporta todas las fases de la minería de datos dentro de la base de datos. Para cada fase, el entorno ODM presenta numerosas ventajas en términos de prestaciones, automatización e integración.
Preparación de los datos La tarea de preparación de los datos permite crear nuevas tablas o nuevas vistas de los datos existentes. Ambas opciones son más rápidas que transferir los datos hacia una utilidad de minería de datos externa, y ofrecen al programador la opción de utilizar instantáneas o actualizaciones en tiempo real. Oracle Data Mining proporciona utilidades para las tareas complejas específicas de la minería de datos. ODM acepta los datos en formato de registros aislados o en formato transaccional, y puede realizar tareas de minería sobre los fortnatos transaccionales. El formato de registros aislados es el más común en la mayoría de las aplicaciones, por lo que ODM proporciona una utilidad para transformar dicho formato de registros aislados. El análisis típico para la exploración preparatoria de los datos y la evaluación del modelo se amplía mediante las funciones estadísticas y las capacidades OLAP de Oracle. Puesto que estas técnicas también operan dentro de la base de datos, pueden incorporarse dentro de una aplicación integrada que comparta los objetos de la base de datos. Esto permite conseguir aplicaciones más funcionales y rápidas.
Construcción
del modelo
Oracle Data Mining proporciona cuatro algoritmos: Bayes simple, árboles de decisión, agrupamientos y reglas de asociación. Estos algoritmos son aplicables a un amplio conjunto de problemas de negocio, que van desde la predicción de la probabilidad futura de que un cliente compre un cierto producto, hasta la comprensión de qué productos son los que más probablemente se adquieran de manera simultánea en una visita a una tienda de comestibles. Toda la construcción del modelo tiene lugar en la base de datos. De nuevo, no es necesario transferir los datos hacia afuera de la base de datos para reconstruir el modelo, por lo que se acelera todo el proceso de minería de datos.
1126
Sistemas de bases de datos
Evaluación del modelo Los modelos están almacenados en la base de datos y se puede acceder directamente a ellos para su evaluación, para la generación de informes y para un análisis posterior mediante una amplia variedad de herramientas y funciones de aplicación. ODM proporciona interfaces de programación de aplicaciones para calcular matrices de confusión tradicionales y diversos tipos de diagramas. ODM almacena los modelos, los datos subyacentes y estos análisis en la base de datos, con el fin de permitir que se realicen con posterioridad nuevos análisis, nuevos informes y tareas de gestión del modelo específicas de la aplicación.
Puntuación Oracle Data Mining proporciona mecanismos de puntuación tanto en tiempo real como por lotes. En el modo de puntuación por lotes, ODM toma una tabla como entrada, puntúa cada registro y devuelve una tabla de puntuaciones como resultado. En el modo de tiempo real, se pasan los parámetros correspondientes a un único registro y las puntuaciones se devuelven en forma de objeto Java. En ambos modos, ODM puede proporcionar diversos tipos de puntuaciones. Puede devolver una clasificación o probabilidad de que se produzca un resultado específico. Alternativamente, puede devolver un resultado específico y la probabilidad de que dicho resultado tenga lugar. Por ejemplo: •
¿Cuál es la probabilidad de que este suceso tenga como resultado el suceso A?
•
¿Cuál es el suceso que más probablemente puede producirse a partir de este proceso?
•
¿Cuáles son las probabilidades de cada uno de los posibles resultados de este suceso?
Resumen del capítulo •
La minería de datos es el proceso de extraer información válida, previamente desconocida, comprensible y útil partiendo de bases de datos de gran tamaño, y utilizar dicha información para tomar decisiones de negocio cruciales.
•
Hay cuatro operaciones principales asociadas con las técnicas de minería de datos: modelado predictivo, segmentación de la base de datos, análisis·€le enlaces y detección de desviaciones.
•
Las técnicas son implementaciones específicas de las operaciones (algoritmos) que se utilizan para llevar a cabo las operaciones de minería de datos. Cada operación tiene sus propias fortalezas y debilidades.
•
El modelado predictivo puede utilizarse para analizar una base de datos existente con el fin de determinar ciertas características esenciales (modelo) acerca del conjunto de datos. El modelo se desarrolla utilizando un enfoque de aprendizaje supervisado, que consta de dos fases: entrenamiento y prueba. Entre las aplicaciones del modelado predictivo podemos citar la gestión de las tasas de retención de los clientes, aprobación del crédito de los clientes, ventas cruzadas y marketing directo. Son dos las técnicas asociadas: clasificación y predicción de valores.
•
La segmentación de la base de datos particiona una base de datos en un número desconocido de segmentos o clústeres de registros similares. Este enfoque utiliza el aprendizaje no supervisado para descubrir subconjuntos homogéneos dentro de una base de datos, con el fin de mejorar la precisión de los perfiles.
•
El análisis de enlaces trata de establecer enlaces, denominados asociaciones, entre los registros individuales o conjuntos de registros de una base de datos. Hay tres tipos de análisis de enlaces: descubrimiento de asociaciones, descubrimiento de patrones secuenciales y descubrimiento de secuencias temporales similares. El descubrimiento de asociaciones localiza elementos que implican la presencia de otros elementos en el mismo suceso. El descubrimiento de patrones secuenciales trata de localizar patrones entre sucesos tales que la presencia de un conjunto de elementos se vea seguida de otro conjunto de elementos en una base de datos de sucesos producidos a lo largo de un periodo de tiempo. El descubrimiento de secuencias temporales similares se utiliza, por ejemplo, en el descubrimiento de datos entre dos conjuntos de datos que dependen del tiempo, y se basa en el grado de similitud entre los patrones exhibidos por ambas series temporales.
Capítulo 34 Minería de datos
1127
•
La detección de desviaciones es a menudo una fuente de verdaderos descubrimientos de conocimiento, porque permite identificar excepciones, que expresan una desviación con respecto a las expectativas o a una norma previamente conocida. Esta operación puede realizarse utilizando técnicas estadísticas y de visualización o como subproducto de la minería de datos.
•
La especificación CRISP-DM (Cross Industry Standard Process for Data Mining) describe un modelo de proceso de minería de datos que no es específico de ningún sector ni herramienta concretos.
•
Las características más importantes de las herramientas de minería de datos son: las funciones de preparación de datos; la selección de operaciones de minería de datos (algoritmos), la escalabilidad y las prestaciones; y las facilidades existentes para comprender los resultados.
•
Un almacén de datos está bien preparado para proporcionar información para las operaciones de minería de datos, ya que el almacén de datos no sólo almace~a datos de alta calidad y de una gran coherencia, que proceden de múltiples fuentes, sino que además es capaz de proporcionar subconjuntos (vistas) de los datos para su análisis y también puede proporcionar detalles de menor nivel sobre los datos de origen cuando así se requiera.
Cuestiones de repaso 34.1.
Explique qué es la minería de datos.
34.2.
Proporcione ejemplos de aplicaciones de minería de datos.
34.3.
Describa cómo se aplican las siguientes operaciones de minería de datos y proporcione ejemplos típicos de cada uno: (a)
modelado predictivo,
(b)
segmentación de la base de datos,
(c)
análisis de enlaces,
(d)
detección de desviaciones.
y fases
principales del modelo CRISP-DM.
34.4.
Describa los objetivos
34.5.
Proporcione ejemplos de las características más importantes de las herramientas de minería de datos.
34.6.
Explique la relación existente entre los almacenes de datos y las técnicas de minería de datos.
34.7.
Explique el soporte que Oracle proporciona para las técnicas de minería de datos.
Ejercicios 34.8.
Considere cómo podría beneficiarse una empresa como DreamHome de las técnicas de minería de datos. Explique, utilizando ejemplos, las operaciones de minería de datos que podrían aplicarse con más éxito en el caso de DreamHome.
34.9.
Averigue si su organización (su empresa o su universidad) ha invertido en tecnologías de minería de datos y, en c!lso afirmativo, verifique si las herramientas de minería de datos forman parte de una inversión de mayor envergadura en tecnologías de inteligencia empresarial. En caso de que sea posible, determine las razones por las que su organización está interesada en la minería de datos, averigue cómo se están aplicando las herramientas y compruebe si se han obtenido beneficios de la utilización de estas tecnologías.
Apéndices
A Especificación DreamHome
de requisitos de usuario para el caso de estudio de
B Otros casos de estudio C Organizaciones de archivos e índices
o
¿Cuándo es relacional un SGBD?
E
Sal procedimental
F Notaciones alternativas
para modelado ER
G Resumen de la metodología de diseño de bases de datos relaciona les
pénalce
Especificación de requisitos de usuario para el caso de estudio de DreamHome Objetivos En este apéndice aprenderá: •
Los requisitos de datos y de transacciones para las vistas de usuario Branch y Staff del caso de estudio DreamHome descrito en la Sección lOA.
Este apéndice describe la especificación de requisitos de usuario para las vistas de usuario Branch y Staff del sistema de base de datos de DreamHome. Para cada colección de vistas de usuario, la sección 'Requisitos de datos' describe los datos utilizados y la sección 'Transacciones de datos' proporciona ejemplos de utilización de dichos datos.
A.1 Vistas de usuario Branch de DreamHome A.1.1
Requisitos de datos
Sucursales DreamHome tiene sucursales en diversas ciudades del Reino Unido. Cada sucursal tiene una serie de empleados, incluyendo un Director (Manager) para gestionar las operaciones de la sucursal. Los datos que se almacenan en una sucursal incluyen un identificador de sucursal unívoco, una dirección (calle, ciudad y código postal), números telefónicos (hasta un máximo de tres) y el nombre del empleado que dirige actualmente la sucursal. Para cada uno de los directores de sucursal se almacenan datos adicionales, que incluyen la fecha en la que el Director fue nombrado para dirigir la sucursal y un incentivo mensual monetario basado en los objetivos logrados para el mercado de los inmuebles en alquiler.
Empleados Los empleados con el rol de Supervisor son responsables de las actividades cotidianas de una serie de empleados dependientes de ellos y que tienen la categoría de asistentes (Assistant), pudiendo cada supervisor tener un máximo de 10 asistentes en cualquier momento determinado. No todos los empleados están asignados a un supervisor. Para cada empleado se almacenan una serie de datos que incluyen el número de empleados, el nombre, la dirección, la categoría laboral, el salario, el nombre del Supervisor (cuando corresponda) y los detalles de la sucursal en la que trabaja actualmente. El número de empleado es unívoco entre todas las sucursales de DreamHome.
Inmuebles en alquiler Cada sucursal ofrece diversos inmuebles en alquiler. Los datos almacenados para cada inmueble incluyen el número de inmueble, la dirección (calle, ciudad, código postal), el tipo, el número de habitaciones, el importe del alquiler mensual y los detalles concernientes al propietario del inmueble. El número de inmueble es uní-
1132
Sistemas de bases de datos
vaca entre todas las sucursales. La gestión de cada inmueble se asigna a un empleado, independientemente de si el inmueble ya está alquilado o necesita alquilarse. Un empleado puede gestionar un máximo de 100 inmuebles en alquiler simultáneamente.
Propietarios de los inmuebles También se almacenan d~talles sobre los propietarios de los inmuebles. Hay dos tipos principales de propietario de inmuebles: propietarios privados (personas físicas) y propietarios de carácter empresarial (personas jurídicas). Los datos almacenados acerca de los propietarios privados incluyen el número de propietario, el nombre, la dirección y el número telefónico. Los datos almacenados para los propietarios de carácter empresarial incluyen el nombre de la empresa, el tipo de empresa, la dirección, el número telefónico y el nombre de contacto.
Clientes En DreamHome, se denominan clientes a las personas interesadas en alquilar un inmueble como inquilinos. Para llegar a ser cliente, una persona debe primero registrarse en una sucursal de DreamHome. Los datos almacenados sobre los clientes incluyen el número de cliente, el nombre, el número telefónico, el tipo preferido de inmueble y el importe máximo de alquiler que el cliente está dispuesto a pagar. También se almacena el nombre del empleado que ha procesado el registro, la fecha en la que el cliente se ha registrado y algunos detalles acerca de la sucursal en la que se ha registrado el cliente. El número de cliente es unívoco entre todas las sucursales de DreamHome.
Contratos de alquiler Cuando se alquila un inmueble, se redacta un contrato entre el cliente y el propietario. En el contrato se detallan diversas informaciones, como el número de contrato, el número de cliente, el nombre y dirección del cliente, el número del inmueble y la dirección en la que se encuentra, el importe del alquiler mensual, el modo de pago, una indicación de si se ha hecho un depósito (el depósito es equivalente a dos veces el importe del alquiler mensual), la duración del contrato y las fechas en las que se inicia y vence el contrato.
Periódicos En caso necesario, los detalles acerca de los inmueble s en alquiler se anuncian en periódicos locales y nacionales. Los datos almacenados incluyen el número de inmueble, la dirección, el tipo, el número de habitaciones, el importe mensual de alquiler, la fecha en la que se publicó el anuncio, el nombre del periódico y el coste del anuncio. Para cada periódico los datos que se almacenan son el nombre del periódico, la dirección, el número telefónico y el nombre de contacto.
A.1.2 Requisitos de transacciones (ejemplos) Introducción
de datos
Introducir los detalles de una nueva sucursal (como por ejemplo la sucursal B003 en Glasgow). Introducir los detalles de un nuevo empleado en una cierta sucursal (como por ejemplo Ann Beech en la sucursal B003). Introducir los detalles de un contrato de alquiler para un cierto cliente y un cierto inmueble (por ejemplo el cliente Mike Ritchie, que alquila el inmueble número PG4 desde ellO de mayo de 2003 al 9 de mayo de 2004). Introducir los detalles de un inmueble anunciado en un periódico (como por ejemplo el inmueble número PG4, anunciado en el periódico local de Glasgow el 6 de mayo de 2003).
Actualización/borrado
de datos
Actualizar/borrar
los detalles de una sucursal.
Actualizar/borrar
los detalles de un empleado en una cierta sucursal.
A Especificación
Actualizar/borrar Actualizar/borrar dico.
de requisitos de usuario para el caso de estudio de DreamHome
1133
los detalles de un cierto contrato de alquiler en una cierta sucursal. los detalles de un anuncio que una cierta sucursal ha publicado en un determinado perió-
Consultas de datos Ejemplos de consultas requeridas para las vistas de usuario Branch: (a) Enumerar los detalles de las sucursales existentes en una cierta ciudad. (b) Identificar el número total de sucursales en cada ciudad. (c) Enumerar el nombre, posición y salario de los empleados de una cierta sucursal, ordenando el listado alfabéticamente según los apellidos de los empleados. (d) Identificar el número total de empleados y la suma de sus salarios. (e) Identificar el número total de empleados de cada categoría laboral en las sucursales de Glasgow. (f) Indicar el nombre de los directores de las distintas sucursales, ordenados según la dirección de las sucursales. (g) Enumerar los nombres de los empleados supervisados por un determinado Supervisor. (h) Enumerar el número de inmueble, la dirección, el tipo y el importe del alquiler para todos los inmuebles de Glasgow, ordenados según el importe del alquiler. (i) Enumerar los detalles de los inmuebles en alquiler gestionados por un determinado empleado.
(j) Identificar el número total de inmuebles asignados a cada empleado de una cierta sucursal. (k) Enumerar los detalles de los inmuebles ofrecidos en alquiler por un cierto propietario de carácter empresarial en una determinada sucursal. (1)
Identificar el número total de inmuebles de cada tipo en todas las sucursales.
(m) Identificar los detalles de los propietarios privados de inmuebles que ofrecen más de un inmueble en alquiler. (n) Identificar los apartamentos con al menos tres habitaciones y con un alquiler mensual no superior a 350 euros en Aberdeen. (o) Enumerar el nombre, número telefónico y número de cliente de todos los clientes de una cierta sucursal, indicando además sus preferencias relativas a los inmuebles. (p) Identificar los inmuebles que han sido anunciados un número de veces superior al promedio. (q) Indicar los detalles de los contratos de alquiler que está previsto que caduquen el mes siguiente en una cierta sucursa1. (r) Indicar el número total de contratos de alquiler cuyo periodo de validez sea inferior a un año, para todas las sucursales de Londres. (s) Enumerar el importe total de alquiler diario de inmuebles en cada sucursal, ordenando los resultados según el número de sucursal.
A.2 Vistas de usuario Staff para DreamHome A.2.1
Requisitos de datos
Empleados Los datos requeridos sobre los empleados incluyen el número de empleado, el nombre (nombre y apellido), la categoría laboral, el sexo, la fecha de nacimiento y el nombre del Supervisor (cuando sea aplicable). Los empleados que tienen categoría de Supervisor controlan a un grupo de empleados asignados (hasta un máximo de 1O simultáneamente).
1134
Sistemas de bases de datos
Inmuebles en alquiler Los datos almacenados sobre los inmuebles en alquiler incluyen el número de inmueble, la dirección (calle, ciudad y código postal), el tipo, el número de habitaciones, el alquiler mensual y los detalles relativos al propietario del inmueble. El alquiler mensual de un inmueble se revisa anualmente. La mayoría de los inmuebles alquilados por DreamHome son apartamentos. La gestión de cada inmueble se asigna a un empleado, independientemente de si el inmueble está todavía por alquilarse o ya ha sido alquilado. Cada empleado no puede gestionar más de 100 inmuebles en alquiler al mismo tiempo.
Propietarios de los inmuebles Hay dos tipos principales de propietarios de inmuebles: propietarios privados (personas físicas) y propietarios de carácter empresarial (personas jurídicas). Los datos almacenados sobre los propietarios privados incluyen el número de propietario, el nombre y el apellido, la dirección y el número telefónico. Los datos almacenados sobre los propietarios de carácter empresarial incluyen el número de propietario, el nombre de la empresa, el tipo de empresa, la dirección, el número de teléfono y el nombre de contacto.
Clientes Cuando un cliente prospecto se registra en la base de datos de DreamHome, los datos que se almacenan incluyen el número de cliente, el nombre y el apellido, el número de teléfono y algunos datos sobre los inmuebles deseados, incluyendo el tipo preferido de inmueble y el importe máximo de alquiler que el cliente está dispuesto a pagar. También se almacena el nombre del empleado que ha registrado al nuevo cliente.
Visitas a inmuebles Los clientes pueden solicitar ver el inmueble. Los datos que se almacenan para cada visita incluyen el número de cliente, el nombre y el número de teléfono, el número de inmueble y su dirección, la fecha en la que el cliente ha visitado el inmueble y los comentarios que el cliente haya hecho referidos a la posible adecuación del inmueble a sus preferencias. Un cliente puede visitar un cierto inmueble una única vez en cada fecha determinada.
Contratos de alquiler Una vez que un cliente encuentra un inmueble adecuado, se redacta un contrato. La información que se guarda sobre el contrato incluye el número de contrato, el número y el nombre del cliente, el número de inmueble, la dirección, el tipo, el número de habitaciones, el importe del alquiler mensual, el modo de pago, la fianza (que se calcula como dos veces el importe del alquiler mensual), una indicación de si se ha pagado la fianza, la fecha en la que se inicia y se termina el contrato de alquiler y la duración del contrato. El número de alquiler es unívoco entre todas las sucursales de DreamHome. Un cliente puede firmar un contrato para un cierto inmueble por un mínimo de tres meses y un máximo de un año.
A.2.2 Requisitos de transacciones (ejemplo) Introducción
de datos
Introducir los detalles de un nuevo inmueble y de su propietario (como por ejemplo los detalles del inmueble número PG4 en Glasgow, propiedad de Tina Murphy). Introducir los detalles de un nuevo cliente (como por ejemplo los detalles de Mike Ritchie). Introducir los detalles de la visita de un cliente a un inmueble (como por ejemplo la visita del cliente Mike Ritchie al inmueble número PG4 en Glasgow el 6 de mayo de 2003). Introducir los detalles de un contrato de un cliente para un cierto inmueble (como por ejemplo el alquiler del inmueble número PG4 por parte del cliente Mike Ritchie del 10 de mayo de 2003 al 9 de mayo de 2004).
A Especificación
de requisitos de usuario para el caso de estudio de DreamHome
Actualización/borrado
de datos
Actualizar/borrar
los detalles de un inmueble.
Actualizar/borrar Actualizar/borrar Actualizar/borrar Actualizar/borrar
los los los los
detalles detalles detalles detalles
1135
de de de de
un propietario de inmueble. un cliente. una visita de un cliente a un inmueble. un contrato.
Consultas de datos Ejemplos de consultas requeridas para las vistas de usuario Staff: (a) Enumerar los detalles de los empleados supervisados por un determinado sucursal.
Supervisor en una cierta
(b) Enumerar los detalles de todos los asistentes de una cierta sucursal, ordenados alfabéticamente por apellidos. (c) Enumerar los detalles de los inmuebles (incluyendo la fianza) que están disponibles para ser alquilados en una cierta sucursal, junto con los detalles de los correspondientes propietarios. (d) Enumerar los detalles de los inmuebles gestionados por un determinado empleado en una cierta sucursal. (e) Enumerar los clientes que se han registrado en una cierta sucursal y los nombres de los empleados que los han registrado. (f) Identificar las propiedades ubicadas en Glasgow y que tengan un alquiler mensual no superior a 450 euros. (g) Identificar el nombre y el número de teléfono del propietario de un cierto inmueble. (h) Indicar los comentarios realizados por los clientes que han visitado un cierto inmueble. (i) Mostrar el nombre y número de teléfono de los clientes que han visitado un cierto inmueble pero no han realizado ningún comentario.
(j) Mostrar los detalles de un cierto contrato, para un cierto cliente y un cierto inmueble. (k) Identificar los contratos que vencen al mes siguiente en una cierta sucursal. (1) Enumerar los detalles de los inmuebles que hace más de tres meses que no se alquilan. (m) Generar una lista de clientes cuyas preferencias se correspondan con un determinado inmueble.
••
Apénaice
...
Otros casos de estudio
Objetivos En este apéndice aprenderá: •
El caso de estudio University Accommodation Office, que describe los requisitos de datos y de transacciones de un departamento de alojamientos para universitarios.
•
El caso de estudio EasyDrive School of Motoring, que describe los requisitos de datos y de transacciones de una autoescuela.
•
El caso de estudio Wellmeadows Hospital, que describe los requisitos de datos y de transacciones de un hospital.
Este apéndice describe el caso de estudio University Accommodation Office en la Sección B.l, el de EasyDrive School of Motoring".en la Sección B.2 y el de Wellmeadows Hospital en la Sección B.3. El lector interesado puede encontrar casos de estudio adicionales en Connolly y Begg (2003).
B.1 Caso de estudio University Accommodation Office El Director del departamento de alojamientos universitarios nos pide que diseñemos una base de datos que sirva de ayuda para la administración del departamento. La fase de recopilación y análisis de requisitos, dentro del proceso de diseño de la base de datos, nos da la siguientes especificación de requisitos de datos para la base de datos University Accommodation Office, junto con determinados ejemplos de las transacciones de consulta que la base de datos debe soportar.
B.1.1 Requisitos de datos Estudiantes Los datos almacenados sobre cada estudiante a tiempo completo incluyen: el número de matrícula, el nombre y apellido, la dirección personal (calle, ciudad, código postal), la fecha de nacimiento, el sexo, la categoría de estudiante (por ejemplo, estudiante de primer año, estudiante de postgrado), la nacionalidad, una indicación de si es o no fumador, las necesidades especiales que pueda tener el estudiante, los comentarios adicionales, el estado actual (alojado/en espera) y el curso que está estudiando. La información almacenada sobre los estudiantes se refiere a aquellos que ya estén alquilando una habitación y a aquellos que estén en la lista de espera. Los estudiantes pueden alquilar una habitación en una residencia universitaria o en un piso de estudiantes. Cuando un estudiante ingresa en la Universidad, se le asigna a un empleado, que actúa como consejero curricular. El consejero curricular es responsable de supervisar si el estudiante se encuentra adecuadamente
1138
Sistemas de bases de datos
atendido y de controlar también su progreso académico mientras permanece en la Universidad. Los datos que se almacenan sobre el consejero (Advisor) de un estudiante incluyen el nombre completo, su categoría, el nombre del departamento, el número de teléfono interno y su número de habitación.
Residencias de estudiantes Cada residencia de estudiantes tiene un nombre, una dirección, un número de teléfono y un director que supervisa el funcionamiento de la residencia. Las residencias sólo proporcionan habitaciones individuales, que tienen un número de habitación, un número de identificación y un importe de alquiler mensual. El número de identificación de la habitación identifica unívocamente a cada habitación entre todas las residencias controladas por el departamento de alojamientos, y se utiliza a la hora de alquilar una habitación a un estudiante.
Pisos de estudiantes El Departamento de alojamientos también ofrece pisos de estudiantes. Estos pisos están completamente amueblados y proporcionan habitaciones individuales para grupos de tres, cuatro o cinco estudiantes. La información que se almacena sobre los pisos de estudiantes incluye el número de apartamento, la dirección y el número de habitaciones individuales disponibles en cada apartamento. El número de apartamento identifica unívocamente cada piso. Cada habitación de un apartamento tiene un importe mensual de alquiler asociado, un número de habitación y un número de identificación que es unívoco para todas las habitaciones disponibles en todos los pisos de estudiante; este número de identificación se utiliza a la hora de alquilar una habitación a un estudiante.
Contratos Un estudiante puede alquilar una habitación en una residencia o en un piso de estudiantes durante varios periodos de tiempo. Los nuevos contratos de alquiler se negocian al principio de cada año académico, siendo el periodo mínimo de alquiler de un semestre y el periodo máximo de un año, lo que incluye los semestres 1 y 2 y el semestre de verano. Cada contrato de alquiler individual entre un estudiante y el departamento de alojamientos se identifica de manera unívoca utilrzando un número de contrato. Los datos almacenados sobre cada contrato incluyen el número de contrato, la duración del contrato (en semestres), el nombre y número de matrícula del estudiante, el número de identificación y número de habitación, los detalles relativos a la dirección de la residencia del piso de estudiantes y la fecha en la que el estudiante quiere comenzar a vivir en esa habitación, así como la fecha en la que piensa abandonada (si es que se conoce).
Facturas Al principio de cada semestre, se envía a cada estudiante una factura para el siguiente periodo de alquiler. Cada factura tiene un número de factura unívoco. Los datos almacenados sobre cada factura incluyen el número de factura, el número de contrato, el semestre, el pago que hay que realizar, el nombre completo y número de matrícula del estudiante, el número de habitación y número de identificación de la habitación, y la dirección de la residencia o piso de estudiantes. También se almacenan datos adicionales sobre el pago de la factura, lo que incluye la fecha en la que se pagó la factura, el modo de pago (cheque, efectivo, Visa, etc.), y la fecha en que se han enviado el primer y segundo recordatorio (en caso necesario).
Inspecciones de los pisos de estudiantes Los pisos de estudiantes son inspeccionados por los empleados de manera periódica para garantizar que los alojamientos estén adecuadamente conservados. La información que se registra para cada inspección es el nombre del empleado que lleva a cabo la inspección, la fecha en la que se llevó a cabo, una indicación de si el inmueble estaba en condiciones satisfactorias o no y, posiblemente, una serie de comentarios adicionales.
B Otros casos de estudio
Personal del departamento
1139
de alojamientos
También se almacena información sobre los empleados del departamento de alojamientos, lo que incluye el número de empleado, el nombre y apellidos, la dirección personal (calle, ciudad, código postal), la fecha de nacimiento, el sexo, la categoría (por ejemplo, Director de residencia, Asistente administrativo, Limpiador) y la ubicación (por ejemplo, departamento de alojamientos o residencia).
Cursos El departamento de alojamientos guarda también una cantidad limitada de información sobre los cursos ofrecidos por la Universidad, incluyendo el número de curso, el título del curso (lo que incluye el año), la persona que imparte el curso, el número de teléfono interno, el número de habitación y el nombre del departamento. Cada estudiante es asociado con un único curso.
Parientes Siempre que sea posible, se almacena información sobre algún pariente de cada estudiante, lo que incluye el nombre, la relación con el estudiante, la dirección (calle, ciudad, código postal) y el número de teléfono de contacto.
8.1.2 Transacciones de consulta (ejemplos) A continuación se muestran algunos ejemplos de transacciones de consultas que deberá soportar el sistema de base de datos del Departamento de alojamientos de la Universidad. (a) Presentar un informe que indique el nombre y el número de teléfono del Director de cada residencia de estudiantes. (b) Presentar un informe que indique el nombre y el número de matricula de todos los estudiantes, junto con los detalles relativos a sus contratos de alquiler. (c) Mostrar los detalles de"¡os contratos de alquiler que estén vigentes en el semestre de verano. (d) Mostrar los detalles relativos al alquiler total pagado por un cierto estudiante. (e) Presentar un informe sobre los estudiantes que no hayan pagado sus facturas en una fecha determinada. (f) Mostrar los detalles de las inspecciones de los pisos de estudiantes, para todos los casos en los que el inmueble no estuviera en condiciones satisfactorias. (g) Presentar un 'informe sobre los nombres y números de matrículas de los estudiantes que viven en una residencia determinada, junto con su número de habitación y el número de identificación de ésta. (h) Presentar un informe que indique los detalles de todos los estudiantes que están actualmente en la lista de espera para conseguir alojamiento. (i) Mostrar el número total de estudiantes de cada categoría.
(j) Presentar un informe de los nombres y números de matrícula de todos los estudiantes que no han suministrado detalles sobre algún pariente. (k) Mostrar el nombre y el número de teléfono interno del Consejero curricular de un estudiante concreto. (1) Mostrar el alquiler mensual mínimo, máximo y promedio para todas las habitaciones de todas las residencias. (m) Mostrar el número total de habitaciones en cada residencia. (n) Mostrar el número de empleado, el nombre, la edad y el alojamiento actual de todos los empleados del departamento de alojamientos que tengan actualmente más de 60 años.
1140
Sistemas de bases de datos
B.2 Caso de estudio EasyDrive School of Motoring La autoescuela EasyDrive School of Motoring fue fundada en Glasgow en 1992. Desde entonces, la autoescuela ha crecido de manera continuada y ahora dispone de varias sucursales en las principales ciudades de Escocia. Sin embargo, ahora es tan grande la empresa que cada vez hacen falta más administrativos para realizar todo el papeleo. Además, la comunicación y la compartición de información entre las distintas sucursales, incluso dentro de la misma ciudad, es bastante deficiente. El Director de la autoescuela, Dave MacLeod, cree que se están cometiendo demasiados errores y que el éxito de la autoescuela será de corta duración si no hace algo para remediar la situación. Sabe que una base de datos podría ayudar a resolver el problema y nos pide que le ayudemos a crear un sistema de base de datos que soporte la gestión de EasyDrive School of Motoring. El Director ha proporcionado la siguiente descripción breve del modo en el que funciona la autoescuela.
8.2.1 Requisitos de datos Cada sucursal tiene un Director (Manager), que normalmente es también un instructor senior; tiene asimismo varios instructores senior, varios instructores y varios administrativos. El Director es responsable de las operaciones cotidianas de la sucursal. Los clientes deben primero registrarse en una sucursal y esto requiere que rellenen un formulario de solicitud, en el que se registran sus detalles personales. Antes de recibir la primera lección, el cliente debe asistir a una entrevista con un instructor, para que éste verifique cuáles son las necesidades del cliente y para garantizar que el cliente esté en posesión de un permiso de conducir provisional válido. El cliente puede solicitar que le atienda un instructor concreto o pedir que le cambien de instructor en cualquier momento de su aprendizaje. Después de la entrevista, se programa la primera lección. Un cliente puede solicitar lecciones individuales o un conjunto de lecciones, lo que le sale más barato. Cada lección individual es de una hora de duración, comenzando y terminando en la sucursal. Cada lección se lleva a cabo con un instructor concreto y un coche determinado en un cierto momento. Las lecciones dan comienzo a las 8 de la mañana y la última lo hace a las 8 de la tarde. Después de cada lección, el instructor anota el proceso realizado por el cliente y los kilómetros recorridos durante la lección. La autoescuela dispone de un conjunto de vehículos que están adaptados para la enseñanza de la conducción. A cada instructor se le asigna un vehículo concreto. Además de para las lecciones, los instructores pueden utilizar los vehículos para su uso personal. Los vehículos se inspeccionan periódicamente, para revisarlos. Una vez que está listo, el cliente puede solicitar una fecha para realizar el examen de conducir. Para obtener un permiso de conducción normal, el cliente debe aprobar tanto la parte teórica como la práctica del examen. Esto es responsabilidad del instructor garantizar que el cliente está adecuadamente preparado para ambas partes del examen. El instructor no es quien realiza los exámenes y no está presente en el vehículo durante el examen, aunque debe estar disponible para llevar al cliente hasta el lugar donde se realiza el examen y para recogerle luego. Si el cliente no aprueba el examen, el instructor debe anotar los motivos del fracaso.
8.2.2 Transacciones de consulta (ejemplos) El Director ha proporcionado algunos ejemplos de consultas típicas que el sistema de base de datos de EasyDrive School of Motoring debe soportar: (a) Los nombres y números de teléfono de los directores de las distintas sucursales. (b) La dirección completa de todas las sucursales de Glasgow. (c) Los nombres de todos los instructores de sexo femenino de la sucursal de Bearsden en Glasgow. (d) El número total de empleados en cada sucursal. (e) El número total de clientes (pasados y presentes) en cada ciudad. (f) El calendario de citas de la semana entrante para un cierto instructor. (g) Los detalles de las entrevistas realizadas por un cierto instructor. (h) El número total de clientes de sexo masculino y femenino (pasados y presentes) en la sucursal de Bearsden en Glasgow.
B Otros casos de estudio
1141
(i) El número total de empleados que son instructores y tienen más de 55 años de edad, junto con sus respectivos nombres.
(j) El número de registro de los vehículos en los que no se ha detectado ningún fallo. (k) El número de registro de los vehículos usados por los instructores de la sucursal de Bearsden en Glasgow. (1) Los nombres de los clientes que han aprobado el examen de conducir en enero de 2000. (m) Los nombres de los clientes que se han presentado al examen más de tres veces y no han conseguido todavía aprobarlo. (n) El número medio de kilómetros recorridos durante una lección de una hora de duración. (o) El número de empleados administrativos de cada sucursal.
8.3 El caso de estudio Wellmeadows Hospital Este caso de estudio describe un pequeño hospital denominado Wellmeadows, que está ubicado en Edimburgo. Wellmeadows Hospital está especializado en los cuidados a personas ancianas. A continuación se muestra una descripción de los datos almacenados y que el personal del hospital utiliza para soportar la gestión y las operaciones cotidianas de Wellmeadows Hospital.
8.3.1
Requisitos de datos
Departamentos Wellmeadows Hospital tiene 17 departamentos con un total de 240 camas, disponibles para pacientes con estancias cortas y largas y para atención ambulatoria. Cada departamento se identifica de manera uní vaca mediante un número (por ejemplo, departamento 11), Y también mediante un nombre de departamento (por ejemplo, Ortopedia), su ubicación (por ejemplo, Bloque E), el número total de camas y el número de extensión telefónica (por ejemplo, Extn 7711).
Empleados Wellmeadows Hospital tiene un Director Médico, que es el responsable de la gestión del hospital. El Director Médico es quien controla el uso de los recursos hospitalarios (incluyendo los empleados, las camas y los suministros), tratando de que se atienda a todos los pacientes de manera adecuada y con un coste mínimo. Wellmeadows Hospital tiene un Director de Personal que es responsable de garantizar que se asigne el número y tipo apropiados de empleados a cada departamento y a la atención ambulatoria. La información almacenada sobre cada empleado incluye un número de empleado, el nombre y el apellido, la dirección completa, el número de teléfono, la fecha de nacimiento, el sexo, el· número de la seguridad social (National lnsurance number, NIN), la categoría, el salario actual y la escala salarial. También incluye las cualificaciones de cada empleado (lo que incluye la fecha en la que fue obtenida la cualificación, el tipo y el nombre de la institución) y los detalles sobre su experiencia laboral (lo que incluye el nombre de la organización, la categoría y las fechas de incorporación y de terminación del contrato). El tipo de contrato para cada empleado también se almacena, incluyendo el número de horas trabajadas por semana, una indicación de si se trata de un contrato temporal o fijo y el tipo de nómina (semanal/mensual). La Figura B.l muestra un ejemplo de formulario que Wellmeadows Hospital utiliza para registrar los detalles de una empleada llamada Moira Samuel que trabaja en el departamento 11. Todos los departamentos y la sección de atención ambulatoria tienen un empleado con la categoría de Jefe de Enfermería. El Jefe de Enfermería es responsable de controlar las operaciones cotidianas del departamento/ambulatorio. El Jefe de Enfermería dispone de un presupuesto para el departamento y debe garantizar que se utilicen de manera efectiva todos los recursos (empleados, camas y suministros) para la atención de los pacientes. El Director Médico trabaja estrechamente con los Jefes de Enfermería para garantizar el eficiente funcionamiento del hospital.
1142
Sistemas de bases de datos
I I 12-Jul-87 11 Wellmeadows M 37,5 temporal 1C scale (FHospital oStaff T)de Nurse 23-Jan-90 Moira Sexo P 49 WB123423D Samuel 18.760 School Road NIN Position 1-May-93 Female Apellido Fecha Asignado 30-May-61 Charge Nurse BSc Nursing Studies .•• Fecha Fecha de Experiencia laboral .. nacimiento Cualificaciones Detallesa departamento personales de inicio finalización Horas/semana actual ual semanal Fijo o gh University Formulario empleados5011 Número dede empleado: Broxburn . 01506-45633 Tipolas .cualificaciones/referencias Organización Western .. oduzca laboralesHospital adicionales en el reverso~. Nombre
r
Figura 8.1.
Formulario de empleados de We/lmeadows Hospital.
El Jefe de Enfermería es responsable de establecer los horarios semanales de los empleados y debe garantizar que el departamento/ambulatorio tenga el número y tipos correctos de empleados en todo momento, tanto de día como de noche. En una semana determinada, a cada empleado se le asigna para que trabaje en horario de mañana, de tarde o de noche. Además del Jefe de Enfermería, cada departamento tiene una serie de enfermeras senior y junior, doctores y auxiliares. Los especialistas (por ejemplo, fisioterapeutas) pueden estar asignados a varios departamentos del hospital. En la Figura B.2 se muestra un ejemplo de informe de Wellmeadows Hospital donde se enumeran los detalles de los empleados asignados al departamento 11.
Pacientes Cuando un paciente llega por vez primera al hospital, se le asigna un número de identificación de paciente. También se toma nota de una serie de detalles adicionales acerca del paciente, incluyendo el nombre y el ape-
B Otros casos de estudio
Wellmeadows Hospital
Página_l
Asignación
Número de departamento Nombre de departamento
de personal a un departamento
Ward 11 Orthopaedic
Ubicación Block E
Jefe de Enfermería Número de empleado
Semana que comienza el
1143
9-Jan-04
Moira Samuel SOl1
Extn. Tel. 7711
Nurse Robin Plevin 0131-334-9099 Late 5taff Consultant Burns Nurse 01506-67676 0131-334-9100 0131-339-6123 0131-334-5677 No. Empl Laurence Nombre Dirección No.5treet Tel. AmyTurno O'Donnell Categoría Early Night 1 Apple Drive Edinburgh Morgan Russell Carol Cummings 234 Princes Edinburgh 7 23A Glen George Terrace 5treet Edinburgh Broxburn 15 High 5treet
Primera página del informe de Wellmeadows Hospital en el que se enumeran los empleados de un departamento.
Figura 8.2.
llido, la dirección, el número de teléfono, la fecha de nacimiento, el sexo, el estado civil, la fecha en la que ha sido registrado en el hospital y los detalles de algún pariente.
Parientes de los pacientes Se almacenan los detalles de UIíl pariente de capa paciente, lo que incluye su nombre completo, su relación con el paciente, la dirección y el número de teléfono.
Médicos de cabecera Los pacientes llegan normalmente al hospital por indicación de su médico de cabecera. Se almacenan los detalles de los médicos de cabecera, incluyendo su nombre completo, el número de ambulatorio, la dirección y el número de teléfono. Los números de ambulatorio son unívocos para todo el Reino Unido. En la Figura B.3 se muestra un ejemplo· del formulario de registro de pacientes de Wellmeadows Hospital, que se utiliza para registrar los detalles de un paciente llamado Anne Phelps.
Citas de pacientes Cuando un médico de cabecera envía a un paciente a Wellmeadows Hospital, se cita al paciente para ser examinado por un médico del hospital. Cada cita se identifica mediante un número de cita unÍvoco. Se registran los detalles de cada paciente, lo que incluye el nombre y el número de empleado del médico que realiza el examen, la fecha y la hora de la cita y la habitación donde se lleva a cabo el examen (por ejemplo, Habitación E252). Como resultado del examen, el paciente puede tener que acudir al ambulatorio o ingresar en una lista de espera hasta que haya una cama disponible en el departamento apropiado.
Pacientes ambulatorios Los detalles sobre los pacientes ambulatorios también se almacenan, incluyendo el número de paciente, el nombre y el apellido, la dirección, el número de teléfono, la fecha de nacimiento, el sexo y la fecha y la hora de la cita en la clínica ambulatoria.
1144
Sistemas de bases de datos
Wellmeadows Hospital Formulario de registro de pacientes Número de paciente: P10234 Detalles personales Nombre
Anne
Apellido
Phelps
Sexo Female
Dirección 44 North Bridges Cannonmills
No. Te!. 0131-332-4111
Edinburgh, EHl 5GH 12-Dec-33
Fecha nacimiento Fecha registro
Estado civil
Single
21-Feb-04
Detalles pariente Nombre completo Dirección
James Phelps
Relación
Son
145 Rowlands Street Paisley, PA2 5FE
No. Te!. 0141-848-2211
Detalle§. médico de cabecera Nombre completo Dirección
Dr Helen Pearson
No. ambulatorio
E102
22 Cannonqate Way, Edinbur.9!1 EH1 6 TY
Tel No. 0131-332-0012
Figura B.3.
Formulario de registro de pacientes de Wellmeadows Hospital.
Pacientes internos El Jefe de Enfermería y el resto de los médicos de categoría senior son responsables de asignar las camas a los pacientes incluidos en lista de espera. Se registran los detalles relativos a los pacientes que están actualmente en cada departamento y a los que están en lista de espera. Estos detalles incluyen el número de paciente, el nombre y el apellido, la dirección, el número de teléfono, la fecha de nacimiento, el sexo, el estado civil, los detalles relativos al pariente del paciente, la fecha en la que el paciente ingresó en la lista de espera, el departamento solicitado, la estancia prevista en el departamento (en días), la fecha de ingreso en el departamento, la fecha esperada de salida del departamento y la fecha real en la que el paciente lo abandonó, cuando se ea-nace. Cuando un paciente ingresa en el departamento, se le asigna una cama con un número de cama unívoco. En la Figura BA se muestra un ejemplo de informe de Wellmeadows Hospital donde se indican los detalles de los pacientes asignados al departamento 11.
B Otros casos de estudio
Wellmeadows Hospital Asignación de pacientes
Págin~
Jefe de enfermería Número de empleado
Número del Ward 11 departamento Nombre del Orthopoedic departamento Ubicación Block E
Semana que comienza el
1145
16-Jan-04
Moira 5amuel 5011
Extn. Te!. 7711
Duración ingreso 45 17-Jan-04 real 14-Jan-04 18-Jan-04 12-Jan-04 13-Jan-04 Steven Robert cama 16-Jan-04 17-Jan-04 salida 84 Parks Drumtree 14 12-Jan-04 Número Salida Fecha Nombre 15-Jan-04 Ian Thomson 10 17-Jan-04 Peter Smith David ;>7-Jan-04 Black13-Jan-04 ;>5-Jan-04 14-Jan-04 22-Jan-04 79 84 80 87 de lista espera En (días) esperada Fecha
Primera página del informe de Wel/meadows Hospital que enumera los pacientes de un departamento.
Figura 8.4.
Medicación
de los pacientes
Cuando se prescribe medicación a un paciente, se anotan los correspondientes detalles. Esto incluye el nombre y el número del paciente, el nombre y el número de la medicina prescrita, las unidades por día, el modo de administración (por ejemplo; oral, intravenosa) y la fecha de inicio y de finalización de la medicación. Es necesario controlar la medicación (suministros farmacéuticos) proporcionada a cada paciente. En la Figura B.5 se muestra un ejemplo de informe Wellmeadows Hospital que se utiliza para registrar los detalles relativos a la medicación dada a un paciente llamado Robert MacDonald.
Wellmeadows Hospital Informe de medicación de pacientes Número de paciente: Nombre completo
Robert MacDonald
Número de cama
84
Número24-Mar-04 Método fin Fecha Fecha Unid. diarias Nombre Dosis inicio 50 IV Antibiotic killer 10 Oral Pain Descripción 24-Apr-O~ 17-Apr-04 25-Apr-04 2-May-04 Tetracycline 0.5mg/ml lOmg/ml Morphine
Figura 8.5.
P10034
No. departamento Nombre de departamento
Ward 11
Orthopaedic
admin.
Informe de medicación de pacientes de Wel/meadows Hospital.
1146
Sistemas de bases de datos
Suministros quirúrgicos y no quirúrgicos Wellmeadows Hospital mantiene un almacén central de suministros quirúrgicos (por ejemplo, jeringuillas o vestimentas estériles) y no quirúrgicos (por ejemplo, bolsas de plástico o delantales). Los detalles relativos a los suministros quirúrgicos y no quirúrgicos incluyen el número y nombre del elemento, la descripción del elemento, la cantidad existente en almacén, el nivel de petición de repuestos y el coste unitario. El número del elemento identifica de manera unívoca cada tipo de suministro quirúrgico o no quirúrgico. Se controlan los suministros utilizados por cada departamento.
Suministros farmacéuticos El hospital también mantiene una cierta cantidad de suministros farmacéuticos (por ejemplo, antibióticos y analgésicos). Los detalles relativos a los suministros farmacéuticos incluyen el número y nombre de la especialidad farmacéutica (medicina), la descripción, la dosis, el modo de administración, la cantidad que hay en almacén, el nivel de petición de repuestos y el coste unitario. El número de especialidad farmacéutica identifica unívocamente cada tipo de suministro farmacéutico. Se controlan los suministros farmacéuticos utilizados por cada departamento.
Pedidos de los departamentos Cuando sea necesario, el Jefe de Enfermería puede obtener suministros quirúrgicos, no quirúrgicos y farmacéuticos del almacén central de suministros del hospital. Esto se lleva a cabo pidiendo dichos suministros mediante un formulario de pedido de los departamentos. La información contenida en el formulario de pedido incluye un número unívoco de pedido, el nombre del empleado que hace el pedido y el número y el nombre del departamento. También se incluye el número de elemento o de especialidad farmacéutica, su nombre, la descripción, la dosis y el modo de administración (sólo para las especialidades farmacéuticas), el coste unitario, la cantidad requerida y la fecha en la que se realiza el pedido. Cuando se entregan los suministros requeridos al departamento, el formulario debe ser firmado y fechado por el Jefe de Enfermería que ha hecho el pedido. La Figura B.6 muestra un ejemplo de formulario de pedido de Wellmeadows Hospital utilizado para pedir un suministro de morfina para el Departamento 11.
Wellmeadows Hospital Formulario de pedido al almacén central
Número de pedido: Número de departamento Nombre de departamento
No. item/
Orthopaedic
Coste Cantidad 50 unitario Nombre admin. Método 27.75 Pain Oralkiller Descripción Dosis (sólo Morphine lOmg/ml
Recibido por:
Figura B.6.
Ward 11
034567712 Pedido por
Moira Samuel
Fecha pedido
15-Feb-04
medicinas)
Fecha recepción:
Formulario de pedido de departamento
de Wellmeadows
Hospital.
B Otros casos de estudio
1147
Proveedores Es necesario almacenar los detalles relativos a los proveedores de los suministros quirúrgicos, no quirúrgicos y farmacéuticos. Esta información incluye el nombre y el número del proveedor, su dirección, su teléfono y su número de fax. El número de proveedor es unívoco para todos los proveedores.
8.3.2 Requisitos de transacciones (ejemplo) Utilizamos las siguientes transacciones para verificar que esté disponible la información que permita a los empleados gestionar y controlar las operaciones cotidianas del hospital. Cada transacción está asociada con una función específica dentro del hospital. Estas funciones son la responsabilidad de los empleados que tienen una categoría laboral concreta. Se indica entre paréntesis el usuario o grupo de usuarios principal para cada transacción. (a) Crear y mantener registros que indiquen los detalles de los empleados (Jefe de Personal). (b) Localizar los empleados que tengan unas cualificaciones o una experiencia laboral previas determinadas (Jefe de Personal). (c) Generar un informe que indique los detalles de los empleados asignados a cada departamento (Jefe de Personal y Jefe de Enfermería). (d) Crear y mantener registros donde se almacenen los detalles de los pacientes que han acudido al hospital (todos los empleados). (e) Crear y mantener registros donde se indiquen los detalles de los pacientes a los que se les ha enviado a la sección ambulatoria (Jefe de Enfermería). (f) Generar un informe que indique los detalles de los pacientes enviados a la sección ambulatoria (Jefe de Enfermería y Director Médico). (g) Crear y mantener registros donde se indican los detalles de los pacientes enviados a un departamento concreto (Jefe de Enfermería). (h) Generar un informe donde se indiquen los detalles de los pacientes que están actualmente ingresados en un departamento w~creto (Jefe de Enfermería y Director Médico). (i) Generar un informe que indique los detalles de los pacientes que están actualmente en lista de espera para un departamento concreto (Jefe de Enfermería y Director Médico).
(j) Crear y mantener registros donde se indiquen los detalles de la medicación suministrada a un paciente concreto (Jefe de Enfermería). (k) Generar un informe donde se indiquen los detalles relativos a la medicación de un paciente concreto (Jefe de Enfermería). (1) Crear y mantener registros donde se indiquen los detalles de los suministradores del hospital (Director Médico). (m) Crear y mantener registros donde se indiquen los pedidos de suministros realizados por un departamen to concreto (Jefe de Enfermería). (n) Generar un informe donde se indiquen los detalles de los suministros entregados a un departamento concreto (Jefe de Enfermería y Director Médico).
Organizaciones de archivos e índices Objetivos En este apéndice aprenderá: •
La distinción entre el almacenamiento principal y el secundario.
•
El significado de los conceptos de organización de archivos y métodos de acceso.
•
Cómo están organizados los archivos en cúmulo.
•
Cómo están organizados los archivos secuenciales.
•
Cómo están organizados los archivos hash.
•
El concepto de índice y cómo puede utilizarse un índice para acelerar la extracción de información de la base de datos.
•
La diferencia entre índices principales, secundarios y agrupados.
•
Cómo están organizado~ los archivos secuenciales indexados.
•
Cómo están organizados los índices multinivel.
•
Cómo están organizados los árboles binarios.
•
Cómo están organizados los índices en mapa de bits.
•
Cómo están organizados los índices de combinación.
•
Cómo están organizados los clústeres indexados y los clústeres hash.
•
Cómo seleccionar una organización de archivos apropiada.
Los Pasos 4.2 y 4.3 en la metodología de diseño físico de bases de datos presentada en el Capítulo 17 requieren la selección de las apropiadas organizaciones de archivo y de los índices adecuados para las tablas base que hayan sido creadas para representar la parte de la organización que esté siendo modelada. En este apéndice vamos a presentar los conceptos principales concernientes al almacenamiento físico de la base de datos en dispositivos de almacenamiento secundario como discos magnéticos y discos ópticos. El almacenamiento principal de la computadora, es decir, la memoria principal, resulta inapropiado para almacenar la base de datos. Aunque los tiempos de acceso para el almacenamiento principal son mucho más rápidos que para el almacenamiento secundario, el almacenamiento principal no es lo suficientemente grande ni fiable como para almacenar la cantidad de datos que una base de datos típica pueda requerir. Asimismo, como los datos guardados en el almacenamiento principal desaparecen al desconectar la alimentación, decimos que el almacenamiento principal es un tipo de almacenamiento volátil. Por contraste, los datos almacenados en almacenamiento secundario persisten a pesar de que desaparezca la alimentación, por lo que este tipo de almacenamiento se denomina almacenamiento no volátil. Además, el coste de almacenamiento por unidad de datos es un orden de magnitud superior para el almacenamiento principal que para el almacenamiento en disco.
1150
Sistemas de bases de datos
Estructura del apéndice En la Sección C.l se presentan los conceptos básicos del almacenamiento físicos. En las Secciones C.2-CA se explican los tipos especiales de la organización de archivos, que son la realización en cúmulo (desordenada), secuencial (ordenada) y los archivos hash. En la Sección C.S se explica cómo pueden utilizarse los índices para aumentar la velocidad de la extracción de información de una base de datos. En particular, se examinan los archivos secuenciales indexados, los índices multinivel, los árboles binarios, los índices en mapa de bits y los índices de combinación. Finalmente, en la Sección C.6 se proporciona una serie de directrices para seleccionar la adecuada organización de los archivos. Los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome que se documenta en la Sección lOA y en el Apéndice A.
C.1
Conceptos básicos
La base de datos en el almacenamiento secundario está organizada en uno o más archivos, estando compuesto cada archivo de uno o más registros y cada uno de éstos, a su vez, estando formado por uno o más campos. Normalmente, cada registro se corresponde con una entidad y cada campo con un atributo. Considere la tabla 8taft reducida del caso de estudio de DreamHome que se muestra en la Figura C.l. Cabría esperar que cada tupla de esta relación se correspondiera con un registro dentro del archivo del sistema operativo donde esté almacenada la tabla 8taft. Cada campo de un registro almacenaría un valor de atributo de la tabla 8taft. Cuando un usuario solicite una tupla del SGBD, por ejemplo, la tupla SG37 de 8taft, el SGBD establece la correspondencia entre este registro lógico y su registro físico y extrae el registro físico, almacenando la información en búferes del SGBD en el almacenamiento principal, utilizando las rutinas de acceso a archivos del sistema operativo. El registro físico es la unidad de transferencia entre el disco y el almacenamiento principal, y viceversa. Generalmente, un registro físico está compuesto de más de un registro lógico, aunque pudiera ser que un registro lógico se correspondiera con un registro físico, dependiendo de los respectivos tamaños. Sería incluso posible que un registro lógico de gran tamaño abarcara más de un registro físico. En ocasiones, se utilizan los términos bloque y página en lugar del término registro físico. En el resto de este apéndice, emplearemos el término 'página'. Por ejemplo, las tuplas de 8taft en la Figura C.l podrían estar almacenadas en dos páginas, como se muestra en la Figura C.2. El orden en el que se almacenan los registros dentro de un archivo y con el que se accede a esos registros depende de la organización del archivo. Organización de archivo
La disposición física de los datos en un archivo, distribuidos en registros y páginas en el almacenamíento secundario.
Los tipos principales de organización de archivos son: •
Archivos en cúmulo (desordenados).
•
Archivos secuenciales especificado. staffNo Assistant IName Lee Brand Howe White Beech Ford BOOS BOO? branchNo BOO3 position Manager Supervisor
(ordenados).
Los registros se almacenan en disco sin ningún orden concreto . Los registros se ordenan de acuerdo con el valor de un campo
staftNo -SA9 ---SG14 SG3? SL41 SGS SL2!
--
- - - - - ---- -- - - --
BOOS Lee Howe BOO3 BOO? White Beech Ford Assistant Brand IName branchNo Manager position Supervisor
Página
2
Figura C.1. Tabla Staff reducida para el caso de estudio de OreamHome.
Figura C.2. Almacenamiento de la tabla Staff en páginas.
e •
Organizaciones de archivos e índices
1151
Archivos hash. Los registros se almacenan en disco de acuerdo con una función hash.
Además de una organización del archivo, hay un conjunto de métodos de acceso. Método de acceso
Los pasos necesarios para almacenar y extraer registros de un archivo.
Puesto que algunos métodos de acceso sólo pueden aplicarse a ciertas organización de archivo (por ejemplo, no se puede aplicar un método de acceso indexado a un archivo que no disponga de un índice), los términos organización de archivo y método de acceso se suelen usar de forma intercambiable. En el resto de este apéndice, presentaremos los tipos principales de organización de archivos y las principales técnicas de acceso y proporcionaremos una serie de directrices de uso.
C.2
Archivos desordenados
Un archivo desordenado, que en ocasiones se denomina archivo en cúmulo, representa el tipo más simple de organización de archivo. Los registros se almacenan en el archivo en el mismo orden en que se los inserta. Cada nuevo registro se insertará en la última página del archivo; si no hay suficiente espacio en la última página, se añade al archivo una página nueva. Esto hace que la inserción sea muy eficiente, sin embargo, como un archivo en cúmulo no tiene ninguna ordenación concreta en lo que respecta a los valores de los campos, es necesario efectuar una búsqueda lineal para acceder a cada registro. Una búsqueda lineal implica leer páginas del archivo hasta encontrar el registro deseado, lo que hace que la extracción de información de los archivos en cúmulo que tengan más de unas pocas páginas sea relativamente lenta, a menos que esa operación de extracción implique un gran porcentaje de los registros del archivo. Para borrar un registro, primero es necesario extraer la página requerida, marcar el registro como borrado y volver a escribir la página en disco. El espacio correspondiente a los registros borrados no se reutiliza. En consecuencia, la velocidad se va deteriorando a medida que se van haciendo más borrados. Esto significa que los archivos en cúmulo tienen que ser reorganizados periódicamente por el administrador de la base de datos, con el fin de recuperar el espacio no utilizado correspondiente a los registros borrados. Los archivos en cúmulo son uno de los mejores tipos de organización de archivos para la carga masiva de datos en una tabla, ya que los registros se insertarán al final de la secuencia, no existiendo ninguna necesidad de calcular la página a la que corresponde el registro.
C.3
Archivos ordenados
Los registros de un archivo pueden ordenarse de acuerdo con los valores de uno o más de los campos, formando así un conjunto de datos dotados de una secuencia basada en una cierta clave. El archivo resultante se denomina archivo ordenado o secuencial. Los campos de acuerdo con los cuales se ordena el archivo se denomina campos de ordenación. Si el campo o campos de ordenación son también una clave del archivo, estando por tanto garantizado que cada registro tendrá un valor unívoco, el campo se denomina también clave de ordenación del archivo. Por ejemplo, considere la siguiente consulta SQL: SELECT * FROMStaff
ORDER BY
staffNo;
Si las tuplas de la tabla Staff ya están ordenadas de acuerdo con el campo de ordenación staffNo, debería ser posible reducir el tiempo de ejecución de la consulta, ya que no es necesario efectuar ninguna operación de ordenación (aunque en la Sección 3.2 hemos indicado que las tuplas están desordenadas, esto se aplica como propiedad externa, es decir, lógica, y no como propiedad física, es decir, de la implementación. Siempre habrá un primer registro, un segundo registro y un registro n-ésimo). Si las tuplas están ordenadas de acuerdo con el valor de staffNo, bajo ciertas condiciones podremos utilizar una búsqueda binaria para ejecutar aquellas consultas que tengan una condición de búsqueda basada en staffNo. Por ejemplo, considere la siguiente consulta SQL:
1152
Sistemas de bases de datos
3
2
Página SA9
5
4
SG5
6 SL41
~
SG37
(1)
(3)
~
(2)
i~ Figura C.3.
SELECT * FROM Staff WHERE staffNo
Búsqueda binaria en un archivo ordenado.
= 'SG37';
Si utilizamos las tuplas de ejemplo mostradas en la Figura C.I y asumimos, por simplicidad, que hay un único registro por cada página, obtendríamos el archivo ordenado que se muestra en la Figura C.3. La búsqueda binaria tendría lugar de la forma siguiente: (1) Extraer la página situada en la mitad del archivo. Comprobar si el registro requerido se encuentra entre el primer y el último registro de esta página. Si es así, el registro requerido estará dentro de la página y no hace falta extraer ninguna página adicional. (2) Si el valor del campo clave del primer registro de la página es superior al valor requerido, éste (en caso de que exista) estará contenido en una página anterior. Por tanto, repetimos los pasos anteriores utilizando la mitad inferior del archivo como nueva área de búsqueda. (3) Si el valor del campo clave en el último registro de la página es inferior al valor requerido, el valor requerido estará en una página posterior, por lo que repetiremos los pasos anteriores utilizando la mitad superior del archivo como nueva área de búsqueda. De esta forma, se elimina la mitad del espacio de búsqueda con cada página que se extrae': En nuestro caso, la página situada en el centro del archivo es la página 3 y el registro de la página extraída (SOI4) no es igual al que buscamos (S037). El valor del campo clave de la página 3 es inferior al que buscamos, por lo que podemos descartar la primera mitad del archivo, limitando así el espacio de búsqueda. Ahora extraemos la página intermedia de la mitad superior del archivo, es decir, la página 5. Esta vez, el valor del campo clave (SL21) es superior a (S037), lo que nos permite descartar la mitad superior de este espacio de búsqueda. Extraemos ahora la página intermedia del espacio de búsqueda restante, es decir, la página 4, que corresponde al registro que buscamos. En general, la búsqueda binaria es más eficiente que una búsqueda lineal. Sin embargo, la búsqueda binaria se aplica más frecuentemente a los datos contenidos en almacenamiento principal que a los que se encuentran en almacenamiento secundario. La inserción y borrado de registros en un archivo ordenado son problemáticos, porque es preciso mantener el orden de los registros. Para insertar un nuevo registro, debemos primero averiguar la posición correcta del registro dentro de la secuencia de ordenación y luego localizar el espacio necesario para insertar el registro. Si hay suficiente espacio en la página requerida para el nuevo registro, se puede reordenar esa única página y volverla a escribir en disco. Si no es así, será necesario desplazar uno o más registros a la página siguiente. De nuevo, la página siguiente puede no tener espacio libre y será necesario desplazar los registros de esta página, etc. La inserción de un registro cerca del principio de un archivo de gran tamaño podría requerir mucho tiempo. Una solución consiste en crear un archivo desordenado temporal, denominado archivo de desbordamiento (o de transacción). Las inserciones se añaden al archivo de desbordamiento y este archivo se combina periódicamente con el archivo ordenado principal. Esto hace que las inserciones sean muy eficientes, pero reduce la velocidad de las operaciones de extracción de información. Si el registro no se puede localizar durante la búsqueda binaria, es necesario explorar linealmente el archivo de desbordamiento. A la inversa,
e
Organizaciones de archivos e índices
1153
para borrar un registro debemos reorganizar los registros con el fin de eliminar el espacio que haya quedado libre. Los archivos ordenados se utilizan muy raramente para almacenar bases de datos, a menos que se añada un índice principal al archivo (véase la Sección C.5.l).
C.4
Archivos hash
En un archivo hash, no es necesario escribir los registros secuencialmente en el archivo. En lugar de ello, una función hash calcula la dirección de la página en la que hay que almacenar el registro, basándose en los valores de uno o más campos del registro. El campo base se denomina campo hash o, si el campo es también un campo clave del archivo, se denomina clave hash. Los registros de un archivo hash parecerán estar distribuidos aleatoriamente por todo el espacio asignado al archivo. Por esta razón, los archivos hash se denominan en ocasiones archivos aleatorio s o directos. La función hash se elige de tal manera que los registros estén distribuidos de la manera más uniforme posible por todo el archivo. Una de las técnicas, denominada de plegado, aplica una función aritmética, como por ejemplo la adición, a diferentes partes del campo hash. Las cadenas de caracteres se convierten a valores enteros antes de aplicar la función, utilizando para ello algún tipo de código, como por ejemplo la posición alfabética o los valores Ascn. Por ejemplo, podríamos tomar los primeros dos caracteres del número de empleado, staffNo, convertirlos en un valor entero y luego sumar este valor con los dígitos restantes del campo. La suma resultante se utiliza como dirección de la página de disco en la que se almacenará el registro. Otra técnica alternativa y más popular es la técnica del resto de división. Esta técnica utiliza la función MOD, que toma el valor del campo, lo divide entre algún valor entero predeterminado y usa el resto de esta división como dirección de disco. El problema con la mayoría de las funciones hash es que no garantizan una dirección unívoca, porque el número de posibles valores que un campo hash puede tomar es normalmente muy superior al número de direcciones disponibles para los registros. Cada dirección generada por una función hash corresponde a una página, o bloque, con franjas para múltiples registros. Dentro de un bloque, los registros se almacenan en el orden de llegada. Cuando se genera la misma dirección para dos o más registros, decimos que ha tenido lugar una colisión y los registros se denominan sinónimos. En esta situación, debemos insertar el nuevo registro en otra posición, ya que su dirección hash está ocupada. Los mecanismos de gestión de colisiones complican la gestión de los archivos hash y degradan el rendimiento global. Hay varias técnicas que pueden utilizarse para gestionar las colisiones: •
direccionamiento
abierto;
•
desbordamiento
no encadenado;
•
desbordamiento
encadenado;
•
hash múltiple.
Direccionamiento abierto Si se produce una colisión, el sistema realiza una búsqueda lineal para localizar la primera franja disponible en la que insertar el nuevo registro. Una vez explorado el último bloque, el sistema comienza de nuevo con el primer bloque. Para buscar un registro se emplea la misma técnica que para almacenarlo, salvo porque se considera que el registro no existe si se encuentra una franja no utilizada antes de haber utilizado el registro. Por ejemplo, suponga que tuviéramos una función hash trivial que tomara los dígitos del número de Staff MOD 3, como se muestra en la Figura CA. Cada bloque tiene dos franjas y a los registros SG5 y SG 14 les corresponde el bloque 2. Cuando se inserta el registro SL4l, la función hash genera una dirección correspondiente al bloque 2. Como no hay ninguna franja libre en el bloque 2, se realiza una búsqueda de la primera franja libre, que estará ubicada en el bloque 1, después de haber vuelto al principio y haber explorado el bloque O completo.
1154
Sistemas de bases de datos Antes
Bloque
Registro 8A9 de 8taff Registro 8L21 de 8taff
o
Registro 8G37 de 8taff
Registro 8G5 de 8taff Registro 8G14 de 8taff
Después Registro 8A9 de 8taff Registro 8L41 8L21 8G14 de de 8taff 8taff Registro Registro 8G37 8G5 de de 8taff 8taff
2
Bloque
o
2
Figura C.4. Resolución de colisiones utilizando un direccionamiento abierto.
Bloque Registro 8A9 de 8taff Registro 8L21 de 8taff
o
Área de desbordamiento Registro 8L41 de 8taff
Registro 8G37 de 8taff
Registro 8G5 de 8taff Registro 8G14 de 8taff
Bloque
3 4
2
Figura C.5. Resolución de colisiones utilizando desbordamiento.
Desbordamiento
no encadenado
En lugar de buscar una franja libre, se mantiene un área de desbordamiento para las colisiones que impliquen que no puede almacenarse un registro en su dirocción hash. La Figura C.5 muestra cómo se gestionaría la colisión de la Figura CA utilizando un área de desbordamiento. En este caso, el lugar de buscar una franja libre para el registro SL41, el registro se almacena en el área de desbordamiento. A primera vista, podría parecer que esto no permite mejorar mucho la velocidad. Sin embargo, utilizando el direccionamiento abierto, los registros que generan una colisión se almacenan en la primera franja libre, lo que tiene como consecuencia que puedan provocarse colisiones adicionales en el futuro con otros registros cuya dirección hash corresponda a la dirección de esa franja libre. Así, el número de colisiones se incrementaría y la velocidad se reduciría. Por el contrario, si podemos minimizar el número de colisiones, será más rápido realizar una búsqueda lineal en el área de desbordamiento, que será más pequeña.
Desbordamiento
encadenado
Al igual que con la técnica anterior, se mantiene un área de desbordamiento para aquellas colisiones que impliquen que el registro no puede almacenarse en su dirección hash. Sin embargo, con esta técnica cada bloque tiene un campo adicional, que a veces se denomina puntero de sinónimos, que indica si se ha producido una colisión y, en caso afirmativo, apunta a la página de desbordamiento utilizada. Si el puntero tiene el valor cero, querrá decir que no se ha producido ninguna colisión. En la Figura C.6, el bloque 2 apunta a un bloque de desbordamiento con el número 3; los bloques y 1 tienen un puntero con valor 0, para indicar que todavía no se ha producido ninguna colisión con estos bloques. Una variación de esta técnica proporciona un acceso más rápido al registro de desbordamiento, al utilizar un puntero de sinónimo que apunta a una dirección de franja dentro del área de desbordamiento, en lugar de apuntar a una dirección de bloque. Los registros del área de desbordamiento también tienen un puntero de sinónimo que indica la dirección del área de desbordamiento correspondiente al siguiente sinónimo de la misma dirección hash, por lo que pueden extraerse todos los sinónimos correspondientes a una dirección concreta siguiendo una cadena de punteros.
°
C Organizaciones de archivos e índices Bloque Registro 8A9 de 8taff Registro 8L21 de 8taff
o
Área de desbordamiento Registro 8L41 de 8taff
Registro 8G37 de 8taff
Registro 8G5 de 8taff Registro 8G14 de 8taff
1155
Bloque
3 4
2
Figura C.5. Resolución de colisiones utilizando desbordamiento encadenado.
Hash múltiple Otra técnica alternativa de gestión de colisiones consiste en aplicar una segunda función hash si la primera da como resultado una colisión. El objetivo es generar una nueva dirección hash que evite la colisión. Esa segunda función hash se utiliza generalmente para almacenar los registros en un área de desbordamiento. Con las técnicas de hash, pueden localizarse de manera eficiente un registro aplicando primero la función hash y, si se ha producido una colisión, utilizando una de estas técnicas para localizar su nueva dirección. Para actualizar un registro almacenado con la técnica hash, primero es necesario localizar el registro. Si el campo que hay que actualizar no es la clave de hash, la actualización puede llevarse a cabo sin más problemas, escribiéndose el registro en la misma franja. Sin embargo, si se está actualizando el campo hash, será necesario volver a aplicar la función hash al nuevo valor. Si se genera una nueva dirección hash, será preciso borrar el registro de su franja actual y almacenado en su nueva dirección.
C.4.1
Hash dinámico
Las técnicas de hash anteriores son estáticas, en el sentido de que el espacio de direcciones hash está fijo en el momento de crear el archiv
i
i
i
i
i
1156
Sistemas de bases de datos
Directorio
o
Profundidad
Bloque O I Profundidad local
.1 Registro
8L21 de 8taff Registro 8G37 de 8taff
O
O
(a)
O O
2 O
00 01 2
10 11
Figura C.7. Ejemplo de hash extensible. (a) Después de insertar 8L21 y 8837. (b) Después de insertar 8814. (c) Después de insertar 8A9.
local de cada bloque serán iguales a 1. De nuevo, cuando llega el momento de insertar el siguiente registro SA9, el bloque O vuelve a estar lleno, por lo que tenemos que dividir el bloque basándonos en los dos bits más significativos del valor hash, como se muestra en la Figura C.7(c). El directorio contendrá 22 punteros para los valores de bits 00, 01, 10 Y 11 (i =o 2). La profundidad del directorio y la profundidad local de los bloques O y 2 será igual a 2. Observe que esta operación no afecta al bloque 1, porlo que el directorio para los bits 10 Y 11 apuntan a este mismo bloque, y el puntero de profundidad local del bloque 1 sigue teniendo el valor 1. Cuando un bloque se vacía después de un borrado, puede borrarse junto con su entrada en el directorio. En algunos esquemas, resulta posible combinar bloques y dividir a la mitad el tamaño del directorio.
C.4.2
Limitaciones de las técnicas hash
La utilización de mecanismos hash para la extracción de información dependen del valor completo del campo hash. En general, los mecanismos de organización basados en hash no resultan apropiados para realizar extracciones que estén basadas en correspondencias de patrones o rangos de valores. Por ejemplo, para buscar valores del campo hash que se encuentren dentro de un rango especificado, necesitamos disponer de una función hash que preserve el orden: es decir, si r min Y r máx son los valores mínimo y máximo del rango, necesitamos una función hash h tal que h(r min) < h(r máJ. Además, las técnicas hash no resultan apropiadas para realizar extracciones basadas en un campo que no sea el propio campo hash. Por ejemplo, si la tabla 8taff se organiza utilizando como campo hash staffNo, no se podrá utilizar la técnica hash para buscar un registro basándose
\
e
Organizaciones de archivos e índices
1157
en el campo IName. En este caso, sería necesario realizar una búsqueda lineal para localizar al registro o añadir IName como índice secundario (véase la Sección C.5.3).
e.s índices En esta sección vamos a exponer una serie de técnicas que permiten aumentar la eficiencia de la extracción de los datos utilizando índices. índice
Una estructura de datos que permite al SGBD localizar registros concretos dentro de un archivo más rápidamente, acelerando así la respuesta a las consultas de los usuarios.
Un índice de una base de datos es similar a un índice de un libro. Se trata de una estructura auxiliar asociada con un archivo y que puede consultarse cuando se esté buscando un elemento de información, igual que se hace al buscar en el índice de un libro, cuando buscamos una palabra clave con el fin de obtener una lista de una o más páginas en las que dicha palabra clave aparezca. Los índices eliminan la necesidad de explorar secuencialmente todo el archivo cada vez que queramos encontrar el elemento. En el caso de los índices de bases de datos, el elemento requerido será uno o más registros de un archivo. Al igual que sucede con la analogía del índice de un libro, el índice de una base de datos está ordenado, cada entrada del índice contiene el elemento requerido y una o más ubicaciones (identificadores de registros) en donde puede encontrarse el elemento. Aunque los índices no son estrictamente necesarios para utilizar el SGBD, pueden tener un impacto significativo sobre el rendimiento. Al igual que con el índice del libro, podríamos tratar de localizar la palabra clave deseada examinando el libro completo, pero esto sería muy tedioso y requeriría mucho tiempo. Disponer de un índice al final del libro en orden alfabético de palabras clave nos permite ir directamente a la página o páginas deseadas. Con cada índice de búsqueda concreto se asocia una estructura de índice, que contiene registros compuestos por el valor de la clave y laairección del registro lógico del archivo que contiene dicho valor de clave. El archivo que contiene los registros lógicos se denomina archivo de datos, mientras que el archivo que contiene los registros de índice se denomina archivo de índice. Los valores del archivo de índice se ordenan de acuerdo con el campo de indexación, que usualmente está basado en un único atributo.
C.5.1
Tipos de índices
Hay diferentes tipos de índices, siendo los más importantes: •
Índice principal. El archivo de datos está ordenado secuencialmente mediante un campo clave de ordenación (véase la Sección C.3) y el campo de indexación se construye basándose en el campo clave de ordenación, que se garantiza que tiene un valor unívoco en cada registro.
•
Índice de agrupamiento. El archivo de datos está ordenado secuencialmente según un campo no clave y el archivo de indexación se construye basándose en este campo no clave, por lo que puede haber más de un registro correspondiente a cada valor del campo de indexación. El campo no clave se denomina atributo de agrupamiento.
• Índice índice que está sobre uno campo de no del archivo de puede datos. Un archivo secundaÁo~n puede tener 2omo máximo un definido índice principal un índice de ordenación agrupamiento, y además tener varios índices secundarios. Asimismo, un índice puede ser disperso o denso: un índice disperso dispone de un registro de índice únicamente para algunos de los valores de la clave de búsqueda del archivo. Un índice denso dispone de un registro de índice para todo valor de la clave de búsqueda del archivo. La clave de búsqueda para un índice puede estar compuesta de uno o más campos. La Figura C.8 ilustra cuatro índices densos sobre la tabla Staff (reducida): un basado en la columna salary, otro en la columna branchNo, otro basado en el índice compuesto (salary, branchNo) y, finalmente, otro basado en el índice compuesto (branchNo, salary).
1158
Sistemas de bases de datos
Beech David II branchNo Ford 12000 18000 fName Ann BOOS 30000 IName staffNo B003 IWhite IName John 9000 I BOOS salary I branchNo I~ Julie II Lee9000 I salary BOOS
(salary, branchNo) SG37 SL21 9000, SL41 Ann John SG14 BOOS David
(a) (b)
staffNo
9000
12000, B003
12000
18000, B003
18000
30000, BOOS
30000
branchNo
(branchNo, salary) B003, 12000
B003
B003,18000
B003
BOOS, 9000
BOOS
BOOS,30000
BOOS
Figura C.8.
C.5.2
salary
índices sobre la tabla Staff: (a) (salary, branchNo) y salary; (b) (branchNo, salary) y branchNo.
Archivos secuenciales indexados
Un archivo de datos ordenado con un índice principal se denomina archivo secuencial indexado. Esta estructura es un compromiso entre un archivo puramente secuencial y un archivo puramente aleatorio, en el sentido de que los registros pueden procesarse sec1'1'encialmente o puede accederse individualmente a ellos utilizando un valor de clave de búsqueda mediante el que se accede al registro a través del índice. Un archivo secuencial indexado es una estructura más versátil, que normalmente tiene: •
un área de almacenamiento
•
un índice o índices separados;
principal;
•
un área de desbordamiento.
El método ISAM (Indexed Sequential Access Method, método de acceso secuencial indexado) de IBM utiliza esta estructura, que está estrechamente relacionada con las características del hardware subyacente. Este tipo de archivo necesita ser reorganizado periódicamente para mantener la eficiencia. Dicha reorganización no sólo resulta cara sino que hace que el archivo no esté disponible mientras tiene lugar. Una evolución posterior de este método, VSAM (Virtual SequentialAccess Method, método de acceso secuencial virtual), es una mejora de ISAM, en el sentido de que resulta independiente del hardware. No hay un área de desbordamiento independiente, aunque hay un espacio asignado en el área de datos para permitir la expansión. A medida que el archivo crece y se comprime, el proceso se gestiona dinámicamente sin necesidad de ninguna reorganización periódica. La Figura C.9(a) ilustra un índice denso sobre un archivo ordenado de registros Staff. Sin embargo, como los registros del archivo de datos están ordenados, podemos reducir el índice a un índice dis-
y
Normalmente, una gran de C.9(b un íj~~~principal puede almacenarse en la memoria principal y properso, como se muestra en laparte Figura cesarse de manera más rápida. Con el fin de acelerar todavía más el acceso, pueden emplearse métodos de acceso como el de búsqueda binaria que se explica en la Sección C.3. La principal desventaja de utilizar un índice principal, al igual que sucede con cualquier archivo ordenado, es que es preciso mantener el orden a medida que insertamos y borramos registros. Los problemas se agravan porque tenemos que mantener el
e
--
índice 8A9 8G5 8L41 8G37 8G14 8L21
Organizaciones de archivos e índices
Archivo de datos
1159
Página
>-- Registro R 8G14 de8taft 8taf i-8L21 de8A9 21egistro 3 8G5 de 8G37 de8taft 8taf Registro de 8taft Registro 8L41 de 8taft ...••.
2
3 8G5Registro 8L41 8G37 de de 8taft 8taft 8L41 1
3 2
Registro 8G5 de 8taft Registro Página (a)23 8G14 de 8taft I , Registro Registro 8L21 de8A9 8taftde I8taft
8G37 Archivo de datos
(b)
Figura C.9. Ejemplo de índices densos y dispersos. (a) índice denso. (b) índice disperso.
orden tanto en el archivo de datos como en el archivo de índice. Un método que puede emplearse consiste en mantener un área de desbordamiento con punteros encadenados, de forma similar a la técnica descrita en la Sección CA para la gestión de colisiones en los archivos hash.
C.5.3
índices secundarios
Un índice secundario también es un archivo ordenado, de forma similar a un índice principal. Sin embargo, mientras que el archivo de datos asociado con un índice principal está ordenado según la clave de índice, el archivo de datos asociado con un índice secundario puede no estar ordenado según la clave de indexación. Además, la clave del índice secundario no tiene por qué contener valores unívocos, a diferencia de lo que sucede con un índice .principal. Por ejemplo, podríamos crear un índice secundario sobre la columna branchNo de la tabla 8taft, pero en la Figura C.l podemos ver que los valores de la columna branchNo no son unívocos. Hay diversas técnicas para gestionar los índices secundarios no unívocos: •
Generar un índice secundario denso en el que exista una correspondencia para cada uno de los registros del archivo de datos, permitiendo así que aparezcan valores de clave duplicados en el índice.
•
Permitir que el índice secundario tenga una entrada de indice para cada valor de clave distinto, pero usando punteros de bloque multivaluados, con una entrada por cada valor de clave duplicado en el archivo de datos.
•
Permitir que el índice secundario tenga una entrada de índice por cada valor de clave distinto y hacer que el puntero de bloque apunte no al archivo de datos sino a un bloque que contenga punteros a los
registros correspon~ntro del archivo de datos. Los índices secundarios mejoran el rendimiento de las consultas que utilicen atributos distintos de la clave principal. Sin embargo, esta mejora de la velocidad de las consultas tiene que compararse con los recursos adicionales de procesamiento necesarios para mantener los índices mientras se actualiza la base de datos. Esta tarea forma parte del diseño físico de la base de datos y ya fue analizada en el Capítulo 17.
1160
Sistemas de bases de datos
·
SG5
~ ~ índicenivel2 Página Archivode datos RegistroSG37de Staff RegistroSL41de Staff índicenivel1 III RegistroSA9de I 32 Staff SL41 SG37 RegistroSG14de Staff Staff I RegistroSG5de Staff RegistroSL21de SG37 SL41
Figura C.10.
Ejemplo de un índice multínivel.
C.5.4 índices multinivel Cuando un archivo de índice llega a tener un tamaño considerable y ocupa muchas páginas, el tiempo de búsqueda del índice requerido se incrementa. Por ejemplo, una búsqueda binaria requiere aproximadamente 10g:zP accesos de página para un índice con p páginas. Los índices multinivel tratan de resolver este problema reduciendo el rango de búsqueda. Esto se lleva a cabo tratando el propio índice como cualquier otro archivo, dividiéndolo en una serie de índices más pequeños y manteniendo el índice a dichos índices. La Figura C.lO muestra un ejemplo de un índice parcial de dos niveles para la tabla Staff de la Figura C.l. Cada página del archivo de datos puede almacenar dos registros. Como ejemplo, también hay dos registros de índice por página, aunque en la práctica habría muchos registros de índice en cada página del índice. Cada registro del índice almacena un valor de clave de acceso y una dirección de página. El valor de clave de acceso almacenado es el mayor de los valores dentro de la página direccionada. Para localizar un registro con un valor staffNoespecificado, como por ejemplo SG 14, comenzamos por el índice de segundo nivel y buscamos la página cuyo valor de clave de acceso más alto sea inferior o igual a SG 14, en este caso SG37. Este registro contiene una dirección a la página de índice de primer nivel en la que hay que continuar la búsqueda. Si repetimos efproceso anterior, llegamos a la página 2 del archivo de datos, que es donde está almacenado el registro. Si se hubiera especificado un rango de valores staffNo, podríamos usar el mismo proceso para localizar el primer registro dentro del archivo de datos que se corresponda con el valor mínimo del rango. Puesto que los registros del archivo de datos están ordenados según staffNo,podemos localizar los registros restantes del rango leyendo en serie a través del archivo de datos. La técnica ISAM de IBM está basada en una estructura de índice en dos niveles. La inserción se gestiona mediante páginas de desbordamiento, como se explica en la Sección CA. En general, puede construirse un índice de n niveles, aunque lo común en la práctica es usar tres niveles; un archivo tendría que ser muy grande para requerir más de tres niveles de índice. En la siguiente sección vamos a analizar un tipo concreto de índice denso multinivel, denominado árbol B+.
C.5.5 Árboles B+ Muchos SGBD utilizan una estructura de datos denominada árbol para almacenar datos o índices. Un árbol está compuesto por una jerarquía de nodos. Cada nodo del árbol, excepto el nodo raíz, tiene un nodo padre y cero o más nodo s hijos. El nodo raíz no tiene padre. Un nodo que no tenga ningún hijo se denomina nodo hoja. La profundidad de un árbol es el número máximo de niveles existente entre el nodo raíz y los nodos hoja. La profundidad puede ser distinta según los distintos trayectos que sigamos desde la raíz hasta las hojas, mienen cuyo caso decimos que se trata de un á bol equilibrado o B-tree (Bayer y McCreight, 1972; Comer, 1979). orden puede de un que árbollaes el nú ero máximo hijoselpermitidos cada padre. Cuanto tras queElengrado otros uíndices profun~dad sea igual de desde nodo raíz apor cualquiera de los nodosmayor hoja, sea el grado, más anchos y menos profundos serán, en general, los árboles. Puesto que el tiempo de acceso en una estructura de árbol depende normalmente más de la profundidad que de la anchura, usualmente resulta
e
Organizaciones de archivos e índices
1161
ventajoso tener árboles poco profundos y extensos. Los árboles binarios tienen orden 2, teniendo cada nodo no más de dos hijos. Las reglas para un árbol B+ son las siguientes: •
Si el nodo raíz no es un nodo hoja, debe tener al menos dos hijos.
•
Para un árbol de orden n, cada nodo (excepto el nodo raíz y los nadas hoja) debe tener entre n/2 y n punteros e hijos. Si n/2 no es un entero, el resultado se redondea hacia arriba.
•
Para un árbol de orden n, el número de valores clave en un nodo hoja debe estar comprendido entre (n - 1)/2 Y (n - 1) punteros e hijos. Si (n - 1)/2 no es un entero, el resultado se redondea hacia arriba.
•
El número de valores clave contenidos en un nodo que no sea de hoja es 1 menos que el número de punteros.
•
El árbol debe siempre estar equilibrado: es decir, todo los trayectos desde el nodo raíz hasta las hojas deben tener la misma longitud.
•
Los nadas hoja están enlazados según el orden de los valores de la clave.
La Figura C.ll representa un índice sobre el campo de árbol B+ de orden l. Cada nodo tiene la forma:
D
valorClave¡
D
valorClave¡
staffNo
de la tabla
Staff
mostrada en la Figura C.1, en forma
I
donde· puede estar en blanco o representar un puntero a otro registro. Si el valor de la clave de búsqueda es igualo inferior a valorClave¡, se utiliza el puntero a la izquierda de valorClave¡ para localizar el siguiente nodo en el que hay que buscar; en caso contrario, se utiliza el puntero situado al final del nodo. Por ejemplo, para localizar SL21, comenzamos en el nodo raíz. SL21 es superior a SOI4, por lo que seguimos el puntero de la derecha, que nos conduce al nodo de segundo nivel que contiene los valores de clave S037 y SL21. Seguimos el puntero a la izquierda de SL21, que nos conduce al nodo hoja que contiene la dirección del registro SL21. En la práctica, cada nodo del árbol corresponde a una página, por lo que podemos almacenar más de tres punteros y de dos valores clave. Si asumimos que una página tiene 4096 bytes, que cada puntero tiene 4 bytes de longitud y que el campo staffNo necesita 4 bytes de espacio de almacenamiento, y si asumimos también que cada página tiene un puntero de 4 byte s al siguiente nodo de cada nivel, podríamos almacenar (4096 - 4)/(4 + 4) = 511 registros de índice por cada página. El árbol B+ sería del orden 512. La raíz puede almacenar 511 registros y tener 512 hijos. Cada hijo puede también almacenar 512 registros, lo que da un total de 261.632 registros. Cada hijo puede tener también 512 hijos, lo que nos da un total de 262.144 hijos en el nivel 2 del árbol. Cada uno de esos hijos puede tener 511 registros, lo que da un total de 133.955.584. Esto nos da un número máximo teórico de registros de índice igual a: raíz: Nívell:
511 261.632
Níve12:
133.955.584
TOTAL
134.217.727
Así, podríamos acceder de manera aleatoria a cualquier registro de un archivo Staff que contuviera 134.217.727 registros realizando tan sólo cuatro accesos al disco (de hecho, la raíz se almacenará normalmente en memoria principal, por lo que habra un acceso menos al disco). En la práctica, sin embargo, el número de registros almacenados en cada página sería menor, ya que no todas las páginas estarían llenas (véase la Figura C.ll). \ Con un árbol B+, siempre se tarda aproximadamente lo mismo para acceder a cualquier registro de datos, al garantizarse que se explora el mismo número de nadas; en otras palabras, al garantizar que el árbol tiene una profundidad constante. Al tratarse de un índice denso, todos los registros están direccionados en el índi
1162 Sistemas de bases de datos
Figura C.11.
Ejemplo de índice en árbol B+.
ce, por lo que no es necesario que el archivo de datos esté ordenado; por ejemplo, podría almacenarse como un archivo en cúmulo. Sin embargo, las características de equilibrado del árbol pueden resultar costosas de mantener a medida que el contenido del árbol se actualiza. La Figura C.12 proporciona un ejemplo de cómo se mantendría un árbol B+ a medida que se insertaran registros utilizando el orden de los registros que se muestra en la Figura C.l. La Figura C.12( a) muestra la construcción del árbol después de la inserción de los dos primeros registros, SL21 y SG3 7. El siguiente registro que hay que insertar es SG 14. El nodo está lleno, por lo que debemos dividir el nodo desplazando SL21 a un nodo nuevo. Además, creamos un nodo padre compuesto del valor de clave de más a la derecha del nodo izquierdo, como se muestra la Figura C.12(b). El siguiente registro que hay que insertar es SA9. SA9 debe ubicarse a la izquierda de SGJ4, pero de nuevo el nodo está lleno. Dividimos el nodo desplazando SG37 a un nodo nuevo. También desplazamos SG 14 al nodo padre, como se muestra en la Figura C.12(c). El siguiente registro que hay que insertar es SGS, que debe ubicarse a la derecha de SA9, pero de nuevo no está lleno. Dividimos el nodo moviendo SG 14 a un nodo nuevo y añadiendo SGS al nodo padre. Sin embargo, el nodo padre también está lleno y debe ser dividido. Además, es necesario crear un nuevo nodo padre como se muestra en la Figura C.12(d). Finalmente, se añade el registro SL4J a la derecha de SL2J, como se muestra en la Figura C.l J .
C.5.6
índices de mapa de bits
Otro tipo de índices que cada vez se está haciendo más popular, particularmente en las aplicaciones de almacenes de datos, es el índice de mapa de bits. Los índices de mapa de bits se construyen generalmente sobre atributos que tengan un dominio disperso (es decir, el dominio contiene un número relativamente bajo de valores posibles). En lugar de almacenar el valor real del atributo, el índice en mapa de bits almacena un veclar de bits para cada atributo mediante el que se indica qué tuplas contienen este valor de dominio concreto. Cada bit con el valor 1 dentro del mapa de bits se corresponde con un identificador de fila. Si el número de valores de dominio distintos es pequeño, los índices de mapa de bits son bastante eficientes en términos de espacio. Por ejemplo, considere la relación 8taff mostrada en la Figura C.13(a). Suponga que el atributo position sólo puede uno de los valores presentes (es decir, Manager, Assistant o Supervisor) y suponga también que el atributo branchNo sólo puede tomar uno de los valores que se indican en la figura (es decir, B003, BOOSo B007). C.13(b). Los índices de mapa de bits proporcionan dos ventajas 'mportantes con respecto a los índices de árbol B+. Podríamos construir índices de mapa de bits que para los representabstos dosB+, atributos, comomenos se muestra en la En primer lugar, puede ser más compactos índices n árbol requiriendo espacio de Figura almacenamiento, y se prestan muy bien a utilizar técnicas de compresión. En segundo lugar, los índices de mapa
e
Organizaciones de archivos e índices
1163
de bits pueden proporcionar mejoras significativas de rendimiento cuando la consulta incluye múltiples predicados, cada uno de ellos con su propio índice de mapa de bits. Por ejemplo, considere la consulta: SELECT staffNo, FROM Staff WHERE
salary
position = 'Supervisor'
AND
branchNo
= 'BOQ3';
En este caso, podemos tomar el tercer vector de bits para position y realizar una operación AND bit a bit con el primer vector de bit para branchNo, con el fin de obtener un vector de bits que tenga un 1 para todo Supervisor que trabaje en la sucursal 'B003'.
fTTI (a)
(b)
(e)
(d)
(a) Después de la nserción de 8L21 y 8837. Después en~n de inserción 8814. Figura C.12. (b) Inserciones índice condeestructura de árbol B+. (c) Después de la inserción de 8A9. (d) Después de la inserción de 885.
1164
Sistemas de bases de datos
staffNo3-Jun-40 DOB M branchNo 24-Mar-58 10-Nov-60 I-Oct-45 B003 B005 Ann David 18000 Brand Susan 24000 B007 Howe B005 Assistant Fsalary IName fName sex White Ford Beech 30000 12000 19-Feb-709000 13-Jun-659000 Lee John Julie position Supervisor Manager Mary
(a)
Manager
I1Supervisor I Assistant
B003
OO O O
1 1
I1 B005 B007
O O
1I
O O
O O
(b)
Figura C.13.
C.5.7
(a) Relación Staff. (b) índices de mapa de bits sobre los atributos position y branchNo.
índices de combinación
Otro tipo de índice que también está siendo cada vez más popular, de nuevo en las aplicaciones de almacenes de datos, es el índice de combinación. Un índice de combinación es un índice construido sobre atributos procedentes de dos o más tablas y que se corresponden con el mismo dominio. Por ejemplo, considere las tablas Branch y PropertyForRent ampliadas que ¡re muestran en la Figura C.14( a). Podríamos crear un índice de Branch rowlD
B007 B00522 B00256 London ... B003163 B00432 Bristol Manse MainRd St Rd SWI4EH Deer NWlO6EU Clover Dr branchNo AB23SU BS991NZ street Aberdeen postcode G1l9QX 16Glasgow city ArgyU St
PropertyForRent 450 600 375 rent C087 C093SG37 C040 PGI6 PG21 PG36 PG4 43PL94 56rooms 350 B003 SGI4 SG37 Flat House 52618 Novar Lawrence B003 Dr rowlD C093 C087SUI 400 C046SA9 PAI4 ... 650 AB75SU Aberdeen GI29AX GI2 Manor Dale Rd RdSI B005 NW2 street London ownerNo B007 staffNo 16 Holhead branchNo G324QX GI19QX Glasgow propertyNo postcode type 6Argyll city St
Figura C.14.
(
(a) Tablas Branch y PropertyForRent.
e Organizaciones de archivos e índices
1165
índice de combinación branchRowlD
30003 30004 Aberdeen London 30005 ... 30001 30002 30006 propertyRowlD city Glasgow
(b)
Figura C.14. (Cant.) (b) índice de combinación sobre el atributo no clave city.
combinación sobre el atributo no clave city con el fin de generar la tabla de índice que se muestra en la Figura C.14(b). Hemos decidido ordenar el índice de combinación según el atributo branchRowlD, pero podría haberse ordenado sobre cualquiera de los tres atributos. En ocasiones, se crean dos índices de combinación, uno como se muestra y otro con los dos atributos rowlD invertidos. Este tipo de consulta podría ser común en las aplicaciones de almacén de datos a la hora de tratar de localizar hechos acerca de elementos de información relacionados (en este caso, estamos tratando de averiguar cuántos inmuebles corresponden a una ciudad donde exista una sucursal). El índice de combinación precalcula la combinación de las tablas Branch y PropertyForRent basándose en el atributo city, lo que elimina la necesidad de realizar la combinación cada vez que se ejecute la consulta, mejorando así la velocidad de ésta. Esto puede ser particularmente importante si se trata de una consulta que se utiliza muy frecuentemente. Oracle combina los índices de mapa de bits y los índices de combinación, proporcionando un índice de combinación en mapa de bits.
Tablas agrupadas y no agrupadas
C.6
Algunos SGBD, como Oracle, soportan las tablas agrupadas y no agrupadas. La decisión de utilizar una tabla agrupada o no agrupada depende del análisis de las transacciones, y dicha decisión puede tener un impacto sobre el rendimiento. En esta sección vamos a examinar brevemente ambos tipos de estructura. Los agrupamiento s o clústeres son grupos de una o más tablas que se almacenan físicamente juntas porque comparten columnas comunes y se utilizan juntas a menudo. Al almacenar físicamente juntos los registros relacionados, se mejoran los tiempos de acceso a disco. Las columnas relacionadas de las tablas que forman un clúster se denominan clave de agrupamiento o de clúster. La clave de agrupamiento sólo se almacena una vez, por lo que los clústeres almacenan un conjunto de tablas de manera más eficiente que si las tablas se almacenaran individualmente (no agrupadas). La Figura C.15 ilustra cómo se almacenarían las tablas Branch y Staff si agrupáramos dichas tablas basándonos en la columna branchNo. Cuando se agrupan estas dos tablas, cada valor unívoco de branchNo se almacena una única vez, en la clave de clúster. A cada valor de branchNo se le asocian las columnas de ambas tablas. Como vamos a ver, Oracle soporta dos tipos de clústeres: clústeres indexados y clústeres hash.
C.5.1
Clústeres indexados
En un clúster indexado, los registros con la misma clave de clúster se almacenan juntos. Oracle sugiere utilizar clústeres indexados cuando: •
las consultas extraen registros para un rango de ~alores de la clave de clúster;
•
las tablas agrupadas pueden crecer de manera im~ecible.
1166
Sistemas de bases de datos
-
-
30000 12000 street DOB Susan Beech Aun SL21 David fName sex Brand B003 SG37 SW14EH BOOS London Ford Assistant Lee IName branchNo staffNo White John Julie position postcode city G119QX Glasgow salary Manager Supervisor
24000 18000 9000
Tabla Staff Tabla Branch Clave de c1úster
Figura C.15.
Como se almacenarían
las tablas Branch y Staff agrupadas según branchNo.
Los clústeres permiten mejorar la velocidad de la extracción de datos, dependiendo de la distribución de éstos y del tipo de operaciones SQL que se realicen más frecuentemente con los datos. En particular, cuando las tablas se combinan en una consulta, resulta beneficiosa la utilización de clústeres, porque los registros comunes de las tablas combinadas se extraen en una misma operación de E/S. Para crear un clúster indexado en Oracle denominado BranchlndexedCluster utilizando como clave de clúster la columna branchNo, podríamos emplear la siguiente instrucción SQL: CREATE CLUSTER BranchlndexedCluster (branchNo CHAR( 4)) SIZE 512 STORAGE
(INITIAL
lOOK NEXT 50K PCTINCREASE
10);
El parámetro SIZE especifica la cantidad de espacio (en byte s) que se necesita para almacenar todos los registros con un mismo valor de clave de clúster. El tamaño es opcional y, si se omite, Oracle reserva un bloque de datos para cada valor de la clave de cl~ter. El parámetro INITIAL especifica el tamaño (en bytes) de la primera extensión del clúster y el parámetro NEXT especifica el tamaño (en bytes) de la siguiente extensión que haya que asignar. El parámetro PCTINCREASE especifica el porcentaje mediante el que crecerán la tercera y las subsiguientes extensiones con respecto a la extensión precedente (el valor predeterminado es 50). En nuestro ejemplo, hemos especificado que cada extensión subsiguiente debe ser un 10% mayor que la anterior.
C.6.2
Clústeres hash
Los clústeres hash también agrupan los datos de las tablas de forma similar a los c1ústeres indexados. Sin embargo, los registros se almacenan en un clúster hash basándose en el resultado de aplicar una función hash al valor de la clave de clúster del registro. Todos los registros con el mismo valor de clave hash se almacenan juntos en disco. Oracle sugiere utilizar clústeres hash cuando: •
las consultas extraen registros basándose en condiciones de igualdad en las que aparecen todas las columnas de la clave de clúster (por ejemplo, extraer todos los registros correspondientes a la sucursal B005);
•
las tablas agrupadas son estáticas o se puede determinar en el momento de su creación el número máximo de registros y la máxima cantidad de espacio requerida por el clúster.
Para crear un clúster hash en Oracle denominado podríamos usar la siguiente instrucción SQL:
propertyNo,
CREATE
CLUSTER PropertyHashCluster VARCHAR2(5)) HASH IS propertyNo HASHKEYS 300000; (propertyNo
PropertyHashCluster
y agrupado según la columna
e
Organizaciones de archivos e índices
1167
Una vez creado el clúster hash, podemos crear las tablas que formarán parte de la estructura. Por ejemplo: CREATE TABLE PropertyForRent (propertyNoVARCHAR2(S) PRIMARY KEY, ...) CLUSTER PropertyHashCluster (propertyNo);
C.7
Directrices para seleccionar la organización de los archivos
Como ayuda para comprender el tema de la realización de archivos y de los índices más profundamente, vamos a proporcionar una serie de directrices para seleccionar la organización de un archivo, basándonos en los siguientes tipos de archivo: •
En cúmulo.
•
Hash.
• •
ISAM (Indexed Sequential Access Method). Árbol B+.
•
Clústeres.
Cúmulo (desordenado) La organización de archivo en cúmulo se ha explicado en la Sección C.2. El cúmulo es una buena estructura de almacenamiento en las siguientes situaciones: (1) Cuando después cúmulo después
se están cargando de forma masiva los datos en la tabla. Por ejemplo, para rellenar una tabla de crearla, puede que sea necesario insertar un lote de tuplas en la misma. Si se selecciona el como organiza~ión inicial del archivo, puede resultar más eficiente reestructurar el archivo de haber completado las inserciones.
(2) La tabla sólo tiene unas pocas páginas de longitud. En este caso, el tiempo necesario para localizar cualquier tupla es muy corto, aunque haya que explorar toda la tabla de forma secuencia!. (3) Cuando es necesario extraer todas las tuplas de la tabla (en cualquier orden) cada vez que se accede a la tabla. Por ejemplo, cuando hay que extraer las direcciones de todos los inmuebles en alquiler. (4) Cuando la tabla tiene una estructura de acceso adicional, como por ejemplo una clave de índice, puede emplearse el almacenamiento en cúmulo para ahorrar espacio. Los archivos en cúmulo resultan poco apropiados cuando sólo es necesario acceder a una serie de tuplas seleccionadas de una tabla.
Hash La organización de archivos de tipo hash se explica en el Apéndice CA. La técnica hash constituye una buena estructura de almacenamiento cuando se extraen las tuplas basándose en una correspondencia exacta del valor de la clave de hash, particularmente si el orden de acceso es aleatorio. Por ejemplo, si se aplica el hash a la tabla PropertyForRent según el valor de propertyNo,la extracción de la tupla con un valor propertyNoigual a PG36 resultará muy eficiente. Sin embargo, la estructura hash no es una buena estructura de almacenamiento en las siguientes situaciones: (1) Cuando las tuplas se extraen basándose en una correspondencia de patrones con el valor de la clave de hash. Por ejemplo, si se quieren extraer todos los inmuebles cuyo número de inmueble, propertyNo, comience con los caracteres 'PG'. (2) Cuando las tuplas se extraen basándose en un rango de valores para la clave hash. Por ejemplo, si se quieren extraer todos los inmuebles con un alquiler comprendido en el rango 300-500.
1168
Sistemas de bases de datos
(3) Cuando las tuplas se extraen basándose en un campo distinto del campo hash. Por ejemplo, si se aplica la función hash a la tabla Staff, según el campo staffNo, no puede utilizarse la estructura hash para buscar una tupla basándose en el atributo IName. En este caso, sería necesario realizar una búsqueda lineal para localizar la tupla, o añadir IName como índice secundario (véase el Paso 4.3). (4) Cuando las tuplas se extraen basándose únicamente en una parte del campo hash. Por ejemplo, si se aplica la función hash sobre los atributos rooms y rent de la tabla PropertyForRent, no puede utilizarse la estructura hash para buscar una tupla basándose exclusivamente en el valor del atributo rooms. De nuevo, sería necesario realizar una búsqueda lineal para buscar la tupla. (5) Cuando el campo de hash se actualiza frecuentemente. Cada. vez que se actualiza un campo hash, el SGBD debe borrar toda la tupla y, posiblemente, reubicarla en una nueva dirección (si al aplicar la función hash se obtuviera un valor de dirección distinto). Por tanto, la actualización frecuente del campo hash tiene un impacto sobre el rendimiento.
ISAM (lndexed Sequential Access Method) La organización de archivo secuencial indexado se analiza en la Sección C.S.2. ISAM es una estructura de almacenamiento más versátil que la estructura hash; soporta las extracciones basadas en una correspondencia exacta con el valor de clave, así como las extracciones basadas en correspondencia de patrones, rangos de valores y especificaciones parciales de clave. Sin embargo, el índice ISAM es estático, creándose en el momento de crear el archivo. Por tanto, el rendimiento de un archivo ISAM se deteriora a medida que se actualiza la tabla. Las actualizaciones pueden también hacer que el archivo ISAM pierda la secuencia de claves de acceso, de modo que las extracciones según el orden de la clave de acceso se hacen más lentas. Estos dos problemas se solventan mediante la organización de archivo en árbol B+. Sin embargo, a diferencia del árbol B+, puede gestionarse fácilmente el acceso concurrente al índice, ya que el índice es estático.
Árbol B+ La organización de archivo en árbol B+ se explica en la Sección C.S.S. De nuevo, el árbol B+ es una estructura de almacenamiento más versátil que la estruetura hash. Soporta las extracciones basadas en correspondencias exactas con la clave, en correspondencias de patrones, en rangos de valores y en especificaciones parciales de la clave. El índice en árbol B+ es dinámico, creciendo a medida que lo hace la tabla. Por tanto, a diferencia de ISAM, las prestaciones de un archivo con estructura de árbol B+ no se deterioran a medida que la tabla se actualiza. El árbol B+ también mantiene el orden de la clave de acceso aunque se actualice el archivo, por lo que la extracción de las tuplas según el orden de la clave de acceso es más eficiente que con ISAM. Sin embargo, si la relación no se actualiza frecuentemente, la estructura ISAM puede ser más eficiente, ya que tiene un nivel menos de índice que el. árbol B+, cuyos nodos hoja contienen punteros a las tuplas, en lugar de las propias tuplas.
Tablas agrupadas Algunos SGBD, como por ejemplo Oracle, soportan las tablas agrupadas (véase la Sección C.6). La decisión de utilizar una tabla agrupada o no agrupada dependerá del análisis de las transacciones, y dicha decisión puede tener un impacto sobre las prestaciones. Vamos a ver una serie de directrices para la utilización de tablas agrupadas. Observe que en esta sección utilizaremos la terminología Oracle, denominando tablas a las relaciones, y estando dichas tablas compuestas por columnas y filas. Los clústeres son grupos de una o más tablas que se almacenan físicamente juntas, porque comparten (~lumnas relacionadas, comunes se mejoran y se utilizan los tiempos frecuentemente de acceso adedisco. manera Las conjunta. columnasAlrelacionadas almacenar físicamente de las tablasjuntas de unlas clúster filas se denominan clave de clúster o clave de agrupamiento. La clave de clúster se almacena una única vez, por lo que los clústeres permiten almacenar un conjunto de tablas de manera más eficiente que si la tablas se almacenaran individualmente (no agrupadas). Oracle soporta dos tipos de clústeres: clústeres indexados y clústeres hash.
e (a) Clústeres
Organizaciones de archivos e índices
1169
indexados
En un clúster indexado, las filas con la misma clave de clúster se almacenan juntas. Oracle sugiere utilizar clústeres indexados cuando: •
las consultas extraigan filas para un rango de valores de la clave de clúster;
•
las tablas agrupadas puedan crecer de forma impredecible.
Las siguientes directrices pueden resultar útiles a la hora de decidir si se deben agrupar las tablas: •
Considere el agrupamiento de aquellas tablas a las que suela accederse en instrucciones que incluyan operaciones de combinación.
•
No agrupe las tablas si sólo se realizan combinaciones de las mismas ocasionalmente o si los valores de la columna común se modifican de manera frecuente (la modificación del valor de la clave de clúster de una fila requiere más tiempo que la modificación del valor de una tabla no agrupada, porque Oracle puede tener que desplazar la fila modificada a otro bloque con el fin de mantener el clúster).
•
No agrupe las tablas si se requiere realizar a menudo una búsqueda completa de una de las tablas (una búsqueda completa de una tabla agrupada puede tardar más tiempo que una búsqueda completa en una tabla no agrupada. Oracle necesitará leer más bloques, debido al hecho de que las tablas se almacenan juntas).
•
Considere el agrupamiento de las tablas que están implicadas en una relación uno a muchos selecciona a menudo una fila de la tabla padre y las correspondientes filas de la tabla hija hijas se almacenan en los mismos bloques de datos que la tabla padre, por lo que es probable en memoria cuando se efectúe la selección, lo que hace que Oracle necesite realizar menos nes de E/S).
•
Considere almacenar uña tabla hija sola en un clúster si se seleccionan múltiples filas hija a partir de la misma fila padre (esta medida mejora la velocidad de aquellas consultas que seleccionan las filas hijas de un mismo padre, sin reducir la velocidad de las operaciones de búsqueda completa sobre la tabla padre).
•
No agrupe las tablas si los datos de todas las tablas que tienen un mismo valor de clave de clúster sobrepasan uno o dos bloques de Oracle (para acceder a una fila en una tabla agrupada, Oracle lee todos los bloques que contienen filas con dicho valor. Si dichas filas ocupan múltiples bloques, acceder a una única fila podría requerir más lecturas que acceder a la misma fila en una tabla no agrupada).
(b) Clústeres
(1 :*) si se (las tablas que estén operacio-
hash
Los clústeres hash también agrupan los datos de las tablas de forma similar a los clústeres de índice. Sin embargo, cada fila se almacena en un clúster hash basándose en el resultado de aplicar una función hash al valor de la clave de clúster de la fila. Todas las filas con el mismo valor de la clave hash se almacenarán juntas en disco. Oracle sugiere utilizar clústeres hash cuando: • •
las consultas extraen filas basándose en condiciones de igualdad en las que aparecen todas las columnas de las clave de clúster (por ejemplo, devolver todas las filas para la sucursal B003); las tablas agrupadas son estáticas, o se puede determinar en el momento de su creación el número máximo de filas y la cantidad máxima de espacio requerido por el clúster.
Las siguientes directrices pueden resultar útiles a la hora de decidir si se deben utilizar clústeres hash: •
Considere la utilización de clústeres hash para almacenar las tablas a las que se acceda frecuentemente utilizando una cláusula de búsqueda que contenga condiciones de igualdad con las mismas columnas. Designe estas columnas como clave de clúster.
•
Almacene una tabla en un clúster hash si puede determinarse cuánto espacio se requiere para almacenar todas las filas que tengan un determinado valor de la clave de clúster, tanto ahora como en el futuro.
1170
Sistemas de bases de datos
•
No utilice clústeres hash si hay poco espacio y no resulta recomendable asignar espacio adicional para las filas que haya que insertar en el futuro.
•
No utilice un clúster hash para almacenar una tabla que esté creciendo de manera constante, si el proceso de crear ocasionalmente un clúster hash nuevo de mayor tamaño con el fin de contener la tabla no resulta apropiado.
•
No almacene una tabla en un clúster hash si se requiere realizar a menudo una búsqueda en la tabla completa y si debe asignarse una cantidad significativa de espacio al clúster hash, en previsión del futuro crecimiento de la tabla (dichas búsquedas completas deben leer todos los bloques asignados al clúster hash, aún cuando algunos bloques puedan contener sólo unas pocas filas. Almacenar la tabla sola permitiría reducir el número de bloques leídos por la operación de búsqueda completa en la tabla). No almacene una tabla en un clúster hash si los valores de la clave de clúster se modifican frecuentemente.
• •
Almacenar una única tabla en un clúster hash puede resultar útil, independientemente de si la tabla se combina a menudo con otras tablas, siempre que la utilización del clúster hash resulte apropiada para la tabla basándose en las directrices anteriores.
Resumen del apéndice •
Una organización de archivo es la disposición fisica de los datos de un archivo en registros y páginas, en el almacenamiento secundario. Un método de acceso son los pasos necesarios para almacenar y extraer registros de un archivo.
•
Los archivos en cúmulo (desordenados) almacenan los registros en el mismo orden en que se los inserta. Los archivos en cúmulo son adecuados para insertar un gran número de registros en el archivo. Resultan muy apropiados cuando sólo hay que extraer una serie de registros seleccionados.
•
Los archivos secuenciales (ordenados) almacenan los registros ordenándolos según los valores de uno o más campos (los campos de ordenación). L3"'Ínserción y borrado de registros en un archivo ordenado resultan problemáticos, porque es necesario mantener el orden de los registros. Como resultado, raramente se utilizan archivos ordenados para el almacenamiento de una base de datos, a menos que se añada un índice principal al archivo.
•
Los archivos hash son adecuados cuando la extracción se basa en una correspondencia exacta con la clave. No resultan adecuados cuando la extracción está basada en correspondencia de patrones, rangos de valores, claves parciales, o cuando la extracción se realiza basándose en una columna distinta del campo de hash.
•
Un índice es una estructura de datos que permite al SGBD localizar registros completos dentro de un archivo más rápidamente, acelerando así la respuesta a las consultas de los usuarios. Hay tres tipos fundamentales de índice: índice principal, índice de agrupamiento e índice secundario (un índice que está definido sobre un campo de no ordenación del archivo de datos).
•
Los índices secundarios proporcionan un mecanismo para especificar una clave adicional para una tabla base, que pueden utilizarse para extraer los datos más eficientemente. Sin embargo, se requieren recursos adicionales para el mantenimiento y utilización de los índices secundarios, debiendo compararse esos recursos con las mejoras de velocidad que se obtienen a la hora de extraer los datos.
•
El método ISAM es más versátil que el método de hash, permitiendo extracciones basadas en correspon-
(~
dencias exactas con laSin clave, en correspondencias de patrones, en rangos valores y en especificaciones parciales de la clave. embargo, los índices ISAM son estáticos, por lodeque la velocidad se deteriora a medida que se actualiza la tabla. Las actualizaciones pueden también hacer que el archivo ISAM pierda la secuencia de la clave de acceso, por lo que las extracciones según el orden de la clave de acceso se hacen más lentas. •
Estos dos problemas pueden resolverse utilizando la organización de archivo en árbol B+, que tiene un índice dinámico. Sin embargo, los árboles B+ no permiten, a diferencia de los índices ISAM estáticos, ges-
e Organizaciones de archivos e índices 1171 tionar de manera tan fácil el acceso concurrente a los índices. Si la tabla no se actualiza frecuentemente o no es muy grande si se prevé que lo llegue a ser, la estructura ISAM es más eficiente, ya que tiene un nivel menos de índice que el árbol B+, cuyos nodos hoja contienen punteros a registros, en lugar de los propios registros. •
Un índice de mapa de bits almacena un vector de bits para cada atributo, mediante el que se indica qué tuplas contienen dicho valor de dominio concreto. Cada bit que esté puesto a 1 en el mapa de bits se corresponde con un identificador de fila. Si el número de valores de dominio diferentes es pequeño, los índices de mapa de bits son muy eficientes en términos del espacio ocupado.
•
Un índice de combinación es un índice que se construye sobre atributos de dos o más tablas y que están definidos sobre el mismo dominio. El índice de combinación precalcula la combinación de las dos tablas basándose en el atributo especificado, lo que elimina la necesidad de realizar la combinación cada vez que se ejecuta una consulta, mejorando así su velocidad. Esto puede resultar particularmente importante si se trata de una consulta que se ejecuta frecuentemente.
•
Los clústeres son grupos de una o más tablas que se almacenan fisicamente juntas, porque comparten columnas comunes y se utilizan conjuntamente muy a menudo. Al almacenarse fisicamente juntos los registros seleccionados, se mejoran los tiempos de acceso a disco. Las columnas relacionadas de las tablas de un clúster se denominan clave del clúster. La clave de clúster sólo se almacena una vez, por lo que los clústeres permiten almacenar un conjunto de tablas de manera más eficiente que si éstas se almacenaran individualmente (no agrupadas). Oracle soporta dos tipos de clústeres: clústeres indexados y clústeres hash.
¿Cuándo es relacional un SGBD? Objetivos En este apéndice aprenderá: •
Los criterios para la evaluación de los sistemas de gestión de bases de datos relacionales.
Como hemos mencionado en la Sección 3.1, existen en la actualidad varios cientos de SGBD relacionales tanto para entorno s mainframe como pe. Desafortunadamente, algunos de ellos no se ajustan exactamente a la definición del modelo relacional. En particular, algunos fabricantes tradicionales de productos SGBD basados en los modelos de datos en red y jerárquico han implementado unas cuantas características relacionales para afirmar que sus productos son en cierto modo relacionales. Preocupado por la posible distorsión de la potencia y de los fundamentos de la técnica relacional, Codd especificó doce reglas (trece si contamos la Regla O, que es la regla fundacional) para los SGBD relacionales. Estas reglas definen una comparativa con la que se puede evaluar los productos SGBD relacionales 'verdaderos'. A lo largo de los años, las reglas de Codd han provocado una gran controversia. Algunos autores argumentan que dichas reglas no son más que un ejercicio académico. Otros afirman que sus productos satisfacen la mayoría de esas reglas, si es que no las satisfacen todas. Esta discusión generó una mayor concienciación en las comunidades de usuarios y fabricantes acerca de las propiedades esenciales de un SGBDverdaderamente relacional. Para enfatizar las implicaciones de las reglas, las hemos reorganizado en las siguientes cinco áreas funcionales: (1) Reglas fundacionales. (2) Reglas estructurales. (3) Reglas de integridad. (4) Reglas de manipulación de datos. (5) Reglas de independencia de los datos.
Reglas fundacionales
(regla O y regla 12)
Las Reglas O y 12 proporcionan un test básico para verificar si un sistema es un SGBD relacional. Si el producto no se ajusta a estas reglas, no debe considerarse relacional.
Regla O. Regla tundacional Para cualquier sistema que se anuncie como sistema de gestiónode bases de datos relacionales, o que pretenda serio, dicho sistema debe ser capaz de gestionar bases de datos completamente mediante sus capacidades relacionales.
Esta regla significa que el SGBD no debe tener que recurrir a ningún tipo de operación no relacional para implementar ninguna de sus capacidades de gestión de datos, como por ejemplo, las funciones de definición de datos o de manipulación de los datos.
1174
Sistemas de bases de datos
Regla 12. Regla de no subversión Si un sistema relacional tiene un lenguaje de bajo nivel (de manipulación de registros de uno en uno), dicho bajo nivel no puede utilizarse para subvertir o distorsionar las reglas de integridad y las restricciones expresadas en el lenguaje relacional de mayor nivel (de manipulación de múltiples registros cada vez).
Esta regla requiere que todo el acceso a la base de datos sea controlado por el SGBD, de manera que la integridad de la base de datos no pueda verse comprometida sin conocimiento del usuario o del DBA (administrador de la base de datos). Sin embargo, esta regla no prohíbe el uso de un lenguaje con una interfaz de manipulación de los registros de uno en uno.
Reglas estructurales
(regla 1 y regla 6)
El concepto estructural fundamental del modelo relacional es la relación. Codd afirma que un SGBDR debe soportar diversas características estructurales, incluyendo las relaciones, dominios, las claves principales y las claves externas. Debe haber una clave principal para cada relación en la base de datos.
Regla 1. Representación de la información Toda la información contenida en una base de datos relacional se representa explícitamente gico en exactamente una única manera, utilizando valores almacenados en tablas.
en el nivel iló-
Esta regla requiere que toda la información, incluso los metadatos contenidos en el catálogo del sistema, se almacene en forma de relaciones y se gestione mediante las mismas funciones de carácter operativo que se utilizarían para mantener los datos. La referencia al 'nivel lógico' significa que las estructuras fisicas, como los índices, no se representan en las operaciones de extracción y el usuario no tiene que hacer referencia explícita a ellas, incluso en el caso de que existan.
Regla 6. Actualización de vistas Todas las vistas que sean teóricamente
actualizables
son también actualizables
por parte del sistema.
Esta regla trata explícitamente con las vistas. Ea la Sección 6.4.5 hemos visto cuáles eran las condiciones para poder actualizar las vistas en SQL. Esta regla afirma que si una vista es teóricamente actualizable, el SGBD debe ser capaz de realizar la actualización. Ningún sistema soporta verdaderamente esta característica, ya que todavía no se ha determinado cuáles son las condiciones para identificar todas las vistas teóricamente actualizables.
Reglas de integridad (regla 3 y regla 10) Codd especifica dos reglas de integridad de los datos. El soporte de la integridad de los datos es un criterio importante a la hora de evaluar la adecuación de un producto. Cuantas más restricciones de integridad puedan mantenerse en el producto SGBD en lugar de en cada programa de aplicación, mejor se podrá garantizar la calidad en los datos.
Regla 3. Tratamiento sistemático de los valores nulos Los valores nulos (que son distintos de la cadena de caracteres vacía o de la cadena de caracteres en blanco, y distintos también del cero y de cualquier otro número) se soportan para representar de manera sistemática información que falta e información no aplicable, independientemente del tipo de los datos.
~gla
10. Independencia de la integridad Las restricciones de integridad específicas de una base de datos relacional concreta deben poderse definir en el sublenguaje relacional de datost y deben poderse almacenar en el catálogo, no en los programas de aplicación. t Un sublenguaje
es aquel lenguaje que no pretende incluir estructuras para todas las necesidades
y el cálculo relacional son sublenguajes
de base de datos.
de computación.
El álgebra relacional
~
D ¿Cuándo es relacional un SGBD?
1175
Codd señala específicamente que las restricciones de integridad deben almacenarse en el catálogo del sistema, en lugar de encapsularse en los problemas de aplicación o en las interfaces de usuario. Almacenar las restricciones en el catálogo del sistema tiene la ventaja de centralizar el control y la imposición de las restriccIOnes.
Reglas de manipulación de datos (regla 2, regla 4, regla 5 y regla 7) Hay 18 características de manipulación que un SGBD relacíonal ideal debería soportar. Estas características definen la completud del lenguaje de consulta (donde, en este sentido, 'consulta' incluye las inserciones, las actualizaciones y los borrados). Las reglas de manipulación de datos sirven como guía para la aplicación de las 18 características de manipulación. El cumplimiento de estas reglas aísla al usuario y a los programas de aplicación con respecto a los mecanismos fisicos y lógicos que se utilizan para implementar las capacidades de gestión de los datos.
Regla 2. Acceso garantizado Debe garantizarse que todos los datos (valores atómicos) de una base de datos relacional sean accesibles desde el punto de vista lógico, utilizando una combinación del nombre de la tabla, del valor de la clave principal y del nombre de la columna.
Regla 4. Catálogo en línea dinámico basado en el modelo relacional La descripción de la base de datos se representa en el nivel lógico de la misma forma que los datos normales, por lo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional para consultarla que aplicarían para los datos normales.
Esta regla especifica que sólo hay un lenguaje para la manipulación de los datos y de los metadatos, y además que sólo hay una estructura lógica (las relaciones) para almacenar la información del sistema.
Regla 5:
Sublenguaje ~e datos completo
Un sistema relacional puede soportar diversos lenguajes y diversos modos de empleo por parte de los usuarios (por ejemplo, el modo de rellenar los blancos). Sin embargo, debe haber al menos un lenguaje cuyas instrucciones puedan expresar lo siguiente: (a) definición de los datos; (2) definición de las vistas; (3) manipulación de los datos (interactiva y mediante programa); (4) restricciones de integridad; (5) autorización; (6) fronteras de las transacciones (inicio, confirmación y anulación).
Observe que el estándar ISO para SQL proporciona todas estas funciones, por lo que cualquier lenguaje que cumpla con dicho estándar satisfará automáticamente esta regla (véanse los Capítulos 5, 6 y 21).
Regla 7. Inserción, actualización y borrado de alto nivel La capacidad de manipular una relación base o una relación derivada (es decir, una vista) como un único operando se aplica no sólo a la extracción de los datos, sino también a la inserción, la actualización y el borrado de los datos.
Reglas de independencia de los datos (regla 8, regla 9 y regla 11) Codd define tres reglas para especificar la independencia de los datos con respecto a las aplicaciones que los utilizan. El cumplimiento de estas reglas garantiza que tanto los usuarios como los desarrolladores estén protegidos frente a la necesidad de cambiar las aplicaciones después de una reorganización de bajo nivel de la base de datos.
Regla 8. Independencia física de los datos Los programas de aplicación y las actividades de los usuarios no se verán afectados desde el punto de vista lógico cuando se realice algún cambio en las representaciones de almacenamiento o en los métodos de acceso.
1176
Sistemas de bases de datos
Regla 9. Independencia lógica de los datos Los programas de aplicación y las actividades de los usuarios no se verán lógicamente afectados cuando en las tablas base se realicen cambios de cualquier tipo que preserven la información y que, teóricamente, permitan que las aplicaciones y los usuarios no se vean afectados.
Regla 11. Independencia de la distribución El sublenguaje de manipulación de datos de un SGBD relacional debe permitir que los programas de aplicación y las consultas continúen siendo iguales desde el punto de vista lógico, independientemente de si los datos están físicamente centralizados o distribuidos.
La independencia de la distribución quiere decir que un programa de aplicación que acceda al SGBD en una única computadora debe poder funcionar también en un entorno de red sin ninguna modificación, incluso aunque los datos se transfieran de una computadora a otra, en otras palabras, el usuario final debe tener la ilusión de que los datos están centralizados en una única máquina, y la responsabilidad de localizar esos datos (posiblemente) almacenados en múltiples sitios y recomponerlos debe corresponder siempre al sistema. Observe que esta regla no dice que para ser completamente relacional el SGBD deba soportar una base de datos distribuida, sino que lo que dice es que el lenguaje de consulta debe continuar siendo el mismo si se introduce esta capacidad y los datos se distribuyen. Hemos hablado de las bases de datos distribuidas en los Capítulos 22 y 23.
Apénalce
SQL procedimental
Objetivos En este apéndice aprenderá: •
Cómo pueden incluirse instrucciones SQL en lenguajes de programación de alto nivel.
•
La diferencia entre el SQL embebido estático y dinámico.
•
Cómo escribir programas que utilicen instrucciones SQL embebidas estáticas.
•
Cómo escribir programas que utilicen instrucciones SQL embebidas dinámicas.
•
Cómo utiliza el estándar de jacto ODBC (Open DatabaseConnectivity).
En los Capítulos 5 y 6 hemos hablado con cierto detalle del lenguaje SQL (Structured Query Language) y, en concreto, de sus capacidades de manipulación y definición de datos. En la Sección 5.1.1 hemos mencionado que el estándar SQL 1992 carecía de completud computacional: no contenía ningún comando de control de flujo tal como IF...THEN ...ELSE, GO TO o DO ...WHILE. Para resolver este problema y proporcionar una mayor flexibilidad, SQL permite incrustar o embeber instrucciones en un lenguaje procedimental de alto nivel, así como introducir instrucciones SQL interactivamente a través de un terminal. Con la técnica de incrustación de instrucciones SQL, el flujo de control puede implementarse mediante las estructuras proporcionadas por el lenguaje de programación. En muchos casos, el lenguaje SQL es idéntico, aunque la instrucción SELECT, en concreto, requiere un tratamiento más detallado en el SQL embebido. De hecho, podemos distinguir entre dos tipos de SQL programado: •
Instrucciones SQL embebidas. Las instrucciones SQL se incrustan directamente en el código fuente del programa, entremezclándolas con las instrucciones del lenguaje host. Esta técnica permite a los usuarios escribir programas que accedan a la base de datos directamente. Un precompilador especial modifica el código fuente para sustituir las instrucciones SQL por llamada a rutinas del SGBD. El código fuente puede entonces compilarse y montarse de la forma normal. El estándar ISO especifica soporte embebido para Ada, C, COBOL, Fortran, MUMPS, Pascal y PUl.
•
Interjaz de programación
de aplicaciones (API). Una técnica alternativa consiste en proporcionar al
p~ador un conjunto estándar de que funciones que pueda embebidas invocar desde el software. Una APIdepuede proporcicmar la misma funcionalidad las instrucciones y elimina la necesidad efectuar una precompilación. Puede argumentarse que esta técnica proporciona una interfaz más limpia y genera un código más gestionable. La API más conocida es el estándar ODBC (Open Database Connectivity) Muchos SGBD proporcionan algún tipo de SQL embebido, incluyendo Oracle, INGRES, Informix y DB2. Oracle proporciona también una API, Access sólo proporciona una API (llamada ADO, ActiveX Data Objects, una capa por encima de ODBC).
1178
Sistemas de bases de datos
Estructura del apéndice Hay dos tipos de SQL embebido: SQL embebido estático, donde la instrucción SQL completa se conoce en el momento de escribir el programa, y SQL embebido dinámico, que permite especificar toda la instrucción SQL o una parte de la misma en tiempo de ejecución. El SQL dinámico proporciona una mayor flexibilidad y ayuda a producir un software de propósito más general. Vamos a examinar el SQL embebido estático en la Sección E.l y el SQL embebido dinámico en la Sección E.2, en la versión expandida de este libro que se ofrece en el sitio web (véase la URL en el Prefacio). En la Sección E.3, hablaremos del estándar ODBC (Open Database Connectivity), que se ha impuesto como un estándar de Jacto del sector para el acceso a bases de datos SQL heterogéneas. Como de costumbre, presentaremos las características del SQL embebido utilizando ejemplos extraídos del caso de estudio de DreamHome descrito en la Sección lOA y en el Apéndice A. Usaremos la misma notación para especificar el formato de las instrucciones SQL que hemos definido en la Sección 5.2.
E.1 SOL embebido En esta sección vamos a analizar el SQL embebido estático. Para que las explicaciones sean más concretas, utilizaremos el dialecto SQL de Oracle9i embebido en el lenguaje de programación C. Al final de esta sección, comentaremos las diferencias entre el SQL embebido de Oracle y el estándar ISO.
E.1.1
Instrucciones SOL embebidas simples
Los tipos más simples de instrucciones SQL embebidas son aquellas que no producen resultados de consulta; es decir, instrucciones no SELECT, tal como INSERT, UPDATE, DELE TE y la que vamos a utilizar en este ejemplo, CREATE TABLE. Éste es un ejemplo trivial de programa de SQL embebido, pero resulta útil de todos modos para ilustrar algunos conceptos básicos: •
Las instrucciones SQL embebidas comioozan con un identificador, usualmente la palabra clave EXEC SQL, tal como se define en el estándar ISO ('@SQL' en MUMPS). Esto indica al precompilador que se trata de una instrucción de SQL embebido.
•
Las instrucciones de SQL embebido finalizan con un terminador que depende del lenguaje host. En Ada, C y PUl, el terminador es un punto y coma (;). En COBOL, el terminador es la palabra clave END-EXEC. En Fortran, la instrucción embebida termina cuando no hay más líneas de continuación. Las instrucciones SQL embebidas pueden abarcar más de una línea, utilizando el marcador de continuación del lenguaje host.
•
I
•
Una instrucción de SQL embebido puede aparecer en cualquier lugar en donde pueda aparecer una instrucción ejecutable del lenguaje host.
•
Las instrucciones embebidas (CONNECT, CREATE TABLE y COMMIT) son idénticas a como serían si se las introdujera interactivamente.
Ejemplo E.1 CREA TE T ABLE
Crear la tabla Podemos crear Viewi~ la tabla VievVing interactivamente CREATE TABLE
Viewing
(propertyNo
en Oracle utilizando la siguiente instrucción SQL:
viewDate
VARCHAR2(5) VARCHAR2( 5) DATE
comments
VARCHAR2(40));
clientNo
NOTNULL, NOTNULL, NOTNULL,
E SOL procedimental
/* Programa
para crear la tabla Víewing
#include
#ínc!ude
EXEC SQL INCLUDE
1179
*/
sqka;
mainO
EXEC SQL BEGIN DECLARE char *username char 'pas$word
EXEC SQL END DECLARE /* Conectar
SECTlON;
a la base de datos */
EXEC SQL CONNECT if (sqka.sqlcode
/* Mostrar
SECTION;
= «Manager"; = "Manager";
mensaje
printf("Creating
:username
IDENTIFIED
y crear la tabla */
para el usuario VIEWING
tableln");
EXEC SQL CREATE TABLE Viewing
if (sqlca.sqlcode
BY :password;
< O) exit( -1);
>=
VARCHAR2(S)
NOT NULL,
c!ientNo
VARCHAR2(S)
NOT NULL,
viewDate
DATE
NOT NULL,
comments
VARCHAR2(40));
(propertyNo
/* Comprobar
O)
printf("Creatíon
successfulln");
printf("Creation
unsuccessfulln");
sí resultado
adecuado
*/
else
/* Confirmar
la transacción
EXEC SQL COMMIT
Figura E.1.
y desconectarse WORK
de la base de datos */
RELEASE;
Programa de SOL embebido para crear la tabla Viewing.
Sin embargo, también podríamos escribir el programa C mostrado en la Figura E.l con el fin de crear esta tabla.
~
En Oracle, no necesitamos seguir una instrucción de definición de datos con una instrucción COMMIT, porque las instrucciones de definición de datos ejecutan una operación COMMIT automática antes y después de la ejecución. Por tanto, la instrucción COMMIT de este programa de ejemplo (Figura E.l) podría haberse omitido sin ningún problema. Además, la opción RELEASE de la instrucción COMMIT hace que el sistema libere todos los recursos de Oracle, como por ejemplo bloqueos y cursores, y se desconecte de la base de datos.
E.1.2
Área de comunicaciones de SQl
El SGBD utiliza un área de comunicaciones de SQL (SQLCA, SQL Communications
Area) para informar al
programa ~cación los errores que se produzcan en una estructura de datos que cemtiene de variables de error e indicadores de tiempo estado. de Un ejecución. programa El de SQLCA aplicaciónes puede examinar el SQLCA para determinar si se ha ejecutado o no con éxito cada instrucción SQL. La Figura E.2 muestra la definición del SQLCA para Oracle. Para utilizar el SQLCA, al principio del programa incluimos la línea: EXEC SQL INCLUDE sqlca;
1180
Sistemas de bases de datos
1*
NOMBRE SQLCA : SQL Comrnunieations Area. FUNCIÓN No contiene código. Oracle rellena el área SQLCA con información de estado durante la ejecución de una instrucción SQL. *1
stmet sqlca{ ehar
sqlcaid[8];
1* contiene el texto fijo SQLCA *1
long
sqlcabe;
1* longitud de la estructura SQLCA *1
long
sqlcode;
1* código de retorno SQL *1
stmet { short
sqlerrrnl;
1* longitud del mensaje de error *1
ehar
sqlerrme[ 70];
1* texto del mensaje de error *1
} sqlerrm; ehar
sqlerrp[8];
1* reservado para uso futuro *1
long
sqlerrd[6];
1* sqlerrd[2] - número de filas procesadas *1
ehar
sqlwarn[8]; 1* sqlwarn[O] toma el valor W para las advertencias *1 1* sqlwarn[ 1] toma el valor W si la cadena de caracteres se ha visto truncada *1 1* sqlwarn[2] toma el valor W si los valores nulos se han eliminado de los agregados *1 1* sqlwarn[3] toma el valor W si no se corresponden las columnas/variables host *1 1* sqlwarn[4] toma el valorW cuando se prepara una actualización/borrado
sin una cláusula where *1
1* sqlwarn[5] toma el valor W debido a fallo de compilación PL/SQL *1 1* sqlwarn[6] ya no se utiliza *1 1* sqlwam[7] ya no se utiliza *1
ehar
,sqlext[8];
1* reservado para uso futuro *1
};
Figura E.2.
Área de comunicaciones
SOL de Oracle (SaLCA).
Esto le dice al precompilador que instruya la estructura de datos SQLCA en el programa. La parte más importante de esta estructura es la variable SQLCODE, que utilizamos para comprobar si ha habido errores. El SGBD configura la variable SQLCODE de la forma siguiente: •
Un valor de SQLCODE igual a cero indica que la instrucción se ha ejecutando satisfactoriamente que puede que haya mensajes de advertencia en sqlwarn).
•
Un valor de SQLCODE negativo indica que se ha producido un error. El valor de SQLCODE indica el valor específico que ha tenido lugar.
•
Un valor de SQLCODE positivo indica que la instrucción se ha ejecutado con éxito, pero que se ha producido una condición excepcional, como por ejemplo que una instrucción SELECT no ha devuelto más filas (véase más abajo).
En el Ejemplo E.l hemos comprobado si existía un valor SQLCODE (sqlca.sqlcode no se han completado con éxito las instrucciones CONNECT y CREA TE TABLE.
(aun-
< O), que indicaría que
La instrucción WHENEVER Toda instrucción SQL emb~de generar algún error. Obviamente, comprobar que se ha ejecutado con éxito cada instrucción SQL sería demasiado laborioso, por lo que el precompilador Oracle proporciona un método alternativo para simplificar la gestión de errores. La instrucción WHENEVER es una directiva del precompilador mediante la que ésta genera automáticamente el código para gestionar los errores después de cada instrucción SQL. El formato de la instrucción WHENEVER es:
E SOL procedimental
1181
EXEC SQL WHENEVER La instrucción WHENEVER está compuesta de una condición y de una acción que hay que tomar si la condición sucede, como por ejemplo, continuar con la instrucción siguiente, invocar una rutina, saltar a una instrucción etiquetada o detener la ejecución. La condición puede ser una de las siguientes: •
SQLERROR le dice al precompilador que genere código para gestionar los errores (SQLCODE <
•
SQLWARNING le dice al precompilador que genere código para gestionar las advertencias (SQLCODE> O).
•
NOT FOUND le dice al precompilador que genere código para gestionar la advertencia específica relativa a que una operación de extracción no ha encontrado más registros.
O).
La acción puede ser: •
CONTINUE, para ignorar la condición y continuar con la instrucción siguiente.
•
DO, para transferir el control a una función de tratamiento de errores. Cuando se alcanza el final de la rutina, el control se transfiere a la instrucción que sigue a la instrucción SQL fallida (a menos que la función termine la ejecución del programa).
•
DO BREAK, para colocar una instrucción de 'parada' en el programa. Esto resulta útil si se utiliza dentro de un bucle para salir de dicho bucle.
•
DO CONTINUE, para situar una instrucción de 'continuación' en el programa. Esto es útil si se utiliza dentro de un bucle para continuar con la siguiente iteración del bucle.
•
GOTO etiqueta, para transferir el control a la etiqueta especificada.
•
STOP, para cancelar todo el trabajo no confirmado y terminar el programa.
Por ejemplo, la instrucción WHENEVER en el segmento de código: EXEC SQL WHENEVE8 SQLERROR GOTO errorl; EXEC SQL INSERT INTO Viewing VALUES ('CR76', EXEC SQL INSERT INTO Viewing VALUES ('CR77',
'PAI4', 'PAI4',
'12-May-2004', '13-May-2004',
'PAI4',
'12-May-2004',
'PAI4',
'12-May-2004',
'Not enough space'); 'Quite like it');
sería convertida por el precompilador en: EXEC SQL INSERT INTO Viewing VALUES ('CR76', 'Not enough space'); if (sqlca.sqlcode < O) goto errorl; EXEC SQL INSERT INTO Viewing VALUES ('CR77', if (sqlca.sqlcode < O) goto errorl;
E.1.3
'Quite like it');
Variables del lenguaje host
Una variable del lenguaje hast es una variable del programa declarada en el lenguaje en el que se incrusta el código SQL. Puede ser una variable simple o una estructura. Las variables del lenguaje hast pueden utilizarse en las instrucciones de SQL embebido para transferir datos de la base de datos al programa y viceversa. También pueden utilizarse dentro de la cláusula WHERE de las instrucciones SELECT. De hecho, pueden emplearse en cualquier lugar donde pueda aparecer una constante. Sin embargo, no pueden usarse para representar objetos de la base de datos, como por ejemplo nombres de tablas o de columnas. Para utilizar una variable hast en una instrucción de SQL embebido, se antepone como prefijo un carácter de dos punto~bre de la variable. Por ejemplo, suponga que tenemos una variable de programa, increment, que representa el incremento salarial para el empleado SL21; entonces, podríamos actualizar el salario de dicho empleado utilizando la instrucción: EXEC SQL UPDATE StaffSET salary = salary + :increment WHERE staffNo = 'SL21';
1182
Sistemas de bases de datos Tabla E.1. Tipo SQL Oracle
Tipos Oracle y C.
e
int char float char[lOJ long int+ lJ char[n Tipo
DATE NUMBER(6,2) NUMBER(6) NUMBER(10) CHAR(n), CHAR VARCHAR2(n)
Las variables del lenguaje host deben declararse en SQL además de en la sintaxis del lenguaje host. Todas las variables host deben declararse en SQL dentro de un bloque BEGIN DECLARE SECTlON ...END DECLARE SECTlON. Este bloque debe aparecer antes de utilizar cualquiera de las variables en una instrucción de SQL embebido. Utilizando el ejemplo anterior, tendríamos que incluir una declaración de la forma siguiente en un punto apropiado antes de la primera utilización de la variable host: EXEC SQL BEGIN DECLARE SECTION; float increment; EXEC SQL END DECLARE SECTION; Las variables username y password de la Figura E.1 son también ejemplos de variables host. Toda variable del lenguaje host debe ser compatible con el valor SQL que represente. La Tabla E.1 muestra algunos de los tipos principales de datos SQL de Oracle (véase la Sección 8.2.3) y los tipos de datos correspondientes en C. Esta correspondencia puede diferir entre un producto y otro, lo que obviamente hace que escribir código SQL embebido portable sea dificil. Observe que los tipos de datos C para las cadenas de caracteres requieren un carácter extra con el fin de acomodar el terminador nulo de las cadenas C.
Variables indicadoras La mayoría de los lenguajes de programación no proporcionan soporte para valores desconocidos o que falten, es decir, para los valores que en el modelo relacional se representan mediante nulos (véase la Sección 3.3.1). Esto causa problemas cuando es necesario extraer o insertar un nulo en una tabla. El SQL embebido proporciona las denominada variables indicado ras para resolver este problema. Cada variable host tiene una variable indicadora asociada que puede configurarse o examinarse. El significado de la variable indicadora es como sIgue: •
Un valor indicador de cero significa que la variable host asociada contiene un valor válido.
•
Un valor igual a -1 significa que la variable host asociada contiene un valor nulo (el contenido que tenga la variable host es irrelevante).
•
Un valor indicador positivo significa que la variable host asociada contiene un valor válido, que puede haber sido redondeado o truncado (es decir, la variable host no era lo suficientemente grande como para almacenar el valor devuelto).
En una instrucción embebida, una variable indicadora se utiliza poniéndola inmediatamente después de la variable host asociada, utilizando un carácter de dos puntos (:) para separar las dos variables. Por ejemplo, para asignar un valor NULL a la columna address del propietario C021, utilizaríamos el siguiente segmento de código: EXEC SQL BEGIN DECLARE SECTION; char address[51]; ~ short addresslnd; EXEC SQL END DECLARE SECTION;
E SOL procedimental addresslnd = -1; EXEC SQL UPDATE PrivateOwnerSET address WHERE ownerNo = 'C021';
1183
= :address :addresslnd
Una variable indicadora es una variable entera de dos bytes, por lo que declaramos addresslnd como de tipo entero corto en la sección BEGIN DECLARE SECTION. Asignamos a addresslnd el valor -1 para indicar que la variable host asociada, address, debe interpretarse como NULL. La variable indicadora se coloca entonces en la instrucción UPDATE inmediatamente después de la variable host, address. En Oracle, la variable indicadora puede estar precedida opcionalmente por la palabra clave INDICATOR, para mejorar la legibilidad de los programas. Si extraemos datos de la base de datos y existe la posibilidad de que una columna del resultado de la consulta pueda contener un valor nulo, debemos emplear una variable indicadora para dicha columna; en caso contrario, el SGBD generará un error y asignará a SQLCODE algún valor negativo.
E.1.4
Extracción de datos mediante SOL embebido y cursores
En la Sección E.l.l hemos visto una serie de instrucciones de SQL embebido simples que no producen ningún resultado de consulta. También podemos extraer datos utilizando la instrucción SELECT, pero el procesamiento es más complicado si la consulta produce más de una fila. Dicha complicación surge del hecho de que la mayoría de los lenguajes de programación de alto nivel sólo pueden procesar elementos de datos individuales o filas individuales de una estructura, mientras que SQL procesa múltiples filas de datos. Para evitar esta desadaptación de impedancias (véase la Sección 25.2), SQL proporciona un mecanismo para que ellenguaje host pueda acceder a las filas del resultado de una consulta, leyendo una fila cada vez. El SQL embebido divide las consultas en dos grupos: • •
consultas mono fila, en las que el resultado de la consulta contiene como mucho una fila de datos; consultas multifila, donde el resultado de la consulta puede contener un número de filas arbitrario, que puede ser cero, una o más.
Consultas monofila En SQL embebido, las consultas mono fila se manejan mediante la instrucción de selección única, que tiene el mismo formato que la instrucción SELECT presentada en la Sección 5.3, pero empleando una cláusula INTO adicional que .especifica los nombres de las variables host donde debe almacenarse el resultado de la consulta. La cláusula INTO se especifica después de la lista SELECT. Debe existir una correspondencia uno a uno entre las expresiones de la lista SELECT y las variables host enumeradas en la cláusula INTO. Por ejemplo, para extraer los detalles relativos al propietario C021, escribiríamos: EXEC SQL SELECT fName, IName,address INTO :firstName, :lastName, :address :addresslnd FROM PrivateOwner WHERE ownerNo = 'C021'; En este ejemplo, el valor de la columna fName se almacena en la variable hostfzrstName, el valor de IName en lastName y el valor de address en address Uunto con el indicador nulo, en addresslnd). Como hemos explicado antes, es necesario declarar todas las variables host antes de poderlas utilizar en la sección BEGIN DECLARE SECTION.
I
Ejemplo E.2 Con~~ll-a~nofila Escribir un programa que pida al usuario que especifique un número de propietario e imprima el nombre y la dirección de dicho propietario.
1184
Sistemas de bases de datos
1* Programa para imprimir los detalles de PrivateOwner *1
#include #include EXEC SQL INCLUDE sqlca; mainO EXEC SQL BEGIN DECLARE SECTION; char
ownerNo[6];
char
tirstName[ 16J;
1* nombre devuelto *1
char
lastName[16J;
1* apellido devuelto *1
char
address[SI];
1* dirección devuelta *1
short
addresslnd;
1* indicador NULL *1
char
*username
char
*password = "Manager";
1* número de propietario de entrada *1
= UManagee);
EXEC SQL END DECLARE SECTION; 1* Pedir número de propietario *1
printf("Enter owner number: "); scanf("%s", ownerNo); 1* Conectar con la base de datos *1
EXEC SQL CONNECT :username IDENTIFIED BY :password; if (sqlca.sqlcode <
O)
exit (-1);
1* Establecer el tratamiento de errores SQL antes de ejecutar la instrucción SELECT *1
EXEC SQL WHENEVER SQLERROR GOTO error; EXEC SQL WHENEVER NOT FOUND GOTO done; EXEC SQL SELECT fName, lName, address INTO :tirstName, :lastName, :address :addresslnd FROM PrivateOwner WHERE ownerNo = :ownerNo;
1* Mostrar datos *1
printf("Name: if (addresslnd <
%s %s\o", tirstName, lastName); O)
printf("Address:
NULL\n");
printf("Address:
%s\n", address);
else
goto tinished
1* Condición de error - imprimir error *1 error:
printf("SQL error %d\n", sqlca.sqlcode); goto tinished; done: printf("No owner with specified number\n"); 1* Finalmente, desconectar de la base de datos *1
tinished: EXEC SQL WHENEVER SQLERROR continue; EXEC SQL COMMIT WORK RELEASE;
Fi9~
Consulta
monofila.
E SOL procedimental
1185
El programa se muestra en la Figura E.3. Se trata de una consulta monofila: pedimos al usuario que introduzca un número de propietario, seleccionamos la fila correspondiente de la tabla PrivateOwner, comprobamos que los datos han sido devueltos de forma correcta y, finalmente, imprimimos las columnas correspondientes. A la hora de extraer los datos, tenemos que utilizar una variable indicador para la columna address, ya que esta columna puede contener valores nulos.
Si la instrucción de selección única funciona adecuadamente, el SGBD asignará el valor cero a SQLCODE; si no hay ninguna fila que satisfaga la condición especificada en la cláusula WHERE, el SGBD asignará a SQLCODE el valor NOT FOUND. Si se produce un error o hay más de una fila que satisfaga la cláusula WHERE, o si alguna columna del resultado de la consulta contiene un valor nulo y no se ha especificado ninguna variable indicadora para dicha columna, el SGBD asignará a SQLCODE algún valor negativo, dependiendo del error concreto que se haya producido. En el siguiente ejemplo vamos a ilustrar algunos de los puntos anteriores relativos a las variables host, a las variables indicadoras y a la instrucción de selección única.
Consultas multifila Cuando una consulta de base de datos puede devolver un número arbitrario de filas, en SQL embebido se utilizan curso res para devolver los datos. Como hemos explicado en el contexto del lenguaje PL/SQL de Oracle en la Sección 8.2.5, un cursor permite a un lenguaje host acceder a las filas de un resultado de consulta, extrayendo una fila cada vez. En la práctica, el cursor actúa como un puntero a una fila concreta del resultado de la consulta. Para acceder a la siguiente fila, podemos hacer que el cursor avance una posición. Es necesario declarar y abrir el cursor antes de poder utilizarlo, y también es necesario cerrarlo para desactivarlo cuando ya no haga falta. Una vez abierto el cursor, pueden extraerse las filas del resultado de la consulta una a una utilizando la instrucción FETCH, en lugar de la instrucción SELECT. La instrucción DECLARE CURSOR define la instrucción SELECT específica que hay que realizar y asocia con la consulta un nombre de cursor. El formato de esta instrucción es: EXEC SQL DECLARE
nombreCursor
CURSOR FOR instrucciónSelect
Por ejemplo, para declarar un cursor con el fin de extraer todos los inmuebles gestionados por el empleado SL41, escribiríamos: EXEC SQL DECLARE propertyCursor SELECT propertyNo, street, city FROM PropertyForRent WHERE staffNo = 'SL41';
CURSOR
FOR
La instrucción OPEN ejecuta la consulta e identifica todas las filas que satisfacen la condición de búsqueda de la consulta, colocando el cursor antes de la primera fila de esta tabla de resultados. En Oracle, estas filas forman un conjunto denominado conjunto activo del cursor. Si la instrucción SELECT contiene un error, como por ejemplo si se especifica un nombre de columna que no existe, se generará un error en este punto. El formato de la instrucción OPEN es: EXEC SQL OPEN
nombreCursor
Por ejemplo, para abrir el cursor para la consulta anterior, escribiríamos: EXEC SQL OPEN propertyCursor;
La instrucción FETCH extrae la siguiente fila del conjunto activo. El formato de la instrucción FETCH es: EXEC SQL FETCH
nombreCursor
INTO {varibleHost [variablelndicadora]
[, ... ]}
1186
Sistemas de bases de datos
donde nombreCursor el nombre de un cursor que esté actualmente abierto. El número de variables host de la cláusula INTO debe coincidir con el número de columnas de la cláusula SELECT de la consulta correspondiente que se haya incluido en la instrucción DECLARE CURSOR. Por ejemplo, para extraer la siguiente fila del resultado de la consulta en el ejemplo anterior, escribiríamos: EXEC SQL FETCH propertyCursor INTO :propertyNo, :street,
:city;
La instrucción FETCH almacena el valor de la columna propertyNo en la variable host propertyNo, el valor de la columna street en la variable host street, etc. Puesto que la instrucción FETCH opera sobre una única fila de resultado de la consulta, normalmente se la incluye dentro de un bucle en el programa. Cuando ya no hay más filas que devolver en la tabla de resultados de la consulta, se asigna a SQLCODE el valor NOT FOUND, como hemos explicado antes para las consultas monofila. Observe que si no hay filas en la tabla de resultados de la consulta, la función OPEN seguirá posicionando el cursor para que esté listo para las sucesivas extracciones, y dicha instrucción se ejecutará sin ningún error. En este caso, será la primera instrucción FETCH la que detecte que no hay ninguna fila y la que devuelva el valor NOT FOUND en SQLCODE. El formato de la instrucción CLOSE es muy similar al de la instrucción OPEN: EXEC SQL CLOSE donde
nombreCursor
nombreCursor
es el nombre de un cursor que esté actualmente abierto. Por ejemplo,
EXEC SQL CLOSE propertyCursor;
Una vez cerrado el cursor, se borra la definición del conjunto activo. Todos los cursores se cierran automáticamente al final de la transacción en la que están contenidos. Vamos a ilustrar algunos de estos puntos en el Ejemplo E.3.
E.1.5
Utilización de cursores para modificar los datos
Un cursor puede ser de sólo lectura o actualizable. Si la tabla/vista identificada por un cursor no es actualizable (véase la Sección 6.1.4), entonces el cursor será de sólo lectura; en caso contrario, el cursor será actualizable y pueden utilizarse las instrucciones p6Sicionales UPDATE y DELETE CURRENT. Siempre pueden insertarse filas directamente en la tabla base. Si se insertan filas detrás del cursor actual y hay cursores de sólo lectura, el efecto del cambio no será visible a través de ese cursor hasta que no se cierre éste. Si el cursor es actualizable, el estándar ISO especifica que el efecto de dichos cambios dependerá de la implementación. Oracle no hace que las filas recién insertadas sean visibles para la aplicación. Para actualizar datos mediante un cursor en Oracle, hace falta una pequeña extensión de la instrucción DECLARE CURSOR: EXEC SQL CLOSE nombreCursor CURSOR FOR instrucciónSelect FOR UPDATE OF nombreColumna [, ... ]
I
Ejemplo E.3 Consulta multifila Escribir un programa que solicite al usuario que introduzca un número de empleado y que imprima los inmuebles gestionados por dicho empleado. Este programa se muestra en la Figura EA. En este ejemplo, la tabla de resultados de la consulta puede contener más de una fila. En consecuencia, debemos tratar esto como una consulta multifila y utilizar un cursor para extraer los datos. Pedimos al usuario que introduzca un número de empleado y preparamos un cursor para seleccionar las filas correspondientes de la tabla PropertyForRent. Después de abrir el cursor, recorremos en bucle cada fila de la tabla de resultados e imprimimos las columnas correspondientes.
~
E SOL procedimental
/*
** Programa
para imprimir los inmuebles gestionados por un empleado especifico
*1
#include #include EXEC SQL INCLUDE sqJea; mainO EXEC SQL BEGIN DECLARE SECTION; ehar
staffNo[6J;
ehar
propertyNo[6];
/* número de empleado de entrada */ /* número de inmueble devuelto */
ehar
street[26};
/* calle devuelta para el inmueble */
ehar
city[16J;
/* ciudad devuelta para el inmueble */
char
*username
ehar
*password = "Manager";
;::;: '(Manager»;
EXEC SQL END DECLARE SECTION; /* Pedir número de empleado */ printf("Enter staff number: "); seanf("%s", staffNo); /* Conectar a la base de datos */ EXEC SQL CONNECT :username IDENTIFIED BY :password; if (sqlca.sqlcode <
O)
exit (-1);
/* Establecer el tratamiento de errores SQL y luego declarar el cursor para selección */ EXEC SQL WHENEVER SQLERROR GOTO error; EXEC SQL WHENEVER NOT FOUND GOTO done; EXEC SQL DECLARE propertyCursor CURSOR FOR SELECT propertyNc. street, city FROM PropertyForRent WHERE staffNo = :staffNo ORDER by propertyNo; /* Abrir el cursor para comenzar la selección y extraer en bucle cada fila de la tabla de resultados */ EXEC SQL OPEN propertyCursor; for ( ; ; ) { /* Extraer siguiente fila de la tabla de resultados */ EXEC SQL FETCH propertyCursor INTO :propertyNo, :street, :city; /* Mostrar datos */ printf("Property
number: %s\n", propertyNo);
printf("Street:
%s\n", street);
printf("City:
%s\n", eity);
/* Condición de error - imprimir el error */ error:
printf("SQL error %d\n", sqlca.sqlcode); done: /* Cerrar el cursar antes de terminar */ EXEC SQL WHENEVER SQLERROR continue; EXEC SQL CLOSE propertyCursor; EXEC SQL COMMIT WORK RELEASE;
Figura E.4.
Consulta multifila.
1187
1188
Sistemas de bases de datos
Cuando ya no hay más filas que procesar, cerramos el cursor y terminamos el programa. Si se produce un error en cualquier punto, generamos un mensaje de error adecuado y detenemos el procesamie~ La cláusula FOR UPDATE OF debe enumerar las columnas de la tabla especificada en la instrucciónSelect que puedan requerir una actualización; además, las columnas indicadas deben aparecer en la lista SELECT. El formato de la instrucción UPDATE basada en cursor es: EXEC SQL UPDATE NombreTabla SET nombreColumna = valorDatos [, ... ] WHERE CURRENT OF nombreCursor donde
nombreCursor
es el nombre de un cursor actualizable abierto. La cláusula WHERE sirve exclusivamen-
te para especificar la fila a la que apunta actualmente el cursor. La actualización sólo afectará a los datos de dicha fila. Cada nombre de columna de la cláusula SET debe haber sido identificado para actualización en la correspondiente instrucción DECLARE CURSOR. Por ejemplo, la instrucción: EXEC SQL UPDATE PropertyForRent SET staffNo = 'SL22' WHERE CURRENT OF propertyCursor; actualiza el número de empleado, staffNo, de la fila actual de la tabla asociada con el cursor propertyCursor. La actualización no hace que avance el cursor, por lo que será necesario ejecutar otra instrucción FETCH para desplazar el cursor hasta la siguiente fila. También se puede borrar filas mediante un cursor actualizable. El formato de la instrucción DELETE basada en cursor es: EXEC SQL DELE TE FROM NombreTabla WHERE CURRENT OF nombreCursor donde nombreCursor es el nombre de un cursor actualizable abierto. De nuevo, la instrucción se aplica a la fila actual y será necesario ejecutar otra instrucción FETCH para hacer que el cursor avance hasta la siguiente fila. Por ejemplo, la instrucción: EXEC SQL DELETE FROM PropertyForRent WHERE CURRENT OF propertyCursor; borra la fila actual de la tabla asociada.con el cursor propertyCursor. Observe que, para borrar filas, no es necesario especificar la cláusula FOR UPDATE OF de la instrucción DECLARE CURSOR. En Oracle, existe la restricción de que no puede utilizarse CURRENT OF para una tabla con organización basada en índices.
E.1.6
Estándar ISO para el SQL embebido
En esta sección vamos a describir brevemente las diferencias entre el estándar ISO y el dialecto de SQL embebido de Oracle.
La instrucción WHENEVER El estándar ISO no reconoce la condición SQLWARNING de la instrucción WHENEVER.
El área de comunicaciones
de SOL
El están dar ISO no menciona un área de comunicaciones SQL como la que hemos definido en esta sección. Sin embargo, sí que contempla la variable entera SQLCODE, aunque como una característica no recomendada que sólo se soporta por compatibilidad con las versiones anteriores del estándar. En lugar de ello, define
E SOL procedimental
1189
un parámetro SQLSTATE de tipo cadena de caracteres, que comprende un código de clase de dos caracteres y un código de subclase de tres caracteres, basados ambos en un esquema de codificación estandarizado. Para promover la interoperabilidad, SQL predefine todas las excepciones SQL más comunes. El código de clase 00 representa una terminación con éxito, mientras que los otros códigos representan algún tipo de excepción. Por ejemplo, 22012 representa el código de clase 22 (excepción de datos) y el código de subclase 012, que es el que corresponde a la división por cero. Oracle9i soporta el mecanismo SQLSTATE, pero para utilizarlo es necesario declararlo dentro de la sección DECLARE SECTION mediante: char SQLSTATE[6]; Después de ejecutar una instrucción SQL, el sistema devuelve un código de estado mediante la variable SQLSTATE que esté actualmente dentro de ámbito. El código de estado indica si la instrucción SQL se ha ejecutado satisfactoriamente o si ha generado un error o condición de advertencia.
Cursores El estándar ISO especifica la definición y el procesamiento de cursores de forma ligeramente distinta a como aquí hemos presentado. La instrucción DECLARE CURSOR de ISO es como sigue: EXEC SQL DECLARE nombreCursor CURSOR FOR instrucciónSelect [FOR {READ ONLY
I
[INSENSITIVE]
UPDATE [OF
[SCROLL]
listaNombresColumnas]}]
Si se especifica la palabra clave opcional INSENSITIVE, los efectos de los cambios efectuados en la tabla base subyacente no serán visibles para el usuario. Si se especifica la palabra clave opcional SCROLL, el usuario podrá acceder a las filas de manera aleatoria. El acceso se especifica en la instrucción FETCH: EXEC SQL FETCH [[orisntaciónExtracción] INTO varibleHost [, ... ] donde la orientaciónExtracción
FROM]
nombreCursor
puede ser uno de los siguientes valores:
•
NEXT. Extrae la siguiente fila de la tabla de resultados de la consulta, es decir, la fila que sigue inmediatamente a la fila actual del cursor.
•
PRIOR. Extrae la fila de la tabla de resultados de la consulta que precede inmediatamente actual del cursor.
• •
FIRST. Extrae la primera fila de la tabla de resultados de la consulta. LAST. Extrae la última fila de la tabla de resultados de la consulta.
•
ABSOLUTE. Extrae una fila específica, dado su número de fila.
•
RELATIVE. Mueve el cursor hacia adelante o hacia atrás un número especificado de filas con respecto a la posición actual del cursor.
a la fila
Sin esta funcionalidad, para ir hacia atrás a través de una tabla tendríamos que cerrar el cursor, volverlo a abrir y extraer (mediante FETCH) las filas del resultado de la consulta hasta alcanzar aquella que nos interesa.
E.2 SQl dinámico En la sección anterior hemos hablado del SQL embebido o, para ser más precisos, del SQL embebido estático. El SQL estático proporciona una funcionalidad significativa a los desarrolladores de aplicaciones, al permitirles acceder a la base de datos utilizando las instrucciones SQL interactivas normales, con algunas pequeñas modificaciones en ciertos casos. Este tipo de SQL es adecuado para muchas aplicaciones de procesamiento
d, dato,; po, ejemplo, penni',
al d"""Ollad(SOribrr
pmgmmas pam g"lion",
'"",as de mantenimiento p""
1190
Sistemas de bases de datos
los clientes, de introducción de pedidos, de consultas de los clientes y de generación de informes. En cada uno de estos ejemplos, el patrón de acceso a la base de datos está fijo y puede 'precodificarse' en el programa. Sin embargo, existen muchas situaciones en las que el patrón de acceso a la base de datos no está [ljo y sólo se conoce en tiempo de ejecución. Por ejemplo, el diseño de una interfaz que permita a los usuarios definir sus consultas o informes gráficamente y luego genere las correspondientes instrucciones de SQL interactivo requiere una mayor flexibilidad que la que ofrece el SQL estático. El estándar ISO define una técnica alternativa para tales programas, denominada SQL dinámico. La diferencia básica entre los dos tipos de SQL embebido es que el SQL estático no permite utilizar variables hast en lugar de los nombres de tabla o de columna. Por ejemplo, en SQL estático no podemos escribir: EXEC SQL BEGIN DECLARE SECTION; char TableName[20]; EXEC SQL END DECLARE SECTION; EXEC SQL INSERT INTO :TableName VALUES ('CR76', 'PAI4', '05-May-2004',
'Not enough space');
ya que el SQL estático espera que se proporcione el nombre de una tabla de base de datos en la instrucción INSERT y no el nombre de una variable hast. Incluso si esto estuviera permitido, existiría un problema adicional, asociado con la declaración de cursores. Considere la siguiente instrucción: EXEC SQL DECLARE cursor1 CURSOR FOR SELECT * FROM :TableName; El '*' indica que queremos incluir todas las columnas de la tabla TableName en la tabla de resultados, pero el número de columnas variará dependiendo de qué tabla elijamos. Además, los tipos de datos de las columnas también variarán entre unas tablas y otras. Por ejemplo, en la Figura 3.3 las tablas Branch y Staff tienen un número diferente de columnas, y las tablas Branch y Viewing tienen el mismo número de columnas, pero diferentes tipos de datos subyacentes. Si no conocemos el número de columnas y no sabemos cuáles son sus tipos de datos, no podemos utilizar la instrucción FE]CH descrita en la sección anterior, que requiere que se especifiquen el número y los tipos de datos de las variables hast, de forma que éstas se correspondan con los tipos a los que pertenezcan las columnas de la tabla. En la Sección E.2 del sitio web de este libro (véase la URL en el Prefacio) se describen las funcionalidades proporcionadas por el SQL dinámico para resolver estos problemas y para permitir el desarrollo de software de propósito más general.
E.3 El estándar ODBC (Open Database Connectivity) Una técnica alternativa para incluir instrucciones SQL directamente en un lenguaje hast consiste en proporcionar a los programadores una biblioteca de funciones que puedan ser invocadas desde el software de aplicación. Para muchos programadores, la utilización de rutinas de biblioteca resulta bastante común, por lo que suelen considerar que el empleo de una interfaz de programación de aplicaciones (API, Application Programming Interface) constituye una forma relativamente sencilla de utilizar SQL. Con esta técnica, en lugar de incluir instrucciones SQL en bruto dentro del código fuente del programa, el fabricante del SGBD proporciona una API. Esta API está compuesta de un conjunto de funciones de biblioteca para muchos de los tipos más comunes de acceso a base de datos que los programadores requieren, como por ejemplo, la conexión con la base de datos, la ejecución de instrucciones SQL, la extracción de filas individuales de una tabla de resultados, etc. Uno de los problemas de esta técnica, hasta hace no mucho, era la falta de interoperabilidad: era necesario preprocesar los programas utilizando el precompilador proporcionado por el fabricante del SGBD y montar los programas con biblioteca correspondiente a la API del fabricante. Para utilizar la misma aplicación con un SGBD distinto, se necesitaba volver a preprocesar el programa con el otro precompilador y montarlo con otra biblioteca. Los fabricantes independientes de software se enfrentaban con un problema similar, al verse usualmente obligados a escribir una versión de cada aplicación para cada SGBD, o a escribir código específico de cada SGBD al que quisieran acceder. Esto implicaba que se tuviera que invertir una cantidad de
E SOL procedimental
1191
recursos considerable desarrollando y manteniendo rutinas de acceso a los datos, en lugar de dedicar esos recursos a desarrollar y mantener las propias aplicaciones. En un intento de estandarizar esta técnica, Microsoft especificó el estándar ODBC (Open Database Connectivity, conectividad abierta de bases de datos). La tecnología ODBD proporciona una interfaz común para acceder a bases de datos SQL heterogéneas, utilizando SQL como estándar de acceso a los datos. Esta interfaz (definida en el lenguaje C) proporciona un alto grado de interoperabilidad: una aplicación puede acceder a diferentes SGBD SQL utilizando un mismo conjunto de código. Esto permite a los desarrolladores diseñar y distribuir aplicaciones cliente-servidor sin centrarse en un SGBD específico. Después, se añaden los controladores de base de datos para enlazar la aplicación con el SGBD que el usuario haya elegido. ODBC se ha impuesto como estándar de Jacto del sector. Una de las razones de la popularidad de ODBC es su flexibilidad: •
las aplicaciones no están atadas a la API propietaria de ningún fabricante;
•
las instrucciones SQL pueden incluirse explícitamente en el código fuente o construirse dinámicamente en tiempo de ejecución;
•
las aplicaciones pueden prescindir de los detalles relativos a los protocolos de comunicación de datos subyacentes;
•
pueden enviarse y recibirse datos en un formato que resulta cómodo para la aplicación;
•
ODBC está diseñado en conjunción con los estándares X/Open y CL! (Call-Level Interface) de ISO;
•
hoy día, hay disponibles controladores ODBC para la mayoría de los SGBD más populares.
En la Sección 29.7 se examina JDBC, que constituye la técnica más popular y madura para acceder a sistemas SGBD relacionales desde Java, y que es una técnica basada en la especificación ODBC.
E.3.1
La arquitectura ODBC
La interfaz ODBC define lo siguiente: •
una biblioteca de llamadas a función que permite a una aplicación conectarse a un SGBD, ejecutar instrucciones SQL y extraer los resultados;
•
una forma estándar para conectarse a un SGBD e iniciar una sesión;
•
una representació~ I estándar de los tipos de datos;
•
un conjunto estándar de códigos de error;
•
una sintaxis SQL basada en las especificaciones
X/Open y CL! (Call-Level Interface) de ISO.
La arquitectura ODBC tiene cuatro componentes: •
La aplicación, que realiza el procesamiento SQL al SGBD y extraer los resultados.
e invoca las funciones ODBC para enviar instrucciones
•
El gestor de controladores, que carga y descarga controladores por cuenta de las aplicaciones. El gestor de controladores puede procesar las llamadas a función de ODBC o pasárselas a un controlador. El gestor de controladores proporcionado por Microsoft es una biblioteca de montaje dinámico (DLL, Dynamic-Link Library).
•
Un agente del controlador y de la base de datos, que procesa las llamadas a función de ODBC, envía las solicitudes SQL a un origen de datos específico y devuelve los resultados a la aplicación. En caso necesario, el controlador modificará la solicitud de la aplicación para que ésta se adapte a la sintaxis soportada por el SGBD asociado. Los controladores exponen las capacidades de los SGBD subyacentes, no teniendo por qué implementar capacidades que el SGBD no soporte. Por ejemplo, si el SGBD subyacente no soporta las combinaciones externas, el controlador tampoco tiene por qué soportadas. La única excepción significativa a esta regla es que los controladores para sistemas SGBD que no dispongan de motores de base de datos independientes, como Xbase, deben implementar un motor de base de datos que al menos soporte mínimamente SQL.
1192
Sistemas de bases de datos
Aplicación
Gestor de controladores
Aplicación
Interfaz ODSe
Gestor de controladores
Controlador
(b)
(a)
Figura E.5.
Arquitectura ODBC. (a) Múltiples controladores. (b) Un único controlador.
En una arquitectura de múltiples controladores, todas estas tareas son realizadas por el controlador, no existiendo un agente de la base de datos (Figura E.5(a)). En una arquitectura con un único controlador, se diseña un agente de base de datos para el SGBD asociado y se ejecuta el agente en el lado del servidor de la base de datos, como se muestra en la Figura E.5(b). Este agente trabaja conjuntamente con el controlador del lado del cliente para procesar las solicitudes de acceso a la base de datos. Los controladores se implementan como bibliotecas DLL en el entorno Windows. Los agentes de base de datos se implementan como procesos demonio que se ejecutan en el servidor SGBD asociado. •
El origen de datos, que está compuesto por los datos a los que el usuario quiere acceder y por su SGBD asociado, el sistema operativo añtitrión y la plataforma de red, si es que existe.
E.3.2
Niveles de cumplimiento
oose
ODBC define dos niveles distintos de cumplimiento para los controladores: una gramática ODBC API y otra ODBC SQL. En esta sección, vamos a restringir nuestras explicaciones al cumplimiento con la gramática ODBC SQL. El lector interesado puede consultar la Guía de Referencia de ODBC de Microsoft para ver una explicación completa de los niveles de cumplimiento. ODBC define una gramática básica que se corresponde con la especificación CAE de X/Open (1992) y la especificación CL! de ISO (1995). Las versiones anteriores de ODBC estaban basadas en versiones preliminares de estas especificaciones, pero no las implementaban por completo. ODBC 3.0 sí que implementa completamente ambas especificaciones y añade algunas características que los desarrolladores suelen necesitar para aplicaciones de base de datos con acceso a través de pantalla, como es el caso de los cursores desplazables. ODBC también define una gramática mínima que se corresponde con un nivel básico de cumplimiento con ODBC, así como una gramática ampliada que proporciona una serie de extensiones a SQL específicas de cada SGBD:
Gramática SQL mínima •
Lenguaje de definición TABLE.
de datos (DDL, Data Definition
Language):
CREATE TABLE y DROP
•
Lenguaje de manipulación de datos (DML, Data Manipulation Language): SELECT, INSERT, UPDATE SEARCHED y DELETE SEARCHED.
instrucciones
simples
E SOL procedimental • •
1193
Expresiones: simples (como por ejemplo A > B + C). Tipos de datos: CHAR, VARCHAR o LONG VARCHAR.
Gramática SQL básica •
Gramática y tipos de datos SQL mínimos.
•
DDL: ALTER TABLE, CREA TE INDEX, DROP INDEX, CREATE VIEW, DROP VIEW, GRANT y REVOKE.
•
DML: SELECT completa.
•
Expresiones: sub consultas y funciones de conjuntos tales como SUM y MIN.
•
Tipos de datos: DECIMAL, NUMERIC, SMALLINT, INTEGER, REAL, FLOAT, DOUBLE PRECISION.
Gramáticas SQL ampliada
I
•
Tipos de datos y gramática SQL mínima y básica.
•
DML: combinaciones externas, UPDATE posicional, DELETE posicional, SELECT FOR UPDATE y umones.
•
Expresiones: temporal.
•
Tipos de datos: BIT, TINYINT, BIGINT, BINARY, VARBINARY, LONG VARBINARY, DATE, TIME, TIME STAMP.
•
Instrucciones SQL por lotes.
•
Llamadas a procedimientos.
funciones escalares como SUBSTRING y ABS, literales de fecha, de hora y de marca
Ejemplo EA Utilización-de
ODBC
Escribir un programa que imprima los inmuebles gestionados por el empleado SL41. La Figura E.6 rep!~enta el código ODBC de ejemplo para el programa. Por simplicidad, hemos omitido la mayor parte de las tareas de comprobación de errores. Este ejemplo ilustra las operaciones básicas de una aplicaGión típica basada en ODBC: •
Asignar un descriptor de entorno mediante la llamada a SQLAllocEnvO, que asigna la memoria para el descriptor e inicializa la interfaz CL! de ODBC para que la aplicación pueda usada. Un descripto de entorno incluye información acerca del contexto global de la interfaz ODBC, como por ejemplo el estado del entorno y los descriptores de las conexiones que están actualmente asignadas dentro del entorno.
•
Asignar un descriptor de conexión mediante la llamada a SQLAllocConnectO. Una conexión está compuesta de un controlador y un origen de datos. El descriptor de conexión identifica cada conexión e indica qué controlador hay que utilizar y con qué origen de datos debe utilizárselo. También incluye información como el estado de la conexión y los descriptores válidos de instrucciones correspondientes a la conexión.
•
Conectarse con el origen de datos utilizando SQLConnectO. establece una conexión con el origen de datos especificado.
•
Asignar un descriptor de instrucción utilizando SQLAllocStmtO. El descriptor de instrucción incluye información acerca de la instrucción, como por ejemplo, información de la red, valores SQLSTATE y mensajes de error, el nombre del cursor, el número de columnas del conjunto de resultados e información de estado relativa al procesamiento de la instrucción SQL.
Esta llamada carga un controlador y
1194
•
Sistemas de bases de datos
Al terminar, hay que liberar todos los descriptores y finalizar la conexión con el origen de datos. #include
"SQL.H"
#include
#include #define
MAX_STMT_LEN
100
mainO
HENV
hEnv;
/* descriptor
del entorno
HDBC
hDbc;
/* descriptor
de la conexión
*/
HSTMT
hStmt;
/* descriptor
de instrucción
*/
RETCODE
rC;
UCHAR
seIStmt[MAX_STMT
UCHAR
propertyNo[6];
UCHAR
/* código de retorno
*/
*/
/* cadena de instrucción
_LEN];
/* valor de propertyNo
SELECT devuelto
street[26];
/* valor de street devuelto
UCHAR
city(16];
/* valor de city devuelto
SDWORD
propertyNoLen,
SQLAlloeEnv(
streetLen,
&hDbc)
*/ */
cityLen;
&hEnv);
SQLAlloeConnect(hEnv,
*/ */
;
*/
/* asignar
un descriptor
de entorno
/* asignar
un descriptor
de conexión
/* nombre
del origen de datos */
*/
re = SQLConnect(hDbc, "DreamHome", "Manager", "Manager", /* Observe localizando
SQL_NTS, SQL_NTS,
/* identificador
SQL_NTS);
/* contraseña
que SQL _NTS indica al controlador el carácter nulo de terminación */
if (rC == SQL_SUCCESS
11
SQLAllocStmt(hDbe, /* Preparar
la instrucción
rC == SQL_SUCCESS_
&hStrnt);
SELECT,
Istrepy(selStmt,
if (SQLExecDirect(hStrntr exit( -1);
WITH_INFO)
y luego asociar
ejecutarla
"SELECT
la longitud
/* asignar
propertyNo,
'SL41' ORDER
/* Extraer
que debe determinar
de usuario
(
las columnas
street, city FROM PropertyForRent
.. e Stmt, SQL_NTS)
de resultados
*/
where staffNo
=
!= SQL_SUCCESS)
2, SQL_C_CHAR,
street,
SQLBindCol(hStmt,
3, SQL_CCHAR,
propertyNo,
(SDWORD)sizeof(propertyNo),
city, (SDWORD)sizeof(city),
(SDWORD)sizeof(street),
&propertyNoLen);
&streetLen); &cityLen);
fila a fila */
while (rC == SQL_SUCCESS
rC == SQL_SUCCESS_WITH_INFO)
11
(
= SQLFetch(hStmt);
if (rC == SQL_SUCCESS
11
rC == SQL_SUCCESS_ /* imprimir
WITH_INFO)
(
la fila, como antes */
}
SQLFreeStmt(hStmt,
*/
BY propertyNo");
SQLBindCol(hStrnt,
rC
de instrucción
del conjunto
1, SQL_C_CHAR,
de resultados
de la cadena de caracteres
un descriptor
SQLBindCol(hStmt,
el conjunto
*/
*/
SQL_DROP);
SQLDisconnect(hDbc);
/* liberar el descriptor
/* desconectarse
SQLFreeConnect(hDbc);
/* liberar el descriptor
de conexión
SQLFreeEnv(hEnv);
/* liberar el descriptor
de entorno
Figura E.5.
*/
de instrucción
*/
del origen de datos
Aplicación ODBC de ejemplo.
*/ */
E SOL procedimental •
1195
En esta aplicación concreta, el programa construye una instrucción SQL SELECT y la ejecuta utilizando la función ODBC SQLExecDirectO. El controlador modifica la instrucción SQL para utilizar la forma de SQL admitida por el origen de datos, antes de enviar la instrucción al origen de datos. La aplicación puede incluir en caso necesario uno o más contenedores de variable, en cuyo caso deberá invocar la función ODBC SQLBindParameterO para asociar cada uno de los contenedores con una variable del programa. Las sucesivas llamadas a SQLBindColO asignan el almacenamiento y el tipo de datos para columna del conjunto de resultados. A continuación, las sucesivas llamadas SQLFetchO devuelven cada una de las filas del conjunto de resultados (los controladores de variables se describen en la Sección E.2.2 en el sitio web).
Esta estructura resulta apropiada para las instrucciones SQL que se ejecuten una única vez. Si queremos ejecutar una instrucción SQL más de una vez en el programa de aplicación, puede ser más eficiente invocar las funciones ODBC SQLPrepareO y SQLExecuteO, como se explica en la Sección E.2.l, en el sitio web.
-.J
Resumen del apéndice •
Se pueden embeber instrucciones SQL dentro de lenguajes de programación de alto nivel. Las instrucciones embebidas se convierte en llamadas a función mediante un precompilador suministrado por el fabricante del SGBD. Pueden utilizarse variables del lenguaje host dentro de las instrucciones SQL embebidas en todos aquellos lugares donde pueda emplearse una constante. Los tipos más simples de instrucciones SQL embebidas son aquellas que no producen ningún resultado de consulta, en cuyo caso el formato de la instrucción embebida es casi idéntico al de la instrucción SQL interactiva equivalente.
•
Puede incrustarse una instrucción SELECT en un lenguaje host siempre que la tabla de resultados esté compuesta por una única fila. En caso contrario, es necesario utilizar cursores para extraer las filas de la tabla de resultados. Un cursor actúa como un puntero a una fila concreta de la tabla de resultados. La instrucción DECLARE CURsDR define la consulta; la instrucción OPEN la ejecuta, identifica todas las filas que satisfacen la condición de búsqueda de la consulta y coloca el cursor antes de la primera fila de la tabla de resultados; la instrucción FETCH extrae filas sucesivas de la tabla de resultados. La instrucción CLOSE cierra el cursor para terminar el procesamiento de la consulta. Pueden utilizarse instrucciones UPDATE y DELETE posicionales para actualizar o borrar la fila actualmente seleccionada por un cursor.
•
El SQL dinámico es una fo~a ampliada del SQL embebido, que permite escribir programas de aplicación de propósito más general. El SQL dinámico se utiliza cuando parte de la instrucción SQL, o toda ella, se desconoce en ti'empo de compilación y esa parte que se desconoce no es una constante.
•
La tecnología ODBC (Open Database Connectivity) de Microsoft proporciona una interfaz común para acceder a bases de datos SQL heterogéneas. ODBC está basado en SQL como estándar de acceso a los datos. Esta interfaz (construida en el lenguaje C) proporciona un alto grado de interoperabilidad: una aplicación puede acceder a diferentes SGBD SQL utilizando un conjunto de código común. Esto permite al desarrollador construir y distribuir aplicaciones cliente-servidor sin centrarse en un SGBD específico. Después, se añaden controladores de base de datos para enlazar la aplicación con el SGBD que el usuario haya seleccionado. ODBC se ha consolidado como estándar de Jacto del sector.
Cuestiones de repaso E.l.
Explique las diferencias entre el SQL interactivo, el SQL embebido estático y el SQL embebido dinámico.
E.2.
Describa qué son las variables del lenguaje host y proporcione un ejemplo de uso.
E.3.
Describa el concepto de variables indicadoras y proporcione un ejemplo de uso.
1196
Sistemas de bases de datos
Ejercicios Responda las siguientes cuestiones utilizando el esquema relacional de los ejercicios del Capítulo 3. EA.
Escriba un programa que pida al usuario que introduzca los detalles de un huésped e inserte el registro en la tabla de huéspedes.
E.5.
Escriba un programa que pida al usuario que introduzca los detalles de una reserva, compruebe que existen el hotel, el huésped y la habitación especificados e inserte el registro en la tabla de reservas. Escriba un programa que incremente el precio de todas las habitaciones en un 5%.
E.6. E.7.
Escriba un programa que calcule el importe total de la factura para cada uno de los clientes que abandonan el hotel Grosvenor en un día especificado.
E.8.
Investigue la funcionalidad de SQL embebido del SGBD que esté utilizando. Explique en qué se diferencia del estándar ISO para SQL embebido.
e
Apénalce
Notaciones alternativas para modelado ER Objetivos En este apéndice aprenderá: •
Cómo se crean modelos ER utilizando notaciones alternativas.
En los Capítulos 11 y 12 hemos visto como crear un modelo entidad-relación (ER) ampliado utilizando una notación cada vez más popular denominada UML (Unified Modeling Language). En este apéndice vamos a exponer dos notaciones adicionales que se utilizan a menudo para crear modelos ER. La primera notación ER se denomina notación Chen y la segunda se llama notación de pie de cuervo. Ilustraremos cada una de estas notaciones presentando una tabla donde se muestre la notación correspondiente a cada uno de los conceptos principales del modelo ER, después de lo cual presentaremos la notación utilizando como ejemplo parte del diagrama ER mostrado en la Figura 11.1.
~ 1 Modelado ER utilizando la notación Chen La Tabla El muestra la notació'b. Chen para los conceptos principales del modelo ER y la Figura E 1 muestra parte del diagrama ER de la Figura 11.1, redibujado utilizando la notación Chen.
~2
Modelado ER utilizando la notación en pie de cuervo
La Tabla E2 muestra la notación en pie de cuervo para los conceptos principales del modelo ER y la Figura E2 muetra parte del diagrama ER de la Figura(ll.l, redibujado utilizando la notación en pie de cuervo. Tabla F.1. La notación Chen para el modelado ER. Notación
Significado
Nombre Entidad
Entidad fuerte
Nombre Entidad
Entidad débil
(Continúa)
1198
Sistemas de bases de datos Tabla F.1. (Cont.). La notación Chen para el modelado ER. Notación
Significado
Relación
Relación asociada con una entidad débil
Nombre relación Nombre rol
Nombre rol
Relación recursiva con nombres de rol para identificar los roles correspondientes a la entidad dentro de la relación
Nombre entidad
Atributo
Atributo de clave principal
Atributo multivaluado
/ ':~ombre atribut?:,
Atributo derivado
Relación uno a uno (1: 1)
Relación uno a muchos (1 :M)
Relación muchos a muchos (M:N) (Continúa)
F Notaciones alternativas para modelado ER Tabla F.1. (Cant.). La notación Chen para el modelado ER. Notación
A
Significado
~
Relación uno a muchos con participación obligatoria para ambas entidades A y B
B
Relación uno a muchos con participación opcional para la entidad A y participación obligatoria para la entidad B
Relación uno a muchos con participación opcional para ambas entidades A y B
Generalización/especialización. Si el círculo contiene' d', la relación será disjunta (como se muestra); si el círculo contiene' o', la relación será no disjunta. Una doble línea desde la superclase hasta el círculo representa una participación obligatoria (como se muestra); una línea simple representa participación opcional
Supervisor Staff
Supervises
Branch M
Supervisee
M
Has
Registers
M
Client
Figura F.1. Parte del diagrama ER mostrado en la Figura 11.1, redibujado utilizando la notación Chen.
Preference
1199
>
1200
Sistemas de bases de datos Tabla F.2. La notación en pie de cuervo para el modelado ER. Notación
Significado
Nombre entidad
Entidad
Nombre relación
Relación
Nombre relación Nombre rol
Nombre rol
Relación recursiva con nombres de rol para identificar los roles en que participa la entidad dentro de la relación
Nombre entidad
Nombre entidad Nombre Atributo Atributo Atributo
atributo 1 2 n
<
Nombre Nombre relación Nombre relaciónrelación
~ oE1 Nombre relación
Los atributos se enumeran en la sección inferior del símbolo de entidad El atributo de clave primaria está subrayado Los atributos multivaluados se incluyen entre llaves {}
B
Relación uno a uno
Relación uno a muchos
Relación muchos a muchos
Relación uno a muchos con participación obligatoria para ambas entidades A y B
Relación uno a muchos con participación opcional para la entidad A y participación obligatoria para la entidad B
Relación uno a muchos con participación opcional para ambas entidades A y B (Continúa)
F Notaciones alternativas para modelado ER Tabla F.2. (Cant.). La notación en pie de cuervo para el modelado ER. Notación
Significado
Superclase Convenio de 'cajas dentro de cajas' para· representar la generalización/especialización
I Subclase
I
I
Subclase
I
Supervises mgrStartDate Supervisee Manages staffNo
Branch
Has
branchNo
Registers
Client
States
Preference
c1ientNo
Figura F.2. Parte del diagrama ER mostrado en la Figura 11.1, redibujado utilizando la notación en pie de cuervo.
1201
Apenalce
Resumen de la metodología de diseño de bases de datos relacionales Objetivos En este apéndice aprenderá: •
Que el diseño de base de datos está compuesto de tres fases principales: diseño conceptual, lógico y físico de la base de datos.
•
Los pasos que componen las fases principales de la metodología de diseño de la base de datos.
En este libro, presentamos una metodología de diseño de bases de datos para bases de datos relacionales. Esta metodología está formada por tres fases principales, diseño conceptual, lógico y físico de la base de datos, fases que se describen en detalle en los Capítulos 15-18. En este apéndice se resumen los pasos que componen cada una de estas fases, para aquellos lectores que ya estén familiarizados con el diseño de bases de datos. Paso 1 Construcción de un modelo conceptual de los datos El primer paso en el diseño conceptual de una base de datos consiste en construir uno o más modelos conceptuales de los datos, de acuerdo con los requisitos de datos de la organización. Un modelo conceptual de los datos comprende: •
tipos de entidad;
•
tipos de relación;
•
atributos y dominios de los atributos;
•
claves principales y claves alternativas;
•
restricciones de integridad.
El modelo conceptual de los datos está soportado en un conjunto de documentación que incluye diagramas ER y un diccionario de datos, el cual se genera al desarrollar el modelo. Detallaremos los tipos de documentación de soporte que puedan generarse a medida que vamos repasando los distintos pasos. Paso 1.1
Identificar los tipos de entidad
El primer paso a la hora de construir un modelo conceptual local de los datos es definir los objetos principales en los que los usuarios están interesados. Un método para identificar las entidades consiste en examinar la especificación de requisitos del usuario. A partir de esta especificación, identificamos nombres o frases nominales que se mencionen en ella. También buscamos objetos principales, como personas, lugares o conceptos de interés, excluyendo aquellos nombres que sean simplemente cualidades de otros objetos. Se documentan los tipos de entidad. Paso 1.2
Identificar los tipos de relación
Se identifican las relaciones importantes que existen entre los tipos de entidad que se hayan identificado. Se utiliza el modelado entidad-relación (ER) para visualizar las entidades y las relaciones. Se determinan las res-
1204
Sistemas de bases de datos
tricciones de multiplicidad de cada tipo de relación. tivas. Se documentan los tipos de relación. Paso 1.3
Identificar
Se asocian atributos puesto, los atributos Paso 1.4
Paso 1.5
Considerar
y
multiplicativas
y restric-
de relación
o relación apropiados. Se identifican los atributos simples/comy los atributos derivados. Se documentan los atributos.
para los atributos
en el modelo
los atributos de clave candidata,
Se identifican las claves candidatas para cada entidad clave principal. Se documentan las claves principales Paso 1.6
trampas
los dominios de los atributos
los dominios
Determinar
las posibles
asociar los atributos con los tipos de entidad
con los tipos de entidad univaluados/multivaluados
Determinar
Se determinan atributos.
y
Se buscan
Tabla G.1.
de modelado
principal
Se documentan
los dominios
de los
y alternativa
y, si hay más de una clave candidata, se elige una como y alternativas para cada entidad fuerte.
el uso de conceptos de modelado
Se considera el uso de conceptos ción y composición.
conceptual.
avanzado,
avanzados
(paso opcionalj
como los de especialización/generalización,
agrega-
Resumen de la asignación de entidades y relaciones a las tablas.
Entidad/Relación
Asignación
Entidad fuerte
Crear una relación que incluya todos los atributos simples.
Entidad débil
Crear una relación que incluya todos los atributos simples (todavía habrá que identificado la clave principal después de haber asignado la relación con cada una de las entidades propietarias).
Relación binaria 1:*
Incluir la clave principal de la entidad del lado 'uno' para actuar como clave externa en la tabla que represente la entidad en el lado 'muchos'. Los atributos que tenga la relación también se incluyen en el lado 'muchos'
Relación binaria 1: 1: (a) Participación obligatoria en ambos lados
Combinar las entidades en una tabla.
(b) Participación
obligatoria en un ladó
Incluir la clave principal de la entidad del lado 'opcional' para que actúe como clave externa en la tabla que represente a la entidad del lado 'obligatorio'.
(c) Participación
opcional en ambos lados
Arbitraria si no se dispone de información adicional.
Relación superclase/subclase
Véase la Tabla 16.1.
Relación binaria *:*, relación compleja
Crear una tabla para representar la relación e incluir en ella los atributos de la relación. Incluir también una copia de las claves principales de cada una de las entidades propietarias en la nueva tabla, con el fin de que actúen como claves externas.
Atributo multivaluado
Crear una tabla para representar el atributo multivaluado e incluir una copia de la clave principal de la entidad propietaria en la nueva tabla, con el fin de que actúe como clave externa.
G Resumen de la metodología de diseño de bases de datos
1205
Tabla G.2. Directrices para la representación
basándose Restricción
Restricción de disyunción
Tabla requerida
Obligatoria
No disjunta {And}
Una única tabla (con uno o más discriminadores para distinguir el tipo de cada tupla).
Opcional
No disjunta {And}
Dos tablas: una tabla para la superclase y otra para todas las subclases (con uno o más discriminadores para distinguir el tipo de cada tupla).
Obligatoria
Disjunta {Or}
Muchas tablas: una tabla para cada combinación superclase/subclase.
Opcional
Disjunta {Or}
Muchas tablas: una tabla para cada superclase y otra para cada subclase.
Paso 1.7
de participación
de una relación superclase/subclase en las restricciones de participación y disyunción.
Comprobar
si el modelo tiene redundancia
Se comprueba la presencia de redundancia en el modelo. Específicamente, se re-examinan las relaciones uno a uno (1: 1), se eliminan las relaciones redundantes y se considera la dimensión temporal. Paso 1.8
Validar el modelo conceptual
comprobando
las transacciones
de los usuarios
Se verifica que el modelo conceptual soporte las transacciones requeridas. Dos posibles enfoques son: describir las transacciones y utilizar las rutas de transacción. Paso 1.9
Repasar
el modelo de datos conceptual
con los usuarios
Se revisa el modelo de datos conceptual con el usuario para garantizar que el modelo sea una representación 'verdadera' de los requisitos d~ datos de la organización. Paso 2
Construir y validar el modelo lógico de los datos
Construir un modelo lógico de los datos a partir del modelo conceptual de los datos y luego se valida este modelo para garantizar que sea estructural mente correcto (utilizando la técnica de normalización) y para garantizar que soporte las transacciones requeridas. Paso
2.1
Determinar
las relaciones para el modelo lógico de los datos
Se crean tablas a partir del modelo conceptual de los datos para representar las entidades, relaciones y atributos que hayan sido identificados. La Tabla 0.1 resume cómo establecer la correspondencia entre entidades, relaciones y atributos y las tablas. Se documentan las tablas y los atributos de clave externa. Asimismo, se documentan las nuevas claves principales o alternativas que se hayan formado como resultado del proceso de definición de las tablas. Paso
2.2
Validar las relaciones
mediante
técnicas de normalización
Se validan las tablas en el modelo lógico de datos utilizando la técnica de normalización. El objetivo de este paso es comprobar que cada relación se encuentra al menos en tercera forma normal (3NF). Paso
2.3
Validar las relaciones
comprobando
las transacciones
de los usuarios
Se comprueba que las relaciones del modelo lógico de datos soportan las transacciones requeridas. Paso 2.4
Comprobar
las restricciones
de integridad
Se identifican las restricciones de integridad, lo que incluye especificar los datos requeridos, las restricciones que afectan a los dominios y a los atributos, las restricciones de multiplicidad, la integridad de las entidades, la integridad referencial y las restricciones generales. Se documentan todas las restricciones de integridad.
1206
Paso
Sistemas de bases de datos 2.5
Repasar
el modelo lógico de los datos con los usuarios
Se comprueba que los usuarios consideren el modelo lógico de los datos como una representación verdadera de los requisitos de datos de la empresa. Paso
2.6
Combinar los modelos lógicos de los datos en un modelo global
La metodología del Paso 2 está presentada para que pueda aplicarse al diseño de sistemas de base de datos tanto simples como complejos. Por ejemplo, para crear una base de datos con una única vista de usuario o con múltiples vistas de usuario que estén siendo gestionadas mediante el enfoque centralizado (véase la Sección 9.5), se omite el Paso 2.6. Sin embargo, si la base de datos tiene múltiples vistas de usuario y éstas están siendo gestionadas utilizando la técnica de integración de vistas (véase la Sección 9.5), entonces se repiten los Pasos 2.1 a 2.5 para los diversos modelos de datos, cada uno de los cuales representa diferentes vistas de usuario del sistema de base de datos. En el Paso 2.6, estos modelos de datos se combinan. Las tareas típicas asociadas con el proceso de combinación son las siguientes: (1) Revisar los nombres y el contenido de las entidades/tablas y de sus claves candidatas. (2) Revisar los nombres y los contenidos de las relaciones/claves (3) Combinar las entidades/tablas (4) Incluir (sin combinadas)
las entidades/tablas exclusivas de cada modelo de datos local.
(5) Combinar las relaciones/claves (6) Incluir (sin combinadas)
externas.
de los modelos de datos locales.
externas de los modelos de datos locales.
las relaciones/claves
externas exclusivas de cada modelo de datos local.
(7) Verificar si falta alguna entidad/tabla o relación/clave externa. (8) Comprobar las claves externas. (9) Comprobar las restricciones de integridad. (10) Dibujar el diagrama ER global. (11) Actualizar la documentación. Validar las tablas creadas a partir del modelo lógico de datos global utilizando la técnica de normalización y"'"garantizar que soporten las transacciones requeridas, en caso necesano. Paso
2.7
Verificar las consideraciones
derivadas
del crecimiento
futuro
Se determina si hay previstos cambios significativos en el futuro y se comprueba que el modelo lógico de datos puede admitir estos cambios. Paso 3 Traducir el modelo lógico'de los datos al SGSD seleccionado Se genera un esquema de base de datos relacional que pueda implementarse en el SGBD seleccionado a partir del modelo lógico de los datos. Paso 3. 1
Diseñar las relaciones base
Se decide cómo representar las relaciones base que hayan sido identificadas en el modelo lógico de los datos dentro, del SGBD seleccionado. Se documenta el diseño de las tablas base. Paso
3.2
Diseñar la representación
de los datos derivados
Se decide cómo representar los datos derivados presentes en el modelo lógico de los datos, dentro del SGBD seleccionado. Se documenta el diseño de los datos derivados Paso
3.3
Diseñar las restricciones
generales
Se diseñan las restricciones generales para el SGBD seleccionado. Se documenta el diseño de las restricciones generales.
G Resumen de la metodología de diseño de bases de datos Paso 4
1207
Diseñar la organización de los archivos y los índices
Se determinan las organizaciones óptimas de archivo para almacenar las relaciones base y los índices requeridos para conseguir un rendimiento aceptables, es decir, se define la forma en que se guardarán en almacenamiento secundario las tablas y tuplas. Paso
4.1
Analizar
las transacciones
Se analiza la funcionalidad de las transacciones que se ejecutarán en la base de datos y se analizan en detalle las transacciones más importantes. Paso 4.2
Seleccionar
la organización
de los archivos
Se determina una organización de archivo eficiente para cada tabla base. Paso 4.3
Seleccionar
los índices
Se determina si la adición de índices permitirá mejorar el rendimiento del sistema. Paso 4.4
Estimar los requisitos de espacio de disco
Se estima la cantidad de espacio de disco que se necesitará en la base de datos. Paso 5
Diseñar las vistas de usuario
Se diseñan las vistas de usuario identificadas durante la etapa de recopilación y análisis de requisitos del proceso de diseño del sistema de base de datos relaciona!. Se documenta el diseño de las vistas de usuario. Paso 6
Diseñar los mecanismos de seguridad
Se diseñan las medidas de seguridad para el sistema de base de datos, según las hayan especificado los usuarios. Se documenta el diseño de las medidas de seguridad. Paso 7 Considerar la introducción de una cantidad controlada de redundancia Se determina si puede mejorarse el rendimiento del sistema introduciendo redundancia de manera controlada, relajando las reglas de normalización. Por ejemplo, se considera si resultaría conveniente duplicar atributos o combinar relaciones. Se documenta la introducción de redundancia. Paso 8
Monitorización y optimización del sistema final
Se monitoriza el sistema operacional y se mejoran las prestaciones del sistema para corregir las relaciones de diseño inapropiadas o para reflejar los cambios en los requisitos.
Referencias Abiteboul S., Quass D., McHugh J., Widom J. y Wiener J. (1997). The Lorel query language for semistructured data. International Journal on Digital Libraries, 1(1), 68-88 Aho AY. Y Ullman J.D. (1977). PrincipIes of Database Design. Addison- Wesley
A, Sagiv y. y Ullman J.D. (1979). Equivalence among relational expressions. SIAM Journal of Computing, 8(2), 218-246
Aho
Alsberg P.A. y Day J.D. (1976). A principie for resi1ient sharing of distributed resources. In Proc. 2nd Int. Conf Software Engineering, San Francisco, CA, 562-570 American National' Standards Institute (1975). ANSI/X3/SPARC Study Group on Data Base Management Systems. Interim Report, FDT. ACM SIGMOD Bulletin, 7(2)
Atkinson M. Y Buneman P. (1989). Type and persistence in databas e programming languages. ACM Computing Surv., 19(2) Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D. y Zdonik S. (1989). Object-Oriented Database System Manifesto. In Proc. 1st 1nt. Conf Deductive and Object-Oriented Databases, Kyoto, Japón, 40-57 Atkinson M.P. y Morrison R. (1995). Orthogonally persistent object systems. VLDB Journal, 4(3), 319--401 Atkinson M.P., Bailey P.J., Chisolm K.J., Cockshott w.P. y Morrison R. (1983). An approach to persistent programming. Computer Journal, 26(4), 360-365 Atwood T.M. (1985). An object-oriented DBMS for design support applications. In Proc. IEEE 1st Int. Conf Computer-Aided Technologies, Montreal, Canadá, 299-307
Anahory S. y Murray D. (1997). Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems. Harlow, Reino Unido: Addison Wesley Longman
Bailey R.W. (1989). Human Performance Engineering: Using Human Factors/Ergonomics to Archive Computer Usability 2nd edn. Englewood Cliffs, NJ: Prentice-Hall
Annevelink J. (1991). Database programming languages: a functional approacl1. In Froc. ACM SIGMOD Conf, 318-327
Bancilhon F. y Buneman P. (1990). Advanced in Database Programming Languages. Reading, MA: Addison-Wesley, ACM Press
Apers P., Henver A y Yao S.B. (1983). Optimization algorithm for distributed queries. IEEE Trans Software Engineering, 9(1), 57-68
Bancilhon F. y Khoshafian S. (1989). A calculus for complex objects. J. Computer and System Sciences, 38(2), 326-340
Armstrong, W. (1974). Dependency structure of data base relationships. Praceedings of the IFIP Congress Arnold K., Gosling J. y Holmes D. (2000). The Java Programming Language 3rd edn, Addison Wesley Astrahan M.M., Blasgen M.W., Chamberlin D.D., Eswaran K.P., Gray J.N., Griffith P.P., King w.F., Lorie R.A., McJones P.R., Mehl J.w., Putzolu G.R., Traiger I.L., Wade B.W. y Watson V. (1976). System R: Relational approach to database management. ACM Trans. Database Systems, 1(2),97-137
Banerjee J., Chou H., Garza J.F., Kim W., Woelk D., Ballou N. y Kim H. (1987a). Data model issues for object-oriented applications. ACM Trans. Office Information Systems, 5(1), 3-26 Banerjee J., Kim w., Kim H.J. y Korth H.F. (1987b). Semantics and implementation of schema evolution in object-oriented databases. In Prac. ACM SIGMOD Conf, San Francisco, CA, 311-322 Barghouti N.S. y Kaiser G. (1991). Concurrency control in advanced database applications. ACM Computing Surv.
1210
Sistemas de bases de datos
Batini C., Ceri S. y Navathe S. (1992). Conceptual Database Design: An Entity-Relationship Approach. Redwood City, CA: Benjamin/Cummings
Biskup J.
Batini C. y Lanzerini M. (1986). A comparative analysis of methodologies for databas e schema integration. ACM Computing Surv., 18(4)
Bitton D., DeWitt D.J. y Turbyfill C. (1983). Benchmarking database systems: a systematic approach. In ProC. 9th Int. Conf on VLDB, Florencia, Italia, 8-19
Batory D.S., Leung TY. y Wise TE. (1988). Implementation concepts for an extensible data model and data language. ACM Trans. Database Systems, 13(3), 231-262
Y
Convent B. (1986). A Formal View
Integration Method. In Proc. of ACM SIGMOD Conf. on Management of Data, Washington, DC
Blaha M. y Premerlani W. (1997). Object-Oriented Modeling and Design for Database Applications. Prentice Hall
Bayer R. y McCreight E. (1972). Organization and maintenance of large ordered indexes. Acta Informatica, 1(3), 173-189
Booch G., Rumbaugh 1. y Jacobson 1. (1999). Unified Modeling Language User Guide. Reading, MA: Addison Wesley
Beech D. y Mahbod B. (1988). Generalized version control in an object-oriented database. In IEEE 4th Int. Conf. Data Engineering, febrero de 1988
Boucelma O. y Le Maitre J. (1991). An extensible functional query language for an object oriented databas e system. In Proc. 2nd Int. Conf Deductive and ObjectOriented Databases, Munich, Alemania, 567-581
Bell D.E. y La Padula L.J. (1974). Secure computer systems: mathematical foundations and model. MITRE Technical Report M74-244 Bennett K., Ferris M.C. y Ioannidis Y. (1991). A genetic algorithm for database query optimization. In Proc. 4th Int. Conf on Genetic Algorithms, San Diego, CA, 400--407 Bergsten H. (2003). JavaServer Pages. O'Reilly BernersLee T (1992). The Hypertext Transjer Protocolo World Wide Web Consortium. Work in Pro~ess. Disponible en http://www. w3.org/Protocols/Overview.htmr"" Berners-Lee T y Connolly D. (1993). The Hypertext Markup Language. World Wide Web Consortium. Work in Progress. Disponible en http://www.w3.org/MarkUp/MarkUp.html Berners-Lee T, Cailliau R., Luotonen A., Nielsen H.F. y SecretA. (1994). The World Wide Web .. Comm. ACM, 37(8), agosto Berners-Lee T, Fielding R. y Frystyk H. (1996). HTTP Working Group Internet Draft HTTP/l.O. Mayo de 1996. Disponible en http://ds.internic.net/rfc/rfc1945. txt Bernstein P.A. y Chiu D.M. (1981). Using Semi-joins to Solve Relational Queries. Journal ofthe A CM, 28(1), 25--40 Bernstein P.A., Hadzilacos V. y Goodman N. (1987). Concurrency Control and Recovery in Database Systems. Reading, MA: Addison-Wesley Berson A. y Smith S.J. (1997). Data Warehousing, Data Mining, & OLAP. Nueva York, NY: McGraw Hill Companies Inc.
Bouguettaya A., Benatallah B. y Elmagarmid A. (1998). Interconnecting Heterogeneous Information Systems. Kluwer Academic Publishers Bourret R. (2001). Mapping DTDs to Databases. Disponible en http://www.xmI.com/pub/a/2001/05/09/dtdtodbs.html Bourret R. (2004). Mapping W3C Schemas to Object Schemas to Relational Schemas. Disponible en http://www.rpbourret.com/xmI/SchemaMap.htm Boyce R., Chamberlin D., King W. y Hammer M. (1975). Specifying queries as relational expressions: SQUARE. Comm. ACM, 18(11),621-628 Brathwaite K.S. (1985). Data Administration:
Selected
Topics of Data Control. Nueva York: John Wiley Brooks P. (1997). Data marts grow up. DBMS Magazine. Abril de 1997,31-35 Bukhres OA y Elmagarmid A.K., eds (1996). ObjectOriented Multidatabase Systems: A Solutionfor Advanced Applications. Englewood Cliffs, NJ: Prentice-Hall Buneman P. y Frankel R.E. (1979). FQL -A Functional Query Language. In Proc. ACM SIGMOD Conf., 52-58 Buneman P., Davidson S., Hillebrand G. y Suciu D. (1996). A query language and optimization techniques for unstructured data. In Froc. ACM SIGMOD Conf Montreal, Canadá Buretta M. (1997). Data Replication:
Tools and
Techniques for Managing Distributed Information. Nueva York, NY: Wiley Computer Publishing
1211
Referencias
Cabena P., Hadjinian P., Stadler R., Verhees J. y Zanasi A. (1997). Discovering Data Mining from Concept to Implementation. New Jersey, EE.UU.: Prentice-Hall PTR Cannan S. y Otten G (1993). SQL - The Standard Handbook. Maidenhead: McGraw-Hill Intemational Cardelli L. y Wegner P. (1985). On understanding types, data abstraction and polymorphism. ACM Computing Surv., 17(4), 471-522 \Carey M.J., DeWitt D.l y Naughton lE (1993). The 007 Object-Oriented Database Benchmark. In Proc. ACM SIGMOD Conf Washington, D.C. Cattell R.GG (1994). Object Data Management: ObjectOriented and Extended Relational Database Systems revised edn. Reading, MA: Addison- Wesley Cattell R.GG, ed. (2000). The Object Database Standard: ODMG Release 3.0. San Mateo, CA: Morgan Kaufmann
1
Childs D.L. (1968). Feasibility of a set-theoretical data structure. In Proc. Fall Joint Computer Conference, 557-564 Chou H.T y Kim W. (1986). A unifying framework for versions in a CAD environment. In Proc. Int. Conf Very Large Data Bases, Kyoto, Japón, agosto de 1986, 336-344 Chou H.T. y Kim W. (1988). Versions and change notification in an object-oriented database system. In Proc. Design Automation Conference, junio de 1988, 275-281 Cluet S., Jacqmin S. y Simeon J. (1999). The New YATL: Design and Specifications. Technical Report, INRIA Coad P. y Yourdon E. (1991). Object-Oriented 2nd edn. Englewood Cliffs, NJ: Yourdon Press/Prentice- Hall
Analysis
Cockshott w.P. (1983). Orthogonal Persistence. PhD thesis, University ofEdinburgh, febrero de 1983
Cattell R.GG y Skeen (1992). Object operations benchmark. ACM Trans. Database Systems, 17, 1-31
CODASYL Database Task Group Report (1971). ACM, Nueva York, abril de 1971
Ceri S., Negri M. y Pelagatti G (1982). Horizontal Data Partitioning in Database Design. ACM SIGMOD Conf., 128-136
Codd E.F. (1970). A relational model of data for large shared data banks. Comm. ACM, 13(6), 377-387
Chakravarthy v., Grant J. y Minker J. (1990). Logicbased approach to semantic query optimization. ACM Trans. Database Systems, 15(2), 162-207
Codd E.E (1971). A data base sublanguage founded on the relational calculus. In Froc. ACM SIGFIDET Conf. on Data Description, Access and Control, San Diego, CA,35-68
Chamberlin D. y Boyce R. (1974) SEQUEL: A Structured English Query Language. In Proc. ACM SIGMOD Workshop ~ata Description, Access and Control
Codd E.E (1972a). Relationa1 completeness of data base sublanguages. In Data Base Systems, Courant Computo Sci. Symp 6th (R. Rustin, ed.), 65-98. Englewood Cliffs, NJ: Prentice-Hall
Chamberlin D. et al. (1976). SEQUEL2: A unified approach to data definition, manipulation and control. IBM 1. Research and Development, 20(6), 560-575
Codd E.E (1972b). Further normalization ofthe data base relational model. In Data Base Systems (Rustin R., ed.), Englewood Cliffs, NJ: Prentice-Hall
Chamberlin D., Robie.l y Florescu D. (2000). Quilt: an XML Query Language for heterogeneous data sources. In Lecture Notes in Computer Science, SpringerVerlag. También disponible en http://www.almaden.ibm.com/cs/people/ cham berlin/quilUncs.pdf
Codd E.E (1974). Recent investigations in relational data base systems. In Proc. IFIP Congress
Chen P.M., Lee E.K., Gibson GA., Katz R.H., Patterson D.A. (1994). RAID: High-Performance, Reliable Secondary Storage. ACM Computing Surveys, 26(2)
Codd E.F. (1982). The 1981 ACM TuringAward Lecture: Re1ational database: A practical foundation for productivity. Comm. A CM, 25(2), 109-117
Chen P.M. y Patterson D.A. (1990). Maximizing Performance in a Striped Disk Array. In Prac. of 17th Annual International Symposium on Computer Architecture
Codd E.E (1985a). Is your DBMS really relationally Computerworld, 14 de de 1985, 1-9
Chen P.P. (1976). The Entity-Re1ationship modelToward a unified view of data. A CM Trans. Database
Codd E.E (1986). Missing information (applicable and inapplicable) in re1ational databases. ACM SIGMOD Record, 15(4)
Systems, 1(1), 9-36
Codd E.E (1979). Extending the data base relational model to capture more meaning. ACM Trans. Database Systems, 4(4), 397--434
Codd E.E (1985b). Does your DBMS run by the rules? Computerworld, 21 de octubre de 1985,49-64
1212
Sistemas de bases de datos
Codd E.E (1987). More commentary on missing information in relational databases. ACM SIGMOD Record, 16(1) Codd E.E (1988). Domains, keys and referential integrity in relational databases.InfoDB, 3(1) Codd E.F. (1990). The Re!ationa! Mode!for Database Management Version 2. Reading, MA: Addison-Wesley Codd E.E, Codd S.B. y Salley C.T (1993). Providing OLAP (On-hne Analytical Processing) to UserAnalysts: An IT Mandate. Hyperion Solutions Corporation. Disponible en http://www.hyperion.com/solutions/whitepapers.cfm Comer D. (1979). The ubiquitous B-tree. ACM Computing Surv., 11(2), 121-138 Connolly TM. (1994). The 1993 object database standard. Technica! Report 1 (3), Computing and lnformation Systems, University of Paisley, Paisley, Escocia Connolly TM. (1997). Approaches to Persistent Java. Technica! Report 4(2), Computing and Information Systems, University of Paisley, Escocia Connolly TM. y Begg C.E. (2000). Database Solutions: A Step-by-Step Guide to Building Databases. Harlow: Addison- Wesley Connolly TM., Begg C.E. y Sweeney J. (1994). Distributed database management systems: ha ve they arrived? Technica! Report 1(3), Computing and Information Systems, University of Paisley, Paisley, Escocia ~ CRISP-DM (1996). CRISP-DM Version 1. Disponible en http://www.crisp-dm.org. DAFT (Database Architecture Framework Task Group) (1986). Reference Model for DBMS Standardization. SIGMOD Record, 15(1) Dahl O.J. y Nygaard K. (1966). Simula - an ALGOLbased simulation language. Comm. ACM, 9, 671-678 Darling C.B. (1996). How to Integrate your Data Warehouse. Datamation, mayo de 15, 40-51 Darwen H. y Date C.J. (1995). The Third Manifesto. SIGMOD Record, 24(1), 39-49 Darwen H. y Date C.l. (2000). Foundations for Future Database Systems: The Third Manifesto 2nd edn. Harlow: Addison Wesley Longman Date C.l. (1986). Re!ationa! Database: Se!ected Writings. Reading, MA: Addison- Wesley Date CJ. (l987a). Where SQL falls short. Datamation, mayo de 1987,83-86
Date C.J. (1987b). Twelve mIes for a distributed database. Computer Wor!d, 8 de junio, 21(23), 75~81 Date c.l. (1990). Referential integrity and foreign keys. Part 1: Basic concepts;' Part II: Further considerations. In Re!ationa! Database Writing 1985-1989 (Date C.J.). Reading, MA: Addison-Wesley Date C.J. (2003). An Introduction to Database Systems 8th edn. Reading, MA: Addison- Wesley Date C.l. y Darwen H. (1992). Re!ationa! Database Writings 1989-1991. Reading, MA: Addison-Wesley Oavidson S.B. (1984). Optimism and consistency in partitioned distributed database systems. A CM Trans. Database Systems, 9(3), 456-481 Davidson S.B., Garcia-Molina
H. y Skeen D. (1985).
Consistency in partitioned networks. ACM Computing Surv., 17(3), 341-370 Davison D.L. y Graefe G. (1994). Memory-Contention Responsive Hash Joins. In Proc. Int. Conf Very Large Data Bases DBMS: Databases y ClientlServer Solution magazine Web site called DBMS ONLINE. Disponible en http://www.intelligententerprise.com Decker S., Van Harrnelen F., Broekstra J., Erdmann M., Fensel D., Horrocks 1., Klein M. y Melnik S. (2000). The Semantic Web - on the respective Roles of XML and ROE IEEE Internet Computing, 4(5). Disponible en http://computer.org/internet/ic2000/w5toc.htm Deutsch M., Femandez M., Florescu D., Levy A. y Suciu D. (1998). XML-QL: a query language for XML. Disponible en http://www.w3.org/TR/NOTE-xml-ql DeWitt D.J. y Gerber R. (1985). Multiprocessor HashBased Join AIgorithms. In Proc. 11th Int. Conf Very Large Data Bases. Estocolmo, 151-164 DeWitt D.l., Katz R.H., Olken E, Shapiro L.D., Stonebraker M.R. y Wood D. (1984). Implementation techniques for main memory database systems. In , Proc. A CM SIGMOD Conf on Management of Data, Boston, MA, 1-8 Dittrich K. (1986). Object-oriented database systems: the notion and the issues. In Prac of Int. Workshop on Object-Oriented Database Systems, IEEE CS, Pacific Grove, CA Dunnachie S. (1984). Choosing a DBMS. In Database Management Systems Practica! Aspects ofTheir Use (Frost R.A., ed.), 93-105. Londres: Granada Publishing Earl MJ. (1989). Management Strategies for 1nformation Technology. Hemel Hempstead: Prentice Hall
1213
Referencias
Elbra R.A. (1992). Computer Security Handbook. Oxford: NCC Blackwell Elmasri R. y Navathe S. (2003). Fundamentals Database Systems 4th edn. Addison-Wesley
of
Epstein R., Stonebraker M. y Wong E. (1978). Query processing in a distributed relational database system. In Proc. ACM SIGMOD Int. Conf Management ofData, Austin, TX, mayo de 1978, 169-180 Eswaran K.P., Gray J.N., Lorie R.A. y Traiger 1.L. (1976). The notion of consistency and predicate locks in a database system. Comm. ACM, 19(11), 624-633 Fagin R. (1977). Multivalued dependencies and a new normal form for relational databases. ACM Trans. Database Systems, 2(3) Fagin R. (1979). Normal forms and relational database operators. In Prac. ACM SIGMOD Int. Conf on Management of Data, 153-160 Fagin R., Nievergelt J., Pippenger N. y Strong H. (1979). Extendible hashing - A fast access method for dynamic files. ACMTrans. Database Systems, 4(3), 315-344 Fayyad D.M. (1996). Data mining and knowledge discovery: making sense out of data. IEEE Expert, Oct., 20-25 Femandez E.B., Summers R.C. y Wood C. (1981). Database Security and Integrity. Reading, MA: Addison- Wesley Finkel R.A. y Bentley J.L. (1974). Quad trees: a data structure for retrieval on oomposite keys. Acta Informatica 4: 1-9 Fisher A.S. (1988). CASE - Using Software Development Tools. Chichester: John Wiley Fleming C. y Von Halle B. (1989). Handbook of Relational Database Design. Reading, MA: AddisonWesley Frank L. (1988). Database Theory and Practice. Reading, MA: Addison- Wesley Frost R.A. (1984). Concluding comments. In Database Management Systems Practical Aspects ofTheir Use (Frost R.A., ed.), 251-260. Londres: Granada Publishing Furtado A. y Casanova M. (1985). Updating relational views. In Query Processing in Database Systems (Kim w., Reiner D.S. y Batory D.S., eds) Springer-Verlag Gane C. (1990). Computer-Aided Software Engineering: The Methodologies, the Products, and the Future. Englewood Cliffs, NJ: Prentice-Hall
Garcia-Molina H. (J 979). A concurrency control mechanism for distributed data bases which use centralised locking controllers. In Proc. 4th Berkeley Workshop Distributed Databases and Computer Networks, agosto de 1979 Garcia-Molina H. y Salem K. (1987). Sagas. In Prac. ACM Conf on Management of Data, 249-259 Garcia-Solaco M., Saltor F. y Castellanos M. (1996). Semantic heterogeneity in multidatabase systems. In Bukhres and Elmagarmid (1996), 129-195 Gardarin G. y Valduriez P. (1989). Relational Databases and Knowledge Bases. Reading, MA: Addison-Wesley Gates W. (1995). The Road Ahead. Penguin Books Gillenson M.L. (1991). Database administration at the crossroads: the era of end-user-oriented, decentralized data processing. J. Database Administration, 1-11
2(4),
Girolami M., Cichocki A. y Amari S. (1997). A Common Neural Network Modelfor Unsupervised Exploratory Data Analysis and Independent Component Analysis. Brain Information Processing Group Technical Report BIP-97-001 Goldberg A. y Robson D. (1983). Smalltalk 80: The Language and Its Implementation. Reading, MA: Addison- Wesley Goldman R. y Widom 1. (1997). DataGuides: enabling query formulation and optimization in semistructured databases. In Proc. of 23rd Int. Conf. on VLDB, Atenas, Grecia, 436--445 Goldman R. y Widom J. (1999). Approximate dataGuides. In Proc. ofthe Workshop on Query Processingfor Semistructured Data and Non-Standard Data Formats, Jerusalem, Israel Goldman R., McHugh J. y Widom 1. (1999). From semistructured data to XMI.: migrating the Lore data model and query language. In Proceedings of the 2nd Int. Workshop on the Web and Databases Gosling J., Joy B., Steele G. y Branche G. (2000). The Java Language Specification. Addison- Wesley Graefe G. (1993). Query evaluation techniques for large databases. ACM Computing Surv., 25(2), 73-170 Graefe G. y DeWitt D.1. (1987). The EXODUS Optimizer Generator. In Proc. ACM SIGMOD Conf on Management of Data, 160-172 Graham 1. (1993). Object Oriented Methods 2nd edn. Wokingham: Addison- Wesley Gray J. (1981). The transaction concept: virtues and limitations. In Proc. Int. Conf. Very Large Data Bases, 144-154, Cannes, Francia
1214
Sistemas de bases de datos
Gray l. (1989). Transparency in its Place - The Case Against Transparent Access to Geographically Distributed Data. Technical Report TR89 .1. Cupertino, CA: Tandem Computers lnc. Gray l, ed. (1993). The Benchmark Handbooklor Database and Transaction Processing Systems 2nd edn San Francisco, California: Morgan Kaufmann Gray l y Reuter A. (1993). Transaction Processing: Concepts and Techniques. San Mateo, CA: Morgan Kaufmann
Hamilton o. y Cattell R.o.o. (1996). JDBC: A lava SQL API. Technical report, SunSoft Hammer R. y McLeod R. (1981). Database description with SDM: A semantic database model. ACM Trans. Database Systems, 6(3), 351-386 Hanna P. (2003). lSP 2.0: The Complete Relerence. Osborne Hawryszkiewycz I.T. (1994). Database Analysis and Design 4th edn. Nueva York, NY: Macmillan Publishing Company
Gray J.N., Lorie R.A. y Putzolu o.R. (1975). Granularity of locks in a shared data base. In Proc. Int. Conf. Very Large Data Bases, 428-451 Gray P.M.D., Kulkarni K.o. y Paton N.W (1992). Object-Oriented Databases: a Semantic Data Model Approach. Prentice Hall Series in Computer Science Greenblatt D. y Waxman l (1978). A study of three database query languages. In Database: Improving Usability and Responsiveness (Shneiderman B., ed.), 77-98. Nueva York, NY: Academic Press Greenfield L. (1996). Don't let the Data Warehousing Gotchas Getcha. Datamation, Mar 1, 76-77. Disponible en http//pwp.starnetinc.com/larryg/index.html Gualtieri A. (1996). Open Database Access and Interoperability. Disponible en http://www.opengroup.org/dbiop/wpaper.html Guide/Share
(1970). Database Management System
Hellerstein 1.M., Naughton 1.F. y Pfeffer A. (1995). Generalized Search Trees for Database Systems. In Proc. Int. Conf Very Large Data Bases, 562-573 Herbert A.P. (1990). Security policy. In Computer Security: Policy, planning and practice (Roberts D.W., ed.), 11-28. Londres: Blenheim Online Holt R.C. (1972). Some deadlock properties ofcomputer systems. ACM Computing Surv., 4(3), 179-196 Hoskings A.L. y Moss lE.B. (1993). Object fault handling for persistent programming languages: a performance evaluation. In Proc. ACM Conf on ObjectOriented Programming Systems and Languages, 288-303 Howe D. (1989). Data Analysis lor Data Base Design 2nd edn. Londres: Edward Arnold Hull R. y King R. (1987). Semantic database modeling: survey, applications and research issues. ACM Computing Surv., 19(3),201-260
Task Force. Guide/Share Requirements. Report 01 the GuidelShare Database I\ GUIDE (1978). Data Administration GUIDE Publications GPP-30
Methodology.
Gupta S. y Mumick I.S., eds (1999). Materialized Views: Techniques, Implementations, and Applif:ations. MIT Press Gutman A. (1984). R-trees: a dynamic index structure for spatial searching. In Proc. ACM SIGMOD Conf on Management 01Data, Boston, 47-57 Hackathorn R. (1995). Data warehousing energizes your enterprise. Datamation, Feb. 1, 38-42 Haerder T. y Reuter A. (1983). Principies of transactionoriented database recovery. ACM Computing Surv., 15(4),287-318 Hall M. y Brown L. (2003). Core Servlets and JavaServer Pages 2nd edn. Prentice-Hall Halsall F. (1995). Data Communications,
Computer
Networks and Open Systems 4th edn. Wokingham: Addison- Wesley
lbaraki T.
Y Kameda T. (1984). On the optimal nesting order for computing n-relation joins. ACM Trans. Database Syst. 9(3),482-502
IDC (1996). A Survey of the Financial Impact of Data Warehousing. International Data Corporation. Disponible en http://www.idc.ca/sitemap.html IDC (1998). International Data Corporation. Disponible en http://www.idcresearch.com lnmon WH. (1993). Building the Data Warehouse. Nueva York, NY: lohn Wiley lnmon WH. y Hackathorn R.O. (1994). Using the Data Warehouse. Nueva York, NY: lohn Wiley Inmon WH., Welch 1.0. y Glassey K.L. (1997). Managing the Data Warehouse. Nueva York, NY: lohn Wiley Ioannidis Y. y Kang Y. (1990). Randomized algorithms for optimizing large join queries. In Proc. ACM SIGMOD Conf. on Management 01 Data, Atlantic City, NJ, 312-321
Referencias
loannidis Y. Y Wong E. (1987). Query optimization by simulated annealing. In Proc. ACM SIGMOD Conf on Management of Data, San Francisco, CA, 9-22 ISO (1981). ISO Open Systems Interconnection, Reference Model (ISO 7498). Intemational Organization for Standardization
Basic
ISO (1986). Standard Generalized Markup Language (ISO/IEC 8879). Intemational Organization for Standardization ISO (1987). Database Language SQL (ISO 9075: 1987(E)). Intemational Organization for Standardization
Symposium on PrincipIes ofDatabase Angeles, marzo de 1982, 124-138
1215
Systems, Los
Jagannathan D., Guck R.L., Fritchman B.L., Thompson l.P. y Tolbert D.M. (1988). SIM: A database system based on the semantic data model. In Prac. ACM SIGMOD Jarke M. y Koch J. (1984). Query optimization in database systems. ACM Computer Surveys, 16, 11(-152 Java Community Process (2003). Java Data Objects (JDO) Specification. 16 de septiembre de 2003. Disponible en http://jcp.org/aboutJava/communityprocess/finaUj srO 12/index2.h tml
ISO (1989). Database Language SQL (ISO 9075:1989(E)). Intemational Organization for Standardization
Jordan D. y Russell C. (2003). Java Data Objects. O'Reilly
ISO (1990). Information Technology - Information Resource Dictionary System (IRDS) Framework (ISO 10027). Intemational Organization for Standardization
Kahle B. Y MedIar A. (1991). An information system for corporate users: wide area information servers.
ISO (1992). Database Language SQL (ISO 9075: 1992(E)). Intemational Organization for Standardization ISO (1993). Information Teclmology - Information Resource Dictionary System (IRDS) Services Interface (ISO 10728). International Organization for Standardization ISO (1995). Cal/-Level Interface (SQL/CLI) (ISO/IEC 9075-3:1995(E)). Intemational Organization for Standardization ISO (1999a). Database Langtage SQL - Part 2: Foundation (ISO/IEC 9075-2). Intemational Organization for Standardization
Connexions:
The Interoperability
Report, 5(11), 2-9
Katz R.H., Chang E. y Bhateja R. (1986). Version modeling concepts for computer-aided design databases. In Proc. ACM SIGMOD In!. Con[ Management of Data, Washington, DC, mayo de 1986, 379-386 Kemper A. y Kossman D. (1993). Adaptable pointer swizzling strategies in object bases. In Proc. Int. Conf on Data Engineering, abril de 1993, 155-162 Kendall K. y Kendall J. (2002). Systems Analysis and Design 5th edn. Englewood Cliffs, NJ: Prentice Hall International Inc.
i
ISO (1999b). Database Language SQL - Part 4: Persistent Stored Modules (ISO/IEC 9075-4). International Organization for Standardization ISO (2003a). Database Language SQL - Part 2: Foundation (ISO/IEC 9075-2). International Organization for Standardization ISO (2003b). Database Language SQL - Part 4: Persistent Stored Modules (ISO/IEC 9075-4). Intemational Organization for Standardization ISO (2003c). Database Language SQL -XML-Related Specifications (ISO/IEC 9075-14). Intemational Organization for Standardization Jacobson J., Booch G. y Rumbaugh J. (1999). The Unified Software Development Pracess. Reading, MA: Addison- Wesley Jaeschke G. y Schek H. (1982). Remarks on the algebra of non- first normal form relations. In Proc. A CM Int.
Kerschberg L. y Pacheco J. (1976). A Functional Data Base Model. Teclmical Report, Pontifica Universidade Catolica Rio De Janeiro Khoshafian S. y Abnous R. (1990). Object Orientation: Concepts, Languages, Databases and Users. Nueva York, NY: Jolm Wiley Khoshafian S. y Va1duriez P. (1987). Persistence, sharing and object orientation: A databas e perspective. In Proc. Workshop on Database Programming Languages, Roscoff, Francia, 1987 Kim W. (1991). Object-oriented database systems: strengths and weaknesses. J Object-Oriented Programming, 4(4), 21-29 Kim w., Bertino E. y Garza l.F. (1989). Composite objects revisited. In Proc. ACM SIGMOD Int. Conf on Management of Data. Portland, Oregón Kim W. y Lochovsky F.H., eds (1989). Object-Oriented Concepts, Databases and Applications. Reading, MA: Addison- Wesley
1216
Sistemas de bases de datos
Kim W, Reiner D.S. y Batory D.S. (1985). Query Processing in Database Systems. Nueva York, NY: Springer- Verlag
Lacroix M. Y Pirotte A. (1977). Domain-oriented relational languages. In Proc. 3rd Int. Conf Very Large Data Bases, 370-378
Kimball R. (1996). Leuing the Users Sleep Part 1: Nine Decisions in the Design of a Data Warehouse. DBMS Online. Disponible en http://www.dbmsmag.com
Lamb C., Landis 0., Orenstein J. y Weinreb D. (1991). The ObjectStore Database System. Comm. ACM, 34(10)
Kimball R. (1997). LeUing the Users Sleep Part 2: Nine Decisions in the Design of a Data Warehouse. DBMS Online. Disponible en http://www.dbrnsrnag.com
Lamport L. (1978). Time, clocks and the ordering of events in a distributed system. Comm. ACM, 21(7), 558-565
Kimball R. (2000a). Rating your Dimensional Data Warehouse. Disponible en http://www.intelligententerprise.com/000428/webhouse.shtrnl
Larson P. (1978). Dynamic hashing. BIT, 18
Kimball R. (2000b). Is your Dimensional Data Warehouse Expressive? Disponible en http://www.intelligententerprise.com/000515/ webhouse.shtrnl
Litwin W (1980). Linear hashing: a new tool for file and table addressing. In Proc. Int. Con[. Very Large Data Bases, 212-223
Kimball R. y Merz R. (1998). The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. Wiley Computer Publishing Kimball R., Reeves L., Ross M. y Thomthwaite W. (2000). The Data Webhouse Toolkit: Building the WebEnabled Data Warehouse. Wiley Computer Publishing. King J.J. (1981). Quist: a system for semantic query optimization in relational databases. In Proc. 7th Int. Con[. Very Large Data Bases, Cannes, Francia, 510-517 King N.H. (1997). Object DBMSs: now or never. Df!.,.MS Magazine, julio 1997 Kirkpatrick S., Gelatt C.D. Jr y Vecchi M.P. (1983). Optimization by simulated annealing. Science. 220(4598), 671-680 \ Kohler WH. (1981). A survey of techniques for synchronization and recovery in decentralised computer systems. ACM Computing Surv., 13(2), 149-183 Korth H.F., Kim W y Bancilhon F. (1988). On long-duration CAD transactions. Information Science, octubre de 1988 Kossmann D. (2000). The state of the art in distributed query processing. ACM Computing Surveys, 32(4), 422--469 Kulkami K.o. y Atkinson M.P. (1986). EFDM: Extended Functional Data Model. The Computer Journal, 29(1), 38--46
Leiss E.L. (1982). Principles of Data Security. Nueva York, NY: Plenum Press
Litwin W. (1988). From database systems to multidatabase systems: why and how. In Proc. British National Conf Databases (BNCOD 6), (Gray WA., ed.), 161-188. Cambridge: Cambridge University Press Lohman O.M., Mohan C., Haas L., Daniels D.J., Lindsay B., Selinger P., Wilms P. (1985). Query Processing in R *. In Query Processing in Database Systems, (Kim W, Reiner D.S. y Batory D.S., eds). Springer-Verlag, NJ. Loomis M.E.S. (1992). Client-server architecture. J. Object Oriented Programming, 4(9), 40--44 Lorie R. (1977). Physical integrity in a large segmented database. ACM Trans. Database Systems, 2(1), 91-104 Lorie R. y Plouffe W (1983). Complex objects and their use in design transactions. In Proc. ACM SIGMOD Conf Database Week, mayo de 1983, 115-121 Maier D. (1983). The Theory of Relational Databases. Nueva York, NY: Computer Science Press Malley C.Y. y Zdonik S.B. (1986). A knowledge-based approach to query optimization. In Proc. 1st Int. Conf on Expert Database Systems, Charleston, SC, 329-343 Manolo F. y Dayal U. (1986). PDM: an object-oriented data model. In Proc. Int. Workshop. on ObjectOriented Database Systems, 18-25 Mattison R. (1996). Data Warehousing: Strategies, Technologies and Techniques. Nueva York, NY: McGraw-Hill
Kulkami K.o. y Atkinson M.P. (1987). Implementing an ~
\Software Extended -Functional Practice and DataExperience, Model using 17(3), PS-algol. 171-185 Kung H.T. y Robinson J.T. (1981). On optimistic methods for concurrency control. A CM Trans. Database Systems, 6(2), 213-226
McCJure C. (1989). CASE Is Software Automation. Englewood Cliffs, NJ: Prentice-Hall McCool R. (1993). Common Gateway Interface Overview. Work in Progress. National Center for Supercomputing Applications (NCSA), University of
1217
Referencias
Illinois. Disponible en http://hoohoo.ncsa.uiuc.edu/
Oberrnarck R. (1982). Distributed deadlock detection cgi/ overview.htrnl
McCready M. (2003). Object-oriented design (pers. comm.)
analysis and
algorithm. ACM Trans. Database Systems, 7(2), 187-208 OLAP Council (1998). APB-I OLAP Benchmark Release 11. Disponible en http://www.olapcouncil.org/research/brnarkco.htrnl
McHugh l., Abiteboul S., Goldman R., Quass D. y Widom l. (1997). Lore: A database management system for semi-structured data. In SIGMOD Record, 26(3), 54-66
OLAP Council (2001). OLAP Council White Páper. Disponible en
Menasce D.A. y Muntz R.R. (1979). Locking and deadlock detection in distributed databases. IEEE Trans.
OMG y X/Open (1992). CORBA Architecture and
Software Engineering,
5(3), 195-202
Merrett T.H. (1984). Relational Information Systems. Reston Publishing Co. Mishra P. y Eich M.H. (1992). loin Processing in Relational Databases. ACM Computing Surv., 24, 63-113 Mohan C., Lindsay B. y Oberrnarck R. (1986). Transaction management in the R * distributed database management system. ACM Trans. Database Systems, 11(4),378-396 Morrison R., Connor R.C.H., Cutts Q.I. y Kirby o.N.C. (1994). Persistent possibilities for software environments. In The Intersection between Databases and Software Engineering. 78-87
IEEE Computer Society Press,
Moss I.E.B. (1981). Nested transa¡¡tions: An approach to reliable distributed computing. PhD dissertation, MIT, Cambridge, MA
http://www.olapcouncil.org/research/whtpapco.htrnl Specification.
Report 90~38, University of Massachusetts, Amherst, MA Moulton R.T. (1986). Computer Security Handbook: Strategies and Techniques for Preventing Data Loss or Theft. Eng1ewood Cliffs, NI: Prentice-Hall Navathe S.B., Ceri S., Weiderhold o. y Dou l. (1984). Vertical partitioning algorithms for database designo ACM Trans. Database Systems, 9(4), 680-710
l., Hinterberger H. y Sevcik K.C. (1984). The Grid File: An Adaptable, Symmetric Multikey File Structure. ACM Trans. Database Systems, 38-71
Nievergelt
Group
OMG (1999). Common Object Request Broker Architecture and Specification. Object Managernent Group, Revision 2.3.1 Oracle Corporation (2000). Using Oracle Warehouse Builder to Build Express Databases. Disponible en http://www.oracle.com/ Oracle Corporation (2001). http://www.oracle.com/corporate/overview/ 20 de febrero de 2001 Oracle Corporation (2004a). Oracle9i Database Concepts. Capítulos 16 y 20 A96524-01. Oracle Corporation Oracle Corporation (2004b). Oracle9i Database Performance and Tuning Guide and Reference. A96533-0 l. Oracle Corporation Oracle Corporation (2004c). Oracle9i Backup and Recovery Concepts. A96519-0 l. Oracle Corporation Oracle Corporation (2004d). Oracle9i Database Administrator
Moss I.E.B.Toy swizzh~ EliÓ~l. or (1990). objects: not toWorking swizzle. with Coinspersistent Technical
Object Management
s Guide.
A96521-0 l. Oracle Corporation
Oracle Corporation (2004e) Advanced Replication. A96567-01. Oracle Corporation Oracle Corporation (2004f) Data Warehousing Guide. A96520-0 l. Oracle Corporation Oracle Corporation (2004g). Oracle9i Application A97688-13. Oracle Corporation
Server,
Oracle Corporation (2004h) Oracle OLAP. Data Sheet. Oracle Corporation Oracle Corporation (2004i) SQLfor Analysis in Data Warehouses. A96520-0 l. Oracle Corporation Oracle Corporation (2004j) OLAP and Data Mining A96520-01. Oracle Corporation
Nijssen O.M. y Halpin T. (1989). Conceptual Schema and Relational Database Design Prentice Hall, Sydney
02 Technology (1996). Java Relational Binding: A White Paper. Disponible en http://www.o2tech.fr/jrb/wpaper.htrnl
OASIG (1996). Research reporto Disponible en http://www.comlab.ox.ac.uk/oucI/users/john.nicholls/oas-sum.htrnl
Ozsu M. y Valduriez P. (1999). PrincipIes of Distributed Database Systems 2nd edn. Englewood Cliffs, NI: Prentice- Hall
1218
Sistemas de bases de datos
Papadimitriou C.H. (1979). The serializability of concurrent database updates. J ACM, 26(4), 150-157
RevellaA.S. (1993). Software escrow. l/S Analyzer, 31(7), 12-14
Papakonstantinou Y, Garcia-Molina H. y Widom J. (1995). Object exchange across heterogeneous data sources. Proc. of the 11th lnt. Conf on Data Engineering, Taipei, Taiwan, 251-260
y Schach D. (1998). XML Query Robie J., Lapp Language (XQL). Disponible en http://www.w3.org/TandS/QL/QL98/pp/xql.html
1
Parsaye K., Chignell M., Khoshafian S. y Wong H. (1989). lntelligent Databases. Nueva York: John Wiley
1
y Maryanski F. (1988). Semantic data Peckham mode1s. ACM Computing Surv., 20(3), 143-189
Robinson J. (1981). The K-D-B tree: a search structure for large multidimensional indexes. In Proc. ACM SlGMOD Conf Management of Data, Ann Arbor, MI, 10-18
Pendse N. (2000). What is OLAP? Disponible en http://www.olapreport.com/fasmi.html
Robson W. (1997). Strategic Management & lnformation Systems: An lntegrated Approach 2nd edn. Londres: Pitman Publishing
Pendse N. y Creeth R. (2001). The OLAP Report. Disponible en www.olapreport.com
Rogers U. (1989). Denormalization: Why, what and how? Database Programming and Design, 2(12), 46-53
Perry B. (2004). Java Servlet and JSP Cookbook. O'Reilly
Rosenkrantz D.J. y Hunt H.B. (1980). Processing conjunctive predicates and queries. In Proc. lnt. Conf Very Large Data Bases, Montreal, Canadá
Pfieeger C. (1997). Security in Computing 2nd edn. Englewood Cliffs, NJ: Prentice-Hall Piatetsky-Shapiro G. y Connell C. (1984). Accurate estimation of the number of tup1es satisfying a condition. In Froc. ACM SlGMOD Conf On Management of Data, Boston, MA, 256-276 P1ess V. (1989). lntroduction to the Theory of ErrorCorrecting Codes 2nd edn. John Wiley & Sons, Nueva York, NY Poulovassilis A. y King P. (1990). Extending the functional data model to computational completeness. In Proc. EDBT,75-91 Poulovassilis A. y Small C. (1991). A functional programming approach to deductive databases. In Proc. lnt. Conf Very Large Data Bases, 491-500 Pu C., Kaiser G. y Hutchinson N. (1988). Split-transactions for open-ended activities. In Proc. 14th lnt. Conf Very Large Data Bases QED (1989). CASE: The Potential and the Pitfalls. QED Inforrnation Sciences Red Brick systems (1996). Specialized Requirements Relational Data Warehouse Servers. Red Brick
for
Systems Inc. Disponible en http://www.redbrick.com/rbs-g/whitepapers/tenreq_ wp.html Reed D. (1978). Naming and Synchronization in a Decentralized Computer System. PhD thesis, Department of Electrical Engineering, MIT, Cambridge, MA Reed D. (1983). Implementing atomic actions on decentralized data. ACM Trans. on Computer Systems, 1(1), 3-23
Rosenkrantz D.J., Steams R.E. y Lewis 11P.M. (1978). System level concurrency control for distributed data base systems. ACM Trans. Database Systems, 3(2), 178-198 Rothnie lB. y Goodman N. (1977). A survey of research and development in distributed database management. In Proc. 3rd lnt. Conf Very Large Data Bases, Tokyo, Japón, 48-62 Rothnie lB. Jr, Bemstein P.A., Fox S., Goodman N., Hammer M., Landers T.A., Reeve C., Shipman D.W. y Wong E. (1980). Introduction to a System for Distributed Databases (SDD-1). A CM Trans. Database Systems, 5(1),1-17 Rumbaugh l, Blaha M., Premerlani w., Eddy F. Y Lorensen W. (1991). Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall Rusinkiewicz M. y Sheth A. (1995). Specification and execution of transactional workflows. In Modern Database Systems. (Kim w., ed.), ACM Press/Addison Wesley, 592-620 Sacco M.S. Y Yao S.B. (1982). Query optimization in distributed data base systems. In Advances in Computers, 21 (Yovits M.C., ed.), 225-273. Nueva York: Academic Press Schmidt J. y Swenson J. (1975). On the semantics of the relational model. In Prac. ACM SlGMOD lnt. Conf on Management of Data (King F., ed.), 9-36. San José,
CA Selinger P. y Abida M. (1980). Access path selections in distributed data base management systems. In Proc. lnt. Conf on Databases, British Computer Society
Referencias
1219
Selinger P., Astrahan M.M., Chamberlain D.D., Lorie R.A. y Price T.G. (1979). Access path selection in a relational database management system. In Proc. ACM SIGMOD Conf on Management of Data, Boston, MA, 23-34
Skeen D. (1981). Non-blocking commit protocols. In Froc. ACM SIGMOD Int. Conf Management of Data, 133-142
Senn J.A. (1992). Analysis and Design ofInformation Systems 2nd edn. Nueva York: McGraw-Hill
Soley R.M., ed. (1990). Object Management Architecture Guide. Object Management Group
Shapiro L.D. (1986). Join processing in database systems with large main memories. ACM Trans. Database Syst. 11(3), 239-264
Soley R.M., ed. (1992). Object Management Architecture Guide Rev 2, 2nd edn, OMG TC Document 92.11.1. Object Management Group
Sheth A. y Larson J.L. (1990). Federated databases: architectures and integration. ACM Computing Surv., Special Issue on Heterogeneous Databases, 22(3), 183-236
Soley R.M., ed. (1995). Object Management Architecture Guide 3rd edn. Framingham, MA: Wiley
Shipman D.W. (1981). The functional model and the data language DAPLEX. ACM Trans. Database Systems, 6(1),140-173 Shneiderman D. (1998). Design the User Interface: Strategies for Effective Human~Computer Interaction 3rd edn. Reading, MA: Addison- Wesley Sibley E. y Kerschberg L. (1977). Data architecture and data model considerations. In Proc. American Federation of Information Processing Societies (AFIPS) National Computing Conference, 85-96
Smith P. y Bames G. (1987). Files and Databases: An Introduction. Reading, MA: Addison- Wesley
Sollins K. y Masinter L. (1994). Functional requirements for Uniform Resource Names. RFC 1737 Sommerville 1. (2002). Software Engineering Reading, MA: Addison- Wesley
6th edn.
Spaccapietra C., Parent C. y Dupont Y. (1992). Automating heterogeneous schema integration. In Proc. Int. Conf Very Large Data Bases, 81-126 Srinivasan y. y Carey M. (1991). Performance ofB-Tree concurrency control algorithms. In Proc. ACM SIGMOD Conf on Management of Data Standish T.A. (1994). Data Structures, Algorithms, and Software PrincipIes. Reading, MA: Addison-Wesley
Siegel M., Sciore E. y Salveter S. (1992). A method for automatic rule derivation to support semantic query optimization. ACMTrans. Database Systems, 17(4), 563-600
Steinbrunn M., Moerkotte G. y Kemper A. (1997). Heuristic and randomized optimization for the join ordering problem. The VLDB Journal, 6(3), 191-208
Silberschatz A., Stonebraker M. y Ullman J., eds (1990). Database systems: Achievements and opportunities. ACM SIGMOD Record, 19(4)
Stonebraker M. (1996). Object-Relational DBMSs: The Next Great Wave. San Francisco, CA: Morgan Kaufmann Publishers Inc.
Silberschatz A., Stonebraker M.R. y Ullman J. (1996). Database Research: Achievements and Opportunities into the 21st century. Technical Report CS-TR-961563, Department of Computer Science, Stanford University, Stanford, CA.
Stonebraker M. y Neuhold E. (1977). A distributed database version of INGRES. In Proc. 2nd Berkeley Workshop on Distributed Data Management and Computer Networks, Berkeley, CA, mayo de 1977, 9-36
Simoudis E. (1996). Reality check for data mining. IEEE Expert, Oct, 26-33
Stonebraker M. y Rowe L. (1986). The design ofPOSTGRES. In ACM SIGMOD Int. Con[. on Management of Data, 340-355
Singh H.S. (1997). Data Warehousing: Concepts, Technologies, Implementation and Management. Saddle River, NJ: Prentice-Hall
Upper
Singhal Y., Kakkad S.Y. y Wilson P.R. (1992). Texas: an efficient, portable, persistent store. In Proc. Int. Workshop on Persistent Object Systems, 11-33 Skarra A.H. y Zdonik S. (1989). Concurrency control and object-oriented databases. In Object-Oriented Concepts, Databases and Applications (Kim W. y Lochovsky F.H., eds), 395--422. Reading, MA: Addison- Wesley
Stonebraker M., Rowe L., Lindsay B., Gray P., Carie Brodie M.L., Bemstein P. y Beech D. (1990). The third generation database system manifesto. In Proc. ACM SIGMOD Conf Stubbs D.F. y Webre N.W. (1993). Data Structures with Abstract Data Types and Ada. Belmont, CA: Brooks/Cole Publishing Co. Su S.Y.w. (1983). SAM*: A Semantic Association Model for corporate and scientitic-statistical databases. Information Science, 29, 151-199
1220
Sistemas de bases de datos
Sun (1997). JDK 1.1 Documentation. Microsystems Inc.
Palo Alto, CA: Sun
Sun (2003). Enterprise JavaBeans Specification Version 2.1. 12 de noviembre de 2003. Disponible en http://java.sun.com/products/ejb/ docs.html Swami A. (1989). Optimization oflarge join queries: Combining heuristics and combinatorial techniques. In Prac. ACM SIGMOD Con[ on Management of Data, Portland, OR, 367-376 Swami A. y Gupta A. (1988). Optimization of large join queries. In Proc. ACM SIGMOD Conf on Management of Data, Chicago, IL, 8-17 Tanenbaum A.S. (1996). Computer Networks 3rd edn. Englewood Cliffs, NJ: Prentice-Hall Taylor D. (1992). Object Orientation Information Systems: Planning and Implementation. Nueva York, NY: John Wiley Teorey T.J. (1994). Database Modeling and Design: The Fundamental PrincipIes 2nd edn. San Mateo, CA: Morgan Kaufinann Teorey T.l y Fry lP. (1982). Design of Database Structures. Englewood Cliffs, NJ: Prentice-Hall Thomas R.H. (1979). A majority consensus approach to concurrency control for multiple copy databases. ACM Trans. Database Systems, 4(2), 180-209
W3C (1999c). XML Path Language (XPath) 1.0. World Wide Web Consortium 16 de noviembre de 1999. Disponible en http://www.w3.org/TR/xpath W3C (1999d). Resource Description Framework (RDF) Model and Syntax Specification. World Wide Web Consortium Recommendation 22 de febrero de 1999. Disponible en http://www.w3.org/TR/REC-rdfsyntax W3C (2000a). XHTML 1.0. World Wide Web Consortium Recommendation 26 de enero de 2000. Disponible en http://www.w3.org/TR/xhtml1 W3C (2000b). XML 1.0 2nd edn. World Wide Web Consortium 6 de octubre de 2000. Disponible en http://www. w3.org/TR/REC- xml-20001 006 W3C (2000c). ResourceDescription Framework (RDF) Schema Specification. World Wide Web Consortium Candidate Recommendation 27 de marzo de 2000. Disponible en http://www.w3.org/TR/2000/CR-rdfschema-20000327 W3C (2000d). XML Pointer Language (XPointer) 1.0. World Wide Web Consortium 7 de junio de 2000. Disponible en http://www.w3.org/TR/xptr W3C (200Ia). Extensible Stylesheet Language (XSL) Version 1.0. W3C Recommendation 15 de octubre de 2001. Disponible en http://www.w3.org/TR/xsl
Thomsen E. (1997). OLAP Solutions: Building Multidimensionallnformation Systems. John Wiley & Sons
W3C (200Ib). XML Linking Language (XLink) Version 1.0. W3C Recommendation 27 de junio de 2001. Disponible en http://www.w3.org/TR/xlink
Todd S. (1976). The Peterlee relational test vehic1e - a
W3C (200Ic). XML Schema Part 1: Structures. W3C
system overview. IBM Systems J., 15(4),285-308 UDD1.org (2004). Universal Discovery, Description and Integration (UDDI) Specification. Disponible en http://www. uddLorg/specification.html Ullman J.D. (1988). PrincipIes of Database and Knowledge-base Systems Volume 1. Rockville, MD: Computer Science Press Valduriez P. y Gardarin G. (1984). Join and semi-join algorithms for a multi-processor database machine. ACMTrans. Database Syst. 9(1), 133-161 W3C (1999a). HTML 4.01. World Wide Web Consortium Recommendation 24 de diciembre de 1999. Disponible en http://www.w3.org/TR/htmI4 W3C (1999b). Namespaces in XML. World Wide Web Consortium 14 de enero de 1999. Disponible en http://www. w3.org/TR/REC- xml-names
Recommendation 2 de mayo de 2001. Disponible en http://www. w3.org/TR/xmIschema-l W3C (200Id). XML Schema Part 2: Datatypes. W3C Recommendation 2 de mayo de 200 l. Disponible en http://www. w3.org/TR/xmlschema-2 W3C (200Ie). XML Information Set. W3C Recommendation 24 de octubre de 2001. Disponible en http://www. w3.org/TR/xml-infoset W3C (2002a). Extensible HyperText Markup Language (XHTML) Version 1.0 (Second Edition). W3C Recommendation 1 de agosto de 2002. Disponible en http://www. w3.org/TR/xhtmll W3C (2003a). XSL Transformations (XSLT) Version 2.0. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xsIt20 W3C (2003b). XML XPath Language Version 2.0. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xpath20
1221
Referencias W3C (2003c). XML XPointer Framework. W3C Recommendation 25 de marzo de 2003. Disponible en http://www. w3.org/TR/xptr- framework
Weikum G. Y Schek H. (1991). Multi-Ievel transactions
W3C (2003d). SOAP Version 1.2 Part 1: Messaging Framework. W3C Recommendation 24 de junio de 2003. Disponible en http://www.w3.org/TR/soapI2partl
White S.J. (1994). Pointer swizzling techniques for object-oriented systems. University ofWisconsin Technical Report 1242, PhD thesis Wiederhold G. (1983). Database Design 2nd ecill. Nueva York, NY: McGraw-Hill
W3C (2003e). RDF/XML Syntax Specification (Revised). W3C Proposed Recommendation 15 de diciembre de 2003. Disponible en http://www. w3.org/TR/rdf-syntax-grammar W3C (2003±). RDF Vocabulary Description Language 1.0: RDF Schema. W3C Proposed Recommendation de diciembre de 2003. Disponible en http://www. w3.org/TR/rdf-schema
and open nested transactions. IEEE Data Engineering Bulletin
15
W3C (2003g). XML Query (XQuery) Requirements. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xquery-requirements
Williams R., Daniels D., Haas L., Lapis G., Lindsay B., Ng P., Obermarck R., Selinger P., Walker A., Wilms P. y Yost R. (1982). R *: An overview ofthe architecture. IBM Research, San Jose, CA, RJ3325. Reprinted in Stonebraker M. (ed). (1994). Readings in Distributed Database Systems. Morgan Kaufmann Wong E. (1977). Retrieving dispersed data fram SDD-l: A System for Distributed Databases. In Proc. of the Berkeley Workshop on Distributed Data Management and Compute Networks, 217-235
W3C (2003h). XQuery 1.0 - A Query Language for XML. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xquery
Wong E. y Youssefi K. (1976). Decomposition - a strategy for query processing. ACMTrans. Database Syst. 1(3)
W3C (2003i). XQuery 1.0 and XPath 2.0 Functions and Operators. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xpathfunctions
Wutka M. (2001). Special Edition Using Java 2 Enterprise Edition (J2EE): With JSp, Servlets, EJB 2.0, JNDI, JMS, JDBC, CORBA, XML and RMI. Que Corporation
W3C (2003j). XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xpath-datamodel
Wutka M. (2002). Special Edition Using Java Server Pages and Servlets 2nd edn. Que Corporation
W3C (2003k). XQuery 1.0 and XPath 2.0 Formal Semantics. W3C Working Draft 12 de noviembre de 2003. Disponible en http://www.w3.org/TR/xquerysemantics
XlOpen (1992). The X/Open CAE Specification 'Data Management: SQL Call-Level Interface (CLI) '. The Open Group
W3C (20031). XML Syntax for XQuery 1.0 (XQueryX). W3C Working Draft 12 de noviembre de 2003.
Yoo H. Y Lafortune S. (1989). An intelligent search method for query optimization by semijoins. IEEE Trans. on Knowledge and Data Engineering, 1(2), 226-237
Disponible en http://www.w3.org/TR/xqueryx W3C (2003m). Web Services Description Language (WSDL) Version 2.0 Part I - Core Language. W3C Working Draft 10 de noviembre de 2003. Disponible en http://www.w3.org/TR/wsdI20
Yu C. y Chang C. (1984). Distributed Query Processing. ACM Computing Surveys, 16(4), 399-433
W3C (2004a). XML Version 1.1. W3C Recommendation 04 de febrero de 2004. Disponible en http://www. w3.org/TR/xm111
Zaniolo C. et al. (1986). Object-Oriented
W3C (2004b). Namespaces in XML Version 1.1. W3C Recommendation 04 de febrero de 2004. Disponible en http://www. w3.org/TR/xml-namesll
Zdonik S. y Maier D., eds (1990). Fundamentals
Weikum G. (1991). PrincipIes and realization strategies of multi-Ievel transaction management. ACM Trans. Database Systems, 16(1), 132-180
Database
Systems and Knowledge Systems. In Proc. Int. Conference on Expert Database Systems of
object-oriented databases in readings. In ObjectOriented Database Systems, 1-31. San Mateo, CA: Morgan Kaufmann ZloofM. (1977). Query-By-Example: ge. IBM Systems J., 16(4),324-343
A database langua-
Lecturas adicionales Capítulo 1 Recursos
web
Brodie M., Mylopoulos l. y Schmidt J., eds (1984). Conceptual Modeling. Nueva York, NY: Springer-Verlag Gardarin o. y Valduriez P. (1989). Relational Databases and Knowledge Bases. Reading, MA: Addison-Wesley
http://databases.about.com Portal web que contiene artículos sobre diversas cuestiones relativas a las bases de datos.
Tsichritzis D. y Lochovsky F. (1982). Data Models. Englewood Cliffs, NJ: Prentice-Hall
http://searchdatabase.techtarget.com/Portal web que contiene enlaces relacionados con diversas cuestiones relativas a las bases de datos.
Ullman J. (1988). PrincipIes ofDatabase and Knowledge-Base Systems Vol. 1. Rockville, MD: Computer Science Press
http://www.ddj.com Revista Dr Dobbs. http://www.intelligententerp rise.com Revista Intelligent Enterprise, una de las principales en el campo d de las gestiones de bases de datos y áreas relacionadas. Esta revista es el resultado de la combinación de dos publicaciones anteriores: Database Programming y Design and DBMS. http://www.techrepublic.com Un portal para profesionales de las tecnologías de la información que puede personalizarse de acuerdo con los intereses de cada visitante. http://www.webopedia.com Un diccionario en línea y un motor de búsqueda para términos informático s y tecnología Internet. http://www.zdnet.com Otro portal que contiene artículos que cubren un amplio rango de temas de tecnologías de la información. Los grupos de noticias más útiles son: comp.client-server comp.databases comp.databases.ms-access com p.data bases.ms-sqlserver comp.databases.olap comp.databases.oracle comp.databases.theory
Capítulo 2 Batini C., Ceri S. y Navathe S. (1992). Conceptual Database Design: An Entity-Relationship approach. Redwood City, CA: Benjamin Cummíngs
Capítulo 3 Aho A.V., Beeri C. y Ullman J.D. (1979). The theory of joins in relational databases. ACM Trans. Database Systems, 4(3), 297-314 ChamBerlín D. (1976a). Relational data-base management systems. ACM Computing Surv., 8(1), 43-66 Codd E.F. (1982). The 1981 ACM Turing Award Lecture: Relational database: A practical foundation for productivity. Comm. ACM, 25(2), 109-117 Dayal U. y Bernstein P. (1978). The updatability ofrelational views. En Proc. 4th Int. Conf on Very Large Data Bases, 368-377 Schmidt J. y Swenson J. (1975). On the semantics ofthe relational model. En Proc. ACM SIGMOD Int. Conf on Management of Data, 9-36
Capítulo 4 Abiteboul S., Hull R. y Vianu V. (1995). Foundations Databases. Addison Wesley
of
Atzeni P. y De Antonellis V. (1993). Relational Database Theory. Benjamin Cummings Ozsoyoglu 0., Ozsoyoglu Z. y Matos V. (1987). Extending relational algebra and relational calculus with set valued attributes and aggregate functions. ACMTrans. on Database Systems, 12(4), 566-592 Reisner P. (1977). Use of psychological experimentation as an aid to development of a query language. IEEE Trans. Software Engineering, SE3(3), 218-229
1224
Sistemas de bases de datos
Reisner P. (1981). Human factors studies of database query languages: A survey and assessment. ACM Computing Surv., 13(1) Rissanen J. (1979). Theory of joins for relational databases - a tutorial survey. En Proc. Symposium on Mathematical Foundations ofComputer Science, 537-551. Berlín: Springer- Verlag Ullman lD. (1988). Principies of Database and Knowledge-base Systems Volume 1. Rockville, MD: Computer Science Press
Capítulos 5 Y 6 ANSI (1986). Database Language - SQL (X3.l35). American National Standards lnstitute, Technical Committee X3H2 ANSI (1989a). Database Language - SQL with lntegrity Enhancement (X3.l35-l989). American National Standard s Institute, Technical Committee X3H2 ANSI (1989b). Database Language - Embedded SQL (X3.168-1989). American National Standard s Institute, Technical Comrnittee X3H2 Date C.l y Darwen H. (1993). A Guide to the SQL Standard 3rd edn. Reading, MA: Addison-Wesley Melton J. y Simon A. (2002). SQL 1999: Understanding Relational Language Components. Morgan Kaufmann
Recursos web
Simpson A., Levine- Young M., Barrows A. y Levine Young M. (2003). Access 2003 All-in-one Desk Referencefor Dummies. John Wiley & Sons Inc. Viescas J. (2003). Access 2003 lnside Out. Microsoft Press Intemational Zloof M. (1982). Office-by-example: a business language that unifies data and word processing and electronic mail. IBM Systems Journal, 21(3), 272-304
Recursos web http://msdn.microsoft.com/sql Sitio web de la red de desarrolladores de Microsoft, que contiene artículos, detalles técnicos e información de referencia sobre las interfaces de programación de aplicaciones para todas las tecnologías de Microsoft, incluyendo Office Access y SQL Server.
Capítulo 8 Abbey M., Corey M. y Abramson 1. (2001). Oracle9i: A Beginner s Guide. Osborne McGraw-Hill Andersen V. (2003). Microsoft Office Access 2003: The Complete Reference. Osbome McGraw-Hill Balter A. (2003). Sams Teach Yourself Microsoft Access 2003 in 24 Hours. Sams Freeman R. (2004). Oracle Database 10g New Features. Osbome McGraw-Hill Greenwald R., Stackowiak R. y Stem
http://sqlzoo.net
Un tutorial en línea sobre SQL.-
http://www.sqI.org El sitio sql.org es un recurso en línea que proporciona un tutorial sobre SQL, así como enlaces a grupos de noticias, foros de discusión y software gratuito. http://www.sqIcourse.com SQL.
1(2004).
Oracle
Essentials: OracleJOg. O'Reilly Jennings R. (2003). Using Microsoft Access 2003: Special Edition. Que Loney L. y Bryla B. (2004). Oracle Database 10g DBA Handbook. Osbome McGraw-Hill
Un tutorial en línea sobre
http://www.w3schools.com/sql El sitio'webW3 Schools proporciona un tutorial sobre instrucciones SQL básicas y avanzadas. Se proporcionan test para mejorar la comprensión de los conceptos SQL.
Capítulo 7 Andersen V. (2003). Microsoft Office Access 2003: The Complete Reference. Osbome McGraw-Hill Balter A. (2003). Sams Teach Yourself Microsoft Access 2003 in 24 Hours. Sams Jennings R. (2003). Using Microsoft Access 2003: Special Edition. Que Online Training (2003). Access 2003 Step by Step. Microsoft Press Intemational
Loney K. y Koch G. (2002). Oracle9i: The Complete Reference. Osborne McGraw-Hill Loney K. y McClain L. (eds) (2004). Oracle Database 10g: The Complete Reference. Osborne McGraw-Hill Niemiec R., Brown B. y Trezzo J. (1999). Oracle Performance Tuning Tips & Techniques. Oracle Press Online Training (2003). Access 2003 Step by Step. Microsoft Press lntemational Powell G. (2003). Oracle High Performance 9i and 10g. Butterworth-Heinemann
Tuningfor
Price J. (2004). Oracle Database JOg SQL. Os borne McGraw-Hill Simpson A., Levine-Young M., Barrows A. y LevineYoung M. (2003). Access 2003 All-in-one Desk Referencefor Dummies. John Wiley & Sons Inc
1225
Lecturas adicionales
Sunderraman R. (2003). Oracle9i Programming: Primer. Addison Wesley
A
Viescas J. (2003). Access 2003 Inside Out. Microsoft Press Intemational Whalen E., Schroeter M. y Garcia M. (2003). Sams Teach YourselfOracle9i in 21 Days. Sams
Recursos
web
http://msdn.microsoft.com/sql Sitio web de la red de desarrolladores de Microsoft, que contiene artículos, detalles técnicos e información de referencia sobre las interfaces de programación de aplicaciones para todas las tecnologías de Microsoft, incluyendo Office Access y SQL Server. http://otn.oracIe.com Sitio web de la red tecnológica de Oracle, con multitud de información y descargas para los sistemas Oracle. http://www.revealnet.com arrollo y administración http://www.sswug.org llo y administración SQL Server.
Capítulo
Un portal dedicado al desde bases de datos Oracle.
Un portal dedicado al desarrode bases de datos Oracle, DB2 y
9
Brancheau lC. y Schuster L. (1989). Building and implementing an information architecture. Data Base, Summer,9-17 .•• Fox R.W. y Unger E.A. (1984). A DBMS selection model for managers. En Advances in Data Base Management, Vol. 2 (Unger E.A., Fisher P.S. y Slonim J., eds), 147-170. Wiley Heyden Grimson J.B. (1986). Guidelines for data administration. En Proc. IFIP 10th World Computer Congress (Kugler H.J., ed.), 15-22. Amsterdam: Elsevier Science Loring P. y De Garis C. (1992). The changing face of data administration. En Managing Information 11, IFIP Technology s OrganisationalImpact, Transactions A [Computer Science and TechnologyJ Vol. A3 (Clarke R. y Cameron J., eds), 135-144. Amsterdam: Elsevier Science Nolan R.L. (1982). Managing The Data Resource Function 2nd edn. Nueva York, NY: West Pub1ishing Co.
Robson W. (1994). Strategic Management and Information Systems: An Integrated Approach. Londres: Pitman Shneiderman D. y Plaisant C. (2003). Designing the User Interface. Addison- Wesley Teng J.T.c. y Grover V. (1992). An empirical study on the determinants of effective database management. J Database Administration, 3(1), 22-33 Weldon lL. (1981). Data Base Administration. York, NY: Plenum Press
Recursos
Nueva
web
http://tpc.org TPC es una corporación sin ánimo de lucro fundada para definir pruebas comparativas de bases de datos y de procesamiento de transacciones, y para diseminar entre las empresas del sector datos de rendimiento objetivos y verificables basados en las recomendaciones de TPC.
Capítulo
10
Chatzog1u P.D. y McCaulay L.A. (1997). Requirements capture and analysis: a survey of current practice. Requirements Engineering, 75-88 Hawryszkiewycz I.T. (1994). Database Analysis and Design 4th edn. Basingstoke: Macmillan Kendal EJ. y Kendal J.A. (2002). Systems Analysis and Design 5th edn. Prentice Hall Wiegers K.E. (1998). Software Requirements. Press
Microsoft
Yeates D., Shields M. y Helmy D. (1994). Systems Analysis and Design. Pitman Publishing
Capítulos
11 Y 1 2
Bennett s., McRobb S. y Farmer R. (1999). ObjectOriented Systems Analysis Using UML. McGraw Hill Benyon D. (1990). Information and Data Modelling. Oxford: Blackwell Scientific Booch G. (1994). Object-Oriented A nalysis and Design with Applications. Reading, MA: Benjamin Cummings
1
y Jacobson 1. (1999). The Unified Booch G., Rumbaugh Modeling Language User Guide. Addison- Wesley
Ravindra P.S. (1991a). Using the data administration function for effective data resource management. Data Resource Management, 2(1), 58-63
Connolly T.M. y Begg C.E. (2000). Database Solutions: A Step-by-Step Guide to Building Databases. AddisonWesley
Ravindra P.S. (1991b). The interfaces and benefits ofthe data administration function. Data Resource
Elmasri R. y Navathe S. (2000). Fundamentals of Database Systems 3rd edn. Nueva York, NY: AddisonWesley
Management,
2(2), 54-58
1226
Sistemas de bases de datos
Gogolla M. Y Hohenstein U. (1991). Towards a semantic view ofthe Entity-Relationship model. ACMTrans. Database Systems, 16(3) Hawryszkiewycz I.T (1991). Database Analysis and Design 2nd edn. Basingstoke: Macmillan Howe D. (1989). Data Analysisfor Data Base Design 2nd edn. Londres: Edward Arnold
Capítulos 13 Y 14 Connolly TM. Y Begg C.E. (2003). Database Solutions: A Step-by-Step Guide to Building Databases. 2nd edn. Addison- Wesley Date CJ. (2003). An lntroduction to Database Systems 8th edn. Reading, MA: Addison- Wesley Elmasri R. y Navathe S. (2003). Fundamentals of Database Systems 4th edn. Nueva York, NY: AddisonWesley UlIman ID. (1988). PrincipIes of Database and Knowledge-base Systems Volumes I and II. Rockville, MD: Computer Science Press
Capítulos 15 Y 16 Avison D.E. Y Fitzgerald G. (1988). lnformation Systems Development: Methodologies, Techniques and Tools. Oxford: Blackwell Batini C., Ceri S. y Navathe S. (1992). Conceptual Database Design: An Entity-Relationship Approach. Redwood City, CA: Benjamin Cummings Blaha M. y Premerlani W. (] 999). Object-Oriented Modeling and Des ign for Database Applications. Prentice-Hall Castano S., DeAntonellio v., Fugini M.G. y Pemici B. (1998). Conceptual schema analysis: techniques and applications. ACM Trans. Database Systems, 23(3), 286-332 Connolly T.M. y Begg C.E. (2003). Database Solutions: A Step-by-Step Guide to Building Databases 2nd edn. Addison- Wesley Hawryszkiewycz I.T (1994). Database Analysis and Design 4th edn. Nueva York: Macmillan Howe D. (1989). Data Analysis for Data Base Design 2nd edn. Londres: Edward Arnold Muller R.J. (1999). Database Designfor Smarties: Using UMLfor Data Modeling. Morgan Kaufmann Naiburg E. y Maksimchuck R.A. (2001). UMLfor Database Design. Addison Wesley Navathe S. y Savarese A. (1996). A practical schema integration facility using an object-oriented approach. En
Object-Oriented Multidatabase Systems: A So/utionfor Advanced Applications (Bukhres O. y Elmagarmid A., eds). Prentice-Hall Sheth A., Gala S. y Navathe S. (1993). On automatic reasoning for schema integration. lnt. Journal of Intelligent Co-operative Information Systems, 2(1)
Recursos web http://www.businessrulesgroup.org Business Rules Group, anteriormente parte de GUIDE Intemational, que formula y promueve estándares relativos a las reglas de negocio. http://www.inconcept.com/JCM/index.htmIJ oumal of Conceptual Modeling, una revista dedicada al modelado conceptual. http://www.revealnet.com Un portal dedicado al desarrollo y administración de bases de datos Orac1e. http://www.sswug.org Un portal dedicado al desarrollo y administración de bases de datos Orac1e, DB2 y SQL Server.
Capítulos 17 Y 18 Connolly TM. Y Begg C.E. (2003). Database Solutions: A Step-by-Step Guide to Building Databases 2nd edn. Addison- Wesley Howe D. (1989). Data Analysis for Data Base Design 2nd edn. Londres: Edward Arnold Novalis S. (1999). Access 2000 VBA Handbook. Sybex Powell G. (2003). Oracle High Performance 9i and lag. Butterworth-Heinemann
Tuningfor
Senn J.A. (1992). Analysis and Design of lnformation Systems 2nd edn. Nueva York, NY: McGraw-Hill Shasha D. (1992). Database Tuning: A Principled Approach. Prentice-Hall Tillmann G. (1993). A Practical Guide to Logical Data Modelling. Nueva York, NY: McGraw-Hill Wertz C.J. (1993). Relational Database Design.· A Practitioner s Guide. Nueva York, NY: CRC Press Willits J. (1992). Database Design and Construction: Open Learning Course for Students and lnformation Managers. Library Association Publishing
Capítulo 19 Ackmann D. (1993). Software Asset Management: Motorola Inc. l/S Analyzer, 31(7), 5-9 Bemer P. (1993). Software auditing: Effectively combating the five deadly sins. Information Management & Computer Security, 1(2), 11-12
Lecturas adicionales
Bhashar K. (1993). Computer Security: Threats and Countermeasures. Oxford: NCC Blackwell
1227
Brathwaite K.S. (1985). Data Administration: Selected Topics of Data Control. Nueva York, NY: John Wiley
Stachour P. y Thuraisingham B. (1990). Design ofLDV: A multilevel secure relational database management system. IEEE Trans. on Knowledge and Data Engineering, 2(2)
Castano S., Fugini M., Martella G. y Samarati P. (1995). Database Security. Addison- Wesley
Stallings W. (2002). Network Security Essentiak Imports and PHIPE
Chin F. y Ozsoyoglu G. (1981). Statistical database designo ACMTrans. Database Systems, 6(1),113-139
Stallings W. (2003). Cryptography and Network Security: PrincipIes and Practice. Prentice Hall
Collier P.A., Dixon R. y Marston C.L. (1991). Computer Research Findings de UK. Internal Auditor, agosto,49-52 Denning D. (1980). Secure statistical databases with random sample queries. ACM Trans. Database Systems, 5(3),291-315 Denning D.E. (1982). Cryptography and Data Security. Addison- Wesley Ford W. y Baum M.S. (2000). Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption 2nd edn. Prentice Hall Griffiths P. y Wade B. (1976). An authorization mechanism for a relational database system. ACM Trans. Database Systems, 1(3), 242-255 Hsiao D.K., Kerr D.S. y Madnick S.E. (1978). Privacy and security of data communications and data bases.
E~ Issues in Data Base Management, Proc. 4th Int. Con[. Very Large Data Bases. North-Holland Jajodia S. (1999). Database Security: Status and Prospects Vol XII. Kluwer Academic Publishers Jajodia S. y Sandhu R. (1990). Polyinstantiation integrity in multilevel relations. En Proc. IEEE Symp. On Security and Privacy . Kamay V. y Adams T. (1993). The 1992 profile of computer abuse in Australia: Part 2. Information Management & Computer Security, 1(2),21-28 Landwehr C. (1981). Formal models of computer security. ACM Computing Surveys, 13(3),247-278 Nasr 1. y Mahler R. (2001). Designing Secure Database Driven Web Sites. Prentice Hall Perry W.E. (1983). Ensuring Data Base Integrity. Nueva York, NY: John Wiley Pfieeger C. (1997). Security in Computing 2nd edn. Englewood Cliffs, NJ: Prentice Hall Rivest R.L., Shamir A. y Adleman L.M. (1978). A method for obtaining digital signatures and public-key cryptosystems. Comm. ACM, 21(2), 120-126 Schneier B. (1995). Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley & Sons
US
Theriault M. y Heney W. (1998). Oracle Security. O'Reilly & Associates
Recursos
web
http://www.abanet.org/scitech/ec/isc/dsg-tntoria1.html American Bar Association Section of Science and Technology, Information Security Committee, una organización que ha redactado esta guía relativa a las firmas digitales. http://www.computerprivacy.org/who/ Americans for Computer Privacy (ACP) es un grupo de empresas y asociaciones que representan a empresas de fabricación, de telecomunicaciones, de servicios financieros, de tecnologías de la información y de transporte, así como a grupos de libertades civiles y de defensa del contribuyente y a agencias policial es preocupadas por la intimidad informática. http://www.cpsr.org/ Computer Professionals for Social Responsibility (CPSR) es una asociación de informáticos y personas de otros ámbitos que trata de analizar el impacto que la tecnología informática tiene sobre la sociedad. http://www.cve.mitre.org/ Common Vulnerabilities and Exposures (CVE) es una lista de nombres estandarizados para vulnerabilidades y otros riesgos de seguridad de la información identificados por CVE y monitorizados por MITRE Corporation. CVE trata de estandarizar los nombres de todos estos riesgos y vulnerabilidades conocidos. http://www.epic.org Electronic Privacy Information Center (EPIC), una organización dedicada a informar sobre la intimidad electrónica. http://www.isi.edu/gost/brian/security/kerberos.html Este documento contiene una guía del protocolo Kerberos para autenticación de usuarios.
Capítulo 20 Bayer H., Heller H. y Reiser A. (1980). Parallelism and recovery in database systems. ACM Trans. Database Systems,5(4), 139-156 Bernstein P.A. y Goodman N. (1983). Multiversion concurrency control- theory and algorithms. ACM Trans. Database Systems, 8(4),465--483
1228
Sistemas de bases de datos
Bernstein AJ. Y Newcomer E. (2003). PrincipIes of Transaction Processing. Morgan Kaufmann Bernstein P.A., Hadzilacos V. y Goodman N. (1988). Concurrency Control and Recovery in Database Systems. Reading, MA: Addison-Wesley Bernstein P.A., Shipman D. W. y Wong W.S. (1979). Formal aspects of serializability in database concurrency control. IEEE Trans. Software Engineering, 5(3),203-215 Chandy K.M., Browne lC., Dissly C.w. y Uhrig W.R. (1975). Analytic models for rollback and recovery strategies in data base systems. IEEE Trans. Software Engineering, 1(1), 100-110 Chorafas D.N. y Chorafas D.N. (2003). Transaction Management. St Martin's Press Davies Jr. le. (1973). Recovery semantics for a DBIDC system. En Proc. ACM Annual Conf, 136-141 Elmagarmid A.K. (1992). Database Transaction Models for Advanced Applications. Morgan Kaufmann Elmasri R. y Navathe S. (2000). Fundamentals of Database Systems 3rd edn. Addison- Wesley Gray J.N. (1978). Notes on data base operating systems. En Operating Systems: An Advanced Course, Lecture Notes in Computer Science (Bayer R., Graham M. y Seemuller G, eds), 393--481. Berlín: Springer-Verlag Gray J.N. (1981). The transaction concept: virtues and limitations. En Proc. Int. Conf Very Large Data Bases, 144-154 Gray J.N. (1993). Transaction Processing: Concepts and Techniques. San Mateo CA: Morgan-Kaufmann Gray J.N., McJones P.R., Blasgen M., Lindsay B., Lorie R., Price T., Putzolu F. y Traiger 1. (1981). The Recovery Manager of the System R database manager. ACM Computing Surv., 13(2),223-242 Jajodia S. y Kerschberg L., eds (1997). Advanced Transaction Models and Architectures. Kluwer Academic Kadem Z. y Silberschatz A. (1980). Non-two phase locking protocols with shared and exclusive locks. En Proc. 6th Inl. Conf on Very Large Data Bases, Montreal, 309-320 Kohler K.H. (1981). A survey oftechniques for synchronization and recovery in decentralized computer systems. A CM Computing Surv., 13(2), 148-183
Kumar V. (1996). Performance ofConcurrency Control Mechanisms in Cenlralized Database Systems. Englewood Cliffs, NJ: Prentice-Hall Kung H.T. y Robinson J.T. (1981). On optimistic methods for concurrency control. ACM Trans. Database Systems, 6(2), 213-226 Lewis P.M., Bemstein A.l y Kifer M. (2003). Databases and Transaction Processing: An Application-Oriented Approach. Addison Wesley Lorie R. (1977). Physical integrity in a large segmented database. ACM Trans. Database Systems, 2(1), 91-104 Lynch N.A., Merritt M., Weihl w., Fekete A. y Yager R.R., eds (1993). Atomic Transactions. Morgan Kaufmann
1
y Eliot B. (1985). Nested Transactions: Moss l, Eliot An Approach to Reliable Distributed Computing. Cambridge, MA: MIT Press
Papadimitriou e. (1986). The Theory of Database Concurrency Control. Rockville, MD: Computer Science Press Thomas R.H. (1979). A majority concensus approach to concurrency control. ACM Trans. Database Systems, 4(2), 180-209
Recursos web http://tpc.org TPC es una corporación sin ánimo de lucro fundada para definir pruebas comparativas de bases de datos y de procesamiento de transacciones y para diseminar entre las empresas del sector datos de rendimiento objetivos y verificables basados en las recomendaciones de TPC.
Capítulo 21 Freytag J.e., Maier D. y Vossen G (1994). Query Processingfor Advanced Database Systems. San Mateo, CA: Morgan Kaufmann Jarke M. y Koch J. (1984). Query optimization in database systems. ACM Computing Surv., 16(2), 111-152 Kim w., Reiner D.S. y Batory D.S. (1985). Query Processing in Database Systems. Nueva York, NY: Springer- Verlag Korth H., Silberschatz A. y Sudarshan S. (1996). Database System Concepts 3rd edn. McGraw-Hill
Korth H.F. (1983). Locking primitives in a databas e system. J. ACM, 30(1),55-79
Ono K. y Lohman GM. (1990). Measuring tbe complexity of join enumeration in query optimization. En Proc. 16th Int. Conf on Very Large Data Bases, Brisbane, Australia
Korth H., Silberschatz A. y Sudarsban S. (1996). Database System Concepts 3rd edn. McGraw-Hill
Ramakrishnan R. y Gehrke J. (2000). Database Management Systems 2nd edn. McGraw-Hill
Lecturas adicionales
Swami A. Y GuptaA. (1988). Optimization oflarge join queries. Prac. ACM SIGMOD Int. Conf on Management of Data, Chicago, Illinois Vance B. y Maier D. (1996). Rapid bushy join-order optimization with cartesian products. Proc. ACM SIGMOD Int. Conf on Management of Data, Montreal, Canadá
1229
Stonebraker M. (1979). Concurrency control and consistency of multiple copies of data in distributed INGRES. IEEE Trans. Software Engineering, 5(3), 180-194 Traiger I.L., Gray J., Galtieri C.A. y Lindsay B.O. (1982). Transactions and consistency in distributed database systems. ACM Trans. Database Systems, 7(3), 323-342
Yu C. (1997). PrincipIes of Database Query Pracessing for Advanced AppIications. San Francisco, CA: Morgan Kaufmann
Yeung A., Pang N. y Stephenson P. (2002). Oracle9i Mobile. Osbome McGraw-Hill
Capítulos 22 a 24
Capítulos 25 a 27
Bell D. Y Grimson J. (1992). Distributed Database Systems. Harlow: Addison Wesley Longman
Atkinson M., ed. (1995). Froc. ofWorkshop Object Systems. Springer-Verlag
Bhargava B., ed. (1987). Concurrency and Reliability in Distributed Systems. Nueva York, NY: Van Nostrand Reinhold
Ben-Nathan R. (1995). CORBA: A Guide to Common Object Request Broker Architecture. McGraw-Hill
on Persistent
Bray O.H. (1982). Distributed Database Management Systems. Lexington Books
Bertino E. y Martino L. (1993). Object-Oriented Database Systems: Concepts and Architectures. Wokingham: Addison- Wesley
Ceri S. y Pelagatti o. (1984). Distributed Databases: PrincipIes and Systems. Nueva York, NY: McGrawHill
Bukhres O.A. y Elmagarmid A.K., eds (1996). ObjectOriented MuItidatabase Systems: A Solutionfor Advanced Applications. Prentice-Hall Chaudhri A.B. y Loomis M., eds (1997). Object Databases in Practice. Prentice-Hall
Chang S.K. y Cheng W.H. (1980). A methodology for structured database decomposition. IEEE Trans. Software Engineering, 6(2), 205-218 Chorofas D.N. y Chorafas D.M. (1999). Transaction Management: Managing Complex Transactions and Sharing Distributed Databases . .-palgrave Dye C. (1999). Oracle Distributed Systems. O'Reilly Associates
&
Knapp E. (1987). Deadlock detection in distributed databases. ACM Computing Surv., 19(4), 303-328 Navathe S., Karlapalem K. y Ra M.Y. (1996). A mixed fragmentation methodology for the initial distributed databas e designo Journal of Computers and Software Engineering,3(4) Ozsu M. y Valduriez P. (1999). PrincipIes of Distributed Database Systems 2nd edn. Englewood Cliffs, NJ: Prentice- Hall Podeameni S. y Mittelmeir M. (1996). Distributed ReIational Database, Crass PIatform Connectivity. Englewood Cliffs, NJ: Prentice-Hall Rozenkrantz D.J., Steams R.E. y Lewis P.M. (1978). System level concurrency control for distributed data base systems. ACM Trans. Database Systems, 3(2), 178~198 Simon A.R. (1995). Strategic Database Technology: Management for the Year 2000. San Francisco, CA: Morgan Kaufmann
Chaudhri A.B. y Zicari R. (2000). Succeeding with Object Databases: A Practical Look at Today's ImpIementations with Java and XML. John Wiley Sons
&
Cooper R. (1996). Interactive Object Databases: The ODMG Approach. Intemational Thomson Computer Press Eaglestone B. y Ridley M. (1998). Object Databases: An Intraduction. McGraw-Hill Elmasri R. (1994). Object-Oriented Database Management. Englewood Cliffs, NJ: Prentice-Hall Embley D. (1997). Object Database DeveIopment: Concepts and PrincipIes. Harlow: Addison Wesley Longman Fowler M. (2003). UML Distilled: A BriefGuide to the Standard Object Modeling Language 3rd edn. Addison Wesley Harrington J.L. (1999). Object-Oriented CIearIy ExpIained. AP Professional
Database Design
Jordan D. (1998). C++ Object Databases: Programming with the ODMG Standard. Harlow: Addison Wesley Longman Kemper A. y Moerkotte o. (1994). Object-Oriented Database Management: Applications in Engineering and Computer Science. Englewood Cliffs, NJ: Prentice-Hall
1230
Sistemas de bases de datos
Ketabachi M.A., Mathur S., Risch T. y Chen J. (1990). Comparative Analysis of RDBMS and OODBMS: A Case Study. IEEE In!. Conf. on Manufacturing Khoshafian S., Dasananda S. y Minassian N. (1999). The Jasmine Object Database: Multimedia Applications for the Web. Morgan Kaufinann Kim W., ed. (1995). Modern Database Systems: The Object Model, Interaperability MA: Addison-Wesley
and Beyond. Reading,
Loomis M.E.S. (1995). Object Databases. Reading, MA: Addison- Wesley Naiburg E. y Maksimchuck R.A. (2001). UMLfor Database Design. Addison Wesley Nettles S., ed. (1997). Prac. of Workshop on Persistent Object Systems. San Francisco, CA: Morgan Kaufmann Ozsu M.T., Dayal U. y Valduriez P., eds (1994). Distributed Object Management. San Mateo, CA: Morgan Kaufmann
Stonebraker M., Moore D. y Brown P. (1998). ObjectRelational DBMSs: Tracking the Next Great Wave, 2nd edn. Morgan Kaufmann Vermeulen R. (1997). Upgrading Relational Databases Using Objects. Cambridge University Press
Capítulo 29 Ben-Nathan R. (1997). Objects on the Web: Designing, Building, and Deploying Object-Oriented Applications for the Web. McGraw-Hill Berlín D. et al. (1996). CGI Programming Sams Publishing Boutell T. (1997). CGI Programming. Wesley Longman
Unleashed.
Harlow: Addison
Brown B.D. (2001). Oracle9i Web Development. McGraw-Hill
Osbome
Chang B., Scardina M. y Kiritzov S. (2001). Oracle9i XML Handbook. Osbome McGraw-Hill
Pope A. (1998). COREA Reference Guide: Understanding the Common Object Request Broker Architecture. Harlow: Addison Wesley Longman
Cooper B., Sample N., Franklin M.J., Hjaltason M.J. y Shadmon M. (200 1). A fast index for semistructured data. En Proc. Int Conf. Very Large Data Bases
Rosenberg D. y Scott K. (2001). Applying Use Case Driven Object Modeling with UML: An Annotated ECommerce Example. Addison Wesley
Comell o. y Abdeli K. (1997). CGI Programming Java. Prentice-Hall
Saracco C.M. (1998). Universal Database Management: A Guide to Object/Relational Technology. Morgan Kaufinann Simon A.R. (1995). Strategic Database Technology: Managementfor the Year 2000. San Francisco, CA: Morgan Kaufmann
Recursos
http://www.objectivity.com Objectivity. http://www.objectstore.net ObjectStore.
Deitel R.M., Deitel P.J. y Nieto T.R. (2000). Internet World Wide Web: How to Programo Prentice-Hall
&
Forta B. (1997). The Cold Fusion Web Database Construction Kit. Que Corp. Greenspan J. y Bulger B. (2001). MySQLlPHP Database Application. Hungry Minds, lnc. Holm B., Carnell J., Goodman J., Marcotte B., Mukhar K., Naranjo M., Piermarini M., Raj A., Sarang P.o., Singh S. y Stubbs T. (2001). Oracle9i Java
web
http://www.gemstone.com Gemstone.
with
Sitio web del SGBDOO Sitio web del SGBDOO Sitio web del SGBDOO
http://www.omg.org Sitio web de OMG (Object Management Group). http://www.poet.com Sitio web del SGBDOO Poet.
Capítulo 28 Fortier P. (1999). SQL3: Implementing Foundation Standard. McGraw-Hill
the SQL
Melton J. y Simon A. (2003). Advanced SQL 1999: Understanding Object-Relational and Other Advanced Features. Morgan Kaufmann
Programming: Solutions for Developers using Java and PL/SQL. Wrox Press Ud Hotka D. (2001). Oracle9i Development Que
by Example.
Jepson B. (1996). World Wide Web Database Programmingfor
Windows NT. John Wiley
&
Sons
Kaushik R., Bohannon P., Naughton J.F. y Korth H.F. (2002). Covering indexes for branching path expressions. En Prac. ACM SIGMOD Conf, 2002 Ladd R.S. (1998). Dynamic HTML. Nueva York, NY: McGraw-Hill Lang C. (1996). Database Publishing on the Web. Coriolis Group Lemay L. (1997). Teach YourselfWeb Publishing HTML. Sams Publishing
with
1231
Lecturas adicionales
Lovejoy E. (2000). Essential ASP for Web Professionals. Prentice-Hall Melton J., Eisenberg A. y Cattell R. (2000). Understanding SQL and Java Together: A Guide to SQLJ, JDBC, and Related Technologies. Morgan Kaufmann MendelzonA., Minhaila GA. y Milo T. (1997). Querying the World Wide Web. Journal of Digital Libraries, 1, 54-67 Mitchell S. (2000). Designing Active Server Pages. O'Reilly & Associates
http://www.4guysfromrolIa.com
Un sitio web exce-
lente que contiene vistas de preguntas frecuentes, artículos relativos a ASP y ejemplos de código para ASP y ASP.NET. http://www.aspfree.com Contiene tutoriales, ejemplos, foros de discusión y descargas relativas a ASP. http://www.devx.com/dbzone Sitio web dedicado al desarrollo de bases de datos en la Web. http://www.javaworld.com Recursos en línea para desarrolladores Java incluyendo JDBC, JDO, JSP y EJB.
Morisseau-Leroy N., Solomon M. y Momplaisir G (2001). Oracle9i SQLJ Programming. Osborne McGraw-Hill
http://www.jdocentral.com
Newcomer E. (2002). Understanding Web Services: XML, WSDL, SOAP and UDDI. Addison Wesley
http://www.netcraft.com/survey Sitio web de Netcraft, que contiene estadísticas web muy útiles.
Oak H. (2004). Oracle JDeveloper IOg: Empowering J2EE Development. Apress
http://www.nua.ie/survey Fuente en línea de información sobre demografia y tendencias en Internet.
Odewahn A. (1999). Oracle Web Applications: PL/SQL Developer s Introduction. O'Reilly & Associates
http://www.onjava.com Recursos en línea para desarrolladores Java, incluyendo JDBC, JDO, JSP y EJB.
Powers S. (2001). Developing ASP Components 2nd edn. O'Reilly & Associates
http://www.stars.com Es un completo recurso de información para desarrolladores web.
Price J. (2002). Oracle9i JDBC Programming. McGraw-Hill
http://www.w3schools.com Sitio web de W3 Schools, que contiene diversos tutoriales que cubren, entre otras tecnologías, ASP, ADO, PHP, .NET, JavaScript y VBScript.
Reese G (2000). Database Programming Java, 2nd edn. O'Reilly & Assol:iates
Osborne
with JDBC and
Sitio web JDO Central
que contiene recursos en línea para desarrolladores JDO.
Scardina M.Y., Chang B. y Wang J. (2004). Oracle Database IOg XML and SQL: Design, Build and Manage XML Applications in Java, C, C++ and PL/SQL. Osborne McGraw-Hill
http://www.Webdeveloper.com Otro completo recurso de información para desarrolladores web.
Vandivier S. y Cox K. (2001). Oracle9i Application Server Portal Handbook. Osborne McGraw-Hill
Abiteboul S., Buneman P. y Suciu D. (1999). Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufmann
White S., Fisher M., Cattell R., Hamilton G y Hapner M. (1999). JDBC API Tutorial and Reference: Data Access for the Java 2 Platform, 2nd edn. AddisonWesley
Williamson A. y Moran C. (1998). Java Database Programming: Servlets & JDBC. Prentice-Hall
Recursos
web
http://hoohoo.ncsa.uiuc.edu/cgil Información sobre la especificación CGI completa de NCSA. http://java.sun.com/docs/books/tutorial Sitio web de Java creado por Sun, donde podrá encontrar diversos tutoriales, entre ellos algunos dedicados a JDBC, JDO yEJB. http://theserverside.com para desarrollo J2EE.
Una comunidad en línea
Capítulo 30
Arciniegas F. (2000). XML Developer McGraw-Hill
s Guide.
Osborne
Atzeni P., Mecca G y Merialdo P. (1997). To weave the Web. En Proc. of 23rd lnt. Conf on VLDB, Atenas, Grecia, 206-215 Bonifati A. y Ceri S. (2000). Comparative analysis of five XML query languages. ACM SIGMOD Record, 29(1) Bosak J. (1997). XML, Java, and thefuture ofthe Web. Available from http://sunsite.unc.edu/pub/suninfo/standards/xml/w hy /xmlapps.htm Bosak 1. y Bray T. (1999). XML and the SecondGeneration Web. Scientific American, Map 1999 Disponible en http://www.sciam.com Bradley N. (2000). The XSL Companion. Addison- Wesley
1232
Sistemas de bases de datos
Brown P.G. (2001). Object-Relational Database Development: A Plumber s Guide. Prentice-Hall Buneman P., Davidson S., Femandez M. y Suciu D. (1997). Adding structure to unstructured data. En Proc. ofthe /CDT
Ruth-Haymond G., Mitchell G.E., Mukhar K., Nicol G., O'Connor D., Zucca M., Dillon S., Kyte T., Horton A. y Hubeny F. (2000). Professional Oracle8i Application Programming with Java, PL/SQL and XML. Wrox Press Inc.
ChamBerlín D., Draper D., Femandez M., Kay M., Robie J., Rys M., Simeon J., Tivy J. y Wadler P. (2004). XQuery from the Experts: A Guide to the W3C XML Query Language. Addison Wesley
Shanmugasundaram J., Shekita E., Barr R., Carey M., Lindsay B., Pirahesh H., Reinwald B. (2001). Efficiently Publishing Relational Data as XML. VLDB Journal, 10, issue 2~3, 133-154
Chang D. y Harkey D. (1998). Client/Server Data Access with Java and XML. John Wiley & Sons
Stijn Dekeyser S., Hidders J. y Paredaens J. (2004). A transaction model for XML databases. World Wide
Chang B., Scardina M., Karun K., Kiritzov S., Macky 1. y Ramakrishnan N. (2000). Oracle XML. Osborne McGraw-Hill Chaudhri A.B. y Zicari R. (2000). Succeeding with Object Databases: A Practical Look at Today s Implementations with Java and XML. John Wiley & Sons
Web,7(1) Tatarinov 1., Ives Z.G., Halevy A.Y. y Weld D.S. (2001). Updating XML. Froc. ACM SIGMOD Con[ on Management of Data, Santa Barbara, California W3C (1998). Query for XML: position papers. http://www.w3.org/TandS/QL/QL98/pp.html
Recursos Chaudhri A.B., Zicari R., Rashid A. (2003). XML Data Management: Native XML and XML-enabled Database Systems. Addison Wesley Femandez M., Florescu D., Kang J., Levy A. y Suciu D. (1997). Strudel: a web site management system. En Prac.of ACM S/GMOD Con[ on Management ofData Fernandez M., Florescu D., Kang J., Levy A. y Suciu D. (1998). Catching the boat with Strudel: experienc;s with a web-site management system. En Proc. of ACM SIGMOD Conf on Management of Data Fung K.y. (2000). XSLT Addison- Wesley
Working with XML and HTML.
Kay M. (2001). XSLT Programmer Wrox Press Inc.
s Reference
2nd edn.
of six Lee D. y Chu w.w. (2000). Comparative'analysis XML schema languages. ACM SIGMOD Record, 29(3) McHugh J. y Widom J. (1999). Query optimization XML. En Proc. of 25th Int. Conf on VLDB, Edimburgo
for
Muench S. (2000). Building Oracle XML Applications. O'Reilly & Associates Pascal F. (2001). Managing data with XML: Forward to the past? Disponible en http://searchdatabase.techtarget.com Quin L. (2000). Open Source XML Database Toolkit: Resources and Techniques for Impraved Development. John Wiley & Sons Rendon Z.L. y Gardner J.R. (2001). Guide to XML Transformations: XPath and XSLT. Prentice-Hall
web
http://db.bell-Iabs.com/galax ción de XQuery.
Galax: una implementa-
http://www.ipedo.com/htmI/ipedo _ xml_ database.html Sitio web para la base de datos XML Ipedo. http://www.oasis-open.org Sitio web de OASIS (Organization for the Advancement of Structured Information Standards). http://www.oasis-open.org/ committees/relax -ng/spec20011203.html Especificación RELAX-NG de OASIS. http://www.oasis-open.org/cover/xml.html Sitio web que incluye enlaces a preguntas frecuentes, recursos en línea, iniciativas del sector, demostraciones, conferencias y tutoriales http://www.softwareag.com/tamino servidor XML Tamino.
Sitio web para el
http://www.topxmI.com/xq uery /default.asp Tutoriales sobre XQuery y ASP.NET. http://www.w3c.org Sitio web de W3C (World Wide Web Consortium), que desarrolla tecnologías interoperabIes, (especificaciones, directrices, software y herramientas) para la Web. http://www.w3schools.com
Sitio web de W3 Schools
que contiene diversos tutoriales que cubren todas las tecnologías XML. http://www.x-hive.com/products/ db/index.html Sitio web de la base de datos X-Hive, una base de datos XMLnativa.
Lecturas adicionales
http://www.xml.com Sitio web dedicado a XML ya tecnologías relacionadas.
Kimball R. Y Merz R. (2000). The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse. Wiley Computer Publishing
http://www.xml.org Sitio web dedicado a XML ya tecnologías relacionadas. http://www.xmldb.org Sitio web de la comunidad XML:DB para productos de bases de datos XML.
Kimball R. y Ross R. (2002). The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. Wiley Computer Publishing
http://www.xmldb.org/xupdate//xupdate-req.html Requisitos del lenguaje de actualización XML elaborados por XML:DB.
Singh H.S. (1997). Data Warehousing: Concepts, Technologies, Implementation and Management. Saddle River, NJ: Prentice-Hall
http://www.xmlglobal.com/prod/ db/index.j sp Sitio web de GoXML, una base de datos XML nativa.
Recursos web
http://www.xmlinfo.com Otra completa fuente de información acerca de XML. http://xml.coverpages.org Sitio web dedicado a XML y a tecnologías relacionadas.
Capítulos 31 Y 32 Adamson C. y Venerable M. (1998). Data Warehouse Design Solutions. John Wiley & Sons Anahory S. y Murray D. (1997). Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems. Harlow: Addison Wesley Longman Berson A. y Smith S.J. (1997). Data Warehousing, Data Mining, & OLAP. McGraw Hill Companies lnc. Data Warehouse lnformation Center. Disponible en www.dwinfocenter.org Devlin B. (1997). Data Warehouse: From Architecture to Implementation. Harlow: Addison Wesley Longman Hackney D. (1998). The Seven Deadly Sins of Data Warehousing. Harlow: Addison Wesley Longman Hackney D. (1998). Understanding and Implementing Successful Data Marts. Harlow: Addison Wesley Longman Hobbs L. y Hillson S. (2000). Oracle8i Data Warehousing. Butterworth-Heinemann lmhoff C., Galemmo N. y Geiger G. (2003). Mastering Data Warehouse Design.· Relational and Dimensional Techniques. John Wiley & Sons lnmon W.H. (2002). Building the Data Warehouse. Nueva York, NY: John Wiley & Sons lnmon W.H., Welch lD. y Glassey K.L. (1997). Managing the Data Warehouse. Nueva York, NY: John Wiley & Sons Kimball R. y Merz R. (1998). The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. Wiley Computer Publishing
1233
http://www.billinmon.com
Upper
Bill lnmon es una de las
principales autoridades en temas de gestión de datos y almacenes de datos. http://www.datawarehousing.com Portal en linea dedicado al tema de almacenes de datos. http://www.dw-institute.com Data Warehousing lnstitute es un grupo industrial dedicado a los métodos de implementación aplicaciones.
para almacenes de datos y a sus
http://www.ralphkimball.com Ralph Kimball es una de las principales autoridades en el tema de almacenes de datos.
Capítulo 33 Arkhipenkov S. y Golubev D. (2001). Oracle Express Olap. Charles River Media BersonA. y Smith SJ. (1997). Data Warehousing, Data Mining, & OLAP. McGraw Hill Companies lnc. Cabena P., Hadjinian P., Stadler R., Verhees l y Zanasi A. (1997). Discovering Data Mining from Concept to Implementation. New Jersey, USA: Prentice-Hall PTR. Groth R. (1997). Data Mining: A Hands-on Approachfor Business Professionals. Prentice Hall Hackney D. (1998). Understanding and Implementing Successful Data Marts. Harlow: Addison Wesley Longman Han J. y Kamber M. (2001). Data Mining: Concepts and Techniques. Morgan Kaufmann Publishers Thomsen E. (1997). OLAP Solutions: Building Multidimensionallnformation Systems. John Wiley Sons
&
Thomsen E. (2002). OLAP Solutions: Building Multidimensionallnformation Systems. John Wiley Sons
&
Westphal C. y Blaxton T. (1988). Data Mining Solutions. John Wiley & Sons.
1234
Sistemas de bases de datos
Whitehorn M. Y Whitehorn M. (1999). Business Intelligence: The IBM Solution: Data Warehousing and OLAP. Springer Verlag
Recursos
web
http://www.olapreport.com Un sitio que requiere suscripción para acceder a algunas de sus partes y que está dedicado a OLAP, aunque también dispone de recursos gratuitos.
Capítulo 34 Agrawal R., Imielinski T. y Swami A. (1993). Database mining: a performance perspective. IEEE Transactions on Knowledge and Data Engineering, 5(6), 914~925 Berry M. y Linoffo. (1997). Data Mining Techniques: For Marketing, Sales, and Customer Support. John Wiley & Sons. Berry M. y Linoff o. (1999). Mastering Data Mining. John Wiley & Sons. BersonA. y Smith SJ. (1997). Data Warehousing, Data Mining, & OLAP. McGraw Hill Companies Inc. Berthold M. y Hand D. (1999). Intelligent Data Analysis: An Introduction. John Wiley & Sons Fayyad U. y Simoudis E. (1997). Data mining and knowledge discovery. Tutorial notes. en Int. Joint Conf on ArtijicialIntelligence Fayyad U., Piatetsky-Shapiro o. y Smyth P. (1996). The KDD process for extracting useful knowledge from volumes ofdata. Comm. ACM, 39(11), 27-34 Groth R. (1997). Data Mining: A Hands-on Approach for Business Professionals. Prentice Hall Hackney D. (1998). Understanding and Implementing Successful Data Marts. Harlow: Addison Wesley Longman
Pyle D. (1999). Data Preparationfor Morgan Kaufmann
Data Mining.
Selfridge P., Srivastava D. y Wilson L. (1996). IDEA: Interactive Data Exploration and Analysis. En Proc. ACM SIGMOD Conf. on Management of Data Wang J., ed. (2003). Data Mining: Opportunities and Challenges. Idea Group Inc. Witten I.H. y Frank E. (1999). Data Mining: Practical Machine Learning Tools and Techniques with Java Implementations. Morgan Kaufmann
Recursos
web
http://www.kdnuggets.com Este sitio web contiene información sobre minería de datos, minería web, descubrimiento, reconocimiento y sistemas de ayuda a la toma de decisiones; los recursos incluyen noticias, software, soluciones, información sobre empresas, ofertas de trabajo, cursos, reuniones y publicaciones. http://www.thearling.com Sitio web de Kurt Thearling, que contiene información acerca de la minería de datos y las tecnologías analíticas. El sitio web dispone de un tutorial sobre minería de datos.
Apéndice
C
Austing R.H. Y Cassel L.N. (1988). File Organization and Access: From Data to Information. Lexington MA: D.C. Heath y Co. Baeza-Yates R. y Larson P. (1989). Performance ofB+trees with partial expansion. IEEE Trans. Knowledge and Data Engineering, 1(2) Folk M.J. y Zoellick B. (1987). File Structures: A Conceptual Toolkit. Reading, MA: Addison- Wesley Frank L. (1988). Database Theory and Practice. Reading, MA: Addison- Wesley
Han J. y Kamber M. (2001). Data Mining: Concepts and Techniques. Morgan Kaufmann Publishers
Gardarin o. y Valduriez P. (1989). Relational Databases
Hand D. (1997). Construction and Assessment of Classijication Rules. John Wiley & Sons
Johnson T. y Shasha D. (1993). The performance of current B- Tree algorithms. A CM Trans. Database Systems, 18(1)
Hand D., Mannila H. y Smyth P. (2001). PrincipIes of Data Mining (Adaptive Computation and Machine Learning). MIT Press
and Knowledge Bases. Reading, MA: Addison-Wesley
Knuth, D. (1973). The Art ofComputer Programming Volume 3: Sorting and Searching. Reading, MA: Addison- Wesley
Hastie T., Tibshirami R. y Friedman J.H. (2001). The Elements of Statistical Learning: Data Mining, lnference, and Prediction. Springer Verlag
Korth H., Silberschatz A. y Sudarshan S. (1996). Database System Concepts 3rd edn. McGraw-Hill
Imielinski T. y Mannila H. (1996). A database perspective on knowledge discovery. Comm. ACM, 38(11), 58-64
Larson P. (1981). Analysis ofindex-sequential fijes with overflow chaining. ACM Trans. Database Systems, 6(4)
Mannila H. (1997). Methods and problems in data mining. En Int. Conf. on Database Theory
Livadas P. (1989). File Structures: Theory and Practice. Englewood Cliffs, NJ: Prentice-Hall
Lecturas adicionales
1235
Mohan C. y Narang 1. (1992). Algorithms for creating indexes for very large tables without quiescing updates. En Proc. ACM SIGMOD lnt. Conf on Management 01 Data, San Diego, CA
Salzberg B. (1988). File Structures: An Analytic Approach. Englewood Cliffs, NJ: Prentice-Hall
Ramakrishnan R. y Gehrke J. (2000). Database Management Systems 2nd edn. McGraw-Hill
Wiederhold G. (1983). Database Design 2nd edn. Nueva York, NY: McGraw-Hill
& Databases: An Reading, MA: Addison- Wesley
Smith P. y Barnes G. (1987). Files lntroduction.
