Modelos de datos ConvencionalesApuntes de apoyo UNPA-C.Empresariales

Capítulo 1

Modelo de base de datos

Composición de cinco modelos de base de datos

Unmodelo de base de datos es un tipo de modelo de datosque determina la estructura lógica de una base de datos yde manera fundamental determina el modo de almacenar,organizar y manipular los datos.Entre los modelos lógicos comunes para bases de datos seencuentran:

• Modelo jerárquico

• Modelo en red

• Modelo relacional

• Modelo entidad–relación

• Modelo entidad–relación extendido

• modelo de objetos

• modelo documental

• Modelo entidad–atributo–valor

• modelo en estrella

Los modelos físicos de datos incluyen:

• índice invertido

• fichero plano

Otros modelos lógicos pueden ser:

• modelo asociativo

• modelo multidimensional

• modelo multivalor

• modelo semántico

• base de datos XML

• grafo etiquetado

• Triplestore

1.1 Relaciones y funciones

Un sistema de gestión de base de datos puede implementaruno o varios modelos. La estructura óptima depende de lanatural organización de los datos de la aplicación y de los re-quisitos de ésta, que incluyen ritmo de transacciones, fiabili-dad, mantenibilidad, escalabilidad y coste. La mayor partede los sistemas de gestión de bases de datos están construi-dos sobre un modelo de datos concreto, aunque es posibleque soporten más de uno.Sobre los distintos modelos físicos de datos se puede im-plementar cualquier modelo lógico. La mayoría del softwa-re de base de datos ofrece al usuario cierto control sobrela implementación física, dado el impacto que tiene en lasprestaciones.Un modelo no es sólo un modo de estructurar los datos:también define el conjunto de operaciones que se puedenrealizar con los datos. Por ejemplo el modelo relacional de-fine operaciones como SELECT y JOIN. Aunque esas ope-raciones no se ofrezcan explícitamente en un lenguaje deinterrogación dado, proporcionan la base sobre la que unlenguaje de interrogación se diseña.

2

1.3. MODELOS TEMPRANOS 3

1.2 Modelo fichero plano

Flat File Model

Record 1

Record 2

Record 3

I-95

I-495

SR-301

Route No.

12

05

33

Miles Activity

Overlay

Patching

Crack seal

Modelo fichero plano

El modelo de fichero plano consiste en una sola matriz bidi-mensional de elementos, donde todos los miembros en unacolumna dada tienen valores del mismo tipo, y todos losmiembros de la misma fila están relacionados entre ellos.Por ejemplo, las columnas para nombre y clave pueden serusadas para la seguridad de un sistema; cada fila indicará elnombre y su correspondiente clave para un individuo. Lascolumnas en la tabla suelen tener un tipo asociado, que ladefine como cadena de caracteres, fecha u hora, entero onúmero de coma flotante. Este modelo tabular fue el pre-cursor del modelo relacional.

1.3 Modelos tempranos

Estos modelos que se describen a continuación fueron po-pulares en las décadas 1960-1970, pero hoy en día se en-cuentran sólo en sistemas heredados. Se caracterizan prin-cipalmente por tener características de navegación confuertes conexiones entre la estructura física y la lógica, yposeen alta dependencia en los datos.

1.3.1 Modelo jerárquico

Hierarchical Model

Pavement Improvement

Reconstruction

Routine

Maintenance

Corrective

Rehabilitation

Preventive

Modelo jerárquico

En un modelo jerárquico, los datos están organizados enuna estructura arbórea (dibujada como árbol invertido oraíz), lo que implica que cada registro sólo tiene un padre.Las estructuras jerárquicas fueron usadas extensamente enlos primeros sistemas de gestión de datos de unidad cen-tral, como el Sistema IMS por IBM, y ahora se usan paradescribir la estructura de documentos XML. Esta estructu-ra permite relaciones 1:N entre los datos, y es muy eficientepara describir muchas relaciones del mundo real: tablas decontenido, ordenamiento de párrafos y cualquier tipo de in-formación anidada.Sin embargo, la estructura jerárquica es ineficiente paraciertas operaciones de base de datos cuando el camino com-pleto no se incluye en cada registro. Una limitación del mo-delo jerárquico es su incapacidad para representar de ma-nera eficiente la redundancia en datos.En la relación Padre-hijo: El hijo sólo puede tener un padrepero un padre puede tener múltiples hijos. Los padres e hi-jos están unidos por enlaces. Todo nodo tendrá una lista deenlaces a sus hijos.

1.3.2 Modelo de red

Network Model

Preventive Maintenence

Rigid Pavement

Spall Repair

Flexible Pavement

Silicone Sealant

Joint Seal Crack Seal Patching

Asphalt Sealant

Modelo en red

El modelo de red expande la estructura jerárquica, permi-tiendo relaciones N:N en una estructura tipo árbol que per-mite múltiples padres. Antes de la llegada del modelo rela-cional, el modelo en red era el más popular para las basesde datos. Este modelo de red (definido por la especificaciónCODASYL) organiza datos que usan en dos construccionesbásicas, registros y conjuntos. Los registros contienen cam-pos que puede estar organizados jerárquicamente, como enel lenguaje COBOL. Los conjuntos definen relaciones N:Nentre registros: varios propietarios, varios miembros. Un re-gistro puede ser un propietario de varios conjuntos, y miem-bro en cualquier número de conjuntos.

4 CAPÍTULO 1. MODELO DE BASE DE DATOS

