Tema 1

Principales arquitecturas de bases de
datos
[1.1] ¿Cómo estudiar este tema?
[1.2] Introducción a los gestores de bases de datos
[1.3] Arquitectura de los sistemas de bases de datos
[1.4] Componentes de los SGBD
[1.5] Modelos de bases de datos
[1.6] Ventajas y desventajas de los modelos de bases de datos
[1.7] Repositorios XML
[1.8] Directorios LDAP
[1.9] Referencias bibliográficas

1 TEMA
Esquema
TEMA 1 – Esquema
Principales arquitecturas de bases de datos
Repositorios de Arquitecturas
alm acenamiento de datos
SGBD´s Repositorios Servicios de BD NOSQL

XML directorio
Seguridad en Bases de Datos y Almacenamiento de Datos Masivos
© Universidad Internacional de La Rioja (UNIR)

Ideas clave
1.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave, además de los fragmentos indicados de los
siguientes libros disponibles en la Biblioteca Virtual UNIR:
Cabello, J. M. (2014). Almacenamiento de la información e introducción a SGBD:

administración de bases de datos (UF1468). IC Editorial (páginas 17-23 y 96-125).
Sarasa, A. (2016). Introducción a las bases de datos NoSQL usando Mongo DB.
Editorial UOC (páginas 17-34).
Las aplicaciones en casi todos los casos necesitarán almacenar datos en más o menos
cantidades. Para proporcionar este servicio normalmente se añade otra capa a la
arquitectura de la aplicación web que soporta el servicio de almacén de datos como
puede ser un sistema gestor de bases de datos (SGBD) como Oracle, Sql Server o DB2.
También se pueden utilizar repositorios de datos en formato XML en un fichero
de datos que puede ser accedido por la aplicación o un Directorio LDAP (Lightweight
directory access protocol).
Figura 1. Top 10 de los gestores de bases de datos más populares por DB Engines. Fuente: DB-Engines,
2021.
TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

1.2. Introducción a los gestores de bases de datos
Definimos un sistema gestor de bases de datos o SGBD, también llamado DBMS

(data base management system) como una colección de datos relacionados entre sí,
estructurados y organizados, y un conjunto de programas que acceden y gestionan esos
datos. La colección de esos datos se denomina base de datos o BD (data base o DB).
Antes de aparecer los SGBD (década de los setenta), la información se gestionaba

utilizando los típicos sistemas de gestión de archivos que iban soportados sobre un
sistema operativo. Estos consistían en un conjunto de programas que definían y
trabajaban sus propios datos. Los datos se almacenan en archivos y los programas
manejan esos archivos para obtener la información. Si la estructura de los datos de los
archivos cambia, todos los programas que los manejan se deben modificar. Por
ejemplo, un programa trabaja con un archivo de datos de alumnos, con una estructura
o registro ya definido; si se incorporan elementos o campos a la estructura del archivo,
los programas que utilizan ese archivo se tienen que modificar para tratar esos nuevos
elementos. En estos sistemas de gestión de archivos, la definición de los datos se
encuentra codificada dentro de los programas de aplicación en lugar de almacenarse de
forma independiente. Además, el control del acceso y la manipulación de los datos
viene impuesto por los programas de aplicación.
Esto supone un gran inconveniente a la hora de tratar grandes volúmenes de

información. Surge así la idea de separar los datos contenidos en los archivos de los
programas que los manipulan, es decir, que se pueda modificar la estructura de los
datos de los archivos sin que por ello se tengan que modificar los programas con los que
trabajan. Se trata de estructurar y organizar los datos de forma que se pueda acceder a
ellos con independencia de los programas que los gestionan.
Los inconvenientes de un sistema de gestión de archivos son:
» Redundancia e inconsistencia de los datos: se produce porque los archivos

son creados por distintos programas y van cambiando a lo largo del tiempo, es decir,
pueden tener distintos formatos y los datos pueden estar duplicados en varios sitios.
Por ejemplo, el teléfono de un alumno puede aparecer en más de un archivo. La
redundancia aumenta los costes de almacenamiento y acceso, y trae consigo la
inconsistencia de los datos: las copias de los mismos datos no coinciden por
aparecer en varios archivos.

» Dependencia de los datos física-lógica o, lo que es lo mismo, la estructura

física de los datos (definición de archivos y registros) se encuentra codificada en los
programas de aplicación. Cualquier cambio en esa estructura implica para el
programador identificar, modificar y probar todos los programas que manipulan
esos archivos.
» Dificultad para tener acceso a los datos: proliferación de programas, es decir,

cada vez que se necesite una consulta que no fue prevista en el inicio implica la
necesidad de codificar el programa de aplicación necesario. Lo que se trata de
probar es que los entornos convencionales de procesamiento de archivos no
permiten recuperar los datos necesarios de una forma conveniente y eficiente.
» Separación y aislamiento de los datos: al estar repartidos en varios archivos y

tener diferentes formatos, es difícil escribir nuevos programas que aseguren la
manipulación de los datos correctos. Antes se deberían sincronizar todos los
archivos para que los datos coincidiesen.
» Dificultad para el acceso concurrente: en un sistema de gestión de archivos es

complicado que los usuarios actualicen los datos simultáneamente. Las
actualizaciones concurrentes pueden dar por resultado datos inconsistentes, ya que
se puede acceder a los datos por medio de diversos programas de aplicación.
» Dependencia de la estructura del archivo con el lenguaje de

programación: la estructura se define dentro de los programas. Esto implica que
los formatos de los archivos sean incompatibles. La incompatibilidad entre archivos
generados por distintos lenguajes hace que los datos sean difíciles de procesar.
» Problemas en la seguridad de los datos: resulta difícil implantar restricciones

de seguridad, pues las aplicaciones se van añadiendo al sistema según se necesitan.
» Problemas de integridad de datos: los valores almacenados en los archivos

deben cumplir con restricciones de consistencia. Por ejemplo, no se puede insertar
una nota de un alumno en una asignatura si previamente esa asignatura no está
creada. Otro ejemplo: las unidades en almacén de un producto determinado no
deben ser inferiores a una cantidad. Esto implica añadir un gran número de líneas
de código en los programas. El problema se agrava cuando existen restricciones que
implican varios datos en distintos archivos.

Todos estos inconvenientes hacen posible el fomento y desarrollo del SGBD. El

objetivo primordial de un gestor es proporcionar eficiencia y seguridad a la
hora de extraer o almacenar información en las BD. Los sistemas gestores de
BBDD están diseñados para gestionar grandes bloques de información, que implica
tanto la definición de estructuras para el almacenamiento como de mecanismos para la
gestión de la información. Una BD es un gran almacén de datos que se define una sola
vez; los datos pueden ser accedidos de forma simultánea por varios usuarios, están
relacionados y existe un número mínimo de duplicidad. Además, en las BBDD se
almacenarán las descripciones de esos datos, lo que se llama metadatos en el
diccionario de datos.
El SGBD es una aplicación que permite a los usuarios definir, crear y mantener la BD y
proporciona un acceso controlado a la misma. Debe prestar los siguientes servicios:
» Creación y definición de la BD: especificación de la estructura, el tipo de los

datos, las restricciones y relaciones entre ellos mediante lenguajes de definición de
datos. Toda esta información se almacena en el diccionario de datos; el SGBD
proporcionará mecanismos para la gestión del diccionario de datos.
» Manipulación de los datos realizando consultas, inserciones y actualizaciones de

estos utilizando lenguajes de manipulación de datos.
» Acceso controlado a los datos de la BD mediante mecanismos de seguridad de

acceso a los usuarios.
» Mantener la integridad y consistencia de los datos utilizando mecanismos

para evitar que los datos sean perjudicados por cambios no autorizados.
» Acceso compartido a la BD, controlando la interacción entre usuarios

concurrentes.
» Mecanismos de respaldo y recuperación para restablecer la información en

caso de fallos en el sistema.

1.3. Arquitectura de los sistemas de bases de datos
En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards

