BASES DE DATOS

CONFERENCIA #1

TITULO: INTRODUCCIÓN A LAS BASES DE DATOS

Contenido:
1.1- Introducción
1.2- Objetivos de los SGBD (Sistemas de Gestión de Bases de Datos)
1.3- Arquitectura de Bases de Datos
1.4- Modelo conceptual y Modelos de datos
1.5- Lenguajes de bases de datos
1.6- Arquitecturas de aplicaciones

Bibliografía:
 Introducción a los Sistemas de Bases de Datos. C.J. Date. La Habana. 2004. Pág. 2-57.
 Fundamentos de bases de datos. A. Silberschatz, Henry F. Korth and S. Sudarshan.
McGRAW-HILL. Pág. 1-16.

1.1- INTRODUCCIÓN
El término bases de datos fue escuchado por primera vez en un simposio celebrado en
California en 1963.
En una primera aproximación, se puede decir que una base de datos es un conjunto de
información relacionada que se encuentra agrupada o estructurada.
Desde el punto de vista informático, una base de datos es un sistema formado por un
conjunto de datos almacenados en discos, que permiten el acceso directo a ellos y un
conjunto de programas que manipulen ese conjunto de datos.
Por su parte, un Sistema de Gestión de Bases de Datos (SGBD) es un tipo de software muy
específico dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones
que la utilizan; o lo que es lo mismo, una agrupación de programas que sirven para definir,
construir y manipular una base de datos, permitiendo así, almacenar los datos y
posteriormente acceder a estos de forma rápida y estructurada.
Actualmente, las bases de datos están teniendo un impacto decisivo sobre el creciente
uso de las computadoras.
Orígenes
Los orígenes de las bases de datos se remontan a la Antigüedad donde ya existían
bibliotecas y toda clase de registros. Además, también se utilizaban para recoger

1
información sobre las cosechas y censos. Sin embargo, su búsqueda era lenta y poco eficaz
y no se contaba con la ayuda de máquinas que pudiesen reemplazar el trabajo manual.
A la postre, el uso de las bases de datos se desarrolló a partir de las necesidades de
almacenar grandes cantidades de información o datos.
El uso de tarjetas perforadas para almacenamiento de datos se introdujo en 1890, cuando
los datos censales estadounidenses se recopilaron y almacenaron en tarjetas perforadas
por primera vez. La constitución estadounidense requiere que se realice un censo
completo cada 10 años. El censo de 1880 tardó siete años en completarse porque la
población del país aumentó tanto que se anticipó que no habría suficiente tiempo para
completar el censo antes de 1900, cuando comenzaría uno nuevo. La oficina censal
patrocinó una competencia a fin de que se proporcionaran ideas acerca de las formas para
hacer el censo más eficiente. Herman Hollerith, empleado de la
oficina, propuso el uso de tarjetas perforadas para registrar las
respuestas censales de cada hogar y facilitar el procesamiento de las
respuestas. Tales tarjetas ya estaban en uso en la industria de tejido
de seda en Lyon, Francia, para controlar el telar Jacquard, que tejía
patrones en tela de seda. Hollerith diseñó un método con el fin de
usar la misma tecnología para almacenar datos censales y examinar
sus patrones. Ganó la competencia y, debido a su diseño, el censo se
completó en tiempo récord, y se inventó una nueva técnica para el
procesamiento de datos. Después de dicho éxito, el equipo mecánico de tarjetas
perforadas se usó durante muchos años para almacenamiento, ordenación, análisis y
reporte de datos, y las tarjetas perforadas funcionaron como un medio de entrada para
las computadoras, tanto para programas como para datos.
La cinta de papel perforado se usó para almacenar tanto programas de computadora
como datos desde comienzos de la década de 1940, cuando se inventaron las primeras
computadoras electromecánicas y electrónicas. Desde aproximadamente 1950, la cinta
magnética se desarrolló y usó para entrada en las primeras computadoras, incluida la
UNIVAC 1, la primera computadora comercialmente disponible. Los mazos de tarjetas
perforadas, los bucles de cinta de papel perforada o los carretes de cinta magnética se
usaron todos esencialmente en la misma forma, tanto para almacenar programas como
para proporcionar un método de almacenamiento y entrada de datos. Los datos en estos
medios sólo se podían leer en el orden en el que se almacenaban. Este tipo de
procesamiento secuencial de archivos era en extremo eficiente, pero no muy flexible. Por
lo general, la nómina era la primera aplicación que un negocio elegía automatizar, debido
a los complejos cálculos y requerimientos de reporte que eran tediosos para las personas
que los realizaban.
El almacenamiento en disco magnético estuvo disponible hacia finales de la década de
1950, lo que hizo posible el acceso directo (acceso no secuencial) de registros. Los