El modelo en red es una generalización del modelo jerárqui-co, en tanto está construido sobre el concepto de múltiplesramas (estructuras de nivel inferior) emanando de uno o va-rios nodos (estructuras de nivel alto), mientras el modelo sediferencia del modelo jerárquico en que las ramas puedenestar unidas a múltiples nodos. El modelo de red es capazde representar la redundancia en datos de una manera máseficiente que en el modelo jerárquico.Las operaciones del modelo de red se realizan por de nave-gación: un programa mantiene la posición actual, y navegaentre registros siguiendo las relaciones entre ellos. Los re-gistros también pueden ser localizados por valores claves.Aunque no es una característica esencial del modelo, lasbases de datos en red implementan sus relaciones mediantepunteros directos al disco. Esto da una velocidad de recu-peración excelente, pero penaliza las operaciones de cargay reorganización.Entre los SGBD más populares que tienen arquitectura enred se encuentran Total e IDMS. IDMS logró una impor-tante base de usuarios; en 1980 adoptó el modelo relacionaly SQL, manteniendo además sus herramientas y lenguajesoriginales.La mayoría de bases de datos orientadas a objetos (intro-ducidas en 1990) usan el concepto de navegación para pro-porcionar acceso rápido entre objetos en una red. Objec-tivity/DB, por ejemplo, implementa 1:1, 1:N, N:1 y N:Nentre distintas bases de datos. Muchas bases de datos orien-tadas a objetos también soportan SQL, combinando así lapotencia de ambos modelos.

1.3.3 Modelo de fichero invertido

En un fichero invertido o de índice invertido, los datos con-tenidos se usan como claves en una tabla de consulta (lookuptable), y los valores en la tabla se utilizan como punteros ala localización de cada instancia. Esta es también la estruc-tura lógica de los índices de bases de datos modernas, loscuales introducen sólo el contenido de algunas columnas enesa tabla de consulta. El modelo de fichero invertido pue-de poner los índices en ficheros planos para acceder a susregistros de manera eficiente.Implementaciones notables de este modelo de datos la reali-zó Adabas de Software AG, aparecida en 1970. Adabas lo-gró una importante base de usuarios y está soportada aúnhoy. En la década de 1980 adoptó el modelo relacional ySQL, manteniendo sus propias herramientas y lenguajes.

1.4 Modelo relacional

El modelo relacional fue introducido por E.F. Codd en1970[1] con el objetivo de querer hacer los SGBD másindependientes de las aplicaciones. Es un modelo matemá-tico definido en términos de lógica de predicados y teoríade conjuntos, y se han implementado con él SGBDs paramainframe, ordenadores medios y microordenadores.Los productos referidos como base de datos relacional dehecho implementan un modelo que es sólo una aproxima-ción al modelo matemático definido por Codd. Existen trestérminos usados con profusión en el modelo relacional debases de datos: relaciones, atributos y dominios. Una rela-ción equivale a una tabla con filas y columnas. Las columnasde una relación se llaman con rigor atributos, y el dominioes el conjunto de valores que cada atributo puede tomar.La estructura básica de datos del modelo relacional es larelación (tabla), donde la información acerca de una deter-minada entidad (p.e. “empleado”) se almacena en tuplas (fi-las), cada una con un conjunto de atributos (columnas). Lascolumnas de cada tabla enumeran los distintos atributos dela entidad (el nombre del “empleado”, dirección y númerode teléfono, p.e.), de modo que cada tupla de la relación“empleado” representa un empleado específico guardandolos datos de ese empleado concreto.Todas las relaciones (es decir, tablas) en una base de datosrelacional han de seguir unas mínimas reglas:

1. el orden de los atributos es irrelevante

2. no puede haber tuplas repetidas

3. cada atributo sólo puede tener un valor.

Una base de datos puede contener varias tablas, cada unasimilar al modelo plano. Una de las fortalezas del modelorelacional es que un valor de atributo coincidente en dos re-gistros (filas) -en la misma o diferente tabla- implica una re-lación entre esos dos registros. Es posible también designaruno o un conjunto de atributos como “clave”, que permitiráidentificar de manera única una fila en una tabla.Dicha clave que permite identificar de manera unívoca unafila en una tabla se denomina “clave primaria”. Las clavesson habitualmente utilizadas para para combinar datos de

1.5. MODELOS POST-RELACIONALES 5

dos omás tablas. Por ejemplo una tabla de empleados puedecontener una columna denominada “departamento"", cuyovalor coincida con la clave de una tabla denominada “de-partamentos”. Las claves son esenciales a la hora de crearíndices, que facilitan la recuperación rápidas de datos de ta-blas grandes. Una clave puede estar formada por cualquiercolumna o por una combinación de varias columnas, deno-minándose clave compuesta. No es necesario definir todaslas claves por adelantado; una columna puede usarse comoclave incluso si no estaba previsto en origen.Una clave que tenga un significado en el mundo físico (talcomo un nombre de persona, el ISBN de un libro o el núme-ro de serie de un coche) a veces se denomina clave “natu-ral”. Si no existe una clave natural viable, se puede asignarun sucedáneo arbitrario (como dar a una persona un núme-ro de empleado). En la práctica la mayor parte de las basesde datos tienen a la vez claves sucedáneas y naturales, dadoque las claves sucedáneas pueden usarse internamente pa-ra crear enlaces íntegros entre filas, mientras que las clavesnaturales tienen un uso menos fiable a la hora de buscar oenlazar con otras bases de datos.El lenguaje de interrogación más común utilizado con lasbases de datos relacionales es el Structured Query Language(SQL).

1.4.1 Modelo Dimensional