Planning and Requirements Committee) propuso una arquitectura de tres niveles para
los SGBD cuyo objetivo principal era el de separar los programas de aplicación de la BD
física. En esta arquitectura el esquema de una BD se define en tres niveles de
abstracción distintos:
» Nivel interno o físico: el más cercano al almacenamiento físico, es decir, tal y

como están almacenados en el ordenador. Describe la estructura física de la BD
mediante un esquema interno. Este esquema se especifica con un modelo físico y
describe los detalles de cómo se almacenan físicamente los datos: los archivos que
contienen la información, su organización, los métodos de acceso a los registros, los
tipos de registros, la longitud, los campos que los componen, etc.
» Nivel externo o de visión: es el más cercano a los usuarios, es decir, es donde se

describen varios esquemas externos o vistas de usuarios. Cada esquema describe la
parte de la BD que interesa a un grupo de usuarios. En este nivel se representa la
visión individual de un usuario o de un grupo de usuarios.
» Nivel conceptual: describe la estructura de toda la BD para un grupo de usuarios

mediante un esquema conceptual. Este esquema describe las entidades, atributos,
relaciones, operaciones de los usuarios y restricciones, ocultando los detalles de las
estructuras físicas de almacenamiento. Representa la información contenida en la
BD.

En la siguiente figura se representan los niveles de abstracción de la arquitectura ANSI.
Figura 2. Niveles de abstracción de la arquitectura ANSI. Fuente: luzemywonka, 2014.
Esta arquitectura describe los datos en tres niveles de abstracción. En realidad, los
únicos datos que existen están a nivel físico almacenados en discos u otros dispositivos.
Los SGBD basados en esta arquitectura permiten que cada grupo de usuarios haga
referencia a su propio esquema externo. El SGBD debe transformar cualquier petición
de usuario (esquema externo) a una petición expresada en términos de esquema
conceptual para, finalmente, ser una petición expresada en el esquema interno que se
procesará sobre la BD almacenada. El proceso de transformar peticiones y resultados
de un nivel a otro se denomina correspondencia o transformación; el SGBD es capaz de
interpretar una solicitud de datos y realiza los siguientes pasos:
» El usuario solicita unos datos y crea una consulta.

» El SGBD verifica y acepta el esquema externo para ese usuario.
» Transforma la solicitud al esquema conceptual.
» Verifica y acepta el esquema conceptual.
» Transforma la solicitud al esquema físico o interno.
» Selecciona la tabla o tablas implicadas en la consulta y ejecuta esta última.
» Transforma del esquema interno al conceptual y del conceptual, al externo.
» Finalmente, el usuario ve los datos solicitados.
Para una BD específica solo hay un esquema interno y uno conceptual, pero puede
haber varios esquemas externos definidos para uno o para varios usuarios. Con la
arquitectura a tres niveles se introduce el concepto de independencia de datos.

Se definen dos tipos de independencia:
» Independencia lógica: la capacidad de modificar el esquema conceptual sin tener

que alterar los esquemas externos ni los programas de aplicación. Se podrá
modificar el esquema conceptual para ampliar la BD o para reducirla. Por ejemplo,
si se elimina una entidad, los esquemas externos que no se refieran a ella no se verán
afectados.
» Independencia física: la capacidad de modificar el esquema interno sin tener que

alterar ni el esquema conceptual ni los externos. Por ejemplo, se pueden reorganizar
los archivos físicos con el fin de mejorar el rendimiento de las operaciones de
consulta o de actualización o se pueden añadir nuevos archivos de datos porque los
que había se han llenado. La independencia física es más fácil de conseguir que la
lógica, pues se refiere a la separación entre las aplicaciones y las estructuras físicas
de almacenamiento.
En los SGBD basados en arquitecturas de varios niveles se hace necesario ampliar el

catálogo o el diccionario de datos para incluir la información sobre cómo establecer las
correspondencias entre las peticiones de los usuarios y los datos, entre los diversos
niveles. El SGBD utiliza una serie de procedimientos adicionales para realizar estas
correspondencias haciendo referencia a la información de correspondencia que se
encuentra en el diccionario. La independencia de los datos se consigue porque al
modificarse el esquema en algún nivel, el esquema del nivel inmediato superior
permanece sin cambios. Solo se modifica la correspondencia entre los dos niveles. No
es preciso modificar los programas de aplicación que hacen referencia al esquema del
nivel superior.
Sin embargo, los dos niveles de correspondencia implican un gasto de recursos durante
la ejecución de una consulta o de un programa, lo que reduce la eficiencia del SGBD.
Por esta razón pocos SGBD han implementado la arquitectura completa.

1.4. Componentes de los SGBD
Los SGBD son paquetes de software muy complejos que deben proporcionar una serie
de servicios que van a permitir almacenar y explotar los datos de forma eficiente. Los
componentes principales son los siguientes:
Lenguaje de los SGBD
Todos los SGBD ofrecen lenguajes e interfaces apropiadas para cada tipo de usuario:
administradores, diseñadores, programadores de aplicaciones y usuarios finales. Los
lenguajes van a permitir al administrador de la BD especificar los datos que componen
la BD, su estructura, las relaciones que existen entre ellos, las reglas de integridad, los
controles de acceso, las características de tipo físico y las vistas externas de los usuarios.
Los lenguajes del SGBD se clasifican en:
» Lenguaje de definición de datos (LDD o DDL): se utiliza para especificar el

esquema de la BD, las vistas de los usuarios y las estructuras de almacenamiento. Es
el que define el esquema conceptual y el esquema interno. Lo utilizan los
diseñadores y los administradores de la BD.
» Lenguaje de manipulación de datos (LMD o DML): se usa para leer y

actualizar los datos de la BD. Es el utilizado por los usuarios para realizar consultas,
inserciones, eliminaciones y modificaciones.
Los hay procedurales, en los que el usuario será normalmente un programador y

especifica las operaciones de acceso a los datos llamando a los procedimientos
necesarios. Estos lenguajes acceden a un registro y lo procesan. Las sentencias de un
LMD procedural están embebidas en un lenguaje de alto nivel llamado anfitrión. Las
BD jerárquicas y en red utilizan estos LMD procedurales.
Los no procedurales son los lenguajes declarativos. En muchos SGBD se pueden

introducir interactivamente instrucciones del LMD desde un terminal, también
pueden ir embebidas en un lenguaje de programación de alto nivel. Estos lenguajes
permiten especificar los datos que se obtienen en una consulta, o los datos por
modificar, mediante sentencias sencillas. Las BD relacionales utilizan lenguajes no
procedurales como SQL (structured query language) o QBE (query by example).

» La mayoría de los SGBD comerciales incluyen lenguajes de cuarta generación

(4GL) que permiten al usuario desarrollar aplicaciones de forma fácil y rápida;
también se les llama herramientas de desarrollo. Ejemplos de esto son las
herramientas del SGBD Oracle: SQL Forms para la generación de formularios de
pantalla y para interactuar con los datos; SQL Reports para generar informes de los
datos contenidos en la BD; lenguaje PL/SQL para crear procedimientos que
interactúen con los datos de la BD.
Diccionario de datos
El diccionario de datos es el lugar donde se deposita información acerca de todos los

datos que forman la BD. Es una guía en la que se describe la BD y los objetos que la
forman. El diccionario contiene las características lógicas de los sitios donde se
almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y
organización. Identifica los procesos donde se emplean los datos y los sitios donde se
necesita el acceso inmediato a la información.
En una BD relacional, el diccionario de datos proporciona información acerca de:
» La estructura lógica y física de la BD.

» Las definiciones de todos los objetos de la BD: tablas, vistas, índices, disparadores,
procedimientos, funciones, etc.
» El espacio asignado y utilizado por los objetos.
» Los valores por defecto de las columnas de las tablas.
» Información acerca de las restricciones de integridad.
» Los privilegios y roles otorgados a los usuarios.
» Auditoría de información, como los accesos a los objetos.
Un diccionario de datos debe cumplir las siguientes características:
» Debe soportar las descripciones de los modelos conceptual, lógico, interno y externo
de la BD.
» Debe estar integrado dentro del SGBD.
» Debe apoyar la transferencia eficiente de información al SGDB. La conexión entre

