BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS
COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS
RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS
COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS
RELACIONAL, ORIENTADO...
Pereira (día, mes, año)
Nota de aceptación:
______________________________
______________________________
________________...
DEDICATORIA
A decir verdad nuestro transcurso en la universidad fue un poco más difícil de lo
habitual, a pesar de ello, s...
AGRADECIMIENTOS
Es imposible evitar la influencia que tienen las personas sobre nosotros, después
de todo es por eso que e...
CONTENIDO
pág.
INTRODUCCIÓN..................................................................................................
2.1.1.2.6 Producto Cartesiano (×) ......................................................................... 31
2.1.1.2.7 T...
3.1 INTRODUCCION...................................................................................... 48
3.2 MODELO TEÓRI...
4.5.2 Lenguaje de consultas.............................................................................. 75
4.5.3 Optimiz...
6. ANALISIS COMPARATIVO ENTRE LOS MODELOS DE BASE DE
DATOS RELACIONAL Y ORIENTADO A OBJETOS VS MODELO DE BASE DE
DATOS ORI...
LISTADO DE TABLAS
Tabla 1. Ejemplos de Funciones de Agregación ................................................... 35
Tabl...
LISTADO DE FIGURAS
Figura 1. Componentes de un SGBD ....................................................................45...
13
INTRODUCCIÓN
En 1963 durante un simposio celebrado en california-Estados Unidos, se presentó
por primera vez el concept...
14
1. GENERALIDADES
1.1 DEFINICIÓN DEL PROBLEMA
Desde el surgimiento de las bases de datos en la década de los años 60, se...
15
aplicaciones soportadas en tecnologías abiertas y distribuidas como el Web. En
este escenario, Internet de manera gener...
16
1.2.2 Económica
La variedad de motores ofrece diversos modelos de licenciamiento que varían
desde los criterios de soft...
17
1.3 OBJETIVOS GENERAL Y ESPECÍFICOS
1.3.1 Objetivo general
Proponer un conjunto de características mínimas para la comp...
18
1.4 MARCO DE REFERENCIA
1.4.1 Marco Conceptual
Según C.J. Date [6] definimos los siguientes conceptos:
- Dato: Conjunto...
19
1.4.2 Marco teórico
En ciencias aplicadas, un Modelo matemático es uno de los tipos de modelos
científicos, que emplea ...
20
- Cabecera de la relación. Definida como el conjunto de n parejas atributo-dominio,
donde n es el grado de la relación....
21
Se pueden distinguir algunos constructores básicos como son: átomos, tuplas,
conjuntos, listas y arreglos. Se cuenta co...
22
M es un grupo de signatura de métodos bien formados para (C,  ,  )
G Es un grupo de nombres disjuntos de C
A partir d...
23
¿Qué es un objeto?
Los tipos de datos orientados a objetos son abstracciones de las entidades del
mundo real que se gua...
24
1.4.2.4 Modelo orientado a columnas
Según el artículo [5]. Las Bases de Datos orientados a columnas se introdujeron
por...
25
sistemas utilizan menos compresión o almacenan varias versiones de los datos
comprimidos, teniendo más espacio en disco...
26
2. MODELO DE BASE DE DATOS RELACIONAL
2.1 MODELO RELACIONAL
Los datos se han empleado para modelar el mundo real y esto...
27
También identifica tres elementos básicos que componen el modelo de datos
relacional, el componente estructural (conjun...
28
 las letras finales del alfabeto (X, X1 ,Y, Y’,…) para denotar los conjuntos de
atributos,
 las letras mayúsculas R ,...
29
atributos que componen la descripción de una entidad, y recordemos, que las
instanciaciones de esta son variantes en el...
30
Dada una relación r(X) y una fórmula proposicional F definida sobre X, la selección
de r con respecto a F, denotada por...
31
Lo habitual es realizar uniones, intersecciones y restas con esquemas
exactamente iguales.
2.1.1.2.5 Restricción O Teth...
32
Lo cual evidencia en palabras simples como el Theta-Join no es más que un
producto cartesiano condicionado.
2.1.1.2.8 N...
33
Las siguientes son las restricciones a considerar para garantizar la persistencia de
los datos
Una relación o tabla rel...
34
2.2.2 Algebra Relacional Extendida
Como expresa Rodríguez de León en su artículo [20], las operaciones básicas del
alge...
35
Tabla 1. Ejemplos de Funciones de Agregación
Fuente: Tema 3. El modelo relacional (op.cit)
La expresión del álgebra rel...
36
La relación resultante consistirá en las tuplas con los atributos usada para agrupar,
más los resultados de las funcion...
37
x R2.A1 x R1.A1 la operación en este caso se representa por y se
procede de la siguiente manera :
 Para aquellos valor...
38
A la hora de efectuar operaciones en el álgebra relacional que impliquen valores
nulos, hay que tener en cuenta que las...
39
2.2.2.6.1 Borrado
Las solicitudes de borrado se expresan básicamente igual que las consultas. Sin
embargo, en lugar de ...
40
2.3 MODELO TECNOLOGICO
2.3.1 Lenguajes De Consultas Relacionales
Una de las funciones básicas de los SGBD es la recuper...
41
sin interpretación. El álgebra y el cálculo relacional satisfacen estos principios [8] y
por esta razón se convierten e...
42
Una expresión representando la consulta del usuario tiene una forma estándar,
independientemente del contenido de la ba...
43
eliminada al menos parcialmente. Compartido por que las piezas individuales de
datos en la base pueden ser compartidas ...
44
Entre las funciones que ofrece al usuario un SGBD están la actualización,
recuperación y almacenamiento de datos, el ac...
45
Figura 1. Componentes de un SGBD
Fuente: Relational Database Theory 1993
2.3.2.3 Compilador De Consultas (Query Compile...
46
Figura 2. Compilación de una consulta
Fuente: Database System Implementation. 2000. (op.cit)
2.3.2.4 El Árbol Parse
Com...
47
operadores físicos que implementan los operadores lógicos, del orden que se
aplican operaciones iguales y de la forma e...
48
3. MODELO DE BASE DE DATOS ORIENTADO A OBJETOS
3.1 INTRODUCCION
Las bases de datos orientadas a objetos (BDOO) son aque...
49
Un objeto representa una entidad que tiene ciertas características. Los objetos que
comparten las mismas característica...
50
Un ejemplo de un tipo de valores complejos más implicado y de un valor de ese
conjunto es mostrado en la Figura 3 (a). ...
51
Una representación alternativa más en el “espíritu” de nuestras representaciones
de relaciones se muestra en la Figura ...
52
Figura 5. La base de datos CINEMA re-visitada (con información adicional
mostrada)
Fuente: Foundations of Databases. (o...
53
3.2.2 Modelo de Base de Datos de Valor Complejo
Como en el modelo relacional, usaremos nombres de relación en relname,
...
54
Finalmente, note que (a causa del conjunto vacío) un valor complejo puede
pertenecer a más de un tipo. Por ejemplo, el ...
55
El siguiente ejemplo es para ilustrar esta definición, una instancia J de {R1, R2, R3}
donde
sort(R1) = sort(R3) = A : ...
56
Figura 6. Una instancia de base de datos
Fuente: Foundations of Databases. (op.cit)
Una asunción más detallada (más rad...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO...
Upcoming SlideShare
Loading in …5
×

BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO A OBJETOS Y OBJETO RELACIONAL.

471 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
471
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO A OBJETOS Y OBJETO RELACIONAL.

  1. 1. BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO A OBJETOS Y OBJETO RELACIONAL MARIA DEL PILAR AZCÁRATE TORO ÁLVARO CÁRDENAS OROZCO UNIVERSIDAD TECNOLÓGICA DE PEREIRA FACULTAD DE INGENIERÍAS INGENIERÍA DE SISTEMAS Y COMPUTACIÓN PEREIRA 2011
  2. 2. BASES DE DATOS ORIENTADAS A COLUMNAS: UN ANÁLISIS COMPARATIVO FRENTE A LOS MODELOS DE BASES DE DATOS RELACIONAL, ORIENTADO A OBJETOS Y OBJETO RELACIONAL MARIA DEL PILAR AZCÁRATE TORO ÁLVARO CÁRDENAS OROZCO MONOGRAFÍA DIRECTOR INGENIERO JULIO CESAR CHAVARRO PORRAS Doctor En Ingeniería Área De Énfasis: Ciencias De La Computación Universidad Del Valle UNIVERSIDAD TECNOLÓGICA DE PEREIRA FACULTAD DE INGENIERÍAS INGENIERÍA DE SISTEMAS Y COMPUTACIÓN PEREIRA 2011
  3. 3. Pereira (día, mes, año) Nota de aceptación: ______________________________ ______________________________ ______________________________ ______________________________ ______________________________ ______________________________ ______________________________ Firma del presidente jurado ______________________________ Firma del jurado ______________________________ Firma del jurado
  4. 4. DEDICATORIA A decir verdad nuestro transcurso en la universidad fue un poco más difícil de lo habitual, a pesar de ello, si bien logramos hoy terminar nuestro proyecto de grado y estar a puertas de nuestro grado es debido a todas esas personas que creyeron en nosotros y nos apoyaron siempre, esta monografía, el esfuerzo y compromiso que pusimos en ella se lo dedicamos precisamente a nuestros padres, familia y evidente a nosotros mismos, pues cada uno de ellos hizo parte de una ecuación que nos empuja hoy hacia el resto de nuestras vidas y que gracias a Dios se balanceó siempre apuntando a nuestro éxito actual, de verdad muchas gracias.
  5. 5. AGRADECIMIENTOS Es imposible evitar la influencia que tienen las personas sobre nosotros, después de todo es por eso que el hombre es un ser social, para aprender de otros e impactar su entorno de igual manera que este lo empuja a él hacia adelante, es precisamente por ello que hoy queremos agradecer a todas esas personas que de alguna manera nos ayudaron a madurar en este proceso llamado universidad, y que inspiraron en nosotros solo sueños grandes, por ello agradecemos a nuestros amigos, que siempre estuvieron ahí, a todos esos profesores que nos llenaron la cabeza de ilusiones de éxito y por sobre todo a entender el conocimiento como una función de vida, a la institución que hoy nos brindó un espacio para crecer a su sombra y finalmente a Dios, pues es a él que le debemos la vida misma, de verdad, muchas gracias a todos, porque sin ustedes no seriamos las personas de las cuales nos sentimos orgullosos hoy y las cuales esperan poder retribuir ese amor de todos ustedes en algún momento no muy lejano de nuestras vidas.
  6. 6. CONTENIDO pág. INTRODUCCIÓN...................................................................................................13 1. GENERALIDADES................................................................................... 14 1.1 DEFINICIÓN DEL PROBLEMA................................................................ 14 1.2 JUSTIFICACIÓN ...................................................................................... 15 1.2.1 Tecnológica.............................................................................................. 15 1.2.2 Económica................................................................................................ 16 1.2.3 Académica................................................................................................ 16 1.3 OBJETIVOS GENERAL Y ESPECÍFICOS............................................... 17 1.3.1 Objetivo general ....................................................................................... 17 1.3.2 Objetivos específicos................................................................................ 17 1.4 MARCO DE REFERENCIA...................................................................... 18 1.4.1 Marco Conceptual .................................................................................... 18 1.4.2 Marco teórico............................................................................................ 19 1.4.2.1 Modelo Relacional.................................................................................... 19 1.4.2.2 Modelo orientado a objetos ...................................................................... 20 1.4.2.3 Modelo objeto relacional........................................................................... 22 1.4.2.4 Modelo orientado a columnas ..................................................................24 2. MODELO DE BASE DE DATOS RELACIONAL ...................................... 26 2.1 MODELO RELACIONAL .......................................................................... 26 2.1.1 Componentes Del Modelo........................................................................ 27 2.1.1.1 Estructuras ............................................................................................... 27 2.1.1.2 Operadores .............................................................................................. 29 2.1.1.2.1 Proyección.............................................................................................. 29 2.1.1.2.2 Selección ................................................................................................ 29 2.1.1.2.3 Renombramiento .................................................................................... 30 2.1.1.2.4 Unión, Intersección Y Resta ...................................................................30 2.1.1.2.5 Restricción O Tetha-Select.....................................................................31
  7. 7. 2.1.1.2.6 Producto Cartesiano (×) ......................................................................... 31 2.1.1.2.7 Theta-Join............................................................................................... 31 2.1.1.2.8 Natural Join............................................................................................. 32 2.1.1.2.9 División ...................................................................................................32 2.1.1.3 Restricciones............................................................................................ 32 2.2 MODELO DE DATOS RELACIONAL EXTENDIDO .................................33 2.2.1 Conceptualización .................................................................................... 33 2.2.2 Algebra Relacional Extendida ..................................................................34 2.2.2.1 Proyección Generalizada ......................................................................... 34 2.2.2.2 Funciones De Agregación ........................................................................ 34 2.2.2.3 Reunión Externa....................................................................................... 36 2.2.2.4 Valores Nulos ........................................................................................... 37 2.2.2.5 Otras Operaciones Adicionales ................................................................ 38 2.2.2.5.1 Ampliación ........................................................................................... 38 2.2.2.5.2 Resumen Ω............................................................................................. 38 2.2.2.6 Modificaciones De La Base De Datos ...................................................... 38 2.2.2.6.1 Borrado...................................................................................................39 2.2.2.6.2 Inserción .................................................................................................39 2.2.2.6.3 Actualización........................................................................................... 39 2.3 MODELO TECNOLOGICO ...................................................................... 40 2.3.1 Lenguajes De Consultas Relacionales..................................................... 40 2.3.1.1 Definición De Consulta............................................................................. 40 2.3.1.2 Paradigmas De Consulta.......................................................................... 41 2.3.1.2.1 Consultas basadas en el Algebra Relacional.......................................... 41 2.3.2 Optimización De Consultas ...................................................................... 41 2.3.2.1 Optimización............................................................................................. 41 2.3.2.2 Sistemas De Gestión De Bases De Datos ............................................... 42 2.3.2.2.1 Datos ...................................................................................................... 42 2.3.2.2.2 Hardware ................................................................................................ 43 2.3.2.2.3 Software..................................................................................................43 2.3.2.3 Compilador De Consultas (Query Compiler) ............................................ 45 2.3.2.4 El Árbol Parse .......................................................................................... 46 2.3.2.5 Generador De Planes De Consulta .......................................................... 46 2.3.2.6 Plan Físico................................................................................................ 46 3. MODELO DE BASE DE DATOS ORIENTADO A OBJETOS................... 48
  8. 8. 3.1 INTRODUCCION...................................................................................... 48 3.2 MODELO TEÓRICO................................................................................. 48 3.2.1 Objetos complejos.................................................................................... 49 3.2.2 Modelo de Base de Datos de Valor Complejo.......................................... 53 3.2.3 Operadores .............................................................................................. 57 3.2.4 Descripción De Una Base De Datos Orientada A Objetos ....................... 60 3.2.5 Restricciones............................................................................................ 61 3.3 MODELO TECNOLÓGICO ...................................................................... 62 3.3.1 Conceptos Relacionados Con Las Bases De Datos Orientadas A Objetos 62 3.3.2 Origen de las Bases de Datos Orientadas a Objetos ............................... 62 3.3.3 ODMG: El Estándar De Facto Para Modelos De Objetos ........................ 63 3.3.4 Características de las Bases de Datos Orientadas a Objetos y diferencias de éstas con respecto a las relacionales............................................................... 64 3.3.5 Lenguaje De Consulta Y De Manipulación............................................... 65 3.3.6 Optimización De Consultas ...................................................................... 67 4. MODELO DE BASE DE DATOS OBJETO RELACIONAL ....................... 70 4.1 INTRODUCCIÓN...................................................................................... 70 4.2 DEFINICION DEL MODELO ....................................................................71 4.3 DESCRIPCIÓN DEL MODELO ................................................................ 72 4.3.1 Modelo de datos....................................................................................... 72 4.4 DISEÑO DEL MODELO ........................................................................... 72 4.4.1 Métodos....................................................................................................72 4.4.2 Tipos de colecciones................................................................................ 72 4.5 BASES DE DATOS OBJETO RELACIONALES ...................................... 73 4.5.1 Objetos.....................................................................................................73 4.5.1.1 Tipos......................................................................................................... 73 4.5.1.2 Estructura.................................................................................................73 4.5.1.3 Estructura de un tipo de objeto.................................................................74 4.5.1.4 Características ......................................................................................... 74 4.5.1.5 Componentes ........................................................................................... 75 4.5.1.6 Atributos ...................................................................................................75
  9. 9. 4.5.2 Lenguaje de consultas.............................................................................. 75 4.5.3 Optimización de consultas Objeto-Relacional .......................................... 75 4.6 CONSIDERACIONES ENTRE EL MODELO ORDBMS Y RDBMS.......... 76 4.6.1 Rendimiento en la base de datos ............................................................. 76 4.6.2 Cantidad de código................................................................................... 77 4.6.3 Tiempo de diseño más eficiente............................................................... 77 4.6.4 Normalización........................................................................................... 77 5. MODELO DE BASE DE DATOS ORIENTADO A COLUMNAS ............... 78 5.1 INTRODUCCIÓN...................................................................................... 78 5.2 EL MODELO DE DATOS ......................................................................... 83 5.2.1 RS ............................................................................................................ 88 5.2.2 Esquemas de codificación........................................................................ 88 5.2.3 Join a los índices...................................................................................... 88 5.2.4 WS............................................................................................................ 89 5.3 ADMINISTRACIÓN DE ALMACENAMIENTO.......................................... 90 5.4 ACTUALIZACIONES Y TRANSACCIONES............................................. 90 5.5 PROPORCIONAR AISLAMIENTO INSTANTÁNEO.................................91 5.6 EL MANTENIMIENTO DE LA COTA MÁXIMA......................................... 92 5.7 EL COMPROMISO DEL PROCESAMIENTO DISTRIBUIDO .................. 93 5.8 ROLLBACK TRANSACTION....................................................................93 5.9 RECUPERACIÓN..................................................................................... 94 5.10 RECUPERACIÓN EFICAZ DE LA SE...................................................... 94 5.11 MOVER TUPLA........................................................................................ 95 5.12 C-STORE DE EJECUCIÓN DE CONSULTAS......................................... 96 5.13 OPTIMIZACIÓN DE CONSULTAS........................................................... 97
  10. 10. 6. ANALISIS COMPARATIVO ENTRE LOS MODELOS DE BASE DE DATOS RELACIONAL Y ORIENTADO A OBJETOS VS MODELO DE BASE DE DATOS ORIENTADO A COLUMNAS ...................................................................99 6.1 CARACTERÍSTICAS DE LOS MODELOS DE LAS BASES DE DATOS PROPUESTOS...................................................................................................... 99 6.1.1 Características del modelo de base de datos relacional .......................... 99 6.1.2 Características Del Modelo De Bases De Datos Orientado A Objetos...100 6.1.3 Características Del Modelo De Bases De Datos Objeto Relacional....... 101 6.1.3.1 Extensiones en las capacidades de los SGBDOR vs. SGBDR: ............. 102 6.1.4 Características del Modelo de Bases De Datos Orientado a Columnas.102 6.2 VENTAJAS Y DESVENTAJAS DE LOS MODELOS DE BASES DE DATOS PROPUESTOS ...................................................................................... 103 6.2.1 Ventajas y Desventajas del SGBDR....................................................... 103 6.2.2 Ventajas y Desventajas del SGBDOO.................................................... 104 6.2.3 Ventajas y Desventajas del SGBDOR.................................................... 105 6.2.4 Ventajas y Desventajas del SGBDOC.................................................... 106 6.3 ANALISIS COMPARATIVO DE LOS MODELOS PROPUESTOS ......... 108 7. CONCLUSIONES................................................................................... 112 BIBLIOGRAFÍA....................................................................................................114
  11. 11. LISTADO DE TABLAS Tabla 1. Ejemplos de Funciones de Agregación ................................................... 35 Tabla 2. Operaciones lógicas con valores desconocidos ...................................... 37 Tabla 3. Datos de la tabla EMP............................................................................. 84
  12. 12. LISTADO DE FIGURAS Figura 1. Componentes de un SGBD ....................................................................45 Figura 2. Compilación de una consulta .................................................................46 Figura 3. Valor complejo (a) Un tipo y un valor de ese tipo ...................................50 Figura 4. Valor complejo (b) Otra presentación del mismo valor........................... 50 Figura 5. La base de datos CINEMA re-visitada (con información adicional mostrada) .............................................................................................................. 52 Figura 6. Una instancia de base de datos ............................................................. 56 Figura 7. Operaciones algebraicas........................................................................ 59 Figura 8. Proceso de optimización de consultas OO............................................. 68 Figura 9. Estructura de un tipo objeto....................................................................74 Figura 10. Arquitectura de C-Store........................................................................ 82 Figura 11. Un índice de reunión de EMP3 a EMP1............................................... 87 Figura 12. Funcionamiento de HWM.....................................................................93
  13. 13. 13 INTRODUCCIÓN En 1963 durante un simposio celebrado en california-Estados Unidos, se presentó por primera vez el concepto de base de datos, las aplicaciones ganaban día a día complejidad y era evidente la necesidad de dividir las aplicaciones de software en módulos especializados, durante este simposio se expuso entonces, que era posible separar los datos de las aplicaciones. Esta idea surge dado que la estructura de los datos no cambia en el tiempo significativamente, en cambio los lenguajes y plataformas tecnológicas si lo hacen, por tanto, podemos tratar el almacenado de datos y el que hacer de los mismos, como problemas aparte que posteriormente habremos de integrar, se definió entonces, una base de datos como un conjunto de información relacionada que se encuentra agrupada o estructurada. Desde entonces, se han presentado gran variedad de modelos que soporten plataformas tecnológicas para el almacenamiento de datos, y esto ha generado una competencia que ha traído consigo la evolución constante, tanto de los modelos teóricos, como de su implementación tecnológica. Actualmente la evolución del internet, ha traído consigo nuevos retos desde la perspectiva del almacenamiento de los datos y de igual manera, las nuevas necesidades que aparecen en esta sociedad digital, es por esto, que nuestra investigación busca mostrar que diferencias trae consigo la nueva tecnología de base de datos llamada Base de Datos Orientada a Columnas con sus predecesoras, y para ello, se habrá de expresar con rigor los modelos de bases de datos, desde su soporte teórico hasta su implementación tecnológica, caracterizarlos, y a partir de esto, realizar el análisis comparativo.
  14. 14. 14 1. GENERALIDADES 1.1 DEFINICIÓN DEL PROBLEMA Desde el surgimiento de las bases de datos en la década de los años 60, se han propuesto múltiples modelos teóricos y estos han sido usados en diferentes herramientas tecnológicas. Es evidente que cada modelo tiene características que lo diferencian de los otros y que debemos conocer con claridad, para seleccionar un modelo acorde con el problema de almacenamiento de datos y que facilite la decisión sobre la herramienta tecnológica que se usará en la implementación de la solución. Los sistemas de información requieren cubrir distintas necesidades de persistencia que provienen del dominio que se modela y de los usuarios del sistema. Es a partir de esas necesidades, que se determinan los requerimientos funcionales y no funcionales de las bases de datos que participan de la solución. Esta solución puede diferir de una aplicación a otra, y por consiguiente es de vital importancia identificar con precisión en que contextos es mejor un modelo u otro. Los modelos son independientes de la tecnología. En la actualidad existe una variedad importante de motores de base de datos los cuales operan de diversas maneras sobre los datos, razón por la cual este estudio servirá de soporte para comparaciones futuras entre gestores de bases de datos, partiendo de las diferencias existentes entre los modelos de datos que les subyacen y de la forma que operan sobre los datos y su implementación. Según Ramos y otros [1], la evolución de las redes de comunicación e Internet han ocasionado que los fondos documentales, que actualmente están accesibles a través de internet, sean de diversa naturaleza (catálogos estructurados con diferentes colecciones de datos, páginas digitalizadas, textos transcritos, etc.), estén en diferentes formatos (ASCII,HTML, XML, SGML, etc.) y soporten diferentes plataformas (desde sistemas de gestión de bases de datos orientados a objetos, entre los demás modelos de bases de datos, hasta ficheros planos). Estas restricciones limitan la cantidad y la calidad de la información que puede extraerse de estos fondos documentales ya que dificultan el acceso a los mismos, haciendo que pueda ser necesario acceder a los diferentes fondos por separado y realizar, sobre todos ellos, consultas para poder encontrar lo deseado. Ante esta problemática no es solo necesario diferenciar las bases de datos, sino definir muy bien los modelos de datos que habrán de representar la información y como lograr una interfaz global que nos permita relacionarlas todas. Las nuevas tendencias de desarrollo en la ingeniería de software, y la prospectiva del campo de las TIC’s, comparten como escenario común, la construcción de
  15. 15. 15 aplicaciones soportadas en tecnologías abiertas y distribuidas como el Web. En este escenario, Internet de manera general y en particular la Web, ha planteado nuevos retos a nivel de la persistencia en el desarrollo de aplicaciones, trayendo soluciones como las propuestas en las bases de datos orientadas a columnas. Junto a estas tecnologías que se están desarrollando aparece como un nuevo problema a los desarrolladores de aplicaciones, poder determinar: ¿Qué criterios se deben tener en cuenta para poder comparar las tecnologías de persistencia? ¿Cuándo se debe utilizar un modelo de bases de datos determinado? ¿Son las bases de datos orientadas a columnas un modelo o una tecnología? ¿En qué casos esta tecnología es más adecuada que la soportada por los modelos más populares? 1.2 JUSTIFICACIÓN 1.2.1 Tecnológica El rápido crecimiento en la oferta de sistemas de bases de datos comerciales y académicas, nos hace pensar que asistimos a una explosión de sistemas de gestión de bases de datos (SGBD), conocidos comercialmente como motores de bases de datos. Son tantos y de tan diverso tipo que en este campo se generan nuevas inquietudes en torno a cómo hacer para realizar una selección adecuada. En este contexto: surge la inquietud puntual de ¿Cuál será el SGBD más adecuado para un sistema de información determinado?, y ¿Cuáles son los criterios para poderlos comparar entre sí? Responder a estas preguntas requiere de una comparación teórica de los modelos y desde este campo, determinar las variables que en el plano tecnológico son determinantes. Debido a la cantidad de herramientas, es difícil evaluar o comparar los diferentes motores, por esta razón, partimos de comparar de los modelos de bases de datos que les subyacen dado que estos modelos determinan características fundamentales. Otros aspectos, por ejemplo los relacionados con el uso, estabilidad, capacidad de procesamiento y rendimiento, son utilizados para seleccionar una herramienta específica, después de haber determinado el modelo conceptual que mejor se ajusta a un problema específico. Para poder identificar los dominios de uso de las bases de datos orientadas a columnas es necesario conocer las limitaciones y potencialidades de las tecnologías soportadas en el modelo relacional, orientadas a objetos y objeto relacional.
  16. 16. 16 1.2.2 Económica La variedad de motores ofrece diversos modelos de licenciamiento que varían desde los criterios de software open source hasta motores licenciados por usuario o por procesador con inversiones de varios miles de dólares. Es evidente que el costo de implementación de cada aplicación en un motor determinado y su nivel de dificultad al hacerlo, es diferente, lo cual implica que este análisis siempre que articule un proceso de selección de un modelo de bases de datos tendrá un impacto económico. 1.2.3 Académica En el programa de Ingeniería de Sistemas y Computación de la Universidad tecnológica de Pereira, no se han elaborado proyectos de grado en el área de Bases de Datos orientados a columnas. Este proyecto de grado servirá como insumo académico en el área y además, se espera que sirva de base para proyectos de grado futuros referentes a esta temática. Se considera que este análisis comparativo permitirá tener una herramienta teórica preliminar para el estudio, selección y evaluación de los modelos de bases de datos relacionales, objeto relacional, orientado a objetos y orientado a columnas en diferentes contextos.
  17. 17. 17 1.3 OBJETIVOS GENERAL Y ESPECÍFICOS 1.3.1 Objetivo general Proponer un conjunto de características mínimas para la comparación teórica y tecnológica de las bases de datos orientadas a columnas, frente a las que están soportadas en los modelos de datos Relacional, orientado a Objetos y Objeto relacional. 1.3.2 Objetivos específicos Establecer si las bases de datos orientadas a Columnas corresponden a un modelo teórico o conceptual, o si por el contrario son un modelo exclusivamente tecnológico. Determinar los criterios tecnológicos con los cuales se habrá de comparar las bases de datos orientadas a columnas con los diferentes motores que soportan otros modelos de bases de datos. Determinar en qué familias de problemas es procedente utilizar bases de datos orientadas a columnas como mecanismo de persistencia.
  18. 18. 18 1.4 MARCO DE REFERENCIA 1.4.1 Marco Conceptual Según C.J. Date [6] definimos los siguientes conceptos: - Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, o alfanuméricos. - Información: Es un conjunto ordenado de datos los cuales son manejados según la necesidad del usuario, para que un conjunto de datos pueda ser procesado eficientemente y pueda dar lugar a información, primero se debe guardar lógicamente en archivos. - Campo: Es la unidad más pequeña a la cual uno puede referirse en un programa. Desde el punto de vista del programador representa una característica de un individuo u objeto. - Registro: Colección de campos de iguales o de diferentes tipos. - Archivo: Colección de registros almacenados siguiendo una estructura homogénea. - Base de datos: Es una colección de archivos interrelacionados, son creados con un DBMS. El contenido de una base de datos engloba a la información concerniente (almacenadas en archivos) de una organización, de tal manera que los datos estén disponibles para los usuarios, una finalidad de la base de datos es eliminar la redundancia o al menos minimizarla. Los tres componentes principales de un sistema de base de datos son el hardware, el software DBMS y los datos a manejar, así como el personal encargado del manejo del sistema. - Sistema Manejador de Base de Datos (DBMS): Un DBMS es una colección de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de una tarea específica. El objetivo primordial de un sistema manejador de base de datos es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer, almacenar y manipular información de la base de datos. Todas las peticiones de acceso a la base, se manejan centralizadamente por medio del DBMS, por lo que este paquete funciona como interface entre los usuarios y la base de datos. - Esquema de base de datos: Es la estructura por la que está formada la base de datos, se especifica por medio de un conjunto de definiciones que se expresa mediante un lenguaje especial llamado lenguaje de definición de datos. (DDL).
  19. 19. 19 1.4.2 Marco teórico En ciencias aplicadas, un Modelo matemático es uno de los tipos de modelos científicos, que emplea algún tipo de formulismo matemático para expresar relaciones, proposiciones sustantivas de hechos, variables, parámetros, entidades y relaciones entre variables y/o entidades u operaciones, para estudiar comportamientos de sistemas complejos ante situaciones difíciles de observar en la realidad. De lo anterior se entiende que los modelos de datos se componen de tres partes principalmente: - Elementos: son todos aquellos componentes que conforman el conjunto. - Operadores: son los componentes que permiten interactuar a los elementos entre sí. - Restricciones: son las reglas que limitan el dominio de las relaciones entre elementos de tal manera que los elementos resultantes nunca se salgan de la influencia del modelo. A continuación nos concentraremos en caracterizar los modelos de estudio de datos, para los componentes antes nombrados. 1.4.2.1 Modelo Relacional Según el autor del artículo: Problemas Actuales Y Perspectivas En El Campo De Las Bases De Datos [2]. El modelo relacional está fundamentado en la teoría matemática de las relaciones y se complementa en la teoría de la lógica matemática conocida como cálculo de predicados. El concepto básico es el de relación. Una definición formal puede ser expresada como un subconjunto del producto cartesiano de los dominios que definen a R: r (R)  (dom (A1) X dom (A2) X ......X dom (An)) Donde el producto cartesiano especifica todas las combinaciones posibles de valores de los dominios indicados. Suponiendo que todos los dominios son finitos, entonces podemos decir que, en un momento dado, el estado de una relación es el conjunto de las tuplas válidas que representan los valores del mundo real. En toda relación es posible advertir los siguientes elementos: - Nombre que identifica la relación, aunque pueden presentarse relaciones que no poseen nombre cuando son el resultado de una operación.
  20. 20. 20 - Cabecera de la relación. Definida como el conjunto de n parejas atributo-dominio, donde n es el grado de la relación. Una forma de representarlo es: {(Ai, Di)} para i=1....n. - Cuerpo de la Relación. Conjunto de m tuplas, donde cada tupla está conformada por parejas atributo–valor. Representados por {(Ai, Vij)} i=1...n. En este caso Vij, representa el valor j-ésimo que puede ser tomado en el dominio i para el atributo i. El número de tuplas de la relación recibe el nombre de cardinalidad. La definición de la cabecera y el nombre de la relación constituyen lo que se denomina el esquema de una relación. Adicionalmente se conoce como la intensión de la relación. En las relaciones el concepto de conjunto, implica que no existen repeticiones y el orden no es determinante. Adicionalmente cada Relación debe tener un atributo, o conjunto de atributos, que permita identificar cada tupla como única y al cual se le reconocerá como clave primaria. Las relaciones capturan los aspectos estáticos del minimundo del discurso, los aspectos de las inter-relaciones que existen entre objetos serán modeladas a partir de la inclusión de la clave primaria en otra relación donde se conocerá como clave foránea. De otra parte, las restricciones que representan las reglas del negocio, son representadas mediante las reglas de integridad de entidades, de dominio, de clave, y de integridad referencial. Para concluir con los aspectos estáticos del modelo, se definen las siguientes operaciones para la definición de los datos: Inserción, actualización y eliminación de tuplas.[2]. El modelo original establecido por CODD, contaba con un álgebra soportada en los operadores de: Selección. Proyección, Reunión, Unión, Intersección, Diferencia, División y Producto Cartesiano, lo cual permitía la interacción con los datos, de tal manera que todas las operaciones que se realizan entre relaciones, o sobre una relación, dan como resultado una nueva relación. 1.4.2.2 Modelo orientado a objetos Según Rob y otro [7] el modelo OO describe tanto datos como sus relaciones en una sola estructura conocida como objeto. Formalmente un objeto consiste de una tripleta (identificador de objeto, constructor, valor). El identificador del objeto es único por cada objeto y el valor del identificador está definido en un dominio asumido como infinito; el constructor del objeto es una especificación de cómo se construye el valor del objeto y el valor es conocido como el estado del objeto.
  21. 21. 21 Se pueden distinguir algunos constructores básicos como son: átomos, tuplas, conjuntos, listas y arreglos. Se cuenta con un Dominio D que contiene todos los valores atómicos que se encuentran disponibles directamente en el sistema, entre estos se encuentran los enteros, reales, booleanos, cadenas de caracteres, y las fechas. En los sistemas orientados a objeto puro, puede existir una restricción adicional a que todo debe ser un objeto, con su correspondiente estructura. Un ejemplo de un objeto para una base de datos es el siguiente (oid22, [title: “the trouble with harry”, director: oid77, actors: {oid81, oid176, oid77}]) Hasta este punto, el modelo refleja el aspecto estático de los objetos, para adicionar comportamiento debemos referirnos a los métodos. En cada método encontramos tres componentes: nombre, signatura y cuerpo o implementación. El nombre corresponde a un grupo infinito donde cada nombre debe ser único. La signatura (también conocida como firma) especifica los tipos involucrados en la especificación funcional del método, es decir, describe el dominio y el rango de los tipos que participan en la descripción de la función que puede ser ejecutada sobre el objeto. El cuerpo es la forma como se espera implementar la solución al método. [2]. El concepto de encapsulamiento, hace referencia a la unidad que se establece entre información y procedimientos para su actualización, consulta o definición. Esto implica que la ocultación de la información es básica en los modelos orientados a objetos. Toda información está oculta y no existen operadores generales para su manipulación, por el contrario, para cada objeto se define cuáles son los métodos que están permitidos sobre su estructura y como puede ser vista o manipulada su información. Esto permite que exista una colección de métodos disponibles sobre un objeto y los cuales se reconocerán como una interfaz del objeto. Un objeto puede compartir atributos, o métodos, con otros objetos de clases diferentes, lo cual da lugar a la existencia de nuevos conceptos: Jerarquías de clases, Jerarquías de tipos, herencia múltiple, herencia selectiva y polimorfismo. De manera formal podemos definir esquema de una base de datos y su instancia como sigue: Un esquema es una tupla de grado 5, S=(C,,,M,G), donde: C Grupo de nombres de tipos  Es un mapeado de C U G a tipos (C) (C,  ,  ) es una clase jerárquicamente bien formada
  22. 22. 22 M es un grupo de signatura de métodos bien formados para (C,  ,  ) G Es un grupo de nombres disjuntos de C A partir de lo cual se pude decir que una instancia del esquema es una tupla de grado 4: I = (, , , ), donde:  Es un oid único  Mapea cada oid a un valor correcto de tipos  Asocia a cada nombre en G de tipo () un valor en el dominio de   Asigna semántica a los métodos en concordancia con M. Según en el artículo [2]. Como se puede observar la estructura estática y la dinámica se encuentran unificadas en el objeto. El modelo se complementa con un cálculo orientado a objetos el cual es una generalización del cálculo de valores complejos, extendido a objetos, igualdad y métodos. El lenguaje de consulta es propio a cada sistema gestor, varios esfuerzos se han realizado en pro de una estandarización. Lo más popular es O2SQL. 1.4.2.3 Modelo objeto relacional Según el autor de Diseños de Bases de Datos Objeto-Relacionales con UML [3]. El modelo objeto relacional también se conoce como el modelo relacional extendido ya que incluye nuevas funciones y extensiones soportadas por los objetos. Actualmente la opinión sobre las definiciones del modelo objeto relacional están muy dividas, una definición sencilla podría ser: El modelo objeto-relacional (ORDBMS) es similar a un front-end dentro de una base de datos relacional que permite que los datos sean grabados como objetos, sin embargo todos los metadatos y la información siguen utilizando el sistema de filas y columnas para este propósito de tal forma que la base de datos pueda ser abordada también como una base de datos relacional. Y así mismo cuando los datos son recuperados la base de datos tiene la capacidad de reconstruir nuevamente los datos simples a objetos complejos.
  23. 23. 23 ¿Qué es un objeto? Los tipos de datos orientados a objetos son abstracciones de las entidades del mundo real que se guardan en la base de datos, un objeto es un esquema compuesto por un OID (Y que puede manejarse como llave primaria), un nombre, y un conjunto de métodos. ¿Que son los UDTs y UDFs? Corresponden a los nuevos tipos de datos y nuevas funciones personalizadas por el usuario. Los UDTs se pueden clasificar en 3 tipos: De tipo distintivo, tipo opaco o de base y tipo fila o compuesto. Los datos de carácter opaco o de base son datos no derivados de otro tipo de datos, sus estructuras puede deben ser definidas dentro del DBMS con sus respectivas operaciones y funciones. Después de ser definidos pueden usarse como base para la creación de datos tipo distintivos y de tipo fila para ser usando en objetos. Los datos tipo fila pueden incluir más datos de tipo fila de forma anidada. Los datos de tipo distintivo son derivados de otro tipo de datos, manejan sus propios dominios, operaciones (Sobrecarga) y funciones. De ahí que su definición como objeto pueda ser fuertemente tipada lo que ayuda a mejorar la integridad de los datos. Dentro del modelo OR existen tres tipos de métodos cada uno con un respectivo constructor, ellos son: 1. Métodos tipo miembro: Permite modelar el comportamiento de los objetos 2. Métodos tipos estático: Permite modelar el objeto en su totalidad 3. Método tipo comparación: Permite realizar comparaciones entre el objeto original e instancias de este. Tipo de colección: 1. Tipo Arreglo 2. Tipo tabla Ambos tipos de colecciones son del mismo tipo de datos, sin embargo su diferencia radica en que el tipo arreglo es un conjunto ordenado, y limitado mientras que un tipo de tabla es un conjunto desordenado y sin límite alguno. Las tablas pueden anidarse siendo manejadas por medio del objeto tipo fila. También el modelo ORDBMS soporta dos tipos de vistas, el viejo tipo de vista clásica en una tabla y la nueva vista de tipo objeto. Por medio de las vistas tipo objeto es posible crear tablas virtuales de objetos que manejen UDTs y UDFs, las vistas de objeto también tienen la ventaja de producir vistas con datos de tipo relacional adjuntos a una vista objeto previa.
  24. 24. 24 1.4.2.4 Modelo orientado a columnas Según el artículo [5]. Las Bases de Datos orientados a columnas se introdujeron por primera vez en 1970 en productos como Model 204 y ABABAS, este enfoque ha resurgido recientemente en Vertica y en cierta medida en QD Technology. Como su nombre lo indica, las bases de datos están organizadas por columnas en lugar de filas: es decir, todos los casos de un solo elemento de datos (por ejemplo, Nombre de cliente) se almacenan de modo que se puede acceder como una unidad. Esto los hace especialmente eficaces en las consultas analíticas, como la lista de selección, que a menudo lee unos pocos elementos de datos, pero necesitamos ver todas las instancias de estos elementos. En contraste, una base de datos relacional convencional, almacena los datos por filas, por lo que toda la información de un registro (fila) es inmediatamente accesible. Esto tiene sentido para las consultas transaccionales, que suelen referirse a un registro a la vez. Hoy los sistemas orientados a columnas combinan su estructura orientada a columnas con técnicas que incluyen la indexación, compresión y paralelización. Tiempo de carga: ¿Cuánto tiempo se necesita para convertir datos de origen en el formato de columna? Esta es la pregunta más básica de todas. Los tiempos de carga son medidos en gigabytes por hora, que puede ser extremadamente lento, cuando de decenas o cientos de gigabytes de datos se trata. La cuestión a menudo carece de una respuesta sencilla, porque la velocidad de carga puede variar en función de la naturaleza de los datos y las elecciones realizadas por el usuario. Por ejemplo, algunos sistemas pueden almacenar varias versiones de los mismos datos, ordenados en diferentes secuencias o en los diferentes niveles de agregación. Los usuarios pueden construir un menor número de versiones a cambio de una carga rápida, pero puede pagar un precio más adelante con consultas más lentas. Pruebas realistas basadas en sus propios datos son el mejor camino para una respuesta clara. Carga Incremental: Una vez que un conjunto de datos se ha cargado, todo debe ser recargado cada vez que hay una actualización. Muchos sistemas orientados a columnas permiten carga incremental, teniendo sólo los registros nuevos o modificados y la fusión de los datos anteriores. Pero la atención al detalle es fundamental, ya que las funciones de carga incremental varían ampliamente. Algunas cargas incrementales tardan hasta una completa reconstrucción y, algunos pueden agregar registros, pero no cambiarlos o suprimirlos. Las Cargas incrementales a menudo deben completarse periódicamente con una reconstrucción completa. Compresión de datos: Algunos sistemas orientados a columnas pueden comprimir mucho la fuente de datos y archivos resultantes a fin de tomar una fracción de espacio en el disco original. Puede ocasionar en estos casos un impacto negativo en el rendimiento, por la descompresión de datos al realizar la lectura. Otros
  25. 25. 25 sistemas utilizan menos compresión o almacenan varias versiones de los datos comprimidos, teniendo más espacio en disco, pero cobrando otros beneficios a cambio. El enfoque más adecuado dependerá de sus circunstancias. Tenga en cuenta que la diferencia de los requisitos de hardware pueden ser sustanciales. Limitaciones estructurales: Las bases de datos orientados a columnas utilizan diferentes técnicas para imitar una estructura relacional. Algunas requieren la misma clave principal en todas las tablas, es decir, la jerarquía de la base de datos está limitada a dos niveles. Los límites impuestos por un sistema en particular no parecen tener importancia, pero recuerde que sus necesidades pueden cambiar mañana. Limitaciones que parecen aceptables ahora, podría evitar la ampliación del sistema en el futuro. Técnicas de acceso: Algunas bases de datos orientadas a columnas sólo se pueden acceder utilizando su propio proveedor de lenguaje de consultas y herramientas. Estos pueden ser muy poderosos, incluyendo capacidades que son difíciles o imposibles usando el estándar SQL. Pero a veces faltan funciones especiales, tales como las consultas que comparan valores con o en los registros. Si necesita acceder al sistema con herramientas basadas en SQL, determine exactamente qué funciones SQL y dialectos son compatibles. Es casi siempre un subconjunto completo de SQL y, en particular, rara vez se dispone de las actualizaciones. También asegúrese de encontrar si el rendimiento de las consultas SQL es comparable a los resultados con el sistema de la propia herramienta de consulta. Rendimiento: Los sistemas orientados a columnas por lo general superan a los sistemas de relaciones en casi todas las circunstancias, pero el margen puede variar ampliamente. Las consultas que incluyen cálculos o acceso individuales a los registros puede ser tan lentos o más que un sistema relacional adecuadamente indexado. Escalabilidad: El punto de las bases de datos orientadas a columnas es obtener buenos resultados en grandes bases de datos. Pero no puede asumir que todos los sistemas pueden escalar a decenas o centenares de terabytes. Por ejemplo, el rendimiento puede depender de determinados índices de carga en la memoria, de modo que su equipo debe tener memoria suficiente para hacer esto. Como siempre, en primer lugar, preguntar si el vendedor tiene en ejecución los sistemas existentes a una escala similar a la suya y hablar con las referencias para obtener los detalles. Si el suyo fuera más grande que cualquiera de las instalaciones existentes, asegúrese de probar antes de comprar.
  26. 26. 26 2. MODELO DE BASE DE DATOS RELACIONAL 2.1 MODELO RELACIONAL Los datos se han empleado para modelar el mundo real y esto ha causado la necesidad de tener diferentes niveles expresivos para representarlo, por esta razón se han propuesto diferentes modelos de datos, dando la claridad de que para definir los datos se utiliza un modelo y para su manipulación un lenguaje. Existen diversos modelos de datos que soportan las tecnologías de almacenamiento de información teniendo claridad en que la finalidad fundamental de los SGBD es garantizar la persistencia de los datos. Actualmente, para la mayoría de las aplicaciones de gestión que utilizan bases de datos, el modelo más empleado es el modelo relacional, por su gran versatilidad, potencia y por los formalismos matemáticos sobre los que se basa. Este modelo permite representar la información del mundo real de una manera intuitiva, introduciendo conceptos cotidianos y fáciles de entender. El modelo relacional fue propuesto por E.F. Codd en los laboratorios de IBM en California. Se trata de un modelo lógico, que construye una estructura que aunque fue diseñada para dar soporte al almacenamiento de datos, se fundamentó en las teorías de conjuntos1 y la lógica proposicional, es de aclarar que si bien modelamos los datos y sus relaciones, éstos datos habrán de ser almacenados de múltiples formas para aprovechar características físicas concretas de la máquina sobre la que se implanta la base de datos realmente. Es algo así como guardar unos libros en una biblioteca; dependiendo del área de la biblioteca, del tamaño, la forma, el número de estantes, y en definitiva, de las características físicas del sitio, podremos disponer los libros de una forma u otra para hacer más cómoda, fácil y eficiente su consulta y acceso. Los libros son los mismos, pero podemos ubicarlos de muchas formas, emplear diversas metodologías y contratar diversas técnicas de atención al cliente, entre otras consideraciones. A continuación expondremos las características concretas de este modelo de datos, sin entrar a profundidad en el cómo se almacenan físicamente los datos en cada ordenador, o cada S.G.B.D. Según Codd [8], el modelo relacional caracteriza las relaciones como estructura fundamental para describir y organizar los datos, y el álgebra relacional para manipularla. 1 Para conocer a profundidad la exposición de Codd y la teoría de conjuntos que el plantea observar la bibliografía [8].
  27. 27. 27 También identifica tres elementos básicos que componen el modelo de datos relacional, el componente estructural (conjunto de relaciones que varían en el tiempo), el componente de manipulación (un conjunto de reglas u operadores para la manipulación de datos) y el componente de integridad (un conjunto de reglas de integridad para asegurar estados consistentes de la base de datos). 2.1.1 Componentes Del Modelo 2.1.1.1 Estructuras Marta Millán en su texto “Notas de referencia para la asignatura fundamentos de bases de datos” [9] expone: Intuitivamente las relaciones se asocian con tablas nombradas cuyas columnas representan atributos que también pueden tener asociado un nombre, las filas de las tablas son tuplas, los valores que toman las tuplas se extraen de conjuntos constantes llamados dominios, todas las tablas constituyen una estructura de la base de datos que se representan en un esquema de bases de datos (nivel intencional) y su contenido en una instancia de bases de datos (nivel extensional). Es decir: Esquema de base de datos: la instanciación de una relación. Atributo: abstracción de una característica de un objeto. Dominio: valores posibles que puede tomar un atributo. Relación: conjunto de atributos que describen una entidad. Para describir el modelo de datos relacional Millán [9] expone la siguiente notación:  att, un conjunto contable infinito de atributos con un orden total.  dom, un conjunto contable infinito, disjunto con respecto a att, llamado dominio.  relname, un conjunto contable infinito de nombres de relaciones con dominio propio.  var, un conjunto infinito de variables que toman valores sobre elementos de dom. Como notación estándar se utilizan:  las primeras letras del alfabeto en mayúsculas o con subíndices (A, B, A ,A’ ,…) para denotar los atributos individuales,
  28. 28. 28  las letras finales del alfabeto (X, X1 ,Y, Y’,…) para denotar los conjuntos de atributos,  las letras mayúsculas R , S para denotar nombres de relaciones,  el mismo nombre del esquema en letra minúscula (i.e. rk es una instancia de relación definida sobre el esquema Rk ) para denotar las instancias de relaciones, teniendo k por constante.  letras en negrita R, R1 para denotar los esquemas de base de datos. Se define una relación R a partir de n conjuntos S1, S2,…, Sn consistiendo de tuplas de aridad n en donde cada elemento i toma valores en Si. En la relación R cada fila representa una n–tupla distinta. El orden de las filas no es importante pero si el de las columnas. Las diferentes relaciones o tablas, variantes en el tiempo, integran la base de datos. Un esquema de relación es un nombre de relación R. Un esquema de base de datos es un conjunto finito no vacío R de nombres de relación, el cual podemos representar según Elmasri – Navathe [10] como un subconjunto del producto cartesiano de los dominios de los atributos que definen a R. r(R) (dom (A1)× dom (A2)×… ×dom (An)) Sea u una tupla definida sobre U. El valor de u para un atributo A en U es u(A). Cuando V U, u [V] representa a la tupla v de V tal que v(A) = u(A) para cada A V. Enfoques para el modelo Relacional  Enfoques nombrado y no-nombrado Dependiendo de si se considera importante el nombre de los atributos asignados a las columnas de una relación o su orden, el modelo relacional se puede formular desde dos perspectivas: uno nombrado y otro no-nombrado. Bajo la primera, el nombrado, los atributos forman parte, explícitamente, del esquema de la base de datos. Una tupla u se define a partir de un esquema de relación R[U] y se escribe, usualmente, utilizando como sintaxis (A1 : a1, A2 : a2,…, Ak : ak). En el segundo, el no-nombrado, solo se tiene en cuenta la aridad del esquema de una relación. Una tupla es una n-tupla ordenada (n 0) de constantes. La i-ésima coordenada de una tupla u es u(i). Es de anotar, que todas las puestas en escena del modelo relacional para el soporte de SGBD en la actualidad, están soportadas desde la perspectiva nombrada del modelo, y esto se debe, a que la implementación de este enfoque es computacionalmente menos costoso, pues tiene un orden estático para los
  29. 29. 29 atributos que componen la descripción de una entidad, y recordemos, que las instanciaciones de esta son variantes en el tiempo, por lo cual, asumiendo que el orden de los atributos no sea importante durante los cambios constantes de una relación determinada, se generaría un costo computacional gigantesco el hacer consultas a partir de un atributo especifico. 2.1.1.2 Operadores Antes de comenzar es de vital importancia recordar que como resultado de cada operación, por tratarse de operaciones entre conjuntos, se eliminen las tuplas idénticas, siempre y cuando se cumplan las restricciones de integridad (es decir, el modelo y su implementación se ha aplicado correctamente a un sistema de información). 2.1.1.2.1 Proyección Dada una relación r(X) y un subconjunto Y de X, la proyección de r sobre Y, denotada por y (r), es una relación definida sobre los atributos en Y que restringe los atributos de r a los atributos en Y. y (r) = { t (Y) | t r} Es decir, que el resultado de esta operación será un conjunto que tendrá por elementos todos aquellos valores que pertenecen a los dominios de cada una de los atributos que a su vez pertenecen al conjunto de Y y al universo de la relación r. 2.1.1.2.2 Selección Este operador se define con respecto a una fórmula proposicional. Sea r una relación definida sobre un conjunto de atributos X. Una fórmula proposicional F sobre X se define recursivamente a partir de átomos y conectivos de la siguiente forma. Los átomos son de la forma A1 A2 ó A1 a, donde, a es una constante y es uno de los operadores de comparación <, , =, , >, . Cada átomo definido sobre X es una fórmula proposicional sobre X. Si F1, F2 son fórmulas proposicionales definidas sobre X, también lo son ¬(F1), F1 F2 y F1 F2. Una fórmula proposicional tiene asociado un valor booleano (true, false). Es decir, F es simplemente una formula proposicional que delimita las tuplas en una consulta.
  30. 30. 30 Dada una relación r(X) y una fórmula proposicional F definida sobre X, la selección de r con respecto a F, denotada por F (r) es la relación: F (r) = {t r |F (t) = true} El conjunto resultante de esta operación será entonces, como dice la expresión, el subconjunto t que pertenece a r tal que cada tupla que conforma a t, cumpla con la premisa proposicional F. 2.1.1.2.3 Renombramiento Operador unario que cambia el nombre de los atributos en una relación. Dada una relación r sobre atributos X y una función inyectiva f definida sobre X (que asigna un nuevo nombre a cada atributo), el re nombramiento de r con respecto a f, se define como: ρf (r) = {t | existe t’ r tal que t’[A] = t [f (A)] para todo A X} Es decir, al aplicar esta operación a una relación r, obtenemos una relación t, dicha relación podrá ser cambiada de las siguientes dos formas:  cambia el nombre de la relación.  cambia el nombre de un atributo o conjunto de atributos. Esta operación también nos sirve para hacer copias de una relación. La relación resultante contiene las mismas tuplas que el esquema original. 2.1.1.2.4 Unión, Intersección Y Resta Estas son operaciones típicas de conjuntos en donde evidentemente las relaciones deben ser compatibles, lo cual significa que las relaciones involucradas tienen el mismo número de atributos y mismo dominio dos a dos de tal suerte que: R1 (A1, A2,... An) R2 (B1, B2,… Bn) Para todo i, 1 ≤ i ≤ n, Dom (Ai) = Dom (Bi) El resultado de estas operaciones será otra relación que al estar fundamentada en la lógica de conjuntos, no repite tuplas. En la relación resultante, los atributos serán los de la relación que pongamos como primer operando.
  31. 31. 31 Lo habitual es realizar uniones, intersecciones y restas con esquemas exactamente iguales. 2.1.1.2.5 Restricción O Tetha-Select Sea un operador de comparación <, , =, , >, aplicable al atributo A y a la tupla c . R [A c] es el conjunto de tuplas de R, cada una de cuyas A-componentes satisface la condición con respecto a la tupla c. Otros atributos B de R pueden aparecer en lugar de la tupla c, teniendo en cuenta que A y B estén definidos sobre un dominio común. Cuando es la igualdad, el tetha-Select se llama SELECT. 2.1.1.2.6 Producto Cartesiano (×) Combina relaciones. Sean R y S relaciones de aridad n y m respectivamente. R × S = { r(1),..., r(n), s(1),..., s(m) | r R, s S} Esta es una operación binaria. No exige que las relaciones sean compatibles. R1 (A1, ..., An) × R2 (B1, ..., Bm) → R (A1, ..., An, B1, ..., Bm) La relación resultante, R, contiene tuplas con los atributos de ambas relaciones. Pero esas tuplas son el resultado de combinar cada una de las tuplas de la primera relación con todas las de la segunda. 2.1.1.2.7 Theta-Join Sean R(A, B1) y S (B2, C) relaciones con B1, B2 definidos sobre un dominio común y uno de los operadores de comparación <, , =, , >, aplicable al dominio de los atributos B1, B2. El Theta-Join de R y S, denotado por R [B1 B2] S, es la concatenación de filas de R con filas de S en donde la B1-componente de la fila en R satisface la relación con respecto a la B2-componente de la fila S, es decir que el Theta-Join no es más que un producto cartesiano condicionado. Cuando es la igualdad el operador se llama EQUI-JOIN. Si las relaciones R y S tienen atributos comunes, los nombres de los atributos en la relación resultante se deben especificar. En realidad se da la siguiente correspondencia: R1 f R2 ≡ σf (R1 × R2)
  32. 32. 32 Lo cual evidencia en palabras simples como el Theta-Join no es más que un producto cartesiano condicionado. 2.1.1.2.8 Natural Join Sean r1 (YX) y r2 (XZ) dos relaciones, tal que YX XZ = X. El join natural de r1 y r2, denotado por r1 r2, es una relación definida sobre YXZ consistente en todas las tuplas resultantes de concatenar tuplas en r1 con tuplas en r2 que tengan el mismo valor en X. r1 r2 = {t sobre YXZ | existen t1 r1, t2 r2 tal que t [XY] = t1[XY] y t[XZ] = t2[XZ]}, Es decir, que se seleccionan aquellas tuplas cuyos valores coincidan en los atributos con igual nombre. 2.1.1.2.9 División Dadas relaciones R (A, B1) y S (B2, C) con B1, B2 definidas sobre mismo dominio, R [B1÷B2], es el subconjunto maximal de R [A] tal que su producto cartesiano con S [B2] está incluido en R. Contraparte algebraica del cuantificador universal. Esta operación adquiere una vital importancia cuando requerimos consultas en las que se busca que algún atributo de una relación tome (al menos) todos los valores de otro atributo en otra relación (para todo). 2.1.1.3 Restricciones El modelo relacional inicialmente propuesto por Codd [8] se enriquece semánticamente mediante la definición de restricciones de integridad dado que Las restricciones son reglas que siempre deben cumplirse de modo de apoyar la integridad de la base de datos (es decir, que la base de datos cumpla fielmente con el mundo modelado). Varios tipos de restricciones han sido propuestas y particularmente las de dependencia de datos han sido ampliamente estudiadas [8]. Un interesante problema relacionado con las dependencias, que ha sido también estudiado ampliamente, tiene que ver con la implicación de dependencias a partir de un conjunto de éstas. Por otra parte, el estudio de las dependencias también se relaciona con el diseño de esquemas de bases de datos. Si se parte de una relación universal y se aplican estrategias de descomposición para obtener formas normales se pueden obtener buenos esquemas.
  33. 33. 33 Las siguientes son las restricciones a considerar para garantizar la persistencia de los datos Una relación o tabla relacional tiene asociada exactamente una llave primaria (PK), cuyo valor identifica una tupla o fila de manera única (propiedad de unicidad). Si la llave primaria es compuesta (combinación de varios atributos) y alguno de sus atributos se quita, no se garantiza la propiedad de unicidad, a esta segunda propiedad se le llama minimalidad. Restricción de dominio: El valor de cada atributo A debe ser un valor atómico del dominio dom(A). Restricción de clave: Dos tuplas no pueden tener la misma clave. Integridad de la entidad: Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo. Integridad referencial: Si una relación R2 (relación que referencia) tiene un descriptor que es la clave primaria de la relación R1 (relación referenciada), todo valor de dicho descriptor debe concordar con un valor de la clave primaria de R1 o ser nulo. El descriptor es una clave ajena o foránea de la relación R2. 2.2 MODELO DE DATOS RELACIONAL EXTENDIDO 2.2.1 Conceptualización Lo que se buscó desde un principio con la extensión del modelo relacional fue poder incrementar el poder expresivo del mismo dándole componentes nuevos que permitieran expresar mejor el mini mundo de discurso. Con este fin Smith y Smith [13] presentan los conceptos de generalización y agregación. El modelo de datos semántico de Hammer y McLeod[18] introdujo los conceptos de clase y subclase, así como otros conceptos avanzados de modelamiento. Posteriormente se incluyen los conceptos de generalización y especialización, lo que permitió identificar con claridad la jerarquía de los componentes del conjunto universal y la integración de estos con el concepto de herencia. Evidentemente se planteó una extensión del algebra relacional con el fin de incluir estos nuevos conceptos en la manipulación de los datos, esta fue llamada algebra relacional extendida.
  34. 34. 34 2.2.2 Algebra Relacional Extendida Como expresa Rodríguez de León en su artículo [20], las operaciones básicas del algebra relacional se han ampliado de varias maneras para poder efectuar operaciones que son de uso común en la base de datos o que resuelven una determinada problemática. Una ampliación sencilla es permitir operaciones aritméticas como parte de la proyección, la cual posibilita implementar campos calculados. Una ampliación importante es permitir operaciones de agregación, como el cálculo de la suma de los elementos de un conjunto, o su media, que permiten obtener resultados a partir de estas funciones que operan sobre determinadas agrupaciones de los atributos de la relación. Otra ampliación importante es la operación reunión externa, que posibilita efectuar operaciones similares al producto natural, pero que permite a las expresiones del álgebra relacional trabajar con los valores nulos que modelan la información que falta. 2.2.2.1 Proyección Generalizada La operación proyección generalizada se define en [20] como la ampliación de la operación proyección permitiendo que se utilicen funciones aritméticas en la lista de proyección. La operación proyección generalizada tiene la forma: F1, F2, …, Fn(E) Donde E es cualquier expresión del algebra relacional y F1, F2,..., Fn son expresiones aritméticas. De forma trivial, la expresión aritmética puede ser simplemente un atributo o una constante. Además esta ampliación de la operación proyección [21] permite incluir campos calculados posibilitando además nombrar de nuevo estos nuevos atributos. 2.2.2.2 Funciones De Agregación Las funciones de agregación [20] son funciones que toman una colección de valores y devuelven como resultado un único valor. Las funciones de agregación más habituales son: sum (Suma), avg (Media aritmética), count (número de elementos), min y max (Mínimo y máximo, respectivamente). En la siguiente tabla se muestran algunos ejemplos de funciones de agregación.
  35. 35. 35 Tabla 1. Ejemplos de Funciones de Agregación Fuente: Tema 3. El modelo relacional (op.cit) La expresión del álgebra relacional para el uso de una función de agregación es f(a)(R) Donde f es la función de agregación, R es la relación considerada, ya es el atributo a utilizar. Las funciones de agregación toman como entrada una colección de valores y devuelven como resultado un valor resumen. Por ejemplo: sum(sueldo)(empleado) Es una relación con un único atributo [20], que contiene una sola fila con un valor correspondiente a la suma de los sueldos de todos los empleados. Las colecciones en las que operan las funciones de agregación pueden tener valores repetidos; el orden en el que aparezcan los valores no tiene importancia. Pero hay casos en los que se desea borrar los valores repetidos antes de calcular la función de agregación. Es posible dividir una relación en grupos, y aplicar las funciones de agregación de forma independiente en cada grupo. La sintaxis sería así: G1, G2, …, Gn F1(a1), F2(a2), …, Fm(am)(E) Donde E [20] es cualquier expresión del álgebra relacional; G1, G2,..., Gn, constituyen una lista de atributos que indican cómo se realiza la agrupación, cada Fi es una función de agregación y cada Ai es el nombre de un atributo, es decir [2]: a1 es el atributo de E donde se aplica la función F1 a2 es el atributo de E donde se aplica la función F2 . . . am es el atributo de E donde se aplica la función Fm
  36. 36. 36 La relación resultante consistirá en las tuplas con los atributos usada para agrupar, más los resultados de las funciones de agregación. 2.2.2.3 Reunión Externa La operación reunión externa [20][21] es una ampliación de la operación reunión natural dado que añade tuplas a la relación resultante teniendo en cuenta los valores faltantes y asumiéndolos como valores nulos. Esta operación tiene tres formas diferentes: reunión externa por la izquierda, denotada por , reunión externa por la derecha, denotada por y reunión externa completa, denotada por . La reunión externa por la izquierda ( ) toma todas las tuplas de la relación de la izquierda que no coincidan con ninguna tupla de la relación de la derecha, las rellena con valores nulos en todos los demás atributos de la relación de la derecha y las añade al resultado de la reunión natural. La reunión externa por la derecha ( ) es simétrica de la reunión externa por la izquierda. La reunión externa completa ( ) realiza estas dos operaciones, rellenando las tuplas de la relación de la izquierda que no coincidan con ninguna tupla de la relación de la derecha y las tuplas de la relación de la derecha que no coincidan con ninguna tupla de la relación de la izquierda, y añadiéndolas al resultado de la reunión. En esta operación [21] surgen los siguientes casos, sean R1 y R2 dos relaciones cuyo atributo común es A1, ahora bien si los conjuntos R1.A1, R2.a1 son iguales no hay problema de reunión externa y la problemática de reunión de las dos relaciones se resuelve con la operación producto natural R1 R2. La problemática en que interviene reunión externa se produce cuando los conjuntos R1.A1 y R2.a1 son diferentes. Caso (a) Reunión Externa por la izquierda: Se puede aplicar cuando el siguiente predicado es verdadero: x R1.A1 x R2.A1, la operación en este caso se representa por y se procede de la siguiente manera:  Para aquellos valores en R1.A1 R2.A1 (Los que están en ambos) se aplica la operación producto natural.  x R1.A1 x R2.A1 se aplica de nuevo el producto natural asumiendo que la tupla (Null, Null,......x,....Null) existe en R2. Caso (b) Reunión externa por la derecha: Se puede aplicar cuando el siguiente predicado es verdadero:
  37. 37. 37 x R2.A1 x R1.A1 la operación en este caso se representa por y se procede de la siguiente manera :  Para aquellos valores en R1.A1 R2.A1 se aplica la operación producto natural  x R2.A1 x R1.A1 se aplica de nuevo el producto natural asumiendo que la tupla (Null, Null,......x,....Null) existe en R1. Caso (c) Reunión externa total: Se puede aplicar cuando el siguiente predicado es verdadero: ( x R2.A1 x R1.A1) ( y R2.A1 x R1.A1) , es decir cuando se puede aplicar reunión externa por la derecha y por la izquierda. Se representa por el símbolo , en este caso se produce de la siguiente manera:  Para aquellos valores en R1.A1 R2.A1 se aplica la operación de producto natural  Se aplica Reunión externa por la derecha o por la izquierda en función de que el elemento no común se encuentre en R2.A1 o en R1.A1, lo cual equivale a aplicar la operación R1 R2 R1 R2 2.2.2.4 Valores Nulos A menudo hay varias formas de tratar los valores nulos [20]. Las operaciones y las comparaciones con valores nulos se deberían evitar siempre que sea posible. Dado que el valor especial nulo indica “valor desconocido o no existente”, cualquier operación aritmética que incluya valores nulos devolverá un valor nulo. De manera similar, cualquier comparación (como <, , >, y ) que incluya un valor nulo se evalúa al nuevo valor lógico desconocido. Las operaciones lógicas tratan los valores desconocidos tal y como se muestra en la siguiente tabla. Tabla 2. Operaciones lógicas con valores desconocidos Fuente: Tema 3. El modelo relacional (op.cit)
  38. 38. 38 A la hora de efectuar operaciones en el álgebra relacional que impliquen valores nulos, hay que tener en cuenta que las operaciones de proyección, unión, intersección y diferencia tratan los valores nulos como cualquier otro valor al eliminar duplicados. Si dos tuplas del resultado de alguna de estas operaciones son exactamente iguales, y ambos tienen nulos en los mismos campos, se tratan como duplicados. La decisión es un tanto arbitraria porque sin saber cuál es el valor real no se sabe si los dos valores nulos son duplicados o no. Para las funciones de agregación, hay que tener en cuenta que cuando hay nulos en los atributos agregados, la operación borra los valores nulos del resultado antes de aplicar la agregación. Si el multiconjunto resultante está vacío, el resultado agregado será nulo. Obsérvese que el tratamiento de los valores nulos aquí es diferente que en las expresiones aritméticas ordinarias. 2.2.2.5 Otras Operaciones Adicionales 2.2.2.5.1 Ampliación Es una operación unaria [20], que toma una relación R y crea una relación resultante que tiene un atributo más que la original, cuyos valores se obtienen evaluando una expresión de cálculo escalar. La sintaxis de la operación es: R calculo escalar(nombre atributo) 2.2.2.5.2 Resumen Ω Permite incorporar operaciones de agregados (cuenta, suma, media, máximo, mínimo, etc). A partir de una relación R y de una lista de sus atributos, obtiene otra relación en cuya cabecera aparecen los atributos de R especificados y un nuevo atributo, con el nombre indiciado, siendo los valores de este último el resultado de evaluarla expresión de agregados. La sintaxis de la operación es: R(lista atributos) operaciones agregadas(nombre atributo) 2.2.2.6 Modificaciones De La Base De Datos Estas operaciones se encargan de modificar el contenido de la base de datos, las principales operaciones de modificación de una Base de Datos [20] son el Borrado, la Inserción y la Actualización.
  39. 39. 39 2.2.2.6.1 Borrado Las solicitudes de borrado se expresan básicamente igual que las consultas. Sin embargo, en lugar de mostrar las tuplas al usuario, se eliminan de la base de datos un conjunto infinito de tuplas seleccionadas. Solo se pueden borrar tuplas enteras; no se pueden borrar valores de atributos concretos. En el álgebra relacional los borrados se expresan mediante r r – E Donde r es una relación y E es una consulta del algebra relacional. 2.2.2.6.2 Inserción Para insertar datos en una relación se debe especificar la tupla que se va a insertar o escribir una consulta cuyo resultado sea un conjunto de tuplas que vayan a insertarse. Por consiguiente, el valor de los atributos de las tuplas insertadas deben ser miembros del dominio de cada atributo y de manera similar, las tuplas insertadas deben ser de la aridad correcta. En el álgebra relacional las inserciones se expresan de la siguiente forma r r E Igual que la anterior, r es una relación y E es una consulta del algebra relacional. En el caso de la inserción de una sola tupla [2] se expresa haciendo que E sea una relación constante que contiene una sola tupla. 2.2.2.6.3 Actualización Puede que en algunas situaciones, se desee modificar un valor contenido en una tupla sin modificar todo el resto de valores. Para realizar esta modificación, se puede utilizar el operador proyección generalizada mediante r F1, F2, …, Fn(r) Donde cada Fi es o bien el i-ésimo atributo de r, si el i-ésimo atributo no está actualizado, o una expresión que solo implique constantes y los atributos de r, y que del nuevo valor del atributo. Si se desea seleccionar varias tuplas de r y solo actualizar esas mismas tuplas, se puede utilizar la expresión siguiente, donde P denota la condición de selección que escoge las tuplas que hay que actualizar r F1, F2, …, Fn( P(r)) (r - P(r))
  40. 40. 40 2.3 MODELO TECNOLOGICO 2.3.1 Lenguajes De Consultas Relacionales Una de las funciones básicas de los SGBD es la recuperación de datos a partir de la base de datos. Una consulta relacional simple o compleja, se trata como una transformación sobre el contenido de la base de datos considerada como una colección de relaciones. El valor que la consulta devuelve es también una relación, la cual siempre que se cumplan los criterios de integridad, habrá de estar definida dentro del dominio del mundo de discurso. Un lenguaje de consulta es “una herramienta lingüística bien-definida cuyas expresiones corresponden a una petición a la base de datos” [11]. Los lenguajes de consulta relacionales más ampliamente estudiados son el álgebra y el cálculo relacional2, de los cuales habremos de estudiar en este escrito tan solo el primero. 2.3.1.1 Definición De Consulta Sea U el conjunto de todas las relaciones definidas sobre el conjunto de todos los atributos att. Sea I (R) el conjunto de todas las instancias del esquema de base de datos R. Una consulta Q es una función parcial recursiva Q: I (R) U. Para un r I (R) dado, Q(r) es el resultado de Q sobre r. Las consultas se expresan en un lenguaje mediante expresiones E escritas teniendo en cuenta la sintaxis y la semántica del lenguaje. E (r) es el valor que toma la consulta cuando se aplica sobre una instancia de la base de datos r. Dos expresiones E1 y E2 son equivalentes con respecto a un esquema de base de datos R, si representan la misma consulta, E1 (r) = E2 (r), para cada instancia r I (R). Un aspecto que tiene que ver con los lenguajes de consulta es su poder expresivo y más importante aún, en la potencialidad del lenguaje para ser optimizado según la necesidad técnica de la implementación del modelo. La pregunta sobre que poder debe tener un lenguaje de consulta debería depender más de “su capacidad de recuperación de datos a partir de una base de datos que de la aritmética computacional sobre los datos” [12]. Con base en esta apreciación, Aho et al. [12] postulan los siguientes dos principios que un lenguaje de consulta debería satisfacer: El primero, que el resultado de una consulta sea independiente de la manera en la cual los datos estén realmente almacenados en la base de datos. El segundo, que el lenguaje de consulta trate los valores de los datos como objetos 2 Para conocer más a fondo sobre Calculo Relacional, consultar bibliografía [8].
  41. 41. 41 sin interpretación. El álgebra y el cálculo relacional satisfacen estos principios [8] y por esta razón se convierten en modelos de lenguajes de consulta. Justamente, Codd [8] introduce estos lenguajes como estándares para medir el poder expresivo de los lenguajes de consulta relacionales. Sin embargo, el poder expresivo de los lenguajes de consulta relacionales, algebra y cálculo, basados en lógica de primer orden sin símbolos de función es limitado. Un ejemplo de esta limitación resulta de un conjunto de datos que varían, y al hacerlo generan dependencias constantes y variables con otras, de allí la necesidad del modelo de datos orientado a objetos. 2.3.1.2 Paradigmas De Consulta Extraer datos de una base de datos es uno de los tópicos en bases de datos estudiados más extensivamente. Diferentes paradigmas se han propuesto con este propósito: basado en álgebra, basadas en lógica y en programación lógica. 2.3.1.2.1 Consultas basadas en el Algebra Relacional El álgebra relacional es un lenguaje procedimental (procedural) puesto que cualquier expresión relacional describe una serie de pasos para calcular un resultado a partir de una instancia de la base de datos. El álgebra relacional, introducida por Codd [8] [14], incluye los operadores clásicos sobre conjuntos Unión, Intersección y Diferencia y otros aplicables a relaciones como Permutación, Proyección, Renombramiento, Selección y Join. Otros operadores como el Producto cartesiano, Theta-Select, Theta-Join, Natural Join y la División se definen en [14]. Adicionalmente, el álgebra se extiende para tratar con valores. La aplicación de operadores de Unión, Intersección y Diferencia se restringe a relaciones compatibles, por lo tanto, las relaciones deben tener la misma cantidad de atributos lo que corresponde a la definición del mismo dominio. 2.3.2 Optimización De Consultas 2.3.2.1 Optimización El problema de optimización exacta es computacionalmente intratable y como además no se dispone de información estadística precisa sobre la base de datos, los algoritmos de evaluación de consultas se apoyan en heurísticas [15].
  42. 42. 42 Una expresión representando la consulta del usuario tiene una forma estándar, independientemente del contenido de la base de datos, y se transforma de manera que se mejore su evaluación. Después, ésta se convierte en secuencias de operaciones. Para cada operación se tiene una buena implementación con un costo asociado. Cada una de estas secuencias es un plan de acceso. El optimizador escoge el plan de acceso más barato a partir de históricos de cada uno de los diversos componentes del sistema de base de datos, como podrían ser el coste de comunicación de acceso a almacenamiento secundario, el coste de almacenamiento, el coste de computación, el optimizador interviene también en las actualizaciones y borrados entre y otros, y finalmente lo ejecuta. Dado que el modelo de datos relacional ha sido el más utilizado, en consecuencia ha sido también un nicho amplio de investigación, y de allí que el problema de optimización de consultas haya sido ampliamente estudiado, siendo este uno de los temas más importantes de investigación en bases de datos debido al potencial latente para mejorar considerablemente el rendimiento del. Una buena parte de esta investigación en optimización se ha centrado en las consultas conjuntivas. Se parte del supuesto de que el volumen de datos almacenado en la bd es tan grande que no se puede almacenar en la memoria principal. En este sentido, es necesario hacer copias de trozos de los datos almacenados y una vez obtenidos los resultados parciales y totales almacenarlos en disco. El intercambio de páginas entre el disco y la memoria principal es el costo, en términos de tiempo, más alto del procesamiento de una consulta. Para entender mejor la importancia y las estrategias de optimización de consultas, explicaremos superficialmente cómo funciona un SGBD. 2.3.2.2 Sistemas De Gestión De Bases De Datos Según Date [8].el SGBD es un sistema computarizado cuya finalidad general es almacenar información y permitir a los usuarios recuperar y actualizar esa información con base en peticiones. Esta información puede ser cualquier cosa que sea de importancia para el individuo o la organización; es decir, todo lo que sea necesario para auxiliarle en el proceso general de su administración. Un sistema de bases de datos comprende cuatro componentes principales: datos, hardware, software y usuarios [15]. 2.3.2.2.1 Datos En general, los datos de la base de datos, al menos en los sistemas grandes, serán tanto integrados como compartidos. Integrado se refiere a una unificación de varios archivos que de otro modo serían distintos, con una redundancia entre ellos
  43. 43. 43 eliminada al menos parcialmente. Compartido por que las piezas individuales de datos en la base pueden ser compartidas entre diferentes usuarios y que cada uno de ellos puede tener acceso a la misma pieza de datos, probablemente con fines diferentes. Distintos usuarios pueden en efecto acceder a la misma pieza de datos al mismo tiempo, lo que se conoce como acceso concurrente. Este comportamiento, concurrente o no, es en parte consecuencia del hecho de que la base de datos está integrada. Si la base de datos no es compartida, se le conoce como personal o como específica de la aplicación. Que la base de datos sea integrada y compartida significa que cualquier usuario ocupará normalmente sólo una pequeña parte de la base de datos total; lo que es más, las partes de los distintos usuarios se traslaparán de diversas formas. En otras palabras, una determinada base de datos será percibida de muchas formas diferentes por los distintos usuarios. De hecho, aun cuando dos usuarios tengan la misma porción de la base de datos, su visión de dicha parte podría diferir considerablemente a un nivel detallado. 2.3.2.2.2 Hardware Los componentes de hardware del sistema constan de: Los volúmenes de almacenamiento secundario, como discos magnéticos, que se emplean para contener los datos almacenados, junto con dispositivos asociados de E/S, los controladores de dispositivos, los canales de E/S, entre otros. Los procesadores de hardware y la memoria principal asociada usados para apoyar la ejecución del software del sistema de base de datos. 2.3.2.2.3 Software El administrador de base de datos o servidor de base de datos conocido como sistema de gestión de base de datos (SGBS) maneja todas las solicitudes de acceso a la base de datos ya sea para agregar y eliminar archivos, recuperar y almacenar datos desde y en dichos archivos. Por lo tanto, una función general que ofrece el SGBS consiste en ocultar a los usuarios de la base de datos los detalles al nivel de hardware. Es decir, que el SGBS ofrece a los usuarios una percepción de la base de datos que está en cierto modo, por encima del nivel del hardware y que maneja las operaciones del usuario expresadas en términos de ese nivel más alto de percepción. El SGBS es el componente de software más importante del sistema en general, aunque no es el único.
  44. 44. 44 Entre las funciones que ofrece al usuario un SGBD están la actualización, recuperación y almacenamiento de datos, el acceso al catálogo en el que se describen los datos almacenados, el soporte a transacciones, los servicios de control de concurrencia, recuperación y autorización, el soporte para comunicación de datos y servicios de integración y soporte a la independencia de datos [16] Los principales componentes que integran un SGBD se presentan en la Figura 1, tomada de [17]. Cada componente tiene una función específica dentro del sistema. El procesador de consultas (Query Processor) transforma las consultas en instrucciones de bajo nivel para enviarlas al gestor de base de datos (Database Manager). El gestor de base de datos gestiona consultas de usuario con respecto a los esquemas conceptuales. Cuando la consulta se acepta, el gestor de almacenamiento (File Manager) debe ejecutarla. Este último gestiona espacio y asignación de almacenamiento en disco. Adicionalmente, mantiene índices y genera un registro detallado de estadísticamente cómo funciona la consulta. El procesador para el lenguaje de manipulación de datos (Data Manipulation Language –DML- Processor) transforma expresiones de manipulación de datos que aparecen en los programas de aplicación en invocaciones de funciones estándar en el lenguaje anfitrión. De esta manera debe interactuar con el procesador de consultas. El compilador del lenguaje de definición de datos (Data Definition-DDL- Language) toma una expresión de definición de datos y la convierte en un conjunto de tablas con metadatos, que se almacena en el catálogo. El gestor del catálogo (Catalog Manager) gestiona el acceso y mantenimiento del sistema de catálogo, al que acceden la mayoría de los componentes del SGBD. Las funciones de cada uno de estos componentes se detallan en [17]. Conociendo superficialmente el funcionamiento de un SGBD podemos comenzar a estudiar cómo estos optimizan las consultas y así el rendimiento del sistema de información. El propósito de la optimización es minimizar el tiempo de respuesta a una consulta. Para esto debe generar un eficiente plan de ejecución, que se convierte en un Problema de búsqueda. Para resolverlo se requiere disponer de:  Un espacio de planes (espacio de búsqueda)  Una técnica para estimar el costo de cada plan  Un algoritmo de enumeración para buscar en el espacio de planes Por esta razón el proceso de optimización no es trivial.
  45. 45. 45 Figura 1. Componentes de un SGBD Fuente: Relational Database Theory 1993 2.3.2.3 Compilador De Consultas (Query Compiler) Un problema fundamental en la evaluación y optimización de consultas es el llamado conjunctive-query containment. A pesar de que este problema es intratable [19], cuando se imponen restricciones sobre las consultas conjuntivas se convierte en casos tratables. La noción de equivalencia fuerte introducida para dos expresiones conjuntivas o SPJ se define como sigue. Sean dos expresiones E1 y E2 equivalentes con respecto a un esquema de base de datos R, si E1(r) = E2(r) representan la misma consulta para cada instancia r (R) Partiendo de este principio, los SGBD implementaron los compiladores de consultas cuya función es precisamente convertir una consulta en una secuencia de operaciones que se ejecutan en la base de datos, este proceso se lleva a cabo en tres etapas como muestra la figura:
  46. 46. 46 Figura 2. Compilación de una consulta Fuente: Database System Implementation. 2000. (op.cit) 2.3.2.4 El Árbol Parse Como sabemos una de las etapas del proceso de compilación es precisamente agrupar jerárquicamente los caracteres o componentes léxicos en frases gramaticales que el compilador utiliza para sintetizar la salida. Se comprueba si lo obtenido de la fase anterior es sintácticamente correcto (obedece a la gramática del lenguaje). Por lo general, las frases gramaticales del programa fuente se representan mediante un árbol de análisis sintáctico que en este caso habría de ser el árbol parse y que evidentemente se soporta en la gramática que expresa las sentencias SQL. 2.3.2.5 Generador De Planes De Consulta A partir de la consulta y partiendo del hecho antes mencionado de que es posible obtener un mismo conjunto solución a partir de dos expresiones diferentes, el generador de planes de consulta trabaja para mejorar la expresión algebraica correspondiente a la consulta aplicando propiedades que satisface el álgebra relacional Finalmente, una vez se obtiene un plan lógico de la consulta se plantea el plan físico. 2.3.2.6 Plan Físico Esta etapa generalmente implica estimar el costo de evaluar expresiones a partir del número de operaciones entrada y salida (I / O) a disco. Este costo depende de los operadores involucrado. Del tamaño de las relaciones intermedias, de los
  47. 47. 47 operadores físicos que implementan los operadores lógicos, del orden que se aplican operaciones iguales y de la forma en que se pasan los argumentos entre los operadores físicos.
  48. 48. 48 3. MODELO DE BASE DE DATOS ORIENTADO A OBJETOS 3.1 INTRODUCCION Las bases de datos orientadas a objetos (BDOO) son aquellas que están soportadas desde la lógica de predicados y las teorías de conjuntos que describen el modelo de datos orientado a objetos: buscan dar una persistencia mayor entre la base de datos y los objetos con los que trabajan las aplicaciones de hoy, ofreciendo formas de manipular datos estructurados jerárquicamente. Cabe aclarar que este modelo incluye conceptos como el de objeto, identidad de objeto, objetos compuestos, métodos, encapsulación y herencia, entre otros [23] [24], lo que nos da un nuevo nivel expresivo para la descripción de cada elemento en nuestro mini mundo de discurso. Su origen se debe a que en los modelos clásicos de datos existen problemas para representar cierta información, puesto que aunque permiten representar gran cantidad de datos, las operaciones que se pueden realizar con ellos son bastante simples y los elementos que componen dichos sistemas no tienen la complejidad requerida. Las clases utilizadas en un determinado lenguaje de programación orientado a objetos son las mismas clases que serán utilizadas en una BDOO; de tal manera, que no es necesaria una transformación del modelo de objetos para ser utilizado por un SGBDOO [29]. De forma contraria, el modelo relacional requiere abstraerse lo suficiente como para adaptar los objetos del mundo real a tablas. Las bases de datos orientadas a objetos surgen para evitar los problemas que aparecen al tratar de representar cierta información, aprovechar las ventajas del paradigma orientado a objetos en el campo de las bases de datos y para evitar transformaciones entre modelos de datos (usar el mismo modelo de objetos). 3.2 MODELO TEÓRICO Dice Marta Millán [9] que los modelos de valor complejo basados en el paradigma orientado a objetos y de relaciones anidadas surgen como alternativa para relajar la exigencia del modelo relacional de manejar relaciones en 1FN, ofreciendo formas de manipular datos estructurados jerárquicamente. Desde un punto de vista de los sistemas de gestión de datos, un sistema orientado a objetos incluye los conceptos de objeto, identidad de objeto, objetos compuestos, métodos, encapsulación y herencia, entre otros.
  49. 49. 49 Un objeto representa una entidad que tiene ciertas características. Los objetos que comparten las mismas características se definen y referencian como un grupo. En un SGBDOO, los objetos son persistentes. El sistema genera un identificador de objeto, OID, único por objeto que se usa para referenciarlo. Un objeto tiene propiedades o características denominadas atributos. Un atributo puede ser simple o complejo dependiendo de su valor. Los atributos complejos pueden ser colecciones, referencias. 3.2.1 Objetos complejos El modelo presentado, está soportado en el capítulo 20 del libro Foundations of Databases, Serge Abiteboul, Richard Hull, Victor Vianu [30]. Aunque admiramos la simplicidad de la estructura de datos en el modelo relacional, esta simplicidad se convierte en una severa limitación cuando se diseñan muchas aplicaciones de bases de datos prácticas. Para superar este problema, se propone el modelo de valor complejo como una extensión significativa al relacional. Intuitivamente, los valores complejos son relaciones en las cuales no se requiere que las entradas sean atómicas (como en el modelo relacional) pero se les permite ser relacionales. La estructura de datos en el modelo relacional (la relación) puede ser vista como el resultado de aplicar dos constructores a los valores atómicos: un constructor de tuplas para hacer tuplas y un constructor de conjuntos para hacer conjuntos de tuplas (relaciones). Los valores complejos permiten la aplicación de la tupla y el constructor de conjuntos recursivamente. Así pueden ser vistos como árboles finitos en los cuales sus nodos internos indican el uso de la tupla y los constructores de conjuntos finitos. Claramente, una relación es un tipo especial de valor complejo: un conjunto de tuplas de valores atómicos. Al nivel de esquema, especificaremos un conjunto de clases complejas (o tipos). Estos indican la estructura de los datos. Al nivel de instancia, se proporcionan conjuntos de valores complejos correspondientes a estos tipos. Por ejemplo, tenemos lo siguiente: Clase Valor Complejo Dom a {dom} {a, b, c} A : dom, B: dom A : a, B : b { A : dom, B: dom } { A : a, B: b , A : b, B: a } {{dom}} {{a, b}, {a}, { }}
  50. 50. 50 Un ejemplo de un tipo de valores complejos más implicado y de un valor de ese conjunto es mostrado en la Figura 3 (a). Se denota el constructor de tuplas con x y en constructor de conjuntos con *. Figura 3. Valor complejo (a) Un tipo y un valor de ese tipo Figura 4. Valor complejo (b) Otra presentación del mismo valor Fuente: Foundations of Databases. (op.cit)
  51. 51. 51 Una representación alternativa más en el “espíritu” de nuestras representaciones de relaciones se muestra en la Figura 4. (b). Otro valor complejo (para una base de datos CINEMA) se muestra en Figura 5. Mientras es simple agregar el constructor de tuplas al modelo relacional tradicional, el constructor de conjuntos requiere un número de nuevas ideas interesantes. Hay similitudes entre este constructo de conjuntos y los constructos de conjuntos usados en lenguajes de programación de propósito general como Setl. El enfoque se fundamenta en el uso de los dos constructores de valores complejos: tuplas y conjuntos (finitos). Constructores adicionales, tales como listas, bags, y Unión, también han sido incorporados en valores complejos pero no se estudian aquí). Después de introducir el álgebra, presentamos ejemplos de estos interesantes lenguajes.
  52. 52. 52 Figura 5. La base de datos CINEMA re-visitada (con información adicional mostrada) Fuente: Foundations of Databases. (op.cit)
  53. 53. 53 3.2.2 Modelo de Base de Datos de Valor Complejo Como en el modelo relacional, usaremos nombres de relación en relname, atributos en att, y constantes en dom. Los tipos son más complejos que para el modelo relacional. Su sintaxis abstracta está dada por = dom | B1: ,…, Bk : | { }, Donde k 0 y B1,…, Bk son atributos distintos. Intuitivamente, un elemento de dom es una constante; un elemento de B1: 1,…, Bk : es una k-tupla con un elemento de tipo i en la entrada Bi para cada i; y un elemento de tipo { }, es un conjunto finito de elementos de tipo . Formalmente, el conjunto de valores de tipo , (es decir, la interpretación de ), denotado , está definido por 1. dom = dom, 2. { } = {{v1, …, vj} | j 0, vi , i [1, j] }, y 3. B1: 1,…, Bk : = { B1: v1,…, Bk : vk | vj j, j [1, k]}. Un elemento de un tipo es llamado un valor complejo. Se dice que un valor complejo de la forma B1: a1,…, Bk : ak es una tupla, mientras que un valor complejo de la forma {a1, …, aj} es un conjunto. OBSERVACION Por ejemplo, considere el conjunto { A : dom, B: dom, C : { A : dom, E: {dom} } } y el valor { A : a, B: b, C : { A : c, E: { } , A : d, E: { } } , A : e, B: f, C : { } } de ese tipo. Esto es de nuevo el valor de Figura 4. Es costumbre omitir dom y por ejemplo escribir este tipo { A, B, C : { A, E: { } } }. Como se mencionó anteriormente, cada valor complejo y cada tipo puede ser visto como un árbol finito. Observar la representación del árbol. Los bordes salientes de los vértices de las tuplas son etiquetados; los conjuntos de vértices tienen un solo hijo en un tipo y un número arbitrario (pero finito) de hijos en un valor.
  54. 54. 54 Finalmente, note que (a causa del conjunto vacío) un valor complejo puede pertenecer a más de un tipo. Por ejemplo, el valor de la Figura 3 y 4 es también de tipo { A : dom, B : dom, C : { A : dom, E: {{dom}} } }. El álgebra relacional se encarga de los conjuntos de tuplas. De manera similar, el álgebra de valores complejos se encarga de los conjuntos de valores complejos. Esto motiva la siguiente definición de relaciones de tipo (esta definición es frecuentemente una fuente de confusión): Una relación (de valor complejo) de tipo es un conjunto finito de valores de tipo Usamos el término relación para relaciones de valor complejo. Cuando consideramos el modelo relacional clásico, algunas veces utilizamos la frase relación plana para distinguir de la relación de valor complejo. Debería ser claro que las relaciones planas que hemos estudiado son casos especiales de relaciones de valor complejo. Debemos ser cuidadosos en la distinción de tipo de una relación de valor complejo y el tipo de la relación vista como un valor complejo. Por ejemplo, una relación de valor complejo de tipo A, B, C es un conjunto de tuplas sobre los atributos ABC. Al mismo tiempo, la relación entera puede ser vista como un valor complejo de tipo { A, B, C }. No hay contradicción entre estas dos formas de ver la relación. Ahora asumimos que la función sort pertenece al conjunto de nombres de relaciones de relname. También asumimos que por cada tipo, hay un número infinito de relaciones teniendo ese tipo. Note que el tipo de relación no es necesariamente un tipo tupla (puede ser un tipo conjunto). Así las relaciones no siempre tienen atributos en el nivel superior. Tales relaciones, en las cuales el tipo es un conjunto, son esencialmente relaciones unarias sin nombres de atributos. Un esquema (de valor complejo) es un nombre de relación; y un esquema de base de datos (de valor complejo) es un conjunto finito de nombres de relaciones. Una relación (de valor complejo) sobre un nombre de relación R es un conjunto finito de valores de tipo sort (R) – esto es,un subconjunto finito de sort(R). Una instancia (de base de datos de valor complejo) I de un esquema R es una función de R tal que para cada R en R, I(R) es una relación sobre R.
  55. 55. 55 El siguiente ejemplo es para ilustrar esta definición, una instancia J de {R1, R2, R3} donde sort(R1) = sort(R3) = A : dom, B : { A1 : dom, A2: dom } y sort(R2) = A : dom, A1 : dom, A2: dom Es mostrada en la Figura 6 Variaciones Para concluir esta sección, mencionamos brevemente algunas variaciones del modelo de valor complejo. El principal que ha sido considerado es el modelo relacional anidado. Para las relaciones anidadas, se requieren constructores de conjuntos y tuplas para alternar (es decir, conjunto de conjuntos y tupla con un componente tupla están prohibidos). Por ejemplo, 1 = A, B, C : { D, E: { F, G } } y 2 = A, B, C : { E: { F, G } } Son tipos de relaciones anidadas mientras que 3 = A, B, C: { D, E: { F, G } y 4 = A, B, C : {{ F, G }} No lo son. (Para 3, observe dos constructores de tuplas adyacentes; hay dos constructores de conjuntos para 4.) La restricción impuesta en la estructura de las relaciones anidadas es mayormente cosmética. Una restricción más fundamental se impone en las llamadas Verso- relations (V-relations). Como en las relaciones anidadas, se requieren constructores de conjuntos y tuplas en V-relations para alternar. Una relación es definida recursivamente para ser un conjunto de tuplas, de tal forma que cada componente pueda por sí mismo ser una relación pero al menos una de ellas debe ser atómica. El conjunto precedente 1 sería aceptable por una V-relation mientras que el conjunto 2 no por el tipo de tuplas en el componente C.
  56. 56. 56 Figura 6. Una instancia de base de datos Fuente: Foundations of Databases. (op.cit) Una asunción más detallada (más radical) para las V-relations es que para cada conjunto de tuplas, los atributos atómicos forman una llave. Observe que como consecuencia, la cardinalidad de cada conjunto en una V-relation está limitada por un polinomio en el número de elementos atómicos ocurriendo en la V-relation. Este límite ciertamente no aplica para una relación de tipo {dom} (un conjunto de conjuntos) o para una relación anidada de tipo A: { B: dom } La cual es también esencialmente un conjunto de conjuntos. Las V-relations son por lo tanto estructuras de datos mucho más limitadas. Pueden ser vistas esencialmente como instancias de relaciones planas.

×