UNIDAD I I N T R O D U C C I O N BASES DE...

Base de Datos II Docentes: Lic. Zara Yujra - Lic. Juan Vito Condori Lic. Judith Callisaya Choque

1

UNIDAD I I N T R O D U C C I O N

BASES DE DATOS

1. INTRODUCCION. Las necesidades de información en nuestra sociedad actual se dejan sentir de forma cada día más imperiosa. La información como soporte de la transferencia de conocimientos es clave para el porvenir de la humanidad e indispensable para poder modelar bien ese porvenir. Nadie puede negar en la actualidad la importancia de la información ya que esta es actualmente es considerada junto con la materia y la energía, cada uno de los componentes de la naturaleza. 2. CUALIDADES DE LA INFORMACION La explosión de la información puede conducir, sino ponemos medios para evitarlo, a una población informativa fenómeno, análoga a la contaminación del aire llegando a ser mas niem perjudicial para sus destinatarios. Para evitar esto se debe exigir a la información un conjunto de cualidades que mantenga su valor haciendo honor a su nombre, es decir informar. Las cualidades de la información son básicamente: A. Precisión; se refiere al porcentaje de información correcta sobre la información total

del sistema. No se puede pretender en los resultados una precisión superior a la que tenian los datos de entrada.

B. Oportunidad; se refiere al tiempo transcurrido desde el momento en que se produjo

el hecho que originó el dato hasta el momento en que la información se pone a disposición del usuario.

C. Integridad; indica que ha de ser completa para poder cumplir sus fines. La

integridad absoluta es actualmente imposible de conseguir. D. Significado; la información debe tener el máximo contenido semántico posible y

además debe ser interesante, significativa y fácil de entender para el usuario. E. Coherente; la información debe ser cierta o verdadera. Los resultados deben

responder a los datos de entrada y los requerimientos informativos.


2

Datos 1

Datos 2 Datos 3

Datos 6

Datos 4

Datos 5

A2

A1

A3

Proceso 1

Proceso 2

Proceso 3

Datos 1

Datos 4

Datos 5

Datos 6

Datos 2

Datos 3

3. ARCHIVOS TRADICIONALES – BASES DE DATOS Dejando los procesos en archivos tradicionales debemos pensar ya en lo que se denomina Base de Datos, la cual la representaremos del siguiente modo:

LOS PROBLEMAS DEBIDO AL USO DE ARCHIVOS TRADICIONALES: - Mucha redundancia en los datos - Costo de actualización - Gestión no llevada adecuadamente BASES DE DATOS. Al cambiarse los archivos tradicionales por Bases de Datos se tendrá la estructura siguiente.

VENTAJAS RELATIVAS A LOS DATOS CON EL USO DE UNA BASE DE DATOS - Los datos tienen independencia con respecto de los procesos y viceversa. - Mejor disponibilidad de los datos

A4

DEPURACION

ACTUALIZACION

ALMACEN DE LA BASE DE DATOS

BASE DE DATOS

RECUPERA- CION

PROCESOS


3

- Una mayor eficacia y eficiencia en cuanto a la recogida, actualización, modificación y validación de datos.

VENTAJAS RELATIVAS A LOS RESULTADOS CON EL USO DE UNA BASE DE DATOS - Mayor coherencia - Mayor seguridad - Mejor y más normalizada documentación de la información VENTAJAS RELATIVAS A LOS USUARIOS CON EL USO DE UNA BASE DE DATOS - El usuario final va ha tener toda la información de manera fácil, sin que junto a él

exista un informático. - Existe más facilidades para compartir los datos con el conjunto de usuarios. - Se verá muchas más facilidad para requerimientos cambiantes ¿CUANDO REQUERIMOS CONVERTIR DE ARCHIVOS TRADICIONA LES A BASES DE DATOS? 1. Si tengo relaciones muy complejas en mi actual Sistema de Información. 2. Mucha volatilidad en los requerimientos de información. 3. Integrar nuevos procesos y si se exige múltiples consideraciones. 4. Redundancias no controladas 5. Requerimientos de archivos con múltiples tipos de acceso a los archivos. 4. SISTEMAS DE INFORMACION Toda organización necesita para su funcionamiento un Sistema de Información sea este formal o informal; cuando la empresa es más grande estos Sistemas de Información se hacen más importantes, más difíciles, más complejos por lo que se hace necesario un sistema de información formal que integrado en el sistema superior que es el organismo, aporte a este la información eficaz y eficiente. 4.1 SISTEMA. “Conjunto de elementos que ordenadamente relacionados entre si contribuyen a un determinado objetivo” Consideraciones: - Los elementos tienen que estar relacionados entre si con un orden determinado por

unas reglas que gozan de cierta estabilidad. - El sistema típico es finalista, es decir, los elementos están relacionados para

contribuir a un determinado objetivo.


4

ENTRADA SISTEMA

SALIDA

- La noción de sistema es relativa ya que a excepción del universo, en la más alta jerarquia, cualquier sistema es siempre subsistema de otros sistema más amplio que lo englobe.

- El sistema es más que la simple suma o agregación de sus partes, porque en general su objetivo es distinto y presenta nuevas propiedades o características que no son explicables a partir de las características de los elementos considerados de forma aislada.

Todos los sistemas están natural o artificialmente limitados, llamándose todo lo que está fuera de entorno. Luego un sistema será:

ENTORNO Los sistemas se pueden dividir en dos grandes grupos: naturales y artificiales, en estos últimos que son debidos al hombre se encuentran los Sistemas de Información. La mayor parte del poder de las computadoras se centra en los sistemas de información. Ello incluye todos los usos de las computadoras en los aspectos administrativos de una organización como reservaciones en líneas aéreas , sistemas de registro de estudiantes, sistemas de facturación a pacientes hospitalizados y muchos otros. Se combinan el hardware, software y personas, procedimientos y datos para crear un sistema de información. Un sistema de información computarizado brinda a una organización capacidades de procesamiento de datos y a los trabajadores de una organización, la información que requieren para tomar mejores y más racionales decisiones. El término Sistema de Información es una referencia general a un sistema computarizado que hace estas dos cosas: a) Proporciona capacidad de procesamiento de información para una persona o para

toda una compañía. b) Proporciona la información que requieren las personas para tomar decisiones

fundamentales. Ejemplos de Sistemas de Información: Sistemas de procesamiento de datos, Sistema de información gerencial, Sistema de soporte de decisiones, sistema de información ejecutiva, Sistemas expertos y agentes de software. Entre las capacidades de un Sistema de Información se tienen: a) Entrada; la cual tiene la capacidad de: - Datos fuente


5

- Consultas - Respuesta a una indicación - Instrucción - Un mensaje para otro usuario del sistema - Cambio b) Proceso: - Clasificación - Recuperación, registro y actualización de datos almacenados - Elaboración de rexúmenes - Selección - Manipulación c) Salida: - Impresa - Temporal - Control 4.2 Definición de Sistema de Información. “Un Sistema de Información es un conjunto de elementos ordenadamente relacionados entre sí de acuerdo con ciertas reglas que apoyan al sistema objeto, es decir a la organización a la cual sirven y le marca las directrices de funcionamiento y la información necesaria para el cumplimiento de sus fines, para la cual tendrá que recoger, procesar y almacenar datos, procedentes tanto de la misma organización como de fuentes externas, facilitando la recuperación, elaboración y presentación de los mismos”. 4.3 Características - Tecnológicas; que afectan el rendimiento y seguridad del sistema, desde el punto

de vista del equipo. - Funcionales y Semánticas; que se refiere a si el sistema hace los que debe de una

manera correcta y se puede adaptar a requerimientos cambiantes. - Económicas; las cuales ponen énfasis en el costo del sistema y en la eficacia con

que responde a los objetivos. - Sociales, que son las que tienen impacto sobre el entorno social en que se

desenvuelve el sistema.


6

5. BANCO DE DATOS Y BASES DE DATOS El Banco de Datos es un simple almacén en soporte magnético de los datos relativos a un determinado tema o materia , información que puede ser exhaustiva o simplemente masiva y con las siguientes características: - Comprende datos de diversas fuentes - Integrados en una única organización - Disponibles para múltiples usuarios Se considera que un banco de datos es un sistema de información que se ofrece de forma más o menos restringida, su acceso al mercado puede ser a través de la institución que lo ha producido o bien por medio de los intermediarios. En cambio las Bases de Datos son utilizados por su creador y deben cumplir algunos requisitos en acuerdo a su diseño lógico y a la organización en soportes físicos. Un Banco de Datos está más orientados a una forma de organizar la difusión de la organización, en cambio la Base de Datos utiliza cierta tecnología de estructura de datos. “Un Sistema de Bases de Datos; en esencia, no es más que un sistema de mantenimiento de registros basado en computadoras, es decir, un sistema cuyo propósito general es registrar y mantener información”. Tal información puede estar relacionada con cualquier cosa que sea significativa para la organización donde el sistema opera. Una Base de Datos incluye cuatro componentes principales: datos, hardware, software y usuarios. 6. FORMALIZACION DE LA ESTRUCTURA La presentación de la información en el mundo de las ideas, se le llama estructura percibida o estructura conceptual de los datos, es la forma en la que percibimos la información existente en el mundo real y tratamos de plasmar en nuestro sistema de información, para esto resulta necesario formalizar una serie de conceptos. 6.1 Dato. El diccionario de la Real Academia de la Lengua Española dice que los datos

son: “Antecedentes necesarios para llegar al conocimiento exacto de una cosa o para deducir las consecuencias legítimas de un hecho”.

Es así que los datos pueden ser magnitudes numéricas, nombres o conjuntos de símbolos frases e incluso imágenes, sonido o colores. Los datos por sí mismos no nos permiten la adopción de la decisión más conveniente porque no aportan los conocimientos necesarios. Para describir los datos desde el punto de vista del programador los datos se enumeran en: a) Bit o dígito binario


7

b) Byte formado por ocho bits c) Campo; es la unidad más pequeña a la cual se puede referir en un programa.

Puede estar formado por cualquier número de bits. Entre todos los campos que forman un registro suele haber un campo clave o principal que tiene la propiedad de que su valor identifica a un único registro lógico dentro de un archivo.

d) Registro; es un conjunto de campos o de agregados de datos relacionados. e) Archivo o Fichero; Es un conjunto de registros del mismo tipo, consevado en

dispositivo de almacenamiento secundario. 6.2 Entidad; es un objeto real o abstracto que presenta interés para la empresa u

organización y acerca de cual se recoge información. 6.3 Atributos; Es un propiedad asociada a una entidad. 6.4 Ocurrencia; La ocurrencia de un atributo es el valor asignado a cada atributo de la

entidad. 6.5 Relación; Es una asociación entre dos o más entidades. Sus restricciones: De

Cardinalidad y De Participación. 7. SISTEMAS DE GESTION DE BASES DE DATOS. Un SGBD es un conjunto ordenado y coordinado de programas, procedimientos, lenguajes, etc. Que suministran tanto a usuarios informáticos como no informáticos los medios necesarios para describir, recuperar y manipular los datos almacenados en la Base de Datos asegurando sus confiabilidad y seguridad. 7.1 Operaciones de un SGBD . - En toda la Base de Datos: Crear, re - estructurar y Recuperar, Consulta General. - Registros aislados: Altas, Bajas, Modificaciones, Consulta Selectiva 7.2 Funciones del SGBD - Función Descripción. Se debe permitir escribir la Base de Datos, especificar los

elementos que las integran, su estructura, la relación existente entre los elementos, las reglas de integridad semántica, los controles a efectuar antes del acceso a la Base de Datoa, etc, así como las características de tipo físico y vistas lógicas del usuario.

- Nivel Físico: debe determinar el espacio en los volúmenes, cilindros, longitus

de elementos y pistas reservadas para la Base de Datos, además de señalar los caminos de acceso a la Base de Datos.

- Nivel Lógico: monetización del mundo real (definición de entidades, atributos,

relaciones y restricciones semánticas), autorizaciones de acceso, restricciones, etc.


8

- Función Manipulación. Permiten a los usuarios de la Base de Datos tanto

informáticos como no Informáticos añadir, buscar, suprimir o modificar los datos de la Base de Datos, siempre con las especificaciones y normas de seguridad dictadas por el administrador.

- Función Utilización. Es la que reúne las interfaces que necesitan los diferentes

usuarios para comunicarse con la Base de Datos, tiene sus programas en sus paquetes de tipos estadístico que ayudan a la organización de nivel físico de los datos.


9

UNIDAD II

LENGUAJES DE CONSULTA FORMALES

El Modelo Relacional El modelo relacional consta de tres partes:

• Estructura de datos relacional. • Reglas de Integridad referencial y de entidad. • Parte manipulativa de los datos, que consta de:

• Álgebra Relacional. • Cálculo Relacional • SQL

Ejemplo: Para un sistema de proveedores (S), Partes (P) y la relación de Envíos (SP) se tienen las siguientes tablas:

S# SNAME STATUS CITY S1 Smith 20 London S2 Jones 10 Par� S3 Blake 30 Par� S4 Clark 20 London S5 Adams 30 Athens

Tabla 1: Tabla S

P# PNAME COLOR WEIGHT CITY P1 Nut Red 12 London P2 Bolt Green 17 Par� P3 Screw Blue 17 Rome P4 Screw Red 14 London P5 Cam Blue 12 Par�

Tabla 2: Tabla P

S# P# QTY S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200


10

S4 P2 200 S4 P4 300 S4 P5 400 Tabla 3: Tabla SP

Operaciones en el Modelo de Datos Relacional Los datos pueden almacenarse utilizando un modelo de datos relacional, pero no conocemos qué podemos hacer con todas estas tablas para recuperar algo desde esa base de datos todavía. Por ejemplo, alguien podría preguntar por los nombre de todos los proveedores que vendan el artículo 'tornillo'. Hay dos formas diferentes de notaciones para expresar las operaciones entre relaciones.

• El Algebra Relacional es una notación algebraica, en la cual las consultas se expresan aplicando operadores especializados a las relaciones.

• El Cálculo Relacional es una notación lógica, donde las consultas se expresan formulando algunas restricciones lógicas que las tuplas de la respuesta deben satisfacer.

ALGEBRA RELACIONAL

Grupos de Operadores del Algebra Relacional

a. Tradicionales de Conjuntos • UNION (UNION) • INTERSECCION (INTERSECT) • DIFERENCIA (MINUS) • PRODUCTO CARTESIANO (TIMES)

b. Operadores Especiales de Relaciones • SELECCION (WHERE) • PROYECCION ([ ]) • JUNTURA (JOIN) • DIVISION (DIVIDED BY)

c. Nuevos Operadores Relacionales Adicionalmente se han definido algunas extensiones al Algebra relacional entre ellas [TORRES], se contemplan los siguientes operadores:

• DIFERENCIAL • INTEGRAL • MAXIMO • MINIMO • CUENTA • SUMA


11

Operadores Relacionales

Unión

La unión de dos relaciones A y B que deben ser compatibles con respecto a la unión es el conjunto de tuplas que pertenecen a la relación A, a la relación B o a ambas relaciones, y se designa por:

A UNION B

Compatibilidad a la Unión

Dos relaciones son compatibles a la unión si tienen el mismo número de atributos(es decir son del mismo grado), y deben existir atributos equivalentes dentro de las dos relaciones, es decir:

El atributo 1 de la relación debe estar definido en el mismo dominio del atributo 1 de la relación, el atributo 2 de la relación debe estar definido en el mismo dominio del atributo 2 de la relación, y as�ucesivamente.

Gráficamente se verá como se ilustra en la figura 1.

Figura 1: Representación gráfica de la unión de dos tablas

v.g. si tenemos la base de datos de personas solteras y casadas segun se ilustra en las tablas 4, 5 y 6.

#EMP SUELDO E25 10 E30 20


12

E15 40

Tabla 4: Tabla de Casados

EMP# SAL E70 30 E60 40 E85 90

Tabla 5: Tabla de Solteros

EMP# SAL E25 10 E30 20 E15 40 E70 30 E60 40 E85 90

Tabla 6: Tabla de Todos

CASADOS UNION SOLTEROS = TODOS

SOLTEROS UNION TODOS = TODOS

El resultado de la unión conserva los nombres de los atributos de la primer relación

Intersección

La intersección de dos relaciones A y B que deben ser compatibles a la unión es el conjunto de tuplos que pertenecen a la relación y a la relación. Gráficamente esto se verá como se ilustra en la figura 2.


13

Figura 2: Intersección de dos tablas

Con respecto a la base de datos presentada anteriormente tenemos:

CASADOS MINUS TODOS = VACIO

TODOS MINUS CASADOS = SOLTEROS

Diferencia

La diferencia de dos relaciones A y B que deben ser compatibles a la unió es el conjunto de tuplos que pertenecen a la relación y no a la relación. La representación gráfica es ilustrada en la figura 3.

Representación gráfica de la diferencia de tablas


14

Figura 3 Representación gráfica de la diferencia de tablas

Con respecto a la base de datos presentada anteriormente tenemos:

CASADOS MINUS TODOS = VACIO

TODOS MINUS CASADOS = SOLTEROS

Producto Cartesiano

El producto cartesiano de dos relaciones A y B (A TIMES B) es el conjunto de tuplos que resultan de la concatenación de un tuplo de A con un tuplo de B.

v.g. CASADOS TIMES SOLTEROS da como resultado la tabla 7

#EMP SUELDO EMP# SAL E25 10 E70 30 E25 10 E60 40 E25 10 E85 90 E30 20 E70 30 E30 20 E60 40 E30 20 E85 90 E15 40 E70 30 E15 40 E60 40 E15 40 E85 90

Tabla 7: Tabla Resultante del Producto Cartesiano


15

Lo anterior puede ser visto gráficamente según se ilustra en la figura 4

Figura 4: Representación gráfica del producto cartesiano

De este modo el producto cartesiano de una relación de grado G1 y con cardinalidad C1 por una relación de grado G2 y con cardinalidad C2 produce una relación de grado G1+G2 y con cardinalidad C1*C2.

NOTA: Para poder realizar el producto cartesiano de una relación consigo misma es necesario que definamos un ALIAS y conservar la UNICIDAD de los nombres de los atributos. v.g.

DEFINE ALIAS XS FOR R

R TIMES XS

NOTA:

De los cuatro operadores anteriores solo la diferencia no es conmutativo.

Selección

La selección de una relación es un subconjunto horizontal de una relación en este subconjunto aparecen los tuplos que cumplen alguna condición especificada, gráficamente esto se ve en la figura 5.

Figura 3.5: Representación gráfica de la selección de registros de una tabla


16

NOTA IMPORTANTE:

Las siguiente operaciones son equivalentes:

R WHERE C1 AND C2 = (R WHERE C1) INTERSECT (R WHERE C2)

R WHERE C1 OR C2 = (R WHERE C1) UNION (R WHERE C2)

R WHERE NOT C1 = R MINUS ( R WHERE C1)

Proyección

La proyección de una relación es un subconjunto vertical con la eliminación de duplicados. Esto se ilustra en la tabla 8.

* * * * * * * * * * * * * *

Tabla 8: Tabla Indicando la Proyección

La forma de definir la proyección es encerrando entre paréntesis cuadrados y separados por comas los campos que se desean proyectar:

(S TIMES P) [STATUS, P.CITY]

Join

Es equivalente a un producto cartesiano, seguido de una selección de los tuplos que tengan en los atributos ''equivalentes'' el mismo valor, y finalmente una proyección para eliminar los atributos duplicados.

Una forma de definirlo será

A JOIN B = (( A TIMES B)

WHERE A.Ci = B.Ci AND ....A.Cj = B.Cj)

[A.A 1, ...A.An,B.B1,...B.Bm]


17

El JOIN que se manejará conocido como EQUIJOIN IN NATURAL en el que la condición de la selección es por igualdad, además se han definido otros tipos de JOIN cuando la condición involucrada no es por igualdad.

Dadas las tablas 1 y 2 se obtiene lo indicado en la tabla 9

S# SNAME STATUS CITY P# PNAME COLOR WEIGHT S1 Smith 20 London P1 Nut Red 12 S1 Smith 20 London P4 Screw Red 14 S1 Smith 20 London P6 Cog Red 19 S2 Jones 10 París P2 Bolt Green 17 S2 Jones 10 París P5 Cam Blue 12 S3 Blake 30 París P2 Bolt Green 17 S3 Blake 30 París P5 Cam Blue 12 S4 Clark 20 London P1 Nut Red 12 S4 Clark 20 London P4 Screw Red 14 S4 Clark 20 London P6 Cog Red 19

Tabla 9: Tabla Resultante S JOIN P

División

La división de una relación de grado m+n entre una relación de grado n, produce una relación de grado m.

Además para poderse realizar la división se debe cumplir que el (m+i ) cómo atributo de la relación este definido en el mismo dominio que el iésimo atributo de la relación.

Los tuplos resultantes en la relación (Cociente) son aquellos atributos m tales que aparezcan combinados en A con todos los valores de B.

v.g. Si tenemos las tablas: 10, 11, 12

S# P# S1 P1 S1 P2 S1 P3 S1 P4 S1 P5 S1 P6 S2 P1 S2 P2


18

S3 P2 S4 P2 S4 P4 S4 P5

Tabla 10: Tabla X

P# P1

Tabla 11: Tabla Y

P# P2 P4

Tabla 12: Tabla Z

P# P1 P2 P3 P4 P5 P6

Tabla 13: X DIVIDED BY Y=

S# S1 S2

Tabla 14: X Divided by Z

S# S1


19

Tabla 15: X Divided by W

NOTAS:

Respecto a la división es importante tener presente que:

RESIDUO = DIVIDENDO MINUS (COCIENTE TIMES DIVISOR)

DIVIDENDO = ((COCIENTE TIMES DIVISOR) UNION RESIDUO)

Si consideramos que el dividendo consta de atributos X,Y y el dividendo consta de atributos Y, una forma de calcular la división será

COCIENTE= DIVIDENDO[X]

MINUS

((DIVIDENDO[X] TIMES DIVISOR) MINUS DIVIDENDO)[X]

Operadores básicos

De los 8 operadores vistos solo 5 de ellos son básicos puesto que los otros tres pueden ser definidos en función de los básicos. Los operadores no básicos son:

JOIN Cuya definición la fue dada.

DIVISION Cuya definición la fue dada.

INTERSECCION Que equivale a:

A MINUS (A MINUS B)

Ejercicios de álgebra relacional

Ejercicio 1

Respecto a la base de datos de partes(P), proveedores(S) y pedidos(SP), obtenga las consultas en LGEBRA RELACIONAL:

1.- Obtener los nombres de los proveedores que suministran todas las partes.