los modelos interno y externo debe ser realizada en tiempo de ejecución.

» Debe comenzar con la reorganización de versiones de producción de la BD. Además,

debe reflejar los cambios en la descripción de la BD. Cualquier cambio a la
descripción de programas ha de ser reflejado automáticamente en la librería de
descripción de programas con la ayuda del diccionario de datos.
» Debe estar almacenado en un medio de almacenamiento con acceso directo para la

fácil recuperación de información.
Seguridad e integridad de datos
Un SGBD proporciona los siguientes mecanismos para garantizar la seguridad e

integridad de los datos:
» Debe garantizar la protección de los datos contra accesos no autorizados, tanto

intencionados como accidentales. Debe controlar que solo los usuarios autorizados
accedan a la BD.
» Los SGBD ofrecen mecanismos para implantar restricciones de integridad en la BD.

Estas restricciones van a proteger la BD contra daños accidentales. Los valores de los
datos que se almacenan deben satisfacer ciertos tipos de restricciones de
consistencia y reglas de integridad, que especificará el administrador de la BD. El
SGBD puede determinar si se produce una violación de la restricción.
» Proporciona herramientas y mecanismos para la planificación y realización de

copias de seguridad y restauración.
» Debe ser capaz de recuperar la BD llevándola a un estado consistente en caso de

ocurrir algún suceso que la dañe.
» Debe asegurar el acceso concurrente y ofrecer mecanismos para conservar la

consistencia de los datos
En los sistemas de gestión de BBDD actuales existen diferentes categorías de usuarios.

Estas categorías se caracterizan porque cada una de ellas tiene una serie de privilegios o
permisos sobre los objetos que forman la BD.

En los sistemas Oracle las categorías más importantes son:
» Los usuarios de la categoría DBA (database administrator): su función es

precisamente administrar la base y tienen el nivel más alto de privilegios.
» Los usuarios de la categoría RESOURCE: pueden crear sus propios objetos y
tienen acceso a los objetos para los que se les ha concedido permiso.
» Los usuarios del tipo CONNECT: solamente pueden utilizar aquellos objetos
para los que se les ha concedido permiso de acceso.
El DBA tiene una gran responsabilidad, ya que posee el máximo nivel de privilegios.
Será el encargado de crear los usuarios que se conectarán a la BD. En la administración
de una BD siempre hay que procurar que haya el menor número de administradores, si
es posible, una sola persona. El objetivo principal de un DBA es garantizar que la BD
cumple los fines previstos por la organización, lo que incluye una serie de tareas como:
» Instalar SGBD en el sistema informático.

» Crear las BBDD que se vayan a gestionar.
» Crear y mantener el esquema de la BD.
» Crear y mantener las cuentas de usuario de la BD.
» Arrancar y parar SGBD, y cargar las BBDD con las que se ha de trabajar.
» Colaborar con el administrador del SO en las tareas de ubicación, dimensionado y
control de los archivos y espacios de disco ocupados por el SGBD.
» Colaborar en las tareas de formación de usuarios.
» Establecer estándares de uso, políticas de acceso y protocolos de trabajo diario para
los usuarios de la BD.
» Suministrar la información necesaria sobre la BD a los equipos de análisis y
programación de aplicaciones.
A estas se suman tareas de explotación como:
» Vigilar el trabajo diario colaborando en la información y resolución de las dudas de

los usuarios de la BD.
» Controlar en tiempo real los accesos, tasas de uso, cargas en los servidores,
anomalías, etc.
» Llegado el caso, reorganizar la BD.
» Efectuar las copias de seguridad periódicas de la BD.
» Restaurar la BD después de un incidente material a partir de las copias de seguridad.

» Estudiar las auditorías del sistema para detectar anomalías, intentos de violación de
la seguridad, etc.
» Ajustar y optimizar la BD mediante el ajuste de sus parámetros y con ayuda de las
herramientas de monitorización y de las estadísticas del sistema.
En su gestión diaria, el DBA suele utilizar una serie de herramientas de administración

de la BD. Con el paso del tiempo, estas herramientas han adquirido sofisticadas
prestaciones y facilitan en gran medida la realización de trabajos que, hasta no hace
demasiado, requerían de arduos esfuerzos por parte de los administradores.
1.5. Modelos de bases de datos
Un modelo de base de datos es la estructura lógica que adopta la base de datos,

incluyendo las relaciones y limitaciones que determinan cómo se almacenan y
organizan y cómo se accede a los datos. Así mismo, un modelo de base de datos
también define qué tipo de operaciones se pueden realizar con los datos, es decir, cómo
se manipulan, proporcionando también la base sobre la que se diseña el lenguaje de
consultas.
En general, prácticamente todos los modelos de base de datos pueden representarse a

través de un diagrama de base de datos (en esta entrada veremos algunos).
Existen diferentes tipos de modelos de bases de datos, como vamos a ver en los
próximos puntos. Qué modelo elegir para nuestra base de datos dependerá del sistema
de gestión de bases de datos que estemos usando, puesto que este debe ser compatible
con el modelo de datos (lo habitual es que los SGBD estén desarrollados para emplear
un modelo de base de datos en concreto, aunque hay algunos compatibles con múltiples
modelos).
Modelo de base de datos relacional
El modelo de base de datos relacional es uno de los más comunes. Este modelo es
el que emplean las bases de datos relacionales y ordena los datos en tablas (relaciones)
compuestas por columnas y filas.

Cada columna alberga un atributo de la entidad (nombre, dirección, fecha de

nacimiento…); a los atributos de una relación se los llama dominio. Escogiendo un
atributo en concreto o una combinación de varios tenemos una clave primaria, a la que
se puede hacer referencia en otras tablas, en las que será una clave externa.
En cada fila (tupla) se incluyen datos sobre una instancia específica de la entidad (por
ejemplo, un cliente específico).
Además, el modelo también representa el tipo de relaciones entre las tablas, que
pueden ser uno a uno, uno a muchos o muchos a muchos.
A continuación, se presenta la estructura del modelo relacional de base de datos en el

ejemplo:
Figura 3. Esquema modelo base de datos relacional.
Modelo jerárquico
Si vamos a emplear una base datos jerárquica, el modelo de datos que emplearemos
será el jerárquico, que se caracteriza por presentar los datos en una estructura de árbol
invertido, donde cada registro tiene un único nodo raíz del que surgen otros nodos
(registros). Los nodos en un mismo nivel son nodos padre; cada nodo padre tiene el

mismo nodo raíz y puede tener nodos hijos, pero los nodos hijos solo pueden tener un
nodo padre. Este modelo se emplea poco actualmente.
En este modelo, los registros de un mismo nivel se clasifican en un orden específico.

Su estructura se vería como en el siguiente ejemplo:
Figura 4. Esquema modelo base de datos jerárquico.
Modelo de red
El modelo en red de base de datos parte del modelo jerárquico, pero aquí se permiten
las relaciones de uno a muchos o de muchos a muchos entre registros vinculados,
teniendo registros principales múltiples. El modelo se crea a través de conjuntos de
registros relacionados; cada uno de estos conjuntos consiste en un registro propietario
o principal y uno o más registros miembros o secundarios. Además, un registro puede
ser miembro o secundario en diferentes conjuntos. Es decir, que en este modelo se
permite que los nodos hijos tengan más de uno nodo padre, de manera que se pueden
representar relaciones más complejas.

A continuación, se presenta un ejemplo de este modelo de base de datos de red.
Figura 5. Esquema modelo base de datos en red.
Modelo orientado a objetos
El modelo de la base de datos orientada a objetos define la base de datos como una
colección de objetos utilizados en la programación orientada a objetos (es decir,
emplear lenguajes como C++ o Java, por ejemplo). Este modelo de base de datos utiliza
tablas también, pero no solo se limita a ellas y permite almacenar información muy
detallada sobre cada objeto.
Los objetos se dotan de un conjunto de características propias, que a su vez les

diferencian de objetos similares. Los objetos similares pueden agruparse en una clase y
cada objeto de esta es una instancia. Las clases intercambian datos entre sí a través
métodos (mensajes).

