Temario Oposicin a

Tcnicos Auxiliares de Informtica

(BOE 03 NOV 2015)

Considerando los Reyes, de gloriosa memoria, cunto era provechoso e honroso

que a estos sus Reinos se truxiesen libros de otras partes, para que con ellos se
ficiesen los hombres letrados, quisieron e ordenaron: que de los libros non se
pagase alcabala, y porque de pocos das a esta parte, algunos mercaderes
nuestros, naturales y extranjeros, han trahido y cada da trahen libros mucho
buenos, lo cual, por este que redunda en provecho universal de todos, e
ennoblecimiento de nuestros Reinos; por ende, ordenamos e mandamos que,
allende de la dicha franquiza, de aqu en adelante, de todos los libros que se
truxeren a estos nuestros Reinos, as por mar como por tierra, non se pida, nin se
pague, nin lleve almoxarifazgo, nin diezmo, nin portazgo, nin otros derechos algunos
por los nuestros Almoxarifes, nin los Desmeros, nin Portazgueros, nin otras
personas algunas, as como las cibdades e villas e lugares de nuestra Corona Real,
como de Seoros e rdenes e behenias; ms que de todos los dichos derechos o
almoxarifazgos sean libres e francos los dichos libros.
Orden de los Reyes Catlicos

1
 TODOS LOS TEXTOS DE ESTOS APUNTES LLEVAN LA
SIGUIENTE LICENCIA, EXCEPTO SI SE INDICA LO CONTRARIO

Edicin: 1 Edicin Julio 2.015

Ttulo: Temario Oposicin a Tcnicos Auxiliares de Informtica

Autor: http://apuntedecaramelo.blogspot.com.es/

2
 TEMA 5. SGBD RELACIONALES. CARACTERSTICAS Y COMPONENTES. SGBD ORIENTADOS A
OBJETOS

1. INTRODUCCIN
2. SGBD RELACIONALES
2.1. Arquitectura de BBDD
2.2. Modelo relacional
3. CARACTERSTICAS Y COMPONENTES
3.1. Estructura
3.2. Componentes
4. SGBD ORIENTADOS A OBJETOS