El modelo dimensional es una adaptación especializada delmodelo relacional usada para almacenar datos en depósitosde datos, de modo que los datos fácilmente puedan ser ex-traídos usando consultas OLAP. En el modelo dimensional,una base de datos consiste en una sola tabla grande de datosque son descritos usando dimensiones y medidas. Una di-mensión proporciona el contexto de un hecho (como quienparticipó, cuando y donde pasó, y su tipo). Las dimensio-nes se toman en cuenta en la formulación de las consultaspara agrupar hechos que están relacionados. Las dimensio-nes tienden a ser discretas y son a menudo jerárquicas; porejemplo, la ubicación podría incluir el edificio, el estado yel país. Una medida es una cantidad que describe el dato, talcomo los ingresos. Es importante que las medidas puedanser agregados significativamente -por ejemplo, los ingresosprovenientes de diferentes lugares puedan sumarse.En una consulta (OLAP), las dimensiones y los hechos sonagrupados y añadidos juntos para crear un informe. El mo-delo dimensional a menudo es puesto en práctica sobre elmodelo relacional usando un esquema de estrella, consis-tiendo en una tabla que contiene los datos y tablas circun-dantes que contienen las dimensiones. Dimensiones com-plicadas podrían ser representadas usando múltiples tablas,usando un esquema de copo de nieve.

Un almacén de datos (data warehouse) puede contener múl-tiples esquemas de estrella que comparten tablas de dimen-sión, permitiéndoles ser usadas juntas. El establecimientode un conjunto de dimensiones estándar es una parte im-portante del modelado dimensional.

1.5 Modelos post-relacionales

Los productos que ofrecen un modelo de datos más gene-ral que el relacional se denominan a veces post-relational.[2]Como términos alternativos se oyen incluyen “bases de da-tos híbridas”, “bases de datos relacionales potenciadas conobjectos” entre otros. El modelo de datos de esos productosincorpora relaciones pero no limitadas por las restriccionesdel principio de información de E.F. Codd, que requiere quetoda información en la base de datos debe ser modelada entérminos de valores en relaciones nada más[3]

Algunas de estas extensiones al modelo relacional integranconceptos de tecnologías que preceden el modelo relacio-nal. Por ejemplo permiten representar un grafo dirigido conárboles en los nodos. La compañía sones implementa esteconcepto en su GraphDB.Algunos productos post-relacionales aplían los sistemas re-lacionales con caracterśiticas no relacionales. Otros han lle-gado al mismo punto añadiendo características relacionaesa modelos pre-relacionales. Paradójicamente esto ha per-mitido a productos históricamente pre-relacionales, comopor ejemplo PICK y MUMPS, razonar su esencia post-relactional.El Resource Space Model es un modelo de datos no relacio-nal basado en clasificación multi-dimensional.[4]

1.5.1 Modelo de grafo

Las bases de datos de grafos permiten incluso una estructuramás general que una base de datos en red, cualquier nodopuede estar conectado a cualquier otro.

1.5.2 Modelo multivaluados

Las bases de datos multivaluadas contienen datos arraci-mados, en el sentido de que pueden almacenar los datos delmismo modo que las bases de datos relacionales, pero ade-más permiten un nivel de profundidad al que las relacio-nales sólo se pueden aproximar utilizando subtablas. Estoes prácticamente igual al modo en que XML representa losdatos, donde un campo/atributo dado puede contener múl-tiples valores a la vez. El multivalor se puede considerar unaforma de XML comprimida.

6 CAPÍTULO 1. MODELO DE BASE DE DATOS

Un ejemplo puede ser una factura, la que puede ser vistacomo:

1. Encabezado, una entrada por factura

2. Detalle, una entrada por concepto

En el modelo multivaluado tenemos la opción de almace-nar los datos como una sola tabla (1), con tablas imbuidasrepresentando el detalle.Tiene la ventaja que la correspondencia entre la factura con-ceptual y la de la factura como representación de datos esbiunívoca. Esto redunda en menor número de lecturas, me-nos problemas de integridad referencial y una fuerte dismi-nución del hardware necesario para soportar un volumende transacciones dado.

1.5.3 Modelo orientado a objetos

Object-Oriented Model

Object 1: Maintenance Report Object 1 Instance

Object 2: Maintenance Activity

DateActivity CodeRoute No.Daily ProductionEquipment HoursLabor Hours

01-12-0124I-952.56.06.0

Activity CodeActivity NameProduction UnitAverage Daily Production Rate

Modelo orientado a objetos

En la década de 1990, el paradigma de la orientación a ob-jetos se aplicó a las bases de datos creando un nuevo mo-delo llamado base de datos orientada a objetos. Esto tuvoel fin de reducir la impedancia objeto-relacional, la sobre-carga de convertir la información de su representación en labase de datos -como filas en tablas- a su representación en elprograma -típicamente como objeto. Incluso más, los tiposde datos usados en una aplicación pueden definirse directa-mente en la base de datos, preservando así la base de datosla misma integridad de datos. Las bases de datos orientadasa objetos también introducen las ideas clave de la progra-mación orientada a objetos -encapsualción y polimorfismo-en el mundo de las bases de datos.Se han propuesto distintos modos de almacenar objetos enuna base de datos. Algunos se han aproximado desde laprespectiva de la programación, haciendo los objetos ma-nipulados por el programa persistentes. Esto típicamente

requiere la adición de algún tipo de lenguaje de interroga-ción, ya que lo lenguajes tradicionales no tienen la posibilil-dad de encontrar objetos basados en su contenido. Otros sehan proximado al problema desde la prespectiva de la basede datos, definiendo un modelo orientado a objetos para labase de datos, y definiendo un lenguaje de programaciónde dicha base de datos que permite tanto capacidades deprogramación como de interrogación.Las bases de datos orientadas a objetos sufren falta de es-tandarización; aunque han sido definidos estándares por enObject Database Management Group nunca han sido im-plementados con generalidad suficiente como para permitirla interoperabilidad entre productos. Sin embargo, las basesde datos orientadas a objetos han sido empleadas efiocaz-mente en distintas aplicaciones: generalmente en nichos es-pecializados como ingeniería o biología molecular, pero node forma general con soporte comercial. Sin embargo algu-nas de las ideas que ha aportado han sido recogidas por losfabricantes de bases de datos relacionales y se han aplicadoen extensiones al lenguaje SQL.Una alternativa a la traducción entre objetos y relaciones esla de usar una librería Object-Relational Mapping (ORM).