Figura 6. Esquema modelo base de datos orientado a objetos.
Modelo relacional de objetos
El modelo relacional de objetos combina en un modelo híbrido el modelo de base de

datos relacional y el orientado a objetos, de manera que funciona de manera similar al
relacional, pero incorpora funciones del modelo orientado a objetos, como los propios
objetos, las clases, la herencia y el poliformismo. Además, permite una mejor
escalabilidad y se pueden almacenar un gran volumen de datos dentro de las clases.
Modelo entidad-relación
El modelo entidad-relación es básicamente el paso previo a uno modelo de bases datos

relacional, puesto que se trata de un diagrama elaborado a través de unos elementos
básicos y su relación entre ellos:
» Entidades: son los objetos que se representan en la base de datos.

» Atributos: son el contenido de la entidad, sus características. A los atributos se les
asigna un clave para distinguirlos de los demás registros.
» Relación: el vínculo que define la dependencia entre varias entidades.
» Cardinalidad: la participación entre entidades, que pueden ser uno a uno, uno a
varios o varios a varios.

En el diagrama las entidades se representan con un rectángulo, las relaciones con un

rombo y los atributos con un óvalo. Lo vemos en un ejemplo:
Figura 7. Esquema modelo base de datos entidad-relación.
Modelo de archivo invertido
El modelo de archivo invertido, también llamado de índice invertido, contiene datos

que se usan como claves en una tabla de consulta. Los valores en la tabla se emplean
como punteros a la localización de cada instancia. Actualmente, se emplea como índice
de las bases modernas de datos, ya que se trata de tablas de consulta en las que se
introduce un contenido mínimo.
Modelo plano
En el modelo de bases de datos plano, los datos se estructuran en dos dimensiones (de
ahí lo de estructura plana). Todos los objetos en una columna concreta tienen valores
del mismo tipo y todos los objetos de la misma fila están relacionados entre ellos.
Por ejemplo, en una base de datos que recoja solo el nombre de usuario y la contraseña,
cada fila recogerá el nombre y la contraseña correspondiente para cada usuario.
Este modelo tabular de base de datos es el precursor del modelo relacional.
Figura 8. Esquema modelo base de datos plano.

Modelo multidimensional
El modelo de base de datos multidimensional está pensado para la creación de

aplicaciones específicas OLAP (procesamiento analítico en línea). Este modelo de base
de datos se puede visualizar como un cubo de datos en el que se representan diferentes
dimensiones de los datos disponibles; las dimensiones de los cubos se corresponden
con la de la tabla y el valor almacenado en cada celda equivale al valor de la métrica.
Este modelo combina el modelo relacional con el jerárquico y permite extraer datos de
forma selectiva y eficaz. Sin embargo, tiene un inconveniente: no se puede modificar su
estructura, lo que obliga a diseñarlos desde cero cuando hay que introducir cambios.
Modelo semiestructurado
Cuando los datos no encajan en el formato de tablas, filas y columnas, sino que se
organizan mediante etiquetas con las que se puede agruparlos y crear jerarquías (como
ocurre con los datos de una página web), estamos hablando de datos
semiestructurados.
Para ordenar estos datos en una base de datos, podemos recurrir al modelo
semiestructurado. En este modelo no hay separación entre los datos y el esquema y
resulta útil para describir sistemas o describir interacciones entre bases de datos que no
se acogen al mismo esquema.
Modelo contexto
El modelo de contexto se puede usar cuando se necesita incorporar elementos de otros

modelos de bases de datos. Puede adoptar elementos de modelos orientados a objetos,
semiestructurados y en red.
Modelo asociativo
En el modelo asociativo los datos se dividen en entidad y asociación, de manera que

una entidad es todo lo que existe de manera independiente y una asociación es algo que
solo existen en relación con algo más. Así, los datos se estructuran en dos grupos.

» Elementos, donde cada uno tiene un identificador único, un nombre y un tipo.
» Enlaces, donde cada uno tiene un identificador único e identificadores únicos de una
fuente, verbo u objeto. La información almacenada está relacionada con la fuente y
cada uno de los tres identificadores pueden hacer referencia a un enlace o a un
elemento.
Modelo de bases de datos NoSQL
Este apartado se estudia con las páginas 17-34 del libro Introducción a las bases de
datos NoSQL usando MongoDB propuesto en la sección ¿Cómo estudiar este tema?
Ya hemos visto un modelo de bases de datos NoSQL, también llamadas bases de datos
no relacionales, el modelo de base de datos orientado a objetos, pero existen otros:
» Modelo de base de datos gráfico, similar al de red, pero más flexible, puesto
que permite que cualquier nodo se pueda conectar a cualquier otro.
» Modelo multivalor, que nace del modelo relacional, pero en el que los atributos
pueden contener una lista de datos en vez de un solo punto de datos.
» Modelo de documentos, empleado para almacenar y administrar documentos o
datos semiestructurados, en vez de datos atómicos (como hacen las bases
relacionales).
Proceso de
SGA Buffer de la Fondo común Buffer de la
usuario base de datos SQL compartido Redo_Log
Proceso de
servidor
CKPT
DBWR LGWR ARCH SMON PMON RECO
Copia de los archivos de

Redo_Log
Archivos de base de datos Archivos de Redo_Log Archivos de control
Figura 9. Esquema modelo base de datos NoSQL.

1.6. Ventajas y desventajas de los modelos de bases de datos
A la hora de hablar de ventajas y desventajas de los modelos de bases de datos, tenemos

que pensar que cada uno de los modelos que hemos visto cuenta con una serie de
beneficios e inconvenientes que debemos tener en cuenta al elegir qué tipo de base de
datos vamos a diseñar y crear. Por ejemplo, puede que para un modelo de base de
datos para un inventario nos interese usar un modelo relacional en lugar de uno no
relacional.
Sin embargo, en lugar de ver cada modelo, vamos a agrupar las ventajas y las
desventajas en torno a modelos de bases de datos SQL (como las relacionales) y
modelos de bases de datos NoSQL (como pueden ser las orientadas a objetos).
Ventajas modelos SQL
» Portabilidad entre plataformas.

» Madurez. Llevan empleándose mucho tiempo y su uso está muy extendido, lo que ha
generado mucha información y herramientas en torno a ellas.
» Atomicidad (si una operación no cumple los criterios para ejecutarse, no se ejecuta).
» Estándares definidos por el lenguaje SQL, lo que crea criterios de uniformidad de la
información.
» Escritura simple que facilita la compresión de las operaciones.
Desventajas del modelo SQL
» Tienen dificultades para crecer cuando aumenta el volumen de los datos que
almacenar.
» Si es necesario introducir cambios en la base de datos, también es necesario
modificar toda la estructura.
» Complejidad en la instalación, ya que estos modelos se ven condicionados por el
sistema operativo en el que deben funcionar.
» Interfaz compleja.
» Se pueden implementar características de forma patentada, que pueden bloquear al
proveedor.

Ventajas modelos NoSQL
» Pueden gestionar y manejar grandes volúmenes de datos, por lo que se puede

utilizar para aplicaciones Big Data.
» Facilita la administración de la base de datos, puesto que cuenta con capacidades de
distribución de datos y reparación automática.
» Son versátiles, puesto que permiten el crecimiento en el volumen de datos, así como
introducir cambios sin necesidad de modificar la estructura.
» Son muy escalables.
» Son económicos gracias a su adaptabilidad y flexibilidad.
Desventajas del modelo SQL
» Poca madurez y uso minoritario.

» Algunos de estos modelos no tienen atomicidad.
» Su uso relativamente reciente tiene como consecuencia la falta de estandarización en
el lenguaje que emplean y una falta de información sobre las herramientas que
utilizan y sus características.
» Muchas de estas bases de datos carecen de interfaz gráfica.
1.7. Repositorios XML
Otro tipo de almacenamiento de la información es XML, acrónimo de eXtensible