2
programas ya no requerían que el orden de acceso coincidiera con el orden físico de los
registros. Las actualizaciones se podían hacer al disco, sin rescribir todo el archivo. Durante
la década de 1960 se desarrollaron lenguajes de programación, incluidos COBOL y PL/1,
para procesamiento de datos comercial que usaba datos almacenados tanto en cinta
como en disco. Originalmente, se usaron organizaciones de archivo simples para organizar
datos en estos dispositivos de almacenamiento secundario, pero conforme las
aplicaciones se volvieron más complejas, se necesitaron métodos de almacenamiento y
recuperación de datos más sofisticados. Dos modelos de base de datos competitivas, la
red y la jerárquica, se desarrollaron en esta época. Sin embargo, continuó el uso de los
sistemas de archivos para muchas aplicaciones.
El modelo jerárquico para bases de datos se desarrolló durante la década de 1960, como
una solución ad hoc para las necesidades inmediatas de aplicaciones reales. El sistema de
gestión de base de datos jerárquico más antiguo, el IMS de IBM, se creó con el fin de
organizar y almacenar información necesaria para el programa espacial del proyecto de
alunizaje del Apolo. North American Aviation (que se convirtió en Rockwell) e IBM
trabajaron en conjunto para producir la primera versión de IMS, que se lanzó en 1968. Las
primeras versiones de IMS se diseñaron para utilizarse con dispositivos de cinta
magnética, pero más tarde el disco magnético se convirtió en estándar. IMS pronto se
volvió el sistema de gestión de base de datos jerárquico dominante en el mercado y
durante muchos años fue el más ampliamente usado de todos los DBMS, hasta que lo
sustituyeron los sistemas relacionales. Después de 1968 se hicieron muchas mejoras a IMS,
lo que resultó en nuevas versiones que sacaron ventaja de las mejoras en hardware y
software, y proporcionó nuevas características como comunicaciones de datos y
maximizar el rendimiento. El sistema de reservaciones de la aerolínea SABRE se basó en
IMS.
A principios de la década de 1960, Charles Bachman, en General Electric, creó uno de los
sistemas de gestión de base de datos más antiguo, Integrated Data Store (IDS, almacén
datos), usando un modelo de red. Este sistema de gestión de base de datos influyó el
desarrollo del área de base de datos durante muchos años.
Aunque los modelos jerárquicos y de red eran poderosos y eficientes, eran complejos, y
requerían que los usuarios entendieran las estructuras de datos y las rutas de acceso a los
datos. Estaban diseñados para usarse con programas en lugar de para acceso interactivo
de los usuarios, de modo que no soportaban consultas ad hoc. No estaban basados sobre
un fundamento teórico sólido, sino que eran soluciones construidas sobre sistemas de
archivos existentes.
El modelo relacional fue propuesto por primera vez por E. F. Codd en 1970, en un artículo
llamado “A Relational Model of Data for Large Shared Data Banks”. Fue el primer modelo
que se basó en nociones teóricas de matemáticas, que proporcionó una fuerte base

