Lo que se siembra de recoge

Michael Stonebraker
Joseph M. Hellerstein
Abstracto
Este documento presenta un resumen de 35 aos de propuestas de modelos de
datos, agrupados en 9
Diferentes pocas. Discutimos las propuestas de cada poca y mostramos que
slo hay
Las ideas bsicas de modelado de datos, y la mayora han sido alrededor de un
tiempo largo. Propuestas posteriores
Inevitablemente, un fuerte parecido con algunas propuestas anteriores. Por lo
tanto, es un
Valga la pena estudiar las propuestas anteriores.
Adems, presentamos las lecciones aprendidas de la exploracin de las
propuestas en cada
era. La mayora de los investigadores actuales no estuvieron presentes durante
muchas de las eras anteriores y
Limitada (si es que hay alguna) comprensin de lo que se aprendi
anteriormente. Hay un viejo adagio que
El que no entiende la historia est condenado a repetirlo. Al presentar
"antiguos
Historia ", esperamos que los futuros investigadores eviten repetir la historia.
Desafortunadamente, la propuesta principal en la era XML actual tiene un
parecido sorprendente con
La propuesta CODASYL de principios de los aos 70, que fracas debido a su
complejidad.
Por lo tanto, la era actual es repetir la historia, y "lo que va alrededor viene
alrededor".
Esperemos que la prxima era sea ms inteligente.
I. Introduccin
Las propuestas de modelos de datos han existido desde finales de la dcada de
1960, cuando el primer autor
"Entr en escena". Las propuestas han continuado con sorprendente
regularidad
Interviniendo 35 aos. Adems, muchas de las propuestas actuales provienen
de
Investigadores demasiado jvenes para haber aprendido de la discusin de
anteriores. Por lo tanto, la
Propsito de este trabajo es resumir los 35 aos de "progreso" y sealar qu
Debe ser aprendido de este largo ejercicio.
Presentamos propuestas de modelos de datos en nueve pocas histricas:
Jerrquico (IMS): fines de los aos 1960 y 1970
Red (CODASYL): 1970's
Relacional: 1970 y principios de 1980
Entidad-Relacin: 1970's

Extensin Relacional: 1980's

Semntica: finales de los aos setenta y ochenta
Orientado a objetos: finales de los aos ochenta y principios de los noventa
Relacin objeto-relacin: finales de los aos ochenta y principios de los
noventa
Pgina 2

Semi-estructurado (XML): finales de la dcada de 1990 hasta la actualidad

En cada caso, se analiza el modelo de datos y el lenguaje de consulta
asociado,
notacin. Por lo tanto, le ahorraremos al lector los detalles idiosincrticos de
los diferentes
Propuestas. Tambin trataremos de usar una coleccin uniforme de trminos,
de nuevo en un intento
Para limitar la confusin que de otra manera podra ocurrir.
A lo largo de gran parte del trabajo, usaremos el ejemplo estndar de
proveedores y partes,
De [CODD70], que escribimos por ahora en forma relacional en la Figura 1.
Proveedor (sno, sname, scity, sstate)
Parte (pno, pname, psize, pcolor)
Suministro (sno, pno, cantidad, precio)
Un esquema relacional
Figura 1
Aqu tenemos Informacin del Proveedor, Informacin de la Parte y la
relacin de
Indicar las condiciones bajo las cuales un proveedor puede suministrar una
pieza.
II IMS Era
IMS fue lanzado alrededor de 1968, e inicialmente tena un modelo de datos
jerrquico. Entendi
la nocin de un tipo de registro, que es una coleccin de campos
denominados con su asociado
tipos de datos. Cada instancia de un tipo de registro se ve obligado a obedecer
a la descripcin de los datos
Indicada en la definicin del tipo de registro. Adems, algunos subconjuntos
de los
campos deben especificar de forma nica una instancia de registro, es decir,
estn obligados a ser una clave. Finalmente,
los tipos de registro deben estar dispuestos en un rbol, de tal manera que
cada tipo de registro (que no sea el
raz) tiene un nico tipo de registro padre. Una base de datos IMS es una
coleccin de instancias de
Tipos de registro, de forma que cada instancia, que no sea instancias raz,
tenga un nico

Tipo de registro correcto.

Este requisito de los datos estructurados en rbol presenta un desafo para
nuestros datos de muestra, porque
Nos vemos forzados a estructurarlo de una de las dos maneras indicadas en la
Figura 2. Estas
Las representaciones comparten dos propiedades indeseables comunes:
Se repite 1) de la informacin. En el primer esquema, la informacin de la
Parte se repite
Cada Proveedor que suministra la pieza. En el segundo esquema, informacin
del proveedor
Se repite por cada parte que suministra. La informacin repetida es
indeseable,
Porque ofrece la posibilidad de datos inconsistentes. Por ejemplo, una repetida
Elemento de datos podra ser cambiado en algunos, pero no en todos, de los
lugares que aparece,
Lo que conduce a una base de datos inconsistente.
2) La existencia depende de los padres. En el primer esquema es imposible
que haya
Una parte que actualmente no es suministrada por nadie. En el segundo
esquema,
Es imposible tener un proveedor que actualmente no suministra nada. Ahi esta
No hay apoyo para estos "casos de esquina" en una jerarqua estricta.
Lo que se siembra de recoge
3
Pgina 3

Dos Organizaciones Jerrquicas

Figura 2
IMS eligi una base de datos jerrquica porque facilita una simple
manipulacin de datos
Idioma, DL / 1. Cada registro en una base de datos IMS tiene
una clave de secuencia jerrquica
(HSK). Bsicamente, un HSK se obtiene concatenando las claves de los
registros de antepasados, y
Luego agregando la clave del registro actual. HSK define un orden natural de
todos los
Una base de datos de IMS, bsicamente profundidad-primero, izquierda-aderecha. DL / 1 utiliz ntimamente el pedido HSK para
La semntica de los comandos. Por ejemplo, el comando "get next" devuelve
el siguiente
Registro en orden HSK. Otro uso de la orden HSK es el "get next within
parent"
Comando, que explora el subrbol debajo de un registro dado en orden HSK.