Markup Language, traducido como lenguaje de marcado extensible. Es un
metalenguaje que permite definir lenguajes de marcas desarrollado por el World Wide
Web Consortium (W3C), el cual es utilizado para almacenar datos en forma
legible. A diferencia de otros lenguajes, XML da soporte a bases de datos y es
útil cuando varias aplicaciones deben comunicarse entre sí o integrar
información. XML no nació únicamente para su aplicación en Internet, sino que se
volvió el estándar para el intercambio de información estructurada entre
diferentes plataformas.

Historia de XML
Los primeros lenguajes de marcas se idearon a finales de los años sesenta para la
preparación de documentos de texto (William W. Tunnicliffe, 1967). En los años
setenta se crearon varias normas de lenguajes de marcas (GenCode, GML) para su uso
en la industria editorial. En 1986, bajo la dirección de Charles Goldfarb, investigador de
IBM, se creó el SGML (Standard Generalized Markup Language), una norma
extraordinariamente compleja y publicada como norma ISO 8879 en 1986.
En 1989, Tim Berners-Lee se basó en la sintaxis del SGML para crear el HTML, el
lenguaje de marcas de la web. Inicialmente pensada para su uso en el laboratorio
europeo CERN, la web se extendió por todo el planeta de una forma fulminante. Para
tutelar el crecimiento y organización de la web, en 1994 se creó el W3C, un organismo
internacional formado por empresas, instituciones e investigadores. El primer trabajo
del W3C fue normalizar el HTML, incorporando las novedades que aparecían
continuamente en los navegadores. Pese a ello, el crecimiento de la web seguía
aumentado las presiones para ampliar el HTML para todo tipo de usos.
El W3C decidió que la solución no podía ser seguir ampliando el HTML, sino crear
unas reglas generales para que cualquiera pudiera crear lenguajes de marcas adecuados
a sus necesidades, pero manteniendo unas estructuras y sintaxis comunes que
permitieran compatibilizarlos y tratarlos con las mismas herramientas. Ese conjunto de
reglas es el XML, cuya primera versión se publicó en 1998. Así, el XML no es un
lenguaje de marcas, pero sí la base común elegida por el W3C para sus desarrollos
posteriores.
En los primeros años del siglo XXI, el W3C planteó una triple línea de trabajo:
» Desarrollar el XML, creando todo tipo de tecnologías para procesar documentos

XML que pudieran aplicarse a cualquier lenguaje de marcas basado en XML.
» Como el HTML de los años noventa no cumplía las normas del XML, ya que el
primero era anterior, el W3C aprobó en el año 2000 el XHTML, una versión del
HTML que sí que cumplía las reglas del XML y que puso fin al desarrollo del HTML.
» Poner en marcha la iniciativa de la web semántica para dotar de inteligencia a la
web, basándose en el XML.

Veinte años después, este ambicioso plan ha fracasado. Aunque el W3C cumplió su
parte elaborando y aprobando decenas de recomendaciones en esas tres líneas de
trabajo, el mercado no las ha adoptado, especialmente en la web.
Para empezar, los fabricantes de navegadores no aceptaron el XHTML y crearon en

2004 una nueva organización, el WHATWG, para continuar el desarrollo del HTML
que el W3C había abandonado. En 2007 el W3C reconoció su fracaso y retomó el
desarrollo del HTML (incluyendo en él una versión XHTML, basada en XML). En
octubre de 2014 el W3C publicó la recomendación HTML 5, que incluye las dos
variantes: HTML 5, no basada en XML, y XHTML 5, basada en XML (una tercera
variante llamada HTML políglota ha sido abandonada). Desde entonces se han ido
publicando versiones actualizadas del HTML 5, pero realmente el desarrollo del HTML
ya no se hace en el seno del W3C, sino en el WHATWG.
Por otro lado, aunque por unos años el XML se convirtió en la herramienta básica para
el intercambio y almacenamiento de información en muchos sectores de la informática,
poco a poco el mercado ha ido evolucionando en otras direcciones, empleando
tecnologías más sencillas no basadas en el XML.
Para terminar, la iniciativa de la web semántica (aún suponiendo que hubiera

propuesto las tecnologías adecuadas para permitir el procesamiento inteligente de la
información contenida en las páginas web) no ha tenido la menor oportunidad de éxito,
puesto que la web no adoptó ninguno de los componentes de la web semántica.
Reconociendo el fracaso, en 2013 el W3C ya había cerrado prácticamente todos los

grupos de trabajo dedicados a la web semántica y en 2018 el W3C también cerró
prácticamente todos los grupos de trabajo dedicados al XML. Probablemente, el
principal motivo del fracaso sea que el XML, con su exigencia de ausencia de errores en
los documentos, es demasiado estricto para una web que en gran parte todavía se
elabora manualmente.
Aunque la web haya abandonado el XML, este se sigue utilizando en muchos ámbitos
especializados para el almacenamiento y transmisión de la información, por lo que
cuesta creer que su desarrollo en esos ámbitos no sea retomado, dentro o fuera del
W3C, en los próximos años.

Figura 10. Línea del tiempo de la evolución de los lenguajes por marcas.
Tecnologías XML
El éxito de XML ha originado que se demanden nuevas funcionalidades, que se

abordan definiendo extensiones adicionales para estructurar documentos (XML
Schema), enlaces y direccionamiento (XPath, XLink, XPointer), transformación y
presentación (familia XSL, CSS2), consultas (XQuery), programación (DOM, SAX), etc.
El cuadro siguiente muestra algunas de esas tecnologías agrupadas por temas:
Figura 11. Tecnologías XML.

Las tecnologías XML básicas desarrolladas por el W3C son las siguientes:
» XML Namespaces (espacios de nombres XML): define los mecanismos para

permitir que en un mismo documento se puedan utilizar elementos y atributos de
diferentes lenguajes de marcas (resolviendo, por ejemplo, el problemas de que
algunos nombres de elementos coincidan).
» XML Infoset: describe un modelo de datos abstracto para documentos XML a

partir de elementos de información. Se utiliza en las especificaciones de lenguajes
XML para describir restricciones en el lenguaje.
» XPath: permite seleccionar los componentes de un documento XML y facilitar su

acceso a los programas que procesan documentos XML.
» XSLT: lenguaje de transformación de documentos XML a otros formatos (XML o

no XML)
» XSL Formatting Objects (XSL-FO): lenguaje de marcas para formatear

documentos XML que se usa, por ejemplo, para generar archivos PDF.
» XQuery: lenguaje de consulta orientado a XML que permite acceder, manipular y

devolver fragmentos de documentos XML.
» XML Signature: define la sintaxis y las reglas de procesamiento para crear firmas
digitales en documentos XML.
» XML Encryption: define la sintaxis y las reglas de procesamiento para encriptar

documentos XML.
Otras tecnologías XML desarrolladas por el W3C no tuvieron apenas implantación,

como las siguientes:
» XInclude: define el mecanismo para incluir un documento de texto (XML o no

XML) dentro de un documento XML.
» XLink: define métodos para incluir enlaces internos y externos en documentos

XML y asociar metadatos a los enlaces.

» XPointer: define el mecanismo para identificar fragmentos de un documento.
Ventajas de XML
» Es extensible: después de diseñado y puesto en producción, es posible extender XML

con la adición de nuevas etiquetas, de modo que se pueda continuar utilizando sin
complicación alguna.
» El analizador es un componente estándar, no es necesario crear un analizador

específico para cada versión de lenguaje XML. Esto posibilita el empleo de
cualquiera de los analizadores disponibles. De esta manera se evitan bugs y se
acelera el desarrollo de aplicaciones.
» Si un tercero decide usar un documento creado en XML, es sencillo entender su

estructura y procesarla. Mejora la compatibilidad entre aplicaciones. Podemos
comunicar aplicaciones de distintas plataformas, sin que importe el origen de los
datos, es decir, podríamos tener una aplicación en Linux con una base de datos
Postgres y comunicarla con otra aplicación en Windows y base de datos MS-SQL
Server.
» Transformamos datos en información, pues se les añade un significado concreto y

los asociamos a un contexto, con lo cual tenemos flexibilidad para estructurar
documentos.
Estructura de un documento XML
La tecnología XML busca dar solución al problema de expresar información

