Entrega 07 DBMS

UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

ADMINISTRACIÓN DE BASES DE DATOS
SISTEMAS DE ADMINISTRACIÓN DE BASES DE DATOS DE

OBJETOS
MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

Datos complejos:
❑ La mayoría de los DBMS relacionales sólo soportan unos cuantos tipos de datos. Los tipos de datos
interconstruidos que soporta SQL incluyen números enteros, números reales, números de precisión fija
(monedas), fechas, tiempos y texto. Estos tipos de datos son suficientes para muchas aplicaciones
empresariales, o al menos para partes significativas de muchas aplicaciones.
❑ Muchas bases de datos empresariales contienen columnas para nombres, precios, direcciones y fechas de
transacción que se ajustan fácilmente a los tipos de datos estándar.
❑ Los avances en capacidades de hardware y software han permitido la captura y manipulación de datos
complejos en un formato digital. Casi cualquier tipo de dato complejo puede almacenarse digitalmente:
imágenes, audio, mapas y gráficos tridimensionales.
▪ ejemplo, una imagen puede representarse como un arreglo bidimensional de pixeles (elementos de imagen)
donde cada pixel contiene una propiedad numérica que representa su color o escala de grises.
❑ El almacenamiento digital usualmente es más barato y más confiable que los medios tradicionales, como
papel, película o diapositivas. Además, el almacenamiento digital facilita la recuperación y manipulación.
ING. KAREL PERALTA SOTOMAYOR 2



Aplicaciones tradicionales de las Bases de Datos
❑ Aplicaciones de gestión convencionales

▪ Nominas, contabilidad, etc.
❑ Uso de registros de longitud fija y reducida
❑ Campos de cada registro cortos, de longitud fija y tipo alfanumérico
• Tipos sin estructura
Se cumple la primera forma normal


Aplicaciones tradicionales de las Bases de Datos
❑ Nuevas aplicaciones de las BD
▪ Mejoras en el hardware
▪ Integración de nuevos tipos de información en la BD
Ejemplos
 Diseño asistido por ordenador (CAD)
 Sistemas de Información Geográfica (GIS)
 Sistemas de información Multimedia (MM)
 Ingeniería del software asistida por ordenador (CASE)
 Almacenamiento y recuperación de documentos

▪ Ejemplo (Gestión
de rectángulos)


Ejemplo (Gestión de rectángulos)
❑ ¿Podrá el optimizador generar la segunda consulta a partir de la primera?
▪ Con la tecnología actual ?
❑ Además, los árboles B, no son los más eficientes para este tipo de problema
❑ Problemas
▪ Necesidades de información simples se traducen en expresiones SQL demasiado complejas
▪ La eficiencia en la ejecución de esas consultas es muy baja
❑ Solución
▪ Incorporar en el SGBD características presentes en lenguajes O.O.
▪ Diferencia entre lenguajes de programación y gestores de BD
✓ Las aplicaciones se escriben para solucionar un problema específico
✓ Una base de datos se diseña para resolver un conjunto de problemas, alguno de los cuales ni se
conoce en el momento del diseño.

Árbol B y B+
▪ Un árbol B es un árbol binario, es decir, de cada nodo sólo pueden partir como máximo dos nodos. En
enlace de los nodos se hace a través de la estructura jerárquica, es decir, cada nodo sólo sabe quien es
su padre y sus hijos.
▪ Un árbol B+ es un árbol B (se cumple todo lo que he dicho anteriormente) pero además los nodos
tienen un enlace a los elementos de su mismo nivel. Es decir, cada nodo sabe quien es su padre, su hijo
izquierdo, su hijo derecho, si hermano izquierdo y su hermano derecho.
 Para poder hacer búsquedas tanto secuenciales como binarias en un árbol.

 La mayoría de las bases de datos comerciales (Oracle, SQLServer...) utilizan BTree+ en su estructura
interna.

PRINCIPIOS ORIENTADOS A OBJETOS