132
1. INTRODUCCIN
Una de los aspectos ms importantes de la informtica es el proceso de grandes cantidades de informacin.
Para ello se utilizan los Sistemas Gestores de BBDD, en adelante abreviado como SGBD.
Manejar mucha informacin, es un problema que inicialmente se solucion con ficheros ms o menos
organizados. En principio esto mejora la eficiencia, ya que el fichero est adaptado al programa que lo usa,
pero a largo plazo puede resultar una solucin ms lenta si se utiliza otro programa, o se crea un nuevo
fichero. Se pueden generar problemas de coherencia, redundancia y actualizacin. Adems, esta
organizacin impone normas rgidas en la bsqueda y recuperacin de informacin, la relacin entre los
datos no siempre est definida, as como los aspectos de seguridad.
Otros problemas son la dependencia del programa respecto de los datos o el acceso concurrente. Para ello,
estos problemas vienen a solucionarse con los SGBD, cuyos primeros modelos eran jerrquicos o en red.
Actualmente se ha impuesto el modelo relacional y se estn probando con xito modelos orientados a
objetos o datos XML.
Los SGBD suponen una abstraccin de datos, al ocultar al usuario los detalles del almacenamiento. Para
conseguir esta abstraccin se usan los modelos de datos, que sirven para describir la estructura de una
BBDD, definiendo los datos, sus relaciones y sus restricciones. Tambin suele incluirse como parte del
modelo de datos las operaciones que se permiten y las que puede definir el usuario.
Los modelos de datos se suelen clasificar en funcin del nivel de la arquitectura al que operan. As, se
distinguen los modelos de datos de alto nivel, o conceptuales, ms cercanos al usuario, los modelos lgicos
y los modelos de bajo nivel, o fsicos, que se refieren a la implementacin del almacenamiento de los datos
en los sistemas, ms orientados a los administradores.
Los modelos conceptuales manejan conceptos como las entidades, atributos o relaciones. Los modelos de
datos lgicos ocultan detalles del almacenamiento, pero pueden implementarse directamente. Los fsicos se
refieren a aspectos como el formato de registros, la estructura de ficheros o mtodos de acceso. Cada
SGBD se basa en un modelo lgico, destacando el relacional, de red y el jerrquico.
El esquema de una BBDD es la descripcin de la misma con un modelo de datos. El estado u ocurrencia de
la BBDD se refiere al de los datos en un determinado momento. As, al definir una BBDD, se define su
esquema. Al principio, el estado ser vaco. Al cargar los datos iniciales, se pasa al estado inicial. Las
sucesivas operaciones marcarn los sucesivos estados.
2. SGBD RELACIONALES
Un SGBD se define como indica su nombre:
Sistema. Conjunto coordinado de componentes (programas, procedimientos, lenguajes).
Gestor. Supone para sus usuarios el medio para operar con los datos que almacena.
De BBDD. Almacena los datos en una BBDD.
Que sea un sistema, es una generalidad, que se refiere al conjunto. Que sea gestor implica la definicin de
una arquitectura (modelo estructural y funcional) y que sea sobre una BBDD, implica que se deben cumplir
condiciones de integridad, concurrencia, confidencialidad o seguridad, entre otros.
2.1. Arquitectura de BBDD
La arquitectura de una BBDD, define su modelo estructural y el funcional. En 1975, el comit ANSI-SPARC
(American National Standard lnstitute- Standards Planning and Requirements Committee) propuso una
arquitectura de tres niveles para los SGBD, muy adaptado a la tarea de su definicin.
El objetivo es separar la implementacin fsica de los programas de aplicacin de la BBDD. Los 3 niveles de
abstraccin que distingue son el nivel externo, el conceptual y el interno. Los niveles externos y conceptual,
podran englobarse como modelo funcional de la BBDD y el interno como modelo estructural.
As, el nivel externo describira esquemas externos o vistas de usuario. La parte de la BBDD interesante a
un grupo de usuarios desde un punto de vista funcional. Usa modelos lgicos para especificar esquemas.
Del mismo modo, el nivel conceptual describe la BBDD con un esquema que describe entidades, atributos,
relaciones, operaciones y restricciones. Usa modelos conceptuales o lgicos. Por tanto, ambos niveles
pueden entenderse como el modelo funcional de la BBDD.
El nivel interno describe la estructura fsica de la BBDD con un esquema que especifica un modelo fsico y
describe los detalles del almacenamiento y mtodos de acceso. Se puede entender como el modelo
estructural. Los 3 niveles o esquemas que define ANSI-SPARC representan distintos niveles de abstraccin.
En un SGBD basado en la arquitectura de 3 niveles, un usuario har referencia a su esquema externo. Por

