Modelos de datos Convencionales

Apuntes de apoyo UNPA-C.Empresariales

Captulo 1

Modelo de base de datos

ndice invertido
chero plano
Otros modelos lgicos pueden ser:
modelo asociativo
modelo multidimensional
modelo multivalor
modelo semntico
base de datos XML
grafo etiquetado

Composicin de cinco modelos de base de datos

Triplestore
Un modelo de base de datos es un tipo de modelo de datos
que determina la estructura lgica de una base de datos y
de manera fundamental determina el modo de almacenar,
organizar y manipular los datos.

1.1

Relaciones y funciones

Entre los modelos lgicos comunes para bases de datos se Un sistema de gestin de base de datos puede implementar
uno o varios modelos. La estructura ptima depende de la
encuentran:
natural organizacin de los datos de la aplicacin y de los requisitos de sta, que incluyen ritmo de transacciones, abili Modelo jerrquico
dad, mantenibilidad, escalabilidad y coste. La mayor parte
de los sistemas de gestin de bases de datos estn construi Modelo en red
dos sobre un modelo de datos concreto, aunque es posible
Modelo relacional
que soporten ms de uno.
Sobre los distintos modelos fsicos de datos se puede implementar cualquier modelo lgico. La mayora del software de base de datos ofrece al usuario cierto control sobre
la implementacin fsica, dado el impacto que tiene en las
prestaciones.

Modelo entidadrelacin
Modelo entidadrelacin extendido
modelo de objetos

Un modelo no es slo un modo de estructurar los datos:

tambin dene el conjunto de operaciones que se pueden
realizar con los datos. Por ejemplo el modelo relacional dene operaciones como SELECT y JOIN. Aunque esas operaciones no se ofrezcan explcitamente en un lenguaje de
interrogacin dado, proporcionan la base sobre la que un
lenguaje de interrogacin se disea.

modelo documental
Modelo entidadatributovalor
modelo en estrella
Los modelos fsicos de datos incluyen:
2

1.3. MODELOS TEMPRANOS

1.2 Modelo chero plano

Flat File Model
Route No.

Miles

Activity

Record 1

I-95

12

Overlay

Record 2

I-495

05

Patching

Record 3

SR-301

33

Crack seal

En un modelo jerrquico, los datos estn organizados en

una estructura arbrea (dibujada como rbol invertido o
raz), lo que implica que cada registro slo tiene un padre.
Las estructuras jerrquicas fueron usadas extensamente en
los primeros sistemas de gestin de datos de unidad central, como el Sistema IMS por IBM, y ahora se usan para
describir la estructura de documentos XML. Esta estructura permite relaciones 1:N entre los datos, y es muy eciente
para describir muchas relaciones del mundo real: tablas de
contenido, ordenamiento de prrafos y cualquier tipo de informacin anidada.

Sin embargo, la estructura jerrquica es ineciente para

ciertas operaciones de base de datos cuando el camino comModelo chero plano
pleto no se incluye en cada registro. Una limitacin del modelo jerrquico es su incapacidad para representar de maEl modelo de chero plano consiste en una sola matriz bidi- nera eciente la redundancia en datos.
mensional de elementos, donde todos los miembros en una
columna dada tienen valores del mismo tipo, y todos los En la relacin Padre-hijo: El hijo slo puede tener un padre
miembros de la misma la estn relacionados entre ellos. pero un padre puede tener mltiples hijos. Los padres e hiPor ejemplo, las columnas para nombre y clave pueden ser jos estn unidos por enlaces. Todo nodo tendr una lista de
usadas para la seguridad de un sistema; cada la indicar el enlaces a sus hijos.
nombre y su correspondiente clave para un individuo. Las
columnas en la tabla suelen tener un tipo asociado, que la
1.3.2 Modelo de red
dene como cadena de caracteres, fecha u hora, entero o
nmero de coma otante. Este modelo tabular fue el precursor del modelo relacional.
Network Model
Preventive Maintenence

1.3 Modelos tempranos

Estos modelos que se describen a continuacin fueron populares en las dcadas 1960-1970, pero hoy en da se encuentran slo en sistemas heredados. Se caracterizan principalmente por tener caractersticas de navegacin con
fuertes conexiones entre la estructura fsica y la lgica, y
poseen alta dependencia en los datos.

Rigid Pavement

Spall Repair

Joint Seal

Silicone Sealant

1.3.1

Flexible Pavement

Crack Seal

Patching

Asphalt Sealant

Modelo jerrquico
Modelo en red

Hierarchical Model
Pavement Improvement

Reconstruction

Maintenance

Rehabilitation

Routine

Corrective

Preventive

Modelo jerrquico

El modelo de red expande la estructura jerrquica, permitiendo relaciones N:N en una estructura tipo rbol que permite mltiples padres. Antes de la llegada del modelo relacional, el modelo en red era el ms popular para las bases
de datos. Este modelo de red (denido por la especicacin
CODASYL) organiza datos que usan en dos construcciones
bsicas, registros y conjuntos. Los registros contienen campos que puede estar organizados jerrquicamente, como en
el lenguaje COBOL. Los conjuntos denen relaciones N:N
entre registros: varios propietarios, varios miembros. Un registro puede ser un propietario de varios conjuntos, y miembro en cualquier nmero de conjuntos.

CAPTULO 1. MODELO DE BASE DE DATOS

El modelo en red es una generalizacin del modelo jerrquico, en tanto est construido sobre el concepto de mltiples
ramas (estructuras de nivel inferior) emanando de uno o varios nodos (estructuras de nivel alto), mientras el modelo se
diferencia del modelo jerrquico en que las ramas pueden
estar unidas a mltiples nodos. El modelo de red es capaz
de representar la redundancia en datos de una manera ms
eciente que en el modelo jerrquico.

1.4

Modelo relacional