3
teórica. La investigación sobre el modelo la realizaron Codd y otros en el
IBM Research Laboratory en San José, California. System R, un prototipo
de sistema de gestión de base de datos relacional, lo desarrollaron
investigadores de IBM a finales de la década de 1970. DB2, el sistema de
gestión de base de datos relacional de IBM, se basó en System R. SQL,
un lenguaje desarrollado por System R, se convirtió en el lenguaje de
datos estándar para las bases de datos relacionales, con estándares
aprobados por ANSI (American National Standards Institute) publicados
en 1986, 1989, 1992 y 1999. Otros tempranos proyectos de investigación de modelo
relacional fueron el Peterlee Relational Test Vehicle, creado en el IBM UK Scientific
Laboratory e INGRES, desarrollado en la Universidad de California en Berkeley. La
investigación condujo a una versión “universitaria” de INGRES, así como a un producto
comercial. ORACLE se desarrolló y comercializó usando muchos de los resultados del
System R. El extenso uso de microcomputadoras que comenzó en la década de 1980
condujo a la creación de sistemas de gestión de base de datos basados en PC, que eran
todos relacionales. Entre los primeros sistemas de gestión de bases de datos relacionales
basados en microcomputadora estaban dBase, R:Base, Foxpro, Paradox y Access de
Microsoft. Por otra parte, en la actualidad los sistemas de gestión de bases de datos
empresariales más importantes que usan el modelo relacional, tenemos: Oracle, DB2,
Informix, Sybase, Server SQL de Microsoft y otros DBMS con licencia libre como es el
caso de PostgreSQL, MySQL y Firebird.
El modelo relacional usa tablas simples para organizar datos. No permite a los diseñadores
de bases de datos expresar algunas distinciones importantes cuando modelan una
empresa. En 1976, P. P. Chen desarrolló un nuevo tipo de modelo, el modelo entidad-
relación. Éste es un ejemplo de un modelo semántico que intenta capturar el significado
de los datos que representa. El modelo entidad•relación en sí mismo se ha extendido
muchas veces para hacerlo semánticamente más rico. Otros modelos semánticos para
bases de datos se crearon para intentar capturar más del significado en los datos.
La necesidad de almacenar y manipular datos complejos que no es fácil modelar usando
las simples tablas del modelo relacional, así como la aparición de lenguajes de
programación usando el paradigma orientado a objeto, condujo al desarrollo de bases de
datos orientadas a objeto en la década de 1990. Estas bases de datos se crearon para
manipular los datos requeridos para aplicaciones avanzadas como sistemas de
información geográfica (gis), multimedia, diseño y manufactura asistidos por
computadora (CAD/CAM), y otros entornos complejos. Los sistemas de gestión de base
de datos relacional como Oracle agregan algunas capacidades orientadas a objeto a sus
productos, lo que resulta en bases de datos híbridas objeto-relacional.
Los almacenes de datos se desarrollaron en la década de 1990 para proporcionar un
método de captura de datos consolidado a partir de muchas bases de datos. Un almacén
de datos por lo general guarda datos históricos acerca de una organización, con el
4
propósito de minar datos, un proceso de análisis estadístico de datos que permite a la
organización descubrir las tendencias que puedan estar presentes en sus propios
registros.
El amplio uso de Internet ha tenido un tremendo impacto sobre el desarrollo de las bases
de datos. Internet conecta a los usuarios a una rica red de bases de datos en constante
expansión, y proporciona acceso a bibliotecas digitales, recursos multimedia, recursos
educativos y mucho más. Los sitios de comercio electrónico proporcionan acceso a bases
de datos de información acerca de productos y servicios a clientes a lo largo del mundo.
Los dispositivos computacionales inalámbricos y clientes pequeños como los PDA son
otros desarrollos que permiten a los usuarios conectarse a recursos de base de datos en
formas nuevas y flexibles.

1.2- OBJETIVOS DE LOS SGBD