1.6 Referencias[1] E.F. Codd (1970). “A relational model of data for large sha-

red 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 withtechnology, Thomson, ISBN 0-17-012731-1, p. 69.

[3] Date, C. J. (1 de junio de 1999). «When’s an extension notan extension?». Intelligent Enterprise 2 (8).

[4] Zhuge, H. (2008). The Web Resource Space Model. Web In-formation Systems Engineering and Internet TechnologiesBook Series 4. Springer. ISBN 978-0-387-72771-4.

Capítulo 2

CODASYL

CODASYL (también escritoCodasyl) es el acrónimo para"Conference on Data Systems Languages", un consorciode industrias informáticas formado en 1959 con el objeto deregular el desarrollo de un lenguaje de programación están-dar que pudiera ser utilizado en multitud de ordenadores.De todos estos esfuerzos resultó el lenguaje COBOL.Los miembros de CODASYL pertenecían a industrias einstituciones gubernamentales relacionadas con el procesode datos. Su principal meta era promover un análisis, diseñoe implementación de los sistemas de datos más efectivos.La organización trabajó en varios lenguajes a lo largo deltiempo pero nunca llegaron a establecer estándar alguno,proceso que dejaron en manos de ANSI.En 1965 CODASYL formó la List Processing Task Force(en español,Grupo de Trabajo para el Procesado de Listas).Este grupo se dedicó a desarrollar extensiones del lenguajeCOBOL para el procesamiento de colecciones de registros;el nombre surgió a causa del sistema IDS (Integrated Da-ta System) desarrollado por Charles Bachman (sistema quesupuso el mayor aporte técnico al proyecto), y que maneja-ba las distintas relaciones mediante cadenas de punteros. En1967 el grupo fue renombrado como Grupo de Trabajo so-bre Bases de Datos, y su primer informe fechado en enerode 1968 se tituló COBOL extensions to handle data bases(en español, Extensiones COBOL para el manejo de bases dedatos). En octubre de 1969 el DBTG publicó las primerasespecificaciones para el modelo de base de datos en red, elcual acabó por ser conocido comoModelo Codasyl. Propia-mente estas especificaciones definían varios lenguajes porseparado: un lenguaje de descripción de datos (DDL, siglasen inglés) para definir el esquema de la base de datos, otroDDL para crear uno o más subesquemas para definir vis-tas de la base de datos en aplicaciones; y un lenguaje demanipulación de datos (DML) que definía palabras clavepara incluir en el código COBOL las llamadas y actualiza-ciones de la base de datos. Aunque los trabajos siempre secentraron en COBOL, la idea de un lenguaje independientecomenzó a emerger, impulsada por las pretensiones de IBMde utilizar el PL/I como reemplazo de COBOL.En 1971, en gran parte como respuesta a la necesidad de la

independencia del nuevo lenguaje de programación, el tra-bajo fue reorganizado: el desarrollo del DDL fue continua-do por el Data Description Language Committee, mientrasque el desarrollo del COBOL DML fue asumido por el CO-BOL Language Committee. En retrospectiva, esta divisióntuvo desafortunadas consecuencias. Los dos grupos nuncafueron capaces de sincronizar sus especificaciones, obligan-do a los distribuidores a subsanar los problemas generadospor las diferencias entre ellas. Finalmente se hizo inevitablela aparición de una falta de interoperabilidad entre imple-mentaciones.Algunas empresas implementaron productos de bases dedatos rudamente conformes a las especificaciones delDBTG, siendo de todas ellas las más conocidas: HoneywellIntegrated Data Store (IDS/2), Cullinet Integrated Databa-se Management System (IDMS), Univac DMS-1100 o Di-gital Equipment Corporation DBMS32.

2.1 El modelo CODASYL

El modelo Codasyl definió una serie de elementos básicosque definían su estructura de datos. Son los siguientes:- Elemento de datos.- Unidad de datos más pequeña quese puede referenciar. Puede ser de distintos tipos, y puededefinirse como dependiente de valores de otros elementos(datos derivados).- Agregado de datos.- Se asemeja a los campos de un ficheroo a los atributos de otros modelos.- Registro.- Colección nominada de elementos de datos.Unidad básica de acceso y manipulación. Se asemeja a losregistros en ficheros y a las entidades en el modelo E/R.- Conjunto (SET).- Colección nominada de dos o más ti-pos de registros que establece una vinculación entre ellos.Origen de muchas restricciones. Las interrelaciones 1:N serepresentan aquí mediante SET.- Área.- Subdivisión nominada del espacio direccionable dela base de datos que contiene ocurrencias de registros.

7

8 CAPÍTULO 2. CODASYL

- Clave de base de datos identificador interno único paracada ocurrencia de registro.Proporciona su dirección en la base de datos. Es un obstácu-lo para conseguir la independencia lógica / física. Suponíaproblemas el reutilizar una clave cuando se reorganizaba labase de datos.CODASYL: CONJUNTOS (SET)El conjunto es uno de los más importantes elementos delmodelo Codasyl, pues constituye el elemento básico parala representación de interrelaciones. Mediante SET se esta-blecen relaciones jerárquicas (1:N) a dos niveles. El nodoraíz es el propietario y los nodos descendientes (pueden serde varios tipos) son los miembros.CARACTERÍSTICAS BÁSICAS DEL MODELO CO-DASYLSe pueden resumir las características básicas del modelo en:- Un SET es una colección nominada de dos o más tipos deregistros que representan un tipo de interrelación 1:N (enconsecuencia también 1:1).- Cada SET tendrá un tipo de registro propietario y uno omás tipos de registros miembro.- El número de SET que se pueden declarar en el sistema esilimitado.- Cualquier registro puede ser propietario de uno o variosSET.- Cualquier registro puede ser miembro de uno o variosSET.- Podrán existir SET singulares en los que el propietario esel sistema (una entidad se interrelaciona consigo mismo).- A pesar de que una entidad sea miembro de un SET, existela posibilidad de que ciertas ocurrencias de esa entidad noestén ligadas al SET, con lo que no tendrían propietario yquedarían no ligadas respecto de ese SET.RESTRICCIONES INHERENTES DEL MODELO CO-DASYL.Cuando hablábamos del modelo en red general, decíamosque era un modelo muy flexible a coste de no tener restric-ciones inherentes. Esta ausencia de restricciones hace quesea muy difícil de implementar, y a la larga suele reportarescaso rendimiento, por lo que como también decíamos nopasa de ser un modelo teórico.El modelo Codasyl está basado en el modelo en red gene-ral, pero a diferencia de este, es un modelo utilizado. Estoes debido a que Codasyl ha incluido restricciones inheren-tes que hacen que sea posible su implementación y que seobtenga un alto rendimiento del sistema.