Las operaciones del modelo de red se realizan por de navegacin: un programa mantiene la posicin actual, y navega
entre registros siguiendo las relaciones entre ellos. Los re- El modelo relacional fue introducido por E.F. Codd en
gistros tambin pueden ser localizados por valores claves.
1970[1] con el objetivo de querer hacer los SGBD ms
Aunque no es una caracterstica esencial del modelo, las independientes de las aplicaciones. Es un modelo matembases de datos en red implementan sus relaciones mediante tico denido en trminos de lgica de predicados y teora
punteros directos al disco. Esto da una velocidad de recu- de conjuntos, y se han implementado con l SGBDs para
peracin excelente, pero penaliza las operaciones de carga mainframe, ordenadores medios y microordenadores.
y reorganizacin.
Entre los SGBD ms populares que tienen arquitectura en
red se encuentran Total e IDMS. IDMS logr una importante base de usuarios; en 1980 adopt el modelo relacional
y SQL, manteniendo adems sus herramientas y lenguajes
originales.
La mayora de bases de datos orientadas a objetos (introducidas en 1990) usan el concepto de navegacin para proporcionar acceso rpido entre objetos en una red. Objectivity/DB, por ejemplo, implementa 1:1, 1:N, N:1 y N:N
entre distintas bases de datos. Muchas bases de datos orientadas a objetos tambin soportan SQL, combinando as la
potencia de ambos modelos.

Los productos referidos como base de datos relacional de

hecho implementan un modelo que es slo una aproximacin al modelo matemtico denido por Codd. Existen tres
trminos usados con profusin en el modelo relacional de
bases de datos: relaciones, atributos y dominios. Una relacin equivale a una tabla con las y columnas. Las columnas
de una relacin se llaman con rigor atributos, y el dominio
es el conjunto de valores que cada atributo puede tomar.
La estructura bsica de datos del modelo relacional es la
relacin (tabla), donde la informacin acerca de una determinada entidad (p.e. empleado) se almacena en tuplas (las), cada una con un conjunto de atributos (columnas). Las
columnas de cada tabla enumeran los distintos atributos de
la entidad (el nombre del empleado, direccin y nmero
de telfono, p.e.), de modo que cada tupla de la relacin
empleado representa un empleado especco guardando
los datos de ese empleado concreto.
Todas las relaciones (es decir, tablas) en una base de datos
relacional han de seguir unas mnimas reglas:

1.3.3

Modelo de chero invertido

1. el orden de los atributos es irrelevante

En un chero invertido o de ndice invertido, los datos contenidos se usan como claves en una tabla de consulta (lookup
table), y los valores en la tabla se utilizan como punteros a
la localizacin de cada instancia. Esta es tambin la estructura lgica de los ndices de bases de datos modernas, los
cuales introducen slo el contenido de algunas columnas en
esa tabla de consulta. El modelo de chero invertido puede poner los ndices en cheros planos para acceder a sus
registros de manera eciente.

2. no puede haber tuplas repetidas

3. cada atributo slo puede tener un valor.

Una base de datos puede contener varias tablas, cada una

similar al modelo plano. Una de las fortalezas del modelo
relacional es que un valor de atributo coincidente en dos registros (las) -en la misma o diferente tabla- implica una relacin entre esos dos registros. Es posible tambin designar
Implementaciones notables de este modelo de datos la reali- uno o un conjunto de atributos como clave, que permitir
z Adabas de Software AG, aparecida en 1970. Adabas lo- identicar de manera nica una la en una tabla.
gr una importante base de usuarios y est soportada an Dicha clave que permite identicar de manera unvoca una
hoy. En la dcada de 1980 adopt el modelo relacional y la en una tabla se denomina clave primaria. Las claves
SQL, manteniendo sus propias herramientas y lenguajes.
son habitualmente utilizadas para para combinar datos de

1.5. MODELOS POST-RELACIONALES

dos o ms tablas. Por ejemplo una tabla de empleados puede
contener una columna denominada departamento"", cuyo
valor coincida con la clave de una tabla denominada departamentos. Las claves son esenciales a la hora de crear
ndices, que facilitan la recuperacin rpidas de datos de tablas grandes. Una clave puede estar formada por cualquier
columna o por una combinacin de varias columnas, denominndose clave compuesta. No es necesario denir todas
las claves por adelantado; una columna puede usarse como
clave incluso si no estaba previsto en origen.
Una clave que tenga un signicado en el mundo fsico (tal
como un nombre de persona, el ISBN de un libro o el nmero de serie de un coche) a veces se denomina clave natural. Si no existe una clave natural viable, se puede asignar
un sucedneo arbitrario (como dar a una persona un nmero de empleado). En la prctica la mayor parte de las bases
de datos tienen a la vez claves sucedneas y naturales, dado
que las claves sucedneas pueden usarse internamente para crear enlaces ntegros entre las, mientras que las claves
naturales tienen un uso menos able a la hora de buscar o
enlazar con otras bases de datos.

5
Un almacn de datos (data warehouse) puede contener mltiples esquemas de estrella que comparten tablas de dimensin, permitindoles ser usadas juntas. El establecimiento
de un conjunto de dimensiones estndar es una parte importante del modelado dimensional.

1.5

Modelos post-relacionales

Los productos que ofrecen un modelo de datos ms general que el relacional se denominan a veces post-relational.[2]
Como trminos alternativos se oyen incluyen bases de datos hbridas, bases de datos relacionales potenciadas con
objectos entre otros. El modelo de datos de esos productos
incorpora relaciones pero no limitadas por las restricciones
del principio de informacin de E.F. Codd, que requiere que
toda informacin en la base de datos debe ser modelada en
trminos de valores en relaciones nada ms[3]

Algunas de estas extensiones al modelo relacional integran