Usando el primer esquema, uno puede encontrar todas las partes rojas
suministradas por el Proveedor 16 como:
Obtener proveedor nico (sno = 16)
Hasta el fracaso
Obtener el siguiente en el padre (color = rojo)
Enddo
El primer comando encuentra Supplier 16. Entonces iteramos a travs del
subrbol debajo
Este registro en orden HSK, en busca de partes rojas. Cuando el subrbol se
agota, se produce un error
Se devuelve.
Obsrvese que DL / 1 es un lenguaje "registro-a-tiempo", mediante el cual el
programador construye un
Algoritmo para resolver su consulta, y luego IMS ejecuta este algoritmo. A
menudo hay
Mltiples formas de resolver una consulta. Aqu hay otra manera de resolver
la especificacin anterior:
Proveedor (sno,
Sname, scity,
Sstate)
Parte (pno, pname,
Psize, pcolor, qty,
precio)
Parte (pno,
Pname, psize,
Pcolor
Proveedor (sno,
Sname, scity,
Sstate, qty, precio)
4
Captulo 1: Modelos de datos y arquitectura DBMS
Pgina 4

Hasta el fracaso
Obtener la siguiente parte (color = rojo)
Enddo
Aunque se podra pensar que la segunda solucin es claramente inferior a la
primera; en
De hecho, si slo hay un proveedor en la base de datos (nmero 16), la
segunda
Superan a la primera. El programador DL / 1 debe hacer tales compensaciones
de optimizacin.
IMS soporta cuatro formatos de almacenamiento diferentes para los datos
jerrquicos. Bsicamente registros de raz

Puede ser:
Almacenado secuencialmente
Indexado en un rbol B utilizando la clave del registro
Hashed utilizando la clave del registro
Los registros dependientes se encuentran desde la raz usando
Fsico secuencialmente
Varias formas de punteros.
Algunas de las organizaciones de almacenamiento imponen restricciones a los
comandos DL / 1. Por ejemplo
La organizacin puramente secuencial no admite inserciones de registros. Por
lo tanto, es apropiado
Slo para entornos de procesamiento por lotes en los que se ordena una lista
de cambios en orden HSK y
Entonces se hace una sola pasada de la base de datos, los cambios insertados
en el lugar correcto y un
Nueva base de datos escrita. Esto se denomina usualmente "procesamiento de
antiguo maestro nuevo maestro".
Adems, la organizacin de almacenamiento que almacena los registros raz
en una clave no puede
"Get next", porque no tiene forma fcil de devolver registros hash en orden
HSK.
Estas diversas "peculiaridades" en IMS estn diseadas para evitar
operaciones que
Rendimiento increblemente malo. Sin embargo, esta decisin tiene un precio:
no se puede
Cambiar las organizaciones de almacenamiento de IMS para ajustar una
aplicacin de base de datos porque no hay
Garantizar que los programas DL / 1 seguirn funcionando.
La capacidad de una aplicacin de base de datos para seguir ejecutndose,
independientemente de la afinacin es
realizado en el nivel fsico se llamar independencia de datos fsica. Fsico
La independencia de datos es importante porque una aplicacin de DBMS no
suele escribirse todo en
una vez. A medida que se agregan nuevos programas a una aplicacin, las
demandas de ajuste pueden cambiar,
Y un mejor rendimiento de DBMS podra lograrse cambiando la organizacin
de almacenamiento.
IMS ha elegido limitar la cantidad de independencia de datos fsicos que es
posible.
Adems, los requisitos lgicos de una aplicacin pueden cambiar con el
tiempo. Nuevo
Tipos de registros pueden agregarse, debido a nuevos requerimientos de
negocios o
Gubernamentales. Tambin puede ser conveniente mover ciertos elementos de
datos de

Un tipo de registro a otro. IMS es compatible con un cierto nivel

de independencia de datos lgicos,
porque DL / 1 est definido en realidad en una base de datos lgicos, no en
los datos fsica real
Base que se almacena. Por lo tanto, un programa DL / 1 se puede escribir
inicialmente definiendo la lgica
Lo que se siembra de recoge
5
Pgina 5

Base de datos para ser exactamente igual que la base de datos

fsicos. Posteriormente, se pueden agregar tipos de registros
A la base de datos fsicos, y la base de datos lgica redefinida para
excluirlos. Por lo tanto, un
La base de datos IMS puede crecer con nuevos tipos de registro, y el
programa DL / 1 inicial
Contine funcionando correctamente. En general, una base de datos lgica de
IMS puede ser un subrbol de un
Base de datos fsicos.
Es una excelente idea que el programador interacte con una abstraccin
lgica de la
Datos, ya que esto permite que la organizacin fsica cambie, sin
comprometer la
Runability de DL / 1 programas. La independencia de los datos lgicos y
fsicos es importante
Porque la aplicacin DBMS tiene una vida til mucho ms larga (a menudo
un cuarto de siglo o ms)
Que los datos sobre los que operan. La independencia de los datos permitir
que los datos cambien
Sin requerir mantenimiento costoso del programa.
Un ltimo punto debe hacerse sobre IMS. Claramente, nuestros datos de
muestra no son
rbol representacin estructurada como se seal anteriormente. Por lo tanto,
rpidamente hubo presin sobre IMS
Para representar nuestros datos de muestra sin la redundancia o dependencias
mencionadas anteriormente.
IMS respondi extendiendo la nocin de bases lgicas de datos ms all de lo
que era justo
Descrito.
Dos bases de datos fsicas IMS
figura 3
Supongamos que uno construye dos bases de datos fsicas, una que contiene
slo la informacin de la Parte

Y el segundo contiene la informacin de proveedores y suministros como se

muestra en el diagrama de
Figura 3. Por supuesto, los programas DL / 1 se definen en los rboles; Por lo
tanto, no pueden utilizarse
Directamente sobre las estructuras de la Figura 3. En su lugar, IMS permiti la
definicin de la lgica
Base de datos mostrada en la Figura 4. Aqu, los tipos de registro de
Las bases de datos estn "fusionadas" (unidas) sobre el valor comn del
nmero de pieza en la base jerrquica
Estructura mostrada.
Proveedor (sno,
Sname, scity,
Sstate)
Suministro (pno, cantidad,
precio)
Parte (pno,
Pname, psize,
Pcolor
6
Captulo 1: Modelos de datos y arquitectura DBMS
Pgina 6

Bsicamente, la estructura de la Figura 3 se almacena realmente, y se puede

observar que no hay
Redundancia y no hay dependencias de mala existencia en esta estructura. El
programador es
Presentado con la vista jerrquica mostrada en la Figura 4, que apoya el
estndar DL / 1
Programas.
Una base de datos lgicos IMS
Figura 4
Hablando en general, IMS permiten que dos diferentes bases de datos fsicas
estructuradas
"Injertados" juntos en una base de datos lgica. Existen muchas restricciones
(por ejemplo,
El uso del comando delete) y una considerable complejidad para este uso de
datos lgicos
Bases de datos, pero es una forma de representar datos no estructurados de
rbol en IMS.
La complejidad de estas bases lgicas de datos se ver en la actualidad como
pivotial en
Determinando cmo IBM decidi apoyar las bases de datos relacionales una
dcada ms tarde.

Vamos a resumir las lecciones aprendidas hasta ahora, y luego pasar a la

propuesta CODASYL.
Leccin 1: Independencia de datos fsicos y lgicos son altamente deseables
Leccin 2: Los modelos de datos estructurados en rbol son muy restrictivos
Leccin 3: Es un reto proporcionar sofisticadas reorganizaciones lgicas de
los rboles
datos estructurados
Leccin 4: Una interfaz de usuario de registro a la vez obliga al programador a
realizar una consulta manual
Optimizacin, y esto es a menudo difcil.
Proveedor (sno,
Sname, scity,
Sstate)
Suministro (pno, cantidad,
precio)
Parte (pno,
Pname, psize,
Pcolor
Lo que se siembra de recoge
7
Pgina 7

III Era de CODASYL

En 1969, el Comit CODASYL (Comit de Sistemas de
Su primer informe [CODA69], y luego seguido en 1971 [CODA71] y 1973
[CODA73]
Con las especificaciones del lenguaje. CODASYL era un comit ad hoc que
defenda una
Modelo de datos de red junto con un lenguaje de manipulacin de datos de
registro-en-uno-tiempo.
Este modelo organiz una coleccin de tipos de registros, cada uno con
claves, en una red,
Que un rbol. Por lo tanto, una instancia registrada dada podra tener mltiples
padres, en lugar de una
nica, como en IMS. Como resultado, nuestro ejemplo de proveedor-piezassuministro podra ser
Representado por la red CODASYL de la Figura 5.
Suministros
Suministrada por
Una red CODASYL
Figura 5
Aqu, observamos tres tipos de registros dispuestos en una red, conectados por
dos arcos con nombre,

Denominados Suministros y suministrados por. Un arco con nombre se

denomina conjunto de CODASYL, aunque es
No tcnicamente un conjunto en absoluto. Ms bien se indica que para cada
instancia de registro del propietario
Tipo de registro (la cola de la flecha) hay una relacin con cero o ms registro
instancias del tipo de registro secundario (la punta de la flecha). Como tal, es
un 1-a-n
Relacin entre las instancias de registro del propietario y las instancias del
registro secundario.
Una red CODASYL es una coleccin de tipos de registros nombrados y tipos
de conjuntos
Forman un grfico conectado. Por otra parte, debe haber al menos un punto
de entrada (un tipo de registro
Que no es un nio en ningn conjunto). Una base de datos CODASYL es una
coleccin de instancias de registro
Y establecer instancias que obedecen a esta descripcin de red.
Proveedor (sno,
Sname, scity,
Sstate)
Suministro (cantidad, precio)
Parte (pno,
Pname, psize,
Pcolor
8
Captulo 1: Modelos de datos y arquitectura DBMS
Pgina 8

Obsrvese que la Figura 5 no tiene las dependencias de existencia presentes en

una estructura jerrquica
modelo de datos. Por ejemplo, est bien tener una parte que no es
suministrada por nadie. Esta
Ser simplemente una instancia vaca del conjunto Supplied_by. Por lo tanto,
el traslado a una red
El modelo de datos resuelve muchas de las restricciones de una jerarqua. Sin
embargo, todava hay
Situaciones que son difciles de modelar en CODASYL. Consideremos, por
ejemplo, los datos
Ceremonia de matrimonio, que es una relacin de 3 vas entre una novia, un
novio y un
ministro. Debido a que los conjuntos CODASYL son slo relaciones
bidireccionales, uno es forzado a
Modelo de datos indicado en la Figura 6.
Participa-1
Participa-2

Participa-3
Una solucin de CODASYL
Figura 6
Esta solucin requiere tres conjuntos binarios para expresar una relacin de
tres vas, y es
Algo antinatural. Aunque mucho ms flexible que IMS, los datos CODASYL
Modelo todava tena limitaciones.
El lenguaje de manipulacin de datos CODASYL es un lenguaje de registroa-un-tiempo en el que uno
Entra en la base de datos en un punto de entrada y luego navega a los datos
deseados mediante conjuntos siguientes.
Para encontrar las piezas rojas suministradas por el Proveedor 16 en
CODASYL, se puede utilizar lo siguiente
cdigo:
Novia
Ceremonia
Novio
Ministro
Lo que se siembra de recoge
9
Pgina 9

Buscar proveedor (SNO = 16)

Hasta no ms
Buscar el siguiente registro de suministro en Suministros
Encontrar el registro del propietario en Supplied_by
Obtener registro actual
-check para el rojo}
Uno entra en la base de datos en el proveedor 16, y luego itera sobre los
miembros de la
Suministros establecidos. Esto producir una coleccin de registros de
suministro. Para cada uno, el propietario en
Se identifica el conjunto Suministrado_y se comprueba si hay enrojecimiento.
La propuesta de CODASYL sugiri que los registros de cada punto de entrada
se
Clave en el registro. Se propusieron varias implementaciones de conjuntos
que
Combinaciones de punteros entre los registros primarios y secundarios.
La propuesta de CODASYL no proporcion esencialmente independencia de
datos fsicos. por
Ejemplo, el programa anterior falla si la clave (y por lo tanto el
almacenamiento hash) del proveedor

El registro se cambia de sno a otra cosa. Adems, no hay independencia de

datos lgicos
Se proporciona, ya que el esquema no puede cambiar sin afectar a los
programas de aplicacin.
El paso a un modelo de red tiene la ventaja de que no se requiere
Implementar datos estructurados con grficos, como nuestro ejemplo. Sin
embargo, el modelo CODASYL
Es considerablemente ms complejo que el modelo de datos de IMS. En IMS
un programador navega
En un espacio jerrquico, mientras que un programador CODASYL navega en
un entorno multidimensional
Hiperespacio En IMS, el programador slo debe preocuparse por su posicin
actual en el
La base de datos y la posicin de un antepasado nico (si est haciendo un
"get next in parent").
Por el contrario, un programador CODASYL debe realizar un seguimiento de:
El ltimo registro tocado por la aplicacin
El ltimo registro de cada tipo de registro tocado
El ltimo registro de cada tipo de set tocado
Los diversos comandos DMS de CODASYL actualizan estos indicadores de
moneda. Por lo tanto, una
Pueden pensar que la programacin de CODASYL mueve estos indicadores
monetarios
CODASYL hasta que se encuentre un registro de inters. Entonces, puede ser
buscado. En
Adems, el programador CODASYL puede suprimir el movimiento de la
moneda si lo desea.
Por lo tanto, una manera de pensar en un programador CODASYL es que
debe programar buscando
En un mapa de la pared de la red CODASYL que est decorado con varios
alfileres de colores
Indicando la moneda. En su conferencia del Premio Turing de 1973, Charlie
Bachmann lo llam
"Navegar en el hiperespacio" [BACH73].
10
Captulo 1: Modelos de datos y arquitectura DBMS
Pgina 10

Por lo tanto, la propuesta de CODASYL incrementa la complejidad por la

posibilidad de
Representando datos no jerrquicos. CODASYL ofrece datos lgicos y fsicos
ms pobres
Independencia de IMS.

Tambin hay algunos problemas ms sutiles con CODASYL. Por ejemplo, en

IMS cada
Base podra ser independiente de forma masiva desde una fuente de datos
externa. Sin embargo, en
CODASYL, todos los datos estaban tpicamente en una red grande. Este
objeto mucho ms grande tena
Para ser cargados a granel de una vez, dando lugar a tiempos de carga muy
largos. Adems, si un dato CODASYL
Base se corrompi, fue necesario recargar todo de un volcado. Por lo tanto,
accidente
La recuperacin tiende a ser ms complicada que si los datos se dividieran en
una coleccin de
Bases de datos independientes.
Adems, un programa de carga CODASYL tenda a ser complejo porque un
gran nmero de
Los registros tenan que ser ensamblados en conjuntos, y esto usualmente
implicaba muchas bsquedas de disco. Como
Por lo general, es importante pensar cuidadosamente sobre el algoritmo de
carga para optimizar
actuacin. Por lo tanto, no haba ninguna utilidad de carga CODASYL de uso
general, y cada
Instalacin tuvo que escribir su propio. Esta complejidad era mucho menos
importante en IMS.
Por lo tanto, las lecciones aprendidas en CODASYL fueron:
Leccin 5: Las redes son ms flexibles que las jerarquas, pero ms complejas
Leccin 6: Cargar y recuperar redes es ms complejo que las jerarquas
IV Era Relacional
En este contexto, Ted Codd propuso su modelo relacional en 1970
[CODD70]. En un
Conversacin con l aos ms tarde, indic que el conductor de su
investigacin era el hecho
Que los programadores de IMS estaban gastando grandes cantidades de
tiempo haciendo mantenimiento en IMS
Aplicaciones, cuando se produjeron cambios lgicos o fsicos. Por lo tanto, se
centr en
Proporcionando una mejor independencia de los datos.
Su propuesta era triple:
Almacenar los datos en una estructura de datos simple (tablas)
Acceder a l a travs de un alto nivel establecido a la vez DML
No hay necesidad de una propuesta de almacenamiento fsico
Con una estructura de datos simple, uno tiene un mejor cambio de
proporcionar datos lgicos
independencia. Con un lenguaje de alto nivel, se puede proporcionar un alto
grado de

Independencia de los datos. Por lo tanto, no hay necesidad de especificar una

propuesta de almacenamiento, como fue requerido
Tanto en IMS como en CODASYL.
Adems, el modelo relacional tiene la ventaja aadida de que es lo
suficientemente flexible como para
Representan casi cualquier cosa. Por lo tanto, las dependencias de la
existencia que plagaron IMS pueden ser
Fcilmente manejado por el esquema relacional mostrado anteriormente en la
Figura 1. Adems,
Lo que se siembra de recoge
11
Pgina 11

La ceremonia de matrimonio de una manera difcil en CODASYL es

fcilmente representada en la
Modelo relacional como:
Ceremonia (novia-id, groom-id, minister-id, otros-datos)
Codd realiz varias propuestas de modelo relacional (cada vez ms
sofisticadas) a lo largo de los aos
[CODD79, CODDXX]. Adems, sus primeras propuestas de DML fueron el
clculo relacional
(Lenguaje de datos / alfa) [CODD71a] y el lgebra relacional
[CODD72a]. Desde Codd
Era originalmente un matemtico (y trabajado previamente en los autmatas
celulares), su DML
Propuestas fueron rigurosas y formales, pero no necesariamente fciles para
los simples mortales
entender.
La propuesta de Codd propici de inmediato "el gran debate", que dur una
buena parte
De los aos setenta. Este debate se intensific en las conferencias SIGMOD (y
su predecesor
SIGFIDET). Por un lado, haba Ted Codd y sus "seguidores" (en su mayora
Investigadores y acadmicos) que argumentaron los siguientes puntos:
A) Nada tan complejo como CODASYL puede ser una buena idea
B) CODASYL no proporciona una independencia de datos aceptable
C) La programacin de grabacin a la vez es demasiado difcil de optimizar
D) CODASYL e IMS no son lo suficientemente flexibles como para
representar fcilmente situaciones comunes
(Como las ceremonias de matrimonio)
Por otro lado, haba Charlie Bachman y sus "seguidores" (sobre todo DBMS
Practicantes) quienes argumentaron lo siguiente:
A) Los programadores de COBOL no pueden comprender la nueva relacin
relacional