133
tanto, el SGBD debe traducir sus operaciones en trminos del esquema conceptual hasta llegar al esquema
interno, que se procesar sobre la BBDD, de forma anloga a la compilacin, por ejemplo. El proceso de
traduccin se denomina transformacin o correspondencia.
Este mtodo de abstraccin permite dotar a los datos de independencia. La capacidad de modificar el
esquema en un nivel sin afectar a los otros. Se identifican 2 tipos de independencia de datos: lgica y fsica.
La independencia lgica es la capacidad de modificar el esquema conceptual sin alterar esquemas externos
ni programas de aplicacin. Se puede modificar el esquema conceptual para modificar la BBDD. La
independencia fsica es la capacidad de modificar el esquema interno sin alterar esquemas externos o
conceptuales.
2.2. Modelo relacional
Un SGBD relacional (SGBDR o RDBMS) es un SGBD que gestiona datos bajo una estructura llamada
relacin basada en la teora de conjuntos propuesta por Codd (1970). La gestin se realiza con Clculo y
lgebra relacional. Supone la segunda generacin de la evolucin de los SGBD. Estructura los datos a nivel
lgico con tablas formadas por filas y columnas. A nivel fsico pueden presentar otra estructura. Su
simplicidad lgica, basado en la teora de conjuntos lo hace adecuado y muy extendido.
Las caractersticas del modelo relacional se resumen en estructuras de datos relacionadas, que presentan
al usuario la informacin en forma de tablas independientemente de su almacenamiento. Supone una base
slida para la seguridad de los datos, controlando su valor por la pertenencia a un dominio, evitando
duplicidades y consiguiendo integridad. Permite la manipulacin de las relaciones en forma de conjuntos,
basado en teora de conjuntos (lgebra relacional) y en la lgica de predicados (clculo relacional).
El modelo de datos relacional es ampliamente usado en la actualidad. Su funcionalidad se resume en el
establecimiento de cinco objetivos: independencia fsica y lgica, flexibilidad, uniformidad y sencillez. La
independencia fsica separa el almacenamiento de datos de su tratamiento, mientras la independencia
lgica lo hace del cdigo del gestor. La flexibilidad ofrece al usuario diversas opciones de presentacin de
datos y la uniformidad y sencillez se refieren a la forma de organizacin de datos normalizada y de fcil uso.
El elemento central del modelo es la relacin (tabla) como estructura sobre la que se realiza toda operacin.
Una tabla se organiza en tuplas o registros, con el mismo nmero de campos (columnas). El tipo de datos
de un campo ha de ser igual en todos los registros. La informacin se recupera con consultas de un
lenguaje estndar como pueda ser SQL.
Para implementar el modelo se propusieron 12 recomendaciones o reglas, enumeradas en la tabla. En la
actualidad no se soportan por completo, como en el caso de la actualizacin de vistas y la distribucin.
Regla Significado Regla Significado
Informacin Representada con tablas Distribucin Soporte a BBDD distribuidas
Tratamiento de Lgica de tres valores Catlogo en El catlogo se consulta igual que
valores nulos lnea dinmico los datos
Alto nivel de insercin Posibilidad de hacerlo con Lenguaje Debe existir un lenguaje
actualizacin y conjuntos o por filas completo de expresable con caracteres para
supresin datos acceso completo
No subversin A bajo nivel se respetan Independencia La integridad no debe depender
las restricciones de integridad del lenguaje
Independencia lgica Los cambios en tablas no Independencia Los cambios fsicos afectarn a
de datos afectarn a programas fsica de datos programas
Acceso garantizado Acceso a tabla, clave y Actualizacin Todas las vistas actualizables el
columna de vistas sistema debe poder actualizarlas
El diseo de BBDD y su representacin grfica suele usar el modelo entidad-relacin. Se usan distintas
formas; rectngulos para las entidades (tablas), elipses para atributos o columnas (si son clave primaria se
subrayan y se indica si es atmico o multivaluado), polgonos para asociaciones de entidades y rectngulos
dobles para entidades y asociaciones dbiles dependientes de una entidad padre.
Una entidad que puede especializarse se representa con un tringulo. Los atributos tambin pueden
representarse con un crculo con el nombre, que ser negro si es clave primaria y la mitad negro y mitad
blanco si es clave alternativa. Si es multivaluado se usa una flecha y si es opcional puntos suspensivos.