conceptos de tecnologas que preceden el modelo relacional. Por ejemplo permiten representar un grafo dirigido con
El lenguaje de interrogacin ms comn utilizado con las
rboles en los nodos. La compaa sones implementa este
bases de datos relacionales es el Structured Query Language
concepto en su GraphDB.
(SQL).
Algunos productos post-relacionales aplan los sistemas relacionales con caracteriticas no relacionales. Otros han llegado al mismo punto aadiendo caractersticas relacionaes
a modelos pre-relacionales. Paradjicamente esto ha per1.4.1 Modelo Dimensional
mitido a productos histricamente pre-relacionales, como
El modelo dimensional es una adaptacin especializada del por ejemplo PICK y MUMPS, razonar su esencia postmodelo relacional usada para almacenar datos en depsitos relactional.
de datos, de modo que los datos fcilmente puedan ser extrados usando consultas OLAP. En el modelo dimensional,
una base de datos consiste en una sola tabla grande de datos
que son descritos usando dimensiones y medidas. Una dimensin proporciona el contexto de un hecho (como quien
particip, cuando y donde pas, y su tipo). Las dimensiones se toman en cuenta en la formulacin de las consultas
para agrupar hechos que estn relacionados. Las dimensiones tienden a ser discretas y son a menudo jerrquicas; por
ejemplo, la ubicacin podra incluir el edicio, el estado y
el pas. Una medida es una cantidad que describe el dato, tal
como los ingresos. Es importante que las medidas puedan
ser agregados signicativamente -por ejemplo, los ingresos
provenientes de diferentes lugares puedan sumarse.
En una consulta (OLAP), las dimensiones y los hechos son
agrupados y aadidos juntos para crear un informe. El modelo dimensional a menudo es puesto en prctica sobre el
modelo relacional usando un esquema de estrella, consistiendo en una tabla que contiene los datos y tablas circundantes que contienen las dimensiones. Dimensiones complicadas podran ser representadas usando mltiples tablas,
usando un esquema de copo de nieve.

El Resource Space Model es un modelo de datos no relacional basado en clasicacin multi-dimensional.[4]

1.5.1

Modelo de grafo

Las bases de datos de grafos permiten incluso una estructura

ms general que una base de datos en red, cualquier nodo
puede estar conectado a cualquier otro.

1.5.2

Modelo multivaluados

Las bases de datos multivaluadas contienen datos arracimados, en el sentido de que pueden almacenar los datos del
mismo modo que las bases de datos relacionales, pero adems permiten un nivel de profundidad al que las relacionales slo se pueden aproximar utilizando subtablas. Esto
es prcticamente igual al modo en que XML representa los
datos, donde un campo/atributo dado puede contener mltiples valores a la vez. El multivalor se puede considerar una
forma de XML comprimida.

CAPTULO 1. MODELO DE BASE DE DATOS

Un ejemplo puede ser una factura, la que puede ser vista requiere la adicin de algn tipo de lenguaje de interrogacomo:
cin, ya que lo lenguajes tradicionales no tienen la posibilildad de encontrar objetos basados en su contenido. Otros se
han proximado al problema desde la prespectiva de la base
1. Encabezado, una entrada por factura
de datos, deniendo un modelo orientado a objetos para la
2. Detalle, una entrada por concepto
base de datos, y deniendo un lenguaje de programacin
de dicha base de datos que permite tanto capacidades de
En el modelo multivaluado tenemos la opcin de almace- programacin como de interrogacin.
nar los datos como una sola tabla (1), con tablas imbuidas
Las bases de datos orientadas a objetos sufren falta de esrepresentando el detalle.
tandarizacin; aunque han sido denidos estndares por en
Tiene la ventaja que la correspondencia entre la factura con- Object Database Management Group nunca han sido imceptual y la de la factura como representacin de datos es plementados con generalidad suciente como para permitir
biunvoca. Esto redunda en menor nmero de lecturas, me- la interoperabilidad entre productos. Sin embargo, las bases
nos problemas de integridad referencial y una fuerte dismi- de datos orientadas a objetos han sido empleadas eocaznucin del hardware necesario para soportar un volumen mente en distintas aplicaciones: generalmente en nichos esde transacciones dado.
pecializados como ingeniera o biologa molecular, pero no
de forma general con soporte comercial. Sin embargo algunas de las ideas que ha aportado han sido recogidas por los
1.5.3 Modelo orientado a objetos
fabricantes de bases de datos relacionales y se han aplicado
en extensiones al lenguaje SQL.
Object-Oriented Model
Object 1: Maintenance Report
Date
Activity Code
Route No.
Daily Production
Equipment Hours
Labor Hours

Object 1 Instance
01-12-01
24
I-95
2.5
6.0
6.0
Object 2: Maintenance Activity
Activity Code
Activity Name
Production Unit
Average Daily Production Rate

Modelo orientado a objetos

En la dcada de 1990, el paradigma de la orientacin a objetos se aplic a las bases de datos creando un nuevo modelo llamado base de datos orientada a objetos. Esto tuvo
el n de reducir la impedancia objeto-relacional, la sobrecarga de convertir la informacin de su representacin en la
base de datos -como las en tablas- a su representacin en el
programa -tpicamente como objeto. Incluso ms, los tipos
de datos usados en una aplicacin pueden denirse directamente en la base de datos, preservando as la base de datos
la misma integridad de datos. Las bases de datos orientadas
a objetos tambin introducen las ideas clave de la programacin orientada a objetos -encapsualcin y polimorsmoen el mundo de las bases de datos.
Se han propuesto distintos modos de almacenar objetos en
una base de datos. Algunos se han aproximado desde la
prespectiva de la programacin, haciendo los objetos manipulados por el programa persistentes. Esto tpicamente

Una alternativa a la traduccin entre objetos y relaciones es

la de usar una librera Object-Relational Mapping (ORM).

1.6

Referencias

[1] E.F. Codd (1970). A relational model of data for large shared data banks. In: Communications of the ACM archive.
Vol 13. Issue 6(June 1970). pp.377-387.
[2] Introducing databases by Stephen Chu, in Conrick, M.
(2006) Health informatics: transforming healthcare with
technology, Thomson, ISBN 0-17-012731-1, p. 69.
[3] Date, C. J. (1 de junio de 1999). Whens an extension not
an extension?. Intelligent Enterprise 2 (8).
[4] Zhuge, H. (2008). The Web Resource Space Model. Web Information Systems Engineering and Internet Technologies
Book Series 4. Springer. ISBN 978-0-387-72771-4.

Captulo 2

CODASYL
CODASYL (tambin escrito Codasyl) es el acrnimo para
"Conference on Data Systems Languages", un consorcio
de industrias informticas formado en 1959 con el objeto de
regular el desarrollo de un lenguaje de programacin estndar que pudiera ser utilizado en multitud de ordenadores.
De todos estos esfuerzos result el lenguaje COBOL.