Idiomas
B) Es imposible implementar eficientemente el modelo relacional
C) CODASYL puede representar tablas, as que cul es la gran cosa?
El punto culminante (o lowlight) de esta discusin fue un debate real en
SIGMOD '74
Entre Codd y Bachman y sus respectivos "segundos" [RUST74]. Uno de
nosotros estaba en
La audiencia, y era obvio que ninguno de los dos lados articulaba claramente
su posicin. Como un
Resultado, ninguno de los dos lados pudo or lo que el otro lado tena que
decir.
En los dos aos siguientes, los dos campamentos modificaron sus posiciones
(ms o menos)
Siguiente:
Defensores relacionales
A) Codd es un matemtico, y sus lenguas no son las correctas. SQL
[CHAM74]
Y QUEL [STON76] son mucho ms fcil de usar.
12
Captulo 1: Modelos de datos y arquitectura DBMS
Pgina 12

B) El sistema R [ASTR76] y INGRES [STON76] demuestran que las

implementaciones eficientes de
Las ideas de Codd son posibles. Adems, se pueden construir optimizadores
de consultas que sean competitivos
Con todos menos los mejores programadores en la construccin de planes de
consulta.
C) Estos sistemas demuestran que la independencia de datos fsicos es
alcanzable. Adems,
Las vistas relacionales [STON75] ofrecen una mayor independencia de datos
lgicos,
CODASYL.
D) Los lenguajes "Set-at-a-time" ofrecen mejoras sustanciales en la
productividad del programador,
Relativo a los lenguajes de registro en un momento.
Los defensores de CODASYL
A) Es posible especificar lenguajes de red set-at-a-time, como LSL [TSIC76],
que
Proporcionar independencia completa de datos fsicos y la posibilidad de
mejores datos lgicos
independencia.
B) Es posible limpiar el modelo de red [CODA78], por lo que no es tan
arcano.