Las restricciones son las siguientes:- Solo se admiten tipos de interrelaciones jerárquicas de dosniveles (propietario y miembro). Si se admite la combina-ción de varios SET para generar jerarquías multinivel.- En el nivel propietario solo se permite un tipo de registro.- En el mismo SET no se permite que a un registro ser ala vez propietario y miembro, no está admitida la reflexivi-dad. Aunque esta restricción se eliminó con el tiempo, losproductos basados en Codasyl la siguen utilizando.- Una misma ocurrencia de miembro no puede perteneceren unmismo tipo de SET amás de un propietario. Esto haceque se simplifique la implementación física de los SET, yaque sus ocurrencias se pueden organizar como una cadena.

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, enDatabases - Role and Structure, ed. P.M. Stocker,P.M.D. Gray y M.P. Atkinson, CUP, 1984. ISBN 0-521-25430-2

2.3 Enlaces externos• Charles Babbage Institute

Capítulo 3

Modelo jerárquico

Unmodelo de datos jerárquico es un modelo de datos enel cual los datos son organizados en una estructura parecidaa un árbol. La estructura permite a la información que repitey usa relaciones padre/Hijo: cada padre puede tener muchoshijos pero cada hijo sólo tiene un padre. Todos los atributosde un registro específico son catalogados bajo un tipo deentidad.En una base de datos, un tipo de entidad es el equivalentede una tabla; cada registro individual es representado comouna fila y un atributo como una columna. Los tipos de enti-dad son relacionados el uno con el otro usando 1: Trazar unmapa de n, también conocido como relacion de uno a va-rios. El ejemplo más aprobado de base de datos jerárquicamodela es un IMS diseñado por la IBM.

3.1 Historia

Una base de datos puesta en práctica relacionada con estetipo de modelo de datos primero fue llamada en la formade publicación en 1992 [1] (mirar también anidó el modelode conjuntos). Antes del desarrollo del primer sistema degestión de datos (DBMS), los programas de uso proporcio-naron el acceso a los datos que tuvieron acceso a archivosplanos. Los problemas de integridad de datos y la inhabili-dad de tales sistemas de tratamiento de archivo para repre-sentar relaciones de datos lógicas conducen al primer mo-delo de datos: el modelo de datos jerárquico. Este modelo,que fue puesto en práctica principalmente por el Sistemade Dirección de Información de la IBM (IMS) sólo permi-te personalizado(exacto) una a varias relaciones entre en-tidades. Cualquier entidad al final de la relación puede serrelacionada sólo con una entidad.

3.2 Ejemplo

Un ejemplo de un modelo de datos jerárquico sería si unaorganización tuviera los registros de empleados en una tabla

(el tipo de entidad) llamada “Empleados”. En la tabla ha-bría atributos/columnas como el Nombre de pila, el Apelli-do, el Nombre de Trabajo y el Salario. La empresa tambiéntiene datos sobre los hijos del empleado en una tabla se-parada “Hijos” llamada con atributos como el Nombre depila, el Apellido, y la fecha de nacimiento. La tabla de Em-pleado representa un segmento paternal y la tabla de Hijosrepresenta un segmento Infantil. Estos dos segmentos for-man una jerarquía donde un empleado puede tener muchoshijos, pero cada hijo sólo puede tener un padre.Considere la estructura siguiente:En esta tabla, “el hijo” es el mismo tipo que “el padre”. Lajerarquía que declara EmpNo 10 es el jefe de 20, y30 y40 cada informe a 20 es representado por la columna “Re-porta”. Llamada en la Base de datos relacional, la columnaReporta es una llave foranea, el referirse de la columna Em-pNo. Si el tipo de datos “hijo” fuera diferente, estaría en unatabla diferente, pero todavía habría una llave foranea que serefiere la columna EmpNo de la tabla de empleados.Comúnmente se conocen a estos modelos simplemente co-mo la lista de adyacencia, fue presentado por el Doctor Ed-gar F. Codd.

9

Capítulo 4

IMS (IBM)

IBM Information Management System (IMS) es ungestor de bases de datos jerárquicas y un gestor transac-cional con alta capacidad de proceso.IBM diseñó el IMS con Rockwell y Caterpillar en 1966 de-bido al Programa Apolo. El desafío de IBM era inventariarla extensísima lista de materiales del cohete lunar SaturnoV y de la nave Apolo.El primer mensaje “IMS READY” apareció en un termi-nal IBM 2740 en Downey, California un 14 de agosto de1968. IMS todavía se usa extensamente 40 años después y,con el tiempo, ha visto interesantes desarrollos como el sis-tema IBM Sistema/360, hoy convertido en z/OS y Sistemaz9. Por ejemplo, IMS soporta aplicaciones desarrolladas enJava, JDBC, XML y Servicios Web.

4.1 IMS DB

