UNIDAD 1

MODELOS EMERGENTES DE BASES DE DATOS

1.1 Bases de datos orientadas a objetos.

Las Bases de datos orientados a objetos se propusieron con la idea de satisfacer

las necesidades de las aplicaciones más complejas. El enfoque orientado a objetos
ofrece la flexibilidad para cumplir con algunos de estos requerimientos sin estar
limitado por los tipos de datos y los lenguajes de consulta disponibles en los
sistemas de bases de datos tradicionales.

Como cualquier Base de Datos programable, una Base de Datos Orientada a

Objetos (BDOO) proporciona un ambiente para el desarrollo de aplicaciones y un
depósito persistente listo para su explotación. Una BDOO almacena y manipula
información que puede ser digitalizada (presentada) como objetos, además
proporciona un acceso ágil y permite una gran capacidad de manipulación.

Las bases de datos orientadas a objetos (BDOO) son aquellas cuyo modelo de
datos está orientado a objetos y almacenan y recuperan objetos en los que se
almacena estado y comportamiento. 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.

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. 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
surgen 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).

1.1.1 Definición y conceptos de las BDOO.

Base de datos orientada a objetos (BDOO): una colección persistente y

compatible de objetos definida por un modelo de datos orientado a objetos.

Modelo de datos orientado a objetos: Un modelo de datos que captura la

semántica de los objetos soportados en la programación orientada a objetos.

Sistema Gestor de Bases de Datos Orientadas a Objetos (SGBDOO): El gestor de

una base de datos orientada a objetos.

Los principales conceptos que se utilizan en las Bases de Datos Orientada a

Objetos (BDOO) son las siguientes:

• Identidad de objetos
• Constructores de tipos
• Encapsulamiento
• Compatibilidad con los lenguajes de programación
• Jerarquías de tipos y herencia
• Manejo de objetos complejos
• Polimorfismo y sobrecarga de operadores
• Creación de versiones.

1.1.2 El modelo de datos orientado a objetos.

Las aplicaciones de las bases de datos en áreas como el diseño asistido por
computadora, la ingeniería de software y el procesamiento de documentos no se
ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de
procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto
para tratar algunos de estos nuevos tipos de aplicaciones.

El modelo de bases de datos orientado a objetos es una adaptación a los sistemas

de bases de datos. Se basa en el concepto de encapsulamiento de datos y código
que opera sobre estos en un objeto. Los objetos estructurados se agrupan en
clases. El conjunto de clases está estructurado en sub y superclases basado en una
extensión del concepto ISA del modelo Entidad - Relación. Puesto que el valor de
un dato en un objeto también es un objeto, es posible representar el contenido del
objeto dando como resultado un objeto compuesto.

El propósito de los sistemas de BD datos es la gestión de grandes cantidades de

información. Las primeras bases de datos surgieron del desarrollo de los sistemas
de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de
red o en bases de datos jerárquicas y, más tarde, en bases de datos relacionales.

1.1.3 El estándar ODMG.

El modelo de objetos ODMG permite que tanto los diseños, como las
implementaciones, sean portables entre los sistemas que lo soportan. Dispone de
las siguientes primitivas de modelado:

Los componentes básicos de una base de datos orientada a objetos son los objetos
y los literales. Un objeto es una instancia autocontenida de una entidad de interés
del mundo real. Los objetos tienen algún tipo de identificador único. Un literal es
un valor específico, como “Amparo” o 36. Los literales no tienen identificadores.
Un literal no tiene que ser necesariamente un solo valor, puede ser una estructura
o un conjunto de valores relacionados que se guardan bajo un solo nombre.

Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio
específico compartido por todos los objetos y literales de ese tipo. Los tipos
también pueden tener comportamientos. Cuando un tipo tiene comportamientos,
todos los objetos de ese tipo comparten los mismos comportamientos. En el
sentido práctico, un tipo puede ser una clase de la que se crea un objeto, una
interface o un tipo de datos para un literal (por ejemplo, integer). Un objeto se
puede pensar como una instancia de un tipo.