independencia del nuevo lenguaje de programacin, el trabajo fue reorganizado: el desarrollo del DDL fue continuado por el Data Description Language Committee, mientras
que el desarrollo del COBOL DML fue asumido por el COBOL Language Committee. En retrospectiva, esta divisin
tuvo desafortunadas consecuencias. Los dos grupos nunca
fueron capaces de sincronizar sus especicaciones, obligando a los distribuidores a subsanar los problemas generados
por las diferencias entre ellas. Finalmente se hizo inevitable
la aparicin de una falta de interoperabilidad entre implementaciones.

Los miembros de CODASYL pertenecan a industrias e

instituciones gubernamentales relacionadas con el proceso
de datos. Su principal meta era promover un anlisis, diseo
e implementacin de los sistemas de datos ms efectivos.
La organizacin trabaj en varios lenguajes a lo largo del
tiempo pero nunca llegaron a establecer estndar alguno, Algunas empresas implementaron productos de bases de
proceso que dejaron en manos de ANSI.
datos rudamente conformes a las especicaciones del
En 1965 CODASYL form la List Processing Task Force DBTG, siendo de todas ellas las ms conocidas: Honeywell
(en espaol, Grupo de Trabajo para el Procesado de Listas). Integrated Data Store (IDS/2), Cullinet Integrated DatabaEste grupo se dedic a desarrollar extensiones del lenguaje se Management System (IDMS), Univac DMS-1100 o DiCOBOL para el procesamiento de colecciones de registros; gital Equipment Corporation DBMS32.
el nombre surgi a causa del sistema IDS (Integrated Data System) desarrollado por Charles Bachman (sistema que
supuso el mayor aporte tcnico al proyecto), y que manejaba las distintas relaciones mediante cadenas de punteros. En
1967 el grupo fue renombrado como Grupo de Trabajo sobre Bases de Datos, y su primer informe fechado en enero
de 1968 se titul COBOL extensions to handle data bases
(en espaol, Extensiones COBOL para el manejo de bases de
datos). En octubre de 1969 el DBTG public las primeras
especicaciones para el modelo de base de datos en red, el
cual acab por ser conocido como Modelo Codasyl. Propiamente estas especicaciones denan varios lenguajes por
separado: un lenguaje de descripcin de datos (DDL, siglas
en ingls) para denir el esquema de la base de datos, otro
DDL para crear uno o ms subesquemas para denir vistas de la base de datos en aplicaciones; y un lenguaje de
manipulacin de datos (DML) que dena palabras clave
para incluir en el cdigo COBOL las llamadas y actualizaciones de la base de datos. Aunque los trabajos siempre se
centraron en COBOL, la idea de un lenguaje independiente
comenz a emerger, impulsada por las pretensiones de IBM
de utilizar el PL/I como reemplazo de COBOL.

2.1

El modelo CODASYL

El modelo Codasyl deni una serie de elementos bsicos

que denan su estructura de datos. Son los siguientes:
- Elemento de datos.- Unidad de datos ms pequea que
se puede referenciar. Puede ser de distintos tipos, y puede
denirse como dependiente de valores de otros elementos
(datos derivados).
- Agregado de datos.- Se asemeja a los campos de un chero
o a los atributos de otros modelos.
- Registro.- Coleccin nominada de elementos de datos.
Unidad bsica de acceso y manipulacin. Se asemeja a los
registros en cheros y a las entidades en el modelo E/R.
- Conjunto (SET).- Coleccin nominada de dos o ms tipos de registros que establece una vinculacin entre ellos.
Origen de muchas restricciones. Las interrelaciones 1:N se
representan aqu mediante SET.

- rea.- Subdivisin nominada del espacio direccionable de

En 1971, en gran parte como respuesta a la necesidad de la la base de datos que contiene ocurrencias de registros.
7

CAPTULO 2. CODASYL

- Clave de base de datos identicador interno nico para Las restricciones son las siguientes:
cada ocurrencia de registro.
- Solo se admiten tipos de interrelaciones jerrquicas de dos
Proporciona su direccin en la base de datos. Es un obstcu- niveles (propietario y miembro). Si se admite la combinalo para conseguir la independencia lgica / fsica. Supona cin de varios SET para generar jerarquas multinivel.
problemas el reutilizar una clave cuando se reorganizaba la
- En el nivel propietario solo se permite un tipo de registro.
base de datos.
- En el mismo SET no se permite que a un registro ser a
CODASYL: CONJUNTOS (SET)
la vez propietario y miembro, no est admitida la reexiviEl conjunto es uno de los ms importantes elementos del dad. Aunque esta restriccin se elimin con el tiempo, los
modelo Codasyl, pues constituye el elemento bsico para productos basados en Codasyl la siguen utilizando.
la representacin de interrelaciones. Mediante SET se esta- - Una misma ocurrencia de miembro no puede pertenecer
blecen relaciones jerrquicas (1:N) a dos niveles. El nodo en un mismo tipo de SET a ms de un propietario. Esto hace
raz es el propietario y los nodos descendientes (pueden ser que se simplique la implementacin fsica de los SET, ya
de varios tipos) son los miembros.
que sus ocurrencias se pueden organizar como una cadena.
CARACTERSTICAS BSICAS DEL MODELO CODASYL
Se pueden resumir las caractersticas bsicas del modelo en
:
- Un SET es una coleccin nominada de dos o ms tipos de
registros que representan un tipo de interrelacin 1:N (en
consecuencia tambin 1:1).
- Cada SET tendr un tipo de registro propietario y uno o
ms tipos de registros miembro.
- El nmero de SET que se pueden declarar en el sistema es
ilimitado.
- Cualquier registro puede ser propietario de uno o varios
SET.
- Cualquier registro puede ser miembro de uno o varios
SET.
- Podrn existir SET singulares en los que el propietario es
el sistema (una entidad se interrelaciona consigo mismo).
- A pesar de que una entidad sea miembro de un SET, existe
la posibilidad de que ciertas ocurrencias de esa entidad no
estn ligadas al SET, con lo que no tendran propietario y
quedaran no ligadas respecto de ese SET.
RESTRICCIONES INHERENTES DEL MODELO CODASYL.
Cuando hablbamos del modelo en red general, decamos
que era un modelo muy exible a coste de no tener restricciones inherentes. Esta ausencia de restricciones hace que
sea muy difcil de implementar, y a la larga suele reportar
escaso rendimiento, por lo que como tambin decamos no
pasa de ser un modelo terico.
El modelo Codasyl est basado en el modelo en red general, pero a diferencia de este, es un modelo utilizado. Esto
es debido a que Codasyl ha incluido restricciones inherentes que hacen que sea posible su implementacin y que se
obtenga un alto rendimiento del sistema.