Las funcionalidades de IMS relacionadas con bases de datosreciben el nombre de IMS DB (IMS DataBases). Hay trestipos de bases de datos jerárquicas:

1. Bases de datos Full function

• Descendientes directas de las bases de datosData Language/I desarrolladas para el Apolo,pueden tener índices primarios y secundarios ac-cedidos usando llamadas DL/I desde la aplica-ción, algo similar a llamadas SQL a Oracle oDB2 (de hecho, SQL debe su herencia a DL/I).

• Este tipo de bases de datos tiene una gran varie-dad de métodos de acceso, aunque los dominan-tes son: Hierarchical Direct (HDAM) (“Ac-ceso directo jerárquico”) y Hierarchical Inde-xed Direct (HIDAM) (“Acceso directo jerár-quico indexado""). Los otros métodos son Sim-ple Hierarchical Indexed Sequential (SHI-SAM) (“Acceso simple jerárquico indexado se-cuencial”), Hierarchical Sequential (HSAM)

(“Acceso jerárquico secuencial”) y Hierarchi-cal Indexed Sequential (HISAM) (“Acceso je-rárquico indexado secuencial”).

• Los datos se almacenan usando VSAM, un tipode acceso nativo de z/OS, u Overflow Sequen-tial (OSAM) (“Acceso de desbordamiento se-cuencial”), un tipo de acceso propio de IMS queoptimiza la Entrada/Salida de algunos patrones.

2. Bases de datos Fast Path

• Las bases de datos Fast Path pueden ser bienData Entry Databases (DEDB) o Main StorageDatabases (MSDB). Ambos tipos carecen de in-dexación, pero a cambio están optimizados paraofrecer elevados índices de acceso.

• Las MSDB están destinadas a desaparecer debi-do a sus fuertes restricciones. No permiten altasni bajas y las referencias directas se resuelvenmediante búsquedas binarias.

• Las DEDB pueden llegar a ser tan complejascomo las de DL/I mientras mantienen su rendi-miento, por lo que están sustituyendo a MSDB.

• Actualmente se puede aprovechar la riqueza es-tructural de las DEDB y la mejora de rendimien-to de las MSDB gracias a la opción de poner elmemoria virtual áreas de una DEDB. Esta fun-cionalidad permite también, compartir una mis-ma base de datos entre distintos sistemas usandoponiendo las áreas en la coupling facility.

3. Bases de datos High Availability Large Databases(HALDB)

• IMS V7 introdujo HALDBs, como una exten-sión de la base de datos Full Function para pro-veer una mejor disponibilidad de la misma, me-jor manejo de grandes volúmenes de datos, y,con IMS V9, reorganización online para sopor-tar alta disponibilidad.

10

4.4. ENLACES EXTERNOS 11

4.2 IMS TM

Las funcionalidades de IMS relacionadas con la gestióntransaccional reciben el nombre de IMS TM (IMS Transac-tionManager), anteriormente conocido como IMSDC (IMSDataControl)

4.3 Registro

Tanto para un gestor transaccional como para un gestor debases de datos es imprescindible registrar cada paso en unfichero de registro, de manera que todas las acciones se pue-dan deshacer. IMS usa un extenso sistema de registro capazde soportar grandes cantidades de información sin repercu-tir en el tiempo de respuesta.

Buffers IMS

IMS usa buffers para escribir cualquier información que ne-cesite ser registrada. Cuando un buffer se llena, IMS ordenaescribir todo el buffer al fichero de OLDS. El tamaño vienedado por el tamaño del fichero de OLDS.

OLDS

El OLDS (fichero de registro online, del inglés Online LogData Set) es un fichero de registro usados en IMS para al-macenar información que, por razones de recuperabilidad,debe escribirse en disco. Para mejorar el rendimiento, sólose copian bloques de información completos. Si se debe co-piar algún buffer incompleto, este se copia al WADS. LosOLDS se usan en forma de cadena, de modo que cuando unfichero de OLDS se llena, este se archiva y se pasa a usarotro. Para prevenir fallos provocados por errores físicos deescritura en disco, es posible mantener una copia dual deOLDS, de manera que la información se escribe en dos fi-cheros, uno principal y otro como copia de seguridad.

WADS

El WADS (fichero de escritura avanzada, del inglés Write-ahead Data Set) es un fichero de registro usado en IMS paraalmacenar buffers de información incompletos antes de es-cribirse definitivamente en el OLDS. Los WADS tienen unalto rendimiento debido a su pequeño tamaño y a su estruc-tura interna. Cuando el sistema o el IMS sufre una fallida,la información del WADS sirve para cerrar el OLDS comoparte de un arranque de emergencia. Para prevenir fallosprovocados por errores físicos de escritura en disco, es po-sible mantener una copia dual de WADS, de manera que la

información se escribe en dos ficheros, uno principal y otrocomo copia de seguridad.

SLDS

El SLDS (fichero de registro secundario, del inglés Secon-dary Log Data Set) es un fichero de registro usado en IMSpara almacenar información consolidada y que ya ha sidoarchivada. Es normal que el SLDS, a diferencia del OLDS,se almacene en cinta en vez de disco, debido a su tamaño ya su escaso uso, únicamente en escenarios de recuperaciónde bases de datos.

RLDS

El RLDS (fichero de registro de recuperación, del inglésRecovery Log Data Set) es un fichero de registro opcionalusando en IMS para almacenar información consolidada yarchivada relacionada con la recuperación de bases de da-tos. Al contener sólo registros relacionados con la recupera-ción de bases de datos, el volumen de información es muchomenor que en el caso del SLDS, lo cual hace más rápido elproceso de recuperación de bases de datos.

Archivado

Cuando un OLDS se llena, IMS ejecuta un proceso de ar-chivado. Este proceso se compone de los siguientes pasos:

1. El OLDS activo (o la pareja, en caso de que se estéusando copia dual) se cierra y se marca como “pen-diente de archivar”.