Existen muchas formas de organizar las bases de datos, pero hay un conjunto de objetivos
generales que deben cumplir todos los SGBD, de modo que faciliten el proceso de diseño
de aplicaciones y que los tratamientos sean más eficientes y rápidos, dando la mayor
flexibilidad posible a los usuarios.
Los objetivos fundamentales de los SGBD son:
a) Independencia lógica y física de los datos
Se refiere a la capacidad de modificar una definición de esquema en un nivel de la
arquitectura sin que esta modificación afecte al nivel inmediatamente superior.
b) Redundancia mínima
Debe ser controlada, de forma que no exista duplicidad innecesaria, y que las
redundancias físicas, convenientes muchas veces a fin de responder a objetivos de
eficiencia, sean tratadas por el mismo sistema, de modo que no puedan producirse
inconsistencias.
c) Acceso concurrente por parte de múltiples usuarios
Las bases de datos pretenden servir al conjunto de la organización manejando los
datos como otro recurso. Por lo tanto, las bases de datos han de atender a múltiples
usuarios y a diferentes aplicaciones. En contraposición a los sistemas de ficheros, en
donde cada fichero atiende a determinada aplicación.
d) Distribución espacial de los datos
Los datos pueden encontrarse en otra habitación, otro edificio e incluso otro país, pero
el usuario no tiene por qué preocuparse de la localización espacial de los datos a los
que accede.

5
e) Integridad de los datos
Se refiere a las medidas de seguridad que impiden que se introduzcan datos erróneos.
Esto puede suceder tanto por motivos físicos (defectos de hardware, actualización
incompleta debido a causas externas), como de operación (introducción de datos
incoherentes).
f) Consultas complejas optimizadas
Permite la rápida ejecución de las mismas.
g) Seguridad de acceso y auditoría
Se refiere al derecho de acceso a los datos contenidos en la base de datos por parte
de personas y organismos.
El sistema de auditoría mantiene el control de acceso a la base de datos, con el objeto
de saber qué o quién realizó una determinada modificación y en qué momento.
h) Respaldo y recuperación
Responde a la capacidad de un sistema de base de datos de recuperar su estado en
un momento previo a la pérdida de los datos.
i) Acceso a través de lenguajes de programación estándar
Se refiere a la posibilidad ya mencionada de acceder a los datos de una base de datos
mediante lenguajes de programación ajenos al sistema de base de datos.
j) Control centralizado
Uno de los objetivos más importantes de los SGBD es garantizar el control centralizado
de la información, permitiendo controlar de manera sistemática y única los datos que
se almacenan en la BD, así como el acceso a ella.
Por lo planteado anteriormente, implica que debe existir una persona o conjunto de
personas que tengan la responsabilidad de los datos operacionales: el administrador
de la BD, el cual se puede considerar parte integrante del SBD.
Entre las tareas del administrador de la BD están:
 decidir el contenido informativo de la BD
 decidir la estructura de almacenamiento y la estrategia de acceso
 garantizar el enlace con los usuarios
 definir los chequeos de autorización y procedimientos de validación
 definir la estrategia de reorganización de las BD para aumentar la eficiencia del
sistema, etc.

1.3- ARQUITECTURA DE BASES DE DATOS

Hay tres características importantes inherentes a los sistemas de bases de datos: la
separación entre los programas de aplicación y los datos, el manejo de múltiples vistas

6
por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base
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 sistemas de bases de datos, que resulta muy útil a la hora de conseguir
estas tres características.
El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación,
de la base de datos física. En esta arquitectura, el esquema de una base de datos se define
en tres niveles de abstracción distintos:
 Nivel Interno: En el nivel interno se describe la estructura física de la base de datos
mediante un esquema interno. Este esquema se especifica mediante un modelo físico
y describe todos los detalles para el almacenamiento de la base de datos, así como los
métodos de acceso.
 Nivel Conceptual: En el nivel conceptual se describe la estructura de toda la base de
datos para una comunidad de usuarios (todos los de una empresa u organización),
mediante un esquema conceptual. Este esquema oculta los detalles de las estructuras
de almacenamiento y se concentra en describir entidades, atributos, relaciones,
operaciones de los usuarios y restricciones. En este nivel se puede utilizar un modelo
conceptual o un modelo lógico para especificar el esquema.
 Nivel Externo: En el nivel externo se describen varios esquemas externos o vistas de
usuario. Cada esquema externo describe la parte de la base de datos que interesa a un
grupo de usuarios determinados y oculta a ese grupo el resto de la base de datos. En
este nivel se puede utilizar un modelo conceptual o un modelo lógico para especificar
los esquemas.