2.2

Referencias

The Codasyl Approach to Data Base Management. T.

William Olle. Wiley, 1978. ISBN 0-471-99579-7.
The Codasyl Model. J.S. Knowles y D.M.R. Bell, en
Databases - Role and Structure, ed. P.M. Stocker,
P.M.D. Gray y M.P. Atkinson, CUP, 1984. ISBN 0521-25430-2

2.3

Enlaces externos

Charles Babbage Institute

Captulo 3

Modelo jerrquico
Un modelo de datos jerrquico es un modelo de datos en
el cual los datos son organizados en una estructura parecida
a un rbol. La estructura permite a la informacin que repite
y usa relaciones padre/Hijo: cada padre puede tener muchos
hijos pero cada hijo slo tiene un padre. Todos los atributos
de un registro especco son catalogados bajo un tipo de
entidad.

(el tipo de entidad) llamada Empleados. En la tabla habra atributos/columnas como el Nombre de pila, el Apellido, el Nombre de Trabajo y el Salario. La empresa tambin
tiene datos sobre los hijos del empleado en una tabla separada Hijos llamada con atributos como el Nombre de
pila, el Apellido, y la fecha de nacimiento. La tabla de Empleado representa un segmento paternal y la tabla de Hijos
En una base de datos, un tipo de entidad es el equivalente representa un segmento Infantil. Estos dos segmentos forman una jerarqua donde un empleado puede tener muchos
de una tabla; cada registro individual es representado como
una la y un atributo como una columna. Los tipos de enti- hijos, pero cada hijo slo puede tener un padre.
dad son relacionados el uno con el otro usando 1: Trazar un Considere la estructura siguiente:
mapa de n, tambin conocido como relacion de uno a va- En esta tabla, el hijo es el mismo tipo que el padre. La
rios. El ejemplo ms aprobado de base de datos jerrquica jerarqua que declara EmpNo 10 es el jefe de 20, y30 y
modela es un IMS diseado por la IBM.
40 cada informe a 20 es representado por la columna Re-

porta. Llamada en la Base de datos relacional, la columna

Reporta es una llave foranea, el referirse de la columna EmpNo. Si el tipo de datos hijo fuera diferente, estara en una
3.1 Historia
tabla diferente, pero todava habra una llave foranea que se
Una base de datos puesta en prctica relacionada con este reere la columna EmpNo de la tabla de empleados.
tipo de modelo de datos primero fue llamada en la forma Comnmente se conocen a estos modelos simplemente code publicacin en 1992 [1] (mirar tambin anid el modelo mo la lista de adyacencia, fue presentado por el Doctor Edde conjuntos). Antes del desarrollo del primer sistema de gar F. Codd.
gestin de datos (DBMS), los programas de uso proporcionaron el acceso a los datos que tuvieron acceso a archivos
planos. Los problemas de integridad de datos y la inhabilidad de tales sistemas de tratamiento de archivo para representar relaciones de datos lgicas conducen al primer modelo de datos: el modelo de datos jerrquico. Este modelo,
que fue puesto en prctica principalmente por el Sistema
de Direccin de Informacin de la IBM (IMS) slo permite personalizado(exacto) una a varias relaciones entre entidades. Cualquier entidad al nal de la relacin puede ser
relacionada slo con una entidad.

3.2 Ejemplo
Un ejemplo de un modelo de datos jerrquico sera si una
organizacin tuviera los registros de empleados en una tabla
9

Captulo 4

IMS (IBM)
IBM Information Management System (IMS) es un
gestor de bases de datos jerrquicas y un gestor transaccional con alta capacidad de proceso.

(Acceso jerrquico secuencial) y Hierarchical Indexed Sequential (HISAM) (Acceso jerrquico indexado secuencial).

IBM dise el IMS con Rockwell y Caterpillar en 1966 debido al Programa Apolo. El desafo de IBM era inventariar
la extenssima lista de materiales del cohete lunar Saturno
V y de la nave Apolo.

Los datos se almacenan usando VSAM, un tipo

de acceso nativo de z/OS, u Overow Sequential (OSAM) (Acceso de desbordamiento secuencial), un tipo de acceso propio de IMS que
optimiza la Entrada/Salida de algunos patrones.

El primer mensaje IMS READY apareci en un terminal IBM 2740 en Downey, California un 14 de agosto de
1968. IMS todava se usa extensamente 40 aos despus y,
con el tiempo, ha visto interesantes desarrollos como el sistema IBM Sistema/360, hoy convertido en z/OS y Sistema
z9. Por ejemplo, IMS soporta aplicaciones desarrolladas en
Java, JDBC, XML y Servicios Web.

4.1 IMS DB
Las funcionalidades de IMS relacionadas con bases de datos
reciben el nombre de IMS DB (IMS DataBases). Hay tres
tipos de bases de datos jerrquicas:
1. Bases de datos Full function
Descendientes directas de las bases de datos
Data Language/I desarrolladas para el Apolo,
pueden tener ndices primarios y secundarios accedidos usando llamadas DL/I desde la aplicacin, algo similar a llamadas SQL a Oracle o
DB2 (de hecho, SQL debe su herencia a DL/I).
Este tipo de bases de datos tiene una gran variedad de mtodos de acceso, aunque los dominantes son: Hierarchical Direct (HDAM) (Acceso directo jerrquico) y Hierarchical Indexed Direct (HIDAM) (Acceso directo jerrquico indexado""). Los otros mtodos son Simple Hierarchical Indexed Sequential (SHISAM) (Acceso simple jerrquico indexado secuencial), Hierarchical Sequential (HSAM)
10

2. Bases de datos Fast Path