2. Se empieza a grabar en el siguiente OLDS disponible(o en la siguiente pareja de OLDS, en caso de que seesté usando copia dual).

3. Se copia la información del OLDS pendiente de ar-chivar en un fichero SLDS. Opcionalmente, se puedecrear un RLDS.

4. El OLDS que estaba pendiente de archivar se marcacomo “disponible” para escribir en él.

4.4 Enlaces externos• Introducción a Information Management

Capítulo 5

Data Language/Interface

Data Language/Interface (abreviado DL/1 o DL/I) es ellenguaje de programación para acceder a las bases de datosde IMS y a su sistema de comunicación.Se implementa desde cualquier lenguaje existente realizan-do llamadas a un programa puente llamado DFSLI000. Es-te software contiene puntos de entrada para gestionar va-rios lenguajes de programación, por ejemplo, para llamara PLITODLI desde un programa PL/1 o CBLTDLI des-de un programa COBOL. El programa DFSLI00 se enlazadesde el programa real, pasa la información a IMS y poste-riormente devuelve datos y un código de retorno.En cualquier base de datos IMS full-function, el elementomás pequeño que se puede consultar es el segmento. Ca-da segmento se compone de campos, donde normalmenteuno de ellos será un campo clave. Los segmentos en la basede datos están organizados de forma jerárquica, al segmen-to del nivel más alto se denomina segmento raíz. Existenrestricciones en cuanto al número de segmentos distintos:un máximo de 255 segmentos diferentes en 15 niveles. Sinembargo, no hay ningún limite en el número de ocurrenciasde cada tipo de segmento, más allá de los límites físicos delespacio de almacenamiento.La estructura de la base de datos se presenta a la aplicaciónmediante PCB (Bloque de Control de Programa, o ProgramControl Block), este es uno de los parámetros que se pasanal DFSLI000. Además de PCB para acceso a bases de datos,existes PCB para mensajería y acceso a bases de datos enficheros secuenciales.Cuando la aplicación accede a un segmento de la base de da-tos puede usar una SSA (Argumento de Búsqueda de Seg-mento, Segment Search Argument) como parámetro , pa-ra especificar uno o varios segmentos específicos. La SSAcontiene normalmente el tipo de segmento y el valor decualquier campo clave.El primer parámetro en una llamada de DL/1 es el códi-go de función: un campo de cuatro crácteres que indicanla función de la llamada. Por ejemplo: “GU ” (Get Unique),“GN ” (Get Next), “REPL” (Replace), and “ISRT” (Insert).

5.1 Véase también• IMS

5.2 Enlaces externos• Preguntas y respuestas