Nivel Externo
...

Los tres niveles de abstracción de datos

7
Hay que destacar que los tres esquemas no son más que descripciones de los mismos
datos, pero con distintos niveles de abstracción. Los únicos datos que existen realmente
están a nivel físico, almacenados en un dispositivo como puede ser un disco. En un SGBD
basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia
exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar
cualquier petición expresada en términos de un esquema externo a una petición
expresada en términos del esquema conceptual, y luego, a una petición en el esquema
interno, que se procesará sobre la base de datos almacenada. Si la petición es de una
obtención (consulta) de datos, será preciso modificar el formato de la información extraída
de la base de datos almacenada, para que coincida con la vista externa del usuario. El
proceso de transformar peticiones y resultados de un nivel a otro se denomina
correspondencia o transformación. Estas correspondencias pueden requerir bastante
tiempo, por lo que algunos SGBD no cuentan con vistas externas.
La arquitectura de tres niveles es útil para explicar el concepto de independencia de datos
que podemos definir como la capacidad para modificar el esquema en un nivel del sistema
sin tener que modificar el esquema del nivel inmediato superior.

1.4- MODELO CONCEPTUAL Y MODELOS DE DATOS

Un modelo conceptual es una conceptualización formal del mundo real (más
precisamente de un dominio específico del mundo real). Para construirlo necesitamos
modelar las cosas u objetos existentes, sus características y sus relaciones.
Para representar un modelo conceptual utilizamos lenguajes de ontologías (lenguajes que
nos permiten representar el conocimiento del mundo o parte de él). Estos lenguajes por
lo general permiten introducir conceptos, propiedades de los conceptos, relaciones entre

8
los conceptos y algunas restricciones adicionales. Típicamente son expresados por medio
de diagramas.
Los Diagramas de Entidad Relación (orientados a Base de Datos Relacionales) y los
Diagramas de Clases de UML (orientados al paradigma de objetos), pueden ser
considerados lenguajes de ontología.
Resumiendo, los modelos conceptuales son:
 Modelos de datos de muy alto nivel.
 Se focalizan en las estructuras.
 Tienen una representación gráfica.
 Permiten realizar representaciones del “mundo real” de forma abstracta.
 El esquema conceptual asociado a un problema debe representar todos los
aspectos del mismo.
 No debe incluir ningún elemento asociado a la implementación del esquema, así
como ningún elemento orientado a la performance de la futura base de datos.
Los modelos de datos aportan la base conceptual para diseñar aplicaciones que hacen un
uso intensivo de datos, así como la base formal para las herramientas y técnicas
empleadas en el desarrollo y uso de sistemas de información.
Bajo la estructura de la base de datos se encuentra el modelo de datos que se define
como: una colección de herramientas conceptuales para describir los datos, las
relaciones, la semántica y las restricciones de consistencia. Para ilustrar el concepto
de un modelo de datos, describimos dos modelos de datos: el modelo entidad-relación y
el modelo relacional.
1. Modelo Entidad-Relación (MER)
El modelo E-R (Entidad-Relación) es un modelo de datos conceptual de alto nivel y
que se suele utilizar bastante en el diseño de bases de datos Relacional. Se basa en
una percepción del mundo real que consiste en un conjunto de objetos básicos
denominados entidades y relaciones entre estos objetos, y se desarrolló para facilitar
el diseño de bases de datos.
El modelo E-R crea un modelo de la realidad que se asimila a la realidad que queremos
modelar, y lo hace de forma que es independiente de la implementación posterior,
ofreciendo un alto nivel de abstracción, y siendo una herramienta gráfica fácil de
comprender.
El resultado del modelado E-R es un diagrama E-R (DER) que representa una
estructura lógica general de la base de datos.
Una entidad es una abstracción de un conjunto de cosas (objetos) del mundo real que
es distinguible de otros objetos, tienen las mismas características (atributos) y están
sujeta a las mismas reglas. Una entidad válida, debe ser significativa para el alcance del
9
análisis, debe tener más de una ocurrencia y cada ocurrencia debe ser ÚNICA e
identificable. Ejemplos de entidad es un conjunto de personas, vehículos,
computadores, oficinas, facturas, créditos, etc.
Atributos: Es una abstracción de las características que poseen todas las instancias u
ocurrencias de una entidad.
Las entidades se describen en una base de datos mediante un conjunto de atributos.
Por ejemplo, los atributos CI y Nombre describen un a Estudiante particular en una
universidad y pueden ser atributos del conjunto de entidades Estudiante.
Análogamente, los atributos Código y Descripción pueden describir una entidad
Asignatura.
Una relación es una asociación entre varias entidades. Por ejemplo, una relación Cursa
asocia un Estudiante con cada Asignatura que cursa. El conjunto de todas las entidades
del mismo tipo, y el conjunto de todas las relaciones del mismo tipo, se denominan
respectivamente conjunto de entidades y conjunto de relaciones.
La estructura lógica general de una base de datos se puede expresar gráficamente
mediante un Diagrama Entidad-Relación (DER), que consta de los componentes
siguientes:
 Rectángulos, que representan conjuntos de entidades.
 Elipses, que representan atributos.
 Rombos, que representan relaciones entre conjuntos de entidades.
 Líneas, que unen los atributos con los conjuntos de entidades y los conjuntos de