Lo que un objeto sabe hacer son sus operaciones. Cada operación puede requerir
datos de entrada (parámetros de entrada) y puede devolver algún valor de un tipo
conocido. Los objetos tienen propiedades, que incluyen sus atributos y las
relaciones que tienen con otros objetos. El estado actual de un objeto viene dado
por los valores actuales de sus propiedades.

Una base de datos es un conjunto de objetos almacenados que se gestionan de

modo que puedan ser accedidos por múltiples usuarios y aplicaciones.

La definición de una base de datos está contenida en un esquema que se ha creado

mediante el lenguaje de definición de objetos ODL (Object Definition Language)
que es el lenguaje de manejo de datos que se ha definido como parte del estándar
propuesto para las bases de datos orientadas a objetos.

1.1.4 Encapsulamiento, herencia y polimorfismo en BDOO.

Una base de datos orientada a objetos es una base de datos que incorpora todos los
conceptos importantes del paradigma de objetos:

 Encapsulación - Propiedad que permite ocultar la información al resto de

los objetos, impidiendo así accesos incorrectos o conflictos.
 Herencia - Propiedad a través de la cual los objetos heredan
comportamiento dentro de una jerarquía de clases.
 Polimorfismo - Propiedad de una operación mediante la cual puede ser
aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones

sobre los datos como parte de la definición de la base de datos. Una operación
(llamada función) se especifica en dos partes. La interfaz (o signatura) de una
operación incluye el nombre de la operación y los tipos de datos de sus
argumentos (o parámetros). La implementación (o método) de la operación se
especifica separadamente y puede modificarse sin afectar la interfaz. Los
programas de aplicación de los usuarios pueden operar sobre los datos invocando
a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma
en la que se han implementado. Esto podría denominarse independencia entre
programas y operaciones.

1.1.5 Persistencia, concurrencia y recuperación en BDOO.

Persistencia

Esta se refiere a la capacidad de manipular directamente los datos almacenados en

una base de datos usando un lenguaje de programación orientado a objetos. Esto
contrasta con una base de datos utilizada por SQL o una interfaz utilizada por
ODBC o JDBC. Utilizando un objeto de base de datos significa que se puede
tener un mayor rendimiento y se aminora la escritura de código.

Con la persistencia la manipulación de objetos se realiza directamente por el

lenguaje de programación de la misma manera que en la memoria, sin persistencia
de objetos. Esto se logra mediante el uso inteligente de almacenamiento en caché.

Concurrencia

Los SMBDOO deben poder ser accesibles por múltiples usuarios. Cuando una
aplicación está accesando a una sección de la base de datos, otras aplicaciones
deben poder acceder a otras secciones de la base de datos. La concurrencia
permite a los usuarios cooperar y colaborar en una aplicación.

Los mecanismos de control de concurrencia son necesarios para reforzar las

propiedades de las transacciones (ACID). Los modos básicos de control de
concurrencia son:

• Modo Pesimista
• Modo optimista
• Modo mixto
• Modo semi-optimista

El modo pesimista obliga a una transacción a esperar a que se resuelva el

conflicto que pueda o ponga en riesgo la concurrencia para dejarle continuar
cuando el conflicto haya sido resuelto.

El modo optimista deje correr la transacción como si no ocurriera ningún

conflicto y resuelve este al final del commit, generalmente se emplea usando
estampas de tiempo y copias de los elementos de la transacción.

El modo mixto combina diferentes controles de concurrencia a diferentes objetos

y tipos de datas en una misma transacción.
El modo semi-optimista es una variante del modo mixto que no detiene a la
transacción hasta que esta termina.

Los principales mecanismos de control de concurrencia son tres:

 Candados que prohíben accesos que puedan provocar conflictos de acceso

 Estampas de tiempo.- estas permiten impedir violaciones a los datos
 Guardar múltiples versiones de los objetos de datos.

Recuperación

Con recuperación nos referimos al proceso de aplicación de consistencia después

de que una transacción ha abortado como resultado de fallas de hardware o
problemas de comunicación. Las fallas del sistemas, tanto de hardware como de
software no deben repercutir en estados de inconsistencia de la base datos. La
recuperación es la técnica que asegura que eso no ocurra. La recuperación puede
ser total o parcial dependiendo de las circunstancias, de la recuperabilidad.