estructurada de la manera más abstracta y reutilizable posible. Que la información sea
estructurada quiere decir que se compone de partes bien definidas y que esas partes se
componen a su vez de otras. Entonces se tiene un árbol de trozos de información. Por
ejemplo, un tema musical, que se compone de compases que están formados a su vez
por notas. Estas partes se llaman elementos y se señalan mediante etiquetas. Una
etiqueta consiste en una marca hecha en el documento, que señala una porción de este
como un elemento. Un pedazo de información con un sentido claro y definido. Las
etiquetas tienen la forma <nombre>, donde nombre es el nombre del elemento que se
está señalando.

A continuación, se muestra un ejemplo para entender la estructura de un documento

XML:
Figura 12. Ejemplo de estructura XML.
A continuación, se presenta el código del DTD del documento «Edit_Mensaje.dtd», que

define los tipos de datos que aceptara el archivo xml anterior:
Figura 13. Código DTD.

Partes de un documento XML
Un documento XML está formado por el prólogo y por el cuerpo del documento, así
como texto de etiquetas que contiene una gran variedad de efectos positivos o negativos
en la referencia opcional a la que se refiere el documento; hay que tener mucho cuidado
de esa parte de la gramática léxica para que se componga de manera uniforme. Aunque
no es obligatorio, los documentos XML pueden empezar con unas líneas que describen
la versión XML, el tipo de documento y otras cosas.
El prólogo de un documento XML contiene:
» Una declaración XML. Es la sentencia que declara al documento como un

documento XML.
» Una declaración de tipo de documento. Enlaza el documento con su DTD (definición
de tipo de documento) o el DTD puede estar incluido en la propia declaración o
ambas cosas al mismo tiempo. Ejemplo:
<?xml version=“1.0” encoding=“UTF-8”?>
A diferencia del prólogo, el cuerpo no es opcional en un documento XML; el cuerpo

debe contener solo un elemento raíz, característica indispensable también para que el
documento esté bien formado. Sin embargo, es necesaria la adquisición de datos para
su buen funcionamiento. Ejemplo:
<Edit_Mensaje>
(...)
</Edit_Mensaje>
Los elementos pueden tener atributos, que son una manera de incorporar
características o propiedades a los elementos de un documento. Deben ir entre
comillas.
Por ejemplo, un elemento «estudiante» puede tener un atributo «Mario» y un atributo

«tipo», con valores «come croquetas» y «taleno» respectivamente.
<Estudiante Mario="come croquetas" tipo="taleno">Esto es un día que Mario va

paseando…</Estudiante>