entidades con las relaciones.
Cada componente se etiqueta con la entidad o relación que representa.
Como ilustración, considérese parte de una base de datos de un sistema universitario
consistente en Estudiantes y Asignaturas que tienen esos estudiantes. El DER
correspondiente se muestra a continuación:

El DER muestra que hay dos conjuntos de entidades que son: Estudiante y Asignatura,
con sus respectivos atributos y la relación Cursa.
El MER además de representar entidades y relaciones, también es capaz de representar
restricciones que los contenidos de la base de datos deben cumplir. Una restricción
importante es la correspondencia de cardinalidades, que expresa el número de
ocurrencias de una entidad se puede asociar con otra entidad a través de un conjunto
de relaciones.
10
2. Modelo Relacional (MR)
El Modelo Relacional utiliza las tablas para representar los datos y las relaciones entre
ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene un nombre
único. La figura que a continuación se presenta, es un ejemplo de base de datos
relacional consistente en tres tablas: la primera muestra los clientes de un banco, la
segunda, las cuentas, y la tercera, las cuentas que pertenecen a cada cliente.

Ejemplo de Base de datos relacional

La tabla cliente, muestra, por ejemplo, que el cliente cuyo identificador es 19.283.746
se llama González y vive en la calle Arenal sita en La Granja. La segunda tabla, cuenta,
muestra que las cuentas C-101 tienen un saldo de 500 € y la C-201 un saldo de 900 €
respectivamente.
La tercera tabla impositor, muestra las cuentas que pertenecen a cada cliente. Por
ejemplo, la cuenta C-101 pertenece al cliente cuyo identificador es 19.283.746
(González), y los clientes 19.283.746 (González) y 01.928.374 (Gómez) comparten el
número de cuenta A-201 (pueden compartir un negocio).
3. Otros modelos de datos
El modelo de datos orientado a objetos es otro modelo de datos que está recibiendo
una atención creciente y se puede observar como una extensión del MER con las
nociones de encapsulación, métodos (funciones) e identidad de objeto.
El modelo de datos relacional orientado a objetos combina las características del
modelo de datos orientado a objetos y el modelo de datos relacional.
Los modelos de datos semiestructurados permiten la especificación de datos donde
los elementos de datos individuales del mismo tipo pueden tener diferentes conjuntos
de atributos. Esto es diferente de los modelos de datos mencionados anteriormente,
en los que cada elemento de datos de un tipo particular debe tener el mismo conjunto
11
 de atributos. El lenguaje de marcas extensible (XML, eXtensible Markup Language)