Las bases de datos Fast Path pueden ser bien
Data Entry Databases (DEDB) o Main Storage
Databases (MSDB). Ambos tipos carecen de indexacin, pero a cambio estn optimizados para
ofrecer elevados ndices de acceso.
Las MSDB estn destinadas a desaparecer debido a sus fuertes restricciones. No permiten altas
ni bajas y las referencias directas se resuelven
mediante bsquedas binarias.
Las DEDB pueden llegar a ser tan complejas
como las de DL/I mientras mantienen su rendimiento, por lo que estn sustituyendo a MSDB.
Actualmente se puede aprovechar la riqueza estructural de las DEDB y la mejora de rendimiento de las MSDB gracias a la opcin de poner el
memoria virtual reas de una DEDB. Esta funcionalidad permite tambin, compartir una misma base de datos entre distintos sistemas usando
poniendo las reas en la coupling facility.
3. Bases de datos High Availability Large Databases
(HALDB)
IMS V7 introdujo HALDBs, como una extensin de la base de datos Full Function para proveer una mejor disponibilidad de la misma, mejor manejo de grandes volmenes de datos, y,
con IMS V9, reorganizacin online para soportar alta disponibilidad.

4.4. ENLACES EXTERNOS

4.2 IMS TM

11
informacin se escribe en dos cheros, uno principal y otro
como copia de seguridad.

Las funcionalidades de IMS relacionadas con la gestin

transaccional reciben el nombre de IMS TM (IMS Transac- SLDS
tion Manager), anteriormente conocido como IMS DC (IMS
DataControl)
El SLDS (chero de registro secundario, del ingls Secondary Log Data Set) es un chero de registro usado en IMS
para almacenar informacin consolidada y que ya ha sido
archivada. Es normal que el SLDS, a diferencia del OLDS,
4.3 Registro
se almacene en cinta en vez de disco, debido a su tamao y
Tanto para un gestor transaccional como para un gestor de a su escaso uso, nicamente en escenarios de recuperacin
bases de datos es imprescindible registrar cada paso en un de bases de datos.
chero de registro, de manera que todas las acciones se puedan deshacer. IMS usa un extenso sistema de registro capaz RLDS
de soportar grandes cantidades de informacin sin repercutir en el tiempo de respuesta.
El RLDS (chero de registro de recuperacin, del ingls
Recovery Log Data Set) es un chero de registro opcional
usando en IMS para almacenar informacin consolidada y
Buers IMS
archivada relacionada con la recuperacin de bases de datos. Al contener slo registros relacionados con la recuperaIMS usa buers para escribir cualquier informacin que necin de bases de datos, el volumen de informacin es mucho
cesite ser registrada. Cuando un buer se llena, IMS ordena
menor que en el caso del SLDS, lo cual hace ms rpido el
escribir todo el buer al chero de OLDS. El tamao viene
proceso de recuperacin de bases de datos.
dado por el tamao del chero de OLDS.
OLDS

Archivado

Cuando un OLDS se llena, IMS ejecuta un proceso de arEl OLDS (chero de registro online, del ingls Online Log chivado. Este proceso se compone de los siguientes pasos:
Data Set) es un chero de registro usados en IMS para almacenar informacin que, por razones de recuperabilidad,
1. El OLDS activo (o la pareja, en caso de que se est
debe escribirse en disco. Para mejorar el rendimiento, slo
usando copia dual) se cierra y se marca como pense copian bloques de informacin completos. Si se debe codiente de archivar.
piar algn buer incompleto, este se copia al WADS. Los
OLDS se usan en forma de cadena, de modo que cuando un
2. Se empieza a grabar en el siguiente OLDS disponible
chero de OLDS se llena, este se archiva y se pasa a usar
(o en la siguiente pareja de OLDS, en caso de que se
otro. Para prevenir fallos provocados por errores fsicos de
est usando copia dual).
escritura en disco, es posible mantener una copia dual de
3. Se copia la informacin del OLDS pendiente de arOLDS, de manera que la informacin se escribe en dos chivar en un chero SLDS. Opcionalmente, se puede
cheros, uno principal y otro como copia de seguridad.
crear un RLDS.
WADS
El WADS (chero de escritura avanzada, del ingls Writeahead Data Set) es un chero de registro usado en IMS para
almacenar buers de informacin incompletos antes de escribirse denitivamente en el OLDS. Los WADS tienen un
alto rendimiento debido a su pequeo tamao y a su estructura interna. Cuando el sistema o el IMS sufre una fallida,
la informacin del WADS sirve para cerrar el OLDS como
parte de un arranque de emergencia. Para prevenir fallos
provocados por errores fsicos de escritura en disco, es posible mantener una copia dual de WADS, de manera que la

4. El OLDS que estaba pendiente de archivar se marca

como disponible para escribir en l.

4.4

Enlaces externos

Introduccin a Information Management

Captulo 5

Data Language/Interface
Data Language/Interface (abreviado DL/1 o DL/I) es el
lenguaje de programacin para acceder a las bases de datos
de IMS y a su sistema de comunicacin.

5.1

Vase tambin

IMS