Las entidades predefinidas son aquellas que representan caracteres especiales para
que, de esta forma, no sean interpretados como marcado en el procesador XML.
Ejemplo:
entidad predefinida: & carácter: &
Secciones CDATA
Es una construcción en XML para especificar datos utilizando cualquier carácter sin
que se interprete como marcado XML. No confundir con 2(#PCDATA) que es para los
elementos. Permite que caracteres especiales no rompan la estructura. Ejemplo:
<![CDATA[contenido especial: \n áéíóúñ&]]>
Problemas de seguridad en documento XML
Algunos de los problemas de seguridad específicos que los documentos XML pueden
sufrir son:
» XXE, ataques xml external entity, que permiten al atacante la lectura de

archivos arbitrarios en el servidor como SSL private keys o passwords.
» XPATH injection. XPATH es un lenguaje de consultas similar a SQL para
consultas en bases de datos.
» Para prevenir estos problemas es necesario aplicar una adecuada validación de las
cadenas de datos que conforman las peticiones y consultas relacionadas con ficheros
XML.
1.8. Directorios LDAP
Este apartado se estudia con las páginas 116-125 del libro Almacenamiento de la
información e introducción a SGBD: administración de bases de datos (UF1468)
propuesto en la sección ¿Cómo estudiar este tema?
LDAP son las siglas de Protocolo Ligero de Acceso a Directorio o, en inglés,

Lightweight Directory Access Protocol. Se trata de un conjunto de protocolos de
licencia abierta que son utilizados para acceder a la información que está almacenada

de forma centralizada en una red. Este protocolo se utiliza a nivel de aplicación

para acceder a los servicios de directorio remoto.
Un directorio remoto es un conjunto de objetos que están organizados de

forma jerárquica, tales como nombre, claves, direcciones, etc. Estos objetos estarán
disponibles por una serie de clientes conectados mediante una red, normalmente
interna o LAN, y proporcionarán las identidades y permisos para esos usuarios que los
utilicen.
LDAP está basado en el protocolo X.500 para compartir directorios y contiene esta
información de forma jerarquizada y mediante categorías para proporcionar una
estructura intuitiva desde el punto de vista de la gestión por parte de los
administradores. Es, por así decirlo, una guía telefónica, pero con más atributos y
credenciales. En este caso utilizamos el término directorio para referirnos a la
organización de estos objetos.
De forma general, estos directorios se utilizan básicamente para contener información

virtual de usuarios, para que otros usuarios accedan y dispongan de información acerca
de los contactos que están aquí almacenados. Pero es mucho más que esto, ya que es
capaz de comunicarse de forma remota con otros directorios LDAP situados
en servidores que pueden estar en el otro lado del mundo para acceder a la información
disponible. De esta forma se crea una base de datos de información descentralizada y
completamente accesible.
La versión actual se denomina LDAPv3 y se encuentra definida en una hoja de

documentación RFC 4511 accesible de forma pública.
Figura 14. Cliente LDAP-Directorio.

LDAP es un protocolo basado en la conexión entre cliente y servidor. En el

servidor LDAP se almacenarán los datos relativos al directorio, el cual podrá usar una
amplia variedad de bases de datos para este almacenamiento, llegando a ser de grandes
dimensiones.
El funcionamiento de acceso y administración es muy similar a Active Directory de

Windows. Cuando el cliente LDAP se conecta con el servidor, podrá realizar dos
acciones básicas, bien consultar y obtener información del directorio, o bien
modificarla.
» Si un cliente consulta la información, el servidor LDAP puede conectarla

directamente si tienen un directorio alojado en él, o bien redirigir la solicitud hasta
otro servidor que efectivamente tenga esta información. Este podrá ser local o
remoto.
» Si un cliente quiere modificar la información del directorio, el servidor

comprobará si el usuario que está accediendo a este directorio tiene permisos de
administrador o no. Entonces, la información y gestión de un directorio LDAP se
podrá hacer de forma remota.
El puerto de conexión para el protocolo LDAP es el TCP 389, aunque, por

supuesto, se podrá modificar por el usuario y establecerlo en el que desee si así se lo
indica al servidor.
Cómo se almacena la información en LDAP
En un directorio LDAP podremos almacenar básicamente la misma información que en

un directorio activo de Windows. El sistema está basado en la siguiente estructura:
» Entradas, llamadas objetos en Active Directory. Estas entradas son

colecciones de atributos con un nombre distinguido (DN). Este nombre se
utiliza para dar un identificador único e irrepetible a una entrada del directorio. Una
entrada puede ser el nombre de una organización y de ella colgarán unos atributos.
También una persona puede ser una entrada.

» Atributos: los cuales poseen un tipo identificador y los correspondientes valores.

Los tipos se utilizan para identificar los nombres de atributos, por ejemplo: «mail»,
«name», «jpegPhoto», etc. Algunos de los atributos que pertenecen a una entrada
son obligatorios y otros opcionales.
» LDIF: el Formato de Intercambio de Datos de LDAP es la representación en

texto ASCII de las entradas LDAP. Este debe ser el formato de los archivos que se
utilicen para importar información a un directorio LDAP. Cuando se escriba una
línea en blanco, significará el final de una entrada.
[<id>]
dn: <distinguished name>
<attrtype>: <attrvalue>
Árboles: es la organización jerarquizada de entradas. Por ejemplo, en una

estructura de árbol podremos encontrar un país en la parte superior y como principal, y
dentro de este tendremos los distintos estados que conforma el país. Dentro de cada
estado podremos enumerar los distritos, ciudadanos y direcciones donde viven, y así
sucesivamente.
Si aplicáramos esto a Internet y la informática, podríamos organizar un directorio

LDAP mediante un nombre de dominio que haría las funciones de árbol y de él
colgarían los distintos departamentos o unidades organizativas de una empresa,
empleados, etc. Es precisamente de esta forma como actualmente se forman los
directorios, gracias al uso de un servicio DNS, podremos asociar una dirección IP
con un directorio LDAP para poder acceder a él mediante el nombre de dominio.

Un ejemplo de entrada de un directorio de LDAP puede ser:
com
profesionalreview
reviews tutoriales
Jose
Migue
Figura 15. Ejemplo entrada directorio LDAP.
dn: cn=Jose Castillo,dc=profesionalreview,dc=com

cn: Jose Castillo
givenName: Jose
sn: Castillo
telephoneNumber: +34 666 666 666
mail: usuario@profesionalreview.com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
Donde:
» dn (domain name): nombre de entrada, pero no forma parte de la propia entrada.

» dc: componente de dominio para identificar las partes del dominio donde se
almacena el directorio LDAP.
» cn (common name): nombre de atributo para identificar el nombre de usuario,
por ejemplo.
» sn (surname): apellido del usuario.
» telephoneNumber, mail…: identificar nombre para el atributo teléfono y correo
electrónico.
» objectClass: distintas entradas para definir las propiedades de los atributos.

Un servidor LDAP, además de almacenar un árbol, puede contener subárboles que

incluyen entradas específicas del dominio principal. Además, puede almacenar
referencias a otros servidores de directorio para dividir el contenido si es necesario.
Estructura de una URL de acceso en LDAP
Al efectuar conexiones remotas a un servidor LDAP, necesitaremos del uso de

direcciones URL para obtener información de este. La estructura básica:
ldap://servidor:puerto/DN?atributos?ambito?filtros?extensiones
» servidor o host: es la dirección IP o nombre de dominio del servidor LDAP.

» puerto: el puerto de conexión del servidor, por defecto será el 389.
» DN: nombre distinguido para usar en la búsqueda.
» Atributos: es una lista de campos a devolver separados por comas.
» Ámbito o scope: es el ámbito de la búsqueda.
» Filtros: para filtrar la búsqueda según el identificador del objeto, por ejemplo.
» Extensiones: serán las cadenas de caracteres extensiones de la URL en LDAP.
ldap://ldap.profesionalreview.com/cn=Jose%20Castillo,dc=profesionalreview,cd=com
Donde estamos buscando todos los usuarios que haya en la entrada de Jose Castillo en
profesionalreview.com
Herramientas más importantes que utilizan el protocolo LDAP
En la actualidad existen diversas herramientas que utilizan este protocolo para la

comunicación cliente servidor de un servicio de directorio. Lo más relevante es que
incluso Active Directory de Windows utiliza este protocolo de comunicación.
» OpenLDAP: es la implementación libre del protocolo LDAP. Tiene su propia

licencia y es compatible con otros servidores que utilicen el mismo protocolo. Es
utilizado por distintas distribuciones Linux y BSD.
» Active Directory: es un almacén de datos de directorio con licencia Microsoft e

implementado en sus sistemas operativos server desde Windows 2000. Realmente
bajo la estructura de Active Directory se encuentra un esquema LDAPv3, por lo que

también es compatible con otros sistemas que implementen este protocolo en sus
directorios.
» Red Hat Directory Server: es un servidor que también se basa en LDAP similar a
Active Directory, pero mediante una herramienta de código abierto. Dentro de este
directorio podremos almacenar objetos como usuarios claves, grupos, políticas de
permisos, etc.
» Apache Directory Server: otra de las grandes implementaciones que utilizan

LDAP es el directorio con licencia de Apache Software. Además, implementa otros
protocolos como Kerberos y NTP y cuenta con una interfaz de vistas propias de las
bases de datos relacionales.
» Novell Directory Services: este es el servidor de directorio propio de Novell para

gestionar el acceso a un almacén de recursos en uno o varios servidores conectados
en red. Se compone de una estructura de base de datos jerárquica orientada a
objetos en la que se almacenan todos los objetivos típicos de los directorios.
» Open DS: terminamos esta lista con el directorio basado en java de SUN
Microsystems, que posteriormente se liberaría para todos los usuarios. Por
supuesto, está desarrollado en JAVA el necesitaremos el paquete Java Runtime
Environmet para que este funcione.
Los directorios de datos LDAP presentan ventajas en cuanto a instalación,

configuración de seguridad de las conexiones y replicación. En este último apartado hay
que incidir, ya que una arquitectura de directorio LDAP de una empresa se diseña de
tipo distribuida con servidores secundarios en las partes o entidades de la empresa
que hay que mantener con datos actualizados mediante replicación de datos entre el
servidor primario y los secundarios. Es necesario, en este escenario, dotar a las
conexiones de seguridad de tipo TLS. Para autenticar a los usuarios en LDAPv3 se
utiliza el protocolo SASL, simple authorization securtiy layer, que incluye mecanismos
de autenticación como:
» Extermal: si se utiliza TLS se deja que sea este quién se ocupa de la autenticación.
» Digest-MDE5.
» Contraseña en texto claro.
» Anónimo.

El mecanismo de autenticación más deseable de los anteriores sería External

mediante TLS que además aporta el cifrado de la comunicación. Con SASL se puede
proveer integridad y confidencialidad en los datos. El mecanismo de gestión del
servicio de autorización se realiza mediante listas de control de acceso donde se
especifica qué recursos pueden ser accedidos por parte de los usuarios.
Evidentemente, LDAP puede tener ataques a su seguridad. Uno de los problemas

más importantes que puede sufrir LDAP, son ataques de tipo LDAP injection que en
similitud con los ataques de SQL injection consisten en injectar datos en las cadenas de
las consultas de datos para extraer información no permitida, borrarla o insertar datos
igualmente no permitidos. Esto es posible debido a la existencia de una vulnerabilidad
LDAP injection en el código que crea la consulta permitiendo concatenar caracteres que
permiten modificar la consulta original que se pretendía realizar en un principio.
La manera de proteger este problema es la misma que en otros casos anteriormente

expuestos: validación de los datos de entrada, de esta forma, se desechan cadenas
de datos maliciosas que pueden ocasionar de manera sencilla poner fuera de servicio
LDAP, robos de información o el borrado de la misma.
Para validar cadenas de datos de consulta a directorios LDAP, basta con permitir
únicamente los caracteres [a-z][A-Z] [0-9] y escapar o denegar todos los demás.
1.7. Referencias bibliográficas

administración de bases de datos (UF1468). IC Editorial.
Calzada, R. (2016). Introducción al servicio de directorio.

http://www.rediris.es/ldap/doc/ldap-intro.pdf
Cover, R. (s.f.). Extensible Markup Language (XML). Oasis.

http://xml.coverpages.org/xml.html
DB-Engines. (2021). DB-Engines Ranking - Trend Popularity. https://db-

engines.com/en/ranking_trend

Luzemywonka. (6 de mayo de 2014). Arquitectura de un gestor de base de datos.

WordPress. https://luzemywonka.wordpress.com/2014/05/06/areas-de-aplicacion-
de-un-sgbd/
Ramos, M. J., Ramos, A. y Montero, F. (2006). Sistemas gestores de bases de datos.

McGraw Hill.
Sarasa, A. (2016). Introducción a las bases de datos NoSQL usando MongoDB.

Editorial UOC.
W3C. (1998). Extensible Markup Language (XML) 1.0. W3C.

https://www.w3.org/TR/1998/REC-xml-19980210

Material complementario
No dejes de leer…
Tipos de sistemas gestores de bases de datos
Un sistema gestor de bases de datos (SGBD) es un conjunto de programas que

permiten el almacenamiento, modificación y extracción de la información en una base
de datos, además de proporcionar herramientas para añadir, borrar, modificar y
analizar los datos. Los usuarios pueden acceder a la información usando herramientas
específicas de consulta y de generación de informes, o bien mediante aplicaciones al
efecto.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

https://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos#Siste
mas_NoSQL_.282000.29
TEMA 1 – Material complementario © Universidad Internacional de La Rioja (UNIR)

¿Por qué las bases de datos relacionales no sirven para todo?
Hasta ahora el escenario de las bases de datos (BD) ha estado dominado por lo que se
conoce como entornos SQL (lenguaje de consulta estructurado). Estas BD que se suelen
denominar relacionales siguen las reglas llamadas ACID (acrónimo inglés de atomicity,
consistency, isolation, durability). Con estas propiedades las BD garantizan que un
dato sea almacenado de manera inequívoca y con una relación definida sobre una
estructura basada generalmente en tablas que contienen filas y columnas.

http://www.tecnonews.info/opiniones/big_data_4_por_que_las_bases_de_datos_rel
acionales_no_sirven_para_todo
No dejes de ver…
Funciones de un sistema gestor de bases de datos
Concepto y características del modelo de datos entidad-relación.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

https://www.youtube.com/watch?v=G--gVr9eEcA

Sistemas gestores de bases de datos NoSQL
Concepto y características de los sistemas gestores de bases de datos NoSQL.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

https://www.youtube.com/watch?v=RZ66hC2qg6M
A fondo
Bases de datos
Descripción de las bases de datos NoSQL.

https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf

Introducción a LDAP
Descripción y características de los repositorios de datos LDAP.

http://www.rediris.es/ldap/doc/ldap-intro.pdf
Enlaces relacionados
Oracle database
Una de las tecnologías SGBD relacionales más extendidas: Oracle database.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

https://www.oracle.com/es/database/index.html
Open database: MariaDB
Desarrollada por los desarrolladores originales de Mysql.

https://mariadb.org/

MongoDb
Un gestor de datos NoSQL.

https://www.mongodb.com/es
Test: Mysql vs MongoDb
Comparativas entre tecnologías distintas de datos.

http://stackoverflow.com/questions/9702643/mysql-vs-mongodb-1000-reads
http://macool.me/mysql-vs-postgresql-vs-mongodb-velocidad/04
Bibliografía
Ramos, M. J., Ramos, A. y Montero, F. (2006). Sistemas gestores de bases de datos.

McGraw Hill.

administración de bases de datos (UF1468). IC Editorial.
Sarasa, A. (2016). Introducción a las bases de datos NoSQL usando MongoDB.

Editorial UOC.

Test
1. En 1975 el comité ANSI-SPARC (American national standard institute-standards

planningand requirements committe) propuso una arquitectura de tres niveles para los
SGBD cuyo objetivo principal era el de separar los programas de aplicación de la BD
física. En esta arquitectura el esquema de una BD se define en tres niveles de
abstracción distintos:
A. Físico, visión y conceptual.
B. Físico, interno y conceptual.
C. Externo, visión y conceptual.
D. Ninguna de las anteriores.
2. La capacidad de modificar el esquema conceptual sin tener que alterar los esquemas
externos ni los programas de aplicación:
A. Independencia física.
B. Independencia conceptual.
C. Independencia lógica.
3. Se utiliza para especificar el esquema de la BD, las vistas de los usuarios y las
estructuras de almacenamiento. Es el que define el esquema conceptual y el esquema
interno:
A. Lenguajes no proceduales como SQL.
B. Lenguaje de definición de datos (LMD o DML).
C. Lenguaje de definición de datos (LDD o DDL).
D. Lenguajes de cuarta generación (4GL).
4. ¿A partir de qué lenguajes se origina XML?

A. HTML.
B. XHTML.
C. SGML.
D. Ninguna de las anteriores es correcta.
TEMA 1 – Test © Universidad Internacional de La Rioja (UNIR)

5. ¿Mediante qué componente se dispone la información en un documento XML?:

A. Atributos.
B. Elementos.
C. Marcas.
D. DTD.
6. Conjunto de reglas que definen un documento XML:

A. DDT.
B. XHTML.
C. HTML.
D. DTD.
7. LDSP hace uso de un modelo:

A. Lineal.
B. Jerárquico.
C. Relacional.
8. En LDAP las entradas se identifican a través de:

A. ND.
B. Nodos.
C. Marcas.
D. DTD.
9. Los sistemas de datos NoSQL:

A. No tienen un esquema fijo.
B. No usan SQL.
C. Suelen ser open source.
D. Todas las anteriores son ciertas.
10. Una de las ventajas de un SGBD NoSQL es:

A. No usan lenguaje de consultas.
B. Se basan en la existencia de un esquema.
C. No tienen ninguna ventaja especial.
D. Posibilidad de tratar datos a gran escala.
TEMA 1 – Test © Universidad Internacional de La Rioja (UNIR)

Tema 1

Cargado por

Copyright:

Formatos disponibles

Tema 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 1

Cargado por

Copyright:

Formatos disponibles

Principales arquitecturas de bases de

[1.2] Introducción a los gestores de bases de datos

[1.3] Arquitectura de los sistemas de bases de datos

[1.4] Componentes de los SGBD

[1.5] Modelos de bases de datos

[1.6] Ventajas y desventajas de los modelos de bases de datos

[1.7] Repositorios XML

[1.8] Directorios LDAP

[1.9] Referencias bibliográficas

SGBD´s Repositorios Servicios de BD NOSQL

© Universidad Internacional de La Rioja (UNIR)

1.1. ¿Cómo estudiar este tema?

Cabello, J. M. (2014). Almacenamiento de la información e introducción a SGBD:

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

1.2. Introducción a los gestores de bases de datos

Definimos un sistema gestor de bases de datos o SGBD, también llamado DBMS

Antes de aparecer los SGBD (década de los setenta), la información se gestionaba

Esto supone un gran inconveniente a la hora de tratar grandes volúmenes de

Los inconvenientes de un sistema de gestión de archivos son:

» Redundancia e inconsistencia de los datos: se produce porque los archivos

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» Dependencia de los datos física-lógica o, lo que es lo mismo, la estructura

» Dificultad para tener acceso a los datos: proliferación de programas, es decir,

» Separación y aislamiento de los datos: al estar repartidos en varios archivos y

» Dificultad para el acceso concurrente: en un sistema de gestión de archivos es

» Dependencia de la estructura del archivo con el lenguaje de

» Problemas en la seguridad de los datos: resulta difícil implantar restricciones

» Problemas de integridad de datos: los valores almacenados en los archivos

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Todos estos inconvenientes hacen posible el fomento y desarrollo del SGBD. El

» Creación y definición de la BD: especificación de la estructura, el tipo de los

» Manipulación de los datos realizando consultas, inserciones y actualizaciones de

» Acceso controlado a los datos de la BD mediante mecanismos de seguridad de

» Mantener la integridad y consistencia de los datos utilizando mecanismos

» Acceso compartido a la BD, controlando la interacción entre usuarios

» Mecanismos de respaldo y recuperación para restablecer la información en

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

1.3. Arquitectura de los sistemas de bases de datos

En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards

» Nivel interno o físico: el más cercano al almacenamiento físico, es decir, tal y

» Nivel externo o de visión: es el más cercano a los usuarios, es decir, es donde se

» Nivel conceptual: describe la estructura de toda la BD para un grupo de usuarios

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

En la siguiente figura se representan los niveles de abstracción de la arquitectura ANSI.

Figura 2. Niveles de abstracción de la arquitectura ANSI. Fuente: luzemywonka, 2014.

» El usuario solicita unos datos y crea una consulta.

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Se definen dos tipos de independencia:

» Independencia lógica: la capacidad de modificar el esquema conceptual sin tener

» Independencia física: la capacidad de modificar el esquema interno sin tener que

En los SGBD basados en arquitecturas de varios niveles se hace necesario ampliar el

TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

1.4. Componentes de los SGBD

Lenguaje de los SGBD

Los lenguajes del SGBD se clasifican en:

» Lenguaje de definición de datos (LDD o DDL): se utiliza para especificar el

» Lenguaje de manipulación de datos (LMD o DML): se usa para leer y

Los hay procedurales, en los que el usuario será normalmente un programador y

Los no procedurales son los lenguajes declarativos. En muchos SGBD se pueden