Por lo tanto, ambos campos respondieron a las crticas del otro campo. El
debate entonces muri
Hacia abajo, y la atencin se centr en el mercado comercial para ver qu
pasara.
Fortuitamente para el campo relacional, la revolucin del minicomputador
estaba ocurriendo, y
Los VAX estaban proliferando. Ellos eran un objetivo obvio para los primeros
Sistemas relacionales, como Oracle e INGRES. Felizmente para el campo
relacional, el
Los principales sistemas CODASYL, tales como IDMS de Culinaine Corp. se
escribieron en IBM
Ensamblador, y no eran porttiles. Por lo tanto, los sistemas relacionales
tempranos tenan el VAX
Mercado a s mismos. Esto les dio tiempo para mejorar el rendimiento de sus
productos,
Y el xito del mercado VAX fue de la mano con el xito de las relaciones
Sistemas.
En los mainframes, se estaba desarrollando una historia muy diferente. IBM
vendi un derivado de System R
En VM / 370 y una segunda derivada en VSE, su sistema operativo de gama
baja. Sin embargo,
Ninguna plataforma fue utilizada por los usuarios serios de procesamiento de
datos empresariales. Toda la accin fue
En MVS, el sistema operativo de gama alta. Aqu, IBM continu vendiendo
IMS, Cullinaine
Vendido con xito IDMS, y los sistemas relacionales estaban en ninguna parte
ser visto.
Por lo tanto, los VAX eran un mercado relacional y los mainframes eran un
mercado no relacional.
En ese momento todos los datos serios de gestin se hizo en mainframes.
Este estado de cosas cambi abruptamente en 1984, cuando IBM anunci la
prxima
Lanzamiento de DB / 2 en MVS. En efecto, IBM pas de decir que IMS era su
serio
DBMS a una estrategia de base de datos dual, en la cual tanto IMS como DB /
2 fueron declarados estratgicos.
Dado que DB / 2 era la nueva tecnologa y era mucho ms fcil de usar,
Todos los que el ganador a largo plazo iba a ser.
Lo que se siembra de recoge
13
Pgina 13

La seal de IBM de que era seriamente serio acerca de los sistemas

relacionales fue