Se implementa desde cualquier lenguaje existente realizando llamadas a un programa puente llamado DFSLI000. Este software contiene puntos de entrada para gestionar va- 5.2 Enlaces externos
rios lenguajes de programacin, por ejemplo, para llamar
a PLITODLI desde un programa PL/1 o CBLTDLI des Preguntas y respuestas
de un programa COBOL. El programa DFSLI00 se enlaza
desde el programa real, pasa la informacin a IMS y poste[[Categora:Lenguajes de programador
riormente devuelve datos y un cdigo de retorno.
En cualquier base de datos IMS full-function, el elemento
ms pequeo que se puede consultar es el segmento. Cada segmento se compone de campos, donde normalmente
uno de ellos ser un campo clave. Los segmentos en la base
de datos estn organizados de forma jerrquica, al segmento del nivel ms alto se denomina segmento raz. Existen
restricciones en cuanto al nmero de segmentos distintos:
un mximo de 255 segmentos diferentes en 15 niveles. Sin
embargo, no hay ningn limite en el nmero de ocurrencias
de cada tipo de segmento, ms all de los lmites fsicos del
espacio de almacenamiento.
La estructura de la base de datos se presenta a la aplicacin
mediante PCB (Bloque de Control de Programa, o Program
Control Block), este es uno de los parmetros que se pasan
al DFSLI000. Adems de PCB para acceso a bases de datos,
existes PCB para mensajera y acceso a bases de datos en
cheros secuenciales.
Cuando la aplicacin accede a un segmento de la base de datos puede usar una SSA (Argumento de Bsqueda de Segmento, Segment Search Argument) como parmetro , para especicar uno o varios segmentos especcos. La SSA
contiene normalmente el tipo de segmento y el valor de
cualquier campo clave.
El primer parmetro en una llamada de DL/1 es el cdigo de funcin: un campo de cuatro crcteres que indican
la funcin de la llamada. Por ejemplo: GU (Get Unique),
GN (Get Next), REPL (Replace), and ISRT (Insert).

12

Captulo 6

Base de datos XML

Una base de datos XML constituye un sistema software
que da persistencia a datos almacenados en formato XML.
Estos datos pueden ser interrogados, exportados y serializados. Las bases de datos XML estn generalmente asociadas
con las bases de datos documentales.

2. El XML se desgaja en una serie de tablas segn un

esquema[4]
3. El XML se almacena de forma nativa como tipo XML
segn dene ISO[5]

Existen dos grandes clases de bases de datos XML:[1]

Entre los SGBD que soportan ISO XML estn:
1. XML habilitado: stas bien pueden mapear XML en
estructuras tradicionales de bases de datos (como las
relacionales[2] ), aceptando XML como entrada y formateando en XML la salida, o ms recientemente soportando tipos XML nativos en la propia base de datos. Esto implica que la base de datos procesa el XML
internamente (lo opuesto a soportarlo mediante middleware).

IBM DB2 (XML puro[6] )

Microsoft SQL Server[7]
Oracle Database[8]
PostgreSQL[9]

2. XML nativo (NXD): el modelo interno de estas bases

de datos usa documentos XML como la unidad ele- Tpicamente una base de datos habilitada XML se adapta
mental de almacenamiento, los cuales no han de al- mejor all donde la mayora de los datos no estn en XML,
para aquellos datos en los que la mayora estn en XML,
macenarse necesariamente en formato de texto.
una base de datos nativa XML se adaptar mejor.

6.1 Lgica del uso de XML en bases

6.2.1 Ejemplo de interrogacin XML en
de datos
IBM DB2 SQL
O'Connell da una razn para el uso de XML en bases de SELECT id, vol, xmlquery('$j/name', procesando
datos: el generalizado aumento del transporte de datos en revista j) AS name FROM revistas WHERE xmleformato XML, lo que signica que los datos se extraen de xists('$j[publica="Elsevier"]', procesando revista j)
bases de datos y convertidos a XML o viceversa.[3] Resultara ms eciente (en trminos de costes de conversin) y
fcil almacenar los datos en formato XML directamente.

6.3

Bases de datos nativas XML

6.2 Bases de datos habilitadas XML

El trmino base de datos nativa XML (NXD) puede lleTpicamente ofrecen alguna de las siguientes aproximacio- var a confusin. Muchas NXDs no funcionan como bases
nes para almacenar XML en la estructura relacional clsica: de datos independientes, y no almacenan el texto nativo en
XML.
1. El XML se almacena en un campo CLOB (Character La denicin formal de la iniciativa XML:DB (que parece
large object)
inactiva desde 2003[10] ) arma que:
13

14

CAPTULO 6. BASE DE DATOS XML

Dene un modelo (lgico) para un documento XML

contrapuesto a los datos en ese documento y almacena y recupera documentos segn ese modelo. Como mnimo el modelo debe incluir elementos, atributos, CDATA y orden de los documentos. Ejemplos
de estos modelos incluyen el modelo de datos XPath,
XML Infoset y los que implica el DOM y los eventos
en SAX 1.0.

permitiendo a los desarrolladores java realizar preguntas de

acuerdo a la especicacin W3C XQuery 1.0. En denitiva
el XQJ API representa a las bases de datos XML lo mismo
que representa el API JDBC a las bases de datos relacionales y SQL.

Tiene un documento XML como su unidad (lgica)

fundamental de almacenamiento, del mismo modo que
una base de datos relacional lo tiene con la la.

6.4

No necesita basarse en ningn modelo de almacenamiento fsico particular. Por ejemplo las NXD puede
usar estructuras relacionales, jerrquicas u orientadas
a objetos, o usar un formato de almacenamiento propietario (como ndices o cheros comprimidos).
Adems, muchas bases de datos XML databases proporcionan un modelo lgico de agrupar documentos, llamada
colecciones. Las bases de datos pueden estableder y gestionar muchas colecciones al mismo tiempo. En algunas implementaciones puede existir una jerarqua de colecciones,
de modo anlogo a la estructura de directorios de un sistema
operativo.

6.3.1

Caractersticas del lenguaje

Referencias

[1] Bourret, Ronald (20 de junio de 2010). XML Database

Products. Consultado el 16 de diciembre de 2011.
[2] Mustafa Atay and Shiyong Lu, Storing and Querying XML:
An Ecient Approach Using Relational Databases, ISBN
3-639-11581-3, VDM Verlag, 2009.
[3] O'Connell, S. Advanced Databases Course Notes, Southampton, University of Southampton, 2005, 9.2
[4] Creating XMLType Tables and Columns Based on XML
Schema
[5] ISO/IEC 9075-14:2011
[6] IBM DB2 pureXML overview -- DB2 as an XML database
[7] Using XML in SQL Server

Todas las bases de datos XML soportan al menos una sintaxis de interrogacin. Al menos casi todas soportan XPath [8] XMLType Operations
para realizar preguntas a documentos o coleccin de ellos.
[9] PostgreSQL - Data Types - XML Type
XPath provides a simple pathing system that allows users to
identify nodes that match a particular set of criteria.
[10] Frequently Asked Questions About XML:DB. The
XML:DB Initiative. Sourceforge. 2003. Consultado el 16 de
Adems de XPath, muchas bases de datos XML soportan
diciembre de 2011.
XSLT acomo mtodo para transformar documentos o resultados obtenidos de la base de datos. XSLT proporciona [11] Zorba XQuery 3.0 support
un lenguaje declarativo escrito con gramtica XML. Con
l dene una serie de ltros XPath que pueden transformar
documentos XML en otros con otro formato, como texto
plano, XML o HTML.

Las bases de datos XML suelen interrogar mediante

XQuery. XQuery incluye XPath como mtodo de seleccin
de nodos, pero de modo extendido que da capacidad de
transformacin. A veces los usuarios se reeren a su sintacis
como FLWOR al poderse incluir en la pregunta las siguientes clasulas: 'for', 'let', 'where', 'order by' y 'return'. Los fabricantes de SGBD relacionales -que tradicionalmente slo
proporcionan mecanismos SQL- ahora incluyen mecanismos hbridos SQL-XQuery. Esto permite interrogar los datos XML de manera anloga a los relacionales, en la misma
sentencia. Esto permite combinar datos XML y relacionales.
La mayora de bases de datos XML soportan un API neutral
comn llamado XQJ API. Este fue desarrollado por JCP como interfaz estndar de una fuente de datos XML/XQuery,

6.5. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

15

6.5 Text and image sources, contributors, and licenses

6.5.1

Text

Modelo de base de datos Fuente: http://es.wikipedia.org/wiki/Modelo%20de%20base%20de%20datos?oldid=80153002 Colaboradores: Chobot, Baneld, Tomatejc, CEM-bot, IrwinSantos, LMLM, Technopat, Muro Bot, Jesusosm, Javierito92, Eduardosalg, Leonpolanco, Poco a poco,
Aipni-Lovrij, MastiBot, Diegusjaimes, Juvalen, SuperBraulio13, Xqbot, Jkbw, Magomaitin, Igna, Rubenval, TiriBOT, Dxtejada, PatruBOT,
Jorge c2010, Foundling, Savh, WikitanvirBot, Antonorsi, MerlIwBot, KLBot2, OsirisCk, Osboxs, Matiia y Annimos: 52
CODASYL Fuente: http://es.wikipedia.org/wiki/CODASYL?oldid=64405522 Colaboradores: Oblongo, Moriel, Sms, Mandramas, Rembiapo
pohyiete (bot), YurikBot, GermanX, CEM-bot, Pinobot, Mister, Fabeirojorge, Flafus, BotMultichill, SieBot, AVBOT, Jkbw, XeMyCo, Legobot
y Annimos: 9
Modelo jerrquico Fuente: http://es.wikipedia.org/wiki/Modelo%20jer%C3%A1rquico?oldid=80153375 Colaboradores: Pabloab, Rosarinagazo, Fernandopcg, Jmvkrecords, Muro Bot, Quijav, Shalbat, AVBOT, LucienBOT, Angel GN, Diegusjaimes, Arjuno3, Jkbw, Magomaitin,
Sarang, Grillitus, Jarould, Egis57, Fernygaspa y Annimos: 14
IMS (IBM) Fuente: http://es.wikipedia.org/wiki/IMS%20(IBM)?oldid=70040728 Colaboradores: Flextron, Cinabrium, Boticario, RobotQuistnix, Yrbot, Maleiva, Icvav, GermanX, C-3POrao, Eskimbot, Calsbert, Qwertyytrewqqwerty, CEM-bot, Asereware, Locovich, Hanjin, TXiKiBoT, Guirrohl, Dhidalgo, VolkovBot, Ingteleco, Muro Bot, BotMultichill, PaintBot, BotSottile, DioSiTa, DSisyphBot, Rubinbot, AstaBOTh15,
EmausBot, KLBot2, Elvisor, Chevebot y Annimos: 10
Data Language/Interface Fuente: http://es.wikipedia.org/wiki/Data%20Language/Interface?oldid=72829380 Colaboradores: Flextron, CEMbot, Locovich, Muro Bot, Loveless, DioSiTa, EmausBot, Rotlink, Addbot y Leticiapop
Base de datos XML Fuente: http://es.wikipedia.org/wiki/Base%20de%20datos%20XML?oldid=69717894 Colaboradores: CEM-bot, Leonpolanco, Juvalen, TiriBOT, Sergio Andres Segovia, KLBot2, Invadibot, Elvisor y Annimos: 3

6.5.2

Images

Archivo:Database_models.jpg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/3b/Database_models.jpg Licencia: CC BY-SA 3.0

Colaboradores: Trabajo propio Artista original: Marcel Douwe Dekker
Archivo:Emp_Tables_(Database).PNG Fuente: http://upload.wikimedia.org/wikipedia/commons/8/87/Emp_Tables_%28Database%29.
PNG Licencia: Public domain Colaboradores: Trabajo propio Artista original: Jamesssss
Archivo:Flat_File_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/d/dd/Flat_File_Model.svg Licencia: Public domain
Colaboradores: http://commons.wikimedia.org/wiki/File:Flat_File_Model.jpg Artista original: Wgabrie (<a href='//commons.wikimedia.org/
wiki/User_talk:Wgabrie' title='User talk:Wgabrie'>talk</a>) 16:48, 13 March 2009 (UTC)
Archivo:Hierarchical_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/e/eb/Hierarchical_Model.svg Licencia: Public
domain Colaboradores: http://knowledge.fhwa.dot.gov/tam/aashto.nsf/All+Documents/4825476B2B5C687285256B1F00544258/\protect\
char"0024\relaxFILE/DIGloss.pdf, page 10. Artista original:
U.S. Department of Transportation
vectorization: Trabajo propio
Archivo:Mergefrom.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/0/0f/Mergefrom.svg Licencia: Public domain Colaboradores: ? Artista original: ?
Archivo:Network_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/3e/Network_Model.svg Licencia: Public domain
Colaboradores: Data Integration Glossary. Artista original:
U.S. Department of Transportation
vectorization: Trabajo propio
Archivo:Object-Oriented_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/7/7c/Object-Oriented_Model.svg Licencia:
Public domain Colaboradores: Data Integration Glossary. Artista original:
U.S. Department of Transportation
vectorization: Trabajo propio
Archivo:X_mark.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/a/a2/X_mark.svg Licencia: Public domain Colaboradores: Trabajo propio Artista original: User:Gmaxwell

6.5.3

Content license

Creative Commons Attribution-Share Alike 3.0