se usa ampliamente para representar datos semiestructurados.
Históricamente, otros dos modelos de datos, el modelo de datos de red y el modelo
de datos jerárquico, precedieron al modelo de datos relacional. Estos modelos
estuvieron ligados fuertemente a la implementación subyacente y complicaban la tarea
del modelado de datos. Como resultado se usan muy poco actualmente.

1.5- LENGUAJES DE BASES DE DATOS

Un sistema de gestión de bases de datos proporciona un lenguaje de definición de datos
para especificar el esquema de la base de datos y un lenguaje de manipulación de datos
para expresar las consultas a la base de datos y las modificaciones. En la práctica, los
lenguajes de definición y manipulación de datos no son dos lenguajes separados; en su
lugar simplemente forman partes de un único lenguaje de bases de datos, tal como SQL.
1. Lenguaje de Definición de Datos (LDD)
Un esquema de base de datos se especifica mediante un conjunto de definiciones
expresadas mediante un lenguaje especial llamado lenguaje de definición de datos
(LDD).
Por ejemplo, la siguiente instrucción en el lenguaje SQL define la tabla cuenta:
create table cuenta (número-cuenta char(10), saldo integer)
La ejecución de la instrucción LDD anterior crea la tabla cuenta. Además, actualiza un
conjunto especial de tablas denominado diccionario de datos o directorio de datos.
Un diccionario de datos contiene metadatos, es decir, datos acerca de los datos. El
esquema de una tabla es un ejemplo de metadatos. Un sistema de base de datos
consulta el diccionario de datos antes de leer o modificar los datos reales.
Los LDD nos permiten también satisfacer ciertas restricciones de consistencia en
cuanto a los datos almacenados. Por ejemplo, supóngase que el saldo de una cuenta
no debe caer por debajo de 100 €. En este caso se comprueban estas restricciones
cada vez que se actualiza la base de datos.
2. Lenguaje de Manipulación de Datos (LMD)
La manipulación de datos es:
 La recuperación de información almacenada en la base de datos.
 La inserción de información nueva en la base de datos.
 El borrado de información de la base de datos.
 La modificación de información almacenada en la base de datos.

12
 Un lenguaje de Manipulación de Datos (LMD) es un lenguaje que permite a los
usuarios acceder o manipular los datos organizados mediante el modelo de datos
apropiado. Hay dos tipos básicamente:
 LMD procedimentales. Requieren que el usuario especifique qué datos se
necesitan y cómo obtener esos datos.
 LMD declarativos (también conocidos como LMD no procedimentales).
Requieren que el usuario especifique qué datos se necesitan sin especificar cómo
obtener esos datos.

1.6- ARQUITECTURAS DE APLICACIONES

La mayoría de los usuarios de un sistema de bases de datos no están situados junto al
sistema de bases de datos, sino que se conectan a él a través de una red. Por tanto, se
puede diferenciar claramente entre las máquinas cliente, en donde trabajan los usuarios
remotos de la base de datos, y las máquinas servidor, en las que se ejecuta el sistema de
bases de datos.
Las aplicaciones de bases de datos se dividen usualmente en dos o tres partes, como se
ilustra en la Figura.

En una arquitectura de dos capas, la aplicación se divide en un componente que reside

en la máquina cliente, que llama a la funcionalidad del sistema de bases de datos en la
máquina servidor mediante instrucciones del lenguaje de consultas. Los estándares de
interfaces de programas de aplicación como ODBC y JDBC se usan para la interacción
entre el cliente y el servidor.
En cambio, en una arquitectura de tres capas, la máquina cliente actúa simplemente
como frontal y no contiene ninguna llamada directa a la BD. En su lugar, el cliente se
comunica con un servidor de aplicaciones, usualmente mediante una interfaz de
formularios. El servidor de aplicaciones, a su vez, se comunica con el SBD para acceder a
los datos. La lógica de negocio de la aplicación, que establece las acciones a realizar bajo
determinadas condiciones, se incorpora en el servidor de aplicaciones, en lugar de ser

13
distribuida a múltiples clientes. Las aplicaciones de tres capas son más apropiadas para
grandes aplicaciones, y para las aplicaciones Web.

14