momento. Primero, termin de una vez por todas "el gran debate". Dado que
IBM
Mercado en ese momento, anunciaron con eficacia que los sistemas
relacionales tenan
Ganado y CODASYL y los sistemas jerrquicos haban perdido. Poco
despus, Cullinaine e IDMS
Entr en un mercado desmayado. En segundo lugar, declararon efectivamente
que SQL era el
Facto, el lenguaje relacional estndar. Otros lenguajes de consulta
(sustancialmente mejores), como
QUEL, estaban muertos de inmediato. Para una crtica mordaz de la semntica
de SQL, consulte
[DATE84].
Un hecho poco conocido debe ser discutido en este punto. Hubiera sido
natural que IBM
Poner un frontal relacional en la parte superior de IMS, como se muestra en la
Figura 7. Esta arquitectura sera
Han permitido a los clientes de IMS continuar con IMS. Se podra escribir una
nueva solicitud
A la interfaz relacional, proporcionando un camino de migracin elegante a la
nueva tecnologa.
Por lo tanto, con el tiempo un cambio gradual de DL / 1 a SQL se habra
producido, todo el tiempo
Preservando los soportes de IMS de alto rendimiento
De hecho, IBM intent ejecutar exactamente esta estrategia, con un proyecto
llamado Eagle.
Por desgracia, result demasiado difcil implementar SQL en la parte superior
de la nocin IMS de lgica
Bases de datos, debido a cuestiones semnticas. Por lo tanto, la complejidad
de las bases lgicas
IMS volvi a frecuentar IBM muchos aos despus. Como resultado, IBM se
vio obligada a
La estrategia de doble base de datos, y declarar un ganador del gran debate.
Antiguos programas
Nuevos programas
La Arquitectura del Proyecto guila
Figura 7
En resumen, el argumento de CODASL versus relacional fue finalmente
resuelto por tres
eventos:
Relacional
interfaz
IMS
14
Captulo 1: Modelos de datos y arquitectura DBMS

Pgina 14

A) el xito del VAX

B) la no portabilidad de los motores CODASYL
C) la complejidad de las bases de datos lgicas de IMS
Las lecciones que se aprendieron de esta poca son:
Leccin 7: Los lenguajes de set-a-time son buenos, independientemente del
modelo de datos, ya que ofrecen
Mayor independencia de los datos fsicos.
Leccin 8: La independencia de los datos lgicos es ms fcil con un modelo
de datos simple que con un
Complejo.
Leccin 9: Los debates tcnicos son generalmente resueltos por los elefantes
del mercado, y
A menudo por razones que tienen poco que ver con la tecnologa.
Leccin 10: Los optimizadores de consultas pueden superar a todos excepto la
mejor aplicacin de DBMS de registro a la vez
Programadores
V La Era de la Entidad-Relacin
A mediados de los setenta, Peter Chen propuso el modelo de datos entidadrelacin (ER) como un
Alternativa a la relacional, CODASYL y modelos de datos jerrquicos
[CHEN76].
Bsicamente, propone que una base de datos puede pensar en una coleccin
de instancias de entidades.
Hablando francamente, estos son objetos que tienen una existencia,
independiente de cualquier otro
Entidades de la base de datos. En nuestro ejemplo, Supplier y Parts seran
tales entidades.
Adems, las entidades tienen atributos, que son los elementos de datos que
caracterizan la
entidad. En nuestro ejemplo, los atributos de Part seran pno, pname, psize y
pcolor.
Uno o ms de estos atributos seran designados como nicos, es decir, para ser
una clave. Finalmente,
no puede haber relaciones entre las entidades. En nuestro ejemplo, Supply es
una relacin
Entre las entidades Parte y Proveedor. Las relaciones podran ser 1-a-1, 1-a-n,
n-a-1 o
M-a-n, dependiendo de cmo las entidades participen en la relacin. En
nuestro ejemplo,
Los proveedores pueden suministrar mltiples piezas y las piezas pueden ser
suministradas por mltiples proveedores.

Por lo tanto, la relacin de suministro es m-a-n. Las relaciones tambin

pueden tener atributos que
Describir la relacin. En nuestro ejemplo, la cantidad y el precio son atributos
de la relacin
Suministro.
Una representacin popular para los modelos ER era una notacin de "cajas y
flechas" como se muestra en
Figura 8. El modelo ER nunca gan aceptacin como el modelo de datos
subyacente que es
Implementado por un DBMS. Tal vez la razn era que en los primeros das no
haba
Lenguaje de consulta propuesto para ello. Tal vez fue simplemente abrumado
por el inters en la
Relacional en la dcada de 1970. Tal vez se pareca demasiado a una versin
"limpia" de
El modelo CODASYL. Cualquiera que fuera la razn, el modelo de ER
languideca en los aos setenta.
Lo que se siembra de recoge
15
Pgina 15

Suministro
Cantidad, precio
Un Diagrama ER
Figura 8
Hay un rea donde el modelo de ER ha sido exitoso, en la base de datos
(Esquema) de diseo. La sabidura estndar de los defensores relacionales fue
la de realizar datos
Base de diseo mediante la construccin de una coleccin inicial de
tablas. Luego, uno aplicado
Normalizacin a este diseo inicial. A lo largo de la dcada de los setenta,
Fueron una coleccin de formas normales propuestas, incluida la segunda
forma normal (2NF)
[CODD71b], tercera forma normal [CODD71b], forma normal de BoyceCodd (BCNF)
[CODD72b], la cuarta forma normal (4NF) [FAGI77a], y el proyecto de
unirse a la forma normal
[FAGI77b].
Hubo dos problemas con la teora de la normalizacin cuando se aplic a la
base de datos del mundo real
Problemas de diseo. Primero, los DBAs inmediatamente preguntaron:
"Cmo puedo obtener un conjunto inicial de
Tablas? "La teora de la normalizacin no tena respuesta a esta importante
pregunta. Segundo, y

Tal vez ms seria, la teora de la normalizacin se basaba en el concepto de

Dependencias y DBAs del mundo real no pudieron entender esta
construccin. Por lo tanto, la base de datos
El diseo utilizando la normalizacin estaba "muerto en el agua".
En contraste, el modelo ER se hizo muy popular como una herramienta de
diseo de base de datos. Chen's
Contena una metodologa para construir un diagrama ER inicial. Adems,
Fue sencillo convertir un diagrama ER en una coleccin de tablas en la tercera
normal
Forma [WONG79]. Por lo tanto, una herramienta DBA podra realizar esta
conversin automticamente. Como
Tal, un DBA podra construir un modelo ER de sus datos, tpicamente usando
cajas y
Herramienta de dibujo de flechas, y luego estar seguro de que
automticamente obtendra una buena
Esquema relacional. Esencialmente todas las herramientas de diseo de base
de datos, como Silverrun de Magna
Solutions, ERwin de Computer Associates y ER / Studio de Embarcadero
trabajan en
Esta moda
Leccin 11: Las dependencias funcionales son demasiado difciles de entender
para los simples mortales.
Otra razn para KISS (Keep it simple stupid).
VI R ++ Era
A comienzos de los aos ochenta apareci una coleccin (considerable) de
artculos que pueden ser
Descrito por la siguiente plantilla:
Parte
Pno, pname, psize,
Pcolor
Proveedor
Sno, sname, scity,
Estatal
diecisis
Captulo 1: Modelos de datos y arquitectura DBMS
Pgina 16

Considere una aplicacin, llmela X

Trate de implementar X en un DBMS relacional
Mostrar por qu las consultas son difciles o por qu se observa un
rendimiento bajo
Agregar una nueva "caracterstica" al modelo relacional para corregir el
problema

Muchas X fueron investigadas incluyendo mecnica CAD [KATZ86], VLSI