❑ Para proporcionar un fundamento a fin de comprender las arquitecturas y características de los DBMS de objetos,
veamos tres principios fundamentales de computación orientada a objetos.
▪ Encapsulación
 Un objeto es una combinación de datos y procedimientos. A veces, a los datos se les refiere como variables y a los
procedimientos como métodos.
 Cada objeto tiene un identificador único que nunca cambia, a menos que el objeto se destruya. Los identificadores
de objeto no son visibles para los usuarios. En contraste, las llaves primarias en las bases de datos relacionales sí
son visibles.
 Las clases contienen colecciones de objetos. Una definición de clase consiste en una colección de variables y
métodos. A veces a las variables se les llama variables de instancia para distinguirlas de las variables que se aplican
a toda la clase (llamadas variables de clase).
 Encapsulación significa que a los objetos sólo puede accederse a través de sus interfaces. Los detalles internos
(definiciones de variable e implementaciones de método) no son accesibles.

▪ Figura 1.- Jerarquías de

clase con las subclases
ColorPoint y Corporate


▪ Herencia
 Datos y códigos compartidos entre clases similares clases y subclases.
• Los ejemplos 1 y 2 presentan clases que heredan de las clases Point y Bond. La figura 1 muestra una representación
gráfica de las relaciones de herencia.
• Un color point es un punto con color. Del mismo modo, un corporate bond es un bono con una compañía emisora
y una calificación de inversión.
• En las subclases (una clase hijo que hereda de una clase padre), las variables y los métodos de las clases padres no
se repiten. Cuando se usan las subclases, pueden usarse los métodos en las clases padre.
Ejemplo 1 Ejemplo 2


▪ Polimorfismo
 Habilidad de un sistema de cómputo para elegir entre múltiples implementaciones de un método.
 Polimorfismo literalmente significa "de muchas formas".
 En la computación orientada a objetos, el polimorfismo permite un método para tener múltiples implementaciones.
La implementación de un método en una subclase puede invalidar la implementación del método en una clase padre.
▪ Figura 2.- Procesamiento

de un mensaje

ARQUITECTURAS PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

❑ El mercado ofrece una diversidad de enfoques para las
bases de datos orientadas a objetos.
❑ Parte de la variedad es histórica debido aliento
desarrollo inicial de la tecnología.
❑ Los primeros enfoques proporcionan pequeñas
extensiones que dejan la mayor parte del
procesamiento orientado a objetos afuera de un DBMS.
Conforme crece el interés del usuario y maduran la
investigación y el desarrollo, surgen enfoques más
completos para las bases de datos orientadas a objetos.
❑ Los enfoques recientes han implicado significativas
reescrituras de los DBMS para acomodar los objetos.
▪ Figura 3.- Arquitectura de

objeto grande


❑ OBJETOS GRANDES Y SOFTWARE EXTERNO
 Los primeros enfoques para agregar objetos a las bases de datos relacionales consistieron en usar objetos grandes
con software externo.
 Los datos complejos se almacenan en una columna como objeto grande binario o de texto. Por ejemplo, una imagen
usa el tipo de datos BLOB (objeto grande binario), mientras que un gran documento de texto usa el tipo de datos
CLOB (objeto grande carácter).
 Como se muestra en la figura 3, los objetos grandes por lo general se almacenan separados de otros datos de la
tabla.
 Una consulta puede recuperar pero no desplegar objetos grandes. El software externo al DBMS despliega y manipula
objetos grandes.
 El software externo incluye controles ActiveX, applets de Java y plug-ins del navegador web.


❑ SERVIDORES ESPECIALIZADOS EN MEDIOS
 En la arquitectura especializada de servidor de medios, los datos complejos residen fuera de un DBMS, como se
muestra en la figura 4.
 Un servidor separado puede dedicarse a manipular un solo tipo de datos complejos, como video o imágenes. Los
