Bases de Datos

BASES D E D A T O S

BASES D E D A T O S Enrique José Reinosa - Calixto Alejandro Maldonado - Roberto Muñoz Luis Esteban Damiano - Maximiliano Adrián Abrutsky

Alfaomega Buenos Aires • Bogotá • México DF • Santiago de Chile

Reinosa, Enrique José Bases de Datos / Enrique José Reinosa ; Calixto Alejandro Maldonado ; Roberto Muñoz ; Luis Esteban Damiano ; Maximiliano Adrián Abrutsky. - 1a ed. - Buenos Aires : Alfaomega Grupo Editor Argentino, 2012. 384 p. ; 24x21 cm. ISBN 978-987-1609-31-4 1. Informática. 2. Base de datos. I. Maldonado, Calixto II. Muñoz, Roberto III. Título CDD 005.3

Queda prohibida la reproducción total o parcial de esta obra, su tratamiento informático y/o la transmisión por cualquier otra forma o medio sin autorización escrita de Alfaomega Grupo Editor Argentino S.A. Edición: Damián Fernández Corrección de estilo: Juan Arana, Silvia Mellino y Vanesa García Diagramación de interiores: Diego Linares y Patricia Baggio Revisión de armado: Juan Micán Revisión técnica: Claudia Deco, Cristina Bendec, Calixto Alejandro Maldonado y Roberto Muñoz Diseño de tapa: Diego Linares Internet: http://www.alfaomega.com.mx Todos los derechos reservados © 2012, por Alfaomega Grupo Editor Argentino S.A. Paraguay 1307, PB, ofcina 11 ISBN 978-987-1609-31-4 Queda hecho el depósito que prevé la ley 11.723 NOTA IMPORTANTE: La información contenida en esta obra tiene un fn exclusivamente didáctico y, por lo tanto, no está previsto su aprovechamiento a nivel profesional o industrial. Las indicaciones técnicas y programas incluidos han sido elaborados con gran cuidado por el autor y reproducidos bajo estrictas normas de control. Alfaomega Grupo Editor Argentino S.A. no será jurídicamente responsable por: errores u omisiones; daños y perjuicios que se pudieran atribuir al uso de la información comprendida en este libro, ni por la utilización indebida que pudiera dársele. Los nombres comerciales que aparecen en este libro son marcas registradas de sus propietarios y se mencionan únicamente con fnes didácticos, por lo que Alfaomega Grupo Editor Argentino S.A. no asume ninguna responsabilidad por el uso que se dé a esta información, ya que no infringe ningún derecho de registro de marca. Los datos de los ejemplos y pantallas son fcticios, a no ser que se especifque lo contrario. Los hipervínculos a los que se hace referencia no son necesariamente administrados por la editorial, por lo que no somos responsables de sus contenidos o de su disponibilidad en línea. Empresas del grupo: Argentina: Alfaomega Grupo Editor Argentino, S.A. Paraguay 1307 P.B. “11”, Buenos Aires, Argentina, C.P. 1057 Tel.: (54-11) 4811-7183 / 0887 E-mail: [email protected] México: Alfaomega Grupo Editor, S.A. de C.V. Pitágoras 1139, Col. Del Valle, México, D.F., México, C.P. 03100 Tel.: (52-55) 5575-5022 – Fax: (52-55) 5575-2420 / 2490. Sin costo: 01-800-020-4396 E-mail: [email protected] Colombia: Alfaomega Colombiana S.A. Carrera 15 No. 64 A 29, Bogotá, Colombia PBX (57-1) 2100122 – Fax: (57-1) 6068648 E-mail: [email protected] Chile: Alfaomega Grupo Editor, S.A. Doctor La Sierra 1437 – Providencia, Santiago, Chile Tel.: (56-2) 235-4248 – Fax: (56-2) 235-5786 E-mail: [email protected]

“Dedicado a mi familia por el tiempo restado a ellos para la generación de este libro y a mis compañeros docentes y ayudantes por su colaboración en el proceso educativo de nuestros alumnos”. Enrique José Reinosa “A Alicia, mi compañera por veinte años y a Ludmila, Emilio y Sofía, mis tesoros, les dedico el esfuerzo y el resultado”. Calixto Alejandro Maldonado “A mis padres, por inculcarme el valor del estudio. A Eugenia, Alfonsina y Amparo por el estímulo permanente en todo lo que emprendo”. Roberto Muñoz “A los intelectualmente generosos, quienes ayudan a la construcción de un conocimiento para todos”. “A mi familia, a Valentina, Bruno y Andrea”. Luis Esteban Damiano “A Kela, mi madre, por inculcarme el esfuerzo y sus principios morales que me conducen en la vida, a Marcos, hermano y mejor amigo, y a Roberto un ejemplo de profesional y persona, sin ellos este aporte no hubiese sido posible”. Maximiliano Adrián Abrutsky

IX

Mensaje d e l Editor Los conocimientos son esenciales en el desempeño profesional. Sin ellos es imposible lograr las habilidades para competir laboralmente. La universidad o las instituciones de formación para el trabajo ofrecen la oportunidad de adquirir conocimientos que serán aprovechados más adelante en benefcio propio y de la sociedad. El avance de la ciencia y de la técnica hace necesario actualizar continuamente esos conocimientos. Cuando se toma la decisión de embarcarse en una vida profesional, se adquiere un compromiso de por vida: mantenerse al día en los conocimientos del área u ofcio que se ha decidido desempeñar. Alfaomega tiene por misión ofrecerles a estudiantes y profesionales conocimientos actualizados dentro de lineamientos pedagógicos que faciliten su utilización y permitan desarrollar las competencias requeridas por una profesión determinada. Alfaomega espera ser su compañera profesional en este viaje de por vida por el mundo del conocimiento. Alfaomega hace uso de los medios impresos tradicionales en combinación con las tecnologías de la información y las comunicaciones (IT) para facilitar el aprendizaje. Libros como éste tienen su complemento en una página Web, en donde el alumno y su profesor encontrarán materiales adicionales, información actualizada, pruebas (test) de autoevaluación, diapositivas y vínculos con otros sitios Web relacionados. Esta obra contiene numerosos gráfcos, cuadros y otros recursos para despertar el interés del estudiante, y facilitarle la comprensión y apropiación del conocimiento. Cada capítulo se desarrolla con argumentos presentados en forma sencilla y estructurada claramente hacia los objetivos y metas propuestas. Cada capítulo concluye con diversas actividades pedagógicas para asegurar la asimilación del conocimiento y su extensión y actualización futuras. Los libros de Alfaomega están diseñados para ser utilizados dentro de los procesos de enseñanza-aprendizaje, y pueden ser usados como textos guía en diversos cursos o como apoyo para reforzar el desarrollo profesional. Alfaomega espera contribuir así a la formación y el desarrollo de profesionales exitosos para benefcio de la sociedad.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

X

Bases de Datos

Enrique José Reinosa • • • • •

• • • • •

Analista Universitario de Sistemas de la UTN – FRBA. Ingeniero en Sistemas de Información de la UTN – FRBA. Posgrado en Ingeniería Gerencial (MBA) en la UTN – FRBA. Docente Investigador Categorizado en la UTN – FRBA. Profesor Titular Ordinario y Jefe de las Cátedras de: • Gestión de Datos • Paradigmas de Programación • Técnicas Gráfcas por Computadora • Técnicas Avanzadas de Programación • Tecnologías Avanzadas en la Construcción de Software • Administración de Recursos Coautor del Plan de Estudios 1995 de la Carrera Ingeniería en Sistemas de Información de la UTN. Profesor Tutor de Tesis de Títulos Intermedios de Analista Universitario de Sistemas. Director de Desarrollo de Software de la UTN – FRBA. Director de Desarrollo de Software del Instituto Nacional de Educación Técnica (INET). Consultor Independiente en Desarrollo de Software y Bases de Datos.

Calixto Alejandro Maldonado • • • • •

Ingeniero en Sistemas de Información de la UTN-FRC. Profesional certifcado Oracle Developer y DBA-OCP. Doctorando de Ingeniería en software basado en componentes reutilizables, en la Universidad de Vigo. Docente e Investigador en la UTN-FRC y la Universidad Empresarial 21. Consultor DBA independiente.

Roberto Muñoz • • • • • • • •

Ingeniero en Sistemas de Información de la UTN-FRC. Especialista en Docencia Universitaria de la UTN-FRC. Maestrando en Ingeniería en Sistemas de Información de la UTN-FRC. Jefe de la cátedra de Gestión de Datos de la UTN-FRC. Investigador en la UTN-FRC. Coordinador de la Diplomativa Superior en Administración y Exploración de Bases de Datos en la UTN-FRC. Coordinador universitario del Programa Nacional “Plan +” de “Becas Control-F” en la UTN-FRC. Integrante del Centro de Investigación y Desarrollo de Sistemas (CIDS) en la UTN-FRC.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

XI

Luis Esteban Damiano • • •

Analista de Sistemas de Computación de la UBP-ISP, Argentina. Licenciado en Tecnología Educativa de la UTN-FRC. Docente de las cátedras de Gestión de datos y Programación de aplicaciones visuales I en la UTN-FRC. Analista de Sistemas en la Dirección de Sistemas de Gobierno en Córdoba, Argentina. Capacitador del Programa Nacional “Plan+” de “Becas Control-F” (años 2008, 2009, 2010). Diseñador de sistemas independiente.

• • •

Maximiliano Adrián Abrutsky • • • • •

Ingeniero en Sistemas de Información de la UTN-FRC. Docente, Investigador y Maestrando (desarrollando Tesis) en la UTN-FRC. Docente en la UNC - Fac. Cs. Económicas. Socio gerente en Liricus Soluciones Informáticas. Java Developer Senior - DBA certifcado DB2 - SQL Server.

Revisores técnicos: Claudia Deco: •

Licenciada en Matemáticas de la Universidad Nacional de Rosario, Argentina.

•

Magíster en Informática de la Universidad de la República, Uruguay.

•

Doctora en Ingeniería de la Universidad Nacional de Rosario, Argentina.

Cristina Bendec: •

Ingeniera Electrónica de la Universidad de Rosario, Argentina.

•

Magíster en Informática de la Universidad de la República, Uruguay.

•

Especialista en Gestión de Sistemas de Información de la Universidad Católica Argentina.

Calixto Alejandro Maldonado Roberto Muñoz Agradecemos las sugerencias y comentarios realizados por: • Lucila Patricia Arellano Mendoza, Departamento de Computación de la Facultad de Ingeniería de la Universidad Nacional Autónoma de México. •

Nancy Ocotitla Rojas, Docente del Departamento de Ingeniería en Sistemas Computacionales en la ESCOM – IPN.

•

Euler Hernández Contreras, Jefe de la asignatura de Bases de Datos de la carrera de Ingeniería en Sistemas en la Escuela Superior de Cómputo del Instituto Politécnico Nacional.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

XIII

Contenido

Capítulo 1 Estructura y tipos de bases de datos

1

1.1 Introducción

2

1.2 Defnición de base de datos

3

1.3 Sistema de Gestión de Bases de Datos

4

1.4 Usuarios de la base de datos

5

1.5 Seguridad de las bases de datos 1.5.1 Creación de usuarios 1.5.2 Otorgar privilegios de sistema 1.5.3 Usar roles para administrar los accesos de base de datos 1.5.4 Otorgar privilegios de objetos 1.5.5 El cambio de contraseñas 1.5.6 Uso de sinónimos para la transparencia de base de datos

7 8 8 9 10 11 11

1.6 Funciones y responsabilidades de un DBA

12

1.7 Arquitectura ANSI/SPARC

13

1.8 Modelos de datos 1.8.1 Modelo de datos orientado a objetos

17 17

1.8.2 Modelos de datos basados en registros

19

1.9 Resumen

23

1.10 Contenido de la página Web de apoyo 1.10.1 Mapa conceptual del capítulo 1.10.2 Autoevaluación 1.10.3 Presentaciones

23 23 23 23

Capítulo 2 Modelo de datos relacional

25

2.1 Introducción 2.1.1 Conceptos básicos en el modelo relacional 2.1.2 Propiedades de las relaciones 2.1.3 Reglas de Codd 2.1.4 Atributos claves 2.1.5 Condiciones de las claves candidatas 2.1.6 Claves primarias 2.1.7 Clave foránea 2.1.8 Marcador de valores desconocidos 2.1.9 Correspondencias

26 27 29 29 31 31 32 33 34 35

2.1.10 Reglas de integridad 36 2.1.11 Diccionario de datos 37 2.1.12 Diseño de software utilizando bases de datos relacionales 38 2.1.13 El acceso a las bases de datos con aplicaciones escritas en JAVA 39 2.1.14 Acceso a las bases de datos a través de servicios Web 40 2.2 Álgebra relacional 2.2.1 Operaciones de conjuntos 2.2.2 Operaciones relacionales 2.2.3 Reunión 2.2.4 División 2.2.5 Renombrar 2.2.6 Funciones 2.2.7 Agrupación 2.2.8 Relaciones temporales 2.2.9 Cálculo relacional

41 44 48 50 54 55 56 57 58 61

2.3 Normalización 2.3.1 Fundamentos de la normalización 2.3.2 A qué se refere la normalización 2.3.3 A qué no se refere la normalización 2.3.4 Normalización aspecto formal 2.3.5 Concepto de normalizar 2.3.6 Objetivos de la normalización

63 63 64 65 66 66 67

2.4 Origen de los datos 2.4.1 Los datos 2.4.2 Problemática asociada al origen de datos 2.4.3 Los resultados

67 67 68 69

2.5 Las formas normales 2.5.1 las normas 2.5.2 Dominio (extensión conceptual) 2.5.3 Fundamento teórico de las normas 2.5.4 Enumeración de las normas 2.5.5 Interpretación y aplicación de las formas normales

69 69 70 70 72 73

2.6 Las estructuras 2.6.1 El modelo y sus estructuras 2.7 Un caso de estudio

92 92 99

2.8 Resumen

101

2.9 Contenido de la página Web de apoyo 2.9.1 Mapa conceptual del capítulo 2.9.2 Autoevaluación 2.9.3 Presentaciones*

101 101 101 101

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

Bases de Datos

XIV 4.6 Cursores

135

SQL

103

4.7 Errores

136

3.1 Introducción

104

3.2 Algo de historia del lenguaje SQL

104

136 136

3.3 Características del lenguaje SQL

105

4.8 El desarrollo de un bloque PL/SQL 4.8.1 Los tipos de datos de la base de datos 4.8.2 Tipos de datos que son propios del lenguaje PL/SQL 4.9 Interacción con la base de datos Oracle

138

4.10 El tratamiento de transacciones en PL/SQL

139

4.11 Sentencias de control de fujo

141

Capítulo 3

3.4 El lenguaje SQL y su sublenguaje de defnición de datos o DDL

106

3.5 Sentencias del sublenguaje DML 3.5.1 Funciones de f l a simple 3.5.2 Funciones numéricas 3.5.3 Funciones generales de comparación 3.5.4 Funciones de conversión 3.5.5 Funciones de grupo 3.5.6 La cláusula FROM 3.5.7 La cláusula WHERE 3.5.8 La cláusula GROUP BY 3.5.9 La cláusula HAVING 3.5.10 La cláusula ORDER BY

112 113 113 115 115 115 118 121 122 122 123

3.6 Sentencias del sublenguaje DML. INSERT, UPDATE, DELETE 123 3.6.1 Sentencia INSERT 123 3.6.2 Sentencia UPDATE 124 3.6.3 Sentencia MERGE 124 3.6.4 Sentencia DELETE 125

4.11.1 Usando loops

137

142

4.12 Manejo de cursores

144

4.13 Manejo de errores 4.13.1 Excepciones comunes 4.13.2 Codifcando en la sección de excepciones

148 150 150

4.14 Construyendo procedimientos y funciones con PL/SQL 4.14.1 Creando paquetes con PL/SQL 4.14.2 Creando triggers con PL/SQL

151 155 157

4.15 Resumen

159

4.16 Contenido de la página Web de apoyo 4.16.1 Mapa conceptual del capítulo 4.16.2 Autoevaluación 4.16.3 Presentaciones

159 159 159 159

3.7 Sentencias del sublenguaje TCL de control de transacciones

125

Capítulo 5

3.8 Procesamiento de consultas 3.8.1 Plan de consultas 3.8.2 Optimización de consultas

127 128 129

Bases de datos multidimensionales y tecnologías OLAP ...161

3.9 Resumen

129

3.10 Contenido de la página Web de apoyo 3.10.1 Mapa conceptual del capítulo 3.10.2 Autoevaluación 3.10.3 Presentaciones*

129 129 129 129

5.1 Introducción

162

5.2 Bases de datos multidimensionales 5.2.1 Evolución de las bases de datos 5.2.2 Concepto 5.2.3 Estructura de almacenamiento 5.2.4 Dispersión de datos

162 162 164 166 167 169 169 169 169

Lenguaje procedimental como extensión de SQL

131

4.1 Introducción

132

5.3 Tecnologías OLAP 5.3.1 Introducción 5.3.2 Concepto de OLAP 5.3.3 Características de OLAP 5.3.4 Comparación entre el modelo OLTP y el modelo OLAP

4.2 Vista general de PL/SQL

132

5.4 Integración entre bases de datos y herramientas OLAP .173

4.3 Uso del PL/SQL para acceder a la base de datos Oracle

132

Capítulo 4

170

5.5 Arquitecturas OLAP y OLTP

174

4.4 Programas con PL/SQL 133 4.4.1 Modularidad 133 4.4.2 Procedimientos, funciones, triggers y paquetes .... 133

5.6 OLAP: multidimensional contra relacional 5.6.1 OLAP multidimensional (MOLAP) 5.6.2 OLAP relacional (ROLAP) 5.6.3 OLAP híbrido (HOLAP)

175 177 178 182

4.5 Componentes de un bloque PL/SQL 134 4.5.1 Las construcciones lógicas y de control de fujo .... 135

5.7 Evaluación de servidores y herramientas OLAP 5.7.1 Características y funciones

182 182

Alfaomega

de d a t o s - Reinosa, M a l d o n a d o , M u ñ o z , Damiano, Abrutsky

XV

Contenido 5.7.2 Motores de servicios OLAP 5.7.3 Administración 5.7.4 Arquitectura global

182 183 183

6.11.3 Impactos técnicos del almacén de datos 6.11.4 Consideraciones fnales

212 212

6.12 Estrategia recomendada para la implementación de un almacén de datos 6.12.1 Prototipo 6.12.2 Piloto 6.12.3 Prueba del concepto tecnológico 6.12.4 Arquitectura de un almacén de datos 6.12.5 Acceso a datos de usuario fnales 6.12.6 Factores de riesgo

213 213 213 214 214 215 215

5.8 Desarrollo de aplicaciones OLAP

184

5.9 Áreas de aplicación de las tecnologías OLAP 5.9.1 Análisis de ventas 5.9.2 Gestión de informes fnancieros

185 185 186

5.10 Ventajas y desventajas de OLAP

186

5.11 Resumen

187

5.12 Contenido de la página Web de apoyo 5.12.1 Mapa conceptual del capítulo 5.12.2 Autoevaluación 5.12.3 Presentaciones

188 188 188 188

6.13 Resumen

216

6.14 Contenido de la página Web de apoyo 6.14.1 Mapa conceptual del capítulo 6.14.2 Autoevaluación 6.14.3 Presentaciones*

216 216 216 216

Almacén de datos

189

Capítulo 7

6.1 Introducción

190

Minería de datos

6.2 Inteligencia de negocio

191

7.1 Introducción

218

192

7.2 Concepto

218

6.3 Sistemas de almacén de datos

193

7.3 Características de la minería de datos

219

6.4 Concepto de almacén de datos

194

7.4 Capacidades de la minería de datos

220

6.5 Características de un almacén de datos

194

6.6 Arquitectura del almacén de datos 6.6.1 Bases de datos fuentes 6.6.2 Base de datos con datos resumidos 6.6.3 Interfaces orientadas al usuario 6.7 Funcionalidades y objetivo 6.7.1 Acceso a fuentes 6.7.2 Carga 6.7.3 Almacenamiento 6.7.4 Consultas 6.7.5 Metadatos

196 196 197 197 197 198 198 199 199 199

7.5 Herramientas algorítmicas de la minería de datos 7.5.1 Redes neuronales artifciales 7.5.2 Algoritmos Genéticos 7.5.3 Árboles de decisión

221 222 224 226

7.6 Modelado de la minería de datos

228

6.8 Almacén de datos y Data Mart

200

7.10 Aplicaciones de la minería de datos

232

6.9 La integridad de los datos 6.9.1 Concepto de Integridad 6.9.2 La perspectiva del usuario fnal 6.9.3 La perspectiva del Sistema de Información 6.9.4 Controles de integridad de datos

202 203 203 203 203

7.11 Resumen

233

7.12 Contenido de la página Web de apoyo 7.12.1 Mapa conceptual del capítulo 7.12.2 Autoevaluación 7.12.3 Presentaciones

233 233 233 233

6.10 Costos y valor del almacén de datos 6.10.1 Costos de un almacén de datos 6.10.2 Valor del almacén de datos 6.10.3 Balance entre los costos y el valor

208 208 210 210

6.11 Impactos de la implementación de un almacén de datos 6.11.1 Recursos Humanos 6.11.2 Impactos organizacionales

210 211 211

Capítulo 6

6.2.1 Datos, Información y Conocimiento

217

7.7 Integración entre almacén de datos y minería de datos 7.8 Ventajas de la minería de datos

229 230

7.9 Diferencias entre el análisis estadístico y la minería de datos

230

Capítulo 8 Bases de Datos Orientadas a Objetos

235

8.1 Introducción

236

8.2 Historia y origen de las BDOO

237

8.3 Conceptos fundamentales

238

8.4 Bases de la orientación a objetos

239

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

XVI 8.5 Características de las Bases de Datos Orientadas a Objetos 8.5.1 Modelo conceptual 8.5.2 Modelo de datos orientado a objetos 8.5.3 Persistencia de los datos 8.5.4 Almacenamiento y acceso de los objetos persistentes en una BDOO 8.5.5 Manifesto de Atkinson 8.5.6 Intento de estandarización ODMG 8.5.7 Enfoques para la construcción de BDOO

Bases de Datos

240 240 241 241

252 252 253 253 255

8.7 Rendimiento de las BDOO

256

8.8 Ventajas de las BDOO

256

8.9 Desventajas de las BDOO

257

8.10 Bases de Datos Objeto-Relacionales 8.10.1 Concepto 8.10.2 Características de las BDOR 8.10.3 Implementación en Oracle

258 258 258 259

8.11 Resumen

273

8.12 Contenido de la página Web de apoyo 8.12.1 Mapa conceptual del capítulo 8.12.2 Autoevaluación 8.12.3 Presentaciones

273 273 273 273

Capítulo 9 Implementando el modelo en Oracle Express Edition XE ..275

9.2 Creando y probando nuestro modelo de Estudiante – Universidad 9.3 Creación de las tablas y sus relaciones 9.3.1 Ejecución de script 9.3.2 Modelo de datos 9.3.3 Script (sentencias DDL) 9.3.4 Datos de prueba 9.3.5 Función escalar defnida por el usuario 9.3.6 Procedimiento almacenado defnido por el usuario 9.3.7 Ejemplos de ejecución

Alfaomega

296 296 296 296

Capítulo 10 242 242 244 251

8.6 Sistema de gestión de BDOO (SGBDOO) 8.6.1 Concepto de un SGBDOO 8.6.2 Objetivo 8.6.3 Características de los SGBDOO 8.6.4 Estructura de un SGBDOO

9.1. Introducción 9.1.1 Obteniendo el software e inicializando la instalación del Motor Oracle 10g XE 9.1.2. Descarga 9.1.3 Instalación

9.4 Contenido de la página Web de apoyo 9.4.1 Mapa conceptual del capítulo 9.4.2 Autoevaluación 9.4.3 Presentaciones

276 276 276 277 283 285 285 285 286 290 292 293 295

Implementando el modelo en IBM DB2

297

10.1 Introducción

298

10.2 Instalando e inicializando el servidor 10.2.1 Download 10.2.2 Instalación

298 298 298

10.3 Creando y probando nuestro modelo de Estudiante – Universidad 10.3.1 Creación de la base de datos 10.3.2 Creación de las tablas y sus relaciones 10.3.3 Modelo de datos 10.3.4 Datos de prueba

299 299 303 304 308

10.4 Contenido de la página Web de apoyo 10.4.1 Mapa conceptual del capítulo 10.4.2 Autoevaluación 10.4.3 Presentaciones

310 310 310 310

Capítulo 11 Implementando el modelo en SQL Server 2005

311

11.1 Introducción

312

11.2 Inicializando el servidor 11.2.1 Download 11.2.2 Instalación 11.2.3 Inicialización

312 312 312 316

11.3 Inicializando el cliente 11.3.1 Download 11.3.2 Instalación 11.3.3 Utilizando el SSMS

317 317 317 317

11.4 Creando y probando nuestro modelo de Estudiante–Universidad 11.4.1 Creación de la base de datos 11.4.2 Creación de las tablas y sus relaciones 11.4.3 Programación de la base de datos

318 319 320 327

11.5 Contenido de la página Web de apoyo 11.5.1 Mapa conceptual del capítulo 11.5.2 Autoevaluación 11.5.3 Presentaciones

334 334 334 334

Capítulo 12 Implementando el modelo en MySQL 5.1

335

12.1 Introducción

336

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

XVII

Contenido 12.2 Inicializando el servidor 12.2.1 Download 12.2.2 Instalación 12.2.3 Inicialización

336 336 337 341

12.3 Inicializando el cliente 12.3.1 Download 12.3.2 Instalación 12.3.3 Utilizando el MySQL Workbench

342 342 342 343

12.4 Creando y probando nuestro modelo de Estudiante–Universidad

343

12.4.1 Creación de una conexión al servidor 12.4.2 Creación de la base de datos, las tablas y sus relaciones

344 345

12.5 Contenido de la página Web de apoyo 12.5.1 Mapa conceptual del capítulo 12.5.2 Autoevaluación 12.5.3 Presentaciones

358 358 358 358

Bibliografía

359

Indice analítico

361

Información d e l contenido d e l a página W e b El material marcado con asterisco (*) solo está disponible para docentes.

Capítulo 1.

Capítulo 6.

Estructura y tipos de bases de datos

Almacén de datos

• Mapa conceptual

• Mapa conceptual

• Autoevaluación

• Autoevaluación

• Presentaciones*

• Presentaciones*

• Vínculos de interés

Capítulo 7.

Capítulo 2.

Minería de datos

Modelo de datos relacional

• Mapa conceptual

• Mapa conceptual

• Autoevaluación

• Autoevaluación

• Presentaciones*

• Presentaciones*

Capítulo 8.

Capítulo 3.

Bases de datos orientadas a objetos

SQL

• Mapa conceptual

• Mapa conceptual

• Autoevaluación

• Autoevaluación

• Presentaciones*

• Presentaciones*

Capítulo 9.

Capítulo 4.

Implementando el modelo en Oracle Express Edition XE

Lenguaje procedimental como extensión de SQL

• Mapa conceptual

• Mapa conceptual

• Autoevaluación

• Autoevaluación

• Presentaciones*

• Presentaciones*

Capítulo 1 0 .

Capítulo 5.

Implementando el modelo en IBM DB2

Bases de datos multidimensionales y tecnologías OLAP

• Mapa conceptual

• Mapa conceptual

• Autoevaluación

• Autoevaluación

• Presentaciones*

• Presentaciones*

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

XVIII

Bases d e Datos

Capítulo 1 1 .

Capítulo 1 2 .

Implementando el modelo en SQL Server 2005

Implementando el modelo en MySQL 5.1

• Mapa conceptual

• Mapa conceptual

• Autoevaluación

• Autoevaluación

• Presentaciones*

• Presentaciones*

• Lecturas complementarias • Código fuente de los ejemplos • Vínculos de interés Incluye hipervínculos a la descarga de las versiones gratuitas de MySQL 5.1, SQL Server 2005, Oracle Express Edition XE e IBM DB2. Registro e n l a W e b d e a p o y o Para tener a c c e s o al material de la página Web de apoyo del libro: 1. 2. 3.

Ir a la página http://virtual.alfaomega.com.mx Registrarse c o m o usuario del sitio y propietario del libro. Ingresar al apartado de inscripción de libros y registrar la siguiente clave de a c c e s o

4. Para navegar en la plataforma virtual de recursos del libro, usar los nombres de Usuario y Contraseña defnidos en el punto número dos. El acceso a estos recursos es limitado. Si quiere un número extra de accesos envíe un correo electrónico a [email protected] Estimado profesor: Si d e s e a acceder a los contenidos exclusivos para d o c e n t e s por favor c o n t a c t e al representante de la editorial q u e lo suele visitar o envíenos un correo electrónico a [email protected] Convenciones utilizadas en el t e x t o

•"

Conceptos para recordar: bajo este icono se encuentran definiciones importantes que refuerzan lo explicado en la página. Comentarios o información extra: este ícono ayuda a comprender mejor o ampliar el texto principal.

«f1 Alfaomega

Contenidos interactivos: indica la presencia de contenidos extra en la Web.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

XIX

Prólogo En los últimos 20 años, el manejo de Base de Datos y el conocimiento de los Motores de Base de Datos existentes en el mercado han tomado un protagonismo absoluto en el desarrollo de software. Si bien este tema siempre se analizó dentro del área informática, antes solo era considerado para el desarrollo de sistemas de mediana y gran envergadura, pero actualmente no se justifca la construcción de una página Web sin tener como respaldo una base de datos para manejar la persistencia de los datos, aunque sean mínimos. Por esta razón, el objetivo de este libro es introducir al lector en este tema mediante el concepto de composición de un Motor de Base de Datos, la forma de interactuar con él a través de los lenguajes asociados y los diferentes modelos de construcción lógica de datos. En el Capítulo 1, se desarrollan los conceptos generales de las bases de datos y los Sistemas de Gestión de las mismas. Además, analiza conceptos como la seguridad de las mismas, la administración de usuarios y las funciones y las responsabilidades de un DBA (por sus siglas en inglés, Data Base Administrator ). En el Capítulo 2, se especifcan los conceptos fundamentales del modelo relacional, trabajando el concepto de relaciones entre tablas, claves, integración, etcétera. En el Capítulo 3, se especifcan los comandos y la utilización del lenguaje de Consulta Estructurado (SQL), de forma tal que el lector conozca la forma de interactuar con un Sistema de Gestión de Base de Datos. El Capítulo 4 extiende lo tratado en el capítulo anterior, pero también agrega el concepto de los lenguajes procedimentales considerando una extensión de SQL (PL/SQL) para poder agregar objetos creados por el diseñador a una base de datos específca. En el Capítulo 5, se especifcan las diferencias implementadas por las bases de datos multidimensionales y las distintas variantes de modelado aplicadas por las tecnologías OLAP. Los Capítulos 6 y 7 establecen una aproximación a dos temas vinculados con las bases de datos como son el almacenamiento y la minería de datos. Si bien el objetivo del libro no es profundizar estos conceptos, se brinda una visión general de los mismos para conocimiento del lector. En el Capítulo 8, se desarrolla el concepto de objetos aplicado a la persistencia de los datos administradas por un Sistema de Gestión. Además, se tratan las extensiones de bases de datos consideradas orientadas a objetos y las Bases de datos objeto-relacionales. Por último, para poder trabajar sobre la práctica real, se desarrolló un modelo de datos que se implementa en Oracle Express Edition XE, IBM DB2, SQL Server 2005 y MySQL 5.1, en los Capítulos 9, 10, 11 y 12 respectivamente.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Estructura y tipos de bases de datos

Contenido

Objetivos

1.1 Introducción

2

1.2 Definición de base de datos

3

1.3 Sistema de Gestión de Bases de Datos

4

1.4 Usuarios de la base de datos

5

1.5 Seguridad de las bases de datos

7

1.6 Funciones y responsabilidades de un DBA

12

1.7 Arquitectura ANSI/SPARC

13

1.8 Modelos de datos

17

1.9 Resumen

23

1.10 Contenido de la página Web de apoyo

23

•

Conocer la teoría de bases de datos.

•

Identificar los modelos de datos anteriores y actuales para el almacenamiento persistente de grandes volúmenes de datos.

•

Distinguir los tipos de usuarios y las funciones de un administrador de bases de datos.

1 - Estructura y tipos de bases de datos

2

1.1 Introducción Entre 1960 y 1970, las computadoras tenían capacidades limitadas de procesamiento y de almacenamiento. Si bien las aplicaciones no eran tan exigentes como las actuales, había que trabajar demasiado para que se lograran los resultados esperados. Entre 1960 y 1970, las computadoras tenían capacidades limitadas de procesamiento y almacenamiento.

Los datos, que era necesario almacenar, se ubicaban en archivos por un orden físico, cuya determinación se efectuaba de acuerdo con su orden de ingreso o por otro orden previamente indicado. Esto generaba mucho trabajo, ya que algún símbolo separaba los campos que conformaban los registros que, luego, se debían detectar para saber dónde fnalizaba uno y empezaba el otro. La lectura secuencial de los archivos era muy común y se debían recorrer todos los registros para encontrar el deseado; esta situación acarreaba problemas en la velocidad de respuesta.

Los datos que era necesario almacenar se ubicaban en archivos por orden físico.

Muchas veces, los distintos sectores de una empresa contaban con sus propios datos para resolver los problemas de información que se presentaban. Como no había ni políticas ni reglas claras, tampoco había personal informático que centralizara este tipo de situaciones, entonces, se repetían los datos. Por esta razón, se necesitaba un esfuerzo mayor que el actual en la programación de aplicaciones para acceder a los datos, puesto que el almacenamiento se centraba en pocos tipos de datos, por ejemplo, numéricos y de texto. Esto limitaba las capacidades de respuesta a las necesidades de las empresas y exigía algoritmos de programación para un sinfín de situaciones, como el control y el almacenamiento de una determinada fecha. En la actualidad, todas las personas interactúan con datos que, de alguna manera, se almacenan en un medio físico y se asocian a un sistema informático que los registra y permite su acceso. Por ejemplo: si desde su casa o desde un teléfono móvil, una persona marca un número de teléfono, lo que se hace es utilizar los datos registrados dentro de una empresa telefónica, que reconoce el teléfono, el origen de la llamada y el número del receptor. Eso implica una serie de acciones que desencadenan controles y registros en una base de datos. Con respecto al control, se deduce que éste debe verifcar la existencia del número receptor o que, por ejemplo, no se encuentre ocupado; de lo contrario, es una llamada equivocada. Una vez establecida la comunicación, el sistema informático registrará mínimamente su número, el número destino, la hora de inicio y fnal de la llamada, al momento de dar por fnalizada la comunicación. Dichos registros son los que permiten obtener la facturación de los clientes y de todos los reportes que se soliciten. Lo mismo sucede cuando el cliente de un banco interactúa con el cajero automático para retirar dinero: el cliente debe ingresar su tarjeta, que se leerá para, luego, cruzar la identifcación de la tarjeta con la clave que el usuario ingresa. La base de datos mantiene los datos del cliente y sus cuentas asociadas, mientras que una aplicación informática hará controles y mostrará las opciones disponibles al usuario. En alguna sección de un sistema de gestión de alumnos de una universidad, el docente publica el programa de estudios de su materia, las fechas de los exámenes parciales y las notas de los estudiantes de su curso. También, publica los mensajes y los archivos para sus alumnos. El personal de la universidad que carga los resultados de

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.2 Defnición de base de datos

3

los exámenes indica las notas de los alumnos presentes y registra los ausentes. Otros usuarios acceden al sistema para cargar asistencias e inasistencias a clase de los alumnos. Por su parte, los alumnos ingresan con su legajo y su clave a la autogestión que presenta el sistema —por intranet o por Internet—, para ver la información de su estado académico, conformado por las materias que cursaron y las que cursarán, los resultados de sus exámenes —parciales y fnales—, la cantidad de faltas que poseen e, incluso, se pueden inscribir en los exámenes de las materias que ya regularizaron. Entonces, ¿qué es una base de datos? Algunos podrían pensar que son solo datos almacenados en una computadora como, por ejemplo, una planilla de cálculos. Sin embargo, es mucho más que eso.

1.2 Defnición de base de datos Cuando una empresa decide la implementación de un sistema informático, para cubrir necesidades de información específcas, el equipo de análisis y diseño inicia el proceso de desarrollo del software, basándose en las especifcaciones con las que trabaja el cliente que solicita el sistema para, de esta manera, responder a las necesidades de la empresa. Durante este proceso, se defnen los archivos, como el de “Estudiantes”, para almacenar los datos de todos los alumnos de la universidad; el de los “Profesores”, para almacenar los datos de contacto necesarios; el de las “Carreras” que propone la universidad; y el de las materias que conforman cada plan de estudios vigente, o no, de cada carrera, etcétera. Pero esos archivos nunca quedan aislados de otros datos; es decir: mantienen relaciones que, normalmente, son transparentes para los usuarios y que permiten su aprovechamiento para obtener información, a través de aplicaciones programadas para tales fnes. Por ejemplo, es necesario tener algún archivo que mantenga los datos de la inscripción de cada alumno —en las carreras y en las materias que se cursarán—: esto permitirá que se refejen los datos de resultados de los exámenes parciales, las asistencias, etcétera. Por lo que hasta aquí se expresó, se puede ensayar una primera defnición: “una base de datos es un conjunto de datos estructurados y defnidos a través de un proceso específco, que busca evitar la redundancia, y que se almacenará en algún medio de almacenamiento masivo, como un disco”. Cuando se hace referencia al término ‘redundancia’, se alude a la repetición que puede producirse en el momento de defnir los almacenamientos de datos. Es incorrecta la pretensión de que los datos —como el apellido y la dirección— se encuentren defnidos, a la vez, en los almacenamientos de estudiantes y en los relacionados con los exámenes fnales. Un cambio en la dirección de un alumno podría signifcar que en uno de los dos almacenamientos no se realice la modifcación y que provoque inconvenientes a la hora de devolver la información de un alumno.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

s Una base de datos es un conjunto de datos estructurados y defnidos a través de un proceso específco, que busca evitar la redundancia, y que se almacenará en algún medio de almacenamiento masivo, como un disco.

Alfaomega

1 - Estructura y tipos de bases de datos

4

1.3 Sistema de Gestión de Bases de Datos Cuando el alumno desea información de las notas que obtuvo durante el último año cursado, y que está almacenada en una base de datos, no accede directamente a ellos. Cada alumno de la universidad utiliza aplicaciones que ya han sido desarrolladas para fnes específcos, como, por ejemplo, la obtención de un reporte de notas. Al SGBD se lo puede pensar como una capa de software que controla todos los accesos a la base de datos.

Por su parte, las aplicaciones que usa interactúan con un conjunto de programas aglutinados en lo que se denomina “el Sistema de Gestión de Bases de Datos (SGBD)”, “Database Management System” (DBMS) e, incluso, “Motor de Base de Datos”. A este Motor de Base de Datos, se lo puede pensar —de manera simplifcada— como una capa de software que controla todos los accesos a la base de datos. Cabe aclarar, que un DBMS, no se crea para una situación específca de una empresa, sino que se desempeñará tanto para fnes de un sistema de gestión de alumnos como para un sistema bancario, una empresa telefónica, comercial, etcétera. El DBMS puede implementar instrucciones dadas por los distintos usuarios, que se describen en las próximas páginas, y que tienen distintos efectos en una base de datos. Las instrucciones se agrupan mínimamente en: DDL (Lenguaje de Defnición de Datos) y DML (Lenguaje de Manipulación de Datos), aunque también suele reconocerse al DCL (Lenguaje de Control de Datos). A manera introductoria, se indican algunas instrucciones que conforman estos grupos: DDL: es el conjunto de órdenes que permiten defnir la estructura de una base de datos. Por ejemplo, para crear la base de datos en una empresa se utiliza una orden de este tipo, acompañada de los parámetros necesarios e indicados en cada DBMS. Lo mismo sucede si se desea modifcar la estructura de un objeto de la base de datos, como por ejemplo cuando en un archivo de CLIENTES se desea agregar un dato nuevo no considerado al ser creada la estructura. Además incluye una instrucción para eliminar objetos obsoletos en la base de datos. No son instrucciones a incluir en las aplicaciones. DML: las instrucciones que conforman este grupo son las que están incluidas en las aplicaciones y se usan para alterar el contenido de un archivo de datos. Por ejemplo, cuando se desea insertar un nuevo cliente o producto, modifcar la dirección de un cliente o el precio de un producto, o eliminar un producto que fue cargado por error. Nótese la diferencia respecto al DDL que actuaba sobre la estructura para almacenar, mientras que estas órdenes afectan al contenido de los archivos de datos. DCL: son órdenes que se utilizan para implementar seguridad en la base de datos, como por ejemplo indicar que privilegios –insertar, modifcar, etc.– tiene cada usuario respecto a los distintos objetos de la base de datos. Incluso pueden ser retirados privilegios a usuarios existentes.

Fig. 1.1 Representación gráfca de una base de datos. Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.4 Usuarios de la base de datos

5

Si bien las aplicaciones poseen controles de seguridad, al solicitar un nombre de usuario y contraseña cuando el usuario ingresa al sistema, siempre hay una segunda instancia de seguridad defnida por personal que implementa la base de datos, donde se defnen al DBMS perfles de usuarios y privilegios que posee respecto a los datos, por ejemplo si un usuario Carlos puede o no agregar nuevos datos, o modifcar datos almacenados en la base de datos. Teniendo en cuenta lo expresado, ahora podemos pensar en una defnición que amplíe el concepto de bases de datos enunciado en el punto 1.2. Para ello, se utilizará una cita —muy utilizada por otros autores— que abarca las nociones hasta aquí enunciadas. James Martin en su obra de 1975 Computer Data-base Organization defne base de datos como: “Colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su fnalidad es servir a una aplicación o más, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean métodos bien determinados para incluir nuevos datos y para modifcar o extraer los datos almacenados”. Esta defnición incluye el concepto de independencia de datos, que signifca que las aplicaciones deben ser independientes de las modifcaciones que pudieran sufrir los datos, en lo lógico y en lo físico. Sería deseable que esto se lograra en las bases de datos, aunque, en algunas situaciones, resulte más o menos complejo. Es decir que si, por ejemplo, en el almacenamiento “Estudiantes” de la base de datos se agrega un dato —como la cuenta de correo electrónico o el número de teléfono móvil—, no implica que en los programas que usan el almacenamiento se deba hacer cambios. Eso es lo que se denomina independencia lógica. En otras épocas, las aplicaciones incluían la defnición de la estructura de datos y había una sección en la que fguraban todos los datos que poseía cada uno de los archivos de datos, a los que se accedía por dicho programa. Esto signifcaba que, ante un cambio en la estructura, el agregado de un nuevo dato o la alteración de la dimensión de un dato existente, las aplicaciones —que podían ser muchas— debían refejar el cambio en la sección correspondiente.

Independencia de datos signifca que las aplicaciones deben ser independientes de las modifcaciones que pudieran sufrir los datos, en lo lógico y en lo físico.

En cuanto a la independencia física, el almacenamiento “Estudiantes” puede defnirse por la indexación, que es el acceso rápido por el legajo del estudiante. Si esta forma de acceso se cambiara para mejorar la performance del sistema, no debería determinar un cambio en las aplicaciones y, si se decidiera la utilización de otro almacenamiento físico para la base de datos, tampoco se deberían generar cambios en las mencionadas aplicaciones.

1.4 Usuarios de la base de datos

Christopher J. Date. Investigador principal del modelo relacional de bases de datos de Edgar Codd.

Hay diversas clasifcaciones de los usuarios que actúan en un entorno de bases de datos, como las planteadas por grandes autores como C.J. Date en Sistemas de Bases de Datos, Korth en Fundamentos de Bases de Datos y Ramez Elmasri y Shamkant Navathe en Sistemas de Bases de Datos: conceptos fundamentales. Se estudiarán distintos momentos de un sistema con bases de datos y se irán detectando los perfles que, actualmente, se repiten en las empresas, a los que les asignaremos una denominación y, de esta manera, quedarán clasifcados. Cuando se desea informatizar un nuevo sistema de información, es imprescindible que participe un equipo de análisis y diseño de sistemas, conformado por ingenieros Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

En la Web de apoyo, encontrará el vínculo a la página Web personal de Shamkant B. Navathe.

Alfaomega

1 - Estructura y tipos de bases de datos

6

y analistas de sistemas. Este equipo es el que toma los requerimientos del cliente mediante entrevistas, cuestionarios, etc., y plasma —en diagramas y descripciones— la interpretación de ese relevamiento. Luego entrará en un intenso proceso ingenieril, que incluirá el análisis, la creación y el diseño. El equipo planteará una propuesta al cliente —con los alcances y los límites bien determinados— para que la revise y mejore. Si se acepta la propuesta, se mejorará el nivel de detalle del diseño, se intercambiarán opiniones con los usuarios futuros con respecto a las interfaces y los reportes del sistema, para estipular cuáles serán las entidades que participarán en el desarrollo de las aplicaciones, cuáles serán las estructuras de cada una, quiénes serán los usuarios y sus respectivos roles, etcétera.

Usuarios de la base de datos: 1. Administrador de la base de datos. 2. Programador de aplicaciones.

3.

Usuarios fnal.

Alfaomega

De esta manera, se resume un proceso muy importante, que llevará días o meses de trabajo, según la complejidad del sistema; pero la intención es indicar que este equipo no interactúa necesariamente con el sistema en producción, sino que lo hace en la etapa previa a la construcción. Por esta razón, no se lo considera usuario del sistema. Después de reconocer las entidades y relaciones entre ellas, se pueden detectar usuarios que interactúan con la base de datos de distinta manera y con distintos objetivos. La clasifcación que se propone a continuación no es la única que suele expresarse, muchos autores indican otras con diferentes roles en la relación del usuario con la base de datos. •

Administrador de la base de datos: comúnmente es el profesional–ingeniero o analista— con perfl técnico que, en el ambiente informático, se denomina DBA (Data Base Administrator). Este profesional, muy importante para la empresa, recibe las especifcaciones del Equipo de Análisis y Diseño para su implementación en un Sistema de Gestión de Base de Datos, como por ejemplo, Oracle, SQL Server, DB2, etcétera. El DBA tiene múltiples funciones y responsabilidades que se detallarán más adelante.

•

Programador de aplicaciones: conoce los casos que se desarrollarán —escritos e identifcados por el Equipo de Análisis y Diseño—, los prototipos de interfaces y las estructuras de los almacenamientos que se manipularán. El programador genera las aplicaciones necesarias en el sistema —con el lenguaje de programación que se le indica y conoce—, para la obtención de las entradas de datos que alimentarán la base de datos y, también, para lograr las salidas —como las pantallas de resultados o reportes—, que se plantearon en la propuesta de solución. Es conveniente aclarar que no hace falta que este usuario conozca toda la estructura de la base de datos, sino solo lo que necesita para programar. Normalmente, el programador de aplicaciones trabaja en un equipo de desarrollo, cuyo tamaño dependerá de la envergadura del sistema.

•

Usuario fnal: es el personal que interactúa con las aplicaciones programadas por el usuario mencionado en el párrafo precedente y es, de entre todos los usuarios, el que menos conocimiento técnico posee. Si bien hay perfles distintos entre los usuarios fnales que interactúan con el sistema, esta persona no conoce ni los detalles técnicos ni los de la base de datos. Por ejemplo: un alumno que accede a su autogestión vía Internet para conocer su estado académico no necesita conocer la estructura del sistema, solo utiliza las opciones que se le presentan en el menú, que están asociadas con un perfl defnido

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.5 Seguridad de las bases de datos

7

para todos los alumnos. Otro usuario fnal del Sistema de Gestión de Alumnos es el profesor de un curso, quien verá las opciones defnidas para ese perfl, con la posibilidad de cargar las notas de los parciales, enviar mensajes a todo el curso o imprimir la lista de sus alumnos. Durante la vida del sistema, seguramente, se presentarán requerimientos que cambiarán y otros que no fueron considerados cuando se diseñó el sistema. En este último caso, es lógico que determinados usuarios no tengan los programas que necesitan. Por ejemplo, es muy común que el personal directivo especifque una necesidad como, por ejemplo, “Obtener los datos de los alumnos que cursan el último año de la carrera, trabajan, tienen promedio superior a 9 (nueve) y que no han rendido materias en los últimos dos turnos de examen”. Este tipo de solicitud no programada suele dar lugar a que ciertos usuarios tengan permisos para acceder a la base de datos mediante consultas que ellos mismos arman en pantalla, en las que indican los almacenamientos que usarán, las condiciones que cumplirán, los datos que mostrarán y los cálculos que realizarán. Si esta solicitud se repitiera en el tiempo, se la podría incluir como una opción del sistema.

1.5 Seguridad de las bases de datos La seguridad en la base de datos es un tema muy importante. En la mayoría de las organizaciones, es un conjunto de funciones manejadas por el Administrador de la Base de datos (o DBA) o, más apropiadamente, por un administrador de seguridad. Este rol es responsable de la creación de los nuevos usuarios y de la accesibilidad de los objetos de la base de datos. Como regla general, cuanto más grande es la organización, más sensible es la información y más probable es que la seguridad sea manejada por un Administrador de seguridad. Sin embargo, es importante que los desarrolladores, los DBA y los usuarios entiendan las opciones disponibles en el modelo de seguridad.

La seguridad en la base de datos es un conjunto de funciones manejadas por el DBA. Este rol es responsable de la creación de los nuevos usuarios y de la accesibilidad de los objetos de la base de datos.

La base de datos más segura es aquella que no tiene usuarios, pero esta situación carece de sentido. Por esta razón, se debe llegar a un balance entre el permiso de acceso a los usuarios y el control de lo que se les permite hacer cuando establecen una sesión a través de una conexión. Para ello, existe en cada base de datos un modelo de seguridad. Por razones de síntesis, nos dedicaremos a estudiar el que ofrece la base de datos Oracle. Se recomienda visitar la página de documentación ofcial de la empresa en: http://www.oracle.com/technetwork/database/focus-areas/security/index.html En Oracle, el modelo de seguridad se basa en los siguientes elementos: •

Privilegios de sistema.

•

Uso de roles para administrar el acceso a los datos.

•

Privilegios de objeto.

•

Contraseñas modifcables.

•

Otorgar y revocar los privilegios de objetos y de sistema.

•

Uso de sinónimos para la transparencia de base de datos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 - Estructura y tipos de bases de datos

8

El modelo de seguridad Oracle consiste en dos partes: 1.

Autenticación de contraseñas, que puede basarse en el Sistema Operativo que aloja al motor o usar el propio sistema de autenticación de la base. Cuando la última opción es la elegida por el DBA, la información de contraseñas se almacena en un formato encriptado en el diccionario de la base de datos.

2.

Control de qué objeto de la base de datos se puede acceder y por cuál grupo de usuarios. Esta autoridad ser transmite a través de los privilegios que se le asignan a los usuarios directamente o por medio de roles a grupos de usuarios.

1.5.1 Creación de usuarios El inicio del proceso —que es el que permite el acceso a la base de datos— es la creación de usuarios con el comando SQL: CREATE USER IDENTIFIED BY Usualmente se completa con algunas cláusulas de almacenamiento y opciones de usos de la base de datos, pero que no se relacionan con el tema que trataremos aquí.

1.5.2 Otorgar privilegios de sistema Los privilegios de sistema permiten al usuario que los recibe la creación, modifcación y eliminación de los objetos de la base de datos que almacenan los datos de las aplicaciones. Los privilegios de sistema permiten al usuario que los recibe la creación, modif cación y eliminación de los objetos de las bases de datos que almacenan los datos de las aplicaciones.

De hecho, para poder realizar alguna operación en la base de datos, el usuario necesita un privilegio de sistema para ingresar, denominado CREATE SESSION. Dentro del alcance de los privilegios de sistema hay dos categorías: •

La primera de ellas es el conjunto de privilegios de sistema que se relacionan con el manejo de los objetos como tablas, índices, disparadores o triggers, secuencias, vistas, paquete, procedimientos y funciones almacenadas. Con estos privilegios se pueden realizar las siguientes acciones: crear, alterar su defnición y eliminarlos en general y, para las tablas y programas, tenemos los privilegios de creación de índices, hacer referencia a la clave primaria con una clave foránea y ejecutar un programa almacenado.

•

La segunda categoría de los privilegios se refere a la habilidad de un usuario para realizar actividades especiales a lo largo del sistema. Estas actividades incluyen funciones como: actividades de auditoría, generación de estadísticas para soportar el funcionamiento del optimizador basado en costos y permitir el acceso a la base de datos solamente a los usuarios con un privilegio de sistemas especial denominado “sesión restringida” o restricted session. Estos privilegios usualmente se deberían otorgar solo a los usuarios que realizarán tareas de administración de alto nivel.

El otorgamiento de los privilegios de sistemas se ejecuta con la sentencia GRANT y, para otorgar un privilegio de sistema a otro usuario, el que lo transmite (GRANTOR) debe haber recibido el mismo privilegio con el agregado WITH ADMIN OPTION, para poder retransmitirlo a otros usuarios.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.5 Seguridad de las bases de datos

9

Los usuarios pueden crear objetos dentro de su esquema y si fuera necesario que un usuario deba crear objetos para cualquier otro esquema, deberá recibir el privilegio con la palabra ANY como en el siguiente ejemplo: GRANT CREATE ANY TABLE TO miusuario La anulación de un privilegio otorgado se realiza con la sentencia REVOKE. Si un usuario recibió un privilegio de sistema y lo ha transmitido con la opción WITH ADMIN OPTION, el hecho de perderlo no afectará a los usuarios que lo recibieron. Por ejemplo: el usuario PEPE recibió el privilegio CREATE ANY TABLE WITH ADMIN OPTION realizó su trabajo creando cinco tablas y le pasó el mismo privilegio a dos usuarios más, a uno con la opción WITH ADMIN y a otro sin ella. Si otro usuario le revoca este privilegio al usuario PEPE, esta acción no tiene efecto sobre las tablas ni sobre los dos usuarios, ya que no pierden su privilegio de creación de tablas en cualquier esquema.

1.5.3 Usar roles para administrar los accesos de base de datos Cuando la cantidad de objetos y usuarios va creciendo, la administración de accesos y privilegios se torna complicada y trabajosa, porque se van agregando aplicaciones que traen entre cientos y miles de objetos y se incorporan nuevos usuarios o los que están adquieren nuevos privilegios de acceso sobre estos objetos en forma acorde con la operativa. La forma de simplifcar elegida por los Sistemas de Gestión de Base de Datos ha sido la creación de una capa de abstracción llamada ROL, que agrupa los privilegios y, generalmente, defne un nombre de rol que describe un tipo de tarea o función. Además de simbolizar un tipo de tarea o actividad general, con el ROL se establece la idealización de un usuario que necesita un grupo de privilegios para un cierto trabajo, como ESTUDIANTE, PROFESOR, VENDEDOR, OPERADOR, DATAENTRY, SUPERVISOR, OPERADOR_BATCH, OPERADOR_BACKUP. Así, todos los accesos a los objetos se pueden agrupar en estos roles de base de datos para ser administrados y otorgados entre los usuarios y entre otros ROLES, ya que es posible asignar ROLES a otros ROLES.

La forma de simplifcar elegida por los Sistemas de Gestión de Bases de Datos ha sido la creación de una capa de abstracción llamada ROL.

Para usar ROLES es necesario realizar dos tareas: 1.

Agrupar lógicamente los privilegios, como los de creación de tablas, índices y procedimientos. También se puede defnir una contraseña para un ROL para, de esta manera, proteger el acceso a los privilegios con la cláusula idéntica a la creación de usuarios. Veamos el ejemplo: CREATE ROLE creador_procs IDENTIFIED BY soycreador GRANT create any procedure TO creador_procs WITH ADMIN OPTION

2.

La segunda tarea que se debe completar es agrupar a los usuarios de cada aplicación que manejan necesidades similares. El modo más efectivo es la identifcación de los distintos tipos de usuarios que usarán la base de datos. Se determinan las actividades que cada tipo de usuarios realizará y se listan los privilegios que serán necesarios para llevar a cabo esta tarea. Luego, se creará un ROL por cada actividad y se otorgará con GRANT los privilegios al ROL defnido.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Para usar ROLES es necesario realizar dos tareas: 1. Agrupar lógicamente los privilegios. 2. Agrupar a los usuarios de cada aplicación que manejan necesidades similares.

Alfaomega

10

1 - Estructura y tipos de bases de datos

Esta forma de hacer niveles de ROLES como capas intermedias, para distribuir privilegios establecidos, facilita la administración, puesto que bastará con determinar el tipo de usuario que corresponde o la clase de tarea que se le habilitará para encontrar uno o dos ROLES. De esta manera, el usuario recibirá todos los privilegios necesarios. En el ejemplo, ilustramos esta secuencia de tareas: CREATE ROLE desarrollador GRANT CREATE TABLE TO desarrollador GRANT SELECT ANY TABLE TO desarrollador GRANT DROP USER TO desarrollador GRANT desarrollador TO juan GRANT desarrollador TO pedro Los roles se pueden modifcar para que soporten el requerimiento de contraseña usando la siguiente sentencias: ALTER ROLE desarrollador IDENTIFIED BY abrepuertas Los roles se eliminan con la ejecución de la sentencia DROP ROLE. Esta acción requiere que el administrador tenga los siguientes privilegios: CREATE ANY ROLE, ALTER ANY ROLE y DROP ANY ROLE, o que sea dueño del ROL. Los roles se pueden otorgar a otros roles con GRANT y se quitan de los usuarios o roles con REVOKE. El hecho de que un ROL tenga contraseña, nos hace preguntar en qué momento y cómo se activa para ejercer los privilegios asociados. Al inicio de la sesión, se activan los roles fjados como default para el usuario. Normalmente, el estado de un ROL es ENABLED o activado, a menos que haya sido expresamente desactivado. Estas acciones se realizan con las siguientes sentencias: ALTER USER juan DEFAULT ROLE ALL (Activa todos los roles asignados a juan) ALTER USER juan DEFAULT ROLE ALL EXCEPT sysdba ALTER USER juan DEFAULT ROLE desarrollador, operador_backup ALTER USER juan DEFAULT ROLE NONE (ningún ROL queda activado al iniciar la sesión)

1.5.4 Otorgar privilegios de objetos Los privilegios de objetos se agrupan en dos grupos: los que permiten ver, agregar, modifcar e insertar flas y los de objetos que dejan eliminar otros objetos o usarlos como el privilegio REFERENCE y EXECUTE.

Alfaomega

Una vez que se ha creado, un objeto puede ser administrado por su creador o por el usuario que tenga el privilegio GRANT ANY PRIVILEGE. La administración consiste en otorgar los privilegios sobre el objeto que permitirán manipularlo: agregando flas, cambiando su estructura o viendo los datos de sus columnas. Los privilegios de objetos se agrupan en dos grupos: los que permiten ver, agregar, modifcar e insertar flas y los de objetos que dejan eliminar otros objetos o usarlos como el privilegio REFERENCE y EXECUTE, que permiten crear claves foráneas en una tabla que referencia a una clave primaria de otra tabla sobre la que se ha dado este privilegio de referencia. El privilegio EXECUTE otorga a un usuario la facultad de

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.5 Seguridad de las bases de datos

11

ejecutar una función, procedimiento o paquete almacenado. Otros privilegios administran la modifcación y creación de objetos de base de datos, como ALTER TABLE, ALTER SEQUENCE y el privilegio que permite crear un índice sobre una tabla de otro usuario es INDEX TABLE. Estos privilegios de objetos pertenecen al usuario que los creó o que los posea con ANY. Se otorgan también con una opción que facilita su transmisión a otros usuarios, como es el parámetro WITH GRANT OPTION. A diferencia de los privilegios de sistemas, un privilegio de objeto otorgado por un usuario que lo recibió con el parámetro WITH GRANT OPTION se revocará automáticamente si a este usuario GRANTOR se le anulara este privilegio. Es decir: hay un efecto cascada en el REVOKE para los privilegios de objeto que no ocurre con los privilegios de sistema.

1.5.5 El cambio de contraseñas Una vez creado, el usuario puede cambiar su contraseña con la sentencia: ALTER USER juan IDENTIFIED BY abretesesamo

1.5.6 Uso de sinónimos para la transparencia de base de datos Los objetos de base de datos son de los usuarios que los crean y solo estarán disponibles para él, a menos que se otorguen explícitamente privilegios a otros usuarios o roles. Sin embargo, y pese a que otro usuario tenga privilegios para usar estos objetos de otro esquema, al hacer uso de ellos debe respetar los límites del esquema; esto es: debe llamar al objeto con su denominación completa en la base, es decir, el nombre del esquema precederá al nombre del objeto. Por ejemplo: si Juan desea usar la tabla clientes del esquema Pedro, usará el nombre del esquema como prefjo del nombre de la tabla. Si Juan ya tiene permiso sobre la tabla “Materias” de Pedro, incluirá el nombre del esquema de esta manera: SELECT * FROM pedro.materias Sin la información del nombre del esquema al que pertenece el objeto, el motor de la base de datos no entenderá de qué tabla Materias se trata. Este requisito de anteponer el esquema produce la pérdida de transparencia que debe resolverse usando “sinónimos”, ya que permite a Juan ver la tabla Clientes sin necesidad de anteponer explícitamente el nombre del esquema. Hay dos tipos de sinónimos: •

Privados: tienen una aplicación más limitada.

•

Públicos: se usan para poner a disposición de los objetos a todos los usuarios sin el requisito de califcarlos con el formato “esquema.nombre_del_objeto”.

Si se realiza la siguiente operación: CREATE PUBLIC SYNONYM materias FOR pedro. materias

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

El requisito de anteponer el esquema produce la pérdida de transparencia que debe resolverse usando “sinónimos”.

Alfaomega

12

1 - Estructura y tipos de bases de datos

Ahora Juan (y cualquier otro usuario) podrá referirse a la tabla Materias de Pedro solamente con el sinónimo del objeto, sin prefjo del esquema. SELECT * FROM materias Los privilegios privados se crean con el mismo fn, pero tienen alcance limitado para cada usuario en particular, como: CREATE SYNONYM materias FOR pedro. materias Ahora solamente Juan podrá hacer esto con la tabla de Pedro: SELECT * FROM materias Con estos componentes del modelo de seguridad de la base de datos, el usuario podrá entender la mayoría de los modelos de otras bases, ya que implementan esencialmente las mismas características, pero deben observarse las diferencias que pudieran existir en cada implementación.

1.6 Funciones y responsabilidades de un DBA

El DBA indica cuáles son los datos de cada entidad, los tipos de datos, la dimensión de cada dato, las relaciones entre ellos, sus claves identifcadas, las vistas para los usuarios fnales, etc.

Como se afrmó en los párrafos precedentes, el DBA tiene múltiples funciones técnicas y responsabilidades con el sistema. En algunas organizaciones, suele trabajar solo, pero es muy común que necesite personal a su cargo para realizar tareas operacionales y para cubrir la alta demanda de tiempo; por ejemplo, para atender los requerimientos de empresas con servicios internacionales y con uso del sistema en 7días x 24horas, es decir, todas las horas de todos los días de la semana del año, como en el caso de un sistema de vuelos internacionales. Entre sus funciones principales se pueden mencionar:

Alfaomega

•

Especifcación lógica de la base de datos: el DBA especifca —mediante la interfaz del DBMS elegido o las sentencias de defnición de datos— la estructura de la base de datos que recibió del Equipo de Análisis y Diseño. Indica cuáles son los datos de cada entidad, los tipos de datos, la dimensión de cada dato, las relaciones entre ellos, sus claves identifcadas, las vistas para los usuarios fnales, etcétera. Las sentencias que utiliza el DBA se agrupan en lo que se denomina Lenguaje de Defnición de Datos (DDL) y está formada por las instrucciones para trabajar en la estructura y, también, para crear objetos, para modifcar las estructuras de los objetos o para eliminar los que ya no se necesiten en la base de datos.

•

Especifcación física: el DBA defne el medio físico que almacenará a la base de datos; por ejemplo, el disco y su partición en el servidor y, también, cómo se almacenarán los archivos de datos y cómo se accederá a ellos para lograr una mejor performance.

•

Defnición de seguridad: defne grupos de usuarios y usuarios individuales, con los perfles para cada uno, e indica los archivos a los que pueden acceder y los derechos que poseen de manera individual. Por ejemplo: el perfl “Estudiante” permite el derecho de consultar los archivos que contienen los datos de sus Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.7 Arquitectura ANSI/SPARC

13

evaluaciones; de consultar y enviar mensajes a los docentes; de modifcar su contraseña. Sin embargo, no tendrá la posibilidad de ver los datos personales de sus docentes o el derecho a modifcar las notas de sus evaluaciones. •

Defnir procedimiento de respaldo: es responsabilidad del DBA asegurar que los datos estén respaldados para evitar inconvenientes ante algún tipo de incidente (rotura de medio físico, errores de procedimientos en actualizaciones, robo de hardware, incendio, etc.). Por lo tanto, deberá defnir la periodicidad de los respaldos, el o los medios para mantenerlos (back-up); si copiará todo el contenido de la base de datos cada vez que inicie el respaldo, o si será parcial, etcétera. Esto no signifca que el DBA será el que realice este trabajo, sino que es el que defne el procedimiento que ejecutará el personal de soporte en la empresa. Del mismo modo, designará a los encargados del procedimiento para la recuperación de datos.

•

Implementar reglas de integridad: el Equipo de Análisis y Diseño especifca ciertas limitaciones a los datos que se almacenarán, determinados por el mundo real de la organización o por reglas lógicas propias de las bases de datos. Por ejemplo: en determinados países, la nota que un estudiante puede obtener está entre el valor 0 (cero) y el 10 (diez), lo que implica que el dato “Nota” nunca estará fuera de esos límites. Otro ejemplo de integridad se observa en un archivo de “exámenes”, en el cual al estudiante que se registra, debe ser alumno regular de la universidad y, la materia que rinda, parte integrante del plan de estudios de la carrera que cursa. Si se analiza un sistema bancario, también tiene las restricciones propias del negocio al igual que una empresa de telefonía. Estas reglas se defnen durante el proceso de creación de las bases de datos y de los archivos que la conforman; incluso, se pueden agregar algunas nuevas que surjan durante el uso del sistema y mientras los datos lo permitan, ya que algunos, seguramente, existen.

•

Monitorear la performance de la base de datos: el DBA debe monitorear el rendimiento de la base de datos, detectando los procesos que generen demoras en la devolución de información, para mejorar, permanentemente, su performance general. En algunos casos, el resultado es que los desarrolladores deben revisar las aplicaciones o la arquitectura del sistema; en otras situaciones, se pueden mejorar los métodos de acceso; incluso, la ubicación de los archivos de datos o las capacidades del hardware o de la conectividad que infuyen en el rendimiento. El DBA resuelve determinadas situaciones pero, en otras, solo se informará a quienes tienen el poder de decisión, para que encuentren las soluciones posibles.

1.7 Arquitectura ANSI/SPARC Como las funciones de los distintos usuarios mencionados de una base de datos son distintas, lo que implica que cada uno puede interactuar de diversas formas con los datos almacenados, surge la Arquitectura ANSI/SPARC para estandarizar los conceptos y permitir una mejor lectura de la independencia de datos, lo que permitirá que se ubique a cada usuario de una base de datos en función de su relación con ella, ya que no todos poseen la misma visión, aunque los datos almacenados son únicos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

14

S ANSI es el instituto que "supervisa la creación, promulgación y el uso de miles de normas y directrices que impactan directamente en casi todos los sectores de las empresas: desde dispositivos acústicos hasta los equipos de construcción, desde la producción lechera y ganadera hasta la distribución de energía, y muchos más".

1 - Estructura y tipos de bases de datos

ANSI (American National Standards Institute) tuvo mucha infuencia en la defnición de esta arquitectura. Fundado el 19 de octubre de 1918, se autodefne, en su página Web (www.ansi.org), como el instituto que “supervisa la creación, promulgación y el uso de miles de normas y directrices que impactan directamente en casi todos los sectores de las empresas: desde dispositivos acústicos hasta los equipos de construcción, desde la producción lechera y ganadera hasta la distribución de energía, y muchos más”. La arquitectura, que se presentará en tres niveles, tiene su antecedente en 1971, cuando CODASYL (Conference on Data Systems Languages). Además, este comité, formado por personas de industrias informáticas, tiene el objetivo de regular el desarrollo de un lenguaje de programación estándar, de donde surge el lenguaje COBOL, reconoce la necesidad de una arquitectura en dos niveles: un esquema —vista de sistema— y un subesquema —vista de usuario. Posteriormente, ANSI se dedica al tema, como lo dice en el libro Databases, role and structure: an advanced course, escrito por P. M. Stocker, P. M. D. Gray y M. P. Atkinson, en el cual indica que cuenta con un comité denominado X3, que se dedica a la computación y al procesamiento de información. El SPARC (Standards Planning and Requirements Committee) de ANSI/X3 fja un grupo de estudio de DBMS para especifcar los modelos para la estandarización de las bases de datos. En 1972, este comité produce un reporte provisional, seguido por otro fnal, en 1977, el cual divide la vista de sistema —destacada por CODASYL— en vista de empresa y de almacenamiento, que es lo que actualmente se conoce como: •

Nivel externo: lo conforman las múltiples vistas de los datos almacenados en la base de datos y se presentan a los distintos usuarios de múltiples formas, adecuándolas a las necesidades de información que tiene cada uno. A este nivel también se lo denomina nivel de visión, que se defne con el lenguaje de manipulación de datos.

•

Nivel conceptual: es la estructura lógica global, que representa las estructuras de datos y sus relaciones. Hay una única vista en este nivel y se la defne con el lenguaje de defnición de datos.

•

Nivel interno: se defne como el conjunto de datos que están almacenados físicamente y, como no se accede a ellos, también se lo denomina nivel físico.

Vista: usuario 1

Vista: usuario 2

Vista: usuario n

Nivel externo

Nivel

Nivel físico

Base de datos (física)

Fig. 1.2 Niveles de la base de datos. A continuación, se verá la relación de los usuarios con los niveles de abstracción expresados en la Fig. 1.2. Los usuarios fnales y los programadores de aplicaciones no

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.7 Arquitectura ANSI/SPARC

15

necesitan conocer cómo están almacenados los datos físicamente, porque tienen una visión alejada del nivel físico y personalizada para cubrir las necesidades de cada uno. Por ejemplo, un cajero de una entidad bancaria no precisa los mismos datos que un gerente, ni un estudiante universitario las opciones que usa un profesor de la universidad. Un reporte presentado a un gerente, puede ser el resultado de un largo proceso en el cual se combinaron los datos provenientes de distintos archivos y se aplicaron múltiples cálculos. Es lo que necesita, ya que no conoce ni le interesan estos detalles técnicos. Otro usuario, el DBA, está en condiciones y es el único que debería conocer el nivel físico, para modifcarlo si hiciera falta. Por ejemplo: podría cambiar el medio de almacenamiento de la base de datos o la forma de acceso a los archivos, manteniendo siempre inalterables las vistas para los demás usuarios. Solo el DBA puede introducir cambios en el nivel conceptual, pero sí es necesario que mantenga las vistas inalteradas hacia los usuarios fnales y los programadores de aplicaciones. Por ejemplo: agregar una columna a un archivo de datos cuando éste no se lo tuvo en cuenta inicialmente en el sistema o agregar un archivo de datos con las relaciones que corresponda a los ya existentes. Un archivo de datos de “Productos” y otro de “Proveedores”, de una base de datos de una empresa que vende insumos y artículos informáticos, podrían tener este aspecto:

Ejemplo:

Tabla Productos CodProd

DesProd

PrecioVta

CodProv

Stock

StMin

108

IMP. MULTIF. TX410

699,80

19

2

6

230

MON. 19 PULG. LCD W1943C

925,50

32

12

10

110

IMP. MULTIF. C5580-CH.TIN.

769

21

3

6

…

…

…

…

…

…

Tabla Proveedores CodProv

RazónSocial

Contacto

Teléfono

21

HP Center

…

…

19

Moura EPSON

…

…

32

Asoc. LG

…

…

…

…

…

…

Los archivos de la base de datos se almacenan de una única manera que, en defnitiva, es un conjunto de bytes que no son visibles para ningún tipo de usuario y que se administra a través del sistema operativo.

Físicamente, estos archivos de la base de datos se almacenan de una única manera que, en defnitiva, es un conjunto de bytes que no son visibles para ningún tipo de usuario y que se administra a través del sistema operativo. Pero, el DBA, si utiliza

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 - Estructura y tipos de bases de datos

16

herramientas e instrucciones del DBMS, lo puede organizar e indicará en qué disco se almacena la base de datos (disco local o remoto, en uno u otro servidor) y defnirá, para cada archivo, su método de acceso. Por ejemplo: mediante la generación de un índice por código de producto en el archivo “Productos” y, de esta manera, agilizará su búsqueda. En el nivel conceptual o de estructura lógica, el DBA puede crear o modifcar las estructuras de estos archivos. Por ejemplo: si indica que el dato “Código del Producto” es numérico, con cuatro dígitos posibles (0 a 9999), se autogenera cada vez que se inserta un nuevo producto, sin que pueda repetirse. Aquí, también, es necesario identifcar la relación entre los archivos de “Productos” y de “Proveedores” y determinará cómo se produce una búsqueda o qué sucede cuando un proveedor quiere que se lo elimine de la base de datos. En el nivel externo, cada usuario verá lo que necesita y tiene habilitado; por ejemplo: •

•

El vendedor verá, en su pantalla, un listado ordenado por descripción del producto, con cabeceras de listado distintas a los nombres de los campos de datos en el archivo origen. A él no le interesa ni quién es el proveedor ni cuál es el stock mínimo de cada producto. Tampoco sabe si todos estos datos provienen de un solo almacenamiento o de una combinación. Producto

Descripción

Precio

Stock actual

108 110 230

IMP. MULTIF. TX410

699,80

2 3 12 …

IMP. MULTIF. C5580-CH.TIN.

769

MON. 19 PULG. LCD W1943C

925,50

…

…

El encargado de compras visualizará un listado con combinación de datos de los dos archivos, con cabeceras más descriptivas, que incluirá el resultado de un cálculo e indicará lo que debería comprar, como mínimo, para cubrir el stock por producto: Stock

Producto

Descripción

Precio

Actual

Mínimo

Comprar

Proveedor

108

IMP. MULTIF. TX410

699,80

2

6

4

Moura EPSON

230

MON. 19 PULG. LCD W1943C

925,50

12

10

0

Asoc. LG

110

IMP. MULTIF. C5580-CH.TIN.

769

3

6

3

HP Center

…

…

…

…

…

…

… •

Alfaomega

El gerente de la empresa, seguramente, necesitará un informe con una mayor complejidad de proceso, que incluirá los datos estadísticos resultantes de los cálculos que resumirá una situación, en la que se podría utilizar hasta un gráfco en pantalla; pero, en defnitiva, los obtendrá de los datos almacenados en los mismos archivos con una vista distinta.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.8 Modelos de datos

17

1.8 Modelos de datos En los ambientes de desarrollo existen lenguajes de programación estructurados, orientados a aspectos, orientados a objetos, etc.; donde cada uno brinda conceptos y ventajas en determinados tipos de aplicaciones. En los ambientes de base de datos también existen modelos de datos para almacenar los datos de la empresa, algunos que históricamente dieron las bases para el desarrollo de los demás, otros que están actualmente en uso y los que están en proceso de investigación.

Un modelo de datos brinda distintos conceptos y permite defnir las reglas y las estructuras para el almacenamiento de datos para, luego, manipularlos.

Un modelo de datos brinda distintos conceptos y permite defnir las reglas y las estructuras para el almacenamiento de datos para, después, manipularlos. Los modelos de datos se clasifcan de diversas formas. Sin embargo, en la literatura especializada, existe cierta coincidencia en utilizar —para su taxonomía— los conceptos que conforman la base de cada uno de ellos. Por ejemplo: hay modelos de datos basados en objetos y otros en registros; también el modelo físico de datos que apunta al almacenamiento de los datos en un nivel bajo de abstracción, relacionado con el formato y con el camino de acceso a los datos. En los modelos de datos basados en registros, los datos se estructuran en un conjunto de campos que conforman un registro. Tal es el caso de un registro “Estudiante” conformado por campos como legajo, apellido, nombres, fecha y lugar de nacimiento. En el caso de los modelos basados en objetos, se han aprovechado los conceptos utilizados en el paradigma de programación orientada a objetos, como sucede en las áreas de ingeniería de software. Solo que, en las bases de datos orientadas a objetos, existe la posibilidad de crear objetos para que tengan un almacenamiento que persista en el tiempo y para que puedan ser utilizados. 1.8.1 M o d e l o d e d a t o s o r i e n t a d o a o b j e t o s Este modelo nace con el objetivo de permitir el almacenamiento de datos para aplicaciones complejas que —como dicen Elisa Bertino y Lorenzo Martino en Sistemas de bases de datos orientadas a objetos— no se orientan a las del área comercial y administrativa, sino a las de las ingenierías, tales como CAD/CAM, CASE, CIM, sistemas multimediales y sistemas de gestión de imágenes, en las que la estructura de los datos es compleja y las operaciones se defnen en función de la necesidad de las aplicaciones.

Los datos se almacenan de manera persistente en objetos, que se identifcan, unívocamente, por un OID, generado por el sistema.

El grupo de gestión de bases de datos orientadas a objetos (ODMG, Object Database Management Group) —conformado por usuarios y productores de sistemas de gestión de bases de datos orientados a objetos (OODBMS, Object-Oriented Database Management System)— es el encargado de estandarizar el modelo de datos, el lenguaje de defnición de objetos (ODL, Object Defnition Language) y el lenguaje de consulta de objetos (OQL, Object Query Language). Los datos se almacenan de manera persistente en objetos, que se identifcan, unívocamente, por un OID (identifcador de objeto), generado por el sistema. Los objetos se defnen con una estructura (OID, Constructor_Tipo, Estado) en la que: •

OID: identifcador único en el sistema; incluso, cuando se elimina un objeto, es conveniente que el OID no se reutilice.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

18

1 - Estructura y tipos de bases de datos

•

Constructor_Tipo: es la defnición de la construcción del estado del objeto.

•

Estado: se defne a través del Constructor_Tipo.

Por ejemplo: si el Constructor_Tipo es de tupla, signifca que el estado tendrá la estructura, donde es un nombre de atributo y es un OID. Si el Constructor_Tipo es átomo, signifca que el estado será un valor. De esta manera, el Constructor también puede ser un conjunto, una lista, una bolsa y un array y determina que el estado se refera a OID de objetos. Solo el átomo se puede referir a un valor, aunque éste puede, también, referirse a otro objeto mediante su OID. Con estos constructores, se producen anidamientos y se logra una estructura de alta complejidad, además de la posibilidad de incorporar conceptos propios de la programación orientada a objetos: como clase, herencia, polimorfsmo, etcétera. La defnición en ODL de una clase “Personas” se puede expresar de la siguiente manera: Class Personas { attribute string apellido, attribute string nombres, attribute enum PosiblesSexo {Masculino, Femenino} sexo, attribute struct Domicilio {string calle, short numero, string ciudad, attribute date fecha_nac; short edad(); }; Para consultar la base de datos, se utiliza el lenguaje OQL propuesto por ODMG. Las sentencias de este lenguaje son similares a las de SQL y pueden ser insertadas en programas desarrollados con lenguajes de la programación orientada a objetos, como en el caso de C++ o Java. El resultado es un conjunto de objetos que pueden ser manipulados directamente en esos lenguajes y otros que sigan el paradigma. Una consulta OQL puede ser: SELECT p.apellido FROM p in Personas WHERE p.sexo=”Masculino” En esta expresión, aparece “p” como variable iteradora que asume los valores de cada objeto y la consulta devuelve una bolsa string, porque es una colección de apellidos que pueden repetirse.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.8 Modelos de datos

19

Entre las ventajas de este modelo, se pueden distinguir: la posibilidad de manipular objetos complejos con buen rendimiento, la integración de la persistencia de datos a la programación orientada a objetos y un menor costo y esfuerzo en el desarrollo de las aplicaciones y en el mantenimiento. La aparición de este tipo de sistemas de gestión de bases de datos exigió a los RDBMS (sistemas de gestión de bases de datos relacionales), que incorporaran objetos en sus estructuras y fexibilizaran las posibilidades de almacenamiento; de ello, surge el concepto actual de sistemas de gestión de bases de datos objetorelacionales. En la actualidad, se conocen prototipos y productos de gestión de bases de datos orientadas a objetos como, por ejemplo: •

Jasmine: tecnología orientada a objetos que permite tratar datos multimedia y complejas informaciones relacionadas. Se trata de un producto Java que se puede utilizar en entornos Intranet, Internet, Cliente/Servidor y a través de cualquier navegador.

•

GemStone: introducido en 1987, es el ODBMS comercial con más tiempo en el mercado. Soporta acceso concurrente de múltiples lenguajes, que incluye al Smalltalk-80, Smalltalk/V, C++ y C.

•

Versant Object Database (V/OD): ofrece características importantes a los desarrolladores C++, Java o NET, el apoyo a la concurrencia masiva y a grandes conjuntos de datos.

Éste es un tema tan interesante como extenso; por ello, se dejará su tratamiento para otro capítulo y se empezará con la explicación de las bases de conceptos para llegar al modelo relacional. 1.8.2 M o d e l o s d e d a t o s b a s a d o s e n r e g i s t r o s Estos modelos de datos tienen sus inicios con los modelos de red y jerárquicos, hoy obsoletos desde el punto de vista tecnológico. Ambos modelos, red y jerárquicos, compartían el concepto de registro de datos y los enlaces físicos entre ellos, pero diferían en sus restricciones y en su representación. Posteriormente, surgió el Modelo Relacional, donde se mantiene el concepto de registro de datos y las relaciones entre las entidades del mundo real son lógicas, dando origen a entidades que permiten establecer relaciones, como también a otros temas propios del modelo. Por la importancia que tiene el tema en sí mismo, se decidió dedicar otros capítulos al Modelo Relacional. 1.8.2.1 Características del modelo de datos en red Los datos se representan como una colección de registros y las relaciones entre ellos mediante enlaces, que se implementan como campos que almacenan punteros. Cada registro es una colección de campos y cada campo almacena un dato. Gráfcamente, se los representaba con un diagrama, en el que la estructura de datos estaba formada por cajas y líneas. Las cajas eran los registros y las líneas indicaban sus relaciones.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Los datos se representan como una colección de registros y las relaciones entre ellos mediante enlaces, que se implementan como campos que almacenan punteros.

Alfaomega

20

1 - Estructura y tipos de bases de datos

D Cliente 1

E

Bs. As.

Cuenta 1

2000

Cliente 2 La Plata

Cuenta 2 5000

Cliente 3 Bs. As.

Cuenta 3 1000 Cuenta 4 7000

Fig. 1.3 Modelo de datos en red.

La Fig. 1.3 representa a tres registros de clientes y a cuatro registros de cuentas bancarias donde: •

Cliente 1 posee una sola cuenta con un saldo de $2000. Se observa que este registro tiene un campo para un puntero del Cliente a la Cuenta 1 y, en el registro Cuenta 1, se visualiza un campo con un puntero hacia el Cliente 1.

•

Cliente 2 tiene una Cuenta 2 a su nombre y comparte la Cuenta 3 con el Cliente 3. En este caso, en Cliente 2 hay dos campos desde donde parten dos punteros.

•

Cliente 3 comparte la Cuenta 3 con el Cliente 2 y, además, posee su propia cuenta que es la 4.

Se ve que en el registro de la Cuenta 3 hay dos campos, porque tiene un puntero hacia el Cliente 2 y otro, hacia el 3. Los campos que almacenaban punteros hacían que los registros fueran de longitud variable, porque en algunos casos se necesitaba solo uno y en otros, más. La fexibilidad del modelo hizo que la estructura de datos fuera compleja, ya que no había restricciones, en la que se puede observar cierta estructura Padre-Hijo. Las acciones de manipulación de datos en la programación implicaban órdenes que signifcaban movimientos físicos. Ejemplo:

Alfaomega

•

Find: localiza un registro, según alguna condición y el puntero actual, en el archivo, queda apuntando a ese registro.

•

Get: copia registro señalado por el puntero actual en el área de trabajo-buffer de memoria.

•

Store: crea un registro nuevo, en un archivo, con valores de datos ubicados en la memoria que maneja el usuario.

•

Modify: modifca contenido. Implica encontrarlo, subirlo a la memoria y, solo ahí, modifcarlo.

•

Erase: elimina registro, con su búsqueda previa.

•

Connect: conecta un registro con un conjunto de registros de un archivo.

•

Disconnect: desconecta un registro de un conjunto archivo. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.8 Modelos de datos

•

21

Reconnect: mueve un registro de un conjunto a otro. Por ejemplo: cambia una cuenta de una sucursal a otra.

Al crear los conjuntos archivos, se debe indicar qué hacer ante las siguientes acciones: •

Inserción: si la inserción es manual, debe existir en el programa una instrucción connect para enlazar el nuevo registro y, si no, puede ser automática, donde al ejecutar store el registro se almacena en el conjunto y se enlaza.

•

Eliminación: depende si se defnió como;

•

–

Opcional, en el cual pueden existir registros sin conexión al conjunto (elimina padre y desconecta todos los hijos).

–

Fijo, en el cual no puede haber registros de miembros sin conexión al grupo y, además, no pueden reconectarse con otra ocurrencia de un conjunto (elimina padre y elimina todos los hijos).

–

Obligatorio, tampoco puede haber registros sin conexión al grupo, pero sí pueden moverse de un conjunto a otro (no deja eliminar el registro).

Ordenación: en el conjunto “archivo” debe defnirse qué se hará al añadir un nuevo registro. Las opciones son que, al insertarlo, pase a alguna de estas posiciones en el conjunto: –

Primero del conjunto.

–

Último.

–

Siguiente al registro actual del conjunto.

–

Anterior al registro actual.

–

Arbitrario, según determinación del sistema de gestión.

–

Ordenado según algún criterio y el sistema de gestión debe mantener el orden.

1.8.2.2 Características del modelo de datos jerárquico Este modelo se puede considerar una implementación particular del modelo en red, en el cual la estructura física también se basa en registros y en punteros, pero con forma de árbol invertido y con restricciones en las relaciones. Las relaciones se representan mediante enlaces implementados como campos que almacenan punteros. Los grafos se organizan como árboles con un nodo raíz.

•• Un registro es una colección de campos y cada uno de esos campos almacena un dato.

Un registro es una colección de campos y cada uno de esos campos almacena un dato. A la colección de registros, se la denomina tipo de registro, que son los nodos en el árbol. Las relaciones que se mantienen entre tipos de registros son del tipo 1: N, en la que se distinguen un registro “Padre” y n registros Hijos. En el diagrama jerárquico, se muestra la estructura de árbol, con cajas que representan los tipos de registros y líneas que representan las relaciones “Padre-Hijo”. Los niveles del árbol no tienen limitación y el nodo raíz está en el nivel 0 (cero).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

22

1 - Estructura y tipos de bases de datos

Raíz

I

|

Cliente 1 - Bs. As.

1 Cliente 2 - La Plata 1

J^^ ^J^^ Cuenta 1 - 2000

Cuenta 2 - 5000

Cuenta 3 - 1000

Cliente 3 - Bs. As.

/^^^ Cuenta 3 - 1000

Cuenta 4 - 7000

Fig. 1.4 Modelo de datos jerárquico. Algunas restricciones del modelo son: •

El nodo raíz no participa como hijo en ninguna relación y los tipos de registros son siempre hijos de un solo tipo de registros.

•

Un nodo padre puede tener un número ilimitado de hijos, pero un nodo hijo puede y debe tener solo un nodo padre.

•

Si un tipo de registro “Padre” posee más de un tipo de registro “Hijo”, los tipos de registros “Hijo” estarán ordenados de izquierda a derecha.

•

Se puede eliminar un registro “Hijo” y el registro “Padre” puede quedar con 0 (cero) hijos, pero si se desea eliminar en el registro “Padre” no puede quedar un registro “Hijo” sin padre, por lo que se elimina el “Padre” y todos los hijos asociados.

Para que un registro “Hijo” tenga más de un registro “Padre”, debe duplicarse con la consiguiente redundancia de datos. Algunas implementaciones evitan esto mediante uso de registros virtuales con punteros. Ese tipo de situaciones muestran una desventaja del modelo jerárquico: la poca fexibilidad que posee para representar estructuras que, en la vida real, hacen falta. Que dos o más clientes de un banco compartan una cuenta es muy común, como también en una estructura de productos existen productos que son piezas de otro producto (estructura recursiva de datos). Algunas acciones que se pueden mencionar en la manipulación de datos de este modelo:

Alfaomega

•

Get: localiza y copia un registro al área de trabajo las condiciones de búsqueda se agregan con la cláusula WHERE. Con un ciclo, se podía recorrer toda una rama del árbol, leyendo todos los registros al recorrerla, sin que importe la altura del árbol.

•

Insert: añade un registro al árbol. Primero se localiza a su registro “Padre” y luego, se emite la orden de inserción.

•

Replace: modifca uno o más campos de un registro que, primeramente, se ubicará como el registro actual de la base de datos.

•

Delete: elimina un registro de la base de datos que esté como registro actual.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1.9 Resumen

La primera implementación de este modelo fue IMS (Information Management System). Se trata de un diseño de IBM y otros colaboradores, realizado en 1966, para el Programa Apolo de la NASA. En abril de 1968, fue instalado en la División Espacial de la NASA Rockwell en Downey, California.

1.9 Resumen De lo expuesto en este capítulo, podemos concluir que actualmente todas las personas interactúan con datos de alguna manera y en circunstancias diferentes. Estos datos se almacenan en un medio físico y luego, se vinculan a un sistema informático que los registra y habilita su acceso.

23

Encontrará más informacion sobre IMS (Information Management System) en la publicación de IBM: http://publib. boulder.ibm.com/infocenter/zos/basics/ index.jsp?topic=/com.ibm.imsintro.doc. intro/ip0ind0011003710.htm

En el pasado, esta tarea de almacenamiento de datos requería de un esfuerzo mucho mayor a la hora de acceder a la información guardada, dado que este almacenamiento se focalizaba en tipos de datos muy reducidos lo cual limitaba las posibilidades de respuesta sin satisfacer por completo las necesidades de las empresas. Fueron presentados los conceptos fundamentales para introducir al lector en los entornos de bases de datos, incluyendo la descripción de elementos componentes de un sistema con bases de datos, como son el DBMS, los distintos usuarios que interactúan con los datos y las defniciones de seguridad a considerar cuando se asignan privilegios. También se caracterizaron modelos de datos que hacen posible el almacenamiento de datos, incluyendo la introducción mínima al Modelo de Datos Relacional.

1.10 Contenido de la página Web de apoyo El material marcado con asterisco (*) solo está disponible para docentes.

1.10.1 Mapa conceptual del capítulo 1.10.2 Autoevaluación 1.10.3 Presentaciones*

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

Modelo de datos relacional

Contenido

Objetivos

2.1 Introducción

26

2.2 Álgebra relacional

41

2.3 Normalización

63

2.4 Origen de los datos

67

2.5 Las formas normales

69

2.6 Las estructuras

92

2.7 Un caso de estudio

99

2.8 Resumen

101

2.9 Contenido de la página Web de apoyo

101

•

Conocer los conceptos básicos del Modelo Relacional y los relacionados con la consistencia e integridad en una base de datos.

•

Aplicar los operadores del Álgebra y del Cálculo Relacional.

•

Lograr el aprendizaje en la escritura de expresiones para relacionar datos.

•

Conocer la normalización.

26

2 - Modelo de datos relacional

2.1 Introducción El modelo de datos relacional —perteneciente al grupo de modelos de datos orientados a registros— es hoy el modelo de mayor uso y difusión en los distintos tipos de organizaciones, aunque con importantes cambios y adecuaciones realizados a través del tiempo. El Dr. Edgar Frank Codd produjo —tras la publicación de uno de sus principales trabajos— el gran cambio en los modelos de datos existentes, en el cual expresaba conceptos que no perdieron su vigencia y que constituyen un pilar de conocimientos. A partir de 1960, este matemático inglés —que emigró a EE. UU. para trabajar como investigador en IBM en 1949—, concentró su atención en la gestión de bases de datos.

Edgar “Ted” Frank Codd. (23 de agosto de 1923 - 18 de abril de 2003). Científco informático inglés conocido por sus aportes a la teoría de bases de datos relacionales.

Su amigo y reconocido escritor, Christopher Date —autor, entre otras, de la obra Introducción a los Sistemas de Bases de Datos— hace un tributo después de la muerte del Dr. Codd diciendo: “El Modelo Relacional es ampliamente reconocido como una de las grandes innovaciones del siglo xx”, y continúa: “El modelo relacional proporcionó un marco teórico en el que una variedad de problemas importantes podrían ser atacados de una manera científca. Ted describió por primera vez su modelo en 1969 en un informe de investigación de IBM: “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks” (IBM Research Informe RJ599 - 19 de agosto 1969). En junio de 1970, el Dr. Codd publicó un paper —que es el más conocido— con el título A Relational Model of Data for Large Shared Data Banks, que signifca: “Un modelo relacional de datos para grandes bancos de datos compartidos”. Uno de los objetivos centrales de este artículo se expresó de la siguiente manera: “Los futuros usuarios de los grandes bancos de datos deben ser protegidos de tener que saber cómo se organizan los datos en la máquina (la representación interna)”. De su afrmación se podría interpretar que deseaba alejar a los usuarios del nivel físico; es decir: elevar el nivel de abstracción con el que debían interactuar los usuarios y que no dependieran de los detalles técnicos para usar los datos almacenados. Por su parte, Date consideró que “Ted no solo inventó el modelo relacional en particular, él inventó el concepto de modelo de datos en general”. (Ver su paper Data Models in Database Management, ACM SIGMOD Record 1 1 , No. 2 February 1981).

Michael Stonebreaker. Científco especializado en la base de datos de investigación y desarrollo, reconocido por su colaboración en la creación de la mayoría de las bases de datos relacionales del mercado. Además, es fundador de Ingres, Cohera, StreamBase, Vertica, VoltDB, SciDB, entre otros.

Alfaomega

El modelo relacional logró la adhesión inicial de otros expertos, porque apuntaba a resolver el problema de grandes bases de datos compartidas. Un ejemplo claro es el trabajo de Michael Stonebraker, que puede visualizarse en el paper Retrospection on a Database System. En el cual se describe la historia de la implementación de Ingres, desde marzo de 1973, con la primera implementación en septiembre de 1975 y cómo continuaron. Dicho paper está disponible en: http://ece.ut.ac.ir/classpages/f84/AdvancedDatabase/Paper/p225-stonebraker.pdf

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.1 Introducción

27

2.1.1 Conceptos básicos en el modelo relacional El concepto fundamental, en el Modelo Relacional, es que los datos se representan de una sola manera, en el nivel de abstracción que es visible al usuario, y es, específcamente, como una estructura tabular —conformada por flas y columnas— o como una tabla con valores.

Relación Estudiantes Legajo

Apellido

Nombres

TipoDoc

NroDoc

IdLocalidad

Sexo

11904

González

Ana Carolina

DNI

35900342

31

Femenino

13789

López

Hugo Sebastián

DNI

29762007

27

Masculino

Filas i

1

Columnas A esta estructura se la denomina formalmente relación aunque, en lo informal y en la práctica, se la conoce con el nombre de tabla. La diferencia está en el grado de abstracción ya que la relación cuenta con ciertas propiedades —que se verán más adelante— y la relación ya es la implementación, en la que no necesariamente se cumple con todas las propiedades de la relación, porque depende del diseño que se propone y que se implementa.

Los datos se representan como una estructura tabular –conformada por flas y colum nas– o como una tabla con valores.

Los conceptos básicos que se utilizarán, a partir de este momento, son propios del modelo y se resumen en: •

Relación: no es más que una representación en dos dimensiones, o de doble entrada, constituida por flas, o tuplas y columnas o atributos. Es el concepto primitivo y fundamental del modelo. La relación debe cumplir con un conjunto de restricciones o propiedades que ya han sido mencionadas. Dentro del diseño de la base de datos, las relaciones representan a las entidades que se modelaron. Las entidades poseen atributos que las distinguen y cada uno de ellos está ligado a un dominio en particular.

•

Fila o tupla: es un hecho en la relación que contiene datos de la realidad. Por ejemplo: los datos de un alumno en particular forman una tupla de la relación “Estudiantes”; los datos de un artículo pueden ser una tupla en una relación de la base de datos de una “Empresa de Ventas o Producción”, etcétera. La tupla en una relación es una colección ordenada de elementos diferentes. Cada tupla es también una única combinación de estos elementos; por ende, las tuplas no se repiten dentro de la misma relación. Las ocurrencias de distintas instancias en la entidad, se refejan en distintas colecciones de elementos dentro de una relación y cada colección es una tupla. Podríamos decir que una instancia dentro de la entidad posee una tupla en la relación correspondiente.

•

Cuerpo: al conjunto de tuplas de una relación se lo denomina cuerpo de la relación. El cuerpo de la relación "Estudiantes" tiene dos tuplas.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

28

2 - Modelo de datos relacional

•

Columna o atributo: es una propiedad que caracteriza a cada entidad, como el color o tamaño de un artículo, el apellido o el legajo de un estudiante, etcétera. Los elementos que componen la estructura de la entidad se denominan atributos y serán irrepetibles en la entidad.

•

Cabecera: el conjunto de atributos de una relación conforma la cabecera de dicha relación. La cabecera de la relación “Estudiantes” es:

Legajo

4ALegajo=19098 (Exámenes)

El resultado de la expresión es: IdMateria

Legajo

Turno

Año

Fecha

Nota

LegDoc

290 306 333

19098

8

2009

27/11/09

5

21722

19098

1

2010

05/02/10

4

22654

19098

2

2010

10/02/10

7

21987

2.2.2.2 Proyección Así como en el resultado de la selección se obtienen flas que cumplen determinadas condiciones, en este caso, lo que podemos elegir son columnas, que van separadas por coma. Es decir que la operación, que se simboliza con TÍ y es unaria, permite elegir cuáles serán las columnas de la relación entrante que formarán parte de la relación “Resultado”. -K ListaDeColumnas (A)

El resultado será una nueva relación, en la que la cabecera estará formada solo por las columnas elegidas de A y el cuerpo estará formado por todas las tuplas de A, mientras no tengan una operación de selección. Ejemplo: Si se desean obtener Apellido y Nombres de todos los no docentes de la universidad, la expresión será: π Apellido,Nombres ( N o D o c e n t e s )

El resultado de la expresión es: Apellido

Nombres

Asís

Jorge Antonio

Sosa

Santiago Martín

Bustos

Magdalena

Soria

Liliana del Valle

2.2.3 Reunión La operación binaria de reunión permite ampliar los datos de una relación con datos de otra relación, a través de un atributo en común que deben poseer las relaciones, que obtendrá una mayor información.

Alfaomega

Esta operación binaria brinda la posibilidad de ampliar los datos de una relación con datos de otra relación, a través de un atributo en común que deben poseer las relaciones, que obtendrá una mayor información. Generalmente, el atributo común entre ambas es clave primaria en una relación y foránea en la otra; es decir, que se defnirán en el mismo dominio. Esta no es una operación primitiva, puesto que el mismo resultado puede lograrse aplicando producto cartesiano, selección y proyección y se simboliza con C X I .

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.2 Álgebra relacional

51

Sea la relación A (x1, x2, x3) y B (x3, x4, x5), la expresión será: A L>^J x3=x3 B

y la reunión dará como resultado una relación con: •

Cabecera formada por x 1 , x2, x3, x4, x5, en la que aparece una sola vez la columna en común.

•

Cuerpo formado por tuplas, en las que el valor de x3 en A sea igual al valor de x3 en B.

Ejemplo: Si se desea obtener los datos de las localidades que incluyan la descripción de la provincia a la que pertenece cada una, la expresión es: Localidades X

Id Provincia=IdProvincia

Provincias

El resultado es:

IdLocalidad

Descripción

IdProvincia

DescripProv

27

Ciudad Buenos Aires

4

Buenos Aires

31

Córdoba

7

Córdoba

30

Villa María

7

Córdoba

33

Godoy Cruz

2

Mendoza

25

Villa Mercedes

8

San Luis

20

Villa Dolores

7

Córdoba

36

Mar del Plata

4

Buenos Aires

22

Cruz del Eje

7

Córdoba

21

San José

9

Misiones

34

Las Heras

2

Mendoza

29

Oberá

9

Misiones

32

Tunuyán

2

Mendoza

37

La Plata

4

Buenos Aires

2.2.3.1 Reunión externa En el resultado anterior, no aparece la descripción de la provincia de Entre Ríos porque la reunión expresada es una equirreunión; es decir: en el resultado aparecen las flas que cumplen con la igualdad de los valores del atributo común entre ambas relaciones. Algo semejante hubiera sucedido si la expresión fuera: Estudiantes I X ] IdLocalidad=IdLocalidad Localidades

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

52

2 - Modelo de datos relacional

En este caso, no aparecería la fla: 22941

Folmer

Alfonsina

DNI

31892170

nulo

Femenino

Aquí, el atributo “IdLocalidad” tiene valor nulo en la fla y el valor nulo no puede ser comparado con ningún valor, es algo desconocido. La reunión externa se utiliza para resolver este tipo de situaciones y es una ampliación de la operación reunión: •

Cuando se desea que aparezcan en el resultado las flas en las que el valor de la clave foránea o ajena tiene valor desconocido o nulo.

•

Cuando alguna fla en la relación que posee la clave primaria no se referencia por ninguna fla de la otra relación.

•

Ambas a la vez.

2.2.3.2 Reunión externa derecha Si quisiéramos que la provincia de Entre Ríos apareciera en la reunión entre “Localidades” y “Provincias”, la expresión Localidades 1X1 IdProvincia=IdProvincia Provincias debe ser reemplazada por: Localidades X E IdProvincia=IdProvincia Provincias Como la provincia de Entre Ríos no se referencia por ninguna localidad, con esta operación sí aparecerá, pero los demás datos de la tupla serán desconocidos. La relación resultado será:

Alfaomega

IdLocalidad

Descripción

IdProvincia

DescripProv

27

Ciudad Buenos Aires

4

Buenos Aires

31

Córdoba

7

Córdoba

30

Villa María

7

Córdoba

33

Godoy Cruz

2

Mendoza

25

Villa Mercedes

8

San Luis

20

Villa Dolores

7

Córdoba

36

Mar del Plata

4

Buenos Aires

22

Cruz del Eje

7

Córdoba

21

San José

9

Misiones

34

Las Heras

2

Mendoza

29

Oberá

9

Misiones

32

Tunuyán

2

Mendoza

37

La Plata

4

Buenos Aires

Nulo

Nulo

5

Entre Ríos

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.2 Álgebra relacional

53

2.2.3.3 Reunión externa izquierda La situación para ejemplifcar es la de “Estudiantes” con “Localidades”, porque hay una estudiante que no posee localidad asignada y, por eso, el atributo “IdLocalidad” posee valor nulo. Si quisiéramos obtener un listado completo de alumnos, posean o no localidad asignada, la expresión sería: Estudiantes z t x

IdLocalidad=IdLocalidad

Localidades

En el resultado aparece la alumna con localidad desconocida.

Legajo

Apellido

Nombres

TipoDoc

NroDoc

IdLocalidad

Sexo

Descripción

IdProvincia

11904

González

DNI

35900342

31

Femenino

López

DNI

29762007

27

Masculino

25784

Acuña

DNI

33457821

30

Masculino

Córdoba Ciudad Buenos Aires Villa María

7

13789

Ana Carolina Hugo Sebastián Juan Martín

23892

Salinas

DNI

32890128

31

Masculino

19098

Romero

DNI

28089727

27

Femenino

22941

Folmer

DNI

31892170

Nulo

Femenino

Nulo

nulo

24561

Moreno

DNI

30892109

31

Masculino

Córdoba

7

13490

Funes

DNI

32782340

33

Femenino

2

25801

Sosa

DNI

29872301

27

Masculino

12802

López

DNI

27001287

31

Femenino

Godoy Cruz Ciudad Buenos Aires Córdoba

Rubén María Amparo Alfonsina Santiago Rubén Elizabeth Marcelo Alejandro Analía

Córdoba Ciudad Buenos Aires

4 7 7 4

4 7

2.2.3.4 Reunión externa completa Se continúa con la reunión entre “Estudiantes” y “Localidades” para mostrar qué sucede si la expresión es una reunión externa completa. Con la expresión siguiente se logrará mostrar las tuplas de la relación “Estudiantes” —que no poseen localidad conocida— y las localidades que no se referencian por la relación “Estudiantes”. Estudiantes H X L T IdLocalidad=IdLocalidad Localidades El resultado será:

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

54

Legajo

Apellido

Nombres

TipoDoc

NroDoc

IdLocalidad

Sexo

Descripción

IdProvincia

11904

González

DNI

35900342

31

Femenino

López

DNI

29762007

27

Masculino

25784

Acuña

DNI

33457821

30

Masculino

Córdoba Ciudad Buenos Aires Villa María

7

13789

Ana Carolina Hugo Sebastián Juan Martín

23892

Salinas

DNI

32890128

31

Masculino

19098

Romero

DNI

28089727

27

Femenino

22941

Folmer

DNI

31892170

Nulo

Femenino

Nulo

nulo

24561

Moreno

DNI

30892109

31

Masculino

Córdoba

7

13490

Funes

DNI

32782340

33

Femenino

Sosa

DNI

29872301

27

Masculino

12802

López

DNI

27001287

31

Femenino

Nulo

Nulo

Nulo

Nulo

Nulo

25

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Mar del Plata

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Cruz del Eje

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

20 36 22 21 34 29 32 37

Godoy Cruz Ciudad Buenos Aires Córdoba Villa Mercedes Villa Dolores

2

25801

Rubén María Amparo Alfonsina Santiago Rubén Elizabeth Marcelo Alejandro Analía

4 7 7

Córdoba Ciudad Buenos Aires

Nulo

San José

Nulo

Las Heras

Nulo

Oberá

Nulo

Tunuyán

Nulo

La Plata

4

4 7 8 7 4 7 9 2 9 2 4

2.2.4 División Ésta es una operación binaria que permite obtener los datos de los estudiantes que aprobaron todas las materias o empleados que trabajaron en todas las sucursales de una empresa. La condición es que la cabecera de la relación del divisor esté incluida en la cabecera del dividendo. El símbolo es + y la expresión se escribe así: A+ B La estructura de las relaciones tendría que ser A (u, v, w) y B (w), donde se observará que la cabecera de B se incluirá en la cabecera de A. La relación resultante quedaría con:

Alfaomega

•

Cabecera formada por u y v, en la que no aparece el atributo común.

•

Cuerpo formado por todas las tuplas de A, en las que los valores de los atributos u y v se relacionan con todos los valores de w en B.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.2 Álgebra relacional

55

Para utilizar las relaciones de la relación “Estudiantes”, se utilizarán muchas flas más en algunas relaciones para visualizar el efecto en una relación resultado. Por ello, se planteará, a continuación, un ejemplo genérico que buscará el entendimiento de la operación. Ejemplo: Sean las relaciones A y B con las estructuras mencionadas anteriormente:

B

A u

V

u2 u1

w

W

v4

w1

w1

v5

w5

w3

u1

v7

w4

w4

u2

v1

w4

w5

u2

v1

w5

u2

v4

w3

u1

v2

w3

u2

v3

w5

u3

v2

w1

u2

v4

w5

u1

v4

w1

El resultado de A + B será:

u

v

u2

v4

Se observa que los valores de los atributos u, v G A se relacionan en B con todos los valores del atributo w. Esto es, cada par de valores (ui, vj) del resultado de la relación anterior está acompañado en la relación A + B por todos los valores del atributo w de la tabla B. Por cada par (ui, vj), hay 4 flas donde se tienen los 4 valores de w. Además, la columna w ya no forma parte del resultado.

2.2.5 Renombrar La operación renombrar no está dentro de las mencionadas ya que es una operación auxiliar, pero necesaria en determinadas situaciones, como en las que se aplican expresiones complejas o se necesita cumplir con las exigencias de otra operación del Álgebra relacional. Esta operación se simboliza con p (rho) y permite renombrar una relación, unos atributos o los dos a la vez. Sea la relación A con cabecera formada por los atributos u, v y w, se analizarán las distintas posibilidades que brinda la operación renombrar: ps(A): renombra a la relación A como S. P(a,b,c) (A): renombra a los atributos de la relación A como a, b, c. Ps(a,b,c) (A): renombra a la relación A como S y a sus atributos como a, b, c. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

56

2 - Modelo de datos relacional

2.2.6 Funciones A continuación, se mencionará un conjunto de funciones que proporcionarán la posibilidad de aplicar cálculos con valores de las relaciones. Las funciones disponibles son: •

SUM(Atributo): suma de los valores numéricos contenidos en el atributo.

•

AVG(Atributo): promedio de valores numéricos del atributo.

•

MIN(Atributo): menor valor asumido por el atributo, no necesariamente numérico.

•

MAX(Atributo): valor máximo asumido por el atributo, no necesariamente numérico.

•

COUNT(Atributo): contar la ocurrencia de valores en una columna de datos de cualquier tipo.

Estas funciones se escribirán junto al símbolo ^ (F gótica), de la siguiente manera: O función(w) (A)

Y w G A es el atributo sobre el que se aplica la función. Ejemplo: Para obtener la cantidad de alumnos de la universidad, la expresión será: $COUNT(Legajo) (Estudiantes)

que dará como resultado una relación de una única tupla y una columna; es decir, un valor que, en este caso, será 10. En cuanto a la cabecera de la relación, se puede decir que no asume un nombre determinado; por ello, se asumirá que, en la cabecera, aparecerá un nombre FUNCIÓN_Atributo. Por lo antedicho, la relación resultado será: COUNT_Legajo 10

Ejemplo: Si se quisiera calcular la cantidad de exámenes y la nota promedio en la universidad, se escribirá: O COUNT(Legajo),AVG(Nota) ( E x á m e n e s )

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.2 Álgebra relacional

57

Y el resultado será: COUNT_Legajo

AVG_Nota

13

5.23

2.2.7 Agrupación A las funciones mencionadas, si se les aplica lo que se denomina agrupación, se las proveerá de más potencial. Para explicar qué es agrupar, se tomará la relación “Exámenes”. La expresión indica que deben agruparse las tuplas por legajo y, por cada grupo de flas, aplicar la función AVG sobre los valores del atributo “Nota” para el cálculo de promedio. Como ya se calculó el promedio de todos los exámenes y se explicó que devolvía una tupla, si se quisiera calcular el promedio en “exámenes por materia”, se aplicará la agrupación de la siguiente manera: LegajoTAVG(Nota) (Exámenes)

IdMateria

Legajo

Turno

Año

Fecha

Nota

LegDoc

207 306 459 333 290 306 333 207 333 306 333 306 290

11904

2 1 10 2 8 1 2 2 10 9 1 2 3

2010

08/02/10

2 10 8 7 5 4 7 3 8 2 4 2 6

20871

Grupo 1-Legajo=11904-AVG= 2

22654

Grupo 2-Legajo=12802-AVG= 10

12802 13789 13789 19098 19098 19098 19098 24561 25801 25801 25801 25801

2010

05/02/10

2009

22/12/09

2010

10/02/10

2009

27/11/09

2010

05/02/10

2010

10/02/10

2010

08/02/10

2009

21/12/09

2009

07/12/09

2010

03/02/10

2010

12/02/10

2010

24/02/10

21823

Grupo 3-Legajo=13789-AVG= 7.5

21987 21722 22654

Grupo 4-Legajo=19098-AVG= 4,75

21987 20871 21987

Grupo 5-Legajo=24561-AVG= 8

22654 21987 22654

Grupo 6-Legajo=25801-AVG= 3.5

21722

La relación resultado tendrá: •

Cabecera formada por dos columnas: en la primera, por el atributo de la agrupación Legajo y, en la segunda, por el promedio AVG aplicado sobre la columna “Nota”.

•

Cuerpo formado por seis tuplas, una fla por grupo, que corresponden a los distintos legajos de la relación “Exámenes”.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

58

2 - Modelo de datos relacional

Legajo

AVG_Nota

11904 13789

2 10 7.5

19098

4.75

24561

8 3.5

12802

25801

2.2.8 Relaciones temporales En expresiones complejas, suelen utilizarse las relaciones temporales para que se mantengan o recuerden los resultados intermedios de las operaciones del Álgebra relacional. Esto signifca que también se hace en la práctica con SQL, para evitar, de esta manera, las consultas de muy difícil lectura y seguimiento. Para expresar la asignación del resultado de una operación a una relación temporal, se escribirá: temp

(E)

donde E es una expresión válida del Álgebra compuesta por el número de operaciones que se desee. Ejemplo: Si al resultado del cálculo de promedios que se hizo al agrupar, se deseara agregar los datos del alumno, para poder identifcarlo, se grafcaría de la siguiente manera: 1.

temp1

( Legajo T

AVG(Nota) (Examenes))

Legajo

AVG_Nota

11904 13789

2 10 7.5

19098

4.75

24561

8 3.5

12802

25801

Se aplicó agrupación y la función AVG.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.2 Álgebra relacional

2.

temp2

59

( temp1 X I

Legajo=Legajo

(Estudiantes))

Legajo

AVG_Nota

Apellido

Nombres

TipoDoc

NroDoc

IdLocalidad

Sexo

11904

2

González

Ana Carolina

DNI DNI DNI DNI DNI DNI

35900342

31 31 27 27 31 27

Femenino

12802

10

López

Analía

13789

7.5

López

Hugo Sebastián

19098

4.75

Romero

María Amparo

24561

8

Moreno

Santiago Rubén

25801

3.5

Sosa

Marcelo Alejandro

27001287 29762007 28089727 30892109 29872301

Femenino Masculino Femenino Masculino Masculino

Se aplicó reunión entre la relación temporal temp1 y la relación “Estudiantes” por el atributo “Legajo”, para ampliar con los datos de los estudiantes. 3.

t e m p 3 - ( TI Legajo,Apellido,Nombres,AVG_Nota (temp2))

Y el resultado fnal, asignado a temp3, es la relación: Legajo

Apellido

Nombres

11904

González

Ana Carolina

2

12802

López

Analía

10

13789

López

Hugo Sebastián

7.5

19098

Romero

María Amparo

4.75

24561

Moreno

Santiago Rubén

8

25801

Sosa

Marcelo Alejandro

3.5

AVG_Nota

Se aplicó proyección sobre la relación temporal temp2. La operación anterior, escrita con tres relaciones temporales, se podría escribir, también, anidando las expresiones, de manera sensiblemente más compleja, pero con el mismo resultado. Entonces, se la podría escribir como sigue: Legajo,Apellido,Nombres,AVG_Nota ( Legajo T AVG(Nota) (Examenes) C X Legajo=Legajo

(Estudiantes)

2.2.8.1 Ejemplos combinando operaciones En este punto, se plantearán algunos ejercicios y resoluciones propuestas con las operaciones analizadas, con el agregado de funciones, de agrupación y de relaciones temporales. Todos los ejemplos que se basan en las relaciones que se vienen utilizando, correspondientes a los datos de la universidad, tienen una nota aclaratoria que intenta clarifcar lo enunciado y, también, la búsqueda de los datos. A continuación, se recordarán las cabeceras de las relaciones para facilitar el seguimiento de las soluciones propuestas.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

60

2 - Modelo de datos relacional

Relación Estudiantes

Legajo

Apellido

Nombres

TipoDoc

NroDoc

IdLocalidad

Sexo

Relación Localidades

IdLocalidad

Descripción

IdProvincia Relación Provincias

IdProvincia

Relación Materias

IdMateria

Descripción

Carrera

Relación Exámenes IdMateria Legajo Turno

Año

DescripProv

Año

Fecha

Nota

LegDoc

Relación Docentes Legajo Apellido Nombres

TipoDoc

NroDoc

IdLocalidad

Sexo

Legajo

TipoDoc

NroDoc

IdLocalidad

Sexo

Apellido

Nombres

Ejemplo: Obtener legajo, apellido y nombres de los estudiantes que aprobaron alguna asignatura en el turno 9, del año 2009. Nota: son los alumnos que tienen nota igual o superior a 4 (cuatro) en la relación “Exámenes”, pero con Turno 9 y Año 2009. tempApr - o Nota>4ATurno=9AAño=2009 (Examenes) tempReu «- (tempApr 1 X 1 Legajo=Legajo Estudiantes) tempPro - 4

(Examenes)

tempCon - IdMateria TCOUNT(IdMateria) (tempApr) tempReu «- tempCon CXI I dMateria= IdMateria Materias tempFin - TI Count_ IdMateria,Descripción (tempReu)

2.2.9 Cálculo relacional En el Álgebra relacional —como se habrá observado—, las expresiones son operaciones anidadas que indican lo que se desea obtener y cómo conseguirlo; incluso, especifcando un determinado orden para obtener lo que se necesita sin perder datos. Por todo esto, se dice que el Álgebra relacional es un lenguaje procedimental para expresar consultas. El Cálculo relacional, por el contrario, es un lenguaje no procedimental, en el que se indica —sin un orden de escritura— qué se desea obtener, pero no cómo obtenerlo.

El Álgebra relacional es un lenguaje procedimental para expresar consultas. En cambio, el Cálculo relacional es un lenguaje no procedimental, en el que se indica —sin un orden de escritura— qué se desea obtener, pero no cómo obtenerlo.

Si bien existe esta diferencia, con ambos se pueden escribir, en el modelo relacional, el mismo tipo de consultas. Según el tipo de variable que se use para el Cálculo relacional, se determina el tipo de cálculo: •

Cálculo relacional de tuplas.

•

Cálculo relacional de dominios.

2.2.9.1 Cálculo relacional de tuplas Para obtener todos los datos de los estudiantes masculinos de la universidad, en el Álgebra relacional, se escribirá la expresión: ° Sexo= Masculino’ (Estudiantes) Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

62

2 - Modelo de datos relacional

Mientras que en el Cálculo relacional de tuplas, la expresión para la misma consulta es: {e|Estudiantes(e) A e.Sexo = ‘Masculino’} Esto es, obtener que la tupla e de la relación “Estudiantes” cumpla la condición de que el atributo “Sexo” tenga el valor “Masculino”. Cuando se escribe e.Sexo, se dice que el atributo “Sexo” está cualifcado para mayor claridad, lo que es imprescindible para consultas complejas con datos de múltiples relaciones. Por ejemplo, para escribir una reunión del Álgebra relacional, en la que se necesitan las descripciones de las localidades de la provincia de Córdoba, la expresión será: Descripción ( L o c a l i d a d e s u-^-j IdProvincia=IdProvincia (

DescripProv=‘Córdoba’ (Provincias)))

Esa expresión se puede escribir, en el Cálculo relacional de tuplas, de la siguiente manera: Localidades (l) A Provincias (p) A l.ldProvincias = 1 p.Id Provicia A p.DescripProv = ‘Córdoba’

J

Se observarán las partes de la expresión: •

Inicia nombrando solo la descripción de la Localidad, lo que en Álgebra se denomina proyección.

•

Luego se defnen las relaciones con las que se trabaja.

•

Sigue con la igualdad para la reunión de las relaciones “Localidades” y “Provincias”.

•

Finaliza con las condiciones denominadas selecciones en Álgebra, unidas por el conector lógico A, para indicar que deben cumplirse todas (AND). También pueden conectarse con v (OR).

2.2.9.2 Cálculo relacional de dominios A diferencia del cálculo relacional de tuplas, aquí las variables se referen a los dominios de atributos y no a las tuplas. Para establecer las coincidencias y las diferencias con el Álgebra relacional y el cálculo relacional de tuplas, se volverá a la consulta: “Obtener todos los datos de los estudiantes masculinos de la universidad”, que ya había sido resuelta: •

En Álgebra relacional la expresión era: a Sexo=Masculino’ (Estudiantes)

•

En Cálculo relacional de tuplas: {e|Estudiantes(e) A e.Sexo = ‘Masculino’}

En cálculo relacional de dominios, se trabaja con una variable de dominio por atributo de cada relación que participa, que indica a qué relación pertenece y, luego, se utilizarán teniendo en cuenta el orden en que se las menciona. Por ello, se resolverá esa consulta en cálculo relacional de dominios: {abcdefg|(3a)(3b)(3c)(3d)(3e)(3f)(3g) (Estudiantes(abcdefg) A g = ‘Masculino’)}

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.3 Normalización

63

Se verán las distintas partes de la expresión: •

Primero se escriben las variables de dominio que representan a los atributos solicitados. Como en esta consulta no se pide alguno en particular, sino que se necesitan todos los datos de los estudiantes, se mencionan siete variables, una para cada atributo de la relación “Estudiantes” (abcdefg).

•

Después de la barra (|), se indica que la tupla formada por abcdefg debe pertenecer a la relación “Estudiantes”, y que el atributo g tiene valor "masculino".

Lo mismo sucede con la consulta con una reunión de relaciones, por ejemplo, Obtener las descripciones de las localidades de la provincia de Córdoba. En Álgebra se había resuelto como: Descripción ( L o c a l i d a d e s 1>"~J IdProvincia=IdProvincia (° DescripProv=‘Córdoba’ (Provincias)))

En cálculo relacional de tuplas, la solución planteada fue con la expresión: í Localidades (l) A Provincias (p) A l.ldProvincias = 1 < l.Descripcion > [_ p.Id Provicia A p.DescripProv = ‘Córdoba’ J Ahora, en cálculo relacional de dominios, la expresión será: {ab|(3a)(3b)(3c)(3d)(3e) (Localidades(abc) A Provincias(de)Ac = dAe = ‘Córdoba’)} Donde b es el atributo solicitado y corresponde a la descripción de la localidad en la relación “Localidades”. Aparecen las dos relaciones que se reunirán y, luego, las condiciones que se cumplirán. En este caso, incluye a la condición de reunión c=d, en la que el atributo e contiene la palabra Córdoba.

2.3 Normalización 2.3.1 Fundamentos de la normalización Un experimentado diseñador de base de datos relacionales —sin que importe la herramienta que utilice para sus propósitos— quizá conozca el porqué de la normalización. Sin embargo, si el mismo diseñador se sintiera con una gran experiencia en el diseño de bases de datos y no conociera el término “normalización” —o si conociera el término, pero no su propósito—, entonces estaría en un serio problema, pues dejaría de lado el concepto primigenio que fundamenta la tecnología de los motores de base de datos relacionales. Dicho de otro modo: no se podría considerar un experto en el diseño de bases de datos relacionales, si omitiera este concepto. A continuación, se describirán los conceptos que —tal vez- ayudarán a esclarecer el porqué de la normalización, cuya importancia se encuentra en el mismo nivel que el correcto manejo del lenguaje de consultas estructurado (SQL).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

64

2 - Modelo de datos relacional

En este capítulo solo se hará referencia al concepto asociado con las bases de datos relacionales y se omitirá su aspecto más amplio, es decir, el que se refere a las bases de datos en todas sus formas. ¿Por qué son tan importantes la normalización y el SQL? Porque se requerirá el manejo del SQL para interactuar con una base de datos relacional; entonces, es imprescindible comprender qué es una base de datos relacional. La normalización de datos se refere, precisamente, a este concepto, que signifca modelar una base de datos relacional y saber cómo se genera una estructura relacional de datos válida. Por esta razón, el concepto de estructura de datos no debería ocasionar ningún problema en su compresión, aunque, para que esta estructura sea relacional y válida, se requiere la compresión de algunas normas o principios teóricos que la fundamentan. La normalización de datos se refere a modelar una base de datos relacional y saber cómo se genera una estructura relacional de datos válida.

También se descubrirá —después de leer este capítulo y de haber realizado una intensa práctica— que, en algunos casos, el diseño se alcanza en forma espontánea; es decir que, de forma intuitiva, se logran las estructuras que, sin duda, ya poseen un estado relacional válido, sin que ello represente una difcultad o un proceso adicional en el diseño de la base de datos. Se podría agregar que, el lenguaje de consultas estructurado SQL, se comporta correctamente con una base de datos relacional normalizada en tercera forma normal (3FN). Esto es para que el motor de la base de datos funcione correctamente y para que tenga una respuesta apropiada. Una estructura no normalizada se puede procesar, también, por el motor de base de datos y acceder a ella a través de SQL, aunque existe la posibilidad de que se encuentren algunas difcultades y/o anomalías, distorsiones como redundancia de datos, valores no reales en sumatorias, etc. lo que contribuirá a que se piense que la herramienta no es útil. En resumen, SQL es un lenguaje de consultas estructurado que opera sobre bases de datos relacionales y la normalización —con sus formas normales— es el fundamento teórico-práctico que se requiere para que el diseñador de una base de datos logre una estructura relacional apropiada, que funcionará correctamente con el motor de la base de datos, a la que se accede a través del SQL. 2.3.2 A q u é s e r e f e r e l a n o r m a l i z a c i ó n Con normalización nos referimos:

Alfaomega

•

A cómo se estructuran los datos representados por el concepto de atributo en un conjunto de relaciones que los contienen.

•

A que los atributos no posean estructura interna.

•

A la dependencia que se forma entre los atributos dentro de una tupla. –

Que esta relación no se diluya en el acto de transformación.

–

Se mantenga persistente.

•

A cómo se establecen relaciones entre las entidades, a través de las estructuras de atributos (estado relacional – dependencia funcional).

•

A cómo se conforman estas estructuras de atributos. –

Para localizar un registro dentro de una relación, con una clave primaria.

–

Para poder relacionar una relación con otra, a través de estas estructuras de atributos, con claves primarias y claves foráneas. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.3 Normalización

–

Que los componentes de la clave primaria siempre contengan valores ciertos.

•

A la cantidad de atributos que componen la clave primaria, observando que esta cantidad sea mínima.

•

A la eliminación de la redundancia de datos, para que la transformación logre eliminar la repetición de datos, se sustituirán éstos, por valores de referencia que establecerán una relación con nuevas relaciones.

•

A que todas las referencias entre relaciones, a través de sus atributos, estén representadas. Que no se establezcan valores referenciales sin que existan las entidades que contienen las descripciones de estas referencias.

•

A la creación a una estructura lógica que sea fácil de comprender y de mantener.

•

A facilitar el control de la manipulación de datos para que no se violen las restricciones de integridad, en cuanto a: –

Inserción de flas.

–

Modifcación de datos.

–

Borrado de flas.

2.3.3 A q u é n o s e r e f e r e l a n o r m a l i z a c i ó n •

Al comportamiento de los atributos no clave.

•

Al tipo de los atributos. –

Referido a su contenido. _ Texto _ Número _ Fecha _ Otros

•

A la longitud de los atributos, ya que no tiene ninguna importancia el tamaño o dimensión de un atributo.

•

A la nomenclatura de atributos y relaciones. No importa cómo se nombran las relaciones y sus atributos.

•

A la ubicación de los atributos dentro de la cabecera de la relación. Representa lo mismo que un atributo esté en el primer lugar ordinal dentro de la cabecera de la relación o en cualquier otro orden.

•

A la cantidad de relaciones, ya que puede tener una estructura de tres relaciones o de 300.

•

A la cantidad de atributos en una relación y a la calidad de los datos que se cargan dentro de la entidad, más específcamente dentro de los atributos, ya que no tienen un valor intrínseco dentro de la normalización.

•

A la forma de manipulación de los datos, a los que se podrá acceder desde cualquier medio habilitado por el motor de la base de datos. Esto no le compete a la normalización.

•

A la compresión de los datos. Si alguno de los datos representa realmente una “caja negra”, a la normalización no le interesa, siempre y cuando esta información no pueda ser descompuesta en varios atributos distintos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

65

66

2 - Modelo de datos relacional

2.3.4 Normalización aspecto formal

Normalizar una base de datos signifca transformar un conjunto de datos que tienen una cierta complejidad en su entendimiento y que su distribución en el modelo provoca problemas de lógica en las acciones de manipulación de datos, tanto en las consultas como en la inserción y modifcación de ellos, en una estructura de datos que posea un diseño claro, donde estos datos guarden coherencia y no pierdan su estado de asociación.

Dado un conjunto de atributos y un conjunto de dependencias funcionales existentes entre los atributos que conforman un esquema de relación, se trata de transformar este esquema en un conjunto de n esquemas de relación, que satisfagan las siguientes premisas: •

Misma cantidad de información.

•

No alterar la dependencia funcional.

•

Reducir la redundancia de datos a su mínima expresión.

•

Reducir al mínimo los problemas de lógica en la administración de los datos.

2.3.5 C o n c e p t o d e n o r m a l i z a r Normalizar una base de datos signifca transformar un conjunto de datos que tienen una cierta complejidad en su entendimiento y que su distribución en el modelo provoca problemas de lógica en las acciones de manipulación de datos, tanto en las consultas como en la inserción y modifcación de ellos, en una estructura de datos que posea un diseño claro, donde estos datos guarden coherencia y no pierdan su estado de asociación. Estos datos tienen una distribución balanceada, lo que permite la observación de los mismos en forma clara, no redundante, y que, por encima de esto, su lógica sea comprensible, fácil de entender y de mantener. Esta estructura resultante se denomina base de datos normalizada. La transformación, desde el punto de vista de las entidades, signifca que se operarán diversas acciones, entre las que se pueden citar el agrupamiento de atributos y su descomposición, en la que los datos compuestos se expresarán como una colección de datos simples. Luego de estas transformaciones, quedarán conformadas las nuevas relaciones que cumplirán con determinadas restricciones, de acuerdo con el nivel de desarrollo alcanzado en la normalización. Las entidades están compuestas por una colección de dominios que, por lo general, califcan el concepto y establecen la semántica de la entidad a la que pertenecen, como, por ejemplo, formato, tipo, estilo, ubicación, defnición, etc. Estas relaciones contendrán la totalidad de los atributos originales, ni más ni menos de los que existían en la estructura no normalizada. Entonces, las relaciones se conformarán en una estructura de datos normalizada. Esta transformación se fundamenta por una serie de normas o reglas que establecen cómo se deben presentar las relaciones y sus atributos para que compongan una estructura normalizada. Estas normas o reglas se denominan formas normales. Este pasaje se puede realizar de diversas formas, según la comprensión que realice el involucrado en la tarea. Esto quiere decir que el acto de transformación de un conjunto de relaciones no normalizadas a una estructura normalizada de relaciones, se puede realizar con cualquier método. Concretamente, no existe una técnica estándar para poder efectuar esta acción. El que no exista una técnica de normalización no quiere decir que no se pueda crear una que lo lleve a realizar esta acción con éxito. Se debe aclarar que la expresión antes vertida no está relacionada con la acción de realizar las proyecciones de una relación que no satisface una forma normal con las relaciones que sí tienen un formato más deseable y sí satisfacen una determinada forma normal, sino a que el diseñador experimentado podrá establecer una técnica de elaboración del modelo que no requiera tener que generar relaciones no normalizadas, para luego pasarlas a normalizadas en una acción de proyección, sino que

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.4 Origen de los datos

67

podrá, quizá, como una opción entre tantas, implantar en forma directa la relación que ya satisface la forma normal deseada para ese modelo. Si bien el pasaje de un conjunto de relación no normalizadas a un conjunto de relaciones se puede realizar de cualquier forma, el resultado debe ser el mismo, independientemente del método que se haya utilizado. La bibliografía en la materia —consultada para la elaboración de este capítulo—difere con este autor en la manera de abordar el concepto “normalización”. Sin embargo, la metodología aquí utilizada se considera indispensable para la comprensión total del término. Si n diseñadores: •

parten del mismo origen de datos y los interpretan como la misma colección de datos que les permite observar la estructura inicial, por ejemplo, una planilla que contiene el conjunto de datos en una estructura no normalizada,

•

poseen el mismo nivel de conocimiento acerca del tema y cuentan con la misma documentación explicativa y

•

con el conocimiento apropiado sobre cómo realizar la transformación hasta llegar a una estructura normalizada de relaciones, es decir que todos saben realizar el pasaje a un estado normalizado,

pueden realizar la transformación con cualquier método de razonamiento o con cualquier procedimiento lógico, pero todos siempre deben llegar al m i s m o resultado. Objetivos de la normalización: 2.3.6 O b j e t i v o s d e l a n o r m a l i z a c i ó n •

Reducir la redundancia de datos y, por lo tanto, las inconsistencias.

•

Facilitar el mantenimiento de los datos y de los programas.

•

Evitar anomalías en las operaciones de manipulación de datos.

•

Reducir el impacto de los cambios en los datos.

• • • •

Reducir la redundancia de datos y las inconsistencias. Facilitar el mantenimiento de los datos y de los programas. Evitar anomalías en las operaciones de manipulación de datos. Reducir el impacto de los cambios en los datos.

2.4 Origen de los datos 2.4.1 Los datos Se refere a la obtención de los datos, recurso del que se parte para modelar y lograr, como resultado, una estructura de relaciones normalizadas. Los datos pueden proceder de algún documento, de la información suministrada por un especialista en el tema (experto califcado o informante clave) o de su propia observación. Cuando el origen de los datos proviene de un documento, ya se tiene gran parte de la tarea realizada y deberá hacer apuntes sobre algunas sugerencias. Cuando la información proviene de un especialista, se tendrá, también, gran parte de la tarea resuelta; es importante documentar, en detalle, la información que vaya suministrando el especialista. En todos los casos, la interpretación —si existiera— debe ser acotada y validada con él y es recomendable que no se viole esa frontera, puesto que el acto de interpretar (explicar acciones, dichos o sucesos que pueden ser Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

68

2 - Modelo de datos relacional

entendidos de diferentes modos) no signifca lo mismo que entender (Tener las ideas claras de las cosas o saber con perfección algo). Esto puede acarrear serias discrepancias en el resultado obtenido respecto de la realidad que debe refejar el modelo. Si se tuvieran dudas acerca de algún tema determinado, se evitará la interpretación. En estos casos, es indispensable el contacto con un especialista que suministrará la información necesaria que despejará todas las dudas. Pero cuando el origen de datos proviene de la observación, y no se posee un documento o un especialista califcado que informe acerca del circuito de datos, es conveniente que se establezca un límite de entendimiento e interpretación del problema sobre el que se proyectará. Es claro que, cuando es uno el que observa una problemática, tiende a realizar una macrovisión del problema y de sus límites, desde los conocimientos que posee de la difcultad que desea resolver. Si el conocimiento del problema tratado es amplio, la normalización comprenderá una vasta cantidad de entidades y de atributos. Ahora, si el conocimiento es mínimo, la normalización tenderá a ser pequeña y endeble. Esta contraposición pone de manifesto que, cuando se realiza el diseño de una base de datos, siempre es conveniente poseer documentación que avale el diseño o la información suministrada por un especialista en el tema. Lo que queda claro es que fuera cual fuese el problema que se transformará en una base de datos normalizada, se deberá aprender del problema para entenderlo con total claridad. Se recuerda que existe un dominio del conocimiento existente sobre el tema por tratar y esto es la totalidad de conocimiento sobre el tema, pero seguramente esta totalidad de conocimiento no representa el origen de los datos con los que se debe trabajar. Se trabajará con una porción acotada, que representa el problema en sí mismo. Entonces, se podrá determinar como el origen de los datos el dominio del problema. Éste está, sin dudas, contenido en el dominio del conocimiento general del tema que se tratará, pero esta acotado exclusivamente al problema. 2.4.2 P r o b l e m á t i c a a s o c i a d a a l o r i g e n d e d a t o s El ambiente —desde el punto de vista de la informática— es el conjunto de procedimientos y acciones que se producen en el tratamiento de los datos y que fundamentan la estructura en la que éstos actúan.

El origen de los datos no tiene ningún sentido si no se establece en el ambiente en el que aquellos interactúan. El ambiente, quizá más claramente expresado —desde el punto de vista de la Informática— como entorno, es el conjunto de procedimientos y acciones que se producen en el tratamiento de los datos y que fundamentan la estructura en la que éstos actúan. Este fundamento o conocimiento es la semántica, que se defne como el conjunto de reglas que proporcionan el signifcado de funcionalidad de un proceso y que indican cómo se deben presentar los datos (o cómo deben ser presentados) en la estructura normalizada, para que sea funcional con respecto al propósito de la solución del problema.

Fig. 2.1 Dominio del conocimiento total sobre el tema del problema. Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

En la Fig. 2 . 1 , el recuadro externo simboliza el dominio de todo el conocimiento disponible sobre el tema que se normalizará y el círculo interno el conocimiento concreto sobre el que tratará la normalización. Lo que se intenta expresar es que la información que se obtendrá en el origen de datos, nunca alcanzará al total de la información disponible acerca del tema, sino que solo será una porción bien defnida y acotada. Es conveniente que se tenga una idea muy clara sobre el dominio del problema y cuál es su límite, pues esto permitirá que se alcance un resultado defnido y limitado que se manejará con facilidad.

69

s El término “semánti ca” se refere a los aspectos del signifcado, sentido o interpretación del signifcado de un determinado elemento, símbolo, pala bra, expresión o representación formal.

2.4.3 L o s r e s u l t a d o s Normalizar, ¿qué signifca? En los párrafos precedentes, se expresó que n diseñadores siempre deben llegar, bajo ciertas condiciones, a un mismo resultado. En su origen, el conjunto de datos es el mismo. Por esta razón, en el resultado obtenido luego de realizar la normalización, no debería faltar ningún dato y, tampoco, obtener otros adicionales. El mismo resultado se logra cuando se tiene el mismo conjunto de datos, que realiza una correcta comprensión de la problemática, de la que se establecerá una semántica. Dentro de ésta, se prestará especial atención a dos de los elementos —que forman parte del vocabulario específco de la problemática de esta conceptualización—: los datos y los procesos de datos. De la observación de los datos, junto con su comportamiento funcional, se establecerán las entidades que tendrán un conjunto de características que las califcarán y determinarán los atributos de la entidad. Los procesos internos son las acciones que se desprenden del análisis de la problemática, que darán un estado de asociación, actividad y dependencia funcional entre los atributos establecidos en cada entidad. Luego de realizar este análisis y una vez constituidos los componentes que actuarán en esta problemática, se diseñará un modelo de datos que se encuentre normalizado y que la represente de la manera más fel posible. Este modelo no tiene mayores posibilidades de que se represente de otra forma más que la establecida, puesto que no existe una diversidad de estructuras o de relaciones para el mismo concepto y el conjunto de estructuras básicas está limitado a un número muy pequeño de éstas. Solo, en casos muy puntuales, existen estructuras compatibles entre sí, con la característica de que son levemente distintas, pero siempre una de ellas es más deseable que la otra en cuanto a las premisas del modelo relacional. Entonces, si la representación fuese distinta, se estaría ante el modelado de una problemática distinta de la entendida.

2.5 Las formas normales 2.5.1 Las normas Está claro que las seis formas normales no expresan las cosas simplemente. Es por esto que se expresarán estos conceptos, que tienen categoría de normas o de reglas, de otra manera. Para hacer una correcta interpretación de cada forma normal, se realizará un análisis detallado de la semántica que expresa los términos que utiliza y su porqué. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

70

2 - Modelo de datos relacional

2.5.2 Dominio (extensión conceptual) La menor unidad semántica de información es el valor de un dato indivisible: un escalar; por ejemplo, el código de cliente. Al ser este valor indivisible es de característica atómica; es decir, el dato no posee una estructura interna de composición, que no se debe interpretar como la falta de semántica del contenido, sino como la imposibilidad de dividir el dato que compone el dominio. Otra característica del dominio es la homogeneidad de sus valores, todos del mismo tipo. Por ejemplo, el dominio “códigos de proveedores” es el conjunto de todos los posibles números de proveedores. Los atributos se defnen sobre los dominios subyacentes. Cada atributo se defne sobre un solo dominio existente. En su semántica, el dominio restringe su utilización, puesto que su defnición no solo se refere a las características de contenido como un valor de tipo cierto (ej. numérico), sino que va más allá y establece un tipo descriptivo propio. Por ello, dos atributos con contenido de tipo numérico son comparables si poseen la misma semántica de dominio. Para explicarlo de forma comparativa: si un atributo contiene el código de cliente y otro, el código de barrio, ambos pueden ser numéricos, pero no se pueden comparar, pues pertenecen a distintos dominios. ¿En dónde actúa y para qué? El motor de la base de datos solo permitirá, ejerciendo un control, que los atributos de las relaciones se carguen con valores permitidos por la semántica de su dominio. Ya se verá, más adelante, cómo se defne esto en el nivel de diseño de estructura. 2.5.3 F u n d a m e n t o t e ó r i c o d e l a s n o r m a s 2.5.3.1 Dependencia Funcional La Dependencia Funcional o DF es una limitación al conjunto de relaciones aceptadas, según las formas normales. Además, establece una relación fuerte y persistente entre dos atributos, al punto que el cambio de valor de uno determina en su valor al otro. Las restricciones de la relación, en un momento dado, deben poder verifcar el diseño de la relación. Las tuplas deben, en todo momento, convalidar el diseño de la relación y sus restricciones. La DF permite la formulación de algunas restricciones del diseño que se construye en la base de datos. La DF establece en forma forzada que los valores contenidos en un conjunto de atributos defnan unívocamente el valor de otro conjunto de atributos. Definición: Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R (R.X determina funcionalmente a R.Y), denotado como:

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

71

R.X

à

R.Y

Significa que un solo valor Y en R está asociado a cada valor X en R. Donde X, Y pueden ser compuestos.

Ejemplo: Sea el atributo X clave primaria en R, el atributo Y en R debe depender funcionalmente de forma forzada de X, por definición de clave primaria. R.X

à

R.Y

Ahora, ejemplificando con una relación R con una estructura del tipo factura (reducida), los atributos no clave de R —que representan el conjunto Y cliente, fecha, total— dependen cada uno de ellos de la clave primaria en R —representada por R.R#— , entonces: R.R# à R.cliente R.R# à R.fecha

R.R# à R. (cliente, fecha, total)

R.R# à R.total Por definición de DF y partiendo de la premisa de que X no es obligadamente clave primaria, al presentarse un mismo valor de X en diferentes tuplas dentro de R deben tener asociado el mismo valor de Y.

Otra definición: Dada una relación R y el atributo Y de R tiene dependencia funcional del atributo X de R. Significa que, cuando en dos tuplas de R, el valor X sea el mismo, entonces, debe corresponderles forzadamente el mismo valor de Y: R.R# à R.(cliente, fecha, total) En la siguiente planilla se muestra un ejemplo esperado, según la definición antes expuesta. R.R#

R.(cliente, fecha, total)

Número

Cliente

Fecha

Total

1

Miranda

01/01/2000

100,20

2

López

25/02/2009

23,10

1

Miranda

01/01/2000

100,20

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

72

2 - Modelo de datos relacional

2.5.3.2 Dependencia Funcional Completa: Dada una relación R, el atributo Y de R depende funcionalmente, “de forma completa”, del atributo X de R. Depende funcionalmente de X y no depende funcionalmente de ningún subconjunto de X. Si consideramos la relación: RA.(R#,A#) à RA.(cliente, fecha, total, nombre artículo, precio) se observa que esta relación tiene dos conjuntos de valores que dependen cada uno de una parte de la clave primaria. El cliente, fecha y total dependen de la parte de la clave primaria R#, mientras que nombre artículo y precio dependen de parte de la clave A#. Por lo tanto, en esta relación expuesta no se cumple la dependencia funcional completa. Si se descompone la relación RA en dos relaciones como se muestra a continuación: R.R# à R.(cliente, fecha, total) A.A# à A.(nombre artículo, precio) Las relaciones R y A ahora poseen dependencia funcional completa, pues, para el caso de R, todos los atributos dependen por completo del atributo X de R. También se hace extensiva esta condición para la relación A. 2.5.4 E n u m e r a c i ó n d e l a s n o r m a s Las formas normales son más de tres pero, para poder crear, entender y utilizar una base de datos relacional, que es nuestro objetivo, es sufciente con concebir una estructura de datos en tercera forma normal (3FN). A continuación, se defnen las formas normales: Primera Forma Normal (1FN) – Una relación se encuentra en primera forma normal si, y solo si, todos los dominios simples subyacentes de los atributos contienen valores atómicos y monovalentes. Segunda Forma Normal (2FN) –

Una relación se encuentra en segunda forma normal si, y solo si, se encuentra en 1FN y, además, todos los atributos no clave dependen por completo de la clave primaria.

Tercera Forma Normal (3FN) –

Una relación se encuentra en tercera forma normal si, y solo si se encuentra en 2FN; y si ningún subconjunto de atributos no claves tiene dependencia funcional entre sí.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

73

Atributos no primarios: se refere a atributos no clave y que no pertenecen a ninguna combinación de claves candidatas posibles. Forma Normal de Boyce-Codd (FNBC) Una relación está en FNBC si, y solo si, todo determinante es una clave candidata. Determinante es el atributo del que depende, funcionalmente y de manera completa, otro atributo o conjunto de éstos. Una relación está en FNBC si primero está en tercera forma normal y luego, si, y solo si, las únicas dependencias funcionales triviales se encuentran dadas entre la clave primaria y uno o varios atributos. Cuarta Forma Normal (4FN) Una relación R está en cuarta forma normal, si primero está en forma normal Boyce-Codd y, además, todas las dependencias multivaluadas en esta relación R son “dependencias funcionales”. El concepto de dependencia multivaluada, pero que no son dependencias funcionales, es lo que impide que una relación se encuentre en cuarta forma normal. Quinta Forma Normal (5FN) Una relación R está en quinta forma normal si, y solo si, toda dependencia de reunión en R es una consecuencia de las claves candidatas en R. Una relación R está en 5FN si, y solo si, toda dependencia de reunión está condicionada por las claves candidatas de R.

2.5.5 Interpretación y aplicación de las formas normales Se inicia la interpretación con un conjunto de datos que conforman una estructura clásica de un sistema de ventas. Estos datos están conformados por tres (3) facturas de una empresa cualquiera, que solicita crear una base de datos de ventas. Estos datos se muestran en una planilla que, de ahora en más, se denominará relación “Origen de datos” y que representa la totalidad de los datos que hay en las facturas de esta empresa, tal como muestra la siguiente relación. Relación Origen de los datos Sucursal y número de factura

Código Fecha de la Forma de pago del factura factura cliente

01 01 01 107 110

ALVAREZ

3/01/06

E E E CC E

LIZ

01 02 10 08 20

3/01/06

E

110

LIZ

10

01-500

1/01/06

01-500

1/01/06

01-500

1/01/06

01-501

2/01/06

02-500 02-500

Precio unitario del artículo

Subtotal del artículo

Total de la factura

1.25

3.75

48.20

REGLA

3 6 8 4 2

HOJAS

2

Nombre del Código del Nombre del Cantidad del cliente artículo artículo artículo

ALVAREZ ALVAREZ CASTRO

LÁPIZ GOMA HOJAS COMPÁS

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

0.75

4.50

48.20

5.00

40.00

48.20

4.00

16.00

16.00

2.45

4.90

14.90

5.00

10.00

14.90

Alfaomega

2 - Modelo de datos relacional

74

2.5.5.1 Interpretación de la Primera Forma Normal (1FN) Se recordará que la 1FN se definió de la siguiente manera: una relación se encuentra en Primera Forma Normal si, y solo si, todos los dominios simples subyacentes de los atributos contienen valores atómicos y monovalentes. Si observa el origen de datos de la relación “Origen de datos”, las columnas que contienen una composición de datos o combinación de datos serán, en este caso, de nuestro interés. La primera columna, “Sucursal y Número de factura”, contiene una combinación de datos: “Sucursal” y “Número de factura”. Esta columna puede dividirse en dos columnas con valores atómicos: por un lado, “Sucursal” y, por otro, “Número de factura”. Entonces, al aplicar una parte de la 1FN —la referida a atributos atómicos—, resulta en un cambio de la relación “Origen de datos”, que queda de la forma siguiente:

Relación Origen de los datos Sucursal

Número de factura

Fecha de la factura

01 01 01 01 02 02

500 500 500 501 500 500

1/01/06 1/01/06 1/01/06 2/01/06 3/01/06 3/01/06

Cuando se defne 1FN y se refere a atributo monovalente, se quiere expresar que, dentro de una estructura normalizada, los valores no pueden repetirse y que deben expresarse una sola vez por ocurrencia. Las tuplas, que tienen repetidas varias veces la misma información, se reducirán a una única instancia. En otras palabras, se elimi narán los grupos repetitivos.

Alfaomega

Forma Código de pago del factura cliente

E E E CC E E

01 01 01 107 110 110

Código Cantidad Precio Subtotal Nombre del Nombre del unitario Total de la del del del cliente artículo del artículo artículo artículo factura artículo ALVAREZ ALVAREZ ALVAREZ CASTRO

LIZ LIZ

01 02 10 08 20 10

LÁPIZ GOMA HOJAS COMPÁS REGLA HOJAS

3 6 8 4 2 2

1.25

3.75

48.20

0.75

4.50

48.20

5.00

40.00

48.20

4.00

16.00

16.00

2.45

4.90

14.90

5.00

10.00

14.90

Cuando se define 1FN y se refiere a atributo monovalente, se quiere expresar que, dentro de una estructura normalizada, los valores no pueden repetirse y que deben expresarse una sola vez por ocurrencia. Las tuplas que tienen repetidas varias veces la misma información se reducirán a una única instancia. En otras palabras, se eliminarán los grupos repetitivos. En este caso, una factura posee un cliente, una fecha de emisión, una sucursal, un número de factura, un total y una forma de pago, los valores de estos atributos se repiten varias veces para la misma factura. Veamos la siguiente relación, en la que cada factura está sombreada por un contraste diferente. Estos datos deben presentarse una sola vez en la estructura normalizada en 1FN. Entonces, sucursal, número de factura, fecha, forma de pago, identificación del cliente, nombre del cliente y total de factura deben figurar una sola vez.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

75

Relación Origen de los datos

Sucursal

01 01 01 01 02 02

Precio Número Fecha de la Forma Código Nombre del Código Nombre del Cantidad unitario de de pago del del del cliente artículo del factura factura cliente artículo artículo factura artículo

500 500 500 501 500 500

E E E CC E E

1/01/06 1/01/06 1/01/06 2/01/06 3/01/06 3/01/06

01 01 01 107 110 110

ALVAREZ ALVAREZ ALVAREZ CASTRO

LIZ LIZ

01 02 10 08 20 10

LAPIZ GOMA HOJAS COMPAS REGLA HOJAS

3 6 8 4 2 2

Subtotal del artículo

Total de la factura

1.25

3.75

48.20

0.75

4.50

48.20

5.00

40.00

48.20

4.00

16.00

16.00

2.45

4.90

14.90

5.00

10.00

14.90

Si se reducen las ocurrencias de los datos que se repiten, se perderá el detalle de la factura; entonces, para que se realice la eliminación de la repetición y para que no se pierda el detalle de la factura, compuesto por los atributos restantes —los que no se repiten—, no hay otro camino que descomponer los datos de la relación original en dos tablas: una que contenga los datos que se repiten y otra, con los datos que no se repiten, tal como lo ilustran las siguientes tablas:

Tabla A Sucursal

Número de factura

Fecha de la factura

Forma de pago factura

Código del cliente

Nombre del cliente

Total de la factura

01 01 01 01 02 02

500 500 500 501 500 500

1/01/06

E E E CC E E

01 01 01 107 110 110

ALVAREZ

48.20

ALVAREZ

48.20

1/01/06 1/01/06 2/01/06 3/01/06 3/01/06

ALVAREZ

48.20

CASTRO

16.00

LIZ LIZ

14.90

14.90

Tabla B Código del Nombre del Cantidad del Precio unitario artículo artículo artículo del artículo

01 02 10 08 20 10

LAPIZ GOMA HOJAS COMPAS REGLA HOJAS

3 6 8 4 2 2

1.25

Subtotal del artículo 3.75

0.75

4.50

5.00

40.00

4.00

16.00

2.45

4.90

5.00

10.00

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

76

Ahora se tienen dos tablas separadas: la tabla “A” tiene los atributos que contienen los datos repetidos, y la tabla “B”, los atributos que no contienen los datos repetidos por grupo (entiéndase por grupo a una factura). En la tabla “A”, es evidente que los datos se repiten conformando un grupo en el que quedan más de una tupla o fila con los mismos datos. En este caso, hay que reducir las tuplas duplicadas y dejar solo una por grupo. Hasta ahora se ha realizado la separación de los atributos y datos en dos grupos: uno que contiene los datos que se repiten y el otro, con los datos que no se repiten (tabla “B”). Entonces, en la tabla “A” se eliminarán las ocurrencias duplicadas de cada grupo, pero si esto se realiza sin establecer de antemano un mecanismo de referencias entre las tablas, se perderá la relación entre éstas que, por ahora, es evidente en forma visual. En definitiva, no podrá establecer qué artículos corresponden a qué facturas y se tendrán los detalles sin saber a qué factura corresponden. Por esta razón, se debería dejar solo una fila de cada grupo en la siguiente tabla:

De este conjunto de tres filas, que repiten el mismo valor, solo debe quedar una.

Sucursal

Número de factura

Fecha de la factura

Forma de pago factura

Código del cliente

Nombre del cliente

Total de la factura

01 01 01 01 02 02

500 500 500 501 500 500

1/01/06

E E E CC E E

01 01 01 107 110 110

ALVAREZ

48.20

ALVAREZ

48.20

Esta fila que no repite no se alcanza por este mecanismo. De este conjunto de dos filas, que ¿f repiten el mismo valor, solo debe quedar una.

1/01/06 1/01/06 2/01/06 3/01/06 3/01/06

ALVAREZ

48.20

CASTRO

16.00

LIZ LIZ

14.90 14.90

q u e d a n d o así lo q u e muestra la tabla de la izquierda:

Precio Código Cantidad unitario Nombre del del del del artículo artículo artículo artículo

Subtotal del artículo

Sucursal

Número de factura

Fecha de la factura

Forma de pago factura

Código del cliente

01

500

1/01/06

E

01

ALVAREZ

48.20

01

LAPIZ

3

1.25

3.75

01

501

2/01/06

CC

107

CASTRO

16.00

02

GOMA

6

0.75

4.50

02

500

3/01/06

E

110

LIZ

14.90

10

HOJAS

8

5.00

40.00

08

COMPAS

4

4.00

16.00

20

REGLA

2

2.45

4.90

10

HOJAS

2

5.00

10.00

Nombre del Total de la cliente factura

De esta forma, las d o s tablas no contienen valores repetidos, pero surge — c o m o ya se planteará c o n otro problema— que los datos que antes estaban integrados en

Alfaomega

Bases de Datos - Reinosa, M a l d o n a d o , M u ñ o z , Damiano, Abrutsky

2.5 Las formas normales

77

una sola relación, y que tenían correspondencia entre sí, ahora están disociados. Los datos se encuentran en dos relaciones del margen inferior de la página anterior y no se puede establecer su dependencia funcional, sin saber qué detalle corresponde a cada factura; por ello, en la relación inferior derecho, se colorearon los grupos que pertenecen a la misma factura para individualizarlos. En otras palabras, no se sabe qué artículo de detalle corresponde a qué factura, salvo por su color de fondo y por su orden. Entonces, surge una nueva necesidad que es establecer una referencia que indique qué artículos de los detalles corresponden a qué factura. También, es necesario establecer el nombre para cada relación, para poder identificarlas claramente en la nueva estructura resultante: •

A la relación en la que se produce la eliminación de los grupos repetitivos, se la denominará “Factura”.

•

A la relación en la que quedaron los atributos que no conforman el grupo repetitivo, se la denominará “Detalle de factura”.

De esta manera, se establece, como identificador unívoco (PK) en la relación “Factura”, la combinación de las columnas “Sucursal” y “Número de factura”. Relación Detalle de factura Relación Factura Sucursal

Número de factura

Fecha de la factura

Forma de pago factura

Código del cliente

01

500

1/01/06

E

01

ALVAREZ

48.20

01

501

2/01/06

CC

107

CASTRO

16.00

02

500

3/01/06

E

110

LIZ

14.90

Nombre del Total de la cliente factura

Nombre del artículo

Cantidad del artículo

Precio unitario del artículo

Subtotal del artículo

01

LAPIZ

3

1.25

3.75

02

GOMA

6

0.75

4.50

10

HOJAS

8

5.00

40.00

08

COMPÁS

4

4.00

16.00

20

REGLA

2

2.45

4.90

10

HOJAS

2

5.00

10.00

Código del artículo

Relación Factura

Sucursal

Número de factura

Fecha de la factura

Forma de pago factura

Código del cliente

Nombre del cliente

01

500

1/01/06

01

501

2/01/06

E

01

ALVAREZ

48.20

CC

107

CASTRO

16.00

02

500

3/01/06

E

110

LIZ

14.90

Total de la factura

Estas dos columnas conforman la clave primaria de la tabla “Factura”.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

78

¿Por qué la combinación de ambos? La columna “Número de factura” (relación “Factura”) tiene valores que se repiten en dos facturas distintas (valor 500), pero se puede observar que provienen de dos sucursales diferentes. Por esta razón, el número de factura, para este modelo de datos, es insuficiente como identificador o clave primaria. Para que se logre una localización inequívoca de cada registro, se incorporará otro atributo complementario que ayudará a tal efecto; en este caso, el atributo “Sucursal”. Este identificador inequívoco, como se definió en los párrafos precedentes, se denomina clave primaria y se representa con la sigla PK (Primary Key). La relación que se establece entre el conjunto clave primaria y el conjunto formado por los atributos no claves es unívoca. Cada componente de la clave primaria se relaciona unívocamente con un único conjunto de valores de atributos no clave. La forma que se tiene para relacionar las relaciones “Detalle de factura” y “Factura”, es que cada registro del detalle de factura pueda indicar, con información propia del registro, con qué registro se asocia dentro de la relación “Factura”. Esto se logrará si se incorporan, dentro de la relación “Detalle de factura”, los componentes de PK de la relación “Factura”. Entonces, se agregarán las columnas que componen la PK de la relación “Factura” en la relación “Detalle de Factura”:

Relación Factura

Relación Detalle de Factura

Pk

Número Código

Número Sucursal de factura

Fecha de la factura

01

500

1/01/06

01

501

2/01/06

02

500

3/01/06

Forma Código de pago del factura cliente

E CC E

01 107 110

Nombre del cliente

Total de la factura

ALVAREZ

48.20

CASTRO

16.00

LIZ

14.90

Sucursal

de

del

factura artículo

01 01 01 01 02 02

500 500 500 501 500 500

01 02 10 08 20 10

Nombre del artículo

LAPIZ GOMA HOJAS COMPAS REGLA HOJAS

Cantidad Precio Subtotal del unitario del del artículo artículo artículo

3 6 8 4 2 2

1.25

3.75

0.75

4.50

5.00

40.00

4.00

16.00

2.45

4.90

5.00

10.00

Columnas agregadas en la tabla “Detalle de Factura”, para establecer la relación con la tabla “Factura”.

Dentro de la relación “Detalle de Factura”, es visible que hay datos duplicados luego de arrastrar la clave primaria desde la relación “Factura”, en este caso, “Sucursal” y “Número de factura”. La cuestión es que, cuando se construye una estructura relacional en un base de datos relacional, la única forma de establecer la relación entre las relaciones es arrastrando la PK de una relación hacia la otra. Si bien hay redundancia de datos, ésta es una redundancia controlada y necesaria para establecer el estado de relaciones y de dependencias entre los datos, que no se debe perder en la creación del nuevo modelo. En la relación “Detalle de factura”, la PK, que se trajo desde la relación “Factura”, no es suficiente para identificar las filas de la relación “Detalle de factura” en forma inequívoca. Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

79

¿Por qué? Porque se repite la combinación de las columnas “Sucursal” y “Número de factura”. Ahora, si se agregara algún componente nativo de la relación, quizá se logre una combinación única. La correcta sería “Código de artículo”, entonces, quedaría (relación “Detalle de Factura”): Columnas que componen la clave primaria para cada tabla

Relación Detalle de Factura PK Número Sucursal de factura

01 01 02

500 501 500

Fecha de la factura

Forma de pago factura

Código del cliente

Nombre del cliente

Total de la factura

1/01/06

E CC E

01 107 110

ALVAREZ

48.20

2/01/06 3/01/06

• Clave primaria compuesta

CASTRO

16.00

LIZ

14.90

Sucursal

Número Código Cantidad Precio Subtotal de del del unitario Nombre del del artículo factura artículo artículo del artículo artículo

01 01 01 01 02

500 500 500 501 500

02

500

01 02 10 08 20 10

3 6 8 4 2 2

1.25

LAPIZ

3.75

0.75

GOMA

4.50

5.00

HOJAS

40.00

4.00

COMPAS

16.00

2.45

REGLA

4.90

5.00

HOJAS

10.00

Fk

\ Clave foránea hacia la tabla “Factura”.

Esta nueva combinación de atributos sí identifica a cada fila de la relación. La clave primaria se simbolizará con PK, que será el identificador inequívoco de la tupla dentro de la relación, que se podría componer con uno o más atributos, la que será mínima, ya que en una relación se podrían establecer varias combinaciones de clave primaria; pero solo será válida y conveniente la que se forme con la menor cantidad de atributos que mantenga la condición de unicidad. La clave foránea se simbolizará con FK (Foreign Key) y se recordará que es el identificador de la relación que tendrá una relación determinada para establecer un vínculo con otra relación. Estas relaciones, que integrarán la nueva estructura, se vincularán entre sí de forma fácil, sin perder la dependencia funcional establecida en la estructura antes de ser normalizada, y cuya lógica sea fácil de entender y mantener. Lo que interesa en la normalización son las estructuras de datos. Por esta razón, se verá, a continuación, cómo han quedado las estructuras de datos en su conversión a 1FN. Es conveniente declarar las claves primarias con la sigla PK a la izquierda de los atributos que la componen y se los identificará con una sola expresión, “ P K ” . En el caso de que la clave primaria sea compuesta, se adoptarán las medidas para que se interpreten correctamente cuáles son los atributos integrantes. Para la clave foránea, se utilizará la sigla FK y se la ubicará a la derecha de los atributos que intervienen. En caso de que la FK sea compuesta, se manejará el mismo método que para la PK.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

80

2 - Modelo de datos relacional

Lo correcto, en ambas situaciones, para clave compuesta o clave simple.

Pk

Suc

Pk

Nro

Nro

El modelo en estudio, transformado a 1FN, se representa como sigue (Modelo 1FN):

Modelo 1FN: Factura Pk

Detalle de Factura Sucursal

Sucursal Número de factura

Pk

Número de factura

Fecha de la factura

Código del artículo

Forma de pago factura

Nombre del artículo

Código del cliente

Cantidad del artículo

Nombre del cliente

Precio unitario del artículo

Total de la factura

Subtotal del artículo

Fk

Cada una representa una relación del modelo de datos que se está diseñando y que contienen la misma cantidad de datos que el modelo original, y mantienen la dependencia entre los componentes igual que en el primer diseño. 2.5.5.2 Interpretación de la Segunda Forma Normal (2FN) Una relación se encuentra en segunda forma normal si, y solo si, se encuentra en 1FN y si todos los atributos no clave dependen por completo de la clave. Que refiera a que primero se encuentre en Primera Forma Normal deja sentado explícitamente que nunca se puede llegar a Segunda Forma Normal sin antes cumplir con la Primera. Cuando se refiere a que los atributos no clave dependen por completo de la clave primaria y no a una parte de ella, se debe entender como atributos no clave a todos los atributos que no componen la clave primaria. Ninguno de ellos dependerá de una parte de la clave primaria. Si un atributo no clave hace referencia una parte de la clave primaria, se interpretará que existe un subconjunto de la PK que satisface una dependencia funcional, y por ello no se cumplimentará la 2FN. Al hacer referencia a una parte de la clave primaria, se interpretará que no existe un subconjunto de la PK que satisface una dependencia funcional con un atributo no clave Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

81

de la relación. Cuando la explicación habla de algún atributo no clave, no se refiere a cualquiera, sino a uno determinado que mantiene esa DF con otro perteneciente a la clave primaria. Esta DF podría también ser compuesta en cualquiera de los extremos. Si existe un atributo “A”, componente de la clave primaria, que determina el contenido del atributo “B”, que no pertenece a la clave primaria, entonces no se cumple la Segunda Forma Normal. Es necesaria una clave primaria compuesta, conformada por varios atributos, para que se pueda verificar esta situación. En el caso de la clave primaria simple, no hay razones para analizar la Segunda Forma Normal, pues se cumple por defecto. Si en las dos relaciones que hasta ahora se tienen como resultado, podemos detectar la situación de que un atributo no clave depende de uno o varios integrantes de la clave primaria y no depende de toda la clave primaria, entonces encontramos un caso de Segunda Forma Normal. Estas son las dos relaciones:

Relación Factura

Relación Detalle de Factura

Número Fecha de la Forma Código Nombre del Total de la Precio Sucursal de factura factura de pago del Número Código Código Cantida Cantidad Subtotal cliente factura unitario Nombre del factura cliente Sucursal de del del del del artículo factura artículo artículo artículo artículo 01 500 1/01/06 E 01 ALVAREZ 48.20 01

501

2/01/06

CC

107

CASTRO

16.00

02

500

3/01/06

E

110

LIZ

14.90

01 01 01

500 500 500

01 02 02

501 500 500

01 02 10 08 20 10

3 6 8 4 2 2

1.25

LAPIZ

3.75

0.75

GOMA

4.50

5.00

HOJAS

40.00

4.00

COMPAS

16.00

2.45

REGLA

4.90

5.00

HOJAS

10.00

Estas columnas son los atributos no clave.

En la relación “Factura”, se debería encontrar que algún atributo no clave depende de una parte de la clave primaria (PK). Por ejemplo, la fecha ¿podría depender solamente de la “Sucursal” o solo del “Número de factura”? Claramente, n o , la fecha es un atributo que depende de la PK completa. Para la primera factura, cuya sucursal es 01 y número de factura 500, la fecha se asocia en el momento en que se generó la factura; ésta está representada por ambos componentes de la PK, por lo tanto, la fecha depende por completo de la PK, y no de una parte de ella. Para los demás componentes de esta relación, se podría llegar a la misma conclusión. ¿Por qué actúan en forma conjunta los dos atributos de la clave primaria y se deben interpretar como una unidad?

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

82

2 - Modelo de datos relacional

No es lo mismo la factura 500 de la sucursal 01 que la factura 500 de cualquier otra sucursal. Cada sucursal tendrá —sin dudas— la factura 500, que corresponderá cada una a un momento particular y con distintos valores asignados. Por esta razón, para distinguir entre tantas facturas número 500 es imprescindible encontrar un elemento que las caracterice y que permita individualizarla, este es el atributo “Sucursal”. Se analizará la siguiente relación:

Relación Detalle de Factura PK Sucursal

Código Número de del factura artículo

Cantidad del artículo

Precio unitario del artículo

Nombre del artículo

Subtotal del artículo

01 01 01 01 02

500 500 500 501 500

01 02 10 08 20

3 6 8 4 2

1.25

LAPIZ

3.75

0.75

GOMA

4.50

2.45

REGLA

4.90

02

500

10

2

5.00

HOJAS

10.00

5.00

HOJAS

40.00

4.00

COMPAS

16.00

Fk

Subconjunto de la clave primaria que determina los atributos no primarios dentro de la relación.

Columnas no primarias que están asociadas al código del artículo, que integran la clave primaria.

Aquí, sí existe una relación entre atributos no clave y un componente de la clave primaria. Este caso, es la relación directa que existe entre la columna “Nombre del artículo” y “Precio unitario del artículo”, con el atributo “Código de artículo”, componente de la clave primaria. Si cambia el código del artículo debe cambiar, necesariamente, la descripción del artículo y el precio. 2.5.5.2.1 ¿Cómo solucionar esta situación? Se descompondrá la relación “Detalle de Factura” en dos relaciones: una que se mantendrá con el nombre “Detalle de Factura” y otra que se denominará “Artículos”. Se extraerá de la relación “Detalle de Factura” las columnas correspondientes al nombre del artículo y al precio, que se encontrarán en la relación “Artículos”. Además, se establecerá un vínculo entre las dos relaciones, tal como se detallará a continuación:

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

83

Relación Artículos

Relación Factura

PK

Pk Forma de pago factura

Código del cliente

Nombre del cliente

E

01

ALVAREZ

48.20

CC

107

CASTRO

110

LIZ

Sucursal

Número de factura

Fecha de la factura

01

500

1/01/06

01

501

2/01/06

02

500

3/01/06

E

Código del Artículo

Nombre del artículo

Precio unitario del artículo

16.00

01

LAPIZ

1.25

14.90

02

GOMA

0.75

08

COMPAS

4.00

20

REGLA

2.45

10

HOJAS

5.00

Total de la factura

Tabla 2.55: Detalle de Factura Clave primaria relación “Factura”.

PK Sucursal f úme tura de

Código del artículo

Cantidad Precio unitario del del artículo artículo

Subtotal del artículo

01

500

01

3

1.25

3.75

01

500

02

6

0.75

4.50

01

500

10

8

5.00

40.00

01

501

08

4

4.00

16.00

02

500

20

2

2.45

4.90

500

10

2

5.00

10.00

02 Fk

Clave foránea a la relación “Factura”.

Clave primaria relación “Artículo”. Simple.

Fk

Clave foránea a la relación “Artículo”.

Ahora se tiene una nueva relación que se denominará “Artículos” y que contendrá el identificador del artículo, su nombre y su precio. ¿Se tienen de nuevo los datos duplicados? Sí, en efecto, el código de artículo se encuentra en las relaciones “Detalle de Factura” y “Artículos”, ésta es la única forma de establecer una relación referencial, que permite mantener la misma dependencia funcional que existía en el modelo de la relación “Factura” anterior. ¿Pero por qué el precio en ambas relaciones? La respuesta es sencilla pero contundente a la hora de la calidad de la información que reside en el análisis de los datos. En “Artículos”, la columna “Precio” indica el precio actual de cada artículo que, en el pasado, pudo haber sido otro y que, seguramente, variará en el futuro. En cambio, la columna “Precio” de la relación “Detalle de Factura” contiene el precio del artículo en el momento en que se realizó la venta. Sería correcto interpretar que determinados atributos poseen diferentes valores asociados en el tiempo y que no permanecen constates; entonces, de ninguna manera, se referenciará el precio en la relación “Artículos” como constante. En este caso, se toma el último precio de la relación “Artículos” y se lo transfiere a la relación “Detalle de factura”, en el momento en que se realiza la registración. El modelo en estudio transformado a 2FN se representa de la siguiente manera (Mod. 2FN): Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

84

Mod. 2FN

Pk

Artículos

Detalle de Factura

Factura

Sucursal

Sucursal Pk

Número de factura

Fk

Número de factura

Pk

Código del artículo Nombre del artículo

Fk

Fecha de la factura

Código del artículo

Forma de pago factura

Cantidad del artículo

Código del cliente

Precio unitario del artículo

Nombre del cliente

Subtotal del artículo

Precio unitario

Total de la factura 2.5.5.3 Interpretación de la Tercera Forma Normal (3FN) Una relación se encuentra en Tercera Forma Normal si, y solo si, se encuentra en 2FN, y si los atributos no clave dependen de forma no transitiva de la clave primaria. Que primero se encuentre en “Segunda Forma Normal” deja sentado, explícitamente, que nunca se llegará a “Tercera Forma Normal” sin antes cumplir con la segunda. Estas son las relaciones con su contenido y cómo han quedado: Relación Artículos

Relación Factura

PK Número Fecha de la Sucursal de factura factura 01 500 1/01/06

Forma de pago factura E

Código del cliente 01

Nombre del cliente

Total de la factura

ALVAREZ

48.20

01

501

2/01/06

CC

107

CASTRO

16.00

02

500

3/01/06

E

110

LIZ

14.90

Relación Detalle de Factura

Código del Artículo

Nombre del artículo

Precio unitario del artículo

01

LAPIZ

1.25

02

GOMA

0.75

08

COMPAS

4.00

20

REGLA

2.45

10

HOJAS

5.00

PK Sucursal

úmero e factura

Precio unitario del artículo

Subtotal del artículo 3.75

01

500

01

3

1.25

01

500

02

6

0.75

4.50

01

500

10

8

5.00

40.00

01

501

08

4

4.00

16.00

02

500

20

2

2.45

4.90

500

10

2

5.00

10.00

02 Fk

Alfaomega

Código del Cantidad artículo del artículo

Fk

Bases de Datos - Reinosa, M a l d o n a d o , M u ñ o z , Damiano, Abrutsky

2.5 Las formas normales

85

En la definición, se dice que ningún subconjunto tendrá dependencia transitiva; esto se refiere a que el subconjunto estará compuesto por atributos que no pertenecen a la clave primaria. Esta es la clave del entendimiento de la Tercera Forma Normal. Entonces, se deberá encontrar, dentro de la relación, un subconjunto de atributos con dependencia transitiva, que ninguno de ellos pertenezca a la clave primaria y que, al cambiar el valor de un atributo, necesariamente cambiarán su valor otros atributos también.

Ningún subconjunto tendrá dependencia transitiva; esto signifca que el subconjunto estará compuesto por atributos que no pertenecen a la clave primaria.

Relación Factura Pk Sucursal 01

Número de factura 500

Fecha de la Forma de factura pago factura 1/01/06

E

01

501

2/01/06

CC

02

500

3/01/06

E

Código del cliente

01 107 110

Nombre del cliente

Total de la factura

ALVAREZ

48.20

CASTRO

16.00

LIZ

14.90

Las columnas, resaltadas con el reborde, son dependientes entre sí y, luego, dependerán de la PK.

Esta situación se expone en la relación “Factura”, de la relación anterior, en el subconjunto formado por los atributos “Código del cliente” y “Nombre del cliente”. Sin duda, hay una dependencia funcional entre ambos atributos; si cambia el identificador del cliente, necesariamente cambiará su nombre. Esta dependencia funcional, que se acaba de detectar, es la que no permite que la relación alcance la Tercera Forma Normal. ¿Cómo se soluciona? Se aplica la misma técnica que se utilizó con anterioridad: la descomposición por proyección. Se aparta el atributo que está ligado con una dependencia funcional al otro; en este caso, “Nombre del cliente” de la relación “Factura”. Para ello, se creará una nueva relación denominada “Clientes” en la que alojará el “Nombre del cliente”. Siempre se mantendrá la dependencia funcional, lo que obligará, también, a introducir, en esta nueva relación, el identificador del cliente, “Código del cliente”, que quedará como lo muestra la siguiente relación: Clave primaria de las respectivas tablas

Relación Clientes Relación Factura Número Sucursal de factura 01 500

Pk Fecha de la Forma de factura pago factura 1/01/06

01

501

2/01/06

02

500

3/01/06

E CC E

Clave foránea a la tabla “Clientes”, que establece la DF.

Código del cliente

01 107 110 /

Código del cliente

Nombre del cliente

48.20

01

ALVAREZ

CASTRO

16.00

107

CASTRO

LIZ

14.90

110

LIZ

Nombre del cliente

Total de la factura

ALVAREZ

Fk!

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

86

2 - Modelo de datos relacional

Al quitar de la relación “Factura” el atributo “Nombre del cliente”, se perdió la dependencia transitiva que impedía llegar a 3FN. Se creó una nueva relación “Clientes” en la que se alojan los datos del cliente y en la que se establece una clave primaria que mantiene una relación de asociación con la relación “Factura”. El modelo en estudio transformado a 3FN, se representa en el formato (Mod. 3FN): M o d . 3FN Factura Pk

Detalle de Factura

Sucursal

Sucursal

Número de factura

Pk

Número de factura

Fecha de la factura

Código del artículo

Forma de pago factura

Cantidad del artículo

Código del cliente

Fk Fk

Precio unitario del artículo

Fk

Subtotal del artículo

Total de la factura

Artículo Pk

Código del artículo

Pk

Nombre del artículo

Código del cliente Nombre del cliente

Precio unitario

Para explicar las Formas Normales Boyce-Codd —Cuarta Forma Normal y Quinta Forma Normal—, no se puede utilizar el modelo que se venía desarrollando (modelo de facturación), pues éste no presenta las anomalías que son tratadas en las restantes reglas. En otras palabras, este modelo ya está normalizado.

2.5.5.4 Forma Normal Boyce-Codd (FNBC) •

Una relación está en FNBC si, y solo si, todo determinante es una clave candidata. Determinante es un atributo, o conjunto de éstos, del que depende funcionalmente otro atributo completamente.

•

Una relación está en FNBC si primero está en Tercera Forma Normal y si las únicas dependencias funcionales triviales se encuentran dadas entre la clave primaria y un atributo.

Lo que impide la FNBC es la dependencia de atributos no clave pero de condición primarios (atributos que son parte de una clave candidata) y un componente de la clave primaria. En otras palabras: no puede haber ninguna dependencia funcional en la que el determinante no sea una clave candidata. Esta condición establece problemas de actualización y de mantenimiento de datos. Para analizar esta forma normal, se hará sobre una relación con las siguientes características:

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

87

1.

En la que exista más de una clave candidata.

2.

Que estas claves candidatas tengan la condición de ser compuestas.

3.

En la que un atributo componente de una clave candidata es determinante de otro atributo de tipo primario, que compone otra clave candidata.

Se denomina atributos primarios a los atributos que integran cualquier clave candidata de la relación.

Los atributos primarios son los atributos que integran cualquier clave can didata de la relación.

Se analizará una relación que represente la correspondencia que existe entre los alumnos de una carrera y las materias en las que está inscripto, con las siguientes características: Distintas posibilidades de conformar la clave primaria de la relación:

Relación Materias por PK Legajo del alumno

Número de Documento de Código de Identidad del alumno materia

01

01 02 02 11 11 14

Fecha inscripción

10000111

12

01/08/2009

10000111

08

01/08/2009

11222333

04

03/08/2009

11222333

05 04 12 33

03/08/2009

12444666 12444666 45789456

02/08/2009

Observe que esta entidad posee dos claves candidatas. Se demuestra, con ambos ejemplos, cómo puede quedar conformada la clave primaria.

02/08/2009 01/08/2009

Materias por alumno PK Número de Documento de Identidad del alumno

Legajo del alumno

Código de materia

Fecha inscripción

10000111

01 01 02 02 11 11 14

12

01/08/2009

08

01/08/2009

04 05

03/08/2009

04

02/08/2009

12

02/08/2009

33

01/08/2009

10000111 11222333 11222333 12444666 12444666 45789456

03/08/2009

Observe que existen dos claves candidatas. En los dos primeros atributos (“Legajo del alumno”, “Número De Documento De Identidad del alumno”) existe una dependencia funcional no trivial o no común entre ellos. Pueden alternar en su capacidad de pertenecer a la clave primaria; en otras palabras, ambas forman parte de claves candidatas, pero —entiéndase bien— que Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

88

2 - Modelo de datos relacional

“formar parte” no es lo mismo que serlo. Ambos atributos (“Número de Documento de Identidad del alumno” y “Legajo del alumno”) son determinantes, ya que cada uno de ellos ejerce una dependencia directa y no trivial sobre el otro; al cambiar uno de ellos, necesariamente cambia el otro. Esta dependencia funcional (fuerte) entre dos atributos de una relación, con las siguientes características: •

Ambos son parte de una clave candidata.

•

Ambos son determinantes entre sí.

•

Cuando uno de ellos pertenece a la PK, el otro es un atributo no clave.

Estas son las condiciones que se deben eliminar para que la relación alcance FNBC, que no existan dos atributos en la relación con estas características. Para lograr que esta relación alcance FNBC, se debe descomponer la relación en dos, tal como lo muestra la relación “Alumnos”: Relación Alumnos

Materias_por_alumno PK

Legajo del alumno

Número de Documento de Identidad del alumno

Legajo del alumno

Código de Fecha inscripción materia

01

10000111

01

12

01/08/2009

02

11222333

01

08

01/08/2009

11

12444666

02

04

03/08/2009

14

45789456

02

05

03/08/2009

11

04

02/08/2009

11

12

02/08/2009

14

33

01/08/2009

FK

Ahora, la relación “Materias_por_alumno”, de la relación “Alumnos”, no tiene más la dependencia funcional trivial que ya se explicó y, por lo tanto, ahora sí está en FNBC. 2.5.5.5 Interpretación de la Cuarta Forma Normal (4FN) Una relación “R” está en Cuarta Forma Normal si primero está en Forma Normal Boyce-Codd y, además, todas las dependencias multivaluadas en esta relación R son dependencias funcionales. El concepto de dependencia multivaluada —pero que no es dependencia funcional— es el que impide que una relación se encuentre en Cuarta Forma Normal. Esta situación se representa por una relación que contiene las siguientes situaciones:

Alfaomega

1.

La relación tiene que estar compuesta por lo menos por tres atributos; por ejemplo: “AlumnosPorCarreraPorProfesor” (relación “Alumnos”).

2.

Se debe observar que para cada atributo de la relación hay una evidente repetición de valores, que hace pensar en redundancia de datos. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

89

3.

Dos de los atributos son independientes entre sí, como se manifiesta en la relación de estudio. Los atributos “Alumno” y “Profesor” no están relacionados entre sí.

4.

Se debe poder observar una dependencia multivaluada entre el tercer atributo y los dos restantes de la terna. Evidentemente, existe una dependencia entre el “Alumno” y la “Carrera”, también entre el “Profesor” y la “Carrera”.

5.

No existe dependencia funcional entre los valores de los atributos. No hay una relación uno a uno entre ninguno de los atributos.

6. Todos los atributos de la relación son parte de la clave primaria. 7.

Que se encuentre en FNBC.

8.

Lo expuesto en el punto 2 tiene, como consecuencia, serias anomalías de actualización.

Se observará la siguiente relación no normalizada para poder entender la situación a la que se hace referencia. Esta relación representa el vínculo existente entre carreras y profesores que dictan clases en la misma universidad y los alumnos inscriptos en ésta (ver relación “AlumnosPorCarreraPorProfesor”).

Relación AlumnosPorCarreraPorProfesor PK Carrera

Alumno

Profesor

Lic. en Informática

Sánchez José

Dardo

Lic. en Informática

Sánchez José

Miño

Lic. en Informática

Sánchez José

Abru

Lic. en Informática

Salas Miguel

Dardo

Lic. en Informática

Salas Miguel

Miño

Lic. en Informática

Salas Miguel

Abru

Lic. en Informática

Fernández Erika

Dardo

Lic. en Informática

Fernández Erika

Miño

Lic. en Informática

Fernández Erika

Abru

Ing. en Sistemas

Sánchez José

Quinto

Ing. en Sistemas

Salas Miguel

Quinto

Ing. en Sistemas

Fernández Erika

Quinto

Es notorio que la relación “AlumnosPorCarreraPorProfesor” tiene gran cantidad de redundancia. Si se quisiera agregar un nuevo alumno en la carrera Licenciado en Informática, se tendrían que agregar tres nuevos registros a la relación, uno para cada profesor. En forma intuitiva, se puede realizar una división de la relación en dos, que presenta la información de una forma más conveniente (relación “AlumnosPorCarrera”).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

90

2 - Modelo de datos relacional

ProfesorPorCarrera

Relación AlumnosPorCarrera

PK

PK Alumno

Carrera

Profesor

Lic. en Informática

Sánchez José

Lic. en Informática

Dardo

Lic. en Informática

Salas Miguel

Lic. en Informática

Miño

Lic. en Informática

Fernández Erika

Lic. en Informática

Abru

Ing. en Sistemas

Sánchez José

Ing. en Sistemas

Quinto

Carrera

Ing. en Sistemas

Salas Miguel

Ing. en Sistemas

Fernández Erika

En estas dos relaciones, proyectadas en la relación anterior, todos sus atributos son parte de la clave primaria, de la misma manera que en la relación de origen, y también están en FNBC. Como se verá, no se puede establecer entre ambas relaciones una relación sobre la base de dependencias funcionales, pues no existe. Pero sí, si se hace en función de este nuevo concepto, que se menciona en esta forma normal, denominado d e pendencia multivaluada. Dentro de la relación “AlumnosPorCarreraPorProfesor”, existen dos dependencias multivaluadas: una establecida por la relación “carreraprofesor” y, la otra, dada por “carreraalumno”. Observamos que, en la primera dependencia multivaluada (“carreraprofesor”), no No se puede establecer entre ambas relaciones una relación sobre la base de dependencias funcionales porque no existe. Pero sí, si se hace en función de este nuevo concepto denominado dependencia multivaluada.

existe una única tupla que represente la dependencia funcional “carrera à profesor”, pero sí existe un grupo de ellas acotado y limitado que define con claridad un conjunto. Si se extiende la expresión para una carrera determinada y un alumno en particular, se puede establecer con claridad el conjunto de profesores, para la relación “AlumnosPorCarreraPorProfesor”, que depende exclusivamente del valor de la carrera. Ambas dependencias multivaluadas se explican con la misma concepción. Dependencia multivaluada: Dada un relación “R” con atributos “X, Y, Z” (que pueden ser compuestos), la dependencia multivaluada R.X

àà

R.Y

sucede en “R” si y solo si un conjunto de valores de Y pertinente a un par dado de valores de X y Z, en “R”, depende solo del valor de X y es independiente del valor de Z. Dada la relación “R(X,Y,Z)”, la dependencia multivaluada R.X à à R . Y se cumple si, y solo si, R.X à à R . Z también se cumple. Otra forma de notación R.X à à R . Y | R.Z

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.5 Las formas normales

Una DF es un DMV en el que los valores dependientes del determinante siempre son un único valor. El caso inverso no es válido. 2.5.5.6 Interpretación de la Quinta Forma Normal (5FN) Una relación “R” está en Quinta Forma Normal si, y solo si, toda dependencia de reunión en R es una consecuencia de las claves candidatas en R. Hasta este momento, para lograr una forma normal determinada, en cualquiera de las anteriores hasta 4FN, se partía de una relación que no estaba normalizada (no alcanzaba la forma normal deseada) y se la sustituía por dos relaciones que resultaban de la descomposición o de las proyecciones de la primitiva. Estas relaciones resultantes son las que logran la forma normal buscada. Esta mecánica conduce con éxito desde la 1FN hasta la 4FN. También, este método garantizaba que no se perdiera información para reconstruir la relación primera sin problemas. Existen casos particulares, en donde las formas normales expresadas anteriormente implican los conceptos de DF y DMV (de 1FN a 4FN); éstos no alcanzan a satisfacer la premisa de no pérdida de información en la transformación, para la Quinta Forma Normal. A raíz de esto, entra en juego un nuevo concepto denominado Dependencia de Reunión, que implica la descomposición de una relación en n-proyecciones (n >= 3), para lograr la obtención de la forma normal deseada. Este caso se presenta, únicamente, para la Quinta Forma Normal. Esta situación se presenta bajo las siguientes características: 1.

La cantidad de atributos de la entidad es tres o superior a tres.

2.

Todos los atributos de la relación componen la clave primaria.

3.

No debe haber dependencia funcional entre ninguno de sus atributos y tampoco dependencias multivaluadas no triviales.

4.

La entidad se encuentra en 4FN.

Defnición de Dependencia de Reunión (DR): Una relación “R” satisface la dependencia de reunión *(A, B, . . . . , Z) si, y solo si, R se puede construir con la reunión de sus proyecciones A, B, . . . ., Z siendo A, B, . . . ., Z subconjuntos de atributos de R.

Caso teórico: Sea una relación cuyos atributos son A, B y C, que se denominará, de ahora en más, ABC, si se descompone con la concepción de DR (dependencia de reunión), se tienen las proyecciones AB, AC y BC en las relaciones (AB, AC y BC).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

91

92

2 - Modelo de datos relacional

A# A1 A1 A2 A1

B# B1 B2 B1 B1

C# C1 C1 C1 C2

Reunión entre AB y AC según A#

Proyecciones según el concepto dependencia de reunión

AC A#

B#

A1 A1

B1 B2

A# A1

C# C1

A2

C1

B# B1 B2

C# C1 C1

T A# A1 A1 A1 A1 A2

B# B1 B1 B2 B2 B1

C# C1 C2 C1 C2 C1

Reunión entre ABC1 y BC según B#C

Tupla que se obtiene de más con la primera reunión

A# A1 A1 A1 A2

B# B1 B1 B2 B1

C# C1 C2 C1 C1

Si ahora se operara la reunión de estas relaciones, se encontraría el siguiente resultado (relación “ABC1”) se opera la reunión según A# entre AB y AC. Por esta acción, se obtiene la relación “ABC1” con una tupla adicional, no encontrada en la relación primitiva. Para completar el paso de reunión, se realiza la última operación entre ABC1 y BC según B# C#, que da como resultado la eliminación de la tupla que se obtuvo de más en la anterior reunión. Queda una relación “ABC2” (relación “ABC2”) de igual contenido que la original ABC.

2.6 Las estructuras 2.6.1 El modelo y sus estructuras El modelo, en sí mismo, tiene como soporte una combinación de estructuras que representan la realidad. Estas estructuras terminan representando la información de una forma sencilla para lograr la fácil manipulación de los datos, evitando problemas de lógica.

La información que se observa dentro de la mecánica funcional de un problema que se solucionará, se debe representar por una combinación de estructuras que satisfagan como solución al problema. Esta información que está sustentada por un modelo diseñado con la función de solucionar la problemática observada, conforma la estructura de la base de datos. Esta base de datos, con sus estructuras internas, será pensada para que cumpla con las formas normales. Esto último asegura que los datos mantendrán su estado relacional, su dependencia y que no habrá pérdida de información respecto de lo observado en el problema. El modelo, en sí mismo, tiene como soporte una combinación de estructuras que representan la realidad. Estas estructuras, que pueden ser utilizadas en una combinación vasta y diversa, terminan representando la información de una forma sencilla, cuya comprensión no debiera causar problemas para su interpretación y uno de sus principales objetivos es la fácil manipulación de los datos, evitando problemas de lógica. Estas estructuras, claramente limitadas por el funcionamiento del modelo relacional, están acotadas a los formatos que detallaremos a continuación. Es comprensible que las estructuras expuestas a consideración puedan sufrir variaciones acordes con las distintas problemáticas. Lo que se pretende es establecer el formato tipo de estas estructuras para poder enmarcar estos modelos en distintos tipos diferenciados.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.6 Las estructuras

93

Importante: Las estructuras que a continuación se ponen a consideración, están compuestas por relaciones que están ligadas por una fuerte dependencia relacional, en cada caso, hay un conjunto de relaciones que conforman la estructura tratada, y otras, que forman parte del diseño, y están con el propósito de poder observar el contexto para no perder el sentido. Las relaciones que conforman la estructura tratada están ligadas entre sí con una línea continua, y las que forman parte del entorno (no conforman la estructura tratada) están relacionadas con una línea intermitente. Estos modelos están representados en formato de relaciones con contenido de información para poder comprender con mayor facilidad sus características. Relaciones de referencia: • • •

No posee relaciones asociadas que heredan su clave primaria como componente de la clave primaria de aquellas. Sí poseen estado relacional con otras relaciones que establecen referencia con ésta, mediante claves foráneas. Ejemplos: – Relaciones de tipo: tipo de Documento, tipo de estado civil, tipo de vehículo, etc. – Relaciones descriptivas: con mayor cantidad de atributos que las de tipos.

Relación Tipo Documento PK id 1 2 3 4 5

Tipo Person

Descripción Documento Nacional Libreta Enrolamiento Libreta Cívica Cedula Federal Pasaporte

documento 1111 2222 3333 4444 5555

Tipo Sexo Tipo Documento 1 2 1 1 3

Apellido

Nombres

Sexo

López Muñoz Juárez Romero Oliva

José Miguel Antonio Oscar Beatriz

2 2 2 2 1

PK Id 1 2

Descripción Femenino Masculino

Las relaciones “Tipo Documento” y “Tipo De Sexo”, son en este caso relaciones de referencia, pues se accede a ellas desde la relación “Personas” a través de una clave foránea. La relación “Personas” necesita de la presencia de estas relaciones para completar la representación que el modelo sugiere de la realidad. Desde otro punto de vista la relación “Personas” también podría ser una relación de referencia hacia otras relaciones. A continuación, la representación del modelo de la relación “TipoDocumento”: Relación Tipo Personas PK

Documento Tipo Documento Apellido Nombre Sexo Total de la factura

Tipo Documento PK

FK

Id Descripción

Tipo Sexo PK Id Descripción

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

94

Relaciones que conforman estructura Padre-Hijo: Relación denominada “Padre” que posee una relación asociada denominada “Hijo”, que hereda la clave primaria del padre como componente parcial de su propia clave primaria. Ejemplo: • • •

Estructura Factura – Detalle de Factura. Personas – Teléfonos varios. Personas – Domicilios varios. Clave primaria conformada con la herencia de la clave primaria de la tabla “Factura” más un componente (código del artículo) típico de la tabla.

Relación Factura

Detalle Factu

PK Número de sucursal 1 2 2 3 3

PK Número de factura 1 2 1 1 3

Fecha 1-3-09 3-3-09 4-3-09 8-4-09 10-4-09

Código de cliente 1 1 2 3 1

Número de sucursal 1 1 2 2 2 3 3

Total 100 110 90 70 10

Número de factura 1 1 2 2 1 1 3

Código de artículo 1 2 1 2 2 1 2

Cantidad 1 10 1 10 9 7 1

Precio unitario 10 9 10 10 10 10 10

Clave foránea a tabla “Factura”.

Sucursales PK id Descripción Centro 1 V. Allende 2 Río Cuarto 3

Clientes PK id Descripción 1 López 2 Álvarez 3 Olmedo

Artículo PK id Nombre Guante 1 Zapato 2

Precio 10 10

A continuación la representación del modelo, correspondiente a la relación “Factura”: Relación Factura PK

Número de sucursal Número de factura Fecha Código de cliente Total

Sucursales Id Descripción Alfaomega

Detalle Factura PK FK

Número de sucursal Número de factura Código artículo Cantidad Precio unitario

Clientes FK

Pk

Id Descripción

FK Artículos Pk

Id Nombre Precio

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.6 Las estructuras

95

Relaciones que conforman estructura Padre-Múltiples-Hijo: Relación denominada “Padre” que posee varias relaciones asociadas denominadas “Hijos”, que heredan la clave primaria del padre como componente parcial de su propia clave primaria. Ejemplo: Estructura Factura – Detalle de Factura – Formas de Pago de Factura Relación Fac

Detalle Factura

PK Número de sucursal 1 2 2 3 3

PK Número de factura 1 2 1 1 3

Código de cliente 1 1 2 3 1

Fecha 1-3-09 3-3-09 4-3-09 8-4-09 10-4-09

Número de sucursal 1 1 2 2 2 3 3

Total 100 110 90 70 10

Número de factura 1 1 2 2 1 1 3

Código de artículo 1 2 1 2 2 1 2

Cantidad 1 10 1 10 9 7 1

Precio unitario 10 9 10 10 10 10 10

Clave foránea a tabla “Factura”.

Sucursales Id 1 2 3

PK Id 1 2 ' 3

Descripción Centro V. Allende Río Cuarto

Descripción López Álvarez Olmedo

Formas de Pago de Factura

Artículo PK Id Nombre Guante 1 Zapato 2

Precio 10 10

Forma de Pago

PK Número de sucursal

Número de factura

Código forma de pago

Monto

1 1 2 2 2 3 3

1 1 2 2 1 1 3

1 2 1 2 2 1 2

10 9 10 10 10 10 10

PK Id 1 2 3 4

Descripción Efectivo Cheque Tarjeta Crédito Cuenta Corriente

Clave foránea a tabla “Factura”.

A continuación, la representación del modelo correspondiente a la relación “Factura”: Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

96

2 - Modelo de datos relacional

Relación Factura Número de sucursal PK Número de factura Fecha Código de cliente Total

FK

FK

Detalle Factura Número de sucursal PK Número de factura Código artículo Cantidad Precio unitario

FK FK

Forma de Pago de Factura Número de sucursal FK Número de factura PK Código forma de FK pago Monto

Sucursales Id Descripción Clientes Id Descripción Artículos Id Nombre Precio Forma de Pago Id Descripción

Relación con autoreferencia: •

Son relaciones que poseen un estado de asociación en sí mismas.

•

En estas relaciones se encuentra una, o más referencias, a la misma relación.

•

Esta clave foránea se denomina autoreferencia o clave foránea recursiva.

Ejemplo: •

Relación “Empleados” en donde existe una asociación al Jefe de éstos, que es también un empleado.

•

Relación “Personas” en donde existe una asociación al cónyuge que es otra persona de la misma relación.

Relación Empleados PK Número de Tipo Documento Documento 1111 1 2222 2 3333 1 4444 1 5555 3

Alfaomega

Apellido

Nombres

Sexo

López Muñoz Juárez Romero Oliva

José Miguel Antonio Oscar Beatriz

1 1 1 1 2

Documento del Jefe null 1111 2222 2222 2222

Tipo Documento

Tipo Sexo

PK Id 1 2 3 4 5

PK Id 2 1

Descripción Documento Nacional Identidad Libreta Enrolamiento Libreta Cívica Cédula de Identidad Provincial Pasaporte

Tipo Documento del Jefe null 1 2 2 2 FK Clave foránea a la misma tabla, también llamado “autoreferencia”.

Descripción Femenino Masculino

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.6 Las estructuras

97

A continuación, la representación del modelo correspondiente a la relación “Empleados”: Relación Empleados Número de Documento Tipo de Documento Apellido Nombres Sexo Documento de Jefe Tipo Documento del Jefe

PK

Tipo Sexo PK FK

Id Descripción

Tipo Documento PK

Id Descripción

Relaciones que conforman estructura de componentes: •

Se requieren dos relaciones. Una, la que contiene todos los elementos simples y compuestos (en este caso, se denomina “Elementos”). La otra es la que relaciona un elemento compuesto, con algunos elementos simples o compuestos de la relación “Elementos”. A esta última se la denomina “Componentes”.

•

Un elemento simple no posee estructura de componentes.

•

Un elemento simple puede ser referenciado por varios elementos compuestos.

•

La clave primaria de la relación “Componentes” está construida con dos veces la clave primaria de la relación “Elementos”. La primera vez cita al elemento compuesto de la relación “Elementos”, la segunda hace referencia al elemento componente del primero.

•

La relación “Componentes” podrá tener atributos adicionales, si fuera necesario, y referencia a otras relaciones (FK), si así se requiere para el modelo.

Ejemplo: Definición de “Artículo” compuestos por varios elementos. Relación Artículo PK Id 1 2 3 4 5 6

Descripción Ruedas Carrocería Frenos Luces Automóvil Motocicleta

Clave primaria compuesta por ambas columnas.

Componente Código Artículo compuesto

Código artículo Cantidad componente Referencia al elemento componente del producto (elemento) compuesto.

Referencia al producto (elemento) compuesto, formado por varios elementos simples o compuestos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

98

A continuación, la representación del modelo correspondiente a la relación “Artículo”:

Relación Artículo

Componentes

Id Descripción

PK

Código artículo compuesto Código articulo componente Cantidad

FK FK

Relaciones con múltiples asociaciones: •

Cuando dos relaciones se relacionan entre sí con múltiples asociaciones, es inevitable la participación de una tercera que realice la tarea de establecer las múltiples relaciones.

•

Las relaciones que se relacionan entre sí tienen el mismo estatus en la estructura. Una tercera, que se puede denominar relación “Relación”, es la que establece la forma en que ambas se relacionan y el volumen de asociación entre las dos. Sin esta tercera relación no se podría tener la estructura deseada.

•

Siempre la relación se produce a través de la PK de ambas relaciones.

•

También esta relación puede poseer atributos típicos y necesarios.

Ejemplo: Relaciones de empleados, de computadoras, de asociación de las computadoras que puede utilizar cada empleado. Computadoras x Empleados

Relación Empleados

PK

PK Número de Documento

Tipo de Documento

Apellido

Nombres

Sexo

1111 2222 3333 4444 5555

1 2 1 1 3

López Muñoz Juárez Romero Oliva

José Miguel Antonio Oscar Beatriz

2 2 2 2 1

Número de Documento

Tipo de Documento

1111 1111 3333 3333 4444 4444

1 1 1 1 1 1 FK

Tipo Sexo Id 1 2

Alfaomega

Descripción Femenino Masculino

Tipo Documento Id 1 2 3 4 5

Descripción Documento Nacional Identidad Libreta Enrolamiento Libreta Cívica Cédula de Identidad Provincial Pasaporte

Id computadora 1 4 4 5 2 3 FK

Computadoras Id 1 2 3 4 • 5

Descripción PC1 PC2 PC3 PC4 PC5

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.7 Un caso de estudio

99

A continuación, la representación del modelo correspondiente a la relación “Empleados”: Relación Empleados PK

Tipo Sexo

Número de Documento Tipo de Documento Apellido Nombres Sexo

PK FK

Id Descripción

Tipo Documento FK

PK

Id Descripción

Computadoras x Empleados PK

Número de Documento Tipo de Documento Id Computadora

Computadoras FK

PK

FK

Id Descripción

2.7 Un caso de estudio Modelo de Datos para Estudio: “Administración Académica de Institución Educativa” Descripción del modelo y sus características funcionales. •

El sistema almacena información del alumno: apellido, nombres, tipo de Documento, número de Documento, sexo, domicilio —calle , número de la casa y barrio—. Para esta entidad se utilizará una clave primaria artifcial.

•

Las carreras que se pueden cursar: nombre de la carrera y título.

•

Las materias: nombre de la materia.

•

Cada carrera tiene un plan de materias, que consta de la materia, el año de cursada y el cuatrimestre de cursada.

•

Los alumnos se pueden inscribir en más de una carrera; se requiere saber la fecha en la que se realizó este trámite.

•

Los alumnos se inscriben a cursar materias de la carrera en la que están inscriptos; se requiere la fecha de inscripción, un estado en el que se encuentra la materia (ej. inscripto, cursando, regular, libre, promocionado, etc.) y una fecha de ese estado. No se requiere información histórica del cambio de estados; solo se requiere el último.

•

En el transcurso de la cursada de materia, el alumno debe rendir exámenes parciales; se requiere documentar esta información con el tipo de parcial que rindió (tipo_nota) la fecha en que lo hizo y la nota que obtuvo.

•

Para que los alumnos puedan rendir exámenes, se habilitan materias en turnos determinados, que se identifcan por un número y que se incrementan en forma secuencial a partir de uno. Se requiere saber la materia que se habilita para examen, carrera a la que pertenece y fecha en la que se tomará el examen.

•

Luego de cursar las materias y quedar en condición de examen, los alumnos se pueden inscribir para rendir se requiere saber la materia en la que se inscribió a examen, fecha del examen, fecha en la que se inscribió al examen y la nota que obtuvo.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 - Modelo de datos relacional

1 00

Solución propuesta: Carreras

Relación sexos | id_sexo

PK

n_sexo

id_carrera nombre_carrera

Inscripciones_a_carreras Fk Fk

PK

título

id_estudiante

Fk

id_carrera

Fk

fecha

Estados_cursados Materias

id_estado

alumnos_cursando_materias

id_materia

n_estado

id_materia

nombre_materia

PK

barrios n_barrio

PK

id_estudiante fecha_inscripcion

Plan_de_carrera

| id_barrio

id_carrera

id_materia

Fk

id_carrera

Fk

id_estado fecha_estado

año_cursado

tipo_notas

alumnos_examenes

cuatrimestre_año

| id_tipo_nota n_tipo_nota

materias_x_turnos_examenes id_turno

tipo_documento

id_materia

id_tipo_documento

PK

n_tipo_documento

id_carrara fecha_del_examen

FK

PK

id_estudiante id_materia id_carrera fecha_del _examen

Fk FK

fecha_inscripcion_a_ examen nota

alumnos_cursando_notas_

Estudiantes

parciales id_materia id_carrera id_estudiante fecha_inscripcion fecha_nota id_tipo_nota nota

Alfaomega

FK

id_estudiante apellido nombres tipo_documento documento id_sexo calle calle_nro id_barrio

Fk Fk

Fk

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

2.8 Resumen

101

2.8 Resumen El modelo de datos relacional es el modelo con mayor difusión y uso en los distintos tipos de organizaciones. Si bien este modelo sufrió grandes cambios y modificaciones con el correr de los años, expresa conceptos que no han perdido vigencia y que constituyen un pilar de conocimientos. Además, en sus inicios, este modelo se respaldaba en la teoría de conjuntos cuyo aporte brindaba la resolución del inconveniente con las grandes bases de datos compartidas. Posteriormente, se trata el álgebra relacional cuyo objetivo principal de enseñanza es facilitar el aprendizaje de la escritura de sentencias SQL, dado por la manipulación de datos vinculada a la relación con operaciones. El resultado de aplicar una operación de este tipo es otra relación, lo cual habilita la combinación de operaciones y su anidamiento ya que la entrada de una operación podría ser el resultado creado por otra anterior. Se incluyen las operaciones de conjuntos, que son binarias y abarcan dos relaciones de entrada, y las operaciones relacionales, que tienen más potencial aun cuando se combinan con operaciones de conjunto o entre ellas mismas. También se brindan los fundamentos de la normalización referidos a modelar una base de datos relacional y saber cómo organizar una estructura relacional de datos válida. Además, se profundiza sobre el origen de los datos, como un recurso que permite obtener datos para modelar una estructura de relaciones normalizadas, las formas normales y las estructuras, limitadas por el funcionamiento del modelo relacional. Para finalizar se presenta un caso de estudio que se utilizará en otros capítulos de la obra.

2.9 Contenido de la página Web de apoyo El material marcado con asterisco (*) solo está disponible para docentes.

2.9.1 Mapa conceptual del capítulo 2.9.2 Autoevaluación 2.9.3 Presentaciones*

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

!op!

3 SQL

Contenido

Objetivos

3.1 Introducción

104

3.2 Algo de historia del lenguaje SQL

104

3.3 Características del lenguaje SQL

105

3.4 El lenguaje SQL y su sublenguaje de definición de datos o DDL 3.5 Sentencias del sublenguaje DML

•

Conocer el origen del lenguaje SQL.

•

Entender la estructura de las sentencias del lenguaje SQL.

•

Enunciar el propósito de cada sentencia SQL.

•

Conocer las funciones disponibles para ser usadas en las sentencias SQL.

•

Entender el procesamiento de las sentencia y de las transacciones.

•

Obtener consejos de optimización de consultas SQL.

•

Ver ejemplos prácticos de sentencias SQL.

106 112

3.6 Sentencias del sublenguaje DML. INSERT, UPDATE, DELETE ... 123 3.7 Sentencias del sublenguaje TCL de control de transacciones

125

3.8 Procesamiento de consultas

127

3.9 Resumen

129

3.10 Contenido de la página Web de apoyo

129

1 04

3 - SQL

3.1 Introducción En este capítulo se estudiará el Lenguaje Estructurado de Consultas (Structured Query Language o SQL), cuyas sentencias se agrupan en sublenguajes. Para que el estudiante aprenda su sintaxis —que se explica en numerosos sitios de la Web— se realizarán algunas sugerencias de estilo para escribir las sentencias SELECT —también denominadas “consultas”— y otras indicaciones útiles para aprovechar todo su poder; de esta manera, se facilitará la obtención de información que, normalmente, se almacena en una o varias tablas de una base de datos y, además, para cubrir las tareas de una aplicación comercial, científca, de un sitio Web, en la que se insertarán, borrarán o modifcarán los datos ya almacenados en los motores relacionales que soportan la mayoría de las aplicaciones. Es importante destacar el rol de SQL como lenguaje especializado en la comunicación con la base de datos, que funciona dentro o embebido en otros lenguajes de uso general que construyen las demás funcionalidades de una aplicación de negocios, como los numerosos lenguajes procedimentales conocidos como COBOL, C, C++, orientados a objetos como Java, PHP y Python. A estos lenguajes se los podría caracterizar como de propósitos múltiples, ya que con ellos se construirán pantallas, menús, botones, campos listas, mientras que para acceder a la base de datos para obtener las flas haciendo consultas o inserciones, borrados y actualizaciones, se requerirán las correspondientes sentencias SQL. También hay que mencionar que las bases de datos proveen otros lenguajes —procedimentales o basados en procedimientos que se ejecutan en el servidor de base de datos, como PL/SQL de Oracle, SQL PL de DB2, T-SQL de MS SQL Server— que se tratarán en otro capítulo.

3.2 Algo de historia del lenguaje SQL

Raymond Boyce (1947-1974). Científco informático, conocido por desarrollar la forma normal de Boyce-Codd (o FNBC) utilizada en la normalización de bases de datos.

En su libro El modelo Relacional para la administración de Bases de Datos en el capítulo de “Introducción al Modelo Relacional”, E.J. Codd da pistas sobre el origen del lenguaje y lo atribuye a un grupo de investigación de IBM a fnales del año 1972. En esta publicación, el padre del modelo relacional afrma que es inconsistente en diversas formas con las máquinas abstractas del modelo relacional V1 (versión 1) y V2 (versión 2) y que algunas características no están implementadas directamente y otras no están implementadas correctamente y que, cada una de las inconsistencias, pueden reducir su utilidad. En esta publicación, Codd afrma que el lenguaje QUEL, por Query Language o Lenguaje de Consulta —inventado por Held y Stonebraker de la Universidad de California, Berkeley— era el más completo pero, pese a esto, el SQL —desarrollado en IBM por Andrew Richardson, Donald C. Messerly y Raymond F. Boyce— ganó preeminencia porque se adoptó como estándar ANSI y, a partir de ello, lo soportan todos los motores de base de datos. En 1970, luego de que el Dr. E. F. Codd introdujera el concepto del modelo relacional, IBM desarrolló este lenguaje. Se buscó que fuera fácil de aprender y potente en sus posibilidades expresivas. Se basa en la estructura idiomática del inglés para permitir, en teoría, que un usuario no experto escriba sentencias SQL fuida y efcazmente. Aunque esta ventaja se consiguió solo parcialmente, el SQL es fácil de aprender y, con la ayuda de los programas con asistentes, el técnico no especializado puede lograr resultados muy interesantes.

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.3 Características del lenguaje SQL

105

En 1979, casi diez años después de la presentación del modelo relacional de Codd, aparece la primera base de datos comercialmente disponible con SQL como único lenguaje para acceder a los datos; luego, las otras bases de datos empezaron a incorporar esta característica. En 1986, se convirtió en un estándar de la American National Standard Institute (ANSI). En la actualidad, existen siete versiones (SQL86, SQL89, SQL92 o SQL2, SQL99 o SQL 3, SQL2003, SQL2006, SQL2008) a las que les agregaron funcionalidades que adoptaron todos los servidores que quisieron cumplir con el último estándar de la industria. Los avances en motores de bases de datos, en paralelo con los del lenguaje, son múltiples: el descubrimiento de Internet como una forma de conectarse a los motores de bases de datos fue uno de los transformadores de la WWW, que de un rol presentadora de documentos estáticos o folletería electrónica, pasó a soportar aplicaciones corporativas que fueron la base para la explosión del e-commerce como soporte de una nueva economía y se transformó en un ejemplo concreto de la formación de la sociedad del conocimiento. En este movimiento, hay que mencionar a MySQL como un protagonista de mucho menor tamaño que los motores tradicionales, pero con las prestaciones sufcientes para publicar un sitio Web y hacer funcionar los sitios de todo tamaño que aparecieron en esos tiempos. La estrategia de esta empresa fue focalizarse en ofrecer lo que las grandes empresas no hicieron, una implementación en pequeño de las funcionalidades básicas de SQL.

Para conocer un poco más acerca de la historia del lenguaje SQL visite: http://goo.gl/pmUvh

3.3 Características del lenguaje SQL El lenguaje SQL se considera, por un lado, un lenguaje diseñado específcamente para la comunicación entre usuarios y, por otro con la base de datos para realizar todas las tareas requeridas para resolver los requerimientos como obtener información almacenada, realizar cálculos, modifcar lo existente y agregar nuevas flas que contengan información de clientes, productos, transacciones (como ventas, compras, pedidos, reservas, asistencia, ausencias, llegadas tardes, etc.), puesto que la mayoría de las aplicaciones actuales usan bases de datos relacionales y, por ende, SQL.

La característica más destacada del lenguaje SQL es que es no procedimental, es decir, no se indica en sus sentencias cómo realizar la tarea sino que se limita a describir el resultado buscado.

La característica más destacada del lenguaje SQL es que es no procedimental, es decir, no se indica en sus sentencias cómo realizar la tarea sino que se limita a describir el resultado buscado y queda todo el trabajo de resolver lo solicitado al servidor de bases de datos que, de acuerdo con su optimizador y con los metadatos (se los denomina así porque son datos acerca de los datos) del diccionario, cumplirá con la sentencia SQL provista. Por lo antedicho, SQL no tiene sentencias de control de fujo desde su origen aunque, recientemente, se han incluido como partes opcionales aceptadas del estándar de SQL, ISO/IEC 9075-5: 1996. Es común que estas sentencias de control de fujo —conocidas como módulos persistentes almacenados— se consideren como extensiones procedimentales del lenguaje. Los proveedores de bases de datos tienen estas extensiones (por ejemplo: PL/SQL de Oracle, T-SQL de SQL Server de Microsoft, SQL-PL de DB2 de IBM y PSQL de PostgreSQL). En general, estas extensiones complementan a SQL para construir procedimientos almacenados, paquetes y disparadores, que se explicarán —como ya se anticipó— en el siguiente capítulo.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 06

3 - SQL

3.4 El lenguaje SQL y su sublenguaje de defnición de datos o DDL

S TRUNCATE es una sentencia que permite borrar todo el contenido de una tabla, sin eliminar la estructura y sin generar transacciones.

Las sentencias SQL se agrupan en sublenguajes de acuerdo con sus propósitos: primero se revisarán las sentencias del lenguaje de defnición de datos o DDL (Data Defnition Language), que permitirán crear, borrar o modifcar objetos dentro de la base de datos. Por ejemplo, se puede utilizar CREATE, DROP, ALTER y RENAME para crear, eliminar, modifcar su estructura y cambiarle el nombre a los objetos de datos de una base de datos como en el caso de las tablas, las vistas comunes, las vistas materializadas, los índices, las funciones, los procedimientos y los paquetes que pertenecen a un esquema lógico. También se aplican estas acciones sobre los usuarios, los roles, las estructuras de almacenamiento como una base de datos propiamente dicha, un espacio de tablas (Tablespace), los segmentos de RollBack (o RollBack Segments) y numerosas estructuras propias de un motor de base de datos. TRUNCATE es una sentencia que permite borrar todo el contenido de una tabla, sin eliminar la estructura y sin generar transacciones. Por esta razón, se la nombró aparte. En DCL se encuentran, también, las sentencias GRANT y REVOKE, que permiten que se otorguen privilegios sobre objetos y sobre acciones o de sistema, a los usuarios y a los roles de la base de datos. Además, COMMENT es una sentencia de DDL que permite guardar comentarios sobre tablas y columnas. Las sentencias AUDIT y NOAUDIT —presente en algunos motores— que activa o desactiva el registro de todos los cambios hechos sobre los objetos por sesiones, también denominada auditoría automática. A continuación, se verán algunos ejemplos en los que se utilizarán las tablas normalizadas en los capítulos anteriores. Para el modelo de datos del sistema de ventas, se defnieron cuatro tablas: “Artículos”, “Clientes”, “Facturas” y “Detalle de Factura”. Se analizarán las sentencias para su creación. A la tabla “Clientes”, se le agregará una columna “olvidada” en el momento de creación o agregada por nuevos requerimientos para ejemplifcar la sentencia ALTER. Además, se creará una vista que mostrará las facturas del cliente “A01”. Una vez creadas las tablas y la vista, se creará, además, un usuario para luego darle privilegios de lectura al usuario sobre las tablas. Por último, se agregarán los comentarios sobre las tablas y una columna. Nótese que las sentencias SQL empiezan siempre con un verbo que indica la acción; luego, el tipo de objeto sigue solo en la creación y en la modifcación y, después, el nombre del objeto que se tratará. Se continuará —si es necesario— con otra información que completará la tarea. Si bien SQL no es sensible a las mayúsculas y a las minúsculas, es bueno que se adopte un protocolo de escritura que facilite la lectura del código. En este libro, se adoptará el uso de las mayúsculas para las palabras reservadas y de las minúsculas para los nombres de los objetos. En SQL, los nombres de los objetos tienen una longitud máxima (depende de cada motor), son sensibles a las mayúsculas y a las minúsculas y no soportan espacios intermedios en los nombres; normalmente, se utilizan el carácter guión bajo o ‘_’ para unir las palabras y, de esta manera, evitar los espacios. En Oracle, los nombres,

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.4 El lenguaje SQL y su sublenguaje de defnición de datos o DDL

107

que pueden tener hasta 30 caracteres, deben empezar con una letra y no con número o signo. Los signos permitidos son: ‘$’, ‘_’ y ‘#’. Los nombres de los objetos se identifcarán con su esquema y con su nombre. Para ello, se utilizará la notación “esquema.nombre”. Esta regla se puede resolver, también, con el uso de sinónimos públicos que referenciarán directamente a los objetos. Originalmente, en el modelo de datos se incluyeron todos los acentos de las palabras, pero en la creación no se los utilizó para facilitar el trabajo de escritura de las sentencias SQL. Las sentencias SQL se pueden extender por varias líneas y, por ejemplo en Oracle, fnalizan con un punto y coma “ ; ” y tienen como separador interno o semántico el espacio ‘ ’ o la coma ‘,’. Ejemplos de creación de objetos del modelo de datos de ventas:

CREATE TABLE articulo

(codigo_del_articulo VARCHAR2(8),

nombre_de_articulo VARCHAR2(30) NOT NULL, precio_unitario NUMBER(8,3)); CREATE TABLE clientes

(codigo_del_cliente VARCHAR2(8),

nombre _del _cliente VARCHAR2(30) NOT NULL); CREATE TABLE facturas

(sucursal

NUMBER(2),

número_de_factura

NUMBER(2),

fecha_de_factura TIMESTAMP, forma_de_pago_factura VARCHAR2(3), codigo_del_cliente

VARCHAR2(8),

total_de_la_factura

NUMBER(14,2));

CREATE TABLE detalle_de_factura (sucursal numero_de_factura

NUMBER(2),

codigo_del_articulo

VARCHAR2(8),

NUMBER(2),

cantidad_del_artículo NUMBER(8,3) NOT NULL, precio_unitario_del_articulo

NUMBER(8,3),

subtotal_del_articulo

NUMBER(9,3));

En las columnas en las que se prohíbe, por regla de negocios, que tenga valores null, se ubican las restricciones de la columna con las palabras NOT NULL. A modo de ejemplo, se usan los tipos de datos de Oracle, donde NUMBER es un tipo de dato que soporta hasta 38 dígitos, en los que se incluyen los decimales y sus signos. Para los caracteres alfanuméricos de longitud variable, se utiliza VARCHAR2, que soporta hasta 4096 caracteres. Para la fecha, se emplea Timestamp —que es el tipo

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 08

3 - SQL

de datos que se ha defnido como estándar— que soporta seis posiciones para fracciones de segundo y defne la zona horaria, lo que aumenta las prestaciones para el registro de tiempos. Ejemplos de m o d i f c a c i ó n de objetos de la base: Una vez creada la tabla “Clientes”, resultó necesario separar los nombres y los apellidos con la sentencia ALTER TABLE. Esto es, agregar una columna. ALTER TABLE cliente ADD apellido_del_cliente VARCHAR2(30)); Otra alternativa —si aún no se tiene flas ni restricciones referenciales sobre la tabla que se modifcará— sería eliminarla y volverla a crear con todas las columnas o restricciones, según los últimos requerimientos. DROP TABLE clientes; CREATE TABLE clientes

(codigo_del_cliente VARCHAR2(8),

nombre _del _cliente VARCHAR2(30), apellido _del _cliente VARCHAR2(30)); Se notará que, en el momento de la creación de las tablas, no se incluyó nada acerca de las claves primarias y las foráneas; estas restricciones (constraints) se agregarán con ALTER. La sentencia ALTER TABLE tiene, como modifcadores, las acciones ADD, MODIFY y DROP, que pueden agregar, modifcar y eliminar columnas. En algunas implementaciones de lenguajes se permite el uso, dentro de ALTER, de RENAME, que renombra las columnas de una tabla, pero su explicación detallada excede el propósito del libro. Se agregarán, con ALTER, las restricciones correspondientes a las claves primarias y a las foráneas de las tablas anteriores; luego, se ilustrará, con un ejemplo, cómo se puede hacer, siempre bajo el supuesto de que no tienen flas y que las tablas referenciadas en la clave foránea ya existen. ALTER TABLE clientes ADD CONSTRAINT cliente_pk PRIMARY KEY (codigo_del_cliente)); Después de crear la tabla “Artículos” se defne su clave primaria. ALTER TABLE articulo ADD CONSTRAINT articulos_pk PRIMARY KEY (codigo_del_articulo)); Para crear la clave primaria en el momento de crear la tabla, la sintaxis tendría estas dos variantes: •

Variante uno, como restricción de columna (no se puede usar cuando la clave es múltiple).

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.4 El lenguaje SQL y su sublenguaje de defnición de datos o DDL

CREATE TABLE articulo

109

(codigo_del_articulo VARCHAR2(8) PRIMARY KEY,

nombre_de_articulo VARCHAR2(30), precio_unitario NUMBER(8,3)); •

Variante dos, como restricción de tabla (es la única que se puede usar cuando la clave es múltiple).

CREATE TABLE articulo

(codigo_del_articulo VARCHAR2(8),

nombre_de_articulo VARCHAR2(30), precio_unitario NUMBER(8,3), CONSTRAINT articulos_pk PRIMARY KEY (codigo_del_articulo)); En este último ejemplo, se usó la cláusula CONSTRAINT para que la restricción tuviera un nombre “articulos_pk”, que es muy útil cuando una aplicación trata de cargar una fla repetida y el servidor se lo impide. Éste le enviará un mensaje diciendo que esta restricción, “articulos_pk”, ha sido atacada, lo que permitirá entender que se ha intentado cargar una fla con estas columnas con null o con un valor de clave repetido. Ahora se agregarán las claves foráneas y se advertirá que la tabla referenciada debe existir. En una implementación real, también se considerará que si las tablas ya existen desde hace tiempo y tienen flas que no cumplen con las relaciones que se introducirán, se le indicará que ignore los incumplimientos previos, pero no se lo verá en la sintaxis porque es un tema avanzado en el estudio de SQL, que excede el alcance de este libro. ALTER TABLE factura ADD CONSTRAINT cliente_fk FOREIGN KEY (codigo_del_cliente) REFERENCES clientes(codigo_del_cliente); ALTER TABLE detalle_de_factura ADD CONSTRAINT articulo_fk FOREIGN KEY (codigo_del_artículo) REFERENCES artículo(codigo_del_ articulo); ALTER TABLE detalle_de_factura ADD CONSTRAINT factura_fk FOREIGN KEY (numero_de_la_factura) REFERENCES factura(numero_de_la_factura); Para completar las restricciones que permite el lenguaje SQL, se deberá también nombrar el de validación de contenido o CHECK, que impide ingresar un valor en una columna que no cumpla la condición defnida en la restricción. Se aplicará un requerimiento que indicará que los precios de los artículos no serán negativos, entonces:

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 10

3 - SQL

ALTER TABLE artículo ADD CONSTRAINT precio_ck CHECK (precio_unitario_del_articulo > 0);

Para ejemplifcar otras sentencias DDL, se ha omitido erróneamente una ‘s’ en el nombre de la tabla “Artículos”, para corregirlo se utilizará RENAME. Será tarea del motor actualizar todos objetos que hayan sido creados con referencias a este objeto para que se mantenga esta relación. RENAME TABLE artículo TO artículos; Ahora es el momento de crear otros objetos de datos: las vistas y los índices. Aunque aún no se ha visto la sentencia SELECT, se aplicará una sentencia muy simple que, sin analizar los detalles, traerá todas las facturas que tengan en el código de cliente un valor ‘A01’.

CREATE VIEW v_factura_clienteA01 AS SELECT numero_de_factura, fecha_de_factura, monto_de_factura FROM

facturas

WHERE codigo_de_cliente = A 0 1 ’

Así, se habrá creado una vista que se usará de la misma forma que una tabla; por eso, se recomienda que en el nombre se identifque claramente que se trata de una

vista. Por ejemplo, si se utiliza un prefjo como ‘v_...’, como se mostró en el ejemplo anterior. Para los índices la sintaxis es: CREATE INDEX factura_fecha_idx ON factura(fecha_de_la_factura); La consecuencia de esta sentencia es que se ha creado un índice —implementado como un segmento de datos— similar a una tabla en la que se guarda el identifcador único de las que tienen cada fecha distinta; esto facilitará el acceso a las páginas y a las flas donde estén las fechas buscadas, de acuerdo con el funcionamiento del motor de la base. Habitualmente, estos índices tienen la característica de ser árboles B, lo que garantiza el acceso rápido a las flas que cumplen el criterio de búsqueda que use la columna “fecha_de_la_factura”. En otras variantes de sintaxis, se puede indicar que no se permitan las repeticiones (“CREATE UNIQUE INDEX …”), o que arme una estructura de índice que no se base en árboles, sino en una estructura en mapas de bit (“CREATE BITMAPPED INDEX …”) con características dirigidas a la indexación de columnas con baja selectividad, o con pocos valores distintos, lo que permite que se resuelvan rápidamente las consultas basadas en las columnas con pocos valores diferentes y gran cantidad de flas cada uno. La creación de roles, a los que se puede defnir como un conjunto de privilegios que se asignan siempre en bloque, se presentará luego de la creación de usuarios. CREATE USER jgomez IDENTIFIED BY lacontraseña;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.4 El lenguaje SQL y su sublenguaje de defnición de datos o DDL

111

El rol de operador de consultas “op_consultas” se crea de la siguiente manera: CREATE ROLE op_consultas; Los roles se crean para facilitar la administración de privilegios de muchos objetos a grupos de usuarios que necesitan los mismos accesos porque realizan trabajos similares. En este ejemplo, se le darán todos los privilegios al rol “op_consulta” y, luego, se le asignará al usuario “jgomez”. En Oracle, se puede defnir un rol con contraseña para que sea activado después de que el usuario que lo posee se conecte, cuando tenga que realizar una tarea que requiera los privilegios del rol y solicite activarlo. A la vez, se le solicita una contraseña específca para que esa activación pueda ser posible. En algunas bases de datos, con la mera creación del usuario alcanza para poder conectarse inmediatamente; en Oracle, es preciso que se le dé los permisos de conexión “create session”, con el siguiente grupo de sentencias DDL: GRANT y REVOKE. Para esto, se aplicará al usuario un privilegio de acción o de sistema.

En Oracle, se puede defnir un rol con contraseña para que sea activado después de que el usuario que lo posee se conecte, cuando tenga que realizar una tarea que requiera los privilegios del rol y solicite activarlo.

GRANT CREATE_SESSION TO jgomez; Otro privilegio de acción o de sistema sería darle al usuario la posibilidad de consultar cualquier tabla en la base de datos, que se aplicará a las actuales y a las que no se han creado aún. GRANT SELECT ANY TABLE TO jgomez; Ahora, se le otorgará al rol todos los privilegios y, luego, se los asignaremos todos juntos al usuario con un solo GRANT. Con los privilegios de objetos, que son SELECT, ALTER, DROP, DELETE, REFERENCE, INDEX y el que abarca a todos, ALL, la sintaxis indicará sobre qué objetos se asignarán los privilegios al rol: GRANT SELECT ON articulos TO op_consulta; Si quisiéramos darle los otros privilegios solamente a jgomez, se hace directamente: GRANT DELETE ON articulos TO jgomez; Para evitar escribir todas las sentencias, que podría ejecutar el usuario, se puede abreviar con: GRANT ALL ON articulo TO jgomez; Luego, le otorgaremos el rol de op_consultas al usuario jgomez, de esta manera: GRANT op_consultas TO jgomez; Si por alguna razón se quisiera quitar estos privilegios, se usará la sentencia REVOKE como sigue:

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 12

3 - SQL

REVOKE CREATE_SESSION FROM jgomez; REVOKE op_consulta FROM jgomez; (aquí le quitamos el rol al usuario) REVOKE ALL FROM jgomez;

Se fnalizará el tratamiento de DDL con un ejemplo de la creación de comentarios

sobre una tabla y sobre una columna. COMMENT ON articulos (‘Contendrá todos la información de los artículos que se venden en este negocio’); COMMENT ON articulos.nombre_del_articulo (‘Almacena el nombre completo de cada artículo’)

3.5 Sentencias del sublenguaje DML

El sublenguaje DML abarca a SELECT, INSERT, DELETE y UPDATE que sirven para realizar consultas, insertar flas, para borrarlas, y para cambiarle el contenido de las columnas en las flas existentes y para que cumplan con las condiciones de la cláusula WHERE.

El sublenguaje DML (Data Manipulation Language) contiene sentencias para la administración de los datos. Este sublenguaje abarca a SELECT —que se tratará inmediatamente— INSERT, DELETE y UPDATE que sirven —respectivamente— para realizar consultas, insertar flas, para borrarlas, y para cambiarle el contenido de las columnas en las flas existentes y que cumplan con las condiciones de la cláusula WHERE, como se verá en los siguientes ejemplos. SELECT es la sentencia que permite la obtención de los valores almacenados en las columnas de las flas recuperadas como resultado del acceso a las tablas o a las vistas de la base de datos. A esta sentencia también se la denomina “Consulta”, porque es, justamente, lo que hace el motor: busca las flas de las tablas incluidas en su cláusula FROM y realiza las operaciones defnidas en el Álgebra relacional para seleccionar aquellas flas que cumplan las condiciones expresadas. Esta sentencia se estructura en distintas cláusulas, con el funcionamiento que se describirá a continuación: SELECT FROM WHERE [AND, OR, NOT] GROUP BY HAVING [AND, OR, NOT] ORDER BY [DESC, ASC]; Las cláusulas obligatorias son SELECT y FROM, en Oracle; en otras bases como MySQL, solo es obligatoria la cláusula SELECT. En esta cláusula, se puede realizar la operación Proyección del Álgebra relacional cuando se enumeran solo algunas columnas de la tabla que se consultará. Para evitar esta operación, se incluirán todas las columnas, una por una, o se usará el operador

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.5 Sentencias del sublenguaje DML

113

asterisco (‘ * ‘) que indicará que es necesario la recuperación de todas las columnas de la o las tabla/s del FROM. En la primera cláusula, se pueden combinar las columnas de las tablas, las vistas o las subconsultas de la cláusula FROM, funciones como las que veremos en los párrafos siguientes y subconsultas. Estas subconsultas devuelven un solo valor, por lo que se las denomina “escalares”. También se agregan valores literales que se repetirán por cada fla mostrada. Por ejemplo: la sentencia muestra datos constantes, una columna con el nombre de los empleados, luego el sueldo y, en la columna aumento, el cálculo de sueldo con un 20% de aumento. Es para destacar que en los dos últimos se adoptó un “Alias de Columna” para titular las columnas con un nombre distinto al de las columnas de la tabla. SELECT ‘El nombre es:’, ename, salario salarioAnterior, salario*1.20 aumento, FROM empleados; Resulta en: ‘El nombre es:’ El nombre es: El nombre es: El nombre es: El nombre es: El nombre es:

ename

salarioAnterior

aumento

Perez

1100

1200

Lopez

900

1080

Suarez

1100

1320

Gianni

700

840

Vinci

1500

1800

Las funciones de fla simple retornan un solo valor por cada fla de una tabla o de una vista consultada.

3.5.1 Funciones de f l a simple En el ejemplo anterior, se vio el uso de una función de fla simple, el operador multiplicación ‘*’. En este caso, ‘*’ es la función multiplicación que, en otro contexto, signifca “todas las columnas de las tablas que fguran en el FROM”. Las funciones de fla simple retornan un solo valor por cada fla de una tabla o de una vista consultada. Estas funciones pueden usarse en la lista de columnas del SELECT, en las cláusulas WHERE y HAVING, que forman parte de las condiciones y demás. 3.5.2 F u n c i o n e s n u m é r i c a s La mayoría de las funciones numéricas, que reciben y devuelven valores numéricos, retornan valores NUMBER con exactitud en 38 dígitos decimales. Las más simples son los operadores matemáticos: ‘*’ por, ‘/’ dividido, ’+’ más, ’-‘ menos Las funciones como COS, COSH, EXP, L N , LOG, SIN, SINH, SQRT, TAN y TANH tienen una exactitud de 36 de dígitos decimales y las funciones ACOS, ASIN, ATAN una exactitud de 30 dígitos decimales. A modo de ejemplo, algunas funciones del SQL de Oracle 10g son:

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 14

3 - SQL

A B S (Valor absoluto) A C O S (Arc coseno) ASIN (Arc seno) ATAN (Arc tangente) CEIL

(Valor tope)

COS

(Coseno)

C O S H (Coseno hiperbólico) EXP

(Exponente)

FLOOR (Valor mínimo)

LN

(Logaritmo neperiano)

LOG

(Logaritmo decimal)

MOD

(Resto de la división)

POWER (Elevar a una potencia) ROUND (Number) (Redondeo numérico) SIGN (Signo)

Para una lista completa de funciones de fla simple en Oracle visite: http://tahiti.oracle.com

SIN

(Seno)

SINH

(Seno hiperbólico)

SQRT

(Raíz cuadrada)

TAN

(Tangente)

TANH (Tangente hiperbólico) TRUNC (Number) (Truncar numérico)

Las funciones de carácter son aquellas que reciben argumentos numéricos, de fecha o de caracteres y devuelven valores en formato carácter. Éstos son: CHR (devuelve un carácter de acuerdo con un argumento numérico, normalmente el valor ASCII) CONCAT (Concatena valores) INITCAP (Pone mayúscula a las primeras letras de cada palabra) LOWER (Transforma en minúsculas) LPAD (Completa a la izquierda con un carácter hasta una cantidad de caracteres) LTRIM (Recorta una cantidad de caracteres a la izquierda) REPLACE (Reemplaza un carácter por otro) RPAD (Completa a la derecha con un carácter hasta una cantidad de caracteres) RTRIM (Recorta una cantidad de caracteres a la derecha) SUBSTR (Toma una subcadena de una cantidad de caracteres desde una posición determinada) UPPER (Transforma en mayúsculas)

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.5 Sentencias del sublenguaje DML

115

Las funciones de fecha y hora son: ADD_MONTHS (Suma meses a una fecha) CURRENT_DATE (La fecha del sistema) EXTRACT (Datetime) (Extrae fecha u hora) LAST_DAY (Último día del mes de la fecha argumento) MONTHS_BETWEEN (Cantidad de meses entre dos fechas argumento) ROUND (date) (Redondeo de fechas, a mes o a año) SYSDATE (Fecha del sistema) TO_CHAR (Datetime) (Traducir a caracteres una fecha) TRUNC (Date) (Truncar una fecha)

3.5.3 Funciones generales de comparación Las funciones generales de comparación determinan los valores mayores o menores de un conjunto de datos: GREATEST (Mayor) LEAST (Menor)

3.5.4 Funciones de conversión Convierten un valor de un tipo de datos a otro tipo de datos: TO_CHAR (Character) TO_CHAR (Datetime) TO_CHAR (Number) TO_CLOB TO_DATE TO_LOB TO_MULTI_BYTE TO_NUMBER

3.5.5 Funciones de grupo Las funciones de grupo devuelven una fla con el resultado de sumar, contar, etc. de todas las flas resultantes de la consulta. En la cláusula WHERE de la consulta, no se pueden usar las funciones de grupo para fltrar flas porque el resultado de una función de grupo se conoce luego de reunir todas las flas. Es decir, luego de ejecutar el WHERE. Por eso, las funciones de grupo se usan en la cláusula HAVING. Las funciones de grupo son usadas comúnmente en combinación con la cláusula GROUP BY, con la que se divide a las flas seleccionadas porque cumplen con las condiciones de fltro del WHERE, en grupos basados en los distintos valores de las columnas incluidas en el GROUP BY.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 16

3 - SQL

Dada la tabla de estudiantes: Tabla Estudiantes Legajo

Apellido

Carrera

7898

Messi

SIS

6677

García

SIS

6644

Bremen

SOF

3566

Pérez

ABO

5522

Palermo

SOF

2123

López

ABO

5221

Vianni

ABO

4512

Suárez

SOF

GROUP BY columna” separa las flas del conjunto, en gru ismo valor en la columna. Tabla Estudiantes agrupada por carrera Legajo

Apellido

Carrera

7898

Messi

SIS

6677

García

SIS

6644

Bremen

SOF

5522

Palermo

SOF

4512

Suárez

SOF

3566

Perez

ABO

2123

López

ABO

5221

Vianni

ABO

La consulta: SELECT carrera, count(*) FROM estudiantes GROUP BY carrera; Nos da como resultado: Carrera COUNT(*) ABO SIS SOF Alfaomega

3 2 3 Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.5 Sentencias del sublenguaje DML

117

En el ejemplo, se aplicó la función COUNT(*), que cuenta las flas seleccionadas y fltradas por la consulta y muestra el resultado del conteo. Si se usa una función de grupo sin la cláusula GROUP BY, éstas se aplicarán a todo el conjunto de flas seleccionadas. Se usan las funciones de grupo también en la cláusula HAVING, para fltrar los grupos que no cumplen con las condiciones. WHERE fltra grupos antes de que se armen los grupos y HAVING fltra flas una vez que los grupos están armados. Todas las funciones de grupo ignoran los valores nulls; esto es, si en la columna “Apellido” se va a contar con COUNT(Apellido) y tiene en todas las flas valores null, esta función devolverá 0 (cero); si solo en algunas tuviera nulls, contará todas las flas con valores distintos de null. El asterisco en COUNT(*) le indica a la función que cuente todas las flas de la o las tablas que están en el FROM. Según la defnición de una tabla relacional, ésta no puede tener una fla con todos valores null o fla nula. Es posible anidar funciones de grupo, dada la tabla “Notas” (se muestran solo algunas columnas):

Tabla Notas Notas Legajo

Id_Materia

Nota

7898

1

7

6677

1

7

6644

2

8

2123

2

9

5522

3

10

2123

3

10

5221

5

2

4512

5

4

Para calcular el promedio de la nota más alta de cada materia, se puede hacer: SELECT AVG(MAX(nota)) FROM examenes GROUP BY id_materia; AVG(MAX(nota)) 7,5 Esta consulta evalúa el agrupamiento interno (MAX(nota)) trayendo las notas más altas de cada materia, las agrupa nuevamente y, luego, les calcula el promedio. Tomó la nota máxima de cada material (7, 9, 10, 4) y las promedió (30/4)= 7,5.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 18

3 - SQL

Algunas de las funciones de grupo más usadas son: AVG (Average o promedio) COUNT (Conteo) MAX (Máximo) MIN (Mínimo) STDDEV (Desviación estándar) SUM (Suma) VARIANCE (Varianza) 3.5.6 La cláusula FROM En la cláusula FROM, se enumeran las tablas, las vistas y las subconsultas que se consultarán para buscar las columnas que se enumeran en el SELECT. Cuando hay más de una referencia a tablas, se dice que la consulta es MULTITABLA. En este caso, se está frente a la aplicación de la operación reunión (JOIN) del Álgebra relacional y, si no se escriben las condiciones de reunión en el WHERE, el optimizador de consultas realizará un producto cartesiano que relacionará todas las flas de las tablas reunidas, lo que generará resultados falsos: si se tuvieran cinco alumnos y tres exámenes rendidos, la reunión sin “condiciones de reunión”, daría quince flas (5 x 3 flas). Esto produce un gran volumen de flas reunidas que, habitualmente, no se utilizarán. Lo expresado en el párrafo precedente es en general, pero se observa que, para algunos casos, esta operación —producto cartesiano— será necesaria, por ejemplo, en el caso en que se requiera relacionar todos los jugadores de un torneo de tenis para armar los partidos posibles, teniendo en cuenta que se eliminarán los pares en los que se repiten los mismos jugadores. ¿Cómo sería esto? Supongamos que hay catorce empleados y se quiere tener previstos todos los partidos posibles (los imposibles serían, por ejemplo, que un empleado jugara contra sí mismo), para esto se puede hacer el producto cartesiano de la tabla “Empleados” consigo misma con distinto alias de tablas, para identifcar a qué rol corresponde. En el primer intento, dejará un producto cartesiano de la tabla “Empleados” consigo misma. Esta forma de reunión se denomina, también, Auto Join. SELECT l.ename Local, ‘ juega con ‘, v.ename Visita FROM empleados l, empleados v Si esta tabla tiene 14 flas, da un resultado de 196 flas (ver en la Fig. 3.1, en la que se muestran, a modo ilustrativo, solo las primeras). En la siguiente consulta, se resolverá el requerimiento que armará los partidos en el campeonato interno de la empresa (ver Fig. 3.2). SELECT l.ename Local, ‘ juega con ‘, v.ename Visita FROM empleados l, empleados v WHERE l.ename v.ename

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.5 Sentencias del sublenguaje DML

Si bien la intención no es adelantarse al próximo apartado, se observa que hay una cláusula WHERE con una condición que evita que se una al mismo empleado como local y como visitante. Es importante destacar que se han usado alias de tablas para identifcar las columnas “ename”, que como vienen de la misma tabla, pero repetida en el FROM, se las ha califcado con la letra que se escribe, en esta cláusula, a continuación de la tabla. Esta forma de nombrar las columnas de una tabla, en una posición determinada, se denomina alias de tabla y, como recomendación, se usó la letra inicial del rol o del signifcado que tiene cada repetición de la tabla en el SELECT; para este caso, se adoptó la “l” para Local y la “v” para Visita.

Fig. 3.1 Producto cartesiano: se observa que es imposible que SMITH juegue contra SMITH, sin embargo, la operación lo permite.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

119

1 20

3 - SQL

Fig. 3.2 Reunión sin producto cartesiano. Se agregó una restricción en el WHERE y se armó el conjunto de partidos posibles Nótese que el resultado de 182 flas es porque se excluyeron los partidos entre un empleado contra él mismo; es decir: aquellos partidos imposibles que totalizan 14

partidos. Entonces, cuando en el FROM se mencionan más de una tabla y se desea evitar el producto cartesiano, se debe escribir una condición de reunión en el WHERE generalmente, en estas consultas, se reúnen las tablas a través de sus claves foráneas y claves primarias, que concretan la reunión entre tablas relacionadas. Pero esto no es excluyente, también se pueden escribir otras condiciones de reunión con columnas del mismo dominio de valores; es decir, comparables. Para reunir las tablas, existen dos alternativas de sintaxis: la primera y más antigua, es nombrarlas en el FROM y, luego, se evitará el producto cartesiano con condiciones de reunión en el WHERE. En la segunda, se escribe la palabra JOIN entre las tablas y, después, en el mismo FROM, se escribirá la condición dentro del operador ON. De esta manera, se obtendrá el mismo resultado que la Fig. 3.2: SELECT l.ename Local, ‘ juega con ‘, v.ename Visita FROM empleados l JOIN empleados v ON (l.ename v.ename)

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.5 Sentencias del sublenguaje DML

121

Esto se considera como estándar desde SQL3. Se adjunta la ayuda de MySQL sobre la sintaxis de esta forma de escribir las reuniones de tablas. table_reference [INNER | CROSS] JOIN table_factor [join_condition] | table_reference STRAIGHT_JOIN table_factor | table_reference STRAIGHT_JOIN table_factor ON condition | table_reference LEFT [OUTER] JOIN table_reference join_condition | table_reference NATURAL [LEFT [OUTER]] JOIN table_factor | table_reference RIGHT [OUTER] JOIN table_reference join_condition | table_reference NATURAL [RIGHT [OUTER]] JOIN table_factor join_condition: ON conditional_expr | USING (column_list) En la sintaxis mostrada aparecen operadores que no serán tratados en este libro. 3.5.7 L a c l á u s u l a W H E R E En esta cláusula, se escriben las condiciones de fltro que permiten elegir aquellas flas que se quieren mostrar. La condición es una construcción que tiene tres partes en general y, como excepción, cuando se usa el operador de comparación EXISTS o NOT EXISTS, dos. Una condición posee como elementos una columna, un operador de comparación y un valor constante, otra columna, una variable o una subconsulta que devuelva uno o varios valores, que se aceptan solamente si el operador es IN, NOT IN, EXISTS y NOT EXISTS, que son los que tratan con lista de valores.

En la cláusula WHERE, se escriben las condiciones de fltro que permiten elegir aquellas flas que se quieren mostrar.

Ejemplos de condiciones: “Una fla es elegida si… WHERE sal > 1000

… es verdad que el salario de la fla es mayor a 1000”.

WHERE ename = ‘SMITH’ …es verdad que el apellido de la fla es ‘SMITH’ (en mayúsculas)”. WHERE hiredate < ‘01/03/1998’ … es verdad que la fecha de contratación es anterior al primero de marzo de 1998”. o negarlas con NOT, “Una fla es elegida si … WHERE NOT sal > 1000 1000”.

… NO es verdad que el salario de la fla es mayor a

También se pueden combinar las condiciones, lo que permite que se las evalúe, simultáneamente, con los coordinadores AND y OR. De esta manera, se obtendrá que: “Una fla es elegida si…

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 22

3 - SQL

WHERE (sal > 1000) AND (ename = ‘SMITH’) … es verdad que el salario de la fla es mayor a 1000 y que tiene un valor en apellido igual a ‘SMITH’ (en mayúsculas). WHERE hiredate < ‘01/03/1998’ OR (ename = ‘SMITH’ ) … es verdad que la fecha de contratación es anterior al primero de marzo de ese año o si el valor de su columna ename es igual a ‘SMITH’ (en mayúsculas)”. No hay límites en la cantidad de condiciones a defnir en la cláusula WHERE. Las múltiples combinaciones posibles de éstas, permiten obtener las flas requeridas para responder cualquier requerimiento de datos de tablas correctamente normalizadas. Los operadores de comparación son: = igual < menor que > mayor que distinto que = ANY/ALL compara con todos los valores de una lista, =ANY es equivalente a IN < ALL es menor que todos los valores de una lista o subconsulta. > ALL es mayor que todos los valores de una lista o subconsulta. = ALL permite detectar al mayor de todos los valores de una lista o subconsulta. < ANY es menor que algunos de los valores de una lista o subconsulta. > ANY es mayor que algunos de los valores de una lista o subconsulta. IN es igual que al menos uno de los valores de una lista o subconsulta. NOT IN no es igual que al menos uno de los valores de una lista o subconsulta. BETWEEN límite inferior AND límite superior está dentro de un rango inclusivo. NOT BETWEEN límite inferior AND límite superior está fuera de un rango inclusivo. LIKE patrón como % (comodines de múltiples valores y múltiple cantidad) y _ idem pero solo de una posición. NOT LIKE no cumple con un patrón como % (comodines de múltiples valores y múltiple cantidad) y _ idem pero solo de una posición. EXISTS test de existencia en una subconsulta. NOT EXISTS test de no existencia en una subconsulta.

3.5.8 L a c l á u s u l a G R O U P B Y Como se vio en la explicación de las funciones de grupo, esta cláusula defne sobre qué valores de columna o columnas se basará el optimizador para agrupar las flas por sus distintos valores. 3.5.9 L a c l á u s u l a H A V I N G Una vez defnidos los grupos, se puede escribir en HAVING una condición que usa las funciones de grupo para poder fltrar o seleccionar y mostrar solo aquellos grupos que cumplen con las condiciones presentes en HAVING.

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.6 Sentencias del sublenguaje DML. INSERT, UPDATE, DELETE

123

Se la suele comparar con la cláusula WHERE, porque aplica condiciones, pero que quede claro que WHERE fltra flas; HAVING fltra grupos armados en GROUP BY. 3.5.10 L a cláusula O R D E R B Y La última cláusula de la sentencia SELECT es la que permite dar el orden deseado a las flas encontradas que cumplan la condición, junto con los valores de las funciones y otros cálculos o formateos realizados con esta sentencia. Es posible combinar varias columnas para ordenar y el orden de aparición de estas columnas en la cláusula ORDER BY no es trivial, comenzará por la primera columna que aparece luego de la palabra BY. Existen dos indicadores del sentido en el que se debe ordenar, DESC de descendente o ASC de ascendente. Si no se indica ninguno, se toma por defecto ASC. Así, si se usa DESC como indicador del sentido del ordenamiento, mostrará de mayor a menor y, si es ASC, de menor a mayor. Esto es, en cada columna.

3.6 Sentencias del sublenguaje DML. INSERT, UPDATE, DELETE 3.6.1 Sentencia INSERT La sentencia INSERT del grupo de sentencias del Data Manipulation Language permite insertar flas en una tabla e ingresar columna a columna los valores de cada una de ellas: INSERT INTO empleados (empno, ename, job, mgr, hiredate, sal, comm, deptno)

La sentencia INSERT del grupo de sentencias del DML permite insertar flas en una tabla e ingresar columna a columna los valores de cada una de ellas.

VALUES (8000, ‘Alves, Pedro’, ‘Programa’, 7411, 3500, null, 20) La lista de columnas se puede obviar, pero por claridad se sugiere no dejar de consignarla. Otra forma para insertar flas en una tabla —y más de una por ejecución— es la que incluye un select dentro del insert. A esta sentencia subordinada, habitualmente se la denomina subconsultas: INSERT INTO empleados_historico (empno, ename, job, mgr, hiredate, sal, comm, deptno, fecha_carga); SELECT empno, ename, job, mgr, hiredate, sal, comm, deptno, current_date FROM empleados WHERE hiredate < ‘01/01/2000’; En este caso, se parte del supuesto de que estamos insertando, en la tabla de empleados históricos, los empleados contratados antes del 1 de enero de 2000, y se agrega la fecha actual en la columna “fecha_carga” de la mencionada tabla. En

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 24

3 - SQL

esta operación, se insertarán más de una f l a en la tabla objetivo, que es una de las aplicaciones de las subconsultas y se verá más en detalle en las siguientes lecturas.

3.6.2 Sentencia UPDATE La sentencia para cambiar el valor de una o más columnas en una tabla es UPDATE —que tiene la siguiente sintaxis en Oracle: UPDATE

tbl_name

SET col_name1 =expr1 [, col_name2=expr2 ...] [WHERE

where_condition];

Por ejemplo, si se desea aumentar el sueldo de todos los empleados la sentencia es:

UPDATE empleados SET sal = sal * 1.2;

Esto provoca un aumento de sueldo de un 2 0 % a todos los integrantes de la empresa; si se deseara que se le aumente a unos pocos, se utilizará la cláusula WHERE, que tiene las mismas características que la sentencia SELECT. Si, por ejemplo, a la empresa le interesara solo aumentarle el sueldo a los que ganan entre 1000 y 1200, la sintaxis sería la siguiente:

UPDATE empleados SET sal = sal * 1.2 WHERE sal BETWEEN 1000 AND 1200;

En esta sentencia UPDATE, se pueden usar subconsultas c o m o argumento del SET y c o m o parte del WHERE, c o m o en cualquier sentencia SELECT.

UPDATE empleados SET sal = (SELECT AVG(sal) FROM empleados) WHERE sal BETWEEN 1000 AND 1200;

En la sentencia anterior, se ha modifcado el sueldo de los que ganan entre 1000 y 1200 por el valor del sueldo promedio de todos los empleados. La sentencia MERGE es una combinación de INSERT y UPDATE y, con la sintaxis que contiene las dos sentencias, al ejecutarse, busca la fla; si la encuentra la modifca de acuerdo con la sintaxis del UPDATE.

Alfaomega

3.6.3 Sentencia MERGE La sentencia MERGE es una combinación de INSERT y UPDATE y, con la sintaxis que contiene las dos sentencias, al ejecutarse, busca la fla; si la encuentra la modifca de acuerdo con la sintaxis del UPDATE. Si no existe ninguna fla que cumpla con el

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.7 Sentencias del sublenguaje TCL de control de transacciones

criterio del WHERE, la inserta con la sintaxis del INSERT y si una fla cumple con una condición, la puede borrar. Ejemplo de la sintaxis en Oracle 10g: MERGE INTO bonus b USING ( SELECT empno, sal, deptno FROM empleados WHERE deptno =20) e ON (b.empno = e.empno) WHEN MATCHED THEN UPDATE SET b.sal = e.sal * 0.1 DELETE WHERE (e.sal < 40000) WHEN NOT MATCHED THEN INSERT (b.ename, b.sal) VALUES (e.name, e.sal * 0.05) WHERE (e.sal > 40000); 3.6.4 S e n t e n c i a D E L E T E Para borrar flas de una tabla, la sentencia DELETE es muy simple: alcanza con completar el nombre de la tabla y, opcionalmente, se puede incorporar la cláusula WHERE, con el funcionamiento que se vio en la sentencia SELECT. DELETE emp1 WHERE sal > 5000; Sin la cláusula WHERE y su condición, borraría todas las flas de la tabla; en cambio, con esa cláusula, en la columna “sal”, borrará aquellas flas con valores mayores a 5000.

3.7 Sentencias del sublenguaje TCL de control de transacciones Todos los cambios de datos en una base de datos se pueden hacer a través de una transacción. Estas transacciones se confrmarán con COMMIT o se desharán con ROLLBACK. Estas dos sentencias cierran la transacción. El motor de la base de datos, si la transacción se confrma, asegurará que se encuentren los datos modifcados. Si una transacción se deshace, el sistema asegurará que no quede trunca ni ningún dato modifcado sin corregir, como si nunca se hubiera realizado el cambio que se borró.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

125

1 26

3 - SQL

En el siguiente cuadro se observa una transacción: Cuadro 3.1 UPDATE cust_accounts SET balance = balance - 1500 WHERE account_no = ‘70-490930.1’; COMMIT; UPDATE cust_accounts SET balance = balance + 1500 WHERE account_no = ‘70-909249.1’; COMMIT;

Si este código se ejecuta y la base tiene un problema luego del primer COMMIT, las cuentas quedarán desbalanceadas, ya que se han debitado $1500 de la primera cuenta. En cambio, si se dejara solamente el último commit, estas sentencias se completarían o anularían conjuntamente, lo que impediría que quedaran desbalanceadas. La sentencia COMMIT confrma y guarda los cambios de la transacción en curso y libera los recursos bloqueados por cualquier actualización hecha con la transacción actual. Cuadro 3.2 COMMIT [WORK]; Si ejecutamos: Cuadro 3.3 DELETE FROM t_pedidos WHERE cod_pedido = 15; COMMIT; Borra un registro y se guardan los cambios.

ROLLBACK es la sentencia que permite deshacer la última transacción. Cuando se ejecuta, vuelve atrás las transacciones en todas las tablas hechas desde el último COMMIT. Su sintaxis es muy simple: ROLLBACK; En una transacción pueden defnirse puntos de salvaguarda o SAVEPOINTS, para poder realizar ROLLBACKs parciales, deshaciendo solamente los cambios realizados a partir de estos puntos.

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.8 Procesamiento de consultas

127

------SAVEPOINT inicio; --INSERT... UPDATE ... DELETE ... ... ROLLBACKTO SAVEPOINT inicio; Y deshace los cambios realizados a partir del SAVEPOINT inicio. Es necesario mencionar que si se escribiese un COMMIT entre SAVEPOINT y ROLLBACK, el punto de salvaguarda desaparecerá al confrmarse el cambio.

3.8 Procesamiento de consultas Las aplicaciones de software funcionan de acuerdo con los requerimientos de negocio y, normalmente, se prueban con volúmenes de datos iniciales, que no dan una idea del crecimiento potencial de las cantidades de flas que se agregarán con el funcionamiento continuo de la operatoria normal del negocio. Esto llevará a que, en un razonable período de tiempo, las aplicaciones comiencen a cumplir su tarea más lentamente, a medida que las tablas en las que se basa incrementen la cantidad de flas dentro de las tablas afectadas. Esta lógica evolución necesita que se entienda cómo funciona el mecanismo de ejecución de consultas para, de esta manera, mejorar la performance del sistema en general. Por esta razón, se describirán, brevemente, los componentes del procesamiento de consultas y las formas de resolver el plan de ejecución. Existen diferentes métodos para determinar qué recursos usará el ejecutor para resolver una sentencia SQL y, así, obtener el resultado esperado. Con esta información, se puede decidir qué alternativa realizará el trabajo en el menor tiempo posible. El ejecutor de sentencias SQL utiliza un proceso denominado plan de consulta, que se encarga de elegir el método de resolución para encontrar los datos requeridos por la sentencia. Este optimizador tiene dos estrategias o modos de funcionar: El primero, orientado a la sintaxis con la que está escrito, tiene un ranking con las reglas de acceso a los datos. Este modo se denomina Optimizador Basado en Reglas (RBO, Rules Based Optimizer) y, como se afrmó al comienzo de este párrafo, utiliza la forma en la que está escrita la sentencia y, con la información del diccionario sobre estructuras de datos, determina el plan de ejecución para responderle. Esta estrategia se desarrolló en el origen de las primeras bases de datos y como es estático en el modo de resolver el plan de ejecución, en muchos casos se reemplaza por otro que se apoya en las estadísticas de uso de los objetos y que se describe a continuación.

El RBO utiliza la forma en la que está escrita la sentencia y, con la información del diccionario sobre estructuras de datos, determina el plan de ejecución para responderle.

En el modo basado en costos o CBO (Cost Based Optimizer), el optimizador inspecciona cada sentencia e identifca los caminos posibles de acceso a los datos y establece los costos basado en la cantidad de lecturas lógicas que se realizarán para

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 28

3 - SQL

ejecutar la sentencia. Este modo emplea las estadísticas que se almacenan sobre los objetos afectados por la sentencia SQL para, de esta manera, determinar el plan de ejecución que demande menos recursos. El m o d o del optimizador, que se aplicará en las bases de datos Oracle, se fja por parámetros generales o de la base, en el nivel de la sesión, y, también, para cada sentencia en particular.

3.8.1 Plan de consultas Para cada sentencia, el optimizador prepara un árbol de operaciones denominado plan de ejecución que defne el orden y los métodos de operaciones que el servidor seguirá para resolverla. En un motor Oracle existen numerosas herramientas que permiten la elección de un determinado plan de ejecución y la performance asociada. A continuación, se enumerarán los principales recursos: En el paquete STATPACK, un conjunto de programas obtiene la información de las estadísticas almacenadas sobre los objetos de la base de datos. El comando SQL, EXPLAIN PLAN genera, en una sesión de base de datos, el plan que se ejecutará con una sentencia SQL dada. El utilitario TKPROF toma la salida de una sesión que está generando archivos de pistas de auditoría o TRACE y crea un archivo legible con la información que facilitará el estudio de las características del plan de ejecución. También es posible contar con AUTOTRACE —una opción de SQL*Plus— que elabora un plan de ejecución y las estadísticas relativas a las operaciones que se realizarán para cumplir con la sentencia. En una base de datos Oracle con el cliente SQL*Plus se puede usar el comando EXPLAIN PLAN que, en lugar de ejecutar una sentencia SQL, crea el plan de consultas en una tabla especial llamada PLAN_TABLE, que contendrá las operaciones que realizará al ejecutarse la sentencia. Por ejemplo: SQL>

EXPLAIN PLAN FOR

2

SELECT apellido FROM estudiantes; Se crea el plan y la consulta como se ilustra a continuación:

SQL>

SELECT *

2

FROM TABLE(dbms_xplan.display);

Este método de acceso a la PLAN_TABLE, vía el paquete provisto DBMS_XPLAN, es más efectivo ya que resume la información útil del resultado de EXPLAIN PLAN.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

3.9 Resumen

129

3.8.2 Optimización de consultas Con la información de los recursos utilizados por las distintas posibilidades de ejecución de una consulta determinada, será posible entender y elegir la manera de resolver la sentencia que mejor se adapte a las circunstancias requeridas y, eventualmente, se podría decidir si se tomarán medidas complementarias, como la creación de índices que optimicen los tiempos de acceso a la información requerida. Como hay diferentes modos de ejecutar una sentencia SQL —por ejemplo: alterando el orden de acceso a una tabla o a un índice—, el desarrollador puede infuir en la manera en la que el optimizador considere los distintos factores en un proceso en particular. Por ejemplo: incluir en la sentencia los HINTS, que son indicaciones específcas que el optimizador utilizará en la realización de determinadas tareas mediante la utilización de un índice especial o mediante la alteración del orden de acceso a las tablas de consulta. El tratamiento detallado de las distintas técnicas excede el alcance de este libro. Por esta razón, se recomienda al lector que amplíe estos conceptos en la documentación ofcial de los principales proveedores de bases de datos y en las fuentes de información técnica especializada en la materia.

3.9 Resumen Resumiendo, el lenguaje SQL es especializado en comunicarse con los servidores de Bases de Datos relacionales y que puede combinarse con lenguajes de uso general, como JAVA, Cobol, C, Fortran, etc., para construir aplicaciones. Recordemos, también, que SQL es declarativo y no procedimental, porque el escritor de sentencias SQL solamente describe el resultado deseado y no indica cómo resolver el trabajo para obtener ese resultado. Es relativamente sencillo de aprender y le permite, al usuario no especializado en programación, obtener resultados satisfactorios.

3.10 Contenido de la página Web de apoyo El material marcado con asterisco (*) solo está disponible para docentes.

3.10.1 Mapa conceptual del capítulo 3.10.2 Autoevaluación 3.10.3 Presentaciones*

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

slttjpl

Lenguaje procedimental como extensión de SQL

Contenido

Objetivos

4.1 Introducción

132

4.2 Vista general de PL/SQL

132

4.3 Uso del PL/SQL para acceder a la base de datos Oracle

132

4.4 Programas con PL/SQL

133

4.5 Componentes de un bloque PL/SQL

134

4.6 Cursores

135

4.7 Errores

136

4.8 El desarrollo de un bloque PL/SQL

136

4.9 Interacción con la base de datos Oracle

138

4.10 El tratamiento de transacciones en PL/SQL

139

4.11 Sentencias de control de flujo

141

4.12 Manejo de cursores

144

4.13 Manejo de errores

148

4.14 Construyendo procedimientos y funciones con PL/SQL

151

4.15 Resumen

159

4.16 Contenido de la página Web de apoyo

159

•

Conocer los antecedentes y el protocolo de estandarización de la extensión procedimental de SQL.

•

Conocer detalles de un lenguaje procedimental de SQL, PL/SQL de Oracle.

•

Conocer las estructuras de programación que se pueden escribir con PL/SQL.

•

Entender cómo se complementan las sentencias SQL con sentencias de control y estructuras de datos especiales.

•

Entender el manejo de errores de PL/SQL.

•

Ver ejemplos prácticos de las construcciones posibles con PL/SQL.

1 32

4 - Lenguaje procedimental como extensión de SQL

4.1 Introducción Este capítulo de SQL/PSM del estándar ISO/IEC 9075, con PSM (por sus siglas en inglés, Persistent Stored Modules o Módulos persistentes almacenados), se ocupa de la extensión procedimental de SQL, que incluye el control de fujo, el manejo de condiciones, las sentencias de señalización de condiciones, los cursores y las variables locales y la forma de asignar valores o expresiones a variables y parámetros. Además, SQL/PSM formaliza la declaración y el mantenimiento de las rutinas persistentes escritas en lenguaje de bases de datos, como los procedimientos almacenados. Esta parte del estándar es completamente opcional, ya que las distintas proveedoras de bases de datos tienen sus propios lenguajes de extensión procedimental de SQL: Transactional-SQL o T-SQL de Microsoft, para su SQLServer; Procedural Language SQL o PL/SQL, de Oracle; Procedural SQL o PSQL, para Postgresql. Este capítulo se centrará en PL/SQL. Para escribir aplicaciones con acceso a bases de datos con los lenguajes de uso general como Cobol, C o ForTran, sin usar las extensiones procedimentales de SQL, se escriben sentencias de este lenguaje (conocido como Embedded SQL o SQL Empotrado). Así, al programa en lenguaje anftrión con sentencias SQL empotradas, se lo precompila convirtiendo a la sentencias SQL en llamadas a librerías especiales provistas con el software de Base de Datos, y fnaliza el proceso con el compilador común del lenguaje anftrión. Con las extensiones procedimentales de SQL, se escriben funciones, procedimientos y paquetes que son llamados desde cualquier programa que lo necesite, aumentando la reutilización de código almacenado en la base.

4.2 Vista general de PL/SQL La extensión procedimental de SQL tiene ventajas sobre el SQL embebido ya que permite fjar la lógica y las reglas del negocio de las aplicaciones y almacenarlas en un solo lugar, dentro de la base de datos.

La extensión procedimental de SQL tiene ventajas sobre el SQL embebido que otros lenguajes de programación ofrecen desde hace mucho tiempo, ya que permite fjar la lógica y las reglas del negocio de las aplicaciones y almacenarlas en un solo lugar, dentro de la base de datos. En general, los lenguajes de extensión son simples y directos y poseen las construcciones comunes de los lenguajes de uso general. PL/SQL es así y agrega cosas que le permiten el tratamiento de los datos, la modularización de los bloques de código en funciones, los procedimientos, los triggers y los paquetes, además de un manejo de errores muy robusto. Las sentencias, que se comunican internamente con la base de datos, se almacenan en la base de datos Oracle. Observaremos, en esta vista general, los detalles básicos de las ventajas del uso de PL/SQL y sus construcciones básicas.

4.3 Uso del PL/SQL para acceder a la base de datos Oracle Muchas aplicaciones que usan la arquitectura Cliente/Servidor tienen una cuestión en común: la difcultad de mantener las reglas de negocio de una aplicación. Cuando las reglas de negocio están descentralizadas a lo largo de la aplicación, los desarrolladores deben realizar cambios en toda esta extensión e implementar pruebas

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.4 Programas con PL/SQL

133

de sistemas para determinar si los cambios han sido sufcientes. Sin embargo, en situaciones críticas en tiempo, estas pruebas integrales no pueden llevarse adelante, ya que aumentan el riesgo de salidas inesperadas de sistemas. La estrategia de diseño apunta a la centralización de la lógica en la aplicación, que permita una administración más sencilla de los cambios. Esta capa intermedia de la lógica de negocio en la aplicación puede ser diseñada con PL/SQL y con estos benefcios: •

PL/SQL se administra centralmente dentro de la base de datos Oracle. Se manejan el código fuente y los privilegios de ejecución con la misma sintaxis que se usó para manejar otros objetos de base de datos.

•

PL/SQL se comunica en forma directa o nativa con otros objetos de la base de datos Oracle.

•

PL/SQL es fácil de leer y tiene muchas características para modularizar el manejo de código y de los errores.

4.4 Programas con PL/SQL Hay varias formas de construir programas con PL/SQL, desde los diferentes tipos de módulo disponibles a los componentes de un bloque PL/SQL hasta las construcciones lógicas que manejan el fujo de los procesos. Se verán los componentes del lenguaje y algunos puntos importantes sobre cada una de sus áreas. 4.4.1 Modularidad Este lenguaje permite al desarrollador crear módulos de programas para mejorar la reusabilidad del software y para esconder la complejidad de la ejecución de una operación específca detrás de un nombre de procedimiento o función. Por ejemplo, en un proceso complejo, como el que requiere agregar un registro de un nuevo estudiante, que afecta a varias tablas relacionadas de distintas aplicaciones asociadas: la asistencia, la gestión académica y la contable, es posible crear un procedimiento que, a su vez, use varias construcciones PL/SQL almacenadas separadas o en un paquete para que, en un solo paso de carga de información, se cubra la complejidad que un alta de estudiante implica, y que estos distintos programas se usen en conjunto y también por separado en otros procesos.

Este lenguaje permite al desarrollador crear módulos de programas para mejorar la reusabilidad del software y para esconder la complejidad de la ejecución de una operación específca detrás de un nombre de procedimiento o función.

4.4.2 P r o c e d i m i e n t o s , f u n c i o n e s , triggers y p a q u e t e s Los módulos de PL/SQL se dividen en cuatro categorías: procedimientos, funciones, triggers y paquetes, cuyas defniciones siguen a continuación: Procedimientos: son un conjunto de sentencias que aceptan y retornan cero o más variables, que se denominarán parámetros. Funciones: son un conjunto de sentencias que aceptan parámetros y que su tarea principal es calcular un valor y devolverlo para fnalizar su trabajo; no pueden realizar transacciones mientras son ejecutadas.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 34

4 - Lenguaje procedimental como extensión de SQL

Triggers: también se conocen por su traducción como disparadores. Sin embargo, en este libro, se mantendrá la denominación de origen, que se podría defnir como “un conjunto de sentencias asociadas a una tabla de la base y también a los eventos de sistema”, como, por ejemplo, la conexión de un usuario o el inicio del apagado o del encendido de la base. Paquetes: son una colección de procedimientos y funciones que tienen dos partes: una especifcación de los procedimientos, funciones que están disponibles o que se ponen como públicas (además, pueden tener estructuras de datos defnidas por el usuario) y la otra parte del paquete —denominada cuerpo del paquete—, que contiene el código de los procedimientos y de las funciones especifcadas.

4.5 Componentes de un bloque PL/SQL Existen tres componentes de cualquier bloque PL/SQL de los presentados anteriormente: la sección de declaración de variables, la sección ejecutable y el manejo de excepciones. La sección de declaración contiene la identifcación de todas las variables que se usarán en el bloque de código. Una variable puede ser de un tipo de datos disponible en las base de datos Oracle, como así también de algún tipo exclusivo de PL/SQL. La sección ejecutable de un bloque comienza con la palabra clave BEGIN y fnaliza con la palabra END, o con la palabra EXCEPTION, que es el inicio del último componente encargado de atender los errores que ocurrieron en la sección ejecutable y de defnir cómo se debe manejar. Esta sección es opcional en PL/SQL. Existen dos tipos de bloques de código: los denominados bloques c o n nombre y los anónimos. Se verán dos ejemplos: el primero de un código de PL/SQL con nombre, más precisamente, una función denominada convertir_moneda: FUNCTION convertir_moneda

IN NUMBER(12,3),

(cantidad

moneda_original IN VARCHAR2, moneda_destino IN VARCHAR2) RETURNS NUMBER(12,3)

IS

/* ahora comienza la declaración */

conversion

IN NUMBER(12,3);

datos_mal

EXCEPTION;

/*inicio de la sección ejecutable de un bloque*/

BEGIN IF cantidad > 0 THEN

. . .; ELSE

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.6 Cursores

135

. . .; END IF; EXCEPTION

/*inicio de la sección de manejo de excepciones */

WHEN datos_mal THEN . . .; END; La otra clase de bloques se conoce como bloque sin nombre o anónimo. En esta clase de bloques, la sección de declaración se inicia, explícitamente, con la palabra DECLARE y contiene las mismas secciones que los bloques con nombre. /*inicio de sección de declaración de bloque*/

DECLARE conversion

IN NUMBER(12,3);

datos_mal

EXCEPTION; /*inicio de la sección ejecutable de un bloque*/

BEGIN IF cantidad > 0 THEN

. . .; ELSE

. . .; END IF; EXCEPTION

/*inicio de la sección de manejo de excepciones */

WHEN datos_mal THEN

. . .; END;

4.5.1 Las construcciones lógicas y de control de fujo Están disponibles las estructuras lógicas como loops o bucles FOR, WHILE y las sentencias IF-THEN-ELSE, la asignación de valores y de expresiones. Existen otras construcciones lógicas que incluyen tablas y registros propios de PL/SQL, diferentes de las tablas y de las flas de la base de datos. Todos estos ítems permiten al lenguaje soportar reglas de negocios y, también, proveer datos a las aplicaciones que lo soliciten.

4.6 Cursores Una de las fortalezas de PL/SQL es la habilidad de manejar cursores, que son los controladores de áreas de memoria que almacenan los resultados de una sentencia SQL. Se utilizan para realizar operaciones con cada fla resultante de una sentencia SELECT, ya que, en el entorno SQL, el resultado de una sentencia SELECT siempre es tratado como un conjunto de f l a s y no a cada una de ellas como Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

•" Los cursores son los controladores de áreas de memoria que almacenan los resultados de una sentencia SQL.

Alfaomega

1 36

4 - Lenguaje procedimental como extensión de SQL

una individualidad. Para el manejo de estas flas en un cursor, es necesario que se utilicen construcciones repetitivas con lógica incluida, como los loop y, también, las operaciones de manipulación de los cursores. Esto se profundizará más adelante con ejemplos concretos.

4.7 Errores Los errores se denominan excepciones en PL/SQL y se analizan implícitamente en cualquier lugar del código ejecutable en el que aparecen.

Los errores se denominan excepciones en PL/SQL y se analizan implícitamente en cualquier lugar del código ejecutable en el que aparecen. Si en algún momento ocurriera un error en el bloque de código, la correspondiente excepción al error se levantaría con la acción RAISE. En este punto, la ejecución en el código se detendrá y el control se transferirá al manejador de excepciones dentro de la sección de correspondiente, que se podrá escribir al fnal de la sección ejecutable. Esta sección, como es opcional en el bloque, puede que no se haya escrito, lo que hará que el error se envíe al entorno que convocó a este bloque, y allí se atenderá o se ignorará, según cómo se haya previsto la condición de error en este lenguaje anftrión.

4.8 El desarrollo de un bloque PL/SQL En esta sección, se verá cómo se declaran, se asignan valores y se usan las variables, dentro de los bloques que se han visto anteriormente. 4.8.1 Los tipos de datos de la base de datos Hay varios tipos de datos que se utilizan en PL/SQL y que corresponden a los tipos de datos que se usan en la base de datos. Estos son: NUMBER(tamaño[, precisión]): se usa para almacenar cualquier número. CHAR(tamaño), VARCHAR2(tamaño): se usan para almacenar una cadena de texto alfanumérico. El tipo CHAR ocupa todo el tamaño y agrega, al contenido signifcativo, los blancos hasta que cubra el tamaño de la variable. VARCHAR2 almacena solo el contenido signifcativo, lo que ahorra espacio. DATE: se usa para almacenar fechas, horas, minutos y segundos. LONG: almacena grandes bloques de texto, hasta 2 GigaBytes de largo. LONG RAW: almacena grandes bloques de datos en formato binario, como puede ser sonido digital e imágenes. Actualmente, Oracle recomienda que, en su lugar, se use el tipo de datos CLOB. ROWID: se usa para almacenar el formato especial de ROWIDs en la base de datos. El ROWID es un identifcador único para una fla dentro de una base de datos, que no puede ser modifcado por el usuario y es de uso exclusivo de Oracle. BLOB, CLOB, NCLOB, BFILE: son tipos de datos para objetos de gran tamaño que, respectivamente, están en formato binario, en formato carácter, con soporte de caracteres nacionales y en archivos con información en formato binario y que, por su tamaño, no se almacenan en tablas, sino en archivos administrados por el motor.

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.8 El desarrollo de un bloque PL/SQL

137

4.8.2 Tipos de datos que son propios del lenguaje PL/SQL Existen otros tipos de datos no diseñados para almacenar datos en una tabla, sino para manipulación de datos dentro de los bloques PL/SQL. Se clasifcan de la siguiente manera: DEC, DECIMAL, REAL, DOUBLE_PRECISION, INTEGER, INT, SMALLINT, NATURAL, POSITIVE, NUMERIC: son un subconjunto del tipo NUMBER que se usan para declaración de variables. BINARY_INTEGER, PLS_INTEGER: estos tipos de datos almacenan enteros y las variables defnidas así se deben convertir explícitamente a un formato de base de datos para que se almacenen en una columna. BOOLEAN: almacena un valor TRUE, FALSE o NULL. TABLE, RECORD: los tipos de datos TABLE pueden almacenar algo similar a un arreglo, mientras un RECORD puede almacenar variables con tipos de datos compuestos. En general, las variables que almacenarán datos para luego insertarlos en columnas de tablas de bases de datos, se defnen con el mismo tipo de datos que las columnas destino y, para no tener que buscar qué tipo de dato tiene cada columna que se afectará, cuando se defnen las variables se puede usar el modifcador %TYPE en la declaración de la variable; por ejemplo: DECLARE v_legajo

estudiantes.legajo%TYPE;

De esta manera, la variable v_legajo tendrá el tipo de datos declarado en la tabla “Estudiantes para legajo”. Esto ahorra esfuerzo y disminuye la probabilidad de errores en el tiempo de ejecución, con una pequeña sobrecarga en el momento de la compilación. Existe algo similar con el modifcador %ROWTYPE, que permite al desarrollador crear un tipo de dato compuesto con todas las columnas de la tabla referenciada: por ejemplo, con la tabla “Estudiantes”: DECLARE r_estudiante

estudiantes%ROWTYPE;

Con el ejemplo anterior, se habrá creado un RECORD con las columnas y con sus respectivos tipos de datos idénticos a las columnas de la tabla “Estudiantes”. En PL/SQL, también se deben declarar las constantes, según se ve en el ejemplo: DECLARE pi

CONSTANT NUMBER(15,14) := 3,14159265358;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 38

4 - Lenguaje procedimental como extensión de SQL

En el ejemplo, además de declarar como constante al identifcador pi, se ha inicializado su valor con el símbolo de asignación ‘:=’ y el valor exacto, que ya no podrá modifcarse durante la ejecución del programa. En el caso de las variables, se pueden usar varios modos de asignar variables, además de ‘:=’ , una función, cuya cláusula RETURN, le asignará el resultado a la variable, como parámetro de salida de un procedimiento y con la cláusula INTO en el SELECT, como se ejemplifcará más adelante.

4.9 Interacción con la base de datos Oracle Se verá cómo se usan las sentencias SELECT, INSERT, UPDATE y DELETE en los bloques de programación, cómo se utilizan los cursores implícitos y cómo se aplica el procesamiento de transacciones en PL/SQL. Para la interacción de los bloques de programación en PL/SQL, no es necesaria ninguna interfaz, como ODBC, con lo que se gana en simpleza y en performance. La sentencia SELECT agrega una cláusula INTO para que pueda defnirse a qué variable asignar cada columna de la lista del SELECT, como se verá en el siguiente ejemplo de código. Cabe mencionar que se ha usado un RECORD a imagen y semejanza de la tabla “Estudiantes”, para almacenar una fla que tenga como legajo el número 7547. Este conjunto de valores se puede referenciar completamente o por sus partes, con la notación “record.columna”, de la misma manera que en el INSERT Se asigna un legajo cualquiera a la variable del registro, pero cambiándole el contenido original por el valor 7544 y, luego, se lo usará para elegir qué fla se borrará en la última sentencia DELETE. DECLARE r_estudiante

estudiantes%ROWTYPE;

v_apellido

VARCHAR2(30)

:= ‘Perez’;

v_nombre

VARCHAR2(30)

:= ‘Juan’;

BEGIN SELECT * INTO r_estudiante FROM estudiantes WHERE legajo = 7547; UPDATE estudiantes SET nombre = nombre||’, ‘||v_nombre WHERE legajo = r_estudiante.legajo; INSERT INTO estudiantes (legajo, apellido, nombre, tipo_documento, documento, id_sexo, calle, calle_nro, id_barrio) VALUES (r_estudiante.legajo, r_estudiante.apellido, r_estudiante.nombre, r_estudiante.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.10 El tratamiento de transacciones en PL/SQL

139

tipo_documento, r_estudiante.documento, r_estudiante.id_sexo, r_estudiante.calle, r_estudiante.calle_nro, r_estudiante.id_barrio); r_estudiante.legajo := 7544; DELETE FROM estudiantes WHERE legajo = r_estudiante.legajo; END;

4.10 El tratamiento de transacciones en PL/SQL Las mismas opciones del proceso de transacciones de SQL están disponibles en PL/SQL. El inicio de la transacción lo marca la primera sentencia de modifcación de datos y deben ser explícitamente defnidos los puntos de confrmación COMMIT o de corrección ROLLBACK y los eventuales puntos de salvaguarda SAVEPOINT, para defnir apropiadamente la transacción.

En un programa, la primera sentencia SQL inicia la transacción y, cuando ésta fnaliza, la próxima comienza otra automáticamente.

En un programa, la primera sentencia SQL inicia la transacción y, cuando ésta fnaliza, la próxima comienza otra automáticamente. Por esta razón, cada sentencia SQL es parte de una transacción. El uso de COMMIT y ROLLBACK asegura que los cambios hechos con sentencias SQL se confrmen o se deshagan en conjuntos consistentes simultáneamente. Con SAVEPOINT se pone el nombre y se marcan las posiciones de las distintas sentencias de una transacción, para poder deshacer sus partes en el caso en que fuera necesario por alguna regla de negocio. Pero, ¿qué sucede cuando se realizan transacciones desde distintas sesiones de usuarios en forma concurrente? En esta situación, el motor de base de datos debe garantizar que no haya interferencias o anomalías con los cambios que se están llevando a cabo y, además, que las sesiones que están haciendo lecturas de las tablas modifcadas no puedan leer datos que todavía no han sido confrmados. Esta anomalía se denomina lecturas sucias. Para tener una primera idea de los niveles de aislamiento, es preciso indicar que se aplica el principio de que los lectores no bloquean a los escritores, y viceversa. Para esto, el estándar SQL defne niveles de aislamiento que previenen ésta y otras anomalías, como la modifcación de datos leídos y la grabación destructiva de cambios que no estén correctamente aislados. Para una mejor compresión, podríamos describir estas situaciones de la siguiente manera: dadas dos transacciones T1 y T2 tendrían un conficto de escritura-lectura, si la segunda leyera un cambio sin confrmación de la primera (denominada, en el párrafo anterior, lectura sucia o, también, lectura desfasada). Si T2 modifca el valor de una fla mientras T1 ha leído el valor anterior a este cambio, se produce una anomalía de lecto-escritura conocida como lectura no repetible. Por último, se produce un conficto de escritura-escritura si T2 modifca un valor que ha sido alterado por T1 en una transacción que no ha fnalizado aún. Por esta razón, a esta anomalía se la denomina actualización perdida, ya que no se llega a confrmar el cambio de T1.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 40

4 - Lenguaje procedimental como extensión de SQL

El estado por defecto de todas las transacciones en Oracle garantiza la consistencia de lectura en el nivel de Sentencia, que es el que asegura que en una consulta verá solamente los cambios c o n f r m a d o s por otras sesiones antes de que la sentencia SELECT inicie su procesamiento, más los cambios que se hubieran realizado antes en la misma transacción. Se podrá usar la sentencia SET TRANSACTION para establecer una transacción solo lectura (read-only transaction), que provee consistencia de lectura en el nivel de sentencia, de tal m o d o que se garantiza que una consulta leerá solamente los

cambios confrmados antes que la sentencia SELECT, dentro de la transacción actual, haya iniciado. Esta sentencia no tiene argumentos y debe ser la primera sentencia SQL en la transacción de solo lectura, como se expresa en el ejemplo siguiente: SET TRANSACTION READ ONLY; Además de esta sentencia, es posible determinar cerramientos o bloqueos de las tablas que se tratarán en una transacción, asignando diferentes niveles de aislamiento con la sentencia LOCK TABLE y la indicación de los modos disponibles según el siguiente ejemplo: LOCK TABLE mitabla IN MODE [NOWAIT]; Los distintos modos se detallan a continuación: •

EXCLUSIVE permite consultas en la tabla, pero prohíbe cualquier otra actividad sobre ella.

•

SHARE permite acceso concurrente a la tabla afectada, pero prohíbe cualquier actualización sobre ella.

•

ROW SHARE permite acceso concurrente a la tabla afectada, pero impide que otro usuario establezca un LOCK EXCLUSIVE sobre ella.

•

ROW EXCLUSIVE es un bloqueo similar al anterior pero, además, impide que otra sesión fje un modo SHARE sobre el objeto. Es el modo que se fja automáticamente cuando se realiza un UPDATE, INSERT o DELETE sobre una tabla.

•

SHARE ROW EXCLUSIVE bloquea toda la tabla y permite leer las flas, pero impide las actualizaciones y que otra sesión establezca bloqueos del tipo SHARE.

•

SHARE UPDATE —sinónimo de ROW SHARE— ha sido incluido para mantener la compatibilidad con versiones anteriores del motor Oracle.

Es posible que algunos de estos modos de bloqueos se establezcan en la misma tabla simultáneamente, como los SHARE y otros. Al igual que los EXCLUSIVOS, se pueden aplicar solamente una vez en una tabla. Finalmente, el parámetro NOWAIT indica que el motor debe retornar el control de la sesión que intenta hacer alguna operación o establecer un LOCK sobre una tabla que ya posee un bloqueo de otra sesión. Si no se incluye este parámetro, la sesión esperará hasta que se hayan liberado los bloqueos de la otra sesión.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.11 Sentencias de control de fujo

4.11 Sentencias de control de f u j o Su característica procedimental obliga a PL/SQL a tener sentencias de control de fujo, que ya hemos mencionado anteriormente, y dos categorías de sentencias, como las expresiones condicionales y el loop. A continuación, se verán algunos detalles de estas sentencias para controlar la ejecución de un bloque PL/SQL. Una condición en un programa equivale a la idea de tomar una decisión y, detrás de esta condición, subyace el concepto de valores booleanos de verdadero o falso. Estos valores son el resultado de la ejecución de un tipo de sentencias, denominadas operaciones de comparación. Algunas comparaciones pueden ser como las siguientes: •

3+5=8

•

Mi mano tiene 16 dedos.

•

4 = 10

•

Hoy es jueves.

Estas operaciones de comparación se pueden evaluar por su validez, ya que su valor puede resultar verdadero o falso. En el primer caso, es cierto que 3+5 es igual a 8, por lo que esta comparación devolverá el valor TRUE. La segunda no es cierta, ya que mi mano tiene 5 dedos y devolvería un valor FALSE. La tercera también devolverá un valor FALSE porque 4 no es igual a 10. Por último, la afrmación “Hoy es jueves”, si se realiza una vez por día durante toda una semana, devolverá seis veces FALSE y una sola TRUE.

141

s Una condición en un programa equivale a tomar una decisión y además, subyace el concepto de valores booleanos de verdadero o falso.

El mecanismo de proceso de sentencias condicionales permite estructurar cuales se ejecutarán o no, de acuerdo con los resultados de la evaluación de las condiciones.

El mecanismo de proceso de sentencias condicionales permite estructurar sentencias que se ejecutarán, o no, de acuerdo con los resultados de la evaluación de las condiciones. La sintaxis para las sentencias condicionales es “IF (SI) la comparación es verdadera THEN (ENTONCES) haga lo siguiente”. En PL/SQL, se ofrecen dos agregados: •

ELSE (SI NO), que permite decir “SI NO es verdadero, haga lo que sigue a esta cláusula ELSE”.

•

ELSIF, que permite evaluar por distintas condiciones defnidas con cada una de sus líneas, que se analizan ordenadas y, si ninguna de ellas es verdadera, sale por el ELSE.

Se agrega una cláusula al IF-THEN: el ELSIF, que permite evaluar por distintas condiciones defnidas con cada una de sus líneas, que se analizan ordenadas y, si ninguna de ellas es verdadera, sale por el ELSE. Es importante aclarar, en este punto, que las comparaciones se harán entre datos del mismo tipo, y que la comparación con el valor null se realizará con la expresión IS null o por la negativa IS NOT null. Se analizarán los ejemplos de sintaxis de las comparaciones: DECLARE lado_a

number(2) := 20;

lado_b

number(2) := 30;

lado_c

number(2) := 40;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 42

4 - Lenguaje procedimental como extensión de SQL

resultado

number(2) := 0;

BEGIN carga_de_datos(parametro_externo, lado_a,lado_b,lado_c);

IF lado_a > lado_b THEN Calcular _ perimetro (lado_a, lado_b,lado_c, resultado); ELSIF lado_b > lado_c THEN Calcular _ perimetro2 (lado_a, lado_b,lado_c, resultado); ELSE Resultado=350; END IF; END; El ejemplo crea las variables y las inicializa. Cuando inicia el bloque, hay un procedimiento que recibe una variable ya defnida en el entorno de ejecución de llamada que cambiará el valor de las tres variables locales. La sentencia condicional evaluará las variables lado_a, lado_b, lado_c y, según su valor, calculará el perímetro y lo asignará a la variable resultado, inicializada en 0. En caso de que lado_a sea mayor a lado_b, se calculará el perímetro con el procedimiento y, si lado_a es menor a lado_b, pero lado_b es mayor a lado_c, se calculará con otro procedimiento diferente y, si las dos condiciones anteriores devuelven valores FALSE, el bloque asignará al resultado un valor fjo de 350. 4.11.1 Usando loops Otra situación que surge en programación es cuando es necesario ejecutar un conjunto de sentencias repetidamente. Estas repeticiones se pueden controlar de dos maneras: la primera, es repetir el código una determinada cantidad de veces y, la segunda, es repetir el código según se cumpla o no una condición, en función de la sentencia de bucle que se aplique y cómo se escriba la condición lógica. Hay tres tipos de repetidores o bucles, también denominados loops por la sentencia asociada, por ejemplo:

La sentencia LOOP-EXIT está diseñada para determinar si la condición dentro del loop tiene el valor para terminar y procesar la sentencia EXIT, que se debe escribir dentro del grupo de sentencias del loop.

Alfaomega

•

LOOP-EXIT o bucle simple: repite las sentencias hasta que procesa la sentencia de salida EXIT.

•

WHILE-LOOP: entra y se repite según se cumpla la condición que se incluye en su inicio.

•

FOR-LOOP: repite la cantidad de veces indicada en el bucle.

Se analizarán, a continuación, ejemplos de estas sentencias: La sentencia LOOP-EXIT está diseñada para determinar si la condición dentro del loop tiene el valor para terminar y procesar la sentencia EXIT, que se debe escribir dentro del grupo de sentencias del loop. Se escribirá esta sentencia para evitar que el ciclo se repita indefnidamente, y se asegurará que la condición que permitirá ejecutarlo también se cumpla cuando es deseado que el loop termine. En el ejemplo que sigue, si lado_b nunca alcanza el valor 25, no se detendrá el loop, habrá que cancelar desde afuera la ejecución del bloque.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.11 Sentencias de control de fujo

143

DECLARE lado_a

number(2) := 20;

lado_b

number(2) := 30;

lado_c

number(2) := 40;

resultado

number(2) := 0;

BEGIN LOOP Preguntar_datos(parametro_externo, lado_a,lado_b,lado_c); Calcular _ perimetro (lado_a, lado_b,lado_c, resultado); IF lado_b =25 THEN EXIT; END IF; END LOOP; END; Existe una variante en la sentencia EXIT que es la cláusula WHEN a continuación del EXIT en el que se evalúa la condición y se evita que se construya el IF-THEN, para decidir cuándo se ejecuta la salida. Un ejemplo: DECLARE lado_a

number(2) := 20;

lado_b

number(2) := 30;

lado_c

number(2) := 40;

resultado

number(2) := 0;

BEGIN LOOP Preguntar_datos(parametro_externo, lado_a,lado_b,lado_c); Calcular _ perimetro (lado_a, lado_b,lado_c, resultado); EXIT WHEN lado_b =25; END LOOP; END; La sentencia WHILE-LOOP difere del loop básico en que evalúa, primero, la condición para salir del bucle cuando devuelve FALSE. Tiene como ventaja que lo procesa siempre y que la evaluación no se puede eludir. Nótese que se debe invertir el sentido de la comparación, porque se desea que, cuando sea distinto a 25, se ejecute el conjunto de sentencias necesarias. Por ejemplo:

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

144

4 - Lenguaje procedimental como extensión de SQL

DECLARE lado_a

number(2) := 20;

lado_b number(2) := 30; lado_c number(2) := 40; resultado number(2) := 0; BEGIN WHILE lado_b 25; LOOP Preguntar_datos(parametro_externo, lado_a,lado_b,lado_c); Calcular _ perimetro (lado_a, lado_b,lado_c, resultado); END LOOP; END; La sentencia FOR-LOOP difere del loop básico en que defne, exactamente, la cantidad de veces que el código se ejecuta antes que se salga del mismo, ya que crea un contador y un rango entre el cual se valorizará el mismo. Puede defnirse que este contador incremente su valor o que lo vaya disminuyendo hasta encontrar el valor inferior del rango. Vemos el ejemplo: DECLARE lado_a

number(2) := 20;

lado_b

number(2) := 30;

lado_c

number(2) := 40;

resultado

number(2) := 0;

conta

number(2) := 0;

BEGIN FOR conta IN 1 . . 25 LOOP Preguntar_datos(parametro_externo, lado_a,lado_b,lado_c); Calcular _ perimetro (lado_a, lado_b,lado_c, resultado); END LOOP; END; En esta sentencia, la variable conta inicializada en 0, cuando se procesa el FOR-LOOP, se lo valora en 1 y, por cada vuelta del LOOP, se lo incrementa de 1 en 1 hasta llegar al valor 25; en la próxima vuelta, cuando se lo valora en 26, se interrumpe la ejecución y continúa a partir de la sentencia END LOOP.

4.12 Manejo de cursores Ya se defnió qué es un cursor; ahora se verá que existen dos tipos, defnidos explícita o implícitamente, que pueden tener parámetros y cómo se combinan Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.12 Manejo de cursores

145

cursores y sentencias de control de loops y la sentencia que integra ambos elementos llamados LOOP FOR de cursores. Se recordará que los cursores son una dirección de memoria en la que se almacenan los resultados de una sentencia SQL. Se utilizan, frecuentemente, en PL/SQL para que procese el conjunto de flas que devuelve un SELECT. Los cursores explícitos tienen un nombre defnido por el desarrollador y agregan un control mayor sobre la ejecución de la sentencia. Se verá, a continuación, una declaración de un cursor explícito: DECLARE CURSOR cursor_estudiante

IS

SELECT * FROM estudiantes; BEGIN END; Cada vez que se ejecuta una sentencia SQL, se crea un cursor implícito. El desarrollador puede necesitar controlar la operación de una sentencia, aprovechando la defnición que tiene PL/SQL asociada con estas direcciones de memoria. Estos atributos son: %notfound, que se valúa en TRUE cuando la sentencia SELECT no trae flas; el caso inverso, valúa en TRUE a %found y, cuando trae flas, la cantidad se asigna al atributo %rowcount; por último, defne en TRUE al %isopen. A continuación, se verá un ejemplo de un atributo de un cursor implícito que corresponde al procesamiento del UPDATE: aquí, el desarrollador puede preguntar si el resultado de la búsqueda de las flas que se actualizarán —con el atributo %notfound (en este caso, como es implícito, se le antepone el prefjo SQL)— fue positivo o negativo. Si no hubiera flas con el legajo 7547 se insertará, con ese legajo, el apellido Pérez y el documento 16883022.

DECLARE mi_estudiante mi_apellido mi_documento BEGIN

estudiantes.legajo%TYPE := 7547; estudiantes.apellido%TYPE := ‘Perez’; estudiantes.documento%TYPE := 16883022;

UPDATE estudiante SET documento = mi_documento WHERE legajo = mi_estudiante; IF SQL%NOTFOUND THEN INSERT INTO estudiantes (legajo, apellido, documento) VALUES (mi_estudiante, mi_apellido, mi_documento); END IF; END;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

1 46

4 - Lenguaje procedimental como extensión de SQL

Para operar adecuadamente un cursor se necesitan tres pasos: abrir, obtener un valor y cerrarlo. Se usará una tabla denominada “Empleados” que cuenta con el número de empleado, el apellido y el sueldo.

DECLARE mayor_porc_aumento

constant number (10,5) : = 1 . 2 ;

medio_porc_aumento

constant number (10,5) := 1.1;

menor_porc_aumento

constant number (10,5) :=1.05;

TYPE t_emp IS RECORD ( t_sueldo empleado.sueldo%TYPE, t_nro_emp r_empleado

empleado.nroempleado%TYPE); t_emp;

CURSOR c_empleado IS SELECT nroempleado, sueldo FROM empleados; BEGIN OPEN c_empleado; LOOP FETCH c_empleado INTO r_empleado; EXIT WHEN c_empleado%NOTFOUND; IF r_empleado. t_nro_emp = 688 OR r_empleado. t_nro_emp = 700 THEN UPDATE empleados SET sueldo = r_empleado.t_sueldo*mayor_porc_aumento WHERE nroempleado = r_empleado.t_nro_emp; ELSIF r_empleado.t_nro_emp = 777 OR r_empleado.t_nro_emp = 788 THEN UPDATE empleados SET sueldo = r_empleado.t_sueldo*medio_porc_aumento WHERE nroempleado = r_empleado. t_nro_emp; ELSE UPDATE empleados SET sueldo = r_empleado.t_sueldo*menor_porc_aumento WHERE nroempleado = r_empleado. t_nro_emp; END IF; END LOOP; CLOSE c_empleado; END;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.12 Manejo de cursores

147

En el ejemplo se ha realizado un acceso a la base buscando todos los empleados. Con las flas en memoria, en la dirección del cursor, el proceso abre el cursor, que consiste en ejecutar el SELECT asociado y se ubica en su primer registro. Con FETCH toma los valores de éste y se los asigna al RECORD r_empleado. A medida que se vaya repitiendo la ejecución de este FETCH, se moverá al siguiente registro del cursor, correspondiente a la siguiente fla recogida por el SELECT, y los datos se cambian en r_empleados. El loop tiene la condición de fnalización o salida, que será cuando no encuentre flas usando el atributo del cursor defnido (c_empleados%NOTFOUND), que será porque el SELECT no trajo ninguna fla o ya se ha procesado la última. Es importante destacar que el uso de una defnición de tipo de dato diseñado por el usuario, en la línea en la que TYPE indica que se deben precisar un tipo de dato compuesto, un vector con dos campos —t_nro_emp y t_sueldo—, con la misma defnición de las columnas relacionadas en la tabla “Empleados”. En el momento de abrir un cursor, se pueden defnir parámetros para que, al ejecutar el SELECT asociado, se determinen las condiciones por las que, este SELECT, fltrará las flas haciendo más chico el conjunto de flas para, de esta manera, mejorar la performance del proceso. El lenguaje PL/SQL combina dos construcciones en el denominado LOOP FOR para cursores que abrevia todos los pasos: de apertura, de recorrido y de cierre. A continuación, se verá un bloque que hace lo mismo pero, al usar el LOOP FOR para cursores, con menos líneas de código. DECLARE mayor_porc_aumento

constant number (10,5) :=1.2;

medio_porc_aumento

constant number (10,5) := 1.1;

menor_porc_aumento

constant number (10,5) :=1.05;

TYPE t_emp IS RECORD ( t_sueldo empleado.sueldo%TYPE, t_nro_emp r_empleado

empleado.nroempleado%TYPE); t_emp;

CURSOR c_empleado IS SELECT nroempleado, sueldo FROM empleados; BEGIN FOR r_empleado IN c_empleado LOOP IF r_empleado. t_nro_emp = 688 OR r_empleado. t_nro_emp = 700 THEN UPDATE empleados SET sueldo = r_empleado.t_sueldo*mayor_porc_aumento WHERE nroempleado = r_empleado.t_nro_emp; ELSIF r_empleado.t_nro_emp = 777 OR r_empleado.t_nro_emp = 788 THEN

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 48

4 - Lenguaje procedimental como extensión de SQL

UPDATE empleados SET sueldo = r_empleado.t_sueldo*medio_porc_aumento WHERE nroempleado = r_empleado. t_nro_emp; ELSE UPDATE empleados SET sueldo = r_empleado.t_sueldo*menor_porc_aumento WHERE nroempleado = r_empleado. t_nro_emp; END IF; END LOOP; END;

No es necesario escribir la apertura, asignar los valores al registro, la condición de cierre y el cierre propiamente dicho del cursor, ya que todo se procesa internamente por la sentencia FOR LOOP asociada con un cursor.

4.13 Manejo de errores

Los tres tipos de excepciones son: las predefnidas, las defnidas por el usuario y las internas.

En esta sección, se verán los tres tipos básicos de errores, las excepciones comunes y cómo codifcar la sección de excepción. Esta posibilidad de manejo de errores es una de las mejores contribuciones a la robustez de las aplicaciones construidas en Oracle. Los errores necesitan ser tratados explícitamente, sin necesidad de usar IF para detectar la situación anómala. En PL/SQL, se usan los manejadores de excepciones que identifcan el problema y le asignan una porción de código para resolver la situación o, al menos, para dejar registro de lo sucedido y para poder deshacer la transacción en curso. Los tres tipos de excepciones son: las predefnidas, las defnidas por el usuario y las internas. El manejo de excepciones ofrece ventajas en simplicidad y en fexibilidad. Las excepciones predefnidas brindan al desarrollador la posibilidad de revisar los problemas predefnidos; las excepciones defnidas por el usuario permiten determinar situaciones que se tratarán como excepción y tratarlas de la misma manera. Las excepciones internas se desarrollarán en los siguientes ejemplos. Las excepciones predefnidas se usan en conjunto con las situaciones predefnidas que pueden ocurrir en la base; por ejemplo, cuando una sentencia SELECT no devuelve flas —NO_DATA_FOUND—, se ejecuta automáticamente y no es necesario que se ejecute la sentencia RAISE. Cuando este tipo de excepción ocurre, si fuera imprescindible realizar algún cambio, se escribirá el código necesario en la sección de excepciones, en el manejador defnido para esta excepción. Las excepciones defnidas por el usuario se pueden usar para aplicar situaciones previstas en las reglas de negocios, para que se traten de la misma manera que las otras excepciones. Éstas últimas no se consideran errores y se podrían escribir bloques que traten estas situaciones de manera consistente en toda la aplicación. Para utilizar estas defniciones, se cumplirán los siguientes pasos: la declaración de la excepción con un nombre con el que se la invocará durante el proceso cuando

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.13 Manejo de errores

149

esta situación se presente. Luego, se necesitará una prueba de aparición de la excepción, con un código específco que preguntará si las condiciones indican la aparición de esta situación y, además, ejecutará el comando RAISE para que la ejecución se dirija a la próxima etapa. El manejo de la excepción, en la sección EXCEPTION, con la cláusula WHEN y el nombre de la excepción con el que se creó y el bloque de código o la llamada a un procedimiento construido para que siempre se resuelva de la misma manera. A continuación, un bloque con los dos tipos de excepciones: DECLARE mi_estudiante

estudiantes.legajo%TYPE := 7547;

r_estudiante

estudiantes%ROWTYPE;

documento_null

EXCEPTION; /*declara la Excepción del usuario

*/ BEGIN SELECT * INTO r_estudiante FROM estudiantes WHERE legajo = mi_estudiante; IF r_estudiante.documento IS NULL THEN RAISE documento_null; /*Levanta la Excepción declarada*/ END IF; EXCEPTION WHEN NO_DATA_FOUND THEN /*Excepción predefnida*/ DBMS_OUTPUT.PUT_LINE(‘No hay flas’); WHEN documento_null THEN /*Excepción defnida por el usuario */ DBMS_OUTPUT.PUT_LINE(‘La columna Sueldo es nula para el estudiante: ’||r.estudiante.documento); END; Cabe aclarar que se ha usado un procedimiento provisto por la base denominado PUT_LINE, que se almacena en el paquete de la base DBMS_OUTPUT, que muestra este mensaje en la consola de usuario o en el área de mensajes de los programas que llamarían a este bloque de datos. Las excepciones internas asocian un nombre de excepción con un error de la base de datos. El usuario o desarrollador puede extender la lista de excepciones asociadas con errores de la base de datos con el uso de la palabra reservada pragma, seguido por exception_init, que es una directiva al compilador que permite asociar un numero de error, entre el -20 000 y -21 000, que es el rango asignado internamente en la base de datos a los errores del usuario. En el siguiente uso, se observa cómo se utiliza esta sentencia, basado en el código anterior. Cabe destacar que, cuando se recurre a exception_init, se logra que el motor devuelva el código asignado a la excepción al entorno anftrión de este bloque de programación. Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 50

4 - Lenguaje procedimental c o m o extensión de SQL

DECLARE mi_estudiante

estudiantes.legajo%TYPE := 7547;

r_estudiante

estudiantes%ROWTYPE;

documento_null

EXCEPTION; /*declara la Excepción del usuario

*/ PRAGMA EXCEPTION_INIT(documento_null, -20001) /*asigna el numero de error a la Excepción del usuario */

4.13.1 Excepciones comunes Existen numerosas excepciones que se pueden usar y que permiten manejar los errores o las situaciones inesperadas en los programas; algunas de las defnidas son: too_many_rows: cuando un SELECT, ubicado donde se espera solo una fla, devuelve más de una. no_data_found: cuando un SELECT, un UPDATE o DELETE no encuentran flas en la búsqueda. invalid cursor: ocurre cuando se quiere cerrar un cursor que no ha sido abierto. cursor_already_open: ocurre cuando se intenta abrir un cursor que ya está abierto. dup_val_on_index: ocurre cuando se quiere insertar una fla con valor de clave primaria ya existente. zero_divide: ocurre cuando se intenta dividir un número por cero. Las dos primeras son las excepciones más utilizadas; en el ejemplo anterior, se vio el empleo de este tipo de excepciones. Es importante recalcar que no hay que defnirlas ni “levantarlas” con RAISE.

4.13.2 Codifcando en la sección de excepciones Las excepciones aparecen y se deben tratar con código ejecutable que permita registrar y, si es posible, resolver la situación planteada. En la sección de excepciones, se codifcará y se separará en párrafos que se ejecutarán cuando una excepción se detecte. Estos párrafos comienzan con la palabra WHEN y, a continuación, se coloca el nombre de la excepción. Cabe destacar que se pueden tratar excepciones que no tengan un párrafo WHEN asociado, esto se logra si se usa el nombre genérico de excepción, OTHERS. Por lo tanto, esta sería una sección de excepciones muy común: EXCEPTION WHEN NO_DATA_FOUND THEN /*Excepción predefnida*/ DBMS_OUTPUTPUT_LINE(‘No hay flas’); WHEN OTHERS THEN/*Código ejecutable ante cualquier otro tipo de Excepción */ DBMS_OUTPUTPUT_LINE(‘Se ha presentado una excepcion’); END; Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.14 Construyendo procedimientos y funciones con PL/SQL

151

Cabe destacar que una vez ejecutada la sección dedicada a una excepción, el control del programa sale del bloque que lo contiene, esto quiere decir que, si se ingresa a una excepción, no se puede procesar el resto de las excepciones.

4.14 Construyendo procedimientos y funciones con PL/SQL Se han visto hasta aquí, los elementos del lenguaje y las estructuras de programas o bloques de programación, que se denominan anónimos porque no tienen un nombre asignado; resta conocer cómo se construyen los procedimientos, las funciones, los paquetes y los triggers. Estas construcciones —denominadas, genéricamente, programas almacenadostienen, como los bloques anónimos, una sección de declaración, codifcación y manejo de errores. Dos diferencias signifcativas con los bloques anónimos son: los programas almacenados tienen nombres que los bloques anónimos no poseen, esto permite que se los pueda invocar en cualquier línea de ejecución, simplemente indicando el nombre y los parámetros con que deben ingresarse. La segunda diferencia ha sido nombrada, los bloques anónimos no pueden usar parámetros y los programas almacenados sí lo permiten, lo que les da mayor fexibilidad. A su vez, existen diferencias entre los procedimientos y las funciones que se tratarán a continuación. Un procedimiento puede aceptar ninguno, uno o más valores como parámetros, pero una función siempre debe devolver uno y nada más que un solo valor. Antes de ver algunos ejemplos, unas palabras acerca de los aspectos de seguridad. Para crear los procedimientos y las funciones almacenadas, se requiere que el usuario o desarrollador tenga el permiso de creación, que se asigna como sigue: GRANT CREATE PROCEDURE TO miusuario; Y una vez desarrollado el código, cuando se lo crea, se defne el esquema en el que se agrupa junto con otros objetos del mismo usuario. Para que otros usuarios puedan ejecutarlo, el dueño del procedimiento o función almacenada les debe dar el permiso de ejecución. GRANT EXECUTE ON miprocedimiento TO miusuario; Los bloques anónimos tienen la desventaja de que, una vez ejecutados, la base de datos no registra nada acerca de éstos; en cambio, cuando se usan los procedimientos almacenados, la base guarda la compilación y el código parseado -código verifcado y validado por un analizador sintáctico-, lo que defne una mayor rapidez en el procesamiento.

Los bloques anónimos tienen la desventaja de que, una vez ejecutados, la base de datos no guarda registros en cambio, cuando se usan los procedimientos almacenados, guarda la compilación y el código parseado, para mayor rapidez en el procesamiento.

Un ejemplo de construcción de un procedimiento almacenado: CREATE OR REPLACE PROCEDURE cambios_estudiantes (p_legajo

IN NUMBER,

p_apellido

IN VARCHAR2,

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 52

4 - Lenguaje procedimental como extensión de SQL

p_nombre

IN VARCHAR2) AS

BEGIN UPDATE estudiantes SET nombre = p_nombre, apellido = p_apellido WHERE legajo = p_legajo; EXCEPTION WHEN no_data_found THEN DBMS_OUTPUT.PUT_LINE(‘No existe el empleado con el legajo’|| p_legajo) END;

El uso de parámetros es una de las características principales de estos programas almacenados, ya que permiten una mayor fexibilidad y se declaran junto con el nombre

El uso de parámetros permite una mayor fexibilidad y se declara junto con el nombre del programa o función.

del programa o función. Esto los hace parte del nombre completo, por lo que luego se deben valorizar al ejecutarse desde otro bloque o desde la línea de comandos. A continuación, un ejemplo de cómo se debe ejecutar este procedimiento: BEGIN cambios_estudiantes(7547, Alvarez’, ‘Juan’); END;

El resultado es que al empleado con legajo 7547 se le habrá cambiado el nombre y el apellido por los valores que se ingresaron en la llamada del procedimiento cambio_estudiantes. Cabe destacar que, en este caso, se usan solamente los parámetros de entrada, que podrán modifcarse en otra versión para mostrar un ejemplo de parámetros de salida. A continuación:

CREATE OR REPLACE PROCEDURE cambios_estudiantes2 (p_legajo

IN NUMBER,

p_apellido

IN VARCHAR2,

p_nombre

IN VARCHAR2,

p_resultado

OUT NUMBER) AS

BEGIN UPDATE estudiantes SET nombre = p_nombre, apellido = p_apellido WHERE legajo = p_legajo; p_resultado := 1; EXCEPTION WHEN no_data_found THEN

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.14 Construyendo procedimientos y funciones con PL/SQL

153

p_resultado := 0; DBMS_OUTPUT.PUT_LINE(‘No existe el empleado con el legajo ’|| p_legajo) WHEN others THEN p_resultado := - 1 ; END;

Este nuevo parámetro cambia el modo de ejecutarlo; ahora, el bloque que lo convocó debe recibir el resultado de la ejecución que serán tres valores: el 1 signifca que el proceso ha sido exitoso, el 0 que el proceso fracasó porque no existía el empleado con el legajo ingresado y con -1 también fracasó, pero por otro tipo de problema. Se verá el código que llamará al procedimiento. DECLARE s_resultado NUMBER := 0; BEGIN cambios_estudiantes2(7547, ‘Alvarez’, ‘Juan’, s_resultado); IF s_resultado = 1 THEN DBMS_OUTPU.PUT_LINE(‘actualizado’); ELSIF s_resultado = -1 THEN DBMS_OUTPU.PUT_LINE(‘no existe el estudiante’); ELSE DBMS_OUTPU.PUT_LINE(‘problemas’); END IF; END; Se fnalizará este capítulo mostrando una función almacenada y la forma en que se puede ejecutar. Se preverá el ingreso de las dos primeras letras de las monedas y, luego, se buscará en la tabla “Cotizaciones”, el registro que tiene previsto las combinaciones de monedas y el coefciente que se aplicará en la conversión. Si todo resultara exitoso, se devolverá el valor de conversión del cambio entre monedas. Si se ingresara una combinación no prevista, la función saldrá por una excepción y retornará un valor de 0 de conversión y un mensaje. CREATE OR REPLACE FUNCTION convertir_moneda (cantidad

IN NUMBER(12,3),

moneda_original IN VARCHAR2, moneda_destino IN VARCHAR2) RETURNS NUMBER(12,3) IS conversion

NUMBER(12,3) := 0;

coefciente

NUMBER(6,3);

datos_mal

EXCEPTION;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 54

4 - Lenguaje procedimental como extensión de SQL

BEGIN

/*inicio de sección ejecutable de bloque*/ IF moneda_destino IS NULL OR moneda_original IS NULLTHEN RAISE datos_mal; END IF; SELECT coefciente_conversión INTO coefciente FROM cotizaciones WHERE origen = moneda_original AND destino = moneda_destino; conversion = cantidad * coefciente; RETURN conversion;

EXCEPTION

/*inicio de la sección de manejo de excepciones */

WHEN no_data_found THEN DBMS_OUTPU.PUT_LINE(‘Combinación de monedas no prevista’); RETURN conversion; WHEN datos_mal THEN DBMS_OUTPU.PUT_LINE(‘No ingresa datos de moneda’); RETURN conversion; END;

A continuación, se ilustrará cómo se ejecuta esta función, a la que se le pedirá la conversión de 100 pesos a euros. El resultado sería la cantidad de euros que se comprarían con 100 pesos. DECLARE resultado NUMBER(12,3) := 0; BEGIN resultado := convertir_moneda(100,‘PE’, ‘EU’); END;

Otra forma de usar la función dentro de un SELECT sobre una tabla de Oracle, que tiene una sola fla y que se adopta como comodín para superar la restricción de obligatoriedad de la cláusula FROM y de una tabla en ella es la siguiente: DECLARE resultado NUMBER(12,3) := 0; BEGIN SELECT convertir_moneda(100,‘PE’, ‘EU’) INTO resultado FROM dual; END;

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.14 Construyendo procedimientos y funciones con PL/SQL

155

4.14.1 Creando paquetes con PL/SQL En las bases de datos Oracle, existe una construcción denominada paquete —en inglés, package— que ayuda a los desarrolladores a agrupar todos los bloques PL/SQL que pueden estar relacionados dentro de una aplicación o por las características de su funcionamiento. Además de que este agrupamiento permite tener ordenado todos los programas en uso, otorga ventajas en los tiempos de ejecución porque, cuando es convocado por primera vez algún componente del paquete, todo el paquete se sube a la memoria; incluso, puede mantenerse permanentemente allí, para mejorar la performance de los procesos. En los paquetes se pueden almacenar programas, tipos defnidos por el usuario, excepciones, variables y hasta defnición de cursores y tablas temporarias. Responde a las características del concepto de encapsulamiento de la orientación a objetos y, para convocar a un programa, se usa la notación de esta modalidad; es decir, para llamar una construcción cualquiera que esté dentro de un paquete se utiliza la sintaxis nombre_paquete.miprocedimiento. Los paquetes tienen dos partes: la especifcación y el cuerpo. Esta estructura proviene de lenguajes como ADA y C. Se podría afrmar que la especifcación es una unidad de código PL/SQL que nombra los procedimientos, las funciones, las excepciones, los tipos defnidos por el usuario, las variables y otras construcciones disponibles para uso público en ese paquete. Se podría pensar en esta declaración como un índice de contenido del paquete, sin sus detalles de construcción. El cuerpo del paquete contiene el código de todos los procedimientos y las funciones que se han nombrado en la especifcación. Si la especifcación tiene un nombre de procedimiento o de función y el código de este programa no se incluyera en el cuerpo, la compilación del cuerpo fallará con un error hasta que se escriba el código de este programa presente en la especifcación. Dada esta condición, también se podría decir que puede haber construcciones dentro del cuerpo que no están declaradas en la especifcación, y que a estas construcciones —que se denominan privadas— las utilizan otros programas que existen dentro del cuerpo del paquete. A continuación, veremos un ejemplo de un paquete que agrupe al código visto hasta ahora.

En los paquetes se pueden almacenar programas, tipos defnidos por el usuario, excepciones, variables, defnición de cursores y tablas temporarias.

Los paquetes tienen dos partes: la especifcación y el cuerpo. La especifcación es una unidad de código PL/SQL que nombra los procedimientos, las funciones, las excepciones, los tipos defnidos por el usuario, las variables y otras construcciones disponibles para uso público en ese paquete.

Inicio de la declaración del paquete útiles_varios: CREATE OR REPLACE PACKAGE utiles_varios IS FUNCTION convertir_moneda (cantidad

IN NUMBER(12,3),

moneda_original IN VARCHAR2, moneda_destino IN VARCHAR2) RETURNS NUMBER(12,3); /*- - ------------- -- s e p a r a c i o PROCEDURE cambios_estudiantes2(p_legajo

n d e programas- - - - - - - - - - - - - - - - * /

IN NUMBER, p_apellido

IN

p_nombre

IN p_resultado

VARCHAR2, VARCHAR2, OUT NUMBER); END PACKAGE utiles_varios;

/ Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

4 - Lenguaje procedimental como extensión de SQL

1 56

Inicio del cuerpo del paquete:

CREATE OR REPLACE PACKAGE BODY utiles_moneda IS CREATE OR REPLACE FUNCTION convertir_moneda (cantidad

IN NUMBER(12,3),

moneda_original IN VARCHAR2, moneda_destino IN VARCHAR2) RETURNS NUMBER(12,3) IS conversion

NUMBER(12,3) := 0;

coefciente

NUMBER(6,3);

datos_mal

EXCEPTION;

BEGIN

/*inicio de la sección ejecutable de un bloque*/ IF moneda_destino IS NULLOR moneda_original IS NULLTHEN RAISE datos_mal; END IF; SELECT coefciente_conversión INTO coefciente FROM cotizaciones WHERE origen = moneda_original AND destino = moneda_destino; conversion = cantidad * coefciente; RETURN conversion;

EXCEPTION

/*inicio de la sección de manejo de excepciones */

WHEN no_data_found THEN DBMS_OUTPU.PUT_LINE(‘Combinación de monedas no prevista’); RETURN conversion; WHEN datos_mal THEN DBMS_OUTPU.PUT_LINE(‘No ingresa datos de moneda’); RETURN conversion; END FUNCTION convertir_moneda; /*- - -

----------------separacion

de programas- - -

PROCEDURE cambios_estudiantes2(p_legajo

-----------

- -*/

IN NUMBER,

p_resultado

p_apellido

IN VARCHAR2,

p_nombre

IN VARCHAR2,

OUT NUMBER) AS

BEGIN UPDATE estudiantes SET nombre = p_nombre, apellido = p_apellido

Alfaomega

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.14 Construyendo procedimientos y funciones con PL/SQL

157

WHERE legajo = p_legajo; p_resultado := 1; EXCEPTION WHEN no_data_found THEN p_resultado := 0; DBMS_OUTPUT.PUT_LINE(‘No existe el empleado con el legajo ’|| p_legajo) WHEN others THEN p_resultado := - 1 ; END PROCEDURE cambios_estudiantes2; END PACKAGE útiles_varios; / De esta manera, se describió la construcción de programación de PL/SQL que permite trabajar mejor las unidades de programación individuales, agrupándolas, simplifcando su administración y dándoles mejor performance. El último punto de este capítulo trata sobre las unidades de programación PL/SQL que se asocian a las tablas o a los eventos de sistema y tienen la característica de que no se ejecutan por el motor, sin necesidad de que se las convoque explícitamente por la aplicación o por un usuario determinado. Se ejecutan si el evento para el que se defnen acontece. Su utilización se justifca por la dependencia que existe entre un objeto principal y otro derivado dentro de la aplicación y, cuando en aquél existe un cambio, el secundario, lo debe refejar y se requiere que, implícitamente, se ejecute el código necesario para mantener la integridad de la información. Por ejemplo, esta dependencia marca que la aplicación que se encarga de la gestión de envíos de los productos comercializados no puede procesar un registro hasta que la aplicación de cobranza no marque este pedido como pagado, y esto no será posible hasta que la aplicación de cobranzas no haya enviado la factura al cliente. Cada una de estas aplicaciones puede ir actualizando el valor de la columna “Estado” en una tabla; sin embargo, si es necesario registrar la cantidad de días que llevará a la factura transformarse en un remito, se requerirá un procesamiento especial. Si se decide que habrá una tabla de historia con el pedido, el estatus inicial y el fnal, junto con la fecha de cambio, un trigger o disparador de base de datos será muy útil para procesar este trabajo. 4.14.2 C r e a n d o triggers c o n P L / S Q L Los triggers o disparadores de base de datos se almacenan como objetos compilados en la base de datos y el código fuente de su cuerpo se puede consultar en el diccionario de la base de datos que lo almacena. Un trigger se ejecuta automáticamente cuando cierto tipo de sentencias se ejecutan. Si existe un trigger para la sentencia UPDATE sobre una tabla determinada, cuando se actualice una de sus flas, se ejecutará, sin necesidad de convocarlo por su nombre, en forma implícita.

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Los triggers se almacenan como objetos compilados y el código fuente de su cuerpo se puede consultar en el diccionario de la base de datos que lo almacena.

Alfaomega

1 58

4 - Lenguaje procedimental como extensión de SQL

El tipo básico de trigger de base de datos es el que se encuentra en el nivel de la sentencia. Éste se ejecutará cada vez que una sentencia que lo active sea ejecutada sobre la tabla a la que el trigger está asociado. Como ejemplo, se puede defnir que se quiere monitorear la actividad de borrado de la tabla “Pagos de estudiantes” de

tal forma que, cuando se borren cuotas de un estudiante, se guardará en otra tabla la información de la fecha de borrado y la identifcación del usuario que realizó la operación. A continuación, se verá el código que realiza esta operación: CREATE OR REPLACE TRIGGER bd_pagos_estudiantes BEFORE delete ON pagos_estudiantes BEGIN INSERT INTO auditoría_pagos_estud (usuario, fecha_hora_cambio, motivo) VALUES (user, to_char(sysdate, ‘dd/mm/yy hh:mi:ss’,’borrado de flas de pagos_estudiantes’); END; El nombre del trigger, elegido por el autor, tiene un prefjo ‘BD_’, que indica que es antes del borrado (before delete) porque, al ejecutarse automáticamente, un error en su ejecución genera un mensaje que trae el nombre del trigger que ha fallado. La práctica común de nombres ayuda al mantenimiento de la aplicación. Este trigger se ejecutará cuando se ejecute un DELETE sobre la tabla “Pagos_estudiantes” y guardará en la tabla de “Auditoría de pagos de estudiantes” la acción de borrado, fecha y autor de la acción. El otro tipo de trigger permitirá tener la información de cada fla borrada en la acción anterior; se trata de los triggers a nivel de la fla. Para esto, la sintaxis de la creación permite la defnición del valor de las columnas antes de cada cambio y el valor después del cambio. A continuación, se verá el ejemplo de un trigger después de la actualización: CREATE OR REPLACE TRIGGER bd_pagos_estudiantes AFTER update ON pagos_estudiantes REFERENCING OLD AS old NEW AS new FOR EACH ROW BEGIN INSERT INTO h_pagos_estudiantes (usuario, fecha_hora_cambio, fecha_anterior, importe_anterior, fecha_posterior, importe_posterior) VALUES (user, to_char(sysdate, ‘dd/mm/yy hh:mi:ss’,:OLD.fecha, importe, :NEW.fecha, :NEW.importe);

:OLD.

END;

Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

4.15 R e s u m e n

159

En el código anterior, se observa que la segunda línea especifca el momento de ejecución, que es después de ejecutada la sentencia UPDATE sobre la tabla “pagos_estudiantes”; luego se determina el prefjo con el que se defnirán los valores anteriores y posteriores a la acción de las columnas y su contenido. En este caso diferenciará el anterior del resultante por la operación UPDATE. A continuación, la línea que establecerá que este trigger se ejecutará una vez por cada fla actualizada. En este tipo de triggers, se debe considerar detenidamente la cantidad de proceso que se defne, porque puede ser ejecutado miles de veces en una acción muy extendida por las flas de la tabla original. Se pueden escribir doce triggers diferentes sobre una tabla, un grupo antes, otro después; uno en el nivel de la sentencia para cada acción DML (INSERT, UPDATE y DELETE). Es decir, seis diferentes y, luego, el mismo cálculo para los que se encuentran en el nivel de la fla, hacen los seis restantes. Esta cantidad hace nuevamente llamar la atención que un trigger puede disparar otros triggers, imaginemos, defnida sobre la tabla “h_pagos_estudiantes”, lo que constituiría un efecto llamado cascada de triggers. En sí esto no es un problema, pero debe ser diseñado adecuadamente, ya que podría darse que en esta cascada se afecte a la tabla que inicialmente disparó el evento. Se fnaliza, así, el estudio del lenguaje de extensión procedimental de SQL en las bases de datos Oracle, denominado PL/SQL, luego de mostrar las construcciones básicas, las anónimas y con nombre de procedimientos, las funciones, los paquetes y los triggers. Se anima al lector a que practique la creación de todos los objetos para que se asegure el entendimiento de los temas expuestos.

4.15 Resumen Luego de lo expuesto en este capítulo podemos afrmar que el lenguaje procedimental como extensión de SQL engloba el control de fujo, el manejo de condiciones, las sentencias de señalización de condiciones, los cursores y las variables locales y la forma de asignar valores a variables y parámetros. Por otro lado, este lenguaje formaliza el mantenimiento de las rutinas persistentes escritas en lenguaje de bases de datos, como los procedimientos registrados. Además, su rol principal consiste en fjar la lógica y las reglas del negocio de las aplicaciones y almacenarlas en un único lugar dentro de la base.

4.16 Contenido de la página Web de apoyo

SlUjpf

El material marcado con asterisco (*) solo está disponible para docentes.

4.16.1 Mapa conceptual del capítulo 4.16.2 Autoevaluación 4.16.3 Presentaciones* Bases de datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

Bases de datos multidimensionales y tecnologías OLAP

Contenido

Objetivos

5.1 Introducción

162

5.2 Bases de datos multidimensionales

162

5.3 Tecnologías OLAP

169

5.4 Integración entre bases de datos y herramientas OLAP

173

5.5 Arquitecturas OLAP y OLTP

174

5.6 OLAP: multidimensional contra relacional

175

5.7 Evaluación de servidores y herramientas OLAP

182

5.8 Desarrollo de aplicaciones OLAP

184

5.9 Áreas de aplicación de las tecnologías OLAP

185

5.10 Ventajas y desventajas de OLAP

186

5.11 Resumen

187

5.12 Contenido de la página Web de apoyo

188

•

Introducir en el uso de las bases de datos multidimensionales.

•

Aplicar tecnologías OLAP sobre bases de datos multidimensionales o relacionales.

•

Diferenciar los modelos transaccionales (OLTP) y los modelos relacionles (OLAP).

1 62

5 - Bases de datos multidimensionales y tecnologías OLAP

5.1 Introducción En este capítulo y en los subsiguientes, se hará hincapié en la gestión de los datos, pero a diferencia de los apartados precedentes —en los que se analizaba la información desde su procesamiento transaccional—, aquí se buscarán los parámetros que facilitarán la obtención de pronósticos de los entes que suelen interactuar con una organización. La inteligencia del negocio utiliza los datos internos y externos de una organización para analizar los posibles escenarios y, de esta manera, proyectar futuras situaciones.

Este proceso —denominado inteligencia del negocio (o, en inglés, Business Intelligence)— utiliza los datos internos y externos de una organización para —como se afrmó en el párrafo anterior— analizar los posibles escenarios y, de esta manera, proyectar futuras situaciones. Las organizaciones —para garantizar su subsistencia— necesitan ciertos parámetros de efciencia que les permitan, en primer lugar, la maximización de su inversión y, en segundo lugar, su subsistencia en el tiempo mediante una correcta planifcación de su futuro. Por esta razón, establecen dos modelos que se ejecutan en forma simultánea y que permiten, por un lado, el procesamiento de la operación diaria de la organización (On-line Transaccional Processing u OLTP) y, por otro, el procesamiento analítico de las situaciones pasadas que faciliten la planifcación de su futuro (On-line Analytical Processing u OLAP).

El modelo OLTP se ocupa del trabajo diario de la empresa, analiza las ventas y las compras, los pagos a los proveedores, etc. El modelo OLAP utiliza un sistema unifcado de análisis que resume, integra y, también, distribuye la información por las diferentes áreas de una organización.

El modelo OLTP que, como se dijo, se ocupa del trabajo diario de la empresa, analiza —entre otras cuestiones— las ventas y las compras, los pagos a los proveedores, etc. En cambio, el modelo OLAP que, como se mencionó, considera lo ya acontecido, utiliza un sistema unifcado de análisis que resume e integra o distribuye la información por las diferentes áreas de una organización. En una economía globalizada, las empresas necesitan el establecimiento de ciertos parámetros de calidad que contribuyan con la diferenciación de sus productos en el mercado y les permita, además, su expansión hacia nuevos escenarios. Por esta razón, es fundamental —si se quiere buscar nuevas oportunidades de mercados y nichos específcos— el análisis exhaustivo de la información.

5.2 Bases de datos multidimensionales 5.2.1 Evolución de las bases de datos

El modelo multidimensional utiliza bases de datos más grandes que permiten al mercado decidir el futuro de sus negocios de manera rápida y efciente.

Alfaomega

El Dr. Codd, creador del modelo relacional —Relational Data Base Management Systems (RDBMS) o bases de datos relacionales—, posicionó su descubrimiento como la solución adecuada para el almacenamiento y la manipulación de datos. Sin embargo, se dio cuenta de que los RDBMS, si bien servían para almacenar la información, no satisfacían plenamente las necesidades de los negocios, porque el análisis de los datos requería de movimientos electrónicos y de procedimientos muy complejos. Para solucionar las limitantes de este modelo, Codd diseñó el denominado modelo multidimensional. El modelo multidimensional (MMD) utiliza —a diferencia de los RDBMS, que estaban limitados a dos dimensiones— bases de datos más grandes que permiten al mercado decidir el futuro de sus negocios de manera rápida y efciente.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.2 Bases de datos multidimensionales

En la década del setenta, Ken Iverson creó el APL, A Program Language, que fue la primera herramienta de aplicaciones OLAP. Esta herramienta —implementada por IBM— tenía, gracias a la utilización de datos multidimensionales, aplicaciones empresariales con funcionalidades muy similares a las de los productos OLAP de la actualidad. Sin embargo, por su alto grado de complejidad —aun para programadores expertos— no logró un alto grado de adhesión. En los años noventa, algunas empresas de software investigaron —sobre la base de las reglas establecidas por Codd— la implementación de un método (o arquitectura) que unifcara la tecnología multidimensional con las bases de datos relacionales. De esta manera, se llegó a que las herramientas de apoyo que se utilizaban para la toma de decisiones tuvieran una nueva defnición de requerimientos que debían incluir el uso de datos relacionales y la tecnología multidimensional. En los últimos años, la demanda del mercado se orientó hacia el uso de aplicaciones multidimensionales de mayor potencia que ampliaran las posibilidades a la hora de trabajar con bases de datos multidimensionales. Para suplir las falencias de las bases de datos, nacieron las herramientas OLAP relacionales. Éstas, además de incluir la visión multinivel, en algunos casos, utilizan hojas de cálculo y almacenan los datos en un RDBMS. En la actualidad, ciertas herramientas OLAP permiten, para su procesamiento, que se almacenen en las computadoras personales pequeños cubos generados a partir de grandes bases de datos. Como esto ha resultado de mucha utilidad, las empresas distribuidoras ofrecen la herramienta de consultas relacionales y las herramientas de análisis multidimensionales.

163

En los últimos años, la demanda del mercado se orientó hacia el uso de aplicaciones multidimensionales. Para suplir las falencias de las bases de datos, nacieron las herramientas OLAP relacionales que, además de incluir la visión multinivel, utilizan hojas de cálculo y almacenan los datos en un RDBMS.

Kenneth Iverson (17 de diciembre de 1920-19 de octubre de 2004). Científco informático y matemático, se destacó por el desarrollo del lenguaje de programación de APL.

Las bases de datos multidimensionales (MDB), al ofrecer una visión multidimensional de los datos en un concepto de dimensión, permiten la observación de cada uno de los patrones de interés que se evaluarán como una dimensión determinada. De esta manera, no se necesita del concepto de relaciones para la integración y unifcación de datos y, además, se evitan las flas y columnas. La Fig. 5 . 1 , que se muestra a continuación, describe cómo se distribuyen los patrones de interés sin la utilización de flas o de columnas.

Fig. 5.1 Cubo dimensional.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 64

5 - Bases de datos multidimensionales y tecnologías OLAP

En la fgura precedente, la intersección entre las dimensiones genera un valor almacenado que sirve para la conjunción de los dos parámetros representados por cada una de las dimensiones. Entonces, si una dimensión fuese “Productos” y, otra, “Clientes”, en la intersección se almacenaría la cantidad de cada producto adquirida por cada cliente. La base de datos multidimensional contribuye a que el usuario obtenga una visión analítica de la información. Esto le facilitará su procesamiento ya que no deberá recurrir a preguntas complejas y verá con mayor claridad las relaciones entre las diferentes tablas. Por otra parte, las mayores dudas en la implementación de estas bases de datos surgen en la administración, su almacenamiento y en su velocidad de respuesta, temas que se tratarán en este capítulo. 5.2.2 Concepto En las bases de datos multidimensionales, la información se almacena en forma dimensional y no relacional. Las dimensiones determinan la estructura de la información almacenada y defnen caminos de consolidación.

En las bases de datos multidimensionales, la información se almacena en forma dimensional y no relacional. Las dimensiones determinan la estructura de la información almacenada y defnen adicionalmente caminos de consolidación. La información que se reúne se muestra como variables que, a la vez, se determinan por una o más dimensiones. De esta manera, y a partir de la intersección de esas dimensiones, se almacena el valor. En la Fig. 5.2, se ilustra lo antedicho con la representación de un cubo multidimensional:

Fig. 5.2 Cubo multidimensional.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.2 Bases de datos multidimensionales

165

Como se observa en la fgura precedente, el cubo multidimensional posee tres dimensiones: tiempo, productos y regiones. La información de una variable se puede analizar dentro del cubo que se forma en la intersección de sus dimensiones. La información que se obtiene en estas bases es muy útil para las empresas, dado que pueden determinar su desempeño. La fgura a representa la división del cubo en un plano vertical. En este caso, un gerente de área puede medir el desempeño de la región que le corresponde. La fgura b, por ejemplo, sería muy útil para un gerente de producto puesto que podría analizar en el plano horizontal el desempeño del bien o servicio que ofrece.

La información de una variable se puede analizar dentro del cubo que se forma en la intersección de sus dimensiones. La información que se obtiene en estas bases es muy útil para las empresas, dado que pueden determinar su desempeño.

En la fgura c, se comparan dos años diferentes. Esta visión temporal permite medir, por ejemplo, las ventas de dos períodos consecutivos. En la fgura d, se observa lo ocurrido en un periodo de tiempo, una región y un producto determinado, el comportamiento del mismo.

/

r

y

/

/ Tiempo b) Visión del producto

a) Visión regional

X

/

y f

/

c) Visión temporal

/

/

d) Visión Ad-Hoc

Fig. 5.3 Vistas multidimensionales.

Estas dimensiones se pueden estructurar jerárquicamente para construir caminos de consolidación que analicen la información —desde lo más general hasta lo más específco—mediante un mecanismo denominado drill-down. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

166

5 - Bases de datos multidimensionales y tecnologías OLAP

5.2.3 Estructura de almacenamiento Cuantas más dimensiones posea una base de datos multidimensional, mayor será el número de datos o celdas. Por esta razón, es necesario que se consideren todas las celdas que se generarán al establecer el producto cartesiano de las intersecciones que se formarán entre todas las dimensiones de la base. En el ejemplo anterior, que tenía tres dimensiones, si se le agregara una cuarta, ampliaría notablemente la estructura de almacenamiento, puesto que la cantidad de celdas que se deberían añadir en la estructura sería igual al tamaño de la nueva dimensión por el tamaño de las tres dimensiones que ya existían. Se podría dar el caso en que no todas las sucursales estarían habilitadas para vender la misma cantidad de productos y que las más pequeñas solo ofrecieran el 20%. En este caso, si tuviera las mismas dimensiones que en el ejemplo citado, es decir, regiones, producto y tiempo, quedaría el 80% de las celdas vacías para las dos dimensiones restantes. Esta situación es muy común en la práctica, puesto que la gran parte de la bases de datos tienen el 95% de las celdas vacías; esto signifca que los valores son nulos. En la literatura de la materia, se denominan poblados dispersos (sparsely populated) o dispersión de datos. Este fenómeno de explosión es muy común en las bases de datos multidimensionales. Esta situación puede causar errores en muchas de las aplicaciones; por esta razón, es necesario que los que trabajen con este tipo de aplicaciones o con bases de datos multidimensionales tomen ciertas precauciones que prevean esta posibilidad y su posible solución. Entonces, es necesario que se consideren e identifquen las causas de explosión de las bases de datos: Los datos dispersos: si bien una mala redistribución o eliminación de datos dispersos provoca que se ocupe una mayor proporción del disco duro, la diferencia entre un buen o mal almacenamiento de datos dispersos es uno de los factores que no contribuye en gran medida a la dispersión de datos dimensional. •

Almacenamiento de la base de datos multidimensional: la tecnología utilizada no produce dispersión de datos.

•

Errores en el software: La explosión de los datos no tiene nada que ver con errores en el software o con bases de datos corruptas.

Aunque en muchas bases de datos multidimensionales y en algunos productos OLAP existe la posibilidad de comprimir datos, esta característica no soluciona su explosión y tampoco la dispersión multidimensional. La manera más sencilla de almacenamiento de datos dispersos es la utilización de celdas cuyos datos contengan alguna forma preordenada o de indexación. Sin embargo, esto trae aparejado sus propios inconvenientes puesto que se podría dar el caso en que el índice y las claves ocuparan más espacio que los propios datos. Entonces, lo que se debe considerar es cuál de las dos situaciones acarrea un problema mayor: si la dispersión natural de datos en las dimensionales o las medidas que se toman para evitarla.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.2 Bases de datos multidimensionales

En general, los grandes productos dividen los datos en pequeños grupos, denominados objetos multidimensionales. En algunos casos, ciertos fabricantes de bases de datos multidimensionales presentan los datos al usuario en forma de hipercubo. De esta manera, los datos en la aplicación aparecen como una sencilla estructura multidimensional. En otros, los fabricantes hacen explícitamente una aproximación denominada multicubo, en la que la base de datos multidimensional se estructura en un gran número de objetos separados normalmente con diferentes dimensiones y que unidos constituyen la base de datos en su totalidad.

167

La manera más sencilla de almacenamiento de datos dispersos es la utilización de celdas cuyos datos contengan alguna forma preordenada o de indexación.

A continuación, se analizará el funcionamiento de cada una de estas técnicas de almacenamiento.

5.2.4 Dispersión de datos Para evitar la dispersión de datos y agruparlos, los diseñadores de productos multidimensionales se valen de diferentes estrategias entre las que se destacan las ya mencionadas hipercubos y multicubos. Estas dos opciones no son visuales; esto signifca que el usuario no las percibe porque pertenecen a la capa interna de almacenamiento que utiliza el motor de la base de datos para almacenarlos. Esto condiciona el modo en que se procesarán los datos y los cálculos que se realizarán. 5.2.4.1 Hipercubos Algunos productos del mercado ofrecen un único cubo como estructura de almacenamiento de datos con modelos más sofsticados de compresión de datos dispersos. Este tipo de hipercubos permite que se introduzcan los valores de los datos a través de la combinación de dimensiones. Cabe destacar que todas las partes del espacio de datos (cubo) poseen la misma dimensión. Esta estructura de datos —denominada hipercubo— no limita el número de dimensiones a un determinado valor y tampoco considera que éstas sean del mismo tamaño. El hipercubo se utiliza de forma específca para la identifcación de estructuras con más de tres dimensiones. De todas maneras, no se refere a un formato de almacenamiento de datos y se aplica en bases de datos multidimensionales y también en relacionales. El trabajo con este tipo de estructura se realiza con un único cubo de varias dimensiones. Esta estructura pasa a ser estática que, en principio, produce un nivel de almacenamiento mayor y mejora la posibilidad de que se generen dispersiones de datos con valores nulos. Los que se inclinan por este tipo de estructura resaltan la simplicidad que posee para el usuario fnal y su velocidad de acceso a la información ya que ésta se encuentra almacenada en forma contigua.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

El hipercubo se utiliza de forma específca para la identifcación de estructuras con más de tres dimensiones.

Alfaomega

1 68

5 - Bases de datos multidimensionales y tecnologías OLAP

Arbor, con Essbase, y Cognos, con Powerplay, son dos de las compañías que utilizan esta estructura en sus aplicaciones. Por último, es relevante comentar que hay una variante de esta estructura de hipercubo denominado hipercubo bordeado (fringed hypercube), que es más denso y con un pequeño número de dimensiones a las que se le pueden añadir, además, dimensiones de análisis. 5.2.4.2 Multicubos

La estructura de los multicubos divide el universo en diferentes cubos de menor tamaño e intenta dinamizarla mediante punteros. Así, disminuye el espacio de almacenamiento y la posibilidad de dispersión. Esta situación permite que los cubos no deban replicar el tamaño de una de las dimensiones a las restantes.

Los productos que utilizan esta estructura dividen la aplicación de la base de datos en un conjunto de estructuras multidimensionales. Cada una de ellas se compone de un subconjunto de las dimensiones de la de la base de datos. Si bien los diferentes productos del mercado le otorgan diferentes denominaciones a estas pequeñas estructuras (variables, universos, estructuras, cubos, etc.), todas se referen al mismo tipo de subestructura. Esta estructura divide el universo en diferentes cubos de menor tamaño e intenta dinamizarla mediante estos cubos con punteros. De esta manera, disminuye el espacio utilizado para el almacenamiento, ya que, al reducir el tamaño de los cubos que conforman el universo de datos, también lo hace la posibilidad de dispersión. Esta situación permite que los cubos no deban replicar el tamaño de una de las dimensiones a las restantes. Sin embargo, existe la posibilidad de que los valores nulos no sean muy altos y, entonces, este tipo de estructura necesitaría más espacio de almacenamiento, puesto que los punteros que unen los diferentes cubos también ocupan espacio. Existen dos tipos principales de multicubos: el block o bloque y el series. El primero utiliza dimensiones ortogonales lo que permite que no haya dimensiones especiales en este nivel de datos. De esta manera, un bloque se puede constituir por cualquier número de dimensiones defnidas y medidas, por ejemplo: la dimensión tiempo. Esto signifca que las medidas o variables se tratan como si fueran dimensiones. El segundo tipo trata a cada medida o variable como si fueran series de tiempo, con un conjunto propio de dimensiones. 5.2.4.3 Elección de la estructura adecuada

Existen dos tipos principales de multicubos: el block y el series. El primero utiliza dimensiones ortogonales lo que permite que no haya dimensiones especiales en este nivel de datos. El segundo tipo trata a cada medida o variable como series de tiempo, con un conjunto propio de dimensiones.

Alfaomega

En general, los multicubos, gracias a su gran fexibilidad y versatilidad, son los preferidos por los profesionales con experiencia; en cambio, los hipercubos son los elegidos por los usuarios fnales porque son más fáciles de comprender y ofrecen una visión de alto nivel. Los multicubos almacenan de manera más efciente los datos dispersos y reducen el efecto de la explosión de datos, pero si este no es muy grande, es decir que no supera el 30%, utilizan más espacio de almacenamiento que los hipercubos. Algunos fabricantes han optado por ofrecer un modelo mixto: permiten que el almacenamiento físico de los datos se realice como si se tratara de un multicubo, pero los cálculos se ejecutan como si se estuviera trabajando con un hipercubo. De esta manera, combinan la simplicidad del hipercubo con la fexibilidad del multicubo.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.3 Tecnologías OLAP

5.3 Tecnologías OLAP 5.3.1 Introducción En el desarrollo de software sobre bases de datos conviven dos modelos: en primer lugar, el OLTP (On-line Transaccional Processing) integrado por la mayoría de los sistemas desarrollados que realizan operaciones destinadas al procesamiento de transacciones en línea. Dentro de estos sistemas encontramos los clásicos, que modelan la operatoria de una organización, y también los de ventas, compras, cuentas corrientes, etc. En segundo lugar, el OLAP (On-line Analytical Processing) que analiza la información mediante parámetros de interés específcos y que se consideran relevantes para la organización y permiten que esta información se integre en los diferentes modelos OLTP.

169

s OLAP es un proceso que se utiliza para el análisis de información, para la elaboración de reportes administrativos y consolidaciones, para el análisis de la rentabilidad, para reportes de calidad y para otras aplicaciones que necesitan una visión exhaustiva del negocio.

5.3.2 C o n c e p t o d e O L A P OLAP representa el procesamiento analítico en línea que permite el análisis de la información sobre determinados patrones de interés. Esta tecnología se aplica a áreas funcionales de la empresa como producción, ventas, análisis de rentabilidad de la comercialización, consolidaciones fnancieras, presupuestos, pronósticos, planeación de impuestos y contabilidad de costos. OLAP es un proceso que se utiliza para el análisis de información, para la elaboración de reportes administrativos y consolidaciones, para el análisis de la rentabilidad, para reportes de calidad y para otras aplicaciones que necesitan una visión exhaustiva del negocio. Asimismo, realiza los reportes sumarios que los ejecutivos necesitan para la toma de decisiones, los cálculos complejos, los enfoques de detalles operativos y las consultas no programadas. Además, como se alimenta principalmente de los OLTP, también necesita administrar la base de datos de manera efciente y proveer un nivel adecuado de seguridad. 5.3.3 C a r a c t e r í s t i c a s d e O L A P Las tecnologías que se aplican sobre un modelo OLAP ofrecen una visión multidimensional lógica de los datos; esto signifca que se basa en la dimensión de interés que representa cada uno de ellos, con independencia del modo en que se almacenen. Este modelo siempre abarca la consulta interactiva y el análisis de datos. En general, como la interacción se realiza a través de varias pasadas, profundiza en niveles cada vez más detallados o en el ascenso a otros niveles superiores de resumen y acumulación.

OLAP ofrece algunas opciones para el modelado analítico, que incluyen un motor de cálculo para la obtención de proporciones, desviaciones respecto a la media, etcétera, que abarcan las mediciones de datos numéricos realizadas a través de muchas mediciones.

Otra de las características fundamentales del OLAP es ofrecer algunas opciones para el modelado analítico, que incluyen un motor de cálculo para la obtención de proporciones, desviaciones respecto a la media, etcétera, que abarcan las mediciones de datos numéricos realizadas a través de muchas mediciones. Su objetivo es la creación de resúmenes y adiciones —denominadas también consolidaciones—, de jerarquías y, además, en las dimensiones de interés, cuestionar todos los niveles de adición y resumen en cada una de sus intersecciones.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 70

5 - Bases de datos multidimensionales y tecnologías OLAP

Como manipula modelos funcionales de pronóstico, análisis de tendencias y datos estadísticos, tiene la capacidad de recuperar y exhibir datos tabulares en dos o tres dimensiones, cuadros y gráfcas con un pivoteo fácil de los ejes. Este pivoteo es fundamental para los usuarios, porque necesitan analizar los datos desde diferentes perspectivas. Cada una de ellas conducirá a otra visión de la organización que se evaluará, a la vez, desde otra perspectiva. La rapidez de respuesta del modelo OLAP a las consultas permite que el proceso de análisis no se interrumpa y, por lo tanto, que la información no pierda vigencia. Esto se debe al modelado de datos dimensional que se realiza durante el armado del modelo, en el que se efectúan los cálculos previos para la integración de información que lo simplifcan. Además, cuenta con un motor de depósito de datos multidimensional con capacidad para almacenar los datos en arreglos.

La rapidez de respuesta de este modelo a las consultas permite que el proceso de análisis no se interrumpa y, por lo tanto, que la información no pierda vigencia. Esto se debe al modelado de datos dimensional que se realiza durante el armado del modelo OLAP, en el que se efectúan los cálculos previos para la integración de información que lo simplifcan. Además, cuenta con un motor de depósito de datos multidimensional con capacidad para almacenar los datos en arreglos (representación lógica de las dimensiones organizacionales). La bibliografía especializada sostiene que mientras la defnición actual de OLAP ha justifcado su aceptación, poco se ha recorrido en la defnición de un estándar computacional. Los autores proponen el concepto FASMI (Fast Analysis Shared Multidimensional Information) para defnir un OLAP. Fast (rápido): porque el sistema tiene tiempos de respuesta de cinco segundos. En las consultas sencillas demora un segundo, en las complejas, puede tardar hasta 30. En situaciones cotidianas, si las respuestas tomaran más tiempo, el usuario perdería la concentración en lo que busca analizar. Analysis (análisis): signifca que al usuario se le debe proporcionar la funcionalidad necesaria para la resolución de sus problemas, sin el apoyo de sistemas o de una preprogramación. De esta manera, se podrán realizar consultas no defnidas, cálculos de diferencias, variaciones y tendencias, consolidar y llevar a cabo análisis de sensibilidad y de búsqueda de metas. Shared (compartida): se debe acceder a la lectura y a la escritura de forma simultánea, con un esquema de seguridad adecuado que guarde la confdencialidad (probablemente, en el nivel de celda). Multidimensional (multidimensional): fue y será un requisito, debe manejar varias jerarquías y dimensiones. Information (información): son todos los datos y la información derivada, cuando y donde sea necesaria, en su contexto, tanto información suave como dura, interna o externa. 5.3.4 C o m p a r a c i ó n e n t r e e l m o d e l o O L T P y e l m o d e l o O L A P Para comprender el concepto de OLAP es necesario que se entiendan las diferencias entre estos dos tipos de modelos. En el caso de los diseñadores esto es fundamental a la hora de llevar adelante un proyecto de esta naturaleza. A continuación, se analizarán las diferencias entre ambos modelos de procesamiento, según las características disímiles que los componen.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.3 Tecnologías OLAP

171

Tabla Comparaciones OLTP

Concepto

OLAP

• •

Aplica los conceptos de la normalización de datos.

•

desnormalizado.

•

Orientación de los datos por

•

Los datos son organizados

alineación de

inherentemente por cada

datos

aplicación.

•

Está focalizado en resolver

La orientación de los datos es por patrones de interés o

aplicación. Orientación o

Es un modelo

dimensiones.

•

Los datos son organizados por dimensiones defnidas en el negocio.

•

Está focalizado en responder

requerimientos de

los requerimientos de

aplicaciones específcas.

análisis estratégico de la organización.

•

Deben estar integrados para poder analizar la información

•

No están integrados.

•

Cada área del negocio tiene

en su conjunto. •

interés se integra, sin que

su propio modelo. •

importe si se origina en

Diferentes sistemas poseen

modelos transaccionales o

diferentes datos. •

Diferentes nomenclaturas de datos en los distintos

Integración

modelos. •

en sistemas diferentes. • •

Diferentes formatos de

sistema.

Se realizan convenciones de nomenclatura con el objeto de estandarizar la

Diferentes plataformas de hardware para cada

Todos los datos están en un mismo modelo.

archivos para cada sistema. •

Toda la información de

información. •

Utilización de formatos de archivo estándar.

•

Una sola plataforma de hardware.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 72

5 - Bases de datos multidimensionales y tecnologías OLAP

Concepto

OLTP

•

datos del usuario

•

la información, sin realizar

manipulan los datos en

inserciones, modifcaciones

requeridas en cada sistema.

•

•

ni borrado de los datos.

•

Administradores de base de datos

• • Manejo de transacciones

Las operaciones de consulta

Se ejecutan muchas veces

no son repetitivas, de

las mismas acciones

manera continua se cambia

como ser altas, bajas o

el tipo de consulta a la base

modifcaciones.

de datos.

La manipulación de datos se

•

realiza registro a registro.

•

Los usuarios solo consultan

ingresan, modifcan y función de las necesidades

Acceso y manipulación de

Los usuarios son los que

OLAP

Las transacciones y rutinas

La carga y acceso a los datos es masiva.

•

Las validaciones se realizan

de validación se ejecutan

antes o después de cada

en el nivel de registro o

carga, nunca en el nivel de

transacción.

registro o transacción.

Se manejan cientos de

•

Se realiza una sola

transacciones por día.

transacción de carga

Se verifca la integridad

global del modelo, que

y consistencia por

contiene gran cantidad de

transacción.

transacciones originadas en el modelo OLTP.

•

Si la carga termina bien, se garantiza la consistencia de todo el conjunto de datos.

•

La dimensión tiempo

Que falta un soporte

•

Similar a las capas

explícito para la

geológicas, la base de datos

reconstrucción de la historia

se puede ver como una serie

previa. Esto signifca que si

de capas. Cada una de ellas

los datos se reescriben, es

está compuesta por una foto

imposible que se recupere

del modelo OLTP tomada

su estado anterior; si se

en un intervalo de tiempo

mantiene un historial, al

determinado.

aumentar los cambios, será prácticamente imposible reconstruir hasta un punto

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.4 Integración entre bases de d a t o s y herramientas OLAP

Concepto

OLTP determinado. Los datos

tiempo

•

OLAP

•

Los datos son altamente

operacionales son altamente

estables, ya que se insertan

volátiles, cambian a

en un momento determinado

medida que opera la

y no se modifcan o se

organización y sus sistemas

borran.

computacionales refejan la La dimensión

173

•

No se realizan cambios en la

operación.

base de datos, solo cargas

Puede haber cambios en la

de actualizaciones.

base de datos mientras se los consulta debido al alto grado de transaccionalidad de las bases.

5.4 Integración entre bases de datos y herramientas OLAP Las bases de datos multidimensionales suelen adquirir datos de otras fuentes c o m o bases de datos relacionales, herramientas de escritorio u hojas de cálculo; t a m bién los usuarios fnales pueden introducir algunos d a t o s . En un ROLAP (Relational OLAP), los datos se almacenan físicamente en un R D B M S , mientras que en un M O LAP (Multidimentional OLAP) están en un M D B en el que se almacenan en diferentes estructuras q u e se optimizan por un procesamiento multidimensional. Por último, existen los m o d e l o s H O L A P (Hybrid OLAP), en los q u e se mezclan la arquitectura de bases de d a t o s multidimensionales y de d a t o s relacionales. Si los datos se almacenan en un M D B , en condiciones normales utilizarán m e n o s espacio del q u e ocuparían si se encontraran en el sistema originario del que se recogieron los d a t o s . Esto se d e b e , principalmente, a las claves, las indexaciones y las estructuras dimensionales, q u e o no se necesitan o se optimizan para ocupar m u c h o m e n o s espacio. También la dispersión de datos se elimina de una manera m á s e f c a z y éstos se p u e d e n comprimir y resumir.

En un ROLAP, los datos se almacenan físicamente en un RDBMS, mientras que en un MOLAP están en un MDB en el que se almacenan en diferentes estructuras que se optimizan por un procesamiento multidimensional.

En general, las aplicaciones OLAP se orientan hacia el uso interactivo para que el usuario obtenga una rápida respuesta a sus interrogantes (en tiempos muy cortos). Si la respuesta se reduce a reunir la información de la base de datos c o n un formato adecuado para el usuario, estas expectativas se cumplen; en c a m b i o , en los casos en los que sea necesario la realización de grandes cálculos, la respuesta será m u c h o m á s lenta. En términos de tiempo consumido, el principal costo es la recuperación de los datos que afectan a los elementos que se recuperarán y no los cálculos aritméticos. Para obtener una rápida respuesta, las aplicaciones multidimensionales necesitan precalcular algunos de los datos q u e se utilizarán en el análisis. En este tipo de b a s e s , los datos precalculados se almacenan automáticamente; en c a m b i o , en los ROLAP, es c o m ú n el u s o de tablas de resumen.

Bases de Datos - Reinosa, M a l d o n a d o , M u ñ o z , Damiano, Abrutsky

Alfaomega

1 74

Las aplicaciones multidimensionales necesitan precalcular algunos de los datos que se utilizarán en el análisis. En este tipo de bases, los datos precalculados se almacenan automáticamente; en cambio, en los ROLAP, es común usar tablas de resumen.

5 - Bases de datos multidimensionales y tecnologías OLAP

El hecho de precalcular toda la información necesaria puede llegar a ser un problema en lugar de una ventaja. El problema se encuentra en las relaciones multidimensionales que existen en todas las aplicaciones OLAP y en el hecho de que la mayoría de los datos introducidos son considerados dispersos. Esto provoca que los resultados precalculados basados en datos multidimensionales dispersos sean bastante más voluminosos de lo que sería deseable. De acuerdo con lo desarrollado hasta aquí, se puede afrmar que la consulta se basa en tres tipos de datos: a) de entrada, introducidos por el usuario; b) precalculados y c) los cálculos que se realizan en el momento. Para que no se produzca una explosión de datos se pueden utilizar dos principios: en primer lugar, se debe evitar cualquier objeto multidimensional con más de cinco dimensiones, ya que esto provocará la multiplicación de datos dispersos. En segundo lugar, se puede reducir la dispersión de objetos de datos individuales a través de un buen diseño y gracias a la utilización de una aproximación de multicubos en la que cada objeto posea solo la mínima cantidad de dimensiones necesaria. Para calcular la cantidad exacta de lo que se debe precalcular dependemos de los siguientes factores: el hardware, la topología y el tamaño de la red, las características del software, el número de usuarios, la complejidad de los cálculos, etcétera. Normalmente, los datos que se precalculan son: •

Datos lentos de calcular en tiempo de ejecución.

•

Datos que se pidan con cierta asiduidad.

•

Datos que constituyan la base para el cálculo de otros datos.

5.5 Arquitecturas OLAP y OLTP En las aplicaciones OLTP, los usuarios crean, actualizan o retienen registros individuales.

En las aplicaciones OLTP, los usuarios crean, actualizan o retienen registros individuales. Por esta razón, las bases de datos con este tipo de aplicaciones se optimizan para la actualización de las transacciones. En cambio, en las aplicaciones OLAP —utilizadas por analistas y gerentes que requieren vistas con un alto nivel de datos como, por ejemplo, las ventas de una línea de productos—, la base de datos se actualiza, generalmente, por bloques de múltiples fuentes y provee, además, poderosas aplicaciones multiusuario de gran poder analítico. En consecuencia, las bases de datos OLAP se optimizan para el análisis. Si bien las bases de datos relacionales son excelentes para mantener un número reducido de registros de una manera rápida, no tienen el mismo rendimiento para una gran cantidad de registros que se deben resumir en un solo paso. En este caso, su respuesta es lenta y el uso desordenado de recursos son características comunes en la construcción de aplicaciones de soporte de decisiones creadas por encima de la base de datos relacional.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.6 OLAP: multidimensional contra relacional

175

Muchas veces, se intenta resolver problemas con la tecnología relacional cuando, en realidad, son de naturaleza multidimensional. Por ejemplo, en el caso de las búsquedas con SQL en las que se quiere crear resúmenes de ventas de un producto por región y ventas en una región por producto, es probable que esto involucre la lectura de todos los registros de una base de datos de marketing, que tomaría horas. En cambio, con un servidor OLAP, se pueden manejar en segundos. Las aplicaciones OLAP emplean datos resumidos; las OLTP, manejan datos actuales y atómicos y, en general, no requieren datos históricos. En cambio, casi toda la aplicación OLAP requiere de ellos.

En las aplicaciones OLAP, la base de datos se actualiza, generalmente, por bloques de múltiples fuentes y provee, además, poderosas aplicaciones multiusuario de gran poder analítico.

Mientras que las aplicaciones OLTP y sus bases de datos se organizan alrededor de procesos específcos, las OLAP lo hacen por medio de temas y pueden responder a preguntas como la siguiente: “¿Qué productos se están vendiendo bien?”.

5.6 OLAP: multidimensional contra relacional Son dos las opciones para el almacenamiento de datos: el depósito multidimensional y el relacional. Desde la perspectiva del usuario, los datos que se compararán son: •

¿Cuántos datos organizacionales están almacenados y disponibles?

•

¿Es adecuada la capacidad de almacenamiento?

•

¿Es aceptable el desempeño?

•

¿Se justifca el costo?

•

¿La consulta de los mismos es manejable por los usuarios?

•

¿Qué tipos de vínculos se puede asociar?

Las OLTP manejan datos actuales y atómicos y, en general, no requieren datos históricos. En cambio, casi toda la aplicación OLAP requiere de ellos.

La siguiente tabla resume los aspectos de selección de uno u otro.

Tabla Comparaciones entre la base de datos relacional y la base de datos multidimensional Base de datos relacional

Depósito de datos, acceso y visión

• • • •

Base de datos multidimensional •

Dimensional

•

Arreglos: Hipercubo/

SQL con ampliaciones

•

Tecnología de matriz dispersa

Herramientas API

•

Propietario de hoja de

Relacional Tablas de flas y columnas

Multicubo

cálculo

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 76

5 - Bases de datos multidimensionales y tecnologías OLAP

Utilización e

•

OLTP

•

OLAP

•

Motor RDBMS

•

Motor multidimensional

Profundización a nivel de

•

•

incorporación

detalle •

Desempeño de consultas:

•

rango amplio

Tamaño y

•

Gigabytes a Terabytes

•

El depósito de índices y el retiro de normas

actualización de la base de datos

incrementan el tamaño •

Consulta y carga paralelas

•

Actualización durante el año

Profundización a nivel de resumen/adición Desempeño de consultas: rápido

•

Gigabytes

•

Compresión y adición de datos dispersos

•

Difícil actualización durante el uso; los cambios pequeños podrían requerir reorganización

Alcance de interacción del

Transaccional

Base de datos completa

Registros individuales

Grupos de registros

Estática

Dinámica

usuario Datos afectados por interacción del usuario Utilización de la máquina

Prioridades

Alto desempeño Alta disponibilidad

Alta fexibilidad Alta facilidad de consulta por usuarios

En un análisis basado en la tabla precedente, un modelo RDBMS es la mejor opción para el caso en que los datos sean voluminosos (10 GB en adelante) o se considere el crecimiento constante del volumen de datos. De la misma manera, es conveniente si el número de usuarios esperados supera los cincuenta. También un MDB es una excelente opción si se tienen volúmenes cercanos a los 10 GB, con pocos usuarios concurrentes. En el desarrollo de aplicaciones de funcionalidad superior, que se realizarán en períodos cortos, el MDB —gracias a la integración natural de sus herramientas con la estructura de la representación dimensional de los datos— es una opción viable. El costo del administrador es una de las características no técnicas que se debe evaluar. En el caso de las organizaciones grandes que, en general, cuentan con un RDBMS utilizado normalmente por la organización, la estrategia adecuada para reducir los costos, sería el pago de licencias adicionales para desarrollar su almacenamiento global en el mismo RDBMS. La implementación de este almacenamiento in-

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.6 OLAP: multidimensional contra relacional

177

tegrado se favorece si la organización cuenta con diseñadores y administradores con probada experiencia en la optimización de aplicaciones y en la afnación de bases de datos, conocimiento que es muy difícil de alcanzar en el corto plazo con un MDB. 5.6.1 O L A P multidimensional (MOLAP) El diseño lógico o el modelo de información son los que conducen el diseño inicial y la actividad de confguración. A continuación, se describen los pasos básicos para su implementación: •

Seleccionar la función de la organización, como análisis de ingresos por ventas y reportes fnancieros.

•

Identifcar los valores numéricos; es decir, las mediciones que se almacenarán, tales como ingresos por ventas y clientes.

•

Determinar las dimensiones (tiempo, geografía y producto). Por ejemplo, la dimensión tiempo, por mes y por trimestre; la geográfca, por estado o región.

•

Defnir el modelo lógico y cargar el depósito de datos multidimensionales, ya sea directamente de la fuente de datos o fltrando y ajustando el contenido seleccionado.

La implementación de este almacenamiento integrado se favorece si la organización cuenta con diseñadores y administradores con probada experiencia en la optimización de aplicaciones y en la afnación de bases de datos, conocimiento que es muy difícil de alcanzar en el corto plazo con un MDB.

Las funciones principales que se ofrecen a los usuarios de la organización comprenden: •

Rápida respuesta a la consulta de cómputos intensiva, tal como escenarios “¿qué pasa si…?”.

•

Actualización constante e interactiva de la base de datos multidimensional, con el fn de permitir aplicaciones de pronósticos que permitan proyectar situaciones en el futuro y los presupuestos que se realizarán.

•

Explotación de relaciones ricas entre los elementos o valores de las dimensiones para descubrir relaciones insospechadas.

•

Un poderoso motor de cálculo y análisis comparativo: posiciones, comparaciones, porcentaje de clase, máximo, mínimo, promedios, promedios móviles, comparaciones entre períodos y otros.

•

Cálculos cruzados entre dimensiones, como asignación de costos y eliminaciones dentro de la compañía, o cálculos en el nivel de flas para aplicaciones orientadas a hojas de cálculo, como las declaraciones de pérdidas y ganancias.

•

Ampliación de las funciones básicas con funciones defnidas por el usuario.

•

Potentes funciones estadísticas y fnancieras.

•

Inteligencia de tiempo.

•

Pivoteo, tabulación cruzada, profundización, niveles de resumen para una o varias dimensiones y otras funciones poderosas de navegación.

En lo que respecta a la administración en general y a la administración de sistemas en particular, se requiere contar con lo siguiente:

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

1 78

5 - Bases de datos multidimensionales y tecnologías OLAP

•

El modelado inicial de datos en los que es clave elegir las dimensiones correctas, para prever cómo se accederá a ellos y se seleccionarán los fltros apropiados para cargarlos.

•

Transferencias periódicas y actualizaciones en bloque, debido a que las actualizaciones en incrementos son un reto y casi imposibles mientras la base de datos está en uso.

•

Acumulación, resúmenes y precálculo durante el proceso de cálculo.

•

Capacitación en una tecnología diferente y uso de nuevas habilidades.

•

Escritura de nuevas aplicaciones en lenguaje propietario para ampliar y mejorar los procesos frontales comunes de la base de datos.

Se necesitan varias dimensiones porque no se deben mezclar diferentes informaciones (ciudades con provincias, provincias con regiones, etc.). En las MDB sin jerarquías, la solución puede ser por dimensiones separadas.

5.6.2 OLAP relacional (ROLAP) Los datos se presentan al usuario en dimensiones, aunque se almacenan en forma relacional (fla, columna). Para ocultar este tipo de depósito, es necesario que se cree una capa semántica compuesta por metadatos (conjunto de datos sobre los datos), que posiciona las dimensiones para las tablas relacionales. Además, y para mejorar los tiempos de respuesta, es necesaria la creación de metadatos adicionales para cualquier resumen o adición. De esta manera, los datos se almacenan en la base relacional para su mantenimiento y administración. Los datos se presentan al usuario en dimensiones, aunque se almacenan en forma relacional (fla, columna). Para ocultar este tipo de depósito, es necesario que se cree una capa semántica compuesta por metadatos y, además, otros adicionales para cualquier resumen o adición.

La actividad inicial de diseño y confguración se conduce mediante el diseño técnico de una base de datos, a través de los siguientes pasos: •

Construir el diseño dimensional utilizando técnicas como el esquema Estrella (modelo Star), copo de nieve o constelaciones, que se verá en el apartado 5.6.2.1.

•

Incorporar los datos adecuados de adición y resumen.

•

Dividir los grandes conjuntos de datos en segmentos más pequeños y manejables para mejorar el desempeño, por ejemplo, dividiendo las unidades de tiempo.

•

Agregar índices creativos o de mapa de bits para mejorar el desempeño.

•

Crear y almacenar los metadatos. Los metadatos incluyen las defniciones de las dimensiones, su ubicación en las tablas relacionales, las relaciones jerárquicas entre dimensiones, la información de segmentos, las defniciones y descripciones de resúmenes y adiciones, las fórmulas y cálculos, la vigencia de uso y muchas otras cosas.

Desde la perspectiva operacional, los pasos para ejecutar una consulta son los siguientes: •

Alfaomega

Construir la herramienta “Cliente” utilizando una visión dimensional u organizacional de los datos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

5.6 OLAP: multidimensional contra relacional

•

Consultar el servidor OLAP desde la herramienta “Cliente” y examinar los metadatos en tiempo real.

•

Crear declaraciones SELECT de pasos múltiples y/o subconsultas correlacionadas y someterlas a la base de datos relacional.

•

Sobre los resultados de la consulta a la base de datos, se deben realizar funciones multidimensionales, como cálculos y fórmulas, traducción de bits para descripciones de la organización, etcétera.

•

Devolver los resultados a la herramienta “Cliente” para un mayor procesamiento y exhibición.

179

Como las herramientas ROLAP mapean una estructura multidimensional en una capa por encima de la estructura de tablas original, proveen la capacidad de generar los cálculos analíticos que limitan las bases relacionales y al usuario de herramientas que permiten la observación de datos bajo un esquema multidimensional. Dado que una base de datos relacional no entiende las estructuras multidimensionales, la capa multidimensional es de vital importancia. Con el objeto de optimizar el desempeño de un ROLAP, se hace necesaria la creación de una tabla de acumulación que debe pasar a un servidor de cálculos, que se encuentra fuera de la base de datos relacional. Un ROLAP requiere de la creación y mantenimiento de un índice. Para mantener un sistema efciente, es necesario que todos los renglones se ordenen o indexen, con el objeto de que este índice adquiera un tamaño considerablemente grande, que al no poder “subir” a la memoria, afecta el desempeño de la aplicación. 5.6.2.1 Esquemas de generación de modelos ROLAP Esquema Estrella (Modelo Star) El esquema Star o Estrella es una técnica de modelado de datos que se utiliza para hacer corresponder un modelo multidimensional sobre una base de datos relacional. Se lo denomina de esta manera porque su forma se parece a una estrella. El modelo Estrella tiene cuatro componentes: hechos, dimensiones, atributos y jerarquías de atributos. Los dos primeros se representan con tablas físicas relacionales en el almacén de datos; de esta forma, la tabla de hechos se vincula con cada dimensión en una relación “uno a muchos”. Ambas tablas se encuentran relacionadas entre sí por medio de claves foráneas (foreign key). El siguiente gráfco muestra un modelo Estrella para el sector de compras de una organización con tres dimensiones (patrones de interés): tiempo, proveedores y productos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

El modelo Estrella tiene cuatro componentes: hechos, dimensiones, atributos y jerarquías de atributos. Los dos primeros se representan con tablas físicas relacionales en el almacén de datos que se relacionan entre sí a través de claves foráneas. De esta forma, la tabla de hechos se vincula con cada dimensión en una relación "uno a muchos".

Alfaomega

1 80

5 - Bases de datos multidimensionales y tecnologías OLAP

Tiempo Fecha Año Mes Día

Hechos_compras

Proveedor id_proveedor

Fecha

I I

11

n i 1 id proveedor

o\

•• r\

id_producto >= 4;

cant_parciales_reprobados := cant_parciales - cant_parciales_aprobados;

DBMS_OUTPUTPUT_LINE(‘Cantidad de parciales rendidos = ‘||cant_parciales); DBMS_OUTPUTPUT_LINE(‘Cantidad de parciales aprobados = ‘||cant_parciales_aprobados); DBMS_OUTPUTPUT_LINE(‘Cantidad de parciales reprobados = ‘||cant_parciales_reprobados);

IF cant_parciales < 2 THEN DBMS_OUTPUTPUT_LINE(‘La cantidad rendida de parciales es menor a 2, no se cambia el estado’); ELSIF cant_parciales_aprobados >= 2 THEN BEGIN

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

9.3 Creación de las tablas y sus relaciones

295

DBMS_OUTPUT.PUT_LINE(‘2 parciales aprobados, REGULAR’); UPDATE alumnos_cursando_materias SET id_estado = (SELECT id_estado FROM estados_cursados WHERE n_estado LIKE ‘Regular’) WHERE id_estudiante = p_id_estudiante AND AND AND

id_materia = p_id_materia

id_carrera = p_id_carrera fecha_inscripcion = fecha_inscripcion_cursado;

END; ELSE BEGIN DBMS_OUTPUT.PUT_LINE( ‘Menos de 2 parciales aprobados, LIBRE’); UPDATE alumnos_cursando_materias SET id_estado = (SELECT id_estado FROM estados_cursados WHERE n_estado LIKE ‘Libre’) WHERE id_estudiante = p_id_estudiante AND AND

id_materia = p_id_materia

id_carrera = p_id_carrera AND

fecha_inscripcion = fecha_inscripcion_cursado;

END; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_OUTPUTPUT_LINE(‘El alumno no se ha inscripto a la materia – carrera especifcada’); END;

9.3.7 Ejemplos de ejecución Invocación: Si se realiza desde Oracle SQL*PLUS, debe defnirse con el comando set para que muestre los mensajes con la siguiente línea de código SQL> SET SERVEROUTPUT ON. Y, luego, SQL> EXECUTE actualizar_estado_materia(1,8,1) Resultado: “La cantidad rendida de parciales es menor a dos, por lo que si no se actualizan los valores, no se cambia el estado." Procedimiento PL/SQL terminado correctamente”.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

2 96

9 - Implementando el modelo en Oracle Express Edition XE

Invocación: SQL> execute actualizar_estado_materia(1,2,1); Resultado: Cantidad de parciales rendidos = 2 Cantidad de parciales aprobados = 1 Cantidad de parciales reprobados = 1 Menos de 2 parciales aprobados = LIBRE Procedimiento PL/SQL terminado correctamente.

Invocación: EXEC actualizar_estado_materia 1,1,1 Resultado: Cantidad de parciales rendidos = 2 Cantidad de parciales aprobados = 2 Cantidad de parciales reprobados = 0 2 parciales aprobados = REGULAR Procedimiento PL/SQL terminado correctamente.

9.4 Contenido de la página Web de apoyo

ElUjpf

El material marcado con asterisco (*) solo está disponible para docentes.

9.4.1 Mapa conceptual del capítulo 9.4.2 Autoevaluación 9.4.3 Presentaciones*

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Implementando el modelo en IBM DB2

Contenido

Objetivos

10.1 Introducción

298

10.2 Instalando e inicializando el servidor

298

10.3 Creando y probando nuestro modelo de Estudiante - Universidad

299

10.4 Contenido de la página Web de apoyo

310

•

Saber dónde conseguir el instalador de la base DB2 edición “Express - C” de IBM.

•

Entender cómo es el proceso de instalación.

•

Tener referencia sobre más bibliografía de esta edición de la base DB2.

•

Usar el centro de control para crear las tablas del modelo visto en el libro.

2 98

10 - Implementando el modelo en IBM DB2

10.1 Introducción DB2 Express-C forma parte de servidores de datos IBM DB2 que, además de almacenar datos en tablas relacionales, puede manejar información almacenada jerárquicamente como XML. DB2 Express-C tiene una forma de licenciamiento libre, sin límites y fácil de usar.

DB2 Express-C es un integrante de la familia de servidores de datos IBM DB2 que, además de almacenar datos en tablas relacionales, también puede manejar información almacenada jerárquicamente como XML. DB2 Express-C tiene una forma de licenciamiento libre, sin límites y fácil de usar. La ‘C’ es porque se dirige a la comunidad que se ha creado con los usuarios de esta base de datos. La comunidad DB2 Express-C consiste en una variedad de personas y compañías que diseñan, desarrollan, implementan o utilizan soluciones de base de datos, como desarrolladores de aplicaciones, vendedores de hardware e infraestructura y proveedores de otros tipos de solución que quieran incluir o empotrar un completo servidor de datos como parte de sus soluciones. DB2 Express-C comparte el mismo conjunto base de funcionalidades y código, como las ediciones pagas de DB2 para Linux, UNIX y Windows. DB2 Express-C puede correr en sistemas de 32-bits y 64-bits, con sistemas operativos Windows o Linux y, también, en un sistema que tenga cualquier cantidad de núcleos y de memoria. No tiene ningún requerimiento especial de almacenamiento o de configuración del sistema que sea especial. DB2 Express-C también incluye pureXML sin costo, que es la tecnología única de DB2 para almacenar y procesar documentos XML nativamente.

10.2 Instalando e inicializando el servidor

só°Ü¡fe,

El primer paso que se realizará para instalar el software del motor DB2 en nuestro servidor será descargarlo para luego correr el archivo ejecutable de instalación de manera que, posteriormente, podamos conectarnos desde las herramientas incluidas en la instalación como así también desde otros programas “clientes” que pueden ejecutarse en el mismo equipo o bien desde otro nodo de la red.

10.2.1Download En la Web de apoyo, encontrará el vínculo a la página Web que le brindará mayor información acerca del producto IBM DB2.

En la dirección http://www-01 .ibm.com/software/data/db2/express/download.html, se puede descargar la versión adecuada para nuestro Sistema Operativo, entre los que figuran actualmente Windows, Linux, Solaris e incluso, MAC OS X de Apple.

10.2.2 Instalación La arquitectura del procesador está disponible para 32-bit, 64-bit y PowerPC (Linux). Si se necesita correr el DB2 sobre otra plataforma, como UNIX, se debe comprar una de las ediciones de servidor de datos diferente a la Express-C. Los requerimientos del sistema operativo, para todas las ediciones de DB2, se describen en este documento: http://www.ibm.com/software/data/db2/udb/sysreqs.html

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

10.3 Creando y probando nuestro modelo de Estudiante – Universidad

El DB2 Express-C se puede instalar sobre sistemas que contengan uno o varios núcleos de CPU y de memoria, pero solo utilizará hasta dos núcleos y 2GB de memoria para la licencia gratuita y sin garantía y, para la licencia de suscripción de doce meses y versión con soporte, hasta cuatro núcleos y 4GB de memoria. El DB2 Express-C se puede utilizar en sistemas reales y en máquinas virtuales. Obviamente, también corre sobre sistemas más pequeños como, por ejemplo, un sistema de un solo procesador con 1GB de memoria. La última información sobre el requerimiento de hardware para DB2 Express-C se encuentra en su página Web: http://www-306.ibm.com/software/data/db2/express/getstarted.html Luego de bajar y descomprimir la imagen DB2 Express-C, el asistente guiará la instalación. En Windows, se debe ejecutar el archivo setup.exe en el directorio EXP/image; en Linux, alcanzará con ejecutar el programa db2setup del directorio exp/disk1 DB2. Al arrancar el programa de instalación, se verá la pantalla de inicio del proceso o Setup Launchpad del DB2. En las opciones que éste muestra se deberá hacer clic en “Install a product” y, luego, se elegirá la opción “Install New” para instalar otra copia de DB2 Express-C en el sistema. En los pasos siguientes, se verá cómo crear una base de datos para este ejemplo, las tablas asociadas y las filas del sistema académico. Para una referencia completa, se recomienda descargar el libro provisto para la comunidad Conociendo el DB2 Express-C de Raúl Chong, Ian Hakes y Rav Ahuja, que es un recurso gratuito disponible en múltiples idiomas en: http://www.ibm.com/developerworks/wikis/display/DB2/FREE+Book+Getting+Started+with+DB2+Express-C

10.3 Creando y probando nuestro modelo de Estudiante – Universidad 10.3.1 Creación de la base de datos Una vez instalado el software, se accederá a los programas que permitirán operar la base de datos desde el botón inicio y las opciones que se muestran en la Fig. 10.1. Específicamente, se ejecutará el centro de control. Allí se consultará qué vista del centro de control se usará, si la básica o la avanzada, según se ve en la Fig. 10.2. Para trabajar se elegirá la opción de vista avanzada del centro de control y, a continuación, se creará la base de datos para, posteriormente, avanzar sobre la creación de tablas y la inserción de filas.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

299

300

10 - Implementando el modelo en IBM DB2

Fig. 10.1 Creación de una base de datos.

Fig. 10.2 Inicio en el uso del centro de control en el que se especifica la vista que se utilizará.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

10.3 Creando y probando nuestro modelo de Estudiante – Universidad

301

Fig. 10.3 Creación de una base de datos.

En este paso, es necesario que se elija el nombre de la base y en qué ubicación del sistema de archivos se guardarán todos los archivos propios de la base de datos, según lo visto en la Fig. 10.4.

Fig. 10.4 Creación de una base de datos en la que se define el nombre y la ubicación de los archivos en el sistema.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 02

10 - Implementando el modelo en IBM DB2

En la figura anterior, además del nombre de la base de datos y la ubicación, se ve, a la izquierda, el submenú de los pasos que se cubrirán con esta herramienta como, por ejemplo, “Mantenimiento”, en el que se podrá especificar la ventana de tiempo, donde el motor realizará tareas como la reorganización de índices y el respaldo de la base de datos. Estas tareas son importantes para el buen funcionamiento general de las aplicaciones. El nombre elegido para la base de datos es “PRACTICA”, como se observa en la Fig. 10.5.

Fig. 10.5 Base de datos de ejemplo “PRACTICA” creada.

Desde la vista avanzada, si se abren los nodos de las bases de datos a la izquierda, se verán las carpetas en las que se guardarán las definiciones de objetos contenidos en la base de datos. En el menú del centro de control, la opción Herramientas permitirá acceder al programa Editor de mandatos, en el que se ejecutarán las sentencias SQL y se observará el resultado, ya sean los mensajes de ejecución, la descripción de un error que ha ocurrido en la ejecución y las filas resultantes de una consulta. Para ejecutar los comandos, es necesario conectarse a una base de datos. Esto se realiza desde la opción “Destino” del Editor de mandatos, tal como se muestra en la Fig. 10.6.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

10.3 Creando y probando nuestro modelo de Estudiante – Universidad

303

Fig. 10.6 Para ejecutar los comandos en el Editor de comandos, debe conectarse a una base de datos previamente.

10.3.2 Creación de las tablas y sus relaciones 10.3.2.1 Ejecución de scripts Ahora que ya se cuenta con una base de datos conectada, se procederá a crear las tablas correspondientes al modelo y sus respectivas claves para asegurar la integridad de los datos. Posteriormente, se establecerán, a modo de ejemplo, una función y un procedimiento almacenado de programación en la base de datos. El modelo de ejemplo se ha creado con un script similar al de los capítulos anteriores que se corresponden con otros motores de bases de datos. A continuación, se analizarán las diferencias que surgen al instalar en DB2. Como referencia, se deben tomar las primeras sentencias para la creación de las tablas con sus claves primarias y, luego, las de modificación de las tablas recientemente creadas para incorporar las claves foráneas. Finalmente, la inserción de datos de prueba y de creación de la función y del procedimiento almacenado. El motivo en el cual se fundamenta la decisión de modificar las tablas para incorporar las claves foráneas (FK) y no crearlas junto con la definición de cada tabla, es que ambas tablas relacionadas por dicha clave deben existir cuando ésta se crea. De esta manera, se evitarán las complicaciones originadas por esta causa. Para poder crear los objetos con las sentencias usadas en las otras bases, se tuvo que adaptar el nombre del tipo de datos de VARCHAR2 a VARCHAR, y el constraint

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 04

10 - Implementando el modelo en IBM DB2

‘NULL’ ha sido eliminado. Otro detalle que hubo que ajustar es la longitud del nombre de los constraints, para que la creación de los modelos de datos se pudiera ejecutar sin error. 10.3.3 M o d e l o d e d a t o s La Fig. 10.7 representa el diagrama del modelo de datos utilizado.

Fig. 10.7 Modelo de datos completo.

10.3.3.1 Script (sentencias DDL) A continuación, se precisarán las sentencias de definición de datos por ejecutarse, para disponer del modelo completo de la Fig. 10.7.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

10.3 Creando y probando nuestro modelo de Estudiante – Universidad

305

-- Creación de Tablas con sus claves primarias CREATE TABLE carreras( id_carrera int NOT NULL, nombre_carrera varchar(50) NOT NULL, titulo varchar(50), CONSTRAINT PK_carreras PRIMARY KEY (id_carrera) ); CREATE TABLE sexos( id_sexo integer NOT NULL, n_sexo varchar(20) NOT NULL, CONSTRAINT PK_sexos PRIMARY KEY (id_sexo) ); CREATE TABLE estados_cursados( id_estado integer NOT NULL, n_estado varchar(30) NOT NULL, CONSTRAINT PK_estados_cur PRIMARY KEY (id_estado) ); CREATE TABLE barrios( id_barrio integer NOT NULL, n_barrio varchar(50) NOT NULL, CONSTRAINT PK_barrios PRIMARY KEY (id_barrio) ); CREATE TABLE tipo_notas( id_tipo_nota integer NOT NULL, n_tipo_nota varchar(20) NOT NULL, CONSTRAINT PK_tipo_notas PRIMARY KEY (id_tipo_nota) ); CREATE TABLE tipo_documentos( id_tipo_documento integer NOT NULL, n_tipo_documento varchar(20) NOT NULL, CONSTRAINT PK_tipo_documentos PRIMARY KEY (id_tipo_documento) ); CREATE TABLE materias( id_materia integer NOT NULL, nombre VARCHAR(50) NOT NULL, CONSTRAINT PK_materias PRIMARY KEY (id_materia) );

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

10 - Implementando el modelo en IBM DB2

3 06

CREATE TABLE alumnos_cursando_materias( id_materia integer NOT NULL, id_carrera integer NOT NULL, id_estudiante integer NOT NULL, fecha_inscripcion date NOT NULL, id_estado integer NOT NULL, fecha_estado date NOT NULL, CONSTRAINT PK_al_curs_mat PRIMARY KEY (id_materia, id_carrera, id_estudiante, fecha_inscripcion)

); CREATE TABLE alumnos_examenes( id_materia integer NOT NULL, id_carrera integer NOT NULL, id_estudiante integer NOT NULL, fecha_del_examen date NOT NULL, fecha_inscripcion_a_exament date NOT NULL, nota integer, CONSTRAINT PK_alu_exam PRIMARY KEY (id_materia, id_carrera, id_estudiante, fecha_del_examen) ); CREATE TABLE alumnos_cursando_notas( id_materia integer NOT NULL, id_carrera integer NOT NULL, id_estudiante integer NOT NULL, fecha_inscripcion date NOT NULL, fecha_nota date NOT NULL, id_tipo_nota integer NOT NULL, nota integer, CONSTRAINT PK_alu_curs_not PRIMARY KEY (id_materia, id_carrera, id_estudiante, fecha_inscripcion, fecha_nota) ); CREATE TABLE inscripciones_a_carreras( id_estudiante integer NOT NULL, id_carrera integer NOT NULL, fecha date NOT NULL, CONSTRAINT PK_inscr_a_carr PRIMARY KEY (id_estudiante,id_carrera) );

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

10.3 Creando y probando nuestro modelo de Estudiante – Universidad

307

CREATE TABLE carreras( id_carrera int NOT NULL, nombre_carrera varchar(50) NOT NULL, titulo varchar(50), CONSTRAINT PK_carreras PRIMARY KEY (id_carrera) ); CREATE TABLE estudiantes( id_estudiante int NOT NULL, apellido varchar(30) NOT NULL, nombres varchar(100) NOT NULL, id_tipo_documento int NOT NULL, documento bigint NOT NULL, id_sexo int, calle varchar(60) NOT NULL, calle_numero varchar(30) NOT NULL, id_barrio int, CONSTRAINT PK_estudiantes PRIMARY KEY (id_estudiante) ); CREATE TABLE materias_x_turnos_examenes( id_turno integer NOT NULL, id_materia integer NOT NULL, id_carrera integer NOT NULL, fecha_del_examen date NOT NULL, CONSTRAINT PK_matxturexam PRIMARY KEY (id_materia, id_carrera, fecha_del_examen) ); Creación de claves foráneas (en DB2 la longitud de los nombres de constraint ha sido disminuida para que sea aceptado) ALTER TABLE alumnos_cursando_materias ADD CONSTRAINT FK_alucurma_esta FOREIGN KEY(id_estado) REFERENCES estados_cursados (id_estado); ALTER TABLE alumnos_cursando_materias ADD CONSTRAINT FK_alucurma_est FOREIGN KEY(id_estudiante) REFERENCES estudiantes (id_estudiante); ALTER TABLE alumnos_cursando_materias ADD CONSTRAINT FK_alcurma_plan FOREIGN KEY(id_materia, id_carrera) REFERENCES plan_de_carrera (id_materia, id_carrera); ALTER TABLE alumnos_examenes ADD CONSTRAINT FK_alu_exam_est FOREIGN KEY(id_estudiante) REFERENCES estudiantes (id_estudiante);

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

10 - Implementando el modelo en IBM DB2

3 08

ALTER TABLE alumnos_examenes ADD CONSTRAINT FK_alexamatxturexa FOREIGN KEY(id_materia, id_carrera, fecha_del_examen) REFERENCES materias_x_turnos_examenes (id_materia, id_carrera, fecha_del_examen); ALTER TABLE alumnos_cursando_notas ADD CONSTRAINT FK_alcurnotnotas FOREIGN KEY(id_tipo_nota) REFERENCES tipo_notas (id_tipo_nota); ALTER TABLE alumnos_cursando_notas ADD CONSTRAINT FK_alcunoAlucurmat FOREIGN KEY(id_materia, id_carrera, id_estudiante, fecha_inscripcion) REFERENCES alumnos_cursando_materias (id_materia, id_carrera, id_estudiante, fecha_inscripcion); ALTER TABLE inscripciones_a_carreras ADD CONSTRAINT FK_insccarrcarr FOREIGN KEY(id_carrera) REFERENCES carreras (id_carrera); ALTER TABLE inscripciones_a_carreras ADD CONSTRAINT FK_insccarrest FOREIGN KEY(id_estudiante) REFERENCES estudiantes (id_estudiante); ALTER TABLE plan_de_carrera ADD CONSTRAINT FK_pcarreracarr FOREIGN KEY(id_carrera) REFERENCES carreras (id_carrera); ALTER TABLE plan_de_carrera ADD CONSTRAINT FK_pcarremate FOREIGN KEY(id_materia) REFERENCES materias (id_materia); ALTER TABLE estudiantes ADD CONSTRAINT FK_estbarrios FOREIGN KEY(id_barrio) REFERENCES barrios (id_barrio); ALTER TABLE estudiantes ADD CONSTRAINT FK_estudsexos FOREIGN KEY(id_sexo) REFERENCES sexos (id_sexo); ALTER TABLE estudiantes ADD CONSTRAINT FK_esttipodoc FOREIGN KEY(id_tipo_documento) REFERENCES tipo_documentos (id_tipo_documento);

10.3.4 Datos de prueba Se insertará un conjunto de datos para probar la función y el procedimiento almacenado que se programarán en los ítems subsiguientes. De la misma manera que en la creación de tablas, las sentencias de inserción de datos (INSERT) se escribirán en la ventana del Editor del comando, disponible independientemente o desde la opción de Menú Herramientas del Centro de control. Previo a la ejecución, es necesario que se tenga seleccionada la base de datos correcta.

INSERT INTO barrios (id_barrio,n_barrio) VALUES (1,’Alto Alberdi’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (2,’Yofre’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (3,’Nueva Córdoba’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (4,’Centro’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (5,’Los Boulevares’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (6,’Guemes’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (7,’Ipona’);

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

10.3 Creando y probando nuestro modelo de Estudiante – Universidad

309

INSERT INTO barrios (id_barrio,n_barrio) VALUES (8,’Alta Córdoba’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (9,’General Paz’);

INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (1,’Parcial 1’); INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (2,’Parcial 2’); INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (3,’Final’); INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (4,’Trabajo Práctico’);

INSERT INTO tipo_documentos (id_tipo_documento,n_tipo_documento) VALUES (1,’DNI’); INSERT INTO tipo_documentos (id_tipo_documento,n_tipo_documento) VALUES (2,’LC’);

INSERT INTO carreras (id_carrera,nombre_carrera,titulo) VALUES (1,’Ingeniería en Sistemas de Información’,’Ingeniero en Sistemas de Información’);

INSERT INTO sexos (id_sexo,n_sexo) VALUES (1,’Masculino’); INSERT INTO sexos (id_sexo,n_sexo) VALUES (2,’Femenino’);

INSERT INTO estados_cursados (id_estado,n_estado) VALUES (1,’Inscripto’); INSERT INTO estados_cursados (id_estado,n_estado) VALUES (2,’Regular’); INSERT INTO estados_cursados (id_estado,n_estado) VALUES (3,’Libre’);

INSERT INTO materias (id_materia,nombre) VALUES (1,’Algoritmos y Estructuras de Datos’); INSERT INTO materias (id_materia,nombre) VALUES (2,’Análisis Matemático I’); INSERT INTO materias (id_materia,nombre) VALUES (3,’Análisis Matemático II’); INSERT INTO materias (id_materia,nombre) VALUES (4,’Algebra y Geometría Analítica’); INSERT INTO materias (id_materia,nombre) VALUES (5,’Matemática Discreta’); INSERT INTO materias (id_materia,nombre) VALUES (6,’Sistemas y Organizaciones’); INSERT INTO materias (id_materia,nombre) VALUES (7,’Ingeniería y Sociedad’); INSERT INTO materias (id_materia,nombre) VALUES (8,’Paradigmas de Programación’);

INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (1,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (2,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (3,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (4,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (5,1,1,2);

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

10 - Implementando el modelo en IBM DB2

3 10

INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (6,1,1,2); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (7,1,1,2); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (8,1,1,2);

INSERT INTO estudiantes (id_estudiante,apellido,nombres,id_tipo_documento,documento,id_sexo,calle,calle_ numero,id_barrio) VALUES (1, Abrutsky’,’Maximiliano Adrián’,1,23852963,1,’Av. Colón’,’1035’,1); INSERT INTO estudiantes (id_estudiante,apellido,nombres,id_tipo_documento,documento,id_sexo,calle,calle_ numero,id_barrio) VALUES (2,’DAMIANO’,’Luis’,1,19147258,1,’Dean Funes’,’903’,1);

INSERT INTO inscripciones_a_carreras (id_estudiante,id_carrera,fecha) VALUES (1,1,’26/01/2009’);

INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_

estado) VALUES (1,1,1,’01/02/2009’,1,’01/02/2009’); INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_ estado) VALUES (2,1,1,’01/02/2009’,1,’01/02/2009’); INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_ estado) VALUES (3,1,1,’01/02/2009’,1,’01/02/2009’); INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_ estado) VALUES (4,1,1,’01/02/2009’,1,’01/02/2009’);

INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (1,1,1,’01/02/2009’,’15/03/2009’,1,5); INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (1,1,1, ‘01/02/2009’, ‘26/05/2009’,2,7); INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (2,1,1,’01/02/2009’,’18/03/2009’,1,3); INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (2,1,1,’01/02/2009’,’29/05/2009’,2,4);

10.4 Contenido de la página Web de apoyo

^Jp^

El material marcado con asterisco (*) solo está disponible para docentes.

10.4.1 Mapa conceptual del capítulo 10.4.2 Autoevaluación 10.4.3 Presentaciones* Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Implementando el modelo en SQL Server 2005

Contenido

Objetivos

11.1 Introducción

312

11.2 Inicializando el servidor

312

11.3 Inicializando el cliente

317

11.4 Creando y probando nuestro modelo de Estudiante-Universidad 11.5 Contenido de la página Web de apoyo

•

Saber dónde conseguir el instalador del sistema de gestión de bases de datos SQL Server 2005, edición Express de Microsoft.

•

Comprender el proceso de instalación y poder realizar la parametrización básica de la instancia.

•

Adquirir los conocimientos para inicializar el servidor de bases de datos y la herramienta cliente.

•

Utilizar el SQL Server Management Studio para crear la base de datos, todas las tablas y relaciones del modelo visto en el libro y los objetos de programación de la base de datos.

318 334

3 12

11 - Implementando el modelo en SQL Server 2005

11.1 Introducción SQL Server es el Sistema de Gestión de Bases de Datos Relacional (SGBDR) de Microsoft. Esta empresa tuvo su ingreso en el mercado de bases de datos de nivel corporativo, por medio de una asociación con las frmas Sybase y Ashton-Tate. De esa asociación, surgió SQL Server 1.0 en 1989. .W-J-"fa

En la Web de apoyo, encontrará el vínculo a la página Web que le brindará información acerca del producto SQL Server 2005.

Si bien al principio sus características y su compatibilidad con Sistemas Operativos eran limitadas, los sucesivos lanzamientos de SQL Server lograron incrementar la porción de mercado hasta obtener una posición vital en el panorama actual de bases de datos corporativas. En la actualidad, las dos últimas versiones comerciales de SQL Server son la 2005 y 2008. A partir de la versión 2005, existe una edición sin costos de licenciamientos denominada “MS SQL Server Express Edition”; anteriormente, en la versión 2000, existía una edición de licenciamiento similar MSDE “Ms SQL Server 2000 Desktop Engine”. Aquí se utilizará la edición Express de la versión 2005 de Ms SQL Server.

11.2 Inicializando el servidor El primer paso que se realizará es la instalación de SGBDR en el servidor, de manera que, posteriormente, pueda conectarse desde los clientes que se pueden ejecutar en el mismo equipo o bien desde otro nodo de la red. 11.2.1 Download Como se mencionó anteriormente, la edición Express es de distribución gratuita; por lo tanto, se puede descargar desde el centro de descargas ofcial de Microsoft. El link válido al momento de la publicación de esta obra es: http://www.microsoft.com/downloadS/details.aspx?displaylang=es&FamilyID=22 0549b5-0b07-4448-8848-dcc397514b41 Este link podría estar obsoleto en el momento de la lectura, su búsqueda debería hacerse utilizando “Microsoft SQL Server 2005 Express Edition”. 11.2.2 Instalación La instalación puede llevarse a cabo utilizando un archivo de confguración en el que se especifcan todos los datos necesarios (rutas, tipo de autenticación, propiedades de la instancia, etc.), o bien a través del asistente que lo guiará paso a paso. Para usuarios principiantes, se recomienda la segunda alternativa. Los requisitos mínimos de hardware para esta edición son: procesador Pentium 600 Mhz. o mayor, 192Mb de memoria RAM y, al menos, 150Mb de espacio libre en el disco duro. El Sistema Operativo puede ser una edición servidor como Windows 2000 Server SP4, o superior, o bien de uso doméstico como Windows XP SP2 home edition o superior. (En la edición empresarial, es necesario un sistema operativo Windows servidor). En la instalación guiada por el asistente, el usuario deberá defnir algunas características como el nombre de la instancia, el tipo de intercalación, etcétera. Para evitar la Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

11.2 Inicializando el servidor

313

profundización de los aspectos técnicos, se recomienda dejar todas las opciones por defecto; sí se enfatiza en que se preste la máxima atención en el nombre de la instancia, en el modo de autenticación y en la intercalación. 11.2.2.1 Nombre de la instancia Una instancia de SQL Server es básicamente una instalación del motor de bases de datos de SQL Server, que se materializa como un servicio de Windows. Es decir: una instancia sería un servidor lógico, puesto que pueden instalarse varias instancias en un equipo o servidor físico. Cada instancia o servidor lógico contendrá varias bases de datos. Normalmente, se instala solo una instancia por cada equipo, pero suelen darse situaciones en las que se utilizan varias instancias para economizar recursos; por ejemplo, una instancia para cada ciclo de vida del desarrollo, es decir, una instancia de desarrollo, otra de prueba y otra de preproducción, las tres en el mismo equipo físico o servidor y, luego, una única instancia de producción en otro servidor. En el caso de tener varias instancias, es importante destacar que competirán por los recursos de memoria, disco y procesamiento, situación que motiva tener la instancia de producción en un servidor dedicado (solo con una instancia). Cada instancia se diferenciará del resto a través de un nombre único. En la instalación, se tienen dos posibilidades respecto del nombre de la instancia: la primera es que se defna un nombre, práctica recomendada si se tiene previsto instalar más de una instancia en el equipo. La segunda alternativa es utilizar la instancia predeterminada, o sin nombre, lo que es común cuando se instala una sola instancia en el equipo. Solo se puede instalar una instancia predeterminada, o sin nombre, y puede coexistir con varias instancias con nombres en el mismo equipo. La Fig. 11.1 muestra la ventana de diálogo del asistente de instalación, en la que el usuario defnirá el nombre de la instancia o instalará la instancia predeterminada. Se recomienda esta segunda opción, tal cual se visualiza en la fgura mencionada.

Fig. 11.1 Nombre de la instancia. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 14

11 - Implementando el modelo en SQL Server 2005

11.2.2.2 M o d o de autenticación La autenticación es el proceso por el cual se comprueba alguna identidad, se verifca que quién dice ser alguien realmente lo sea, para, de esta manera, controlar el acceso. SQL Server tiene dos modos de autenticación: uno es el modo de autenticación Windows, en el que los usuarios se autentican por el sistema operativo, desligándose el motor de bases de datos de esta tarea, dado que confía en el sistema operativo (con este modo de autenticación, SQL Server no pedirá ninguna contraseña). El otro es el modo de autenticación mixta: los usuarios también se acreditan por SQL Server; el motor de bases de datos solicitará la contraseña para realizarla. En el proceso de instalación (Fig. 11.2), se defne el modo de autenticación para el inicio de sesión ‘sa’, que tiene el rol de System Administrator (sysadmin) o administrador de sistema. Es el rol con el que se realizarán todas las tareas relacionadas al servidor de bases de datos, ya que agrupa todos los permisos posibles y, con esto, se hará la primera conexión al motor de bases de datos. Entonces, si se elije el modo de autenticación mixto, defnirá una contraseña que no se olvidará. Si el modo elegido es autenticación Windows, se logeará al sistema operativo con el mismo usuario que hizo la instalación y, luego, se accederá al servidor sin defnir ninguna contraseña.

Fig. 11.2 Modo de autenticación. En la Fig. 11.2, se visualiza la posibilidad de seleccionar los dos modos de autenticación mencionados con anterioridad; se recomienda elegir el modo de autenticación mixto y recordar la contraseña para poder lograr una conexión efectiva. Fundamentos de sencillez conceptual motivan esta recomendación, no porque sea más seguro o mejor en todos los aspectos que el otro modo. Hay circunstancias en las que resulta Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

11.2 Inicializando el servidor

315

conveniente la utilización de uno u otro, según las necesidades. Queda a criterio del lector profundizar acerca de la seguridad en SQL Server 2005, donde podrá ahondar en las ventajas y desventajas de cada modo. 11.2.2.3 Intercalación También es importante dedicar atención a la defnición de la intercalación para el servidor, ya que defne las reglas de comparación y de ordenamiento entre cadenas de caracteres. ¿Usted considera que la siguiente comparación es verdadera? Papa = papa = papá. Esto dependerá de la intercalación defnida, si es o no binaria, si es sensible a mayúsculas / minúsculas, etc. Ahora, suponga que ese conjunto de valores es retornado desde una consulta SQL con una cláusula que lo ordene, ¿cómo considera que se debería ordenar? Esto también depende de la intercalación, es decir, defne reglas de comparación y de ordenamiento. Este tema puede profundizarse si se aborda desde una intercalación que depende de un juego de caracteres (conjunto de todos los pares símbolo/codifcación), pero esto queda sujeto a interés del lector. Durante la instalación, se defne la intercalación en el nivel servidor (Fig. 11.3), pero, también, puede defnirse otra para cada base de datos (en el momento de su creación) o para cada tabla dentro de cada base, o bien hasta para cada columna (del tipo carácter) de cada tabla (también cuando se la crea). En esta jerarquía de defniciones de intercalaciones, se utiliza siempre la de menor granularidad (la de menor nivel), esto implica que si no se determinó una intercalación específca en una columna, se recurrirá a la de la tabla; si tampoco se la defnió, se utilizará la defnida en la base de datos; y si ésta tampoco se defnió, entonces se empleará la del servidor. Normalmente, sucede esta situación si se descuida esta propiedad y, por ende, se aplica la defnida en el servidor o, lo que es lo mismo, la que se defne en el momento de la instalación.

Fig. 11.3 Intercalación de la instancia. Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 16

11 - Implementando el modelo en SQL Server 2005

11.2.3 Inicialización SQL Server, tal como lo hacen otras aplicaciones en el sistema operativo Windows, se ejecuta a través de servicios (procesos de segundo plano). Distintos componentes de SQL Server se ejecutan como distintos servicios. Este capítulo centrará su interés en el servicio principal de SQL Server, que representa la accesibilidad de la instancia. Si se considera que la instalación se ejecutó con los valores por defecto, el servicio se denomina SQLSERVER (dicho nombre puede cambiar si durante la instalación se defne un nombre para la instancia). El servidor estará ejecutándose y accesible, si y solo si, dicho servicio se está ejecutando. Esto se puede supervisar tanto desde las herramientas administrativas de Windows (Fig. 11.4), como desde el Manejador de confguraciones (Fig. 11.5), que es una herramienta que se instala automáticamente con SQL Server con la fnalidad de confgurar los servicios y las conexiones.

Archivo

Acción

Ver

Ayuda

• ii •• * ^ Servicios (locales)

Nombre

I Descripción

| Estado

| Tipo de in

^ S e r v i d o r de seguimiento de vínculos distribuidos

Habilita el servicio Cliente de seguimi..,

Deshabilit

«§J Sistema de alimentación ininterrumpida

Administra un sistema de alimentado.,,

Manual

^ S i s t e m a de archivos distribuido

Integra recursos de archivo separad...

*jj$ Sistema de sucesos COM+

Admite el Servicio de notificación de ...

Iniciado

% S Q L Server Analysis Services (MSSQLSERVER)

Proporciona procesamiento analítico ,,,

Iniciado

Au hjmátií

^ j S Q L Server Integration Services

Proporciona soporte de administrado..

Iniciado

Automatic

% S Q L Server Reporting Services (MSSQLSERVER)

Administra, ejecuta, representa, pro,,.

Iniciado

Automátit

^SSLdeHTTP

Este servicio implementa el protocolo..,

Iniciado

Manual

«jjg Tarjeta inteligente

Administra el acceso a una tarjeta int..

^Telefonía

Ofrece compatibilidad con la API de t...

%Telnet

Permite que un usuario remoto inicie ...

Deshabilit

% Temas

Proporciona administración de temas ..

Deshabilit

Manual Automatic

*frH8«Hga= 2 BEGIN PRINT ‘2 parciales aprobados, REGULAR’ -- actualización al estado REGULAR UPDATE alumnos_cursando_materias SET id_estado = (SELECT id_estado FROM estados_cursados WHERE n_estado LIKE ‘Regular’) WHERE id_estudiante = @id_estudiante AND AND

Alfaomega

id_materia = @id_materia

id_carrera = @id_carrera

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

11.4 Creando y probando nuestro modelo de Estudiante – Universidad

AND

333

fecha_inscripcion = @fecha_inscripcion_cursado

END ELSE BEGIN PRINT ‘Menos de 2 parciales aprobados, LIBRE’ -- actualización al estado LIBRE UPDATE alumnos_cursando_materias SET id_estado = (SELECT id_estado FROM estados_cursados WHERE n_estado LIKE ‘Libre’) WHERE id_estudiante = @id_estudiante AND AND

id_materia = @id_materia

id_carrera = @id_carrera AND

fecha_inscripcion = @fecha_inscripcion_cursado

END END Ejemplos: Invocación: EXEC actualizar_estado_materia 1,8,1 Resultado: El alumno no se ha inscripto a la materia – carrera especifcada Invocación: EXEC actualizar_estado_materia 1,2,1 Resultado: Cantidad de parciales rendidos = 2 Cantidad de parciales aprobados = 1 Cantidad de parciales reprobados = 1 Menos de 2 parciales aprobados, LIBRE Invocación: EXEC actualizar_estado_materia 1,1,1 Resultado: Cantidad de parciales rendidos = 2 Cantidad de parciales aprobados = 2 Cantidad de parciales reprobados = 0 2 parciales aprobados, REGULAR

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 34

11 - Implementando el modelo en SQL Server 2005

11.5 Contenido de la página Web de apoyo El material marcado con asterisco (*) solo está disponible para docentes.

11.5.1 Mapa conceptual del capítulo 11.5.2 Autoevaluación 11.5.3 Presentaciones*

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Implementando el modelo en MySQL 5.1

Contenido

Objetivos

12.1 Introducción

336

12.2 Inicializando el servidor

336

12.3 Inicializando el cliente

342

12.4 Creando y probando nuestro modelo de Estudiante - Universidad

343

12.5 Contenido de la página Web de apoyo

358

•

Saber dónde conseguir el instalador de MySQL.

•

Comprender los tipos y el proceso de instalación en general, y poder realizar la configuración básica de la instancia.

•

Adquirir los conocimientos para inicializar el servidor de bases de datos y la herramienta cliente.

•

Utilizar el MySQL Workbench para crear la base de datos, todas las tablas y relaciones del modelo visto en el libro y los objetos de programación de la base de datos.

3 36

12 - Implementando el modelo en MySQL 5.1

12.1 Introducción

En la Web de apoyo, encontrará el vínculo a la página Web que le brindará mayor información acerca del producto MySQL 5.1.

MySQL surgió en una empresa sueca MySQL AB, en la década del noventa. En la actualidad, la empresa es subsidiada por Sun Microsystems de Oracle Corporation. MySQL es, sin duda, uno de los Sistemas de Gestión de Bases de Datos Relacionales (SGBDR) open source más difundido y utilizado. Se puede obtener bajo la licencia GNU GPL (Software Libre) o mediante la distribución comercial, que se diferencia en el soporte, las herramientas de monitoreo y en la posibilidad de incorporarlo en productos privativos. En este capítulo se utilizará la versión libre. En sus orígenes, este producto carecía de elementos básicos de un SGBDR como la integridad referencial y las transacciones, que se fueron incorporando a medida de que el proyecto logró una mayor difusión mundial. En la actualidad, existen millones de instalaciones impulsadas por el auge del open source y el conjunto de herramientas de desarrollo LAMP: Linux – Apache – MySQL – PHP/Perl/Python.

12.2 Inicializando el servidor La instalación del servidor es la actividad inicial que se realizará; luego, se entablarán conexiones desde los clientes, ya sean locales o remotos, para interactuar con el servidor de bases de datos.

12.2.1 Download El software libre implica la posibilidad de obtener una distribución sin costo del producto. MySQL puede ejecutarse en diferentes sistemas operativos, como las variadas distribuciones de Linux, Mac OS X, Sun Solaris, IBM AIX, MS Windows, etcétera. Se descargará la distribución indicada a su plataforma. Dentro de las posibilidades para el sistema operativo Windows, se puede optar por un paquete de instalación MSI de Windows Installer, que lo guiará, paso a paso, con un asistente de instalación, o bien por el archivo comprimido en ZIP, en el que el usuario será el encargado de descomprimirlo y de la configuración manual. Las dos opciones se descargarán completas o solo con los componentes esenciales de MySQL. Esto excluye asistentes de configuración, librerías para desarrolladores y otras opciones. Todas las alternativas se encuentran en el siguiente enlace: http://dev.mysql.com/downloads/mysql/ Como este enlace podría estar obsoleto en el momento de la lectura de esta obra, su búsqueda se debería ejecutar utilizando “Download MySQL Community Server”. En este tutorial, se utilizará la distribución para Windows, con instalador y versión completa (no esencial) “Windows (x86, 32-bit), MSI Installer”; el nombre del archivo es “mysql-5.1.44-win32.msi”.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.2 Inicializando el servidor

12.2.2 Instalación La instalación en un sistema operativo Windows puede ser Windows 2000, Windows X P, Windows Server 2003 y Windows Server 2008. Son soportadas tanto las versiones en 32 como en 64 bits. Como requisito mínimo, se recomienda unos 200 mb de espacio libre en el disco duro; es necesario el soporte TCP/IP. Es recomendable ejecutar la instalación con una cuenta con privilegios de administrador. Para MySQL, también se cuenta con la posibilidad de ejecutar el paquete de instalación de forma silenciosa, utilizando un archivo de configuración con todos los parámetros necesarios. La otra alternativa, que es la recomendable para usuarios inexpertos, es través del asistente guía. 12.2.2.1 Tipos de instalación Al ejecutarse el paquete de instalación de MySQL Server 5 . 1 , se inicia el asistente con una pantalla de bienvenida; luego, se solicita que se seleccione el tipo de instalación que se realizará: típica, completa o personalizada, tal como se aprecia en la Fig. 12.1.

Fig. 12.1 Tipo de instalación. La instalación típica consta del servidor MySQL, el cliente por línea de comando para interactuar con el servidor y las utilidades no gráficas para la administración del servidor y de sus bases de datos. La completa incluye todos los componentes

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

337

3 38

12 - Implementando el modelo en MySQL 5.1

scripts de soporte, documentación, librería de servidor embebido, etcétera. El último tipo de instalación es la personalizada, que brinda la flexibilidad de definir los componentes a instalarse acorde con las necesidades particulares. Se seleccionará la instalación completa para continuar con los siguientes pasos. Más adelante, se presentará un resumen previo de la instalación que se realizará y, tras confirmarla, mostrará el progreso actual. Luego de completarse, se publicitarán las ventajas de MySQL Enterprise (distribución comercial paga) y se finalizará el asistente con la posibilidad de configurar el servidor recientemente instalado y, también, de registrar el producto con el fin de recibir notificaciones de actualizaciones, ofertas, etcétera (Fig. 12.2).

Fig. 12.2 Finalización del asistente de instalación del servidor MySQL.

Se seleccionará la configuración del servidor. En el siguiente apartado, se analizarán los aspectos importantes. 12.2.2.2 C o n f g u r a n d o la instancia. Opciones de Servicio Windows Cabe recordar el concepto de instancia explicado para otro motor. Una instancia es, básicamente, una instalación del motor de bases de datos, que en el caso de MySQL se podrá implementar como un servicio de Windows, tal como se verá en este apartado. Es decir que, una instancia, sería un servidor lógico, puesto que pueden instalarse varias instancias en un equipo o servidor físico. Cada instancia o servidor lógico contendrá varias bases de datos.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.2 Inicializando el servidor

Antes de definir si la instancia se implementará como un servicio del sistema operativo, el asistente de configuración brinda la posibilidad de optar por el modo detallado o el básico (Fig. 12.3).

Fig. 12.3 Tipo de configuración de la instancia.

El modo básico se orienta a nuevos usuarios para que puedan, de manera fácil y rápida, poner en funcionamiento el servidor MySQL, sin algunas decisiones de configuración que sí se deben especificar en el modo detallado. Se optará por la vía más sencilla, en este caso, solo se definirán las opciones de servicio y de seguridad. Continuando con el modo básico de configuración, se prosigue con la definición de instalar la instancia como un servicio (Fig. 12.4). Un servicio, dentro del sistema operativo Windows, es un proceso que se ejecuta en segundo plano, que se puede iniciar automáticamente en el momento en que, también, se inicia el sistema. Para su configuración, hay que chequear la opción “Iniciar el servidor MySQL automáticamente”. El nombre por defecto del servicio es MySQL, pero el usuario puede modificarlo. Si se realizaran instalaciones de más de una instancia, tendrá cada una su nombre de servicio propio.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

339

3 40

12 - Implementando el modelo en MySQL 5.1

Fig. 12.4 Opción de servicio en Windows.

12.2.2.3 C o n f g u r a c i ó n de la instancia. Opciones de seguridad Durante el proceso de configuración, el usuario root tiene todos los privilegios en el servidor. Se puede especificar su contraseña y, también, crear una cuenta de acceso anónima, que no es lo recomendado porque disminuiría la seguridad. La Fig. 12.5 es la pantalla en la que se define lo mencionado en el párrafo anterior. Cabe destacar que difiere si se trata de la primera instalación o si ya existía otra instancia MySQL ejecutándose en el equipo. Por aspectos de seguridad, es altamente recomendable definir una contraseña para root, que se recordará para una posterior autenticación contra el servidor. Por defecto, el usuario root solo se puede logear localmente en el servidor. Para permitir que lo pueda hacer remotamente desde otros equipos, se tiene que chequear dicha opción. Para finalizar, se mostrará un resumen de los pasos que realizará el asistente y, luego de que se confirme la ejecución, se visualizará el progreso de la instalación hasta que termine. Se podrá ejecutar nuevamente el asistente de configuración, ya sea para reconfiguración de la instancia, o bien para removerla. Junto con el acceso directo, se creará el cliente por la línea de comando (Fig. 12.6).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.2 Inicializando el servidor

341

Fig. 12.5 Seguridad de la instancia.

Fig. 12.6 Grupo de programas MySQL Server 5.1.

12.2.3 Inicialización Si MySQL se instaló como servicio para que se inicie automáticamente, éste debería estar inicializado (ejecutándose) a la espera de conexiones. Se puede verificar o modificar el estado desde “Servicios” perteneciente al grupo de “Herramientas administrativas” de Windows (Fig. 12.7).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 42

12 - Implementando el modelo en MySQL 5.1

Fig. 12.7 Herramientas Administrativas -> Servicios.

12.3 Inicializando el cliente Luego de la puesta en marcha del servidor, el siguiente paso es la instalación de MySQL Workbench —que es la herramienta gráfica más reciente y de libre distribuciónpara que interactúe con el servidor MySQL. No es obligación instalar esta herramienta cliente, puesto que el servidor ya se encuentra funcionando y se podría administrar a través de sentencias que utilicen la línea de comando, como así también las aplicaciones desarrolladas podrían operar contra el motor de bases de datos. Se optará por su utilización debido a la sencillez operativa brindada por el entorno visual de la herramienta. MySQL Workbench consta de tres componentes principales: •

Database Design & Modeling: diseño y modelado de bases de datos.

•

SQL Development: programación en SQL, realización de consultas, ejecución de scripts, creación de procedimientos almacenados, etc.

•

Database Administration: realización de las tareas inherentes a la administración del servidor, como la implementación de acceso y de seguridad, las políticas de backup, los controles de rendimiento, entre otros.

Workbench reemplaza a las obsoletas MySQL GUI Tools, compuestas por MySQL Administrator, Query Browser, Migration Tool y System Tray Monitor. Se recomienda no utilizarlas porque su mantenimiento y soporte están discontinuados.

12.3.1 Download La descarga se puede hacer libremente desde el siguiente link, válido en el momento de la publicación de este libro (es conveniente que se seleccione una versión 5.2 o superior): http://dev.mysql.com/downloads/workbench/5.2.html En caso de que el enlace se encuentre obsoleto en el momento de la lectura, la búsqueda se realizará utilizando “Download MySQL Workbench”.

12.3.2 Instalación El proceso de instalación es muy sencillo: si se seleccionó un paquete de instalación MSI, un asistente guiará la tarea. Solo se especificará si se desea una instalación completa que incluya todos los componentes, o bien una personalizada. En el caso

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

343

que se hubiese optado por descargar la herramienta para ser utilizada sin instalador, se deberá descomprimir el archivo ZIP en el directorio de destino.

12.3.3 Utilizando el MySQL Workbench Para utilizar esta herramienta, hay que dirigirse al menú Inicio y seleccionar Todos los programas; luego, MySQL. A continuación, se hará clic en MySQL Workbench 5.2 OSS. En la Fig. 12.8, se muestra la solapa inicial, desde la que se puede acceder a las funcionalidades principales mencionadas con anterioridad: Desarrollo, Modelado y Administración (se señalan con óvalos).

Fig. 12.8 Solapa inicial de MySQL Workbench.

12.4 Creando y probando nuestro modelo de Estudiante – Universidad El lector ya está en condiciones de interactuar con MySQL, esto es: el servidor se está ejecutando con el entorno gráfico MySQL Workbench para realizar las tareas administrativas y de programación de forma amigable. Como primer paso, se procederá a establecer una conexión al servidor desde MySQL Workbench; luego, se creará la base de datos y todas las tablas utilizando el script (conjunto de sentencias que se ejecutan de forma conjunta).

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Para mayor información sobre el uso de MySQL Workbench y de todas sus funcionalidades, se sugiere la biblioteca de documentación ofcial: http://dev.mysql.com/doc/workbench/ en/index.html

Alfaomega

12 - Implementando el modelo en MySQL 5.1

12.4.1 Creación de una conexión al servidor Tanto la creación de la conexión como las demás actividades se llevarán a cabo con el MySQL Workbench. A la acción de crear de una conexión, como en tantas otras tareas frecuentes, se puede acceder desde la solapa inicial de MySQL Workbench, tal como se indica en la Fig. 12.8. La opción que se seleccionará es “new connection”, dentro del grupo de tareas frecuentes de “SQL Development”. Se desplegará el administrador de conexiones para crear esta nueva conexión al servidor MySQL (Fig. 12.9). Hay tres métodos de conexión: TCP/IP estándar y sobre SSH (intérprete de órdenes seguras) o por medio de socket. En el siguiente ejemplo, se utilizará el primer método mencionado (TCP/IP estándar). Además del nombre de la conexión (“connLocal” en el ejemplo de la Fig. 12.9), para el método TCP/IP, es necesario que se especifiquen el nombre de red o la dirección IP (hostname) y el puerto (port) en el que se ejecuta el servidor MySQL. En el caso de que MySQL Workbench se ejecute en el mismo equipo servidor, hay que especificarle localhost, o bien la dirección IP 127.0.0.1. El puerto por defecto es el 3306. Luego se configurará el usuario para la conexión. Se utilizará ‘root’ de la misma manera en que se explicitó durante la instalación, ya que es el que tiene todos los privilegios sobre el servidor. Es opcional la definición del esquema (base de datos) al que se conecta por defecto. En el siguiente ítem, se creará una base de datos uniDB.

Fig. 12.9 Creación de conexión MySQL Workbench.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

Antes de concluir con la conexión, se sugiere que se realice el test para verificar que los parámetros definidos sean los correctos. Esto se logra si se presiona “Test Connection”, que abrirá un mensaje de diálogo que solicitará la clave para el usuario especificado, en este caso, root, cuyo password se definió en la instalación del servidor. Se puede almacenar la clave, o bien ignorar esta opción y tipearla cada vez que se solicite.

12.4.2 Creación de la b a s e de d a t o s , las tablas y s u s relaciones 12.4.2.1 Ejecución de script Lo primero que se creará es la base de datos o esquema, luego se crearán las tablas correspondientes y sus respectivas claves para asegurar la integridad de los datos. Finalmente, se introducirá una función y un procedimiento almacenado a modo de ejemplo de programación. Una aclaración importante: en MySQL, el concepto de esquema es sinónimo de base de datos y, normalmente, se usan estos términos indistintamente, tal es así que la sentencia de creación puede invocarse como CREATE DATABASE o CREATE SCHEMA. Esto es de suma relevancia, puesto que, en otros motores de bases de datos, el concepto es otro. En ellos, un esquema es una agrupación o un contenedor de varios objetos que existen por ventajas administrativas y de manejo de seguridad; una base de datos en SQL Server u Oracle podría tener varios esquemas. Referencia para la interpretación del script: las primeras sentencias son las de creación de tablas con sus claves primarias y luego las de modificación de las tablas recientemente creadas para incorporar las claves foráneas; finalmente, la inserción de datos de prueba y de creación de la función y del procedimiento almacenado. El motivo en que se fundamenta la decisión de modificar las tablas para incorporar las claves foráneas (FK) y no crearlas junto con la definición de cada tabla es que ambas tablas relacionadas por dicha clave deben existir en el momento en que ésta se crea. De esta manera, se evitan complicaciones originadas por esta causa. Para ejecutar las sentencias DDL que crearán la base de datos y los objetos del modelo, se abrirá una conexión desde “Open Connection to start Querying” (Fig. 12.8). Una ventana de diálogo solicitará que se seleccione una conexión (se utilizará la creada recientemente, ‘connLocal’, según el ejemplo) y, posteriormente, si es que no se hace uso de la opción de recordar claves, se pedirá el ingreso de la clave del usuario de dicha conexión (‘root’, según el ejemplo). Posterior a copiar las sentencias se proseguirá con la ejecución de las mismas, para ello se hace uso de un botón destinado a tal fin, señalado en la próxima imagen (Fig. 12.10), notar que a través del mismo, se ejecutarán todas las sentencias, a diferencia con el botón que se encuentra a su derecha, que solo ejecutará la sentencia seleccionada. Los resultados de la ejecución se visualizan por la consola de salida (Fig. 12.11). Se podrá navegar entre los objetos de la base de datos desde el explorador; en el caso de las tablas, hay que desplegar la base de datos y, luego, el grupo “Tables”. Es necesario actualizar el explorador (Refresh all) una vez finalizadas todas las sentencias.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

345

3 46

12 - Implementando el modelo en MySQL 5.1

Fig. 12.10 Ejecución de sentencias.

Fig. 12.11 Ejecución correcta.

12.4.2.2 Modelo de datos MySQL Workbench incorpora la funcionalidad de modelado de datos, tal como se mencionó en sus características y como se puede observar en la Fig. 12.8. El modelo de datos utilizado es el que se aprecia en el diagrama a continuación (Fig.12.12) y que se generó, prácticamente, de forma automática por la herramienta en cuestión. Queda a interés del lector profundizar acerca de su funcionalidad y utilización.

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

347

Fig. 12.12 Modelo de datos completo.

12.4.2.3 Script (sentencias DDL) A continuación, se precisan las sentencias de definición de datos que se ejecutarán para crear el modelo completo de la Fig. 12.12. Las sentencias son exactamente las mismas (ANSI) que para SQL Server, a excepción de la primera sentencia que crea la base de datos que, en SQL Server, se hizo uso de su herramienta visual para dicha acción. El separador de instrucción es ‘;’.

-- Creación de la base de datos con confguración por defecto. Podría haberse usado CREATE SCHEMA CREATE DATABASE IF NOT EXISTS `UniDB` ; USE `UniDB`; -- Creación de tablas con sus claves primarias CREATE TABLE IF NOT EXISTS carreras( id_carrera int NOT NULL,

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

12 - Implementando el modelo en MySQL 5.1

3 48

nombre_carrera varchar(50) NOT NULL, titulo varchar(50) NULL, CONSTRAINT PK_carreras PRIMARY KEY CLUSTERED (id_carrera ASC)

) ; CREATE TABLE IF NOT EXISTS sexos( id_sexo int NOT NULL, n_sexo varchar(20) NOT NULL, CONSTRAINT PK_sexos PRIMARY KEY CLUSTERED (id_sexo ASC)

) ; CREATE TABLE IF NOT EXISTS estados_cursados( id_estado int NOT NULL, n_estado varchar(30) NOT NULL, CONSTRAINT PK_estados_cursados PRIMARY KEY CLUSTERED (id_estado ASC)

) ; CREATE TABLE IF NOT EXISTS barrios( id_barrio int NOT NULL, n_barrio varchar(50) NOT NULL, CONSTRAINT PK_barrios PRIMARY KEY CLUSTERED (id_barrio ASC)

) ; CREATE TABLE IF NOT EXISTS tipo_notas( id_tipo_nota int NOT NULL, n_tipo_nota varchar(20) NOT NULL, CONSTRAINT PK_tipo_notas PRIMARY KEY CLUSTERED (id_tipo_nota ASC)

) ; CREATE TABLE IF NOT EXISTS tipo_documentos( id_tipo_documento int NOT NULL, n_tipo_documento varchar(20) NOT NULL, CONSTRAINT PK_tipo_documentos PRIMARY KEY CLUSTERED (id_tipo_documento ASC)

) ;

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

349

CREATE TABLE IF NOT EXISTS materias( id_materia int NOT NULL, nombre VARCHAR(50) NOT NULL, CONSTRAINT PK_materias PRIMARY KEY CLUSTERED (id_materia ASC) ) ; CREATE TABLE IF NOT EXISTS alumnos_cursando_materias( id_materia int NOT NULL, id_carrera int NOT NULL, id_estudiante int NOT NULL, fecha_inscripcion datetime NOT NULL, id_estado int NOT NULL, fecha_estado datetime NOT NULL, CONSTRAINT PK_alumnos_cursando_materias PRIMARY KEY CLUSTERED (id_materia ASC, diante ASC,fecha_inscripcion ASC)

id_carrera ASC, id_estu-

) ; CREATE TABLE IF NOT EXISTS alumnos_examenes( id_materia int NOT NULL, id_carrera int NOT NULL, id_estudiante int NOT NULL, fecha_del_examen datetime NOT NULL, fecha_inscripcion_a_exament datetime NOT NULL, nota tinyint NULL, CONSTRAINT PK_alumnos_examenes PRIMARY KEY CLUSTERED (id_materia ASC, id_carrera ASC, id_estudiante ASC, fecha_del_examen ASC) ) ; CREATE TABLE IF NOT EXISTS alumnos_cursando_notas( id_materia int NOT NULL, id_carrera int NOT NULL, id_estudiante int NOT NULL, fecha_inscripcion datetime NOT NULL, fecha_nota datetime NOT NULL, id_tipo_nota int NOT NULL, nota tinyint NULL,

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

12 - Implementando el modelo en MySQL 5.1

3 50

CONSTRAINT PK_alumnos_cursando_notas PRIMARY KEY CLUSTERED (id_materiaASC,id_carrera ASC,id_estudiante ASC,fecha_inscripcion ASC,fecha_nota ASC)

) ; CREATE TABLE IF NOT EXISTS inscripciones_a_carreras( id_estudiante int NOT NULL, id_carrera int NOT NULL, fecha datetime NOT NULL, CONSTRAINT PK_inscripciones_a_carreras PRIMARY KEY CLUSTERED (id_estudiante ASC,id_carrera ASC) ) ; CREATE TABLE IF NOT EXISTS plan_de_carrera( id_materia int NOT NULL, id_carrera int NOT NULL, anio_cursado int NULL, cuatrimestre_anio int NULL, CONSTRAINT PK_plan_de_carrera PRIMARY KEY CLUSTERED (id_materia ASC,id_carrera ASC) ) ; CREATE TABLE IF NOT EXISTS estudiantes( id_estudiante int NOT NULL, apellido varchar(30) NOT NULL, nombres varchar(100) NOT NULL, id_tipo_documento int NOT NULL, documento bigint NOT NULL, id_sexo int NULL, calle varchar(60) NOT NULL, calle_numero varchar(30) NOT NULL, id_barrio int NULL, CONSTRAINT PK_estudiantes PRIMARY KEY CLUSTERED (id_estudiante ASC) ) ; CREATE TABLE IF NOT EXISTS materias_x_turnos_examenes( id_turno int NOT NULL, id_materia int NOT NULL, id_carrera int NOT NULL,

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

351

fecha_del_examen datetime NOT NULL, CONSTRAINT PK_materias_x_turnos_examenes PRIMARY KEY CLUSTERED (id_materia ASC, id_carrera ASC, fecha_del_ examen ASC) ) ; -- Creación de claves foráneas ALTERTABLE alumnos_cursando_materias ADD CONSTRAINT FK_alumnos_cursando_materias_estados FOREIGN KEY(id_estado) REFERENCES estados_cursados (id_estado)

; ALTERTABLE alumnos_cursando_materias ADD CONSTRAINT FK_alumnos_cursando_materias_estudiantes FOREIGN KEY(id_estudiante) REFERENCES estudiantes (id_estudiante)

; ALTER TABLE alumnos_cursando_materias ADD CONSTRAINT FK_alumnos_cursando_materias_plan_carrera FOREIGN KEY(id_materia, id_carrera) REFERENCES plan_de_carrera (id_materia, id_carrera) ; ALTERTABLE alumnos_examenes ADD CONSTRAINT FK_alumnos_examenes_estudiantes FOREIGN KEY(id_estudiante) REFERENCES estudiantes (id_estudiante)

; ALTER TABLE alumnos_examenes ADD CONSTRAINT FK_alumnos_examenes_materias_x_turnos_examenes FOREIGN KEY(id_materia, id_carrera, fecha_del_examen) REFERENCES materias_x_turnos_examenes (id_materia, id_carrera, fecha_del_examen)

; ALTERTABLE alumnos_cursando_notas ADD CONSTRAINT FK_alumnos_cursando_notas_tipo_notas FOREIGN KEY(id_ tipo_nota) REFERENCES tipo_notas (id_tipo_nota)

; ALTER TABLE alumnos_cursando_notas ADD CONSTRAINT FK_alumnos_cursando_notas_alumnos_cursando_materias FOREIGN KEY(id_materia, id_carrera, id_estudiante, fecha_inscripcion) REFERENCES alumnos_cursando_materias (id_materia, id_carrera, id_estudiante, fecha_inscripcion) ; ALTERTABLE inscripciones_a_carreras ADD CONSTRAINT FK_inscripciones_a_carreras_carreras FOREIGN KEY(id_carrera) REFERENCES carreras (id_carrera)

; ALTERTABLE inscripciones_a_carreras ADD CONSTRAINT FK_inscripciones_a_carreras_estudiantes FOREIGN KEY(id_ estudiante) REFERENCES estudiantes (id_estudiante) ; Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

12 - Implementando el modelo en MySQL 5.1

3 52

ALTERTABLE plan_de_carrera ADD CONSTRAINT FK_plan_de_carrera_carreras FOREIGN KEY(id_carrera) REFERENCES carreras (id_carrera) ; ALTERTABLE plan_de_carrera ADD CONSTRAINT FK_plan_de_carrera_materias FOREIGN KEY(id_materia) REFERENCES materias (id_materia) ; ALTERTABLE estudiantes ADD CONSTRAINT FK_estudiantes_barrios FOREIGN KEY(id_barrio) REFERENCES barrios (id_barrio) ; ALTERTABLE estudiantes ADD CONSTRAINT FK_estudiantes_sexos FOREIGN KEY(id_sexo) REFERENCES sexos (id_sexo) ; ALTERTABLE estudiantes ADD CONSTRAINT FK_estudiantes_tipo_documentos FOREIGN KEY(id_tipo_documento) REFERENCES tipo_documentos (id_tipo_documento)

; ALTERTABLE materias_x_turnos_examenes ADD CONSTRAINT FK_materias_x_turnos_examenes_plan_carrera FOREIGN KEY(id_materia, id_carrera) REFERENCES plan_de_carrera (id_materia, id_carrera)

;

12.4.2.4 Datos de prueba Se insertará un conjunto de datos con la finalidad de probar la función y el procedimiento almacenado que se programarán en los ítems subsiguientes. Las sentencias de inserción de datos (INSERT) se ejecutarán de forma idéntica a la creación de tablas en el punto anterior. Se Asegurará la selección de la base de datos correcta, previo a la ejecución. (Verificar el combo de selector de DB en la Fig. 12.10 o escribir la sentencia USE ‘UniDB’ antes del primer INSERT).

INSERT INTO barrios (id_barrio,n_barrio) VALUES (1,’Alto Alberdi’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (2,’Yofre’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (3,’Nueva Córdoba’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (4,’Centro’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (5,’Los Boulevares’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (6,’Guemes’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (7,’Ipona’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (8,’Alta Córdoba’); INSERT INTO barrios (id_barrio,n_barrio) VALUES (9,’General Paz’); INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (1,’Parcial 1’);

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

353

INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (2,’Parcial 2’); INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (3,’Final’); INSERT INTO tipo_notas (id_tipo_nota,n_tipo_nota) VALUES (4,’Trabajo Practico’); INSERT INTO tipo_documentos (id_tipo_documento,n_tipo_documento) VALUES (1,’DNI’); INSERT INTO tipo_documentos (id_tipo_documento,n_tipo_documento) VALUES (2,’LC); INSERT INTO carreras (id_carrera,nombre_carrera,titulo) VALUES (1,’Ingeniería en Sistemas de Informacion’,’Ingeniero en Sistemas de Informacion’); INSERT INTO sexos (id_sexo,n_sexo) VALUES (1,’Masculino’); INSERT INTO sexos (id_sexo,n_sexo) VALUES (2,’Femenino’); INSERT INTO estados_cursados (id_estado,n_estado) VALUES (1,’Inscripto’); INSERT INTO estados_cursados (id_estado,n_estado) VALUES (2,’Regular’); INSERT INTO estados_cursados (id_estado,n_estado) VALUES (3,’Libre’); INSERT INTO materias (id_materia,nombre) VALUES (1,’Algoritmos y Estructuras de Datos’); INSERT INTO materias (id_materia,nombre) VALUES (2,’Analisis Matematico I’); INSERT INTO materias (id_materia,nombre) VALUES (3,’Analisis Matematico II’); INSERT INTO materias (id_materia,nombre) VALUES (4,’Algebra y Geometria Analitica’); INSERT INTO materias (id_materia,nombre) VALUES (5,’Matematica Discreta’); INSERT INTO materias (id_materia,nombre) VALUES (6,’Sistemas y Organizaciones’); INSERT INTO materias (id_materia,nombre) VALUES (7,’Ingenieria y Sociedad’); INSERT INTO materias (id_materia,nombre) VALUES (8,’Paradigmas de Programacion’); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (1,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (2,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (3,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (4,1,1,1); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (5,1,1,2); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (6,1,1,2); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (7,1,1,2); INSERT INTO plan_de_carrera (id_materia,id_carrera,anio_cursado,cuatrimestre_anio) VALUES (8,1,1,2); INSERT INTO estudiantes (id_estudiante,apellido,nombres,id_tipo_documento,documento,id_sexo,calle,calle_numero,id_ barrio) VALUES (1,’Abrutsky’,’Maximiliano Adrián’,1,23852963,1,’Av. Colón’,’1035’,1); INSERT INTO estudiantes (id_estudiante,apellido,nombres,id_tipo_documento,documento,id_sexo,calle,calle_numero,id_ barrio) VALUES (2,’DAMIANO’,’Luis’,1,19147258,1,’Dean Funes’,’903’,1); INSERT INTO inscripciones_a_carreras (id_estudiante,id_carrera,fecha) VALUES (1,1,CAST(‘2009-01-26’ AS DATETIME));

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

12 - Implementando el modelo en MySQL 5.1

3 54

INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_estado) VALUES (1,1,1,CAST(‘2009-02-01’ AS DATETIME),1,CAST(‘2009-02-01’ AS DATETIME)); INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_estado) VALUES (2,1,1,CAST(‘2009-02-01’ AS DATETIME),1,CAST(‘2009-02-01’ AS DATETIME)); INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_estado) VALUES (3,1,1,CAST(‘2009-02-01’ AS DATETIME),1,CAST(‘2009-02-01’ AS DATETIME)); INSERT INTO alumnos_cursando_materias (id_materia,id_carrera,id_estudiante,fecha_inscripcion,id_estado,fecha_estado) VALUES (4,1,1,CAST(‘2009-02-01’ AS DATETIME),1,CAST(‘2009-02-01’ AS DATETIME));

INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (1,1,1,CAST(‘2009-02-01’ AS DATETIME),CAST(‘2009-03-15’ AS DATETIME),1,5); INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (1,1,1,CAST(‘2009-02-01’ AS DATETIME),CAST(‘2009-05-26’ AS DATETIME),2,7); INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (2,1,1,CAST(‘2009-02-01’ AS DATETIME),CAST(‘2009-03-18’ AS DATETIME),1,3); INSERT INTO alumnos_cursando_notas (id_materia,id_carrera,id_estudiante,fecha_inscripcion,fecha_nota,id_tipo_ nota,nota) VALUES (2,1,1,CAST(‘2009-02-01’ AS DATETIME),CAST(‘2009-05-29’ AS DATETIME),2,4);

12.4.2.5 Función escalar d e f n i d a por el usuario La utilidad de esta función ilustrativa llamada “obtener_Nombre_Completo()" es recibir, por parámetro, el id_estudiante y devolver el nombre completo del estudiante con el formato ‘Apellido, nombres’. Solamente la primera letra del apellido será mayúscula y todas las del/los nombre/s en minúscula. Se comenta la sentencia de creación para facilitar la comprensión. Asimismo, el funcionamiento consiste en declarar una variable, asignarle como valor la primera letra del apellido en mayúsculas, concatenándole el resto de las letras en minúsculas, una coma con espacio en blanco y, finalmente, el o los nombres, todo en minúsculas. Se concluye retornando dicha variable como resultado.

DELIMITER $$ CREATE FUNCTION obtener_Nombre_Completo(p_id_estudiante INT) – cabecera de la función (nombre y parámetros) RETURNS VARCHAR(150) – tipo de valor que retorna BEGIN DECLARE v_nombreCompleto VARCHAR(150); – defnición de variable que será retornada -- seteo de valor de la variable. UPPER y LOWER convierten a mayús. o minús. respectivamente. LEFT y RIGHT recortan la cadena retornando el lado izquiero . derecho respectivamente. CHAR_LENGTH devuelve el largo de la cadena, y CONCAT concatena las cadenas de caracteres recibidas por parámetro. SELECT CONCAT(UPPER(LEFT(apellido, 1)) , LOWER(RIGHT(apellido, CHAR_LENGTH(apellido)-1))

, ‘, ‘

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

355

, LOWER(nombres)) INTO v_nombreCompleto FROM estudiantes WHERE id_estudiante = p_id_estudiante; RETURN v_nombreCompleto; – retorno del valor END$$$$ Esta función, como cualquier otra que también sea escalar, retornará solo un valor, por lo que se pueden invocar cuando se utilizan expresiones escalares (en el SELECT, WHERE, SET, etc…). Ejemplos Invocación: SELECT id_estudiante, apellido, nombres, obtener_Nombre_Completo(id_estudiante) as NombreCompleto FROM estudiantes ; Resultado: id_estudiante

apellido

nombres

NombreCompleto

1

Abrutsky

Maximiliano Adrián

2

DAMIANO

Luis

Abrutsky, maximiliano adrián Damiano, luis

Invocación: SELECT obtener_Nombre_Completo(2) as NombreCompleto ; Resultado: NombreCompleto Damiano, luis

12.4.2.6 Procedimiento almacenado d e f n i d o por el usuario La funcionalidad de este procedimiento consistirá en que recibirá, por parámetro, un estudiante, la materia y la carrera (id_estudiante, id_materia e id_carrera) y la actualización del estado de cursada (tabla alumnos_cursando_materias) de dicha materia-carrera; por ejemplo, de inscripto a regular o libre de acuerdo con si tiene, o no, al menos dos parciales aprobados (tabla alumnos_cursando_notas). Consideraciones: •

Un alumno puede recursar una materia, por lo que se toma la última inscripción.

•

La nota de aprobación es mayor o igual a cuatro.

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

12 - Implementando el modelo en MySQL 5.1

3 56

•

Al menos debe tener dos parciales rendidos para que se actualice el estado.

•

Si se tiene al menos dos parciales aprobados, se lo considera regular.

•

Menos de dos parciales aprobados, se lo considera libre.

•

Por sencillez, no se consideran los recuperatorios en este modelo.

DELIMITER $$ CREATE PROCEDURE actualizar_estado_materia (p_id_estudiante INT, p_id_materia INT, p_id_carrera INT) BEGIN -- Declaración de variables DECLARE v_fecha_inscripcion_cursado DATETIME; DECLARE v_cant_parciales INT; DECLARE v_cant_parciales_aprobados INT; DECLARE v_cant_parciales_reprobados INT; -- Obtención de la última inscripción de la materia (podría estar recursando y solo se procesa la última inscripción) SELECT MAX(fecha_inscripcion) INTO v_fecha_inscripcion_cursado FROM

alumnos_cursando_materias

WHERE id_materia = p_id_materia AND

id_carrera = p_id_carrera

AND

id_estudiante = p_id_estudiante;

-- Si no se obtiene ninguna fecha, signifca que el alumno nunca se inscribió a la materia indicada IF v_fecha_inscripcion_cursado IS NULL THEN SELECT ‘El alumno no se ha inscripto a la materia - carrera especifcada’; ELSE -- cantidad de parciales rendidos (notas cuya descripción contengan ‘parcial’ sin importar mayúsculas y minúsculas) SELECT COUNT(*) INTO v_cant_parciales FROM alumnos_cursando_notas notas INNER JOIN materias mat ON notas.id_materia = mat.id_materia INNER JOIN tipo_notas tip ON notas.id_tipo_nota = tip.id_tipo_nota WHERE notas.id_estudiante = p_id_estudiante AND notas.id_materia = p_id_materia AND notas.id_carrera = p_id_carrera AND notas.fecha_inscripcion = v_fecha_inscripcion_cursado AND LOWER(tip.n_tipo_nota) LIKE ‘%parcial%’;

Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

12.4 Creando y probando nuestro modelo de Estudiante – Universidad

357

-- cantidad de parciales aprobados (rendidos con nota mayor o igual a 4) SELECT COUNT(*) INTO v_cant_parciales_aprobados FROM alumnos_cursando_notas notas INNER JOIN materias mat ON notas.id_materia = mat.id_materia INNER JOIN tipo_notas tip ON notas.id_tipo_nota = tip.id_tipo_nota WHERE notas.id_estudiante = p_id_estudiante AND notas.id_materia = p_id_materia AND notas.id_carrera = p_id_carrera AND notas.fecha_inscripcion = v_fecha_inscripcion_cursado AND LOWER(tip.n_tipo_nota) LIKE ‘%parcial%’ AND notas.nota >= 4; -- a modo informativo se calculan los reprobados (parcial que no se aprobó, se reprobó) SET v_cant_parciales_reprobados = v_cant_parciales - v_cant_parciales_aprobados; SELECT CONCAT(‘Cantidad de parciales rendidos = ‘, CAST(v_cant_parciales AS CHAR)); SELECT CONCAT(‘Cantidad de parciales aprobados = ‘, CAST(v_cant_parciales_aprobados AS CHAR)); SELECT CONCAT(‘Cantidad de parciales reprobados = ‘, CAST(v_cant_parciales_reprobados AS CHAR)); IF v_cant_parciales < 2 THEN SELECT ‘La cantidad rendida de parciales es menor a 2, no se cambia el estado’; ELSE IF v_cant_parciales_aprobados >= 2 THEN SELECT ‘2 parciales aprobados, REGULAR’; -- actualización al estado REGULAR UPDATE alumnos_cursando_materias SET id_estado = (SELECT id_estado FROM estados_cursados WHERE n_estado LIKE ‘Regular’) WHERE id_estudiante = p_id_estudiante AND

id_materia = p_id_materia

AND id_carrera = p_id_carrera AND fecha_inscripcion = v_fecha_inscripcion_cursado; ELSE SELECT ‘Menos de 2 parciales aprobados, LIBRE’; -- actualización al estado LIBRE UPDATE alumnos_cursando_materias SET id_estado = (SELECT id_estado FROM estados_cursados WHERE n_estado LIKE ‘Libre’) WHERE id_estudiante = p_id_estudiante

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

3 58

12 - Implementando el modelo en MySQL 5.1

AND

id_materia = p_id_materia

AND

id_carrera = p_id_carrera

AND

fecha_inscripcion = v_fecha_inscripcion_cursado;

END IF; END IF; END IF; END$$$$ Ejemplos:

Invocación: CALL actualizar_estado_materia (1,8,1) Resultado: El alumno no se ha inscripto a la materia - carrera especifcada Invocación: CALL actualizar_estado_materia (1,2,1) Resultado: Cantidad de parciales rendidos = 2 Cantidad de parciales aprobados = 1 Cantidad de parciales reprobados = 1 Menos de 2 parciales aprobados, LIBRE Invocación: CALL actualizar_estado_materia (1,1,1) Resultado: Cantidad de parciales rendidos = 2 Cantidad de parciales aprobados = 2 Cantidad de parciales reprobados = 0 2 parciales aprobados, REGULAR

12.5 Contenido de la página Web de apoyo El material marcado con asterisco (*) solo está disponible para docentes.

12.5.1 Mapa conceptual del capítulo 12.5.2 Autoevaluación 12.5.3 Presentaciones* Alfaomega

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Bibliografía Libros bertino, e.; martino, l. Sistemas de bases de datos orientadas a objetos: Conceptos y arquitecturas, Ediciones Díaz de Santos, 1995. codd, e. f. a Relational Model for Database Management: Version 2, Addison Wesley, 1990. date, c. j. Introducción a los sistemas de base de datos, Pearson Education, 2001. de miguel, a; piattini, m. Fundamentos y Modelos de Bases de Datos, México DF: Alfaomega, RA-MA, 1999. elmasri, r.; navathe, s. b. Fundamentos de sistemas de bases de datos, México DF: Addison Wesley, 2000. martin, j. Organización de las bases de datos, México DF: Prentice-Hall, 1977. silberschatz, a.; k o r t h , h.; sudarsha, s. Fundamentos de bases de datos, McGraw-Hill, 2002. stocker, p. m.; gray, p. m. d.; atkinson, m. p. Databases, role and structure: an advanced course, Cambridge University Press, 1984.

Artículos en línea codd, e. f. “A Relational Model of Data for Large Shared Data Banks” en Communications of the ACM [en línea], junio de 1970, N.º 13, [consultado diciembre de 2009]. Disponible en: http://www.cs.nott.ac.uk/~nza/G51DBS/codd.pdf codd, e. f. “Dr. E. F. Codd’s 12 rules for defning a fully relational database” [en línea], s/f, [consultado diciembre de 2009]. Disponible en: http://www.state.edu/~sgomori/570/coddsrules.html date, c. j. “Edgar F. Codd 08/23/1923 – 04/18/2003 A TRIBUTE” [en línea], 23/05/2003, [consultado enero de 2010]. Disponible en: http://www.dbdebunk.com/page/page/621965.htm lorentz, d. “Oracle Database SQL Reference, 10g Rel 2 (10.2)” [en línea], junio de 2005, [consultado enero de 2011]. Disponible en: http://www.tahiti.oracle.com lorentz, d. “SQL Reference Release 3 (8.1.7)” [en línea], septiembre de 2000, [consultado enero de 2011]. Disponible en: http://www.docs.oracle.com/html/A85397_01/title.htm marqués, m. “Bases de datos orientadas a objetos” [en línea], 12/04/2002, [consultado febrero de 2010]. Disponible en: http://www3.uji.es/~mmarques/e16/teoria/cap2.pdf oracle “Manual ofcial Oracle Concepts” [en línea], s/f, [consultado agosto de 2009]. Disponible en: http://www.adp-gmbh.ch/ora/concepts/transaction.html quiroz, j. “El modelo relacional de bases de datos” en Boletín de Política Informática [en línea], 2003, N.º 6, [consultado enero de 2010]. Disponible en: http://www.inegi.gob.mx/prod_serv/ contenidos/espanol/bvinegi/productos/integracion/pais/informatica/boletin/2003/num6.pdf yager, r.; reese, g.; king, t. “SQL According to MySQL and mSQL” [en línea], julio de 1999, [consultado enero de 2010]. Disponible en: http://www.docstore.mik.ua/orelly/linux/sql/ch06_01.htm

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega

361

Índice analítico %ROWTYPE 137 anidamiento de funciones de grupo 117 bloques anónimos 134, 135, 151 cerramiento o bloqueos 140 cláusulas de SELECT 112 COMMENT 106 CURSOR_ALREADY_OPEN EXCEPTION 150 DB2 ajustes de sintaxis en DDL 304 centro de control 299 comunidad 298 defnición de tareas de mantenimiento 302 Express-C, funcionalidades 298 modelo de datos Estudiante-Universidad DDL 306 modelo de datos Estudiante-Universidad DML 308 referencia a la documentación en línea 299 XML 298 Descarga MySQL Workbench 342 MySQL 336 SQL Server Management Studio 317 SQL Server 312 DUP_VAL_ON_INDEX EXCEPTION 150 ELSIF 141 encapsulamiento 155 exactitud del tipo de dato number 113 excepciones 136 extensión procedimental 132 FETCH 147 GROUP BY 116 HINTS 129 historia del lenguaje 104 índices 110 Instalación MySQL Workbench 342 MySQL 337 SQL Server Management Studio 317 SQL Server 312 INVALID_CURSOR EXCEPTION 150 MySQL Workbench Conexión 344 creación de base de datos 345 utilización 343 MySQL ejemplo de función escalar en lenguaje procedimental 354 ejemplo de Procedimiento almacenado en lenguaje procedimental 355 modelo de datos Estudiante-Universidad 343 modo básico instalación 339

sentencias DDL del ejemplo 347 sentencias DML del ejemplo 352 servidor lógico 338 no procedimental 105 NO_DATA_FOUND EXCEPTION 150 optimizador 112 basado en costos 127 basado en reglas 127 Oracle construcciones en PL/SQL 292 creación de usuario dueño de tablas 283 listener 280 modelo de datos Estudiante-Universidad DDL 286 modelo de datos Estudiante-Universidad DML 290 puerto de conexión 1521 280 SQL*plus 295 usuarios de administración 279 paquetes de optimización de performance 128 PL/SQL anomalías 139 cómo se administra 133 nivel de aislamiento 139 RECORD 137 rol 104 secciones de un bloque 134 SQL Server Management Studio creación de base de datos 319 explorador de objetos 317 modelo de datos Estudiante-Universidad 318 uso 317 ventana de documentos 317 SQL Server autenticación 314 ejemplo de función T-SQL 329 ejemplo de procedimiento T-SQL 331 inicialización 316 instancia 313 intercalación 315 sentencias DDL del ejemplo 322 sentencias DML del ejemplo 327 SQL anomalías 111 nivel de aislamiento 111 table 137 TOO_MANY_ROWS EXCEPTION 150 transaccional 132 TRUNCATE 106 ventaja del uso 132 ZERO_DIVIDE EXCEPTION 150

Bases de Datos - Reinosa, Maldonado, Muñoz, Damiano, Abrutsky

Alfaomega