134
Si el atributo est compuesto de otros, se unen a la entidad con la misma lnea. El grado de la asociacin
indica el nmero de entidades y se representa como M:N. La cardinalidad define el mximo y mnimo
nmero de ocurrencias de una entidad en una asociacin y se representa (0,1), (1,1), (0,M), (1,M), o (M,N).
El diseo debe definir primero las entidades, sus atributos y la clave primaria. Una vez realizado se
establecen las relaciones entre entidades, indicando tipo y cardinalidad. En general, se comienza realizando
una descripcin escrita en lenguaje natural y como orientacin se identifican entidades con sustantivos y
atributos y los verbos pueden indicar asociaciones.
Una vez diseado el modelo E/R se transforma en relacional construyendo tablas a partir de entidades. Las
relaciones M:N y los atributos mltiples definirn tablas. Si existe una entidad especializada, se puede
eliminar la entidad padre, lo que es redundante o eliminar las entidades hijas y dar todos los atributos a la
entidad padre, lo que genera valores nulos.
Las asociaciones binarias son ms complejas a cambio de claridad y jerarqua, por lo que es de las ms
usadas. Las asociaciones 1:1 con cardinalidad (1,1) se suelen agrupar en una tabla y si la cardinalidad es
distinta se puede usar una tabla para la relacin o aadir una clave fornea como en la relacin 1:M en la
tabla M.
La relacin N:M siempre necesitar una tercera tabla para la relacin, al igual que si existen ms de dos
entidades. Las asociaciones reflexivas de cardinalidad 1 usarn una clave fornea a su clave principal y si
es N:M se usar una tabla para la relacin.
La transformacin de modelos aconseja evitar redundancias y garantizar la integridad, lo que se consigue
normalizando la BBDD. Para ello se distinguen 5 formas de normalizacin, de las que al menos deben
realizarse las conocidas como 3 primeras. Si se decide desnormalizar por algn motivo particular de
implementacin deben prevenirse las posibles incoherencias. Las formas normales son las siguientes.
Primera forma normal. Es la de una BBDD en que el valor de los dominios de los atributos es nico o
atmico, es decir, para cada campo de un registro (fila) hay un solo valor, no un conjunto. Se consigue
eliminando grupos repetitivos, informacin derivada, opcionalidad y especializacin.
Ejemplo: Sea una tabla de contabilidad con una columna facturas, que puede tener distintos valores, con lo
que no estara en primera forma normal. La transformacin de la BBDD sera eliminar esa columna de la
tabla y crear otra llamada facturas con un identificador nico para cada factura. Esto requerira otra tabla
para relacionar contabilidad y facturas. De esta forma la BBDD cumplira la primera forma normal.
Segunda forma normal. Es la de una BBDD en primera forma normal y cada atributo distinto de la clave
primaria tiene dependencia funcional completa de la clave candidata. Es decir, conociendo el valor de un
atributo puede conocerse el valor de otro.
Ejemplo: Sea una tabla con atributos usuario, artculo y domicilio. Si un usuario puede asociarse a varios
artculos, por cada registro, el domicilio se repetir tantas veces como el registro del usuario. Esto podra
dar lugar a incongruencias. Por tanto, si se crea otra tabla con un registro que tenga como campos el
usuario y domicilio, este atributo slo depender del usuario y por tanto se tendr la BBDD en segunda
forma normal.
Tercera forma normal. Una BBDD est en tercera forma normal si lo est en la segunda y no hay
dependencias entre atributos no clave, o sea, un atributo que no sea clave primaria no depende de otro
distinto a la clave primaria. Una versin ms restrictiva de esta forma es la forma normal de Boyce-Codd, en
la que todo determinante (atributo que determina completamente a otro) es clave candidata.
Ejemplo: Sea una tabla con atributos cdigo, usuario y telfono. El telfono depende del usuario, que a su
vez depende del cdigo, existiendo una dependencia transitiva que puede generar incoherencias al no
impedirse que el mismo usuario se muestre con distintos telfonos en distintos registros.
Por tanto, la solucin pasa por la creacin de otra tabla que relacione un usuario como clave fornea con un
telfono.
La mayora de tablas en tercera forma normal no presentan incoherencias a la hora de actualizar, insertar o
borrar y si se dan, pueden evitarse con las formas de Boyce-Codd o formas normales ms altas, que
sucesivamente eliminan dependencias ms indirectas entre campos.
Cuarta forma normal. Cada dependencia mltiple no funcional est definida por una clave candidata o un
conjunto de claves primarias. Es decir, si est en tercera forma normal y no presenta dependencias
mltiples no triviales.
Quinta forma normal. Se da cuando una tabla se encuentra en la cuarta forma normal y cada relacin de
dependencia se define por las claves candidatas. Este tipo de normalizacin se usa raramente por no existir
un conjunto de reglas de inferencia que sean seguras y completas para razonar con las restricciones.