CAD
[BATO85], gestin de textos [STON83], tiempo [SNOD85] y grficos por
ordenador
[SPON84]. Esta coleccin de documentos form "la era R ++", como todos
propusieron
Adiciones al modelo relacional. En nuestra opinin, probablemente el mejor
de la porcin era joya
[ZANI83]. Zaniolo propuso agregar las siguientes construcciones al modelo
relacional,
Junto con las extensiones de lenguaje de consulta correspondientes:
1) establecer los atributos de valor. En una tabla de piezas, a menudo es el
caso de que hay un atributo,
Tales como available_colors, que puede tomar un conjunto de valores. Sera
bueno agregar un dato
Escriba al modelo relacional para tratar con conjuntos de valores.
2) la agregacin (tupla referencia como un tipo de datos). En la relacin de
suministro sealada anteriormente,
hay dos claves externas, sno y pno, que apuntan efectivamente a tuplas en
otras tablas. Eso
que es posiblemente ms limpio para tener la Tabla de origen tienen la
siguiente estructura:
Suministro (PT, SR, cantidad, precio)
Aqu el tipo de datos de PT es "tupla en la tabla de la Parte" y el tipo de datos
de la SR es "tupla en
la tabla de proveedores ". Por supuesto, la aplicacin prevista de estos tipos de
datos se realiza a travs
algn tipo de puntero. Con estas construcciones sin embargo, podemos
encontrar los proveedores que
suministrar piezas rojas como:
Seleccionar Supply.SR.sno
De suministro
Donde Supply.PT.pcolor = "red"
Esta notacin "punto en cascada" permite una para consultar la tabla de
alimentacin y luego con eficacia
tuplas de referencia de otras tablas. Esta notacin de puntos en cascada es
similar a la trayectoria
expresiones visto en los idiomas de red de alto nivel, tales como LSL. Se
permiti una atravesar
entre las tablas sin tener que especificar unirse a una explcita.
3) la generalizacin . Supongamos que hay dos clases de piezas en nuestro
ejemplo, dicen elctrica
partes y piezas de fontanera. Para las piezas elctricas, registramos el
consumo de energa y la

voltaje. Para las piezas de fontanera registramos el dimetro y el material

utilizado para hacer la
parte. Esto se muestra grficamente en la Figura 9, en la que vemos una parte
de la raz con dos
especializaciones. Cada especialidad hereda todos los atributos de datos de
sus antepasados.
jerarquas de herencia se pusieron en los primeros lenguajes de programacin
tales como Planificador
[HEWI69] y Conspirador [MCDO73]. El mismo concepto se ha incluido en
ms
lenguajes de programacin recientes, como C ++. Gem se limit a aplicar este
conocido
concepto a bases de datos.
Lo que se siembra de recoge
17
Pgina 17

Una jerarqua de herencia

Figura 9
En la gema, se podra hacer referencia a una jerarqua de herencia en el
lenguaje de consulta. Por ejemplo
para encontrar los nombres de los componentes elctricos rojos, se debera
usar:
Seleccionar E.pname
De elctrico E
Donde E.pcolor = "red"
Adems, Gema tena un tratamiento muy elegante de los valores nulos.
El problema con las extensiones de este tipo es que, si bien permite la consulta
ms fcil
formulacin que estaba disponible en el modelo relacional convencional,
ofrecieron muy
poca mejora el rendimiento. Por ejemplo, las relaciones de clave-extranjeraclave primaria en
el modelo relacional simular fcilmente tupla como un tipo de datos. Adems,
dado que las claves externas
son punteros esencialmente lgicos, el rendimiento de esta construccin es
similar a la
disponible en algn otro tipo de esquema de puntero. Por lo tanto, una
implementacin de Gem
no sera notablemente ms rpido que una implementacin del modelo
relacional
A principios de la dcada de 1980, los proveedores relacionales se han
centrado en mejorar singularmente

rendimiento de las transacciones y la escalabilidad de sus sistemas, de modo