1.2 Bases de datos multidimensionales (BDM).

Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creación
de Cubos OLAP. Básicamente no se diferencian demasiado de las bases de datos
relacionales (una tabla en una base de datos relacional podría serlo también en una
base de datos multidimensional), la diferencia está más bien a nivel conceptual; en las
bases de datos multidimensionales los campos o atributos de una tabla pueden ser de
dos tipos, o bien representan dimensiones de la tabla, o bien representan métricas que
se desean estudiar.

1.2.1 Definición y conceptos de las BDM.

Las bases de datos multidimensionales se utilizan principalmente para crear

aplicaciones OLAP y pueden verse como bases de datos de una sola tabla, su
peculiaridad es que por cada dimensión tienen un campo (o columna), y otro
campo por cada métrica o hecho, es decir estas tablas almacenan registros cuyos
campos son de la forma: (d1,d2,d3,...,f1,f2,f3,...)

Donde los campos 'di' hacen referencia a las dimensiones de la tabla, y los campos
'fi' a las métricas o hechos que se quiere almacenar, estudiar o analizar.

Cada una de estas tablas puede asimilarse a un hipercubo o -más concretamente si

de herramientas OLAP se trata- a un cubo OLAP, donde las dimensiones del
mismo se corresponden los campos de dimensiones de la tabla (campos 'di...'), y
el valor almacenado en cada celda del cubo equivale a la métrica o métricas
(campos 'fi...') almacenadas en la tabla.
Implementación

Lo más importante a tener en cuenta para implementar esta estructura de datos es

que la tabla contiene todas las n-tuplas, con los valores de las dimensiones, o
índice del cubo, y los valores de las métricas previamente calculados para el cruce
de valores del índice en cuestión.

1.2.2 Modelos conceptuales multidimensionales.

En una base de datos multidimensional, la información se representa como

matrices multidimensionales, cuadros de múltiples entradas o funciones de varias
variables sobre conjuntos finitos. Cada una de estas matrices se denomina Cubo.

El esquema de un cubo queda determinado dando a conocer sus ejes con sus
respectivas estructuras y la estructura de los datos que se presentan en cada celda
de la matriz. Se asume que los datos en todas las celdas son uniformes, es decir,
todas las posiciones de la matriz tienen datos con igual estructura.

Una instancia de un cubo, queda determinada por un conjunto de datos para cada
eje y un conjunto de datos para la matriz.

A los ejes se les llama Dimensiones y al dato que se presenta en la matriz, se le

llama Medida. A los elementos del producto cartesiano de los ejes (dimensiones)
se le llama Coordenadas. La matriz definida, puede ser dispersa. ( función
parcial).

1.2.3 Cubos e hipercubos de datos.

Los cubos de información o cubos OLAP funcionan como los cubos de

rompecabezas en los juegos, en el juego se trata de armar los colores y en el data
warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el
juego) tienen 3 dimensiones, los cubos OLAP tienen un número indefinido de
dimensiones, razón por la cual también reciben el nombre de hipercubos. Un cubo
OLAP contendrá datos de una determinada variable que se desea analizar,
proporcionando una vista lógica de los datos provistos por el sistema de
información hacia el data warehouse, esta vista estará dispuesta según unas
dimensiones y podrá contener información calculada. El análisis de los datos está
basado en las dimensiones del hipercubo, por lo tanto, se trata de un análisis
multidimensional.

A la información de un cubo puede acceder el ejecutivo mediante “tablas

dinámicas” en una hoja de cálculo o a través de programas personalizados. Las
tablas dinámicas le permiten manipular las vistas (cruces, filtrados, organización,
totales) de la información con mucha facilidad. Las diferentes operaciones que se
pueden realizar con cubos de información se producen con mucha rapidez.
Llevando estos conceptos a un data warehouse, éste es una colección de datos que
está formada por «dimensiones» y «variables», entendiendo como dimensiones a
aquellos elementos que participan en el análisis y variables a los valores que se
desean analizar.