programadores usan una interfaz de programación de aplicación (API) para acceder a datos complejos a través de un
servidor de medios.
 La API proporciona un conjunto de procedimientos para recuperar, actualizar y transformar un tipo específico de
dato complejo.
 Para manipular simultáneamente datos simples y complejos, el código de programa contiene una mezcla de SQL y
llamadas de API al servidor de medios.

▪ Figura 4.- Arquitectura

especializada de servidor
de médios.


❑ MIDDLEWARE DE BASES DE DATOS DE OBJETOS
 El middleware de base de datos de objetos evade los problemas con los servidores de medios al simular
características de objetos.
 Los clientes ya no acceden directamente a los servidores de medios, como se muestra en la figura 5. En vez de ello,
los clientes envían enunciados SQL al middleware, quien hace llamadas API a servidores de medios y envía
enunciados SQL a los servidores de bases de datos.
 Los enunciados SQL pueden combinar operaciones tradicionales sobre datos simples con operaciones especializadas
sobre datos complejos.
 El middleware de bases de datos de objetos libera al usuario del conocimiento de una API separada para cada
servidor de medios. Además, el middleware de bases de datos de objetos proporciona independencia de ubicación,
ya que los usuarios no necesitan saber dónde residen los datos complejos.

▪ Figura 5.- Enfoque de

middleware de objetos

▪ Tabla.- Tipos de datos preconstruidos definidos por el usuario en DBMS relacionales de objetos


❑ SISTEMAS DE ADMINISTRACIÓN DE BASES DE DATOS ORIENTADAS A OBJETOS
 Algunos expertos argumentan que es necesario cambios más fundamentales a un DBMS para que soporte objetos.
Para acomodar objetos deben cambiarse tanto el modelo de datos como el kernel.
 Esta convicción impulsó el arranque de algunas compañías de software para implementar una nueva clase de DBMS
de objetos, como se muestra en la figura 6.
 Las compañías de software se han aliado para formar Grupos de Administración de Bases de Datos de Objetos
(ODMG).
 Los ODMG proponen un lenguaje de definición de objetos (ODL) y un lenguaje de consulta de objetos (OQL). Estos
lenguajes son la contraparte de SQL para los DBMS orientados a objetos.


❑ SISTEMAS DE ADMINISTRACIÓN DE BASES DE DATOS
ORIENTADAS A OBJETOS
▪ Figura 6.- Arquitectura de

componente para DBMS
orientados a objetos

Entrega 07 DBMS

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Entrega 07 DBMS

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

SISTEMAS DE ADMINISTRACIÓN DE BASES DE DATOS DE

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 2

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 3

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

❑ Aplicaciones de gestión convencionales

ING. KAREL PERALTA SOTOMAYOR 4

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 5

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 6

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

 Para poder hacer búsquedas tanto secuenciales como binarias en un árbol.

ING. KAREL PERALTA SOTOMAYOR 8

PRINCIPIOS ORIENTADOS A OBJETOS

ING. KAREL PERALTA SOTOMAYOR 9

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 10

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

▪ Figura 1.- Jerarquías de

ING. KAREL PERALTA SOTOMAYOR 11

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 12

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

▪ Figura 2.- Procesamiento

ING. KAREL PERALTA SOTOMAYOR 13

ARQUITECTURAS PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

▪ Figura 3.- Arquitectura de

ING. KAREL PERALTA SOTOMAYOR 14

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 15

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 16

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

▪ Figura 4.- Arquitectura

ING. KAREL PERALTA SOTOMAYOR 17

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 18

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

▪ Figura 5.- Enfoque de

ING. KAREL PERALTA SOTOMAYOR 19

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 20

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

ING. KAREL PERALTA SOTOMAYOR 21

MOTIVACIÓN PARA LA ADMINISTRACIÓN DE BASES DE DATOS DE OBJETOS

▪ Figura 6.- Arquitectura de

ING. KAREL PERALTA SOTOMAYOR 22

S-ar putea să vă placă și