135
3. CARACTERSTICAS Y COMPONENTES
Un SGBD como software destinado a la creacin, control y manipulacin de la informacin de una BBDD
debe incluir funciones como la descripcin del esquema de la BBDD, permitir su manipulacin y gestin, con
operaciones como la consulta, recuperacin o modificacin, ocultando su estructura fsica al usuario,
proveer un diccionario de datos y como se ha comentado, garantizar la integridad de los datos y la
seguridad del acceso y comunicaciones.
La definicin del esquema de la BBDD debe permitir, una vez diseado, describirlo mediante un conjunto de
instrucciones. Esto se realiza con un lenguaje especfico denominado de definicin de datos (DDL).
El acceso a los datos, en general se realizar con algn lenguaje de alto nivel, que se apoyar en un
lenguaje especfico que recibe el nombre genrico de lenguaje de manipulacin de datos (DML). El DML
puede utilizarse de dos formas, bien incluyendo sentencias DML en programas escritos en lenguaje de alto
nivel, bien mediante programas que contengan exclusivamente sentencias propias de este lenguaje. En el
primer caso, el SGBD incluira un precompilador que traduzca instrucciones DML en otras reconocibles por
el compilador del lenguaje de alto nivel (lenguaje anfitrin).
El acceso a la informacin de forma conversacional se refiere a la inclusin de un interfaz de usuario que
permita introducir sentencias directamente para obtener informacin. La funcin de gestin de ficheros es
realizada por un mdulo gestor encargado de la comunicacin con el SO y que podr incluir funciones de
control de usuarios, recuperacin frente a fallos y otras.
El SGBD adems permitir insertar, modificar, borrar y recuperar con un rendimiento aceptable los datos
solicitados. Por facilitar su estudio, se pueden agrupar las funciones de un SGBD en tres niveles. El primero
incluira las funciones relativas a la gestin de tablas o estructuras de datos en memoria secundaria, que
aunque responsabilidad del SO, existen casos en que se delegan en el SGBD para incrementar el
rendimiento. El segundo nivel agrupara las funciones de gestin de los datos almacenados, los enlaces que
se establecen entre ellos y las estructuras que permitan su tratamiento. En el tercer nivel se encontraran
funciones que permiten la interpretacin y anlisis de las peticiones de usuario y la presentacin de los
datos solicitados.
3.1. Estructura
El modelo de datos relacional se estructura en base a elementos y restricciones. Los elementos distinguen
dos estructuras, la relacin (tabla) y la tupla (registro o fila).
La relacin o tabla se apoya en la teora de conjuntos de forma que la
relacin de los conjuntos (dominios) D1, D2,..., Dn es un subconjunto
de su producto cartesiano y n representa el grado de la relacin.
Cada tabla tiene un esquema que define la estructura (metadatos) e
instancias. El esquema define la cantidad de columnas, nombre y sus
atributos, mientras que las instancias son los datos almacenados y no
tienen por qu corresponderse con toda la tabla, ya que puede
trabajarse con subconjuntos. La tabla muestra la correspondencia
entre la notacin formal y la utilizada en SQL.
Una tupla o registro es una lista ordenada de atributos pertenecientes a un dominio. Un atributo posee
nombre, un nmero finito de valores del mismo tipo y es atmico. Una visin que ayuda a comprender la
estructura es identificar tuplas con filas de una tabla y cada campo de la tupla con las columnas. Se define
la cardinalidad como el nmero de tuplas y el grado como el nmero de columnas.
Los tipos de datos son los impuestos por el SGBD aunque se permita que los usuarios generen otros a
partir de los predefinidos. Codd tambin introduce la idea de valor nulo, utilizado para modelar informacin
desconocida, haciendo uso de una lgica triestado en que (V and Nulo > Nulo) y (V or Nulo > Verdadero).
Las restricciones son el segundo fundamento del modelo relacional. Son limitaciones impuestas a los
dominios para evitar incoherencias como la existencia de tuplas imposibles en el sistema modelado. Se
puede diferenciar entre restricciones inherentes y de usuario.
Restricciones inherentes o de unicidad. Exigen que no haya tuplas repetidas, la no existencia de orden
posicional, que cada atributo tenga valor nico y no se admiten estructuras en una tupla.
Restricciones de usuario o de valor no nulo. Obligan a la unicidad con valores no nulos, identificacin y
referencias dbiles (slo los completos), parciales (coinciden los no nulos) y completas (slo los completos
o nulos se comprueban). El clculo relacional tambin permite aadir restricciones.
Otros conceptos importantes de los que se sirve la estructura del modelo son el de clave primaria y ajena.
Clave primaria. Uno o ms atributos (columnas, campos) de una tupla (fila, registro) que la identifican de
136
forma unvoca, cumpliendo por tanto las dos restricciones descritas.
Clave candidata. Clave primaria que no se usa como tal.
Clave ajena o externa. Uno o ms campos de una tabla que coinciden con la clave primaria de otra.
Relaciona tablas. Las relaciones pueden ser 1:1, 1:N o N:M y definen la integridad referencial evitando, por
ejemplo, borrar un registro referenciado por la clave ajena de otro y permiten realizar modificaciones o
borrados en cascada.
3.2. Componentes
A nivel macroscpico o externo, un SGBD podra verse como un sistema compuesto por hw, datos,
programas y usuarios. El hw es el componente fsico donde se almacenan los datos, que se intentar no
sean demasiado redundantes. Los programas son el interfaz entre datos y usuarios, independizando
aplicaciones y SGBD. Gestionan los datos y atienden consultas de las aplicaciones. Los usuarios son
distinguen varios roles, como los usuarios, administradores, programadores y otros.
A nivel interno, el SO proporciona las herramientas bsicas de comunicacin con el hardware, mientras los
componentes de un SGBD pueden varan segn las soluciones comerciales y la implementacin que se
haga del mismo. Pero como componentes comunes a todos se pueden identificar mdulos gestores de
archivos, de BBDD y procesadores de consultas.
El mdulo gestor de archivos administra el almacenamiento de los datos en archivos, ya que en el ltimo
escaln, los datos se tratan como ficheros. El gestor de BBDD est encargado de comunicar el resto de
componentes con los archivos proporcionando una interfaz con la BBDD y el procesador de consultas es el
mdulo encargado de traducir las consultas de un lenguaje de alto nivel como SQL, a consultas de bajo
nivel, permitiendo su optimizacin.
Otros componentes identificables en un SGBD son el lenguaje de descripcin del esquema conceptual, el
lenguaje de definicin de esquemas, mdulos de privacidad e integridad, mdulos generadores de informes
y un lenguaje de consulta de propsito general.
El lenguaje de descripcin del esquema conceptual debe ser sencillo y capaz de evaluar la consistencia de
datos, mientras el lenguaje de definicin de esquemas, debe permitir especificar restricciones de privacidad,
seguridad y acceso. Los mdulos de privacidad tienen entre sus funciones la proteccin de la BBDD frente a
accesos no autorizados y el mdulo de integridad proporcionar la integridad y coherencia de los datos.
Los componentes de un SGBD relacional varan de un sistema a otro. Sin embargo, todos distinguen
mdulos comunes que ofrecen funciones soportadas en servicios bsicos del SO al SGBD.
Procesador de consultas. Tiene por funcin traducir las consultas a instrucciones de bajo nivel del SGBD.
Gestor de la BBDD. Es el interface entre el usuario y los programas de aplicacin. El gestor de la BBDD
acepta consultas y determina los registros a consultar para atender la peticin. Con esta informacin llama
al gestor de ficheros que completa la peticin.
Gestor de ficheros. Gestiona los ficheros en disco que almacenan la BBDD. Establece y mantiene la lista de
estructuras e ndices del esquema interno. En caso de ficheros dispersos, obtiene la direccin de los
registros. No realiza directamente la E/S de datos, pasa la peticin al SO que opera con los datos.
Preprocesador del LMD. Es el encargado de convertir las sentencias del LMO de los programas de
aplicacin, en llamadas a funciones estndar del lenguaje anfitrin. Se coordina con el procesador de
consultas para generar el cdigo apropiado.
Compilador del LDD. Traduce las sentencias del LOO en tablas de metadatos, que se almacenan en el
diccionario de datos.
Gestor del diccionario. Tiene por funcin controlar los accesos al diccionario de datos y su mantenimiento.
Los componentes del SGBD realizan en conjunto unas funciones que se pueden resumir en:
Control de autorizacin. Comprueba que el usuario tiene los permisos necesarios para su accin.
Procesador de comandos. Interpreta y ejecuta las instrucciones de usuario.
Control de integridad. Comprueba que se satisfacen las restricciones de integridad al modificar los datos.
Optimizacin de consultas. Se implementa en mdulos que marcan la estrategia ptima para consultas.
Planificacin (scheduler). Consiste en asegurar que las operaciones concurrentes no presentan conflictos.
Recuperacin. Es el conjunto de funciones tendentes a garantizar que la BBDD permanece en un estado
consistente en caso de fallo.