Dimensiones
Las dimensiones de un cubo son atributos relativos a las variables, son las
perspectivas de análisis de las variables (forman parte de la tabla de dimensiones).
Son catálogos de información complementaria necesaria para la presentación de
los datos a los usuarios, como por ejemplo: descripciones, nombres, zonas, rangos
de tiempo, etc. Es decir, la información general complementaria a cada uno de los
registros de la tabla de hechos.

Variables
También llamadas “indicadores de gestión”, son los datos que están siendo
analizados. Forman parte de la tabla de hechos. Más formalmente, las variables
representan algún aspecto cuantificable o medible de los objetos o eventos a
analizar. Normalmente, las variables son representadas por valores detallados y
numéricos para cada instancia del objeto o evento medido. En forma contraria, las
dimensiones son atributos relativos a la variables, y son utilizadas para indexar,
ordenar, agrupar o abreviar los valores de las mismas. Las dimensiones poseen
una granularidad menor, tomando como valores un conjunto de elementos menor
que el de las variables; ejemplos de dimensiones podrían ser: “productos”,
“localidades” (o zonas), “el tiempo” (medido en días, horas).

1.2.4 Estructuras no-jerárquicas y jerárquicas de los datos.

Una Base de datos jerárquica es un tipo de Sistema Gestor de Bases de Datos que,
como su nombre indica, almacenan la información en una estructura jerárquica
que enlaza los registros en forma de estructura de árbol (similar a un árbol visto al
revés), en donde un nodo padre de información puede tener varios nodos hijo.
Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden
establecerse relaciones entre nodos hermanos. En este caso la estructura en forma
de árbol se convierte en una estructura en forma de grafo dirigido. Esta variante se
denomina Bases de datos de red.

Cómo funcionan: A diferencia del modelo relacional, el modelo jerárquico no

diferencia una vista lógica de una vista física de la base de datos. De manera que
las relaciones entre datos se establecen siempre a nivel físico, es decir, mediante
referencia a direcciones físicas del medio de almacenamiento (sectores y pistas).

Los datos se almacenan en la forma de registros, el equivalente a las filas del

modelo relacional. Cada registro consta de un conjunto de campos, el equivalente
a las columnas del modelo relacional. Un conjunto de registros con los mismos
campos se denomina fichero (record type, en inglés), el equivalente a las tablas
del modelo relacional.
El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de
uno a varios) del modelo relacional. Pero a diferencia de éste último, las
relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero
no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede
relacionarse con el registro de su departamento (nodo padre), pero no al contrario.
Esto implica que solamente se puede consultar la base de datos desde los nodos
hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda
secuencial por todos los registros de la base de datos (por ejemplo, para consultar
todos los empleados de un departamento). En las bases de datos jerárquicas no
existen índices que faciliten esta tarea.

Las relaciones jerárquicas entre diferentes tipos de datos pueden hacer que sea
muy sencillo responder a determinadas preguntas, pero muy difícil el contestar a
otras.

1.2.5 Operadores para datos agregados multidimensionales.

A pesar de los buenos resultados obtenidos con el modelo relacional en los

sistemas Operacionales, la utilización de este modelo en aplicaciones orientadas a
la toma de decisiones presenta varias carencias, Una de las principales carencias
es el bajo rendimiento de las consultas: el modelo relacional está orientado a
transacciones que manejan pocos registros simultáneamente, mientras que los
sistemas de ayuda a la toma de decisiones (DSS) tienden a procesar grandes
volúmenes de datos.

Otra de las limitaciones es la propia estructura de la base de datos: las consultas

realizadas en los DSS son muy complejas y su definición no está fijada de
antemano. Como las consultas dependen de lo que necesite el usuario en cada
momento, con un modelo relacional se debería generar un índice por cada posible
consulta que desee el usuario, lo que dificulta la gestión y mantenimiento de la
base de datos. Por otra parte, si lo que se quiere es acceder a un dato individual
básico como puede ser el importe de una operación concreta, la ventaja del
modelo multidimensional desaparece en favor del relacional. Éstos son capaces de
recuperar un dato individual con mayor eficiencia que las multidimensionales y,
dada su utilización masiva en sistemas OLTP, están optimizados para la inserción
de registros y el control concurrente de usuarios. En el modelo de datos
multidimensional, los datos se organizan en torno a los conceptos de la empresa y
la estructura de datos manejada en este modelo son matrices multidimensionales o
hipercubos.