((SP[S#,P#] DIVIDEDBY P[P#]) JOIN S)[SNAME]

2.- Obtener los números de proveedor que suministran al menos una parte que sea suministrada por un proveedor que suministra alguna parte de color rojo (RED).

((((P WHERE COLOR='RED')[P#] JOIN SP)[S#] JOIN SP)[P#] JOIN SP)[S#]

3.- Obtener las parejas de Nombre de Proveedor y Nombre de Parte tales que el proveedor y la parte tengan la misma ciudad.

(S JOIN P)[SNAME,PNAME]


20

4.- Obtener los números de proveedor que suministran al menos las partes que son suministradas por 'S2'.

SP[S#,P#] DIVIDEDBY (SP WHERE S#='S2')[P#]

5.- Obtener los pedidos en los que el proveedor sea de 'LONDON' y la parte sea de 'PARIS'.

((S TIMES P TIMES SP) WHERE S.S#=SP.S# AND

P.P#=SP.P# AND

(P.CITY='PARIS' OR S.CITY='LONDON')

)[SP.S#,SP.P#,QTY]

Limitaciones del álgebra relacional

La principal limitación del álgebra relacional reside en que no es posible contestar, por lo menos en forma directa, a preguntas que involucren:

• Obtener la suma de atributos.

• Contar el número de tuplos que cumplan una condición

• Obtener los tuplos que tengan el valor mínimo respecto a algunos) atributo(s).

• Obtener los tuplos que tengan el valor máximo respecto a algunos) atributo(s).

• Obtener algún(os) atributo(s) si aparecen exactamente n veces.

• Obtener algún(os) atributo(s) si aparecen mas de n veces.

• Obtener algún(os) atributo(s) si aparecen menos de n veces.

• Obtener algún(os) atributo(s) si aparecen por lo menos n veces.

Se definirá ahora seis operadores nuevos del álgebra relacional que permiten extender su poder de recuperación

Considerando que tenemos una tabla A que consta de atributos X+Y donde X e Y pueden ser compuestos.

3.11 Operadores Torres

Mínimo (MIN)

Permite obtener un subconjunto horizontal de la tabla A de forma que los tuplos seleccionados serán aquellos que tengan el valor mínimo respecto al atributo X.

MIN(A,X) = ALIAS B FOR A

A - ((A TIMES B) WHERE A.X B.X))[A.*]


21

Nota: A.* denota todos los atributos de la tabla A.

Máximo (MAX)

Permite obtener un subconjunto horizontal de la tabla A de forma que los tuplos seleccionados serán aquellos que tengan el valor máximo respecto al atributo X.

MAX(A,X) = ALIAS B FOR A

A - ((A TIMES B) WHERE A.X B.X))[A.*]

Diferencial (DIF)

Permite obtener un subconjunto horizontal de la tabla A, de forma tal que se elimina de A un tuplo para cada valor diferente del atributo X. El tuplo que se elimina es el que tenga el menor valor respecto al atributo Y.

DIF(A,X) = ALIAS B FOR A

((A TIMES B) WHERE A.X = B.X AND A.Y B.Y)[A.*]

Notas sobre el operador diferencial

ES posible definir diferentes versiones del operador diferencial cambiando la condición que compara los atributos Y de las tablas A y B, de la misma forma que se han definido diferentes versiones del JOIN. Además combinando DIFERENCIALES de diferente grado es posible obtener resultados muy interesantes.

Diferencial enésima

DIF0(A,X) = A

DIFi(A,X) = DIF(DIFi-1(A,X),X)

OBTENER LOS TUPLOS QUE APARECEN POR LO MENOS n VECES

DIFn-1(A,X)

OBTENER LOS TUPLOS QUE APARECEN EXACTAMENTE n VECES

DIFn-1(A,X) - DIFn(A,X)

OBTENER LOS TUPLOS QUE APARECEN MENOS DE n VECES

A - DIFn-1(A,X)

Integral (INT)

Es el operador inverso del diferencial, produce una tabla que contiene un tuplo adicional para cada valor diferente de X el valor del nuevo tuplo respecto a Y ser NULO. Además se tendrá un


22

tuplo completamente NULO (tanto en X como en Y) pero esto violaría la regla de integridad de ENTIDAD.

INT(A,X) = A UNION (A[X] TIMES NULA1) UNION NULA2

Nota:

La tabla NULA1 Consta de los Y atributos todos con valor NULO.

La tabla NULA2 Consta de un tuplo de X+Y atributos todos con valor nulo.

Cuenta (CUENTA)

Permite contar el número de tuplos de una tabla.

Suma (SUMA)

Permite obtener la suma de algún campo indicado.

De los seis operadores el operador integral es el que menos se ha utilizado pero se podrá manejar quizá en aplicaciones donde se manejen valores desconocidos o se maneje incertidumbre.

Un detalle muy importante de los primeros 4 nuevos operadores es que no son básicos es decir que pueden ser definidos en función de los 5 básicos. Los mísmos dos si son básicos.

Uso de los nuevos operadores relacionales

Ejemplos

1.- Obtener los números de parte suministradas por lo menos tres veces.

DIF2(SP,P#)

2.- Obtener los nombres de partes que sean suministradas por lo menos por dos proveedores que están en 'LONDON'

DIF((((S WHERE CITY='LONDON')[S#] JOIN SP)[S#,P#],P#)[P#] JOIN P)[PNAME]

3.- Obtener los nombres de proveedores que suministran los pedidos con la menor cantidad.

(MIN(SP,QTY)[QTY] JOIN S)[SNAME]

4.- Obtener los números de proveedores que suministran por lo menos dos partes 'BLUE'.

DIF(((P WHERE COLOR='BLUE')[P#] JOIN SPJ),S#)[S#]

5.- Obtener parejas de nombres de proveedor y nombres de partes, tales que el proveedor suministre el pedido más pequeño de cada parte.

( (SP[P#,QTY] MINUS

DIF(SP[P#,QTY],P#]))


23

JOIN SP JOIN S[S#,SNAME] JOIN P[P#,PNAME])[SNAME,PNAME]

6.- Definir el operador de división utilizando el operador diferencial:

Solución

Si tenemos que la tabla dividendo es DENDO y consta de atributos X+Y y la tabla divisor es SOR y consta de atributos Y, y tanto X como Y pueden ser atributos compuestos, tenemos:

DENDO DIVIDEDBY SOR= DIFCUENTA(SOR)-1(DENDO JOIN SOR,X)

Práctica 1:

RESPECTO A LA BASE DE DATOS DE EMPLEADOS-CURSOS-INCRITOS OBTENGA LAS CONSULTAS EN ALGEBRA RELACIONAL.

1.- Los nombres de empleados que han tomado exactamente tres cursos.

2.- Los nombres de cursos que no han sido tomados por ningún empleado.

3.- Los números de empleados que no han tomado ningún curso.

4.- Los nombres de empleados que han tomado todos los cursos.

5.- Los nombres de cursos que han sido tomados por todos los empleados.

6.- Los números de empleados que han tomado por lo menos todos los cursos que han sido tomados por el empleado con número E78.

7.- Los nombres de cursos que han sido tomados por más de 3 empleados que tengan el mayor salario.

8.- Los nombres de cursos que han sido tomados por los empleados con menor salario.

Practica 2:

RESPECTO A LA BASE DE DATOS DE CONTROL ESCOLAR DE LA UNIVERSIDAD OBTENGA LAS CONSULTAS EN ALGEBRA RELACIONAL

1.- Obtener los nombres de los alumnos que han reprobado más de 10 materias.

2.- Obtener los nombres de los profesores que imparten por lo menos tres materias.

3.- Las materias que sean requisito de dos o más materias.

4.- Parejas de carreras tales que tengan en común por lo menos una materia.


24

UNIDAD III

CÁLCULO RELACIONAL El álgebra relacional y el cálculo relacional son formalismos diferentes que representan distintos estilos de expresión del manejo de datos en el ámbito del modelo relacional. El álgebra relacional proporciona una serie de operaciones que se pueden usar para decir al sistema cómo construir la relación deseada a partir de las relaciones de la base de datos. El cálculo relacional proporciona una notación para formular la definición de la relación deseada en términos de las relaciones de la base de datos. El Cálculo Relacional se basa en la lógica de primer orden. Hay dos variantes del cálculo relacional:

• El Cálculo Relacional de Dominios (DRC), donde las variables esperan componentes

(atributos) de las tuplas. • El Cálculo Relacional de Tuplas The Tuple Relational Calculus (TRC), donde las

variables esperan tuplas. Discutiremos sólo el cálculo relacional de tuplas porque es el único utilizado por la mayoría de lenguajes relacionales. En el cálculo de predicados (lógica de primer orden), un predicado es una función con argumentos que se puede evaluar a verdadero o falso. Cuando los argumentos se sustituyen por valores, la función lleva a una expresión denominada proposición, que puede ser verdadera o falsa. Por ejemplo, las frases `Carlos Baeza es un miembro de la plantilla' y `Carlos Baeza gana más que Amelia Pastor' son proposiciones, ya que se puede determinar si son verdaderas o falsas. En el primer caso, la función `es un miembro de la plantilla' tiene un argumento (Carlos Baeza) y en el segundo caso, la función `gana más que' tiene dos argumentos (Carlos Baeza y Amelia Pastor). Si un predicado tiene una variable, como en ` x es un miembro de la plantilla', esta variable debe tener un rango asociado. Cuando la variable se sustituye por alguno de los valores de su rango, la proposición puede ser cierta; para otros valores puede ser falsa. Por ejemplo, si el rango de x es el conjunto de todas las personas y reemplazamos x por Carlos Baeza, la proposición `Carlos Baeza es un miembro de la plantilla' es cierta. Pero si reemplazamos x por el nombre de una persona que no es miembro de la plantilla, la proposición es falsa. Si F es un predicado, la siguiente expresión corresponde al conjunto de todos los valores de x para los que F es cierto:

x WHERE F(x)

Los predicados se pueden conectar mediante AND, OR y NOT para formar predicados compuestos.


25

Cálculo Relacional de Tuplas En el cálculo relacional orientado a tuplas, lo que interesa es encontrar tuplas para las que se cumple cierto predicado. El cálculo orientado a tuplas se basa en el uso de variables tupla. Una variable tupla es una variable cuyo rango de valores son las tuplas de una relación. Por ejemplo, para especificar el rango de la variable tupla PX sobre la relación PLANTILLA se utiliza la siguiente expresión:

RANGE OF PX IS PLANTILLA

Para expresar la consulta òbtener todas las tuplas PX para las que F(PX) es cierto', se escribe la siguiente expresión:

PX WHERE F(PX)

donde F es lo que se denomina una fórmula bien formada (fbf). Por ejemplo, para expresar la consulta òbtener todos los datos de los empleados que ganan más de 10.000 euros' se puede escribir:

RANGE OF PX IS PLANTILLA PX WHERE PX.salario > 10000

PX.salario se refiere al valor del atributo salario para la tupla PX. Para que se muestren solamente algunos atributos, por ejemplo, apellido y salario , en lugar de todos los atributos de la relación, se escribe:

RANGE OF PX IS PLANTILLA

PX.apellido, PX.salario WHERE PX.salario > 10000

Hay dos cuantificadores que se utilizan en las fórmulas bien formadas para decir a cuántas

instancias se aplica el predicado. El cuantificador existencial ∃(èxiste') se utiliza en las fórmulas bien formadas que deben ser ciertas para al menos una instancia.

RANGE OF OX IS OFICINA ∃OX (OX.onum = PX.onum AND OX.población = `Castellón ')

Esta fórmula bien formada dice que èxiste una oficina que tiene el mismo número que el número de oficina de la tupla que ahora se encuentra en la variable de PLANTILLA , PX, y que está en Castellón'. El cuantificador universal ∀(`para todo') se utiliza en las fórmulas bien formadas que deben ser ciertas para todas las instancias.

∀PX (PX.población ≠`Castellón')


26

Esta fórmula bien formada dice que `para todas las tuplas de PLANTILLA , la población no es Castellón'. Utilizando las reglas de las operaciones lógicas, esta fórmula bien formada se puede escribir también del siguiente modo:

NOT ∃PX (PX.población =`Castellón')

que dice que `no hay ningún miembro de la plantilla cuya población sea Castellón'.

Las variables tupla que no están cuantificadas por ∃ o ∀ s e denominan variables libres. Si están cuantificadas, se denominan variables ligadas. El cálculo, al igual que cualquier lenguaje, tiene una sintaxis que permite construir expresiones válidas. Para que una expresión no sea ambigua y tenga sentido, debe seguir esta sintaxis:

• Si P es una fórmula bien formada n-ária (un predicado con n argumentos) y t1, t2 , ... tn son constantes o variables, P( t1, t2 , ... tn )entonces es también una fórmula bien formada.

• Si t1 y t2 son constantes o variables del mismo dominio y θ es un operador de comparación (<,<=,>,>=,=,≠),entonces t1 θθθθ t2 es una fórmula bien formada.

• Si P1 y P2 son fórmulas bien formadas, también lo son su conjunción P1 AND P2, su disyunción P1 OR P2 y la negación NOT P1 . Además, si P es una fórmula bien formada que tiene una variable libre X, entonces ∃X(P) y∀X(P) y también son fórmulas bien formadas.

Ejemplo :Obtener un listado de los empleados que llevan inmuebles de Almazora.

RANGE OF PX IS PLANTILLA RANGE OF IX IS INMUEBLE

PX WHERE ∃IX (IX.enum PX.enum AND IX.población = `Almazora')

Esta petición se puede escribir en términos del cálculo: `un miembro de la plantilla debe salir en el listado si existe una tupla en INMUEBLE que tenga asignado a ese empleado y que esté en Almazora ( población )'. Nótese que formulando la consulta de este modo no se indica la estrategia a seguir para ejecutarla, por lo que el SGBD tiene libertad para decidir qué operaciones hacer y en qué orden. En el álgebra relacional se hubiera formulado así: `Hacer una restricción sobre INMUEBLE para quedarse con las tuplas que tienen como población Almazora, y hacer después una concatenación con PLANTILLA . Ejemplo 4.13 Obtener las oficinas cuyos empleados (todos) nacieron de 1965 en adelante.

RANGE OF PX IS PLANTILLA RANGE OF OX IS OFICINA

OX WHERE ∀PX (PX.onum ≠ OX.onum OR PX.fecha_nac >= `1/1/65') La expresión anterior es equivalente a esta otra:

OX WHERE NOT PX (PX.onum OX.onum AND PX.fecha_nac < `1/1/65')


27

Cálculo orientado a dominios En el cálculo relacional orientado a dominios las variables toman sus valores en dominios, en lugar de tomar valores de tuplas de relaciones. Otra diferencia con el cálculo orientado a tuplas es que en el cálculo orientado a dominios hay un tipo de comparación adicional, a la que se denomina ser miembro de. Esta condición tiene la forma:

R(a 1:v 1, a 2:v 2, ...)

donde los ai son atributos de la relación R y los v i son variables dominio o constantes. La condición se evalúa a verdadero si existe alguna tupla en R que tiene los valores especificados en los atributos especificados. Por ejemplo, la siguiente condición:

PLANTILLA(puesto:`Supervisor', onum:`O3')

se evaluará a verdadero si hay algún empleado que sea supervisor en la oficina O3. Y la condición PLANTILLA(puesto:px, onum:ox)

será cierta si hay alguna tupla en PLANTILLA que tenga en puesto el valor actual de la variable dominio px y que tenga en onum el valor actual de la variable dominio ox . Ejemplo 4.14 Obtener los apellidos de los empleados que no siendo directores, tienen un salario mayor de 10.000 euros.

ax WHERE ∃px ∃sx (px ≠`Director' AND sx > 10000 AND PLANTILLA(apellido:ax, puesto:px, salario:sx))

Algebra Relacional contra Cálculo Relacional El algebra relacional y el cálculo relacional tienen el mismo poder de expresión; es decir, todas las consultas que se pueden formular utilizando algebra relacional pueden también formularse utilizando el cálculo relacional, y viceversa. Esto fue probado por E. F. Codd en 1972. Este profesor se basó en un algoritmo ("algoritmo de reducción de Codd") mediante el cual una expresión arbitraria del cálculo relacional se puede reducir a la expresión semánticamente equivalente del álgebra relacional. Se dice a veces que los lenguajes basados en el cálculo relacional son de "más alto nivel" o "más declarativos" que los basados en el álgebra relacional porque el álgebra especifica (parcialmente) el orden de las operaciones, mientras el cálculo lo traslada a un compilador o interprete que determina el orden de evaluación más eficiente.


28

UNIDAD IV

LENGUAJES DE CONSULTA COMERCIALES Introducción SQL se ha convetido en el lenguaje de query relacional más popular. El nombre "SQL" es una abreviatura de Structured Query Language (Lenguaje de query estructurado). En 1974 Donald Chamberlain y otros definieron el lenguaje SEQUEL (Structured English Query Language) en IBM Research. Este lenguaje fue implementado inicialmente en un prototipo de IBM llamado SEQUEL-XRM en 1974-75. En 1976-77 se definió una revisión de SEQUEL llamada SEQUEL/2 y el nombre se cambió a SQL en consecuencia. IBM desarrolló un nuevo prototipo llamado System R en 1977. System R implementó un amplio subconjunto de SEQUEL/2 (now SQL) y un número de cambios que se le hicieron a (now SQL) durante el proyecto. System R se instaló en un número de puestos de usuario, tanto internos a IBM como en algunos clientes seleccionados. Gracias al éxito y aceptación de System R en aquellos puestos de usuario, IBM inició el desarrollo de productos comerciales que implementaban el lenguaje SQL basado en la tecnología System R. Durante los años siguientes, IBM y bastantes otros vendedores anunciaron productos SQL tales como SQL/DS (IBM), DB2 (IBM), ORACLE (Oracle Corp.), DG/SQL (Data General Corp.), y SYBASE (Sybase Inc.). SQL es también un estandar oficial hoy. En 1982, la American National Standards Institute (ANSI) encargó a su Comité de Bases de Datos X3H2 el desarrollo de una propuesta de lenguaje relacional estandar. Esta propuesta fue ratificada en 1986 y consistía básicamente en el dialecto de IBM de SQL. En 1987, este estandar ANSI fue también aceptado por la Organización Internacional de Estandarización (ISO). Esta versión estandar original de SQL recibió informalmente el nombre de "SQL/86". En 1989, el estandar original fue extendido, y recibió el nuevo nombre, también informal, de "SQL/89". También en 1989 se desarrolló un estandar relacionado llamado Database Language Embedded SQL (ESQL). Los comités ISO y ANSI han estado trabajando durante muchos años en la definición de una versión muy expandida del estandar original, llamado informalmente SQL2 o SQL/92. Esta versión se convitió en un estandar ratificado durante 1992 - "International Standard ISO/IEC 9075:1992, Database Language SQL" -. SQL/92 es la versión a la que normalmente la gente se refiere cuando habla de "es SQL estandar".

El Modelo de Datos Relacional

Como mencionamos antes, SQL es un lenguaje relacional. Esto quiere decir que se basa en el modelo de datos relacional publicado inicialmente por E.F.Codd en 1970. Una base de datos relacional es una base de datos que se percibe por los usuarios como una colección de tablas (y nada más que tablas). Una tabla consiste en filas y columnas, cada fila representa un registro, y cada columna representa un atributo del registro contenido en la tabla. La Base de Datos de Proveedores y Artículos muestra un ejemplo de base de datos consistente en tres tablas.


29

• SUPPLIER es una tabla que recoge el número (SNO), el nombre (SNAME) y la ciudad (CITY) de un proveedor.

• PART es una tabla que almacena el número (PNO) el nombre (PNAME) y el precio (PRICE) de un artículo.

• SELLS almacena información sobre qué artículo (PNO) es vendido por qué proveedor (SNO). Esto sirve en un sentido para conectar las dos tablas entre ellas.

Ejemplo. La Base de Datos de Proveedores y Artículos SUPPLIER SNO | SNAME | CITY SELLS SN O | PNO -----+---------+-------- --- --+----- 1 | Smith | London 1 | 1 2 | Jones | Paris 1 | 2 3 | Adams | Vienna 2 | 4 4 | Blake | Rome 3 | 1 3 | 3 4 | 2 PART PNO | PNAME | PRICE 4 | 3 -----+-------------+--------- 4 | 4 1 | Tornillos | 10 2 | Tuercas | 8 3 | Cerrojos | 15 4 | Levas | 25 Las tablas PART y SUPPLIER se pueden ver como entidades y SELLS se puede ver como una relación entre un artículo particular y un proveedor particular.

El Lenguaje SQL Como en el caso de los más modernos lenguajes relacionales, SQL está basado en el cálculo relacional de tuplas. Como resultado, toda query formulada utilizando el cálculo relacional de tuplas ( o su equivalente, el álgebra relacional) se pude formular también utilizando SQL. Hay, sin embargo, capacidades que van más allá del cálculo o del álgebra relaciona. Aquí tenemos una lista de algunas carácteristicas proporcionadas por SQL que no forman parte del álgebra y del cálculo relacionales:

• Comandos para inserción, borrado o modificación de datos. • Capacidades aritméticas: En SQL es posible incluir operaciones aritméticas así como

comparaciones, por ejemplo A < B + 3. Notese que ni + ni otros operadores aritméticos aparecían en el algebra relacional ni en cálculo relacional.

• Asignación y comandos de impresión: es posible imprimir una relación construida por una query y asignar una relacion calculada a un nombre de relación.

• Funciones agregadas: Operaciones tales como promedio (average), suma (sum), máximo (max), etc. se pueden aplicar a las columnas de una relación para obtener una cantidad única.

Select El comando más usado en SQL es la instrucción SELECT, que se utiliza para recuperar datos. La sintaxis es: SELECT [ALL|DISTINCT] { * | expr_1 [AS c_alias_1] [, ... [, expr_k [AS c_alias_k]]]}


30

FROM table_name_1 [ t_alias_1] [, ... [, table_name_n [ t_alias_n]]] [WHERE condition] [GROUP BY name_of_attr_i [,... [, name_of_attr_j]] [HAVING condition]] [{UNION [ALL] | INTERSECT | EXCEPT} SELECT ...] [ORDER BY name_of_attr_i [ASC|DESC] [, ... [, name_of_attr_j [ASC|DESC]]]];

Select sencillas Aquí tenemos algunos ejemplos sencillos utilizando la instrucción SELECT: Ejemplo 2-4. Consulta sencilla con cualificación Para recuperar todas las tuplas de la tabla PART donde el atributo PRICE es mayor que 10, formularemos la siguiente Consulta: SELECT * FROM PART WHERE PRICE > 10;

y obtenemos la siguiente tabla: PNO | PNAME | PRICE -----+-------------+-------- 3 | Cerrojos | 15 4 | Levas | 25

Utilizando "*" en la instrucción SELECT solicitaremos todos los atributos de la tabla. Si queremos recuperar sólo los atributos PNAME y PRICE de la tabla PART utilizaremos la instrucción: SELECT PNAME, PRICE FROM PART WHERE PRICE > 10;

En este caso el resultado es: PNAME | PRICE ------------+-------- Cerrojos | 15 Levas | 25

Notese que la SELECT SQL corresponde a la "projección" en álgebra relaciona, no a la "selección" . Las cualificaciones en la clásula WHERE pueden también conectarse lógimente utilizando las palabras claves OR, AND, y NOT: SELECT PNAME, PRICE FROM PART WHERE PNAME = 'Cerrojos' AND (PRICE = 0 OR PRICE < 15);

dará como resultado: PNAME | PRICE ------------+-------- Cerrojos | 15


31

Las operaciones aritméticas se pueden utilizar en la lista de objetivos y en la clausula WHERE. Por ejemplo, si queremos conocer cuanto cuestan si tomamos dos piezas de un artículo, podríamos utilizar la siguiente Consulta: SELECT PNAME, PRICE * 2 AS DOUBLE FROM PART WHERE PRICE * 2 < 50;

dará como resultado: PNAME | DOUBLE ------------+--------- Tornillos | 20 Tuercas | 16 Cerrojos | 30

Notese que la palabra DOBLE tras la palabra clave AS es el nuevo título de la segunda columna. Esta técnica puede utilizarse para cada elemento de la lista objetivo para asignar un nuevo título a la columna resultante. Este nuevo título recibe el calificativo de "un alias". El alias no puede utilizarse en todo el resto de la Consulta.

Joins (Cruces) El siguiente ejemplo muestra como las joins (cruces) se realizan en SQL. Para cruzar tres tablas SUPPLIER, PART y SELLS a través de sus atributos comunes, formularemos la siguiente instrucción: SELECT S.SNAME, P.PNAME FROM SUPPLIER S, PART P, SELLS SE WHERE S.SNO = SE.SNO AND P.PNO = SE.PNO;

y obtendremos la siguiente tabla como resultado: SNAME | PNAME -------+------- Smith | Tornillos Smith | Tuercas Jones | Levas Adams | Tornillos Adams | Cerrojos Blake | Tuercas Blake | Cerrojos Blake | Levas En la clausula FROM hemos introducido un alias al nombre para cada relación porque hay atributos con nombre común (SNO y PNO) en las relaciones. Ahora podemos distinguir entre los atributos con nombre común simplificando la adicción de un prefijo al nombre del atributo con el nombre del alias seguido de un punto. Primero el producto cartesiano: SUPPLIER × PART × SELLS Ahora seleccionamos únicamente aquellas tuplas que satisfagan las condiciones dadas en la claúsula WHERE (es decir, los atributos con nombre común deben ser iguales). Finalmente eliminamos las columnas repetidas (S.SNAME, P.PNAME).

Operadores Agregados SQL proporciona operadores agregados (como son AVG, COUNT, SUM, MIN, MAX) que toman el nombre de un atributo como argumento. El valor del operador agregado se calcula sobre todos los valores de la columna


32

específicada en la tabla completa. Si se especifican grupos en la Consulta, el cálculo se hace sólo sobre los valores de cada grupo (vean la siguiente sección). Ejemplo 2-5. Aggregates Si queremos conocer el coste promedio de todos los artículos de la tabla PART, utilizaremos la siguiente Consulta: SELECT AVG(PRICE) AS AVG_PRICE FROM PART;

El resultado es: AVG_PRICE ----------- 14.5

Si queremos conocer cuantos artículos se recogen en la tabla PART, utilizaremos la instrucción: SELECT COUNT(PNO) FROM PART;

y obtendremos: COUNT ------- 4

Agregación por Grupos SQL nos permite particionar las tuplas de una tabla en grupos. En estas condiciones, los operadores agregados descritos antes pueden aplicarse a los grupos (es decir, el valor del operador agregado no se calculan sobre todos los valores de la columna especificada, sino sobre todos los valores de un grupo). El operador agregado se calcula individualmente para cada grupo). El particionamiento de las tuplas en grupos se hace utilizando las palabras clave GROUP BY seguidas de una lista de atributos que definen los grupos. Si tenemos GROUP BY A1, &tdot;, Ak habremos particionado la relación en grupos, de tal modo que dos tuplas son del mismo grupo si y sólo si tienen el mismo valor en sus atributos A1, &tdot;, Ak. Ejemplo 2-6. Agregados Si queremos conocer cuántos artículso han sido vendido por cada proveedor formularemos la Consulta: SELECT S.SNO, S.SNAME, COUNT(SE.PNO) FROM SUPPLIER S, SELLS SE WHERE S.SNO = SE.SNO GROUP BY S.SNO, S.SNAME;

y obtendremos: SNO | SNAME | COUNT -----+-------+------- 1 | Smith | 2 2 | Jones | 1 3 | Adams | 2


33

4 | Blake | 3

Demos ahora una mirada a lo que está ocurriendo aquí. Primero, la join de las tablas SUPPLIER y SELLS: S.SNO | S.SNAME | SE.PNO -------+---------+-------- 1 | Smith | 1 1 | Smith | 2 2 | Jones | 4 3 | Adams | 1 3 | Adams | 3 4 | Blake | 2 4 | Blake | 3 4 | Blake | 4

Ahora particionamos las tuplas en grupos reuniendo todas las tuplas que tiene el mismo atributo en S.SNO y S.SNAME: S.SNO | S.SNAME | SE.PNO -------+---------+-------- 1 | Smith | 1 | 2 -------------------------- 2 | Jones | 4 -------------------------- 3 | Adams | 1 | 3 -------------------------- 4 | Blake | 2 | 3 | 4

En nuestro ejemplo, obtenemos cuatro grupos y ahora podemos aplicar el operador agregado COUNT para cada grupo, obteniendo el resultado total de la Consulta dada anteriormente. Notese que para el resultado de una Consulta utilizando GROUP BY y operadores agregados para dar sentido a los atributos agrupados, debemos primero obtener la lista objetivo. Los demás atributos que no aparecen en la clausula GROUP BY se seleccionarán utilizando una función agregada. Por otro lado, usted no puede utilizar funciones agregadas en atributos que aparecen en la clausula GROUP BY.

Having La clausula HAVING trabaja muy similarmente a la clausula WHERE, y se utiliza para considerar sólo aquellos grupos que satisfagan la cualificación dada en la clausula HAVING. Las expresiones permitidas en la clausula HAVING deben involucrar funcionen agregadas. Cada expresión que utilice sólo atributos planos deberá recogerse en la clausula WHERE. Por otro lado, toda expresión que involucre funciones agregadas debe aparecer en la clausula HAVING. Ejemplo 2-7. Having Si queremos sólo los proveedores que venden más de un artículo, utilizaremos la Consulta: SELECT S.SNO, S.SNAME, COUNT(SE.PNO) FROM SUPPLIER S, SELLS SE WHERE S.SNO = SE.SNO


34

GROUP BY S.SNO, S.SNAME HAVING COUNT(SE.PNO) > 1;

y obtendremos: SNO | SNAME | COUNT -----+-------+------- 1 | Smith | 2 3 | Adams | 2 4 | Blake | 3

SubConsultas En las clausulas WHERE y HAVING se permite el uso de subqueries (subselects) en cualquier lugar donde se espere un valor. En este caso, el valor debe derivar de la evaluación previa de la subConsulta. El uso de subqueries amplía el poder expresivo de SQL. Ejemplo 2-8. Subselect Si queremos conocer los artículos que tienen mayor precio que el artículo llamado 'Tornillos', utilizaremos la Consulta: SELECT * FROM PART WHERE PRICE > (SELECT PRICE FROM PART WHERE PNAME='Tornillos');

El resultado será: PNO | PNAME | PRICE -----+-------------+-------- 3 | Cerrojos | 15 4 | Levas | 25 Cuando revisamos la Consulta anterior, podemos ver la palabra clave SELECT dos veces. La primera al principio de la Consulta - a la que nos referiremos como la SELECT externa - y la segunda en la clausula WHERE, donde empieza una Consulta anidada - nos referiremos a ella como la SELECT interna. Para cada tupla de la SELECT externa, la SELECT interna deberá ser evaluada. Tras cada evaluación, conoceremos el precio de la tupla llamada 'Tornillos', y podremos chequear si el precio de la tupla actual es mayor. Si queremos conocer todos los proveedores que no venden ningún artículo (por ejemplo, para poderlos eliminar de la base de datos), utilizaremos: SELECT * FROM SUPPLIER S WHERE NOT EXISTS (SELECT * FROM SELLS SE WHERE SE.SNO = S.SNO);

En nuestro ejemplo, obtendremos un resultado vacío, porque cada proveedor vende al menos un artículo. Notese que utilizamos S.SNO de la SELECT externa en la clausula WHERE de la SELECT interna. Como hemos descrito antes, la subConsulta se evalúa para cada tupla de la Consulta externa, es decir, el valor de S.SNO se toma siempre de la tupla actual de la SELECT externa.


35

Unión, Intersección, Excepción Estas operaciones calculan la unión, la intersección y la diferencia de la teoría de conjuntos de las tuplas derivadas de dos subqueries. Ejemplo 2-9. Union, Intersect, Except La siguiente Consulta es un ejemplo de UNION: SELECT S.SNO, S.SNAME, S.CITY FROM SUPPLIER S WHERE S.SNAME = 'Jones' UNION SELECT S.SNO, S.SNAME, S.CITY FROM SUPPLIER S WHERE S.SNAME = 'Adams';

Dará el resultado: SNO | SNAME | CITY -----+-------+-------- 2 | Jones | Paris 3 | Adams | Vienna

Aquí tenemos un ejemplo para INTERSECT: SELECT S.SNO, S.SNAME, S.CITY FROM SUPPLIER S WHERE S.SNO > 1 INTERSECT SELECT S.SNO, S.SNAME, S.CITY FROM SUPPLIER S WHERE S.SNO > 2;

que dará como resultado: SNO | SNAME | CITY -----+-------+-------- 2 | Jones | Paris La única tupla devuelta por ambas partes d e la Consulta es la única que tiene $SNO=2$.

Finalmente, un ejemplo de EXCEPT: SELECT S.SNO, S.SNAME, S.CITY FROM SUPPLIER S WHERE S.SNO > 1 EXCEPT SELECT S.SNO, S.SNAME, S.CITY FROM SUPPLIER S WHERE S.SNO > 3;

que dará como resultado: SNO | SNAME | CITY -----+-------+-------- 2 | Jones | Paris 3 | Adams | Vienna


36

Definición de Datos Hay incluidos en el lenguaje SQL un conjunto de comandos utilizados para definición de datos.

Create Table El comando fundamental para definir datos es el que crea una nueva relación (una nueva tabla). La sintaxis del comando CREATE TABLE es: CREATE TABLE table_name ( name_of_attr_1 type_of_attr_1 [, name_of_attr_2 type_of_attr_2 [, ...]]);

Ejemplo 2-10. Creación de una tabla Para crear las tablas definidas en La Base de Datos de Proveedores y Artículos se utilizaron las siguientes instrucciónes de SQL: CREATE TABLE SUPPLIER (SNO INTEGER, SNAME VARCHAR(20), CITY VARCHAR(20)); CREATE TABLE PART (PNO INTEGER, PNAME VARCHAR(20), PRICE DECIMAL(4 , 2)); CREATE TABLE SELLS (SNO INTEGER, PNO INTEGER);

Tipos de Datos en SQL A continuación sigue una lista de algunos tipos de datos soportados por SQL:

• INTEGER: entero binario con signo de palabra completa (31 bits de precisión). • SMALLINT: entero binario con signo de media palabra (15 bits de precisión). • DECIMAL (p[,q]): número decimal con signo de p dígitos de precisión, asumiendo q a la

derecha para el punto decimal. (15 ≥ p ≥ qq ≥ 0). Si q se omite, se asume que vale 0. • FLOAT: numérico con signo de dobre palabra y coma flotante. • CHAR(n): cadena de caracteres de longitud fija, de longitud n. • VARCHAR(n): cadena de caracteres de longitud variable, de longitud máxima n.

Create Index Se utilizan los índices para acelerar el acceso a una relación. Si una relación R tiene un índice en el atributo A podremos recuperar todas la tuplas t que tienen t(A) = a en un tiempo aproximadamente proporcional al número de tales tuplas t más que en un tiempo proporcional al tamaño de R. Para crear un índice en SQL se utiliza el comando CREATE INDEX. La sintaxis es: CREATE INDEX index_name ON table_name ( name_of_attribute );


37

Ejemplo 2-11. Create Index Para crear un índice llamado I sobre el atributo SNAME de la relación SUPPLIER, utilizaremos la siguiente instrucción: CREATE INDEX I ON SUPPLIER (SNAME);

El indice creado se mantiene automáticamente. es decir, cada vez que una nueva tupla se inserte en la relación SUPPLIER, se adaptará el índice I. Notese que el único cambio que un usuario puede percibir cuando se crea un índice es un incremento en la velocidad.

Create View Se puede ver una vista como una tabla virtual, es decir, una tabla que no existe físicamente en la base de datos, pero aparece al usuario como si existiese. Por contraste, cuando hablamos de una tabla base, hay realmente una contraparte físicamente almacenada para cada fila en la tabla en algún sitio del almacenamiento físico. Las vistas no tiene datos almacenados propios, distinguibles y físicamente almacenados. En su lugar, el sistema almacena la definición de la vista (es decir, las reglas para acceder a las tablas base físicamente almacenadas para materializar la vista) en algún lugar de los catálogos del sistema. Para una discusión de las diferentes técnicas para implementar vistas, refierase a SIM98. En SQL se utiliza el comando CREATE VIEW para definir una vista. La sintaxis es: CREATE VIEW view_name AS select_stmt

donde select_stmt es una instrucción select válida, como se definió en Select. Notese que select_stmt no se ejecuta cuando se crea la vista. Simplemente es almacenada en los catalogos del sistema y se ejecuta cada vez que se realiza una Consulta contra la vista. Sea la siguiente definicón de una vista, utilizamos de nuevo las tablas de la BD Ejemplo: CREATE VIEW London_Suppliers AS SELECT S.SNAME, P.PNAME FROM SUPPLIER S, PART P, SELLS SE WHERE S.SNO = SE.SNO AND P.PNO = SE.PNO AND S.CITY = 'London';

Ahora podemos utilizar esta relación virtual London_Suppliers como si se tratase de otra tabla base: SELECT * FROM London_Suppliers WHERE P.PNAME = 'Tornillos';

Lo cual nos devolverá la siguiente tabla: SNAME | PNAME -------+---------- Smith | Tornillos Para calcular este resultado, el sistema de base de datos ha realizado previamente un acceso oculto a las tablas de la base SUPPLIER, SELLS y PART. Hace esto ejecutando la Consulta dada en la definición de la vista contra aquellas tablas base. Tras eso, las qualificaciones adicionales (dadas en la Consulta contra la vista) se podrán aplicar para obtener la tabla resultante.


38

Drop Table, Drop Index, Drop View Se utiliza el comando DROP TABLE para eliminar una tabla (incluyendo todas las tuplas almacenadas en ella): DROP TABLE table_name;

Para eliminar la tabla SUPPLIER, utilizaremos la instrucción: DROP TABLE SUPPLIER; Se utiliza el comando DROP INDEX para eliminar un índice: DROP INDEX index_name; Finalmente, eliminaremos una vista dada utilizando el comando DROP VIEW: DROP VIEW view_name;

Manipulación de Datos

Insert Into Una vez que se crea una tabla puede ser llenada con tuplas utilizando el comando INSERT INTO. La sintaxis es: INSERT INTO table_name ( name_of_attr_1 [, name_of_attr_2 [,...]]) VALUES ( val_attr_1 [, val_attr_2 [, ...]]); Para insertar la primera tupla en la relación utilizamos la siguiente instrucción: INSERT INTO SUPPLIER (SNO, SNAME, CITY) VALUES (1, 'Smith', 'London');

Para insertar la primera tupla en la relación SELLS, utilizamos: INSERT INTO SELLS (SNO, PNO) VALUES (1, 1);

Update Para cambiar uno o más valores de atributos de tuplas en una relación, se utiliza el comando UPDATE. La sintaxis es: UPDATE table_name SET name_of_attr_1 = value_1 [, ... [, name_of_attr_k = value_k]] WHERE condition; Para cambiar el valor del atributo PRICE en el artículo 'Tornillos' de la relación PART, utilizamos: UPDATE PART SET PRICE = 15 WHERE PNAME = 'Tornillos';

El nuevo valor del atributo PRICE de la tupla cuyo nombre es 'Tornillos' es ahora 15.

Delete Para borrar una tupla de una tabla particular, utilizamos el comando DELETE FROM. La sintaxis es: DELETE FROM table_name


39

WHERE condition; Para borrar el proveedor llamado 'Smith' de la tabla SUPPLIER, utilizamos la siguiente instrucción: DELETE FROM SUPPLIER WHERE SNAME = 'Smith';


40

UNIDAD V

SEGURIDAD E INTEGRIDAD Seguridad e Integridad son dos conceptos que se utilizan frecuentemente en el contexto de las Bases de Datos. Seguridad se refiere a la protección de los datos contra una revelación, alteración o destrucción no autorizada; integridad se refiere a la exactitud o validez de los datos. Seguridad implica asegurar que los usuarios están autorizados para llevar a cabo lo que tratan de hacer. Integridad implica asegurar que lo que tratan de hacer es correcto. SEGURIDAD La unidad de información para propósitos de seguridad puede ser desde una Base de Datos o conjunto de tablas completos hasta un valor específico en una posición específica de fila y columna dentro de una tabla específica. Un usuario dado tendrá por lo regular diferentes derechos de acceso o autorizaciones sobre diferentes objetos de información. Por ejemplo para que un usuario pueda hacer un select , otro para hacer select y update, etc. El esquema de seguridad en SQL se basa en tres conceptos principales: • Los usuarios , cada vez que el DBMS recupera, inserta, suprime y actualiza datos lo hace a

cuenta de algún usuario. • Los objetos de la base de datos, son los elementos a los cuales se aplica la protección de

seguridad SQL. • Los privilegios son las acciones que un usuario tiene permitido efectuar para un determinado

objeto de la BD. Un usario diferente puede tener un conjunto diferente de privilegios. En el caso del SQL, el sistema tiene dos características más o menos independientes para el mantenimiento de la seguridad:

• El mecanismo de las vistas, que puede servir para ocultar ciertos datos confidenciales a ciertos usuarios no autorizados

• El subsistema de autorización mediante el cual los usuarios con derechos específicos pueden conceder de manera selectiva y dinámica esos derechos a otros usuarios, y desùés revocar esos derechos.

Vistas y Seguridad Una vista es una tabla virtual en la Base de Datos cuyo contenido está definido por una consulta. Las vistas son parte importante en SQL por varios razones:

• Las vistas permiten acomodar el aspecto de una BD de modo que diferentes usuarios la vean desde desde diferentes perspectivas.

• Las vistas permiten restringir acceso a los datos, permitiendo que usuarios sólo vean ciertas filas o ciertas columnas de una tabla.


41

• Las vistas simplifican el acceso a la BD mediante la presentación de la estructura de los datos almacenados de modo que sea más natural para cada usuario.

Ventajas de las vistas • Seguridad • Simplicidad de consulta • Simplicidad estructurada • Aislamiento frente al cambio • Integridad de datos Desventajas de las vistas • Rendimiento • Restricciones de actualización Creación de Vistas La sentencia CREATE VIEW se utiliza para crear una vista. Para crear la vista es necesiario tener permiso para acceder a todas las tablas referenciadas en la consulta. CREATE VIEW Nombre-de-vista --------------------------------------- AS Consulta ---� (Nombre de columna) Pueden existir : • Vistas Horizontales • Vistas verticales • Vistas agrupadas • Vistas compuestas Actualización de Vistas Bajo el estándar SQL una vista puede ser actualizada si la consulta que la define satisface todas estas restricciones:

• No debe especificar DISTINCT • La cláusual FROM debe especificar solamente una tabla actualizable • Cada elemento de selección debe ser referencia a una columna simple • La clásula WHERE no debe incluir subconsultas. • La consulta no debe incluir una cláusula GROUP BY O HAVING Si la vista satisface estas condiciones, es posible definir operaciones INSERT, DELETE Y UPDATE. Ejemplo 1: Para usuarios que solo se les permite tener acceso a los registros completos de proveedores que son de La Paz: CREATE VIEW ProveedoresLaPaz AS select codP, NomP, ciudadP


42

From Proveedores Where ciudad=’La Paz’ Ejemplo 2: Para los usuarios que solo pueden tener acceso a los datos de los artículos pero no a sus precios unitarios CREATE VIEW ArticulosD AS select codA, NomA, Color From Proveedores Ejemplo 3: Para usuarios a los cuales se le permiten tener acceso a las cantidades promedio enviadas por los proveedores, pero no cantidades individuales CREATE VIEW CP(codP, CantProm) AS select codP, AVG(cant) From suministros Group by CodP Indentificadores de usuario Cada usuario de una Base de Datos basada en SQL tiene asignado un id-usuario, un nombre breve que identifica al usuario dentro del del software DBMS. El id-usuario se encuentra en el núcleo de la seguridad SQL. Toda sentencia SQL ejecutada por DBMS se lleva a cuenta de un id-usuario específico. El id_usuario determina si la sentencia va ser permitida o prohibida por el DBMS. En una BD de producción los id_usuarios son asignados por el administrador. Grupos de usuarios Consesión de Privilegios () La sentencia GRANT se utiliza para conceder privilegios de seguridad sobre objetos de la BD a usuarios específicos La sentencia REVOKE se utiliza para quitar los privilegios de seguridad sobre objetos de la BD a usuarios específicos EJEMPLOS:

GRANT SELECT ON TABLES PROVEEDORES TO PUBLIC;

GRANT ALL ON TABLE INSCRIPCION, ALUMNOS TO LETY, MEDARDO, VICTOR;

GRANT UPDATE, DELETE ON TABLE CALIFICACIONES

TO GOYO;

REVOKE UPDATE, DELETE

ON TABLE CALIFICACIONES FROM INTRUSO;

REVOKE ALL ON TABLE CALIFICACIONES FROM GERARDO;

También es posible que a un usuario se le conceda el permiso de conceder permisos de acceso. EJEMPLOS:

GRANT SELECT ON TABLE ALUMNOS TO PEDRO


43

WITH GRANT OPTION;

Del mismo modo se le puede revocar el permiso de conceder permiso:

REVOKE SELECT ON TABLES FROM PEDRO;

Otros Aspectos De Seguridad Es importante tener en mente que un SMBD no proporciona toda la seguridad requerida, por lo cual es necesario establecer mecanismos de control adicionales. Uno de estos mecanismos es la realización de auditorías periódicas del contenido de la base de datos. Un mecanismo que incluso ya se soporta en diversos SMBD es el encriptado, de forma tal que un usuario a pesar de lograr el acceso formal a los archivos de una base de datos no pueda leerlos si no posee la clave de encriptado/decriptado dependiendo del esquema de encriptado seguido.

INTEGRIDAD El término de Integridad de datos se refiere a la corrección y completitud de los datos en una Base de Datos. Cuando los contenidos de una BD se modifican con sentencias INSERT, DELETE o UPDATE la integridad de los datos almacenados puede perderse de muchas maneras diferentes. • Pueden añadirse datos no válidos a la BD, tales como una inscripcion a una materia no

existente. • Pueden modificarse datos existentes, tomando un valor incorrecto, por ejemplo cuando se

modifica la nota final (rango) • Los cambios a la BD pueden perderse debido a un error del sistema o un fallo eléctrico

(transacciones ) • Los cambios pueden ser aplicados parcialmente, como por ejemplo si inscribe a un alumno a

una materia sin verficar y actualizar el cupo del curso. Existen varios casos diferentes de restricciones de integrida de datos que suelen encontrarse en las BDRelacionales como: • Datos requeridos (datos válidos para algunas columnas, no NULL Ej: Nombre, no Materno) • Chequeo de valides (dominio Ej. Rangos de números) • Integridad de entidad (clave primaria, único y distinto de NULL) • Integridad Referencial (DBMS, Disparadores, SP) • Reglas comerciales (De la Institución Ej. Cupos, prerequisitos, pago de cuotas) • Consistencia (operaciones de manera transaccional Ej.inscripcion: insert alumnos, insert

inscripcion, update cupos) Nota.


44

Cuando se realiza un Insert se crea una pseudotabla denominada inserted con la misma estructura de la tabla afectada. Cuando se realiza un DELETE se crea una pseudotabla denominada deleted con la misma estructura de la tabla afectada. Cuando se realiza un UPDATE se crean ambas tablas (inserted y deleted) Qué es un Disparador o Trigger? Para cualquier evento que provoca un cambio en el contenido de una tabla se puede especificar una acción asociada que el DBMS debería efectuar automáticamente. Los eventos que pueden disparar una acción son el INSERT, UPDATE Y DELETE. La acción disparada por un evento se especifica mediante una secuencia de sentencias SQL, propias del lenguaje SQL del DBMS (Ej. T-SQL, i-SQL, PL-SQL) Ejemplo: Cuando se añade un nuevo registro a la tabla Inscripción Internamente se suceden dos eventos: 1. La insercion de un registro en Inscripcion 2. Actualización de número de inscritos (asignación) Nota. Cuando se realiza un Insert se crea una pseudotabla denominada inserted con la misma estructura de la tabla afectada. Cuando se realiza un DELETE se crea una pseudotabla denominada deleted con la misma estructura de la tabla afectada. Cuando se realiza un UPDATE se crean ambas tablas (inserted y deleted) Estructura General de un Disparador: CREATE TRIGGER Nombre_del_Disparador ON NombreTabla FOR [INSERT][UPDATE][DELETED] AS Sentencias SQL Ejemplo: Diseñar un Trigger que permita verificar las plazas y actualizar automaticamente el valor del campo numero_inscritos en caso de una inscripcion. CREATE TRIGGER ActualizarPlazas ON Inscripcion FOR INSERT AS DECLARE @I SMALLINT, @N SMALLINT SELECT @N=a.plazas


45

FROM asignacion a, inserted t1 Where a.sigla_mat = t1.sigla_mat and a.paralelo = t1.paralelo and a.gestion = t1.gestion SELECT @I=a.num_inscritos FROM asignacion a, inserted t1 Where a.sigla_mat = t1.sigla_mat and a.paralelo = t1.paralelo and a.gestion = t1.gestion IF ( @I < @N ) begin UPDATE Asignacion SET num_inscritos = num_inscritos+1 where Asignacion.sigla_mat in (select sigla_mat from inserted) and Asignacion.paralelo in (select paralelo from inserted) and Asignacion.gestion in (select gestion from inserted) PRINT 'Registro satisfactorio' end ELSE begin PRINT 'NO HAY CUPO EN ESTE CURSO' ROLLBACK end Disparadores e integridad referencial Los disparadores proporcionan un modo alternativo de implementar las restricciones de integridad referencial proporcionadas por claves foráneas y claves primarias. De hecho, el mecanismo disparador es más flexible que la integridad referencial estricta proporcionado por el estándar ANSI/ISO. Ejemplo: Realizar un Trigger verifique la existencia de un alumno cuando se inscribe CREATE TRIGGER AlumnoExistente ON Inscripcion FOR INSERT AS IF NOT EXISTS (Select * FROM ALUMNOS a, inserted t1 WHERE a.Cod_al=t1.Cod_al) Begin PRINT 'Alumno No Existente' ROLLBACK End ELSE PRINT 'Alumno correctamente inscrito'


46

El futuro de los disparadores

La principal ventaja de los disparadores es que las reglas comerciales pueden almacenarse en las BD y ser forzadas consistentemente con cada actualización en la BD. Esto puede reducir sustancialmente la complejidad de los programas de aplicación (rutinas de front end, SP, etc) que accedan a la BD. Los disparadores tienen algunas desventajas: Complejidad de la BD: Cuando las reglas se trasladan al interior de la BD, preparar la BD pasa a ser una tarea más compleja (Ej. Para cada tabla un triggers) Reglas ocultas: Con las reglas ocultas en la BD programas que parecen efectuar sencillas actualizaciones, pueden de hecho, generar una cantidad enorme de actividad en la BD.


47

UNIDAD VI

BASE DE DATOS ORIENTADAS A OBJETOS (OODBMS)

Introducción A los nuevos servicios de las empresas, le corresponden nuevas funciones de aplicación. Esas modificaciones de aplicación deben poder hacerse rápido, sin tener que reescribir todo. Corría la segunda mitad de la década de los 80’, cuando comienzan a generalizarse en múltiples aplicaciones los sistemas de gestión de bases de datos orientadas al objeto (OODBMS), los cuales toman las ventajas del enfoque orientado al objeto, ya probados y los sistemas de gestión de bases de datos, siendo su principal virtud el ofrecer un muy buen desempeño en la gestión de datos complejos y multimediales. Desde el punto de vista del desarrollador las ventajas están dadas en ganancias de productividad, dado su modelamiento más simple que facilita el desarrollo de aplicaciones. El modelamiento de aplicaciones es mucho más sencillo gracias al concepto de objetos complejos y el modelo obtenido es fácilmente comprensible para el usuario. Este modelo puede ser validado directamente por el cliente de la aplicación. El enfoque Orientado al Objeto favorece la reutilización, porque gracias a la encapsulación y la herencia, es fácil especializar un componente existente para responder a las necesidades particulares de la aplicación. Desde el punto de vista del usuario final de los OODBMS, el mayor aporte es la calidad en términos de ergonomía, fiabilidad, evolución y desempeño. La mayor parte de los productos disponibles en el mercado, son productos cerrados, difícilmente adaptables a las especificaciones de la empresa: la ergonomía de la aplicación es fija, las reglas de cálculo son difícilmente modificables, etc. la tecnología objeto, gracias en particular a la encapsulación y la herencia, da productos desarrollos con un OODBMS más abierto y fácilmente adaptables. El usuario puede obtener un costo menor de las modificaciones de sus procedimientos, que van a integrar más fácilmente su medio ambiente (entorno).

Un poco de historia

La primera aparición del concepto data de 1984 con la proposición de David Maier y George Copeland de construir un DBMS desde Smalltalk, Copeland et al. (1984). Se pueden citar dos grandes proyectos desde 1985, el proyecto ORION de MCC en Austín, Texas y en 1986 el proyecto Altair, en Rocquencowt, Francia. En 1988, la primera generación apareció, seguida por una segunda generación en 1990. Después de esta intensa actividad, pareciera necesario definir de una manera precisa el concepto de OODBMS (Sistemas de Gestión de Bases de Datos Orientadas al Objeto). En efecto, contrariamente al caso de los sistemas relacionales que primero fueron definidos formalmente en el artículo original de Codd, después se generaron prototipos y finalmente transformados en producto, no hubo un principio de especificación precisa de lo que debía ser un OODBMS. En 1989, el paper "The Object-Oriented Database System Manifesto" aunque con un enfoque demasiado limitado en temas de administración, Stonebraker et al. (1990), propone una definición compuesta de tres tipos de reglas que deben respetar un OODBMS:

• Reglas Obligatorias: Las cuales el sistema debe imperativamente seguir para merecer la calidad de OODBMS.

• Reglas Facultativas: Lineamientos suplementarios del sistema, pero que no son indispensables. • Reglas Abiertas: Propiedades alternativas del sistema que puede ejercer.


48

El conjunto de reglas es rápidamente admitido por la comunidad científica y comercial como un consenso mínimo. A principios de la década de los 90’, la comercialización efectiva de sistemas progresó rápidamente y fueron desarrolladas varias aplicaciones. En 1992, los principales distribuidores se juntan para definir un estándar que asegure la portabilidad de las aplicaciones de un sistema a otro, y en Octubre de 1993 es publicado el estándar del ODMG (Grupo de Administración de Bases de Datos Orientadas al Objeto), Catell et al. (1993). Se cuenta con una tecnología madura y adaptada al mercado, una oferta rica y diversificada, una demanda para este tipo de producto y un estándar realista (ODMG-93 es un estándar para bases de datos al objeto puras, en contraste con el estándar SQL3 nacido para bases de datos relaciones extendidas basadas en objetos, siendo ésta compatible con el modelo relacional clásico). EL ESTÁNDAR ODMG-93: UN ESTÁNDAR PARA BASES DE DATO S ORIENTADAS AL OBJETO PURAS Es el resultado de trabajos que duraron 18 meses por los 5 principales distribuidores de OODBMS. Su objetivo fue asegurar la portabilidad de las aplicaciones de un sistema a otro. En este objetivo son definidas tres interfaz: 1) ODL (Lenguaje de Definición de Objetos) El lenguaje de definición del objeto permite definir el modelo de datos. Es compatible con IDL, el lenguaje del OMG (Grupo de Administración de Objetos). Permite la definición de objetos complejos, de relación entre esos objetos y de métodos asociados a dichos objetos. 2) OQL (Lenguaje de Consulta al Objeto) El lenguaje de requerimientos permite consultar los objetos de estructuras complejas, de enviar mensajes a objetos, efectuar join y otras operaciones de tipo asociativo. Su sintaxis es del tipo SQL. 3) Conexión vía C++ y Smalltalk. Esta interfaz ("bindings", enlazamientos), especifica como se debe hacer la programación en C++ o Smalltalk de una aplicación sobre una base de datos que ha sido declarada en ODL. La conexión es basada sobre la noción de "puntero inteligente" que permite manejar los objetos persistentes como objetos ordinarios vía punteros persistentes. DEFINIENDO LAS OODBMS Un OODBMS ofrece todas la funcionalidad de un sistema de gestión de bases de datos, al igual que todas las de un sistema objeto. Conceptos DBMS La tecnología de gestión de bases de datos (DBMS), nació a fines de los años 60. Las tecnologías de implementación de esos sistemas han evolucionado, su arquitectura ha emigrado hacia una arquitectura Cliente/Servidor, pero los servicios ofrecidos (En particular a su nivel físico) son los mismos. La figura 1 muestra un DBMS tradicional considerando sus aspectos más característicos. Un DBMS ofrece facilidades de almacenamiento, de acceso, manipulación y de compartimento de grandes volúmenes de datos. Esos datos pueden ser muy abultados, ellos no están ni en memoria principal ni en memoria virtual. Es el DBMS quien asegura la gestión de diferentes niveles de jerarquía de memoria, el programador no hace la diferencia entre un dato en memoria y un dato en disco. La gestión del disco asegurada por el DBMS debe ser transparente y ofrece buenos desempeños. Ella debe ofrecer mecanismos tales como gestión oculta de indexación, reagrupamiento de objetos sobre los discos (debe proveer una forma adecuada de reagrupar los objetos de un nivel físico, a un nivel superior ), etc.


49

Figura 2: Composición de un Objeto.

La parte estática del objeto puede reagrupar informaciones alfanuméricas, gráficas, textuales, sonoras, etc. Ella puede ser atómica (los objetos atómicos son del tipo de base del sistema: enteros, reales, caracteres, strings, booleanos) o compleja (constituida a partir de otros objetos, atómicos o complejos). La parte dinámica del objeto puede estar constituida de funciones de archivos, cálculos, de búsqueda de información, etc. Contrariamente a lo que existe en la programación clásica, las operaciones son subordinadas a los objetos; el objeto no es solamente caracterizado por lo que es, sino también por lo que hace, ocultando la estructura interna de un objeto y la implementación de las operaciones. Cada objeto tiene una identidad propia (ver figura 3), independiente de su valor. Podemos actualizar el valor de un objeto sin alterar su identidad. El sistema maneja su identidad, atribuyendo a cada objeto un identificador que asegura unicidad.

Figura 3: La identidad objeto.

La noción de identidad de objeto guarda relación con la composición del objeto, diferenciándose de otros objetos. Conceptos como la herencia permiten definir una clase (la clase define una estructura y un comportamiento común, a varios objetos) de objetos a partir de una clase ya existente (herencia simple) o de varias otras clases (herencia múltiple). La clase creada recupera no solamente su estructura sino además sus métodos de su(s) clase(s) padre(s). La herencia trae una descripción compacta bien estructurada del esquema de aplicación. Es una técnica de clasificación de objetos que evita la duplicación de código facilitando la reutilización de propiedades de estructuras y comportamientos ya definidas.


50

Los objetos se comunican entre ellos por envío de mensajes, lo que se quiere decir, es que transmiten órdenes a otros objetos. Cuando se recibe un mensaje por un objeto, éste lo ejecuta. Él puede crear nuevos objetos y enviar nuevos mensajes. Los métodos asociados a clases diferentes, pueden tener el mismo nombre: la elección del método que sea efectivamente llamado es aplazada hasta el momento de la ejecución (enlazamiento dinámico), dependiendo de la persistencia de la clase del objeto del cual el método es llamado en tiempo de ejecución. Ese mecanismo de enlace dinámico aumenta la independencia entre los métodos y los objetos y permite sumar nuevas clases sin modificar ni recompilar los programas existentes, Por ejemplo, la aplicación de gestión de pago maneja diferentes tipos de contratos, cada uno con su método de cálculo de sueldo, basta con crear una nueva subclase de la clase "contrato" con un método de cálculo de sueldo correspondiente a ese algoritmo. Esos nuevos contratos son entonces inmediatamente tomados en cuenta por los programas existentes, sin modificación particular del código. La herencia y el enlazamiento dinámico permiten alivianar los programas y el trabajo del programador (por efecto de la reutilización) cuando se activan los módulos de la aplicación. Se hace notar que el modelamiento de objetos se puede realizar bajo una forma gráfica, pudiendo tener ciclos. CONCEPTOS ESPECIFICOS DE OODBMS La noción de objetos complejos optimiza la representación de las estructuras complejas y acortando la distancia que separa el modelamiento de un escenario del mundo real y su implementación. Los objetos complejos permiten así, un modelamiento más intuitivo de datos de una aplicación, su presentación en la base de datos está mas cerca de la realidad. La estructura compleja de los objetos es manejada por punteros lógicos. Esos punteros reemplazan la utilización de uniones relacionales, e inducen así una ganancia de desempeño, particularmente cuando la cantidad de datos es importante. La siguiente figura muestra un esquema típico de una OODBMS:

Figura 4: Una OODBMS tradicional, Manola (1994).


51

El concepto de identidad de objeto, tiene repercusiones particularmente interesantes en el contexto de un DBMS. La distribución de objetos permite limitar la tabla de la base de datos. Permite una mejor gestión de actualización, y es más rápida, ya que tiene menos objetos que modificar. Ofrece igualmente una gestión automática de integridad referencial (desaparición de referencias a objetos destruidos), problema crucial de las bases de datos. Con las generaciones previas de DBMS, los desarrolladores tuvieron un nivel bajo de productividad. Esto es en particular dado por un problema de funcionalidad entre aquellas DBMS y los lenguajes de programación utilizados. En efecto, los tipos de datos de esas categorías de herramientas son incompatibles, el programador debe asegurarse por si mismo de la conversión de datos entre la base de datos y el lenguaje: Esto impone el desarrollo suplementario que hay que realizar para mantener la consistencia de la aplicación en su ejecución. La falta de coincidencia entre lenguajes orientados a tablas, tales como SQL, y los lenguajes comunes, significa que se necesita un lenguaje separador para la manipulación de datos (DML), existiendo impedimentos de acoplar estilos declarativos y basados en procedimientos entre los tipos de sistemas del lenguaje de aplicación y de bases de datos, dando lugar a una perdida de información en la interfaz, y obstaculizando la comprobación automática de tipos. Para solucionar este problema los OODBMS ofrecen el concepto de completitud; que es la percepción de escribir completamente una aplicación utilizando el DBMS como un único lenguaje (tal como los lenguajes estándar según la norma ODMG; C++, Smalltalk o Java), sin tener que recurrir a los recursos de los lenguajes externos. Este concepto suprime el problema de funcionalidad, ya que los datos son manipulados de la misma manera en la base de datos que por el lenguaje de programación. En efecto, es el mismo modelo de datos, que es soportado por el lenguaje objeto de desarrollo de la aplicación y por el OODBMS. Los OODBMS ofrecen todo un lenguaje de programación completo integrando los accesos a las bases de datos. CARACTERÍSTICAS DE LAS ODBMS Un completo modelo de bases de datos, con rasgos tales como; la manipulación fija y el acceso de asociación. Un modelo orientado al objeto que respalda objetos complejos, identidad del objeto, encapsulamiento, clases, caracteres, extensibilidad e integridad computacional. Un DDL (Data Definition languaje, define tipos de objetos, y además el usuario puede declarar procedimientos y variables asociadas con los tipos de objetos) real con rasgos de manipulación de esquemas. La capacidad de almacenar y manipular tanto los datos (objetos) como los metadatos (clases y métodos) en el propio sistemas. Un DML (Data Manipulation Languaje, por lo general contiene un lenguaje de consultas y un componente de lenguaje de programación ), a través de un lenguaje de consulta completo, declarativo. Independencia de datos lógica y física (esto es, un DDL físico y uno lógico y la capacidad para modificar el esquema físico sin cambiar la aplicación). La capacidad de manipular cantidades de datos enormes. La capacidad de desarrollar aplicaciones completas en un medio único. LOS DESEMPEÑOS El problema de los desempeños es esencial para los DBMS. El mercado de sistemas orientados al objeto se desarrolla porque esos sistemas ofrecen desempeños mejorados con respecto a los sistemas relacionales. Existen tres tipos de benchmarking ("pruebas de rendimiento") que permiten medir estos sistemas.

• Bechmarking 001, Rubenstein et al. (1987), Catell et al. (1992), está orientado a aplicaciones que tienen por objetivo describir la aplicación en cuanto a su tipo de concepción (refiriéndose a su forma de generación, formación). Manipula los objetos complejos entre el servidor y una estación de trabajo.


52

• Bechmarking de Hypermodel, fue hecho por un grupo de navegadores de conceptos en sistemas. Se basa sobre la aplicación del tipo hipertexto y mide el tiempo de acceso a los objetos.

• Bechmarking 007, Carey et al. (1993), hecho en 1992 para las limitaciones del Bechmarking 001, abarcando un gran número de operaciones, transacciones, requerimientos y el control de versiones. El 007 denota tres diferentes tamaños:

• Pequeño: La base de datos en memoria principal. • Mediano: La base de datos está contenida en memoria virtual y una parte en la memoria principal. • Grande: La base de datos está en memoria virtual.

¡Error!Nombre de archivo no especificado. Figura 5: Comparación Arquitectura OODBMS vs RDBMS, Manola (1994, pág. 3,19).

Los OODBMS dominan en desempeño con respecto a los sistemas relacionales sobre las aplicaciones manipulando objetos complejos. Esto es por una sencilla razón; que los sistemas relacionales fueron hechos y diseñados para efectuar algunas operaciones simples (selección, proyección, etc.), y los OODBMS tienen por finalidad manipular objetos estructurados y complejos. En cuanto a una comparación arquitectónica entre el modelo relacional y el modelo objeto aplicado a DBMS, la figura 5 muestra su correspondiente composición habitual. LOS APORTES A LA TECNOLOGIA Los OODBMS permiten llegar a nuevos dominios para los cuales las bases de datos tradicionales son renuentes a ser aceptadas. Su fuerte es en ambientes donde hay una necesidad de datos no estándar, es decir, de aquellos que uno manipula textos estructurados o no estructurados, imágenes, gráficos, sonidos, videos, documentos o programas. Se trata entonces de ambientes donde la estructura de los datos es tan compleja que representarla en un modelo tradicional es ineficaz. Se trata de dominios o tipos de datos que al usarlos no permanecen fijos desde el inicio y son variables en el tiempo. Son dominios comunes, por ejemplo:

• CAD • Gestión de datos técnicos • Cartografía • Multimedia. • Sistemas distribuidos y cliente/servidor. • Bases de datos multimedia. • Correo por voz. • GIS

En todos estos dominios, la tecnología de OODBMS aporta los desempeños mejores y un desarrollo más eficaz de aplicaciones.

Los OODBMS disminuyen los costos lógicos de desarrollo.

Esta baja de costos es obtenida en opinión de connotadas figuras ligadas a DBMS (Por citar algunos: Atkinson et al., Bancilhon, Graham), por un acortamiento del ciclo de análisis, concepción, codificación, depuración, testeo, mantención y evolución. Mejoramiento obtenido por:

• La reutilización del componente lógico. • La disminución de código. • La capacidad de modelamiento directo de información compleja. • La mejor integración a los lenguajes de programación. • Desarrollo rápido de prototipos de aplicaciones. • Utilización de medio ambiente gráfico de desarrollo.


53

• Utilización de herramientas de generación de interfaz gráfica de realización.

Los OODBMS permiten producir aplicaciones gráficas de mejor calidad.

Las aplicaciones son mejoradas en dos puntos esenciales: • Los desempeños en el caso de la manipulación de datos complejos. • La calidad "industrial" de aplicaciones para la facilidad de mantención, su capacidad de

crecimiento y posibilidad de ser personalizadas en dominios específicos.

Los OODBMS permiten recuperar y mejorar las aplicaciones existentes.

Para los sistemas que disponen de una interfaz C++ estándar, el mecanismo consiste en tomar una aplicación existente en la cual la persistencia es asegurada por un sistema de archivos que al migrarlos al OODBMS se reemplaza el acceso a los archivos por el almacenamiento en el OODBMS. Así, el costo de migración es mínimo y la aplicación es bastante mejorada. En efecto, resultando en:

• Una simplificación de código (el acceso a los objetos de la base de datos es inmediata y sin traducción).

• La capacidad de fiabilidad y compatibilidad de los datos.

Los Mercados

1. Aplicación en Sistemas de información geográficos. Para los sistemas de información geográficos o para toda aplicación en la cual hay una dimensión espacial o geográfica (la cartografía de una región, la topología de una zona o el plano de un edificio), los desarrolladores de estas aplicaciones necesitan la tecnología de objetos; ella ofrece un mayor desarrollo y mejores desempeños. 2. Gestión de datos técnicos. Porque permiten almacenar los datos de naturaleza variada y de tipo extensible, los OODBMS son elegibles como sistemas de almacenamiento para este tipo de aplicaciones, que incluyen la gestión de datos científicos experimentales, la gestión de datos asistidos por computador (CAD) y la documentación técnica. 3. Aplicaciones Multimedia. Para toda aplicación que manipula gráficos, imágenes, animación y voz, los OODBMS son los primeros en la elección de los desarrolladores. Orientado a objetos. Una idea superficial del concepto Orientado a Objetos consiste en una organización del software como un conjunto de objetos que contienen tanto información en estructuras de datos como su comportamiento. La información que tienen se organiza en atributos y el comportamiento en operaciones.

Para comprender mejor el concepto se van a examinar las cuatro principales características:

Identidad, Clasificación, Polimorfismo y Herencia.

Identidad. Identidad quiere decir que los datos están organizados en entidades discretas y distinguibles llamadas objetos. Cada objeto ha de poder distinguirse por un puntero, un índice en un array, un valor de un atributo,...

• Dos objetos que tengan la misma información no son indistinguibles, la identidad los distingue. C++: La implementación de la identidad se realiza a través del puntero al objeto (this). Ejemplo:

int * p; p=new int; ... {int a=*p; delete p; p=new int; *p=a;} // Código vacío ... El código que aparece en el ejemplo, ¿puede tener alguna influencia en la funcionalidad del programa?


54

Clasificación. Los objetos con la misma estructura de datos (atributos) y el mismo comportamiento (Operaciones) se aglutinan para formar una clase. Una clase es una abstracción que describe las propiedades de los objetos.

Una clase define un conjunto de objetos individuales. Se dice que cada objeto es una instancia de una

clase. Los objetos de la misma clase, aparte de la identidad, solo se diferencian en el valor de los atributos,

comparten los nombres de los atributos, así como las operaciones.

Nada impide que un objeto pertenezca a más de una clase. Ejemplo: Clase Circulo Atributos Centro Radio Operaciones Superficie Mover CambiarTamaño

Clase Gráfico Atributos Posición Color Operaciones Dibujar Mover

• Como sería un objeto de ambas clases? • Qué pasa con la operación mover? Polimorfismo. Significa que una misma operación puede comportarse manera diferente en diferentes clases. Con esto estamos diciendo que es el propio objeto el que sabe como tiene que comportarte ante una determinada operación. Podemos tener la clase fichero y la clase PiezaAjedrez, ambas pueden tener la operación mover pero cada una hará tarea diferente, según lo que se espera de ella. La implementación concreta de una operación para una clase se llama método. Gracias al polimorfismo se puede invocar a un método sin conocer exactamente el objeto sobre el que se invoca. Si suponemos que tenemos un conjunto de objetos y de entre ellos se selecciona uno, pero no sabemos cual, si todos esos objetos tienen el método mover, puedo invocar dicha operación y ,según el objeto que sea, invocará al método adecuado. Herencia. Herencia es compartir atributos y operaciones entre clases utilizando una estrategia jerárquica. Tanto los atributos como las operaciones que se toman de otra clase se pueden redefinir. En términos generales se puede definir una clase que después se puede ir refinando en sucesivas subclases. Cuando se dice que una clase A hereda de otra clase B, A tendrá todos los atributos y operaciones de B, además podrá tener otros atributos y operaciones propias. Puede ocurrir que la clase A tenga operaciones o atributos que se llamen igual que la clase B, este tipo de refinamiento de las clases consiste en redefinir las acciones o atributos de la clase padre. Realmente no se puede decir que en este caso se sustituyan, los atributos y operaciones de B están en A, pero dependiendo del gestor de objetos, éstos pueden quedar ocultos o inaccesibles. Una clase puede heredar de varias clases, cuando esto ocurre tendrá todos los atributos y operaciones de todas las clases que hereda. Puede ocurrir que dos clases tengan atributos u operaciones con el mismo nombre, si una clase heredara de ambas habría ambigüedad, cuando me refiera a una operación, cada gestor de objetos particular puede deshacer la ambigüedad de diferente manera. Cuando un objeto es de una clase, y ésta hereda de otras clases, ese objeto es de todas las clases que hereda su clase. Otras características. Las características que se tratan en este punto no específicas de la orientación a objetos, pero si son muy importantes.


55

Abstracción. La abstracción consiste en centrarse en los aspectos esenciales de una entidad e ignorar sus propiedades accidentales. La abstracción en la orientación a objetos se produce a través de dos maneras: • Clasificación: Permite englobar a muchas entidades particulares dando una idea general y abstracta de

todas ellas. • Herencia + Polimorfismo: Permite crear una clase original muy general para que en sucesivos

refinamientos se creen otras subclases más concretas. Con la primera clase nos hemos abstraído de lo común e importante de todas las subclases y con el polimorfismo podemos mantener o refinar las operaciones iniciales.

Encapsulamiento. La encapsulación consiste en separar los aspectos externos del objeto, a los cuales pueden acceder otros objetos, de los detalles internos de la implementación del mismo, que quedan ocultos para los demás. Esto permite modificar la implementación de un objeto, sabiendo seguro que no influye en el resto de la aplicación, lo que hay que hacer es modificar solo la parte oculta, respetando la externa. Combinación datos y comportamiento. Con un enfoque convencional por procedimientos, cuando tenemos un conjunto de estructuras de datos, éstos vienen asociados con otro conjunto similar pero de procedimientos que permiten su manejo. Con este enfoque se están duplicando los elementos por que hay dos conjuntos. Se más adecuado crear un solo conjunto donde los elementos del mismo sean pares de estructura de datos / procedimiento. Ejemplo: Gestor de bases de datos de información geográfica (GIS):

• Tratamiento convencional: Se definen propiedades para zonas geográficas. Se definen como varían esas propiedades en el tiempo.

• Combinando datos y comportamiento. Se definen un elemento propiedad junto con la forma en que varía en el tiempo. Se aplica ese elemento sobre zonas geográficas.

Compartir. Una de las principales características de las técnicas orientadas a objetos es la capacidad que tienen para poder compartir, esto se realiza en dos niveles:

• A través de la herencia se utiliza código de manera natural y con el polimorfismo se puede particularizar para cada clase.

• La reutilización de código se realiza de manera inmediata. Gracias al encapsulamiento se puede utilizar código sin tener en cuenta su implementación.

Objetos / Procedimientos. Un diseño basado en objetos es más estable que un diseño basado en procedimientos, a lo largo de un proyecto pueden cambiar algunos procedimientos o acciones, sin embargo los objetos que forman parten del mismo rara vez cambian. Ejemplo: Se quiere diseñar un software para analizar la vuelta a España. Habrá objetos ciclistas, etapas, equipos,... Si se quiere realizar el diseño del Tour de Francia, puede que haya que cambiar valores de atributos e implementación de métodos, pero seguirán los mismos objetos. Sinergia. Cuando los resultados de combinar una serie de elementos son mayores de lo que se espera de esos elementos vistos individualmente, se dice que se produce sinergia entre ellos. Esto ocurre con la identidad, clasificación, polimorfismo y herencia, al utilizarlas en conjunto forman un estilo diferente de programación (orientado a objetos).


56

Orientación por objetos La orientación por objetos es un nuevo enfoque para el desarrollo de sistemas programados, que permite la representación del dominio de una aplicación en forma natural y directa, en términos de los objetos que intervienen en dicha aplicación. Este enfoque atañe también a las BD. La figura 1 muestra una descomposición de los objetos vs. la descomposición funcional y jerárquica. La representación de tales objetos se hace en forma abstracta definiendo su estructura y su comportamiento.

Figura 1. Descomposición funcional y de objetos. Los conceptos de la orientación por objetos se remontan a los años 60 con la aparición del lenguaje de simulación llamado Simula’67, donde los objetos existen por sí mismos conteniendo sus datos y sus operaciones, y además se comunican entre sí por medio de mensajes. También fue en este lenguaje donde se introdujo la noción de clase de objetos, que describen la estructura y el comportamiento de todos los objetos que pertenecen a la clase, la noción de herencia entre las clases siguiendo una jerarquía de las mismas, y por último, la noción de dos tipos de igualdad: la igualdad en valores (shallow equality) y la identidad (deep equality). Los lenguajes de programación que aparecieron después y que siguieron estas premisas, fueron Smalltalk, Eiffel, Trellis/Owl, Java, etc. La extensión de lenguajes existentes arrojaron nuevas versiones de: C en C++, Objective C y Borland C, LISP en Flavors, Object LISP y CLOS, y Pascal en TurboPascal6 y CLASCAL, entre otros. Los tópicos tratados en esta sección son los siguientes:

Un lenguaje de modelado unificado UML Los métodos estructurados y funcionales aparecieron primero, inspirados directamente de la arquitectura de los computadores. Los métodos OO comienzan a emerger a inicios de los años 80, ellos se articulan alrededor de las nociones de clases y asociaciones (James Rumbaugh), de divisiones en subsistemas (Grady Booch) y de la expresión de los requerimientos a partir del estudio de la interacción entre usuarios y sistemas (los casos de uso de Ivar Jacobson). A finales de 1994, Rumbaugh y Booch deciden unificar sus trabajos en un método único, el método unificado. El año siguiente se une al grupo Jacobson y fijan cuatro objetivos de trabajo:

1. Representar sistemas enteros siguiendo la OO 2. Establecer una conexión explícita entre los conceptos y los elementos ejecutables 3. Tomar en cuenta los factores inherentes a los sistemas complejos y críticos


57

4. Crear un lenguaje de modelado que pueda ser usado por humanos y por máquinas Así, en octubre de 1995 aparece el método unificado V0.8, luego en junio 1996, la versión 0.9 y por último, este método se transforma el 17 de enero de 1997 en un lenguaje universal para el modelado de objetos denominado UML 1.0 (The Unified Modeling Language for Object-Oriented Development).

Conceptos básicos de la OO y su representación en UML Los conceptos de la orientación por objetos se basan en la manipulación de representaciones abstractas de los objetos plasmadas en su definición y su comportamiento. Un objeto se define entonces como la representación de algo que se describe mediante una estructura y un comportamiento. La estructura de un objeto describe aquellas características de interés presentes en el objeto y que sirven para plasmar el estado de ese objeto, siendo el estado de un objeto el conjunto de valores actuales almacenados en su estructura, que está escondida. El comportamiento del objeto está representado por una serie de operaciones, funciones o métodos que modifican ó no el estado del objeto, haciendo que ocurra un cambio de estado en el mismo, el cual representa el comportamiento visible del objeto en la realidad. Así, el comportamiento del objeto está dado por sus cambios de estado. La figura 2 presenta la notación UML para los objetos (un rectángulo con el nombre del objeto subrayado), los enlaces que pueden existir entre ellos (una línea continua que conecta dos objetos) y la invocación de sus operaciones por medio del pase de mensajes (una flecha indicando la dirección y el nombre del mensaje), en base al contenido de algunos de sus atributos. Un objeto puede ser conocido y descrito por medio de sus propiedades o atributos que son ilimitados. Un mensaje es el soporte de una relación de comunicación que relaciona en forma dinámica los objetos separados por el proceso de descomposición. Los atributos se representan en UML con sub-rectángulos conteniendo un valor subrayado, dentro del rectángulo del objeto. Una nota, representada con un rectángulo con la esquina doblada, indica una clarificación o descripción, en formato libre, para facilitar la comprensión del diagrama. Una nota está ligada a los objetos por medio de una línea discontinua para indicar a que objeto pertenece la nota. Un objeto puede componerse de dos o más objetos, conformando así un objeto compuesto. Cada objeto tiene un único identificador que es asignado por el sistema, para aquellos sistemas que soportan la identidad del objeto. Los atributos son las propiedades relevantes de un objeto que representa su estructura. Ellos pueden ser simples o monovaluados, en el caso que ellos contengan un único valor a la vez, y multivaluados cuando pueden contener varios valores a la vez. La existencia de un objeto es independiente de los valores de sus atributos, así dos objetos son idénticos si ellos son el mismo objeto, es decir sus identificadores son iguales (deep equality), o ellos son iguales si tienen los mismos valores en sus atributos (shallow equality). En un sistema o lenguaje que no soporta identidad del objeto, la representación gráfica de los objetos es un árbol. En los sistemas que si la soportan es un grafo, ya que los objetos compuestos pueden compartir componentes. Una operación es una función asociada al objeto que efectua una acción atómica sobre el mismo. Tal acción puede ó no modificar el estado del objeto.


58

Figura 2. Objetos con enlaces, operaciones y pase de mensajes.

Tipos abstractos de datos y su especificación Un tipo abstracto de dato (TAD) se basa en la separación clara entre su implantación y el uso del TAD a través de su interfase, que es la cara visible del TAD. Ello implica que un TAD tiene una interfaz y puede tener varias implantaciones. La definición de un TAD se hace en dos partes: la especificación y la implementación. Una especificación formal es la acción de determinar o explicar en términos formales o matemáticos la cosa deseada, en este caso un tipo de dato que es necesario para la resolución del problema. Este tipo de dato T se define "como una clase de valores y una colección de operaciones sobre esos valores. Si las propiedades de esas operaciones son especificadas solamente con axiomas, entonces T es un tipo abstracto de dato o una abstracción de dato" [Gutt-78,p.1049]. Una implantación correcta del TAD cumple con todos los axiomas especificados para él. La especificación por axiomas algebraicos para el tipo T se compone de: una especificación sintáctica donde se definen los nombres, dominios y rangos de las operaciones sobre T; y una especificación semántica que está compuesta del conjunto de axiomas en forma de ecuaciones, que dicen como opera cada una de las operaciones especificadas sobre las otras. La implementación se compone de: una representación que especifica como los valores del TAD serán almacenados en la memoria, es decir su estructura de datos, y los algoritmos que especifican como será usada y manipulada la estructura de datos, es decir las operaciones del TAD.


59

El acceso al TAD es hecho a través de su interfaz que es visible para los usuarios de ella. La implementación del TAD es invisible para el usuario y es visible para el que desarrolla el TAD. Como un ejemplo de esto se presenta aquí la especificación del tipo abstracto de dato: Pila. Tal especificación será hecha para una pila no limitada. Tipo de dato: Pila[elemento:tipoEle] Especificación sintáctica: creaPila() -> Pila, Crea la pila meterElePila(Pila,tipoEle) -> Pila, Inserta un nuevo elemento en el tope sacarElePila(Pila) -> Pila, Elimina el elemento que está en el tope conTopePila(Pila) -> tipoEle \/ {TipoEleNoDef}, Consulta el elemento que está en el tope vacíaPila(Pila) -> Lógico, Verifica si la pila está vacía destruyePila(Pila) -> . Destruye la pila Especificación semántica: Declaración: P: Pila, el: tipoEle; sacarElePila(creaPila()) = creaPila() conTopePila(creaPila()) = {TipoEleNoDef} conTopePila(meterElePila(P,el)) = el vacíaPila(creaPila()) = Verdadero vacíaPila(meterElePila(P,el)) = Falso Con la especificación sintáctica se pueden ver claramente cuáles son las operaciones primitivas válidas sobre la estructura y cuáles son los tipos de datos que cada una regresa, luego que se ha efectuado la operación. Para mayor claridad, véase la operación sacarElePila() que necesita para operar la Pila, devolviendo la misma Pila pero disminuida en tamaño por un elemento, ya que e lla suprime el elemento que está colocado en el tope de la Pila. En esta especificación se incluyen unicamente aquellas operaciones que son básicas para el TAD, es decir las operaciones que sirven de base para construir cualquier otra operación sobre el tipo. Por ejemplo, en la mayoría de las estructuras de datos es útil tener una operación que vacíe o limpie la estructura, en el caso de la Pila, sería la operación vaciarPila(Pila)->Pila. Dicha operación no aparece en la especificación del TAD Pila, pues ella puede ser construida invocando varias veces la operación sacarElePila(Pila) hasta que vacíaPila(Pila) sea verdadero. Por lo tanto, las operaciones que aparecen en una implementación cualquiera de un TAD no tienen por que ser iguales, en número, a las de la especificación del mismo. Con la especificación semántica se observa el efecto que tiene cada una de las operaciones especificadas sobre las otras. Por ejemplo: ¿Qué sucede si se desea saber si la Pila está vacía, habiéndose recien creado?, esto es vacíaPila(creaPila()), el resultado es Verdadero, ya que aunque la pila existe, ella ha sido recientemente creada y por ello, está vacía. En el caso de conTopePila(creaPila()), el resultado es un valor especial denominado TipoEleNoDef, esto es tipoElemento no definido, para expresar que no puede regresarse elemento alguno, pues la pila está vacía. Este valor especial para el debe estar definido en la implementación del tipo abstracto de dato. Para llevar a la práctica esta especificación debe escogerse una representación física para el tipo Pila, ella puede ser una de las siguientes: la secuencial, donde los elementos de la Pila están contigüos en memoria; o el enlazado, donde esos elementos están esparcidos en la memoria y encadenados mediante punteros al siguiente. Ambas implantaciones, las hechas con las representaciones mencionadas, deben tomar en cuenta que la memoria es finita, y por ello tal especificación es lo que es, una especificación para un tipo abstracto de dato. Ella diferirá en algunos detalles de la implementación realizada basándose en ella.

Mecanismos de la abstracción de datos La clasificación es la agrupación de objetos con propiedades y comportamiento similares dentro de una clase. Una clase es un objeto que define la estructura y el comportamiento de un conjunto de objetos que tienen el mismo patrón estructural y de comportamiento. Cada objeto que pertenece a una clase es una


60

instancia de ella. En UML, cada clase se representa con un rectángulo dividido en tres compartimentos. El primero indica el nombre de la clase, que debe permitir la comprensión de lo que es la clase y NO lo que ella hace. El segundo contiene los atributos expresados con su nombre, su tipo y un valor inicial por omisión, en caso de ser necesario, y el tercero indica sus operaciones expresadas con el nombre de la operación, sus argumentos entre paréntesis, expresados como nombre del argumento, su tipo y su valor por omisión, si es necesario; y por último el tipo de resultado que devuelve la operación. Cada uno de los atributos y operaciones va antecedido por un caracter que indica el tipo de acceso o la visibilidad de dicho parámetro en la clase. Estos son: (+) para los públicos, (#) para los protegidos, (-) para los privados, (7) para los atributos calculados por alguna operación definida en la clase, y el parámetro subrayado para los de la clase, lo que hace que existan atributos y operaciones de la clase y no de las instancias de la clase. La figura 3 presenta la estructura de una clase y un ejemplo.

El conjunto de todas las instancias de una clase es la extensión de la clase. La instanciación es el proceso de generación o creación de las instancias de una clase. La definición de una clase normalmente contiene: su nombre, el nombre de sus superclases (clases de las que se hereda), su interfaz, su estructura y su implementación. En UML, la interfaz de una clase se representa con un círculo pequeño enlazado a la clase y sirve para describir el comportamiento visible de la clase. La interfaz también puede representarse con una clase que lleve debajo de su nombre el estereotipo <<interfaz>>. Las clases parametrizables son modelos de clases que se corresponden con clases genéricas como los templates de C++. Ellas se representan en UML con la misma representación de una clase, pero lleva en la esquina superior derecha del rectángulo, otro rectángulo más pequeño en líneas entrecortadas. La instanciación de esta clase con el tipo deseado se materializa con una flecha de línea entrecortada orientada hacia la clase parametrizable. La figura 4 muestra ambas representaciones. Existen también en UML las clases utilitarias, ellas sirven para indicar aquellas clases de librería o funciones agrupadas en librerías, por ejemplo las clases en C++ que contienen solamente miembros estáticos. Se indican con <<utilitaria>>. Las clases abstractas no pueden ser instanciadas, ya que ellas no crean objetos sino que sirven de especificación general. Ellas se indican con la palabra abstracta en itálicas.

Figura 4. Clases parametrizables y utilitarias en UML. Las clases formarán una jerarquía denominada jerarquía de clases, donde las clases superiores a una clase particular se denominan superclases y a la clase particular se le llama subclase. La relación entre una superclase y una subclase se denomina ES-UN(A). La metaclase es la clase que define todas las clases del sistema. La figura 5 presenta un ejemplo de una jerarquía de clases en notación gráfica UML. Cada rectángulo representa una clase de objetos. Sus divisiones indican: primero, el nombre de la clase; a continuación, la estructura de las instancias de la clase; y por último, las operaciones o métodos que tabajan sobre las instancias de la misma. La metaclase se indica con <<metaclase>>.


61

Figura 5. Jerarquía de clases en UML.

La generalización es un proceso de abstracción en el cual un conjunto de clases existentes, que tienen atributos y operaciones comunes es referido por una clase genérica a un nivel mayor de abstracción. La generalización corresponde a la relación ES-UN(A) entre las clases. En la figura 5 pudo haber habido una generalización, si las clases Empleado y Estudiante fueron realizadas antes y una vez que se tuvieron, se decidió crear una nueva clase genérica denominada Persona, para contener los atributos y operaciones comunes a las clases ya implementadas, ya que tanto Estudiante como Empleado son Personas. La especialización o particularización es el proceso inverso de la generalización, ya que una subclase se crea a partir de una clase ya existente. Este es el proceso que soportan la mayoría de los sistemas orientados por objetos. La figura 5 muestra un ejemplo de ello, si se crea la clase Preparador como subclase de Estudiante y de Empleado. Una clase puede tener varias superclases, denominándose una generalización o especialización múltiple. La figura 6 muestra esta situación para una alfombra voladora. La generalización o la especialización pueden ser realizadas según uno o varios criterios, los cuales se indican en UML con una palabra discriminante en la línea de la abstracción y si es una restricción como: incompleta, exclusiva o inclusiva, ella puede indicarse entre paréntesis, como lo muestra la figura 6. Las asociaciones representan relaciones estructurales entre las clases, ellas se representan en UML con una línea. Las asociaciones pueden ser binarias, terciarias o de mayor aridad. Las asociaciones n-arias generalmente se representan promoviendo la asociación al rango de clase y agregando una restricción que expresa que las múltiples ramas se instancian todas simultáneamente, como se muestra en la figura 7. Las asociaciones pueden llevar un nombre, en itálicas y que normalmente se expresa en forma activa, i.e. trabaja para, o en forma pasiva, i.e. es empleado por. En ambos casos se puede indicar el sentido de lectura con < ó >. Así también, se pueden expresar los roles al extremo de las asociaciones y la multiplicidad de las mismas expresadas como: 1: sólo uno; 0..1: cero o uno; 0..*: de cero a muchos; 1..*: de uno a muchos. Ellas también pueden llevar restricciones entre paréntesis: {ordenado}, {subconjunto}, {exclusivo}, etc. como lo muestra la figura 8. También pueden existir subasociaciones o asociación


62

reflexiva, de una clase con ella misma; y puede calificarse las asociaciones para seleccionar un subconjunto de objetos que participan en la asociación por medio de una clave, simple o compuesta, que pertenece a la asociación y no a la clase. Estas situaciones se muestran en la figura 9.

Figura 6. Generalización exclusiva, inclusiva e incompleta en UML.

Figura 7. Asociación ternaria en UML.

Figura 8. Roles de asociación en UML.


63

Figura 9. Restricciones y claves de asociación en UML.

La agregación permite definir clases según los criterios siguientes:

• Una clase forma parte de otra • Los valores de los atributos de una clase se propagan en los valores de los atributos de otra • Una acción sobre una clase implica una acción sobre otra • Los objetos de una clase están subordinados a los objetos de otra

La figura 10 presenta un ejemplo de agregación. La composición es un caso particular de la agregación, ella se utiliza para indicar clases de objetos compuestos, ya que coloca atributos en la clase que pertenecen a otra clase. Ella representa la relación ES-PARTE-DE entre una entidad compuesta y sus entidades componentes. Ambas representan una relación no simétrica en la que una de las extremidades juega un rol predominante en relación a la otra, por lo cual sólo lleva un rol. La figura 10 muestra el diagrama UML de una clase de objetos compuestos.

Figura 10. Agregación y composicón en UML.

El protocolo o interfaz es el conjunto de operaciones o métodos declarados como posibles de invocar o activar por los otros objetos. Los mensajes son la especificación de un objeto junto con la invocación de uno de sus métodos. Por lo general, el pase de mensajes tiene la forma

objetoDestino.nombreDelMétodo(listaDeArgumentos) La encapsulación es la propiedad que permite que los objetos sean definidos en su estructura y su comportamiento, obligando al uso del pase de mensajes o de la invocación de sus métodos, si se quiere acceder al objeto. La herencia es la propiedad que tienen las clases de heredar de sus superclases estructura y/o comportamiento. La herencia estructural es aquella donde se hereda la estructura y la herencia de comportamiento cuando se heredan los métodos. La herencia se puede tipificar como: simple o múltiple. La herencia simple se da cuando la subclase hereda solamente de una superclase, y es múltiple cuando hereda de varias superclases. La herencia múltiple presenta problemas de ambigüedad cuando hay


64

atributos o métodos con el mismo nombre en varias de las superclases. La solución a dicho problema es la declaración explícita de cada uno de ellos junto con la superclase de la que se hereda. En la figura 5 se puede ver un ejemplo de herencia simple, la subclase Estudiante, y un ejemplo de herencia múltiple, la subclase Preparador. Esta última debe explicitar la herencia de los atributos y métodos de Persona a través de una de sus dos superclases, para evitar ambigüedades en el pase de mensajes. Polimorfismo significa que se puede usar el mismo nombre para la definición de un método en varias clases sin importar la relación entre las mismas. Ejemplo: el operador + para tipos numéricos y para tipos caracter. Para que el polimorfismo sea posible se utilizan los conceptos de: reescritura y encadenamiento tardío o dinámico. La reescritura o sobrecarga es la que permite nombrar código diferente con el mismo nombre para más de una clase de objetos. El encadenamiento tardío permite seleccionar el código adecuado al objeto definido en la invocación del método. Un ejemplo de ello se puede observar en la figura 5 donde el método desplegar() se define para cada una de las clases de dicha figura. Notación UML Es una fusión de las notaciones de Booch, OMT, OOSE y otras. UML ha sido concebida para ser simple, intuitiva, homogénea, coherente, genérica y para ser extensible y configurable por el usuario. Elementos comunes Los elementos son la base de UML, que pueden ser: de modelado y de visualización, como lo muestra la figura 11. Los elementos se agrupan en paquetes que contienen referencias a los elementos de modelado. Un modelo es una abstracción de un sistema representado por un árbol de paquetes.

Figura 11. Metamodelo de UML.

Mecanismos comunes Definen y aseguran la integridad conceptual de la notación UML y se componen de: los estereotipos, las etiquetas, las notas, las restricciones, la relación de dependencia y las dicotomías (tipo, instancia) y (tipo, clase) . Cada elemento de modelado posee una especificación que contiene la descripción única y detallada de todas las características del elemento. Los estereotipos (clichés) especializan las clases del metamodelo, las etiquetas extienden los atributos de las clases del metamodelo y las restricciones extienden la semántica del metamodelo, todos ellos permiten la extensión de UML. La figura 12 muestra los mecanismos comunes.


65

Figura 12. Metamodelo de UML. Mecanismos comunes. Los estereotipos facilitan la unificación de conceptos cercanos como los subsistemas y las categorías, permiten la extensión controlada de las clases del metamodelo. Se representan con <<nombre del estereotipo>>. Etiqueta es un par (nombre, valor) que describe una propiedad de un elementos de modelado, ella modifica la semántica del elemento que califica. Una nota es un comentario asignado a uno o varios elementos de modelado. Una restricción es una relación semántica cualquiera entre los elementos de modelado, que se pueden expresar en lenguaje natural, en pseudocódigo, con expresiones de navegación o por expresiones matemáticas. Una relación de dependencia define una relación de uso unidireccional entre dos elementos de modelado, denominados fuente y blanco de la relación, respectivamente. Las notas y las restricciones pueden ser fuente de una relación de dependencia. Numerosos elementos de modelado representan una dicotomía (tipo, instancia) en la cual el tipo denota la esencia del elemento y la instancia con sus valores corresponde a una manifestación del tipo. La dicotomía (tipo, clase) corresponde a la separación entre la especificación de un elemento que es denotado por el tipo y la realización de esa especificación que está dada por la clase. Tipos primitivos Son los tipos elementales que no son elementos de modelado y no poseen ni estereotipos, ni etiquetas ni restricciones. Ellos son:

• Booleano: es un tipo enumerado con dos valores: Verdadero y falso. • Expresión: es una cadena de caracteres. • Lista: es un contenedor donde el contenido puede ser ordenado e indizado. • Multiplicidad: es un conjunto no vacío de enteros positivos extendido con *, que significa de

multiplicidad ilimitada.


66

• Nombre: es una cadena de caracteres que designa un elemento. Nombre compuesto = nombre simple {'.' nombre compuesto}. Nombre calificado con el paquete al que pertenece = paquete '::' nombre

• Punto: es una tupla (x, y, z) que indica la posición en el espacio, por omisión z = 0. • Cadena: es una cadena de caracteres que tiene un nombre. • Tiempo: es una cadena que representa un tiempo absoluto o relativo. • No interpretado: es un blob, cuyo significado depende del dominio.

Paquetes Permiten dividir un modelo y reagrupar y encapsular los elementos de modelado y se representa con una carpeta con nombre, como lo muestra la figura 13. Poseen una interfaz y una realización. Cada uno de sus elementos posee un parámetro que indica si es o no visible al exterior del paquete. Se recomienda que el grafo de paquetes sea un grafo acíclico.

Los diagramas de UML Ellos permiten visualizar y manipular los elementos de modelado. Normalmente son grafos donde los nodos y los arcos tienen diferentes representaciones dependiendo del tipo de diagrama. Ellos muestran todo o parte de las características de los elementos de modelado, según el nivel de detalle útil en el contexto del diagrama. La lista de los diagramas es la siguiente:

• Diagrama de clases: representa la estructura estática en términos de clases y asociaciones. Se realizan con las clases y sus asociaciones, que pueden o no ir en paquetes. La figura 14 muestra un ejemplo.

Figura 14. Diagrama de clases en UML.

• Diagrama de casos de uso: representa las funciones del sistema desde el punto de vista del usuario. Un caso de uso es una secuencia de acciones efectuadas por un actor del sistema, es decir, ellos permiten definir los límites del sistema y sus relaciones con el ambiente, haciendo concreto el futuro sistema en una formalización cercana al usuario, así no exista un sistema anterior. En UML se representan con una elipse contenida por el sistema. La figura 15 presenta un ejemplo. Un actor representa el rol jugado por una persona o cosa que interactua con el sistema. La misma persona puede jugar varios roles y varias personas pueden jugar el mismo rol. Hay cuatro grandes categorías de actores:

• Principales: las personas que utilizan las funciones principales. • Secundarios: las personas que efectuan tareas administrativas o de mantenimiento. • Externos: los dispositivos que forman parte del dominio de aplicación y que deben ser

utilizados. • Otros sistemas: los sistemas con los que debe interactuar.


67

Figura 15. Casos de uso en UML.

Los actores se describen de forma clara y concisa en tres o cuatro líneas. Los casos de uso se determinan observando y precisando, actor por actor, las secuencias de interacción (escenarios) desde el punto de vista del usuario. Un escenario es un camino particular a través de la descripción abstracta y general dada por el caso de uso. Un caso de uso agrupa una familia de escenarios de uso según un criterio funcional. Los casos de uso se ven como clases cuyas instancias son los escenarios. Las relaciones entre los casos de uso son: comunicación, donde el actor inicia la interacción indicado con una flecha; utilización, donde una instancia del caso de uso fuente utiliza el comportamiento del caso de uso destino; y extensión, donde un caso de uso extiende el caso de uso destino. En general, sólo hay un actor por cada caso de uso y para su realización es conveniente responder las preguntas siguientes: ¿Cuáles son las tareas del actor?, ¿Cuáles datos o información el actor debe crear, guardar, modificar, destruir o leer?, ¿Debe el actor informar al sistema de los cambios externos? y ¿Debe el sistema informar al actor las condiciones internas?. La descripción se debe concentrar en lo que DEBE HACERSE y NO en la manera de hacerlo. La descripción de un caso de uso contiene: su inicio (que evento lo dispara), su fin (que evento lo para), la interacción con los actores, el intercambio de información, la cronología y origen de las informaciones, las repeticiones de comportamiento y las situaciones opcionales. Si un caso de uso es muy complejo (por ejemplo más de diez páginas) es posible dividirlo en casos más pequeños. El enfoque orientado por objetos materializa un caso de uso por medio de la colaboración entre los objetos. Los escenarios se representan con los diagramas de interacción.

Diagrama de estado-transición: representa el comportamiento de una clase en término de sus estados. La figura 16 muestra un ejemplo. Diagrama de actividades: representa el comportamiento de una operación en términos de sus acciones. La figura 17 presenta un ejemplo.


68

Figura 16. Diagrama de estado-transicion en UML.

Figura 17. Diagrama de actividades en UML.


69

Diagrama de secuencias: es una representación temporal de los objetos y sus interacciones. La figura 18 muestra un ejemplo.

Figura 18. Diagrama de secuencias en UML.

Diagrama de colaboración: es una representación espacial de los objetos, sus enlaces y sus interacciones. (junto con los de secuencias se denominan, diagramas de interacción). La figura 19 presenta un ejemplo.


70

Figura 19. Diagrama de colaboracion en UML.

Diagrama de objetos: representan los objetos y sus relaciones, corresponden a diagramas de colaboración simplificados sin representación de los envios de mensajes. La figura 20 muestra un ejemplo.

Figura 20. Diagrama de objetos en UML.

Diagrama de componentes: representa las componentes físicas de la aplicación. Diagrama de despliegue: representa el despliegue de las componentes sobre los dispositivos físicos. Metamodelo Numerosos elementos de modelado presentan la dicotomía (esencia, manifestación) por la cual un tipo representa la esencia de una abstracción y la instancia es la manifestación concreta, asimismo la dicotomía (especificación, realización) donde las clases y los tipos primitivos realizan los tipos.


71

Un tipo especifica un dominio de valores y un conjunto de operaciones aplicables a esos valores. Una clase realiza un tipo. La figura 23 ilustra tales dicotomías. La clase Tipo comprende las clases: tipo primitivo (entero o enumerado), clase y caso de uso. La clase Clase comprende: clase activa que tiene un o varios flujos de ejecución; señal que es un evento con nombre; componente que es un elemento reutilizable de componentes físicas y nodo que es un dispositivo físico sobre el cual las componentes pueden ser desplegadas para su ejecución.

Figura 23. Metamodelo de las clases en UML.

UML define cinco relaciones, la más general, la relación de dependencia se aplica de forma uniforme a todos los elementos de modelado. La asociación y la generalización conciernen a todos los tipos, en particular a las clases y a los casos de uso. Las transiciones y los enlaces se aplican a ciertos elementos de modelado del comportamiento. La figura 24 ilustra estas relaciones. La asociación representa una conexión semántica bidireccional entre tipos, posee al menos dos roles, cada rol tiene los atributos siguientes:

Figura 24. Metamodelo de las relaciones en UML.

• Multiplicidad: especifica el número de instancias que participan en la relación.


72

• Navegabilidad: precisa si los enlaces, instancias de asociación, son navegables en la dirección del rol considerado.

• Agregabilidad: especifica si las instancias del tipo asociado al rol son el todo en una relación (todo, partes). Sólo uno de los roles puede tener este atributo en verdadero. Si la multiplicidad del rol es 1, significa que el todo posee las partes y por ello la destrucción del todo implica la destrucción de las partes. Si la multiplicidad es mayor que 1, varias instancias juegan el rol de todo y comparten las partes, la destrucción de una de las instancias del todo no implica la destrucción de las partes, sólo la destrucción de todas las instancias del todo implica la destrucción de las partes.

• Cambiable: precisa si la semántica de la asociación se mantiene luego de que una instancia del tipo que participa en el rol es reemplazada por otra.

• Ordenada: se aplica si la multiplicidad es mayor que 1 y significa que las instancias están ordenadas.

La generalización especifica una relación de clasificación por la que una instancia de un subtipo puede ser substituida por una instancia del supertipo. Un supertipo puede tener varios subtipos y un subtipo puede tener varios supertipos. Todo elemento generalizable posee los atributos lógicos siguientes:

• Abstracto: Si es verdadero indica que el elemento no puede ser instanciado directamente. • Hoja: Si es verdadero indica que el elemento no puede tener subtipos. • Raíz: Si es verdadero indica que el elemento no puede tener supertipos.

UML define tres elementos generalizables: stereotipo (no puede tener subtipos), paquete (no puede tener supertipos) y tipo. La figura 25 muestra la relación de generalización y de dependencia. La dependencia es una relación de uso unidireccional entre los elementos.

Figura 25. Metamodelo de las generalizaciones y dependencias en UML.


73

Ventajas y desventajas de la orientación por objetos

Las ventajas de la programación orientada por los objetos son las siguientes:

• La abstracción de datos y el ocultamiento de la información aumentan la confiabilidad y ayudan a separar la especificación de la implantación.

• El encadenamiento dinámico incrementa la flexibilidad. • La herencia junto con el encadenamiento tardío permite la reusabilidad aumentando así la

productividad. Entre sus desventajas se encuentran:

• El costo de tiempo de ejecución del encadenamiento tardío puede llegar a ser importante dependiendo de la aplicación.

• La implantación con lenguajes orientados por objetos es más compleja que con los lenguajes convencionales.

• El programador debe leer con frecuencia extensas librerías de clases.


74

UNIDAD VII

BASE DE DATOS DISTRIBUIDAS Introducción La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha promovido un cambio en la forma de observar a los sistemas de información y, en general, a las aplicaciones computacionales. Existen avances tecnológicos que se realizan continuamente en circuitos, dispositivos de almacenamiento, programas y metodologías. Sin embargo, los cambios tecnológicos van de la mano con la demanda de los usuarios y programas para la explotación exhaustiva de tales dispositivos mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales incorporan ideas nuevas desarrolladas por compañías e instituciones académicas. Aún cuando es posible que un usuario común no perciba los desarrollos relevantes de nuevos productos, para las aplicaciones existe una demanda permanente por mayor funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento. Así, al diseñar un nuevo sistema de información o al prolongar la vida de uno ya existente, se debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnología disponible a las necesidades de las aplicaciones de los usuarios. Una área en la cual las soluciones están integrando tecnología con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidos de información. Ellos se refieren al manejo de datos almacenados en facilidades de cómputo localizadas en muchos sitios ligados a través de una red de comunicaciones. Un caso específico de estos sistemas distribuidos es lo que se conoce como bases de datos distribuidas, tópico a estudiar en estas notas. 1. MOTIVACION Existen dos fuerzas que han impulsado la evolución de los sistemas de bases de datos. Por un lado los usuarios como parte de organizaciones más complejas han demandado una serie de capacidades que se han ido incorporando en los sistemas de bases de datos (Figura 1.1). Un ejemplo de esto es la necesidad de integrar información proveniente de fuentes diversas. Por otro lado, la tecnología ha hecho posible que algunas facilidades inicialmente imaginadas solo en sueños se conviertan en realidad. Por ejemplo, las transacciones en línea que permite el sistema bancario actual no hubiera sido posible sin el desarrollo de los equipos de comunicación. Los sistemas de cómputo distribuido son ejemplos claros en donde presiones organizacionales se combinan con la disponibilidad de nuevas tecnologías para hacer realidad tales aplicaciones.

La presión por datos distribuidos La presión de los usuarios Las bases de datos grandes permiten organizar la información relevantes a alguna parte de la operación de una organización como por ejemplo servicios de salud, corporaciones industriales o bancos. Casi cualquier organización que ha incorporado sistemas de información para su funcionamiento ha experimentado dos fases.

Figura 1.1. Fuerzas evolucionarias en los sistemas de bases de datos.


75

En la primera fase, se ha agrupando toda la información en un solo lugar. La idea original era que todos los accesos a datos podrían ser integrados en un solo lugar usando herramientas de bases de datos tales como lenguajes de descripción de datos, lenguajes de manipulación de datos, mecanismos de acceso, verificadores de restricciones y lenguajes de alto nivel. Para poder tener estos mecanismos de almacenamiento y recuperación de información, las organizaciones hicieron fuertes inversiones en equipos computacionales sofisticas y con grandes capacidades. Sin embargo, después de experimentar por un tiempo con este enfoque, muchas organizaciones encontraron que el sistema completo era satisfactorio, en algún grado, para un buen número de usuarios pero muy pocos obtenían un servicio óptimo. Más aún, bajo este esquema centralizado los "propietarios" u originadores de la información específica perdieron el control sobre el manejo de su información ya que ésta no se almacenaba en sus lugares de trabajo. Algunos experimentos mostraron que el 90% de las operaciones de entrada y salida de información eran "locales" (correspondientes al departamento que las generaba) y solo el 10% de tales operaciones involucraba información cruzada (información proveniente de más de un departamento). Así, en la segunda fase se promovió la descentralización de los sistemas de bases de datos corporativos. Entonces, se empezaron a adquirir sistemas de software y hardware departamentales. Este enfoque presentó grandes beneficios para el control de la seguridad de la información y la disponibilidad de la misma. Permitió que los esquemas de mantenimiento y planeación de los sistemas de información afectara en menor medida al funcionamiento general de la organización. Sin embargo, muy pronto empezaron a aparecer inconvenientes con este enfoque. Se presentaron problemas de consistencia de la información entre los sistemas locales y central y se hallaron dificultados al transferir información de entre departamentos diferentes de una corporación. De esta manera, en una tercera fase (la cual aún no ha concluido) se ha tratado de formalizar la descentralización de las bases de datos y de sus funciones manteniendo la integridad de la información y quizá algún tipo de control centralizado o distribuido.

La presión de la tecnología Existen buenas razones técnicas para distribuir datos. La más obvia es la referente a la sobrecarga de los canales de entrada y salida a los discos en donde se almacena finalmente la información. Es mucho mejor distribuir los accesos a la información sobre diferentes canales que concentrarlos en uno solo. Otra razón de peso es que las redes de computadoras empezaron a trabajar a velocidades razonables abriendo la puerta a la distribución del trabajo y la información. El hacer una descentralización de la información se justifica desde el punto de vista tecnológico por las siguientes razones:

• Para permitir autonomía local y promover la evolución de los sistemas y los cambios en los requerimientos de usuario.

• Para proveer una arquitectura de sistemas simple, flexible y tolerante a fallas. • Para ofrecer buenos rendimientos.

Existen aplicaciones que nacieron distribuidas. Para ellas ha sido necesario el uso de nuevas tecnologías para integrar sistemas de información diferentes, de forma que, no se afecte de manera sustancial el estilo de trabajo o de hacer las cosas de los usuarios. Aunque la idea de distribución de datos es bastante atractiva, su realización conlleva la superación de una serie de dificultades tecnológicas entre las que se pueden mencionar:

• Asegurar que el acceso entre diferentes sitios o nodos y el procesamiento de datos se realice de manera eficiente, presumiblemente óptima.

• Transformar datos e integrar diferentes tipos de procesamiento entre nodos de un ambiente distribuido.

• Distribuir datos en los nodos del ambiente distribuido de una manera óptima. • Controlar el acceso a los datos disponibles en el ambiente distribuido. • Soportar la recuperación de errores de diferentes módulos del sistema de manera segura y

eficiente.


76

• Asegurar que los sistemas locales y globales permanezcan como una imagen fiel del mundo real evitando la interferencia destructiva que pueden ocasionar diferentes transacciones en el sistema.

Así también, la aplicación de técnicas de distribución de información requiere de superar algunas dificultades de índole organizacional y algunas otras relacionadas con los usuarios. Entre ellas se puede mencionar:

• El desarrollo de modelos para estimar la capacidad y el tráfico esperado en el sistema distribuido. • Soportar el diseño de sistemas de información distribuidos. Por ejemplo, ayudar a decidir donde

localizar algún dato particular o donde es mejor ejecutar un programa de aplicación. • Considerar la competencia que habrá por el uso de los recursos entre nodos diferentes.

Aun cuando las dificultades mencionadas son importantes, las ventajas de la distribución de información han promovido su aplicación en ambientes del presente y del futuro.

Heterogeneidad y la presión para integrar datos La descentralización de los sistemas de información y el advenimiento de los sistemas distribuidos están bien justificados. Sin embargo, existe todavía un argumento importante para el desarrollo de sistemas de bases de datos distribuidas; éste se refiere a la integración de necesidades de procesamiento no locales en donde es necesario intercambiar información proveniente de otras áreas o departamentos. La descentralización de la información promueve la heterogeneidad en su manejo. La heterogeneidad se puede dar a muchos niveles, desde la forma y significado de cada dato hasta el formato y el medio de almacenamiento que se elige para guardarlo. La integración de la información es de importancia mayor para el funcionamiento de una organización. En resumen, en los sistemas de bases de datos distribuidas se persigue la integración de sistemas de bases de datos diversos no necesariamente homogéneos para dar a los usuarios una visión global de la información disponible. Este proceso de integración no implica la centralización de la información, más bien, con la ayuda de la tecnología de redes de computadoras disponible, la información se mantiene distribuida (localizada en diversos lugares) y los sistemas de bases de datos distribuidos permiten el acceso a ella como si estuviera localizada en un solo lugar. La distribución de la información permite, entre otras cosas, tener accesos rápidos a la información, tener copias de la información para accesos más rápidos y para tener respaldo en caso de fallas.

Computación Distribuida Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de cómputo distribuido en los cuales un conjunto de elementos de procesamiento autónomos (no necesariamente homogéneos) se interconectan por una red de comunicaciones y cooperan entre ellos para realizar sus tareas asignadas. Históricamente, el cómputo distribuido se ha estudiado desde muchos puntos de vista. Así, es común encontrar en la literatura un gran número de términos que se han usado para identificarlo. Entre los términos más comunes que se utilizan para referirse al cómputo distribuido podemos encontrar: funciones distribuidas, procesamiento distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital, procesamiento tipo "backend", computadoras dedicadas y de propósito específico, sistemas de tiempo compartido, sistemas funcionalmente modulares. Existen muchas componentes a distribuir para realizar una tarea. En computación distribuida los elementos que se pueden distribuir son:

• Control. Las actividades relacionadas con el manejo o administración del sistema. • Datos. La información que maneja el sistema. • Funciones. Las actividades que cada elemento del sistema realiza. • Procesamiento lógico. Las tareas específicas involucradas en una actividad de procesamiento de

información.


77

Figura 1.2. Motivación de los sistemas de bases de datos distribuidos.

Sistemas de bases de datos distribuidas Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones (ver Figura 1.2). Un sistema de bases de datos distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su sitio propio. Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que se encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la distribución sea transparente a los usuarios. El término transparente significa que la aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutado en una sola máquina, administrara esos datos. Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la integración de una base de datos distribuida con un sistema para su manejo. Dada la definición anterior, es claro que algunos sistemas no se pueden considerar como SBDD. Por ejemplo, un sistema de tiempo compartido no incluye necesariamente un sistema de manejo de bases de datos y, en caso de que lo haga, éste es controlado y administrado por una sola computadora. Un sistema de multiprocesamiento puede administrar una base de datos pero lo hace usualmente a través de un solo sistema de manejo de base de datos; los procesadores se utilizan para distribuir la carga de trabajo del sistema completo o incluso del propio SMBD pero actuando sobre una sola base de datos. Finalmente, una base de datos la cual reside en un solo sitio de una red de computadoras y que es accesada por todos los nodos de la red no es una base de datos distribuida (Figura 1.3). Este caso se trata de una base de datos cuyo control y administración esta centralizada en un solo nodo pero se permite el acceso a ella a través de la red de computadoras. El medio ambiente típico de un SMBDD consiste de un conjunto de sitios o nodos los cuales tiene un sistema de procesamiento de datos completo que incluye una base de datos local, un sistema de manejo de bases de datos y facilidades de comunicaciones. Si los diferentes sitios pueden estar geográficamente dispersos, entonces, ellos están interconectados por una red de tipo WAN. Por otro lado, si los sitios están localizados en diferentes edificios o departamentos de una misma organización pero geográficamente en la misma ubicación, entonces, están conectados por una red local (LAN) (Figura 1.4).


78

Figura 1.3. Un sistema centralizado sobre una red.

Figura 1.4. Un medio ambiente distribuido para bases de datos.

Ambientes con múltiples procesadores Desde el punto de vista de las bases de datos, conceptualmente existen tres tipos de ambientes que se integran con múltiples procesadores:

• Arquitecturas de memoria compartida. Consisten de diversos procesadores los cuales accesan una misma memoria y un misma unidad de almacenamiento (uno o varios discos). Algunos ejemplos de este tipo son las computadoras Sequent Encore y los mainframes IBM4090 y Bull DPS8 (Figura 1.5).

Figura 1.5. Arquitectura de memoria compartida.


79

• Arquitecturas de disco compartido. Consiste de diversos procesadores cada uno de ellos con su memoria local pero compartiendo una misma unidad de almacenamiento (uno o varios discos). Ejemplos de estas arquitecturas son los cluster de Digital, y los modelos IMS/VS Data Sharing de IBM (Figura 1.6).

Figura 1.6. Arquitectura de disco compartido.

• Arquitecturas nada compartido. Consiste de diversos procesadores cada uno con su propia memoria y su propia unidad de almacenamiento. Aquí se tienen los clusters de estaciones de trabajo, la computadoras Intel Paragon, NCR 3600 y 3700 e IBM SP2 (Figura 1.7).

Figura 1.7. Arquitectura nada compartido.

Aplicaciones Los ambientes en los que se encuentra con mayor frecuencia el uso de las bases de datos distribuidas son:

• Cualquier organización que tiene una estructura descentralizada. • Casos típicos de lo anterior son: organismos gubernamentales y/o de servicio público. • La industria de la manufactura, particularmente, aquella con plantas múltiples. Por ejemplo, la

industria automotriz. • Aplicaciones de control y comando militar. • Líneas de transportación aérea. • Cadenas hoteleras. • Servicios bancarios y financieros.

Ventajas Los SMBDD tienen múltiples ventajas. En primer lugar los datos son localizados en lugar más cercano, por tanto, el acceso es más rápido, el procesamiento es rápido debido a que varios nodos intervienen en el procesamiento de una carga de trabajo, nuevos nodos se pueden agregar fácil y rápidamente. La comunicación entre nodos se mejora, los costos de operación se reducen, son amigables al usuario, la probabilidad de que una falla en un solo nodo afecte al sistema es baja y existe una autonomía e independencia entre los nodos.


80

Las razones por las que compañías y negocios migran hacia bases de datos distribuidas incluyen razones organizacionales y económicas, para obtener una interconexión confiable y flexible con las bases de datos existente, y por un crecimiento futuro. El enfoque distribuido de las bases de datos se adapta más naturalmente a la estructura de las organizaciones. Además, la necesidad de desarrollar una aplicación global (que incluya a toda la organización), se resuelva fácilmente con bases de datos distribuidas. Si una organización crece por medio de la creación de unidades o departamentos nuevos, entonces, el enfoque de bases de datos distribuidas permite un crecimiento suave. Los datos se pueden colocar físicamente en el lugar donde se accesan más frecuentemente, haciendo que los usuarios tengan control local de los datos con los que interactúan. Esto resulta en una autonomía local de datos permitiendo a los usuarios aplicar políticas locales respecto del tipo de accesos a sus datos. Mediante la replicación de información, las bases de datos distribuidas pueden presentar cierto grado de tolerancia a fallas haciendo que el funcionamiento del sistema no dependa de un solo lugar como en el caso de las bases de datos centralizadas. Desventajas La principal desventaja se refiere al control y manejo de los datos. Dado que éstos residen en muchos nodos diferentes y se pueden consultar por nodos diversos de la red, la probabilidad de violaciones de seguridad es creciente si no se toman las precauciones debidas. La habilidad para asegurar la integridad de la información en presencia de fallas no predecibles tanto de componentes de hardware como de software es compleja. La integridad se refiere a la consistencia, validez y exactitud de la información. Dado que los datos pueden estar replicados, el control de concurrencia y los mecanismos de recuperación son mucho más complejos que en un sistema centralizado. 1.5 Aspectos importantes de los SMBD distribuidos Existen varios factores relacionados a la construcción de bases de datos distribuidas que no se presentan en bases de datos centralizadas. Entre los más importantes se encuentran los siguientes:

1. Diseño de la base de datos distribuida. En el diseño de bases de datos distribuidas se debe considerar el problema de como distribuir la información entre diferentes sitios. Existen razones organizacionales las cuales determinan en gran medida lo anterior. Sin embargo, cuando se busca eficiencia en el acceso a la información, se deben abordar dos problemas relacionados. Primero, como fragmentar la información. Segundo, como asignar cada fragmento entre los diferentes sitios de la red. En el diseño de la BDD también es importante considerar si la información está replicada, es decir, si existen copias múltiples del mismo dato y, en este caso, como mantener la consistencia de la información. Finalmente, una parte importante en el diseño de una BDD se refiere al manejo del directorio. Si existen únicamente usuarios globales, se debe manejar un solo directorio global. Sin embargo, si existen también usuarios locales, el directorio combina información local con información global.

2. Procesamiento de consultas. El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor. El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos. No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del sistema. Así, el procesamiento de consultas presenta un problema de optimización en el cual se determina el orden en el cual se hace la menor cantidad de operaciones. Este problema de optimización es NP-difícil, por lo que en tiempos razonables solo se pueden obtener soluciones aproximadas. En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisión de información al lugar en donde se solicitó la consulta.

3. Control de concurrencia. El control de concurrencia es la actividad de coordinar accesos concurrentes a la base de datos. El control de concurrencia permite a los usuarios accesar la base de datos en una forma multiprogramada mientras se preserva la ilusión de que cada usuario está utilizándola solo en un sistema dedicado. El control de concurrencia asegura que transacciones múltiples sometidas por usuarios diferentes no interfieran unas con otras de forma que se


81

produzcan resultados incorrectos. En BDD el control de concurrencia es aún más complejo que en sistemas centralizados. Los algoritmos más utilizados son variaciones de aquellos usados en sistemas centralizados: candados de dos fases, ordenamiento por estampas de tiempo, ordenamiento por estampas de tiempo múltiples y control de concurrencia optimista. Un aspecto interesante del control de concurrencia es el manejo de interbloqueos. El sistema no debe permitir que dos o más transacciones se bloqueen entre ellas.

4. Confiabilidad . En cualquier sistema de bases de datos, centralizado o distribuido, se debe ofrecer garantías de que la información es confiable. Así cada consulta o actualización de la información se realiza mediante transacciones, las cuales tienen un inicio y fin. En sistemas distribuidos, el manejo de la atomicidad y durabilidad de las transacciones es aún más complejo, ya que una sola transacción puede involucrar dos o más sitios de la red. Así, el control de recuperación en sistemas distribuidos debe asegurar que el conjunto de agentes que participan en una transacción realicen todos un compromiso (commit) al unísono o todos al mismo tiempo restablezcan la información anterior (roll-back).

En la Figura 1.8 se presenta un diagrama con las relaciones entre los aspectos relevantes sobre las BDD.

Figura 1.8. Factores importantes en BDD.

Estado del Arte Aun cuando los beneficios del uso de BDD son claramente perceptibles, en la actualidad muchos de los desarrollos se encuentran únicamente en sistemas experimentales (de investigación). A continuación se discute el estado actual de las bases de datos comerciales respecto de cuatro logros potenciales asequibles en BDD.

1. Manejo transparente de datos distribuidos, fragmentados y replicados. Comercialmente aún no se soporta la replicación de información. La fragmentación utilizada es únicamente de tipo horizontal (ésta se discute en el capítulo 3). La distribución de información no se realiza aún con la transparencia requerida. Por ejemplo, el usuario debe indicar la localización de un objeto y el acceso a los datos es mediante sesiones remotas a bases de datos locales. La mayoría de los sistemas comerciales utilizan el modelo múltiples clientes-un solo servidor.

2. Mejoramiento de la confiabilidad y disponibilidad de la información mediante transacciones distribuidas. Algunos sistemas como Ingres, NonStop SQL y Oracle V 7.x ofrecen el soporte de transacciones distribuidas. En Sybase, por ejemplo, es posible tener transacciones distribuidas pero éstas deber ser implementadas en las aplicaciones mediante primitivas dadas. Respecto del soporte para replicación de información o no se ofrece o se hace a través de la regla une-lee-todos-escriben.


82

3. Mejoramiento de la eficiencia. Una mayor eficiencia es una de las grandes promesas de los SMBDD. Existen varias partes en donde ésto se puede lograr. En primer lugar, la ubicación de los datos a lugares próximos a donde se usan puede mejorar la eficiencia en el acceso a la información. Sin embargo, para lograrlo es necesario tener un buen soporte para fragmentación y replicación de información. Otro punto en donde se puede incrementar la eficiencia es mediante la explotación del paralelismo entre operaciones. Especialmente en el caso de varias consultas independientes, éstas se pueden procesar por sitios diferentes. Más aún, el procesamiento de una sola consulta puede involucrar varios sitios y así procesarse de manera más rápida. Sin embargo, la explotación del paralelismo requiere que se tenga tanta información requerida por cada aplicación en el sitio donde la aplicación se utiliza, lo cual conduciría a una replicación completa, esto es, tener toda la información en cada sitio de la red. El manejo de réplicas es complicado dado que las actualizaciones a este tipo de datos involucran a todos los sitios teniendo copias del dato. Los sistemas comerciales ofrecen únicamente aproximaciones a este requisito. Por ejemplo, en los bancos se destina usualmente el horario de oficina para hacer lecturas y las horas no hábiles para hacer actualizaciones. Otra estrategia es tener dos bases de datos, una para consultas y otra para actualizaciones.

4. Mejor escalabilidad de las BD. El tener sistemas escalables de manera fácil y económica se ha logrado por el desarrollo de la tecnología de microprocesadores y estaciones de trabajo. Sin embargo, respecto de la escalabilidad, la comunicación de la información tiene un costo el cual no se ha estudiado con suficiente profundidad.

ARQUITECTURA DE BASE DE DATOS DISTRIBUIDA En el presente capítulo se mostrará la arquitectura general de un sistema de bases de datos distribuida, se introducirá el concepto de fragmentación de datos relacionado con el nivel de transparencia de distribución que un SBDD debe ofrecer. Se dará una descripción acerca de las componentes de las bases de datos distribuidas. La arquitectura define la estructura de un sistema. Al definir la arquitectura se deben identificar las componentes de un sistema, las funciones que realiza cada una de las componentes y las interrelaciones e interacciones entre cada componente. NIVELES DE TRANSPARENCIA EN SBDD El próposito de establecer una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la información. La transparencia se puede entender como la separación de la semántica de alto nivel de un sistema de las aspectos de bajo nivel relacionados a la implementación del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de implementación a las capas de alto nivel de un sistema y a otros usuarios. En sistemas de bases de datos distribuidos el propósito fundamental de la transparencia es proporcionar independencia de datos en el ambiente distribuido. Se pueden encontrar diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir transparencia en el manejo de la red de comunicación, transparencia en el manejo de copias repetidas o transparencia en la distribución o fragmentación de la información. La independencia de datos es la inmunidad de las aplicaciones de usuario a los cambios en la definición y/u organización de los datos y viceversa. La independencia de datos se puede dar en dos aspectos: lógica y física.

1. Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lógica de la base de datos. Esto permite que un cambio en la definición de un esquema no debe afectar a las aplicaciones d eusuario. Por ejemplo, el agregar un nuevo atributo a una relación, la creación de una nueva relación, el reordenamiento lógico de algunos atributos.


83

2. Independencia física de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la descripción física de datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la organización de los datos puede cambiar.

La transparencia al nivel de red se refiere a que los datos en un SBDD se accesan sobre una red de computadoras, sin embargo, las aplicaciones no deben notar su existencia. La transparencia al nivel de red conlleva a dos cosas:

1. Transparencia sobre la localización de datos. Esto es, el comando que se usa es independiente de la ubicación de los datos en la red y del lugar en donde la operación se lleve a cabo. Por ejemplo, en Unix existen dos comandos para hacer una copia de archivo. Cp se utiliza para copias locales y rcp se utiliza para copias remotas. En este caso no existe transparencia sobre la localización.

2. Transparencia sobre el esquema de nombramiento. Lo anterior se logra proporcionando un nombre único a cada objeto en el sistema distribuido. Así, no se debe mezclar la información de la localización con en el nombre de un objeto.

La transparencia sobre replicación de datos se refiere a que si existen réplicas de objetos de la base de datos, su existencia debe ser controlada por el sistema no por el usuario. Se debe tener en cuenta que al cuando el usuario se encarga de manejar las réplicas en un sistema, el trabajo de éste es mínimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia de las réplicas teniendo así datos diferentes. La transparencia a nivel de fragmentación de datos permite que cuando los objetos de la bases de datos están fragmentados, el sistema tiene que manejar la conversión de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente.

Ejemplo 2.1. Como un ejemplo se utilizará a lo largo de estas notas una base de datos que modela una compañía de ingeniería. Las entidades a ser modeladas son ingenieros y proyectos. Para cada ingeniero, se desea conocer su número de empleado (ENO), su nombre (ENOMBRE), el puesto ocupado en compañía (TITULO), el salario (SAL), la identifiación de los nombres de proyectos en los cuales está trabajando (JNO), la responsabilidad que tiene dentro del proyecto (RESP) y la duración de su responsabilidad en meses (DUR). Similarmente, para cada proyecto se desea conocer el número de proyecto (JNO), el nombre del proyecto (JNOMBRE), el presupuesto asignado al proyecto (PRESUPUESTO) y el lugar en donde se desarrolla el proyecto (LUGAR). Un ingeniero puede participar en más de un proyecto pero su salario corresponde únicamente al puesto que ocupa en la compañía. Así, después de aplicar normalización se obtienen las relaciones E –para ingenieros, J –para proyectos, S –para los salarios asignados a los puestos y G –para los ingenieros asignados a cada proyecto. Un ejemplo de las instancias para cada relación se presenta en la Figura 2.1.

E

ENO ENOMBRE TITULO E1 Juan Rodríguez Ingeniero Eléctrico E2 Miguel Sánchez Analista de Sistemas E3 Armando Legarreta Ingeniero Mecánico E4 Beatriz Molleda Programador E5 Jorge Castañeda Analista de Sistemas E6 Luis Chávez Ingeniero Eléctrico E7 Roberto Dávila Ingeniero Mecánico E8 Julia Jiménez Analista de Sistemas G


84

ENO JNO PUESTO DUR E1 J1 Administrador 12 E2 J1 Analista 24 E2 J2 Analista 6 E3 J3 Consultor 10 E3 J4 Ingeniero 48 E4 J2 Programador 18 E5 J2 Administrador 24 E6 J4 Administrador 48 E7 J3 Ingeniero 36 E7 J5 Ingeniero 23 E8 J3 Administrador 40

J JNO JNOMBRE PRESUPUEST

O LUGAR

J1 Instrumentación 150000 Monterrey J2 Desarrollo de

bases de datos 135000 México

J3 CAD/CAM 250000 Puebla J4 Mantenimiento 310000 México J5 CAD/CAM 500000 Monterrey S

TITULO SALARIO Ingeniero Eléctrico 40000 Analista de Sistemas 34000 Ingeniero Mecánico 27000 Programador 24000

Figura 2.1. Bases de datos de una empresa con cuatro relaciones. Si se quisiera obtener todos los empleados y sus salarios en la corporación quienes han trabajado más de 12 meses se haría la consulta siguiente en SQL:

SELECT ENOMBRE, SALARIO FROM E, G, S WHERE JORNADA > 12 AND E.ENO = G.ENO AND E.TILE = S.TITLE

Se debe tener en cuenta que en cada sitio de la corporación puede haber esquemas diferentes o repetidos. Por ejemplo, en la Figura 2.2 se presentan esquemas diferentes para el manejo de proyectos, empleados y puestos en cada sitio de la bases de datos del Ejemplo 2.1.


85

Figura 2.2. Diferentes sitios de un corporación.

En resumen, la transparencia tiene como punto central la independencia de datos. Los diferentes niveles de transparencia se puede organizar en capas como se muestra en la Figura 2.3. En el primer nivel se soporta la transparencia de red. En el segundo nivel se permite la transparencia de replicación de datos. En el tercer nivel se permite la transparencia de la fragmentación. Finalmente, en el último nivel se permite la transparencia de acceso (por medio de lenguaje de manipulación de datos). La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la base de datos distribuida. Entre estos tres módulos se deben resolver los aspectos sobre el procesamiento distribuido de consultas y sobre el manejo de nombres de objetos distribuidos.

Figura 2.3. Organización en capas de los niveles de transparencia.


86

ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRI BUIDAS La mayoría de los sistemas de manejo de bases de datos disponibles actualmente están basadas en la arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles: interno, conceptual y externo, como se puede apreciar en la Figura 2.4. La vista conceptual, conocida también como vista lógica global, representa la visión de la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma en que las aplicaciones individuales observan los datos o como éstos son almacenados. La vista conceptual está basada en el esquema conceptual y su construcción se hace en la primera fase del diseño de una base de datos. Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a través de un esquema externo definido a nivel externo. La vista externa proporciona una ventana a la vista conceptual lo cual permite a los usuarios observar únicamente los datos de interés y los aísla de otros datos en la base de datos. Puede existir cualquier número de vistas externas y ellos pueden ser completamente independientes o traslaparse entre sí. El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel de descripción más bajo de los datos en una base de datos. Este proporciona una interfaz al sistema de archivos del sistema operativo el cual es el responsable del acceso a la base de datos. El nivel interno tiene que ver con la especificación de qué elementos serán indexados, qué técnica de organización de archivos utilizar y como los datos se agrupan en el disco mediante "clusters" para mejorar su acceso. En las Figuras 2.5, 2.6 y 2.7 se presenta la definición de los esquemas conceptual, interno y externo para las relaciones de la Figura 2.1.

Figura 2.4. Arquitectura ANSI/SPARC de una base de datos.

Figura 2.5. Vista conceptual de las relaciones E, S, J y G.


87

Figura 2.6. Definición de una vista interna a partir de la relación S.

Figura 2.7. Dos ejemplos de vistas externas.

Desafortunadamente, no existe un equivalente de una arquitectura estándar para sistemas de manejo de bases de datos distribuidas. La tecnología y prototipos de SMBDD se han desarrollado más o menos en forma independiente uno de otro y cada sistema ha adoptado su propia arquitectura. Para definir un esquema de estandarización en bases de datos distribuidas se debe definir un modelo de referencia el cual sería un marco de trabajo conceptual cuyo propósito es dividir el trabajo de estandarización en piezas manejables y mostrar a un nivel general como esas piezas se relacionan unas con otras. Para definir ese modelo de referencia se puede seguir uno de los siguientes tres enfoques: 1. Basado en componentes. Se definen las componentes del sistema junto con las relaciones entre ellas.

Así, un SMBD consiste de un número de componentes, cada uno de los cuales proporciona alguna funcionalidad.

2. Basado en funciones. Se identifican las diferentes clases de usuarios junto con la funcionalidad que el sistema ofrecerá para cada clase. La especificación del sistema en esta categoría típicamente determina una estructura jerárquica para las clases de usuarios. La ventaja de este enfoque funcional es la claridad con la cual se especifican los objetivos del sistema. Sin embargo, este enfoque no proporciona una forma de alcanzar los objetivos.

3. Basado en datos. Se identifican los diferentes tipos de descripción de datos y se especifica un marco de trabajo arquitectural el cual define las unidades funcionales que realizarán y/o usarán los datos de acuerdo con las diferentes vistas. La ventaja de este enfoque es la importancia que asigna al manejo de datos. Este es un enfoque significativo para los SMBD dado que su propósito principal es manejar datos. Sin embargo, la desventaja de este enfoque es que es prácticamente imposible especificar un modelo arquitectural sin especificar los modelos para cada una de sus unidades funcionales. Este es el enfoque seguido por el modelo ANSI/SPARC.


88

Figura 2.8. Dimensiones a considerar al integrar múltiples bases de datos.

ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD En la Figura 2.8 se presentan las diferentes dimensiones (factores) que se deben considerar para la implementación de un sistema manejador de base de datos. Las dimensiones son tres:

1. Distribución . Determina si las componentes del sistema están localizadas en la misma computadora o no.

2. Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a los algoritmos para manejo de transacciones.

3. Autonomía. La autonomía se puede presentar a diferentes niveles: • Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones

relacionadas a su propio diseño. • Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y

cuando comunicarse con otros SMBD. • Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones

locales de la manera que él quiera.


89

Figura 2.9. Arquitectura de un SMBDD homogéneo.

Desde el punto de vista funcional y de organización de datos, los sistemas de datos distribuidos están divididos en dos clases separadas, basados en dos filosofía totalmente diferentes y diseñados para satisfacer necesidades diferentes:

1. Sistemas de manejo de bases de datos distribuidos homogéneos 2. Sistemas de manejo de bases de datos distribuidos heterogéneos

Un SMBDD homogéneo tiene múltiples colecciones de datos; integra múltiples recursos de datos como se muestra en la Figura 2.9. Los sistemas homogéneos se parecen a un sistema centralizado, pero en lugar de almacenar todos los datos en un solo lugar, los datos se distribuyen en varios sitios comunicados por la red. No existen usuarios locales y todos ellos accesan la base de datos a través de una interfaz global. El esquema global es la unión de toda las descripciones de datos locales y las vistas de los usuarios se definen sobre el esquema global. Para manejar los aspectos de la distribución, se deben agregar dos niveles a la arquitectura estándar ANSI-SPARC, como se muestra en la Figura 2.10. El esquema de fragmentación describe la forma en que las relaciones globales se dividen entre las bases de datos locales. La Figura 2.11 presenta el ejemplo de una relación, R, la cual se divide en cinco fragmentos. El esquema de asignamiento especifica el lugar en el cual cada fragmento es almacenado. De aquí, los fragmentos pueden migrar de un sitio a otro en respuesta a cambios en los patrones de acceso.


90

Figura 2.10. Arquitectura de los esquemas de un SMBDD homogéneo.

Figura 2.11. Fragmentación de una relación global.

Figura 2.12. Arquitectura de un sistema multi-bases de datos.


91

La clase de sistemas heterogéneos es aquella caracterizada por manejar diferentes SMBD en los nodos locales. Una subclase importante dentro de esta clase es la de los sistemas de manejo multi-bases de datos. Un sistema multi-bases de datos (Smulti-BD) tiene múltiples SMBDs, que pueden ser de tipos diferentes, y múltiples bases de datos existentes. La integración de todos ellos se realiza mediante subsistemas de software. La arquitectura general de tales sistemas se presenta en la Figura 2.12. En contraste con los sistemas homogéneos, existen usuarios locales y globales. Los usuarios locales accesan sus bases de datos locales sin verse afectados por la presencia del Smulti-BD. En algunas ocasiones es importante caracterizar a los sistemas de bases de datos distribuidas por la forma en que se organizan sus componentes. En la Figura 2.13 se presenta la arquitectura basada en componentes de un SMBD distribuido. Consiste de dos partes fundamentales, el procesador de usuario y el procesador de datos. El procesador de usuario se encarga de procesar las solicitudes del usuario, por tanto, utiliza el esquema externo del usuario y el esquema conceptual global. Así también, utiliza un diccionario de datos global. El procesador de usuario consiste de cuatro partes: un manejador de la interfaz con el usuario, un controlador semántico de datos, un optimizador global de consultas y un supervisor de la ejecución global. El procesador de datos existe en cada nodo de la base de datos distribuida. Utiliza un esquema local conceptual y un esquema local interno. El procesador de datos consiste de tres partes: un procesador de consultas locales, un manejador de recuperación de fallas locales y un procesador de soporte para tiempo de ejecución.

Figura 2.13. Arquitectura basada en componentes de un SMBD distribuido.

En la Figura 2.14, se presenta la arquitectura basada en componentes de un sistema multi-bases de datos. Consiste un sistema de manejo de bases datos para usuarios globales y de sistemas de manejo de bases de datos para usuarios locales. Las solicitudes globales pasan al procesador global el cual consiste de un procesador de transacciones, una interfaz de usuario, un procesador de consultas, un optimizador de consultas, un esquema y un administrador de recuperación de fallas, todos ellos actuando de manera global. En cada sitio existe un SMBD completo el cual consiste de la interfaz con el usuario, el procesador y optimizador de consultas, el manejador de transacciones, el despachador de operaciones, el manejador de recuperación de fallas y el sistema de soporte para tiempo de ejecución, todos ellos actuando de manera local. Para comunicar el sistema global con los sistemas locales se define una interfaz común entre componentes mediante la cual, las operaciones globales se convierten en una o varias acciones locales.


92

El manejo de directorio de datos es de una importancia mayor en bases de datos distribuidas. Por un lado, puede haber directorios locales o un solo directorio global. Por otra parte, su manejo puede ser local o distribuido. Finalmente, desde otro punto de vista el directorio puede ser replicado o no replicado. Como se puede ver en la Figura 2.15, existen combinaciones, en estas tres dimensiones, que no tienen mayor relevancia. Sin embargo, en varios de los vértices del cubo en tres dimensiones aparecen las combinaciones importantes para bases de datos distribuidas.

Figura 2.14. Arquitectura basada en componentes de un sistema multi-bases de datos.

Figura 2.15. Manejo del directorio de datos en bases de datos distribuidas.


93

UNIDAD VIII

DATAWAREHOUSE El mundo de los Decision Suport Systems en adelante DSS ha creado varias arquitecturas de información. La más notable de las estructuras DSS es el Data warehouse. El Data warehouse contiene datos históricos que son comunes en toda la organización, la información puede estar sumarizada y/o detallada. Los datos que alimentan los sistemas de Data warehouse los proporcionan los sistemas operacionales, también denominados sistemas de ejecución de procesos de negocios. El Data warehouse casi siempre es un sistema de datos guardados físicamente en estructuras separadas, los datos son transformados a partir de los datos proporcionados por los sistemas operacionales. El potencial de la explotación de los datos (Data Mining) puede realzarse si de manera apropiada los datos son recolectados y guardados en un almacén o depósito de datos (Data warehouse). Un almacén de datos o Data warehouse es un sistema de gestión de bases de datos relacional diseñado específicamente para ofrecer las necesidades de los sistemas de análisis de la información. Se trata de una nueva técnica que posibilita la extracción de datos de los sistemas operacionales. También facilita la integración y homogeneización de los datos de toda la empresa. En otras palabras el almacén de datos provee datos que ya han sido transformados y sumarizados, por lo tanto crea el entorno apropiado para un uso más eficiente de las herramientas DSS y EIS. PROCESOS EN EL DISEÑO DE UN DATAWAREHOUSE La primera fase en el diseño de un sistema de almacén de datos consiste en aislar el actual sistema de información operacional, para preservar la seguridad y la integridad de las aplicaciones de misión críticas de OLTP. La base de datos resultante o almacén de datos puede consumir cientos de gigabytes o incluso de terabytes de espacio en disco. Existen técnicas para guardar y obtener grandes cantidades de información. Empresas con volúmenes de información enormes pueden requerir el uso de sistemas de procesamiento en paralelo para así obtener el ancho de banda suficiente.

Los datos se transforman y incluyen en el almacén de datos según un modelo preestablecido

Los procesos de transformación y movimiento de los datos pueden ejecutarse en cualquier momento cada vez que se necesite actualizar el almacén de datos mediante funciones especiales. La información que describe el modelo y la definición de los elementos de datos fuente se llama metadatos. Los metadatos son las unidades de información mínimas que manejarán los usuarios del almacén de datos y como mínimo incluirán:

• La estructura de los datos. • Los algoritmos usados en los procesoso de suma y acumulación. • El mapeado del sistema de información del entorno operacional al sistema de información del

almacén de datos. La limpieza de los datos en el sistema de información del entorno operacional es uno de los aspectos más importantes, consiste en eliminar parte de los datos operacionales, tales como información de transacciones de bajo nivel, los cuales por su elevado volumen inciden negativamente en los tiempos de ejecución de las consultas. Los datos que a nivel operacional ya no son operativos deberían extraerse de las fuentes de producción a intervalos regulares eliminándolos del sistema de información operacional y traspasándolos al almacén de datos o Data warehouse.


94

SISTEMAS DE DATA WAREHOUSE Y OLTP Una base de datos para soportar procesos transaccionales en línea (OLTP), puede no ser adecuada para el Data warehouse ya que ha sido diseñada para maximizar la capacidad transaccional de sus datos y tipicamente tiene cientos de tablas la gran mayoría normalizadas. Su diseño también ha sido condicionado por los procesos operacionales que deberá soportar para la óptima actualización de sus datos, normalmente muchas de sus tablas en constantes y continuos cambios. Los sistemas Data warehouse están orientados a procesos de consultas en contraposición con los procesos transaccionales. OLTP Data Warehouse

Propósito Ejecuta operaciones transaccionales diariamente

Consultas y análisis para la obtención de información

Estructura Sistemas de bases de datos relacionales

Normalmente sistemas de bases de datos relacionales

Modelo de datos

Normalizado Muchas de sus tablas pueden no estar normalizadas se admite redundancia en los datos. Bases de datos multidimensionales.

Acceso SQL

SQL más extensiones especiales dependientes de las herramientas de explotación de datos (Data Mining) No obstante, el SQL estándar puede ser suficiente en manos de personal experto.

Tipo de datos

Los datos están orientados a la gestión de los negocios

Los datos están orientados al análisis de los negocios. Transforman los datos en información para su análisis.

Perdurabilidad

Los datos cambian constantemente, vistos globalmente en procesos de reporting sofisticados pueden perder consistencia, o bien, para no perder consistencia deben imponerse mecanismos de bloqueo de datos con un elevado consumo de recursos globales del sistema.

Datos históricos con referencias temporales no sujetos a modificaciones.

CARACTERISTICAS De acuerdo con Bill Inmon, autor de Building the Data warehouse Construyendo el almacén de datos, ampliamante reconocido como el gurú creador del concepto data warehousing, existen generalmente cuatro características que describen un almaceén de datos:

5. orientado al sujeto: Los datos se organizan de acuerdo al sujeto en vez de la aplicación, por ejemplo, una compañia de seguros usando un almacén de datos podría organizar sus datos por cliente, premios, y reclamaciones, en lugar de por diferentes productos (automóviles, vida, etc.). Los datos organizados por sujetos contienen solo la información necesaria para los procesos de soporte para la toma de decisiones.

6. integrados: Cuando los datos residen en muchas aplicaciones separados por los distintos entornos operacionales, la descodificación de los datos es a menudo inconsistente. Por ejemplo, en una aplicación, la palabra gender podría codificarse como "m" y "f" en otra como "0" y "1". cuando los datos fluyen de un entorno operacional a un entorno de almaceén de datos o de Data


95

warehouse, ellos asumen una codificación consistente, por ejemplo gender siempre se transformaría a "m" y "f".

7. variación-temporal: El almaceén de datos contiene un lugar para guardar datos con una antiguedad de 5 a diez años, o incluso más antiguos, para poder ser usados en comparaciones, tendencias y previsiones. Estos datos no se modificarán.

8. no son inestables: Los datos no serán modificados o cambiados de ninguna manera una vez ellos han sido introducidos en el almacén de datos, solamente podrán ser cargados, leidos y/o accedidos.

BENEFICIOS Optimización

• Las estructuras de datos operacionales están orientadas a una explotación mediante procesos transaccionales en línea (OLTP), las características de sus tablas y registros.

Datos versus información • El Data warehouse con las herramientas adecuadas nos permitirá obtener o realizar análisis,

reporting, extracción y exploración de los datos para, en suma, transformar los datos en información útil para nuestra organización.

Beneficios económicos • Normalmente los beneficios económicos que podemos obtener de un Data warehouse no tienen la

inmediatez de los que pueden obtenerse mediante un efeciente sistema de información operacional, por lo general mediante los Data warehouse o Almacenes de datos hemos de esperar el ahorro de gastos motivados por los cambios que puedan sugerirse en la gestión de nuestra empresa en el medio y largo plazo.

Conclusión Las Data Warehouse representan una tecnología innovadora y un mercado en pleno desarrollo. Data Warehousing y Data Mining son dos procesos que permiten la Gestión del Conocimiento. El Conociemnto, convertido ahora en el más importante factor de producción, es un recurso clave para cualquier compañía que quiera sobrevivir y medrar en el competitivo y global entorno empresarial de hoy en día. Es importante señalar que este tipo de proyectos en constante evolución de la empresa. Por tanto, se podría decir que nunca tiene fin, que siempre son susceptibles al cambio. "El Data Warehousing no es un destino, sino un viaje" INTRODUCCION AL CONCEPTO DATA WAREHOUSING Data warehousing es el centro de la arquitectura para los sistemas de información en la década de los '90. Soporta el procesamiento informático al proveer una plataforma sólida, a partir de los datos históricos para hacer el análisis. Facilita la integración de sistemas de aplicación no integrados. Organiza y almacena los datos que se necesitan para el procesamiento analítico, informático sobre una amplia perspectiva de tiempo. Un Data Warehouse o Depósito de Datos es una colección de datos orientado a temas, integrado, no volátil, de tiempo variante, que se usa para el soporte del proceso de toma de decisiones gerenciales. Se puede caracterizar un data warehouse haciendo un contraste de cómo los datos de un negocio almacenados en un data warehouse, difieren de los datos operacionales usados por las aplicaciones de producción.


96

Base de Datos Operacional Data Warehouse Datos Operacionales Datos del negocio para Información Orientado a la aplicación Orientado al sujeto Actual Actual + histórico Detallada Detallada + más resumida Cambia continuamente Estable

Diferentes tipos de información El ingreso de datos en el data warehouse viene desde el ambiente operacional en casi todos los casos. El data warehouse es siempre un almacén de datos transformados y separados físicamente de la aplicación donde se encontraron los datos en el ambiente operacional. SISTEMAS DE INFORMACION En las metodologías anteriores, publicadas por el Instituto Nacional de Estadística e Informática - INEI y con el fin de proporcionar una visión más clara, los sistemas de información se han dividido de acuerdo al siguiente esquema:

• Sistemas Estratégicos, orientados a soportar la toma de decisiones, facilitan la labor de la dirección,

proporcionándole un soporte básico, en forma de mejor información, para la toma de decisiones. Se caracterizan porque son sistemas sin carga periódica de trabajo, es decir, su utilización no es predecible, al contrario de los casos anteriores, cuya utilización es periódica. Destacan entre estos sistemas: los Sistemas de Información Gerencial (MIS), Sistemas de Información Ejecutivos (EIS), Sistemas de Información Georeferencial (GIS), Sistemas de Simulación de Negocios (BIS y que en la práctica son sistemas expertos o de Inteligencia Artificial - AI).

• Sistemas Tácticos, diseñados para soportar las actividades de coordinación de actividades y manejo de documentación, definidos para facilitar consultas sobre información almacenada en el sistema, proporcionar informes y, en resumen, facilitar la gestión independiente de la información por parte de los niveles intermedios de la organización. Destacan entre ellos: los Sistemas Ofimáticos (OA), Sistemas de Transmisión de Mensajería (E-mail y Fax Server), coordinación y control de tareas (Work Flow) y tratamiento de documentos (Imagen, Trámite y Bases de Datos Documentarios).

• Sistemas Técnico-Operativos, que cubren el núcleo de operaciones tradicionales de captura masiva de datos (Data Entry) y servicios básicos de tratamiento de datos, con tareas predefinidas


97

(contabilidad, facturación, almacén, presupuesto, personal y otros sistemas administrativos). Estos sistemas están evolucionando con la irrupción de censores, autómatas, sistemas multimedia, bases de datos relacionales más avanzadas y data warehousing.

• Sistemas Interinstitucionales, este último nivel de sistemas de información recién está surgiendo, es consecuencia del desarrollo organizacional orientado a un mercado de carácter global, el cual obliga a pensar e implementar estructuras de comunicación más estrechas entre la organización y el mercado (Empresa Extendida, Organización Inteligente e Integración Organizacional), todo ésto a partir de la generalización de las redes informáticas de alcance nacional y global (INTERNET), que se convierten en vehículo de comunicación entre la organización y el mercado, no importa dónde esté la organización (INTRANET), el mercado de la institución (EXTRANET) y el mercado (Red Global). Sin embargo, la tecnología data warehousing basa sus conceptos y diferencias entre dos tipos fundamentales de sistemas de información en todas las organizaciones: los sistemas técnico-operacionales y los sistemas de soporte de decisiones. Este último es la base de un data warehouse.

Sistemas técnico-operacionales Como indica su nombre, son los sistemas que ayudan a manejar la empresa con sus operaciones cotidianas. Estos son los sistemas que operan sobre el "backbone" (columna vertebral) de cualquier empresa o institución, entre las que se tiene sistemas de ingreso de órdenes, inventario, fabricación, planilla y contabilidad, entre otros. Debido a su volumen e importancia en la organización, los sistemas operacionales siempre han sido las primeras partes de la empresa a ser computarizados. A través de los años, estos sistemas operacionales se han extendido, revisado, mejorado y mantenido al punto que hoy, ellos son completamente integrados en la organización. Desde luego, la mayoría de las organizaciones grandes de todo el mundo, actualmente no podrían operar sin sus sistemas operacionales y los datos que estos sistemas mantienen. Sistemas de Soporte de Decisiones Por otra parte, hay otras funciones dentro de la empresa que tienen que ver con el planeamiento, previsión y administración de la organización. Estas funciones son también críticas para la supervivencia de la organización, especialmente en nuestro mundo de rápidos cambios. Las funciones como "planificación de marketing", "planeamiento de ingeniería" y "análisis financiero", requieren, además, de sistemas de información que los soporte. Pero estas funciones son diferentes de las operacionales y los tipos de sistemas y la información requerida son también diferentes. Las funciones basadas en el conocimiento son los sistemas de soporte de decisiones. Estos sistemas están relacionados con el análisis de los datos y la toma de decisiones, frecuentemente, decisiones importantes sobre cómo operará la empresa, ahora y en el futuro. Estos sistemas no sólo tienen un enfoque diferente al de los operacionales, sino que, por lo general, tienen un alcance diferente. Mientras las necesidades de los datos operacionales se enfocan normalmente hacia una sola área, los datos para el soporte de decisiones, con frecuencia, toma un número de áreas diferentes y necesita cantidades grandes de datos operacionales relacionadas. Son estos sistemas sobre los se basa la tecnología data warehousing. CARACTERISTICAS DE UN DATA WAREHOUSE

Entre las principales se tiene: • Orientado al tema • Integrado • De tiempo variante • No volátil


98

Orientado a Temas Una primera característica del data warehouse es que la información se clasifica en base a los aspectos que son de interés para la empresa. Siendo así, los datos tomados están en contraste con los clásicos procesos orientados a las aplicaciones. En la Figura N° 1 se muestra el contraste entre los dos tipos de orientaciones.

El ambiente operacional se diseña alrededor de las aplicaciones y funciones tales como préstamos, ahorros, tarjeta bancaria y depósitos para una institución financiera. Por ejemplo, una aplicación de ingreso de órdenes puede accesar a los datos sobre clientes, productos y cuentas. La base de datos combina estos elementos en una estructura que acomoda las necesidades de la aplicación. En el ambiente data warehousing se organiza alrededor de sujetos tales como cliente, vendedor, producto y actividad. Por ejemplo, para un fabricante, éstos pueden ser clientes, productos, proveedores y


99

vendedores. Para una universidad pueden ser estudiantes, clases y profesores. Para un hospital pueden ser pacientes, personal médico, medicamentos, etc. La alineación alrededor de las áreas de los temas afecta el diseño y la implementación de los datos encontrados en el data warehouse. Las principales áreas de los temas influyen en la parte más importante de la estructura clave. Las aplicaciones están relacionadas con el diseño de la base de datos y del proceso. En data warehousing se enfoca el modelamiento de datos y el diseño de la base de datos. El diseño del proceso (en su forma clásica) no es separado de este ambiente. Las diferencias entre la orientación de procesos y funciones de las aplicaciones y la orientación a temas, radican en el contenido de la data a nivel detallado. En el data warehouse se excluye la información que no será usada por el proceso de sistemas de soporte de decisiones, mientras que la información de las orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los requerimientos funcionales y de proceso, que pueden ser usados o no por el analista de soporte de decisiones. Otra diferencia importante está en la interrelación de la información. Los datos operacionales mantienen una relación continua entre dos o más tablas basadas en una regla comercial que está vigente. Las del data warehouse miden un espectro de tiempo y las relaciones encontradas en el data warehouse son muchas. Muchas de las reglas comerciales (y sus correspondientes relaciones de datos) se representan en el data warehouse, entre dos o más tablas. Integración El aspecto más importante del ambiente data warehousing es que la información encontrada al interior está siempre integrada. La integración de datos se muestra de muchas maneras: en convenciones de nombres consistentes, en la medida uniforme de variables, en la codificación de estructuras consistentes, en atributos físicos de los datos consistentes, fuentes múltiples y otros. El contraste de la integración encontrada en el data warehouse con la carencia de integración del ambiente de aplicaciones, se muestran en la Figura N° 2, con diferencias bien marcadas. A través de los años, los diseñadores de las diferentes aplicaciones han tomado sus propias decisiones sobre cómo se debería construir una aplicación. Los estilos y diseños personalizados se muestran de muchas maneras. Se diferencian en la codificación, en las estructuras claves, en sus características físicas, en las convenciones de nombramiento y otros. La capacidad colectiva de muchos de los diseñadores de aplicaciones, para crear aplicaciones inconsistentes, es fabulosa. La Figura N° 2 mencionada, muestra algunas de las diferencias más importantes en las formas en que se diseñan las aplicaciones. • Codificación. Los diseñadores de aplicaciones codifican el campo GENERO en varias formas. Un

diseñador representa GENERO como una "M" y una "F", otros como un "1" y un "0", otros como una "X" y una "Y" e inclusive, como "masculino" y "femenino". No importa mucho cómo el GENERO llega al data warehouse. Probablemente "M" y "F" sean tan buenas como cualquier otra representación. Lo importante es que sea de cualquier fuente de donde venga, el GENERO debe llegar al data warehouse en un estado integrado uniforme. Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicación, donde ha sido representado en formato "M" y "F", los datos deben convertirse al formato del data warehouse.

• Medida de atributos. Los diseñadores de aplicaciones miden las unidades de medida de las tuberías en una variedad de formas. Un diseñador almacena los datos de tuberías en centímetros, otros en pulgadas, otros en millones de pies cúbicos por segundo y otros en yardas.


100

Al dar medidas a los atributos, la transformación traduce las diversas unidades de medida usadas en las diferentes bases de datos para transformarlas en una medida estándar común.


101

Cualquiera que sea la fuente, cuando la información de la tubería llegue al data warehouse necesitará ser medida de la misma manera. • Convenciones de Nombramiento.- El mismo elemento es frecuentemente referido por nombres

diferentes en las diversas aplicaciones. El proceso de transformación asegura que se use preferentemente el nombre de usuario.

• Fuentes Múltiples.- El mismo elemento puede derivarse desde fuentes múltiples. En este caso, el proceso de transformación debe asegurar que la fuente apropiada sea usada, documentada y movida al depósito.

Tal como se muestra en la figura, los puntos de integración afectan casi todos los aspectos de diseño - las características físicas de los datos, la disyuntiva de tener más de una de fuente de datos, el problema de estándares de denominación inconsistentes, formatos de fecha inconsistentes y otros. Cualquiera que sea la forma del diseño, el resultado es el mismo - la información necesita ser almacenada en el data warehouse en un modelo globalmente aceptable y singular, aun cuando los sistemas operacionales subyacentes almacenen los datos de manera diferente. Cuando el analista de sistema de soporte de decisiones observe el data warehouse, su enfoque deberá estar en el uso de los datos que se encuentre en el depósito, antes que preguntarse sobre la confiabilidad o consistencia de los datos. De Tiempo Variante Toda la información del data warehouse es requerida en algún momento. Esta característica básica de los datos en un depósito, es muy diferente de la información encontrada en el ambiente operacional. En éstos, la información se requiere al momento de accesar. En otras palabras, en el ambiente operacional, cuando usted accesa a una unidad de información, usted espera que los valores requeridos se obtengan a partir del momento de acceso. Como la información en el data warehouse es solicitada en cualquier momento (es decir, no "ahora mismo"), los datos encontrados en el depósito se llaman de "tiempo variante". Los datos históricos son de poco uso en el procesamiento operacional. La información del depósito por el contraste, debe incluir los datos históricos para usarse en la identificación y evaluación de tendencias. (Ver Figura N° 3).


102

El tiempo variante se muestra de varias maneras: 1° La más simple es que la información representa los datos sobre un horizonte largo de tiempo - desde cinco a diez años. El horizonte de tiempo representado para el ambiente operacional es mucho más corto - desde valores actuales hasta sesenta a noventa días. Las aplicaciones que tienen un buen rendimiento y están disponibles para el procesamiento de transacciones, deben llevar una cantidad mínima de datos si tienen cualquier grado de flexibilidad. Por ello, las aplicaciones operacionales tienen un corto horizonte de tiempo, debido al diseño de aplicaciones rígidas. 2° La segunda manera en la que se muestra el tiempo variante en el data warehouse está en la estructura clave. Cada estructura clave en el data warehouse contiene, implícita o explícitamente, un elemento de tiempo como día, semana, mes, etc. El elemento de tiempo está casi siempre al pie de la clave concatenada, encontrada en el data warehouse. En ocasiones, el elemento de tiempo existirá implícitamente, como el caso en que un archivo completo se duplica al final del mes, o al cuarto. 3° La tercera manera en que aparece el tiempo variante es cuando la información del data warehouse, una vez registrada correctamente, no puede ser actualizada. La información del data warehouse es, para todos los propósitos prácticos, una serie larga de "snapshots" (vistas instantáneas). Por supuesto, si los snapshots de los datos se han tomado incorrectamente, entonces pueden ser cambiados. Asumiendo que los snapshots se han tomado adecuadamente, ellos no son alterados una vez hechos. En algunos casos puede ser no ético, e incluso ilegal, alterar los snapshots en el data warehouse. Los datos operacionales, siendo requeridos a partir del momento de acceso, pueden actualizarse de acuerdo a la necesidad. No Volátil La información es útil sólo cuando es estable. Los datos operacionales cambian sobre una base momento a momento. La perspectiva más grande, esencial para el análisis y la toma de decisiones, requiere una base de datos estable. En la Figura N° 4 se muestra que la actualización (insertar, borrar y modificar), se hace regularmente en el ambiente operacional sobre una base de registro por registro. Pero la manipulación básica de los datos que ocurre en el data warehouse es mucho más simple. Hay dos únicos tipos de operaciones: la carga inicial de datos y el acceso a los mismos. No hay actualización de datos (en el sentido general de actualización) en el depósito, como una parte normal de procesamiento. Hay algunas consecuencias muy importantes de esta diferencia básica, entre el procesamiento operacional y del data warehouse. En el nivel de diseño, la necesidad de ser precavido para actualizar las anomalías no es un factor en el data warehouse, ya que no se hace la actualización de datos. Esto significa que en el nivel físico de diseño, se pueden tomar libertades para optimizar el acceso a los datos, particularmente al usar la normalización y denormalización física. Otra consecuencia de la simplicidad de la operación del data warehouse está en la tecnología subyacente, utilizada para correr los datos en el depósito. Teniendo que soportar la actualización de registro por registro en modo on-line (como es frecuente en el caso del procesamiento operacional) requiere que la tecnología tenga un fundamento muy complejo debajo de una fachada de simplicidad.


103

La tecnología permite realizar backup y recuperación, transacciones e integridad de los datos y la detección y solución al estancamiento que es más complejo. En el data warehouse no es necesario el procesamiento. La fuente de casi toda la información del data warehouse es el ambiente operacional. A simple vista, se puede pensar que hay redundancia masiva de datos entre los dos ambientes. Desde luego, la primera impresión de muchas personas se centra en la gran redundancia de datos, entre el ambiente operacional y el ambiente de data warehouse. Dicho razonamiento es superficial y demuestra una carencia de entendimiento con respecto a qué ocurre en el data warehouse. De hecho, hay una mínima redundancia de datos entre ambos ambientes. Se debe considerar lo siguiente: • Los datos se filtran cuando pasan desde el ambiente operacional al de depósito. Existe mucha data que

nunca sale del ambiente operacional. Sólo los datos que realmente se necesitan ingresarán al ambiente de data warehouse.

• El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La información en el ambiente operacional es más reciente con respecto a la del data warehouse. Desde la perspectiva de los horizontes de tiempo únicos, hay poca superposición entre los ambientes operacional y de data warehouse.

• El data warehouse contiene un resumen de la información que no se encuentra en el ambiente operacional.

• Los datos experimentan una transformación fundamental cuando pasa al data warehouse. La mayor parte de los datos se alteran significativamente al ser seleccionados y movidos al data warehouse. Dicho de otra manera, la mayoría de los datos se alteran física y radicalmente cuando se mueven al depósito. No es la misma data que reside en el ambiente operacional desde el punto de vista de integración.

En vista de estos factores, la redundancia de datos entre los dos ambientes es una ocurrencia rara, que resulta en menos de 1%. ESTRUCTURA DEL DATA WAREHOUSE Los data warehouses tienen una estructura distinta. Hay niveles diferentes de esquematización y detalle que delimitan el data warehouse. La estructura de un data warehouse se muestra en la Figura N° 5.


104

En la figura, se muestran los diferentes componentes del data warehouse y son: • Detalle de datos actuales • Detalle de datos antiguos • Datos ligeramente resumidos • Datos completamente resumidos • Meta data • Detalle de datos actuales.- En gran parte, el interés más importante radica en el detalle de los datos

actuales, debido a que: • Refleja las ocurrencias más recientes, las cuales son de gran interés • Es voluminoso, ya que se almacena al más bajo nivel de granularidad. • Casi siempre se almacena en disco, el cual es de fácil acceso, aunque su administración sea costosa y

compleja. • Detalle de datos antiguos.- La data antigua es aquella que se almacena sobre alguna forma de

almacenamiento masivo. No es frecuentemente accesada y se almacena a un nivel de detalle, consistente con los datos detallados actuales. Mientras no sea prioritario el almacenamiento en un medio de almacenaje alterno, a causa del gran volumen de datos unido al acceso no frecuente de los mismos, es poco usual utilizar el disco como medio de almacenamiento.

• Datos ligeramente resumidos.- La data ligeramente resumida es aquella que proviene desde un bajo nivel de detalle encontrado al nivel de detalle actual. Este nivel del data warehouse casi siempre se almacena en disco. Los puntos en los que se basa el diseñador para construirlo son:

• Que la unidad de tiempo se encuentre sobre la esquematización hecha. • Qué contenidos (atributos) tendrá la data ligeramente resumida.

Datos completamente resumidos.- El siguiente nivel de datos encontrado en el data warehouse es el de los datos completamente resumidos

A veces se encuentra en el ambiente de data warehouse y en otros, fuera del límite de la tecnología que ampara al data warehouse. (De todos modos, los datos completamente resumidos son parte del data warehouse sin considerar donde se alojan los datos físicamente.) • Metadata.- El componente final del data warehouse es el de la metadata. De muchas maneras la

metadata se sitúa en una dimensión diferente al de otros datos del data warehouse, debido a que su contenido no es tomado directamente desde el ambiente operacional. La metadata juega un rol especial y muy importante en el data warehouse y es usada como:

• Un directorio para ayudar al analista a ubicar los contenidos del data warehouse. • Una guía para el mapping de datos de cómo se transforma, del ambiente operacional al de data

warehouse. • Una guía de los algoritmos usados para la esquematización entre el detalle de datos actual, con los

datos ligeramente resumidos y éstos, con los datos completamente resumidos, etc. . Estos datos son compactos y fácilmente La metadata juega un papel mucho más importante en un ambiente data warehousing que en un operacional clásico. A fin de recordar los diferentes niveles de los datos encontrados en el data warehouse, considere el ejemplo mostrado en la Figura N° 6. El detalle de ventas antiguas son las que se encuentran antes de 1992. Todos los detalles de ventas desde 1982 (o cuando el diseñador inició la colección de los archivos) son almacenados en el nivel de detalle de datos más antiguo.


105

El detalle actual contiene información desde 1992 a 1993 (suponiendo que 1993 es el año actual). En general, el detalle de ventas no se ubica en el nivel de detalle actual hasta que haya pasado, por lo menos, veinticuatro horas desde que la información de ventas llegue a estar disponible en el ambiente operacional. • accesibles.


106


107

En otras palabras, habría un retraso de tiempo de por lo menos veinticuatro horas, entre el tiempo en que en el ambiente operacional se haya hecho un nuevo ingreso de la venta y el momento cuando la información de la venta haya ingresado al data warehouse. El detalle de las ventas son resumidas semanalmente por línea de subproducto y por región, para producir un almacenamiento de datos ligeramente resumidos. El detalle de ventas semanal es adicionalmente resumido en forma mensual, según una gama de líneas, para producir los datos completamente resumidos. La metadata contiene (al menos): • La estructura de los datos • Los algoritmos usados para la esquematización • El mapping desde el ambiente operacional al data warehouse La información adicional que no se esquematiza es almacenada en el data warehouse. En muchas ocasiones, allí se hará el análisis y se producirá un tipo u otro de resumen. El único tipo de esquematización que se almacena permanentemente en el data warehouse, es el de los datos que son usados frecuentemente. En otras palabras, si un analista produce un resumen que tiene una probabilidad muy baja de ser usado nuevamente, entonces la esquematización no es almacenada en el data warehouse. ARQUITECTURA DE UN DATA WAREHOUSE Una de las razones por las que el desarrollo de un data warehouse crece rápidamente, es que realmente es una tecnología muy entendible. De hecho, data warehousing puede representar mejor la estructura amplia de una empresa para administrar los datos informacionales dentro de la organización. A fin de comprender cómo se relacionan todos los componentes involucrados en una estrategia data warehousing, es esencial tener una Arquitectura Data Warehouse. ARQUITECTURA DE UN DATA WAREHOUSE

Elementos constituyentes de una Arquitectura Data Warehouse Una Arquitectura Data Warehouse (Data Warehouse Architecture - DWA) es una forma de representar la estructura total de datos, comunicación, procesamiento y presentación, que existe para los usuarios finales que disponen de una computadora dentro de la empresa.


108

La arquitectura se constituye de un número de partes interconectadas: • Base de datos operacional / Nivel de base de datos externo • Nivel de acceso a la información • Nivel de acceso a los datos • Nivel de directorio de datos (Metadata) • Nivel de gestión de proceso • Nivel de mensaje de la aplicación • Nivel de data warehouse • Nivel de organización de datos • Base de datos operacional / Nivel de base de datos externo Los sistemas operacionales procesan datos para apoyar las necesidades operacionales críticas. Para hacer eso, se han creado las bases de datos operacionales históricas que proveen una estructura de procesamiento eficiente, para un número relativamente pequeño de transacciones comerciales bien definidas. Sin embargo, a causa del enfoque limitado de los sistemas operacionales, las bases de datos diseñadas para soportar estos sistemas, tienen dificultad al accesar a los datos para otra gestión o propósitos informáticos. Esta dificultad en accesar a los datos operacionales es amplificada por el hecho que muchos de estos sistemas tienen de 10 a 15 años de antigüedad. El tiempo de algunos de estos sistemas significa que la tecnología de acceso a los datos disponible para obtener los datos operacionales, es así mismo antigua. Ciertamente, la meta del data warehousing es liberar la información que es almacenada en bases de datos operacionales y combinarla con la información desde otra fuente de datos, generalmente externa. Cada vez más, las organizaciones grandes adquieren datos adicionales desde bases de datos externas. Esta información incluye tendencias demográficas, econométricas, adquisitivas y competitivas (que pueden ser proporcionadas por Instituciones Oficiales - INEI). Internet o también llamada "information superhighway" (supercarretera de la información) provee el acceso a más recursos de datos todos los días. • Nivel de acceso a la información El nivel de acceso a la información de la arquitectura data warehouse, es el nivel del que el usuario final se encarga directamente. En particular, representa las herramientas que el usuario final normalmente usa día a día. Por ejemplo: Excel, Lotus 1-2-3, Focus, Access, SAS, etc. Este nivel también incluye el hardware y software involucrados en mostrar información en pantalla y emitir reportes de impresión, hojas de cálculo, gráficos y diagramas para el análisis y presentación. Hace dos décadas que el nivel de acceso a la información se ha expandido enormemente, especialmente a los usuarios finales quienes se han volcado a las PCs monousuarias y las PCs en redes. Actualmente, existen herramientas más y más sofisticadas para manipular, analizar y presentar los datos, sin embargo, hay problemas significativos al tratar de convertir los datos tal como han sido recolectados y que se encuentran contenidos en los sistemas operacionales en información fácil y transparente para las herramientas de los usuarios finales. Una de las claves para esto es encontrar un lenguaje de datos común que puede usarse a través de toda la empresa. • Nivel de acceso a los datos El nivel de acceso a los datos de la arquitectura data warehouse está involucrado con el nivel de acceso a la información para conversar en el nivel operacional. En la red mundial de hoy, el lenguaje de datos común que ha surgido es SQL. Originalmente, SQL fue desarrollado por IBM como un lenguaje de consulta, pero en los últimos veinte años ha llegado a ser el estándar para el intercambio de datos. Uno de los adelantos claves de los últimos años ha sido el desarrollo de una serie de "filtros" de acceso a datos, tales como EDA/SQL para accesar a casi todo los Sistemas de Gestión de Base de Datos (Data Base Management Systems - DBMSs) y sistemas de archivos de datos, relacionales o no. Estos filtros permiten


109

a las herramientas de acceso a la información, accesar también a la data almacenada en sistemas de gestión de base de datos que tienen veinte años de antigüedad. El nivel de acceso a los datos no solamente conecta DBMSs diferentes y sistemas de archivos sobre el mismo hardware, sino también a los fabricantes y protocolos de red. Una de las claves de una estrategia data warehousing es proveer a los usuarios finales con "acceso a datos universales". El acceso a los datos universales significa que, teóricamente por lo menos, los usuarios finales sin tener en cuenta la herramienta de acceso a la información o ubicación, deberían ser capaces de accesar a cualquier o todos los datos en la empresa que es necesaria para ellos, para hacer su trabajo. El nivel de acceso a los datos entonces es responsable de la interfase entre las herramientas de acceso a la información y las bases de datos operacionales. En algunos casos, esto es todo lo que un usuario final necesita. Sin embargo, en general, las organizaciones desarrollan un plan mucho más sofisticado para el soporte del data warehousing. • Nivel de Directorio de Datos (Metadata) A fin de proveer el acceso a los datos universales, es absolutamente necesario mantener alguna forma de directorio de datos o repositorio de la información metadata. La metadata es la información alrededor de los datos dentro de la empresa. Las descripciones de registro en un programa COBOL son metadata. También lo son las sentencias DIMENSION en un programa FORTRAN o las sentencias a crear en SQL. A fin de tener un depósito totalmente funcional, es necesario tener una variedad de metadata disponibles, información sobre las vistas de datos de los usuarios finales e información sobre las bases de datos operacionales. Idealmente, los usuarios finales deberían de accesar a los datos desde el data warehouse (o desde las bases de datos operacionales), sin tener que conocer dónde residen los datos o la forma en que se han almacenados. • Nivel de Gestión de Procesos El nivel de gestión de procesos tiene que ver con la programación de diversas tareas que deben realizarse para construir y mantener el data warehouse y la información del directorio de datos. Este nivel puede depender del alto nivel de control de trabajo para muchos procesos (procedimientos) que deben ocurrir para mantener el data warehouse actualizado. • Nivel de Mensaje de la Aplicación El nivel de mensaje de la aplicación tiene que ver con el transporte de información alrededor de la red de la empresa. El mensaje de aplicación se refiere también como "subproducto", pero puede involucrar sólo protocolos de red. Puede usarse por ejemplo, para aislar aplicaciones operacionales o estratégicas a partir del formato de datos exacto, recolectar transacciones o los mensajes y entregarlos a una ubicación segura en un tiempo seguro. • Nivel Data Warehouse (Físico) En el data warehouse (núcleo) es donde ocurre la data actual, usada principalmente para usos estratégicos. En algunos casos, uno puede pensar del data warehouse simplemente como una vista lógica o virtual de datos. En muchos ejemplos, el data warehouse puede no involucrar almacenamiento de datos. En un data warehouse físico, copias, en algunos casos, muchas copias de datos operacionales y/o externos, son almacenados realmente en una forma que es fácil de accesar y es altamente flexible. Cada vez más, los data warehouses son almacenados sobre plataformas cliente/servidor, pero por lo general se almacenan sobre mainframes. • Nivel de Organización de Datos El componente final de la arquitectura data warehouse es la organización de los datos. Se llama también gestión de copia o réplica, pero de hecho, incluye todos los procesos necesarios como seleccionar, editar,


110

resumir, combinar y cargar datos en el depósito y accesar a la información desde bases de datos operacionales y/o externas. La organización de datos involucra con frecuencia una programación compleja, pero cada vez más, están creándose las herramientas data warehousing para ayudar en este proceso. Involucra también programas de análisis de calidad de datos y filtros que identifican modelos y estructura de datos dentro de la data operacional existente. Operaciones en un Data Warehouse En la Figura N° 8 se muestra algunos de los tipos de operaciones que se efectúan dentro de un ambiente data warehousing.

a) Sistemas Operacionales Los datos administrados por los sistemas de aplicación operacionales son la fuente principal de datos para el data warehouse. Las bases de datos operacionales se organizan como archivos indexados (UFAS, VSAM), bases de datos de redes/jerárquicas (I-D-S/II, IMS, IDMS) o sistemas de base de datos relacionales (DB2, Oracle, Informix, etc.). Según las encuestas, aproximadamente del 70% a 80% de las bases de datos de las empresas se organizan usando DBMSs no relacional. b) Extracción, Transformación y Carga de los Datos Se requieren herramientas de gestión de datos para extraer datos desde bases de datos y/o archivos operacionales, luego es necesario manipular o transformar los datos antes de cargar los resultados en el data warehouse. Tomar los datos desde varias bases de datos operacionales y transformarlos en datos requeridos para el depósito, se refiere a la transformación o a la integración de datos. Las bases de datos operacionales, diseñadas para el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato. Los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por diferentes software DBMS, pueden definirse al usar nombres de elementos inconsistentes, que tienen formatos inconsistentes y/o ser codificados de manera diferente. Todas estas inconsistencias deben resolverse antes


111

que los elementos de datos sean almacenados en el data warehouse. c) Metadata Otro paso necesario es crear la metadata. La metadata (es decir, datos acerca de datos) describe los contenidos del data warehouse. La metadata consiste de definiciones de los elementos de datos en el depósito, sistema(s) del (os) elemento(s) fuente. Como la data, se integra y transforma antes de ser almacenada en información similar. d) Acceso de usuario final Los usuarios accesan al data warehouse por medio de herramientas de productividad basadas en GUI (Graphical User Interface - Interfase gráfica de usuario). Pueden proveerse a los usuarios del data warehouse muchos de estos tipos de herramientas. Estos pueden incluir software de consultas, generadores de reportes, procesamiento analítico en línea, herramientas data/visual mining, etc., dependiendo de los tipos de usuarios y sus requerimientos particulares. Sin embargo, una sola herramienta no satisface todos los requerimientos, por lo que es necesaria la integración de una serie de herramientas. e) Plataforma del data warehouse La plataforma para el data warehouse es casi siempre un servidor de base de datos relacional. Cuando se manipulan volúmenes muy grandes de datos puede requerirse una configuración en bloque de servidores UNIX con multiprocesador simétrico (SMP) o un servidor con procesador paralelo masivo (MPP) especializado. Los extractos de la data integrada/transformada se cargan en el data warehouse. Uno de los más populares RDBMSs disponibles para data warehousing sobre la plataforma UNIX (SMP y MPP) generalmente es Teradata. La elección de la plataforma es crítica. El depósito crecerá y hay que comprender los requerimientos después de 3 o 5 años. Muchas de las organizaciones quieran o no escogen una plataforma por diversas razones: el Sistema X es nuestro sistema elegido o el Sistema Y está ya disponible sobre un sistema UNIX que nosotros ya tenemos. Uno de los errores más grandes que las organizaciones cometen al seleccionar la plataforma, es que ellos presumen que el sistema (hardware y/o DBMS) escalará con los datos. El sistema de depósito ejecuta las consultas que se pasa a los datos por el software de acceso a los datos del usuario. Aunque un usuario visualiza las consultas desde el punto de vista de un GUI, las consultas típicamente se formulan como pedidos SQL, porque SQL es un lenguaje universal y el estándar de hecho para el acceso a datos. f) Datos Externos Dependiendo de la aplicación, el alcance del data warehouse puede extenderse por la capacidad de accesar a la data externa. Por ejemplo, los datos accesibles por medio de servicios de computadora en línea (tales como CompuServe y America On Line) y/o vía Internet, pueden estar disponibles a los usuarios del data warehouse. Evolución del Depósito Construir un data warehouse es una tarea grande. No es recomendable emprender el desarrollo del data warehouse de la empresa como un proyecto cualquiera. Más bien, se recomienda que los requerimientos de una serie de fases se desarrollen e implementen en modelos consecutivos que permitan un proceso de implementación más gradual e iterativo. No existe ninguna organización que haya triunfado en el desarrollo del data warehouse de la empresa, en un sólo paso. Muchas, sin embargo, lo han logrado luego de un desarrollo paso a paso. Los pasos previos evolucionan conjuntamente con la materia que está siendo agregada.


112

Los datos en el data warehouse no son volátiles y es un repositorio de datos de sólo lectura (en general). Sin embargo, pueden añadirse nuevos elementos sobre una base regular para que el contenido siga la evolución de los datos en la base de datos fuente, tanto en los contenidos como en el tiempo. Uno de los desafíos de mantener un data warehouse, es idear métodos para identificar datos nuevos o modificados en las bases de datos operacionales. Algunas maneras para identificar estos datos incluyen insertar fecha/tiempo en los registros de base de datos y entonces crear copias de registros actualizados y copiar información de los registros de transacción y/o base de datos diarias. Estos elementos de datos nuevos y/o modificados son extraídos, integrados, transformados y agregados al data warehouse en pasos periódicos programados. Como se añaden las nuevas ocurrencias de datos, los datos antiguos son eliminados. Por ejemplo, si los detalles de un sujeto particular se mantienen por 5 años, como se agregó la última semana, la semana anterior es eliminada.


113

LECTURAS COMPLEMENTARIAS - TEORIA DE BASES DE DATOS: http://sql.manivesa.com/Manuales+SQL/134.aspx http://72.14.253.104/search?q=cache:oPOGZsvrc8AJ:www.dsic.upv.es/~fgarcia/ina/temario/BDTeoEUITI.ppt+TEORIA+DE+BASE+DE+DATOS&hl=es&ct=clnk&cd=5&gl=bo&lr=lang_es http://www.agapea.com/Teoria-de-Bases-de-Datos-cn259p1i.htm http://www.microsoft.com/spanish/MSDN/estudiantes/ssii/teoria/default.mspx

BIBLIOGRAFIA KORTH, HENRY, “Fundamentos de bases de datos”, España, McGRAW-HILL, 1999 DATE, J.C., “Sistemas de bases de datos”, España, ADDISON-WESLEY, 1995 HAWRYSZKIEWYCZ, “Análisis y Diseño de Bases de Datos”, , , JAMES MARTIN, “Organización de Bases de Datos”, México, PRENTICE HALL, 1998 GROFF, JAMES & WEINBER, PAUL, “Aplique SQL”, , , JOYANES AGUILAR, LUIS, ”Programación orientada a objetos”, España, McGRAW-HILL, 1998 BOOCH, GRADY, “Diseño orientado a objetos con aplicaciones “, España, McGRAW-HILL, 1991 RUMBAUGH, J. ; BLAHA, M., “Modelado y diseño orientado a objetos, España, PRENTICE HALL, 1995


114

GLOSARIO

1. Administración de Base de Datos Relacional: Técnica de admistración de bases de datos en la que la información se guarda en tablas de datos bidimensionales. El programa que funciona con dos tablas de datos al mismo tiempo, relaciona la información mediante vinculaciones establecidas por una columna o campos comunes.

2. Acceso: La manera en la cual los archivos o conjunto de datos son referenciados por la computadora.

3. ÇBase de datos distribuida (BDD): Conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones

4. BDOO: Bases de Datos Orientadas a Objetos 5. BDR: Bases de Datos por Relación 6. BLOB: Objetos Binarios de Gran Tamaño 7. BDOO94: Bases de Datos orientados a Objetos 94 8. Base de Datos: Es una serie de datos organizados y relacionados entre sí, los cuales son

recolectados y explotados por los Sistemas de Información de una empresa o negocio en particular.

9. Buscadores: O también llamados motores de búsqueda, son herramientas que permiten clasificar la información que existe en la red y hacerla localizable en poco tiempo según las preferencias del usuario.

10. Campo: Unidad básica de una base de datos, un campo puede ser, por ejemplo, el nombre de una persona. Los nombres de los campos, no pueden empezar con espacios en blanco y caracteres especiales. No pueden llevar puntos, ni signos de exclamación o corchetes. Si pueden tener espacios en blanco en el medio.

11. CAD: Diseño Asistido por Computadora 12. CAE: Ingeniería Apoyada por computadora 13. CORBA: (Common Object Request Broker Arquitecture) 14. Datos estadísticos: estos almacenan información estadística sobre los datos en la base de

datos. 15. El DBMS: es un conjunto de programas que se encargan de manejar la creación y todos los

accesos a las bases de datos. 16. ELIMINACION: Es una solicitud de eliminación que se expresa de forma muy parecida a

una consulta. Sin embargo, en vez de presentar tuplas al usuario, quitamos las tuplas seleccionadas de la base de datos. Sólo puede eliminar tuplas completas; no se puede eliminar únicamente valores de determinados atributos.

17. Facilidad de Consultas: Permitir al usuario hacer cuestiones sencillas a la base de datos. Este tipo de consultas tienen como misión proporcionar la información solicitada por el usuario de una forma correcta y rápida.

18. Formulario: es el elemento en forma de fecha que permite la gestión de los datos de una forma mas cómoda y visiblemente mas atractiva

19. Gestor de Base de Datos: Es un conjunto de programas que permiten crear y mantener una base de datos, asegurando su integridad, confidencialidad y seguridad.


115

20. Independencia de los datos: Se refiere a la protección contra los programas de aplicaciones que pueden originar modificaciones cuando se altera la organización física y lógica de las bases de datos.

21. JDBC: La Conectividad de Bases de Datos Java (Java Database Connectivity, JDBC) es una especificación de la interfaz de aplicación de programa (application program interface, API) para conectar los programas escritos en Java a los datos en bases de datos populares.

22. La manipulación de datos: la manipulación de datos es la recuperación de información almacenada en la base de datos

23. Lenguaje de consulta: Son los lenguajes en el que los usuarios solicitan información de la base de datos. Estos lenguajes son generalmente de más alto nivel que los lenguajes de programación. Los lenguajes de consulta pueden clasificarse como procedimentales y no procedimentales

24. LDD ó DDL: Lenguaje de definición de Datos 25. LMD ó DML: Lenguaje de Manejo de Datos 26. Manipulación de Base de Datos: Usando la base de Datos -- el usuario puede añadir,

borrar y modificar información a la base de datos así como también hacer consultas. 27. Modelo de base de datos orientado a objetos: es una adaptación a los sistemas de bases

de datos. Se basa en el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto.

28. Modelos de Red: Este modelo permite la representación de muchos a muchos de una Base de Datos. El modelo de red evita redundancia en la información, a través de la incorporación de un tipo de registro denominado el conector.

29. Nivel lógico: definición de las estructuras de datos que constituyen la base de datos 30. OO: Orientación a Objetos 31. ODL: Estándar de Definición de Lenguaje de Datos 32. OMG: Grupo Manejador de Objetos 33. OML: Lenguaje de Manipulación de Datos 34. ODMG: Gestión Manejadora de datos Objeto 35. OQL: Equivalente al SQL(Lenguaje de Consulta) 36. Reglas de Integridad: Son restricciones que definen los estados de consistencias de las

bases de datos. 37. DBMS: Es un conjunto de programas que se encarga de manejar la cremación y todos los

acceso a las bases de datos. 38. DDL: Es un lenguaje de definición de datos 39. Rectángulos: es parte de la estructura de base de datos y son aquellos que representan un

conjunto de entidades 40. Recuperación: Proporcionar como mínimo el mismo nivel de recuperación que los

sistemas de bases de datos actuales. De forma que, tanto en caso de fallo de hardware como de fallo de software, el sistema pueda retroceder hasta un estado coherente de los datos.

41. Sistema de Administración de Base de Dato: Es el softwware que controla la organización, almacenamiento, recuperación, seguridad e integridad de los datos en una base de datos.

42. SISTEMA GESTOR DE BASE DE DATOS (SGBD): Es un conjunto de programas que permiten crear y mantener una base de datos, asegurando su integridad, confidencialidad y seguridad.


116

43. Sistema de bases de datos distribuida (SBDD): Un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su sitio propio.

44. Sistema de manejo de bases de datos distribuidas (SMBDD): Aquel que se encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la distribución sea transparente a los usuarios. El término transparente significa que la aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutado en una sola máquina, administrara esos datos.

45. Sistema de base de datos distribuida (SBDD): El resultado de la integración de una base de datos distribuida con un sistema para su manejo.

46. Software: Es un sistema manejador de bases de datos que permite al usuario accesar con facilidad a los datos almacenados o que ande ser almacenados.

47. SQL: Lenguaje de Consulta Estructurado 48. SGBD: Sistema de Gestión de Bases de Datos 49. SGBDOO: Sistema de Gestión de Bases de Datos Orientada a Objeto 50. SO: Sistema Operativo 51. Transacción: es una secuencia de operaciones de acceso a la base de datos que constituye

una unidad lógica de ejecución. 52. Transacciones compartidas: Las transacciones compartidas soportan grupos de usuarios

en estaciones de trabajo, los cuales desean coordinar sus esfuerzos en tiempo real, los usuarios pueden compartir los resultados intermedios de una base de datos. La transacción compartida permite que varias personas intervengan en una sola transacción.

53. TUPLAS: Es la representación de una fila en una de las tablas que se esta almacenando datos. Y las cuales serán llamadas por los administradores de Base de Datos en el tiempo de ejecución de un sistema.

54. Usuario final: es quien accesa a las bases de datos por medio de un lenguaje de consulta o de programas de aplicación.

UNIDAD I I N T R O D U C C I O N BASES DE...

Documents

Transcript of UNIDAD I I N T R O D U C C I O N BASES DE...