que pudieran ser utilizados para
grandes aplicaciones de procesamiento de datos empresariales escala. Este fue
un mercado muy grande que tena
potencial de ingresos importante. Por el contrario, las ideas de I ++ tendran
un impacto menor. Por lo tanto, hay
haba poca transferencia de tecnologa de las ideas R ++ en el mundo
comercial, y esta investigacin
enfoque tuvo muy poco impacto a largo plazo.
Parte (PNO, pname,
psize, pcolor
Elctrico
(poder,
voltaje)
Plomera
(dimetro,
material)
18
Captulo 1: Modelos y datos DBMS Arquitectura
Pgina 18

Leccin 12: A menos que haya un gran rendimiento o funcionalidad ventaja,

nuevas construcciones
ir a ninguna parte.
VII La semntica de datos Modelo poca
Aproximadamente al mismo tiempo, hubo otra escuela de pensamiento con
ideas similares, pero una
diferente estrategia de marketing. Sugirieron que el modelo de datos
relacional es
"Semnticamente empobrecida", es decir, es incapaz de expresar fcilmente
una clase de datos de
interesar. Por lo tanto, hay una necesidad de un modelo de datos "post
relacional".
modelos de datos relacional mensaje No se suele llamar modelos semnticos
de datos. Ejemplos
incluido el trabajo de Smith y Smith [SMIT77] y Hammer y McLeod
[HAMM81].
SDM desde Hammer y McLeod es sin duda el modelo de datos semntico ms
elaborado,
y nos centramos en sus conceptos de esta seccin.
SDM se centra en la nocin de clases , que son una coleccin de registros de
la obediencia a la misma
esquema. Al igual que la gema, SDM explotado los conceptos de agregacin y
generalizacin y

incluida una nocin de conjuntos. La agregacin se apoya al permitir a clases

tienen atributos
que son registros en otras clases. Sin embargo, SDM generaliza el constructo
de agregacin en
Gem permitiendo un atributo en una clase a ser un conjunto de instancias de
registros en algunos
clase. Por ejemplo, puede haber dos clases, Barcos y Pases. La clase Pases
podra tener un atributo llamado Ships_registered_here, teniendo como valor
de una coleccin de
los buques. La inversa de atributo, country_of_registration tambin se puede
definir en SDM.
Adems, las clases pueden generalizar a otras clases. A diferencia de la gema,
la generalizacin se extiende
ser un grfico en lugar de slo un rbol. Por ejemplo, la Figura 10 muestra un
grfico generalizacin
donde American_oil_tankers hereda los atributos de ambos y Oil_tankers
American_ships. Esta construccin se llama a menudo la herencia
mltiple . Las clases tambin pueden ser
la unin, interseccin o diferencia entre las otras clases. Tambin pueden ser
una subclase
de otra clase, especificado por un predicado para determinar la
pertenencia. Por ejemplo,
Heavy_ships podra ser una subclase de los buques con un peso superior a 500
toneladas. Por ltimo, una
clase tambin puede ser una coleccin de registros que se agrupan por alguna
otra razn.
Por ejemplo Atlantic_convoy podra ser una coleccin de barcos que navegan
juntos
a travs del Ocano Atlntico.
Por ltimo, las clases pueden tener variables de clase, por ejemplo, la clase de
los buques pueden tener una clase
variable que es el nmero de miembros de la clase.
La mayora de los modelos semnticos de datos eran muy complejas, y en
general fueron las propuestas de comunicacin.
Varios aos despus se defini SDM, Univac explor una implementacin del
martillo
y las ideas de McLeod. Sin embargo, rpidamente se descubri que era un
SQL intergalctico
estndar, y su sistema incompatibles no tuvo mucho xito en el mercado.
Lo que se siembra de recoge
19
Pgina 19

Un ejemplo de herencia mltiple

Figura 10
En nuestra opinin, SDM tena los mismos dos problemas que enfrentan los
defensores de I ++. Como el
propuestas de I ++, que eran una gran cantidad de maquinaria que fue fcil
para simular el relacional
Sistemas. Por lo tanto, no haba propuesto muy poca influencia en las
construcciones. los
campo de SDM tambin se enfrent a la segunda edicin de R ++ propuestas,
a saber, que la estableci
vendedores estaban distrados con un rendimiento de procesamiento de
transacciones. Por lo tanto, los datos semntica
modelos tenan poca influencia a largo plazo.
VIII OO poca
A partir de mediados de la dcada de 1980 hubo una "ola" de inters en
Object-Oriented
DBMS (OODB). Bsicamente, esta comunidad apunt a una "falta de
concordancia"
entre las bases de datos relacionales y lenguajes como C ++.
En la prctica, las bases de datos relacionales tenan sus propios sistemas de
nomenclatura, su propio tipo de datos
sistemas, y sus propias convenciones para el retorno de datos como resultado
de una consulta. Lo que sea
lenguaje de programacin se utiliza junto con una base de datos relacional
tambin tena su propia versin
de todas estas instalaciones. Por lo tanto, para unir una aplicacin a la base de
datos requiere una
conversin del "lenguaje de programacin hablar" a "hablar base de datos" y
la espalda. Esta
era como "encolado de una manzana sobre un panqueque", y fue la razn de la
llamada
desajuste de impedancia.
Buques
Tanques de aceite
American_ship
American_Oil_tankers
20
Captulo 1: Modelos y datos DBMS Arquitectura
Pgina 20

Por ejemplo, considere el siguiente fragmento de cdigo C ++ que define una

estructura de partes y luego
asigna un Example_part.
Parte struct {
int numero;

Nombre del personaje;

Char * grandeza;
Char * del color;
Example_part};
Todos los sistemas SQL en tiempo de ejecucin incluye mecanismos para
cargar variables en el anterior Struct
a partir de valores en la base de datos. Por ejemplo, para recuperar parte 16 en
lo anterior Struct
se requiere el siguiente programa estilizada:
Definir cursor P como
Seleccionar *
De Parte
Donde Pno = 16;
P Abrir en Example_part
Hasta sin ms {
Fetch P (= Example_part.number PNO
Example_name = pname
Example_part.bigness = psize
Example_part.color = pcolor)
}
El primero define un cursor para desplazarse en la respuesta a la consulta
SQL. Entonces, uno abierto
el cursor, y finalmente fue a buscar un registro del cursor y la at a la
programacin
variables de idioma, que no necesitan ser el mismo nombre o tipo que el que
corresponde
objetos de la base de datos. Si es necesario, la conversin de tipo de datos se
realiz por el tiempo de ejecucin
interfaz.
El programador ahora poda manipular el Struct en el lenguaje de
programacin nativo.
Cuando ms de un registro podra ser el resultado de la consulta, el
programador tena que recorrer
el cursor como en el ejemplo anterior.
Parecera ser mucho ms limpio para integrar la funcionalidad DBMS ms de
cerca en una
lenguaje de programacin. En concreto, a uno le gustara una programacin
persistente
lengua , es decir, uno donde las variables en el lenguaje podran representar
los datos basados en disco como
as como los principales datos de la memoria y, en su criterio de bsqueda de
bases de datos tambin fueron idioma
construcciones. Varios prototipos de idiomas persistentes se desarrollaron en
la dcada de 1970,

incluyendo Pascal-R [SCHM77], Rigel [ROWE79], y una incrustacin de

idioma para PL / 1
[DATE76]. Por ejemplo, Rigel permiti la consulta anterior para ser
expresado como:
Lo que se siembra de recoge
21
Pgina 21

Para P en la parte donde P.pno = 16 {

Code_to_manipulate_part
}
En Rigel, como en otros idiomas persistentes, las variables (en este caso PNO)
podran ser declarados.
Sin embargo, slo necesitaban ser declarado una vez para Rigel, y no una vez
a la lengua
y una segunda vez en el DBMS. Adems, el p.no predicado = 16 es parte de la
Rigel
lenguaje de programacin. Por ltimo, uno us los iteradores de lenguaje de
programacin estndar
(En este caso un bucle For) para iterar sobre los registros de calificacin.
Un lenguaje de programacin persistente es, obviamente, mucho ms limpio
que una incrustacin de SQL.
Sin embargo, requiere el compilador para el lenguaje de programacin para
ser extendido con
funcionalidad DBMS orientado. Puesto que no hay lenguaje de programacin
Esperanto, este
extensin debe hacerse una vez por compilador. Por otra parte, cada extensin
ser probablemente
nico, ya que C ++ es bastante diferente de, por ejemplo, APL.
Por desgracia, los expertos del lenguaje de programacin se han negado
sistemticamente a centrarse en la I / O
en la funcionalidad general y, en particular, DBMS. Por lo tanto, todos los
lenguajes de programacin que
somos conscientes de ningn hayan funcionalidad integrada en esta rea. No
slo esta marca
la incorporacin de los datos sublenguas tedioso, sino tambin el resultado
suele ser difcil de programar
y propenso a errores. Por ltimo, los conocimientos de idiomas no consigue
aplicar a importantes especial
lenguajes orientados a datos de usos, tales como los generadores de informes
y la llamada cuarta generacin
idiomas.
Por lo tanto, no hubo transferencia de tecnologa del lenguaje de
programacin persistente

los esfuerzos de investigacin de la dcada de 1970 en el mercado comercial y

de datos feos
incrustaciones de sublenguaje prevalecieron.
A mediados de la dcada de 1980 se produjo un resurgimiento del inters en
los lenguajes de programacin persistentes,
motivado por la popularidad de C ++. Este empuje investigacin se llama
orientada a objetos
Bases de datos (OODB), y se centraron principalmente en C ++
persistente. Aunque los primeros trabajos
procedan de la comunidad de investigacin con sistemas como el Jardn
[SKAR86] y el xodo
[RICH87], el empuje principal en BDOO proceda de una coleccin de nuevas
empresas, incluidas las
Ontologic, Diseo de objetos y Versant. Todos los sistemas comerciales
construidos que apoyaron
C ++ persistente.
La forma general de estos sistemas era apoyar C ++ como un modelo de
datos. Por lo tanto, cualquier C ++
estructura podra ser persisti. Por alguna razn, era popular para extender C
++ con el
nocin de relaciones, un concepto tomado directamente de los datos entidadrelacin
modelar una dcada antes. Por lo tanto, varios sistemas extendieron el C ++ en
tiempo de ejecucin con el apoyo
por este concepto.
La mayor parte de la comunidad OODB decidi abordar las bases de datos de
ingeniera como su objetivo
mercado. Un ejemplo tpico de esta zona es de ingeniera CAD. En una
aplicacin CAD, una
ingeniero abre un dibujo de ingeniera, digamos por un circuito electrnico, y
luego modifica
el objeto de ingeniera, pruebas, o se ejecuta un simulador de potencia en el
circuito. Cuando se hace
22
Captulo 1: Modelos y datos DBMS Arquitectura
Pgina 22

que cierra el objeto. La forma general de estas aplicaciones es abrir un gran

objeto de ingeniera y luego la procesan extensivamente antes de cerrarlo.
Histricamente, estos objetos se lee en la memoria virtual mediante un
programa de carga. Esta
programa podra "Swizzle" una representacin basada en disco del objeto en
una memoria virtual

C ++ objeto. La palabra "Swizzle" vino de la necesidad de modificar los

punteros en
el objeto al cargar. En el disco, los punteros son tpicamente algn tipo de
referencia lgica
tales como una clave externa, aunque tambin pueden ser punteros de disco,
por ejemplo (bloque de nmeros,
compensar). En la memoria virtual, que deberan ser los punteros de memoria
virtual. Por lo tanto, el cargador
tenido en Swizzle la representacin en disco para una representacin de la
memoria virtual. Entonces, el cdigo
operara en el objeto, por lo general por un largo tiempo. Cuando haya
terminado, un descargador hara
linealizar la estructura de datos de C ++ de nuevo en uno que podra persistir
en el disco.
Para abordar el mercado de la ingeniera, una implementacin de C ++
persistente tena la
los siguientes requisitos:
1) sin necesidad de un lenguaje de consulta declarativa. Todo lo que uno
necesita es una manera de hacer referencia a
grandes objetos de ingeniera basados en disco en C ++.
2) sin necesidad de gestin de transacciones de lujo. Este mercado es en gran
parte de un usuario-a-atiempo de procesamiento de objetos de ingeniera de gran tamao. Ms bien,
algn tipo de sistema de control de versiones
sera bueno.
3) El sistema de tiempo de ejecucin tena que ser competitivo con C ++
convencional cuando
operativo en el objeto. En este mercado, el rendimiento de un algoritmo
utilizando
persistente C ++ tena que ser competitivo con la disponible a partir de una
carga de encargo
programa y C ++ convencional
Naturalmente, los vendedores OODB se centraron en el cumplimiento de
estos requisitos. Por lo tanto, no haba
dbil apoyo para las transacciones y consultas. En cambio, los vendedores se
centraron en buena
rendimiento para la manipulacin de estructuras persistentes C ++. Por
ejemplo, considere la
siguiente declaracin:
Persistente int i;
Y a continuacin, el fragmento de cdigo:
I =: I + 1;
En convencional C ++, esta es una sola instruccin. Para ser competitivo,
incrementando un

