EL PARADIGMA DE LA ORIENTACION A OBJETO EN …andrea/cursos/SDB2005/La OO en SQL1999 y...El...

El Paradigma de la Orientación a Objeto en SQL:1999

y Oracle 8i Capacidades y Limitaciones

El

Facultad de Ciencias Empresariales Depto. de Auditoría e Informática Ingeniería de Ejecución en Computación e Informática

Universidad Del Bío-Bío

Paradigma de la Orientación a Objeto en SQL:1999

y Oracle 8i Capacidades y Limitaciones

Informe para optar al título profesional de Ingeniero de Ejecución

en Computación e Informática

Alumno Miguel Esteban Romero Vásquez.

Profesor Guía

Gilberto Gutiérrez Retamal.

Chillán, diciembre del 2001

“Los buenos viven eternamente; El Altísimo cuida de ellos.

Por lo tanto recibirán de manos del Señor un reino glorioso y

una hermosa corona; ...” ( Sabiduría 5, 15-17)

A la Memoria de Rodrigo Muñoz

(1977-1997)

Y dedicado a Mis Padres.

Resumen del Contenido General Resumen del Contenido General ..............................................................iv Contenido General ...................................................................................vi Resumen .............................................................................................xiv Agradecimientos .....................................................................................xv 1 Introducción.......................................................................................... 1 2 El Paradigma de la Orientación a Objeto................................................ 3 2.1 Introducción............................................................................................................. 4 2.2 Conceptos Básicos.................................................................................................... 6 3 Bases de datos Orientadas a Objeto .................................................... 22 3.1 Introducción........................................................................................................... 23 3.2 Estándares de SABDOO........................................................................................... 27 4 La Orientación a Objeto en SQL:1999.................................................. 34 4.1 Introducción........................................................................................................... 35 4.2 Soporte a la Orientación a objeto............................................................................ 40 4.3 Evaluación .............................................................................................................. 83 5 Oracle 8i y la Orientación a Objeto...................................................... 87 5.1 Introducción........................................................................................................... 88 5.2 Soporte a la Orientación a Objeto ........................................................................... 89 5.3 Evaluación ............................................................................................................ 134 6 Una Aplicación de ejemplo ................................................................ 138 6.1 Introducción......................................................................................................... 139 6.2 Descripción del Prototipo...................................................................................... 146 6.3 Diseño del prototipo............................................................................................. 154 7 Conclusiones .................................................................................... 169 Apéndice A: Sintaxis de SQL:1999 Relacionada con la OO. ................... 172 A.1 Leyenda ............................................................................................................... 173 A.2 Sentencias............................................................................................................ 174 Apéndice B: UML .................................................................................. 190 B.1 ¿Qué es UML?........................................................................................................ 191 Apéndice C: Código Fuente del Prototipo y Pantallas........................... 201 C.1 Creación de tipos ................................................................................................. 202 C.2 Definición de Tablas de objetos e inserción de instancias ..................................... 239 C.3 Pantallas. ............................................................................................................. 245

C.4 Código Java. ......................................................................................................... 254 Bibliografía........................................................................................... 375

Contenido General Resumen del Contenido General ..............................................................iv Contenido General ...................................................................................vi Resumen .............................................................................................xiv Agradecimientos .....................................................................................xv 1 Introducción.......................................................................................... 1 2 El Paradigma de la Orientación a Objeto................................................ 3 2.1 Introducción............................................................................................................. 4

2.1.1 ¿Qué es el paradigma de la orientación a objeto?............................................. 4 2.2 Conceptos Básicos.................................................................................................... 6

2.2.1 Objetos ........................................................................................................... 6 2.2.1.1 Estado....................................................................................................... 7 2.2.1.2 Comportamiento y Mensajes ..................................................................... 8 2.2.1.3 Identidad .................................................................................................. 9

2.2.2 Abstracción y Clase. ........................................................................................ 9 2.2.3 Encapsulamiento ........................................................................................... 11 2.2.4 Modularidad.................................................................................................. 11 2.2.5 Jerarquía de Clases........................................................................................ 12

2.2.5.1 Herencia ................................................................................................. 13 2.2.5.1.1 Polimorfismo .................................................................................... 15

2.2.5.2 Asociación .............................................................................................. 16 2.2.5.3 Agregación y Composición ...................................................................... 17

2.2.6 Tipos (tipificación)......................................................................................... 17 2.2.7 Concurrencia................................................................................................. 18 2.2.8 Persistencia................................................................................................... 19

2.2.8.1 Formas de solucionar el problema de la persistencia ............................... 19 2.2.8.1.1 Archivos convencionales ................................................................... 19 2.2.8.1.2 Bases de datos relacionales............................................................... 20 2.2.8.1.3 Bases de datos orientadas a objetos.................................................. 20

3 Bases de datos Orientadas a Objeto .................................................... 22 3.1 Introducción........................................................................................................... 23

3.1.1 Bases de datos relacionales ........................................................................... 23 3.1.2 Bases de datos orientadas a objeto................................................................ 24

3.1.2.1 Nuevos requerimientos ........................................................................... 24 3.2 Estándares de SABDOO........................................................................................... 27

vi

Contenido General

3.2.1 Las tendencias: SABD relacionales “Extendidos” vs. SABDOO “Puros” .............. 27 3.2.2 Estándar SQL:1999........................................................................................ 30

3.2.2.1 Origen y evolución .................................................................................. 30 3.2.2.2 Partes que lo componen.......................................................................... 31

3.2.3 Estándar ODMG 2.0 ....................................................................................... 32 3.2.3.1 Origen y evolución .................................................................................. 32 3.2.3.2 Partes que lo componen.......................................................................... 32

4 La Orientación a Objeto en SQL:1999.................................................. 34 4.1 Introducción........................................................................................................... 35

4.1.1 Organizaciones preocupadas de la estandarización de SQL........................... 35 4.1.2 Nuevas características. .................................................................................. 37

4.1.2.1 Nuevos Tipos de Datos............................................................................ 37 4.1.2.2 nuevos predicados .................................................................................. 38 4.1.2.3 semántica reforzada................................................................................ 38 4.1.2.4 seguridad adicional ................................................................................. 39 4.1.2.5 bases de datos activa .............................................................................. 39

4.2 Soporte a la Orientación a objeto............................................................................ 40 4.2.1 Tipos, abstracción y clases ............................................................................ 40

4.2.1.1 Creación de tipos (CREATE TYPE)............................................................. 40 4.2.1.2 Atributos................................................................................................. 42 4.2.1.3 Métodos.................................................................................................. 43

4.2.1.3.1 Métodos de Instancia ........................................................................ 44 4.2.1.3.2 Métodos estático............................................................................... 47 4.2.1.3.3 Constructores ................................................................................... 48 4.2.1.3.4 Creación de métodos (CREATE METHOD)........................................... 48

4.2.1.4 Modificación de tipos (ALTER TYPE) ......................................................... 52 4.2.1.4.1 Agregar un atributo .......................................................................... 52 4.2.1.4.2 Eliminar un atributo .......................................................................... 53 4.2.1.4.3 Agregar un método........................................................................... 53 4.2.1.4.4 Eliminar un método........................................................................... 54

4.2.1.5 Eliminación de tipos (DROP TYPE) ............................................................ 54 4.2.1.6 Comparación de instancias...................................................................... 55

4.2.1.6.1 Eliminación de funciones de comparación ......................................... 57 4.2.1.7 Conversión de UDT (CAST definidos por el usuario) ................................. 58

4.2.1.7.1 Eliminación de CAST definidos por el usuario .................................... 59 4.2.2 Colecciones................................................................................................... 59

4.2.2.1 Arreglos.................................................................................................. 59 4.2.3 Encapsulamiento ........................................................................................... 60 4.2.4 Modularidad.................................................................................................. 62 4.2.5 Persistencia................................................................................................... 62

vii

Contenido General

4.2.5.1 Manejo de Tablas .................................................................................... 62 4.2.5.1.1 Creación (CREATE TABLE) .................................................................. 62 4.2.5.1.2 Modificación (ALTER TABLE) .............................................................. 65 4.2.5.1.3 Eliminación (DROP TABLE) ................................................................. 66

4.2.5.2 Manejo de Instancias............................................................................... 67 4.2.5.2.1 Inserción de objetos.......................................................................... 67 4.2.5.2.2 Selección de objetos (SELECT) ........................................................... 69 4.2.5.2.3 Modificación de objetos .................................................................... 71 4.2.5.2.4 Eliminación de objetos ...................................................................... 72

4.2.6 Jerarquía de Clases........................................................................................ 73 4.2.6.1 Asociación .............................................................................................. 73 4.2.6.2 Agregación y Composición ...................................................................... 75 4.2.6.3 Herencia y Polimorfismo.......................................................................... 76

4.2.7 Concurrencia................................................................................................. 78 4.2.8 Manejo de Versiones de objetos y configuraciones ........................................ 79 4.2.9 Evolución de esquemas y de Instancias.......................................................... 79 4.2.10 Transacciones y recuperación ante fallos ..................................................... 80 4.2.11 Mecanismos de Autorización ....................................................................... 80 4.2.12 Compatibilidad con el modelo relacional ..................................................... 80 4.2.13 Limitaciones encontradas en SQL:1999........................................................ 82

4.3 Evaluación .............................................................................................................. 83 4.3.1 Criterios de evaluación .................................................................................. 83 4.3.2 Matriz de evaluación ..................................................................................... 85

5 Oracle 8i y la Orientación a Objeto...................................................... 87 5.1 Introducción........................................................................................................... 88 5.2 Soporte a la Orientación a Objeto ........................................................................... 89

5.2.1 Tipos, abstracción y clases ............................................................................ 89 5.2.1.1 Estructura de un tipo objeto.................................................................... 90 5.2.1.2 Sintaxis para la creación de tipos ............................................................ 90

5.2.1.2.1 CREATE TYPE .................................................................................... 91 5.2.1.2.2 CREATE TYPE BODY........................................................................... 94

5.2.1.3 Atributos................................................................................................. 95 5.2.1.4 Métodos.................................................................................................. 99

5.2.1.4.1 Constructor ...................................................................................... 99 5.2.1.4.2 Miembro (member) ......................................................................... 100 5.2.1.4.3 Estático (Static) ............................................................................... 102 5.2.1.4.4 Comparación (Map u Order) ............................................................ 102 5.2.1.4.5 Sobrecarga de métodos................................................................... 104

5.2.1.5 Alternativas para la implementación de los métodos ............................. 105 5.2.1.5.1 Implementación de los métodos con PL/SQL ................................... 106

viii

Contenido General

5.2.1.5.2 Implementación de métodos con JAVA ............................................ 106 5.2.1.5.3 Implementación de métodos con C ................................................. 109

5.2.1.6 Modificación de tipos (ALTER TYPE) ....................................................... 110 5.2.1.7 Eliminación de tipos (DROP TYPE y DROP TYPE BODY)............................ 112

5.2.2 Tipo Colección ............................................................................................ 112 5.2.2.1 Métodos de un tipo colección................................................................ 113 5.2.2.2 VARRAY ................................................................................................ 114 5.2.2.3 Tablas anidadas .................................................................................... 116

5.2.3 Encapsulamiento ......................................................................................... 117 5.2.4 Modularidad................................................................................................ 118 5.2.5 Persistencia................................................................................................. 118

5.2.5.1 Manejo de tablas (relacionales y de objetos) .......................................... 118 5.2.5.1.1 Creación (Create Table) ................................................................... 118 5.2.5.1.2 Modificación (Alter Table)................................................................ 121 5.2.5.1.3 Eliminación (Drop Table) ................................................................. 121

5.2.5.2 Manejo de objetos................................................................................. 122 5.2.5.2.1 Inserción de objetos (INSERT INTO) ................................................. 122 5.2.5.2.2 Selección de objetos (SELECT ... FROM)............................................ 124 5.2.5.2.3 Modificación de objetos (UPDATE) ................................................... 125 5.2.5.2.4 Eliminación de objetos (DELETE) ...................................................... 126

5.2.6 Jerarquía de Clases...................................................................................... 126 5.2.6.1 Asociación ............................................................................................ 126 5.2.6.2 Agregación y Composición .................................................................... 127 5.2.6.3 Herencia y Polimorfismo........................................................................ 128

5.2.7 Concurrencia............................................................................................... 129 5.2.8 Manejo de Versiones de objetos y Configuraciones...................................... 129 5.2.9 Evolución de esquemas y de Instancias........................................................ 130 5.2.10 Transacciones y recuperación ante fallos. .................................................. 130 5.2.11 Mecanismos de autorización ..................................................................... 131 5.2.12 Compatibilidad con el modelo relacional ................................................... 131 5.2.13 Limitaciones encontradas en Oracle 8i....................................................... 132

5.3 Evaluación ............................................................................................................ 134 5.3.1 Criterios de evaluación ................................................................................ 134 5.3.2 Matriz de evaluación ................................................................................... 136

6 Una Aplicación de ejemplo ................................................................ 138 6.1 Introducción......................................................................................................... 139

6.1.1 Importancia del recurso hídrico [29] ............................................................ 139 6.1.2 Gestión del recurso hídrico en Chile ............................................................ 140 6.1.3 Modelación de cuencas y proceso de Simulación hidrológico operacional. ... 141

6.1.3.1 Simulación ............................................................................................ 145

ix

Contenido General

6.2 Descripción del Prototipo...................................................................................... 146 6.2.1 Descripción de los objetos soportados ........................................................ 147

6.2.1.1 Nodos. .................................................................................................. 147 6.2.1.2 Ríos y tramos de río. ............................................................................. 148 6.2.1.3 Embalses. ............................................................................................. 149 6.2.1.4 Central Hidroeléctrica de pasada ........................................................... 150 6.2.1.5 Canal Principal ...................................................................................... 151 6.2.1.6 Hoya Intermedia.................................................................................... 152 6.2.1.7 Régimen Natural ................................................................................... 152 6.2.1.8 Captación de Agua Potable.................................................................... 153

6.3 Diseño del prototipo............................................................................................. 154 6.3.1 Diagramas de clases.................................................................................... 154

6.3.1.1 Clases implementadas en Oracle 8i ....................................................... 154 6.3.1.2 Clases implementadas en Java............................................................... 161

6.3.2 Diagramas de colaboración ......................................................................... 166 6.3.2.1 Simulación ............................................................................................ 166

6.3.3 Limitaciones Encontradas ............................................................................ 168 6.3.3.1 Limitaciones de PL/SQL ......................................................................... 168 6.3.3.2 Limitaciones de Oracle y la exportación de tipos ................................... 168

7 Conclusiones .................................................................................... 169 Apéndice A: Sintaxis de SQL:1999 Relacionada con la OO. ................... 172 A.1 Leyenda ............................................................................................................... 173 A.2 Sentencias............................................................................................................ 174

A.2.1 Creación de tipos (CREATE TYPE)................................................................. 174 A.2.2 Definición de atributos................................................................................ 176 A.2.3 Modificación de tipos (ALTER TYPE) ............................................................. 176 A.2.4 Creación de métodos, funciones y procedimientos ...................................... 177 A.2.5 Modificación de métodos, funciones y procedimientos ................................ 179 A.2.6 CAST definido por el usuario....................................................................... 180 A.2.7 Eliminación de un CAST............................................................................... 181 A.2.8 Definición del ORDERING de un tipo. ........................................................... 181 A.2.9 Eliminación de un user definer ordering ...................................................... 182 A.2.10 Funciones de transformación de tipos ....................................................... 182 A.2.11 Eliminación de funciones de transformación.............................................. 183 A.2.12 Definición de Tablas (CREATE TABLE) ........................................................ 183 A.2.13 Modificación de tablas (ALTER TABLE)........................................................ 186 A.2.14 Eliminación de tablas (DROP TABLE) .......................................................... 187 A.2.15 Inserción de filas (INSERT INTO) ................................................................ 187 A.2.16 Actualización de filas (UPDATE) ................................................................. 188 A.2.17 Eliminación de filas (DELETE FROM) ........................................................... 188

x

Contenido General

Apéndice B: UML .................................................................................. 190 B.1 ¿Qué es UML?........................................................................................................ 191

B.1.1 Diagramas de clases.................................................................................... 193 B.1.1.1 Compartimentos adicionales ................................................................. 194 B.1.1.2 Estereotipos .......................................................................................... 195 B.1.1.3 Asociaciones ......................................................................................... 196 B.1.1.4 Agregación y composición..................................................................... 196 B.1.1.5 Generalización ...................................................................................... 197 B.1.1.6 Restricciones y comentarios .................................................................. 198

B.1.2 Diagrama de colaboración ........................................................................... 199 B.1.3 Para Más información. ................................................................................. 200

Apéndice C: Código Fuente del Prototipo y Pantallas........................... 201 C.1 Creación de tipos ................................................................................................. 202

C.1.1 array_caudal. .............................................................................................. 202 C.1.2 arr_caudales................................................................................................ 202 C.1.3 Punto.......................................................................................................... 204 C.1.4 arr_puntos .................................................................................................. 204 C.1.5 Polilinea...................................................................................................... 204 C.1.6 Cuadrado.................................................................................................... 207 C.1.7 Elipse.......................................................................................................... 207 C.1.8 Triangulo .................................................................................................... 208 C.1.9 Graf_flujo.................................................................................................... 209 C.1.10 graf_cent_hidro......................................................................................... 209 C.1.11 graf_nodo ................................................................................................. 210 C.1.12 graf_emb .................................................................................................. 210 C.1.13 graf_Cuenca.............................................................................................. 210 C.1.14 Cuenca ..................................................................................................... 211 C.1.15 Nodo......................................................................................................... 213 C.1.16 Rio............................................................................................................ 217 C.1.17 Hoya_inter ................................................................................................ 217 C.1.18 Regimen_Natural....................................................................................... 219 C.1.19 Salida_Emb................................................................................................ 220 C.1.20 Aportante.................................................................................................. 221 C.1.21 Canal ........................................................................................................ 222 C.1.22 Tramo....................................................................................................... 224 C.1.23 Central_hidro ............................................................................................ 226 C.1.24 Apor_extrac .............................................................................................. 228 C.1.25 Cap_agua_Pot ........................................................................................... 230 C.1.26 Extracción................................................................................................. 231 C.1.27 Flujo ......................................................................................................... 233

xi

Contenido General

C.1.28 Embalse .................................................................................................... 235 C.2 Definición de Tablas de objetos e inserción de instancias ..................................... 239

C.2.1 Tabla: tbl_cuenca ..................................................................................... 239 C.2.2 Tabla: tbl_nodo ........................................................................................ 239 C.2.3 Tabla: tbl_rio .......................................................................................... 239 C.2.4 Tabla: tbl_Flujo ...................................................................................... 239 C.2.5 Tabla: tbl_Emb .......................................................................................... 239 C.2.6 Inserción de una Cuenca ............................................................................. 240 C.2.7 Inserción de un Rio ..................................................................................... 240 C.2.8 Inserción de un Nodo .................................................................................. 240 C.2.9 Inserción de un Embalse y sus salidas ......................................................... 240 C.2.10 Inserción de un Regimen Natural............................................................... 242 C.2.11 Inserción de una Hoya Intermedia ............................................................. 242 C.2.12 Inserción de una Captación de Agua Potable ............................................. 243 C.2.13 Inserción de una Central Hidroeléctrica ..................................................... 243 C.2.14 Inserción de un Tramo de Rio.................................................................... 243 C.2.15 Inserción de un Canal................................................................................ 244

C.3 Pantallas. ............................................................................................................. 245 C.3.1 Datos de Conexión...................................................................................... 245 C.3.2 Abrir cuenca existente ................................................................................ 245 C.3.3 Ventana Principal, después de abrir una cuenca. (Frame1.java) .................... 246 C.3.4 Agregar Cuenca .......................................................................................... 246 C.3.5 Ventana simulación al finalizar.................................................................... 247 C.3.6 Nodos y sus caudales.................................................................................. 247 C.3.7 Modificando un Rio (FrmModificarRio.java y FrmRio.java)............................. 248 C.3.8 Acerca de (Frame1_AboutBox.java).............................................................. 248 C.3.9 Propiedadas de un Canal (FrmCanal.java) .................................................... 249 C.3.10 Propiedades de una Captación de Agua Potable (FrmCapAguaPot.java) ...... 249 C.3.11 Propiedades de una central hidroeléctrica (FrmCentralHidro.java) .............. 249 C.3.12 Propiedades de una hoya intermedia (frmHoyaInter.java) ........................... 250 C.3.13 Propiedades de un régimen natural (frmRegNat.java)................................. 250 C.3.14 Propiedades de una salida de embalse (frmSalidaEmb.java) ....................... 250 C.3.15 Propiedades de un tramo de río (FrmTramo.java)....................................... 251 C.3.16 Propiedades de un nodo (frmNodo.java) .................................................... 251 C.3.17 Ventana para la modificación del Zoom (FrmZoom.java) ............................ 251 C.3.18 Menu Cuenca ............................................................................................ 252 C.3.19 Menu Río .................................................................................................. 252 C.3.20 Menu Zoom............................................................................................... 252 C.3.21 Menu Insertar............................................................................................ 252 C.3.22 Menu Consultas ........................................................................................ 253

xii

Contenido General

C.3.23 Menu Ayuda.............................................................................................. 253 C.4 Código Java. ......................................................................................................... 254

C.4.1 Paquete consultorSql................................................................................... 254 C.4.1.1 Clase: ConectorJDBC ............................................................................... 254 C.4.1.2 Clase: FrmConexion ................................................................................ 257 C.4.1.3 Clase: FrmConsultor .............................................................................. 265 C.4.1.4 Clase: JDBCAdapter ................................................................................ 268 C.4.1.5 Clase: OldJTable..................................................................................... 273 C.4.1.6 Clase sqlQuery....................................................................................... 277 C.4.1.7 Clase: TableMap ...................................................................................... 281 C.4.1.8 Clase: TableSorter................................................................................. 282 C.4.2 Paquete cuencamaule.................................................................................. 289 C.4.2.1 Clase: Frame1 ........................................................................................ 289 C.4.2.20 Clase: MainGui..................................................................................... 313 C.4.3 Paquete Figuras .......................................................................................... 314 C.4.3.1 Clase: Cuadrilatero ............................................................................. 314 C.4.3.2 Clase: Dibujante.................................................................................... 316 C.4.3.3 Clase: Elipse ........................................................................................ 321 C.4.3.4 Clase: FigGeo ........................................................................................ 323 C.4.3.5 Interfaz: Graficable ............................................................................. 323 C.4.3.6 Clase: LienzoCuenca ............................................................................. 324 C.4.3.7 Clase: Poligono..................................................................................... 327 C.4.3.8 Clase: PoliLinea................................................................................... 329 C.4.3.9 Clase: Punto .......................................................................................... 333 C.4.3.10 Clase: Triangulo................................................................................. 334 C.4.4 Paquete objcuenca ...................................................................................... 337 C.4.4.1 Clase: AporExtracOra ........................................................................... 338 C.4.4.2 Clase: AporExtracOraRef...................................................................... 346 C.4.4.3 Clase: BDObjCuenca ............................................................................... 348 C.4.4.4 Clase: GuiEmbalse ................................................................................. 353 C.4.4.5 Clase: GuiFlujo..................................................................................... 358 C.4.4.6 Clase: GuiNodo....................................................................................... 371

Bibliografía........................................................................................... 375

xiii

Resumen

Cuando desarrollamos aplicaciones bajo el paradigma de la orientación a

objeto, nos encontramos con el problema de la persistencia. Para solucionar

esto, existen diversas estrategias pasando por simples archivos, hasta bases

de datos orientadas a objetos. Las bases de datos relacionales hasta el

estándar SQL-92 no daban soporte al almacenamiento de objetos, pero, la

actual versión aprobada, del estándar llamada SQL:1999, da soporte a dichas

características.

El presente trabajo tuvo como objetivo general analizar las capacidades y

limitaciones del estándar SQL:1999 y del SABD Oracle 8i, para dar soporte al

paradigma de la orientación a objeto.

En una primera etapa, describimos los conceptos básicos del paradigma de la

orientación a objeto y las características y los tipos de bases de datos

orientadas a objeto junto con sus estándares respectivos. Después,

analizamos y describimos detalladamente cómo el estándar SQL:1999

implementa la orientación a objeto, y evaluamos dicha implementación. Lo

mismo hicimos con el SABD Oracle 8i.

Finalmente, implementamos un prototipo, utilizando como lenguaje a Java y

como SABD a Oracle 8i, con el objetivo de evaluar empíricamente la

implementación del paradigma de la orientación a objeto en Oracle8i.

Como resultado de este trabajo, podemos decir que el estándar SQL:1999

implementa en un 78,25% el paradigma de la orientación a objeto, mientras

que el SABD Oracle 8i lo implementa en un 70,58%. La limitación más

importante que tiene el SABD Oracle 8i frente a SQL:1999 es la falta de

herencia y el deficiente soporte a la evolución de esquemas.

El estándar SQL:1999, es lo suficientemente robusto para dar soporte a la

persistencia de los objetos, a diferencia del SABD Oracle 8i debido a su falta

de herencia.

xiv

Agradecimientos

Si hay algo que me ha costado hacer, es el trabajo que hoy estás leyendo.

Dos años de sacrificios, que hubieran sido eternos y quizás un rotundo

fracaso, sin la ayuda de muchos. En primer lugar quiero dar gracias a Dios,

por llenarme de bendiciones todos los días, quien me dio todos mis talentos

y es la luz en mi camino. A mis padres, Miguel y Patricia, que me han sabido

enseñar, acompañar y amar, dándome todo su apoyo y comprensión,

“tirándome las orejas” cuando me lo merecía y buscando siempre lo mejor

para mi. Junto con ellos a mis hermanos, Fabián y Pablo, por soportar mi mal

humor durante el desarrollo del proyecto. A mis amigos y compañeros de

universidad, JUFRA, Hogar de Cristo, AUC, RCC, Peñihuén Juvenil y a mis

amigos que han partido: Gonzalo Seguel, Rodrigo Fuentes y Rodrigo Muñoz

por toda la amistad y los buenos momentos que pasamos juntos. A mis

profesores, en especial a los que me acompañaron en la universidad por su

apoyo, consejo y educación. A la profesora María Antonieta, por su tiempo

y apoyo en lo referente a UML. A mi profesor guía Gilberto Gutiérrez, por su

apoyo, guía y comprensión a lo largo de todo el proyecto. Al Ministerio de

Obras Públicas (MOP), pero en particular a Mauricio Zambrano, por su tiempo

y apoyo en la explicación de los modelos de simulación hidrológica, y por las

revisiones hechas al prototipo. A Marlene Sáez por su ayuda en la traducción

del estándar SQL-1999. Y a todos los que de una u otra manera han estado

conmigo...

...Muchas Gracias.

Miguel Esteban Romero Vásquez.

Paz y Bien a todos

xv

1 Introducción

La orientación a objeto, desde sus orígenes ha sido un paradigma muy

prometedor para el desarrollo de software. En estos últimos años, hemos

visto aparecer varios productos, estándares y herramientas que han marcado

un hito en la historia de la Orientación a Objeto. Uno de ellos es el lenguaje

Java que da un soporte muy completo al paradigma de la orientación a

objeto, además, de contar con características que facilitan el desarrollo de

programas (fácil de aprender, multiplataforma, multihilo, cliente/servidor,

robusto, seguro, etc). Otro hito importante lo ha marcado la notación UML,

que rápidamente se ha convertido en el estándar para el desarrollo orientado

a objeto (ver apéndice B). A partir de UML, se han desarrollado varias

herramientas CASE, por ejemplo: Rational Rose de Rational Software y

Object Database Designer (ODD) de Oracle. Rational Rose permite diseñar

sistemas utilizando la notación UML y a partir de estos diseños, generar

automáticamente los programas en distintos lenguajes orientados a objeto,

como por ejemplo en Java y en C++. Mediante ODD podemos diseñar las

bases de datos y los tipos objetos que utilizaremos en Oracle, luego serán

generadas automáticamente las estructuras en el SABD.

Otra área del desarrollo del paradigma, son las bases de datos orientadas a

objeto. Las cuales nacen para solucionar el problema de la persistencia de

los objetos, en forma eficiente. En esta área existen dos líneas de

investigación y desarrollo, cada una con su respectivo estándar. El tema

central de este trabajo corresponde a una de las líneas de investigación,

definida por el estándar SQL:1999.

Los objetivos de este trabajo son:

Objetivo general:

Analizar las capacidades y limitaciones del estándar SQL:1999 y del

SABD Oracle 8i, para dar soporte al paradigma de la orientación a

objeto.

Objetivos específicos:

1. Analizar las capacidades y limitaciones del modelo objeto

considerado por SQL:1999.

Introducción

2. Analizar las capacidades y limitaciones del modelo objeto en el

SABD Oracle 8i.

3. Verificar las capacidades mediante la implementación de un

prototipo

Al iniciar este proyecto, el estándar SQL:1999 no había sido aprobado, y era

conocido como SQL-3. A esas alturas, ya existían productos que daban

soporte a la orientación a objeto basándose en el borrador de trabajo, entre

ellos Oracle 8i. Ahora que el estándar está aprobado, es de esperar que

aparezcan productos que implementen dicha especificación, pero por el

momento tendremos que conformarnos con implementaciones incompletas

basadas en el borrador de trabajo de SQL.

En el capítulo uno de este trabajo, explicaremos las características

fundamentales del paradigma de la orientación a objeto, y plantearemos el

problema de la persistencia, que es lo que solucionan las bases de datos

orientadas a objeto. En el dos, haremos una breve reseña histórica de las

bases de datos. Explicaremos las dos líneas de desarrollo en este campo y

sus estándares. En el tres, describiremos detalladamente todas las

características de la orientación a objeto manejadas por SQL:1999. El orden

en que describimos los conceptos es el mismo en el que explicamos las

características del paradigma de la orientación a objeto en el capítulo 1. Al

final del capítulo haremos una evaluación del soporte de la orientación a

objeto en SQL:1999. En el capítulo 4, tendrá la misma estructura del capítulo

3, para facilitar su comparación y estudio. Aquí describiremos

detalladamente el manejo de objetos que hace Oracle 8i. Al final del capítulo

haremos una evaluación del soporte del paradigma de la orientación a objeto

que hace Oracle 8i. En el capítulo cinco encontrará el desarrollo de una

aplicación orientada a objeto, utilizando el lenguaje Java y a Oracle 8i para

hacer persistir los objetos. La aplicación consiste en la implementación de un

modelo de simulación hidrológico operacional para una cuenca, realizando

una simulación de temporada. Es necesario indicar que, por motivos de

tiempo, no existe una documentación bien detallada del diseño.

2

2 El Paradigma de la Orientación a Objeto

2.1 Introducción

Las ideas de la orientación a objeto nacen a partir de los lenguajes de

programación orientados a objeto. El primero de ellos fue Simula, y desde

entonces se han desarrollado muchos otros (Smalltalk, C++, Java, etc.).

Aprender estos lenguajes no es suficiente para desarrollar un software con

estas ideas, puesto que ellas forman un paradigma.

2.1.1 ¿Qué es el paradigma de la orientación a objeto?

Para poder responder a esta pregunta, analizaremos primero lo que significa

el vocablo paradigma. Si buscamos el significado de esta palabra en un

diccionario, nos dirá que es un Ejemplo o Modelo, pero en el contexto

utilizado, es mucho más amplio.

El Historiador Tomas Kuhn define paradigma como un conjunto de teorías,

estándares y métodos que juntos representan una forma de organizar el

conocimiento, esto es, una forma de ver el mundo [5]. Todos los seres

humanos tenemos un conjunto de paradigmas que adquirimos a lo largo de

nuestra vida a través del aprendizaje y actuamos de acuerdo con ellos.

Nuestros paradigmas son de gran ayuda, porque nos permiten analizar

rápidamente la información que recibimos, además, nos dan una pauta de

cómo debemos actuar y reaccionar. Pero, cuando los hechos se escapan a la

regla general, nuestros paradigmas nos inducen a cometer errores o a tener

que reaccionar mucho más lento, para no cometerlos. Por ejemplo si vamos

conduciendo un automóvil, y el semáforo está en verde, simplemente

cruzamos la calle, puesto que el conocimiento que tenemos sobre el

semáforo, nos dice que podemos cruzar cuando la luz está de ese color, y

que por supuesto el otro lado tiene rojo. Pero ¿qué pasa si en realidad los

dos lados del semáforo están en verde?, lo más probable es que ocurra un

accidente. Que pasó aquí, bueno nuestros paradigmas nos jugaron una mala

pasada, tomamos una decisión rápida basada en ellos, sin percatarnos de

esta situación que escapa a la regla general.

4

El Paradigma de la orientación a objeto - Introducción

Al Programar un software tenemos varios paradigmas, que nos permiten

plantear soluciones. Algunos ejemplos de estos paradigmas son [4]:

• Orientados a procedimientos (enfoque clásico)

• Orientados a objetos

• Orientados a Lógica

• Orientados a Reglas

• Orientados a Restricciones

Si ponemos atención a la definición de paradigma que plantea Tomas Kuhn,

nos daremos cuenta, que cada uno de estos ejemplos tiene su propia forma

de organizar el conocimiento y de mirar al mundo.

No existe el mejor paradigma, cada uno es más adecuado que el otro para

resolver cierto tipo de problemas. Por esta razón es necesario que sean

conocidos por los desarrolladores, sólo de este modo podrán escoger el

mejor, para su problema.

Los paradigmas que utilizamos para desarrollar un software abarcan más que

lo relacionado con la tarea de programar. Tomas Kuhn en su definición nos

plantea que son un conjunto de teorías, estándares y métodos, a partir de

ello, podríamos decir que un paradigma de desarrollo de software esta

compuesto por: modelos, métodos, y diagramas para realizar análisis,

diseño, programación, gestión del desarrollo y control de la calidad. Cada

uno de estos elementos está basado en un marco de referencia conceptual

propio del paradigma. En apoyo al desarrollo de software bajo un paradigma

en particular, tenemos herramientas, lenguajes de programación, y bases de

datos que, por supuesto, están acordes al marco conceptual del paradigma.

Entonces, el paradigma de la orientación a objeto, estaría compuesto por

todos los elementos antes descritos, donde el marco de referencia

conceptual, o toda la teoría en la que se basa, está orientada al objeto. Éste

marco de referencia conceptual en particular suele denominarse modelo de

objetos (por ejemplo en [4]).

La pregunta ahora es ¿qué es orientado a objeto?. En la siguiente sección se

responderá a esta pregunta.

5

2.2 Conceptos Básicos

En el Modelo Objeto existen cuatro elementos fundamentales, estos son:

Abstracción, Encapsulamiento, Modularidad y Jerarquía; donde “un

modelo que carezca de cualquiera de estos elementos no es orientado a

objetos” [4] página 45.

Y tres elementos secundarios: Tipos (tipificación), Concurrencia y

Persistencia, donde “cada uno de ellos es una parte útil del modelo objeto

pero no es esencial.” [4] página 45.

Estos elementos parten de la noción de objeto, por ende definiremos primero

este concepto y luego, los elementos del modelo objeto.

2.2.1 Objetos

Los seres humanos estamos familiarizados con los objetos, los utilizamos

diariamente y desde muy temprana edad aprendemos a identificarlos y

reconocerlos [4]. Éstos pueden ser:

• Una cosa Tangible y/o visible

• Algo que puede comprenderse intelectualmente

• Algo hacia lo que se dirige un pensamiento o acción.

Un objeto posee un conjunto de

características esenciales, llamadas

propiedades o atributos [20].

Estos atributos son los que dan al

objeto su naturaleza o tipo y hacen

que el objeto no sea otro. Por

ejemplo, un televisor tiene una

encen

televis

televis
figura 1: Ejemplo de objetos pantalla, un dispositivo de
dido y apagado, un selector de canales, una antena, etc. Si este

or, no tuviera una antena y un selector de canales, no sería un

or, sería un monitor de computador, que es otro tipo de objeto.

6

El Paradigma de la orientación a objeto – Conceptos Básicos

Además de las propiedades, un objeto tiene un conjunto de servicios,

operaciones o métodos [20], que definen el comportamiento del objeto, y

actúan sobre sus atributos. Siguiendo el ejemplo del televisor, podríamos

identificar los siguientes métodos: Encender, Apagar, Cambiar Canal,

Sintonizar, Subir Volumen y Bajar Volumen.

Si realizamos una comparación entre la programación orientada a objetos y la

programación estructurada, podríamos decir que: en la programación

orientada a objeto los atributos del objeto son como las variables y las

estructuras de datos; mientras que los métodos de los objetos serían como

las funciones o procedimientos que manipulan las estructuras de datos. La

gran diferencia radica en que un objeto es una sola entidad compuesta por

atributos y métodos, en cambio en la programación estructurada, las

estructuras de datos y las funciones o procedimientos son cosas separadas.

Todo objeto tiene un estado, un comportamiento bien definido y una

identidad única [4]. Veamos qué significa cada concepto.

2.2.1.1 Estado

Las propiedades de los objetos suelen ser estáticas, es decir, no cambian en

el tiempo, aunque en algunos casos el objeto puede mutar y modificar su

conjunto de propiedades (evolución [2]).

Cada una de las propiedades de un objeto tiene algún valor y éste puede ser

una cantidad u otro objeto. El valor de un objeto es la parte dinámica de la

propiedad.

Las propiedades del objeto son los que definen su estado. Grady Booch da

la siguiente definición de estado: “El Estado de un objeto abarca todas las

propiedades (normalmente estáticas) del mismo más los valores actuales

(normalmente dinámicos) de cada una de estas propiedades” [4] página 98.

7


Entonces, el estado de un objeto depende de los valores actuales de sus

atributos.

2.2.1.2 Comportamiento y Mensajes

El comportamiento de un objeto, representa su actividad visible y

comprobable exteriormente, y él está definido en sus métodos.

Los objetos se comportan de una manera conocida, esto permite que ellos

interactúen entre sí, colaborando en pos de un objetivo. Esta interacción se

logra a través del paso de mensajes, donde un mensaje es un mandato o

solicitud que un objeto envía a otro indicándole que debe realizar una acción,

lo que gatilla la ejecución de un método. Cada mensaje está compuesto por:

destino, operación y parámetros [20], donde el destino es el objeto

receptor, la operación es el método solicitado y los parámetros son el

conjunto de datos necesarios para ejecutar el método. En la mayoría de los

lenguajes de programación orientados a objetos, un mensaje tiene la forma:

Destino.Operación(parámetro1, parámetro

2, ... , parámetro

n). Siguiendo

con el ejemplo del televisor, si tenemos un objeto llamado TV y quisiéramos

ver el canal 13, tendríamos que pasar los siguientes mensajes:

TV.encender() TV.cambiarCanal(13)

Consideremos que el método encender(), sirve para prender y apagar el

televisor, de esta manera, el comportamiento del objeto al invocar este

método dependerá del estado actual del objeto, es decir, si él está encendido,

entonces se apagará, y viceversa. Además, este método, cambiará el estado

actual de encendido a apagado y viceversa. Esto se produce porque el

comportamiento de un objeto altera el estado del mismo, y el estado actual

del objeto afecta su comportamiento.

Como resumen, veamos la siguiente definición de Grady Booch: “el

comportamiento es como actúa y reacciona un objeto, en término de sus

cambios de estados y paso de mensajes” [4] página 98.

8


2.2.1.3 Identidad

La identidad es la característica del objeto que lo hace ser único y lo

distingue del resto de los objetos. Es importante destacar que la identidad

de un objeto es independiente de los valores actuales de sus atributos, por

ejemplo si tenemos un objeto libro, y cambiamos el valor del ISBN, éste va a

tener la misma identidad.

En los lenguajes de programación orientados al objeto, los objetos se

identifican con nombres de variables o a través de su OID (Object Identifier,

identificador de objeto) generados por el sistema. Un nombre de variable es

asignado por el programador, y el sistema se encarga de asociar ese nombre

con el OID correspondiente. Utilizando los OID, los objetos pueden compartir

otros objetos y se pueden crear redes entre ellos [2].

La Identidad de un Objeto hace que tengamos dos nociones de igualdad [2]:

• Igualdad por identidad. Dos objetos son iguales si tienen el mismo

OID, es decir, son el mismo.

• Igualdad por valor. Dos objetos son iguales si los valores de sus

atributos son recursivamente iguales.

2.2.2 Abstracción y Clase.

La abstracción no sólo es utilizada en la orientación a objeto, ésta es una

capacidad humana que nos permite simplificar la realidad de manera que sea

más manejable. Ésta consiste en centrarnos en las características esenciales

de un objeto, descartando detalles que no son pertinentes en ese momento.

Una definición más formal sería : “Una abstracción denota las características

esenciales de un objeto que lo distinguen de todos los demás tipos de objetos

y proporciona así fronteras conceptuales nítidamente definidas respecto a la

perspectiva del observador.” [4] página 46.

En otras palabras, a través de una abstracción encontramos un conjunto de

atributos y métodos que son la esencia de un objeto, descartando los detalles

9


de su implementación por este momento. Los atributos y métodos

identificados dependerán del dominio de la aplicación a desarrollar

(perspectiva del observador).

La manera en que representamos las abstracciones es a través de clases.

Una clase es la especificación de los atributos y métodos que debe tener un

objeto para pertenecer a esa clase, es decir es una abstracción del objeto. Al

leer esta definición, da la impresión que los términos son sinónimos, pero no

lo son. En algunos casos una abstracción será representada por una sola

clase, pero en otros, se necesitarán varias clases. Por ejemplo consideremos

la abstracción de un automóvil, con los atributos de: numPasajeros,

propietario, numPuertas; y con los métodos: avanzar(), frenar(),

doblarIz(), doblarDer();

figura 2:Clase Automóvil

esta abstracción puede ser representada por una única clase como la

mostrada en la figura 2. Por otro lado, si tratáramos de representar la

abstracción Industria, con los atributos: Empleados, departamentos,

muebles y útiles, maquinarias; y con los métodos: Comprar(), vender(),

fabricar(), inventariar(), balance(); difícilmente podríamos representarlo a

través de una sola clase.

Al incorporar el concepto de clase a la definición de objeto podemos decir

que: un objeto es una ocurrencia concreta (o instancia) de una clase, con una

identidad única, donde todos los objetos que comparten un mismo conjunto

de atributos y métodos están agrupados en una misma clase.

10


2.2.3 Encapsulamiento

El encapsulamiento es uno de los pilares fundamentales en que se basa la

orientación a objeto, éste consiste en agrupar en una única entidad los

atributos y métodos de un objeto, ocultando los detalles de su

implementación. Para lograr esto, el objeto tiene dos partes, una pública o

visible denominada Interfaz y otra privada u oculta denominada

implementación. Al momento de definir la clase del objeto, se establece qué

atributos y métodos van a ser públicos, y cuáles privados. En el caso de los

métodos públicos, el algoritmo que utilizan para ejecutar el trabajo queda

oculto (forma parte de la implementación).

Con el concepto de encapsulamiento podemos decir que la abstracción de un

objeto corresponde a la interfaz de la clase encapsulada.

Cabe destacar que un encapsulamiento real se logra solamente cuando todos

sus atributos son privados, y la única forma de acceder a ellos, es a través de

métodos públicos [2]. Si un objeto permite que sus atributos sean públicos

pierde el control sobre los valores que le son asignados, no pudiendo realizar

la validación de los datos que se ingresan, pudiendo ser asignados valores

inválidos para esos atributos.

Un encapsulamiento real, hace que los métodos públicos sean como una

muralla que garantice la integridad y validez de los datos guardados por el

objeto en sus atributos. Además permite modificar la estructura interna del

objeto sin que estos cambios afecten a los que lo utilizan. Lo mismo pasa

con los algoritmos implementados por los métodos. Esto nos trae como

beneficio una facilidad de mantención, al minimizar los efectos colaterales

producidos por cambios en la implementación del objeto.

2.2.4 Modularidad

Como punto de partida tomaremos la definición de Booch que dice: “La

modularidad es la propiedad que tiene un sistema que ha sido descompuesto

en un conjunto de módulos cohesivos y débilmente acoplados.” [4] página 64.

11


Para entender esta definición debemos comprender el significado de módulo,

cohesión y acoplamiento desde la perspectiva de la orientación a objeto.

Un módulo es un conjunto de clases o abstracciones que han sido agrupadas

por guardar cierta relación lógica. El módulo pasa a ser un paquete que se

puede diseñar, programar y compilar separadamente, gracias al

encapsulamiento. Por lo general los módulos no son totalmente

independientes, en la mayoría de los casos existen conexiones entre

módulos.

La cohesión se refiere al grado de relación lógica con el que se han agrupado

las clases. Mientras más tengan en común las clases, en función del objetivo

que persiguen, mayor es la cohesión. Existen varios grados de cohesión,

siendo el más bajo la cohesión por coincidencia donde las clases son

agrupadas sin ninguna relación; y el más alto la cohesión funcional donde las

clases trabajan juntas para lograr un comportamiento bien delimitado [4].

El acoplamiento esta relacionado con el grado de dependencia que existen

entre un módulo y los demás. Lo que se busca es minimizar el acoplamiento,

para minimizar los efectos colaterales que pueda causar la modificación de

un módulo.

El Objetivo de la modularidad es hacer más manejable la programación a gran

escala, basándose en la estrategia “dividir para vencer”.

2.2.5 Jerarquía de Clases

Para modelar una determinada aplicación, no es suficiente definir todas las

clases que la componen, además de eso es necesario describir las relaciones

que existen entre ellas. Recordemos que todo sistema es un conjunto de

partes que interactúan entre sí.

Existen tres tipos básicos de relaciones entre clases [4]. La primera denota

una relación “Es un”, por ejemplo un automóvil es un medio de transporte. A

este tipo de relaciones se denomina herencia. La segunda denota una

12


relación “parte de” por ejemplo un motor es parte de un automóvil. A este

tipo de relación se denomina agregación. Y por último tenemos la

asociación, que denota una relación semántica entre clases que de otro

modo no existiría. Un ejemplo de esto es la relación que se produce entre

una persona y un automóvil, cuando decimos que una persona es propietaria

de uno o más automóviles, o una persona conduce un automóvil.

El concepto de Jerarquía de clases también es uno de los pilares de la

orientación a objeto.

2.2.5.1 Herencia

La herencia permite definir una clase (llamada subclase) tomando como base

la definición de otra (llamada superclase). La subclase hereda todos los

atributos y operaciones de la superclase, a lo que agrega sus propios

atributos y métodos [2]. Para construir este tipo de relaciones existen dos

procesos, uno llamado generalización y otro llamado especialización.

figura 3: Clases antes de la generalización

Por ejemplo, si hemos identificado las siguientes clases: automóvil, bicicleta,

camión (figura 3), podríamos extraer los atributos y operaciones que tienen

en común y con ellos generar una clase llamada medios_de_transporte

(figura 4) que pasaría a ser una superclase donde sus subclases automóvil,

bicicleta y camión tendrían sólo los atributos y métodos que no fueron

extraídos, puesto que ellos serán heredados de la superclase.

Pensemos ahora que solamente tenemos la clase medios_de_transporte,

podríamos decir que ella se divide en tres: medios de transporte Aéreos,

13


terrestres y marítimos. Estas tres últimas clases son una especialización de

medios de transporte.

figura 4: Clases después de la generalización.

La especialización es el proceso mediante el cual definimos una o más

subclases a partir de una superclase, en cambio en la generalización

definimos una superclase a partir de una o más subclases.

Todos los objetos que pertenecen a una subclase también lo son de su

superclase. Siguiendo el ejemplo anterior, podríamos decir, que un

automóvil XX y una Bicicleta YY, pertenecen a clases distintas, pero a la vez

tienen una clase en común que es Medios_de_transporte. Si en algún

momento esperamos un objeto de la clase medios de transporte, XX e YY

son perfectamente válidos. Esto no se limita a la superclase directa, también

es válido para las indirectas, es decir, para la superclase de la superclase, y

así sucesivamente.

Cabe mencionar que, existe un tipo de superclase de la cual no se instancian

objetos directamente, ellas reciben el nombre de superclase abstracta.

Dependiendo del número de superclases que posea una clase, podemos

definir dos tipos de herencia: Herencia simple y Herencia múltiple. La

14


herencia simple es aquella donde una subclase puede tener solamente una

superclase. En la herencia múltiple una subclase puede tener una o más

superclases.

La herencia trae los siguientes beneficios:

• Elimina redundancia innecesaria. Al definir los atributos y métodos

que son comunes a un grupo de objetos en una superclase se evita

que estos estén repetidos en sus subclases.

• Facilita la mantención. Al modificar una superclase se modifican

automáticamente las subclases.

• Facilita la localización de errores. Al construir una subclase basada

en una superclase libre de errores, cualquier error que aparezca en la

subclase va a ser producto de los métodos que esta introdujo.

• Reutilización. Al poder heredar métodos y atributos no tenemos que

definirlos nuevamente sólo reutilizarlos, lo que incrementa la

productividad.

Pero ninguno de estos beneficios serían significativos, si no existiera el

polimorfismo.

2.2.5.1.1 Polimorfismo

La idea de polimorfismo es: permitir que diferentes métodos tengan el

mismo nombre [20]. Éste concepto esta íntimamente ligado al de herencia

[2]. Pensemos en una superclase llamada figuras_geométricas, que

tenga como subclases a triangulo, cuadrado, circulo. Pensemos que

tenemos un arreglo de figuras geométricas y queramos dibujar cada una

de ellas. Una alternativa es la siguiente implementación (en pseudo

código):

Inicio Defina A[1..10] de figuras_geométricas Llenar el arreglo A con figuras_geométricas Para i = 1 hasta 10 haga En caso que A[i] sea triangulo entonces A[i].dibujarTriangulo cuadrado entonces A[i].dibujarCuadrado circulo entonces A[i].dibujarCirculo fin en caso que Fin Para

15


Fin Esto se puede simplificar enormemente. Podemos agregar un método

llamado Dibujar en la superclase Figuras_geométricas. De esta manera

todas las subclases tendrían este mismo método. Cada una de sus

subclases tiene un modo particular de dibujarse, esto se logra

redefiniendo la implementación del método. Esta redefinición también se

denomina suplantación o anulación (overriding) porque la definición

particular ocupa el lugar de la definición general (la suplanta) [2]. De esta

manera logramos tener un mismo nombre de método, pero diferentes

implementaciones de él.

De este modo el algoritmo antes presentado se reduce a :

Inicio Defina A[1..10] de figuras_geométricas Llenar el arreglo A con figuras_geométricas

Para i = 1 hasta 10 haga A[i].Dibujar() Fin

Esto trae como consecuencia un diseño más simple, una herencia más

efectiva, y en casos como el ejemplo anterior, menos líneas de código.

Para lograr esta nueva funcionalidad el sistema tiene que asociar la

invocación al método con el método correspondiente en tiempo de

ejecución. Esto se denomina ligadura tardía (late binding) [2].

Otra manera de lograr el polimorfismo es la sobrecarga de métodos. Esta

consiste en tener dos o más métodos con el mismo nombre pero con

distintos argumentos. En este caso no es necesario hacer una ligadura

tardía, se puede hacer de manera normal, es decir, en momento de

compilación (enlace más temprano).

2.2.5.2 Asociación

Las clases se asocian para poder interactuar entre sí. La asociación es un

enlace físico o conceptual que permite a un objeto ocupar los servicios

(métodos) de otro. Este enlace es bidireccional a menos que se especifique lo

contrario. Además este enlace posee una multiplicidad, por ejemplo:

• Uno a uno

16


• Cero a Muchos

• Uno a muchos

• Muchos a muchos.

Una asociación entre clases es similar al concepto de relación entre entidades

en un Diagrama Entidad-Relación [1].

2.2.5.3 Agregación y Composición

La agregación es una asociación que representa una relación Todo-Parte

donde un objeto es parte de otro [39]. Al todo se le denomina agregado y

sus partes pasan a ser atributos [4]. En la agregación, las partes, pueden

tener una existencia independiente a la del agregado, pudiendo formar parte

de varias clases, o de ninguna. Un ejemplo, es una comisión compuesta por

varias personas, donde algunas de ellas, no participarán en una comisión,

pero otras participarán en una o varias.

La composición es una forma más fuerte de agregación, donde las partes

sólo podrán pertenecer a un todo, y estás no existirán fuera del contexto del

agregado. La única forma de acceder a las partes será a través del todo [4].

Por ejemplo podemos definir una clase bicicleta como una composición de las

siguientes clases: rueda, pedal, manubrio, cadena, freno, asiento, marco.

Donde la clase rueda puede ser un agregado de rayos, eje, cámara,

neumático.

Mediante la agregación y la composición podemos definir objetos

arbitrariamente complejos.

2.2.6 Tipos (tipificación)

Los conceptos de clases y tipos son muy similares, puesto que una clase es la

implementación de un tipo, pero los tipos ponen énfasis en el significado de

una abstracción de manera diferente: “Los tipos son la puesta en vigor de la

clase de los objetos, de modo que los objetos de tipos distintos no pueden

17


intercambiarse o, como mucho, pueden intercambiarse sólo de formas muy

restringidas.” [4] página 74.

El objetivo de contar con tipos, es evitar que se mezclen abstracciones de

manera equivocada. Para lograrlo se debe realizar una comprobación de

tipos, durante el proceso de compilación, que puede ser estricta o débil.

Mediante la comprobación estricta de tipos se pueden detectar errores como:

referencias a atributos inexistentes, invocación de métodos inexistentes,

invocación de métodos con parámetros no válidos (Ej.: se espera un objeto

del tipo automóvil, pero se recibe una del tipo persona), y cualquier otro que

cause una incongruencia de tipos. En los lenguajes de comprobación débil

de tipos, es posible ignorar o suprimir las reglas sobre los tipos.

Existen lenguajes sin tipos como Smalltalk, donde los errores como

invocación de método inexistente solo son reconocidos en tiempo de

ejecución [4].

La ventaja de contar con un sistema que soporte la comprobación estricta es

la detección temprana de errores de incongruencia de tipos en forma

automática, puesto que un error de tipos en tiempo de ejecución no se

manifiesta hasta que esa línea de código es ejecutada y eventualmente

podríamos pasarla por alto en las pruebas de software.

2.2.7 Concurrencia

La concurrencia es transversal a varios paradigmas de la computación. Ésta

consiste en dividir un programa en dos o más procesos que se ejecutarán

simultáneamente, logrando así una mayor eficiencia [6].

Se pueden distinguir dos tipos de procesos: pesados y ligeros (hilos),

donde los procesos pesados consumen más recursos computacionales que

los ligeros. Estos procesos se pueden ejecutar en una sola CPU, utilizando

algún algoritmo de tiempo compartido, o en varias, logrando un proceso

verdaderamente concurrente (o paralelo) [4].

18


Un modelo objeto que incorpora la concurrencia, considera que cada objeto

puede ser representado por un proceso (o hilo) separado, pasando a ser un

objeto activo. Los objetos activos funcionan independientemente, pero

cooperando con el resto de los objetos, además, sincronizándose cuando sea

necesario. A partir de esto se puede definir la concurrencia como: “La

concurrencia es la propiedad que distingue un objeto activo de uno que no

está activo.” [4] página 83.

2.2.8 Persistencia

Cuando desarrollamos un software orientado a objeto y lo implementamos

con algún lenguaje de programación apropiado nos encontramos con la

siguiente pregunta ¿cómo puedo almacenar los objetos en memoria

secundaria?. Esto sucede porque los lenguajes de programación orientados a

objeto, en su mayoría, no permiten almacenar en forma directa un objeto o

una jerarquía de objetos en memoria secundaria, y solamente los crean,

manipulan y destruyen en memoria principal. Este es el problema de la

persistencia, es decir, permitir que un objeto (o una jerarquía completa) sea

almacenado en un soporte auxiliar no volátil, con el objetivo de ser usado

nuevamente por la aplicación que lo creó o por otra aplicación [21]. Es

impensable tener un software que cada vez que se inicie tenga que ingresar

todos sus datos, como por ejemplo, una lista de clientes y de productos.

2.2.8.1 Formas de solucionar el problema de la persistencia

Para solucionar el problema de la persistencia tenemos las siguientes

alternativas [21]:

• Archivos convencionales

• Bases de datos relacionales

• Bases de datos orientadas a objetos (puras y objeto- relacional).

2.2.8.1.1 Archivos convencionales

Los archivos convencionales son los archivos básicos que puede manejar

todo lenguaje de programación, estos no tienen ningún soporte directo

19


para los objetos, por lo tanto tenemos que crear nuestros propios

protocolos para almacenarlos. Un caso especial es el lenguaje Smalltalk el

que cuenta con protocolos para escribir y leer objetos en discos [4]. En

cualquiera de los dos casos, esta solución para la persistencia, es muy

limitada, y solo sería aconsejable para entornos monousuarios que no

necesiten manejar grandes cantidades de datos.

2.2.8.1.2 Bases de datos relacionales

Un Software de administración de bases de datos relacional (SABDR) es

nuestra segunda solución. Gracias a sus características (como

concurrencia, transacciones, réplica, backup, auditoría, etc.) podemos

implementar aplicaciones que necesiten mantener gran cantidad de

información y manejo de múltiples usuarios concurrentes.

En este caso también será necesario implementar la persistencia por

nosotros mismos lo que incrementa la complejidad y el tiempo de

desarrollo de nuestra aplicación y con ello, los costos.

Ambas soluciones no permiten que los objetos persistentes sean

independientes a la aplicación creada. Esto es necesario cuando varias

aplicaciones distintas tienen que utilizar los mismos objetos.

2.2.8.1.3 Bases de datos orientadas a objetos.

Hoy en día, existen en el mercado sistemas de bases de datos diseñadas

para almacenar objetos, si bien no son perfectas, nos brindan una serie de

características, que nos facilitan esta tarea (Ej.: O2, Object Store, Orión,

etc). Además tienen características propias de los SABD y logran que el

objeto persistente sea independiente de la aplicación. Esta independencia

se logra almacenando las jerarquías de clases, junto con los objetos, en la

base de datos.

En las tres soluciones existe un problema denominado falta de

correspondencia (impedance mismatch) [2], este se produce cuando

20


alguna característica del lenguaje orientado a objeto no está presente en

nuestra solución. La falta de correspondencia es completa en las dos

primeras soluciones y en la tercera, ésta es casi nula.

Dentro de esta línea existen dos tendencias importantes. Estas son las

bases de datos objeto relacional (SABDOR) y las bases de datos orientadas

a objetos puras (SABDOO). En el siguiente capítulo hablaremos con

detenimiento sobre ambas.

21

3 Bases de datos Orientadas a Objeto

3.1 Introducción

Los sistemas de Administración de bases de datos (SABD) nacen en los años

60, como solución a los problemas de manejo de archivos. Mario Piattini

explica la evolución de los SABD definiendo tres generaciones [13]. La

primera generación constituida por los sistemas jerárquicos (IMS, Total, etc.)

y en Red (IDMS, AIM, IDS, etc.); la segunda por los sistemas relacionales

(Oracle, DB2, Ingres, Informix, Sybase, etc.); y una tercera generación

representada por los SADB orientados a objetos (SABDOO), deductivos,

activos, multimedia, temporales, federadas, móviles y otros [40].

3.1.1 Bases de datos relacionales

La segunda generación ha sido motivo de investigación durante más de 20

años, consolidándose en el mercado. Los SABD relacionales tienen

fundamentos teóricos sólidos introducidos por Codd en 1970 [10]. Estos se

basan en una estructura de datos simple y uniforme llamada Relación.

Los SABD relacionales se caracterizan por [10]

• Persistencia. Esta característica es la esencia de las bases de datos,

guardar la información en memoria secundaria hasta que sea

explícitamente borrada.

• Existencia de un catálogo o diccionario de datos. Éste contiene

información sobre la estructura de las tablas (relaciones) y

restricciones sobre la manipulación de los datos.

• Abstracción de los datos. Los SABD ofrecen a los usuarios una

representación conceptual de los datos, ocultando los detalles de

almacenamiento.

• Independencia entre programas y datos. Gracias a esto los datos

pueden ser utilizados por distintos programas. Esto se logra

almacenando la estructura de los archivos en la base de datos

(catálogo).

23

Bases de Datos orientadas a objeto - Introducción

• Manejo de múltiples vistas de usuario. Las vistas permiten mostrar

a los usuarios solamente lo que necesitan o les es permitido “ver” de

la base de datos.

• Gestión de transacciones concurrentes. Esto permite que dos o

más usuarios utilicen los mismos datos simultáneamente, en forma

controlada.

• Lenguaje de consulta SQL. Es un lenguaje declarativo que permite

interrogar a la base de datos para buscar información. Se basan en el

estándar SQL.

3.1.2 Bases de datos orientadas a objeto

Los SABD orientados a objeto son la unión entre las características propias de

las bases de datos y del paradigma de la orientación a objeto. De esta

manera, las bases de datos no sólo almacenan información, sino que también

algoritmos. Éstas nacen para solucionar el problema de la persistencia en

forma eficiente (ver sección 2.2.6.1), requisito indispensable para

aplicaciones como: CASE (Ingeniería de software asistida por computador),

CAD/CAM (Diseño / fabricación asistidos por computador), SIG (Sistemas de

información geográficos), multimedia, gestión de redes [14]; donde los

sistemas relacionales han sido incapaces de satisfacer los requerimientos de

dichas aplicaciones.

Los SABDOO están creciendo rápidamente (sobre un 300% en 1995 [13]),

pero todavía representan un mínimo porcentaje respecto al total de los

sistemas instalados (5% del mercado mundial de bases de datos en 1997

[40]).

3.1.2.1 Nuevos requerimientos

Por la necesidad de almacenar objetos persistentes, las Bases de datos OO

deberán satisfacer un conjunto de requisitos que están estrechamente

ligados a los conceptos básicos del paradigma de la orientación a objeto.

Estos son:

24


• Definición de clases y extensión de los tipos de datos primitivos.

La definición de clases y su jerarquía debe formar parte del catálogo,

además es deseable que estas clases pasen a formar parte del sistema

de tipos del SABD.

• Lenguajes de programación computacionalmente completos. Los

SABD deben contar con leguajes de programación o interfaces con

lenguajes para implementar los métodos de los objetos.

• Objetos complejos1. Para poder implementar este tipo de objetos es

necesario contar con mecanismos que permitan tener atributos

multivaluados (como listas, conjuntos, arreglos, etc.), identificadores

únicos y referencias a otros objetos.

• Herencia, Encapsulamiento y Polimorfismo. Estos son pilares

fundamentales de la orientación a objeto, por lo que deben

considerarse.

• Manejar versiones de objetos y configuraciones. Cuando

cambiamos los valores de los atributos, estos son reemplazados por

los nuevos. En algunas aplicaciones es necesario conocer los valores

históricos que han asumido los objetos, esto se logra manejando

distintas versiones del objeto. Una configuración establece enlaces

entre una versión de un objeto compuesto y las correspondientes

versiones de sus objetos componentes.

• Evolución de esquemas y de instancias. Los cambios en este tipo

de sistemas son la regla más que una excepción. Para ello es

necesario proveer de mecanismos que permitan modificar la

definición de las clases y sus jerarquías (Evolución de esquemas),

además de soportar la migración de instancias entre clases.

• Transacciones de larga duración. Como los objetos y sus atributos

pueden ser bastante grandes (Ej.: un video en una base de datos

multimedia), las transacciones pueden ser bastante largas. Por eso se

deben reconsiderar los mecanismos de recuperación ante un fallo y el

control de la consistencia.

1 Objeto donde uno de sus atributos es otro objeto o un grupo de objetos.

25


• Mecanismos de autorización basados en la noción de objetos. En

los sistemas tradicionales, los mecanismos de autorización están

asociados a una relación o a una vista. Estos mecanismos no son del

todo adecuados para un modelo orientado a objeto, el que necesita

mecanismos asociados a la noción de objetos, considerando la

herencia, versiones, objetos compuestos, etc.

• Interactuar con sistemas existentes. Es necesario que estos nuevos

sistemas sean capaces de acceder y manipular datos en sistemas

existentes como bases de datos relacionales, debido al impacto que

tiene en una organización la migración de datos.

26

3.2 Estándares de SABDOO

En general, existen dos clases de normas, una de ellas llamada de Jure (por

ley) que corresponde a aquellos estándares publicados por organizaciones

dedicadas a ello y reconocidas internacionalmente (Ej.: ANSI, ISO, IEE); Y

otras llamadas de facto (de hecho) que corresponden a aquellos estándares

que realmente están en uso en el mercado sean estos o no, publicados por

una organización formal de estandarización.

Asociados a las bases de datos orientadas a objetos, existen dos estándares:

SQL:1999 y ODMG v2.0 [13], el primero “de Jure” (y de facto) y el segundo

“de facto”. Estos dos estándares siguen tendencias distintas, pero que están

convergiendo. Estas tendencias son:

• Extender los SABD relacionales para que soporten la orientación a

objetos (SQL:1999);

• confeccionar un SABDOO basado en un modelo de objetos “puro” que

no extienda sistemas relacionales (ODMG-93).

3.2.1 Las tendencias: SABD relacionales “Extendidos” vs. SABDOO “Puros”

Ambas tendencias tienen un manifiesto que recoge las características que

debe tener un SABDOO, según su punto de vista. El primero de ellos se

denomina “Manifiesto de los sistemas de bases de datos de tercera

generación”, propuesto por Carey et al. en 1991 [13] [14], y es el que

promueve extender los SABD relacionales. Este manifiesto presenta tres

principios que se desarrollan en trece preposiciones. El siguiente resumen

está sacado textualmente de [13]:

1. Principio: “además de los servicios tradicionales de gestión de datos, los

SABD de la tercera generación proporcionaran gestión de objetos y reglas

más ricos”

• Un SABD de tercera generación debe tener un rico sistema de tipos

27

Bases de Datos orientadas a objeto – Estándares de SABDOO

• La herencia es una buena idea

• Las funciones (incluyendo procedimientos y métodos) y el

encapsulamiento, son una buena idea.

• Se deberían asignar identificadores de objeto para los registros sólo si

no está disponible una clave primaria

• Las reglas se convertirán en una característica primordial de los

futuros sistemas.

2. Principio: “Los SABD de tercera generación deben subsumir a los SABD de

segunda generación”

• Un SABD de la tercera generación debe tener un lenguaje de acceso

declarativo y de alto nivel

• Deben existir dos formas de especificar las colecciones: por

enumeración de sus miembros o mediante un lenguaje de consultas

• Las vistas deben ser actualizables

• Los indicadores de resultado no deben aparecer en los datos

3. Principio: “los SABD de tercera generación deben ser abiertos a otros

subsistemas”

• Un SABD de la tercera generación debe ser accesible desde múltiples

lenguajes de alto nivel

• Se debe soportar la persistencia de las variables

• El SQL es una forma "intergaláctica" de expresión de datos

• Las consultas y sus respuestas deben ser el nivel más bajo de

comunicación entre un cliente y un servidor

Este manifiesto deja en claro la idea de extender los sistemas relacionales

actuales, manteniendo una compatibilidad hacia atrás. Este enfoque también

llamado "evolutivo" es el que han adoptado la mayoría de los fabricantes de

SABD relacionales (Oracle, Informix, Sybase, etc). A los SABDOO que siguen

este enfoque también se les denomina SABD objeto relacional (ORDBMS o

SABDOR), por combinar ambos paradigmas.

La segunda tendencia se plasma en el manifiesto denominado "Manifiesto de

los Sistemas de Bases de Datos Orientadas al Objeto", propuesto por

28


Atkinson en 1989 [13], es el que recoge el punto de vista de los SABDOO

“puros”. Mario Piattini resume este manifiesto de la siguiente manera [13]:

[En este manifiesto se recogen] trece "características obligatorias" o "reglas

de oro" que deben cumplir todos los SABDOO, y que afectan a:

• objetos complejos

• identidad del objeto

• encapsulamiento

• tipos y clases

• jerarquías de tipos o clases

• anulación, sobrecarga y vinculación (binding) dinámica

• completitud de cálculos

• extensibilidad

• persistencia

• gestión del almacenamiento secundario

• concurrencia

• recuperación

• facilidad de consulta "ad hoc"

Junto a cinco "características opcionales" que sería deseable que presentaran:

• herencia múltiple

• verificación e inferencia del tipo

• distribución

• transacciones de diseño

• versiones

Además exponen "opciones abiertas" a los fabricantes de los SABDOO, como

pueden ser:

1. paradigma de programación

2. sistema de representación

3. sistema de tipos

4. uniformidad

De este manifiesto se desprende que el paradigma de la orientación a objeto

debe ser soportado fuertemente, además no se mencionan los elementos del

modelo relacional, ni tampoco una compatibilidad con los estándares

actuales de bases de datos relacionales. Por esto podríamos decir que este

29


enfoque pretende crear un SABDOO puro, porque no mezcla orientación a

objeto con los conceptos relacionales.

Independiente del enfoque que adopten los SABDOO, el que “gane la batalla”,

será aquel que: brinde el soporte más completo al paradigma de la

orientación a objeto, sea compatible con las bases de datos relacionales, sea

un SABD de alto rendimiento y logre una integración transparente entre el

lenguaje de programación y la base de datos. En este momento, no existe

un producto que reúna todas estas características, pero siguen trabajando en

ello.

3.2.2 Estándar SQL:1999

El estándar SQL:1999 sigue el enfoque “evolutivo”, puesto que es la última

versión aprobada del estándar SQL. Éste estándar incorpora varias

características del paradigma de la orientación a objeto al enfoque relacional,

pero no se limita a eso, puesto que incorpora otras características (véase el

siguiente capítulo) y reestructura completamente la documentación del

estándar, en vistas a una progresión más rápida en el futuro [8].

Durante su desarrollo se conoció como SQL 3, y a partir de los borradores de

trabajo del estándar, se desarrollaron varios ORDBMS entre ellos: Oracle 8 de

Oracle, Universal Server de Informix, DB2 Universal Database de IBM,

Cloudscape de Cloudscape, entre otros. En el capítulo 5 se analizará el

ORDBMS Oracle 8i.

3.2.2.1 Origen y evolución

SQL nace a partir de SEQUEL, un lenguaje de consulta de bases de datos

relacionales desarrollado por IBM en 1976-77 [10]. En 1979 aparece el

primer SABDR comercial basado en SQL, Oracle. Luego de este, aparecieron

muchos otros SABDR basados en SQL como: DB2, Interbase, Sybase, etc; y

otros, que no lo tenían como lenguaje base, empiezan a ofrecer interfaces

SQL. De esta manera, el SQL pasa a ser un estándar de facto [15].

30


El primer estándar de Jure de SQL es el SQL/ANS (SQL-86), aprobado en 1986,

por ANSI, al año siguiente fue aprobado por ISO. En 1989 se publica una

nueva versión del estándar que incorpora una integridad referencial básica.

En 1992 se aprueba la siguiente versión de SQL, llamada SQL-92. En esta

versión, se incrementa sustancialmente la capacidad semántica del esquema

relacional, añadiendo nuevos operadores, mejorando el tratamiento de

errores incorporando normas para el SQL embebido. Dos partes adicionales

se desarrollan también en 1992 el SQL/CLI y el SQL/PSM [8]. La última

versión del estándar, fue aprobada por ANSI e ISO en 1999, llamándose

SQL:1999 (No se llamó SQL-99 para no sufrir el problema del 2000), en este

mismo año ISO aprueba el SQL/Multimedia.

3.2.2.2 Partes que lo componen

El estándar está dividido en cinco documentos o partes:

Número de Documento Nombre del documento

1. ANSI/ISO/IEC 9075-1-1999

Informatión Technology – Database

Languages – SQL – part 1: Framework

(SQL/Framework)

2. ANSI/ISO/IEC 9075-2-1999

Information Technology – Database

Languages – SQL – part 2: Foundation

(SQL/ Foundation)

3. ANSI/ISO/IEC 9075-3-1999


Languages – SQL – part 3: Call-level

Interface (SQL/CLI)

4. ANSI/ISO/IEC 9075-4-1999


Languages – SQL – part4: Persistent

Stored Modules (SQL / P SM)

5. ANSI/ISO/IEC 9075-5-1999


Languages – SQL – part 5: Host Language

Bindings (SQL/Binding)

Cada una de las partes puede ser adquirida por separado en

http://web.ansi.org.

31


3.2.3 Estándar ODMG 2.0

El estándar ODMG 2.0, es al que se acogen las empresas de SABDOO “Puros”,

y a diferencia de SQL:1999, es un estándar de facto, cuya primera versión

apareció hace siete años.

3.2.3.1 Origen y evolución

En verano de 1991, se reunió un grupo de expertos que trabajaban en

distintas empresas de SABDOO, para elaborar un estándar de facto, basado

en las características que presentaban los productos existentes y que se

pudiera publicar en un corto plazo. Así nació el ODMG (Object Data

Management Group) que actualmente agrupa a los principales vendedores de

SABDOO [13]: Object Design, Ontos, O2 Technology, Versant, Objectivity,

POET Software y Servio Corporation; y que cuenta también con diversos

revisores tanto de empresas (Andersen, Hewlett-Packard, EDS, Sybase, Texas

Instruments o Persistence), como de universidades: Maier, Dewitt, Carey,

Dittrich, Zdonik, Liskov, King, etc. En 1993 ODMG publica la primera versión

de este estándar, el ODMG-93, una versión mejorada de este es publicada en

1995, el ODMG-93 v 1.2, en 1997 el ODMG 2.0 y la última versión publicada

de este estándar es ODMG 3.0, publicada en el año 2000.

3.2.3.2 Partes que lo componen

Este estándar se divide en las siguientes partes [19]:

• Modelo de Objetos. Este está basado en el aprobado por el OMG

(Object Management Group) y extendido con los conceptos propios de

las bases de datos.

• Lenguaje de Definición de Objetos. Se utiliza para describir la

interfaz de los objetos. Su sigla es ODL (Object Definition Language)

y está basado en IDL (Interface Definition Language) de CORBA

(Common Object Request Broker Architecture).

• Lenguaje de Consulta de Objetos. Este lenguaje es similar a SQL,

pero no es compatible con él. Sus siglas originales son OQL (Object

Query Language).

32


• Vinculación con el lenguaje C++

• Vinculación con el lenguaje Smalltalk

• Vinculación con Java

Para la vinculación con los lenguajes de programación este estándar ha

procurado que el programador piense que utiliza un solo lenguaje. Esto lo

logra integrando el lenguaje anfitrión con el lenguaje de manipulación de

datos en forma natural y consistente [13].

Cabe destacar, que algunos SABDOO dan soporte a características que no son

consideradas en el modelo objeto relacional, como la herencia múltiple (Ej.:

IRIS, O2) y el manejo de versiones y configuraciones (Ej.: Orion). Puede ver

un estudio comparativo, sobre las características de un grupo representativo

de bases de datos orientadas a objeto en [2].

33

4 La Orientación a Objeto en SQL:1999

4.1 Introducción

En el capítulo anterior, explicamos la historia que hay detrás de SQL:1999,

además de las partes que lo componen y dónde conseguirlo. Aquí

profundizaremos más en el tema, partiendo por las organizaciones

internacionales dedicadas a la estandarización de SQL:1999, las mejoras que

introduce con respecto a su antecesor, y se evaluará el soporte que da a la

Orientación a objeto, basándonos en el capítulo 2 y la sección 3.1.2.1.

4.1.1 Organizaciones preocupadas de la estandarización de SQL

El primero en publicar un estándar para SQL (SQL-86) fue el instituto

estadounidense para la estandarización ANSI (American National Standards

Institute), y desde entonces ha sido un actor fundamental dentro del proceso

de estandarización de SQL. Dentro de su esquema de trabajo, ANSI, no

desarrolla las normas por si mismo, más bien acredita a otras organizaciones

para que desarrollen los estándares bajo su auspicio y sus reglas [7] [8].

ANSI ha publicado varias normas referentes a tecnologías de la información a

través de varios acreditados diferentes (SDO -Standards Developing

Organization), incluyendo a IEEE y un grupo llamado NISO (National

Information Standards Organization). La mayoría de los estándares asociados

con las tecnologías de la información publicadas por ANSI fueron

desarrollados por un grupo, conocido anteriormente con el nombre de X3

(entre 1961 – 1996) y ahora denominado NCITS (National Committee for

Information Technology Standards). Este grupo crea comités técnicos que

son los que realmente hacen el trabajo. Uno de estos comités es el H2

(anteriormente conocido como X3H2 y ahora como NCITS H2) que es el

encargado de desarrollar una serie de estándares asociados a las bases de

datos entre ellos RDA (Acceso a bases de datos remotas), SQL y SQL/MM.

En el ámbito internacional, el principal cuerpo de desarrollo de estándares es

ISO (International Standards Organization) y es quien tiene el rol oficial de

desarrollo de normas internacionales. Este, al igual que ANSI, coopera con

35

La Orientación a Objeto en SQL:1999 - Introducción

otras organizaciones, siendo una de ellas IEC (International Electro technical

Comision). Del esfuerzo conjunto entre ISO e IEC nace el JTC1 (Joint

Technical Committee 1) cuya misión es desarrollar y mantener estándares

relacionados a tecnologías de la Información. El JTC1 crea subcomités (SCs)

para distintas áreas de las tecnologías de la información. Hasta más o menos

1997 el SC21 era el responsable de SQL, pero luego de su disolución, esta

responsabilidad fue asignada a un nuevo comité llamado SC32. Este

Subcomité se encarga de los estándares asociados a las bases de datos y a

los meta datos (RDO, SQL, SQL/MM, etc). Para esto crea, a su vez grupos de

trabajo (Working Group), entre ellos destacamos el WG3 que es el encargado

del estándar SQL y el WG4 que se encarga del SQL/MM. En total son 28

países los que integran el JTC1 y sus respectivos subcomités y grupos de

trabajo. Alguno de estos miembros y sus institutos de estandarización son :

Canadá (SCC), Australia (SAA), Brasil (ABNT), China (CSBTS), Francia (AFNOR),

Alemania (DIN), Italia (UNI), Japón (JISC), Reino Unido (BSI), Estados Unidos

(ANSI).

Para más información sobre estas organizaciones y los procesos actuales de

estandarización visite los siguientes sitios web:

• American National Standards Institute (ANSI)

o http://www.ansi.org

• National Committee for Information Technology Standards (NCITS)

o http://www.ncits.org

• NCITS H2

o http://www.ncits.org/tc_home/h2.htm

• International Organization for Standardization (ISO)

o http://www.iso.ch

• International Electro technical Commission (IEC)

o http://www.iec.ch/

• Joint Technical Committee 1(JTC1)

o http://www.jtc1.org/

36

http://www.ansi.org/

http://www.ncits.org/

http://www.ncits.org/tc_home/h2.htm

http://www.iso.ch/

http://www.iec.ch/

http://www.jtc1.org/


4.1.2 Nuevas características.

Las nuevas características del estándar SQL:1999, se pueden dividir en

“Características Relacionales” y “Características Orientadas a Objeto”. En esta

sección nos limitaremos a describir las “Características relacionales y en la

sección 4.2, explicaremos las referentes a la orientación a objeto.

4.1.2.1 Nuevos Tipos de Datos

SQL:1999 tienen cuatro nuevo tipos de datos. El primero de estos tipos es el

LARGE OBJET, o LOB. Este tipo tiene las siguientes variantes: CHARACTER

LARGE OBJECT (CLOB) y BINARY LARGE OBJECT (BLOB).

Otro nuevo tipo de datos es BOOLEAN que le permite a SQL grabar

directamente los valores de verdad: verdadero (true), falso (false), y

desconocido (Unknown) [25].

SQL:1999 también incorpora dos tipos compuestos: ARRAY y ROW [8] [25]. El

tipo ARRAY nos permite guardar colecciones de valores directamente en una

columna de una tabla de la base de datos. Por ejemplo:

DIAS_DE_LA_SEMANA VARCHAR(10) ARRAY[7]

El tipo ROW en SQL:1999 es una secuencia de una o más parejas (<Nombre

Campo>,<Tipo de datos>) llamados campos (fields) [25] que permite

almacenar valores estructurados en simples columnas de la base de datos.

Por ejemplo:

CREATE TABLE employee ( EMP_ID INTEGER, NAME ROW (GIVEN VARCHAR(30), FAMILY VARCHAR(30)),

SALARY REAL ) SELECT E.NAME.FAMILY FROM employee E

SQL:1999 agrega además otro tipos de datos llamados “tipos distintos”, que

son tipos de datos definidos por el usuario (UDT en adelante) que se basan

en tipos primitivos o en otros tipos distintos[25]. Por ejemplo:

37


CREATE TYPE SHOW_SIZE AS INTEGER(3) FINAL CREATE TYPE IQ AS INTEGER(3) FINAL ... WHERE MY_SHOE_SIZE > MY_IQ // ERROR

En este ejemplo, la última expresión arrojaría un error de sintaxis, puesto que

MY_SHOE_SIZE y MY_IQ son de distinto tipo.

4.1.2.2 nuevos predicados

En SQL:1999 existen dos nuevos predicados que no se relacionan con la

orientación a objeto, el predicado SIMILAR y el predicado DISTINCT [8].

El predicado SIMILAR es utilizado para definir expresiones regulares para la

búsquedas de patrones como lo hacen los programas UNIX. Por ejemplo:

WHERE NAME SIMILAR TO ' (SQL-(86|89|92|99)) | (SQL(1|2|3)) '

En este ejemplo se emparejarían varios nombres dados al estándar SQL

durante los años. [8].

El otro predicado nuevo, DISTINCT, es muy similar en operación al predicado

ordinario UNIQUE de SQL; Dos valores nulos no son distintos (DISTINCT), si

únicos (UNIQUE) [14].

4.1.2.3 semántica reforzada

SQL:1999 ha aumentado significativamente el alcance de vistas que pueden

actualizarse directamente, facilitando así su utilización .

Una limitación de SQL ha sido su incapacidad para ejecutar recursión [8] [24],

pero esto ha sido solucionado en SQL:1999 proporcionando una

característica llamada Recursive Query. Definir una consulta recursiva

involucra escribir la expresión de consulta que usted quiere recurrente,

entonces usa ese nombre en una expresión de consulta asociada. Por

Ejemplo

38


WITH RECURSIVE Q1 AS SELECT...FROM...WHERE..., Q2 AS SELECT...FROM...WHERE... SELECT...FROM Q1, Q2 WHERE...

Otra funcionalidad incorporada es la noción de savepoints. Ellos permiten, a

una aplicación, deshacer las acciones realizadas después del principio de un

savepoint sin deshacer todas las acciones de una transacción entera[8].

SQL:1999 permite ROLLBACK TO SAVEPOINT y RELEASE SAVEPOINT [26].

4.1.2.4 seguridad adicional

La nueva característica de seguridad de SQL:1999 se encuentra en su

capacidad de creación de roles (o papeles) [8]. Pueden concederse privilegios

a los papeles y estos pueden ser identificadores de autorización individual o

conceder privilegios de autorización a otros papeles. Por ejemplo [14]:

CREATE ROLE Administrador CREATE ROLE Jefe_Supremo GRANT Administrador TO Miguel GRANT Administrador TO Jefe_Supremo

4.1.2.5 bases de datos activa

SQL:1999 reconocen la noción de base de datos activa, aunque algunos años

después que los SABD lo hicieran. Esta facilidad es proporcionada a través de

una característica conocida como disparador (trigger). Un disparador es una

facilidad que les permite a los diseñadores de la base de datos instruir al

sistema para ejecutar ciertos procedimientos cada vez que una aplicación

realice operaciones específicas en tablas particulares [8] [26].

Por ejemplo, podrían usarse disparadores para anotar todas las operaciones

que cambian sueldos en una tabla empleado [8]:

CREATE TRIGGER log_salupdate BEFORE UPDATE OF salary ON employees REFERENCING OLD ROW as oldrow NEW ROW as newrow FOR EACH ROW INSERT INTO log_table VALUES (CURRENT_USER, oldrow.salary, newrow.salary)

39

4.2 Soporte a la Orientación a objeto

Para analizar el soporte de la orientación a objeto en SQL:1999, nos

basaremos en los conceptos básicos de la orientación a objetos (ver 2) y en

los requerimientos para bases de datos orientadas a objetos (ver 3.1.2.1 ).

Por motivos didácticos el orden de los conceptos será diferente. La sintaxis

de SQL:1999 relacionada con la orientación a objeto, se encuentra en el

apéndice A.

4.2.1 Tipos, abstracción y clases

El estándar unifica estos conceptos bajo el nombre de tipo estructurado, que

es otro tipo de UDT. Un tipo estructurado encapsula atributos y métodos en

una única entidad lógica, pero físicamente separados. Los atributos de un

objeto persistente los almacenaremos en una tabla, y los métodos, junto con

los demás procedimientos almacenados. Cabe destacar que esta separación

será transparente para el usuario.

Este nuevo tipo, pasará a ser uno más del sistema, pudiendo ser utilizado del

mismo modo que un tipo primitivo.

4.2.1.1 Creación de tipos (CREATE TYPE)

Para crear un tipo estructurado se utiliza el predicado CREATE TYPE [26],

donde especificamos una lista de atributos, y opcionalmente, una lista de

métodos (ver A.2.1).

Por ejemplo, consideremos un tipo Punto, con los atributo: X, Y; y con los

métodos: moverA(x,y), distanciaA(p), crear(x,y); su implementación sería:

CREATE TYPE punto AS ( X INTEGER , Y INTEGER )INSTANTIABLE NOT FINAL METHOD moverA(x INTEGER, y INTEGER), METHOD distanciaA(p Punto) RETURNS FLOAT, STATIC METHOD crear(x INTEGER, y INTEGER) RETURNS punto

40

La Orientación a Objeto en SQL:1999 – Soporte a la Orientación a objeto

La cláusula INSTANTIBLE, permite crear instancias del tipo directamente. Si

queremos prohibir esto (para implementar clases abstractas), indicamos NOT

INSTANTIABLE. Esta cláusula es opcional (ver A.2.1), cuyo valor por defecto

es INSTANTIABLE.

La cláusula NOT FINAL, permite que el tipo sea utilizado como supertipo de

otro (ver 4.2.6.3 Herencia y polimorfismo). Esta cláusula no es opcional.

Todo tipo estructurado tiene asociado un correspondiente tipo de

referencia. Este tipo almacena una secuencia de bytes, que indica el lugar

donde está almacenado un objeto de ese tipo. El número de bytes es

dependiente de la implementación del estándar.

Un tipo de referencia puede ser utilizado en los mismos lugares que un tipo

estructurado. Para definirlos utilizamos la palabra reservada REF, seguida

por el nombre del tipo entre paréntesis. Por ejemplo, consideremos un tipo

linea_recta, definido de la siguiente manera:

CREATE TYPE linea_recta AS (

a REF(punto), b REF(punto)

)INSTANTIABLE NOT FINAL

con este tipo de datos, podemos crear redes de objetos. Por ejemplo,

podemos crear una lista enlazada, un árbol binario, etc.

Al definir un tipo estructurado, podemos indicar la manera en que el sistema

construirá sus referencias. Para eso, debemos escoger entre tres formas de

representación, definidas por la cláusula opcional <reference type

specification> (ver A.2.1), que es indicada a continuación de la cláusula

<finality>. Las formas de representación son:

• USER GENERATED, la referencia se basa en un tipo primitivo, cuyo valor

será proporcionado por el usuario.

La sintaxis es: REF USING <predefined type>. Ejemplo:

CREATE TYPE persona AS (

Rut CHAR(12) , Nombre CHAR(40)

)INSTANTIABLE NOT FINAL REF USING INTEGER

41


• SYSTEM GENERATED, la referencia es generada automáticamente por

el sistema. Este es el valor por defecto.

La sintaxis es: REF IS SYSTEM GENERATED Ejemplo:



)INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED

• DERIVED, La referencia se basa en uno o más atributos. Es semejante

a una clave primaria.

La sintaxis es: REF FROM <list of attributes> Ejemplo:



)INSTANTIABLE NOT FINAL REF FROM (Rut)

Una limitación importante de los tipos de referencia, es que sólo pueden

almacenar direcciones de objetos persistentes.

4.2.1.2 Atributos

Un tipo estructurado puede tener uno o más atributos, cada uno con un

nombre, un tipo de datos, y opcionalmente, un valor por defecto (con

DEFAULT) [26]. No podemos definir dos atributos del mismo nombre, para

un mismo tipo estructurado. El tipo de datos del atributo, puede ser

cualquiera de SQL, incluyendo un UDT [14]. Por ejemplo, si quisiéramos crear

un tipo Direccion con los atributos calle, numero, ciudad y region, sería.

CREATE TYPE Direccion AS ( calle CHAR(40), numero CHAR(10), ciudad CHAR(30), region CHAR(30) )NOT FINAL

Ahora, podemos crear un tipo empleado con un atributo del tipo Dirección

de la siguiente manera:

CREATE TYPE empleado AS ( rut CHAR(12), nombre CHAR(40),

42


sueldoBase INTEGER , anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, jefe REF(empleado), domicilio direccion )INSTANTIABLE NOT FINAL

Para acceder al atributo de una instancia, lo hacemos de la misma manera

que en JAVA, a excepción de los atributos del tipo REF(...). Por ejemplo, para

acceder al atributo rut, de un empleado e, sería: e.rut, y esto en cualquier

nivel de anidamiento, por ejemplo: e.domicilio.numero.

Para acceder a los atributos cuyo tipo de datos sea REF(...), existe el operador

->. Por ejemplo, si queremos saber el nombre del jefe del empleado, sería:

e.jefe->nombre

No podemos asignar una visibilidad (Ej.: public, private, protected) a los

atributos (característica que estuvo presente en el borrador de trabajo del

año 1997). A pesar de esto, el acceso a los atributos de un tipo no es

directo. Para cada atributo, el sistema genera dos funciones, una

observadora y otra mutadora [26]. Por ejemplo, si decimos p.rut, lo que

sucede en realidad es que estamos invocando a la función observadora

rut(p). Si realizamos una asignación como p.rut:=’13.131.344-6’,

estamos invocando implícitamente a la función mutadora

rut(p,’13.131.344-6’). Lamentablemente, las funciones observadoras y

mutadoras, no pueden ser sobrecargadas [14].

A diferencia de Java, los atributos estáticos no son soportados.

4.2.1.3 Métodos

A contar del SQL-92, se introduce la noción de procedimiento almacenado,

que corresponde a funciones o procedimientos definidos por el usuario, que

pueden ser utilizados en sentencias SQL. SQL:1999 incorpora una tercera

categoría de procedimiento almacenado, los métodos [8]. Un método, al

igual que una función, posee un nombre, una lista de argumentos (que puede

estar vacía) y un valor de retorno (opcional). La gran diferencia radica en que

un método, está asociado a un UDT estructurado en particular, y no puede

ser invocado Independientemente.

43


Al definir los métodos en la creación del UDT estructurado, sólo declaramos

su interfaz (función prototipo o encabezado). Para definir su implementación

o cuerpo, utilizamos la sentencia CREATE METHOD (ver A.2.4). El código

que implementa al método, puede ser escrito en SQL (usando las sentencias

computacionalmente completas del SQL/PSM [47]) o en cualquiera de los

lenguajes de programación más tradicionales, incluyendo JAVA [14].

Los métodos pueden ser: métodos de instancia, métodos constructores o

métodos estáticos.

4.2.1.3.1 Métodos de Instancia

Los métodos de instancia, son aquellos que serán invocados a partir de un

objeto concreto. Para definirlos anteponenemos las palabras reservadas

INSTANCE METHOD o simplemente METHOD, seguido por el nombre, la

lista de parámetros (que puede estar vacía) y opcionalmente el tipo del

valor de retorno. Cada elemento de la lista de parámetros está compuesto

por: Modo, nombre y tipo de datos; donde el modo es la manera en la que

se pasa el parámetro, que puede ser IN (entrada), OUT (salida), INOUT(

entrada y salida). Los métodos de instancia, pueden ser sobrecargados.

Por ejemplo, consideremos un tipo triángulo, definido por los tres

vértices que lo componen, y con tres métodos, uno que calcule su área, y

dos para calcular la distancia de un punto al lado más cercano del

triángulo.

CREATE TYPE triangulo AS ( A punto , B punto , C punto )INSTANTIABLE NOT FINAL METHOD Area() RETURNS FLOAT, INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT INSTANCE METHOD distanciaA(x FLOAT,y FLOAT) RETURNS FLOAT

La Invocación de un método de instancia, se realiza de la misma forma que

accedemos a un atributo. Por ejemplo, si quisiéramos saber el área de un

triángulo t, sería:

...t.Area()

44


Si t fuera una referencia a un triangulo, la invocación al método area()

sería:

...t->Area()

Los métodos de instancia incluyen, implícitamente un parámetro, cuyo

nombre es SELF, y representa al objeto de la invocación.

Opcionalmente podemos especificar otras características del método (ver

<method characteristic> en A.2.1), las cuales se indican a continuación del

encabezado. La primera de ellas (<language clause>) indica el lenguaje en

el que se programará el método. Si omitimos esta cláusula, el lenguaje

por defecto, es SQL. Por ejemplo, si el método área del tipo triangulo,

mostrado anteriormente, lo quisiéramos programar en pascal, tendríamos

que especificar:

... METHOD Area() RETURNS FLOAT LANGUAGE PASCAL ...

La cláusula <parameter style clause> indica cómo debemos pasar los

parámetros. Puede tomar dos valores posibles:

• PARAMETER STYLE SQL. Los parámetros son pasados al estilo de

SQL. Para las rutinas externas que utilicen este estilo, es necesario

agregar algunos parámetros para el control de los valores nulos,

valores de retorno y otros parámetros de control. En general, se

necesitan 2n+4 parámetros para los procedimientos y 2n+6 para las

funciones, donde n es el número de parámetros del método.

• PARAMETER STYLE GENERAL. Cada parámetro del método,

corresponde efectivamente a un parámetro en la implementación.

Para las rutinas externas, es la manera más fácil de pasar parámetros,

porque coinciden uno a uno. El problema existe con los valores nulos,

que no son soportados, es decir, no podemos invocar al método con

parámetros cuyos valores actuales, sean nulo.

Cuando esta cláusula es omitida, se asume PARAMETER STYLE SQL como

valor. Ejemplo:

45


... METHOD Area() RETURNS FLOAT LANGUAGE PASCAL PARAMETER STYLE GENERAL ...

La cláusula <deterministic characteristic> indica si el método es

determinista o no. Un método es determinista, si en cada llamada con los

mismos parámetros entrega el mismo resultado, por ejemplo,

...Math.sqrt(9). Es difícil que un método de instancia sea determinista,

puesto que el estado actual del objeto, afecta su comportamiento, este

comportamiento es más propio de los métodos estáticos. El valor por

defecto de esta cláusla es NOT DETERMINISTIC.

... METHOD Area() RETURNS FLOAT LANGUAGE PASCAL PARAMETER STYLE GENERAL NOT DETERMINISTIC ...

La cláusula <SQL-data access indication>, indica si el método manipula o

no datos y sentencias de SQL. Los valores posibles son: NO SQL,

CONTAINS SQL, READS SQL DATA, MODIFIES SQL DATA. Ejemplo:

... METHOD Area() RETURNS FLOAT LANGUAGE PASCAL PARAMETER STYLE GENERAL NOT DETERMINISTIC NOT SQL ...

Los métodos que modifican datos de SQL (cláusula MODIFIES SQL DATA)

no son permitidos en:

• Constraint

• Assertions

• Sentencia CASE

• Before Triggers

• Cláusula de búsqueda en sentencias DELETE

• Cláusula de búsqueda en sentencias UPDATE (aunque es permitido

dentro de la cláusula SET)

• Expresiones de consulta distintas a constructores de tablas.

46


La cláusula <null-call clause>, indica la forma de proceder, si todos los

parámetros pasados al momento de la llamada son nulos. Para este caso

existen dos alternativas, retornar NULL sin llamar al método (RETURNS

NULL ON NULL INPUT) o llamar al método (CALLED ON NULL INPUT). El

valor por defecto es CALLED ON NULL INPUT. Ejemplo:

... INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT RETURNS NULL ON NULL INPUT ...

4.2.1.3.2 Métodos estático

Los métodos estáticos, son aquellos que serán invocados a partir de un

tipo estructurado y no de un objeto. Para definirlos se anteponen las

palabras reservadas STATIC METHOD seguido del nombre, la lista de

parámetros (que puede estar vacía) y opcionalmente el tipo del valor de

retorno. Un método estático, no posee el parámetro implícito self, porque

son invocados a partir de un tipo y no de un objeto. Por esta razón, no

podemos acceder a los atributos del tipo, desde un método estático.

Al igual que en un método de instancia, los métodos estáticos pueden ser

sobrecargados.

Por ejemplo, consideremos el mismo tipo triángulo mostrado

anteriormente, agregándole un método estático que permita crear un

triángulo a partir de tres puntos:

CREATE TYPE triangulo AS ( A punto , B punto , C punto )INSTANTIABLE NOT FINAL METHOD Area() RETURNS FLOAT, INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT STATIC METHOD crear(a Punto, b Punto, c Punto) RETURNS triangulo

Para invocar al método crear se utiliza:

...triangulo::crear(a,b,c)

considerando que a,b,c son instancias del tipo Punto previamente

definidas.

47


Al igual que en los métodos de instancia, podemos especificar las

características opcionales descritas en <method characteristic> en A.2.1.

4.2.1.3.3 Constructores

Cuando creamos un tipo estructurado con la cláusula INSTANTIABLE, el

sistema define un método constructor por defecto [25]. Este método, es

una función cuyo nombre coincide con el del tipo estructurado, no posee

argumentos, y el valor de retorno es una instancia del tipo al que

pertenece, donde el valor de cada atributo corresponde al valor por

defecto, especificado al momento de su creación. Por ejemplo, para el

tipo persona, el constructor por defecto es persona( ).

El estándar SQL:1999, no permite los constructores definidos por el

usuario, pero el borrador de trabajo de la futura versión del estándar

(SQL:200n), ya lo incorpora.

Existe un operador llamado NEW que nos permite invocar a un método de

instancia que haga las veces de constructor. El método debe tener el

mismo nombre que su tipo estructurado, y puede ser sobrecargado. Por

ejemplo, consideremos el siguiente tipo persona:


rut CHAR(12), nombre CHAR(40), )INSTANTIABLE NOT FINAL METHOD persona(r CHAR(12),n CHAR(40)) RETURNS persona

Si queremos construir un objeto del tipo persona utilizando el operador

NEW sería:

...new persona(’13.131.344-6’,’Miguel Romero Vásquez’) El operador NEW suple la limitación de constructores definidos por el

usuario.

4.2.1.3.4 Creación de métodos (CREATE METHOD)

Para cada método definido en el tipo estructurado, es necesario definir su

código o enlazarlo con un programa externo. Para esto utilizamos la

48


sentencia CREATE METHOD (ver A.2.4). Por ejemplo, consideremos la

siguiente implementación de un número complejo:

CREATE TYPE complex AS ( rpart REAL DEFAULT 0, ipart REAL DEFAULT 0 )INSTANTIABLE FINAL METHOD suma(x complex) RETURNS complex, METHOD resta(x complex) RETURNS complex, METHOD mult(x complex) RETURNS complex, METHOD div(x complex) RETURNS complex;

Un numero complejo consta de dos partes una real (atributo rpart) y otra

imaginaria (atributo ipart), ambas dentro del rango de los números reales.

Además existen una serie de operaciones matemáticas que se pueden

aplicar a dichos números (métodos suma, resta, mult y div).

Para crear los método del tipo utilizando SQL/PSM, sería:

CREATE METHOD suma(x complex) RETURNS complex FOR complex BEGIN DECLARE co complex; SET co = complex(); SET co.rpart = self.rpart + x.rpart; SET co.ipart = self.ipart + x.ipart;

RETURN co; END; CREATE METHOD resta(x complex) RETURNS complex FOR complex BEGIN DECLARE co complex; SET co = complex(); SET co.rpart = self.rpart - x.rpart; SET co.ipart = self.ipart - x.ipart; RETURN co; END; CREATE METHOD mult(x complex) RETURNS complex FOR complex BEGIN DECLARE co complex; SET co = complex(); SET co.rpart = rpart * x.rpart – ipart * x.ipart; SET co.ipart = rpart * x.ipart + ipart * x.rpart; RETURN co; END; CREATE METHOD div(x complex) RETURNS complex FOR complex BEGIN DECLARE z REAL; DECLARE co complex; SET z = x.rpart * x.rpart + x.ipart * x.ipart;

SET co = complex(); SET co.rpart = (rpart * x.rpart + ipart * x.ipart)/z; SET co.ipart = (ipart * x.rpart - rpart * x.ipart)/z;

49


RETURN co; END;

Como puede observar, la sintaxis es bastante sencilla. Parte con las

palabras reservadas CREATE METHOD, seguida por el nombre del

método, la lista de argumentos y opcionalmente la cláusula RETURNS

junto al tipo del valor de retorno. La palabra reservada FOR nos permite

indicar el tipo al que pertenece el método, en este caso complex. A este

encabezado le sigue el cuerpo del método, que puede ser escrito en SQL

(como en el ejemplo anterior) o en un lenguaje externo (C, Fortran, Ada,

etc). Para aquellos métodos que son implementados en un lenguaje

externo, es necesario indicar <external routine name>,<parameter style

clause>,<external security clause> (ver A.2.4). Por ejemplo: Consideremos

el mismo tipo complex, con el método suma externo. Lo primero sería

indicar el lenguaje en el que está programado al momento de definir el

tipo:

CREATE TYPE complex AS ( rpart REAL DEFAULT 0, ipart REAL DEFAULT 0 )INSTANTIABLE FINAL METHOD suma(x complex) RETURNS complex, LANGUAGE C METHOD resta(x complex) RETURNS complex, METHOD mult(x complex) RETURNS complex, METHOD div(x complex) RETURNS complex;

Luego, al implementar el método, indicar el nombre externo, y

opcionalmente, el estilo del paso de parámetros y la cláusula de

seguridad :

CREATE METHOD suma(x complex) RETURNS complex FOR complex EXTERNAL NAME ‘/routines/suma’ PARAMETER STYLE GENERAL EXTERNAL SECURITY INVOKER

Para poder invocar un método, el usuario debe tener el privilegio EXECUTE

sobre el método (otorgado con la cláusula GRANT).

La cláusula de seguridad indica al sistema qué privilegios considerar para

permitir o negar la ejecución del método, como también, cada una de sus

sentencias. Puede asumir tres valores posibles [46]:

50


• EXTERNAL SECURITY DEFINER. Considerar los privilegios del

usuario que definió el método.

• EXTERNAL SECURITY INVOKER. Considerar los privilegios del

usuario que invoca al método.

• EXTERNAL SECURITY IMPLEMENTATION DEFINED. Permite que la

implementación decida qué privilegios utiliza, si los del usuario que

definió el método o del que lo invoca. Este valor es asumido cuando

se omite la cláusula de seguridad.

Los métodos externos tienen varias ventajas frente a los métodos

implementados con SQL [46]:

• Permiten utilizar funciones que ya teníamos, o incorporar bibliotecas

de funciones de otros lenguajes como Java, Pascal, C, Fortran,

extendiendo las capacidades de SQL, sin la necesidad de programarlas

en SQL.

• Las rutinas externas son más portables (por ejemplo rutinas escritas

en C o Java).

• Las rutinas externas, permiten aprovechar las características y

capacidades de un amplio conjunto de lenguajes. Por ejemplo:

concurrencia, funciones matemáticas y estadísticas avanzadas,

comunicación entre procesos, envío de correo electrónico, manejo de

censores, etc.

• Las rutinas externas permiten invocar las mismas funciones que

utiliza el resto de nuestra aplicación, desde la base de datos.

• Las rutinas externas permiten definir la cláusula EXTERNAL

SECURITY.

Pero tienen las siguientes desventajas que deben ser consideradas [46]:

• Mover datos entre la rutina externa y el código SQL requiere un

esfuerzo adicional de programación y a veces problemas, por la falta

de correspondencia entre los tipos de datos. Por ejemplo el tipo Real

de SQL soporta valores nulos, pero el tipo Real de C, no.

• Para las rutinas externas que contienen código SQL, es necesaria la

creación de nuevas sesiones de SQL, lo que puede ser bastante

costoso.

51


• El tiempo de desarrollo puede incrementarse al tener que utilizar

lenguajes externos, por el esfuerzo adicional de entrenamiento y

depuración frente a los métodos desarrollados bajo SQL/PSM.

4.2.1.4 Modificación de tipos (ALTER TYPE)

Con el predicado ALTER TYPE (ver A.2.3 <alter type statement>) podemos

agregar o eliminar atributos y métodos a un tipo estructurado. Para

ejemplificarlo utilizaremos el siguiente tipo:

CREATE TYPE empleado AS ( rut CHAR(12), nombre CHAR(40), sueldoBase INTEGER , anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, domicilio direccion )INSTANTIABLE NOT FINAL

4.2.1.4.1 Agregar un atributo

Si queremos agregar el atributo email al tipo empleado, sería:

ALTER TYPE empleado ADD ATTRIBUTE email CHAR(50)

No podremos agregar el atributo email si existe una o más columnas en

alguna tabla relacional cuyo tipo de datos sea:

• Empleado.

• Un arreglo de cualquier supertipo o subtipo de empleado.

• Cualquier supertipo o subtipo de T, siendo T un tipo que posee

uno o más atributos que referencian a un empleado.

• Un arreglo de cualquier supertipo o subtipo de T, siendo T un tipo

que posee uno o más atributos que referencian a un empleado.

Tampoco podremos agregar un atributo, si existe alguna tabla de objetos

(ver 4.2.5.1 ) cuyo tipo base sea un subtipo (directo o no) de empleado.

La definición de un atributo con ALTER TYPE utiliza la misma sintaxis que

en CREATE TYPE.

52


4.2.1.4.2 Eliminar un atributo Si queremos eliminar el atributo domicilio del tipo empleado sería:

ALTER TYPE empleado DROP ATTRIBUTE domicilio RESTRICT En los siguientes casos, no podremos eliminar el atributo domicilio:

• Si es el único que posee el tipo empleado.

• Si es un atributo heredado.

• Si existe una o más columnas en alguna tabla relacional cuyo tipo

de datos sea:

o Empleado.

o Un arreglo de cualquier supertipo o subtipo de empleado,

sea directo o no.

o Cualquier supertipo o subtipo de T, sea directo o no.

Siendo T un tipo que posee uno o más atributos que

referencian a un empleado.

o Un arreglo de cualquier supertipo o subtipo de T, sea

directo o no. Siendo T un tipo que posee uno o más

atributos que referencian a un empleado.

• Si existe alguna typed table (ver 4.2.5.1 ) cuyo tipo base sea un

subtipo (directo o no) de empleado.

• Si es utilizado directa o indirectamente en:

o El cuerpo de un método, una función o un procedimiento,

o un trigger,

o la expresión booleana de una constraint o una assertion

o la expresión de consulta que define una vista.

• Si es utilizado en una función de conversión definida por el usuario

(ver 4.2.1.7 )

4.2.1.4.3 Agregar un método

Si queremos agregar el método SueldoLiquido() al tipo empleado, sería:

ALTER TYPE empleado ADD METHOD SueldoLiquido() RETURNS INTEGER

53


Para especificar el nuevo método, utilizamos la misma sintaxis que en

CREATE TYPE.

4.2.1.4.4 Eliminar un método

Consideremos el siguiente tipo:

CREATE TYPE triangulo AS ( A punto , B punto , C punto )INSTANTIABLE NOT FINAL METHOD Area() RETURNS FLOAT, INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT INSTANCE METHOD distanciaA(x FLOAT,y FLOAT) RETURNS FLOAT

Si queremos eliminar el método distanciaA del tipo triangulo sería:

ALTER TYPE triangulo DROP METHOD distanciaA(Punto) FOR triangulo RESTRICT

Para indicar el método a eliminar, tenemos que indicar su nombre y

opcionalmente, los tipos de datos de los parámetros, separados por coma

y entre paréntesis, seguido de eso, la palabra reservada FOR y el nombre

del tipo al que pertenece. Esto último, es obligatorio cuando tenemos

sobrecargado el método.

4.2.1.5 Eliminación de tipos (DROP TYPE)

Mediante la sentencia DROP TYPE, podemos eliminar un tipo estructurado.

Por ejemplo, si queremos eliminar el tipo punto, decimos:

DROP TYPE punto CASCADE

La cláusula CASCADE, indica que se deben borrar todas las dependencias

que existan con este tipo. Alternativamente a CASCADE, existe la cláusula

RESTRICT, que impide el borrado del tipo si existen dependencias. Por

ejemplo:

DROP TYPE punto RESTRICT

54


4.2.1.6 Comparación de instancias

Inicialmente, no podemos comparar dos instancias de un tipo estructurado

(ej: A>B) . Para lograr esto, es necesario que el usuario defina una función

que los compare y luego asociarla al tipo estructurado correspondiente. Para

esto existe la sentencia CREATE ORDERING (ver A.2.8).

Existen dos categorías de comparación:

• EQUALS ONLY. Sólo se permiten comparaciones de igualdad (=) y

desigualdad (<>).

• ORDER FULL. Todas las comparaciones son permitidas (>,<,=,<>)

Además, podemos escoger entre tres categorías de funciones de

comparación:

• STATE. La función de comparación es creada por el sistema. Dicha

función tiene dos parámetros (las instancias a comparar) y retorna un

Boolean. La función compara ambas instancias, atributo por atributo.

Si coinciden los valores de todos los atributos entre las instancias,

retorna true si no, false.

• RELATIVE. El usuario debe especificar la función de comparación, la

cual debe contar con dos parámetros (las instancias a comparar) y

cuyo valor de retorno sea del tipo Integer. La función debe retornar 0

si ambas instancias son iguales, un valor positivo si la primera

instancia es mayor que la segunda, y un valor negativo si es menor.

• MAP. El usuario debe especificar la función de comparación, la cual

debe contar con un sólo parámetro y debe retornar un tipo de dato

primitivo. La función no se encarga de comparar las instancias, sólo

indica la posición que tomaría la instancia pasada por parámetro, si

ordenáramos el universo completo de las instancias. El sistema utiliza

el valor devuelto para realizar la comparación.

Al momento de definir una función de comparación debemos considerar lo

siguiente:

• STATE sólo puede ser utilizado con EQUALS ONLY.

55


• dentro de una jerarquía de tipos, STATE y RELATIVE deben ser

especificados para el supertipo máximo (aquel que no tiene padre).

• MAP puede ser especificado para más de un tipo, dentro de una

jerarquía de tipos, pero todos ellos deben utilizar MAP, es decir, no

podemos definir unos tipos con MAP y otros con STATE o RELATIVE.

Para ejemplificarlo, utilizaremos el mismo tipo empleado utilizado

anteriormente:

CREATE TYPE empleado AS ( rut CHAR(12), nombre CHAR(40), sueldoBase INTEGER , anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, domicilio direccion )INSTANTIABLE NOT FINAL

Si queremos definir una función de comparación del tipo STATE sería:

CREATE ORDERING FOR empleado EQUALS ONLY BY STATE

Con ella podremos hacer comparaciones de igualdad y desigualdad. Si lo que

queremos es permitir todas las comparaciones, debemos utilizar ORDER

FULL y definir una función del tipo RELATIVE o MAP. Por ejemplo:

CREATE ORDERING FOR empleado ORDER FULL BY RELATIVE WITH FUNCTION empleado_relative(empleado,empleado) CREATE ORDERING FOR empleado ORDER FULL BY MAP WITH FUNCTION empleado_map(empleado)

Una implementación válida de la función empleado_relative sería:

CREATE FUNCTION empleado_relative(a empleado, b empleado) RETURNS INTEGER BEGIN DECLARE comp INTEGER; IF a.sueldoBase = b.sueldoBase THEN SET comp = 0; ELSE

IF a.sueldoBase > b.sueldoBase THEN SET comp = 1;

ELSE SET comp = - 1; END IF; END IF;

RETURN comp; END

56


Una implementación válida de la función empleado_map sería:

CREATE FUNCTION empleado_map(a empleado) RETURNS INTEGER BEGIN RETURN a.sueldoBase; END

Las funciones del tipo MAP y RELATIVE, también pueden ser usadas con

EQUALS ONLY. Por ejemplo:

CREATE ORDERING FOR empleado EQUALS ONLY BY RELATIVE WITH FUNCTION empleado_relative(empleado,empleado) CREATE ORDERING FOR empleado EQUALS ONLY BY MAP WITH FUNCTION empleado_map(empleado)

Para entender mejor cómo trabajan estas funciones, consideremos la

comparación “E1 = E2” siendo E1 y E2 instancias del tipo empleado.

Internamente esta expresión será sustituida por otra, basada en la función de

comparación correspondiente. Tenemos tres casos posibles:

• Si la función es del tipo STATE, la expresión se sustituye por:

o “SF(E1,E2)=TRUE”, siendo SF(...) la función definida por el

sistema.

• Si la función es del tipo MAP, se sustituye por:

o “empleado_map(E1) = empleado_map(E2)”

• Si la función es del tipo RELATIVE, se sustituye por:

o “empleado_relative(E1,E2) = 0”

4.2.1.6.1 Eliminación de funciones de comparación

Para eliminar la función de comparación de un tipo, utilizamos la sentencia

DROP ORDERING (ver A.2.9). Por ejemplo, para eliminarla del tipo

empleado sería:

DROP ORDERING FOR empleado RESTRICT No podremos eliminar la función de comparación, si existe algún

predicado que compare instancias del tipo empleado en:

• métodos , Funciones o procedimientos

• Vistas

• Constraint

57


• Assertion

• Trigger

4.2.1.7 Conversión de UDT (CAST definidos por el usuario)

SQL siempre ha sido un lenguaje fuertemente tipado. Esto significa que no

podemos mezclar tipos arbitrariamente en expresiones de comparación o en

asignaciones, sino que debemos hacer una conversión explícita de tipos con

la sentencia CAST. Para los tipos primitivos (ej.: INTEGER, BOLEAN, CHAR,

etc), existen funciones CAST predefinidas. Por ejemplo, si queremos asignar

un valor INTEGER a una variable SMALLINT dentro de una función sería:

... DECLARE a INTEGER, b SMALLINT; SET b = CAST (a AS SMALLINT); ...

Para los tipos definidos por el usuario, no existen funciones CAST por

defecto. Para solucionar esto, SQL-1999 permite al usuario definir funciones

CAST para sus tipos con la sentencia CREATE CAST (ver A.2.6). Por ejemplo,

consideremos que tenemos dos tipos estructurados, uno llamado T1 y otro

T2, y queremos implementar un CAST para convertir valores de T1 a T2.

Lo primero que tenemos que hacer, es crear una función con un único

parámetro del tipo T1, cuyo valor de retorno sea del tipo T2, es decir:

CREATE FUNCTION conver(a T1) RETURNS T2 BEGIN ... RETURN ... END;

Y luego definimos el CAST de la siguiente manera:

CREATE CAST(T1 AS T2) WITH FUNCTION convert(T1) AS ASSIGNMENT

La cláusula AS ASSIGNMENT es opcional, y permite que la función de

conversión sea llamada implícitamente en las asignaciones. Por ejemplo:

... DECLARE a T1, b T2; SET b = a; ...

Si omitimos esta cláusula, tendremos que llamar explícitamente al CAST en

las asignaciones. Por ejemplo:

...

58


DECLARE a T1, b T2; SET b = CAST (a AS T2); ...

4.2.1.7.1 Eliminación de CAST definidos por el usuario

Para eliminar un CAST definido por el usuario existe la sentencia DROP

CAST ( ver A.2.7). Por ejemplo:

DROP CAST (T1 AS T2) RESTRICT

No podremos eliminar el CAST definido por el usuario, si es utilizado en:

• métodos , Funciones o procedimientos

• Vistas

• Constraint

• Assertion

• Trigger

4.2.2 Colecciones

Una colección es una estructura que permite almacenar cero o más

elementos de distinto o del mismo tipo de datos [26]. El término colección es

genérico, y comprende varios tipos de colecciones como: arreglos, conjuntos,

árboles, etc. El estándar SQL:1999 solamente soporta los arreglos.

4.2.2.1 Arreglos

Un arreglo (array) es un conjunto de elementos del mismo tipo, donde cada

elemento está en una posición determinada [31]. Al definir un arreglo, se

especifica la cantidad máxima de elementos que puede tener (m en adelante).

Las posiciones del arreglo comienzan a partir de 1 (uno), hasta n, siendo n el

número de elementos que contiene el arreglo, que debe estar en el rango

1≤n≤m.

Un arreglo, es un tipo de datos, que lo utilizamos de igual modo que un tipo

primitivo. Por ejemplo, podemos crear un tipo polígono, que contenga un

arreglo para sus vértices (del tipo punto), y los métodos de area(), y

perímetro(), de la siguiente manera:

59


CREATE TYPE poligono ( vertices punto ARRAY [200] )INSTANTIABLE NOT FINAL METHOD Area() RETURN FLOAT, METHOD Perimetro() RETURN FLOAT

Si queremos acceder al segundo vértice del poligono p, se escribe:

...p.vertices[2].

Podemos asignar varios elementos en un arreglo, simultáneamente. Por

ejemplo, supongamos que hemos definido un arreglo notas, y quisiéramos

asignarle las calificaciones: 100, 80 y 45 de una sola vez, esto sería:

... set Notas = ARRAY[100,80,45]; ...

También existe un operador de concatenación (||), que nos permitirá construir

un nuevo arreglo, a partir de dos o más. Para el mismo ejemplo anterior,

pensemos que queremos agregar las notas al final del arreglo, esto sería:

... set Notas = Notas || ARRAY[100,80,45]; ...

Podemos definir un arreglo a partir de cualquier tipo de datos, sea primitivo o

no, siempre y cuando, no contenga o no sea un arreglo.

Dos arreglos (C y D) son iguales (C = D), si ambos tienen el mismo número

de elementos y C[i]=D[i], para i=1 hasta n


Como vimos en la sección 2.2.3, el encapsulamiento abarca tres aspectos:

• Agrupar atributos y métodos en una sola entidad.

• Distinguir entre interfaz(pública) e implementación (privada)

• Asignar niveles de acceso individual a los atributos y métodos.

El primer aspecto, es cubierto con el predicado CREATE TYPE. Esta es la

parte pública del método.

60


Con el predicado CREATE METHOD es cubierto el segundo punto. Gracias a

esta división (publica y privada) podemos realizar cambios a la

implementación de los métodos, sin que estos afecten a las aplicaciones que

los utilizan.

El tercer punto es cubierto medianamente por las funciones observadoras y

mutadoras (ver 4.2.1.2 ) definidas por el sistema, puesto que estas impiden

que los usuarios accedan a los atributos directamente. Lamentablemente, no

podemos sobrescribir dichas funciones.

Lo que falta para que el soporte al encapsulamiento sea completo, es la

posibilidad de definir niveles de acceso a los atributos y métodos, como

public, private y protected de Java.

Sin embargo, el modelo de seguridad de SQL-1999, permite obtener una

funcionalidad similar, pero no completa de lo anterior. Con respecto a los

métodos, sólo los usuarios que tenga el privilegio EXECUTE podrán ejecutar

un método, tanto para objetos persistentes como transitorios. Para otorgar

el privilegio EXECUTE utilizamos la sentencia GRANT. Por ejemplo:

GRANT EXECUTE ON METHOD sueldo_liquido() FOR empleado TO PUBLIC

Podemos ejecutar métodos dentro de sentencias SELECT. Para ello debemos

otorgar el permiso correspondiente. Por ejemplo:

GRANT SELECT (METHOD sueldo_liquido() FOR empleado) ON TABLE tbl_emp TO PUBLIC

Con respecto a los atributos, sólo podremos restringir el acceso a ellos sobre

objetos persistentes, para los objetos transitorios, todos sus atributos serán

públicos. Por defecto, un usuario no puede acceder a las filas de una tabla.

Existen distintas sentencias que manipulan una tabla, para cada una de ellas

existe un privilegio que debe ser otorgado. Por ejemplo:

GRANT SELECT (rut,nombre,sueldo) ON TABLE tbl_emp TO PUBLIC GRANT INSERT (rut,nombre,sueldo) ON TABLE tbl_emp TO PUBLIC GRANT UPDATE (rut,nombre) ON TABLE tbl_emp TO PUBLIC GRANT DELETE ON TABLE tbl_emp TO PUBLIC

61


También podemos restringir el acceso de los atributos, creando vistas sobre

las tablas.

4.2.4 Modularidad

SQL:1999 cuenta con la noción de módulos, pero estos sólo proveen

modularidad para las funciones y procedimientos almacenados, pero no para

tipos. Sin embargo, podemos agrupar tipos basándonos en los esquemas de

SQL, logrando así una funcionalidad similar.

4.2.5 Persistencia

Para hacer persistir los objetos tenemos dos alternativas:

• Almacenarlos como columnas en tablas relacionales

• Almacenarlos en una tabla especial denominada typed table, donde

cada fila es un objeto y cada columna un atributo del mismo.

En las siguientes secciones veremos el manejo de tablas que almacenen

objetos, tanto en columnas como en fila. Además de cómo trabajar con

dichas instancias.

4.2.5.1 Manejo de Tablas

El estándar incorpora varias características a las tablas relacionales. Además

de permitir almacenar objetos como columnas, define tres tipos especiales de

tablas: typed tables, subtablas y supertablas. En la presente sección,

describiremos como definir dichas tablas.

4.2.5.1.1 Creación (CREATE TABLE)

Como mencionamos anteriormente, podemos almacenar objetos como

columnas de tablas relacionales. Por ejemplo, Consideremos la siguiente

definición de un tipo direccion.

62


CREATE TYPE Direccion AS ( calle CHAR(40), numero CHAR(10), ciudad CHAR(30), region CHAR(30) )NOT FINAL

Ahora, podemos crear una tabla relacional con una columna del tipo

dirección. Como ejemplo, consideremos la definición de una tabla de

personas de la siguiente manera:

CREATE TABLE persona ( rut CHAR(12) PRIMARY KEY, nombre CHAR(40), fecha_nacim DATE, domicilio direccion )

Como podemos observar, es bastante sencillo definir columnas basadas

en tipos estructurados.

Los objetos almacenados como columnas no pueden ser referenciados por

no poseer un OID. Solamente los objetos almacenados en una typed table

pueden ser referenciados.

Una typed table, es una tabla o vista construida en base a un tipo

estructurado definido por el usuario. Para cada atributo del tipo base, es

creada una columna con el mismo nombre y el mismo tipo de datos.

Además de estas, se agrega otra, para almacenar el identificador de

objeto. Esta columna tiene las restricciones UNIQUE y NOT NULL

implícitas.

Para ejemplificarlo consideremos el tipo empleado utilizado en secciones

anteriores:

CREATE TYPE empleado AS ( rut CHAR(12), nombre CHAR(40),

sueldoBase INTEGER , anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE,

domicilio direccion )INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED METHOD SueldoLiquido() RETURNS INTEGER

63


Para crear una typed table llamada tbl_emp basada en el tipo empleado

sería:

CREATE TABLE tbl_emp OF empleado (REF IS oid SYSTEM GENERATED)

oid, es el nombre de la columna adicional que almacenará el identificador

de objeto. El nombre es puesto por el usuario y puede ser cualquier

identificador válido de columna. El tipo de datos de oid es

REF(empleado), este no puede ser asignado por el usuario.

Dependiendo de la forma que el tipo base de la tabla maneje las

referencias, (SYSTEM GENERATED, USER GENERATED y DERIVED) se

especificará:

• REF IS oid SYSTEM GENERATED

• REF IS oid USER GENERATED

• REF IS oid DERIVED

El valor que asumirá la columna oid, será asignado al insertar el objeto en

la tabla, y no podrá ser modificado posteriormente. Si especificamos

SYSTEM GENERATED o DERIVED, el valor de oid será definido

automáticamente al momento de la inserción. En cambio, si es USER

GENERATED, será entregado por el usuario.

Si queremos hacer persistir objetos que tengan un supertipo (ver 4.2.6.3 ),

tenemos la posibilidad de definir una estructura super tabla/subtabla.

Por ejemplo, consideremos el tipo vendedor que es un subtipo de

empleado definido de la siguiente manera:

CREATE TYPE vendedor UNDER empleado AS ( comision FLOAT, viatico INTEGER )INSTANTIABLE NOT FINAL OVERRIDING METHOD SueldoLiquido() RETURNS INTEGER

Ahora, podemos crear una subtabla de tbl_emp que almacene instancias

del tipo vendedor. Para ello escribimos:

CREATE TABLE tbl_vendedor OF vendedor UNDER tbl_emp

64


Para que esta sentencia sea válida, tbl_emp, debe ser una typed table

cuyo tipo de datos sea el supertipo directo de vendedor. Si observamos la

definición hecha de tbl_emp anteriormente, veremos que estas

condiciones se cumplen.

En las subtablas, no podemos especificar la cláusula <self-referencing

column specification>, esta es heredada de la supertabla. Las columnas

de la supertabla, no son heredadas físicamente en la subtabla, pero si

referenciadas.

Como toda instancia de un subtipo, lo es también de su supertipo, cada

objeto almacenado en una subtabla, también es almacenado en la

supertabla. Debido a esto, físicamente, los valores de los atributos

heredados de una instancia, serán almacenados en la supertabla y los

valores más específicos del tipo, serán almacenados en la subtabla. Como

es el mismo objeto almacenado en la supertabla y en la subtabla, poseerá

el mismo OID en ambas. Es por esto que la forma de manejar el OID debe

concordar en toda la Jerarquía de tablas.

Cuando necesitamos recuperar un objeto en particular, el sistema se

encarga de recopilar los valores desde las distintas tablas,

automáticamente.

La definición de estructuras jerárquicas de tablas, permite minimizar el

impacto al extender las aplicaciones.

Al definimos tablas relacionales, podemos especificar restricciones como

NOT NULL, CHECK, PRIMARY KEY, sobre ellas. En las typed tables,

estas restricciones también son permitidas, a excepción de PRIMARY KEY.

Por ejemplo, si queremos restringir el atributo comisión a valores entre 0 y

100, seria:

CREATE TABLE tbl_vendedor OF vendedor UNDER tbl_emp (CONSTRAINT com CHECK (comision BETWEEN 0 AND 100))

4.2.5.1.2 Modificación (ALTER TABLE)

65


Para modificar una tabla utilizamos el predicado ALTER TABLE (A.2.13).

Esta sentencia nos permite:

• Agregar y Eliminar columnas.

• Agregar y elimina cláusula DEFAULT.

• Agregar y eliminar cláusula SCOPE.

• Agregar y eliminar restricciones (CONSTRAINT).

Para la eliminación de elementos podemos especificar la cláusula

CASCADE, que indica al sistema que, además de eliminar el elemento,

elimine todas las dependencias existentes; o la cláusula RESTRIC, que

impide el borrado del elemento al haber dependencias.

Por ejemplo, si queremos eliminar la restricción com de la tabla

tbl_vendedor sería:

ALTER TABLE tbl_vendedor DROP CONSTRAINT com CASCADE

Existen limitaciones a la hora de utilizar esta sentencia. Estas son:

• No podremos agregar o eliminar columnas a una typed table

• No podremos agregar o eliminar las cláusulas DEFAULT o SCOPE a

una columna heredada en una subtabla.

• No podremos agregar o eliminar las cláusulas DEFAULT o SCOPE a

la columna que almacena el identificador de objeto.

4.2.5.1.3 Eliminación (DROP TABLE)

Para eliminar una tabla utilizamos el predicado DROP TABLE (ver A.2.14).

Cuando queremos eliminar una tabla, debemos indicarle al sistema qué

hacer con las dependencias que existan de ella, como pueden ser,

subtablas, triggers, vistas, etc. Para ello tenemos dos predicados:

• CASCADE, que indica que se borren todas las dependencias de la

tabla.

• RESTRICT, impide que se borre la tabla si existen dependencias.

La sintaxis es bastante sencilla. Por ejemplo, si queremos eliminar la tabla

tbl_emp, sería:

DROP TABLE tbl_emp CASCADE O bien:

DROP TABLE tbl_emp RESTRICT

66


4.2.5.2 Manejo de Instancias

Para manipular las instancias que fueron almacenadas en una tabla,

utilizamos las mismas sentencias del manejo de filas y columnas en tablas

relacionales.

Las operaciones sobre las instancias las podemos agrupar en: Inserción,

selección, eliminación y modificación de objetos. Estas operaciones serán

descritas en las secciones siguientes.

4.2.5.2.1 Inserción de objetos

Para insertar un objeto, tanto en tablas relacionales como en typed table

utilizamos la sentencia INSERT INTO (ver A.2.15). Veamos primero cómo

insertar un objeto como columna de una tabla relacional. Para ello,

consideremos las siguientes definiciones:

CREATE TYPE direccion AS ( calle CHAR(40), numero CHAR(10), ciudad CHAR(30) )NOT FINAL METHOD direccion(ca CHAR(40),nu CHAR(10),ciu CHAR(30)) RETURNS direccion CREATE TABLE persona ( rut CHAR(12) PRIMARY KEY, nombre CHAR(40), domicilio direccion )

La inserción de una fila en la tabla persona sería:

INSERT INTO persona VALUES(‘13131344-6’,’Miguel Romero’,

NEW direccion(‘Emmanuel, pasaje san Damián’, ’1661’,’Chillán’)

)

Mediante el operador NEW creamos un nuevo objeto del tipo direccion, el

cual será asignado a la columna domicilio de la tabla persona. También

podremos utilizar el constructor del tipo direccion, el que creará un objeto

con los valores por defecto. Esta inserción sería:

67


INSERT INTO persona VALUES(‘13131344-6’,’Miguel Romero’,direccion())

La sintaxis para insertar un objeto como fila es muy similar. Por ejemplo,

consideremos un tipo cliente y una tabla de clientes (tbl_cli), definidos de

la siguiente manera:

CREATE TYPE cliente AS ( rut CHAR(12), nombre CHAR(40),

domicilio direccion )INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED CREATE TABLE tbl_cli OF cliente (REF IS oid SYSTEM GENERATED)

Para insertar un cliente en esta tabla sería:

INSERT INTO tbl_cli VALUES(‘13131344-6’,’Miguel Romero’,

NEW direccion(‘Emmanuel, pasaje san Damián’, ’1661’,’Chillán’)

)

al insertar este objeto, automáticamente se genera el valor para la

columna OID, puesto que esta columna fue definida como SYSTEM

GENERATED.

Al momento de insertar, tenemos la posibilidad de sobrescribir el valor

que el sistema asigna automáticamente como OID. Por ejemplo

INSERT INTO tbl_cli (oid,rut,nombre,domicilio) OVERRIDING SYSTEM VALUE VALUES(145,‘13131344-6’,’Miguel Romero’,

NEW dirección(‘Emmanuel, pasaje san Damián’, ’1661’,’Chillán’)

)

Si al definir la tabla, especificamos que la columna es generada por el

usuario, obligatoriamente tendremos que entregar el valor para la columna

OID. Por ejemplo, consideremos la cláusula REF del tipo cliente como:

... REF USING NUMERIC(8)

y la definición de la tabla como:

CREATE TABLE tbl_cli OF cliente (REF IS oid USER GENERATED)

68


La inserción de un cliente sería:

INSERT INTO tbl_cli (oid,rut,nombre,domicilio) VALUES(13131344,‘13131344-6’,’Miguel Romero’,

NEW dirección(‘Emmanuel, pasaje san Damián’, ’1661’,’Chillán’)

)

Para insertar un objeto en una typed table, el tipo estructurado base de la

tabla, debe ser instanciable (INSTANTIABLE).

Cuando insertamos un objeto en una typed table que posea una

supertabla, automáticamente se insertará la fila correspondiente en la

supertabla, con los valores para los atributos heredados. Para ello, será

necesario que asignemos los valores tanto para los atributos heredados

como para los más específicos, dentro del predicado INSERT. Por

ejemplo, para insertar un vendedor en la tabla tbl_vendedor definida en la

sección 4.2.5.1.1 sería:

INSERT INTO tbl_vendedor (rut,nombre,SueldoBase, Anticipo, domicilio, comision, viatico) VALUES(’11.111.111-1’,’Luis Perez’,150000,10000,

direccion(),12,35000)

Si se excluyen valores para alguno de los atributos, estos asumirán el valor

por defecto. Eso es lo que pasa en el ejemplo anterior con el atributo

fecha_ing, que no fue especificado.

4.2.5.2.2 Selección de objetos (SELECT)

La sentencia SELECT, nos permite obtener uno o más objetos

almacenados en tablas, tanto relacionales como typed table. Por ejemplo,

consideremos la tabla de persona definida en la sección anterior (ver

4.2.5.2.1 ), supongamos que queremos obtener el nombre y el domicilio

de todas las personas que viven en Chillán, esto sería:

SELECT nombre, domicilio.calle, domicilio.numero FROM persona WHERE domicilio.ciudad=’Chillán’

Como puede observar, podemos utilizar el atributo de un objeto, de la

misma manera que las columnas de las tablas relacionales. Lo mismo

pasa con los métodos. Por ejemplo, consideremos la tabla tbl_emp

69


definida en la sección 4.2.5.1.1 donde el tipo base es empleado. Si

queremos obtener el RUT, el nombre y el sueldo líquido de todos los

empleados que tengan sueldos superiores a $250.000, sería:

SELECT e.rut,e.nombre,e.SueldoLiquido() FROM tbl_emp e WHERE e.SueldoLiquido() > 250000

Si aplicamos la sentencia SELECT sobre una typed table que posea

subtablas, la búsqueda de filas se extenderá a todas las subtablas que

posea. Por ejemplo, consideremos la tabla tbl_vendedor que es una

subtabla de tbl_emp y cuyo tipo base es vendedor (vea 4.2.5.1.1 ). Para

obtener a todos los empleados de la empresa, incluyendo a los

vendedores, sería:

SELECT e.rut,e.nombre,e.SueldoLiquido() FROM tbl_emp

Gracias al polimorfismo (ver 4.2.6.3 ), la ejecución del método

SueldoLiquido(), dependerá del tipo concreto del objeto ya sea empleado

o vendedor. Para el ejemplo anterior, esta característica es fundamental,

pues el cálculo del sueldo líquido de un vendedor, es diferente al de un

empleado.

Para excluir de la búsqueda a las subtablas de tbl_emp, utilizamos la

cláusula ONLY, de la siguiente manera:

SELECT * FROM ONLY(tbl_emp)

También podemos restringir la búsqueda a la tabla tbl_vendedor, de la

siguiente manera:

SELECT * FROM tbl_emp WHERE DEREF(oid) IS OF(tbl_vendedor)

Cuando tenemos un atributo o una columna que es una referencia a un

objeto, podemos acceder a los atributos y métodos del objeto al que

referencia, utilizando el operador ->. Por ejemplo, consideremos los

siguientes tipos y sus respectivas tablas:

CREATE TYPE punto AS ( X REAL, Y REAL

70


)INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT CREATE TABLE tbl_pto OF punto (REF IS oid SYSTEM GENERATED)

CREATE TYPE linea_recta AS ( A REF punto, B REF punto )INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED CREATE TABLE tbl_lineas OF linea_recta (REF IS oid SYSTEM GENERATED)

Si queremos obtener las coordenadas de los puntos A y B de todas las

líneas que tengan un largo mayor a 100, sería:

SELECT L.A->X, L.A->Y, L.B->X, L.B->Y FROM tbl_lineas L WHERE L.A->distanciaA(B) > 100

El uso de referencias simplifica el manejo de consultas, puesto que

disminuye la necesidad de utilizar JOIN.

4.2.5.2.3 Modificación de objetos

Para modificar uno o más objetos, utilizamos el predicado UPDATE (ver

A.2.16). Por ejemplo, consideremos la typed table tbl_emp definida en la

sección 4.2.5.1.1 donde el tipo base es empleado; si queremos aumentar

el sueldo en $25.000 a todos los empleados que tengan sueldos entre

$100.000 y $ 200.000, sería:

UPDATE tbl_emp SET SueldoBase = SueldoBase + 25000 WHERE SueldoBase BETWEEN 100000 AND 200000

Si aplicamos el predicado UPDATE sobre una supertabla, los cambios

también se aplicarán a todos los objetos de las subtablas que cumplan con

la condición definida en la cláusula WHERE Para evitar esto, utilizamos el

predicado ONLY de la siguiente manera:

UPDATE ONLY(tbl_emp) SET SueldoBase = SueldoBase + 25000 WHERE SueldoBase BETWEEN 100000 AND 200000

71


Al igual que en la sentencia SELECT, en UPDATE, podemos restringir las

tablas que serán utilizadas. Si en el ejemplo anterior, quisiéramos que

UPDATE sólo afectara a la tabla tbl_vendedor sería:

UPDATE tbl_emp SET SueldoBase = SueldoBase + 25000 WHERE DEREF(oid) IS OF(tbl_vendedor) AND SueldoBase BETWEEN 100000 AND 200000

Como toda fila de la tabla tbl_vendedor posee una fila correspondiente a

sus atributos heredados en la tabla tbl_emp, el sistema ajustará

automáticamente la fila correspondiente a la supertabla cuando utilicemos

el predicado UPDATE sobre la tabla tbl_vendedor. Por ejemplo:

UPDATE tbl_vendedor SET SueldoBase = SueldoBase + 25000 WHERE SueldoBase BETWEEN 100000 AND 200000

Si el tipo base de la tabla, posee un atributo que es un arreglo, podemos

actualizarlo de dos maneras. La primera, tomando los elementos

individualmente, por ejemplo, consideremos que el tipo base posee un

atributo llamado arr que es un arreglo de 5 enteros:

UPDATE tabla_de_arreglos SET arr[5] = 23, arr[2] = 12 WHERE arr[1]=0

Y la segunda, asignando un arreglo completo, por ejemplo:

UPDATE tabla_de_arreglos SET arr = ARRAY[12,34,56,78,90] WHERE arr[1]=0

4.2.5.2.4 Eliminación de objetos

Para eliminar uno o más objetos utilizamos el predicado DELETE (ver

A.2.17). Este predicado borrará todas las filas que cumplan con la

condición indicada por la cláusula WHERE, tanto en tablas relacionales

como en typed tables. Por ejemplo, consideremos la tabla tbl_cli definida

en la sección 4.2.5.2.1 Para eliminar a todos los clientes cuyo nombre

contenga el string ‘miguel’, sería:

DELETE FROM tbl_cli c WHERE c.nombre LIKE ’%miguel%’

72


Si ejecutamos la sentencia DELETE sobre una typed table que posea

subtablas, también se eliminarán todos los objetos que cumplan con la

condición en las subtablas. Por ejemplo, consideremos la tabla tbl_emp

definida en la sección 4.2.5.1.1 que posee una subtabla denominada

tbl_vendedor, si ejecutamos la sentencia:

DELETE FROM tbl_emp e WHERE e.sueldobase < 100 Eliminará a todos los empleados y vendedores que tengan sueldos inferior

a 100. Para limitar el borrado a la tabla tbl_emp, utilizamos la cláusula

ONLY. Ejemplo:

DELETE FROM ONLY(tbl_emp) e WHERE e.sueldobase < 100

Al igual que en UPDATE, podemos restringir las tablas que serán

utilizadas por DELETE. Si para el ejemplo anterior, queremos eliminar

solamente a los vendedores que cumplan con esa condición sería:

DELETE FROM tbl_emp e WHERE DEREF(oid) IS OF(tbl_vendedor) AND e.sueldobase < 100

Al eliminar directamente una fila de una subtabla, automáticamente se

eliminará la fila correspondiente en la supertabla. Por ejemplo:

DELETE FROM tbl_vendedor v WHERE v.sueldobase < 100

4.2.6 Jerarquía de Clases

4.2.6.1 Asociación

Como mencionamos en la sección 2.2.5.2 , el concepto de asociación es

similar al de relación en el modelo entidad relación. Por eso, podemos

utilizar las mismas estrategias para su implementación, pero con la ventaja

de la existencia de las referencias de objeto, que son más eficientes que el

manejo de clave foránea. Por ejemplo, consideremos la siguiente asociación:

Vendedor ClienteVende

1 *

73


Para implementarla, agregaremos un atributo en el tipo cliente que sea una

referencia al tipo vendedor. La implementación de los tipos quedaría:

CREATE TYPE vendedor AS ( rut CHAR(12), nombre CHAR(40), sueldo NUMBER,

comision NUMBER, domicilio direccion


CREATE TYPE cliente AS ( rut CHAR(12), nombre CHAR(40), telefono CHAR(20), domicilio dirección, vendedorAsignado REF(vendedor) )INSTANTIABLE NOT FINAL

Otra alternativa es agregar un atributo clientes al tipo vendedor, que sea un

arreglo de referencias a sus clientes. El único inconveniente es que debemos

definir un largo máximo al arreglo. Lo anterior sería:


comision NUMBER, domicilio direccion, clientes REF(cliente) ARR [100]


Si la multiplicidad de la asociación es uno a uno, cualquiera de los tipos

puede tener la referencia al otro.

Si la multiplicidad de la asociación es Muchos a muchos, o la asociación en si

misma tenga atributos, será necesario crear un tipo para implementarla. Por

ejemplo, supongamos que la asociación entre un vendedor y un cliente fuera:

Vendedor Cliente

Cartera_de_clientes

vende

* *

74


La implementación de estos tres tipos sería:


comision NUMBER, domicilio direccion


CREATE TYPE cliente AS ( rut CHAR(12), nombre CHAR(40), telefono CHAR(20), domicilio direccion )INSTANTIABLE NOT FINAL CREATE TYPE cartera_de_clientes AS ( vendedorAsignado REF(vendedor), cliente REF(cliente) )INSTANTIABLE NOT FINAL


La implementación de la agregación es muy similar a la asociación. Pero se

diferencia por existir una relación todo-parte, donde desde el todo queremos

acceder a sus partes. En la Agregación, el todo no contiene físicamente a las

partes, por esta razón, la implementación es a través de referencias de

objetos. Consideremos por ejemplo la relación de agregación entre una

carrera y sus asignaturas, donde una carrera puede tener muchas asignaturas

y una asignatura puede pertenecer a varias carreras. La implementación

sería:

CREATE TYPE carrera AS ( codigo CHAR(12), nombre CHAR(40),

Asignaturas REF(asignatura) ARR [100] )INSTANTIABLE NOT FINAL CREATE TYPE asignatura AS ( codigo CHAR(12), nombre CHAR(40), creditos NUMBER )INSTANTIABLE NOT FINAL

Si la agregación es uno a uno no necesitaremos un arreglo, bastará con una

referencia a la parte.

75


Como en la composición las partes pertenecen a un único agregado y se

destruyen junto con él, la mejor estrategia es implementarlo utilizando los

tipos directamente. Por ejemplo, consideremos la relación entre un círculo y

un punto, donde un círculo posee un único punto que es su centro. La

implementación sería:

CREATE TYPE circulo AS ( centro punto, radio NUMBER )INSTANTIABLE NOT FINAL

Si la multiplicidad de la composición es uno a muchos, la implementación es

por medio de un arreglo. Por ejemplo, consideremos la relación entre un

polígono irregular y los puntos (vértices) que lo componen. Esto sería:

CREATE TYPE circulo AS ( vertices punto ARR [100] )INSTANTIABLE NOT FINAL

4.2.6.3 Herencia y Polimorfismo

SQL:1999 permite la herencia simple de tipos, es decir, un tipo puede poseer

un único supertipo. La sintaxis es bastante sencilla (ver A.2.1), para

entenderla mejor, veamos el siguiente ejemplo. Consideremos un tipo

llamado figura_geométrica, con la siguiente definición:

CREATE TYPE figura_geometricas AS ( color_linea CHAR(10), Color_fondo CHAR(10) )NOT FINAL METHOD area() RETURNS REAL METHOD perimetro() RETURNS REAL

A partir de este tipo, podemos definir dos subtipo: triángulo y cuadrado, de

la siguiente manera:

CREATE TYPE punto AS ( X REAL, Y REAL )INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT CREATE TYPE triangulo UNDER figura_geometrica AS (

a punto,

76


b punto, c punto

) INSTANTIABLE NOT FINAL OVERRIDING METHOD area() RETURNS REAL OVERRIDING METHOD perimetro() RETURNS REAL

CREATE TYPE cuadrado UNDER figura_geometrica AS (

a punto, b punto, c punto, d punto

) INSTANTIABLE NOT FINAL OVERRIDING METHOD area() RETURNS REAL OVERRIDING METHOD perimetro() RETURNS REAL

Para indicar el nombre del supertipo, especificamos la cláusula UNDER,

seguido del nombre del supertipo correspondiente. Un tipo, no puede ser

supertipo de si mismo. Tampoco podemos definir como supertipo a un

subtipo del mismo, sea directo o no.

Una característica esencial de la herencia es que los atributos y métodos del

supertipo pasan a formar parte del subtipo. Por lo anterior, no podemos

definir el nombre de un atributo igual a otro que se haya heredado. Con

respecto a los métodos, estos pueden ser redefinidos en el subtipo. Esto es

lo que indica la cláusula OVERRIDING que precede a la definición de los

métodos en los tipos triangulo y cuadrado. Al momento de crear el método,

será necesario indicar que el método está siendo sobrescrito. Por ejemplo,

una implementación del método area() del tipo cuadrado sería;

CREATE OVERRIDING METHOD area() RETURNS REAL FOR cuadrado BEGIN RETURN a.distanciaA(b) * b.distanciaA(c); END;

La redefinición y la sobrecarga de métodos son la base del polimorfismo

soportado por el estándar.

Otra característica de la herencia es que toda instancia de un subtipo, es una

instancia de su supertipo directo y también de los indirectos. Así tenemos

que una instancia t del tipo triangulo también es una instancia del tipo

figura_geométrica. Esto significa que la instancia t puede ser utilizada en

cualquier lugar donde se espere una instancia del tipo figura_geométrica.

77


Por ejemplo, si tenemos una tabla que posea una columna del tipo

figura_geométrica:

CREATE TABLE figuras ( id NUMBER PRIMARY KEY, fig figura_geometrica )

Podemos insertar una fila donde la columna fig almacene un cuadrado, y

otra, donde almacene un triangulo, de la siguiente manera:

INSERT INTO figuras VALUES(1,cuadrado()) INSERT INTO figuras VALUES(1,triangulo())

Si hacemos una consulta sobre la tabla figuras y ejecutamos el método

area() de la columna fig, el sistema determinará el método correspondiente

según el tipo concreto en tiempo de ejecución.

SELECT id, fig.area() FROM figuras

Además de las columnas, existen otros casos donde podemos sustituir el

valor de una instancia del supertipo, por un valor de su subtipo. Por ejemplo,

en los parámetros de una función, método o procedimiento.

Una excepción a esta característica son las instancias almacenadas como fila

en una typed table. Es decir, si tenemos una typed table tbl_fig cuyo tipo

base sea figura_geometrica, no podremos insertar en ella instancias que no

sean del tipo figura_geometrica. Sin embargo, podemos lograr la misma

funcionalidad al definir jerarquías de tablas (ver 4.2.5 ).

Al modificar un supertipo con la cláusula ALTER TYPE, estos cambios

afectarán a sus subtipos. Por ejemplo, si agregamos un atributo a la clase

figuras_geometricas, automáticamente, se agrega el atributo a los subtipos,

triangulo y cuadrado. Lo mismo pasa con los métodos.

4.2.7 Concurrencia

Como las versiones anteriores, SQL:1999 soporta la concurrencia de usuarios.

Desde el punto de vista de la orientación a objetos, podríamos decir que

78


varios usuarios pueden manipular un mismo objeto a la vez o que varios

objetos pueden ser manipulados por varios usuarios simultanéamele.

Otro aspecto de la concurrencia es que los métodos puedan ser concurrentes,

ya sea multihilo o multiproceso. Si desarrollamos los métodos con SQL/PSM,

no podremos contar con esta característica. Pero si lo implementamos como

una rutina externa, podremos utilizar algún lenguaje que soporte

concurrencia, como Java o C.

4.2.8 Manejo de Versiones de objetos y configuraciones

No soportado en el estándar, pero existe una especificación llamada

SQL/Temporal prevista para el 2003 aproximadamente, que se encargará del

manejo de bases de datos históricas, en ella debería estar soportada estas

característica.

4.2.9 Evolución de esquemas y de Instancias

La evolución de esquemas se refiere a la capacidad de modificar la estructura

de los tipos, agregando, modificando o eliminando métodos o atributos y que

estos cambios sean reflejados en todas las estructuras que dependan de él.

La evolución de instancia apunta a dos cosas, la primera es que al alterar un

tipo, dicho cambio debe verse reflejado en las instancias y la otra es contar

con la posibilidad de migrar instancias entre tipos.

La evolución de esquemas está completamente soportada mediante la

sentencia ALTER TYPE.

La evolución de instancias no es soportada completamente, debido a las

restricciones impuestas al predicado ALTER TYPE con respecto a los

atributos. Pero utilizando tablas temporales, lo podemos simular

La migración de clases no es soportada directamente, pero podemos sacar

una copia idéntica de él e insertarla en otra tabla, y eliminar el original. Esto

es posible, gracias a la posibilidad de sobrescribir el OID.

79


4.2.10 Transacciones y recuperación ante fallos

El estándar implementa un robusto sistema de transacciones, incorporando

en esta versión la noción de SAVEPOINT.

Con respecto a la recuperación ante fallos, es una materia dependiente de las

implementaciones del estándar.

4.2.11 Mecanismos de Autorización

Los mecanismos de autorización están basados en las tablas y en los tipos.

Se autoriza o restringe el acceso y manipulación de las tablas o tipos, como

un todo, pero no se puede restringir el acceso sobre un objeto o una fila.

4.2.12 Compatibilidad con el modelo relacional

El estándar ofrece una alta compatibilidad con el modelo relacional, no sólo

por soportarlo directamente, sino por permitir el mezclado de tablas

relacionales y tablas que almacenan objetos. Además podemos definir vistas

de objetos sobre tablas relacionales, permitiendo definir una “capa” de

orientación a objeto sobre nuestros datos relacionales. Las vistas de objeto

también pueden ser creadas jerárquicamente. Por ejemplo, consideremos la

tabla persona:

CREATE TABLE persona ( rut CHAR(12) PRIMARY KEY, nombre CHAR(40), fecha_nacim DATE )

Para definir una vista de objetos sobre esta tabla tendremos que definir un

tipo que represente a una fila de la tabla persona. Por ejemplo

CREATE TYPE tipo_persona AS ( rut CHAR(12), nombre CHAR(40), fecha_nacim DATE )INSTANTIABLE NOT FINAL INSTANCE METHOD edad() RETURNS REAL

80


Ahora, podemos crear una vista de objetos llamada persona_view de la

siguiente manera:

CREATE WIEW persona_view OF tipo_persona REF IS oid SYSTEM GENERATED AS (SELECT * FROM persona)

Esto facilita enormemente la migración de bases de datos relacionales a

bases de datos orientadas a objeto, puesto que las aplicaciones actuales

pueden continuar utilizando la tabla relacional, mientras que las nuevas

aplicaciones orientadas a objeto podrán utilizar la vista de objeto, sin que se

produzcan inconsistencias.

81


4.2.13 Limitaciones encontradas en SQL:1999

Al leer este capítulo podrá percatarse que el estándar tiene las siguientes

limitaciones:

• No podemos sobrecargar las funciones observadoras y mutadoras

• No podemos especificar un nivel de encapsulamiento (public, private,

protected) sobre los atributos y métodos.

• No podemos definir constructores

• No podemos definir atributos estáticos

• Sólo contamos con los arreglos para definir colecciones.

• No podemos definir arreglos de múltiples dimensiones (por ejemplo

matrices).

• Los tipos de referencia sólo pueden almacenar direcciones de objetos

persistentes.

• No podemos crear módulos o paquetes de objetos.

• No contamos con herencia múltiple.

• No está soportado el manejo de versiones y configuraciones de

objetos.

• No podemos modificar la definición de un atributo ni la interfaz de los

métodos.

82

4.3 Evaluación

En este capítulo evaluaremos la implementación que hace el estándar

SQL:1999 del paradigma de la orientación a objeto. El objetivo de esta

evaluación es determinar en qué porcentaje son soportadas las características

de la orientación a objeto (ver 2) y los requerimientos para las bases de datos

orientadas a objeto (ver 3.1.2.1), por parte del estandar SQL:1999.

4.3.1 Criterios de evaluación

Para evaluar objetivamente el paradigma de la orientación a objeto en SQL-

1999, definimos un conjunto de criterios basados en las características del

paradigma de la Orientación a Objeto (ver 2) y en los requerimientos para las

bases de datos orientadas a objeto (ver 3.1.2.1).

Los criterios de evaluación son:

1. Definición de tipos o clases

a. Definición de atributos estáticos

b. Definición de atributos de instancia

c. Constructores definidos por el usuario

d. Métodos estáticos

e. Métodos de instancia

f. Sobrecarga de métodos

g. Definición de colecciones

h. Clases abstractas

2. Encapsulamiento

a. Atributos y métodos en una sola entidad

b. Distinguir entre interfaz e implementación

c. Visibilidad de métodos (Ej.: Public, private, protected)

d. Visibilidad de atributos (Ej.: Public, private, protected)

3. Modularidad

4. Jerarquía de clases o tipos

a. Asociación

b. Agregación y Composición

83

Orientadas a Objeto en SQL:1999 – Soporte a la Orientación a objeto

c. Herencia Simple

d. Herencia Múltiple

e. Polimorfismo

5. Concurrencia

a. Métodos con múltiples hilos de control

b. Concurrencia de usuarios.

6. Persistencia de objetos

a. Creación

b. Modificación

c. Eliminación

d. Consulta

e. Identificadores de objetos

7. Versiones y configuraciones de objetos

8. Evolución de instancias

9. Evolución de esquemas

a. Agregar Atributos

b. Agregar Métodos

c. Agregar Restricciones sobre objetos persistentes

d. Eliminar Atributos

e. Eliminar Métodos

f. Eliminar Restricciones

g. Modificar definición de atributos

h. Modificar Interfaz de métodos

i. Modificar Implementación de métodos

j. Modificar Restricciones

k. Deshabilitar y habilitar restricciones

10. Transacciones y recuperación ante fallos

11. Mecanismos de autorización basados en objetos

12. Compatibilidad con el modelo relacional.

Cada criterio lo evaluaremos con los siguientes valores:

Si la característica: Valoración

Está presente 100%

No está presente, pero se puede simular 60%

No está presente 0%

84


4.3.2 Matriz de evaluación

Características

Parcia

l

Valo

ració

n

Fin

al

1. Definición de tipos o clases 95,00%

a. Definición de atributos estáticos 60%

b. Definición de atributos de instancia 100%

c. Constructores definidos por el usuario 100%

d. Métodos estáticos 100%

e. Métodos de instancia 100%

f. Sobrecarga de métodos 100%

g. Definición de colecciones 100%

h. Clases abstractas 100%

2. Encapsulamiento 80,00%

a. Atributos y métodos en una sola entidad 100%

b. Distinguir entre interfaz e

implementación

100%

c. Visibilidad de métodos (Ej.:Public,

private, protected)

60%

d. Visibilidad de atributos (Ej.: Public,

private, protected)

60%

3. Modularidad 60,00%

4. Jerarquía de clases o tipos 92,00%

a. Asociación 100%

b. Agregación y Composición 100%

c. Herencia Simple 100%

d. Herencia Múltiple 60%

e. Polimorfismo 100%

5. Concurrencia 100,00%

a. Métodos con múltiples hilos de control 100%

b. Concurrencia de usuarios. 100%

85


6. Objetos Persistentes 100,00%

a. Creación 100%

b. Modificación 100%

c. Eliminación 100%

d. Consulta 100%

e. Identificadores de objetos 100%

7. Versiones y configuraciones de objetos 0,00%

8. Evolución de instancias 60,00%

9. Evolución de esquemas 92,00%

a. Agregar Atributos 100%

b. Agregar Métodos 100%

c. Agregar Restricciones sobre objetos

persistentes

100%

d. Eliminar Atributos 100%

e. Eliminar Métodos 100%

f. Eliminar Restricciones 100%

g. Modificar definición de atributos 60%

h. Modificar Interfaz de métodos 60%

i. Modificar Implementación de métodos 100%

j. Modificar Restricciones 100%

10. Transacciones y recuperación ante fallos 100%

11. Mecanismos de autorización basados en

objetos

60%

12. Compatibilidad con el modelo relacional. 100%

Promedio 78,25%

86

5 Oracle 8i y la Orientación a Objeto.

5.1 Introducción

Oracle fue el primer servidor de bases de datos relacional, y desde entonces

ha sido uno de los líderes de la industria, realizando grandes inversiones en

investigación y desarrollo, además, participa activamente en la

estandarización del lenguaje SQL. Entre las características más importantes

de SABD Oracle 8i destacan [31]:

• Entorno cliente / servidor y procesamiento distribuido.

• Bases de datos de gran tamaño (Terabyte de datos).

• Gran número de usuarios concurrente.

• Conectividad con distintos sistemas operativos y distintas máquinas.

• Alto desempeño en procesamiento de transacciones.

• Alta disponibilidad, puede trabajar 24 horas por día sin una baja de

desempeño y algunas operaciones como respaldos se pueden hacer

sin “bajar” el servidor.

• Disponibilidad controlada.

• Se ajusta a los estándares de la industria.

• Integridad de la base de datos reforzada.

• Portabilidad y compatibilidad.

• Capacidad de replica de bases de datos.

A partir de la versión 8 de Oracle, comenzaron a incorporar características

orientadas a objeto, como definición de tipos, creación de tablas y vistas de

objeto, etc. En este capítulo se revisarán y analizarán los aspectos más

importantes de Oracle 8i relacionados con la tecnología de objetos

incorporada, para finalmente realizar una evaluación objetiva de esta

tecnología.

Como observación, asumiremos que el lector está familiarizado con SQL 92,

especialmente en lo relacionado con la definición, manipulación y consulta

de tablas relacionales y, por lo menos, posee una noción sobre los

procedimientos almacenados.

88

5.2 Soporte a la Orientación a Objeto

Para analizar el soporte de la orientación a objeto en ORACLE, como lo

hicimos con SQL:1999, nos basaremos en los conceptos básicos de la

orientación a objeto (ver 2) y en los requerimientos para las bases de datos

orientadas a objeto (ver 3.1.2.1 ). En lo posible, mantendremos la misma

estructura de presentación utilizada al analizar SQL:1999 para facilitar su

comparación con Oracle.

5.2.1 Tipos, abstracción y clases

Como explicamos en la sección 2.2.6 los conceptos de clase y tipo son

distintos, pero muchos lenguajes no hacen dicha distinción e incorporan

ambos conceptos bajo un mismo nombre ya sea el de clase o de tipo. En

Oracle el nombre empleado es tipo objeto (object type), que es un tipo de

datos definido por el usuario, que luego de ser descrito, pasa a formar parte

del sistema de tipos del lenguaje, quedando disponible para todos los

usuarios que tengan los privilegios de acceso correspondientes.

Un tipo objeto implementa una abstracción y por ende está compuesto por

[31]:

1. nombre, que lo identifica dentro de la base de datos y debe ser único

dentro del esquema en que se está definiendo

2. Atributos, cada uno con un nombre y un tipo de datos, que puede ser

un tipo primitivo u otro tipo definido por el usuario

3. métodos. Son funciones o procedimientos escritos en PL/SQL, Java o

C. Los métodos escritos en PL/SQL o en Java son almacenados en la

base de datos (de la misma manera que un procedimiento

almacenado) y los métodos escritos en C son invocados

externamente.

Describiremos los atributos y métodos con detenimiento más adelante en

las secciones 5.2.1.3 y 5.2.1.4 respectivamente.

89

Oracle 8i y la orientación a objeto - Soporte a la orientación a objeto

5.2.1.1 Estructura de un tipo objeto

Un tipo objeto tiene dos partes: una especificación y un cuerpo. La

especificación es la interfaz pública del tipo y en ella se declaran sus

atributos y la especificación de sus métodos (sin su implementación). En el

cuerpo se especifican e implementan los métodos que aparecieron en la

especificación del tipo[32]. El cuerpo es la parte privada del tipo.

1

especificación

Especificación de Métodos

Declaración de Atributos

Interfa

Cuerpo

Cuerpo de los Métodos

ImplemPrivad

entación a

z Pública

figura 5: Estructura de un tipo objeto.

Esta separación permite modificar los algoritmos que implementan los

métodos, sin que esto afecte a los usuarios del tipo (aplicaciones), siempre y

cuando no alteremos su interfaz. De este modo, el cuerpo pasa a ser una

“caja negra”, donde las aplicaciones clientes sólo conocen la interfaz del

método.

Como muestra la figura 5, sólo podemos declarar atributos en la

especificación del tipo, y éstos se declaran antes que los métodos. No es

necesario definir el cuerpo de un tipo cuando este no especifica métodos[32].

5.2.1.2 Sintaxis para la creación de tipos

Para definir la interfaz del tipo se utiliza la sentencia SQL CREATE TYPE Y

para el cuerpo CREATE TYPE BODY [41]. No se pueden definir tipos o

cuerpos de tipos en bloques PL/SQL, subprogramas o paquetes.

Para describir la sintaxis usaremos la siguiente notación:

90


• Las palabras en mayúsculas son palabras reservadas

• Los paréntesis cuadrados, [ ], indican que su contenido es opcional.

• El paréntesis de llave, { }, agrupan elementos.

• La barra vertical, |, indica que los elementos son alternativos (Es

como un OR exclusivo o XOR).

• Los puntos suspensivos, ..., indican repetición.

5.2.1.2.1 CREATE TYPE

La sintaxis para el predicado CREATE TYPE es la siguiente [41][32]:

CREATE [OR REPLACE] TYPE [schema.]type_name [AUTHID {CURRENT_USER | DEFINER}] {IS | AS} OBJECT ( attribute_name datatype [, attribute_name datatype]... [{MAP | ORDER} MEMBER function_spec,] [{MEMBER | STATIC} subprogram_spec [call_spec] [, {MEMBER | STATIC} subprogram_spec [call_spec]]...] );

Descripción de la sintaxis.

OR REPLACE. Cláusula opcional que permite remplazar la definición

anterior del tipo (si existe) con la nueva. No se puede reemplazar un tipo

si existen tablas, vistas u otros tipos que dependan de él [41].

[schema.]type_name. Es el nombre del tipo, el cual puede ir precedido

con el nombre del esquema en el que se quiere crear, separados por un

punto. Si no se especifica el esquema, el tipo se crea en el esquema del

usuario actual[41]. Estos son ejemplos de nombres válidos:

Persona, esquema.persona, miguel.persona_tipo, etc.

AUTHID CURRENT_USER o AUTHID DEFINER. Especifica si los métodos

se ejecutan con los privilegios y en el esquema del usuario actual(AUTHID

CURRENT_USER) o con los privilegios y en el esquema de usuario que

definió el tipo (AUTHID DEFINER). Esta cláusula también se aplica al

cuerpo del tipo [41]. La cláusula por defecto es AUTHID CURRENT_USER

[31].

91


attribute_name. Nombre del atributo que debe ser único dentro del tipo,

pero puede repetirse en otros [31].

datatype. Tipo de dato del atributo que puede ser un tipo de dato

definido por el usuario o bien un tipo de dato primitivo con la excepción

de: ROWID, UROWID, LONG, LONG ROW, NCLOB, NCHAR y NBARCHAR2

[41].

MEMBER. Especifica que el método que se está declarando es del tipo

miembro (ver sección 5.2.1.4.2 ), esto significa que su invocación será a

partir de un objeto. Por ejemplo, si tenemos un tipo persona con un

método miembro edad y un objeto p, para saber la edad de p se escribe:

p.edad().

STATIC. Especifica que el método que se está declarando es del tipo

Estático (ver sección 5.2.1.4.3 ). Un método estático, a diferencia de un

método miembro, se invocan a partir del nombre del tipo, y no de un

objeto. Tomando el ejemplo anterior, si el método edad fuera estático se

invocaría: persona.edad(). Al no haber objeto de la invocación no

podemos acceder a los atributos de este.

[{MAP | ORDER} MEMBER function_spec,]. Especifica una función

miembro que el sistema emplea para realizar comparaciones de objetos de

este tipo. La función de comparación puede ser de dos tipos MAP u

ORDER y un tipo puede tener sólo una de ellas[31]. Para mayor

información vea la sección 5.2.1.4.4

subprogram_spec. Es la especificación de un procedimiento o de una

función que consta de un nombre y de una lista opcional de parámetros.

Además de lo anterior, las funciones cuentan con un valor de retorno. El

formato para describir funciones es:

FUNCTION name [(parameter [IN|OUT|IN OUT] datatype [, parameter [IN|OUT|IN OUT] datatype]…)] RETURN datatype

y para procedimientos corresponde a:

PROCEDURE name [(parameter [IN|OUT|IN OUT] datatype [, parameter [IN|OUT|IN OUT] datatype]…)]

92


Donde

name es el nombre de la función o procedimiento,

parameter es el nombre del parámetro.

IN indica que se debe especificar un valor para el argumento al

invocar el método.

OUT indica que el argumento es usado por el subprograma para

devolver un valor al punto de llamada (o invocación del método),

una vez terminada la ejecución.

IN OUT indica que el argumento es utilizado como IN y OUT a la

vez.

datatype es el tipo de dato del parámetro

RETURN datatype es el tipo de dato de retorno de la función.

Al no especificar las cláusulas IN, OUT o IN OUT, el valor por defecto es IN.

call_spec. Esta cláusula indica que el método está implementado en java

o en C. Call_spec, especifica cómo llamar al método java o función C, y

cómo trasladar los parámetros y los valores de retorno. Si para todos los

métodos se especifica un call_spec, entonces no es necesario definir un

cuerpo del tipo con CREATE TYPE BODY.

El formato para el call_spec en el caso que el lenguaje sea java es:

LANGUAJE JAVA NAME ’ string ’

En el caso que el lenguaje sea C:

LANGUAJE C [NAME name] LIBRARY lib_name [WITH CONTEXT] [PARAMETERS ( parameters )]

Para más información sobre métodos implementados con java o C, vea las

secciones 5.2.1.5.2 ó 5.2.1.5.3 respectivamente.

93


5.2.1.2.2 CREATE TYPE BODY

La sintaxis para el predicado CREATE TYPE BODY es la siguiente:

CREATE [OR REPLACE] TYPE BODY [schema.]type_name { IS | AS} {{MAP|ORDER}MEMBER function_spec {IS|AS} {pl/sql_block|call_spec}; |{MEMBER|STATIC}subprogram_spec{IS|AS}{pl/sql_block|call_spec};} [{MEMBER|STATIC}subprogram_spec{IS|AS}{pl/sql_block|call_spec};]... END;

Descripción de la sintaxis.

OR REPLACE. Funciona de la misma manera que en CREATE TYPE [41].

[schema.]type_name. El nombre del cuerpo debe coincidir con el nombre

del tipo para el cual se define el cuerpo.

MEMBER, STATIC, MAP, ORDER, function_spec, subprogram_spec.

Tienen el mismo significado que en CREATE TYPE, además, estas

especificaciones deben coincidir exactamente con las definidas en el

predicado CREATE TYPE correspondiente.

{ pl/sql_block | call_spec }. Indican la manera en que se implementan los

métodos. La cláusula pl/sql_block representa un bloque PL/SQL que

contiene un conjunto de instrucciones que implementa el método en dicho

lenguaje. Para el caso de call_spec, si éste aparece en CREATE TYPE, éste

debe estar presente en CREATE TYPE BODY. Si no aparece quedamos

libres de escoger el lenguaje de implementación de los métodos, y

cambiarlo cuando queramos.

Para una mejor comprensión de cómo se crea un tipo objeto, veamos el

siguiente ejemplo tomado de [32], que corresponde a la implementación de

un tipo para la manipulación de números complejos. Un numero complejo

consta de dos partes, una real y otra imaginaria, ambas dentro del rango de

los números reales. Además existen una serie de operaciones matemáticas

que se pueden aplicar a dichos números. Las implementadas para este tipo

son las cuatro operaciones básicas (suma, resta, multiplicación y división). El

texto precedido con “- -“ es un comentario.

94


CREATE TYPE Complex AS OBJECT ( -- atributos

rpart REAL, ipart REAL,

-- métodos MEMBER FUNCTION suma (x Complex) RETURN Complex, MEMBER FUNCTION resta (x Complex) RETURN Complex, MEMBER FUNCTION mult (x Complex) RETURN Complex, MEMBER FUNCTION div (x Complex) RETURN Complex

); CREATE TYPE BODY Complex AS

MEMBER FUNCTION suma (x Complex) RETURN Complex IS BEGIN RETURN Complex(rpart + x.rpart, ipart + x.ipart); END suma; MEMBER FUNCTION resta (x Complex) RETURN Complex IS BEGIN RETURN Complex(rpart - x.rpart, ipart - x.ipart); END resta; MEMBER FUNCTION mult (x Complex) RETURN Complex IS BEGIN RETURN Complex(rpart * x.rpart - ipart * x.ipart , rpart * x.ipart + ipart * x.rpart ); END mult; MEMBER FUNCTION div (x Complex) RETURN Complex IS z REAL := x.rpart**2 + x.ipart**2; BEGIN RETURN Complex((rpart*x.rpart + ipart*x.ipart)/z, (ipart*x.rpart - rpart*x.ipart)/z); END div;

END;

Como sugerencia, comparar esta implementación con la mostrada en la

sección 4.2.1.3.4 SQL:1999.

5.2.1.3 Atributos

Todo tipo objeto debe poseer a lo menos un atributo, y como máximo 1.000.

Un atributo consta de un nombre y un tipo de dato, donde el nombre debe

ser único dentro del tipo objeto, y el tipo de datos del atributo puede ser otro

tipo definido por el usuario o un tipo primitivo, con las excepciones ROWID,

UROWID, LONG, LONG ROW, NCLOB, NCHAR y NBARCHAR2.

Entre los tipos de datos primitivos existe uno denominado REF, que permite

almacenar una referencia a un tipo objeto. Gracias a él podemos definir un

tipo objeto recursivo que es aquel donde uno o más de sus atributos tienen

95


como tipo de dato una referencia a si mismo. Por ejemplo, consideremos una

lista enlazada con dos atributos, uno llamado info para almacenar un número

y un atributo next que es una referencia a la lista siguiente. Para construirlo

podemos escribir:

CREATE OR REPLACE TYPE lista AS OBJECT ( info number, next REF lista );

Una referencia (REF), almacena un puntero lógico a un objeto, lo que nos

permite acceder a él directamente. El manejo de las referencias en Oracle, es

semejante al de JAVA. Por ejemplo, para obtener el atributo info de la lista

siguiente (referenciada por next) a la lista L, seria:

... L.next.info ...

Como en muchos lenguajes de programación (Ej.: c, pascal, etc) un tipo no

puede tener un atributo del mismo tipo que él. Por ejemplo si intenta crear

el tipo lista mostrado anteriormente, pero omitiendo la palabra REF obtendrá

un error de compilación. Las siguientes líneas muestran la ejecución de este

ejemplo en SQL*PLUS:

SQL> create type lista as object ( 2 info number, 3 next lista --esta linea es ilegal. 4 ) 5 / Warning: Type created with compilation errors. SQL> show errors; Errors for TYPE LISTA: LINE/COL ERROR -------- ------------------------------------------------------ 0/0 PL/SQL: Compilation unit analysis terminated 3/7 PLS-00318: type "LISTA" is malformed because it is a non-REF mutually recursive type

Si está interesado en crear tipos recursivos, le recomendamos la referencia

bibliográfica [2], ahí explican cómo crear estructuras de red, árbol, listas

enlazadas y de anillo en Oracle 8.

Al observar los ejemplos se percatará que si comparamos la definición de

atributos con la definición de columnas de una tabla, son muy similares, pero

96


existen diferencias notables. Para apreciar las diferencias y semejanzas

veremos la siguiente definición de un tipo empleado y de una tabla empleado

Creación del tipo empleado

CREATE OR REPLACE TYPE empleado AS OBJECT (

rut VARCHAR2(10), nombre VARCHAR2(30), fecha_ingreso DATE, salario NUMBER

);

Creación de la tabla empleado

CREATE TABLE empleado (

rut VARCHAR2(10) CONSTRAINT pk_emp PRIMARY KEY, nombre VARCHAR2(30) CONSTRAINT nn_ename NOT NULL, fecha_ingreso DATE DEFAULT SYSDATE, sueldo NUMBER CONSTRAINT ck_suel CHECK(sueldo>95000)

);

En ambas definiciones (atributos y columnas) especificamos un nombre y un

tipo de datos, pero cuando definimos un tipo objeto, no podemos indicar

valores iniciales ni imponer restricciones como NOT NULL a un atributo [32].

Estas restricciones podrán ser impuestas cuando definamos una tabla que

almacene objetos.

Otra restricción que tenemos a la hora de definir un tipo objeto, es que el

tipo de datos de un atributo debe existir. En el siguiente ejemplo la primera

sentencia CREATE TYPE es ilegal, porque el tipo Departamento todavía no

existe:

CREATE OR REPLACE TYPE Empleado AS OBJECT ( rut varchar2(9),

nombre varchar2(20), dept REF Departamento – - esta linea es ilegal ); CREATE OR REPLACE TYPE Departamento AS OBJECT (

nombre varchar2(20), jefe Empleado );

Una solución podría ser definir primero el tipo Departamento, pero esto

provocaría el mismo error al tratar de definir el atributo jefe de un tipo que

97


todavía no existe. Este problema se produce porque los dos tipos son

mutuamente dependientes, es decir, uno depende del otro a través de una

referencia [32]. Para solucionar este problema existe una sentencia CREATE

TYPE especial, denominada forward type definition (definición de tipo

adelantada) cuya sintaxis es la siguiente:

CREATE [OR REPLACE] TYPE [schema.]type_name;

El tipo objeto creado con esta sentencia es denominado tipo objeto

incompleto, por no contar con atributos o métodos, los que serán definidos

más adelante con la sentencia CREATE TYPE normal, dejando de ser

incompleto.

Siguiendo con el ejemplo anterior, ahora podemos solucionar el problema de

la dependencia mutua al definir por adelantado el tipo Departamento:

-- definición adelantada del tipo departamento CREATE OR REPLACE TYPE Departamento ; CREATE OR REPLACE TYPE Empleado AS OBJECT ( rut varchar2(9),

nombre varchar2(20), dept REF Departamento -- No produce error. ); –- definición normal del tipo departamento CREATE OR REPLACE TYPE Departamento AS OBJECT (

nombre varchar2(20), jefe Empleado );

Es necesario señalar que no es posible definir un atributo a partir de un tipo

incompleto, sólo se pueden definir referencias a tipos incompletos. Por

ejemplo, si creamos un tipo departamento y luego tratamos de definir un

atributo de este tipo, obtendremos un error de compilación. Las siguientes

líneas fueron ejecutadas en SQL*PLUS, y ejemplifican lo antes descrito.

SQL> create type departamento; 2 / Type created. SQL> create type Empleado as Object 2 ( 3 rut varchar2(9), 4 dep departamento –-esta linea es ilegal. 5 );

98


6 / Warning: Type created with compilation errors. SQL> show errors; Errors for TYPE EMPLEADO: LINE/COL ERROR -------- ----------------------------------------------------- 0/0 PL/SQL: Compilation unit analysis terminated 4/8 PLS-00311: the declaration of "DEPARTAMENTO" is

incomplete or malformed

Como consecuencia de lo anterior, no podemos tener dos tipos mutuamente

dependientes si el atributo dependiente de uno de ellos (o de ambos) no es

una referencia al otro tipo.

5.2.1.4 Métodos

Los métodos no son más que funciones o procedimientos almacenados que

se asocian a un tipo específico, y no pueden ser invocados

independientemente.

Existen cuatro categorías para los métodos estas son: Constructor,

miembro, estático y comparación.

5.2.1.4.1 Constructor

Todos los tipos objeto definidos por el usuario poseen un método

constructor generado por el sistema, que es una función con el mismo

nombre que el tipo. Los parámetros formales de esta función coinciden

exactamente con los atributos del tipo, es decir, son declarados en el

mismo orden, con el mismo nombre y del mismo tipo de dato que los

atributos [32]. El valor de retorno del constructor es un nuevo objeto del

mismo tipo al que pertenece el constructor, donde los valores de los

atributos fueron inicializados con los valores pasados por parámetro al

momento de llamar al constructor [31]. Por ejemplo, consideremos el

siguiente tipo:

CREATE OR REPLACE TYPE Persona AS OBJECT ( rut VARCHAR2(10), nombre VARCHAR2(30),

99


); Si queremos crear un objeto Persona donde el rut sea 13.131.344-6 y el

Nombre Miguel Romero, utilizaremos el método constructor de la

siguiente manera

... Persona(‘13131344-6’,’Miguel Romero’)

Como el método constructor es una función, sólo puede ser utilizar dentro

de una expresión en la que se espera un objeto de ese tipo. Los

constructores también pueden ser utilizados en sentencias SQL.

Muchos lenguajes como JAVA, permiten la sobrecarga de constructores,

esto no es posible en Oracle 8i, y tampoco podemos redefinirlo.

5.2.1.4.2 Miembro (member)

Para especificar un método miembro se antepone la palabra reservada

MEMBER, y como mencionamos anteriormente, estos son invocados a

partir de un objeto. Los métodos miembro son definidos por el usuario al

momento de especificar el tipo, pudiendo ser una función o un

procedimiento. Por ejemplo, podemos definir un tipo punto para

representar las coordenadas (X,Y) con los método moverA (cambia la

ubicación del punto) y distanciaA (calcula la distancia a otro punto). El

código para la creación del tipo es el siguiente:

CREATE OR REPLACE TYPE Punto AS OBJECT ( X number,

Y number, MEMBER PROCEDURE moverA(X IN number, Y IN number), MEMBER FUNCTION distanciaA(p IN Punto) RETURN NUMBER );

Hasta este momento, sólo hemos descrito la interfaz del método, falta su

implementación. Las siguientes líneas implementan los métodos:

CREATE OR REPLACE TYPE BODY Punto AS MEMBER PROCEDURE moverA(X IN number, Y IN number) IS BEGIN SELF.X:=X; SELF.Y:=Y; END moverA; MEMBER FUNCTION distanciaA(p IN Punto) RETURN NUMBER IS

100


-- Funcion POWER(m,n) retorna m elevado a n. -- Funcion SQRT(m) retorna la raiz cuadrada de m. -- Este metodo entrega la distancia euclidiana entre el -- objeto de la invocación y el punto p. BEGIN RETURN SQRT(POWER((x - p.x),2) + POWER((y - p.y),2)); END distanciaA; END;

El primer parámetro de un método es siempre el objeto de la invocación

llamado SELF cuyo tipo de dato es el mismo al que pertenece el método.

El argumento SELF esta implícito al declarar un método de este tipo (no es

necesario declararlo) [32]. Este parámetro nos permite acceder a los

atributos o métodos del objeto de la invocación. El uso del parámetro

SELF sólo es obligatorio cuando un método cuenta con un parámetro o

una variable con el mismo nombre que un atributo. Por eso, en el método

moverA se utiliza el parámetro SELF (ej: SELF.X:=X;), y en el método

distanciaA es omitido (ej: POWER((x - p.x),2)).

El modo por defecto para el parámetro SELF es IN para el caso de las

funciones miembro e IN OUT para el caso de los procedimientos miembro

[32]. Esto significa que no podemos actualizar los atributos del objeto en

una función pero si en un procedimiento. Si queremos un pasaje de

parámetros distinto será necesario declarar explícitamente el parámetro

SELF, teniendo en cuenca lo siguiente:

• SELF debe ser el primer argumento.

• No se puede declarar el modo OUT para SELF.

• SELF no puede ser de un tipo diferente al del tipo en el que se

declara el método.

Por ejemplo:

CREATE TYPE Persona as OBJECT ( nombre VARCHAR(40), MEMBER FUNCTION setNombre(SELF IN OUT Persona, Nom IN VARCHAR) return BOOLEAN );

Las funciones miembro pueden ser invocadas desde sentencias SQL

(SELECT, INSERT, DELETE, etc) siempre que el modo de todos sus

parámetros sea IN, de lo contrario obtendremos el siguiente error:

101


SQL> select p.setNombre('Miguel Romero') from per p; select p.setNombre('Miguel Romero') from per p * ERROR at line 1: ORA-06572: Function SETNOMBRE has out arguments

Los procedimientos miembro no pueden ser invocados desde sentencias

SQL, sólo a través de objetos transitorios desde el lenguaje de

programación.

5.2.1.4.3 Estático (Static)

Un método estático al igual que un método miembro, puede ser un

procedimiento o una función, pero a diferencia de este, no podemos

declarar el parámetro SELF, implícita o explícitamente. Debido a esto, en

un método estático no podemos acceder a los atributos del tipo, ni

referenciar a SELF [32].

El uso más común de los métodos estáticos es crear funciones que hagan

las veces de constructor, supliendo así la carencia de constructores

definidos por el usuario. Por ejemplo para el tipo Punto descrito en la

sección 5.2.1.4.2 el constructor por defecto construye un punto a partir

de las coordenadas X e Y (ej.: Punto(3,5) ). Si quisiéramos construir un

punto a partir de otro, podríamos hacerlo definiendo un método estático



Y number, MEMBER PROCEDURE moverA(X IN number, Y IN number), MEMBER FUNCTION distanciaA(p IN Punto) RETURN NUMBER, STATIC FUNCTION constructor(p IN Punto) RETURN PUNTO ); y luego lo invocaríamos como :

...Punto.constructor(P) siendo P un objeto del tipo Punto.

5.2.1.4.4 Comparación (Map u Order)

102


Los valores de tipos de datos como REAL o CHAR tienen un orden

predefinido (1,2,3 ó A,B,C... etc.), lo que permite su comparación (=, <, >,

etc.) [32]. Pero las instancias de un tipo objeto no tienen un orden

predefinido. Para poder realizar comparaciones, existen dos tipos de

métodos que se definen anteponiendo las palabras reservadas MAP u

ORDER. Un tipo objeto puede tener solamente una función de

comparación ya sea MAP u ORDER.

Un método de comparación del tipo MAP es una función miembro que no

posee argumentos y cuyo valor de retorno es de uno de los siguientes

tipos de datos escalares: DATE, NUMBER, VARCHAR2, o un tipo ANSI SQL

como CHARACTER o REAL [32]. Por ejemplo, consideremos un tipo

Racional para representar los números racionales (ej.: ½).

CREATE TYPE Racional AS OBJECT ( num INTEGER, den INTEGER, MAP MEMBER FUNCTION convert RETURN REAL );

CREATE TYPE BODY Rational AS MAP MEMBER FUNCTION convert RETURN REAL IS BEGIN RETURN num / den ; END convert; END;

Un método del tipo MAP deberá entrega la posición relativa que ocuparía

el objeto si se ordenara el universo completo de objetos del mismo tipo.

Para el caso anterior es muy conveniente una función de ordenación del

tipo map, porque todo número racional puede ser convertido a un número

real. Pero no todos los tipos objetos que definamos tendrán esa

característica. Para todos los tipos objetos que no puedan ser convertidos

a uno de los tipos escalares nombrados anteriormente existe otro tipo de

método de comparación llamado ORDER.

Un Método de tipo ORDER es una función miembro que tiene

obligatoriamente dos parámetros: el parámetro SELF (ver sección 5.2.1.4.2

), y otro objeto del mismo tipo. La función retorna un valor numérico, que

103


puede ser negativo, cero o positivo. Esto significa que el parámetro SELF

es menor (negativo), igual (cero) o mayor (positivo) que el otro parámetro.

Por ejemplo:

CREATE TYPE Producto AS OBJECT ( id NUMBER, nombre VARCHAR2(40), ORDER MEMBER FUNCTION comparTo(p Producto) RETURN NUMBER ); CREATE TYPE BODY Producto AS ORDER MEMBER FUNCTION comparTo(p Producto) RETURN NUMBER BEGIN IF id < p.id THEN RETURN –1; ELSIF id > p.id THEN RETURN 1; ELSE RETURN 0; END IF; END comparTo; END;

Si un método del tipo ORDER es llamado con un valor NULL, retorna un

NULL.

Gracias a los métodos de comparación, tanto MAP u ORDER, el sistema

puede evaluar expresiones booleanas como X > Y o hacer comparaciones

implícitas en las cláusulas GROUP BY, DISTINCT y ORDER BY. Si no se

especifica una función miembro del tipo MAP u ORDER, Oracle no podrá

hacer comparaciones en bloques PL/SQL, ni en las sentencias SQL,

solamente podrá saber si dos objetos son iguales o no.

Cuando definimos funciones miembro del tipo MAP, el sistema puede

realizar ciertas optimizaciones. Por esta razón siempre que pueda utilice

métodos del tipo MAP.

5.2.1.4.5 Sobrecarga de métodos.

La sobrecarga de métodos como explicamos en la sección 2.2.5.1.1 ,

consiste en tener dos o más métodos con el mismo nombre pero con

distintos parámetros formales, ya sea en número, orden, o tipo de dato.

104


La sobrecarga es soportada, únicamente, para los métodos miembro y

estático. No podemos sobrecargar métodos si sus parámetros formales

difieren únicamente en el modo (IN, OUT, IN OUT). Tampoco podemos

sobrecargar funciones miembro, que difieran únicamente en el tipo de

dato del valor de retorno [32].

Siguiendo con el ejemplo del tipo Punto, sobrecargaremos el método

moverA, para que acepte un Punto como argumento.


Y number, MEMBER PROCEDURE moverA(X IN number, Y IN number), MEMBER PROCEDURE moverA(P IN Punto), MEMBER FUNCTION distanciaA(p IN Punto) RETURN NUMBER );

5.2.1.5 Alternativas para la implementación de los métodos

Tenemos tres alternativas para implementar los métodos, PL/SQL, JAVA o C.

Cada lenguaje tiene ventajas y desventajas comparativas, por esta razón, es

importante escoger el que mejor se ajuste a nuestras necesidades, que

podrían ser: facilidad de uso, disponibilidad de personal capacitado,

portabilidad, compatibilidad con sistemas existentes o heredados [30]. Sin

embargo, la elección podría estar estrechamente ligada a la naturaleza de la

aplicación y la forma en que trabajará con Oracle. Bajo este punto de vista,

considere lo siguiente [30]:

• PL/SQL está especialmente diseñado para el procesamiento de

transacciones SQL.

• C es el lenguaje indicado para los métodos que realizan cálculos

intensivos, gracias a su alta eficiencia y la posibilidad de programar a

bajo nivel.

• JAVA es altamente portable y seguro.

Desde el punto de vista del rendimiento, PL/SQL se ejecuta ligeramente mejor

que JAVA interpretado [6], pero en Oracle 9i, es posible compilar JAVA a

código nativo, dicho código, se ejecutará diez veces más rápido que en

PL/SQL. El Código nativo de JAVA posee un rendimiento similar al de los

105


métodos escritos con C. Esto se debe a que Oracle, primero pasa el código

java a C, y luego lo compila.

5.2.1.5.1 Implementación de los métodos con PL/SQL

PL/SQL es el lenguaje por defecto (no se necesita un call_spec) para la

implementación de métodos y es el que hemos utilizado para la

implementación de los ejemplos.

Como debe haber apreciado implementar los métodos en PL/SQL resulta

fácil, gracias a que está transparentemente incorporado en las sentencias

CREATE TYPE y CREATE TYPE BODY. Otra característica que facilita el

trabajo, es que los tipos definidos en SQL pueden ser utilizados

directamente en PL/SQL sin la necesidad de importarlos o de declararlos.

Además existe una correspondencia exacta de tipos.

Ejemplo:

CREATE or replace TYPE Empleado AS OBJECT ( rut VARCHAR2(10), nombre VARCHAR2(10), cargo VARCHAR2(9), fechaIng DATE, sueldo NUMBER(9), comision NUMBER(9), anticipo NUMBER(9), MEMBER FUNCTION sueldo_liquido RETURN NUMBER, MEMBER PROCEDURE aumento_sueldo (aumento NUMBER) ); CREATE OR REPLACE TYPE BODY Empleado IS MEMBER FUNCTION sueldo_liquido RETURN NUMBER IS BEGIN RETURN (sueldo + comision)-anticipo; END sueldo_liquido; MEMBER PROCEDURE aumento_sueldo (aumento NUMBER) IS BEGIN sueldo:=sueldo+aumento; END aumento_sueldo; END;

5.2.1.5.2 Implementación de métodos con JAVA

Los métodos de un tipo objeto no pueden ser implementados

directamente con el lenguaje java. Para esto debemos crear una clase (en

java) con sus propios atributos y métodos, cargarla en el servidor, y luego,

asociar los métodos del tipo objeto (en Oracle) con los de la clase java

106


correspondiente. Dicha asociación se logra mediante las cláusulas AS

LANGUAGE JAVA NAME ‘...’, las cuales pueden ser especificadas en la

sentencia CREATE TYPE y/o en CREATE TYPE BODY.

Consideremos el mismo tipo empleado utilizado como ejemplo en la

sección anterior (5.2.1.5.1 , pero asociando sus métodos con los de la

clase EmpleadoBody previamente cargada en el servidor:

CREATE or replace TYPE Empleado AS OBJECT ( rut VARCHAR2(10), nombre VARCHAR2(10), cargo VARCHAR2(9), fechaIng DATE, sueldo NUMBER(9), comision NUMBER(9), anticipo NUMBER(9), MEMBER FUNCTION sueldo_liquido RETURN NUMBER AS LANGUAGE JAVA NAME 'EmpleadoBody.sueldoLiquido() return java.math.BigDecimal', MEMBER PROCEDURE aumento_sueldo (aumento NUMBER) AS LANGUAGE JAVA NAME 'EmpleadoBody.aumentoSueldo(java.math.BigDecimal)' );

Al indicar cómo llamar al método de la clase java correspondiente,

también se especifica el tipo (clase java) de retorno y el de cada uno de los

parámetros. No se puede omitir la jerarquía de paquetes del tipo. Otra

cosa importante es que los tipos deben ser compatibles con su

contraparte de Oracle. Para ver en detalle la compatibilidad de tipos vea la

referencia [43].

Cuando invoquemos un método (que no sea estático) sobre una instancia

del tipo objeto Empleado, ésta invocará al método correspondiente, sobre

una instancia de la clase EmpleadoBody. Para que los métodos se ejecuten

correctamente, la instancia de la clase EmpleadoBody debe tener el mismo

estado que su contraparte y los cambios de estado deben reflejarse en

ambas instancias. Para lograr esto, la clase EmpleadoBody, deberá

implementar la interfaz SQLData, la que define los métodos readSQL() y

writeSQL() [43]. Estos métodos son invocados automáticamente por el

driver JDBC. El método readSQL() permite a la instancia de EmpleadoBody

leer los atributos de su contraparte para actualizar sus propios atributos.

107


El método writeSQL() permite que la instancia de EmpleadoBody escriba el

valor de sus atributos en los de su contraparte.

Otro método definido en la interfaz SQLData es getSQLTypeName() que le

permite a JDBC conocer el tipo objeto al que representa. Y por último, es

necesario agregar una variable de instancia del tipo String que guardará el

nombre del tipo al que representa (pasado como parámetro en el método

readSQL).

Ejemplo: el siguiente código muestra la implementación de la clase

EmpleadoBody, que fue creada directamente en el servidor con el

predicado CREATE JAVA.

CREATE AND COMPILE JAVA SOURCE NAMED EmpleadoBody as import java.sql.*; import java.io.*; import Oracle.sql.*; import Oracle.jdbc.driver.*; import Oracle.oracore.*; import Oracle.jdbc2.*; import java.math.*; public class EmpleadoBody implements SQLData { private String rut; private String nombre; private String cargo; private Date fechaIng; private BigDecimal sueldo; private BigDecimal comision; private BigDecimal anticipo; public BigDecimal sueldoLiquido() { BigDecimal liquido = sueldo; if (comision != null)

liquido = liquido.add(comision); if (anticipo != null)

liquido = liquido.subtract(anticipo); return liquido; } public void aumentoSueldo(BigDecimal aumento) { sueldo = sueldo.add(aumento); } // Implementacion de la interfaz SQLData String sql_type; public String getSQLTypeName() throws SQLException { return sql_type; } public void readSQL(SQLInput stream, String typeName) throws SQLException { sql_type = typeName;

108


rut = stream.readString(); nombre = stream.readString(); cargo = stream.readString(); fechaIng = stream.readDate(); sueldo = stream.readBigDecimal(); comision = stream.readBigDecimal(); anticipo = stream.readBigDecimal(); } public void writeSQL(SQLOutput stream) throws SQLException { stream.writeString(rut); stream.writeString(nombre); stream.writeString(cargo); stream.writeDate(fechaIng); stream.writeBigDecimal(sueldo); stream.writeBigDecimal(comision); stream.writeBigDecimal(anticipo); } } ;

También podemos cargar la clase EmpleadoBody desde un archivo,

ejecutando la utilidad loadjava, desde el interprete de comandos, de la

siguiente manera:

>Loadjava –u scott/tiger@zorro:1521:ORCL -v –r –t EmpleadoBody.java

El parámetros –u scott/tigre@zorro:1521:ORCL es la url de conexión

con la base de datos. El tipo se cargará en el esquema del usuario de la

conexión.

Para más información sobre la sentencia CREATE JAVA vea la referencia

bibliográfica [41], para más información sobre loadjava vea [42].

5.2.1.5.3 Implementación de métodos con C

Implementar los métodos con C es mucho más difícil que con java, porque

no existe una correspondencia directa entre tipos de Oracle y C. Otro

problema es que los tipos primitivos de Oracle soportan valores nulos,

pero los de C no.

Para implementar los métodos con C debemos crear una biblioteca

(archivo .DLL en Windows o .so en Solaris) que contenga las funciones que

más tarde serán llamadas desde Oracle.

109


Luego se crea un alias en el servidor que almacena la ruta externa de la

biblioteca. Por ejemplo:

CREATE LIBRARY agelib UNTRUSTED IS ’/tmp/scott1.so’;

Y finalmente definimos el tipo y la llamada a la rutina externa de C

CREATE OR REPLACE TYPE Person1_typ AS OBJECT ( Name VARCHAR2(30),

B_date DATE, MEMBER FUNCTION calcAge_func RETURN NUMBER AS LANGUAGE C NAME "age" LIBRARY agelib WITH CONTEXT PARAMETERS ( CONTEXT, SELF,SELF INDICATOR STRUCT,SELF

TDO, RETURN INDICATOR ) ); Para más información vea la referencia bibliográfica [30] y la [44].

5.2.1.6 Modificación de tipos (ALTER TYPE)

El predicado ALTER TYPE permite recompilar la especificación y/o el cuerpo

de un tipo objeto, también nos permite agregarle nuevos métodos. Con

ALTER TYPE no podemos modificar o eliminar los atributos o métodos

existentes, tampoco agregar atributos [41].

La sintaxis para el predicado ALTER TYPE es la siguiente:

ALTER TYPE [schema.]type_name {COMPILE [DEBUG] [{SPECIFICATION | BODY } ] | REPLACE AS OBJECT ( attribute_name datatype [, attribute_name datatype]... [{MAP | ORDER} MEMBER function_spec,] [{MEMBER | STATIC} subprogram_spec [call_spec] [, {MEMBER | STATIC} subprogram_spec [call_spec]]...] )} ;

Donde:

[schema.]type_name, es el nombre del tipo a modificar

COMPILE, recompila la especificación y el cuerpo del tipo. Con las cláusulas

opcionales SPECIFICATION o BODY se puede indicar que sólo se compile la

especificación o el cuerpo.

DEBUG, le indica al compilador de PL/SQL que genere y almacene código

para ser utilizado con PL/SQL debugger de Oracle.

110


REPLACE AS OBJECT( ... ), permite agregar nuevos métodos al tipo que se

está alterando. Dentro de los paréntesis se especifica el tipo, donde

debemos incluir todos sus atributos y métodos actuales (sin ninguna

modificación) y agregar los nuevos métodos.

Ejemplos:

Para los ejemplos, tomaremos como base el tipo Empleado especificado en la

sección 5.2.1.5.1

1. Recompilación del tipo , para depuración:

ALTER TYPE Empleado COMPILE DEBUG;

2. Recompilación de la especificación del tipo:

ALTER TYPE Empleado COMPILE SPECIFICATION;

3. Recompilación del cuerpo del tipo:

ALTER TYPE Empleado COMPILE BODY;

4. Agregando método setAnticipo:

ALTER TYPE data_t REPLACE AS OBJECT (

rut VARCHAR2(10), nombre VARCHAR2(10), cargo VARCHAR2(9), fechaIng DATE, sueldo NUMBER(9), comision NUMBER(9), anticipo NUMBER(9), MEMBER FUNCTION sueldo_liquido RETURN NUMBER, MEMBER PROCEDURE aumento_sueldo (aumento NUMBER), MEMBER PROCEDURE setAnticipo(anticipo NUMBER)

);

En el ejemplo 4, el texto que no está en negrita, corresponde a los

atributos y métodos actuales, que se deben declarar pero no modificar.

Para crear el cuerpo para el nuevo método, se debe emplear el

predicado CREATE TYPE:

CREATE OR REPLACE TYPE BODY Empleado IS MEMBER FUNCTION sueldo_liquido RETURN NUMBER IS BEGIN RETURN (sueldo + comision)-anticipo; END sueldo_liquido; MEMBER PROCEDURE aumento_sueldo (aumento NUMBER) IS BEGIN sueldo:=sueldo+aumento; END aumento_sueldo;

111


MEMBER PROCEDURE setAnticipo (anticipo NUMBER) IS BEGIN SELF.anticipo:=anticipo; END setAnticipo; END;

Como queremos remplazar la definición anterior del cuerpo, incluimos

la cláusula OR REPLACE. Junto con los nuevos métodos agregados con

el predicado ALTER TYPE debemos incluir a todos los métodos actuales.

Podemos modificar el cuerpo de los métodos actuales sin ninguna

restricción, pero no podemos modificar su especificación, porque debe

coincidir exactamente con lo descrito en ALTER TYPE. Y en CREATE

TYPE.

5.2.1.7 Eliminación de tipos (DROP TYPE y DROP TYPE BODY)

Para eliminar la especificación y el cuerpo de un tipo se utiliza la sentencia

DROP TYPE, la sintaxis es la siguiente:

DROP TYPE [schema.]type_name [FORCE] ;

Donde :

[schema.]type_name. es el nombre del tipo a eliminar

[FORCE], fuerza el borrado del tipo en el caso que existan dependencias.

Oracle marca como UNUSED todas las columnas que dependan del tipo que

ha sido borrado. Las columnas marcadas como UNUSED son inaccesibles

[41].

Para eliminar sólo el cuerpo del tipo existe el predicado DROP TYPE BODY,

cuya sintaxis es:

DROP TYPE BODY [schema.]type_name ;

Donde :

[schema.]type_name. es el nombre del cuerpo del tipo que será eliminado.

5.2.2 Tipo Colección

112


Un tipo colección es otro tipo de dato definido por el usuario, que nos

permite almacenar un número indefinido de elementos, todos de un mismo

tipo [31]. Un tipo colección puede ser usado para definir:

• Una columna en una tabla relacional

• Un atributo en un tipo objeto.

• Variables, parámetros o tipo de retorno de una función, en PL/SQL.

En Oracle, existen dos tipos de colecciones: arreglos (VARRAYs) y tablas

anidadas (nested table).

Al igual que un tipo objeto, un tipo colección posee un método constructor

definido por el sistema, cuyo nombre es el mismo que el de la colección, y los

parámetros corresponden a los elementos que contendrá, separados por

coma, todos del mismo tipo y que, obviamente, coincide con el tipo que es

almacenado por la colección. Este constructor es una función que retorna

una nueva colección con estos valores almacenados. Si no se pasan

parámetros, se crea una colección vacía, que es diferente de una colección

nula.

No podemos agregar métodos o atributos a un tipo colección, si lo

necesitamos, tendremos que crear un tipo objeto donde uno de sus atributos

sea del tipo colección correspondiente, junto con los atributos y métodos que

sean necesarios.

5.2.2.1 Métodos de un tipo colección.

Además del constructor, el sistema define un conjunto de métodos miembro,

que nos permitirán usar las colecciones fácilmente. Estos son [32]:

• EXISTS(n), retorna verdadero si el elemento n existe, de lo contrario

retorna falso.

• COUNT, retorna el número actual de elementos de la colección.

• LIMIT, para los varray retorna el número máximo de elementos que

puede contener. Para las tablas anidadas retorna null, por no poseer

un límite.

113


• FIRST y LAST, retornan el primer y el último índice de una colección

respectivamente. Al no existir elementos retorna null, si únicamente

hay uno, ambos retornan el mismo índice.

• PRIOR(n) y NEXT(n), retornan el índice del antecesor (PRIOR) o

sucesor (NEXT) al elemento ubicado en la posición n

• EXTEND, EXTEND(n), EXTEND(n, i), permiten agrandar el tamaño de

una colección. El primero, agrega un elemento null al final de la

colección. El segundo, agrega n elementos null al final de la

colección. Y el tercero, agrega n copias del elemento de la posición i,

al final de la colección.

• TRIM, TRIM(n), eliminan elementos desde el final de la colección.

TRIM, elimina el último elemento. TRIM(n), elimina n elementos desde

el final.

• DELETE, DELETE(n), DELETE(m, n), también permite eliminar

elementos, pero de una manera distinta. El primero elimina todos los

elementos de la colección. El segundo elimina el elemento de la

posición n en una tabla anidada. Y el tercero elimina los elementos

desde m hasta n de una tabla anidada.

Estos métodos no pueden ser invocados desde sentencias SQL, sólo podemos

hacerlo desde bloques PL/SQL. Para invocar uno de estos métodos

utilizamos la misma notación que en los tipos objeto.

5.2.2.2 VARRAY

Un arreglo (array) es un conjunto de elementos del mismo tipo, donde cada

elemento está en una posición determinada [31]. En Oracle, los arreglos son

de largo variable, por eso son denominados VARRAY. Sin embargo, debemos

indicar el máximo número de elementos que podrá contener el arreglo. La

sintaxis para un varray es la siguiente [32]:

TYPE type_name IS {VARRAY | VARYING ARRAY} (size_limit) OF element_type [NOT NULL];

Donde:

Type_name, es el nombre del tipo de dato que el usuario está definiendo.

114


Size_limit, es un valor (literal) entero positivo, que representa el número

máximo de elementos que puede contener el array.

Element_type, es cualquier tipo de PL/SQL con la excepción de [32]:

• BINARY_INTEGER, PLS_INTEGER

• BOOLEAN

• BLOB, CLOB

• LONG, LONG RAW

• NATURAL, NATURALN

• NCHAR, NCLOB, NVARCHAR2

• Tipos Objeto con atributos BLOB, CLOB, TABLE o VARRAY

• POSITIVE, POSITIVEN

• REF CURSOR

• SIGNTYPE

• STRING

• TABLE

• VARRAY

Es necesario distinguir entre tamaño y límite, donde tamaño es el número de

elementos que contiene la colección, y límite que es el número máximo de

elementos que puede contener. Cuando creamos un objeto de algún tipo

varray, la cantidad de memoria asignada estará en función de su tamaño y no

de su límite. Por ejemplo, si quisiéramos crear un arreglo de puntos llamado

arr_puntos con un límite de 100 elementos, sería:

CREATE OR REPLACE TYPE arr_puntos AS VARRAY(100) OF PUNTO;

Para crear un objeto del tipo Arr_puntos, usamos su constructor de la

siguiente manera:

...Arr_puntos(Punto(3,4),Punto(5,1));

Esto creará un varray de tamaño dos, que contendrá a los puntos (3,4) y (5,1)

en las posiciones 1 y 2, respectivamente.

Si necesitamos agregar un nuevo punto a un varray existente tendremos que

aumentar el tamaño del arreglo con el método EXTEND, dentro de un bloque

PL/SQL. Por ejemplo:

... Polilinea := Arr_puntos(Punto(3,4),Punto(5,1));

115


Polilinea.EXTEND; -- agrego un elemento null al final. Polilinea(3):=Punto(8,5); ...

Para eliminar el último elemento utilizamos el método TRIM,

... Polilinea.trim; ...

No podemos utilizar los métodos delete(n) o delete(m,n) sobre un varray. Si

queremos eliminar un elemento intermedio, tendremos que desplazar a la

derecha a todos sus sucesores y luego eliminar el último elemento con el

método TRIM.

Con respecto al almacenamiento de un varray en la base de datos, este será

almacenado en línea con la fila propietaria de la colección. Para aquellos

varrays donde el tamaño exceda los 4K, el excedente se almacenará fuera de

línea.

5.2.2.3 Tablas anidadas

Una Tabla anidada es un conjunto de elementos, sin un orden particular,

todos del mismo tipo. Ésta posee una única columna cuyo tipo puede ser un

tipo primitivo o un tipo objeto. Si es un tipo objeto, la tabla puede ser vista

también como una tabla de múltiples columnas, con una columna para cada

atributo del tipo objeto. Sintaxis para una tabla anidada es

TYPE type_name IS TABLE OF element_type [NOT NULL];

Type_name y element_type, tienen el mismo significado y restricciones que

en los varrays.

Oracle almacena una tabla anidada sin un orden particular, pero cuando

recuperamos una tabla anidada, desde la base de datos, y la almacenamos en

una variable de PL/SQL, a cada fila de la tabla se le asigna una posición o

subíndice que parte de uno (1). Esto permite acceder a la tabla anidada como

si fuera un varray, lo que simplifica su manipulación. Si manejamos la tabla

anidada desde PL/SQL podremos acceder a los métodos de la colección, de la

misma manera que con un varray.

116


Ya vimos las semejanzas entre los varray y las tablas anidadas, ahora

veremos en qué se diferencian [32]:

• Un varray está limitado a un máximo número de elementos, pero las

tablas anidadas no.

• En un varray no podemos eliminar directamente elementos

intermedios, pero en una tabla anidada sí.

• Oracle almacena los datos de un varray en línea con la tabla (en la

misma tabla), pero una tabla anidada es almacenada fuera de línea, en

una tabla generada por el sistema.

• Cuando almacenamos en la base de datos un varray, este retiene su

orden y subíndices, pero las tablas anidadas no.

• Desde SQL, no podemos insertar, modificar o eliminar, directamente,

elementos de un varray, pero sí sobre una tabla anidada.

• Podemos crear índices sobre tablas anidadas, pero no en un varray.

Para más información sobre tablas anidadas vea las referencias bibliográficas

[6], [30], [31], [32].


Como puede ver en la sección 2.2.3 el encapsulamiento abarca tres

aspectos:

1. Agrupar atributos y métodos en una sola entidad,

2. Distinguir entre interfaz (pública) e implementación (privada),

3. Asignar niveles de acceso individual a los atributos y métodos.

Los aspectos 1 y 2 están cubiertos en Oracle 8i, a través de los predicados

CREATE TYPE (ver 5.2.1.2.1 ) y CREATE TYPE BODY (ver 5.2.1.2.2 ).

Lamentablemente, el tercer aspecto no es soportado directamente, pero a

través de las vistas podemos restringir el acceso a los atributos.

117


5.2.4 Modularidad

En Oracle existe una estructura denominada paquete, que brinda

modularidad a los programas escritos en PL/SQL. Lamentablemente, no

podemos incluir un tipo objeto en estos paquetes. Sin embargo, podemos

agrupar los tipos objeto a través de los esquemas de usuarios, logrando así la

funcionalidad de un paquete.

5.2.5 Persistencia

En todas las bases de datos relacionales la estructura encargada de persistir o

almacenar información es la tabla. En Oracle podemos persistir objetos en

columnas de tablas relacionales, o en filas de una tabla de objetos. Una

tabla de objeto, es una clase especial de tabla que es construida en base a

un tipo objeto, donde cada fila de la tabla será una instancia de él, y cada

atributo del tipo, será una columna de la tabla [30].

Lamentablemente, si está interesado en construir una base de datos

distribuida utilizando las capacidades de replica de Oracle, no podrá replicar

las columnas de una tabla relacional que almacene objetos. Tampoco podrá

replicar una tabla de objetos.

Las operaciones básicas sobre tablas son : creación, modificación y

eliminación.

5.2.5.1 Manejo de tablas (relacionales y de objetos)

Como aclaración, no pretendemos explicar toda la sintaxis, para el manejo de

tablas, por ser muy extenso, la intención es dar una idea clara de cómo

trabajar con ellas.

5.2.5.1.1 Creación (Create Table)

Como mencionamos anteriormente, podemos definir una columna de una

tabla relacional en base a un tipo objeto. Por ejemplo: consideremos el

tipo punto definido en secciones anteriores como:

118



Y number, MEMBER PROCEDURE moverA(X IN number, Y IN number), MEMBER PROCEDURE moverA(P IN Punto), MEMBER FUNCTION distanciaA(p IN Punto) RETURN NUMBER );

Pensemos ahora que necesitamos almacenar la información de un

triangulo y su identificador, para lograr esto, creamos una tabla relacional


CREATE TABLE triangulo (

id VARCHAR2(10) CONSTRAINT pk_emp PRIMARY KEY, A Punto CONSTRAINT nn_A NOT NULL, B Punto CONSTRAINT nn_B NOT NULL, C Punto CONSTRAINT nn_C NOT NULL

);

Como podemos observar, la definición de tablas relacionales sigue siendo

la misma, y el tipo Punto puede ser visto como un tipo más del sistema.

Otro aspecto importante es la simplificación de la tabla triángulo al usar el

tipo punto.

Para las aplicaciones orientadas a objeto, la forma más natural de

almacenarlos es a través de tablas de objetos. Por ejemplo, consideremos

los siguientes tipos:

CREATE TYPE Empleado; CREATE TYPE Departamento AS OBJECT ( Nombre VARCHAR2(10), Jefe REF Empleado );

CREATE TYPE Empleado AS OBJECT ( rut VARCHAR2(10), nombre VARCHAR2(10), cargo VARCHAR2(9), fechaIng DATE, sueldo NUMBER(9), comision NUMBER(9), anticipo NUMBER(9), depto REF Departamento, MEMBER FUNCTION sueldo_liquido RETURN NUMBER, MEMBER PROCEDURE aumento_sueldo (aumento NUMBER) ); La construcción de tablas de objetos es muy sencilla, por ejemplo,

podemos crear una tabla denominada tbl_emp para almacenar a los

119


empleados, y otra denominada tbl_dep para los departamentos, de la

siguiente manera:

CREATE TABLE tbl_emp OF Empleado; CREATE TABLE tbl_dep OF Departamento;

Como puede observar, no definimos columnas para la tabla tbl_emp, ni

para tbl_dep, porque estas se definen automáticamente a partir de los

tipos Empleado y Departamento, respectivamente. Tampoco es posible

agregar columnas adicionales.

Al momento de definir las tablas de objeto, podemos imponer

restricciones como: NOT NULL, UNIQUE, CHECK, o definir valores por

defecto con DEFAULT sobre las columnas de una tabla de objeto, al igual

que en las tablas relacionales. Por ejemplo:

CREATE TABLE tbl_emp OF Empleado ( CONSTRAINT rut_cons UNIQUE(RUT), CONSTRAINT sueldo_cons CHECK(sueldo IS NOT NULL), fechaIng DEFAULT SYSDATE, CONSTRAINT anticipo_cons CHECK(anticipo >= 0) ); Otro tipo de restricción tiene que ver con las referencias de objeto a las

cuales podemos imponer restricciones de integridad, como si fueran

claves foráneas de tablas relacionales. Por ejemplo:

CREATE TABLE tbl_emp OF Empleado ( FOREIGN KEY(depto) REFERENCES tbl_dep ON DELETE CASCADE ); CREATE TABLE tbl_dep OF Departamento ( FOREIGN KEY (Jefe) REFERENCES tbl_emp );

Cada instancia almacenada en una tabla de objeto posee un identificador

de objeto único denominado OID [31]. Este identificador permite que el

objeto almacenado pueda ser referenciado externamente, ya sea desde

otros objetos, desde columnas de tablas relacionales o desde un lenguaje

de programación como JAVA. En Oracle, podemos especificar que el OID

sea generado por el sistema o una clave primaria. Un OID generado por

el sistema es un número de 16 bytes de largo, que es único en toda la

base de datos e independiente de los valores actuales de los atributos del

objeto. Un OID basado en la clave primaria es único dentro de la tabla y

120


depende de los valores del objeto. El tipo de OID a utilizar se especifica al

momento de crear la tabla de objeto utilizando las palabras reservadas

OBJECT IDENTIFIER IS PRIMARY KEY u OBJECT IDENTIFIER IS SYSTEM

GENERATED. Al no especificar el tipo de OID, este será generado por el

sistema. Por ejemplo, si queremos definir un OID del tipo clave primaria

para las instancias del tipo empleado, almacenadas en la tabla tbl_emp,

tendremos que escribir lo siguiente:

CREATE TABLE tbl_emp OF Empleado (rut PRIMARY KEY) OBJECT IDENTIFIER IS PRIMARY KEY; Aunque innecesario, podemos especificar que el identificador de objeto

sea generado por el sistema, de la siguiente manera:

CREATE TABLE tbl_emp OF Empleado OBJECT IDENTIFIER IS SYSTEM GENERATED;

Como restricción no podemos especificar un OID en una tabla relacional,

puesto que las filas no son objetos.

5.2.5.1.2 Modificación (Alter Table)

Mediante el predicado ALTER TABLE [41] podemos agregar eliminar o

modificar las columnas de una tabla relacional, pero no sobre una tabla de

objetos. Además de alterar las columnas, el predicado ALTER TABLE

permite agregar, modificar, eliminar o deshabilitar restricciones sobre

tablas relacionales o sobre tablas de objeto. Por ejemplo, si queremos

eliminar las restricciones sueldo_cons y anticipo_cons de la tabla

tbl_emp sería:

ALTER TABLE tbl_emp DROP (sueldo_cons, anticipo_cons);

5.2.5.1.3 Eliminación (Drop Table)

Para la eliminación de tablas relacionales y de tablas de objetos,

utilizamos el predicado DROP TABLE. Las siguientes sentencias, nos

permiten borrar la tabla relacional triangulo y la tabla de objetos

tbl_emp, creadas anteriormente

DROP TABLE triangulo; DROP TABLE tbl_emp;

121


Como puede observar la eliminación de una tabla de objeto es idéntica a la

de una tabla relacional.

5.2.5.2 Manejo de objetos

Luego que hayamos definido las tablas que almacenarán nuestros objetos,

podemos empezar a trabajar con las instancias. Para esto contamos con

varios predicados que nos permitirán insertar, consultar, modificar o eliminar

objetos persistentes, que son los mismos que empleamos al trabajar con

tablas relacionales, pero que tienen algunas características nuevas, para dar

soporte al manejo de objetos. En los siguientes párrafos se describen dichos

predicados.

5.2.5.2.1 Inserción de objetos (INSERT INTO)

Para la inserción de objetos, utilizamos el predicado INSERT INTO, ya sea

al insertarlo como columna en una tabla relacional o como una fila en una

tabla de objetos. Si quisiéramos insertar una fila en la tabla triángulo,

descrita en la sección 5.2.5.1.1 (creación de tablas) sería:

INSERT INTO triangulo VALUES (“TR – 0001”,PUNTO(12,5),PUNTO(5,25),PUNTO(19,25));

Para aquellas columna definidas a partir de un tipo objeto, el sistema

esperará una instancia de ese tipo, al momento de pasar el valor

correspondiente a la columna. Para crearla, utilizaremos el constructor del

tipo, como en el ejemplo anterior, donde utilizamos el constructor PUNTO,

para asignarle valores a las columnas a, b, c, que representan a los

vértices del triángulo.

Para el caso de las tablas de objeto, la inserción es muy similar. Por

ejemplo: si quisiéramos insertar un empleado a la tabla tbl_emp definida

en la sección 5.2.5.1.1 (creación de tablas) sería:

INSERT INTO tbl_emp Values(‘13131344-6’, ‘Miguel’, ‘Ingeniero’, SYSDATE, 600000, 10000, 0,null);

122


El orden de los valores debe coincidir con el orden de los atributos del tipo

en el que se basa la tabla de objetos. Si un atributo está definido en base

a otro tipo objeto, será necesario utilizar el constructor respectivo, al igual

que en el primer ejemplo de esta sección (inserción de un triángulo),

pudiendo anidar constructores, cuando sea necesario.

Alternativamente, podemos utilizar el constructor del tipo objeto

empleado para realizar la inserción. Lo anterior quedaría:

INSERT INTO tbl_emp Values( Empleado(‘13131344-6’, ‘Miguel’, ‘Ingeniero’, SYSDATE,

600000,10000, 0,null) );

Para las columnas que sean del tipo REF, necesitaremos utilizar una

subconsulta para obtener el valor correspondiente. Por ejemplo,

consideremos la tabla de departamentos de la sección 5.2.5.1.1 (creación

de tablas) , la inserción de una instancia de Departamento, quedaría:

INSERT INTO tbl_dep Values( Departamento(‘Departamento de Informática’, (SELECT REF(e) FROM tbl_emp e WHERE e.rut = ‘13131344-6’) ) );

Para el empleado insertado anteriormente, será necesario actualizar el

atributo depto, para que apunte al departamento correspondiente. Dicha

actualización la mostraremos, más adelante, en la sección 5.2.5.2.3

(update).

También podemos insertar objetos a partir de otra tabla, siempre y cuando

sean compatibles. Por ejemplo:

INSERT INTO tbl_emp select value(emp) from tbl_emp2 emp emp.nombre like ‘R%’;

En este ejemplo se copian los objetos de la tabla emp2 cuyo atributo

nombre empieza con R, pero a cada uno se le asignará un nuevo OID.

Si hacemos la inserción desde PL/SQL, podemos obtener el OID del objeto

insertado en la misma sentencia INSERT. Por ejemplo, consideremos que

123


queremos insertar un objeto del tipo Empleado previamente definido,

llamado emp, en la tabla tbl_emp, y queremos guardar el OID del objeto

insertado en la variable OID_Emp que también fue previamente definida,

sería:

... insert into tbl_emp e values(emreturning ref(e) into OID_emp;

p)

...

La cláusula returning ref es muy útil cuando tenemos un objeto que

posee un atributo que es una referencia a otro, y queremos insertar ambos

objetos en una misma transacción.

5.2.5.2.2 Selección de objetos (SELECT ... FROM)

Podemos realizar consultas con el predicado SELECT sobre tablas de

objeto como si fueran tablas relacionales, donde los atributos del objeto

son las columnas de la tabla. Por ejemplo:

SELECT * FROM tbl_emp emp WHERE emp.sueldo >100

Aquí se obtienen todos los empleados de la tabla tbl_emp (definida en la

sección 5.2.5.1.1 ) cuyo sueldo base sea mayor a 100.

Las consultas pueden invocar a las funciones miembro de un objeto y

utilizarlas como si fueran columnas. Por ejemplo:

SELECT rut,nombre, emp.sueldoLiquido() FROM tbl_emp emp WHERE emp.sueldoLiquido() < 100

Este ejemplo retorna el rut, el nombre y el sueldo líquido de todos los

empleados de la tabla tbl_emp cuyo sueldo líquido es menor que 100.

Esto también es válido para las tablas relacionales con columnas definidas

a partir de un tipo objeto. Por Ejemplo:

SELECT * FROM from triangulo t WHERE t.a.distanciaA(b) = 100

124


Este ejemplo entrega todos los triángulos cuyo lado AB mida 100.

La principal ventaja al usar referencias de objeto es la simplificación de las

consultas. Por ejemplo, para saber el nombre del departamento al que

pertenecen los empleados bastaría con:

SELECT rut,nombre, emp.depto.nombre FROM tbl_emp emp;

Bajo el enfoque tradicional, sería necesario utilizar un JOIN para obtener el

nombre del departamento, pero acá basta con utilizar la referencia depto.

5.2.5.2.3 Modificación de objetos (UPDATE)

Para modificar una instancia almacenada en una tabla de objetos

utilizamos el predicado UPDATE. Por ejemplo:

UPDATE tbl_emp emp SET emp.sueldo=emp.sueldo * 1.15 WHERE emp.sueldoLiquido() < 100

Aquí le aumentamos el sueldo base, en un 15%, a todos los empleados de

la tabla_emp (definida en la sección 5.2.5.1.1 ) cuyo sueldo líquido es

inferior a 100.

También podemos reemplazar el valor de todos los atributos del objeto

con los de otro. Por ejemplo

UPDATE tbl_emp emp SET emp= Empleado(‘13131344-6’, ‘Miguel R.’, ‘Ingeniero’, SYSDATE, 800000,20000, 0,null) WHERE emp.rut =’13131344-6’

La forma más natural de modificar los atributos de un objeto es a través

de sus métodos. Lamentablemente, estos métodos no podrán invocarse

sobre objetos persistentes, debido a las restricciones impuestas por

Oracle.

Cuando explicamos la inserción de objetos, dejamos pendiente la

actualización del atributo depto que es una referencia a una instancia de

Departamento. Para realizar esta actualización sería:

UPDATE tbl_emp emp SET emp.depto = ( SELECT REF(d) FROM tbl_dep

125


WHERE d.nombre =’Departamento de Informática’) WHERE emp.rut =’13131344-6’

5.2.5.2.4 Eliminación de objetos (DELETE)

Para eliminar objetos de una tabla de objetos utilizamos el predicado

DELETE. Por ejemplo:

DELETE FROM tbl_emp emp WHERE emp.sueldoLiquido() < 100 Aquí se eliminan todos los empleados cuyo sueldo líquido sea menor a

100.

5.2.6 Jerarquía de Clases 5.2.6.1 Asociación

Para implementar las asociaciones utilizamos las referencias de objetos. Por

ejemplo, supongamos que queremos implementar la asociación entre una

persona y una organización:

Organización PersonaParticipa

1 *

Para implementar esta relación, será necesario agregar un atributo en el tipo

objeto Persona que sea una referencia al tipo Organización. La

implementación de los tipos quedaría:

CREATE TYPE Organizacion AS OBJECT ( id NUMBER, Nombre VARCHAR2(30) ); CREATE TYPE Persona AS OBJECT ( rut NUMBER, Nombre VARCHAR2(30), Org REF Organizacion );

Si la multiplicidad de la asociación fuera uno a uno, cualquiera de los tipos

puede tener la referencia al otro.

126


Si la multiplicidad de la asociación fuera Muchos a muchos, o la asociación

en sí misma tenga atributos, será necesario crear un tipo objeto para

implementarla. Por ejemplo, supongamos que la asociación entre una

organización y una persona fuera:

Organización Persona

Participantes

Participa

* *

Y quisiéramos almacenar el rol o papel que desempeña la persona en la

organización, los tipos objeto quedarían:

CREATE TYPE Organizacion AS OBJECT ( id NUMBER, Nombre VARCHAR2(30) ); CREATE TYPE Persona AS OBJECT ( rut NUMBER, Nombre VARCHAR2(30) );

CREATE TYPE Participantes AS OBJECT ( persona REF Persona, Org REF Organizacion, Rol VARCHAR2(50) );


La agregación podemos implementarla de la misma manera que una

asociación. Pero, como la asociación refleja una relación todo-parte, en la

mayoría de los casos, será más conveniente implementarla a través de un tipo

colección que almacene referencias de objetos. Por ejemplo, podemos crear

una tabla anidada llamada lista_per que almacene referencias a

participantes, y crear una columna en Organización llamada lista del tipo

Lista_per. La definición de tipos para este ejemplo quedaría:

CREATE TYPE Persona AS OBJECT ( rut NUMBER,

127


Nombre VARCHAR2(30) ); CREATE TYPE lista_per AS TABLE OF REF Persona; CREATE TYPE Organizacion AS OBJECT ( id NUMBER, Nombre VARCHAR2(30), Lista lista_per );

La composición, por su naturaleza, no debe representarse a través de

referencias de objetos, puesto que las partes sólo pertenecen a un agregado,

y se destruyen junto con él. En lugar de eso, utilizamos los objetos

directamente. Si el ejemplo anterior fuera una relación de agregación,

tendríamos que definir la tabla anidada lista_per como una tabla de

personas:

CREATE TYPE lista_per AS TABLE OF Persona;

Para aquellas composiciones, donde haya una asociación uno a uno el todo

contendrá un atributo del tipo de datos del tipo asociado. Por ejemplo, si

una organización tuviera una sola persona como miembro quedaría:

CREATE TYPE Persona AS OBJECT ( rut NUMBER, Nombre VARCHAR2(30) ); CREATE TYPE Organizacion AS OBJECT ( id NUMBER, Nombre VARCHAR2(30), Per Persona );

5.2.6.3 Herencia y Polimorfismo

En Oracle 8i La herencia no es soportada, y la única forma de polimorfismo es

la sobrecarga de métodos.

En todo caso, si necesitamos modelar relaciones de herencia, podemos

simularla a través de agregación o composición, y tendremos que dar un

soporte manual al polimorfismo. Existen varias estrategias para realizar esto,

por ejemplo, si A es la clase padre, y B, C sus subclases, podríamos crear un

128


tipo objeto para cada uno, donde B y C tendrían un atributo llamado super,

que sería una referencia a A, el que nos permitiría acceder a sus atributos y

métodos. El único problema con esta implementación es que no satisface

una característica esencial de la herencia, donde una instancia de B o C

también es de A, en la práctica, si tenemos una colección que almacena

instancias de A, una instancia de B debería ser posible de almacenar. Una

solución a esto es crear el tipo A como una composición, es decir, con un

atributo para cada subclase, y una variable que indique el tipo particular de la

instancia almacenada. Este último enfoque fue empleado por Oracle para

implementar el SQL espacial [35], que es un conjunto de tipos objeto que dan

soporte a la implementación de sistemas de información geográficos.

5.2.7 Concurrencia

La concurrencia podemos verla desde dos puntos de vista:

• Como un método con múltiples hilos de ejecución.

• Como varios usuarios manipulando el mismo objeto.

La concurrencia desde el primer punto de vista está resuelta, si

implementamos el método con JAVA, puesto que este lenguaje implementa

un robusto sistema para el manejo y sincronización de múltiples hilos de

control.

Desde el segundo punto de vista, la concurrencia también es soportada,

permitiendo que varios usuarios utilicen y modifiquen el mismo objeto,

permitiendo bloqueos manuales o automáticos que garantizan la consistencia

y la integridad del objeto.

5.2.8 Manejo de Versiones de objetos y Configuraciones

Lamentablemente, Oracle no provee mecanismos para manejar versiones y

configuraciones de objetos.

129


5.2.9 Evolución de esquemas y de Instancias

La evolución de esquemas se refiere a la capacidad de modificar la estructura

de los tipos, agregando, modificando o eliminando métodos o atributos y que

estos cambios sean reflejados en todas las estructuras que dependan de él.

La evolución de instancia apunta a dos cosas, la primera es que al alterar un

tipo, dicho cambio debe verse reflejado en las instancias y la otra es contar

con la posibilidad de migrar instancias entre tipos.

En Oracle 8i, existe una forma restringida de evolución. A diferencia de una

tabla relacional, un tipo no puede ser alterado, solamente podemos agregar

métodos (vea 5.2.1.6 ), cambio que no afecta a los tipos, tablas o vistas que

dependen de él.

Esta carencia junto con la de herencia son las limitaciones más significativas

que tiene Oracle, Aunque con un poco más de trabajo, podremos lograr esta

funcionalidad. Una solución a este problema es crear una tabla relacional con

los atributos del objeto como columna y una vista de objeto sobre la tabla

relacional. Luego utilizaremos la vista de objeto como si fuera una tabla de

objetos, y cuando necesitemos agregar, modificar o eliminar la definición de

un atributo, lo haremos sobre la tabla relacional, y luego modificaremos

nuestra vista de objeto.

No se pueden migrar instancias entre tipos en Oracle 8i.

5.2.10 Transacciones y recuperación ante fallos.

Estas características están presentes en Oracle desde varias versiones atrás, y

de hecho son uno de sus puntos más fuertes.

Una transacción, es una unidad lógica de trabajo que contiene una o más

sentencias SQL que pueden ser todas aplicadas a la base de datos o ninguna.

La utilidad de una transacción es que nos permite impedir que los cambios

producidos por las sentencias SQL ya ejecutadas se apliquen a la base de

130


datos, al ocurrir alguna excepción, manteniendo así la consistencia y la

integridad.

En lo referente a la recuperación ante fallos, existen varios errores que Oracle

soluciona automáticamente y otros requieren de una mínima intervención del

usuario. Otra característica importante, es que la mayoría de los fallos

pueden ser superados sin la necesidad de bajar el servidor.

5.2.11 Mecanismos de autorización

Al igual que en SQL:1999, los mecanismos de autorización están basados en

las tablas y en los tipos objeto. Se autoriza o restringe el acceso y

manipulación de las tablas o tipos objeto, pero no se puede restringir el

acceso sobre un objeto o una fila.

5.2.12 Compatibilidad con el modelo relacional

Oracle posee una alta compatibilidad con el modelo relacional, permitiendo

que interactúen las estructuras relacionales con las nuevas estructuras.

Además permite la creación de vistas de objeto sobre tablas relacionales.

Una vista de objetos, se basa en el resultado de una consulta y en un tipo

objeto, que definirá las columnas de la vista. La consulta pude estar basada

en varias tablas, sean relacionales o de objeto. Al consultar una vista de

objetos, se obtendrá un conjunto de instancias del tipo objeto en el que se

base la vista.

Por ejemplo: supongamos que una empresa posea una tabla que almacena a

todos sus departamentos, y que fue creada de la siguiente manera:

CREATE TABLE departamento ( ID_Dep NUMBER (10) NOT NULL PRIMARY KEY, Nombre VARCHAR2 (50) );

Para crear una vista de objetos de esta tabla, primero tendremos que crear un

tipo objeto cuyos atributos serán las columnas de la tabla departamento, y

luego podremos crear nuestra vista de objeto.

131


CREATE TYPE dep_T ( ID_Dep NUMBER, Nombre VARCHAR2 (50) ); CREATE VIEW dep_ObjView OF dep_T WITH OBJECT OID (ID_Dep) AS SELECT ID_Dep, Nombre FROM DEPARTAMENTO;

Al crear la vista, debemos indicar que cree el OID de los objetos a partir de

la clave primaria de la tabla relacional.

Crear esta clase de vistas permite acceder a toda la capacidad del manejo de

objetos, como invocación de métodos y referencias a objetos, sin tener que

migrar los datos de las tablas relacionales.

5.2.13 Limitaciones encontradas en Oracle 8i

En Oracle 8i, encontramos las siguientes limitaciones, referente al manejo de

objetos:

• Un tipo no puede tener más de 1000 atributos

• No podemos sobrecargar el constructor definido por el sistema, ni

redefinirlo. Tampoco podrá crear nuevos constructores.

• Los procedimientos miembro de un tipo, no pueden ser invocados

desde SQL.

• Las funciones miembro de un tipo, que posean uno o más parámetros

pasados como INOUT o OUT, no pueden ser invocados desde SQL.

• No podemos modificar la definición de atributos o métodos existentes

de un tipo objeto. Sólo podemos agregar nuevos métodos.

• No podemos replicar tablas de objetos.

• No podemos tener colecciones que almacenen colecciones, ni

colecciones de objetos que posean un atributo de un tipo de

colección.

• No podemos definir colecciones en base a ciertos tipos de datos como

por ejemplo: BOOLEAN, BLOB, CLOB, LONG, LONG RAW, y otros.

• No podemos especificar un nivel de encapsulamiento (private, public,

protected) para los atributos, ni para los métodos.

• No podemos definir Jerarquías de Herencia, ni simple, ni múltiple.

132


• No podemos duplicar las tablas de objeto en Oracle 8i.

133

5.3 Evaluación

En este capítulo evaluaremos la implementación que hace el SABD Oracle 8i

del paradigma de la orientación a objeto, utilizando los mismos criterios de la

evaluación del estándar SQL:1999. El objetivo de esta evaluación es

determinar en que porcentaje son soportadas las características de la

orientación a objeto (ver 2) y los requerimientos para las bases de datos

orientadas a objeto (ver 3.1.2.1), por parte del SABD Oracle 8i. Junto con

ello, agregaremos la evaluación realizada para el estándar SQL:1999, para

facilitar su comparación.

5.3.1 Criterios de evaluación

Para la evaluación del soporte dado por Oracle 8i a la Orientación a Objeto,

utilizaremos los mismos criterios y la misma valoración utilizada en el

capítulo anterior para evaluar SQL-1999. Estos son:

1. Definición de tipos o clases

a. Definición de atributos estáticos

b. Definición de atributos de instancia

c. Constructores definidos por el usuario

d. Métodos estáticos

e. Métodos de instancia

f. Sobrecarga de métodos

g. Definición de colecciones

h. Clases abstractas

2. Encapsulamiento

a. Atributos y métodos en una sola entidad

b. Distinguir entre interfaz e implementación

c. Visibilidad de métodos (Ej.: Public, private, protected)

d. Visibilidad de atributos (Ej.: Public, private, protected)

3. Modularidad

4. Jerarquía de clases o tipos

a. Asociación

134

Oracle 8i y la orientación a objeto – Evaluación

b. Agregación y Composición

c. Herencia Simple

d. Herencia Múltiple

e. Polimorfismo

5. Concurrencia

a. Métodos con múltiples hilos de control

b. Concurrencia de usuarios.

6. Persistencia de objetos

a. Creación

b. Modificación

c. Eliminación

d. Consulta

e. Identificadores de objetos

7. Versiones y configuraciones de objetos

8. Evolución de instancias

9. Evolución de esquemas

a. Agregar Atributos

b. Agregar Métodos

c. Agregar Restricciones sobre objetos persistentes

d. Eliminar Atributos

e. Eliminar Métodos

f. Eliminar Restricciones

g. Modificar definición de atributos

h. Modificar Interfaz de métodos

i. Modificar Implementación de métodos

j. Modificar Restricciones

k. Deshabilitar y habilitar restricciones

10. Transacciones y recuperación ante fallos

11. Mecanismos de autorización basados en objetos

12. Compatibilidad con el modelo relacional.

Si la característica... Valoración

Está presente 100%

No está presente, pero se puede simular 60%

No está presente 0%

135


5.3.2 Matriz de evaluación

Valoración

Oracle 8i

Valoración

SQL:1999

Características

Parcia

l

Fin

al

Parcia

l

Fin

al

1. Definición de tipos o clases 85% 95%

a. Definición de atributos estáticos 60% 60%

b. Definición de atributos de instancia 100% 100%

c. Constructores definidos por el

usuario

60% 100%

d. Métodos estáticos 100% 100%

e. Métodos de instancia 100% 100%

f. Sobrecarga de métodos 100% 100%

g. Definición de colecciones 100% 100%

h. Clases abstractas 60%

100%

2. Encapsulamiento 80% 80%

a. Atributos y métodos en una sola

entidad

100% 100%

b. Distinguir entre interfaz e

implementación

100% 100%

c. Visibilidad de métodos (Ej.:Public,

private, protected)

60% 60%

d. Visibilidad de atributos (Ej.: Public,

private, protected)

60%

60%

3. Modularidad 60% 60%

4. Jerarquía de clases o tipos 82% 92%

a. Asociación 100% 100%

b. Agregación y Composición 100% 100%

c. Herencia Simple 60% 100%

d. Herencia Múltiple 60% 60%

e. Polimorfismo 60%

100%

5. Concurrencia 100% 100%

136


a. Métodos con múltiples hilos de

control

100% 100%

b. Concurrencia de usuarios. 100%

100%

6. Objetos Persistentes 100% 100%

a. Creación 100% 100%

b. Modificación 100% 100%

c. Eliminación 100% 100%

d. Consulta 100% 100%

e. Identificadores de objetos 100%

100%

7. Versiones y configuraciones de

objetos

0% 0%

8. Evolución de instancias 0% 60%

9. Evolución de esquemas 80% 92%

a. Agregar Atributos 60% 100%

b. Agregar Métodos 100% 100%

c. Agregar Restricciones sobre objetos

persistentes

100% 100%

d. Eliminar Atributos 60% 100%

e. Eliminar Métodos 60% 100%

f. Eliminar Restricciones 100% 100%

g. Modificar definición de atributos 60% 60%

h. Modificar Interfaz de métodos 60% 60%

i. Modificar Implementación de

métodos

100% 100%

j. Modificar Restricciones 100%

100%

10. Transacciones y recuperación ante

fallos

100% 100%

11. Mecanismos de autorización basados

en objetos

60% 60%

12. Compatibilidad con el modelo

relacional.

100% 100%

Promedio 70,58% 78,25%

137

6 Una Aplicación de ejemplo

6.1 Introducción

En este capítulo se describirá un prototipo desarrollado bajo el paradigma de

la orientación a objeto, utilizando como lenguaje a Java y Oracle 8i para hacer

persistir a los objetos.

El prototipo esta relacionado con la gestión de recursos hídricos, tema que, a

juicio personal, es muy interesante y complejo a la vez. Por esta razón y para

una mejor comprensión del prototipo que expondremos más adelante,

veamos primero lo siguiente.

6.1.1 Importancia del recurso hídrico [29]

El mundo cuenta con grandes reservas de agua dulce, sobre 37 millones de

Km3, que exceden cualquiera necesidad imaginable de la población humana,

como por ejemplo los siguientes usos: riego, agua potable, generación de

energía industrial y minería, navegación, recreación, control de calidad,

control de crecidas, protección y conservación del medio ambiente, bebida

animal, refrigeración de plantas nucleares, turismo, etc.

Sin embargo, la mayor parte del recurso no nos es accesible, ya que más de

las tres cuartas partes de las reservas se encuentran retenidas en los

glaciares y en el hielo polar, y el resto muestra una distribución irregular de

un lugar a otro y de una estación a otra.

Es por lo anterior, que en la mayoría de las regiones del planeta sólo se

puede alcanzar un nivel de aprovechamiento adecuado y rentable mediante

una planificación y una gestión activa de los recursos hídricos.

Aunque el agua cae del cielo, no es gratuita, y la intervención del hombre en

un ciclo natural acarrea siempre un costo, precio que a veces resulta muy

caro.

139

Una aplicación de ejemplo - Introducción

La planificación de los recursos hídricos tiene por objetivo fundamental dar el

máximo aprovechamiento al recurso en forma integral.

6.1.2 Gestión del recurso hídrico en Chile

La Dirección General de Aguas (DGA) del Ministerio de Obras Públicas de

Chile (MOP) es la encargada de planificar y gestionar los recursos hídricos con

los que cuenta el país. Los objetivos de carácter general de la planificación de

los recursos hídricos son [29]:

Perfeccionar las técnicas de control y manejo del agua.

Desarrollar y mejorar los métodos para conservar y aumentar las

disponibilidades de agua en cantidad y distribución temporal.

Desarrollar y mejorar los métodos de control de contaminación, de

modo de proteger y mejorar la calidad de los recursos hídricos.

Desarrollar y mejorar los métodos y la eficiencia de la recolección

de los datos de terreno necesarios para lograr una adecuada

planificación y diseño de las obras de aprovechamiento del agua.

Desarrollar y mejorar los métodos de evaluación de los desarrollos

de los recursos hidráulicos de modo de obtener una maximización

de los beneficios socioeconómicos netos.

Para llevar a cabo su tarea, la DGA necesita contar con herramientas que le

permitan hacer pronósticos acertados, y predecir por ejemplo lo que

sucederá al intervenir el cause de un río con algún nuevo proyecto (embalse,

central hidroeléctrica, canales, etc). Algunas de estas herramientas

corresponden a los modelos de simulación2 hidrológica operacional [29],

los cuales representan los fenómenos hidrológicos en una cierta cuenca3,

además, incorporan todas las obras hidráulicas existentes o futuras.

2 La técnica de reproducir la esencia de un sistema sin reproducir el sistema en si 3 Territorio cuyas aguas afluyen todas a un mismo río, lago o mar

140


6.1.3 Modelación de cuencas y proceso de Simulación hidrológico operacional4.

Para facilitar el proceso de simulación, existen modelos de tipo general que

se caracterizan por tener previamente definidas las rutinas típicas de la

simulación, de modo que el usuario sólo realiza lo siguiente [29]:

• Definición de topología

• Ingreso de datos para cada elemento del modelo

• Procesar

Para realizar la simulación es necesario contar con un modelo de la cuenca

que nos interesa analizar (Definición de topología), La cual es modelada a

través de un conjunto interconectado de objetos cada uno de los cuales

representa un elemento hidráulico de la cuenca. Existen dos tipos de

objetos: Fijos y Variables [29].

Los objetos fijos, tienen una ubicación preestablecida, que no se puede

modificar, como tampoco sus atributos, porque estos objetos definen la

topología básica de la cuenca (al modificarse dejan de modelar la cuenca).

Los objetos fijos son los ríos o causes naturales más importantes y los Nodos

o lugares donde confluyen aportes o extracciones de caudales. En los nodos

se realiza un operación matemática denominada balance de caudal, cuya

fórmula general es:

Entrada – Salida = Variación de almacenamiento.

Dos nodos consecutivos dentro de un mismo río definen los tramos de río.

Por los tramos de ríos de la cuenca es por donde se mueven los caudales de

un nodo a otro según la dirección del flujo [29].

4 En esta sección no pretendemos enseñar a modelar cuencas reales, sólo dar los conocimientos

básicos para el diagrama de una cuenca modelada. Tampoco se verá en forma detallada el

proceso de simulación

141


Considerando solamente los objetos fijos (ríos y nodos) podríamos tener un

esquema de la modelación de una cuenca como el siguiente (figura 6) :

Simbología:

: Nodo

: Tram

o de Río

figura 6 : Esquema de una cuenca en base a ríos y nodos

Por su parte los objetos variables son posibles de ubicar en cualquier nodo y

modificar sus atributos. Los objetos variables corresponden a diferentes

elementos hidráulicos cuya función puede ser extracción, aporte, conducción,

consumo, generación o regulación de caudales. Estos son [29]:

• Aporte natural: Aporte de caudales a un nodo.

• Canal: Permite la conducción de un caudal máximo entre dos

nodos. (Son creados por el hombre).

• Hoya intermedia: Aporte de caudales a un nodo que corresponden

a aquellos caudales que son aportados a un tramo de río al cual el

nodo pertenece. Esto se debe a que en el modelo las entradas o

salidas de caudales sólo se pueden hacer en un nodo.

• Central hidroeléctrica: Realiza una captación de agua desde un

nodo inicial, genera energía eléctrica y entrega los caudales a un

nodo final sin consumo.

• Embalse: Obra de regulación de caudal que permite el

almacenamiento de agua.

• Zona de riego: Centro de demanda consuntiva de agua para el

sector agrícola.

• Captación de agua potable: Extracción de agua potable para el

consumo.

• Captación de uso industrial o minero: Extracción de agua para

consumo Industrial o minero

• Descarga contaminante: Aporte de caudales (contaminados) a un

nodo.

142


• Recuperación en el cauce: Punto donde se ha verificado una

recuperación de caudal en un río, que se supondrán concentradas

en un nodo específico.

• Pérdida en el cauce: Punto donde se ha verificado una pérdida de

caudal en un río, que se supondrán concentradas en un nodo

específico.

Ya explicamos todos los objetos que intervienen en el modelo de una cuenca,

sólo falta agregar, que estas se pueden dividir en sectores.

La figura 7 corresponde a un modelo real: La cuenca del río Maule, que por

motivos de espacio, sólo se mostrará el sector uno de dicha cuenca

(aproximadamente el 10% del diagrama total). En ella podemos apreciar la

mayoría de los objetos aquí descritos.

Este diagrama fue desarrollado por la Dirección General de Aguas del

Ministerio de Obras Públicas.

143


Abrevi

HI = Hoya In

F = Filtraci

R = Rebase

Ee = Entreg

Energí

Er = Entreg

Riego

G = Entregas

por cen

RN = Régime

Simb

Nodo

Nodcoincon epluv

Em

C CenHidrPro

Zon

C CenHidr

Rí

Can

ología

o cidente stación

iométrica

o o Estero

balse

tral oeléctrica

yectada

tral oeléctrica

al Principal

Derrames

a de Riego

144

aturas

termedia

ones

s

as para

a

as para

generables

tral Hidro.

n Natural

figura 7: Sector uno del esquema de la modelación de la cuenca del río Maule [29]


6.1.3.1 Simulación

Para realizar la simulación hidrológica en la cuenca del río Maule, la DGA

cuenta con un programa computacional, el cual toma como base información

estadística, las modificaciones hechas por el usuario, como por ejemplo

agregar un embalse, y un rango de años que indican el período de

simulación. La unidad mínima en este modelo es el mes, puesto que todas

las estadísticas de caudales se encuentran en esta unidad de tiempo. La

simulación comienza desde aguas arriba hacia aguas abajo, nodo por nodo.

En cada uno de los nodos se consideran todos los caudales de entrada y se

distribuye el agua por todas las salidas del nodo, las cuales en algunos casos

pasarán a ser entradas de otros nodos. Cada vez que se recorre el modelo

completo, se pasa al siguiente mes de simulación. El algoritmo de simulación

es el siguiente

Inicio Para cada año de simulación haga Para cada mes Para cada nodo del modelo haga

Operar Objetos que aportan caudal Distribuir caudales Opera embalses Balance hidrológico en el nodo Fin Para cada nodo Resultados de operación mensual Fin Para cada mes Resultados de operación anual Fin Para cada año Fin

Además existe un proceso de simulación especial llamado simulación de

temporada octubre a marzo [29]. Para desarrollarla se pronostican los

caudales medios mensuales de cada uno de los objetos del modelo

denominados “Hoya Intermedia” (H.I.) y Régimen natural (R.N), para cada uno

de los meses de octubre a marzo del año en que se hace la simulación.

Estos pronósticos, más los cambios en el modelo, son los datos de entrada

para la simulación, la que es idéntica a la anterior, salvo que esta tiene un

período fijo.

145

6.2 Descripción del Prototipo

El prototipo consiste en una aplicación que implementa una versión reducida

del modelo de simulación hidrológico operacional de tipo general, descrito en

la sección anterior, realizando únicamente la simulación de temporada, para

una cuenca que contemple los siguientes objetos:

Nodos

Ríos y tramos de río

Embalses

Central Hidroeléctrica de pasada

Canal Principal

Hoya Intermedia

Régimen Natural

Captación de agua potable

A partir de estos objetos podemos simular una cuenca como la mostrada en

la sección anterior (sector 1 de la cuenca del río Maule) si a esta

excluyéramos las zonas de riego, los derrames y los nodos coincidentes con

estación pluviométrica.

Los requerimientos del prototipo son:

Implementar una interfaz de usuario gráfica para mostrar el esquema

de la cuenca

Permitir la consulta de cualquier objeto de la cuenca pudiendo ser

antes o después de la simulación.

Realizar el proceso de simulación de temporada el que tendrá como

salida un informe con los caudales medios mensuales para cada

elemento (objeto) de la cuenca, en cada mes de simulación.

Responder a consultas como:

1. Embalses bajo sus volúmenes mínimos y rebasados.

2. Energía generada.

146

Una aplicación de ejemplo – Descripción del prototipo

6.2.1 Descripción de los objetos soportados

Para todos los objetos de la cuenca es necesario almacenar los atributos que

describen su ubicación y el caudal para cada mes de la simulación. Cabe

destacar que esta aplicación debe mostrar el esquema de una cuenca y no

una cuenca, por esto, los datos de ubicación son en el plano cartesiano y no

coordenadas terrestres como sucede en las aplicaciones SIG. Otro aspecto a

considerar, es que la simulación de temporada está basada en demandas y no

en derechos de agua, por esta razón, no es necesario almacenar la

información referente a los derechos.

6.2.1.1 Nodos.

El nodo es un objeto de tipo fijo, es decir que su ubicación y definición no es

posible de alterar en el modelo una vez que se ha definido. En cada nodo es

posible colocar cualquier objeto, a sola excepción de los cauces naturales

que son fijos.

Cada nodo representa un lugar de la cuenca donde confluyen aportes y

extracciones, de modo que es posible efectuar un balance de caudales. Sólo

en los nodos se puede efectuar balances hídricos en este modelo.

Para individualizar cada nodo, cada uno de ellos se denomina con dos

números separados por un guión. El primer número representa el sector, en

tanto que el segundo corresponde al número correlativo dentro del sector,

esto es útil cuando se tiene una cuenca dividida en subcuencas o sectores.

Cabe destacar que el número correlativo dentro del sector se debe definir de

modo que todos los caudales afluentes y extracciones estén determinados

previamente, para efectuar el respectivo balance hídrico. De este modo, se

puede definir la secuencia de los balances en los nodos, utilizando el

mencionado número correlativo.

147


Esquema

i-j

Información que se desea almacenar

Código del nodo, que se indica como 'NO i-j", donde 'i" es el número

del sector, 'j" es el número correlativo del nodo en el sector.

Cota del nodo.

6.2.1.2 Ríos y tramos de río.

Este es un objeto de tipo fijo al igual que los nodos. Corresponde a los ríos,

esteros o cauces naturales en general, los cuales pueden atravesar por varios

nodos en su trayecto. Dependiendo del número de nodos por los cuales pase

el río, se definen tramos, que se designan en forma correlativa, desde aguas

arriba hacia aguas abajo.

En el modelo de simulación, este es un objeto que permite la conducción del

caudal entre un nodo inicial y un nodo final, sin restricción de capacidad de

conducción.

Esquema

En el esquema, el rió se indica con una línea de trazo más grueso.

i-j )

Información

Có

No

Tr

No

Rio XXXX (Tramo K
m-n
que se desea almacenar

digo del río

mbre del río

amos del río,

do inicial y nodo final.

148


6.2.1.3 Embalses.

Este objeto representa una obra de regulación de caudal, que puede tener

varias entradas, tales como una hoya aportante o caudales en régimen

natural, como también canales alimentadores. El objeto embalse contempla

cinco tipo de salidas diferentes, a saber:

Filtraciones (F)

Entregas para energía, sin generar (Ee)

Entregas para riego (Er)

Rebases (R)

Caudal Generado (G)

El objeto embalse se ubica en un cierto nodo, pero cada una de sus salidas

puede definirse en nodos diferentes.

Esquema EV

F R Ee Er G

Abreviaturas:

Ev: Evaporación del embalse

R : Rebases

Ee: Entrega para energía (sin generar)

Er: Entrega para riego

G : Caudal generado en el embalse (central a pié de presa).

F : Filtraciones del embalse.


Código del objeto

Nodo

149


Capacidad máxima del embalse (volumen útil), en millones de metros

cúbicos.

Evaporación bandeja mensual, en milímetros.

Valores de superficie (hectáreas) y volúmenes (millones de metros

cúbicos).

Coeficiente de embalse. (Normalmente se utiliza 0,7).

Valores de caudal máximo posible de entregar por válvulas en m3/s y

volumen almacenado en millones de m3. (para verificación de entrega

máxima del embalse).

Valores de filtración en litros por segundo y volumen del embalse, en

millones de metros cúbicos.

Nodos de llegada de cada una de las salidas del embalse. (Son 5

valores)

Capacidad máxima de conducción de las entregas Er (riego), Ee

(energía) y G (generada).

Volumen inicial del embalse, en el primer mes de la simulación, en

millones de metros cúbicos.

Curva de alerta. Consiste en la definición de los volúmenes mínimos

que debe tener el embalse en cada mes, como condición deseable. Si

no se incluye este dato, no se verificará esta restricción de curva de

alerta.

6.2.1.4 Central Hidroeléctrica de pasada

Este objeto representa una central hidroeléctrica de pasada, que capta sus

aguas desde un nodo inicial y las entrega a un nodo final, sin consumo de

agua.

Esquema

i-j C m-n


Código del objeto

Nodo inicial.

Nodo Final.

150


Caudal máximo de generación en m3/s.

Caudal mínimo medio anual, en m3/s.

6.2.1.5 Canal Principal

Este objeto permite la conducción de un caudal máximo, con una eficiencia

de conducción dada, entre dos nodos.

Esquema

En el esquema, el objeto “canal" se representa a través de una flecha con

trazo doble, que indica el sentido del escurrimiento.

i-j Canal Principal

i-j


Código del objeto

Denominación del canal

Nodo inicial

Nodo final o punto de llegada

Capacidad de conducción en m3/s

Eficiencia de conducción en porcentaje.

Parámetros ‘a’, ‘b’ y ‘c’ de la captación del canal en un cauce natural y

que representa el caudal posible de captar por el canal en función del

caudal del río, según se indica en la figura siguiente :

a

b cCAUDAL DEL RIO

CAUDAL CAPTADO (m3/s)

(m3/s)

151


6.2.1.6 Hoya Intermedia

Corresponde a una estadística de caudales medios mensuales, que ingresan o

aportan al nodo y representan el aporte de la hoya intermedia de un río o

cauce natural entre dos nodos.

Esquema

i-j H.I.


Código del Objeto

Denominación de la Hoya Intermedia o nombre del río

Código del Nodo

Estadística de caudales.

Código del río al cual aporta la H.I.

6.2.1.7 Régimen Natural

Corresponde a una estadística de caudales medios mensuales, en régimen

natural, que ingresan o aportan al nodo.

Esquema

i-j R.N


Código del objeto

Denominación de los aportes

Nodo

Estadística de caudales.

152


6.2.1.8 Captación de Agua Potable

Este objeto representa una extracción de agua potable desde un nodo, para

el consumo. Requiere los valores de caudales medios mensuales de las

extracciones.

Esquema

i-j A.P.


Código del Objeto

Código del Nodo

Caudales de extracción medio mensual

153

6.3 Diseño del prototipo

Para el diseño del prototipo utilizamos la notación UML, pero no completa,

solamente los diagramas de clases y los diagramas de colaboración. Para los

lectores no familiarizados con UML en el apéndice B encontrará una breve

descripción. Una aclaración importante, por falta de información y de

tiempo, no fue posible encontrar información sobre la correcta operación de

un embalse, y la fórmula con la que se convierte un caudal a kilo watt. Por lo

tanto, estos dos aspectos del prototipo están desarrollados a partir de una

fórmula incorrecta, por lo tanto los resultados que pueda entregar el modelo

de simulación, serán incorrectos. En todo caso bastaría con corregir los

métodos que incorporan dichas fórmulas y el modelo quedaría correcto.

Tenga en cuenta que el objetivo de este prototipo es probar las capacidades y

limitaciones de Oracle 8i para el manejo de objetos y como interactúa este

con Java y no dar una solución acabada y óptima para el problema planteado.

6.3.1 Diagramas de clases 6.3.1.1 Clases implementadas en Oracle 8i

Comenzaremos analizando el conjunto de clases que representa a los objetos

de la cuenca, y que serán creadas en Oracle 8i para hacer persistir a los

objetos.

Para cada uno de los objetos de la cuenca soportados por el prototipo,

crearemos una clase. De este modo tenemos las siguientes:

Nombre de la Clase Descripción

Cuenca Representa a una cuenca

Nodo Representa a un nodo de la cuenca

Río Representa un Río de la cuenca

Embalse Representa a un embalse de la cuenca

Salida_Emb Representa a los flujos de salida de un embalse

Regimen_Natural Representa a un Régimen Natural

154

Una aplicación de ejemplo – Diseño del prototipo

Hoya_Inter Representa a una Hoya Intermedia

Cap_Agua_Pot Representa una Captación de agua potable

Central_hidro Representa una Central Hidroeléctrica

Canal Representa un Canal

Tramo Representa un tramo de Río, que transporta un

caudal desde un nodo inicial a un nodo final

Al analizar el problema, descubrimos que existe un conjunto de clases que en

términos generales son Flujos de caudales que aportan y/o extraen caudales

de un nodo. A partir de esto construimos el siguiente esquema de

generalización:

Flujo

Apor_extracExtraccionAportante

Salida_Emb Hoya_InterRegimen_Natural Cap_Agua_Pot Central_Hidro TramoCanal

Además de la jerarquía de generalización mostrada anteriormente, existen

otras relaciones entre las clases. Estas relaciones son:

• Un Río posee uno o muchos tramos

• Un embalse esta ubicado en un único nodo

• Un Embalse posee siempre cinco flujos de salida

• Un nodo posee uno o muchos flujos de entrada que le aportan

caudales, y uno o muchos flujos de salida que le extraen caudales.

• Dependiendo del tipo de flujo, éste puede poseer un nodo inicial, de

donde extrae un caudal y un nodo final a donde aporta un caudal. El

nodo inicial debe ser distinto al final, y un flujo debe poseer por lo

menos un nodo (sea inicial o final).

155


El siguiente diagrama muestra dichas relaciones:

Flujo

RioEmbalse

Nodo

Cuenca

1..*

0..1

Aporta

entrada

Nodo_Inicial1..*

0..1Extrae

Salida

Nodo_Final

Tramo

1..*

1*

1

Salida_Emb

1

0..1Está

5

1

Una cuenca es un conjunto de nodos, flujos, embalses, etc, pero como todos

estos objetos están enlazados directa o indirectamente con el nodo,

podemos representar una cuenca como un conjunto de nodos.

El conjunto de clases mostrado hasta ahora corresponde a las abstracciones

del dominio del problema, cuyos objetos deberán ser almacenados en la base

de datos. El siguiente diagrama muestra las clases a nivel de

implementación, incluyendo los atributos y métodos para cada clase.

Además de otras clases necesarias para la implementación. El tipo de dato

de los atributos corresponde a los tipos de Oracle.

156


Como la razón de ser de este prototipo es evaluar las capacidades de Oracle

8i en el soporte de objetos, la simulación es ejecutada directamente en el

servidor.

La clase arr_caudales, almacena los caudales para cada uno de los meses de

la simulación (6 meses, de octubre a marzo). Las clases Graf_nodo y

Graf_cuenca, forman parte la jerarquía de clases definidas para describir la

geometría de cada uno de los objetos del diagrama de la cuenca. El

siguiente Diagrama de clases muestra dicha jerarquía :

157


Como Oracle8i, no implementa la herencia, tuvimos que simularla a través

de la composición. La estrategia utilizada fue incluir en la superclase un

atributo para cada una de sus subclases, junto con otro que indicara el tipo

actual del objeto. Esto nos permite dar soporte a la substituibilidad de tipos,

es decir, permitir que donde se espere una instancia de una superclase,

también sea válida una instancia de la subclase. La misma estrategia

utilizamos para implementar la jerarquía de herencia de la clase flujo. El

siguiente diagrama muestra dicha implementación

158


El código necesario para implementar todas estas clases en Oracle 8i, se

encuentra en el anexo C.1, junto con ello, una explicación del tipo, de sus

atributos y métodos.

159


Para almacenar los objetos, se crearon cinco tablas, estas son:

• Tbl_Cuenca. Almacena objetos del tipo Cuenca

• Tbl_Rio. Almacena objetos del tipo Río

• Tbl_Nodo. Almacena objetos del tipo Nodo

• Tbl_Flujo. Almacena objetos del tipo Flujo

• Tbl_Emb. Almacena objetos del tipo Embalse

Como puede observar, no es necesario crear una tabla para cada subclase del

tipo flujo. Esto se debe a que el tipo flujo encapsula a todas las subclases.

El código para la implementación de estas tablas en Oracle 8i se encuentra en

el anexo C.2. Ahí también encontrará un ejemplo de inserción para cada uno

de los tipos existentes.

160


6.3.1.2 Clases implementadas en Java

Existe una utilidad llamada JPUB (Java Publisher) [34] que permite exportar los

tipos creados en Oracle 8i a Java. Por cada tipo objeto, esta utilidad crea dos

clases java, una para almacenar referencias al objeto y otra para almacenar al

objeto. Este conjunto de clases permiten el intercambio de objetos entre Java

y Oracle en forma transparente. Por ejemplo, para exportar el tipo

apor_extrac definido en Oracle a Java sería:

$ jpub –user=scott/tigre –sql=apor_extrac:AporExtracOra

Esto genera las clases AporExtracOra.java y AporExtracOraRef.java,

descritas en los anexos C.4.4.1 y C.4.4.2, respectivamente.

Para desarrollar el prototipo, lo primero fue generar las clases java con JPUB,

las cuales fueron agrupadas en el paquete objcuenca. Para eso fue necesario

agregar una línea de código (package objcuenca;) a cada una de las clases.

En C.4.4 encontrará una lista completa de las clases generadas con JPUB para

el prototipo.

Para mostrar visualmente cada uno de los objetos de la cuenca, definimos la

Interface Graficable y una clase para la superficie de dibujo llamada

LienzoCuenca.

«Interface»Graficable

+dibujar(d : Dibujante) : void+dimensionMinima() : Dimension+dlgAtributos() : void+getZoom() : int+loadFigura() : void+pertenece(p : Punto) : boolean+setZoom(zoom : int) : void

LienzoCuenca

+addFigura(f : Graficable) : void+buscarFigura(x : int, y : int) : Graficable+clearFiguras() : void+dibujarFiguras(g : Graphics ) : void+getZoom() : int+setZoom(zoom : int) : void+paint(g : Graphics) : void+reloadFiguras() : void+setVectorFiguras(f : Vector) : void

-lasFiguras : Vector-zoom : int

JPanel

1..*

0..*

161


Para lograr una independencia entre la superficie de dibujo y el dibujado de

los objetos, creamos una clase llamada Dibujante, que es la encargada de

dibujar en una instancia de LienzoCuenca, de manera que Graficable, no

accede directamente al lienzo, sino que lo haga a través de Dibujante

Dibujante

+drawCuadrado(cuad : CuadradoOra) : void+drawElipse(e : ElipseOra) : void+drawPolilinea(p : ArrPuntosOra) : void+drawPolilinea(p : PolilineaOra) : void+drawPolilineaDoble(p : ArrPuntosOra) : void+drawPolilineaDoble(p : PolilineaOra) : void+drawPolilineaGruesa(p : ArrPuntosOra) : void+drawPolilineaGruesa(p : PolilineaOra) : void+drawTriangulo(t : TrianguloOra) : void+setColorLinea(c : Color) : void+drawString(s : String, x : int, y : int, tam : int) : vo

-colorLinea : Color-g : Graphics-zoom : int

Para cada objeto de la cuenca que es mostrado gráficamente fue creada una

clase para mostrar los atributos descriptivos del objeto.

JDialog

frmEmbalse frmFlujo frmNodo

FrmCanal FrmTramoFrmCapAguaPot FrmCentralHidrofrmSalidaEmb frmRegNatfrmHoyaInter

Las pantallas que representan estos diálogos, las podemos encontrar en

C.3.9 al C.3.16.

Como las clases generadas con JPUB, no pueden ser mostradas directamente

sobre el LienzoCuenca, creamos tres clases GuiEmbalse, GuiNodo, GuiFlujo,

como subclases de EmbalseOraRef, NodoOraRef, FlujoOraRef

respectivamente; y las tres implementan la interfaz Graficable. La clase

GuiFlujo encapsula a todos los flujos. El siguiente diagrama muestra dicha

relación:

162


frmNodo

«Interface»GraficableNodoOraRef

frmEmbalse

ElipseOra

1

1

1

1

EmbalseOraRef

GuiNodo

+dibujar(d : Dibujante) : void+dimensionMinima() : Dimension+dlgAtributos() : void+getZoom() : int+loadFigura() : void+pertenece(p : Punto) : boolean+setZoom(zoom : int) : void

-codigo : String-frm : frmNodo-graf : ElipseOra-zoom : int

ElipseOra

1

1

1

1

GuiEmbalse

-alertaEmb() : boolean+dibujar(d : Dibujante) : void+dimensionMinima() : Dimension+dlgAtributos() : void+getZoom() : int+loadFigura() : void+pertenece(p : Punto) : boolean+setZoom(zoom : int) : void

-alerta : boolean-codigo : String-frm : frmNodo-graf : ElipseOra-zoom : int

frmFlujo

FlujoOraRef

GrafCuencaOra

1

1

1

1

GuiFlujo

-alertaEmb() : boolean+dibujar(d : Dibujante) : void+dimensionMinima() : Dimension+dlgAtributos() : void+getZoom() : int+loadFigura() : void+pertenece(p : Punto) : boolean+setZoom(zoom : int) : void-alertaFlujo() : boolean-colineales(a : Punto, b : Punto, c : Punto) : boolean-dibujarCentHidro(d : Dibujante) : void-dibujarFlujo(d : Dibujante) : void-dimensionMinima(fl : PolilineaOra) : Dimension-dimensionMinimaCh() : Dimension-dimensionMinimaGFlujo() : Dimension-pertenece(arr : ArrPuntosOra, p : Punto) : boolean-pertenece(gch : GrafCentHidroOra, p : Punto) : boolean-setZoomCentHidro(zoom : int) : void-setZoomGrafFlujo(zoom : int) : void

-alerta : boolean-frm : frmNodo-graf : ElipseOra-zoom : int

Como puede observar, utilizamos las clases que referencian a un objeto y no

las que almacenan directamente el objeto. Esto se debe a que estas últimas,

almacenan una copia del objeto persistente, lo que dificulta la modificación

del objeto y la consistencia entre la vista del usuario y la base de datos. Por

el contrario, las referencias de objetos, permiten a las aplicaciones obtener y

modificar el objeto persistente referenciado en cualquier momento, a través

de los métodos setValue(C) (actualiza el objeto referenciado con C) y

getValue() (obtiene el objeto referenciado).

163


La pantalla principal del prototipo es la clase frame1 cuyo código fuente

puede ser visto en C.4.2.1. El siguiente diagrama muestra la relación que

existe entre Frame1 y las demás clases.

CuencaOraRef

JPanel

FrmConeccion

BDObjCuenca

LienzoCuenca

Frame1

11

1

1

1

1

11

La clase Frame1, además de los atributos que son parte de la interfaz gráfica

estándar, cuenta con cuatro atributos, uno es del tipo CuencaOraRef, que

almacena una referencia a la cuenca que actualmente está siendo desplegada.

Otro es del tipo FrmConexion, que permite desplegar la ventana de conexión

y almacenar los datos necesarios para realizarla. Otro es del tipo

LienzoCuenca que almacena y muestra los objetos de la cuenca. Y por

último, un atributo del tipo BDObjCuenca. La clase BDObjCuenca es una

especialización de la clase ConectorJdbc que encapsula la conexión entre

java y la base de datos, almacenando los datos básicos para la conexión.

Estos son: el nombre del usuario (atributo usr), la contraseña (passwd), el

driver a utilizar para la conexión (driver) y la URL JDBC que indica la dirección

de la base de datos (url). El Atributo Connection, almacena la conexión entre

java y la base de datos. Los métodos de la clase ConectorJdbc permiten

abrir y cerrar una conexión, consultar el estado de la conexión (abierta o

cerrada), obtener y modificar el estado de los atributos (set y get). La clase

BDObjCuenca, no incorpora nuevos atributos, pero sí nuevos métodos que

permiten obtener los objetos de una cuenca, ingresar cuencas, ríos y flujos a

la base de datos, eliminar ríos y cuencas. El siguiente diagrama, muestra

dicha jerarquía:

164


BDObjCuenca

+eliminar(c : CuencaOra) : void+eliminar(c : RioOra) : void+getAllEmbalseoraRef(c : CuencaOra) : Vector+getAllFigRef(c : CuencaOra) : Vector+getAllFlujosOraRef(c : CuencaOra) : Vector+getAllNodoOraRef(c : CuencaOra) : Vector+getCuenca(codigo : String) : CuencaOra+getCuencaRef(codigo : String) : CuencaOraRe+getRioRef(codigo : String) : RioOraRef+Insertar(c : CuencaOra) : void+insertar(flujo : FlujoOra) : GuiFlujo+Insertar(c : RioOra) : void

ConectorJdbc

+close() : void+getConnection() : Connection+getDriver() : String+getOracleConnection() : OracleConnection+getPasswd() : String+getUrl() : String+getUsr() : String+isClosed() : boolean+isOpen() : boolean+open(url : String, driverName : String, user : String, passwd : String) : void+setDriver(driver : String) : void+setPasswd(passwd : String) : void+setUrl(url : String) : void+setUsr(usr : String) : void

connection : OracleConnection driver : String passwd : String url : String usr : String

La siguiente pantalla corresponde a Frame1, en ella podemos apreciar el

comportamiento final de las clases Frame1, LienzoCuenca, GuiNodo,

GuiFlujo y GuiEmbalse.

165


La parte blanca, donde se dibujan los objetos de la cuenca, corresponde a

una instancia de la clase LienzoCuenca. Las flechas corresponden a

instancias de la clase GuiFlujo, los óvalos a GuiNodo y los triángulos a

GuiEmbalse. La misma imagen, pero de un tamaño más grande, puede ser

vista en C.3.3

Las ventanas restantes: Frame1_AboutBox (C.3.17), FrmAbrirCuenca

(C.3.2), FrmCuenca (ver C.3.4), FrmModificarRio (C.3.7),

FrmResultConsulta (C.3.6), FrmSimular (ver C.3.5), FrmZoom (ver C.3.5),

son llamadas desde Frame1, dependiendo de la opción del menú utilizada

por el usuario. Para conocer las opciones del menú disponible vea las

pantallas desde C.3.18 a la C.3.23

6.3.2 Diagramas de colaboración

6.3.2.1 Simulación

El método que realiza la simulación corresponde a Simular() del tipo definido

en Oracle Cuenca. Este método es ejecutado en el servidor, y es invocado

desde la aplicación java a partir de un objeto del tipo CuencaOra. Antes de

mostrar el diagrama de colaboración para este método, veremos el contexto

en el que es invocado.

Cuando el usuario escoge la opción del menú cuenca (D.3.18) “Iniciar

simulación...” de la clase Frame1. Esta opción abre la ventana de simulación

(FRMSimular), pasándole como parámetro una referencia de Frame1 y otra

al atributo dataBase de Frame1 que almacena la conexión abierta entre el

programa y la base de datos. Al abrir la ventana FRMSimular,

automáticamente, es invocado por el sistema su método

this_windowOpened(...), que a su vez invoca al método iniciarSim() de la

clase FRMSimular. El método inicairSim() obtiene la cuenca mostrada por

Frame1 y la almacena en una instancia llamada cuenca que es del tipo

CuencaOra. Luego invoca al método Simular() sobre Cuenca, el cual realiza

166


la simulación. Finalizado el método Simular(), es invocado el método

reloadFiguras() de la instancia lienzo, (que es un atributo de Frame1 del

tipo LienzoCuenca) para actualizar los objetos mostrados.

El siguiente Diagrama de colaboración muestra la ejecución del método

Simular(), el cual es ejecutado en la base de datos.

Simular():Cuenca

«cursor Sql»:Nodo

Conjunto de nodos que pertenecen a la cuenca

ordenados.

1*:[i:=1..6] [para cada] no:=siguiente( )

La iteración es de 1..6 porque son 6 mesde de simulación.En cada mes, invocaremos el método distribuirCaudal(i)

sobre todos los nodos de la cuenca

no:Nodo

2: distribuirCaudal(i)

no:Nodo«cursor Sql»:Flujof:Flujo

2.1*: [para cada] f:=siguiente( )2.2: Ent=Ent+Salida( i )

:arr_caudal

2.3: setCaudal(Ent, i )

Atributo delnodo no

:Embalse2.4a: [existe embalse] entrada(Ent, i )

«cursor Sql»:Flujo

f:Flujo

conjunto de flujos queaportan caudales a un nodo

2.4b*: [no existe embalse] fs:=siguiente()

2.5b: [no existe embalse]dem:=dem+Demanda(Ent, i )

2.7b: [no existe embalse]entrada(prop, i)

2.6b*: [no existe embalse] fs:=siguiente()

prop, contieneel caudal proporcionala la demanda del flujo

El método simular() de la cuenca, invoca al método distribuirCaudal(...),

sobre cada uno de sus nodos, para cada mes de la simulación. Para la

distribución de caudales, el nodo calcula el total de caudal de entrada a partir

de los flujos que le aportan caudal. Para ello, invoca al método salida(...)

167


sobre ellos. Luego, almacena dicho caudal en su arreglo de caudales,

invocando el método SetCaudal(...) sobre el atributo caudales. Si el nodo

tiene un embalse, todo el caudal de entrada es aportado a él, para ello invoca

al método del embalse entrada(...). Si no hay un embalse en el nodo,

entonces, se distribuye el caudal de entrada, proporcional a la demanda de

los flujos que extraen caudal del nodo. Para calcular la demanda total, invoca

el método demanda(...) sobre todos los flujos que le extraen caudal, y

acumula su resultado. Luego, es asignado el caudal que le corresponde a

cada uno de los flujos con el método entrada(...).

6.3.3 Limitaciones Encontradas 6.3.3.1 Limitaciones de PL/SQL

• No podemos navegar a través de los atributos del tipo REF de un tipo.

• No podemos actualizar un atributo de un objeto persistente

directamente, tenemos que utilizar UPDATE

• No podemos modificar un atributo en funciones.

• Sólo podemos invocar métodos del tipo procedimiento en objetos

transitorios. No podemos utilizar esta clase de métodos dentro de

predicados SELECT, UPDATE, O DELETE.

6.3.3.2 Limitaciones de Oracle y la exportación de tipos

• Cuando exporto un tipo a java con JPUB, todos los métodos son

ejecutados por el servidor.

168

7 Conclusiones

A pesar de las limitaciones del estándar para el manejo de objetos, este

obtiene una buena calificación en nuestra evaluación, un 78,25%. Lo que nos

permite concluir que, en la próxima versión del estándar (SQL:200n), estará

cubriendo prácticamente el 100% de las características que debe tener una

base de datos orientada a objeto. Por otro lado, Oracle 8i obtiene una

calificación de 70,58%, más baja que el estándar, esto se debe principalmente

a la falta de herencia, un encapsulamiento incompleto, y el deficiente soporte

a la evolución de esquemas.

El estándar, con sus capacidades y limitaciones, es lo suficientemente

robusto para permitir que los desarrolladores lo utilicen para hacer persistir

sus objetos, puesto que las limitaciones son pocas y en áreas no

fundamentales. Pero Oracle 8i, por su falta de herencia, hace que el

desarrollo de aplicaciones orientadas a objeto en él sea muy complejo y poco

productivo. Es de esperar que en uno o dos años más ya existan productos

que implementen todas las instrucciones del estándar SQL:1999.

Uno de los beneficios de la tecnología de objetos incluida en el estándar

SQL:1999 y en Oracle 8i es permitir que los usuarios incrementen el

conjunto de tipos de datos provisto por el sistema. Esto permite la

reutilización del código, lo que disminuye el tiempo de desarrollo y la

complejidad. Además, trae como consecuencia una mayor eficiencia a la

hora de mantener sistemas, porque bastaría con modificar un tipo (ALTER

TYPE) para que automáticamente se modifiquen todas las tablas y tipos que

dependen de él. Lamentablemente dicha actualización no está presente en

Oracle 8i aunque cuenta con el predicado ALTER TYPE, este sólo permite

agregar nuevos métodos, lo cual es muy limitado. En SQL:1999 esto sí es

posible, pero tiene algunas restricciones.

La herencia y el polimorfismo, también traen beneficios a las bases de datos,

puesto que permiten extender el sistema fácilmente para que se adapte a los

cambios de requerimientos. Permitiendo así un desarrollo incremental, lo

que disminuye la complejidad del desarrollo. Estas características están

presentes en SQL:1999, pero no en Oracle 8i.

170

Conclusiones

Otra de las capacidades de SQL:1999 y de Oracle 8i, son las vistas de objetos.

Estas permiten definir una capa de orientación a objeto sobre datos

relacionales, lo que elimina la necesidad de migrar las tablas relacionales a

tablas de objetos.

El contar con el estándar SQL:1999 garantiza a las aplicaciones una

compatibilidad, portabilidad e independencia entre las distintas bases de

datos que implementan el estándar

Una limitación del estándar SQL:1999 y Oracle 8i es que carece de la

funcionalidad para manejar versiones y configuraciones de objetos. Esta es la

desventaja más grande entre las bases de datos objeto-relacional y las bases

de datos orientadas a objeto puras.

Gracias a la implementación del prototipo del capítulo 6, podemos deducir

que la interacción que logramos entre Oracle y Java es bastante transparente,

gracias a la utilidad JPUB, que permite generar las clases Java a partir de los

tipos definidos en Oracle.

El presente trabajo puede ser complementado con una investigación similar a

ésta pero sobre el estándar ODMG-93 y algunas bases de datos orientadas a

objeto puras que lo implementen. Y a partir ello realizar una comparación

entre los estándares y los productos para determinar cuál de los dos resuelve

mejor el problema de la persistencia.

Otro trabajo interesante sería, realizar la misma descripción y análisis hecho

para Oracle 8i, sobre una o más bases de datos objeto relacional, como

puede ser Informix o DB2 DE IBM, y luego realizar una comparación entre

ellas.

171

Apéndice A: Sintaxis de SQL:1999 Relacionada con la OO.

A.1 Leyenda

Para la descripción del lenguaje se utiliza una sintaxis extendida de la

gramática BNF (Backus Normal Form o Forma normal de Backus) [25].

En la gramática BNF, cada elemento sintáctico es conocido como un símbolo

no terminal, el cual es definido por el significado de una regla de

producción [25]. Esto define el elemento en términos de una fórmula

consistente de: caracteres, cadenas de caracteres, y elementos sintácticos

que pueden ser usados para formar una instancia del [25].

La simbología es la siguiente:

Símbolo Significado

< > Las palabras encerradas en estos símbolos, representa un

símbolo no terminal.

: : =

El operador de definición es utilizado en una regla de

producción para separar el elemento definido por la regla y su

definición. A la izquierda del operador, aparece el símbolo no

terminal, y a la derecha, la fórmula que lo define.

[ ] Los corchetes indican que el elemento en una fórmula es

opcional.

{ } Las llaves agrupan elementos en una fórmula.

| Indica que la porción de la fórmula que aparece después de la

barra es una alternativa a la porción que precede a la barra.

. . . Indica que el elemento que aparece antes de los puntos

suspensivos, puede ser repetido n veces

La sintaxis expuesta en este apéndice es tan sólo un extracto del estándar,

por ser éste de gran tamaño (1.196 páginas).

A.2 Sentencias

A.2.1 Creación de tipos (CREATE TYPE) Especifica un tipo de datos definido por el usuario.

Formato:

<user-defined type definition> ::=

CREATE TYPE <user-defined type body>

<user-defined type body> ::= <user-defined type name> [ <subtype clause> ] [ AS <representation> ] [ <instantiable clause> ] <finality> [ <reference type specification> ] [ <cast option> ] [ <method specification list> ]

<subtype clause> ::= UNDER <supertype name> <supertype name> ::= <user-defined type> <representation> ::= <predefined type>| <member list> <member list> ::=

<left paren> <member> [ { <comma> <member> }... ] <right paren>

<member> ::= <attribute definition> <instantiable clause> ::= INSTANTIABLE | NOT INSTANTIABLE <finality> ::= FINAL | NOT FINAL <reference type specification> ::=

<user-defined representation> | <derived representation> | <system-generated representation>

<user-defined representation> ::=

REF USING <predefined type> [ <ref cast option> ] <derived representation> ::= REF FROM <list of attributes> <system-generated representation> ::=

REF IS SYSTEM GENERATED <ref cast option> ::=

[ <cast to ref> ] [ <cast to type> ]

<cast to ref> ::=

CAST <left paren> SOURCE AS REF <right paren> WITH <cast to ref identifier>

Apéndice A – Sintaxis SQL:1999

<cast to ref identifier> ::= <identifier> <cast to type> ::=

CAST <left paren> REF AS SOURCE <right paren> WITH <cast to type identifier>

<cast to type identifier> ::=<identifier> <list of attributes> ::=

<left paren> <attribute name> [ { <comma> <attribute name> }...] <right paren>

<cast option> ::=

[ <cast to distinct> ] [ <cast to source> ]

<cast to distinct> ::=

CAST <left paren> SOURCE AS DISTINCT <right paren> WITH <cast to distinct identifier>

<cast to distinct identifier> ::= <identifier> <cast to source> ::=

CAST <left paren> DISTINCT AS SOURCE <right paren> WITH <cast to source identifier>

<cast to source identifier> ::= <identifier> <method specification list> ::=

<method specification> [ { <comma> <method specification> }... ]

<method specification> ::=

<original method specification> | <overriding method specification>

<original method specification> ::=

<partial method specification> [ SELF AS RESULT ] [ SELF AS LOCATOR ] [ <method characteristics> ]

<overriding method specification> ::=

OVERRIDING <partial method specification> <partial method specification> ::=

[ INSTANCE | STATIC ] METHOD <method name> <SQL parameter declaration list> <returns clause> [ SPECIFIC <specific name> ]

<method characteristics> ::= <method characteristic>... <method characteristic> ::=

<language clause> | <parameter style clause> | <deterministic characteristic> | <SQL-data access indication> | <null-call clause> | <transform group specification>

175


<language clause> ::= LANGUAGE <language name> <language name> ::=

ADA |C |COBOL | FORTRAN | MUMPS | PASCAL | PLI | SQL

A.2.2 Definición de atributos

Define los atributos de un tipo estructurado

Formato:

<attribute definition> ::=

<attribute name> <data type> [ <reference scope check> ] [ <attribute default> ] [ <collate clause> ]

<attribute default> ::= <default clause> <default clause> ::= DEFAULT <default option> <default option> ::=

<literal> | <datetime value function> | USER | CURRENT_USER | CURRENT_ROLE | SESSION_USER | SYSTEM_USER | CURRENT_PATH | <implicitly typed value specification>

A.2.3 Modificación de tipos (ALTER TYPE)

Permite agregar y eliminar atributos o métodos.

Formato:

<alter type statement> ::=

ALTER TYPE <path-resolved user-defined type name> <alter type action>

<alter type action> ::=

<add attribute definition> | <drop attribute definition> | <add original method specification> | <add overriding method specification> | <drop method specification>

<add attribute definition> ::=

ADD ATTRIBUTE <attribute definition> <drop attribute definition> ::=

DROP ATTRIBUTE <attribute name> RESTRICT <add original method specification> ::=

ADD <original method specification> <add overriding method specification> ::=

176


ADD <overriding method specification> <drop method specification> ::=

DROP <specific routine designator> RESTRICT <drop data type statement> ::=

DROP TYPE <path-resolved user-defined type name> <drop behaviour>

<drop behaviour> ::= CASCADE | RESTRICT

<specific routine designator> ::=

SPECIFIC <routine type> <specific name> | <routine type> <member name> [ FOR <path-resolved user-defined type name> ]

<routine type> ::=

ROUTINE | FUNCTION | PROCEDURE | [ INSTANCE | STATIC ] METHOD

<member name> ::= <schema qualified routine name> [ <data type list> ]

<data type list> ::=

<left paren> [ <data type> [ { <comma> <data type> }... ] ] <rige paren>

A.2.4 Creación de métodos, funciones y procedimientos

Permite definir métodos, funciones y procedimientos almacenados.

Formato:

<SQL-invoked routine> ::= <schema routine> <schema routine> ::= <schema procedure> | <schema function> <schema procedure> ::= CREATE <SQL-invoked procedure> <schema function> ::= CREATE <SQL-invoked function> <SQL-invoked procedure> ::=

PROCEDURE <schema qualified routine name> <SQL parameter declaration list> <routine characteristics> <routine body>

<SQL-invoked function> ::=

{ <function specification> | <method specification designator> } <routine body>

<SQL parameter declaration list> ::=

<left paren> [ <SQL parameter declaration> [ { <comma> <SQL parameter declaration> }... ] ] <right paren>

<SQL parameter declaration> ::=

[ <parameter mode> ] [ <SQL parameter name> ] <parameter type>

177


[ RESULT ] <parameter mode> ::= IN | OUT | INOUT <parameter type> ::= <data type> [ <locator indication> ] <locator indication> ::= AS LOCATOR <function specification> ::=

FUNCTION <schema qualified routine name> <SQL parameter declaration list> <returns clause> <routine characteristics> [ <dispatch clause> ]

<method specification designator> ::=

[ INSTANCE | STATIC ] METHOD <method name> <SQL parameter declaration list> [ <returns clause> ] FOR <path-resolved user-defined type name>

<routine characteristics> ::=[ <routine characteristic>... ] <routine characteristic> ::=

<language clause> | <parameter style clause> | SPECIFIC <specific name> | <deterministic characteristic> | <SQL-data access indication> | <null-call clause> | <transform group specification> | <dynamic result sets characteristic> <dynamic result sets characteristic> ::= DYNAMIC RESULT SETS <maximum dynamic result sets>

<parameter style clause> ::=

PARAMETER STYLE <parameter style> <dispatch clause> ::= STATIC DISPATCH <returns clause> ::=

RETURNS <returns data type> [ <result cast> ] <result cast> ::= CAST FROM <result cast from type> <result cast from type> ::=

<data type> [ <locator indication> ] <returns data type> ::= <data type> [ <locator indication> ] <routine body> ::=

<SQL routine body>| <external body reference> <SQL routine body> ::= <SQL procedure statement> <external body reference> ::=

EXTERNAL [ NAME <external routine name> ] [ <parameter style clause> ] [ <external security clause> ]

<external security clause> ::=

EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER

178


| EXTERNAL SECURITY IMPLEMENTATION DEFINED <parameter style> ::= SQL | GENERAL <deterministic characteristic> ::=

DETERMINISTIC | NOT DETERMINISTIC <SQL-data access indication> ::=

NO SQL | CONTAINS SQL | READS SQL DATA | MODIFIES SQL DATA <null-call clause> ::=

RETURNS NULL ON NULL INPUT | CALLED ON NULL INPUT <maximum dynamic result sets> ::= <unsigned integer> <transform group specification> ::=

TRANSFORM GROUP { <single group specification> | <multiple group specification> }

<single group specification> ::= <group name> <multiple group specification> ::=

<group specification> [ { <comma> <group specification> }... ]

<group specification> ::=

<group name> FOR TYPE <path-resolved user-defined type name>

A.2.5 Modificación de métodos, funciones y procedimientos

Permite modificar la definición de una función, procedimiento o de un

método.

Formato:

<alter routine statement> ::=

ALTER <specific routine designator> <alter routine characteristics> <alter routine behaviour>

<alter routine characteristics> ::=

<alter routine characteristic>... <alter routine characteristic> ::=

<language clause> | <parameter style clause> | <SQL-data access indication> | <null-call clause> | <dynamic result sets characteristic> | NAME <external routine name>

<alter routine behaviour> ::= RESTRICT <drop routine statement> ::=

DROP <specific routine designator> <drop behaviour> <specific routine designator> ::=


179


<routine type> ::=





A.2.6 CAST definido por el usuario

Permite crear un CAST definido por el usuario

Formato:

<user-defined cast definition> ::=

CREATE CAST <left paren> <source data type> AS <target data type> <right paren> WITH <cast function> [ AS ASSIGNMENT ]

<cast function> ::= <specific routine designator> <source data type> ::= <data type> <target data type> ::= <data type> <specific routine designator> ::=


<routine type> ::=





180


A.2.7 Eliminación de un CAST

Permite eliminar un CAST definido por el usuario

Formato:

<drop user-defined cast statement> ::=

DROP CAST <left paren> <source data type> AS <target data type> <right paren> <drop behaviour>

A.2.8 Definición del ORDERING de un tipo.

Define la forma en que el sistema debe comparar dos instancias de un mismo

tipo.

Formato:

<user-defined ordering definition> ::=

CREATE ORDERING FOR <path-resolved user-defined type name> <ordering form>

<ordering form> ::=

<equals ordering form> | <full ordering form> <equals ordering form> ::=EQUALS ONLY BY <ordering category> <full ordering form> ::=ORDER FULL BY <ordering category> <ordering category> ::=

<relative category> | <map category> | <state category>

<relative category> ::=

RELATIVE WITH <relative function specification> <map category> ::=

MAP WITH <map function specification> <state category> ::= STATE [ <specific name> ] <relative function specification> ::=

<specific routine designator> <map function specification> ::=

<specific routine designator>

<specific routine designator> ::= SPECIFIC <routine type> <specific name> | <routine type> <member name> [ FOR <path-resolved user-defined type name> ]

<routine type> ::=

ROUTINE | FUNCTION | PROCEDURE

181


| [ INSTANCE | STATIC ] METHOD <member name> ::= <schema qualified routine name> [ <data type list> ]



A.2.9 Eliminación de un user definer ordering

Permite eliminar la definición de un user definer ordering.

Formato:

<drop user-defined ordering statement> ::=

DROP ORDERING FOR <path-resolvedEuser-defined type name> <drop behaviour>

A.2.10 Funciones de transformación de tipos

Permite definir una o más funciones de transformación para tipos definidos

por el usuario.

Formato:

<transform definition> ::=

CREATE { TRANSFORM | TRANSFORMS } FOR <path-resolved user-defined type name> <transform group>...

<transform group> ::=

<group name> <left paren> <transform element list> <right paren>

<group name> ::= <identifier> <transform element list> ::=

<transform element> [ <comma> <transform element> ] <transform element> ::= <to sql> | <from sql> <to sql> ::= TO SQL WITH <to sql function> <from sql> ::= FROM SQL WITH <from sql function> <to sql function> ::= <speciic routine designator> <from sql function> ::= <specific routine designator> <specific routine designator> ::=


<routine type> ::=

ROUTINE | FUNCTION

182


| PROCEDURE | [ INSTANCE | STATIC ] METHOD




A.2.11 Eliminación de funciones de transformación

Permite eliminar funciones de transformación de tipos definidos por el

usuario.

Formato:

<drop transform statement> ::=

DROP { TRANSFORM | TRANSFORMS } <transforms to be dropped> FOR <path-resolved user-defined type name> <drop behaviour>

<transforms to be dropped> ::=

ALL | <transform group element> <transform group element> ::= <group name>

A.2.12 Definición de Tablas (CREATE TABLE)

Permite definir tablas, tanto relacionales como typed tables, subtablas, y

supertablas.

Formato:

<table definition> ::=

CREATE [ <table scope> ] TABLE <table name> <table contents source> [ ON COMMIT <table commit action> ROWS ]

<table contents source> ::= <table element list> | OF <user-defined type>

[ <subtable clause> ] [ <table element list> ]

<table scope> ::= <global or local> TEMPORARY <global or local> ::= GLOBAL | LOCAL <table commit action> ::= PRESERVE | DELETE <table element list> ::=

<left paren> <table element> [ { <comma> <table element> }... ] <right paren>

183


<table element> ::=

<column definition> | <table constraint definition> | <like clause> | <self-referencing column specification> | <column options>

<self-referencing column specification> ::= REF IS <self-referencing column name> <reference generation>

<reference generation> ::= SYSTEM GENERATED | USER GENERATED | DERIVED

<self-referencing column name> ::= <column name> <column options> ::=

<column name> WITH OPTIONS <column option list>

<column option list> ::= [ <scope clause> ] [ <default clause> ] [ <column constraint definition>... ] [ <collate clause> ]

<subtable clause> ::= UNDER <supertable clause> <supertable clause> ::= <supertable name> <supertable name> ::= <table name> <like clause> ::= LIKE <table name>

<column definition> ::=

<column name> { <data type> | <domain name> } [ <reference scope check> ] [ { <default clause> | <identity column specification> } ] [ <column constraint definition>... ] [ <collate clause> ]

<column constraint definition> ::= [ <constraint name definition> ] <column constraint> [ <constraint characteristics> ]

<column constraint> ::= NOT NULL | <unique specification> | <references specification> | <check constraint definition>

<reference scope check> ::= REFERENCES ARE [ NOT ] CHECKED [ ON DELETE <reference scope check action> ]

<reference scope check action> ::= <referential action>

<identity column specification> ::=

184


GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ <start and increment> ]

<start and increment> ::=

<left paren> <start or increment 1> [ <comma> <start or increment 2> ] <right paren>

<start or increment 1> ::= <start or increment> <start or increment 2> ::= <start or increment> <start or increment>::=

<start specification> | <increment specification> <start specification> ::= START WITH <start value> <increment specification> ::= INCREMENT BY <increment> <start value> ::= <signed numeric literal>

<increment> ::= <signed numeric literal>

<table constraint definition> ::= [ <constraint name definition> ] <table constraint> [ <constraint characteristics> ]

<table constraint> ::= <unique constraint definition> | <referential constraint definition> | <check constraint definition>

<unique constraint definition> ::= <unique specification> <left paren> <unique column list> <right paren> | UNIQUE ( VALUE )

<unique specification> ::= UNIQUE | PRIMARY KEY

<unique column list> ::= <column name list>

<referential constraint definition> ::= FOREIGN KEY <left paren> <referencing columns> <right paren> <references specification>

<references specification> ::=

REFERENCES <referenced table and columns> [ MATCH <match type> ] [ <referential triggered action> ]

<match type> ::= FULL | PARTIAL | SIMPLE <referencing columns> ::= <reference column list> <referenced table and columns> ::=

<table name> [ <left paren> <reference column list> <right paren> ]

185


<reference column list> ::= <column name list> <referential triggered action> ::=

<update rule> [ <delete rule> ] | <delete rule> [ <update rule> ]

<update rule> ::= ON UPDATE <referential action> <delete rule> ::= ON DELETE <referential action> <referential action> ::=

CASCADE | SET NULL | SET DEFAULT | RESTRICT | NO ACTION

<check constraint definition> ::= CHECK <left paren> <search condition> <right paren>

A.2.13 Modificación de tablas (ALTER TABLE)

Permite cambiar la definición de una tablas.

Formato:

<alter table statement> ::=

ALTER TABLE <table name> <alter table action> <alter table action> ::=

<add column definition> | <alter column definition> | <drop column definition> | <add table constraint definition> | <drop table constraint definition>

<add column definition> ::= ADD [ COLUMN ] <column definition>

<alter column definition> ::= ALTER [ COLUMN ] <column name> <alter column action>

<alter column action> ::=

<set column default clause> | <drop column default clause> | <add column scope clause> | <drop column scope clause>

<set column default clause> ::=

SET <default clause>

<drop column default clause> ::=

DROP DEFAULT

<add column scope clause> ::=

ADD <scope clause>

186


<drop column scope clause> ::= DROP SCOPE <drop behaviour>

<drop column definition> ::=

DROP [ COLUMN ] <column name> <drop behaviour>

<add table constraint definition> ::=

ADD <table constraint definition>

<drop table constraint definition> ::=

DROP CONSTRAINT <constraint name> <drop behaviour>

A.2.14 Eliminación de tablas (DROP TABLE)

Permite eliminar una tabla.

Formato:

<drop table statement> ::=

DROP TABLE <table name> <drop behaviour>

A.2.15 Inserción de filas (INSERT INTO)

Permite insertar una fila en una tabla.

Formato:

<insert statement> ::= INSERT INTO <insertion target> <insert columns and source>

<insertion target> ::=<table name> <insert columns and source> ::=

<from subquery> | <from constructor> | <from default>

<from subquery> ::=

[ <left paren> <insert column list> <right paren> ] [ override clause> ] <query expression>

<from constructor> ::=

[ <left paren> <insert column list> <right paren> ] [ <override clause> ] <contextually typed table value constructor>

<override clause> ::=

OVERRIDING USER VALUE | OVERRIDING SYSTEM VALUE

<from default> ::=

DEFAULT VALUES

<insert column list> ::= <column name list>

187


<contextually typed table value constructor> ::=

VALUES <contextually typed row value expression list>

<contextually typed row value expression list> ::= <contextually typed row value expression> [ { <comma> <contextually typed row value expression> }... ] <contextually typed row value expression> ::=

<row value special case> | <contextually typed row value constructor>

<row value special case> ::=

<value specification> | <value expression>

A.2.16 Actualización de filas (UPDATE)

Permite modificar el contenido de una fila existente.

Formato:

<update statement: searched> ::=

UPDATE <target table> SET <set clause list> [ WHERE <search condition> ]

<set clause list> ::=

<set clause> [ { <comma> <set clause> }... ]

<set clause> ::= <update target> <equals operator> <update source> | <mutated set clause> <equals operator> <update source>

<update target> ::= <object column> | <object column> <left bracket or trigraph> <simple value specification> <right bracket or trigraph>

<object column> ::= <column name> <mutated set clause> ::= <mutated target> <period> <method name> <mutated target> ::=

<object column> | <mutated set clause>

<update source> ::=

<value expression> | <contextually typed value specification>

A.2.17 Eliminación de filas (DELETE FROM)

Permite modificar el contenido de una fila existente.

Formato:

188


<delete statement: searched> ::= DELETE FROM <target table> [ WHERE <search condition> ]

<target table> ::=

<table name> | ONLY <left paren> <table name> <right paren>

189

Apéndice B: UML

B.1 ¿Qué es UML?

UML cuya sigla significa Unified Modeling Language (Lenguaje Unificado de

Modelado) fue desarrollado por Grady Booch, Jim Rumbaugh e Ivar Jacobson

en respuesta a una serie de necesidades [6]. UML es un lenguaje que permite

especificar, visualizar, construir y documentar artefactos de sistemas de

software, como también, modelar negocios y otros sistemas no software [6].

El UML representa una colección de las mejores prácticas de ingeniería que

han demostrado ser exitosas en el modelamiento de sistemas grandes y

complejos [37].

Como se manifiesta en el documento UML Sumary [37], los objetivos

principales que se perseguían al diseñar UML fueron:

“Proporcionar a los usuarios un lenguaje de modelización visual listo

para ser utilizado que sirviera para desarrollar e intercambiar

modelos con significado.

Proporcionar mecanismos de extensibilidad y especialización para

extender los conceptos esenciales.

Ser independiente de cualquier lenguaje de programación y de

cualquier proceso de desarrollo.

Proporcionar una base formal para comprender el lenguaje de

modelización.

Fomentar el crecimiento del mercado de las herramientas orientadas

a objeto

Dar soporte a conceptos de nivel superior, tales como, colaboración,

marcos de trabajo, patrones y componentes.

Integrar las mejores prácticas”

En UML existen diversos diagramas, estos son [6]:

Diagrama de clases. En este diagrama se definen las clases y cómo

se relacionan entre sí.

Diagrama de Objetos. Es un diagrama de clases para sólo un

conjunto de objetos.

Apéndice C: UML

Diagrama de casos de uso. Un caso de uso muestra la interacción

entre distintos actores (por ejemplo clientes, empleado) y casos de

uso.

Diagrama de secuencias. Un diagrama de secuencia muestra una

interacción de los objetos dispuestos en una secuencia temporal.

Diagrama de colaboración. Un diagrama de colaboración muestra

los objetos y mensajes que se han pasado entre dichos objetos para

llevar a cabo alguna función.

Diagramas de estados. Los diagramas de estado son diagramas

estándares de transición de estados. Muestran en qué estado puede

encontrarse un objeto y qué puede hacer que dicho objeto cambie de

estado.

Diagrama de actividad. Un diagrama de actividad es un tipo de

diagrama de flujo. Representa puntos de operación y de decisión.

Diagrama de realización. Un diagrama de realización muestra los

componentes del sistema y la forma en que interactúan entre sí. El

diagrama de realización puede mostrar los componentes software o

hardware del sistema.

Estos diagramas se suelen agrupar en vistas y las vistas se agrupan en tres

áreas [39]:

• Clasificación estructural. Describe los elementos del sistema

y sus relaciones, proporcionando la base para el

comportamiento dinámico.

• Comportamiento dinámico. describe el comportamiento de

un sistema en el tiempo.

• Gestión del modelo. Describe la organización del propio

modelo en unidades jerárquicas denominadas paquetes.

Existen varias construcciones previas que permiten extender la capacidad de

UML pero de forma limitada. Estas construcciones son transversales a todas

las vistas.

La siguiente tabla [39] describe la agrupación antes descrita.

192

Apéndice C: UML

193

Área Vista Diagrama

vista estática diagrama de clases

vista de casos de uso diagrama de casos de uso

diagrama de componentes

estructural

vista de implementación

vista de despliegue diagrama de despliegue

Vista de máquinas de

estados

diagrama de estados

Vista de actividad Diagrama de actividad

Diagrama de secuencia

Dinámica

Vista de interacción

Diagrama de colaboración

Gestión del modelo Vistas de gestión del

modelo

Diagrama de clases

Extensión del modelo Todas Todos

En la siguiente sección presentaremos la notación para los diagramas

utilizados para diseñar el prototipo.

B.1.1 Diagramas de clases

Los diagramas de clases son la base de los demás diagramas de UML. Ellos

describen la relación que existe entre las distintas clases, siendo las

principales: herencia, agregación, composición y asociación.

La notación para una clase es un rectángulo con tres compartimentos

separados con líneas verticales, el superior para el nombre, el central para los

atributos y el inferior para sus métodos (ver figura 8):

figura 8: Ejemplo de clase [27]

Apéndice C: UML

Para indicar la visibilidad de un atributo o método, anteponemos uno de

estos caracteres: + (público), - (privado), # (protegido). Además, Si el

atributo o el método es estático, se subraya.

Es posible ocultar uno o más compartimientos (preservando el del nombre),

para facilitar la comprensión del diagrama. También, podemos ocultar

aquellos métodos y atributos que forman parte de la implementación y no del

dominio del problema. Esto permitirá definir un mismo diagramas, en

distintos niveles de detalle (ver figura 9):

figura

Detalles suprimidos

Detalle a nivel de análisis Detalles a nivel de implementación

Figura 9: Clases en distintos niveles de detalle [27]

B.1.1.1 Compartimentos adicionales

Es posible agregar compartimentos definidos por el usuario o predefinidos,

para mostrar otras propiedades del modelo como: reglas del negocio,

excepciones, responsabilidades, etc [27]. Un compartimiento adicional, se

señala con un nombre en la parte superior de él, que indique en forma clara

su contenido (ver figura 10). Los compartimentos para los atributos y

métodos, no necesitan llevar un nombre, aunque pude ser necesario para

evitar ambigüedades, cuando es suprimido uno de ellos (ver figura 10)

194

Apéndice C: UML

figura 10: Clase con compartimentos adicionales [27]

B.1.1.2 Estereotipos

Los estereotipos permiten extender la semántica de algún elemento de UML,

por ejemplo las clases. Estos permiten definir restricciones adicionales, o

indicar un modo de uso particular.

Para denotar un estereotipo dentro de una clase, se escribe el nombre del

estereotipo entre comillas («»), sobre el nombre de la clase. Por ejemplo, en

la figura 11 tenemos una clase llamada PenTracker, que tiene el estereotipo

«control».

figura 11: Ejemplo de clase con estereotipo [27]

195

Apéndice C: UML

B.1.1.3 Asociaciones

Para representar las asociaciones de dos clases, utilizamos una línea continua

que las une. En cada extremo de la asociación colocamos la multiplicidad y el

rol que ocupa la clase en la asociación. El nombre de la asociación lo

colocamos a lo largo de la línea pudiendo indicar la dirección en la que se

debe leer el nombre con una punta de flecha triangular negra. Cuando la

asociación posee atributos, entonces creamos una clase de asociación, la cual

es indicada por una línea punteada que une la asociación a su clase (ver

figura 12).

a

Una

auto

clas

B.1.

Para

rom

clas

relac

Nombre del Rol

figura 12: Ejemplo de Asociaciones entre clases [

clase puede estar asociada consigo misma. En UM

asociación. En el ejemplo anterior, tenemos una aut

e trabajo.

1.4 Agregación y composición

la agregación utilizamos un rombo en blanco y para

bo negro, en el extremo correspondiente al compues

e que posee a los componentes. Por ejemplo, conside

ión de agregación entre un Polígono y un Punto:

Autoasociación

Multiplicid
Nombre Asociación
Clase Asociación

27] [39]

L, esto se llama

oasociación en la

la composición un

to, es decir, a la

remos la siguiente

196

Apéndice C: UML

Poligono Punto3..*

0..*

figura 13: Ejemplo de agregación

Un polígono, posee 3 o más puntos que son sus vértices, y un punto puede

pertenecer a muchos polígonos o a ninguno.

En la composición, la multiplicidad en el extremo del compuesto puede ser

como máximo una. Por ejemplo, veamos la relación de composición entre

una Bicicleta y sus partes:

BicicletaPedal

Rueda Marco Asiento Manubrio

Freno

1

2

1

2

1

2 1 1 1

figura 14: Ejemplo de composición

B.1.1.5 Generalización

Para la generalización dibujamos como una flecha desde el hijo hacia el

padre, utilizando un triángulo blanco en la punta. Por ejemplo, consideremos

la siguiente jerarquía de generalización, con empleado como superclase y

con las subclases gerente y vendedor (ver figura 15):

197

Apéndice C: UML

Empleado

Gerente Vendedor

figura 15: Ejemplo generalización

B.1.1.6 Restricciones y comentarios

Una restricción es una expresión encerrada entre llaves que impone ciertas

condiciones al modelo. Las restricciones pueden ser expresadas utilizando el

lenguaje natural, notación de teoría de conjuntos, lenguajes de restricciones

o lenguajes de programación. Para los comentarios se utilizan un rectángulo

que tiene doblada la esquina superior derecha, pero también en ellos

podemos incluir restricciones (ver figura 16).

figura 16: Ejemplo de restricciones y comentarios [39]

198

Apéndice C: UML

B.1.2 Diagrama de colaboración

Los diagramas de colaboración nos permiten mostrar como interactúan los

objetos de las distintas clases para implementar una operación. En un

diagrama, solamente mostramos los objetos que participan en la

implementación de la operación, el resto se omite. La notación de estos

diagramas se compone de:

• Objetos participantes

Los objetos participantes son representados por un rectángulo, con el

nombre del objeto, seguido por dos puntos (:) y el rol de clasificación que es

el nombre de la clase del objeto, subrayado. El rol de asociación describe un

enlace dentro de una colaboración. Los mensajes se muestran como flechas,

ligadas a las líneas de la relación, que conectan a los objetos. La secuencia

de mensajes la indicamos con número secuenciales que preceden a las

descripciones del mensaje. Ejemplo:

• Paso de mensajes

• Relaciones entre los objetos.

• Roles de clasificación

• Roles de asociación.

199

Apéndice C: UML

B.1.3 Para Más información.

si necesita más información revise las referencia bibliográfica [6], [11], [27],

[37] y [38].

200

Apéndice C: Código Fuente del Prototipo y Pantallas

Código Fuente

Este es un tipo distinto que define un arreglo de seis elementos del tipo

number.

C.1 Creación de tipos

Los tipos serán mostrados en el orden que deben ser creados (CREATE

TYPE). Como no podemos utilizar un tipo si este no está creado, debemos

crear primero todos los tipos, y después sus cuerpos. Pero, por motivos

didácticos hemos agrupado la creación de un tipo con la de su cuerpo,

aunque esto causaría errores de compilación.

C.1.1 array_caudal.

CREATE OR REPLACE TYPE array_caudal AS VARRAY(6) OF NUMBER / show errors

C.1.2 arr_caudales

Este tipo almacena los caudales de octubre a marzo.

ATRIBUTOS

Nombre Descripción

Caudal Arreglo para los caudales de octubre a marzo (6 elementos)

del tipo arr_caudal

METODOS

Nombre Descripción

setCaudal(v,m) Modifica la posición M del arreglo caudal con el valor V

getCaudal(m):num Retorna el valor de la posición m del arreglo caudal

init() inicializa el arreglo con valor 0 para cada elemento

CÓDIGO FUENTE

202

Código Fuente

-- métodos

else

end if;

CREATE OR REPLACE TYPE arr_caudales as OBJECT ( -- atributos caudal array_caudal,

MEMBER PROCEDURE setCaudal(v IN NUMBER,m IN NUMBER), MEMBER FUNCTION getCaudal(m IN NUMBER) RETURN NUMBER, MEMBER PROCEDURE init ) / show errors CREATE OR REPLACE TYPE BODY arr_caudales AS -- modifica la posición M del arreglo caudales con el valor V MEMBER procedure setCaudal(v IN NUMBER,m IN NUMBER) IS BEGIN IF (m<=6) and (m>=1) then caudal(m) := v;

RAISE_APPLICATION_ERROR(-21100,'indice Fuera de Rango');

END setCaudal; -- Retorna el valor v de la posición m MEMBER FUNCTION getCaudal(m IN NUMBER) RETURN NUMBER IS BEGIN RETURN (caudal(m)); END getCaudal; -- pone en cero el arreglo MEMBER Procedure init IS BEGIN FOR i IN 1..6 LOOP caudal(i):=0; END LOOP; END init; END; / show errors

203

Código Fuente

ATRIBUTOS

C.1.3 Punto

Este tipo almacena un punto de coordenadas (x,y)

Nombre Descripción

X Coordenada x del punto.

Y Coordenada y del punto.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Punto as OBJECT ( X NUMBER, --coordenada x del punto Y NUMBER --coordenada y del punto ) / show errors

C.1.4 arr_puntos Crea un tipo de arreglo de 100.000 puntos.

CREATE OR REPLACE TYPE arr_puntos AS VARRAY(100000) OF PUNTO / show errors

C.1.5 Polilinea

Este tipo almacena un conjunto de puntos que forman una polilínea (varios

trazos de línea recta unidos)

ATRIBUTOS

Nombre Descripción

LosPuntos Arreglo para almacenar los vértices que forman la polilinea

Npuntos Entero que indica el número de vértices

METODOS

Nombre Descripción

INIT() Inicializa la estructura.

AddP(p) Agrega el punto p al final del arreglo LosPuntos.

AddP(p,i) Agrega el punto p en la posición i del arreglo LosPuntos.

Desplazando los puntos desde i hasta el final.

indexOf(P):NUM Devuelve la posición del punto p.

204

Código Fuente

CREATE OR REPLACE TYPE Polilinea as OBJECT

-- atributos

NPUNTOS NUMBER,

show errors

GETP(i):punto Devuelve el punto de la posición i.

SETP(p,i) Remplaza el punto que esta en i con p

DELP(i) Borra el punto que está en i, desplazando los demás puntos

a la izquierda para eliminar el hueco

CÓDIGO FUENTE

(

LOSPUNTOS ARR_PUNTOS,

ESTILO NUMBER, -- métodos MEMBER PROCEDURE INIT, MEMBER PROCEDURE ADDP(p in Punto), EMBER PROCEDURE ADDP(p in Punto,i in number),

MEMBER FUNCTION indexOf(P in punto) RETURN NUMBER, MEMBER FUNCTION GETP(i in number) RETURN PUNTO,

MEMBER PROCEDURE SETP(p in Punto,i in number), MEMBER PROCEDURE DELP(i in number) ) /

CREATE OR REPLACE TYPE BODY Polilinea AS MEMBER PROCEDURE init IS BEGIN NPUNTOS := 0; LOSPUNTOS := ARR_PUNTOS(NULL); ESTILO := 1; END init;

MEMBER PROCEDURE ADDP(p in Punto) IS BEGIN IF ((p<>null)and(NPUNTOS <= 100000)) then NPUNTOS := NPuntos + 1; lospuntos.extend; --agrega un casillero null al final LosPuntos(NPUNTOS):= P; ELSE

RAISE_APPLICATION_ERROR(-21000,'Error al insertar el punto');

END IF; END ADDP; MEMBER PROCEDURE ADDP(p in Punto,i in number) IS cont number := npuntos; BEGIN IF ((P<>null)and((NPUNTOS <= 100000)and((i<=cont)

and (i>=1)))) then NPUNTOS := NPuntos +1; lospuntos.extend;

205

Código Fuente

return(LosPuntos(i));

lospuntos.trim;--elimina el ultimo elemento

RAISE_APPLICATION_ERROR(-21001,'indice fuera

END IF;

END DELP;

while cont>=i loop LosPuntos(cont+1):=LosPuntos(cont); cont := cont - 1; end loop; LosPuntos(i):=P; ELSE

RAISE_APPLICATION_ERROR(-21001,'Error al insertar el punto');

END IF; END ADDP; MEMBER FUNCTION indexOf(P in punto) RETURN NUMBER IS cont number:=1; BEGIN

While (cont<=NPUNTOS) and ((P.x<>LosPuntos(cont).x) or (P.y<>LosPuntos(cont).y)) loop

cont := cont + 1; end loop; if cont>NPUNTOS THEN return(-1); else return(cont); end if; END INDEXOF;

MEMBER FUNCTION GETP(i in number) RETURN PUNTO IS BEGIN

END GETP;

MEMBER PROCEDURE SETP(p in Punto,i in number) is BEGIN LosPuntos(I) := P; END SETP;

MEMBER PROCEDURE DELP(i in number) IS cont number := i;

BEGIN IF (i<=npuntos) and (i>=1) then while cont<npuntos loop LosPuntos(cont):=LosPuntos(cont+1); cont := cont + 1; end loop; NPUNTOS := NPuntos - 1;

ELSE

de rango');

END; / show errors

206

Código Fuente

C.1.6 Cuadrado

Cuadrado representado por sus cuatro vértices

ATRIBUTOS

Nombre Descripción

a Punto del extremo superior izquierdo del cuadrado

b Punto del extremo superior derecho del cuadrado

c Punto del extremo inferior izquierdo del cuadrado

d Punto del extremo inferior derecho del cuadrado

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Cuadrado as OBJECT ( --propiedades

a PUNTO, b PUNTO, c PUNTO, d PUNTO

) / show errors

C.1.7 Elipse

Elipse representada por su centro, ancho (paralelo al eje x) y su alto (paralelo al

eje Y).

ATRIBUTOS

Nombre Descripción

Centro Punto que indica el centro de la elipse.

Ancho Entero que indica el ancho de la elipse.

Alto Entero que indica el alto de la elipse.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE elipse as OBJECT ( --propiedades

Centro PUNTO, ANCHO NUMBER, ALTO NUMBER

)

207

Código Fuente

/ show errors

C.1.8 Triangulo

Triangulo representado por sus tres vértices.

ATRIBUTOS

Nombre Descripción

a Punto que representa el vértice superior del triángulo

b Punto que representa el vértice inferior izquierdo del

triangulo

c Punto que representa el vértice inferior derecho del

triangulo

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Triangulo as OBJECT ( --propiedades a PUNTO,

b PUNTO, c PUNTO

) / show errors

208

Código Fuente

C.1.9 Graf_flujo

Este tipo representa un flujo genérico

ATRIBUTOS

Nombre Descripción

pl Arreglo para almacenar los vértices que forman el flujo.

Estilo Entero que indica el estilo de dibujo del flujo, que puede ser

gruesa=0, simple=1 doble=2

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Graf_flujo as OBJECT (

Pl ARR_PUNTOS, Estilo NUMBER ) / show errors

C.1.10 graf_cent_hidro

Este objeto representa los atributos gráficos de una central hidroeléctrica

ATRIBUTOS

Nombre Descripción

PL1 Polilínea que representa al canal de entrada

PL2 Polilínea que representa al canal se salida

CUAD Cuadrado que representa a la central hidroeléctrica.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE graf_cent_hidro as OBJECT ( --atributos PL1 POLILINEA,--canal de entrada PL2 POLILINEA,--canal salida CUAD Cuadrado --representa el cuadrado central ) / show errors

209

Código Fuente

ATRIBUTOS

C.1.11 graf_nodo

Representación gráfica de un nodo

Nombre Descripción

Elip Elipse que representa al nodo

CÓDIGO FUENTE

C.1.12 graf_emb

Nombre Descripción

CREATE OR REPLACE TYPE graf_nodo as OBJECT ( Elip Elipse ) / show errors

Representación gráfica de un embalse

ATRIBUTOS

TR Triángulo que representa al embalse

(

)

C.1.13 graf_Cuenca

Supertipo de las clases Graf_emb, Graf_flujo, Graf_nodo y Graf_Cent_Hidro,

que son las representaciones gráficas de los objetos de la cuenca.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE graf_emb as OBJECT

TR TRIANGULO

/ show errors

ATRIBUTOS

Nombre Descripción

ColorLinea Indica el color de la figura.

Tipo Entero que indica el tipo concreto de gráfico

GFL Almacena un objeto del tipo Graf_Flujo.

GCH Almacena un objeto del tipo Graf_Cent_hidro.

210

Código Fuente

GNO Almacena un objeto del tipo Graf_nodo

GEM Almacena un objeto del tipo Graf_emb

CÓDIGO FUENTE

CREATE OR REPLACE TYPE graf_Cuenca as OBJECT ( ColorLinea Varchar(15), Tipo Number, GFL Graf_Flujo, GCH Graf_Cent_Hidro, GNO Graf_Nodo, GEM Graf_Emb ) / show errors

C.1.14 Cuenca

Este tipo almacena los datos de una cuenca

ATRIBUTOS

Nombre Descripción

Codigo Código de la cuenca

Nombre Nombre de la cuenca

METODOS

Nombre Descripción

simular() Realiza la simulación de la cuenca

CÓDIGO FUENTE

CREATE OR REPLACE TYPE cuenca as OBJECT (

--propiedades CODIGO VARCHAR2(40), NOMBRE VARCHAR2(50), --metodos MEMBER PROCEDURE SIMULAR

) / show errors

CREATE OR REPLACE TYPE BODY CUENCA AS MEMBER PROCEDURE SIMULAR IS -- cursor con los nodos pertenecientes a la cuenca

CURSOR NODO_C (cod varchar2) IS SELECT ROWID FROM TBL_NODO N

211

Código Fuente

open NODO_C(codigo);

FETCH NODO_C INTO NODO_rec;

SELECT VALUE(e) INTO nodoObj FROM TBL_NODO e WHERE ROWID=NODO_rec;

WHERE N.MYCUENCA=(SELECT REF(C) FROM TBL_CUENCA C WHERE C.CODIGO=COD)

ORDER BY N.ORDEN()FOR UPDATE; nodo_rec UROWID; nodoObj nodo; n number; i number; fecha varchar2(80); BEGIN

FOR I IN 1..6 LOOP -– recorre cada uno de los meses de la -- simulación

LOOP

exit when NODO_C%NOTFOUND;

if NodoObj is not null then NodoObj.DistribCaudal(i);

end if; -- actualiza el nodo persistente con el nodo transitorio NodoObj utilizado para UPDATE TBL_nodo e SET e=NodoObj WHERE ROWID=NODO_rec; COMMIT;

END LOOP; close NODO_C;

END LOOP; -- fin del for COMMIT;

END SIMULAR; END; / show errors

212

Código Fuente

C.1.15 Nodo

Este tipo es la abstracción de un nodo de la cuenca.

ATRIBUTOS

Nombre Descripción

Codigo Código del nodo

Caudales Arreglo con los caudales de entrada para cada mes de la

simulación.

Graf Almacena los atributos gráficos del nodo

MyCuenca Almacena una referencia al nodo al que pertenece.

METODOS

Nombre Descripción

orden():num Indica la posición que ocuparía el nodo, si ordenamos a

todos los nodos existentes

DistribuirCaudal(m) Calcula el total de caudal de entrada y lo distribuye entre

todos los objetos que extraen su caudal, el caudal de

entrada es almacenado en caudales(m).

CÓDIGO FUENTE

CREATE OR REPLACE TYPE nodo as OBJECT (

CODIGO VARCHAR2(40) ,

strCod:=REPLACE(SUBSTR(LTRIM(RTRIM(codigo)),4),'-','');

end orden;

--atributos

COTA NUMBER , CAUDALES ARR_CAUDALES , GRAF GRAF_NODO , MYCUENCA REF CUENCA , -- métodos MAP MEMBER FUNCTION Orden RETURN NUMBER, MEMBER PROCEDURE DistribCaudal(m in number) ) / show errors CREATE OR REPLACE TYPE BODY nodo AS --convierte el código de la forma "NO I-J" en el Num real I.J MAP MEMBER function orden RETURN number IS strCod varchar2(40); begin

RETURN (TO_NUMBER(strCod));

213

Código Fuente

emb Embalse;

ent:=ent + valor;

function demandaAlNodo(e in number,mes in number,

-- Distribuye el caudal de entrada al nodo por todas las -- salidas que tenga

MEMBER procedure distribCaudal(m IN number) is -- definición de variables entrada number:=0; demanda number:=0; resto number:=0; n number:=0; fl_rec UROWID; emb_rec UROWID; fl flujo;

valor number:=0; --definición de cursores CURSOR Emb_c(COD VARCHAR2) IS select ROWID from tbl_emb e where e.mynodo= (select Ref(n) from tbl_nodo n where

n.codigo=COD) FOR UPDATE; CURSOR flujo_cursor(COD VARCHAR2) IS

select ROWID from tbl_flujo f where (f.tipo!=1)and (f.nodo_ini= (select Ref(n) from tbl_nodo n where

n.codigo=COD)) FOR UPDATE; -- Esta función calcula las entradas del nodo

function caudalEntradas(mes in number,cod varchar2) return number is

CURSOR ENT_C(M NUMBER,C VARCHAR2) IS select f.salida(M),rowid from tbl_flujo f

where f.tipo!=2 and f.nodo_fin=(select ref(n) from tbl_nodo n where n.codigo=c);

ent number:=0; valor number:=0; begin open ENT_C(mes,cod); loop

FETCH ENT_C INTO valor,id; exit when ENT_C%NOTFOUND;

end loop; close ENT_C; return( ent ); end; -- Esta función calcula las demandas del nodo

cod in varchar2)return number is CURSOR DEM_C(ent number,m number,c VARCHAR2) is select f.demanda(ent,m) from tbl_flujo f where f.tipo!=1 and f.nodo_ini=(select ref(n) from

tbl_nodo n where n.codigo=cod);

214

Código Fuente

open DEM_C(e,mes,cod);

open EMB_C(codigo);

fetch emb_c into emb_rec;

n:=n+1;

valor number:=0; dem number:=0;

begin

loop FETCH DEM_C INTO valor; exit when DEM_C%NOTFOUND; dem:=dem + valor;

end loop; close DEM_C; return(dem);

end; BEGIN

entrada:=caudalEntradas(m,codigo); demanda:=demandaAlNodo(Entrada,m,codigo); caudales.setCaudal(entrada,m);

-- si el nodo tiene un embalse entonces no puede tener -- otras salidas. así que todo el caudal de entrada va -- para el embalse.

n:=0; -- numero de embalses

loop

exit when emb_c%notfound;

end loop; close EMB_C; if n>0 then -- si el nodo tiene uno o más embalses

open EMB_C(codigo); loop

FETCH EMB_C INTO EMB_rec; exit when EMB_C%NOTFOUND; SELECT VALUE(e) INTO EMB FROM TBL_EMB e WHERE ROWID=EMB_rec; valor:=entrada/N; EMB.entrada(valor, M);

UPDATE TBL_EMB e SET e=emb WHERE ROWID=EMB_rec; COMMIT;

end loop; close EMB_C; else

-- SI NO TIENE EMBALSE -> PROCESAR SUS FLUJOS. -- entregar caudales a flujos demandantes, en -- forma proporcional a sus demandas.

n:=0; if demanda > 0 then --si hay flujos demandantes.

open flujo_cursor(codigo);

215

Código Fuente

FETCH flujo_cursor INTO fl_rec;

valor:=entrada*(fl.demanda(entrada,m)/

WHERE ROWID=fl_rec;

Else

--no demandan caudal.

loop

exit when flujo_cursor%NOTFOUND; SELECT VALUE(F) INTO FL FROM TBL_FLUJO F WHERE ROWID=fl_rec; if fl.demanda(entrada,m) > 0 then

demanda ); fl.entrada(valor,M); UPDATE TBL_FLUJO F SET F=FL

COMMIT;

n:=n+1;--cuento el numero de flujos que

end if; end loop; close flujo_cursor;

else -- si no hay demanda, es necesario contar los -- flujos que no demandan caudal

open flujo_cursor(codigo); loop

FETCH flujo_cursor INTO fl_rec; exit when flujo_cursor%NOTFOUND; SELECT VALUE(F) INTO FL FROM TBL_FLUJO F WHERE ROWID=fl_rec; if fl.demanda(entrada,m) = 0 then

n:=n+1; -- cuento el numero de flujos -- que no demandan caudal.


end if; -- caudal restante para los flujos no demandantes

-- como los ríos Resto:=entrada - demanda; if resto < 0 then

resto:=0; end if; if N >0 then --si existen flujos no demandantes.

open flujo_cursor(codigo); loop

FETCH flujo_cursor INTO fl_rec; exit when flujo_cursor%NOTFOUND; SELECT VALUE(F) INTO FL FROM TBL_FLUJO F WHERE ROWID=fl_rec; if fl.demanda(entrada,m) = 0 then

valor:=Resto/N; fl.entrada(valor,M); UPDATE TBL_FLUJO F SET F=FL WHERE ROWID=fl_rec; COMMIT;

216

Código Fuente


end if; end if;

END distribCaudal; END; / show errors

C.1.16 Rio

Este tipo nos permite almacenar los datos generales de un Río.

ATRIBUTOS

Nombre Descripción

codigo Código que identifica al río

nombre Nombre del río

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Rio as OBJECT ( --atributos CODIGO VARCHAR2(40), NOMBRE VARCHAR2(50) ) / show errors

C.1.17 Hoya_inter

Este tipo es la abstracción de una Hoya Intermedia

ATRIBUTOS

Nombre Descripción

codigo Código que identifica la hoya intermedia

nombre Nombre de la hoya intermedia

Ref_rio_aportante Referencia al río al que pertenece la hoya intermedia

Caudales Arreglo con los caudales que aporta la hoya intermedia en

cada mes de la simulación.

METODOS

217

Código Fuente

Nombre Descripción

ToVarchar2():cad Entrega una cadena de caracteres formada por la palabra

“hoya_Inter“ concatenado con el código de la hoya

intermedia

salida(m):num Entrega el caudal que es aportado por la hoya intermedia a

un nodo en el mes m.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Hoya_inter as OBJECT ( --atributos CODIGO VARCHAR2(40), NOMBRE VARCHAR2(50), REF_RIO_APORTE REF RIO , CAUDALES ARR_CAUDALES, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER

)

begin

/ show errors CREATE OR REPLACE TYPE BODY Hoya_inter AS MEMBER FUNCTION toVarchar2 return varchar2 is

return('Hoya_inter '||codigo); end toVarchar2; MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN return(Caudales.getcaudal(m)); END Salida; END; / show errors

218

Código Fuente

Nombre Descripción

C.1.18 Regimen_Natural

Este tipo es la abstracción de un régimen natural.

ATRIBUTOS

codigo Código que identifica al régimen natural

nombre Nombre del régimen natural

Caudales Arreglo con los caudales que aporta el régimen natural en

cada mes de la simulación.

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena de caracteres formada por la palabra

“Regimen_Natural “ concatenado con el código del régimen

natural.

salida(m):num Entrega el caudal que es aportado por el régimen natural a

un nodo en el mes m.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Regimen_Natural as OBJECT

--atributos (

CODIGO VARCHAR2(40), NOMBRE VARCHAR2(50),

CAUDALES ARR_CAUDALES, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER ) / show errors CREATE OR REPLACE TYPE BODY Regimen_Natural AS MEMBER FUNCTION toVarchar2 return varchar2 is BEGIN return('Regimen_Natural'||codigo); END toVarchar2;

return(Caudales.getcaudal(m));

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN

END Salida; END; /

219

Código Fuente

Nombre Descripción

show errors

C.1.19 Salida_Emb

Este tipo es la abstracción de una salida de un embalse

ATRIBUTOS

tipo Tipo de la salida de embalse, que puede ser Ee,Er,F,R,G

codigoemb Código del embalse al que pertenece el flujo

Caudales Arreglo con los caudales que recibe la salida desde el

embalse en cada mes de la simulación.

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena de caracteres formada por la cadena

“Salida_Emb “, concatenado con CodigoEmb”-“tipo.

salida(m):num Entrega el caudal que aporta la salida del embalse a un

nodo para el mes m de la simulación.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Salida_Emb as OBJECT ( --atributos Tipo VARCHAR2(2) , --Ee,Er,F,R,G CODIGOEMB VARCHAR2(40), CAUDALES ARR_CAUDALES, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER ) / show errors

CREATE OR REPLACE TYPE BODY Salida_Emb AS MEMBER FUNCTION toVarchar2 return varchar2 is begin return('Salida_Emb '||codigoEMB||'-'||tipo); end toVarchar2;

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN return(Caudales.getcaudal(m)); END Salida; END;

220

Código Fuente

show errors /

C.1.20 Aportante

Esta es la implementación mediante agregación del supertipo de: Hoya_Inter,

Regimen_natural, Salida_emb.

ATRIBUTOS

Nombre Descripción

tipo Número que indica el tipo concreto de un objeto aportante,

que puede ser: 1=Hoya_Inter, 2=Regimen_natural,

3=Salida_emb.

HI Almacena un objeto del tipo Hoya_Inter.

RN Almacena un objeto del tipo Regimen_Natural.

SE Almacena un objeto del tipo Salida_Emb.

METODOS

Nombre Descripción

ToVarchar2():cad Invoca al método ToVarchar2(), sobre HI, RN o SE

dependiendo del tipo correspondiente.

salida(m):num Invoca al método salida(), sobre HI, RN o SE dependiendo

del tipo correspondiente.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Aportante as OBJECT ( --atributos Tipo NUMBER, HI Hoya_inter, RN Regimen_Natural, SE Salida_Emb, --metodos MEMBER FUNCTION toVarchar2 return varchar2,

/

IF tipo=1 THEN

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER )

show errors CREATE OR REPLACE TYPE BODY Aportante AS MEMBER FUNCTION toVarchar2 return varchar2 is begin

221

Código Fuente

ELSIF tipo=2 THEN

ELSIF tipo=3 THEN

ELSE

return(HI.toVarchar2());

return(RN.toVarchar2());

return(SE.toVarchar2());

RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente corregir campo tipo');

END IF;

end toVarchar2;

Nombre Descripción

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN IF tipo=1 THEN return(HI.salida(m)); ELSIF tipo=2 THEN return(RN.salida(m)); ELSIF tipo=3 THEN return(SE.salida(m)); ELSE


END IF; END Salida; END; / show errors

C.1.21 Canal

Esta es la abstracción de un canal

ATRIBUTOS

codigo Código del canal

nombre Nombre del canal

cap_conducción Cantidad máxima de M3 por segundo que es posible

transportar por el canal.

Eficiencia Porcentaje que indica la cantidad de agua de salida con

referencia a la entrada.

A Máximo caudal posible de captar

B Caudal mínimo que debe tener el río para que el canal

pueda captar agua. Si el caudal del río es menor a B,

entonces el caudal captado es cero.

C Caudal del río que hace que el caudal captado sea máximo.

222

Código Fuente

Caudales Arreglo con los caudales de entrada al canal.

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena compuesta por “Canal “ concatenado

con Codigo.

salida(m):num Entrega la cantidad que el canal aporta al nodo final en el

mes m

NOMBRE VARCHAR2(50),

Demanda(caudal,m) Entrega la cantidad de agua que demanda el canal sobre el

caudal del río pasado como parámetro. El parámetro m, es

pasado por compatibilidad del método con los otros tipos

del mismo supertipo.

Entrada(caudal,m) Cantidad de caudal que entra en el canal desde el nodo

inicial en el mes m.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Canal as OBJECT ( --atributos CODIGO VARCHAR2(40),

CAP_CONDUCION NUMBER , EFICIENCIA NUMBER , A NUMBER , B NUMBER , C NUMBER , CAUDALES ARR_CAUDALES, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER, MEMBER FUNCTION DEMANDA(caudal in number,m in number)

RETURN NUMBER, MEMBER PROCEDURE ENTRADA(caudal in number,m in number) ) / show errors CREATE OR REPLACE TYPE BODY Canal AS MEMBER FUNCTION toVarchar2 return varchar2 is begin return('Canal '||codigo); end;

MEMBER FUNCTION DEMANDA(caudal in number,m in number) RETURN NUMBER IS

BEGIN

223

Código Fuente

return(((A / (c-b))*(caudal - c))+A);

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS

IF caudal<=b THEN return(0); ELSIF caudal>c THEN return(a); ELSE -- Calcula el valor del caudal captado en base a la

-- ecuación de la recta que pasa por los punto (b,0) y -- (c,a).

END IF; END DEMANDA;

MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS BEGIN CAUDALES.SetCaudal(caudal,m); END ENTRADA;

BEGIN return((Caudales.getcaudal(m)*Eficiencia)/100); END Salida; END; / show errors

C.1.22 Tramo

Esta es la abstracción de un tramo de río

ATRIBUTOS

Nombre Descripción

MyRio Referencia al río al cual corresponde el tramo

Num_Tramo Número del tramo. La numeración comienza desde aguas

arriba hacia aguas abajo.

Caudales Arreglo con los caudales de entrada al tramo de río

224

Código Fuente

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena compuesta por “Tramo Nº”,

concatenado con el número del tramo y “del río “ seguido

del nombre del río.

salida(m):num Caudal aportado al nodo final por el tramo de río.

Demanda(caudal,m) Siempre devuelve cero, puesto que un tramo de río no

tiene una demanda de caudal. Los parámetros son

mantenidos por compatibilidad.

Entrada(caudal,m) Cantidad de caudal que entra en el tramo de río desde el

nodo inicial en el mes m.

BEGIN

from tbl_rio r where ref(r)=myrio;

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Tramo as OBJECT ( --atributos MYRIO Ref RIO , NUM_TRAMO NUMBER , CAUDALES ARR_CAUDALES, --metodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER, MEMBER FUNCTION DEMANDA(caudal in number,m in number)

RETURN NUMBER, MEMBER PROCEDURE ENTRADA(caudal in number,m in number) ) / show errors CREATE OR REPLACE TYPE BODY Tramo AS MEMBER FUNCTION toVarchar2 return varchar2 is nomrio varchar2(40);

select r.codigo into nomrio

return('Tramo N '||to_char(num_tramo)|| ' del rio'||nomrio);

END toVarchar2;


BEGIN return(0); END DEMANDA;

225

Código Fuente

MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS

CAUDALES.SetCaudal(caudal,m); BEGIN

END ENTRADA;

END Salida;

ATRIBUTOS

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN return(Caudales.getcaudal(m));

END; / show errors

C.1.23 Central_hidro

Este tipo es la abstracción de una central hidroeléctrica.

Nombre Descripción

codigo Código de la central hidroeléctrica

nombre Nombre de la central hidroeléctrica

caudal_max_gen Caudal de entrada que permite la máxima generación

hidroeléctrica por parte de la central.

caudal_min Caudal mínimo de entrada a la central hidroeléctrica que

permite su funcionamiento.

Caudales Arreglo con los caudales de entrada a la central

hidroeléctrica.

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena compuesta por “Central Hidro ”,

concatenado con el código de la central.

salida(m):num Caudal aportado al nodo final por la central en el mes m.

Kw(m):num Función que entrega la energía generada para el mes m.

Por falta de información, este método no utiliza la fórmula

correcta para calcular los KW generados por la central.

Demanda(caudal,m) La demanda de la central es constante, y corresponde a

cauda_max_gen.

Entrada(caudal,m) Cantidad de caudal que entra en la central hidroeléctrica

desde el nodo inicial en el mes m.

226

Código Fuente

MEMBER FUNCTION DEMANDA(caudal in number,m in number) RETURN

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Central_hidro as OBJECT ( --atributos CODIGO VARCHAR2(40), NOMBRE VARCHAR2(50), CAUDAL_MAX_GEN NUMBER , CAUDAL_MIN NUMBER , CAUDALES ARR_CAUDALES, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION KW(m in number) RETURN NUMBER, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER,

NUMBER, MEMBER PROCEDURE ENTRADA(caudal in number,m in number) ) / show errors CREATE OR REPLACE TYPE BODY Central_hidro as MEMBER FUNCTION toVarchar2 return varchar2 is begin return('Central_hidro '||codigo); end;

end KW;

MEMBER FUNCTION KW(m in number) RETURN NUMBER is Begin --NOTA: ESTA FORMULA NO ES CORRECTA. return(Caudales.getcaudal(m)*1.86);


BEGIN return(Caudal_max_gen); END DEMANDA;

CAUDALES.SetCaudal(caudal,m);

MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS BEGIN

END ENTRADA; MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN return(Caudales.getcaudal(m)); END Salida; END; / show errors

227

Código Fuente

C.1.24 Apor_extrac

Este tipo corresponde a la implementación del supertipo de: Canal, Tramo y

Central_Hidro.

ATRIBUTOS

Nombre Descripción

Tipo Número que indica el tipo concreto que está almacenado.

Los valores que puede tomar son: 1=Canal, 2=Tramo,

3=Central_hidro

CA Almacena una instancia de Canal.

TR Almacena una instancia de Tramo.

CH Almacena una instancia de Central_hidro.

METODOS

Nombre Descripción

ToVarchar2():cad Invoca a la función ToVarchar2() sobre el atributo CA, TR o

CH dependiendo del atributo tipo

salida(m):num Invoca a la función salida(m) sobre el atributo CA, TR o CH

dependiendo del atributo tipo

Demanda(caudal,m) Invoca a la función demanda(caudal,m) sobre el atributo

CA, TR o CH dependiendo del atributo tipo

Entrada(caudal,m) Invoca a la función Entrada(caudal,m) sobre el atributo CA,

TR o CH dependiendo del atributo tipo

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Apor_extrac as OBJECT ( --atributos Tipo NUMBER, CA Canal, TR Tramo, CH Central_hidro, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER, MEMBER FUNCTION DEMANDA(caudal in number,m in number)

RETURN NUMBER, MEMBER PROCEDURE ENTRADA(caudal in number,m in number)

228

Código Fuente

)

show errors

return(TR.toVarchar2());

IF tipo=1 THEN

ELSIF tipo=2 THEN

ELSIF tipo=3 THEN

/

CREATE OR REPLACE TYPE BODY Apor_extrac AS MEMBER FUNCTION toVarchar2 return varchar2 is begin IF tipo=1 THEN return(CA.toVarchar2()); ELSIF tipo=2 THEN

ELSIF tipo=3 THEN return(CH.toVarchar2()); ELSE


END IF; end toVarchar2;


BEGIN

return(CA.demanda(caudal,m));

return(TR.demanda(caudal,m));

return(CH.demanda(caudal,m)); ELSE


END IF; END DEMANDA; MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS BEGIN IF tipo=1 THEN CA.ENTRADA(caudal,m); ELSIF tipo=2 THEN TR.ENTRADA(caudal,m); ELSIF tipo=3 THEN CH.ENTRADA(caudal,m); ELSE


END IF; END ENTRADA; BEGIN

ELSIF tipo=3 THEN

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS

IF tipo=1 THEN return(CA.salida(m)); ELSIF tipo=2 THEN return(TR.salida(m));

229

Código Fuente

ELSE return(CH.salida(m));


END IF; END Salida; END; / show errors

C.1.25 Cap_agua_Pot

Este tipo representa la abstracción de una captación de agua potable

Central_Hidro.

ATRIBUTOS

Nombre Descripción

codigo Código de la captación de agua potable

nombre Nombre de la captación de agua potable.

Caudal_de_extrac Arreglo con la demanda de extracción para cada mes de la

simulación.

Caudales Caudales extraídos del nodo inicial para cada mes de la

simulación.

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena compuesta por “Cap_agua_Pot ”,

concatenado con el código de la captación de agua potable.

Demanda(caudal,m) Entrega la cantidad de agua demandada, según el arreglo

caudal_de_extrac.

Entrada(caudal,m) Permite asignar el caudal captado desde el nodo inicial en

el mes m.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Capt_Agua_Pot as OBJECT ( --atributos CODIGO VARCHAR2(40), NOMBRE VARCHAR2(50), Caudal_de_extrac ARR_CAUDALES,

230

Código Fuente

begin

CAUDALES ARR_CAUDALES, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION DEMANDA(caudal in number,m in number)

RETURN NUMBER, MEMBER PROCEDURE ENTRADA(caudal in number,m in number) ) / show errors CREATE OR REPLACE TYPE BODY Capt_Agua_Pot AS MEMBER FUNCTION toVarchar2 return varchar2 is

return('Capt_agua_Pot '||codigo); end;


BEGIN return(Caudal_de_extrac.getCaudal(m)); END DEMANDA;

Nombre Descripción

MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS BEGIN CAUDALES.SetCaudal(caudal,m); END ENTRADA; END; / show errors

C.1.26 Extracción

Este tipo corresponde a la implementación del supertipo de cap_agua_pot. Este

tipo representa a todos los flujos que extraen caudales del nodo.

ATRIBUTOS


Los valores que puede tomar son: 1=Cap_agua_pot

CA Almacena una instancia de Cap_agua_pot.

METODOS

Nombre Descripción

231

Código Fuente

end toVarchar2;

END DEMANDA;

ToVarchar2():cad Invoca a la función ToVarchar2() sobre el atributo CA, TR o

CH dependiendo del atributo tipo

Demanda(caudal,m) Invoca a la función Demanda(caudal,m) sobre el atributo

CA

Entrada(caudal,m) Invoca a la función Entrada(caudal,m) sobre el atributo CA

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Extraccion as OBJECT ( --atributos Tipo NUMBER, CA Capt_Agua_Pot, --métodos MEMBER FUNCTION toVarchar2 return varchar2, MEMBER FUNCTION DEMANDA(caudal in number,m in number)

RETURN NUMBER, MEMBER PROCEDURE ENTRADA(caudal in number,m in number) ) / show errors CREATE OR REPLACE TYPE BODY Extraccion AS MEMBER FUNCTION toVarchar2 return varchar2 is begin IF tipo=1 THEN return(CA.toVarchar2());

ELSE RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente corregir campo tipo');

END IF;


BEGIN IF tipo=1 THEN return(CA.demanda(caudal,m)); ELSE RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente

corregir campo tipo'); END IF;

MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS BEGIN IF tipo=1 THEN CA.ENTRADA(caudal,m);

ELSE RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente

corregir campo tipo'); END IF;

232

Código Fuente

END ENTRADA; END; / show errors

C.1.27 Flujo

Este tipo corresponde a la implementación del supertipo de: Aportante,

Extraccion y Apor_extrac.

ATRIBUTOS

Nombre Descripción

Nodo_ini Referencia al nodo inicial del flujo.

Nodo_fin Referencia al nodo final del flujo.

Graf Almacena los atributos gráficos del flujo.


Los valores que puede tomar son: 1=Aportante,

2=extraccion, 3=Apor_extrac

AP Almacena una instancia de Aportante.

EX Almacena una instancia de Extraccion.

APEX Almacena una instancia de Apor_extrac.

METODOS

Nombre Descripción

ToVarchar2():cad Invoca a la función ToVarchar2() sobre el atributo AP, EX o

APEX dependiendo del atributo tipo

(

salida(m):num Invoca a la función salida(m) sobre el atributo AP, EX o

APEX dependiendo del atributo tipo

Demanda(caudal,m) Invoca a la función demanda(caudal,m) sobre el atributo

AP, EX o APEX dependiendo del atributo tipo

Entrada(caudal,m) Invoca a la función Entrada(caudal,m) sobre el atributo AP,

EX o APEX dependiendo del atributo tipo

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Flujo as OBJECT

233

Código Fuente

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER,

return(ap.toVarchar2());

corregir campo tipo');

invocar el método demanda(c,m):n sobre un

ELSIF tipo=2 THEN

ELSIF tipo=3 THEN

--atributos NODO_INI Ref NODO , NODO_FIN Ref NODO , GRAF Graf_Cuenca, Tipo NUMBER, AP Aportante, EX Extraccion, APEX Apor_extrac, --métodos MEMBER FUNCTION toVarchar2 return varchar2,

MEMBER FUNCTION DEMANDA(caudal in number,m in number) RETURN NUMBER,

MEMBER PROCEDURE ENTRADA(caudal in number,m in number) ) / show errors CREATE OR REPLACE TYPE BODY Flujo AS MEMBER FUNCTION toVarchar2 return varchar2 is begin IF tipo=1 THEN

ELSIF tipo=2 THEN return(EX.toVarchar2());

ELSIF tipo=3 THEN return(APEX.toVarchar2()); ELSE RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente

END IF; end toVarchar2;


BEGIN IF tipo=1 THEN RAISE_APPLICATION_ERROR(-20111,'No se puede

tipo Aportante');

return(EX.demanda(caudal,m));

return(APEX.demanda(caudal,m)); ELSE RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente

corregir campo tipo'); END IF; END DEMANDA; MEMBER PROCEDURE ENTRADA(caudal in number,m in number)IS BEGIN IF tipo=1 THEN RAISE_APPLICATION_ERROR(-20111,'No se puede

invocar el metodo Entrada(c,m) sobre un tipo Aportante');

234

Código Fuente

ELSIF tipo=2 THEN EX.ENTRADA(caudal,m); ELSIF tipo=3 THEN APEX.ENTRADA(caudal,m); ELSE RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente

corregir campo tipo'); END IF; END ENTRADA;

RAISE_APPLICATION_ERROR(-22000,'Tipo inexistente

ATRIBUTOS

MEMBER FUNCTION SALIDA(m in number) RETURN NUMBER IS BEGIN IF tipo=1 THEN return(AP.salida(m)); ELSIF tipo=2 THEN

RAISE_APPLICATION_ERROR(-20111,'No se puede invocar el método Salida(m):n sobre un tipo Extracione');

ELSIF tipo=3 THEN return(APEX.salida(m)); ELSE

corregir campo tipo'); END IF; END Salida; END; / show errors

C.1.28 Embalse

Este tipo es la abstracción de un embalse.

Nombre Descripción

codigo Código del embalse

myNodo Referencia al nodo en el que está ubicado el embalse.

volumenUtil Volumen del embalse que puede ser utilizado.

capmax Capacidad máxima del embalse.

Evap Almacena la evaporación mensual del embalse

VolumenTot Volumen total de caudal en el embalse

EntregaMaxPorV Caudal máximo de salida por válvula.

Superficie Hectarias que abarca el embalse

Coef Coeficiente del embalse, que por lo general es 0.7

VolumenInicial Volumen con el que cuenta el embalse antes de la

simulación.

235

Código Fuente

Curva_alerta Arreglo con los valores mínimos de caudales para cada mes

de la simulación

Graf Atributos gráficos del embalse

Caudales Arreglo con los caudales de entrada para el embalse para

cada uno de los meses de simulación.

Filtraciones Salida del embalse por concepto de filtraciones

Rebases Salida del embalse por concepto de rebases

EntregaEner Salida del embalse para generación hidroeléctrica

EntregaRieg Salida del embalse por riego

EntregaGen Salida del embalse que representa al caudal utilizado en la

generación hidroeléctrica en la central al pie del embalse.

METODOS

Nombre Descripción

ToVarchar2():cad Entrega una cadena formada por “Embalse” concatenado

con el código del embalse.

Entrada(caudal,m) Permite asignar el caudal entregado por el nodo al embalse

en el mes m.

CÓDIGO FUENTE

CREATE OR REPLACE TYPE Embalse as OBJECT ( --atributos CODIGO VARCHAR2(40) , MYNODO Ref NODO , VOLUMENUTIL NUMBER , CAPMAX NUMBER , EVAP NUMBER , SUPERFICIE NUMBER , VOLUMENTOT NUMBER , COEF NUMBER , ENTRAGAMAXPORV NUMBER , VOLUMENINICIAL NUMBER , CURVA_ALERTA ARR_CAUDALES, GRAF GRAF_EMB, CAUDALES ARR_CAUDALES, FILTRACIONES REF FLUJO, REBASES REF FLUJO, ENTREGAENER REF FLUJO , ENTREGARIEG REF FLUJO , ENTREGAGEN REF FLUJO , --METODOS MEMBER FUNCTION toVarchar2 return varchar2, MEMBER PROCEDURE ENTRADA(caudal in number,m in number)

236

Código Fuente

MEMBER FUNCTION toVarchar2 return varchar2 is

Vac := VolumenInicial;

mes:=1;

) / show errors CREATE OR REPLACE TYPE BODY Embalse AS

begin return('Embalse '||codigo); end toVarchar2;

--Este método no es la forma real en que se opera un – --embalse.

MEMBER PROCEDURE ENTRADA(caudal in number,m in number) IS F number; R number; Ee number; Er number; Eg number; Vac number:=0; mes number;

Procedure entregarCaudal(c in number,m in number,RFL in ref flujo) is

fl flujo; begin --ENTREGAGEN.caudales.setCaudal(Eg,m) select value(p) into fl

from tbl_flujo p where ref(p)=RFL; fl.ap.se.caudales.setCaudal(c,m);

update tbl_flujo p set p= fl where ref(p)=RFL; end;

BEGIN caudales.setCaudal(caudal,M); if (M = 1) then

else

while mes < M loop Vac :=Vac + caudales.getCaudal(mes); mes:=mes+1;

end loop; end if; R:=(caudal + Vac ) - CapMax; if (r < 0 ) then r:=0; end if; Vac := caudal - r; F := Vac * 0.005; Vac := Vac - F;

237

Código Fuente

Ee := Caudal / 3; Er := Caudal / 3; Eg := Caudal - Ee - Er; entregarCaudal(F,m,FILTRACIONES); entregarCaudal(R,m,REBASES); entregarCaudal(Ee,m,ENTREGAENER); entregarCaudal(Er,m,ENTREGARIEG); entregarCaudal(Eg,m,ENTREGAGEN); END entrada; END; / show errors

238

Código Fuente

C.2 Definición de Tablas de objetos e inserción de instancias C.2.1 Tabla: tbl_cuenca

Create table tbl_cuenca OF cuenca ( CODIGO NOT NULL PRIMARY KEY ) / show errors

C.2.2 Tabla: tbl_nodo create table tbl_nodo OF nodo ( CODIGO NOT NULL PRIMARY KEY, FOREIGN KEY (myCuenca) REFERENCES tbl_cuenca ON DELETE CASCADE ) / show errors

C.2.3 Tabla: tbl_rio

create table tbl_rio OF rio ( CODIGO NOT NULL PRIMARY KEY ) / show errors

C.2.4 Tabla: tbl_Flujo create table tbl_Flujo OF Flujo ( FOREIGN KEY (nodo_ini) REFERENCES tbl_nodo ON DELETE CASCADE, FOREIGN KEY (nodo_fin) REFERENCES tbl_nodo ON DELETE CASCADE ) / show errors

C.2.5 Tabla: tbl_Emb create table tbl_Emb OF Embalse ( FOREIGN KEY (mynodo) REFERENCES tbl_nodo ON DELETE CASCADE, FOREIGN KEY (FILTRACIONES) REFERENCES tbl_flujo ON DELETE CASCADE, FOREIGN KEY (REBASES) REFERENCES tbl_flujo ON DELETE CASCADE, FOREIGN KEY (ENTREGAENER) REFERENCES tbl_flujo ON DELETE CASCADE,

239

Código Fuente

arr_caudales(array_caudal(0,0,0,0,0,0)))),

FOREIGN KEY (ENTREGARIEG) REFERENCES tbl_flujo ON DELETE CASCADE, FOREIGN KEY (ENTREGAGEN) REFERENCES tbl_flujo ON DELETE CASCADE ) / show errors

C.2.6 Inserción de una Cuenca

insert into tbl_cuenca values(cuenca('01','Cuenca del Rio Maule')) /

C.2.7 Inserción de un Rio

insert into tbl_rio values(rio('R00','Estero [sin nombre]')) /

C.2.8 Inserción de un Nodo Insert into tbl_nodo values ( nodo('NO 1-1',2500, arr_caudales(array_caudal(0,0,0,0,0,0)), graf_nodo(elipse(Punto(387,87),39,24)), (select REF(C) from tbl_cuenca C where c.codigo='01') ) ) /

C.2.9 Inserción de un Embalse y sus salidas insert into tbl_emb values ( embalse('EM1',(select REF(N) from tbl_nodo n where n.codigo='NO 1-1'), 100000,150000,20000,10,150000, 0.7,20000,1000, arr_caudales(array_caudal(1000,1200,1300,1400,1500,1600)), GRAF_EMB(TRIANGULO(PUNTO(387,99),PUNTO(354,138),PUNTO(425,138))), arr_caudales(array_caudal(0,0,0,0,0,0)),null,null,null,null,null ) ) / -- insertando las 5 salidas del embalse insert into tbl_flujo values ( flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-2'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(360,138), Punto(378,229)),1),null,null,null),1, aportante(3,null,null,SALIDA_EMB('F','EM1',

null,null) ) /

240

Código Fuente

flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-2'),

)

insert into tbl_flujo values ( flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-2'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(375,138), Punto(382,228)),1),null,null,null),1, aportante(3,null,null,SALIDA_EMB('Ee','EM1', arr_caudales(array_caudal(0,0,0,0,0,0)))), null,null) ) / insert into tbl_flujo values ( flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-2'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(387,138), Punto(387,228)),1),null,null,null),1, aportante(3,null,null,SALIDA_EMB('R','EM1', arr_caudales(array_caudal(0,0,0,0,0,0)))), null,null) ) / insert into tbl_flujo values ( flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-2'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(400,138), Punto(393,228)),1),null,null,null),1, aportante(3,null,null,SALIDA_EMB('Er','EM1', arr_caudales(array_caudal(0,0,0,0,0,0)))), null,null) ) / insert into tbl_flujo values (

graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(417,138), Punto(399,230)),1),null,null,null),1, aportante(3,null,null,SALIDA_EMB('G','EM1', arr_caudales(array_caudal(0,0,0,0,0,0)))), null,null)

/ -- actualizando las referencias en el embalse update tbl_emb e set filtraciones=(select REF(f) from tbl_flujo f where (f.ap.se.codigoemb='EM1')and(f.ap.se.tipo='F')) WHERE e.codigo='EM1' / update tbl_emb e set Rebases=(select REF(f) from tbl_flujo f

241

Código Fuente where (f.ap.se.codigoemb='EM1')and(f.ap.se.tipo='R')) WHERE e.codigo='EM1' / update tbl_emb e set EntregaEner=(select REF(f) from tbl_flujo f where (f.ap.se.codigoemb='EM1')and(f.ap.se.tipo='Ee')) WHERE e.codigo='EM1' / update tbl_emb e set EntregaRieg=(select REF(f) from tbl_flujo f where (f.ap.se.codigoemb='EM1')and(f.ap.se.tipo='Er')) WHERE e.codigo='EM1' / update tbl_emb e set EntregaGen=(select REF(f) from tbl_flujo f where (f.ap.se.codigoemb='EM1')and(f.ap.se.tipo='G')) WHERE e.codigo='EM1' /

C.2.10 Inserción de un Regimen Natural insert into tbl_flujo values ( flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-1'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(432,65), Punto(398,77)),1),null,null,null),1,aportante(2,null, Regimen_natural('RN 1-1','Afluentes Laguna Maule', arr_caudales(array_caudal(5000,6000,7000,7000,8000,2000))), null), null,null) ) /

C.2.11 Inserción de una Hoya Intermedia insert into tbl_flujo values ( flujo(null,(select REF(n) from tbl_nodo n where n.codigo='NO 1-5'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(272,391), Punto(308,391)),1),null,null,null), 1,aportante(1,Hoya_Inter('HI 1-5','-', (select ref(r) from tbl_rio r where r.codigo='R11'), arr_caudales(array_caudal(9230,8980,7520,6520,9860,7510))), null,null), null,null) ) /

242

Código Fuente

null,

null,

graf_cuenca('Negro',2,null,

)

(flujo((select REF(n) from tbl_nodo n where n.codigo='NO 1-2'),

Punto(387,348)),3),null,null,null),3,null,null,

))

C.2.12 Inserción de una Captación de Agua Potable insert into tbl_flujo values ( flujo((select REF(n) from tbl_nodo n where n.codigo='NO 1-6'),

graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(404,366), Punto(444,382)),1),null,null,null), 2,

EXTRACCION(1, CAPT_AGUA_POT('CAPT AGUA 01','Captación de agua potable 01',

arr_caudales(array_caudal(8560,7320,6980,5680,9760,1230)), arr_caudales(array_caudal(0,0,0,0,0,0)))) ,null ) ) /

C.2.13 Inserción de una Central Hidroeléctrica insert into tbl_flujo values ( flujo( (select REF(n) from tbl_nodo n where n.codigo='NO 1-2'), (select REF(n) from tbl_nodo n where n.codigo='NO 1-6'),

graf_cent_hidro(polilinea(arr_puntos(Punto(406,243), Punto(432,257),Punto(432,276)),3,2), polilinea(arr_puntos(Punto(432,300), Punto(432,311),Punto(400,351)),3,2), cuadrado(Punto(420,276),Punto(444,276), Punto(420,300),Punto(444,300))),null,null), 3,null,null, apor_extrac(3,null,null, Central_hidro('CI 1-1','Central los condores',50000,1000, arr_caudales(array_caudal(0,0,0,0,0,0)) ))

) /

C.2.14 Inserción de un Tramo de Rio insert into tbl_flujo values

(select REF(n) from tbl_nodo n where n.codigo='NO 1-6'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(387,252),

apor_extrac(2,null,Tramo( (select ref(r) from tbl_rio r where r.codigo='R11'), 2,arr_caudales(array_caudal(0,0,0,0,0,0))),null

) /

243

Código Fuente

(

apor_extrac( 1,

)

C.2.15 Inserción de un Canal insert into tbl_flujo values

flujo( (select REF(n) from tbl_nodo n where n.codigo='NO 1-11'), (select REF(n) from tbl_nodo n where n.codigo='NO 1-12'), graf_cuenca('Negro',1,graf_flujo(arr_puntos(Punto(159,474), Punto(241,474)),2),null,null,null), 3,null,null,

Canal('CA 2','Rama Cipreses',1000,100,1000,0,3000, arr_caudales(array_caudal(0,0,0,0,0,0))) ,null,null )

) /

244

Código Fuente

C.3 Pantallas. C.3.1 Datos de Conexión

C.3.2 Abrir cuenca existente

245

Código Fuente

C.3.3 Ventana Principal, después de abrir una cuenca. (Frame1.java)

C.3.4 Agregar Cuenca

246

Código Fuente

C.3.5 Ventana simulación al finalizar

C.3.6 Nodos y sus caudales

247

Código Fuente

C.3.7 Modificando un Rio (FrmModificarRio.java y FrmRio.java)

a

C.3.8 Acerca de (Frame1_AboutBox.java)

FrmModificarRio.jav

a
FrmRio.jav
248

Código Fuente

C.3.9 Propiedadas de un Canal (FrmCanal.java)

C.3.10 Propiedades de una Captación de Agua Potable (FrmCapAguaPot.java)

C.3.11 Propiedades de una central hidroeléctrica (FrmCentralHidro.java)

249

Código Fuente

C.3.12 Propiedades de una hoya intermedia (frmHoyaInter.java)

C.3.13 Propiedades de un régimen natural (frmRegNat.java)

C.3.14 Propiedades de una salida de embalse (frmSalidaEmb.java)

250

Código Fuente

C.3.15 Propiedades de un tramo de río (FrmTramo.java)

C.3.16 Propiedades de un nodo (frmNodo.java)

C.3.17 Ventana para la modificación del Zoom (FrmZoom.java)

251

Código Fuente

C.3.18 Menu Cuenca

C.3.19 Menu Río

C.3.20 Menu Zoom

C.3.21 Menu Insertar

252

Código Fuente

C.3.22 Menu Consultas

C.3.23 Menu Ayuda

253

Código Fuente

C.4 Código Java.

import Oracle.jdbc.driver.*;

}

this.url = url;

/**-------------------------------

C.4.1 Paquete consultorSql C.4.1.1 Clase: ConectorJDBC //Nombre del archivo ConectorJDBC.java package consultorSql; import java.sql.*;

import Oracle.sql.*;

public class ConectorJDBC { OracleConnection connection=null; String url; String usr; String driver; String passwd; public ConectorJDBC() {

public ConectorJDBC(String url, String driverName,String user, String passwd) {

this.driver = driverName; this.usr = user; this.passwd = passwd;

{

/*----------------------------- * Funcion mutadora de Usr */ public void setUsr(String usr) { this.usr=usr; } /**------------------------------ * Funcion mutadora de passwd */ public void setPasswd(String passwd) { this.passwd = passwd; }

* Funcion mutadora de Url

254

Código Fuente

{

* Funcion mutadora de driver

this.driver = driver;

/**-------------------------------

public String getPasswd()

*/ public void setUrl(String url)

this.url = url; } /**-------------------------------

*/ public void setDriver(String driver) {

} /**------------------------------- * Funcion observadora de Usr */ public String getUsr() { return this.usr; }

* Funcion observadora de passwd */

{ return this.passwd; } /**------------------------------- * Funcion observadora de Url */ public String getUrl() { return this.url ; } /**------------------------------- * Funcion observadora de driver */ public String getDriver() { return this.driver; } /**---------------------------------------------------------- * Abre la coneccion a la base de datos con los atributos de

255

Código Fuente

* coneccion.

*/

* coneccion. */ public void open() throws Exception { Class.forName(driver); System.out.println("conectando a la base de datos..."); connection = (OracleConnection) DriverManager.getConnection(url, usr, passwd); } /**---------------------------------------------------------- * Abre la coneccion a la base de datos con los atributos de

*/ public void open(String url, String driverName, String user, String passwd) throws Exception { Class.forName(driverName); System.out.println("conectando a la base de datos..."); connection =(OracleConnection) DriverManager.getConnection(url, user, passwd); } /**----------------------------------------------------------- * Cierra la conneccion a la base de datos.

public void close() throws SQLException { System.out.println("Cerrando la conneccion a la base de datos"); connection.close(); } public Connection getConnection() { return connection; }

public OracleConnection getOracleConnection() { return connection; } public boolean isClosed() throws SQLException { return ((this.connection==null) ||(connection.isClosed()));

} public boolean isOpen() throws SQLException {

256

Código Fuente return !((this.connection==null)|| (connection.isClosed()));

} }

C.4.1.2 Clase: FrmConexion //Nombre del archivo FrmConexion.java package consultorSql; import javax.swing.*; import java.awt.*; import java.awt.event.*; public class FrmConexion extends JDialog { JPanel jPanel1 = new JPanel(); JButton btSalir = new JButton(); JPanel jPanel2 = new JPanel(); GridLayout gridLayout1 = new GridLayout(); JPanel jPanel3 = new JPanel(); JPanel jPanel4 = new JPanel(); JPanel jPanel5 = new JPanel(); JPanel jPanel6 = new JPanel(); JLabel jLabel1 = new JLabel(); JPasswordField paswd = new JPasswordField(); JLabel jLabel2 = new JLabel(); JTextField url = new JTextField(); JLabel jLabel3 = new JLabel(); JTextField driver = new JTextField(); JLabel jLabel4 = new JLabel(); FlowLayout flowLayout1 = new FlowLayout(); FlowLayout flowLayout2 = new FlowLayout(); FlowLayout flowLayout3 = new FlowLayout(); FlowLayout flowLayout4 = new FlowLayout(); JTextField user = new JTextField(); JPanel jPanel7 = new JPanel(); JPanel jPanel8 = new JPanel(); JPanel jPanel9 = new JPanel(); private ConectorJDBC conector; JButton btConectar = new JButton(); public FrmConexion() { try { jbInit(); } catch(Exception e) { e.printStackTrace(); } }

257

Código Fuente public FrmConexion(Frame po,ConectorJDBC conector) { super(po); try { jbInit(); this.conector=conector; } catch(Exception e) { e.printStackTrace(); } } public FrmConexion(Frame po) { super(po); try { jbInit(); } catch(Exception e) { e.printStackTrace(); } } private void jbInit() throws Exception { btSalir.setPreferredSize(new Dimension(89, 25)); btSalir.setMinimumSize(new Dimension(89, 25)); btSalir.setText("Salir"); btSalir.setMnemonic('S') ; btSalir.setMaximumSize(new Dimension(89, 25)); btSalir.addKeyListener(new java.awt.event.KeyAdapter() { public void keyReleased(KeyEvent e) { btSalir_keyReleased(e); } }); btSalir.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { btSalir_actionPerformed(e); } }); jPanel2.setLayout(gridLayout1); gridLayout1.setRows(4); jLabel1.setText("Nombre de Usuario"); jLabel1.setPreferredSize(new Dimension(127, 15)); jLabel1.setMinimumSize(new Dimension(127, 15));

258

Código Fuente jLabel1.setMaximumSize(new Dimension(127, 15)); paswd.setPreferredSize(new Dimension(215, 19)); paswd.setMinimumSize(new Dimension(215, 19)); paswd.setText("romero"); paswd.setMaximumSize(new Dimension(215, 19)); paswd.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(FocusEvent e) { paswd_focusGained(e); } public void focusLost(FocusEvent e) { paswd_focusLost(e); } }); paswd.addKeyListener(new java.awt.event.KeyAdapter() { public void keyReleased(KeyEvent e) { paswd_keyReleased(e); } }); jLabel2.setText("Contraseña"); jLabel2.setPreferredSize(new Dimension(127, 15)); jLabel2.setMinimumSize(new Dimension(127, 15)); jLabel2.setMaximumSize(new Dimension(127, 15)); url.setPreferredSize(new Dimension(215, 19)); url.setMinimumSize(new Dimension(215, 19)); url.setSelectionStart(0); url.setText("jdbc:Oracle:thin:@zorro:1521:ORCL"); url.setSelectionEnd(0); url.setMaximumSize(new Dimension(215, 19)); url.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(FocusEvent e) { url_focusGained(e); } public void focusLost(FocusEvent e) { url_focusLost(e); } }); url.addKeyListener(new java.awt.event.KeyAdapter() { public void keyReleased(KeyEvent e) { url_keyReleased(e); } }); jLabel3.setText("URL JDBC"); jLabel3.setPreferredSize(new Dimension(127, 15)); jLabel3.setMinimumSize(new Dimension(127, 15));

259

Código Fuente jLabel3.setMaximumSize(new Dimension(127, 15)); driver.setPreferredSize(new Dimension(215, 19)); driver.setMinimumSize(new Dimension(215, 19)); driver.setText("Oracle.jdbc.driver.OracleDriver"); driver.setMaximumSize(new Dimension(215, 19)); driver.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(FocusEvent e) { driver_focusGained(e); } public void focusLost(FocusEvent e) { driver_focusLost(e); } }); driver.addKeyListener(new java.awt.event.KeyAdapter() { public void keyReleased(KeyEvent e) { driver_keyReleased(e); } }); jPanel3.setLayout(flowLayout1); jPanel4.setLayout(flowLayout2); jPanel5.setLayout(flowLayout3); jPanel6.setLayout(flowLayout4); flowLayout1.setAlignment(FlowLayout.LEFT); flowLayout2.setAlignment(FlowLayout.LEFT); flowLayout3.setAlignment(FlowLayout.LEFT); flowLayout4.setAlignment(FlowLayout.LEFT); user.setPreferredSize(new Dimension(215, 19)); user.setMinimumSize(new Dimension(215, 19)); user.setText("miguel"); user.setMaximumSize(new Dimension(215, 19)); user.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(FocusEvent e) { user_focusGained(e); } public void focusLost(FocusEvent e) { user_focusLost(e); } }); user.addKeyListener(new java.awt.event.KeyAdapter() { public void keyPressed(KeyEvent e) { user_keyPressed(e); } }); jLabel4.setText("Driver JDBC");

260

Código Fuente jLabel4.setPreferredSize(new Dimension(127, 15)); jLabel4.setMinimumSize(new Dimension(127, 15)); jLabel4.setToolTipText(""); jLabel4.setMaximumSize(new Dimension(127, 15)); jPanel2.setBorder(BorderFactory.createEtchedBorder()); this.setModal(true); this.setTitle("Datos de Conección"); jPanel1.setMinimumSize(new Dimension(10, 10)); btConectar.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { btConectar_actionPerformed(e); } }); btConectar.addKeyListener(new java.awt.event.KeyAdapter() { public void keyReleased(KeyEvent e) { btConectar_keyReleased(e); } }); btConectar.setText("Conectar"); btConectar.setMnemonic('C'); this.getContentPane().add(jPanel1, BorderLayout.SOUTH); jPanel1.add(btConectar, null); jPanel1.add(btSalir, null); this.getContentPane().add(jPanel2, BorderLayout.CENTER); jPanel2.add(jPanel3, null); jPanel3.add(jLabel1, null); jPanel3.add(user, null); jPanel2.add(jPanel4, null); jPanel4.add(jLabel2, null); jPanel4.add(paswd, null); jPanel2.add(jPanel5, null); jPanel5.add(jLabel3, null); jPanel5.add(url, null); jPanel2.add(jPanel6, null); jPanel6.add(jLabel4, null); jPanel6.add(driver, null); this.getContentPane().add(jPanel7, BorderLayout.WEST); this.getContentPane().add(jPanel8, BorderLayout.EAST); this.getContentPane().add(jPanel9, BorderLayout.NORTH); } void user_keyPressed(KeyEvent e) { if (e.getKeyChar()=='\n') { paswd.requestFocus(); } } void paswd_keyReleased(KeyEvent e)

261

Código Fuente { if (e.getKeyChar()=='\n') { url.requestFocus(); } } void url_keyReleased(KeyEvent e) { if (e.getKeyChar()=='\n') { driver.requestFocus(); } } void driver_keyReleased(KeyEvent e) { if (e.getKeyChar()=='\n') { btSalir.requestFocus(); } } void btSalir_actionPerformed(ActionEvent e) { this.hide(); } void user_focusGained(FocusEvent e) { user.setSelectionStart(0) ; user.setSelectionEnd(user.getText().length()) ; } void paswd_focusGained(FocusEvent e) { paswd.setSelectionStart(0) ; paswd.setSelectionEnd(paswd.getPassword().length); } void url_focusGained(FocusEvent e) { url.setSelectionStart(0) ; url.setSelectionEnd(url.getText().length()) ; } void driver_focusGained(FocusEvent e) { driver.setSelectionStart(0) ;

262

Código Fuente driver.setSelectionEnd(driver.getText().length()) ; } void user_focusLost(FocusEvent e) { user.setSelectionStart(0) ; user.setSelectionEnd(0) ; } void paswd_focusLost(FocusEvent e) { paswd.setSelectionStart(0) ; paswd.setSelectionEnd(0) ; } void url_focusLost(FocusEvent e) { url.setSelectionStart(0) ; url.setSelectionEnd(0) ; } void driver_focusLost(FocusEvent e) { paswd.setSelectionStart(0) ; paswd.setSelectionEnd(0) ; } /** * entregan los datos de coneccion */ public String getUsr() { return user.getText(); } public String getPasswd() { return new String(paswd.getPassword()); } public String getUrl() { return url.getText(); } public String getDriver() { return driver.getText(); } void btSalir_keyReleased(KeyEvent e)

263

Código Fuente

}

}

{ if (e.getKeyChar()=='\n') { this.hide(); } } void btConectar_actionPerformed(ActionEvent e) { try { conector.setDriver(this.getDriver()); conector.setUrl(this.getUrl()); conector.setUsr(this.getUsr() ); conector.setPasswd(this.getPasswd()); if(conector.isOpen()) { conector.close(); conector.open(); } else { conector.open(); } this.hide(); } catch (Exception ex) { JOptionPane.showMessageDialog(this,"Error al conectar: "+ex) ; } } void btConectar_keyTyped(KeyEvent e) { } void btConectar_keyPressed(KeyEvent e) {

void btConectar_keyReleased(KeyEvent e) {

//habilita o deshabilita el boton salir public void enbableBtSalir(boolean enabled) { btSalir.setEnabled(enabled); } }

264

Código Fuente

sqlQuery sqlQuery1 = new sqlQuery();

{

jbInit();

e.printStackTrace();

sqlQuery1.setActive(true) ;

C.4.1.3 Clase: FrmConsultor package consultorSql; import java.awt.*; import javax.swing.*; import java.awt.event.*; public class FrmConsultor extends JDialog { GridBagLayout gridBagLayout3 = new GridBagLayout(); JScrollPane jScrollPane1 = new JScrollPane(); JScrollPane jScrollPane2 = new JScrollPane(); JButton jButton1 = new JButton(); JButton jButton2 = new JButton(); JTextArea jTextArea1 = new JTextArea();

String usr; String passwd; String url; String driver; /** * Constructor */ public FrmConsultor()

try { jbInit(); } catch(Exception e) { e.printStackTrace(); } } /** * Construcctor para el FrmConsultor */ public FrmConsultor(String usr,String passwd,String url,String driver) { try {

} catch(Exception e) {

} sqlQuery1.setUsr(usr) ; sqlQuery1.setPasswd(passwd) ; sqlQuery1.setUrl(url) ; sqlQuery1.setDriver(driver) ;

265

Código Fuente

{

}

} /** * Construcctor para el FrmConsultor */ public FrmConsultor(Frame po,String usr,String passwd,String url,String driver) { super(po); try { jbInit(); } catch(Exception e)

e.printStackTrace(); } sqlQuery1.setUsr(usr) ; sqlQuery1.setPasswd(passwd) ; sqlQuery1.setUrl(url) ; sqlQuery1.setDriver(driver) ; sqlQuery1.setActive(true) ; } private void jbInit() throws Exception { this.getContentPane().setLayout(gridBagLayout3); this.setModal(true); this.setTitle("Consultas SQL"); this.addWindowListener(new java.awt.event.WindowAdapter() { public void windowActivated(WindowEvent e) { this_windowActivated(e); } }); jButton1.setNextFocusableComponent(jButton2); jButton1.setText("Ejecutar"); jButton1.setMnemonic('E') ; jButton1.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jButton1_actionPerformed(e);

}); jButton2.setNextFocusableComponent(jTextArea1); jButton2.setText("Salir"); jButton2.setMnemonic('S') ; jButton2.addKeyListener(new java.awt.event.KeyAdapter() { public void keyReleased(KeyEvent e) { jButton2_keyReleased(e); }

266

Código Fuente

public void actionPerformed(ActionEvent e)

jButton2_actionPerformed(e);

this.getContentPane().add(jButton2, new GridBagConstraints(1, 1, 1,

jScrollPane2.getViewport().add(jTextArea1, null);

}); jButton2.addActionListener(new java.awt.event.ActionListener() {

{

} }); jTextArea1.setNextFocusableComponent(jButton1); jTextArea1.setText("Select * from dual"); jTextArea1.setToolTipText("escriba la consulta, para ejecutarla

utilize alt + e o el botón Ejecutar"); sqlQuery1.setAutoResizeMode(JTable.AUTO_RESIZE_ALL_COLUMNS); sqlQuery1.setDoubleBuffered(true); sqlQuery1.setUsr("miguel"); sqlQuery1.setPasswd("romero"); sqlQuery1.setUrl("jdbc:Oracle:thin:@zorro:1521:ORCL"); sqlQuery1.setDriver("Oracle.jdbc.driver.OracleDriver"); sqlQuery1.setQuery("Select * from Dual"); sqlQuery1.setActive(true); this.getContentPane().add(jScrollPane1, new GridBagConstraints(0, 3,

GridBagConstraints.REMAINDER, 10, 1.0, 0.666666666 ,GridBagConstraints.WEST, GridBagConstraints.BOTH, new Insets(3,

7, 7, 7), 0, 0)); jScrollPane1.getViewport().add(sqlQuery1, null); this.getContentPane().add(jButton1, new GridBagConstraints(1, 0, 1,

1,0.0,0.0,GridBagConstraints.NORTHEAST, GridBagConstraints.BOTH, new Insets(7, 3, 3, 7), 0, 0));

1, 0.0, 0.0,GridBagConstraints.NORTHEAST, GridBagConstraints.BOTH, new Insets(3, 3, 3, 7), 0, 0));

this.getContentPane().add(jScrollPane2, new GridBagConstraints(0, 0, 1, 3, 0.6, 0.23,GridBagConstraints.NORTHWEST, GridBagConstraints.BOTH, new Insets(7, 7, 3, 3), 93, 18));

} void jButton2_actionPerformed(ActionEvent e) { this.hide() ; } void jButton2_keyReleased(KeyEvent e) { if (e.getKeyChar()=='\n') { this.hide(); }

} void jButton1_actionPerformed(ActionEvent e) {

267

Código Fuente

C.4.1.4 Clase: JDBCAdapter

// pero tiene algunas modificaciones para ser utilizada en este proyecto

String[] columnNames = {};

ejecutarConsulta(); } void ejecutarConsulta() { String query=jTextArea1.getText().trim() ; sqlQuery1.setQuery(query) ; sqlQuery1.exeQuery(); } void this_windowActivated(WindowEvent e) { jTextArea1.requestFocus(); } }

//Nota: esta clase pertenece a los ejemplos de JDK 1.2,

package consultorSql; import java.util.Vector; import java.sql.*; import javax.swing.table.AbstractTableModel; import javax.swing.event.TableModelEvent; public class JDBCAdapter extends AbstractTableModel { Connection connection; Statement statement; ResultSet resultSet;

Vector rows = new Vector(); ResultSetMetaData metaData; public JDBCAdapter() { } public JDBCAdapter(String url, String driverName, String user, String passwd) { try{

open(url,driverName,user,passwd); } catch (Exception e) { System.err.println(e); } }

268

Código Fuente

fireTableChanged(null); // Tell the listeners a new table

/** * Ejecuta la consulta pasada por parametro. */ public void executeQuery(String query) throws SQLException { if (connection == null || statement == null) { SQLException e=new SQLException("Base de datos

Cerrada"); System.err.println("No hay base de datos que ejecute la

consulta, debe conectarse a una"); throw e; } resultSet = statement.executeQuery(query); metaData = resultSet.getMetaData(); int numberOfColumns = metaData.getColumnCount(); columnNames = new String[numberOfColumns]; // Get the column names and cache them. // Then we can close the connection. for(int column = 0; column < numberOfColumns; column++) { columnNames[column] = metaData.getColumnLabel(column+1); } // Get all rows. rows = new Vector(); while (resultSet.next()) { Vector newRow = new Vector(); for (int i = 1; i <= getColumnCount(); i++) { newRow.addElement(resultSet.getObject(i)); } rows.addElement(newRow); }

// has arrived. } /********************************************************************** * Abre la coneccion a la base de datos con los atributos de coneccion. */ public void open(String url, String driverName, String user, String passwd) throws Exception { Class.forName(driverName); System.out.println("conectando a la base de datos..."); connection = DriverManager.getConnection(url, user, passwd); statement = connection.createStatement();

}

269

Código Fuente /**

*/

System.out.println("Cerrando la conneccion a la base de datos");

return Boolean.class;

* Cierra la conneccion a la base de datos.

public void close() throws SQLException {

resultSet.close(); statement.close(); connection.close(); } protected void finalize() throws Throwable { close(); super.finalize(); } ////////////////////////////////////////////////////////////////////////// // // Implementacion de la interfaz TableModel // ////////////////////////////////////////////////////////////////////////// // MetaData public String getColumnName(int column) { if (columnNames[column] != null) { return columnNames[column]; } else { return ""; } } public Class getColumnClass(int column) { int type; try { type = metaData.getColumnType(column+1); } catch (SQLException e) { return super.getColumnClass(column); } switch(type) { case Types.CHAR: case Types.VARCHAR: case Types.LONGVARCHAR: return String.class; case Types.BIT:

case Types.TINYINT:

270

Código Fuente

}

case Types.SMALLINT: case Types.INTEGER: return Integer.class; case Types.BIGINT: return Long.class; case Types.FLOAT: case Types.DOUBLE: return Double.class; case Types.DATE: return java.sql.Date.class; default: return Object.class; } } public boolean isCellEditable(int row, int column) { try { return metaData.isWritable(column+1); } catch (SQLException e) { return false; }

public int getColumnCount() { return columnNames.length; } // Data methods public int getRowCount() { return rows.size(); } public Object getValueAt(int aRow, int aColumn) { Vector row = (Vector)rows.elementAt(aRow); return row.elementAt(aColumn); } public String dbRepresentation(int column, Object value) { int type; if (value == null) { return "null"; } try { type = metaData.getColumnType(column+1); } catch (SQLException e) {

271

Código Fuente

try {

" where ";

for(int col = 0; col<getColumnCount(); col++) {

if (colName.equals("")) {

}

query = query + " and ";

query = query + colName +" = "+

//System.out.println("Not sending update to database");

}

}

dataRow.setElementAt(value, column);

return value.toString(); } switch(type) { case Types.INTEGER: case Types.DOUBLE: case Types.FLOAT: return value.toString(); case Types.BIT: return ((Boolean)value).booleanValue() ? "1" : "0"; case Types.DATE: return value.toString().trim(); default: return "\""+value.toString()+"\""; }

} public void setValueAt(Object value, int row, int column) {

String tableName = metaData.getTableName(column+1); if (tableName == null) { System.out.println("Table name returned null."); } String columnName = getColumnName(column); String query = "update "+tableName+ " set "+columnName+" = "+dbRepresentation(column, value)+

// We don't have a model of the schema so we don't know the // primary keys or which columns to lock on. To demonstrate // that editing is possible, we'll just lock on everything.

String colName = getColumnName(col);

continue;

if (col != 0) {

}

dbRepresentation(col, getValueAt(row, col)); } System.out.println(query);

// statement.executeQuery(query);

catch (SQLException e) { // e.printStackTrace(); System.err.println("Update failed");

Vector dataRow = (Vector)rows.elementAt(row);

272

Código Fuente

* The OldJTable is an unsupported class containing some methods that

} }

C.4.1.5 Clase: OldJTable //Nota: esta clase pertenece a los ejemplos de JDK 1.2, // pero tiene algunas modificaciones para ser utilizada en este proyecto package consultorSql; import java.lang.Thread; import java.util.*; import java.awt.*; import java.awt.event.*; import javax.swing.*; import javax.swing.event.*; import javax.swing.plaf.*; import javax.swing.table.*; /**

* were deleted from the JTable between releases 0.6 and 0.7 */ public class OldJTable extends JTable { /* * A new convenience method returning the index of the column in the * co-ordinate space of the view. */ public int getColumnIndex(Object identifier) { return getColumnModel().getColumnIndex(identifier); } // // Methods deleted from the JTable because they only work with the // DefaultTableModel. // public TableColumn addColumn(Object columnIdentifier, int width) { return addColumn(columnIdentifier, width, null, null, null); } public TableColumn addColumn(Object columnIdentifier, Vector columnData) { return addColumn(columnIdentifier, -1, null, null, columnData); } public TableColumn addColumn(Object columnIdentifier, int width, TableCellRenderer renderer,TableCellEditor editor)

273

Código Fuente

TableCellRenderer renderer, TableCellEditor editor, Vector columnData)

checkDefaultTableModel();

DefaultTableModel m = (DefaultTableModel)getModel();

{ return addColumn(columnIdentifier, width, renderer, editor, null); } public TableColumn addColumn(Object columnIdentifier, int width,

{

// Set up the model side first

m.addColumn(columnIdentifier, columnData);

}

public void insertRow(int rowIndex, Object[] rowData) {

// The column will have been added to the end, so the index of the // column in the model is the last element. TableColumn newColumn = new TableColumn(m.getColumnCount()-1,

width, renderer, editor); super.addColumn(newColumn); return newColumn; } public void removeColumn(Object columnIdentifier) { super.removeColumn(getColumn(columnIdentifier)); } public void addRow(Object[] rowData) { checkDefaultTableModel(); ((DefaultTableModel)getModel()).addRow(rowData); } public void addRow(Vector rowData) { checkDefaultTableModel(); ((DefaultTableModel)getModel()).addRow(rowData); } public void removeRow(int rowIndex) { checkDefaultTableModel(); ((DefaultTableModel)getModel()).removeRow(rowIndex); } public void moveRow(int startIndex, int endIndex, int toIndex) { checkDefaultTableModel(); ((DefaultTableModel)getModel()).moveRow(startIndex, endIndex,

toIndex);

checkDefaultTableModel(); ((DefaultTableModel)getModel()).insertRow(rowIndex, rowData); } public void insertRow(int rowIndex, Vector rowData) {

274

Código Fuente

}

public void setDataVector(Object[][] newData, Object[] columnIds) {

//

checkDefaultTableModel(); ((DefaultTableModel)getModel()).insertRow(rowIndex, rowData); } public void setNumRows(int newSize) { checkDefaultTableModel(); ((DefaultTableModel)getModel()).setNumRows(newSize); } public void setDataVector(Vector newData, Vector columnIds) { checkDefaultTableModel(); ((DefaultTableModel)getModel()).setDataVector(newData, columnIds);

checkDefaultTableModel(); ((DefaultTableModel)getModel()).setDataVector(newData, columnIds); } protected void checkDefaultTableModel() { if(!(dataModel instanceof DefaultTableModel)) throw new InternalError("In order to use this method, the

data model must be an instance of efaultTableModel."); } // // Methods removed from JTable in the move from identifiers to ints.

public Object getValueAt(Object columnIdentifier, int rowIndex) {

return super.getValueAt(rowIndex, getColumnIndex(columnIdentifier));

}

public boolean isCellEditable(Object columnIdentifier, int rowIndex) {

return super.isCellEditable(rowIndex, getColumnIndex(columnIdentifier));

} public void setValueAt(Object aValue, Object columnIdentifier, int rowIndex) {

super.setValueAt(aValue, rowIndex,getColumnIndex(columnIdentifier));

} public boolean editColumnRow(Object identifier, int row) { return super.editCellAt(row, getColumnIndex(identifier)); } public void moveColumn(Object columnIdentifier,

Object targetColumnIdentifier)

275

Código Fuente

return isColumnSelected(getColumnIndex(identifier));

public TableColumn addColumn(int modelColumn) {

* <p>

* @param editor The editor used with the new column.

*/

public TableColumn addColumn(int modelColumn, int width,

{ moveColumn(getColumnIndex(columnIdentifier), getColumnIndex(targetColumnIdentifier)); } public boolean isColumnSelected(Object identifier) {

} public TableColumn addColumn(int modelColumn, int width) { return addColumn(modelColumn, width, null, null); }

return addColumn(modelColumn, 75, null, null); } /** * Creates a new column with <I>modelColumn</I>, <I>width</I>, * <I>renderer</I>, and <I>editor</I> and adds it to the end of * the JTable's array of columns. This method also retrieves the * name of the column using the model's <I> * getColumnName(modelColumn) </I> method, and sets the both the * header value and the identifier for this TableColumn accordingly.

* The <I>modelColumn</I> is the index of the column in the model * which will supply the data for this column in the table. This, * like the <I>columnIdentifier</I> in previous releases, does not * change as the columns are moved in the view. * <p> * For the rest of the JTable API, and all of its associated * classes, columns are referred to in the co-ordinate system of the * view, the index of the column in the model is kept inside the * TableColumn and is used only to retrieve the information from the * appropraite column in the model. * <p> * * @param modelColumn The index of the column in the model * @param width The new column's width. Or -1 to use * the default width * @param renderer The renderer used with the new column. * Or null to use the default renderer.

* Or null to use the default editor.

TableCellRenderer renderer, TableCellEditor editor) { TableColumn newColumn = new TableColumn(modelColumn, width,

renderer, editor); addColumn(newColumn); return newColumn;

276

Código Fuente

// pero tiene algunas modificaciones para ser utilizada en este proyecto

import javax.swing.JWindow;

private TableSorter sorter=new TableSorter();

private String usr="";

private String url="";

} public boolean editColumnRow(int columnIndex, int rowIndex) { return super.editCellAt(rowIndex, columnIndex); } public boolean editColumnRow(int columnIndex, int rowIndex,

EventObject e) { return super.editCellAt(rowIndex, columnIndex, e); } } // End Of Class OldJTable

C.4.1.6 Clase sqlQuery //Nota: esta clase pertenece a los ejemplos de JDK 1.2,

package consultorSql; import java.sql.SQLException; import javax.swing.JOptionPane; import javax.swing.JTable; import java.awt.event.*;

public class sqlQuery extends JTable {

private JDBCAdapter dataBase=new JDBCAdapter();

private String passwd="";

private String driver=""; private String query=""; private boolean active=false; /** * Constructor por derfecto del sqlQuery */ public sqlQuery() { this.setModel(sorter); sorter.addMouseListenerToHeaderInTable(this); sorter.setModel(dataBase) ; try { jbInit(); } catch(Exception e) { e.printStackTrace(); }

277

Código Fuente

(query!=""))

} /** * Funcion mutadora de Usr */ public void setUsr(String usr) { this.usr=usr; } /** * Funcion mutadora de passwd */ public void setPasswd(String passwd) { this.passwd = passwd; } /** * Funcion mutadora de Url */ public void setUrl(String url) { this.url = url; } /** * Funcion mutadora de driver */ public void setDriver(String driver) { this.driver = driver; } /** * Funcion mutadora de query */ public void setQuery(String query) { this.query = query; } /** * Funcion mutadora de active */ public void setActive(boolean active) { if (active) { if ((url!="") && (driver!="") && ( usr !="") && (passwd !="") &&

{ try { dataBase.open(url,driver,usr,passwd);

278

Código Fuente

else

try

System.err.println(e);

* Funcion observadora de passwd

return this.url ;

dataBase.executeQuery(query) ; sorter.setModel(dataBase); } catch (Exception e) { System.err.println(e); active=false; } } else active=false; }

{

{ dataBase.close() ; } catch (Exception e) { System.err.println("base de datos no se pudo cerrar");

active=false; } } this.active = active; } /** * Funcion observadora de Usr */ public String getUsr() { return this.usr; } /**

*/ public String getPasswd() { return this.passwd; } /** * Funcion observadora de Url */ public String getUrl() {

}

/** * Funcion observadora de driver */

279

Código Fuente

*/

{

{

public String getDriver() { return this.driver; } /** * Funcion observadora de active */ public boolean getActive() { return this.active; } /** * Funcion observadora de query

public String getQuery() { return this.query; } /** * Funcion que ejecuta la consulta del atributo query */ public void exeQuery()

if (!this.active) {this.setActive(true);} try { dataBase.executeQuery(query); } catch (SQLException e){ JOptionPane.showMessageDialog(this,e.getMessage()) ; } } private void jbInit() throws Exception { this.setAutoResizeMode(JTable.AUTO_RESIZE_ALL_COLUMNS); this.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(FocusEvent e) { this_focusGained(e); } }); } void this_focusGained(FocusEvent e)

}

280

Código Fuente

C.4.1.7 Clase: TableMap

}

return (model == null) ? 0 : model.getColumnCount();

return model.getColumnClass(aColumn);

return model.isCellEditable(row, column);

}

//Nota: esta clase pertenece a los ejemplos de JDK 1.2, // pero tiene algunas modificaciones para ser utilizada en este proyecto package consultorSql; import javax.swing.table.*; import javax.swing.event.TableModelListener; import javax.swing.event.TableModelEvent;

public class TableMap extends AbstractTableModel implements TableModelListener { protected TableModel model; public TableModel getModel() { return model; } public void setModel(TableModel model) { this.model = model; model.addTableModelListener(this); } // By default, Implement TableModel by forwarding all messages // to the model. public Object getValueAt(int aRow, int aColumn) { return model.getValueAt(aRow, aColumn); } public void setValueAt(Object aValue, int aRow, int aColumn) { model.setValueAt(aValue, aRow, aColumn); } public int getRowCount() { return (model == null) ? 0 : model.getRowCount();

public int getColumnCount() {

} public String getColumnName(int aColumn) { return model.getColumnName(aColumn); }

public Class getColumnClass(int aColumn) {

}

public boolean isCellEditable(int row, int column) {

281

Código Fuente

// Implementation of the TableModelListener interface,

// Imports for picking up mouse events from the JTable.

import javax.swing.table.TableColumn;

public void setModel(TableModel model) {

public int compareRowsByColumn(int row1, int row2, int column)

} //

// By default forward all events to all the listeners. public void tableChanged(TableModelEvent e) { fireTableChanged(e); } }

C.4.1.8 Clase: TableSorter //Nota: esta clase pertenece a los ejemplos de JDK 1.2, // pero tiene algunas modificaciones para ser utilizada en este proyecto package consultorSql; import java.util.*; import javax.swing.table.TableModel; import javax.swing.event.TableModelEvent;

import java.awt.event.MouseAdapter; import java.awt.event.MouseEvent; import java.awt.event.InputEvent; import javax.swing.JTable; import javax.swing.table.JTableHeader;

import javax.swing.table.TableColumnModel;

public class TableSorter extends TableMap { int indexes[]; Vector sortingColumns = new Vector(); boolean ascending = true; int compares; public TableSorter() { indexes = new int[0]; // For consistency. }

public TableSorter(TableModel model) { setModel(model); }

super.setModel(model); reallocateIndexes(); }

{

282

Código Fuente Class type = model.getColumnClass(column); TableModel data = model; // Check for nulls Object o1 = data.getValueAt(row1, column); Object o2 = data.getValueAt(row2, column);

double d2 = n2.doubleValue();

// If both values are null return 0 if (o1 == null && o2 == null) { return 0; } else if (o1 == null) { // Define null less than everything. return -1; } else if (o2 == null) { return 1; }

/* We copy all returned values from the getValue call in case an optimised model is reusing one object to return many values. The Number subclasses in the JDK are immutable and so will not be used in this way but other subclasses of Number might want to do this to save space and avoid unnecessary heap allocation. */

if (type.getSuperclass() == java.lang.Number.class) { Number n1 = (Number)data.getValueAt(row1, column); double d1 = n1.doubleValue(); Number n2 = (Number)data.getValueAt(row2, column);

else if (type == java.util.Date.class)

if (d1 < d2) return -1; else if (d1 > d2) return 1; else return 0; }

{ Date d1 = (Date)data.getValueAt(row1, column); long n1 = d1.getTime(); Date d2 = (Date)data.getValueAt(row2, column); long n2 = d2.getTime(); if (n1 < n2) return -1; else if (n1 > n2) return 1; else return 0; } else if (type == String.class) {

283

Código Fuente String s1 = (String)data.getValueAt(row1, column); String s2 = (String)data.getValueAt(row2, column); int result = s1.compareTo(s2);

}

if (result < 0) return -1; else if (result > 0) return 1; else return 0;

else if (type == Boolean.class) { Boolean bool1 = (Boolean)data.getValueAt(row1, column); boolean b1 = bool1.booleanValue(); Boolean bool2 = (Boolean)data.getValueAt(row2, column); boolean b2 = bool2.booleanValue();

if (result < 0)

else if (result > 0)

if (b1 == b2) return 0; else if (b1) // Define false < true return 1; else return -1; } else { Object v1 = data.getValueAt(row1, column); String s1 = v1.toString(); Object v2 = data.getValueAt(row2, column); String s2 = v2.toString(); int result = s1.compareTo(s2);

return -1;

return 1; else return 0; } }

{

int result = compareRowsByColumn(row1, row2,

public int compare(int row1, int row2) { compares++; for(int level = 0; level < sortingColumns.size(); level++)

Integer column = (Integer)sortingColumns.elementAt(level);

column.intValue()); if (result != 0) return ascending ? result : -result; } return 0; }

public void reallocateIndexes()

284

Código Fuente { int rowCount = model.getRowCount(); // Set up a new array of indexes with the right number of elements // for the new data model. indexes = new int[rowCount]; for(int row = 0; row < rowCount; row++)

// Initialise with the identity mapping.

indexes[row] = row; } public void tableChanged(TableModelEvent e) { System.out.println("Sorter: tableChanged"); reallocateIndexes(); super.tableChanged(e); } public void checkModel() { if (indexes.length != model.getRowCount()) { System.err.println("Sorter not informed of a change in

model."); } } public void sort(Object sender) { checkModel(); compares = 0; // n2sort(); // qsort(0, indexes.length-1); //similar a mergesort; shuttlesort((int[])indexes.clone(), indexes, 0, indexes.length); System.out.println("Compares: "+compares); }

public void n2sort() { for(int i = 0; i < getRowCount(); i++) { for(int j = i+1; j < getRowCount(); j++) { if (compare(indexes[i], indexes[j]) == -1) { swap(i, j); } } } } // This is a home-grown implementation which we have not had time // to research - it may perform poorly in some circumstances. It // requires twice the space of an in-place algorithm and makes // NlogN assigments shuttling the values between the two // arrays. The number of compares appears to vary between N-1 and

285

Código Fuente

// using it here is that, unlike qsort, it is stable.

int p = low;

// NlogN depending on the initial order but the main reason for

public void shuttlesort(int from[], int to[], int low, int high) { if (high - low < 2) { return; } int middle = (low + high)/2; shuttlesort(to, from, low, middle); shuttlesort(to, from, middle, high);

int q = middle; /* This is an optional short-cut; at each recursive call, check to see if the elements in this subset are already ordered. If so, no further comparisons are needed; the sub-array can just be copied. The array must be copied rather than assigned otherwise sister calls in the recursion might get out of sinc. When the number of elements is three they are partitioned so that the first set, [low, mid), has one element and and the second, [mid, high), has two. We skip the optimisation when the number of elements is three or less as the first compare in the normal merge will produce the same sequence of steps. This optimisation seems to be worthwhile for partially ordered lists but some analysis is needed to find out how the performance drops to Nlog(N) as the initial order diminishes - it may drop very quickly. */ {

if (high - low >= 4 && compare(from[middle-1], from[middle]) <= 0)

for (int i = low; i < high; i++) { to[i] = from[i]; } return; } // A normal merge. for(int i = low; i < high; i++) { if (q >= high || (p < middle && compare(from[p], from[q]) <=

0)) { to[i] = from[p++]; } else { to[i] = from[q++]; } } } public void swap(int i, int j) { int tmp = indexes[i];

286

Código Fuente indexes[i] = indexes[j];

}

// The mapping only affects the contents of the data rows.

}

}

public void sortByColumn(int column, boolean ascending) {

sortingColumns.removeAllElements();

int shiftPressed=e.getModifiers()&InputEvent.SHIFT_MASK;

};

indexes[j] = tmp;

// Pass all requests to these rows through the mapping array: // "indexes". public Object getValueAt(int aRow, int aColumn) { checkModel(); return model.getValueAt(indexes[aRow], aColumn);

public void setValueAt(Object aValue, int aRow, int aColumn) { checkModel(); model.setValueAt(aValue, indexes[aRow], aColumn); } public void sortByColumn(int column) { sortByColumn(column, true);

this.ascending = ascending;

sortingColumns.addElement(new Integer(column)); sort(this); super.tableChanged(new TableModelEvent(this)); } // There is no-where else to put this. // Add a mouse listener to the Table to trigger a table sort // when a column heading is clicked in the JTable. public void addMouseListenerToHeaderInTable(JTable table) { final TableSorter sorter = this; final JTable tableView = table; tableView.setColumnSelectionAllowed(false); MouseAdapter listMouseListener = new MouseAdapter() { public void mouseClicked(MouseEvent e) { TableColumnModel columnModel = tableView.getColumnModel(); int viewColumn = columnModel.getColumnIndexAtX(e.getX()); int column =tableView.convertColumnIndexToModel(viewColumn); if(e.getClickCount() == 1 && column != -1) { System.out.println("Sorting ...");

boolean ascending = (shiftPressed == 0); sorter.sortByColumn(column, ascending); } }

JTableHeader th = tableView.getTableHeader();

287

Código Fuente th.addMouseListener(listMouseListener); } }

288

Código Fuente

JMenuItem menuAbrirCuenca = new JMenuItem();

C.4.2 Paquete cuencamaule

En esta sección mostraremos algunas clases, puesto que la mayoría son 100%

generadas por el RAD JBUILDER 4, a partir del diseño visual de las ventanas.

C.4.2.1 Clase: Frame1 package cuencamaule; import java.awt.*; import java.awt.event.*; import javax.swing.*; import figuras.*; import consultorSql.*; import objcuenca.*; import java.util.*; import javax.swing.border.*; import java.sql.Connection; public class Frame1 extends JFrame { boolean insert=false; int tipoInsert=0; private static final int INSERT_CANAL=1; private static final int INSERT_CAP_AGUA_POT=2; private Graficable figInsert; private int countClick=0; private ArrPuntosOra puntos; JPanel contentPane; CuencaOraRef CuencaActualRef; BDObjCuenca dataBase=new BDObjCuenca(); JMenuBar jMenuBar1 = new JMenuBar(); JMenu jMenuFile = new JMenu(); JMenuItem jMenuFileExit = new JMenuItem(); JMenu jMenuHelp = new JMenu(); JMenuItem jMenuHelpAbout = new JMenuItem(); JToolBar jToolBar = new JToolBar(); JButton btAbrir = new JButton(); JButton jButton2 = new JButton(); JButton jButton3 = new JButton(); ImageIcon image1; ImageIcon image2; ImageIcon image3; JLabel statusBar = new JLabel(); BorderLayout borderLayout1 = new BorderLayout(); JScrollPane FigurasSP = new JScrollPane();

JMenu jMenu1 = new JMenu(); JMenuItem mnuNodo = new JMenuItem(); JMenuItem menuNueva = new JMenuItem(); JMenuItem mnuEm = new JMenuItem(); JMenuItem mnuHI = new JMenuItem();

289

Código Fuente

JRadioButtonMenuItem jRadioButtonMenuItem8 = new

JRadioButtonMenuItem();

JMenuItem mnRN = new JMenuItem(); JMenuItem mnuTr = new JMenuItem(); JMenuItem mnuCAP = new JMenuItem(); JMenuItem mnuCanal = new JMenuItem(); JMenuItem mnuCentHidro = new JMenuItem(); JMenuItem menuModificarCuenca = new JMenuItem(); JMenu jMenu2 = new JMenu(); JRadioButtonMenuItem jRadioButtonMenuItem2 = new JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem3 = new JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem4 = new JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem5 = new JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem7 = new JRadioButtonMenuItem();

JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem9 = new JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem10 = new JRadioButtonMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem6 = new

JMenu jMenu3 = new JMenu(); JMenuItem mnuEmbBajos = new JMenuItem(); JMenuItem mnuEnGen = new JMenuItem(); JRadioButtonMenuItem jRadioButtonMenuItem11 = new JRadioButtonMenuItem(); JMenuItem jMenuSimular = new JMenuItem(); JMenuItem jMenuItem17 = new JMenuItem(); JMenuItem jMenuItem2 = new JMenuItem(); JMenuItem jMenuItem18 = new JMenuItem(); JMenuItem jMenuItem19 = new JMenuItem(); FrmConexion datosConeccion; LienzoCuenca lienzo = new LienzoCuenca(); JPanel jPanel1 = new JPanel(); JPanel jPanel3 = new JPanel(); Border border1; JPanel jPanel4 = new JPanel(); GridBagLayout gridBagLayout2 = new GridBagLayout(); JLabel jlMensaje = new JLabel(); JPanel jPanel5 = new JPanel(); GridBagLayout gridBagLayout1 = new GridBagLayout(); JLabel jlPunto = new JLabel(); JPanel jPanel2 = new JPanel(); JMenu jMenu4 = new JMenu(); JMenuItem menuNuevoRio = new JMenuItem(); JMenuItem menuModificarRio = new JMenuItem(); /**Construct the frame*/ public Frame1() { enableEvents(AWTEvent.WINDOW_EVENT_MASK); try {

290

Código Fuente jbInit();

image1 = new

jMenuFileExit.setText("Salir");

jMenuHelpAbout.setText("Acerca de...");

btAbrir.addActionListener(new java.awt.event.ActionListener()

} catch(Exception e) { e.printStackTrace(); } } /**Component initialization*/ private void jbInit() throws Exception {

ImageIcon(cuencamaule.Frame1.class.getResource("openFile.gif")); image2 = new ImageIcon(cuencamaule.Frame1.class.getResource("closeFile.gif")); image3 = new ImageIcon(cuencamaule.Frame1.class.getResource("help.gif")); contentPane = (JPanel) this.getContentPane(); contentPane.setLayout(borderLayout1); this.setSize(new Dimension(647, 452)); this.addWindowListener(new java.awt.event.WindowAdapter() { public void windowOpened(WindowEvent e) { this_windowOpened(e); } }); this.setTitle("Modelo de Simulación Hidrologico Operacional"); statusBar.setText(" "); jMenuFile.setText("Cuenca"); jMenuFile.setMnemonic('C'); jMenuFileExit.setAccelerator(javax.swing.KeyStroke.getKeyStroke(88, java.awt.event.KeyEvent.CTRL_MASK, true));

jMenuFileExit.setMnemonic('S'); jMenuFileExit.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { jMenuFileExit_actionPerformed(e); } }); jMenuHelp.setText("Ayuda"); jMenuHelp.setMnemonic('A');

jMenuHelpAbout.setMnemonic('c'); jMenuHelpAbout.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { jMenuHelpAbout_actionPerformed(e); } }); btAbrir.setIcon(image1); btAbrir.setToolTipText("Open File");

{ public void actionPerformed(ActionEvent e) {

291

Código Fuente

{

mnuNodo.setText("Nodo");

});

java.awt.event.KeyEvent.CTRL_MASK, true));

menuNueva.setMnemonic('N');

btAbrir_actionPerformed(e); } }); jButton2.setIcon(image2); jButton2.setToolTipText("Simular"); jButton3.setIcon(image3); jButton3.setToolTipText("Ayuda");

FigurasSP.setVerticalScrollBarPolicy( JScrollPane.VERTICAL_SCROLLBAR_ALWAYS); FigurasSP.setHorizontalScrollBarPolicy( JScrollPane.HORIZONTAL_SCROLLBAR_ALWAYS); FigurasSP.getViewport().setBackground(Color.white); menuAbrirCuenca.setText("Abrir..."); menuAbrirCuenca.setMnemonic('A'); menuAbrirCuenca.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e)

menuAbrirCuenca_actionPerformed(e); } }); jMenu1.setText("Insertar"); jMenu1.setMnemonic('I'); mnuNodo.setEnabled(false);

mnuNodo.setMnemonic('N'); mnuNodo.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuNodo_actionPerformed(e); }

menuNueva.setAccelerator(javax.swing.KeyStroke.getKeyStroke(78,

menuNueva.setText("Nueva...");

menuNueva.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { menuNueva_actionPerformed(e); } }); mnuEm.setEnabled(false); mnuEm.setText("Embalse"); mnuEm.setMnemonic('E'); mnuEm.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuEm_actionPerformed(e);

292

Código Fuente

mnRN_actionPerformed(e);

});


mnuCAP_actionPerformed(e);

});

mnuCanal.setText("Canal");

} }); mnuHI.setEnabled(false); mnuHI.setText("Hoya Intermedia"); mnuHI.setMnemonic('H'); mnuHI.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuHI_actionPerformed(e); } }); mnRN.setEnabled(false); mnRN.setText("Regimen Natural"); mnRN.setMnemonic('g'); mnRN.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) {

} }); mnuTr.setEnabled(false); mnuTr.setText("Tramo"); mnuTr.setMnemonic('T'); mnuTr.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuTr_actionPerformed(e); }

mnuCAP.setEnabled(false); mnuCAP.setText("Captación Agua Potable"); mnuCAP.setMnemonic('C'); mnuCAP.addActionListener(new java.awt.event.ActionListener() {

{

}

mnuCanal.setEnabled(false);

mnuCanal.setMnemonic('a'); mnuCanal.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuCanal_actionPerformed(e); } }); mnuCentHidro.setEnabled(false); mnuCentHidro.setText("Central Hidroeléctrica");

293

Código Fuente

menuModificarCuenca.setEnabled(false);

{

mnuCentHidro.setMnemonic('l'); mnuCentHidro.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuCentHidro_actionPerformed(e); } });

menuModificarCuenca.setText("Modificar..."); menuModificarCuenca.setMnemonic(77); menuModificarCuenca.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { menuModificarCuenca_actionPerformed(e); } }); jMenu2.setText("Zoom"); jMenu2.setMnemonic('Z'); jRadioButtonMenuItem2.setEnabled(false); jRadioButtonMenuItem2.setText("15%"); jRadioButtonMenuItem2.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem2_actionPerformed(e); } }); jRadioButtonMenuItem3.setEnabled(false); jRadioButtonMenuItem3.setText("30%"); jRadioButtonMenuItem3.addActionListener(new java.awt.event.ActionListener()

public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem3_actionPerformed(e); } }); jRadioButtonMenuItem4.setEnabled(false); jRadioButtonMenuItem4.setText("50%"); jRadioButtonMenuItem4.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem4_actionPerformed(e); } }); jRadioButtonMenuItem5.setEnabled(false); jRadioButtonMenuItem5.setText("75%"); jRadioButtonMenuItem5.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) {

294

Código Fuente

jRadioButtonMenuItem7.addActionListener(new

jRadioButtonMenuItem8.setText("150%");

java.awt.event.ActionListener() {

jRadioButtonMenuItem5_actionPerformed(e); } }); jRadioButtonMenuItem7.setEnabled(false); jRadioButtonMenuItem7.setText("125%");

java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem7_actionPerformed(e); } }); jRadioButtonMenuItem8.setEnabled(false);

jRadioButtonMenuItem8.addActionListener(new

public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem8_actionPerformed(e); } }); jRadioButtonMenuItem9.setEnabled(false); jRadioButtonMenuItem9.setText("200%"); jRadioButtonMenuItem9.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem9_actionPerformed(e); } }); jRadioButtonMenuItem10.setEnabled(false); jRadioButtonMenuItem10.setText("300%"); jRadioButtonMenuItem10.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem10_actionPerformed(e); } }); jRadioButtonMenuItem6.setEnabled(false); jRadioButtonMenuItem6.setSelected(true); jRadioButtonMenuItem6.setText("100%"); jRadioButtonMenuItem6.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem6_actionPerformed(e); } }); jMenu3.setText("Consultas"); jMenu3.setMnemonic('o'); mnuEmbBajos.setEnabled(false); mnuEmbBajos.setText("Embalse Bajo sus Volumens Minimos..."); mnuEmbBajos.setMnemonic('E'); mnuEmbBajos.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) {

295

Código Fuente mnuEmbBajos_actionPerformed(e); } }); mnuEnGen.setEnabled(false); mnuEnGen.setText("Energía Generada..."); mnuEnGen.setMnemonic('n'); mnuEnGen.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { mnuEnGen_actionPerformed(e); } }); ButtonGroup group = new ButtonGroup(); jRadioButtonMenuItem11.setEnabled(false); jRadioButtonMenuItem11.setText("Personalizado..."); jRadioButtonMenuItem11.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jRadioButtonMenuItem11_actionPerformed(e); } }); jMenuSimular.setEnabled(false); jMenuSimular.setText("Iniciar Simulación..."); jMenuSimular.setMnemonic(73); jMenuSimular.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jMenuSimular_actionPerformed(e); } }); jMenuItem17.setText("Conección..."); jMenuItem17.setMnemonic('o'); jMenuItem17.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jMenuItem17_actionPerformed(e); } }); jMenuItem2.setText("SQL..."); jMenuItem2.setMnemonic('S'); jMenuItem2.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { jMenuItem2_actionPerformed(e); } }); jMenuItem18.setText("Contenido...");

296

Código Fuente

jMenuItem19.setMnemonic('B');


jMenuItem18.setMnemonic('C'); jMenuItem19.setText("Búsqueda...");

jPanel4.setLayout(gridBagLayout2); jPanel3.setLayout(gridBagLayout1); jMenu4.setText("Rio"); jMenu4.setMnemonic(82); menuNuevoRio.setText("Nuevo..."); menuNuevoRio.setMnemonic(78); menuNuevoRio.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { menuNuevoRio_actionPerformed(e); } }); menuModificarRio.setText("Modificar..."); menuModificarRio.setMnemonic(77); menuModificarRio.addActionListener(new java.awt.event.ActionListener() {

{ menuModificarRio_actionPerformed(e); } }); lienzo.setBackground(Color.white); lienzo.addMouseListener(new java.awt.event.MouseAdapter() { public void mouseClicked(MouseEvent e) { lienzo_mouseClicked(e); } }); group.add(jRadioButtonMenuItem2); group.add(jRadioButtonMenuItem3); group.add(jRadioButtonMenuItem4); group.add(jRadioButtonMenuItem5); group.add(jRadioButtonMenuItem6); group.add(jRadioButtonMenuItem7); group.add(jRadioButtonMenuItem8); group.add(jRadioButtonMenuItem9); group.add(jRadioButtonMenuItem10); group.add(jRadioButtonMenuItem11); jMenuFile.add(menuNueva); jMenuFile.add(menuAbrirCuenca); jMenuFile.add(menuModificarCuenca); jMenuFile.addSeparator(); jMenuFile.add(jMenuItem17); jMenuFile.add(jMenuSimular); jMenuFile.addSeparator(); jMenuFile.add(jMenuFileExit);

297

Código Fuente

jMenuBar1.add(jMenuHelp);

jToolBar.add(jButton2);

jMenuHelp.add(jMenuItem18); jMenuHelp.add(jMenuItem19); jMenuHelp.add(jMenuHelpAbout); jMenuBar1.add(jMenuFile); jMenuBar1.add(jMenu4); jMenuBar1.add(jMenu2); jMenuBar1.add(jMenu1); jMenuBar1.add(jMenu3);

this.setJMenuBar(jMenuBar1); contentPane.add(FigurasSP, BorderLayout.CENTER); FigurasSP.getViewport().add(lienzo, null); contentPane.add(jToolBar, BorderLayout.NORTH); jToolBar.add(btAbrir);

jToolBar.add(jButton3, null); contentPane.add(jPanel3, BorderLayout.SOUTH); jPanel3.add(jlMensaje, new GridBagConstraints(0, 0, 1, 1, 1.0, 1.0 ,GridBagConstraints.WEST, GridBagConstraints.BOTH, new Insets(0, 12, 4, 8), 0, 0)); jPanel3.add(jlPunto, new GridBagConstraints(1, 0, 1, 1, 0.0, 0.0 ,GridBagConstraints.CENTER, GridBagConstraints.BOTH, new Insets(4, 12, 4, 12), 0, 0)); contentPane.add(jPanel5, BorderLayout.EAST); contentPane.add(jPanel2, BorderLayout.WEST); jMenu1.add(mnuNodo); jMenu1.add(mnuTr); jMenu1.add(mnuEm); jMenu1.add(mnuHI); jMenu1.add(mnRN); jMenu1.add(mnuCAP); jMenu1.add(mnuCanal); jMenu1.add(mnuCentHidro); jMenu2.add(jRadioButtonMenuItem2); jMenu2.add(jRadioButtonMenuItem3); jMenu2.add(jRadioButtonMenuItem4); jMenu2.add(jRadioButtonMenuItem5); jMenu2.add(jRadioButtonMenuItem6); jMenu2.add(jRadioButtonMenuItem7); jMenu2.add(jRadioButtonMenuItem8); jMenu2.add(jRadioButtonMenuItem9); jMenu2.add(jRadioButtonMenuItem10); jMenu2.add(jRadioButtonMenuItem11); jMenu3.add(mnuEmbBajos); jMenu3.add(mnuEnGen); jMenu3.add(jMenuItem2); jMenu4.add(menuNuevoRio); jMenu4.add(menuModificarRio); } public void jMenuFileExit_actionPerformed(ActionEvent e) { System.exit(0); }

298

Código Fuente

void jRadioButtonMenuItem2_actionPerformed(ActionEvent e)

}

public void jMenuHelpAbout_actionPerformed(ActionEvent e) { Frame1_AboutBox dlg = new Frame1_AboutBox(this); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); dlg.setModal(true); dlg.show(); } /**Overridden so we can exit when window is closed*/ protected void processWindowEvent(WindowEvent e) { super.processWindowEvent(e); if (e.getID() == WindowEvent.WINDOW_CLOSING) { jMenuFileExit_actionPerformed(null); } } void jRadioButtonMenuItem1_actionPerformed(ActionEvent e) { lienzo.setZoom(5); }

{ lienzo.setZoom(15); }

void jRadioButtonMenuItem3_actionPerformed(ActionEvent e) { lienzo.setZoom(30); } void jRadioButtonMenuItem4_actionPerformed(ActionEvent e) { lienzo.setZoom(50); }

void jRadioButtonMenuItem5_actionPerformed(ActionEvent e) { lienzo.setZoom(75); } void jRadioButtonMenuItem6_actionPerformed(ActionEvent e) { lienzo.setZoom(100);

void jRadioButtonMenuItem7_actionPerformed(ActionEvent e) { lienzo.setZoom(125); } void jRadioButtonMenuItem8_actionPerformed(ActionEvent e) { lienzo.setZoom(150); }

299

Código Fuente

}

//llamar al dialogo de zoom

Point loc = getLocation();

String usr=datosConeccion.getUsr();

try{dataBase.open() ;}

Dimension dlgSize = dlg.getPreferredSize();

de datos "+ex.getMessage()) ;

void jRadioButtonMenuItem9_actionPerformed(ActionEvent e) { lienzo.setZoom(200);

void jRadioButtonMenuItem10_actionPerformed(ActionEvent e) { lienzo.setZoom(300); }

void jRadioButtonMenuItem11_actionPerformed(ActionEvent e) {

FrmZoom dlg = new FrmZoom(this, lienzo); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize();

dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); dlg.show(); }

void menuNueva_actionPerformed(ActionEvent e) { try { if ((dataBase==null)||(dataBase.isClosed())) {

String psswd=datosConeccion.getPasswd(); String url=datosConeccion.getUrl(); String drv=datosConeccion.getDriver(); dataBase=new BDObjCuenca(url,drv,usr,psswd);

catch(Exception err) { JOptionPane.showMessageDialog(this,err.getMessage()); err.printStackTrace(System.err) ; } } FrmCuenca dlg=new FrmCuenca(this.dataBase,null);

Dimension frmSize = getSize(); Point loc = getLocation(); dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack(); dlg.show(); } catch (Exception ex) { JOptionPane.showMessageDialog(this, "Error al conectar a la base

}

300

Código Fuente

void abrirCuenca()

{

String url=datosConeccion.getUrl();

FRMAbrirCuenca dlg = new FRMAbrirCuenca(this,dataBase);

Point loc = getLocation();

/**

{

String url=datosConeccion.getUrl();

dataBase=new BDObjCuenca(url,drv,usr,psswd);

}

{ try { if ((dataBase==null)||(dataBase.isClosed()))

String usr=datosConeccion.getUsr(); String psswd=datosConeccion.getPasswd();

String drv=datosConeccion.getDriver(); dataBase=new BDObjCuenca(url,drv,usr,psswd); dataBase.open() ; }

Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize();

dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack(); dlg.show(); } catch(Exception err) { JOptionPane.showMessageDialog(this,err.getMessage()); err.printStackTrace(System.err) ; } }

* Abre una cuenca. */ void menuAbrirCuenca_actionPerformed(ActionEvent e) { jlMensaje.setText("Abriendo la cuenca..."); abrirCuenca(); jlMensaje.setText(" "); } void menuModificarCuenca_actionPerformed(ActionEvent e)

try { if ((dataBase==null)||(dataBase.isClosed())) { String usr=datosConeccion.getUsr(); String psswd=datosConeccion.getPasswd();

String drv=datosConeccion.getDriver();

try{dataBase.open() ;} catch(Exception err) {

301

Código Fuente

Primero") ;

FrmCuenca dlg=new

dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x,

this.setTitle("Modelo de Simulacion Hidrologico operacional");

}

* pone en enable o disable todos los itemes del zoom

jRadioButtonMenuItem2.setEnabled(enabled);

jRadioButtonMenuItem6.setEnabled(enabled);

JOptionPane.showMessageDialog(this,err.getMessage()); err.printStackTrace(System.err) ; } } if (CuencaActualRef==null) { JOptionPane.showMessageDialog(this,"Debe Abrir una cuenca

} else {

FrmCuenca(this.dataBase,this.CuencaActualRef); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation();

(frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack(); dlg.show(); } } catch (Exception ex) { JOptionPane.showMessageDialog(this, "Error al conectar a la base de datos "+ex.getMessage()) ; } finally { if(FrmCuenca.accionRealizada==FrmCuenca.ELIMINAR) { setEnabledMenu(false);

this.CuencaActualRef=null; }

} /**

*/ private void setEnabledMenu(boolean enabled) {

jRadioButtonMenuItem3.setEnabled(enabled); jRadioButtonMenuItem4.setEnabled(enabled); jRadioButtonMenuItem5.setEnabled(enabled);

jRadioButtonMenuItem7.setEnabled(enabled); jRadioButtonMenuItem8.setEnabled(enabled); jRadioButtonMenuItem9.setEnabled(enabled); jRadioButtonMenuItem10.setEnabled(enabled); jRadioButtonMenuItem11.setEnabled(enabled);

302

Código Fuente

this.mnuNodo.setEnabled(enabled);

this.mnuEm.setEnabled(enabled);

}

this.menuModificarCuenca.setEnabled(enabled); this.jMenuSimular.setEnabled(enabled); this.mnRN.setEnabled(enabled); this.mnuCanal.setEnabled(enabled); this.mnuCAP.setEnabled(enabled); this.mnuCAP.setEnabled(enabled);

this.mnuCentHidro .setEnabled(enabled); this.mnuTr.setEnabled(enabled);

this.mnuHI.setEnabled(enabled); this.mnuEmbBajos.setEnabled(enabled); this.mnuEnGen.setEnabled(enabled); } /**************************************************************** * * Llama al dialogo de conección. * */ void jMenuItem17_actionPerformed(ActionEvent e) { Dimension dlgSize = datosConeccion.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); datosConeccion.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); datosConeccion.pack() ; datosConeccion.show(); } /************************************************************ * Realiza la simulación. */ void jMenuSimular_actionPerformed(ActionEvent e) { try { if(this.CuencaActualRef !=null) { if ((dataBase==null)||(dataBase.isClosed())) { String usr=datosConeccion.getUsr(); String psswd=datosConeccion.getPasswd(); String url=datosConeccion.getUrl(); String drv=datosConeccion.getDriver(); dataBase=new BDObjCuenca(url,drv,usr,psswd); dataBase.open();

FRMSimular dlg=new FRMSimular(this,dataBase); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation();

303

Código Fuente

}

void mnuNodo_actionPerformed(ActionEvent e)

dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack() ; dlg.show() ; } else {JOptionPane.showMessageDialog(this,"La cuenca está cerrada, ábrala nuevamente");

} catch (Exception err) { JOptionPane.showMessageDialog(this,err.getMessage()); err.printStackTrace(System.err) ; } } /********************************************************** * */

{ JOptionPane.showMessageDialog(this,"Por Implementar... "); } void jMenuItem6_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... "); } void mnuTr_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... "); } void mnuEm_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... "); } void mnuHI_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... "); } void mnRN_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... "); } void mnuCAP_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... ");

304

Código Fuente } void mnuCanal_actionPerformed(ActionEvent e) { this.insert=true; this.tipoInsert=INSERT_CANAL; this.setEnabledMenu(false); } void mnuCentHidro_actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(this,"Por Implementar... "); } void mnuEmbBajos_actionPerformed(ActionEvent e) { try { frmResultConsulta frm=new frmResultConsulta(); frm.sqlQuery1.setUrl(this.dataBase.getUrl()); frm.sqlQuery1.setDriver(this.dataBase.getDriver()); frm.sqlQuery1.setUsr(this.dataBase.getUsr()); frm.sqlQuery1.setPasswd(this.dataBase.getPasswd()); frm.setTituloInforme("Embalses Bajo volumenes mínimos"); frm.sqlQuery1.setQuery( "Select "+ "emb.codigo\"CODIGO\""+ " from tbl_emb emb"+ " Where emb.myNodo.myCuenca.codigo=\'" + this.getCuencaRef().getValue().getCodigo()+ "\'"+ "and "+ " ( emb.curva_Alerta.getCaudal(1)>emb.caudales.getCaudal(1)"+ " Or emb.curva_Alerta.getCaudal(2)>emb.caudales.getCaudal(2)"+ " Or emb.curva_Alerta.getCaudal(3)>emb.caudales.getCaudal(3)"+ " Or emb.curva_Alerta.getCaudal(4)>emb.caudales.getCaudal(4)"+ " Or emb.curva_Alerta.getCaudal(5)>emb.caudales.getCaudal(5)"+ " Or emb.curva_Alerta.getCaudal(6)>emb.caudales.getCaudal(6)"+ " ) " ); frm.pack(); frm.setLocation((int)(this.getLocation().getX()- 20),(int)(this.getLocation().getY()-10)); frm.show(); } catch (Exception ex) { JOptionPane.showMessageDialog(this,"error en FrmSimular: "+ ex.getMessage()) ; } } void mnuEnGen_actionPerformed(ActionEvent e) { try

305

Código Fuente { frmResultConsulta frm=new frmResultConsulta(); frm.sqlQuery1.setUrl(this.dataBase.getUrl()); frm.sqlQuery1.setDriver(this.dataBase.getDriver()); frm.sqlQuery1.setUsr(this.dataBase.getUsr()); frm.sqlQuery1.setPasswd(this.dataBase.getPasswd()); frm.setTituloInforme("Energia Generada en KW mes"); frm.sqlQuery1.setQuery( "Select "+ "n.apex.ch.codigo\"CODIGO\","+ "n.apex.ch.nombre\"NOMBRE\","+ " to_char(n.apex.ch.KW(1), \'999,999,999.99\') " + "\"OCT\","+ " to_char(n.apex.ch.KW(2), \'999,999,999.99\') " + "\"NOV\","+ " to_char(n.apex.ch.KW(3), \'999,999,999.99\') " + "\"DIC\","+ " to_char(n.apex.ch.KW(4), \'999,999,999.99\') " + "\"ENE\","+ " to_char(n.apex.ch.KW(5), \'999,999,999.99\') " + "\"FEB\","+ " to_char(n.apex.ch.KW(6), \'999,999,999.99\') " + "\"MAR\""+ " from tbl_flujo n"+ " Where n.apex.tipo=3 and "+ " ( n.nodo_ini.myCuenca.codigo=\'" + this.getCuencaRef().getValue().getCodigo() + "\'" + " Or n.nodo_fin.myCuenca.codigo=\'" + this.getCuencaRef().getValue().getCodigo() + "\'" + " ) " ); frm.pack(); frm.setLocation((int)(this.getLocation().getX()- 20),(int)(this.getLocation().getY()-10)); frm.show(); } catch (Exception ex) { JOptionPane.showMessageDialog(this,"error en FrmSimular: "+

ex.getMessage()) ; } } void jMenuItem2_actionPerformed(ActionEvent e) { String usr=datosConeccion.getUsr(); String passwd=datosConeccion.getPasswd(); String url=datosConeccion.getUrl(); String driver=datosConeccion.getDriver(); FrmConsultor dlg = new FrmConsultor(this,usr,passwd,url,driver); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x,

(frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack() ; dlg.show(); }

306

Código Fuente public void setCuencaRef(CuencaOraRef cr) { try { jlMensaje.setText("Obteniendo Figuras..."); CuencaActualRef=cr; lienzo.clearFiguras(); Vector figuras=dataBase.getAllFigRef(cr.getValue()); jlMensaje.setText("Cargando Figuras..."); lienzo.setVectorFiguras(figuras); jlMensaje.setText(" ") ; this.setTitle("Cuenca Actual :

"+this.CuencaActualRef.getValue().getCodigo()+"-"+ this.CuencaActualRef.getValue().getNombre()); this.setEnabledMenu(true); } catch (Exception err) { JOptionPane.showMessageDialog(this,"En setCuencaRef()

:"+err.getMessage()); err.printStackTrace(System.err) ; } } public CuencaOraRef getCuencaRef() { return CuencaActualRef; } void btAbrir_actionPerformed(ActionEvent e) { abrirCuenca(); } void this_mouseMoved(MouseEvent e) { jlPunto.setText("(" + e.getX() + "," + e.getY() +")") ; } void FigurasSP_mouseMoved(MouseEvent e) { jlPunto.setText("(" + e.getX() + "," + e.getY() +")") ; } void lienzo_mouseMoved(MouseEvent e) { jlPunto.setText("(" + e.getX() + "," + e.getY() +")") ; } /********************************************************************** * */ void menuNuevoRio_actionPerformed(ActionEvent e) {

307

Código Fuente try { if ((dataBase==null)||(dataBase.isClosed())) { String usr=datosConeccion.getUsr(); String psswd=datosConeccion.getPasswd(); String url=datosConeccion.getUrl(); String drv=datosConeccion.getDriver(); dataBase=new BDObjCuenca(url,drv,usr,psswd); dataBase.open() ; } FrmRio dlg=new FrmRio(this.dataBase,null); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x,

(frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack(); dlg.show(); } catch (Exception ex) { JOptionPane.showMessageDialog(this, "Error al conectar a la base

de datos "+ex.getMessage()) ; } } /*********************************************************************** * */ void menuModificarRio_actionPerformed(ActionEvent e) { try { if ((dataBase==null)||(dataBase.isClosed())) { String usr=datosConeccion.getUsr(); String psswd=datosConeccion.getPasswd(); String url=datosConeccion.getUrl(); String drv=datosConeccion.getDriver(); dataBase=new BDObjCuenca(url,drv,usr,psswd); dataBase.open() ; } FrmModificarRio dlg=new FrmModificarRio(this,dataBase); Dimension dlgSize = dlg.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); dlg.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x,

(frmSize.height - dlgSize.height) / 2 + loc.y); dlg.pack(); dlg.show(); } catch (Exception ex) {

308

Código Fuente

JOptionPane.showMessageDialog(this, "Error al conectar a la base de datos : "+ex.getMessage()) ;

} } /** * Crea un canal con valores por defectos */ private FlujoOra crearCanal(Graficable noIni,Graficable noFin) { try { FlujoOra flujo=new

FlujoOra(this.dataBase.getConnection()); flujo.setNodoIni((NodoOraRef)noIni); flujo.setNodoFin((NodoOraRef)noFin); flujo.setTipo(new java.math.BigDecimal(3)); //actualizadondo el atributo graf GrafCuencaOra gc=new

GrafCuencaOra(dataBase.getConnection()); GrafFlujoOra gf=new

GrafFlujoOra(dataBase.getConnection()); gf.setEstilo(new java.math.BigDecimal(2)); //este punto se ingresa para que el arreglos

//de puntos no sea null //pero el valor sera corregido mas adelante. this.puntos=new ArrPuntosOra(new PuntoOra[1]); PuntoOra p = new

PuntoOra(dataBase.getConnection()); p.setX(new java.math.BigDecimal(0)); p.setY(new java.math.BigDecimal(0)); this.puntos.setElement(p,0); gf.setPl(this.puntos); gc.setColorlinea("negro") ; gc.setTipo(new java.math.BigDecimal(1)); gc.setGfl(gf); flujo.setGraf(gc); //actualizando el tipo apex AporExtracOra apex=new

AporExtracOra(this.dataBase.getConnection()); apex.setTipo(new java.math.BigDecimal(1)); CanalOra ca=new

CanalOra(dataBase.getConnection()); ca.setA(new java.math.BigDecimal(0)); ca.setB(new java.math.BigDecimal(0)); ca.setC(new java.math.BigDecimal(0)); ca.setCodigo("CA nuevo"); ca.setNombre("Canal en proceso de ingreso"); ca.setCapConducion(new

java.math.BigDecimal(0)); ca.setEficiencia(new java.math.BigDecimal(0)); ArrCaudalesOra arrCaudales=new

ArrCaudalesOra(dataBase.getConnection()); ArrayCaudalOra arr=new ArrayCaudalOra(new

309

Código Fuente

java.math.BigDecimal[6]); arr.setElement(new java.math.BigDecimal(0),0); arr.setElement(new java.math.BigDecimal(0),1); arr.setElement(new java.math.BigDecimal(0),2); arr.setElement(new java.math.BigDecimal(0),3); arr.setElement(new java.math.BigDecimal(0),4); arr.setElement(new java.math.BigDecimal(0),5); arrCaudales.setCaudal(arr); ca.setCaudales(arrCaudales) ; apex.setCa(ca); flujo.setApex(apex); return flujo; } catch (Exception ex) { JOptionPane.showMessageDialog(null,"eror al crear canal por

defecto : "+ex); } return null; } //******************************************************************** // void lienzo_mouseClicked(MouseEvent e) { try { boolean esNodo=false; if (this.insert) { if (this.tipoInsert==this.INSERT_CANAL) { Graficable f=lienzo.buscarFigura(e.getX(),e.getY()) ; try {esNodo=(f.getClass().getName()=="objcuenca.GuiNodo");} catch (Exception ex) {esNodo=false;} //si es el primer punto, debe ser un nodo. if(this.countClick ==0) { if(esNodo) { FlujoOra flujo=this.crearCanal(f,f);

this.figInsert=(Graficable)dataBase.insertar(flujo); this.countClick++; } else { JOptionPane.showMessageDialog(this,"El Primer

punto del canal debe ser del nodo inicial"); } } else

310

Código Fuente { GuiFlujo flref=(GuiFlujo)this.figInsert; FlujoOra flujo=flref.getValue(); if(esNodo) { if(this.countClick > 2) { //actualizo el nodo final //this.jlMensaje.setText("Nodo Final marcado"); flujo.setNodoFin((NodoOraRef)f); this.countClick=0; this.insert=false; this.tipoInsert=0; flref.setValue(flujo); flref.loadFigura(); this.figInsert=(Graficable)flref; this.figInsert.dlgAtributos(); this.setEnabledMenu(true); this.jlMensaje.setText(" "); } else { JOptionPane.showMessageDialog(this,"Minimo se

necesitan dos puntos(sin contar nodo inicial y final)");

} } else { GrafCuencaOra gc=flujo.getGraf();; GrafFlujoOra gf=flujo.getGraf().getGfl();; PuntoOra p = new PuntoOra(dataBase.getConnection()); int x=(e.getX()*100)/lienzo.getZoom(); int y=(e.getY()*100)/lienzo.getZoom(); p.setX(new java.math.BigDecimal(x)); p.setY(new java.math.BigDecimal(y)); //extiendo el arreglo, asignandole uno nuevo. PuntoOra[] arrPuntos=new PuntoOra[countClick];

// traslado los valores originales para // que no se pierdan

for(int i=0;i<countClick-1;i++) { arrPuntos[i]=this.puntos.getElement(i); } arrPuntos[countClick-1]=p; this.puntos.setArray(arrPuntos); gf.setPl(this.puntos); gc.setGfl(gf); flujo.setGraf(gc); countClick++; flref.setValue(flujo); flref.loadFigura(); this.figInsert=(Graficable)flref;

311

Código Fuente

}

void this_windowOpened(WindowEvent e)

if(countClick==3){this.lienzo.addFigura(figInsert);} if(countClick>2) {

this.figInsert.dibujar(new Dibujante(lienzo.getGraphics(),lienzo.getZoom()));

} } } } } else { lienzo.Click(e); } } catch (Exception ex) { JOptionPane.showMessageDialog(this,"Error al insertar el

canal:"+ex); ex.printStackTrace(System.err);

}

{ //llamar al dialogo de conección, try { datosConeccion=new FrmConexion(this,dataBase); Dimension dlgSize = datosConeccion.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); datosConeccion.setLocation((frmSize.width - dlgSize.width) / 2 + loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); datosConeccion.enbableBtSalir(false); datosConeccion.pack() ; datosConeccion.show(); } finally { datosConeccion.enbableBtSalir(true); } } /******************************************************/ }

312

Código Fuente

package cuencamaule;

{

frameSize.width = screenSize.width;

frame.setVisible(true);

UIManager.setLookAndFeel(

C.4.2.20 Clase: MainGui

import javax.swing.UIManager; import java.awt.*; public class MainGui { boolean packFrame = false; /**Construct the application*/ public MainGui()

Frame1 frame = new Frame1(); // Validate frames that have preset sizes // Pack frames that have useful preferred size info, e.g. from their // layout if (packFrame) { frame.pack(); } else { frame.validate(); } //Center the window Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize(); Dimension frameSize = frame.getSize(); if (frameSize.height > screenSize.height) { frameSize.height = screenSize.height; } if (frameSize.width > screenSize.width) {

} frame.setLocation((screenSize.width - frameSize.width) / 2,

(screenSize.height - frameSize.height) / 2);

} /**Main method*/ public static void main(String[] args) { try {

UIManager.getSystemLookAndFeelClassName()); } catch(Exception e) { e.printStackTrace(); } new MainGui(); } }

313

Código Fuente

{

cnt++;

(inicio.y==0 && fin.y<0))

C.4.3 Paquete Figuras C.4.3.1 Clase: Cuadrilatero package figuras;

import java.awt.*; import javax.swing.*; import javax.swing.border.*; public class Cuadrilatero extends FigGeo { private Punto a,b,c,d; //----------------------------------------------- public Cuadrilatero(Punto A,Punto B,Punto C,Punto D) { super();a=A;b=B; c=C; d=D;} //--------------------------------------------------------- //Redefiniendo los métodos de FigGeo public void dibujar(Graphics g) { int x[]={a.x,b.x,c.x,d.x}; int y[]={a.y,b.y,c.y,d.y}; g.drawPolygon(x,y,4); } //-------------------------------------------------------------- public boolean pertenece(Punto p) { Punto inicio,fin,direccion; int coorx,cnt=0,np=4; Punto q[]={a,b,c,d}; for(int i=0;i<np;i++)

inicio=p.restar(q[i%np]); fin=p.restar(q[(i+1)%np]); if((inicio.y * fin.y) <=0) { if((inicio.y!=0) || (fin.y!=0)) { direccion = inicio.restar(fin); coorx = (inicio.x * direccion.y - inicio.y * direccion.x); if(direccion.y<0) coorx*=-1; if(coorx==0) {cnt =1; break;} if(coorx > 0) {

if((inicio.y < 0 && fin.y==0)||

cnt --; } }

314

Código Fuente

} } return ((cnt %2)!=0); }//fin función //------------------------------------------------------------- public void dlgAtributos() { JOptionPane.showMessageDialog(null,"soy un cuadrilatero"); } //------------------------------------------------------------- public void setZoom(int z) { //modificando los atributos a,b,c,d int actual=getZoom(); a.x=(a.x * z)/actual; a.y=(a.y * z)/actual; b.x=(b.x * z)/actual; b.y=(b.y * z)/actual;

c.x=(c.x * z)/actual; c.y=(c.y * z)/actual;

public int yMayor()

d.x=(d.x * z)/actual; d.y=(d.y * z)/actual;

super.setZoom(z); } //---------------------------------------------------------- //coordenada x mas lejana al origen public int xMayor() { int mayor=a.x>b.x?a.x:b.x; mayor=mayor>c.x?mayor:c.x; mayor=mayor>d.x?mayor:d.x; return mayor; } //-------------------------------------------------------------- //coordenada y mas lejana al origen

{ int mayor=a.y>b.y?a.y:b.y; mayor=mayor>c.y?mayor:c.y; mayor=mayor>d.y?mayor:d.y; return mayor; } //------------------------------------------------------- public String toString() { return "{"+a+b+c+d+"}"; } }

315

Código Fuente

import javax.swing.JOptionPane;

import java.awt.Color;

public class Dibujante

{

C.4.3.2 Clase: Dibujante package figuras; import java.awt.Font; import java.awt.FontMetrics; import java.awt.Graphics; import objcuenca.*; import java.sql.SQLException;

import java.math.*;

{ private Graphics g; private int zoom=100; private Color colorLinea=Color.black; public Dibujante(Graphics g,int zoom) { this.g=g; this.zoom=zoom; } public void setColorLinea(Color c)

this.colorLinea=c; } /** * Dibuja una polilinea a partir de una PolilineaOra */ public void drawPolilinea(PolilineaOra p) { try { g.setColor(colorLinea); int nPuntos=p.getNpuntos().intValue() ; int xCor[]=new int[nPuntos]; int yCor[]=new int[nPuntos]; for(int i=0;i<nPuntos;i++) { xCor[i]=p.getLospuntos().getElement(i).getX().intValue(); yCor[i]=p.getLospuntos().getElement(i).getY().intValue(); } g.drawPolyline(xCor,yCor,nPuntos); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } } /** * Dibuja una polilinea a partir de un ArrPuntosOra */

316

Código Fuente

{ angulo=270;}

* Dibuja una polilinea doble

public void drawPolilineaDoble(PolilineaOra p)

try

public void drawPolilinea(ArrPuntosOra p) { try { g.setColor(colorLinea); int nPuntos=p.length(); int xCor[]=new int[nPuntos]; int yCor[]=new int[nPuntos]; for(int i=0;i<nPuntos;i++) { xCor[i]=p.getElement(i).getX().intValue(); yCor[i]=p.getElement(i).getY().intValue(); } g.drawPolyline(xCor,yCor,nPuntos); int H=xCor[nPuntos-1]; int K=yCor[nPuntos-1]; int X=xCor[nPuntos-2]; int Y=yCor[nPuntos-2]; //el radio es 10 cuando el zoom es 100, por regla de tres simple //r=10*zoom/100 al simplificar queda r=zoom/10; int R=this.zoom/10; int anch=40; double angulo; if((X-H)==0)

else { angulo = Math.toDegrees(Math.atan2((Y-K),(X-H)));} if ((angulo==0)&&(X<H)){angulo=180;} //ancho de la flecha en grados. // los grados en fillArc se incrementan en sentido contrario que en // el plano cartesiano, por esa razón ajusto el ángulo // inicial con 360-angulo this.g.fillArc(H-R,K-R,R*2,R*2,(int)(360-angulo-(anch/2)),anch); } catch (Exception err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } }

/*************************************************************

*/

{

{ drawPolilineaDoble(p.getLospuntos() ); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage());

317

Código Fuente

// los grados en fillArc se incrementan en sentido contrario

err.printStackTrace(System.err) ; } } /************************************************************* * Dibuja una polilinea doble a partir de un ArrPuntosOra */ public void drawPolilineaDoble(ArrPuntosOra p) { try { g.setColor(colorLinea); int nPuntos=p.length(); int xCor[]=new int[nPuntos]; int yCor[]=new int[nPuntos]; for(int i=0;i<nPuntos;i++) { xCor[i]=p.getElement(i).getX().intValue(); yCor[i]=p.getElement(i).getY().intValue(); } g.drawPolyline(xCor,yCor,nPuntos); int H=xCor[nPuntos-1]; int K=yCor[nPuntos-1]; int X=xCor[nPuntos-2]; int Y=yCor[nPuntos-2]; //el radio es 10 cuando el zoom es 100, por regla de tres simple //r=10*zoom/100 al simplificar queda r=zoom/10; int R=this.zoom/10; int anch=40; double angulo; if((X-H)==0) { angulo=270;} else { angulo = Math.toDegrees(Math.atan2((Y-K),(X-H)));} if ((angulo==0)&&(X<H)){angulo=180;}

// que en el plano cartesiano, por esa razón ajusto el ángulo // inicial con 360-angulo

this.g.fillArc(H-R,K-R,R*2,R*2,(int)(360-angulo-(anch/2)),anch); //El radio de la circunferencia rellena del inicio es de 3 al 100% R=(3*zoom)/100; this.g.fillArc(xCor[0]-R,yCor[0]-R,R*2,R*2,0,360); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } } /** * Dibuja una polilinea Gruesa

318

Código Fuente

}

*/ public void drawPolilineaGruesa(PolilineaOra p) { try { this.drawPolilinea(p.getLospuntos()); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ;

} /** * Dibuja una polilinea Gruesa a partir de un ArrPuntosOra */ public void drawPolilineaGruesa(ArrPuntosOra p) { this.drawPolilinea(p) ; } public void drawCuadrado(CuadradoOra cuad) { try { g.setColor(colorLinea); PuntoOra a=cuad.getA() ; PuntoOra b=cuad.getB() ; PuntoOra c=cuad.getC() ; PuntoOra d=cuad.getD() ; int nPuntos=4; int xCor[]={a.getX().intValue() ,b.getX().intValue(), d.getX().intValue(), c.getX().intValue()}; int yCor[]={a.getY().intValue() ,b.getY().intValue(), d.getY().intValue(), c.getY().intValue()}; g.drawPolygon(xCor,yCor,nPuntos); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } } public void drawTriangulo(TrianguloOra t) { try { g.setColor(colorLinea); PuntoOra a=t.getA() ; PuntoOra b=t.getB() ; PuntoOra c=t.getC() ; int nPuntos=3; int xCor[]={a.getX().intValue(),b.getX().intValue(), c.getX().intValue()};

319

Código Fuente int yCor[]={a.getY().intValue(),b.getY().intValue(),

catch (SQLException err)

{

PuntoOra cent = e.getCentro() ;

int ancho = e.getAncho().intValue();

int esqIzY = cent.getY().intValue()- (alto/2);


}

public void drawString(String s,int x,int y,int tam)

g.drawString(s,x,y);

c.getY().intValue()}; g.drawPolygon(xCor,yCor,nPuntos); }

{ JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } } public void drawElipse(ElipseOra e)

try { g.setColor(colorLinea);

int alto = e.getAlto().intValue();

int esqIzX = cent.getX().intValue()- (ancho/2);

g.drawOval(esqIzX,esqIzY,ancho,alto);

}

{ JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ;

}

{ g.setColor(colorLinea); Font f=new Font("Helvetica",Font.BOLD,tam); g.setFont(f);

}

public void drawCenteredString(String s,int x, int y, int w,int h, int tam)

{ g.setColor(colorLinea); Font f=new Font("Helvetica",Font.BOLD,tam); g.setFont(f); FontMetrics fm = g.getFontMetrics(); int xx = x + (w -fm.stringWidth(s))/2; int yy = y +(fm.getAscent() + (h -(fm.getAscent()+ fm.getDescent()))/2); g.drawString(s,xx,yy); } }

320

Código Fuente

public class Elipse extends FigGeo

public String toString()

return "{"+esqIz+","+ancho+","+alto+"}";

C.4.3.3 Clase: Elipse package figuras; import java.awt.*; import javax.swing.*; import javax.swing.border.*;

{ private Punto esqIz; private int ancho,alto; //---------------------------------------------------- public Elipse(Punto c,int an,int al) { super();esqIz=c; ancho=an; alto = al; } //---------------------------------------------------- //Redefiniendo los métodos de FigGeo public void dibujar(Graphics g) { g.drawOval(esqIz.x,esqIz.y,ancho,alto); } //--------------------------------------------------------- public boolean pertenece(Punto p) { Punto c=new Punto(esqIz.x+ancho/2,esqIz.y+alto/2); int an=ancho/2; int al=alto/2; if ((((Math.pow((p.x-c.x),2))/(Math.pow(an,2)))+ ((Math.pow((p.y-c.y),2))/(Math.pow(al,2))))<=1) {return true;} else {return false;} }//fin función //------------------------------------------------------------ public void dlgAtributos() { JOptionPane.showMessageDialog(null,"soy una Elipse"); }

{

} //------------------------------------------------------------------- //Esta funcion acutaliza las propiedades de la elipse para que

321

Código Fuente //esten acordes al nuevo Zoom aplicando la regla de 3 simple public void setZoom(int z) { //modificando los atributos esqIz,alto,ancho int actual=getZoom(); esqIz.x=(esqIz.x * z)/actual; esqIz.y=(esqIz.y * z)/actual; ancho=(ancho * z)/actual; alto =(alto * z)/actual; super.setZoom(z); } //------------------------------------------------------------- //coordenada x mas lejana al origen public int xMayor() { return esqIz.x+ancho; } //----------------------------------------------------------- //coordenada y mas lejana al origen public int yMayor() { return esqIz.y+alto ; } }

322

Código Fuente

import javax.swing.*;

abstract class FigGeo

}

C.4.3.4 Clase: FigGeo package figuras; import java.awt.*;

import java.awt.Dimension;

{ private int zoom; public FigGeo(){zoom=100;} public abstract void dibujar(Graphics g); public abstract boolean pertenece(Punto p); public abstract void dlgAtributos(); public abstract int xMayor(); public abstract int yMayor(); //------------------------------------------------------------- public void setZoom(int z) { zoom=z; } //------------------------------------------------------------- public int getZoom() { return zoom;

//-------------------------------------------------------------

C.4.3.5 Interfaz: Graficable

public boolean esContenidoEn(Dimension d,Dimension nueva) { int xM=xMayor()+12;//12 pixeles de margen derecho int yM=yMayor()+12;//12 pixeles de margen inferir nueva.width=d.width>xM?d.width:xM; nueva.height=d.height>yM?d.height:yM; return ((d.width>xM)&(d.height>yM)); } }

package figuras; import java.awt.Dimension; public interface Graficable { public void setZoom(int zoom); public int getZoom(); public void dibujar(Dibujante d); public void dlgAtributos(); public Dimension dimensionMinima(); public boolean pertenece(Punto p); public void loadFigura(); }

323

Código Fuente

private Vector lasFiguras;

setBackground(new Color(255,231,184));

finally

this.repaint();

C.4.3.6 Clase: LienzoCuenca package figuras; import javax.swing.JPanel; import java.awt.*; import javax.swing.*; import javax.swing.event.*; import javax.swing.border.*; import java.awt.event.MouseEvent; import java.util.*; public class LienzoCuenca extends JPanel { //----------------------------------------------------------------- // Variables de Instancia

private int zoom=100; public LienzoCuenca() { lasFiguras= new Vector();

this.setOpaque(false); //this.addMouseListener( new MouseInputAdapter(){ // public void mouseClicked(MouseEvent e){ Click(e);}}); } //--------------------------------------------------------------- public void paint(Graphics g) { // g.setColor(new Color(15,23,100)); dibujarFiguras(g); }

//---------------------------------------------------------------- public void Click(MouseEvent e) { try { if ((e.getClickCount() == 1)&&(!e.isConsumed())) { int x = e.getX(); int y = e.getY(); Graficable f = buscarFigura(x,y); if (f!=null) { f.dlgAtributos(); } e.consume(); } }

{

324

Código Fuente

}

Enumeration FigIter=lasFiguras.elements();

}

{return null;}

//--------------------------------------------------------------------

* Dibuja las figuras contenidas en el vector lasFiguras

}

public void setVectorFiguras(Vector f) { lasFiguras=f; setZoom(100); } //--------------------------------------------------------------------- public void clearFiguras() { lasFiguras.clear() ; } //-------------------------------------------------------------------- public void addFigura(Graficable f) { lasFiguras.addElement(f); } //-------------------------------------------------------------------- /** * debuelve la referencia de la figura a la cual le pertenece el punto * dado por las coordenadas x,y. * en caso de existir ninguna, debuelve null. */ public Graficable buscarFigura(int x,int y) { Graficable f=null;boolean ok=false;

while((FigIter.hasMoreElements())&&(!ok)) { f=(Graficable)FigIter.nextElement(); if (f.pertenece(new Punto(x,y))){ok=true;}

if ( ok ) {return f;} else

}

/**

* * */ public void dibujarFiguras(Graphics g) { Dibujante pincel=new Dibujante(g,this.zoom); Graficable f; Enumeration FigIter=lasFiguras.elements(); while (FigIter.hasMoreElements()) { f=(Graficable)FigIter.nextElement(); //Redimiensiono el lienzo si la figura no es contenida

325

Código Fuente Dimension df=f.dimensionMinima() ; Dimension dAct=this.getSize() ; int x=df.width>dAct.width ? df.width : dAct.width ; int y=df.height > dAct.height ? df.height : dAct.height; Dimension nueva=new Dimension(x,y); if ((df.width>dAct.width)||(df.height > dAct.height)) {this.setSize(nueva);} f.dibujar(pincel) ; } } //--------------------------------------------------------------------- public void reloadFiguras() { Enumeration figIter=lasFiguras.elements(); Graficable f; while(figIter.hasMoreElements()) { f=(Graficable)figIter.nextElement(); f.loadFigura(); } this.repaint(); } //-------------------------------------------------------------------- public void setZoom(int z) { zoom=z; Graficable f; Enumeration FigIter=lasFiguras.elements(); while (FigIter.hasMoreElements()) { f=(Graficable)FigIter.nextElement(); f.setZoom(zoom); } this.setSize(1024,768); repaint(new Rectangle(getSize())); } //------------------------------------------------------------------ public int getZoom() { return zoom; } }

326

Código Fuente

{ super();

Punto arr[]=new Punto[nPuntos];

{

{

C.4.3.7 Clase: Poligono package figuras; import java.awt.*; import javax.swing.*; import javax.swing.border.*; public class Poligono extends FigGeo { private int x[]; private int y[]; private int nPuntos=0; //----------------------------------------------- public Poligono(int xP[],int yP[],int n)

x=(int[])xP.clone(); y=(int[])yP.clone(); nPuntos=n; } //--------------------------------------------------------- //Redefiniendo los métodos de FigGeo public void dibujar(Graphics g) { g.drawPolygon(x,y,nPuntos); } //------------------------------------------------------------------- private Punto[] arrPuntos() {

for (int i=0;i<nPuntos;i++)

arr[i]=new Punto(x[i],y[i]); } return arr; } public boolean pertenece(Punto p)

Punto inicio,fin,direccion; int coorx,cnt=0,np=nPuntos; Punto q[]=arrPuntos(); for(int i=0;i<np;i++) { inicio=p.restar(q[i%np]); fin=p.restar(q[(i+1)%np]); if((inicio.y * fin.y) <=0) { if((inicio.y!=0) || (fin.y!=0)) { direccion = inicio.restar(fin); coorx = (inicio.x * direccion.y -

327

Código Fuente

if(direccion.y<0) coorx*=-1;

return ((cnt %2)!=0);

inicio.y * direccion.x);

if(coorx==0) {cnt =1; break;} if(coorx > 0) { cnt++; if((inicio.y < 0 && fin.y==0)|| (inicio.y==0 && fin.y<0)) cnt --; } } } }

}//fin función

//--------------------------------------------------------------- public void dlgAtributos() { JOptionPane.showMessageDialog(null,"soy un Poligono"); } //---------------------------------------------------------------

//---------------------------------------------------------------

public void setZoom(int z) { //modificando los atributos a,b,c,d int actual=getZoom(); for(int i=0;i<nPuntos;i++) { x[i]=(x[i] * z)/actual; y[i]=(y[i] * z)/actual; } super.setZoom(z); }

//coordenada x mas lejana al origen public int xMayor() { int mayor=x[0]; for(int i=0;i<nPuntos;i++) { mayor=x[i]>mayor?x[i]:mayor; } return mayor; }

//--------------------------------------------------------------- //coordenada y mas lejana al origen public int yMayor() { int mayor=y[0]; for(int i=0;i<nPuntos;i++) { mayor=y[i]>mayor?y[i]:mayor;

328

Código Fuente

}

import java.awt.*;

private int nPuntos;

} return mayor; } //------------------------------------------------------------- public String toString() { String s="{"; for(int i=0;i<nPuntos;i++) { s+=new Punto(x[i],y[i])+","; } s=s.substring(0,s.length()-1)+"}"; return s;

}

C.4.3.8 Clase: PoliLinea package figuras;

import javax.swing.*; import javax.swing.border.*; public class PoliLinea extends FigGeo {

private int[] xCor; private int[] yCor; private int estilo; public static final int SIMPLE=1; public static final int DOBLE =2; public static final int GRUESA=0; private int error=250; //Constructores //--------------------------------------------------------- public PoliLinea(PoliLinea p,int e) { super(); estilo=e; this.nPuntos=p.nPuntos; xCor=new int[nPuntos]; yCor=new int[nPuntos]; for(int i=0;i<nPuntos;i++) { xCor[i]=p.xCor[i]; yCor[i]=p.yCor[i];

329

Código Fuente

}

{

for(int i=0;i<nPuntos;i++)

xCor[i]=x[i];

}

}

//cordenadas correspondientes

switch(estilo)

case DOBLE:

n2.moverEn(-2,0);

}

public PoliLinea(int[] x,int[] y,int nPuntos,int e)

super(); estilo=e; this.nPuntos=nPuntos; xCor=new int[nPuntos]; yCor=new int[nPuntos];

{

yCor[i]=y[i];

//--------------------------------------------------------- //mueve la polilínea sumando o restando x e y a las

public void moverEn(int x,int y) { for(int i=0;i<nPuntos;i++) { xCor[i]+=x; yCor[i]+=y; } } //--------------------------------------------------------- //Redefiniendo los métodos de FigGeo public void dibujar(Graphics g) { PoliLinea n1=new PoliLinea(this,SIMPLE); PoliLinea n2=new PoliLinea(this,SIMPLE);

{ case SIMPLE: g.drawPolyline(xCor,yCor,nPuntos); error=250; break;

n1.moverEn(2,0);

g.drawPolyline(n1.xCor,n1.yCor,nPuntos); g.drawPolyline(n2.xCor,n2.yCor,nPuntos); error=500; break; case GRUESA: n1.moverEn(1,0); g.drawPolyline(n1.xCor,n1.yCor,nPuntos);

330

Código Fuente

g.drawPolyline(xCor,yCor,nPuntos); error=300; break; }

/**------------------------------------------------------------------

*/

{

g.drawPolyline(n1.xCor,n1.yCor,nPuntos); g.drawPolyline(n2.xCor,n2.yCor,nPuntos); }

* p1,p2 linea de p1 a p2 * p3 el punto a consultar. * el mouse no es tan presiso, por eso la comparación * no es == a "0"(exacto)

private boolean colineales(Punto a,Punto b,Punto c) { return (Math.abs((a.x * b.y) - (a.y * b.x) + (a.y * c.x) - (a.x * c.y) + (b.x * c.y) - (b.y*c.x))<error); } //------------------------------------------------------------------- public boolean pertenece(Punto p) { boolean resultado=false; for (int i=0;i<(nPuntos-1);i++) { if(colineales(vertice(i),vertice(i+1),p)) { resultado=true; break; } } return resultado; }//fin función //---------------------------------------------------------------- public void dlgAtributos() { JOptionPane.showMessageDialog(null,"soy una polilinea"); } //------------------------------------------------------------------- public int[] getXCor()

return this.xCor; } //--------------------------------------------------------------------- public void setXCor(int[] xCor) {

331

Código Fuente

//-------------------------------------------------------------------

//-------------------------------------------------------------------

//esten acordes al nuevo Zoom

public void setZoom(int z)

this.xCor = xCor; }

public int[] getYCor() { return this.yCor; } //-------------------------------------------------------------------- public void setYCor(int[] yCor) { this.yCor = yCor; } //-------------------------------------------------------------------- public int getNPuntos() { return this.nPuntos; } //-------------------------------------------------------------------- public void setNPuntos(int nPuntos) { this.nPuntos = nPuntos; }

public Punto vertice(int i) { if ((i>=0) && (i<nPuntos)) {return (new Punto(xCor[i],yCor[i]));} else { return null;} } //------------------------------------------------------------------- public String toString() { String s="{"; for(int i=0;i<nPuntos;i++) s+="("+xCor[i]+","+yCor[i]+")"; s+="}"; return s; } //------------------------------------------------------------------- //Esta funcion acutaliza las propiedades de la polilinea para que

{ //modificando los atributos xCor, yCor int actual=getZoom();

332

Código Fuente

//-------------------------------------------------------------------

public int xMayor()

}

{

for(int i=0;i<nPuntos;i++) { xCor[i]=(xCor[i] * z)/actual; yCor[i]=(yCor[i] * z)/actual;; } super.setZoom(z); }

//coordenada x mas lejana al origen

{ int mayor=xCor[0]; for(int i=0;i<nPuntos;i++) { mayor=mayor>xCor[i]?mayor:xCor[i];

return mayor; } //-------------------------------------------------------------- //coordenada y mas lejana al origen public int yMayor() { int mayor=yCor[0]; for(int i=0;i<nPuntos;i++)

mayor=mayor>yCor[i]?mayor:yCor[i]; } return mayor; } }

C.4.3.9 Clase: Punto package figuras; public class Punto { public int x, y; //construye el punto (0,0) public Punto() { x=0;y=0; } //construye el punto a partir de las cordenadas x e y public Punto(int x, int y) { this.x=x;this.y=y; } //Construye el punto a partir de otro public Punto(Punto P) { x=P.x;y=P.y;

333

Código Fuente

//como argumento

} //Calcula la distancia entre el punto y otro pasado

public double distanciaA(Punto p) { int dx=p.x - this.x; int dy=p.y - this.y; return Math.sqrt(dx*dx+dy*dy); } public void asignar(Punto p) { x=p.x;y=p.y; } public void asignar(int x, int y) { this.x=x;this.y=y; } {

public Punto restar(Punto p)

return (new Punto(x-p.x,y-p.y)); } public Punto sumar(Punto p) { return (new Punto(x+p.x,y+p.y)); }

//---------------------------------------------------------

public String toString() { return ("("+x+","+y+")"); } }

C.4.3.10 Clase: Triangulo package figuras; import java.awt.*; import javax.swing.*; import javax.swing.border.*; public class Triangulo extends FigGeo { private Punto a; private Punto b; private Punto c; //Constructores

Triangulo() { super(); a=new Punto(15,20); b=new Punto(15,100);

334

Código Fuente

//-----------------------------------------------------------

{

int coorx,cnt=0,np=3;

{

cnt++;

(inicio.y==0 && fin.y<0)) cnt --;

}

c=new Punto(50,60); } //--------------------------------------------------------- Triangulo(Punto d,Punto e,Punto f) { super();a=d;b=e;c=f; } //--------------------------------------------------------- //Redefiniendo los métodos de FigGeo public void dibujar(Graphics g) { int x[]={a.x,b.x,c.x}; int y[]={a.y,b.y,c.y}; g.drawPolygon(x,y,3); }

public boolean pertenece(Punto p)

Punto inicio,fin,direccion;

Punto q[]={a,b,c}; for(int i=0;i<np;i++) { inicio=p.restar(q[i%np]); fin=p.restar(q[(i+1)%np]); if((inicio.y * fin.y) <=0)

if((inicio.y!=0) || (fin.y!=0)) { direccion = inicio.restar(fin); coorx = (inicio.x * direccion.y - inicio.y * direccion.x); if(direccion.y<0) coorx*=-1; if(coorx==0) {cnt =1; break;} if(coorx > 0) {

if((inicio.y < 0 && fin.y==0)||

}

} } return ((cnt %2)!=0); }//fin función //----------------------------------------------------------- public void dlgAtributos() { JOptionPane.showMessageDialog(null,"soy un Triangulo");

335

Código Fuente } //-------------------------------------------------------------- //Esta funcion acutaliza las propiedades del triangulo para //que esten acordes al nuevo Zoom aplicando la regla de 3 simple // por ejemplo: // valor actual -----> valor Actual del Zoom // nuevo valor -----> nuevo zoom // nuevo valor = (valor actual * nuevo zoom)/valor actual zoom

int actual=getZoom();

b.y=(b.y * z)/actual;

c.x=(c.x * z)/actual;

public void setZoom(int z) { //modificando los atributos a,b,c

a.x=(a.x * z)/actual; a.y=(a.y * z)/actual; b.x=(b.x * z)/actual;

c.y=(c.y * z)/actual; super.setZoom(z); } //----------------------------------------------------------- public int xMayor() {return (a.x>b.x?a.x:b.x)>c.x?(a.x>b.x?a.x:b.x):c.x;} //------------------------------------------------------------------ public int yMayor() {return (a.y>b.y?a.y:b.y)>c.y?(a.y>b.y?a.y:b.y):c.y;} //----------------------------------------------------------------- public String toString() { return "{("+a.x+","+a.y+")("+b.x+","+b.y+") ("+c.x+","+c.y+")}"; } }

336

Código Fuente

• GrafFlujoOra.java, GrafFlujoOraRef.java

C.4.4 Paquete objcuenca

Las siguientes clases son generadas por el utilitario JPUP de Oracle a partir de

los tipos creados con CREATE TYPE. Estas clases sierven de interfaz entre

los tipos de Oracle y las clases de java. Para cada tipo Objeto, le

corresponden dos clases java, una para acceder a las instancias del tipo y

otra para acceder a referencias del tipos. Para los tipos creados a partir de

un tipo primitivo, solamente es generada la clase para acceder a instancias:

• AporExtracOra.java , AporExtracOraRef.java

• AportanteOra.java, AportanteOraRef.java

• ArrayCaudalOra.java

• ArrCaudalesOra.java, ArrCaudalesOraRef.java,

• ArrPuntosOra.java

• CanalOra.java, CanalOraRef.java

• CaptAguaPotOra.java, CaptAguaPotOraRef.java

• CentralHidroOra.java, CentralHidroOraRef.java

• CuadradoOra.java, CuadradoOraRef.java

• CuencaOra.java, CuencaOraRef.java

• ElipseOra.java, ElipseOraRef.java

• EmbalseOra.java, EmbalseOraRef.java

• ExtraccionOra.java, ExtraccionOraRef.java

• FlujoOra.java, FlujoOraRef.java

• GrafCentHidroOra.java, GrafCentHidroOraRef.java

• GrafCuencaOra.java, GrafCuencaOraRef.java

• GrafEmbOra.java, GrafEmbOraRef.java

• GrafNodoOra.java, GrafNodoOraRef.java

• HoyaInterOra.java, HoyaInterOraRef.java

• NodoOra.java, NodoOraRef.java

• PolilineaOra.java, PolilineaOraRef.java

• PuntoOra.java, PuntoOraRef.java

• RegimenNaturalOra.java, RegimenNaturalOraRef.java

• RioOra.java, RioOraRef.java

• SalidaEmbOra.java, SalidaEmbOraRef.java

337

Código Fuente

/*@lineinfo:filename=AporExtracOra*/

import Oracle.sql.CustomDatum;

• TramoOra.java, TramoOraRef.java

• TrianguloOra.java, TrianguloOraRef.java

Acada una de estas clases, le agregamos una línea de código para indicar que

pertenecen al paquete objcuenca. Por ser muy extensas y poco claras, sólo

mostraremos dos de estas clases: AporExtracOra.java, AporExtracOraRef.java.

El paquete objcuenca consta de 58 clases, donde 4 de ellas no son generadas

por las utilidades de Oracle. Estas son:

• BDObjCuenca.java

• GuiEmbalse.java

• GuiFlujo.java

• GuiNodo.java

Estas clases si son mostradas.

C.4.4.1 Clase: AporExtracOra package objcuenca;//linea agregada manualmente

/*@lineinfo:user-code*/ /*@lineinfo:1^1*/ import java.sql.SQLException; import Oracle.jdbc.driver.OracleConnection; import Oracle.jdbc.driver.OracleTypes;

import Oracle.sql.CustomDatumFactory; import Oracle.sql.Datum; import Oracle.sql.STRUCT; import Oracle.jpub.runtime.MutableStruct; import sqlj.runtime.ref.DefaultContext; import sqlj.runtime.ConnectionContext; import java.sql.Connection; public class AporExtracOra implements CustomDatum, CustomDatumFactory { public static final String _SQL_NAME = "APOR_EXTRAC"; public static final int _SQL_TYPECODE = OracleTypes.STRUCT; /*@lineinfo:generated-code*//*@lineinfo:18^3*/ // ************************************************************ // SQLJ context declaration: // ************************************************************ static class _Ctx

338

Código Fuente

java.lang.String password, boolean autoCommit)

public _Ctx(java.lang.String url, boolean autoCommit)

{

}

extends sqlj.runtime.ref.ConnectionContextImpl implements sqlj.runtime.ConnectionContext { public _Ctx(java.sql.Connection conn) throws java.sql.SQLException { super(profiles, conn); } public _Ctx(java.lang.String url, java.lang.String user,

throws java.sql.SQLException { super(profiles, url, user, password, autoCommit); } public _Ctx(java.lang.String url, java.util.Properties info, boolean autoCommit) throws java.sql.SQLException { super(profiles, url, info, autoCommit); }

throws java.sql.SQLException { super(profiles, url, autoCommit); } public _Ctx(sqlj.runtime.ConnectionContext other) throws java.sql.SQLException { super(profiles, other); } public static _Ctx getDefaultContext() { if (defaultContext == null) { java.sql.Connection conn = sqlj.runtime.RuntimeContext.getRuntime().getDefaultConnection(); if (conn != null) { try { defaultContext = new _Ctx(conn); } catch (java.sql.SQLException e)

} } } return defaultContext; } public static void setDefaultContext(_Ctx ctx) { defaultContext = ctx;

private static _Ctx defaultContext = null;

339

Código Fuente

{

static int[] _sqlType =

}

_ctx = new _Ctx(DefaultContext.getDefaultContext());

catch (Exception e)

public static java.lang.Object getProfileKey(sqlj.runtime.profile.Loader loader, java.lang.String profileName) throws java.sql.SQLException { return profiles.getProfileKey(loader, profileName); } private static final sqlj.runtime.ref.ProfileGroup profiles = new sqlj.runtime.ref.ProfileGroup(); public static sqlj.runtime.profile.Profile getProfile(java.lang.Object profileKey)

return profiles.getProfile(profileKey); } } // ************************************************************ /*@lineinfo:user-code*//*@lineinfo:18^26*/ _Ctx _ctx;

{ 2, 2002, 2002, 2002 }; static CustomDatumFactory[] _factory = new CustomDatumFactory[4]; static { _factory[1] = CanalOra.getFactory(); _factory[2] = TramoOra.getFactory(); _factory[3] = CentralHidroOra.getFactory(); }

MutableStruct _struct; static final AporExtracOra _AporExtracOraFactory = new AporExtracOra(); public static CustomDatumFactory getFactory() { return _AporExtracOraFactory;

/* constructors */ public AporExtracOra() { _struct = new MutableStruct(new Object[4], _sqlType, _factory); try {

}

{

340

Código Fuente _ctx = null;

{

public CanalOra getCa() throws SQLException

} } public AporExtracOra(ConnectionContext c) throws SQLException { _struct = new MutableStruct(new Object[4], _sqlType, _factory); _ctx = new _Ctx(c == null ? DefaultContext.getDefaultContext() : c); } public AporExtracOra(Connection c) throws SQLException { _struct = new MutableStruct(new Object[4], _sqlType, _factory); _ctx = new _Ctx(c); } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { _ctx = new _Ctx(c); return _struct.toDatum(c, _SQL_NAME); } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { if (d == null) return null; AporExtracOra o = new AporExtracOra(); o._struct = new MutableStruct((STRUCT) d, _sqlType, _factory); o._ctx = new _Ctx(((STRUCT) d).getConnection()); return o; } /* shallow copy method: give object same attributes as argument */ void shallowCopy(AporExtracOra d) throws SQLException

_struct = d._struct; } /* accessor methods */ public java.math.BigDecimal getTipo() throws SQLException { return (java.math.BigDecimal) _struct.getAttribute(0); } public void setTipo(java.math.BigDecimal tipo) throws SQLException { _struct.setAttribute(0, tipo); }

{ return (CanalOra) _struct.getAttribute(1); } public void setCa(CanalOra ca) throws SQLException { _struct.setAttribute(1, ca); }

341

Código Fuente

{ return (TramoOra) _struct.getAttribute(2); }

public void setTr(TramoOra tr) throws SQLException

// #sql [_ctx] { BEGIN

public TramoOra getTr() throws SQLException

{ _struct.setAttribute(2, tr); }

public CentralHidroOra getCh() throws SQLException { return (CentralHidroOra) _struct.getAttribute(3); } public void setCh(CentralHidroOra ch) throws SQLException { _struct.setAttribute(3, ch); } public java.math.BigDecimal demanda ( java.math.BigDecimal caudal, java.math.BigDecimal m) throws SQLException { AporExtracOra __jPt_temp = this; java.math.BigDecimal __jPt_result; /*@lineinfo:generated-code*//*@lineinfo:127^5*/ // ************************************************************

// :__jPt_result := :__jPt_temp.DEMANDA( // :caudal, // :m); // END; // }; // ************************************************************ { sqlj.runtime.ConnectionContext __sJT_connCtx = _ctx; if (__sJT_connCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_CONN_CTX(); sqlj.runtime.ExecutionContext __sJT_execCtx = __sJT_connCtx.getExecutionContext(); if (__sJT_execCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_EXEC_CTX(); AporExtracOra __sJT_2 = __jPt_temp; java.math.BigDecimal __sJT_3 = caudal; java.math.BigDecimal __sJT_4 = m; synchronized (__sJT_execCtx) { sqlj.runtime.profile.RTStatement __sJT_stmt = __sJT_execCtx.registerStatement(__sJT_connCtx, AporExtracOra_SJProfileKeys.getKey(0), 0); try { __sJT_stmt.setObject(2, __sJT_2); __sJT_stmt.setBigDecimal(3, __sJT_3); __sJT_stmt.setBigDecimal(4, __sJT_4); __sJT_execCtx.executeUpdate(); __jPt_result = __sJT_stmt.getBigDecimal(1);

342

Código Fuente

{

// :caudal,

sqlj.runtime.ConnectionContext __sJT_connCtx = _ctx;

sqlj.runtime.ExecutionContext __sJT_execCtx = __sJT_connCtx.getExecutionContext();

} finally

__sJT_execCtx.releaseStatement(); } } } // ************************************************************ /*@lineinfo:user-code*//*@lineinfo:133^5*/ return __jPt_result; } public void entrada ( java.math.BigDecimal caudal, java.math.BigDecimal m) throws SQLException { AporExtracOra __jPt_temp = this; /*@lineinfo:generated-code*//*@lineinfo:143^5*/ // ************************************************************ // #sql [_ctx] { BEGIN // :__jPt_temp.ENTRADA(

// :m); // END; // }; // ************************************************************ {

if (__sJT_connCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_CONN_CTX();

if (__sJT_execCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_EXEC_CTX(); AporExtracOra __sJT_1 = __jPt_temp; java.math.BigDecimal __sJT_2 = caudal; java.math.BigDecimal __sJT_3 = m; synchronized (__sJT_execCtx) { sqlj.runtime.profile.RTStatement __sJT_stmt = __sJT_execCtx.registerStatement(__sJT_connCtx, AporExtracOra_SJProfileKeys.getKey(0), 1); try { __sJT_stmt.setObject(1, __sJT_1); __sJT_stmt.setBigDecimal(2, __sJT_2); __sJT_stmt.setBigDecimal(3, __sJT_3); __sJT_execCtx.executeUpdate();

343

Código Fuente __jPt_temp = ((AporExtracOra)(__sJT_stmt.getObject(1, AporExtracOra.class))); } finally { __sJT_execCtx.releaseStatement(); } } } // ************************************************************ /*@lineinfo:user-code*//*@lineinfo:149^5*/ shallowCopy(__jPt_temp); } public java.math.BigDecimal salida ( java.math.BigDecimal m) throws SQLException { AporExtracOra __jPt_temp = this; java.math.BigDecimal __jPt_result; /*@lineinfo:generated-code*//*@lineinfo:159^5*/ // ************************************************************ // #sql [_ctx] { BEGIN // :__jPt_result := :__jPt_temp.SALIDA( // :m); // END; // }; // ************************************************************ { sqlj.runtime.ConnectionContext __sJT_connCtx = _ctx; if (__sJT_connCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_CONN_CTX(); sqlj.runtime.ExecutionContext __sJT_execCtx = __sJT_connCtx.getExecutionContext(); if (__sJT_execCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_EXEC_CTX(); AporExtracOra __sJT_2 = __jPt_temp; java.math.BigDecimal __sJT_3 = m; synchronized (__sJT_execCtx) { sqlj.runtime.profile.RTStatement __sJT_stmt = __sJT_execCtx.registerStatement(__sJT_connCtx, AporExtracOra_SJProfileKeys.getKey(0), 2); try { __sJT_stmt.setObject(2, __sJT_2); __sJT_stmt.setBigDecimal(3, __sJT_3); __sJT_execCtx.executeUpdate(); __jPt_result = __sJT_stmt.getBigDecimal(1); }

344

Código Fuente

sqlj.runtime.profile.RTStatement __sJT_stmt = __sJT_execCtx.registerStatement(__sJT_connCtx, AporExtracOra_SJProfileKeys.getKey(0), 3);

finally { __sJT_execCtx.releaseStatement(); } } } // ************************************************************ /*@lineinfo:user-code*//*@lineinfo:164^5*/ return __jPt_result; } public String tovarchar2 () throws SQLException { AporExtracOra __jPt_temp = this; String __jPt_result; /*@lineinfo:generated-code*//*@lineinfo:173^5*/ // ************************************************************ // #sql [_ctx] { BEGIN // :__jPt_result := :__jPt_temp.TOVARCHAR2(); // END; // }; // ************************************************************ { sqlj.runtime.ConnectionContext __sJT_connCtx = _ctx; if (__sJT_connCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_CONN_CTX(); sqlj.runtime.ExecutionContext __sJT_execCtx = __sJT_connCtx.getExecutionContext(); if (__sJT_execCtx == null) sqlj.runtime.error.RuntimeRefErrors.raise_NULL_EXEC_CTX(); AporExtracOra __sJT_2 = __jPt_temp; synchronized (__sJT_execCtx) {

try { __sJT_stmt.setObject(2, __sJT_2); __sJT_execCtx.executeUpdate(); __jPt_result = __sJT_stmt.getString(1); } finally { __sJT_execCtx.releaseStatement(); } } }

345

Código Fuente

}/*@lineinfo:generated-code*/class AporExtracOra_SJProfileKeys

// ************************************************************ /*@lineinfo:user-code*//*@lineinfo:177^5*/ return __jPt_result; }

{ private static AporExtracOra_SJProfileKeys inst = null; public static java.lang.Object getKey(int keyNum) throws java.sql.SQLException { if (inst == null) { inst = new AporExtracOra_SJProfileKeys(); } return inst.keys[keyNum]; } private final sqlj.runtime.profile.Loader loader = sqlj.runtime.RuntimeContext.getRuntime().getLoaderForClass(getClass()); private java.lang.Object[] keys; private AporExtracOra_SJProfileKeys() throws java.sql.SQLException { keys = new java.lang.Object[1]; keys[0] = AporExtracOra._Ctx.getProfileKey(loader, "objcuenca/AporExtracOra_SJProfile0"); } }

C.4.4.2 Clase: AporExtracOraRef package objcuenca; //linea agregada manualmente import java.sql.SQLException; import Oracle.jdbc.driver.OracleConnection; import Oracle.jdbc.driver.OracleTypes; import Oracle.sql.CustomDatum; import Oracle.sql.CustomDatumFactory; import Oracle.sql.Datum; import Oracle.sql.REF; import Oracle.sql.STRUCT; public class AporExtracOraRef implements CustomDatum, CustomDatumFactory { public static final String _SQL_BASETYPE = "APOR_EXTRAC"; public static final int _SQL_TYPECODE = OracleTypes.REF; REF _ref;

static final AporExtracOraRef _AporExtracOraRefFactory = new AporExtracOraRef();

public static CustomDatumFactory getFactory() {

346

Código Fuente

} return _AporExtracOraRefFactory;

/* constructor */ public AporExtracOraRef() { } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { return _ref; } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { if (d == null) return null; AporExtracOraRef r = new AporExtracOraRef(); r._ref = (REF) d; return r; } public AporExtracOra getValue() throws SQLException { return (AporExtracOra) AporExtracOra.getFactory().create( (Datum) _ref.getValue(), OracleTypes.REF); } public void setValue(AporExtracOra c) throws SQLException { _ref.setValue((STRUCT) c.toDatum(_ref.getConnection())); } }

347

Código Fuente

* Obtiene desde la base de datos un objeto del tipo CuencaOraRef a

{

cuencaRef._ref =rs.getREF(1);

*/

C.4.4.3 Clase: BDObjCuenca package objcuenca; import java.sql.*; import Oracle.jdbc2.*; import Oracle.sql.*; import Oracle.jdbc.driver.*; import Oracle.jdbc.oracore.*; import Oracle.sqlj.runtime.Oracle; import Oracle.sqlj.runtime.util.*; import consultorSql.ConectorJDBC; import java.util.Vector; import java.util.Dictionary; import objcuenca.*; public class BDObjCuenca extends ConectorJDBC { /** * Constructor Generico. */ public BDObjCuenca() { super(); } /** * Constructor con parametros de coneccion. */ public BDObjCuenca(String url, String driverName, String user, String passwd) { super(url,driverName,user,passwd); } /*********************************************************************

* partir del codigo del objeto al que referencia. */ public CuencaOraRef getCuencaRef(String codigo) throws Exception

PreparedStatement st= getConnection().prepareStatement( "SELECT ref(c) FROM tbl_cuenca c where c.codigo=(?)") ; st.setObject(1,codigo,OracleTypes.VARCHAR) ; st.executeQuery(); OracleResultSet rs = (OracleResultSet) st.getResultSet() ; rs.next() ; CuencaOraRef cuencaRef= new CuencaOraRef();

return cuencaRef; } /** * Obtiene desde la base de datos un objeto del tipo RioOraRef * del codigo del objeto al que referencia.

public RioOraRef getRioRef(String codigo)

348

Código Fuente

RioOraRef rioRef= new RioOraRef();

{

}

* partir de su codigo

return cuencaRef.getValue();

*/

getConnection().prepareStatement(

OracleResultSet rs = (OracleResultSet) st.getResultSet() ;

{ try { PreparedStatement st= getConnection().prepareStatement( "SELECT ref(r) FROM tbl_rio r where r.codigo=(?)") ; st.setObject(1,codigo,OracleTypes.VARCHAR) ; st.executeQuery(); OracleResultSet rs = (OracleResultSet) st.getResultSet() ; rs.next() ;

rioRef._ref =rs.getREF(1); return rioRef; } catch (Exception err)

err.printStackTrace(System.err); return null;

} /** * Obtiene desde la base de datos un objeto del tipo CuencaOra a

*/ public CuencaOra getCuenca(String codigo) throws Exception { CuencaOraRef cuencaRef=getCuencaRef(codigo);

} /** * Obtiene los nodos de la cuenca. y los debuelve * en un vector. Se entrega un NodoOraRef

public Vector getAllNodoOraRef(CuencaOra c) throws Exception { Vector nodos=new Vector(); PreparedStatement st=

" SELECT ref(n) " + " FROM tbl_nodo n"+ " where n.myCuenca = "+ " (SELECT ref(c) FROM tbl_cuenca c where c.codigo=(?))" ); st.setObject(1,c.getCodigo(),OracleTypes.VARCHAR) ; st.executeQuery();

while(rs.next()) { GuiNodo guiNodoRef=new GuiNodo(); guiNodoRef._ref=rs.getREF(1); guiNodoRef.loadFigura(); nodos.add(guiNodoRef) ;

349

Código Fuente

*/

getConnection().prepareStatement(

" where e.myNodo.myCuenca.codigo = ?") ;

{

emb.loadFigura();

Vector vector=new Vector();

while(rs.next())

} return nodos; }

/** * Obtiene los embalses de la cuenca. y los debuelve * en un vector. Se entrega un EmbalseOraRef

public Vector getAllEmbalseOraRef(CuencaOra c) throws Exception { Vector embalses=new Vector(); PreparedStatement st=

" SELECT ref(e) " + " FROM tbl_emb e"+

st.setObject(1,c.getCodigo(),OracleTypes.VARCHAR) ; st.executeQuery(); OracleResultSet rs = (OracleResultSet) st.getResultSet() ; while(rs.next())

GuiEmbalse emb=new GuiEmbalse(); emb._ref=rs.getREF(1);

embalses.add(emb) ; } return embalses; } /** * Obtiene los Flujos de la y los debuelve * en un vector. Se entrega un FlujoOraRef */ public Vector getAllFlujosOraRef(CuencaOra c) throws Exception {

PreparedStatement st= getConnection().prepareStatement( " SELECT ref(f) " + " FROM tbl_flujo f"+ " where f.nodo_ini.myCuenca.codigo = ?"+ " or f.nodo_fin.myCuenca.codigo = ?") ; st.setObject(1,c.getCodigo(),OracleTypes.VARCHAR) ; st.setObject(2,c.getCodigo(),OracleTypes.VARCHAR) ; st.executeQuery(); OracleResultSet rs = (OracleResultSet) st.getResultSet() ;

{ GuiFlujo figura=new GuiFlujo(); figura._ref=rs.getREF(1); figura.loadFigura(); vector.add(figura) ;

350

Código Fuente

return vector;

return vector;

/**

PreparedStatement st=


" VALUES (rio(?,?))"

st.executeQuery();

* Eliminar cuenca.

}

}

/** * obtiene todas las figuras de la cuenca. * */ public Vector getAllFigRef(CuencaOra c) throws Exception { Vector vector=getAllNodoOraRef(c); vector.addAll(getAllEmbalseOraRef(c)); vector.addAll(getAllFlujosOraRef(c));

}

* Inserta una cuenca a la base de datos */ public void Insertar(CuencaOra c) throws SQLException {

getConnection().prepareStatement( " INSERT INTO tbl_cuenca" + " VALUES (cuenca(?,?))" ); st.setObject(1,c.getCodigo(),OracleTypes.VARCHAR) ; st.setObject(2,c.getNombre(),OracleTypes.VARCHAR) ; st.executeQuery(); } /** * Inserta un rio a la base de datos. */ public void Insertar(RioOra c) throws SQLException {

getConnection().prepareStatement( " INSERT INTO tbl_rio" +

); st.setObject(1,c.getCodigo(),OracleTypes.VARCHAR) ; st.setObject(2,c.getNombre(),OracleTypes.VARCHAR) ;

} /**

*/ public void eliminar(CuencaOra c) throws SQLException

351

Código Fuente


*/


{

getConnection().prepareStatement( " DELETE FROM tbl_cuenca c" + " WHERE c.codigo=?" ); st.setObject(1,c.getCodigo().trim(),OracleTypes.VARCHAR) ; st.executeQuery(); } /** * Eliminar Rio

public void eliminar(RioOra c) throws SQLException {

getConnection().prepareStatement( " DELETE FROM tbl_rio r" + " WHERE r.codigo=?" ); st.setObject(1,c.getCodigo().trim(),OracleTypes.VARCHAR) ; st.executeQuery(); } /** * Insertar un Canal * * */ public GuiFlujo insertar(FlujoOra flujo) throws SQLException { OracleCallableStatement ocs= (OracleCallableStatement) getConnection().prepareCall("{ ? = call Insert_Flujo(?) }"); ocs.registerOutParameter(1,OracleTypes.REF,"FLUJO"); ocs.setCustomDatum(2,flujo); ocs.execute(); GuiFlujo guiFlujo=new GuiFlujo(); guiFlujo._ref =ocs.getREF(1); return guiFlujo; } }

352

Código Fuente

/**-----------------------------------------------------------------

Codigo=em.getCodigo();

C.4.4.4 Clase: GuiEmbalse package objcuenca; import objcuenca.*; import java.awt.Dimension; import javax.swing.JOptionPane; import java.sql.SQLException; import java.math.*; import cuencamaule.frmEmbalse; import figuras.*;

public class GuiEmbalse extends EmbalseOraRef implements Graficable { private int zoom=100; private GrafEmbOra graf; private String Codigo; private frmEmbalse frm; private boolean alerta=false; public GuiEmbalse() { }

* Carga la figura que reprecenta al embaslse */ public void loadFigura() { try { int zoomAct=zoom; EmbalseOra em=this.getValue(); //la figura almacenada en la base de datos, esta al 100% zoom=100; graf=em.getGraf();

this.alerta=alertaEmb(); // restauro el valor del zoom, // y se ajusta la figura que estaba al100% setZoom(zoomAct); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); } } // implementacion metodos de la interfaz Graficable /** * Cambia el valor del zoom con el pasado como parametro */ public void setZoom(int zoom) {

353

Código Fuente try { TrianguloOra tr=graf.getTr() ; PuntoOra a=tr.getA() ; PuntoOra b=tr.getB() ; PuntoOra c=tr.getC() ; double X;double Y; int actual=getZoom(); //aplicando el zoom al punto a X = a.getX().doubleValue() ; Y = a.getY().doubleValue() ; X=(X * zoom)/actual; Y=(Y * zoom)/actual; a.setX(new BigDecimal(X)); a.setY(new BigDecimal(Y)); //aplicando el zoom al punto b X = b.getX().doubleValue() ; Y = b.getY().doubleValue() ; X=(X * zoom)/actual; Y=(Y * zoom)/actual; b.setX(new BigDecimal(X)); b.setY(new BigDecimal(Y)); //aplicando el zoom al punto c X = c.getX().doubleValue() ; Y = c.getY().doubleValue() ; X=(X * zoom)/actual; Y=(Y * zoom)/actual; c.setX(new BigDecimal(X)); c.setY(new BigDecimal(Y)); tr.setA(a); tr.setB(b); tr.setC(c) ; graf.setTr(tr); this.zoom=zoom; } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); } } /********************************************************** * Entrega el Zoom actual * */ public int getZoom() { return zoom;

354

Código Fuente } private boolean alertaEmb() { try { ArrCaudalesOra curAler=this.getValue().getCurvaAlerta(); ArrCaudalesOra caudal =this.getValue().getCaudales(); boolean colorCambiado=false; for(int i=1;i<=6;i++) { if(curAler.getcaudal(new BigDecimal(i)).compareTo( caudal.getcaudal(new BigDecimal(i)))==1) { return true; } } } catch (Exception ex) { JOptionPane.showMessageDialog(null,"Error en el embalse : " +ex.getMessage()) ; } return false; } /*********************************************************** * Dibuja un triangulo que reprecenta al embalse * */ public void dibujar(Dibujante d) { try { if(alerta){d.setColorLinea(java.awt.Color.red);} TrianguloOra tr=graf.getTr() ; d.drawTriangulo(tr) ; PuntoOra poA=tr.getA() ; PuntoOra poB=tr.getB() ; PuntoOra poC=tr.getC() ; Punto a=new Punto( poA.getX().intValue(),poA.getY().intValue()); Punto b=new Punto( poB.getX().intValue(),poB.getY().intValue()); Punto c=new Punto( poC.getX().intValue(),poC.getY().intValue()); a.x=c.x; int an = (int) b.distanciaA(c); int alturaTriangulo = (int) a.distanciaA(c) ; int al = alturaTriangulo/2; int x=b.x; int y=b.y-(alturaTriangulo/2);

355

Código Fuente //las constantes 3 y 22 furon obtenidas empiricamente. int tamfuente=an*3/22; if(Codigo.length() >0) { d.drawCenteredString(Codigo ,x,y,an, al,tamfuente); d.drawCenteredString("F Ee R Er G", b.x,b.y,an,al*2/3,tamfuente); } if(alerta){d.setColorLinea(java.awt.Color.black);} } catch (Exception err) { JOptionPane.showMessageDialog(null,err.getMessage()); } } /*********************************************************** * Despliega el dialogo para modificar los atributos del * nodo * */ public void dlgAtributos() { try { PuntoOra poA=graf.getTr().getA(); frm=new frmEmbalse(this); frm.setLocation(poA.getX().intValue() , poA.getY().intValue()); frm.pack() ; frm.show() ; } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); } } /************************************************************ * Entrega la dimencion minima para el contenedor * del embalse * */ public Dimension dimensionMinima() { try { int x=graf.getTr().getC().getX().intValue() ; int y=graf.getTr().getC().getY().intValue() ; return (new Dimension(x,y)); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage());

356

Código Fuente return null; } } /************************************************************ * Entrega Verdadero si el punto pasado por parametro * percenece al triangulo o falso si no pertenece. */ public boolean pertenece(Punto p) { try { TrianguloOra tr=graf.getTr() ; PuntoOra poA=tr.getA() ; PuntoOra poB=tr.getB() ; PuntoOra poC=tr.getC() ; Punto a=new Punto( poA.getX().intValue(),poA.getY().intValue() ); Punto b=new Punto( poB.getX().intValue(),poB.getY().intValue() ); Punto c=new Punto( poC.getX().intValue(),poC.getY().intValue() ); Punto inicio,fin,direccion; int coorx,cnt=0,np=3; Punto q[]={a,b,c}; for(int i=0;i<np;i++) { inicio=p.restar(q[i%np]); fin=p.restar(q[(i+1)%np]); if((inicio.y * fin.y) <=0) { if((inicio.y!=0) || (fin.y!=0)) { direccion = inicio.restar(fin); coorx = (inicio.x * direccion.y - inicio.y * direccion.x); if(direccion.y<0) coorx*=-1; if(coorx==0) {cnt =1; break;} if(coorx > 0) { cnt++; if((inicio.y < 0 && fin.y==0)|| (inicio.y==0 && fin.y<0)) cnt --; } } } } return ((cnt %2)!=0); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); return false; } } }

357

Código Fuente C.4.4.5 Clase: GuiFlujo package objcuenca; import objcuenca.*; import java.awt.Dimension; import javax.swing.JOptionPane; import java.sql.SQLException; import java.math.*; import cuencamaule.*; import figuras.*; public class GuiFlujo extends FlujoOraRef implements Graficable { private int zoom=100; private GrafCuencaOra graf; private frmFlujo frm; private boolean alerta=false; /** * Constructor por defecto. */ public GuiFlujo() { } //Carga la figura que reprecenta al flujo public void loadFigura() { try { //Como vamos a leer la figura desde la base de datos, debemos //ajustarla al valor del zoom actual. Para esto guardo el zoom. int zoomAct=zoom; //la figura almacenada en la base de datos, esta al 100% zoom=100; graf=this.getValue().getGraf(); // restauro el valor del zoom, y se ajusta la figura que // estaba al100% this.alerta=alertaFlujo(); setZoom(zoomAct); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } }

358

Código Fuente // ajuste de Zoom para una figura del tipo GrafCentHidroOra private void setZoomCentHidro(int zoom) { try { GrafCentHidroOra gch=graf.getGch(); PolilineaOra pl1=graf.getGch().getPl1(); PolilineaOra pl2=graf.getGch().getPl2(); //ajustando zoom polilineas int cont=0; PolilineaOra pl=pl1; while(cont!=2) { int actual=getZoom(); int largo=pl.getNpuntos().intValue(); double X,Y; PuntoOra a; int i; for(i=1;i<=largo;i++) { a=pl.getp(new BigDecimal(i)); X = a.getX().doubleValue() ; Y = a.getY().doubleValue() ; X=(X * zoom)/actual; Y=(Y * zoom)/actual; a.setX(new BigDecimal(X)); a.setY(new BigDecimal(Y)); pl.setp(a,new BigDecimal(i)); } pl=pl2; cont++; } gch.setPl1(pl1); gch.setPl2(pl2); CuadradoOra cuad=graf.getGch().getCuad(); PuntoOra a=graf.getGch().getCuad().getA() ; PuntoOra b=graf.getGch().getCuad().getB() ; PuntoOra c=graf.getGch().getCuad().getC() ; PuntoOra d=graf.getGch().getCuad().getD() ; //ajustando puntos del cuadrado. PuntoOra p=a ; cont=0; while(cont != 4) { double X = p.getX().doubleValue() ; double Y = p.getY().doubleValue() ; int actual=getZoom(); X=(X * zoom)/actual; Y=(Y * zoom)/actual; p.setX(new BigDecimal(X)); p.setY(new BigDecimal(Y)); cont++; switch (cont)

359

Código Fuente { case 1: p=b; break; case 2: p=c; break; case 3: p=d; break; } } cuad.setA(a); cuad.setB(b); cuad.setC(c); cuad.setD(d); gch.setCuad(cuad); graf.setGch(gch); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } } // aplica el zoom a un GrafFlujoOra private void setZoomGrafFlujo(int zoom) { try { int actual=getZoom(); int largo=graf.getGfl().getPl().length(); double X,Y; PuntoOra a; for(int i=0;i<largo;i++) { a=graf.getGfl().getPl().getElement(i) ; X = a.getX().doubleValue() ; Y = a.getY().doubleValue() ; X=(X * zoom)/actual; Y=(Y * zoom)/actual; a.setX(new BigDecimal(X)); a.setY(new BigDecimal(Y)); graf.getGfl().getPl().setElement(a,i) ; } } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } }

360

Código Fuente

*/

try

// implementacion metodos de la interfaz Graficable public void setZoom(int zoom) { try { if ((graf != null)&&(graf.getTipo() != null)) { switch (graf.getTipo().intValue()) { case 1: setZoomGrafFlujo(zoom); break; case 2: setZoomCentHidro(zoom); break; } this.zoom=zoom; } } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } } /********************************************************** * Entrega el Zoom actual * */ public int getZoom() { return zoom; } /*********************************************************** * Dibuja un flujo.

private void dibujarFlujo(Dibujante d) {

{ ArrPuntosOra arrp=graf.getGfl().getPl(); switch (graf.getGfl().getEstilo().intValue()) { case 1: //linea simple d.drawPolilinea(arrp) ; break; case 2: //linea doble d.drawPolilineaDoble(arrp) ; break;

361

Código Fuente

err.printStackTrace(System.err) ;

{

try

{

case 3: //gruesa d.drawPolilineaGruesa(arrp) ; break; } } catch (Exception err) { JOptionPane.showMessageDialog(null,err.getMessage());

} } /********************************************************* * Dibuja una Central Hidroelectrica. */ private void dibujarCentHidro(Dibujante d) { try

GrafCentHidroOra ch=graf.getGch(); d.drawCuadrado(ch.getCuad()); d.drawPolilinea(ch.getPl1()); d.drawPolilinea(ch.getPl2().getLospuntos()); } catch (Exception err) { err.printStackTrace(System.err) ; JOptionPane.showMessageDialog(null,err.getMessage()); } } /*********************************************************** * Dibuja el flujo correspondiente. * */

public void dibujar(Dibujante d) { if(alerta){d.setColorLinea(java.awt.Color.red);}

{ if((graf!=null)&&(graf.getTipo()!=null)) { switch (graf.getTipo().intValue())

case 1: dibujarFlujo(d); break; case 2: dibujarCentHidro(d); int ax=graf.getGch().getCuad().getA().getX().intValue();

362

Código Fuente

int dy=graf.getGch().getCuad().getD().getY().intValue();

{

else

if(fl.getAp().getTipo().intValue()==3)

int ay=graf.getGch().getCuad().getA().getY().intValue(); int bx=graf.getGch().getCuad().getB().getX().intValue(); int by=graf.getGch().getCuad().getB().getY().intValue(); int cx=graf.getGch().getCuad().getC().getX().intValue(); int cy=graf.getGch().getCuad().getC().getY().intValue(); int dx=graf.getGch().getCuad().getD().getX().intValue();

int al=Math.abs(cy - ay); int an=Math.abs(bx - ax); int x=ax ; int y=ay ; int tamfuente=an*9/24; d.drawCenteredString("C" ,x,y,an, al,tamfuente); break; } } } catch (Exception err) { JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } if(alerta){d.setColorLinea(java.awt.Color.black);} } /*********************************************************** * Despliega el dialogo para modificar los atributos del * flujo * */ public void dlgAtributos() { try { FlujoOra fl=this.getValue(); switch (fl.getTipo().intValue())

case 1://aportante if(fl.getAp().getTipo().intValue()==1) { frm=new frmHoyaInter(this); break; } else { if(fl.getAp().getTipo().intValue()==2) { frm=new frmRegNat(this); break; }

{

{

363

Código Fuente

{//si es un tramo.

if(fl.getApex().getTipo().intValue()==3)

catch (Exception err)

frm=new frmSalidaEmb(this); break; } } } break; case 2://extracción if(fl.getEx().getTipo().intValue() == 1 ) { frm=new FrmCapAguaPot(this); break; } case 3://aportante y extractor if(fl.getApex().getTipo().intValue() ==1 ) {//si es un canal. frm=new FrmCanal(this); break; } else { if(fl.getApex().getTipo().intValue() ==2)

frm=new FrmTramo(this); break; } else {

{// si es una central hidroelectrica. frm=new FrmCentralHidro(this); break; } } } default: frm=new frmFlujo(); break; } frm.pack() ; frm.show() ; }

{ JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; } }

364

Código Fuente

int y=0; int py=0;

for (int i = 0; i < largo; i++)

px=graf.getGfl().getPl().getElement(i).getX().intValue();

}

/** * Entrega la dimension minima para el contenedor de los * puntos en arr */ private Dimension dimensionMinimaGFlujo() { try { int x=0; int px=0;

int largo=graf.getGfl().getPl().length();

{

py=graf.getGfl().getPl().getElement(i).getY().intValue(); x=x>px?x:px; y=y>py?y:py; } return new Dimension(x,y); } catch (Exception ex) { JOptionPane.showMessageDialog(null,ex.getMessage()); ex.printStackTrace(System.err) ; return new Dimension(0,0); }

private Dimension dimensionMinima(PolilineaOra fl) { try { int x=0; int px=0; int y=0; int py=0; int largo=fl.getLospuntos().length(); for (int i = 0; i < largo; i++) { px=fl.getLospuntos().getElement(i).getX().intValue(); py=fl.getLospuntos().getElement(i).getY().intValue(); x=x>px?x:px; y=y>py?y:py; } return new Dimension(x,y); } catch (Exception ex) { JOptionPane.showMessageDialog(null,ex.getMessage()); ex.printStackTrace(System.err) ; return new Dimension(0,0); } }

365

Código Fuente

}

case 1:

break;

d=dimensionMinimaCH();

}

/** * Entrega la dimension minima para el contenedor la central * hidroelectrica */ private Dimension dimensionMinimaCH() { try { GrafCentHidroOra gch=graf.getGch() ; Dimension d1=dimensionMinima(gch.getPl1()); Dimension d2=dimensionMinima(gch.getPl2()); PuntoOra p=gch.getCuad().getD(); Dimension d3=new Dimension( p.getX().intValue(),p.getY().intValue()); int x=Math.max(d1.width , Math.max(d2.width,d3.width)); int y=Math.max(d1.height , Math.max(d2.height,d3.height)); return new Dimension(x,y); } catch (Exception ex) { JOptionPane.showMessageDialog(null,ex.getMessage()); ex.printStackTrace(System.err) ; return new Dimension(0,0);

} /************************************************************ * Entrega la dimencion minima para el contenedor * del nodo * */ public Dimension dimensionMinima() { try { Dimension d=new Dimension(0,0); if((graf!=null)&&(graf.getTipo()!=null)) { switch (graf.getTipo().intValue()) {

d=dimensionMinimaGFlujo();

case 2:

break;

} return d; } catch (SQLException err)

366

Código Fuente

}

{ JOptionPane.showMessageDialog(null,err.getMessage()); err.printStackTrace(System.err) ; return new Dimension(0,0); } } private boolean pertenece(ArrPuntosOra arr,Punto p) { try { int largo=arr.length(); PuntoOra[] vertice=new PuntoOra[largo]; for (int i = 0; i < largo; i++) { vertice[i]=arr.getElement(i); } for (int i=0;i<(vertice.length-1);i++) { Punto a=new Punto( vertice[i].getX().intValue(),vertice[i].getY().intValue()); Punto b=new Punto( vertice[i+1].getX().intValue(),vertice[i+1].getY().intValue()); if (!this.colineales(a,b,p)) {return false;} else { if (a.x!=b.x) { return ((a.x <= p.x) && (p.x <= b.x)) ||((a.x >=p.x)&&(p.x>=b.x)); } else { return ((a.y <= p.y) && (p.y <= b.y)) ||((a.y >=p.y)&&(p.y>=b.y));

} } return false; } catch (Exception ex) { JOptionPane.showMessageDialog(null,ex.getMessage()); ex.printStackTrace(System.err) ; return false; } }

367

Código Fuente

private boolean pertenece(GrafCentHidroOra gch,Punto p)

/**--------------------------------------------------------------- * p1,p2 linea de p1 a p2 * p3 el punto a consultar. * el mouse no es tan presiso, por eso la comparación * no es == a "0"(exacto) */ private boolean colineales(Punto a,Punto b,Punto c) { return (Math.abs((a.x * b.y) - (a.y * b.x) + (a.y * c.x) - (a.x * c.y) + (b.x * c.y) - (b.y*c.x))<300); }

{ try { PuntoOra a=gch.getCuad().getA(); PuntoOra b=gch.getCuad().getB(); PuntoOra c=gch.getCuad().getC(); PuntoOra d=gch.getCuad().getD(); int vecX[]={a.getX().intValue(),b.getX().intValue(), c.getX().intValue(),d.getX().intValue() }; int vecY[]={a.getY().intValue(),b.getY().intValue(), c.getY().intValue(),d.getY().intValue() }; Poligono pol=new Poligono(vecX,vecY,4); if (pol.pertenece(p)) {return true;} else if (pertenece(gch.getPl1().getLospuntos(),p)){return true;} else if (pertenece(gch.getPl2().getLospuntos(),p)){return true;} return false; } catch (Exception ex) { JOptionPane.showMessageDialog(null,ex.getMessage()); ex.printStackTrace(System.err) ; return false; } }

368

Código Fuente

* percenece a la figura, sino retorna falso.

{

resp=pertenece(graf.getGfl().getPl(),p);

break;

}

}

{

err.printStackTrace(System.err) ;

}

/**

try

FlujoOra flujo=this.getValue();

/************************************************************ * Entrega Verdadero si el punto pasado por parametro

* */ public boolean pertenece(Punto p)

try { boolean resp=false; if((graf!=null)&&(graf.getTipo()!=null)) { switch (graf.getTipo().intValue()) { case 1:

break; case 2: resp=pertenece(graf.getGch(),p);

}

return resp;


JOptionPane.showMessageDialog(null,err.getMessage());

return false; }

* Indica si el tipo de flujo no cumple con las condiciones impuestas */ private boolean alertaFlujo() {

{

int tipoFlujo=flujo.getTipo().intValue(); int tipoExtrac; try {tipoExtrac =flujo.getEx().getTipo().intValue();} catch (NullPointerException ex) {tipoExtrac=-1;} int tipoApex; try {tipoApex=flujo.getApex().getTipo().intValue();} catch (NullPointerException ex) { tipoApex=-1;} if((tipoFlujo==2)&&(tipoExtrac==1))

369

Código Fuente

if(caudales.getcaudal(new BigDecimal(i)).compareTo(

{ ArrCaudalesOra caudales=flujo.getEx().getCa().getCaudales(); ArrCaudalesOra caudalEx= flujo.getEx().getCa().getCaudalDeExtrac(); for(int i=1;i<=6;i++) { //si algun valor de caudales, es menor que el caudal de //extracción.

caudalEx.getcaudal(new BigDecimal(i)))==-1) { return true;} } } else { if((tipoFlujo==3)&&(tipoApex==3)) { ArrCaudalesOra cau=flujo.getApex().getCh().getCaudales(); double caudal; double caudalMinimoGeneracion= flujo.getApex().getCh().getCaudalMin().doubleValue(); for(int i=1;i<=6;i++) { caudal=cau.getcaudal(new BigDecimal(i)).doubleValue(); if (caudal<caudalMinimoGeneracion) { return true; } } } } } catch (Exception ex) { JOptionPane.showMessageDialog(null,"error en flujo: "+ ex.getMessage()); } return false; } }

370

Código Fuente

import javax.swing.JOptionPane;

import java.math.*;

import figuras.*;

}

C.4.4.6 Clase: GuiNodo package objcuenca; import objcuenca.*; import java.awt.Dimension;

import java.sql.SQLException;

import cuencamaule.frmNodo;

public class GuiNodo extends NodoOraRef implements Graficable { private int zoom=100; private ElipseOra graf; private String Codigo; private frmNodo frm; public GuiNodo() { } //Carga la figura que reprecenta al nodo localmente public void loadFigura() { try { //Como vamos a leer la figura desde la base de datos, //debemos ajustarla //al valor del zoom actual. Para esto guardo el zoom. int zoomAct=zoom; NodoOra no=this.getValue(); //la figura almacenada en la base de datos, esta al 100% zoom=100; graf=no.getGraf().getElip(); Codigo=no.getCodigo(); // restauro el valor del zoom, y se ajusta la figura //que estaba al100% setZoom(zoomAct); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage());

}

// implementacion metodos de la interfaz Graficable public void setZoom(int zoom) { try { PuntoOra c=graf.getCentro();

371

Código Fuente

c.setY(new BigDecimal(Y));

double alto = graf.getAlto().doubleValue() ; double ancho = graf.getAncho().doubleValue() ; double X = c.getX().doubleValue() ; double Y = c.getY().doubleValue() ; int actual=getZoom(); X=(X * zoom)/actual; Y=(Y * zoom)/actual; ancho=(ancho * zoom)/actual; alto =(alto * zoom)/actual;

c.setX(new BigDecimal(X));

graf.setCentro(c) ; graf.setAlto(new BigDecimal(alto)) ; graf.setAncho(new BigDecimal(ancho)); this.zoom=zoom; } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); } }

/********************************************************** * Entrega el Zoom actual * */ public int getZoom() { return zoom; } /*********************************************************** * Dibuja una elipse que reprecenta al nodo * */ public void dibujar(Dibujante d) { try { d.drawElipse(graf); int an=graf.getAncho().intValue() ; int al=graf.getAlto().intValue() ; int x=graf.getCentro().getX().intValue() ; int y=graf.getCentro().getY().intValue() ; x-=an/2; y-=al/2; int tamfuente=an*10/44; if(Codigo.length() >0) { d.drawCenteredString(Codigo ,x,y,an, al,tamfuente);

372

Código Fuente }

/***********************************************************

frm=new frmNodo(this);

public Dimension dimensionMinima()

try

int x=graf.getCentro().getX().intValue()+

} catch (Exception err) { JOptionPane.showMessageDialog(null,err.getMessage()); } }

* Despliega el dialogo para modificar los atributos del * nodo * */ public void dlgAtributos() { try { PuntoOra centro=graf.getCentro();

frm.setLocation(centro.getX().intValue(), centro.getY().intValue()); frm.pack() ; frm.show() ; } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); } } /************************************************************ * Entrega la dimencion minima para el contenedor * del nodo * */

{

{

(graf.getAncho().intValue()/2); int y=graf.getCentro().getY().intValue()+ (graf.getAlto().intValue()/2); return (new Dimension(x,y)); } catch (SQLException err) { JOptionPane.showMessageDialog(null,err.getMessage()); return null; } }

373

Código Fuente

int an=graf.getAncho().intValue() /2;

{return false;}

JOptionPane.showMessageDialog(null,err.getMessage());

}

/************************************************************ * Entrega Verdadero si el punto pasado por parametro * percenece a la elipse o falso si no pertenece. * */ public boolean pertenece(Punto p) { try { PuntoOra centro=graf.getCentro() ; Punto c=new

Punto(centro.getX().intValue(),centro.getY().intValue());

int al=graf.getAlto().intValue() /2; if ((((Math.pow((p.x-c.x),2))/(Math.pow(an,2)))+ ((Math.pow((p.y-c.y),2))/(Math.pow(al,2))))<=1) {return true;} else

} catch (SQLException err) {

return false;

}

}

374

Bibliografía

Bibliografía

[1] Carlos Batini, Stefano Ceri, Shamkant B. Navathe. Diseño conceptual de Bases de

datos, un enfoque de entidades-interrelaciones. Addison-Wesley/Diaz de Santos

1994

[2] Elisa Bertino, Lorenzo Martino. Sistemas de bases de datos orientadas a objetos,

conceptos y arquitecturas. Addison-Wesley/Diaz de Santos, 1995

[3] Luis A. Lobos, Mauricio J. Cardemil, Paola M. Terrazas. “Diseño e

Implementación de una Base de datos Objeto Relacional”. En: Actas del XIX

International Conference of the Chilean Computer Science Society, VII Encuentro

Chileno de computación, I congreso Chileno de Educación superior en

computación III Workshop Chileno en sistemas Distribuídos, Campeonato

Sudamericano de Programación ACM-Sede Chile. Talca – Chile, noviembre, 1999.

[4] Grady Booch. Análisis y Diseño Orientado a Objetos con Aplicaciones. Addison-

Wesley/Diaz de Santos, 1996

[5] Timothy Budd. Introducción a la Programación orientada a Objeto. Addison-

Wesley Iberoamericana, 1994.

[6] Paul Dorsey, Joseph R. Hudicka. Oracle 8. Diseño de Bases de datos con UML.

Osborne McGraw-Hill 1999.

[7] Andrew Eisenberg, Jim Melton. “Standars In Practice”. En la revista Sigmod

Record(http://www.acm.org/sigmod/record/) volumen 27 número 3, septiembre

de 1998.

[8] Andrew Eisenberg, Jim Melton. “SQL:1999, formerly know as SQL3”. En la revista

Sigmod Record(http://www.acm.org/sigmod/record/) volumen 28 número 1,

marzo de 1999.

[9] Andrew Eisenberg, Jim Melton. “SQL Standardization: the Next Steps”. En la

revista Sigmod Record(http://www.acm.org/sigmod/record/) volumen 29

número 1, marzo del 2000.

[10] Ramez Elmasri, Shamkant B. Navathe. Sistemas de bases de datos, conceptos

fundamentales. Addison-Wesley Iberoamericana, 1997.

[11] Craig Larman. Applying UML and patterns: an introduction to object-oriented

analysis and design. Prentice Hall 1998

[12] Patrick Naughton. Manual de Java. Osborne/McGraw-Hill, 1996

[13] Mario Piattini. “SABD Orientados a Objetos”. En: revista algoritmo

http://www.algoritmodigital.com, abril de 1995

[14] Mario Piattini. “El futuro de las Bases de Datos”. En: Tutorial del XIX International

376

Bibliografía

Conference of the Chilean Computer Science Society, VII Encuentro Chileno de

computación, I congreso Chileno de Educación superior en computación III

Workshop Chileno en sistemas Distribuídos, Campeonato Sudamericano de

Programación ACM-Sede Chile. Talca – Chile, noviembre, 1999.

[15] Mario Piattini. “SQL3: Futuro estándar de bases de datos (I)”. En: revista

algoritmo http://www.algoritmodigital.com, Octubre de 1995

[16] Mario Piattini. “SQL3: Futuro estándar de bases de datos (II)”. En: revista

algoritmo http://www.algoritmodigital.com, Noviembre de 1995

[17] Mario Piattini. “SQL3: Futuro estándar de bases de datos (y III)”. En: revista

algoritmo http://www.algoritmodigital.com, Diciembre de 1995

[18] Mario Piattini. “SQL/MM:Estándar para bases de datos multimedia”. En: revista

algoritmo http://www.algoritmodigital.com, Marzo de 1996

[19] Mario Piattini. “ODMG-93. El otro estándar para SABD Orientados a Objeto”. En:

revista algoritmo http://www.algoritmodigital.com, Abril de 1996.

[20] Roger S. Pressman. Ingeniería del Software un enfoque práctico, cuarta edición.

McGraw-Hill 1998.

[21] Antonio Quirós. “La persistencia de los objetos: un principio de la OOP (I)”. En:

revista algoritmo http://www.algoritmodigital.com

[22] Antonio Quirós. “La persistencia de los objetos: un principio de la OOP (II)”. En:

revista algoritmo http://www.algoritmodigital.com

[23] Carlos A. Sabino. Cómo hacer una tesis y toda clase de escritos, edición

ampliada. Editorial Lumen Hvmanitas, 1998

[24] Jeffrey Ulman. A First Course in Database System. Prentice Hall 1997

[25] ANSI X3H2-99-462/WG3:SAF-003, (ANSI/ISO Working Draft) Framework

(SQL/Framework), agosto 1999. En: ftp://jerry.ece.umassd.edu/SC32/WG3

[26] ANSI X3H2-99-463/WG3:SAF-004, (ANSI/ISO Working Draft) Foundation

(SQL/Foundation), agosto 1999. En: ftp://jerry.ece.umassd.edu/SC32/WG3

[27] Rational Software et al. “UML Notation Guide” en UML resource Center de

Rational Software. En: http://www.rational.com/uml/index.jsp

[28] Gilberto Gutiérrez R. “Modelamiento de Sistemas de Información Geográfica bajo

un enfoque de Orientación a Objetos. Tesis para optar al grado de Magíster en

Ciencias de la Computación de la Universidad de Chile.

[29] Enrique Kaliski y Luis Arrau. “Apuntes del curso de capacitación en modelación

hidrológica”. Documento perteneciente al la Dirección General de Aguas del

Ministerio de Obras Públicas de Chile.

377

ftp://jerry.ece.umassd.edu/SC32/WG3

ftp://jerry.ece.umassd.edu/SC32/WG3

http://www.rational.com/uml/index.jsp

Bibliografía

[30] Oracle. “Oracle 8i Applications Developer’s Guide – Fundamentts”. Número del

documento A68003-01 en: http://technet.Oracle.com/docs

[31] Oracle. “Oracle 8i Concepts”. Número del documento A67781-01 en:

http://technet.Oracle.com/docs

[32] Oracle. “Oracle 8i PL/SQL User’s Guide and Reference”. Número del documento

A67842-01 en : http://technet.Oracle.com/docs

[33] Oracle. “Oracle 8i Java Developer’s Guide”. Número del documento A64681-01

en : http://technet.Oracle.com/docs

[34] Oracle. “Oracle 8i Jpublisher User’s Guide”. Número del documento A68027-01

en: http://technet.Oracle.com/docs

[35] Oracle . “Oracle 8i Spatial. User’s Guide and reference”. Número del documento

A67295-01 en: http://technet.Oracle.com/docs

[36] Oracle. “Oracle8i SQLJ Developer’s Guide and Reference”. Número del


[37] Rational Software et al. “UML Summary” en UML resource Center de Rational

Software. En: http://www.rational.com/uml/index.jsp

[38] Rational Software et al. “UML Semantics” en UML resource Center de Rational

Software. En: http://www.rational.com/uml/index.jsp

[39] James Rumbaugh, Ivar Jacobson, Grady Booch. El Lenguaje Unificado de

Modelado. Manual de referencia. Addison Wesley, 2000.

[40] Mario Piattini. “El futuro de las bases de datos(I). Evolución y nuevos retos”. En:

revista algoritmo http://www.algoritmodigital.com, abril de 1997.

[41] Oracle. “Oracle8i SQL Reference”. Número del documento A67779-01 en:

http://technet.Oracle.com/docs

[42] Oracle. “Java Stored Procedures Developer’s Guide”. Número del documento


[43] Oracle. “Oracle8i JDBC Developer’s Guide and Reference”. Número del


[44] Oracle. “Oracle Call Interface Programer’s Guide”. Número del documento


[45] Martin Fowler. UML Gota A Gota. Editorial Addison Wesley Longman de México,

1999

[46] Jim Melton, Alan R. Simon. SQL:1999 Understanding Relational Language

Components. Morgan Kaufmann Publishers 2001

[47] ANSI X3H2-99-269/WG3:RTM-006, (ANSI-ISO Working Draft) Persistent Stored

378

http://technet.oracle.com/docs






http://www.rational.com/uml/index.jsp





Bibliografía

Modules (SQL/PSM), agosto 1999. En:

ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-

psm-1999-07.pdf

[48] ISO WG3:YYJ-007/H2-2001-144, (ISO-ANSI Working Draft) Temporal

(SQL/Temporal), Mayo 2001. En:

http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/5A5731749C3013238

8256A5B0044557A/$FILE/32N0651.PDF

[49] ISO WG3:YYJ-012/H2-2001-149, (ISO-ANSI Working Draft) XML-Related

Specifications (SQL/XML), Mayo 2001. En :

ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_dr

afts/wd-xml-2001-06.pdf

379

ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-psm-1999-07.pdf

ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-psm-1999-07.pdf

http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/5A5731749C30132388256A5B0044557A/$FILE/32N0651.PDF

http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/5A5731749C30132388256A5B0044557A/$FILE/32N0651.PDF

ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-xml-2001-06.pdf

ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-xml-2001-06.pdf

EL PARADIGMA DE LA ORIENTACION A OBJETO EN …andrea/cursos/SDB2005/La OO en SQL1999 y...El...

Documents

Transcript of EL PARADIGMA DE LA ORIENTACION A OBJETO EN …andrea/cursos/SDB2005/La OO en SQL1999 y...El...