005756A992

Vista previa del material en texto

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
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 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Pereira (día, mes, año) 
Nota de aceptación: 
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________ 
 
 
 
 
 
 
______________________________
Firma del presidente jurado 
 
 
______________________________
Firma del jurado 
 
 
______________________________
Firma del jurado 
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. 
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.
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 
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 
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 
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 
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 
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 
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 
 
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 
 
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 
 
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íasde 
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 
 
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 
 
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 
 
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 
 
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 siguienteselementos: 
- Nombre que identifica la relación, aunque pueden presentarse relaciones que no 
poseen nombre cuando son el resultado de una operación. 
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 
 
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 
 
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 
 
¿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 
 
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 
 
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 
 
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 construyeuna 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 
 
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 
 
 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 
 
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 
 
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 pertenecea 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 
 
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 
 
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 
 
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 
 
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 resultadosa 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 
 
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 
 
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 
 
� 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 
 
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 tieneun 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 
 
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 
 
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 
 
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 
 
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