[[Categoría:Lenguajes de programador

12

Capítulo 6

Base de datos XML

Una base de datos XML constituye un sistema softwareque da persistencia a datos almacenados en formato XML.Estos datos pueden ser interrogados, exportados y serializa-dos. Las bases de datos XML están generalmente asociadascon las bases de datos documentales.Existen dos grandes clases de bases de datos XML:[1]

1. XML habilitado: éstas bien pueden mapear XML enestructuras tradicionales de bases de datos (como lasrelacionales[2]), aceptando XML como entrada y for-mateando en XML la salida, o más recientemente so-portando tipos XML nativos en la propia base de da-tos. Esto implica que la base de datos procesa el XMLinternamente (lo opuesto a soportarlo mediante midd-leware).

2. XML nativo (NXD): el modelo interno de estas basesde datos usa documentos XML como la unidad ele-mental de almacenamiento, los cuales no han de al-macenarse necesariamente en formato de texto.

6.1 Lógica del uso de XML en basesde datos

O'Connell da una razón para el uso de XML en bases dedatos: el generalizado aumento del transporte de datos enformato XML, lo que significa que “los datos se extraen debases de datos y convertidos a XML o viceversa”.[3] Resul-taría más eficiente (en términos de costes de conversión) yfácil almacenar los datos en formato XML directamente.

6.2 Bases de datos habilitadas XML

Típicamente ofrecen alguna de las siguientes aproximacio-nes para almacenar XML en la estructura relacional clásica:

1. El XML se almacena en un campo CLOB (Characterlarge object)

2. El XML se desgaja en una serie de tablas según unesquema[4]

3. El XML se almacena de forma nativa como tipo XMLsegún define ISO[5]

Entre los SGBD que soportan ISO XML están:

• IBM DB2 (XML puro[6])

• Microsoft SQL Server[7]

• Oracle Database[8]

• PostgreSQL[9]

Típicamente una base de datos habilitada XML se adaptamejor allí donde la mayoría de los datos no están en XML,para aquellos datos en los que la mayoría están en XML,una base de datos nativa XML se adaptará mejor.

6.2.1 Ejemplo de interrogación XML enIBM DB2 SQL

SELECT id, vol, xmlquery('$j/name', procesandorevista “j”) AS name FROM revistas WHERE xmle-xists('$j[publica="Elsevier"]', procesando revista “j”)

6.3 Bases de datos nativas XML

El término “base de datos nativa XML” (NXD) puede lle-var a confusión. Muchas NXDs no funcionan como basesde datos independientes, y no almacenan el texto nativo enXML.La definición formal de la iniciativa XML:DB (que pareceinactiva desde 2003[10]) afirma que:

13

14 CAPÍTULO 6. BASE DE DATOS XML

• Define un modelo (lógico) para un documento XML—contrapuesto a los datos en ese documento— y al-macena y recupera documentos según esemodelo. Co-mo mínimo el modelo debe incluir elementos, atri-butos, CDATA y orden de los documentos. Ejemplosde estos modelos incluyen el modelo de datos XPath,XML Infoset y los que implica el DOM y los eventosen SAX 1.0.

• Tiene un documento XML como su unidad (lógica)fundamental de almacenamiento, del mismomodo queuna base de datos relacional lo tiene con la fila.

• No necesita basarse en ningún modelo de almacena-miento físico particular. Por ejemplo las NXD puedeusar estructuras relacionales, jerárquicas u orientadasa objetos, o usar un formato de almacenamiento pro-pietario (como índices o ficheros comprimidos).

Además, muchas bases de datos XML databases propor-cionan un modelo lógico de agrupar documentos, llamada“colecciones”. Las bases de datos pueden estableder y ges-tionar muchas colecciones al mismo tiempo. En algunas im-plementaciones puede existir una jerarquía de colecciones,de modo análogo a la estructura de directorios de un sistemaoperativo.Todas las bases de datos XML soportan al menos una sin-taxis de interrogación. Al menos casi todas soportan XPathpara realizar preguntas a documentos o colección de ellos.XPath provides a simple pathing system that allows users toidentify nodes that match a particular set of criteria.Además de XPath, muchas bases de datos XML soportanXSLT acomo método para transformar documentos o re-sultados obtenidos de la base de datos. XSLT proporcionaun lenguaje declarativo escrito con gramática XML. Conél define una serie de filtros XPath que pueden transformardocumentos XML en otros con otro formato, como textoplano, XML o HTML.Las bases de datos XML suelen interrogar medianteXQuery. XQuery incluye XPath como método de selecciónde nodos, pero de modo extendido que da capacidad detransformación. A veces los usuarios se refieren a su sintaciscomo FLWOR al poderse incluir en la pregunta las siguien-tes claúsulas: 'for', 'let', 'where', 'order by' y 'return'. Los fa-bricantes de SGBD relacionales -que tradicionalmente sóloproporcionan mecanismos SQL- ahora incluyen mecanis-mos híbridos SQL-XQuery. Esto permite interrogar los da-tos XML de manera análoga a los relacionales, en la mismasentencia. Esto permite combinar datos XML y relaciona-les.Lamayoría de bases de datos XML soportan un API neutralcomún llamadoXQJ API. Este fue desarrollado por JCP co-mo interfaz estándar de una fuente de datos XML/XQuery,

permitiendo a los desarrolladores java realizar preguntas deacuerdo a la especificación W3C XQuery 1.0. En definitivael XQJ API representa a las bases de datos XML lo mismoque representa el API JDBC a las bases de datos relaciona-les y SQL.

6.3.1 Características del lenguaje

6.4 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 Efficient Approach Using Relational Databases”, ISBN3-639-11581-3, VDM Verlag, 2009.

[3] O'Connell, S. Advanced Databases Course Notes, Southam-pton, University of Southampton, 2005, 9.2

[4] Creating XMLType Tables and Columns Based on XMLSchema

[5] ISO/IEC 9075-14:2011

[6] IBM DB2 pureXML overview -- DB2 as an XML database

[7] Using XML in SQL Server

[8] XMLType Operations

[9] PostgreSQL - Data Types - XML Type

[10] «Frequently Asked Questions About XML:DB». TheXML:DB Initiative. Sourceforge. 2003. Consultado el 16 dediciembre de 2011.

[11] Zorba XQuery 3.0 support

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: Cho-

bot, Banfield, Tomatejc, CEM-bot, IrwinSantos, LMLM, Technopat, Muro Bot, Jesusosm, Javierito92, Eduardosalg, Leonpolanco, Poco a poco,Açipni-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 Anónimos: 52

• CODASYL Fuente: http://es.wikipedia.org/wiki/CODASYL?oldid=64405522 Colaboradores: Oblongo, Moriel, Sms, Mandramas, Rembiapopohyiete (bot), YurikBot, GermanX, CEM-bot, Pinobot, Mister, Fabeirojorge, Flafus, BotMultichill, SieBot, AVBOT, Jkbw, XeMyCo, Legoboty Anónimos: 9

• Modelo jerárquico Fuente: http://es.wikipedia.org/wiki/Modelo%20jer%C3%A1rquico?oldid=80153375 Colaboradores: Pabloab, Rosarina-gazo, Fernandopcg, Jmvkrecords, Muro Bot, Quijav, Shalbat, AVBOT, LucienBOT, Angel GN, Diegusjaimes, Arjuno3, Jkbw, Magomaitin,Sarang, Grillitus, Jarould, Egis57, Fernygaspa y Anónimos: 14

• IMS (IBM) Fuente: http://es.wikipedia.org/wiki/IMS%20(IBM)?oldid=70040728 Colaboradores: Flextron, Cinabrium, Boticario, RobotQuist-nix, Yrbot, Maleiva, Icvav, GermanX, C-3POrao, Eskimbot, Calsbert, Qwertyytrewqqwerty, CEM-bot, Asereware, Locovich, Hanjin, TXiKi-BoT, Guirrohl, Dhidalgo, VolkovBot, Ingteleco, Muro Bot, BotMultichill, PaintBot, BotSottile, DioSiTa, DSisyphBot, Rubinbot, AstaBOTh15,EmausBot, KLBot2, Elvisor, Chevebot y Anónimos: 10

• Data Language/Interface Fuente: http://es.wikipedia.org/wiki/Data%20Language/Interface?oldid=72829380 Colaboradores: Flextron, CEM-bot, 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, Leon-polanco, Juvalen, TiriBOT, Sergio Andres Segovia, KLBot2, Invadibot, Elvisor y Anónimos: 3

6.5.2 Images• Archivo:Database_models.jpg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/3b/Database_models.jpg Licencia:CCBY-SA 3.0Colaboradores: 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 domainColaboradores: 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: Publicdomain 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 Colaborado-res: ? Artista original: ?

• Archivo:Network_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/3e/Network_Model.svg Licencia: Public domainColaboradores: 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: Tra-bajo propio Artista original: User:Gmaxwell

6.5.3 Content license• Creative Commons Attribution-Share Alike 3.0