la variable persistente no puede requerir un interruptor de un proceso a otro un

objeto persistente. Por lo tanto,
el DBMS debe ejecutarse en el mismo espacio de direcciones como la
aplicacin. Del mismo modo, la ingeniera
los objetos se deben almacenar en cach de manera agresiva en la memoria
principal, y luego "perezosa" vuelven a escribir
disco.
Por lo tanto, las BDOO comerciales, por ejemplo, objeto de diseo
[LAMB91], tena innovadora
arquitecturas que han logrado estos objetivos.
Lo que se siembra de recoge
23
Pgina 23

Por desgracia, el mercado para este tipo de aplicaciones de ingeniera nunca

lleg muy grande, y
haba demasiados vendedores que compiten por un mercado "nicho". En la
actualidad, todos
los vendedores OODB han fallado o han reposicionado sus empresas para
ofrecer algo
aparte de y OODB. Por ejemplo, el diseo de objetos ha cambiado el nombre
a s mismos Excelon,
y es la venta de servicios XML
En nuestra opinin, hay una serie de razones para esta falla del mercado.
1) ausencia de apalancamiento. Los vendedores OODB presentan al cliente la
oportunidad de evitar la escritura de un programa de carga y un programa de
descarga. Esto no es una
gran servicio, y los clientes no estaban dispuestos a pagar grandes cantidades
de dinero para esta funcin.
2) No hay normas. Todas las ofertas de los proveedores OODB eran
incompatibles.
3) Volver a vincular el mundo. En cambiado algo, por ejemplo un mtodo de
C ++ que operaba
en los datos persistentes, entonces todos los programas que utilizan este
mtodo se tuvieron que vuelvan a vincular.
Este fue un problema de gestin notable.
4) No hay lenguaje de programacin Esperanto. Si la empresa tena una sola
aplicacin
No est escrito en C ++ que necesitan acceder a datos persistentes, entonces
no se podra utilizar
uno de los productos OODB.
Por supuesto, los productos OODB no fueron diseados para trabajar en el
procesamiento de datos de negocios

Aplicaciones. No slo carecen de sistemas de transacciones y consultas de

fuertes sino que tambin
corri en el mismo espacio de direcciones que la aplicacin. Esto significaba
que la aplicacin podra
manipular libremente todos los datos basados en disco, y sin la proteccin de
datos fue posible. Proteccin y
autorizacin es importante en el mercado de procesamiento de datos de la
empresa. Adems, BDOO
eran claramente un tiro de nuevo a los das CODASYL, es decir, un registro
de bajo nivel a la vez
idioma con el programador de codificacin del algoritmo de optimizacin de
consultas. Como resultado,
estos productos tenan esencialmente sin penetracin en este mercado muy
grande.
No haba una sola compaa, O2, que tena un plan de negocio diferente. O2
apoy un objetoorientada modelo de datos, pero no era C ++. Adems, en medio de un alto
nivel declarativo
lengua llamada NCO en un lenguaje de programacin. Por lo tanto,
propusieron lo
ascendi a un modelo de datos semntico con un lenguaje de consulta
declarativa, pero comercializado como
un OODB. Asimismo, se concentraron en el procesamiento de datos de la
empresa, no en la ingeniera
espacio de aplicacin.
Por desgracia para O2, hay un dicho que "a medida que pasa los Estados
Unidos pasa el resto de la
mundo". Esto significa que los nuevos productos deben hacerlo en Amrica
del Norte, y que el resto
del mundo observa los EE.UU. por la aceptacin del mercado. O2 era una
empresa francesa, se sali
de Inria por Francois Bancilhon. Fue difcil para O2 para conseguir una
traccin de mercado en Europa
con un producto avanzado, debido a el dicho anteriormente. Por lo tanto, O2
cuenta que tenan que
atacar el mercado de Estados Unidos, y se traslad a los Estados Unidos y no
al final del juego. Para entonces,
era simplemente demasiado tarde, y la era OODB estaba en una espiral
descendente. Es interesante
conjeturas acerca de las posibilidades de mercado de O2 si haban comenzado
inicialmente en el EE.UU.
con sofisticados respaldo de capital riesgo de Estados Unidos.
Leccin 13: Los paquetes no se venden a los usuarios a no ser que se
encuentren en "gran dolor"
24

Captulo 1: Modelos y datos DBMS Arquitectura

Pgina 24

Leccin 14: idiomas persistentes irn a ninguna parte sin el apoyo de la

programacin
comunidad lingstica.
IX La Era-relacional de objetos
El objeto-relacional (O) era fue motivado por un problema muy simple. A
principios
das de INGRES, el equipo se haba interesado en los sistemas de informacin
geogrfica (GIS)
y haban sugerido mecanismos para su apoyo [GO75]. Alrededor de 1982, los
siguientes
cuestin sencilla SIG se cierne sobre el equipo de investigacin
INGRES. Supongamos que se quiere almacenar
posiciones geogrficas en una base de datos. Por ejemplo, uno puede querer
almacenar la ubicacin de
una coleccin de intersecciones como:
Intersecciones (I-id, larga, lat, otra-datos)
A continuacin, se requiere almacenar los puntos geogrficos (a largo, lat) en
una base de datos. Entonces, si queremos
encontrar todas las intersecciones dentro de un rectngulo delimitador, (X0,
Y0, X1, Y1), entonces el SQL
consulta es:
Seleccione I-id