137
Gestin de buffers. Consiste en transferir los datos entre MP y los dispositivos de almacenamiento
secundario. Estas funciones se integran en el gestor de ficheros o datos.
4. SGBD ORIENTADOS A OBJETOS
Los Sistemas de Gestin de BBDD Orientados a Objetos (SGBDOO) suponen la ampliacin del modelo
relacional para integrar los lenguajes de POO y la complejidad de los nuevos desarrollos de aplicaciones,
incorporando caractersticas como herencia o polimorfismo. El grupo ODMG, Open Database Management
Group, desarrolla el estndar y el modelo de objetos para persistencia, que especifica cmo y qu
elementos deben definirse para conseguirlo.
Se apoya en el lenguaje ODL de definicin de objetos. Existen modelos hbridos, sistemas objeto-
relacionales, como pueden ser Oracle o SQL3 y capas de persistencia que mapean objetos sobre
estructuras relacionales conocidos como ORM, Object Relational Mapping, caso de Hibernate en Java o
Zope en phyton.
En la estructura de un SGBDOO se distinguen objetos, que pertenecen a un tipo y poseen identificador
nico y literales, sin identificador, embebidos en los objetos. Las BBDD son navegacionales y se accede
mediante OQL (Object Query Languaje), que obliga a la manipulacin mediante mtodos de los objetos. Es
el lenguaje de consulta propuesto por ODMG-93 y algunas de sus caractersticas son su sintaxis abstracta
al estilo SQL, semntica formal fcil y acceso declarativo a objetos optimizable de forma sencilla.
Sin embargo, el modelo es complicado, debido a la dificultad de adaptar los conceptos (abstraccin,
encapsulacin, herencia y polimorfismo) que define el paradigma de POO al diseo de BBDD no es fcil.
Por tanto, se suelen encontrar argumentos en su contra.
Por ejemplo, el problema de la encapsulacin surge desde el momento en que las BBDD almacenan datos,
no mtodos ni procedimientos. Si se almacenan mtodos implicara dependencia entre plataformas. Es
decir, el manejo de los datos, accesibles a todos los usuarios, de forma independiente al equipo con que se
realice la consulta.
La operatividad en entornos distintos cliente-servidor est conseguida. As, se puede tener una BBDD en un
servidor de cierto entorno y el cliente en otro, bajo protocolos como TCP/IP o IPX, por ejemplo. Pero al
encapsular mtodos compilados, al servirse al cliente, no todos sern compatibles.
Un SGBDOO puede entenderse como un SGBD de objetos, que permite concurrencia y recuperacin. Lo
que implica la gestin directa de objetos sin traduccin a registros o tablas. Su aspecto de orientacin a
objetos se traduce en 8 caractersticas: abstraccin, encapsulacin, modularidad, jerarqua, control de tipos,
concurrencia, persistencia y genericidad. El aspecto de BBDD implica 5 caractersticas: persistencia,
concurrencia, recuperacin, gestin del almacenamiento secundario y facilidad de consulta.
La persistencia se refiere a la capacidad del programador para que sus datos se conserven al finalizar la
ejecucin de un proceso, de forma que se puedan reutilizar en otros procesos. La concurrencia se refiere a
la gestin de la interaccin simultnea de los usuarios en el sistema, lo que afecta directamente a la
consistencia de la BBDD.
La recuperacin ante fallos pretende dotar de un nivel de respuesta a la BBDD ante fallos, de forma que se
garantice un anterior estado coherente de datos. La gestin del almacenamiento secundario debe ser
soportada de forma transparente al usuario y garantizar la facilidad de consulta de forma eficaz y eficiente.

138