Un hipercubo consiste en un conjunto de celdas, de tal manera que cada una está
identificada por la combinación de los miembros de las diferentes dimensiones y
contiene el valor de la medida analizada para dicha combinación de dimensiones.
Las variables o medidas son aquellas características del negocio que pueden ser
cuantificadas y son seleccionadas para el análisis. Por ejemplo: ventas, compras,
costes,… Se corresponden con los datos numéricos. Los valores que toman las
variables son el resultado de las diferentes combinaciones posibles de los
miembros de las dimensiones sobre las que se definen.

1.2.6 Consultas multidimensionales de datos.

Las consultas Dbase constan de archivos que permiten realizar muchas tareas
diferentes con los datos. Se pueden utilizar las consultas para controlar los campos
de datos que se pueden ver. También se pueden utilizar las consultas para
controlar los registros que visualiza Dbase. Las consultas pueden cambiar el orden
de presentación de datos y pueden incluso actualizarlos. Las consultas no
contienen información de la base de datos, sino tan solo las instrucciones
necesarias para seleccionar los registros y campos requeridos de una base de
datos.

Consulta de un campo para una entrada carácter:

Se pueden crear consultas simples para encontrar todos los registros que contienen
una entrada de carácter específica. Se puede utilizar la coincidencia exacta u
operadores relacionales cuando se realiza la búsqueda. Puesto que se deben
encerrar las cadenas de caracteres entre comillas, se puede buscar una
coincidencia exacta colocando la cadena de caracteres que se necesite encontrar
entre comillas.

Almacenamiento y uso de consultas:

Dbase IV puede almacenar una consulta como archivo. Esto ofrece la ventaja de
reutilizar la consulta posteriormente sin reentrar en ella. Para utilizar cualquier
consulta almacenada en disco se selecciona un archivo de consultas del panel de
consultas del centro de control con la apropiada base de datos en uso. Las
condiciones que también se denominan filtros establecidas por esta consulta se
ponen en vigor automáticamente para ocultar los registros que presenta Dbase. Se
puede utilizar para afectar a la visualización de los registros sobre la pantalla o
para restringir los registros presentados en los informes que se crean.

Consulta de campos numéricos:

La búsqueda de valores numéricos permite operar con todos los registros de

empleado con un código de trabajo específico o todos los registros de un número
de cliente particular. Se controlan los registros que cumplan la consulta en base a
los contenidos de un campo numérico en lugar de un campo carácter, pero la
mayor parte de las características de las consultas utilizadas para campos
numéricos son exactamente las mismas que se utilizan para campos de carácter.

Se pueden utilizar ejemplos de coincidencia exacta para localizar datos. Puesto

que estamos trabajando con datos numéricos, las comillas no se necesitan.
También se puede utilizar muchos de los operadores relacionales que utilizaron
con los campos de carácter.

Consulta de campo de fecha:

La consulta de los campos de fecha no es diferente del acceso a otros tipos de

campos. Dbase reconoce los campos de fecha y los trata como una entrada de
fecha si se incluyen de las llaves { }. Se utilizan los ejemplos bajo este tipo de
campos para encontrar una coincidencia exacta o relacional. Se pueden utilizar
ejemplos relacionales para localizar todos los registros anteriores y posteriores a
una fecha dada. También se pueden encontrar registros dentro de un rango
especifico de fechas colocando en el ejemplo dos expresiones relacionadas
separadas por coma (,).

Consultas de campos lógicos:

Los campos lógicos contienen indicadores de verdadero o falso.

Cuando se crea un ejemplo de un campo lógico, se puede hacer que Dbase busque
valores verdaderos o falsos colocando .T. o .F. como un ejemplo debajo del tipo
de campo. Dbase también acepta .t., .f., ..f., .Y., .N., .y., y .n., como entradas para
este campo.

Las operaciones más comunes realizadas sobre los datos multidimensionales son:

cube y roll up definidas en Cube calcula todas las posibles agregaciones que
resultan de las combinaciones de atributos incluidos en la cláusula de la consulta,
generando totales y subtotales para dichas combinaciones de los atributos.