DAM MP02 Bases de Datos

Ciclos Formativos de Grado
Superior en Desarrollo de
Aplicaciones Web y Desarrollo
de Aplicaciones Multiplataforma
Bases de datos
Quedan rigurosamente prohibidas, sin la autorización escrita
de los titulares de «Copyright», bajo las sanciones establecidas
en las leyes, la reproducción total o parcial de esta obra por
cualquier medio o procedimiento, comprendidos la reprografía
y el tratamiento informático, y la distribución de ejemplares de
ella mediante alquiler o préstamo públicos. Diríjase a CEDRO
(Centro Español de Derechos Reprográficos, http://www.cedro.org)
si necesita fotocopiar o escanear algún fragmento de esta obra.
INICIATIVA Y COORDINACIÓN
IFP Innovación en Formación Profesional
Supervisión editorial y metodológica:
Departamento de Producto de Planeta Formación
Supervisión técnica y pedagógica:
Departamento de Enseñanza de IFP Innovación en Formación Profesional
Módulo: Bases de datos / Desarrollo de aplicaciones web
© Planeta DeAgostini Formación, S.L.U.

Barcelona (España), 2017
INTRODUCCIÓN AL MÓDULO
En este módulo desarrollaremos las habilidades necesarias para estructurar, crear

y administrar bases de datos. Aprenderemos a utilizar las herramientas necesa-
rias para poder conceptuar situaciones de la vida real, de manera que podamos
crear bases de datos que se adapten a nuestras necesidades. Analizaremos todos
aquellos recursos necesarios para poder almacenar la información de manera es-
tructurada. Conoceremos los diferentes tipos de bases de datos y las característi-
cas de cada una.
Conoceremos también todos los aspectos relacionados con las bases de datos
relacionales, actualmente el sistema más utilizado para la representación de los
datos. Veremos, además, cómo se relacionan las diferentes tablas que conforman
una base de datos y cómo deben utilizarse los lenguajes de descripción de datos
para poder crear la estructura de la base de datos.
Estudiaremos las consultas de las bases de datos y aprenderemos a utilizarlas para

obtener la información de nuestra base de datos. Nos familiarizaremos también
con la utilización de los sistemas gestores de bases de datos.
Otro aspecto importante es cómo manipular la información de nuestra base

de datos, por lo que aprenderemos a insertar y modificar la información, y cono-
ceremos los problemas de acceso que pueden surgir cuando intervienen diferen-
tes usuarios al mismo tiempo.
3
uNIDAD FORMATIVA 1
• Almacenamiento de la información
• Base de datos relacionales

Almacenamiento de la información
1. ALMACENAMIENTO DE LA INFORMACIÓN
En esta unidad estudiaremos lo que son las bases de datos y profundizaremos en

los aspectos más básicos, como el funcionamiento interno, los tipos de bases de
datos existentes, así como cuáles son los componentes y conceptos más impor-
tantes sobre el almacenamiento de la información.
Veremos también cuándo es importante almacenar la información en bases de

datos, y analizaremos los tipos de gestores de bases de datos que tenemos actual-
mente disponibles para la administración de estos sistemas.
1.1 Ficheros
Los archivos o ficheros de datos son colecciones de registros con una temática
común que están organizados para un propósito específico. Según cómo se or-
ganizan dichos registros de datos, y cómo se realiza el posterior acceso a ellos, los
ficheros pueden recibir distintos nombres:
●● Ficheros planos. Aquellos que almacenan los registros de datos en formato de

texto plano (ASCII), es decir, uno a continuación del otro, y utilizan un carácter
especial para separarlos. El acceso a los registros se realiza de forma secuencial
porque el programa debe leer, uno a uno, todos los registros que se encuentran
almacenados antes del que se desea consultar para poder llegar a él.
●● Ficheros indexados. Aquellos que asignan un índice o clave a los registros y

almacenan una tabla asociando dichas claves a la ruta para localizar los registros.
Gracias a este sistema, el acceso a los registros puede agilizarse indicando el
índice concreto del registro a consultar.
●● Ficheros relativos. Aquellos en los que la propia clave asignada a cada registro
mantiene una estrecha relación con la localización del mismo. Dentro de este
grupo se encuentran los de acceso directo, por ejemplo, aquellos que alma-
cenan los registros de datos en posiciones específicas de memoria y utilizan los
números de dichas direcciones de memoria como clave inequívoca para acce-
der a ellos.
Podríamos imaginar los ficheros planos, o secuenciales, como una pila de fichas
de registro, los ficheros indexados como archivos con clasificadores y los ficheros
relativos, o de acceso directo, como documentos con un identificador único co-
rrespondiente a su posición, como podría ser el número de página (Figura 1.1).
7
Bases de datos – Unidad Formativa 1
Figura 1.1
Símil de los tipos de archivo en
función de su organización.
1.2 Bases de datos
Para saber más Las bases de datos son colecciones de ficheros de datos relacionados entre sí a
los que pueden acceder varios usuarios y aplicaciones a la vez. Los conjuntos de
Antes de aparecer programas que acceden y gestionan esos datos son los llamados sistemas ges-
los SGBD (Sistemas
tores de bases de datos (SGBD). Estos conceptos surgen principalmente con el
de Gestión de Bases
de Datos) en la objetivo de poder modificar las estructuras de datos de los ficheros sin tener que
década de 1970, toda realizar cambios en los programas que utilizan dichos datos. Para independizar los
la información se programas o aplicaciones de la estructura de datos con la que trabajan se utilizan
gestionaba mediante representaciones a través de distintos niveles de abstracción: nivel físico, nivel
los sistemas de ficheros lógico o conceptual, y nivel externo o de vistas (Figura 1.2).
soportados sobre un
sistema operativo.
Figura 1.2
Niveles de abstracción de la
arquitectura ANSI.
Los datos almacenados en una base de datos se guardan en disco en forma de

información relacionada. Estos datos pueden representarse conceptualmente en
forma de tablas, en las que cada fila es un objeto y cada columna un atributo de
dicho objeto. En cuanto a las vistas, éstas son un recurso muy común de las bases
de datos para poder visualizar diferentes tablas en una única tabla que mantiene
el formato de filas y columnas (Figura 1.3).
8
Figura 1.3
La tabla Ver (en el centro) es una
conjunción de columnas que
provienen de diferentes tablas.
Los modelos de datos son las herramientas conceptuales que sirven para descri-
bir de forma abstracta la estructura de una base de datos (los datos, las relaciones
y las restricciones que existen entre ellos). Se dividen en tres grupos:
●● Modelos lógicos basados en objetos. Se utilizan para describir datos en el ni-

vel conceptual y externo. Los más conocidos son el modelo entidad-relación y el
orientado a objetos. El modelo entidad-relación consiste en la elaboración de un
diagrama que representa el modelado de los datos en un sistema de información.
El modelo orientado a objetos pretende representar el paradigma de la programa-
ción orientada a objetos en la que los elementos a almacenar en la base de datos
adquieren características y propiedades parecidas a elementos de la vida real.
●● Modelos lógicos basados en registros. Se utilizan para describir datos en el nivel

conceptual y físico. Los más aceptados son los modelos relacional, de red y jerár-
quico. El modelo relacional es el más utilizado en la actualidad para la creación de
bases de datos. Consiste en una estructuración de los datos de manera que todos
Para saber más
estén relacionados entre sí y agrupados en tuplas a las que se añade la información Fue en 1975 cuando
en forma de registros. El sistema jerárquico consiste en el almacenamiento de los el comité ANSI-SPARC
(American National
datos en forma de árbol, es decir, se parte de un nodo padre al que se añade el
Standard Institute –
resto de los datos. A la información almacenada se accede mediante la localización Standards Planning
padre-hijo, partiendo del nodo padre. El inconveniente de este sistema es que no Requirements Committee)
permite el control en la duplicidad de los datos. También la integridad referencial propuso la arquitectura
puede estar condicionada, al poder eliminarse un nodo padre del que dependen de tres niveles con el
otros datos. El modelo de red también utiliza las referencias a otros nodos padre objetivo de separar los
para construir los registros almacenados. La diferencia con el modelo jerárquico, es programas de aplicación
que un nodo puede tener más de un padre, haciéndolo más flexible. de la base de datos física.
9
Recuerda ●● Modelos físicos de datos. Se utilizan para describir cómo se almacenan los
datos. Los más conocidos son el modelo unificador y el de memoria de ele-
Los SGBD (Sistemas de mentos. Funcionan al más bajo nivel para representar la manera en la que se
Gestión de Bases de
almacenan los datos en el sistema.
Datos) o DBMS (Data
Base Management
Systems) son el conjunto
de programas que 1.3 Sistemas gestores de bases de datos
acceden a las bases de
datos y las gestionan. Las principales funciones de los sistemas gestores de bases de datos (SGBD),
Gracias a ellos, los datos también llamados DBMS (Data Base Management Systems), son definir, construir,
se pueden estructurar, manipular y controlar bases de datos (Figura 1.4).
organizar y manipular
de forma independiente
con respecto a los
programas que los
gestionan.
Figura 1.4
Estructura de un SGBD.
Para proporcionar estos servicios, los SGBD constan de varios componentes. Vea-
mos a continuación cuáles son:
●● El diccionario de datos es el lugar donde se almacena información acerca de

todos los datos que forman la base de datos. Cuando se crea y define una base
de datos se deposita en ella la especificación de la estructura, el tipo de datos, las
restricciones, las relaciones, etc.
●● Para definir las características de una base de datos y trabajar con sus datos, se
utilizan los lenguajes de los SGBD. El lenguaje de definición de datos (LDD o
DDL) lo emplean los diseñadores y administradores de la base de datos para
especificar las características propias de ella. El lenguaje de manipulación de
10
datos (LMD o DML) es el que emplean todos los usuarios para consultar y ac-
tualizar los datos de la base de datos. En este lenguaje, existen los LMD proce-
dimentales, en los que el usuario debe especificar los datos que quiere y cómo
acceder a ellos, y los LMD no procedimentales, en los que el usuario indica
directamente los datos que necesita sin especificar cómo obtenerlos. Un ejem-
plo de DDL sería la creación de una tabla nueva en nuestra base de datos, que
normalmente realiza el administrador:
CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,

PRIMARY KEY (a), KEY(b))
TYPE=MyISAM SELECT b,c FROM test2;
Por otro lado, una consulta para obtener un dato concreto sería:
SELECT persona FROM empresa WHERE sueldo>1000;
●● Los mecanismos para garantizar la seguridad e integridad de los datos sirven

para controlar que sólo los usuarios autorizados puedan acceder a la base de da-
tos, para que se realicen copias de seguridad, pueda accederse con facilidad a los
datos sin perder su consistencia, etc.
●● El administrador de la base de datos es la persona que posee el máximo nivel de

privilegios o permisos sobre ella. Sus funciones son instalar el SGBD en el sistema
informático; crear y administrar las bases de datos; establecer las políticas de acce-
so de los usuarios, etc.
1.4 Sistemas gestores de bases de datos comerciales y libres
Actualmente, existe en el mercado una gran variedad de sistemas gestores de ba-

ses de datos tanto libres como comerciales. Los administradores eligen un sistema
u otro según el tamaño de la base de datos con la que se va a trabajar, el nivel de
seguridad necesario, la concurrencia que se va a soportar, la velocidad y eficiencia
requeridas, la simplicidad en el uso de la interfaz, el presupuesto para el proyecto,
etc. En el cuadro de la figura 1.5 se muestran cuáles son los SGBD más utilizados.
Comerciales Libres
• Oracle • PostgreSQL Figura 1.5
• Microsoft SQL Server • MySQL Los SGBD comerciales y libres
• IM DB2 • FireBird
• Microsoft Access • SQLite que gozan hoy en día de mayor
• RazorSQL popularidad.
11
En cuanto a Microsoft Access, más que un SGDB es una interfaz que permite acceder
Recuerda a las bases de datos creadas desde el propio programa de Microsoft. Si bien es cierto
Se entiende por que es posible acceder a otras bases de datos mediante conexiones ODBC (Open
software libre todo DataBase Connectivity) o Conexión Abierta de Base de Datos, la verdad es que
aquel que da plena Microsoft Access tiene grandes limitaciones a la hora del tratamiento de datos.
libertad a los usuarios
para ejecutarlo,
Por lo que respecta a SQLite, se trata de un SGDB de bajo consumo que permite
copiarlo, distribuirlo
y modificarlo. Aunque obtener datos con menos recursos. Por ello, es el que está siendo más utilizado en
los sistemas de el desarrollo de aplicaciones móviles, donde es necesario realizar procesos que no
software libre suelen consuman muchos recursos.
ser gratuitos, no es
obligatorio que sea así.
1.5 Bases de datos centralizadas y bases de datos distribuidas.
Fragmentación
Según todos los componentes de una base de datos se hallen ubicados en una
misma máquina o bien distribuidos en distintos ordenadores de una red, las bases
de datos se clasifican en centralizadas o distribuidas. Antiguamente, la mayoría
de los sistemas de información era de carácter centralizado; sin embargo, en la
actualidad, debido al aumento de la capacidad de las redes de comunicación y a
la globalización de las empresas, resulta cada vez más interesante tener los datos
repartidos entre los distintos sitios desde donde se gestionan (Figura 1.6).
Figura 1.6
Ejemplo de base de datos
distribuida.
12
Cuando los datos se encuentran distribuidos entre diversos puntos, la relación

global entre ellos queda fragmentada en diferentes partes. A este tipo de descom-
posición se le llama fragmentación y puede ser de distintas formas: horizontal,
vertical o mixta. En rasgos generales, si imaginamos la base de datos como
una única tabla con filas de registros y columnas con sus distintos campos, en
una fragmentación horizontal distribuiríamos filas; en una vertical, columnas; y,
en una mixta, estableceríamos un criterio para hacer un híbrido entre una y otra
solución (Figura 1.7).
Figura 1.7
Ejemplo de representación
gráfica de la fragmentación de
una tabla.
Para que la estructura física de una base de datos resulte transparente al usuario, el
administrador deberá escoger un SGBD que soporte la distribución.
13
Resumen
La información es almacenada, en los ordenadores, en ficheros que podemos dividir según su forma-
to. Cada uno de estos formatos tiene un programa asociado que es el encargado de ejecutar y realizar
la lectura de los ficheros.
A diferencia de los sistemas de ficheros que están divididos por unidades de información y están re-
presentados por diferentes formatos, las bases de datos están constituidas por niveles de abstracción.
En una base de datos la información almacenada está relacionada entre sí para facilitar su localiza-
ción. Dicha información está representada conceptualmente en forma de tabla, en la que las filas
representan los registros almacenados y las columnas cada uno de los atributos del registro. Si de-
seamos almacenar los usuarios de una web en una tabla, cada persona será un registro, es decir una
fila, mientras que sus datos, como el correo, el nombre, la contraseña, etc., se almacenarán en cada
una de las columnas.
Los SGDB, son los programas que se comunican con las bases de datos y proporcionan una interface
para el usuario y el administrador con el fin de permitirles la administración de las bases de datos de
una manera sencilla y visual, y sin la necesidad de tener conocimientos de programación para llevar
a cabo las consultas.
Las bases de datos distribuidas están basadas en la separación de los datos en diferentes servidores
con el fin de proporcionar un acceso simultáneo a los diferentes datos sin saturar un mismo canal.
Debido a sus múltiples ventajas con respecto a las bases de datos centralizadas, cada vez son más
utilizadas en la actualidad.
14
Ejercicios de autocomprobación
Indica si las siguientes afirmaciones son verdaderas (V) o falsas (F):
1. Los archivos o ficheros de datos son colecciones de registros con una temática
común que están organizados para un propósito específico.
2. Las bases de datos son colecciones de ficheros de datos que no están relacio-
nados entre sí a los que pueden acceder varios usuarios y aplicaciones a la vez.
3. Los modelos de datos son las herramientas conceptuales que sirven para des-
cribir de forma clara y definida la estructura de una base de datos (los datos, las
relaciones y las restricciones que existen entre ellos).
4. Los modelos físicos de datos se utilizan para describir cómo se almacenan los
datos. Los más conocidos son el modelo unificador y el de memoria de elementos.
5. El lenguaje de definición de datos (LDD o DDL) lo emplean los diseñadores y

administradores de la base de datos para especificar las características propias
de ella.
6. Por lo que respecta a SQLite, se trata de un SGDB de alto consumo que permite
obtener datos con menos recursos.
7. Para que la estructura física de una base de datos resulte transparente al usuario,
el administrador deberá escoger un SGBD que soporte la distribución.
Completa las siguientes afirmaciones:
8. Los datos almacenados en una base de datos se guardan en ______________

en forma de información relacionada. Estos datos pueden representarse con-
ceptualmente en forma de ______________ , en las que cada fila es un objeto
y cada columna un ______________ de dicho objeto.
9. El administrador de la base de datos es la persona que posee el ______________

nivel de privilegios o permisos sobre ella. Sus funciones son ______________
el SGBD en el sistema informático; crear y ______________ las bases de datos;
establecer las políticas de acceso de los ______________, etc.
15
Bases de datos
10. Los modelos lógicos basados en objetos se utilizan para describir datos en el
nivel ______________ y ______________ . Los más conocidos son el modelo
entidad-relación y el orientado ______________ .
Las soluciones a los ejercicios de autocomprobación se encuentran al final de esta Unidad

Formativa. En caso de que no los hayas contestado correctamente, repasa la parte de la lec-
ción correspondiente.
16
Base de datos relacionales
2. BASE DE DATOS RELACIONALES
A lo largo de esta unidad estudiaremos los conceptos básicos de una base de da-
tos relacional. Aprenderemos en qué consiste el modelo relacional y conoceremos
su terminología más frecuente.
El modelo relacional de una base de datos fue introducido en 1970 por el

informático inglés Edgar Frank Codd, en los laboratorios IBM, en San José (Cali-
fornia), y no tardó en consolidarse como un nuevo paradigma en los modelos
de bases de datos. Se trata de una estructura de datos simples y uniformes (la
relación), es decir, de una nueva forma de estructurar y procesar una base de
datos, en la que el lugar y el modo en como se almacenen los datos no tienen
relevancia.
La ventaja del modelo relacional es que los datos se almacenan, al menos concep-
tualmente, de una manera que a los usuarios les resulta más fácil de entender y uti-
lizar. Los datos se almacenan como tablas, lo que permite establecer interconexio-
nes (relaciones) entre los datos de las distintas tablas de una forma muy versátil
y sencilla y, a través de dichas conexiones, relacionar los datos de ambas tablas,
motivo por el cual se le conoce con el nombre de modelo relacional. Durante su
diseño, una base de datos relacional pasa por un proceso llamado normalización
de una base de datos.
2.1 Modelo de datos
El modelo de datos es un lenguaje orientado a describir una base de datos (Figu-

ra 2.1). Un modelo de datos permite describir:
●● Estructuras de datos. Son los tipos de datos contenidos en la base y la forma en

que éstos se relacionan.
●● Restricciones de integridad. Son las condiciones que los datos deben cumplir
para reflejar correctamente la realidad deseada.
●● Operaciones de manipulación. Son aquellas operaciones de agregado, borra-

do, modificación y recuperación de los datos de la base.
En la figura 2.1 puede verse claramente la estructura que sigue la base de datos
que representa, es decir, las relaciones que existen entre las diferentes tablas,
mediante sus correspondientes flechas, así como las llaves que indican qué atri-
17
butos son claves primarias de la tabla. Si nos fijamos, veremos que al lado de
cada atributo está el tipo de dato que almacena (enteros, caracteres, boleanos,
fechas, etc.), lo que nos ayudará a la hora de saber qué datos debemos introducir
en la base de datos.
Figura 2.1
Ejemplo de modelo de datos.
La clasificación de los modelos de datos se realiza según el nivel de abstracción

que presentan:
●● Conceptuales. Son los que describen las estructuras de los datos y sus restriccio-
nes de integridad. Se utilizan en la etapa de análisis, y representan los elementos
que intervienen y sus relaciones.
●● Lógicos. Son los orientados a las operaciones. Normalmente se implementan en

algún manejador de base de datos.
●● Físicos. Son las estructuras de datos en bajo nivel, implementadas dentro del
propio manejador.
18
2.2 Terminología del modelo relacional Recuerda

El modelo relacional representa la base de datos como una colección de relacio- En la terminología del
modelo relacional,
nes. La terminología asociada con el modelo relacional es la siguiente:
una tabla se denomina
relación, una tupla es
●● Relación (relation). Conjunto de datos organizados en forma tabular. Se com- una fila y un atributo
pone de tuplas y atributos; cada intersección de tupla y atributo contiene un es una columna. A las
valor. entidades también se
las conoce como una
●● Tupla (tuple). Cada uno de los registros dentro de una tabla. relación.
●● Atributo (attribute). Corresponde a las divisiones verticales de la relación. El

conjunto de todos los atributos es lo que compone una tupla.
Los términos relación y tupla han caído en desuso. Así pues, utilizaremos para ellos
la terminología más común y denominaremos a la relación tabla (table) y fila (row)
a la tupla. En cambio, el término atributo, denominado también columna (co-
lumn), se utiliza indistintamente al hablar del modelo relacional (Figura 2.2).
Sistemas gestores Sistemas gestores

Modelo relacional
de bases de datos de bases de datos
Relación Tabla Fichero

Tupla Fila Registro Figura 2.2
Atributo Columna Campo Tabla de equivalencias en la
terminología.
2.3 Características de una relación
Uno de los logros del modelo relacional radica en la simplicidad del diseño básico
de la tabla. Veamos cuáles son sus características: Para saber más
El número de filas de
●● A cada tabla se le da un nombre. No pueden existir dos tablas con el mismo una tabla se denomina
nombre. Cada tabla es, a su vez, un conjunto de filas y columnas. cardinalidad de la tabla;
el número de columnas
●● La información en la base de datos son datos explícitos. No existen apuntadores es el grado de la tabla;
o ligas entre tablas. y el conjunto de valores
válidos que puede tener
●● Cada fila de la tabla debe ser única, es decir, no pueden existir dos filas con datos cada atributo se llama
idénticos para todos los atributos. La razón es que cada fila representa un hecho dominio.
diferenciado, y la presencia de dos filas idénticas sería redundante.
19
●● El orden de las filas de una tabla es irrelevante.
●● Todas las entradas de cualquier columna son de un solo tipo.
●● A cada columna se le asigna un nombre que refleje la característica correspon-

diente del mundo real.
●● El orden de las columnas no es importante para la tabla.
●● Cada entrada de una tabla debe tener un sólo valor (son atómicos); no se admi-
ten valores múltiples. En definitiva, la intersección determinada de fila y columna
tiene un solo valor, nunca un conjunto de valores.
Dentro del modelo relacional existe una relación entre las diferentes tablas que
ayudan a evitar los datos redundantes. Esta relación vincula la clave primaria de
una tabla, que proporciona a un identificador único para cada fila, con una clave
ajena o foránea de la otra tabla (Figura 2.3).
Figura 2.3
Ejemplo de una tabla
y sus vinculaciones.
A continuación, podremos ver la relación que existe entre la Tabla director y la

Tabla empleados.
Cada empleado tiene un director asociado mediante la columna “Director” (Figura

2.4), que es clave foránea de la clave primaria DNI_director en la otra tabla. De esta
20
manera, se crea una dependencia de la tabla foránea, y así si eliminamos al director

Sergio Martínez, el registro del empleado Fernando García será incorrecto, puesto
que estará referenciado a un elemento inexistente (Figura 2.5).
TABLA DIRECTOR
DNI_director Apellido Nombre
00000000 A Sánchez Pablo
Figura 2.4
00000001 B Martínez Sergio
Tabla director.
TABLA EMPLEADOS
DNI empleado Apellido Nombre Director
46872145 A Pérez Álex 00000000 A
45212201 B Aguilar José 00000000 A
Figura 2.5
34342142 C García Fernando 00000001 B Tabla empleados.
2.4 Tipos de datos
La teoría de bases de datos relacionales no establece ninguna norma concreta con

respecto a los tipos de datos que éstas deben contener. Por lo tanto, cualquier
conjunto de valores disponibles en una determinada plataforma de hardware y
sistema operativo, o incluso los nuevos tipos de datos definidos por el usuario,
podrían ser tipos de datos válidos.
Los sistemas gestores de bases de datos incorporan sus propias especificacio-

nes en cuanto a tipos de datos. Para cada columna de cada una de las tablas, es
necesario determinar el tipo de datos que debe contener, de esa forma, se ajusta
el diseño de la base de datos y se consigue un almacenamiento óptimo con el
mínimo espacio.
Los tipos de datos que puede contener una columna o atributo pueden clasificar-
se en tres grandes grupos:
●● Numéricos. Los tipos de datos numéricos pueden dividirse en numéricos ente-

ros y numéricos con partes fraccionarias (coma flotante).
●● Fecha. Los tipos de datos fecha sólo admiten fechas y horas. Cuando se almace-
nan las fechas no se comprueba de una manera estricta si una fecha es válida o
no, sino que el mes esté comprendido entre 0 y 12, y el día entre 0 y 31.
21
●● Cadena. Los tipos de datos cadena pueden dividirse en alfanuméricos o en

aquellos que almacenan datos binarios, como los ficheros llamados BLOB (Binary
Large Object) (Figura 2.6).
Figura 2.6
Tipos de datos más usuales.
2.5 Juegos de caracteres

Recuerda Se llama juego de caracteres (charset) al conjunto de caracteres reconocidos
Al empezar a trabajar por un hardware o un software. Cada código es una representación numérica de
con una base de datos un determinado carácter. Por ejemplo, el conjunto de caracteres ASCII (American
determinada, es Standard Code for Information Interchange) está basado en el alfabeto latino, tal
conveniente conocer las como se utiliza en inglés. ASCII es un código de siete bits, lo que significa que utili-
especificaciones del tipo
za cadenas de bits con siete dígitos binarios (que van de 0 a 127 en base decimal)
de datos que ésta puede
contener. para representar información de caracteres.
Existen extensiones que utilizan 8 bits para proporcionar caracteres adicionales,

que son utilizados en idiomas distintos del inglés. En juegos de caracteres de 8
bits podemos representar hasta 256 caracteres diferentes. Actualmente, se utili-
zan juegos de caracteres de 16 bits, que permiten codificar hasta 65.535 caracte-
res. Casi todos los sistemas informáticos actuales utilizan el código ASCII o una
extensión compatible. En definitiva, un juego de caracteres es un sistema de co-
dificación para todos los caracteres y signos que utilizamos en la representación
y comunicación de la información. Su importancia se debe a que determina qué
caracteres pueden presentarse en nuestro sistema y pueden alterar la presen-
tación de los datos; adicionalmente, también pueden alterar el criterio de ordena-
ción alfabética (Figura 2.7).
22
Figura 2.7
Tablas del juego de carácteres
ASCII de 8 bits.
2.6 Claves primarias
Se denomina clave candidata (candidate key) al conjunto no vacío de atributos que

identifican cada fila de una tabla. Sin embargo, en una tabla podemos tener más de
una clave candidata y, en ese caso, el usuario deberá escoger una de las claves can-
didatas para que sea la clave primaria (primary key) de la tabla (Figura 2.8).
DNI Apellido Nombre Ciudad
00000000 A Sánchez Pablo Barcelona Figura 2.8

00000001 B Martínez Sergio Madrid Listado de personas con diferen-
00000002 C Pérez Álex Barcelona tes atributos que las identifican.
La tabla de la figura 2.8 representa un listado de personas y en ella podremos de-

finir diferentes claves candidatas.
En ella definiremos tres claves candidatas:
●● DNI Recuerda
●● Nombre
Sólo se podrán
●● Apellido
almacenar
correctamente en
Cualquiera de estas tres claves candidatas podría identificar a una persona. Ahora la base de datos los
bien, podemos suponer que pueden existir dos personas con el mismo nombre y caracteres admitidos por
apellido; en cambio, es imposible que existan dos personas con el mismo DNI. Por el juego de caracteres
ello, en este caso lo más conveniente sería definir el DNI como la clave primaria definidos en cada base
de la tabla. de datos.
23
La clave primaria es aquella clave candidata que el usuario elegirá, por consi-
deraciones ajenas al modelo relacional, para identificar las filas de la tabla; lo que
la convierte en un identificador que será siempre único para cada fila. El modelo
relacional no incluye el concepto de elegir una clave como clave primaria cuando
hay varias claves candidatas. En ocasiones, el usuario decide crear una clave prima-
ria numérica, de manera aleatoria, cuyo único requisito es el de guardar un valor
numérico único para cada fila de forma totalmente independiente a los datos de
negocio y que, generalmente, no tiene significado por sí misma. Este tipo de cla-
ves primarias también se conocen como claves subrogadas (surrogate key).
Diremos que una clave primaria es simple cuando el conjunto de atributos no

vacío está compuesto por una sola columna. Sin embargo, una clave primaria se
llamará clave compuesta cuando el conjunto de atributos no vacío este formado
por más de una columna, creando siempre una sola clave única. Es decir, si se opta
por utilizar una clave compuesta, ésta deberá ser única con respecto a las demás
filas de la tabla (Figura 2.9).
Figura 2.9
Distintos tipos de claves prima-
rias para una tabla.
Imaginemos ahora que, por cuestiones de seguridad, no deseamos conservar el

DNI de las personas en nuestra base de datos; en ese caso, deberíamos buscar
una alternativa. Por separado, tanto el nombre como el apellido (nuestras claves
candidatas) pueden ser susceptibles de que existan repeticiones; en cambio, hay
muchas menos posibilidades de que existan dos personas con el mismo nombre
y apellido. Por tanto, definiremos una clave primaria compuesta que agrupará las
columnas Nombre y Apellido en una única clave (Figura 2.10).
24
Apellido Nombre Ciudad
Sánchez Pablo Barcelona

Figura 2.10
Sánchez Sergio Madrid
Tabla de personas con sus
Pérez Pablo Barcelona ciudades de origen.
2.7 Índices
El índice de una base de datos mejora la velocidad de las consultas, lo que permite
un rápido acceso a las filas de una tabla en una base de datos. Al aumentar drásti-
camente la velocidad de acceso, el índice de una base de datos se suele utilizar en
aquellos atributos sobre los que se realizan búsquedas frecuentes. El funcionamien-
to del índice es similar al de un libro: se guarda el elemento que se desea indexar y Recuerda
su posición en la base de datos (que, en el caso del libro, correspondería al número Sólo puede haber una
de páginas). Los índices pueden crearse con una o más columnas y constituyen la clave primaria por
base para poder realizar búsquedas rápidas al azar o un acceso ordenado a regis- tabla, pero ningún
tros, evitando así una búsqueda secuencial que podría ser muy lenta en el caso de atributo de dicha clave
puede contener valores
que se almacene mucha información. Los índices, generalmente, no se consideran
vacíos (Null).
parte de la base de datos, ya que son un complemento añadido (Figura 2.11).
Figura 2.11
Utilización de índices en las
consultas para ser más efectivas.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como
clave primaria, pero que también puede identificar de forma única una fila dentro
de una tabla. Las claves alternativas son las primeras candidatas para convertirse
en índices. Veamos a continuación cuáles son las ventajas e inconvenientes de
trabajar con claves alternativas:
25
Recuerda ●● Ventajas:
Los índices son - Evitan una lectura secuencial de la tabla.

recomendables en
- Ayudan a no sobrecargar la CPU, el disco y la concurrencia.
campos que poseen
- Las consultas tipo SELECT son más rápidas si tenemos una clave alternativa en
un amplio abanico de
valores alojados. Esto la clausula WHERE.
no significa que para un - Útiles en campos que no tengan datos duplicados.
campo binario no sean
efectivos; pero, en ese ●● Desventajas:
caso, un índice sólo nos
ahorraría el 50% de las - No son adecuadas en las tablas en que se utilizan frecuentemente operaciones
filas en cada consulta; de escritura (Insert, Delete, Update), ya que éstas se actualizan cada vez que se
mientras que, si modifica una columna.
hablamos de un atributo
- No se aprecia la mejora en tablas pequeñas.
“id” de valor único, nos
- No se aconsejan en consultas que devuelven gran cantidad de datos.
ahorraríamos el 99% de
las filas en la consulta. - Ocupan espacio.
Tanto los índices como las claves primarias pueden definirse con una característica
para evitar que dos valores puedan ser duplicados en una misma tabla.
2.8 El valor NULL. Operar con el valor NULL
NULL es un valor muy importante en el modelo relacional, puesto que permite tra-
bajar con datos desconocidos o que carecen de valor. Definido por el informático
inglés Edgar Frank Codd, NULL indica un valor asignado a un atributo que no contie-
ne ninguno de los valores del dominio de dicho atributo. Sirve para reprensentar, en
los sistemas de gestión relacionales de base de datos (DBMS Database Management
System), la información “desconocida” o “no aplicable”. Para comprenderlo mejor, vea-
mos un ejemplo. Tenemos una tabla de vehículos en la que podemos guardar tanto
motocicletas como automóviles.
Un atributo, o campo de la tabla, indica a qué lado está el volante (para distinguir
vehículos con el volante a la izquierda de los que lo tienen a la derecha). Dicho atri-
buto no tiene sentido en el caso de tratarse de una motocicleta; en este caso, el
atributo para entidades de tipo motocicleta será NULL. El dominio de este atributo
es derecha o izquierda, de modo que si queremos asignar un valor del dominio,
no tenemos otra opción que asignarle un NULL. El valor NULL nos indica que este
atributo no tiene ninguno de los valores posibles del dominio (derecha o izquier-
da). De esta manera el valor NULL amplía la información. Es importante señalar que
no pueden realizarse operaciones aritméticas con el valor NULL (5+null), pero sí, en
cambio, es posible realizar operaciones lógicas. Esta clase de operaciones sólo dan
26
como resultado verdadero o falso; sin embargo, cuando interviene un valor nulo, se Para saber más
generan operaciones con resultados que no pueden ser determinados, creando de
esta manera el sistema de Lógica ternaria, en el que a los valores verdadero o falso se Existe una gran
controversia con
les añade el valor desconocido (Figura 2.12).
respecto a la lógica
ternaria. Algunos
expertos consideran que
la existencia de un valor
“desconocido” carece
de la lógica necesaria
para formar parte de
operaciones lógicas.
Figura 2.12
Tablas de resultados tras operar
con el valor NULL.
2.9 Claves ajenas
La clave ajena o foránea (foreign key) es un conjunto de atributos en una tabla

(tabla hija o referida) que se referencia con la clave primaria en otra tabla (tabla pa- Recuerda
dre o referenciada) y determina la relación existente entre ambas tablas. Las claves
foráneas no necesitan ser claves únicas en la tabla referida, pero sí, en cambio, en NULL es también una
palabra propia del
la tabla donde está referenciada (Figura 2.13).
lenguaje de consulta
estructurada SQL
(Structured Query
Language) para indicar
que no existe un valor
para un atributo de una
tabla de la base de datos.
Figura 2.13
Las claves foráneas relacionan
una tabla referenciada con una
tabla referida.
27
A continuación, veremos cómo se relacionan dos tablas mediante las claves foráneas.
Tenemos, por un lado, una tabla con un listado de alumnos identificados por el DNI
(columna que reconoce a cada alumno de manera única) (Figura 2.14) y, por otro lado,
una tabla con una serie de notas identificadas por el DNI del alumno (Figura 2.15).
TABLA DE ALUMNOS
DNI_ alumno Apellido Nombre
00000000 A Sánchez Pablo

00000001 B Martínez Sergio
Figura 2.14 00000002 C Pérez Álex
Tabla de alumnos.
TABLA DE NOTAS
Codigo_asignatura Asignatura DNI_ alumno Nota
M001 Matemáticas 00000000 A C+

G002 Geografía 00000001 B B
Figura 2.15 I006 Inglés 00000002 C C-
Tabla de notas.
Se entiende que la Tabla de notas es foránea de la Tabla de alumnos, ya que es

necesaria esta última para saber de quién son las notas. Además, si se cambiase
el DNI de algún alumno, debería cambiarse en las dos tablas para que la referen-
cia se mantuviese.
La tabla referida y la tabla referenciada pueden ser la misma, es decir, la clave foránea
se referencia en la propia tabla. Una tabla puede tener múltiples claves foráneas y
cada una puede estar referenciada en diferentes tablas.
Los atributos de las claves primaria y ajena referidos, vinculados o relacionados

han de estar definidos con el mismo tipo de dato (dominio), mientras que los
nombres de los atributos pueden ser diferentes.
El tipo de relación entre tablas dependerá de cómo se definan las columnas rela-
cionadas:
●● Uno-a-uno. Una fila en tabla padre no tiene más de una fila vinculada en tabla
hija (y viceversa). Por ejemplo, si tenemos una tabla con directores y otra con
sucursales, cada director sólo podrá ser responsable de una sucursal y cada su-
cursal sólo podrá tener un director.
28
●● Uno-a-muchos. Se trata del tipo de relación más común entre tablas. Una fila Recuerda
en la tabla padre tiene muchas filas vinculadas en la tabla hija; sin embargo, una
fila en la tabla hija tiene una única fila vinculada en la tabla padre. Por ejemplo, Las claves ajenas
colaboran para
si tenemos una tabla de empresas y otra tabla de empleados, cada empleado
garantizar la integridad
pertenecerá a una única empresa; sin embargo cada empresa estará relacionada referencial; es decir,
con varios empleados. aseguran que no existan
en las claves foráneas
●● Muchos-a-muchos. Una fila en la tabla padre tiene muchas filas vinculadas en valores que no estén en
tabla hija (y viceversa). Esta relación puede crearse definiendo una tercera tabla, la clave primaria, una
llamada tabla de unión, cuya clave primaria consiste en las claves foráneas de propiedad deseable en
ambas tablas padre e hija. Por ejemplo, un cliente que compra en un centro las bases de datos.
comercial. En ese caso, cada tipo de producto podrá ser comprado por varios
clientes, y cada cliente podrá comprar varios productos.
2.10 Vistas
Una vista (view) puede definirse como una tabla lógica que permite acceder a
los datos de otras tablas. Las tablas sobre las cuales se crea se denominan tablas
base. El que una vista sea una tabla lógica significa que no contiene datos en sí
misma, por lo que puede ser entendida como una tabla virtual que se nutre de
datos de una o varias tablas. Una vez definida, puede ser utilizada en cualquier
lugar (incluso en la definición de otra vista). Al igual que sucede con una tabla,
pueden insertarse, modificarse, borrarse y seleccionarse los datos en una vista; y en
algunos casos existen restricciones en la actualización de sus datos (Figura 2.16).
Figura 2.16
Composición de una vista
a partir de las columnas de
diferentes tablas.
29
Recuerda En la figura 2.16 podemos ver cómo a partir de diferentes columnas de dos tablas
podemos crear una nueva vista que reúna todas estas columnas en una nueva
Las vistas tienen la tabla.
misma estructura
que una tabla: filas y
columnas. Las vistas se utilizan con el fin de:
●● Proporcionar un nivel adicional de seguridad sobre las tablas y, así, restringir el

acceso a un predeterminado conjunto de filas o atributos de una tabla base.
●● Ocultar la complejidad de los datos; por ejemplo, puede utilizarse para actuar
como una única tabla, mientras que varias tablas se utilizan para construir el
resultado.
●● Presentar los datos desde otra perspectiva. Permiten la posibilidad de renombrar

los atributos sin necesidad de cambiar la definición de la tabla base.
●● Obligar al gestor de base de datos a realizar algunas operaciones. Resultan más

cómodas y manejables que escribir complejas sentencias SQL.
La mayoría de los sistemas de gestión de bases de datos relacionales soportan,

con más o menos prestaciones, la creación y manipulación de vistas.
2.11 Usuarios, privilegios y roles
Para conservar la integridad de los datos y sus estructuras es imprescindible que

sólo algunos usuarios puedan realizar determinadas tareas. Conceptos como
usuarios y privilegios están íntimamente relacionados, ya que no puede crearse
un usuario sin asignarle al mismo tiempo privilegios y restricciones.
Un privilegio es un permiso dado a un usuario dentro de la base de datos para

ejecutar determinadas operaciones o acceder a determinados objetos. Éste puede
clasificarse en dos categorías:
●● Privilegios de sistema. Permiten crear una acción particular dentro del siste-
ma o una acción particular sobre un tipo determinado de objeto (como nuevas
tablas) y adjudicarles propiedades, niveles de seguridad, etc. La mayoría están
disponibles sólo para administradores y desarrolladores de aplicaciones.
●● Privilegios de objetos. Permiten crear acciones sobre un objeto específico,

como borrar filas de una tabla específica. Estos privilegios son asignados nor-
malmente a usuarios finales.
30
En cuanto a un rol, éste no es más que un conjunto de privilegios del sistema y

de objetos agrupados con un determinado nombre. Un rol puede ser asignado a
usuarios o a otros roles, lo que hace posible una administración más fácil y contro-
lada de los privilegios (Figura 2.17).
Figura 2.17
Los usuarios a los que se asigna
un rol comparten todos los
privilegios que alberga éste.
El usuario puede recibir un privilegio de dos formas distintas:
●● Asignado a los usuarios explícitamente.
●● Asignado a roles (grupo de privilegios), que después pueden ser asignados a uno
o más usuarios.
2.12 Lenguaje de descripción de datos (DDL)
El DDL (Data Definition Language) o Lenguaje de Definición de Datos es un len-

guaje proporcionado por el sistema de gestión de la base de datos que permite
a los usuarios de ésta llevar a cabo las tareas de definición o modificación de la
estructura de los objetos que contiene.
A diferencia de muchos lenguajes DDL, el SQL (Structured Query Language) utiliza

una serie de verbos imperativos, llamados sentencias, cuyo efecto es modificar el
31
esquema de la base de datos, añadir, cambiar o eliminar las definiciones de tablas

y otros objetos. Estas declaraciones pueden mezclarse libremente con otras sen-
tencias SQL, por lo que el DDL no es realmente un lenguaje independiente en SQL.
El lenguaje de programación SQL, el más difundido entre los gestores de bases de

datos, admite las siguientes sentencias con sus respectivas cláusulas de definición
de datos:
●● CREATE. Crea una tabla en la que definiremos los atributos que tendrá así como
el formato y las características de clave primaria y foránea.
CREATE TABLE “nombre_tabla”

(“columna 1” “tipo_de_datos_para_columna_1”,
“columna 2” “tipo_de_datos_para_columna_2”,
... )
●● ALTER. Modifica la estructura de una tabla ya creada. Podemos añadir o modifi-

car columnas, e incluso cambiar sus características.
ALTER TABLE table_name

[ADD column_name datatype] *crea una nueva columna dentro
de la tabla
[DROP COLUMN column_name] *elimina una columna
[ALTER COLUMN column_name datatype] *cambia las propie-
dades de la columna
●● DROP. Elimina una tabla creada.
DROP TABLE table_name
●● TRUNCATE. Vacía todo el contenido de una tabla. Esta sentencia parece una
DML (Data Manipulation Language) o Lenguaje de Manipulación de Datos; pero
a diferencia de éste, TRUNCATE borra la tabla y la vuelve a crear sin ejecutar nin-
guna transacción.
TRUNCATE TABLE table_name
Los tipos de objetos a los que pueden aplicarse dichas sentencias dependen
del gestor de base de datos que esté siendo utilizado. La mayoría permite su
aplicación en tablas, vistas, índices, usuarios, sinónimos, procedimientos alma-
cenados (stored procedure), consultas almacenadas (triggers) y bases de datos
(Figura 2.18).
32
Figura 2.18
El lenguaje DDL permite mo-
dificar la estructura de la base
de datos.
2.13 Lenguaje de control de datos (DCL)
El DCL (Data Control Language) o Lenguaje de Control de Datos es un lenguaje

proporcionado por el sistema de gestión de base de datos que permite al adminis-
trador controlar el acceso a los datos contenidos en la base de datos.
Para saber más
Un procedimiento
almacenado (stored
El SQL, a diferencia de muchos lenguajes DCL, incluye una serie de sentencias que
procedure) es un
permiten al administrador asignar a los usuarios permisos para realizar tareas en la
programa guardado en
base de datos. El DCL no es realmente un lenguaje independiente en SQL; no debe- una base de datos. Se
mos olvidar este aspecto a la hora de trabajar en un entorno multiusuario, en el que ejecuta directamente
se debe tener en cuenta la protección de los datos, la seguridad de las tablas y el es- en el motor de bases
tablecimiento de restricciones en el acceso, así como los elementos para coordinar de datos y sólo necesita
y compartir los datos por parte de usuarios concurrentes, y asegurarnos de que no enviar sus resultados
interfieren unos con otros. La existencia de estas sentencias del Lenguaje de Control al usuario, por lo que
de Datos dependerá de la implementación del estándar SQL que lleve a cabo el elimina la sobrecarga
gestor de base de datos que está siendo utilizado. Veamos a continuación algunos de comunicar grandes
ejemplos de sentencias con sus respectivas cláusulas incluidas en el DCL: cantidades de datos
salientes y entrantes.
Los procedimientos
●● GRANT. Permite asignar privilegios o permisos a uno o varios usuarios, así como almacenados y
roles para realizar tareas determinadas, como acceder a los datos o modificarlos. utilizados para la
validación de datos se
GRANT nombre_del_privilegio conocen, comúnmente,
ON objeto con el nombre de
TO {usuario |PUBLIC |rol} “disparadores”
[WITH GRANT OPTION]; (triggers).
33
●● REVOKE. Permite eliminar o revocar los privilegios que previamente se han con-
cedido con GRANT.
REVOKE nombre_del_privilegio
ON objeto
FROM { usuario |PUBLIC |role_name}
●● CREATE ROL. Es una colección de privilegios y derechos de acceso que pueden

ser aplicados a un gran número de usuarios al mismo tiempo.
CREATE ROLE test; *Crea un rol con el nombre test

GRANT CREATE TABLE TO test; *Da permisos al rol “test”
para crear tablas
GRANT test TO usuario1; *Aplica el rol a un usuario
●● CREATE USER. Crea un usuario al que se le aplicarán unos permisos determinados.
CREATE USER usuario [IDENTIFIED BY ‘contraseña’]
●● Nombre_del_privilegio. Tipo de privilegio que se le asignará al usuario; algunos

de ellos podrían ser ALL, EXECUTE o SELECT.
●● Objeto. Tipo de elemento al que se le aplican los derechos; pueden ser tablas,
vistas, procedimientos.
●● Usuario. Usuario al que se le conceden los permisos.
●● PUBLIC. Se le asigna este permiso a todos los usuarios.
●● Rol. Los usuarios pueden agruparse en grupos llamados roles, a los que se les
puede aplicar permisos a todos ellos al mismo tiempo.
●● WITH GRANT OPTION. Concede al usuario la capacidad de modificar permisos

sobre otros usuarios. Se utiliza para designar administradores.
En definitiva, las sentencias del Lenguaje de Control de Datos sirven para otorgar
permisos o quitarlos, ya sea a usuarios específicos o a un rol creado dentro de la
base de datos.
34
Resumen
Las bases de datos relacionales se caracterizan por la simplicidad de su diseño mediante la represen-
tación de los datos en tablas relacionadas entre ellas. Estas relaciones proporcionan al usuario pistas
para poder contextualizar los datos en la vida real en vez de ser mera información digitalizada. En las
tablas pueden existir claves primarias que identifican de manera inequívoca cada uno de los registros
almacenados. Esto es especialmente útil para obtener datos específicos, ya que al ser identificados
con un elemento único favorece las operaciones de búsqueda y ordenación por parte del servidor.
Las claves ajenas son aquellas enlazadas con claves primarias de otras tablas; de esta manera se con-
sigue establecer las relaciones entre las tablas.
Las tablas que no disponen de claves primarias tienen la posibilidad de optimizar las búsquedas de
registros mediante la incorporación de índices en los registros. Los índices suelen ser asignados de
manera automática y correlativa por el sistema, al insertar un nuevo registro, lo que evita que existan
índices repetidos.
Las vistas son estructuras conceptuales creadas por los usuarios para reunir en una sola tabla los
datos de diferentes objetos con el fin de obtener la información que se ajuste a sus necesidades. De
esta manera los usuarios pueden crear tablas personalizadas en las que podrán aplicar consultas tal
y como lo harían con una tabla normal.
El valor NULL es un concepto utilizado en las bases de datos para representar aquellos registros en los
que no se ha introducido ningún valor. No es considerado un valor real, y a pesar de que no pueden
realizarse operaciones aritméticas sobre el valor NULL, los sistemas de bases de datos y la programa-
ción en general permite realizar operaciones lógicas y de comparación con este valor, siguiendo la
denominada lógica ternaria.
El acceso a una base de datos está restringido a los usuarios registrados en ella, y cada usuario puede te-
ner diferentes privilegios sobre los objetos, sean tablas o vistas. De esta manera pueden definirse usua-
rios que sólo podrán realizar consultas, o usuarios que pueden modificar datos. Los roles son definidos
para agrupar diferentes usuarios con los mismos permisos. El Lenguaje de Descripción de Datos (DDL)
engloba todas aquellas consultas realizadas a la base de datos por aquellos usuarios que tienen como
objetivo definir o modificar las estructuras de los objetos de la base de datos. Dentro de esta categoría
se hallan las instrucciones para crear tablas y vistas, definir las columnas, vaciar el contenido de una ta-
bla, modificar nombres y parámetros, etc. En cambio, el Lenguaje de Control de Datos (DCL) se encarga
de crear y modificar los permisos de los usuarios sobre los objetos de la base de datos.
35
1. Los modelos conceptuales son los que describen las estructuras de los datos y
sus restricciones de integridad. Se utilizan en la etapa de análisis, y representan
los elementos que intervienen y sus relaciones.
2. Los tipos de datos fecha sólo admiten fechas y horas. Cuando se almacenan las
fechas no se comprueba de una manera estricta si una fecha es válida o no, sino
que el mes esté comprendido entre 0 y 12, y el día entre 0 y 31.
3. Los tipos de datos cadena sólo pueden dividirse en alfanuméricos como los
ficheros llamados BLOB.
4. ASCII es un código de siete bits, lo que significa que utiliza cadenas de bits con
siete dígitos binarios (que van de 0 a 127 en base decimal) para representar in-
formación de caracteres.
5. Se denomina clave candidata (candidate key) al conjunto vacío de atributos que
identifican cada fila de una tabla.
6. El modelo relacional incluye el concepto de elegir una clave como clave prima-
ria cuando hay varias claves candidatas.
7. Una clave alternativa es aquella clave candidata que no ha sido seleccionada

como clave primaria, pero que también puede identificar de forma única una
fila dentro de una tabla.
8. NULL indica un valor asignado a un ______________ que no contiene ninguno

de los valores del ______________ de dicho ______________.
9. Las claves foráneas no necesitan ser claves ______________ en la tabla referida,

pero sí, en cambio, en la ______________ donde está referenciada.
36
10. Un privilegio es un permiso dado a un ______________ dentro de la base de

datos para ______________ determinadas operaciones o acceder a determi-
nados ______________ .

37
Soluciones a los ejercicios

de autocomprobación
Unidad 1
1. V
2. F. Las bases de datos son colecciones de ficheros de datos relacionados entre sí
a los que pueden acceder varios usuarios y aplicaciones a la vez.
3. F. Los modelos de datos son las herramientas conceptuales que sirven para des-
cribir de forma abstracta la estructura de una base de datos (los datos, las rela-
ciones y las restricciones que existen entre ellos).
4. V
5. V
6. F. Por lo que respecta a SQLite, se trata de un SGDB de bajo consumo que permi-
te obtener datos con menos recursos.
7. V
8. disco, tablas, atributo
9. máximo, instalar, administrar, usuarios.
10. conceptual, externo, objetos.
Unidad 2
1. V
2. V
3. F. Los tipos de datos cadena pueden dividirse en alfanuméricos o en aquellos
que almacenan datos binarios, como los ficheros llamados BLOB.
4. V
5. F. Se denomina clave candidata (candidate key) al conjunto no vacío de atributos
que identifican cada fila de una tabla.
6. F. El modelo relacional no incluye el concepto de elegir una clave como clave
primaria cuando hay varias claves candidatas.
7. V
8. atributo, dominio, atributo.
9. únicas, tabla
10. usuario, ejecutar, objetos.
38
Índice
Índice
MÓDULO: BASES DE DATOS
UNIDAD FORMATIVA 1
1. Almacenamiento de la información................................................................................................................................ 7
1.1 Ficheros .................................................................................................................................................................................................. 7
1.2 Bases de datos ................................................................................................................................................................................... 8
1.3 Sistemas gestores de bases de datos .................................................................................................................................. 10
1.4 Sistemas gestores de bases de datos comerciales y libres .................................................................................... 11
1.5 Bases de datos centralizadas y bases de datos distribuidas. Fragmentación ............................................. 12
Resumen ........................................................................................................................................................................................................ 14
Ejercicios de autocomprobación .................................................................................................................................................... 15
2. Base de datos relacionales ....................................................................................................................................................... 17

2.1 Modelo de datos .............................................................................................................................................................................. 17
2.2 Terminología del modelo relacional .................................................................................................................................... 19
2.3 Características de una relación ................................................................................................................................................ 19
2.4 Tipos de datos .................................................................................................................................................................................... 21
2.5 Juegos de caracteres ..................................................................................................................................................................... 22
2.6 Claves primarias ................................................................................................................................................................................ 23
2.7 Índices ..................................................................................................................................................................................................... 25
2.8 El valor NULL. Operar con el valor NULL ............................................................................................................................ 26
2.9 Claves ajenas ....................................................................................................................................................................................... 27
2.10 Vistas ....................................................................................................................................................................................................... 29
2.11 Usuarios, privilegios y roles ...................................................................................................................................................... 30
2.12 Lenguaje de descripción de datos (DDL) ....................................................................................................................... 31
2.13 Lenguaje de control de datos (DCL) .................................................................................................................................. 33
Resumen ........................................................................................................................................................................................................ 35
Soluciones a los ejercicios de autocomprobación .............................................................................................................. 38
39
uNIDAD FORMATIVA 2
• Realización de consultas
• Tratamiento de dato
3. REALIZACIÓN DE CONSULTAS
Una vez hemos aprendido cómo se estructuran las bases de datos, analizaremos una
parte fundamental del módulo: la realización de consultas. Las consultas son el
modo que tenemos de obtener o insertar la información en las bases de datos para
poder utilizarla posteriormente. A lo largo de este capítulo, estudiaremos los diferen-
tes tipos de consultas que existen, y conoceremos cuál es su funcionalidad y cuál
su estructura. A pesar de que las diferentes bases de datos pueden tener algunas
diferencias en la construcción de las consultas, la mayoría de ellas sigue unas pautas
determinadas y se rige por las mismas normas con el fin de conseguir una mayor
estandarización entre ellas.
3.1 Herramientas gráficas proporcionadas por el sistema gestor

para la realización de consultas
Para ampliar este
Los SGDB nos permiten realizar cualquier operación sobre la información alma-
tema, puedes ver el
videotutorial Cómo cenada en las bases de datos, lo que resulta especialmente útil para modificar
utilizar workbench de los permisos y las políticas de acceso de los usuarios, así como para modificar las
MySQL, que encontrarás estructuras. Los SGBD deben cumplir los siguientes objetivos:
en el Campus online.
●● Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca
del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa
uno o cientos de archivos, este hecho se hace transparente al usuario; de ese
modo, se definen varios niveles de abstracción.
●● Independencia. La independencia de los datos consiste en la capacidad de mo-

dificar el esquema (físico o lógico) de una base de datos sin tener que realizar
cambios en las aplicaciones que se sirven de ella.
●● Consistencia. En aquellos casos en los que no se ha logrado eliminar la redun-

dancia, será necesario supervisar que aquella información que aparece repetida
se actualice de forma coherente, es decir, que todos los datos repetidos se ac-
tualicen de forma simultánea. Por otra parte, la base de datos representa una
realidad concreta que tiene también determinadas condiciones; por ejemplo,
que los menores de edad no pueden tener licencia de conducir. El sistema, por
lo tanto, no debería aceptar datos de un conductor menor de edad. En los SGBD
existen herramientas que facilitan la programación de este tipo de condiciones.
●● Seguridad. La información almacenada en una base de datos puede llegar a

tener un gran valor. Los SGBD deben garantizar que esta información se halla
42
Realización de consultas
segura y permiten que se otorguen diversas categorías de permisos a usuarios y

grupos de usuarios.
●● Manejo de transacciones. Una transacción es un programa que se ejecuta como

una sola operación. Esto significa que, después de una ejecución en la que se pro-
duce un fallo, el resultado es el mismo que se obtendría si el programa no se hubiera
ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los
datos de una forma mucho más simple que si no se dispusiera de ellos.
●● Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el

SGBD demora en proporcionar la información solicitada y en almacenar los cam-
bios realizados.
Dichas herramientas también nos permiten realizar consultas con el fin de obtener
los datos almacenados de una manera más sencilla, pues basta con hacer clic en la
parte visual para seleccionar el campo que quieres consultar. El SGBD nos avisará
si en la construcción de la consulta hay algún error y, al ejecutarla, se mostrará el
resultado en una ventana aparte (Figura 3.1).
Figura 3.1
Estructura de base de datos en
un SGBD.
43
Es recomendable probar los diferentes SGBD que existen en el mercado para fa-
miliarizarnos con ellos. Durante el curso, utilizaremos el Workbench de MySQL, un
software libre de gestión de bases de datos disponible para todas las plataformas.
Se puede descargar desde la dirección: http://www.mysql.com/.
3.2 La sentencia SELECT
La sentencia SELECT (seleccionar) es, sin duda, la más utilizada en una base de
datos. Su objetivo es obtener la información que precisemos de la base de datos,
y su complejidad dependerá de la consulta que realicemos.
Recuerda En la misma consulta podremos obtener datos de una o más tablas, así como
ordenarlos o discriminarlos según nuestros criterios. A lo largo de este capítulo
Para seleccionar todas conoceremos la mayoría de configuraciones que permite esta sentencia:
las columnas en una
consulta SELECT, es
necesario utilizar el Veamos a continuación la sintaxis básica de una consulta SELECT (Figura 3.2).
símbolo asterisco (*). La
consulta SELECT * FROM ●● SELECT (seleccionar). Definiremos las columnas de las que queremos obtener
[tabla] devolverá todos su valor. En la misma consulta, seleccionaremos varias columnas de diferentes
los valores que existen tablas, siempre y cuando especifiquemos las relaciones entre tabla y columna,
en la tabla. ya que las columnas de diferentes tablas pueden tener el mismo nombre.
SELECT [nombre_columna]
FROM [tabla]
WHERE [condicion]
Figura 3.2
Estructura de una ORDER BY [Asc/Desc]
sentencia SELECT.
●● FROM (desde). Numeraremos las tablas a las que queramos tener acceso. Po-
dremos elegir tantas tablas como queramos, aunque es recomendable acceder
sólo a aquellas tablas que contengan los datos que necesitamos, de lo contrario
cargaremos el sistema de forma innecesaria.
●● WHERE (donde). Definiremos las condiciones que tienen que cumplir los datos
que vayamos a obtener. De esta manera, filtraremos los resultados según los cri-
terios que nos interesen. Esta cláusula es opcional y, en caso de no ponerla en la
consulta, nos devolverá todas las filas de la columna que hayamos seleccionado
en el SELECT.
44
●● ORDER BY (ordenar por). La consulta SELECT nos permite, además, ordenar al-
fabética o numéricamente los resultados. Un ejemplo sería la ordenación por
apellido de una lista de alumnos. Veamos a continuación algunos ejemplos de
esta sentencia utilizando la tabla de la figura 3.3 como muestra.
P_Id Apellido Nombre Ciudad

1 Sánchez José Barcelona Figura 3.3
2 Alonso Enrique Málaga Ejemplo de tabla que
3 Gutiérrez Pablo Madrid utilizaremos para realizar
4 Martínez Eduardo Madrid los siguientes ejercicios.
Con esta tabla en nuestra base de datos:
1. Seleccionaremos todas las personas de las que tenemos constancia y las orde-
naremos según su apellido:
SELECT * FROM Personas

ORDER BY Apellido
Y como resultado obtendremos la tabla de la figura 3.4.

1 Alonso Enrique Málaga
2 Gutiérrez Pablo Madrid Figura 3.4
3 Martínez Eduardo Madrid Ordenación por apellidos de una
4 Sánchez José Barcelona lista de alumnos.
2. Seleccionaremos todas las personas de las que tenemos constancia que viven
en la ciudad de Barcelona:

WHERE Ciudad=Barcelona

Figura 3.5
P_Id Apellido Nombre Ciudad Resultado de las personas que
1 Sánchez José Barcelona viven en Barcelona.
3.3 Consultas calculadas. Sinónimos
A continuación, conoceremos qué son las consultas calculadas y los sinónimos, y

cómo inciden éstos en los cálculos matemáticos y en la construcción de sentencias.
45
3.3.1 Consultas calculadas
La mayoría de bases de datos nos permite insertar cálculos matemáticos en las con-
sultas para obtener los datos de una operación entre dos o más campos. Imaginé-
monos que una hoja de cálculo es una base de datos. Para poder obtener el valor
deseado realizaremos una operación aritmética sobre dos o más campos. Imagine-
mos que deseamos obtener una consulta en la que, además de la información de la
base de datos, deseamos crear una nueva columna con el resultado de multiplicar
dos valores. La sentencia que produciría como resultado la figura 3.6 sería:
SELECT id_Producto, Producto, PVP, Unidades, (PVP* Unidades) AS Total

FROM Stock
Figura 3.6
Ejemplo de consulta calculada.
3.3.2 Sinónimos
Los sinónimos son un recurso para facilitar la construcción de sentencias. Si que-

remos efectuar operaciones entre diferentes tablas, debemos concatenar la tabla
con sus respectivos campos, utilizando el punto (.). Estas concatenaciones pueden
ser muy largas, pero con los sinónimos podemos definirlas con una sola palabra
para facilitar la programación y comprensión de la consulta. Para crear un sinóni-
mo, utilizamos la cláusula AS (como). Si en las dos tablas de la página siguiente
(Ciudades y Personas) deseamos obtener el nombre de la ciudad y de la persona
con un ID determinado podemos utilizar los sinónimos para definir los nombres
como Ciudad y Persona. La sentencia Transact SQL que ilustra esta explicación es:
SELECT ciudad.nombre as cityName, persona.nombre as per-

sonName
3.4 Selección y ordenación de registros
Al realizar una consulta con varios resultados, la cláusula ORDER BY nos dará la posibi-
lidad de ordenar dicho resultado según el criterio que queramos aplicarle. Deberemos
46
definir un orden alfabético o numérico, ascendente o descendente, e indicar a qué

columna o columnas deseamos aplicarle la ordenación. Si hemos obtenido los valo-
res de diferentes columnas, el resto se adaptará al orden de la columna que hayamos
definido. Es posible definir varias columnas en caso de que en la primera hayan repe-
ticiones. Por ejemplo, ordenar por el primer apellido, el segundo apellido y el nombre
respectivamente. Veamos a continuación algunos ejemplos de esta sentencia partien-
do de que la tabla de la figura 3.7 pertenece a nuestra base de datos:

1 Sánchez José Barcelona
4 Martínez Eduardo Madrid Ejemplo de aplicación de la
5 Martínez Alicia Madrid sentencia ORDER BY.
1. Seleccionaremos todas las personas de las que tenemos constancia que viven
en las ciudades que empiezan por la letra M y las ordenaremos por el apellido:

WHERE Ciudad LIKE M%
ORDER BY Apellido

2 Alonso Enrique Málaga Figura 3.8
3 Gutiérrez Pablo Madrid
4 Martínez Eduardo Madrid Ejemplo de personas ordenadas
5 Martínez Alicia Madrid según su apellido.
2. Seleccionaremos todas las personas y las ordenaremos por el apellido y el nombre:

ORDER BY Apellido, nombre

4 Martínez Eduardo Madrid Si el primer criterio de ordenación
5 Martínez Alicia Madrid se repite, utilizaremos el segundo
1 Sánchez José Barcelona para ordenar los registros.
47
3.5 Operadores
En las consultas podremos utilizar operadores lógicos para filtrar los resultados de
las búsquedas. Se colocarán junto a la cláusula WHERE y servirán para realizar ope-
raciones entre dos columnas o entre una columna y un valor dado. Estos opera-
dores son comunes a todos los sistemas de bases de datos gracias a la supervisión
del Instituto Nacional Estadounidense de Estándares (ANSI, American National
Standards Institute) a la hora de crear un estándar. Pese a ello, algunos SGBD uti-
lizan ciertas peculiaridades para construir consultas, como pueden ser, saltos de
línea o la incorporación del “;” al final de cada sentencia.
3.5.1 Operadores de comparación
Utilizaremos los operadores de comparación para filtrar los resultados que sean
mayores, menores o iguales a un valor dado. La nomenclatura que emplearemos
será la que podemos ver en la figura 3.10.
Nombre Ejemplo Devuelve cierto cuando:

== Igual $a == $b $a es igual a $b
!= Distinto $a != $b $a es distinto a $b
Figura 3.10 < Menor que $a < $b $a es menor que $b
> Mayor que $a > $b $a es mayor que $b
Lista de operadores <= Menor o igual $a <= $b $a es menor o igual que $b
de comparación. >= Mayor o igual $a >= $b $a es mayor o igual a $b
Existen otros operadores de comparación más complejos que realizan un cálculo

sobre una cadena de caracteres o una secuencia de números para devolver un
resultado lógico de verdadero o falso (Figura 3.11).
Operador Nombre Ejemplo Devuelve cierto cuando:

LIKE Parecido Select * Realiza la comparación en
From santos función de un patrón, en lugar
WHERE nombre LIKE ‘San%’ de un valor concreto.
BETWEEN Entre Select * Encuentra los resultados
From vacaciones comprendidos en un rango de
WHERE dias BETWEEN ‘5’ AND ‘7’ números o fechas.
Figura 3.11 IN Dentro de Select * Parecido al operando =, pero
From empleados capaz de realizar más de una
Lista de operadores de compa- WHERE cargo IN comparación.
ración complejos. (“responsable”, “director”, “comercial”)
Podemos utilizar, además, patrones con la cláusula LIKE para realizar comparacio-
nes con porciones de textos (Figura 3.12).
48
Operador Nombre Ejemplo Resultado

% Comodín S% Palabra o frase que empiece por S,
de cadena seguido de más caracteres.
_ Comodín M_S Palabra de tres letras que empiece Figura 3.12

de carácter por M y termine por S.
Lista de patrones.
3.5.2 Operadores lógicos
Se utilizan siempre para realizar una operación lógica entre dos operandos de
comparación: y su resultado será boleano. Hay tres tipos de operadores lógicos:
AND, OR y negación.
●● AND (y). Devuelve el valor lógico verdadero en caso de que los dos operandos
sean verdadero; en caso contrario, devolverá falso.
●● OR (o). Devuelve el valor lógico verdadero en caso de que uno o dos de los operandos
sean verdaderos; en caso que los dos sean falsos, el resultado será también falso.
●● Negación. Invierte el valor lógico del operando al que se le aplica. Transforma el

verdadero en falso y viceversa.
3.5.3 La precedencia
La precedencia es única para cada operando, y define el orden en el que la con-

sulta calcula las operaciones aritmético-lógicas. Por ejemplo, en la sentencia:
SELECT id_Producto, Producto, PVP, Unidades, Descuento,

(Unidades * PVP-Descuento) AS Total
FROM Stock
Primero se realizará la operación PVP*Unidades y del resultado se restará el des-

cuento; eso es así porque la multiplicación y la división tienen preferencia sobre la Para saber más
suma y la resta. Para alterar la precedencia de los operandos, podemos utilizar los Los valores boleanos
paréntesis: son aquellos que
corresponden a una
SELECT id_Producto, Producto, PVP, Unidades, Descuento, numeración binaria.
(Unidades * (PVP-Descuento)) AS Total Sólo pueden tomar como
FROM Stock valor el 1 o el 0, y suelen
asociarse a los valores
En este caso, primero se restará el descuento al PVP y el resultado se multiplicará true (verdadero) o false
(falso) respectivamente.
a las unidades.
49
3.6 Tratamiento de valores nulos
Además de las operaciones lógicas, podemos realizar funciones utilizando el valor

nulo (en inglés NULL), que puede sernos de gran utilidad. Para empezar, tenemos
que saber que sólo algunas de las cláusulas en SQL tienen en cuenta el valor NULL.
A continuación, citaremos las funciones que lo utilizan:
●● NULLIF (A, B). Función que compara dos valores A y B. Si son iguales devuelve
NULL, sino devuelve el primer valor; hay que tener siempre en cuenta que el
valor A no puede ser nunca NULL.
●● NULLS FIRST. Por defecto, cuando usamos el ORDER BY, el resultado coloca los
valores NULL al final. En cambio, con la sentencia ORDER BY NULLS FIRST apare-
cerán los NULLS en los primeros lugares de los registros consultados.
●● COALESCE (A,B,C, [...]). La función devuelve el primer valor de la lista que no sea NULL.
Veamos a continuación cómo obtener el resultado de una consulta ordenada por

el parámetro Número, pero mostrando primero los resultados nulos (Figura 3.13).
Figura 3.13 P_Id Apellido Nombre Número

Resultado de una consulta 1 Alonso Enrique 526
ordenada por Número, con los 2 Gutiérrez Pablo Null
primeros resultados nulos. 3 Martínez Eduardo 123
SELECT Apellido, Nombre, Numero

ORDER BY Apellido NULLS FIRST)
P_Id Apellido Nombre Número

Figura 3.14 2 Gutiérrez Pablo Null
Ejemplo de sentencia ORDER BY 3 Martínez Eduardo 123
NULLS FIRST. 1 Alonso Enrique 526
3.7 Consultas de resumen y funciones de agregado
Las consultas de resumen son aquellas en las que el resultado es un resumen de

las filas de origen y que agrupa a las que tienen el mismo valor.
Para realizar las consultas de resumen es necesario añadir dos cláusulas nuevas a la
sentencia SELECT: GROUP BY y HAVING.
50
Las funciones de agregado son el complemento para realizar las consultas resu-
men. Se trata de funciones que aplican cálculos a un conjunto de valores y devuel-
ven un único resultado (Figura 3.15).
SUM (expresión) MIN (expresión)

AVG (expresión) MAX (expresión)
STDEV (expresión) COUNT (expresión) Figura 3.15
STDEPV (expresión) COUNT (*) Funciones de agregado.
3.8 Agrupamiento de registros
Hemos explicado en qué consisten las consultas de resumen. A continuación, vea-

mos cómo funcionan las cláusulas implicadas en este tipo de consultas.
●● GROUP BY (agrupar por). Con esta cláusula agruparemos el conjunto de filas

que tengan el mismo valor en la columna que hayamos definido. Se sitúa des-
pués de la cláusula WHERE y antes de ORDER BY, y se aplica a los resultados
obtenidos después de aplicar la condición WHERE.
●● HAVING (teniendo). Esta cláusula, al igual que WHERE, aplica una condición a la
consulta, pero ésta se ejecuta en diferente orden y se aplica a aquellas columnas
agrupadas previamente; es decir, sólo podrá utilizarse junto a la cláusula GROUP BY.
A continuación, mostramos una representación de una base da datos que alma-

cena un listado de jugadores de fútbol, su edad y el equipo al que pertenecen. En
ella puede verse cómo debemos realizar una consulta para obtener el nombre de
cada equipo y la edad media de los jugadores mayores de 24 años. Además, sólo
se muestran los equipos que contengan más de tres jugadores mayores de 24
años (Figura 3.16).
Equipo Edad Nombre SELECT Equipo, AVG(Edad)

FROM jugadores
Bcn 26 Álex WHERE Edad>24
Vlc 26 Pablo GROUP BY Equipo
HAVING COUNT(nombre)>1
Mad 22 Javi
Vlc 23 Sergio Equipo Edad Nombre
Vlc 25 Raúl Bcn 26 Álex
Mad 26 Carlos Vlc 26 Pablo
Vlc 25 Raúl
Bcn 27 Manu Bcn 27 Manu Figura 3.16
Bcn 28 Marc Bcn 28 Marc Ejemplo de una consulta
GROUP BY y HAVING.
51
3.9 Unión de consultas

Para saber más
La cláusula GROUP BY Podemos obtener el resultado de dos consultas diferentes y mostrarlas al mismo
realiza la agrupación tiempo al utilizar las llamadas consultas de unión. Para ello emplearemos la cláu-
de registros en sula UNION, que es muy sencilla y nos proporcionará en un mismo resultado los
función de unas valores obtenidos de dos tablas diferentes. Sus limitaciones son que en ella sólo
características comunes. pueden unirse dos tablas y todas las columnas asociadas tienen que tener el mis-
Posteriormente la mo tipo de valor; además, sólo devuelve resultados distintos, como si utilizáramos
cláusula HAVING
SELECT DISTINCT.
aplica una consulta
de selección de
registros agrupados A continuación, veamos una representación con figuras geométricas del contenido
anteriormente. de dos tablas, y cómo el resultado de la consulta UNION devuelve todas las figuras,
sin repetirlas, que existen tanto en la “TABLA 1” como en la “TABLA 2” (Figura 3.17).
Figura 3.17
Ejemplo de una consulta
UNION.
La consulta que representa este grafico sería:
SELECT * FROM TABLA 1

UNION
SELECT * FROM TABLA 2
3.10 Composiciones internas y nombres cualificados
Las composiciones internas, entre las que se encuentran la cláusula JOIN, son un
recurso de los lenguajes de bases de datos que permiten obtener datos relacionados
entre varias tablas, de una manera más eficiente que utilizando la cláusula UNION.
52
3.10.1 Composiciones internas
La cláusula JOIN realiza una función parecida a UNION pero es más compleja y
ofrece la posibilidad de unir más de dos tablas. Existen diferentes clases de JOIN,
pero la más utilizada es INNER JOIN, que se emplea para unir tablas mediante ope-
radores de comparación entre sus columnas (Figura 3.18).
SELECT *
FROM Equipos
INNER JOIN jugadores
ON equipo.id_equipo=jugadores.id_equipos Figura 3.18
Ejemplo de una consulta
INNER JOIN.
Veamos en el siguiente ejemplo la utilización de un INNER JOIN: en una tabla con

las siguientes personas, vemos que la columna DNI tiene un valor único para cada
registro, puesto que es la clave primaria que identifica cada una de las entradas
(Figura 3.19):
DNI Apellido Nombre Dirección Ciudad
00000001A Sánchez Pablo Gran Vía Madrid

00000002B Martínez Eduardo Diagonal Barcelona Figura 3.19
00000003B Pérez Enrique Paseo Marítimo Málaga Tabla en la que la columna DNI
es la clave primaria.
Tenemos también una tabla llamada Registro (Figura 3.20):
R_Id RegistroNo DNI

1 77895 00000001A
2 44678 00000001A
3 22456 00000002B Figura 3.20
4 24562 00000002B Tabla Registro en la que la
5 34764 00000005D columna DNI no está como
clave primaria.
Vemos que DNI también está en esta tabla, pero no como clave primaria. Aun así,
la utilizaremos para relacionarla con la tabla Personas:
53
SELECT Personas.Apellido, Personas.Nombre, Registro.Re-

gistroNo
FROM Personas
INNER JOIN Registro
ON Personas.DNI= Registro.DNI
ORDER BY Personas.Apellido
El resultado de la consulta se muestra en la figura 3.21.
Apellido Nombre OrderNo

Sánchez Pablo 77895
Sánchez Pablo 44678
Figura 3.21 Martínez Eduardo 22456
Resultado de la consulta con la
Martínez Eduardo 24562
cláusula INNER JOIN.
El INNER JOIN devuelve los registros que tienen al menos una coincidencia entre
ambas tablas en función del DNI, que es el parámetro especificado en la cláusula
“ON”. Si hay algún registro en Personas que no se encuentra en Órdenes, esta fila
no se mostrará.
La operación que acabamos de realizar también podría conseguirse con la si-

guiente consulta sin utilizar INNER JOIN:
SELECT Personas.Apellido, Personas.Nombre, Registro.Re-

gistroNo
FROM Personas, Registro
WHERE Personas.DNI= Registro.DNI
ORDER BY Personas.Apellido
Es importante remarcar que, aunque una consulta INNER JOIN también puede
realizarse con una consulta WHERE, esta última tiene un rendimiento mucho
menor, y en tablas de gran tamaño puede incrementar el tiempo de ejecución
de manera considerable. Esto es debido a que con la cláusula WHERE se realiza
la consulta de todos los registros de ambas tablas y se realiza el producto car-
tesiano (cada registro de A lo relacionamos con cada registro de B), y después
ese resultado lo filtramos, mientras que con el INNER JOIN primero se filtran los
resultados de cada tabla y después simplemente los une, sin tener que realizar
el producto cartesiano.
La clase NATURAL JOIN es una abreviación de INNER JOIN por condición de igual-
dad. Además, elimina las columnas que estén repetidas (Figura 3.22).
54
Figura 3.22
Representación de dos círculos. La
parte en rojo representa los datos
comunes de ambos círculos.
3.10.2. Nombres cualificados
Si realizamos una consulta en una sola tabla, el sistema deduce que la columna
a la que queremos acceder es la tabla que hemos definido con la cláusula FROM.
Cuando trabajamos con diferentes tablas o bases de datos, es necesario utilizar
nombres cualificados: “nombre_tabla.nombre_columna”. Se utiliza el punto para
separar el nombre del objeto y el nombre de su contenedor, con el fin de crear una
cadena de elementos que representa el objeto y el lugar al que pertenece.
3.11 Composiciones externas
Las composiciones externas se utilizan para realizar consultas uniendo dos o

más tablas; pero, a diferencia de las composiciones internas (INNER JOIN), no es
Recuerda
necesario que cada registro de una tabla tenga una correspondencia con las de- Existen muchos tipos de
más. El registro se mantiene en la tabla combinada, rellenando las columnas que JOIN y las construcciones
no tengan información con valores NULL. de estas consultas
pueden llegar a ser
complicadas.
Para crear la composición externa, usaremos la cláusula OUTER JOIN (unión exter-
na) junto a los parámetros RIGHT (derecha), LEFT (izquierda) o FULL (todo).
Veamos a continuación las tablas de la figura 3.23, que utilizaremos para realizar
los ejemplos de los diferentes tipos de OUTER JOIN:
Tabla Empleado Tabla Departamento

Apellido IDDepartamento Nombre Departamento IDDepartamento
Sánchez 31 Dirección 31
Martínez 33 Informática 33
Gutiérrez 33 Comercial 34
Pérez 34 Contable 35
Figura 3.23
Moreno 34
García 36
Tablas de ejemplo utilizadas en
los ejercicios de OUTER JOIN.
55
●● LEFT. Se añadirán las filas de la primera tabla que se haya definido en la cláusula
FROM (Figura 3.24):
SELECT *
FROM empleado
LEFT OUTER JOIN departamento
ON empleado.IDDepartamento = departamento.IDDepartamento
Empleado. Apellido Empleado.IDDepartamento Departamento. Nombre Departamento Empleado.IDDepartamento
Pérez 34 Comercial 34
Moreno 34 Comercial 34
Figura 3.24 García 36 NULL NULL
Resultado de la ejecución de la Gutiérrez 33 Informática 33
cláusula LEFT.
Podemos ver como el registro García de la tabla Empleado aparece en el re-

sultado relacionado con valores NULL al no haber una correspondencia con la
tabla Departamento.
●● RIGHT. Se añadirán las filas de la segunda tabla que se haya definido en la cláu-
sula FROM (Figura 3.25):
SELECT *
FROM empleado
RIGHT OUTER JOIN departamento
Empleado. Apellido Empleado.IDDepartamento Departamento. NombreDepartamento Empleado.IDDepartamento
Gutiérrez 33 Informática 33
Figura 3.25
Resultado de la ejecución de la
NULL NULL Contable 35
cláusula RIGHT.
56
Podemos ver como el registro Contable de la tabla Departamento aparece en el resultado,

relacionado con valores NULL, al no haber una correspondencia con la tabla Empleado.
FULL. Se añadirán las filas de las dos tablas definidas en la cláusula FROM (Figura 3.26).
SELECT *
FROM empleado
FULL OUTER JOIN departamento
Empleado. Apellido Empleado.IDDepartamento Departamento. Nombre Departamento Empleado.IDDepartamento
García 36 NULL NULL
Gutiérrez 33 Informática 33
Figura 3.26
Resultado de la ejecución de la
NULL NULL Contable 35
cláusula FULL.
En este caso, el registro García aparece en el resultado relacionado con valores

NULL, así como el departamento Contable, que también tiene valores nulos. Si
hubiéramos realizado esta misma consulta con un inner join, los resultados con
valores null no hubieran aparecido en el resultado.
3.12 Subconsultas. Ubicación de subconsultas. Subconsultas anidadas
Una subconsulta es una instrucción SELECT anidada dentro de otra instrucción SE-
LECT, INSERT, DELETE o UPDATE, o incluso dentro de otra subconsulta, formando de
esta manera una cadena de consultas anidadas. La tabla de la figura 3.27 muestra
los tres tipos de sintaxis que pueden utilizarse para realizar las subconsultas.
Comparación [Comparación} (instrucción SQL)
Comparación cuantificada [Comparación] [ANY | ALL | SOME] (instrucción SQL)
Pertenencia a un conjunto Expresión [NOT] IN (instrucción SQL)

Figura 3.27
Existencia [NOT] EXIST (instrucción SQL)
Tabla de tipos de subconsultas.
57
Para saber más 3.12.1 Comparación

Las consultas con Se realizan operaciones lógicas para comparar un valor de la fila actual con el valor
comparaciones son más
devuelto por la subconsulta. En este tipo de operación, las subconsultas deben
fáciles de componer
que las consultas con hacerse en una única columna, y nunca debe realizarse de manera que devuelva
JOIN y, en ocasiones, como resultado más de una columna.
realizan las mismas
funciones. Sin embargo, El siguiente ejemplo de comparación devuelve cualquier ciudad que tenga más
en tablas grandes, las habitantes que Girona:
comparaciones no son
viables ya que consumen SELECT ciudad
muchos más recursos FROM Cataluña
que las composiciones WHERE habitantes > (SELECT SUM(personas) FROM Girona)
internas JOIN.
3.12.2 Comparación cuantificada
Se realizan operaciones lógicas para comparar un valor de la fila actual con cada
uno de los valores devueltos por la subconsulta. En este tipo de operación, las
subconsultas deben hacerse en una única columna, nunca deben realizarse de
manera que devuelva como resultado más de una columna.
Existen tres cláusulas que podremos aplicar junto a esta consulta: ANY (ninguno),
ALL (todos) y SOME (alguno).
●● ANY. Devolverá un resultado verdadero en caso de que alguna de las compa-

raciones produzca un resultado verdadero; en caso contrario, devolverá falso o
NULL.
●● ALL. Devolverá un resultado verdadero en caso de que todas las comparaciones

produzcan un resultado verdadero; en caso contrario, devolverá falso o NULL.
●● SOME. Es equivalente a la cláusula ANY.
En el siguiente ejemplo, seleccionaremos todas las mujeres cuya edad sea mayor
a la de cualquier hombre:
SELECT Empleado.Nombre
FROM Empleados
WHERE Sexo=’M’ and Edad > ANY (
SELECT Empleados.Edad FROM Empleados WHERE Sexo=’H’
)
58
3.12.3 Pertenencia a conjunto (IN)
Se comprobará si existe el valor de la consulta en alguno de los resultados produ-

cidos por la subconsulta. En este tipo de operación, la subconsulta debe hacerse
en una única columna, nunca debe realizarse de manera que devuelva como re-
sultado más de una columna.
El ejemplo siguiente devuelve todos los productos vendidos con un descuento

igual o mayor al 50 por ciento:
SELECT *
FROM Productos
WHERE id_producto IN(
SELECT id_producto FROM Pedido WHERE Descuento= 0.5
)
3.12.4 Existencia (EXISTS)
La cláusula existencia comprobará si la subconsulta produce algún resultado. Si

ésta devuelve algún resultado, la operación devolverá el valor verdadero. En este
tipo de operación, la subconsulta puede devolver varias columnas, puesto que no
nos importa el valor sino la existencia, o no, de resultado. En la figura 3.28 puede
verse una representación con figuras geométricas del contenido de dos tablas y
cómo el resultado de la consulta EXISTS devuelve todas las figuras que existen en
la TABLA 1 que, además, existen en la TABLA 2.
Figura 3.28
Ejemplo de subconsultas
con la cláusula EXISTS.
59
El siguiente ejemplo devolverá todos los clientes que hayan hecho, al menos, una
compra:
SELECT cliente
FROM clientes
WHERE EXISTS (
SELECT * FROM pedidos WHERE pedido.id_cliente=Cliente.
id_cliente
)
60
Resumen
Los SGDB (Sistemas gestores de Bases de datos) proporcionan a usuarios y administradores la posi-
bilidad de manejar las bases de datos de una manera gráfica e intuitiva. Suponen una mejora impor-
tante en la que no es necesario el conocimiento experto en programación de bases de datos para
poder realizar consultas o tareas de mantenimiento en la base de datos.
Las consultas son leídas por las bases de datos para poder realizar gestiones de mantenimiento, inser-
ción de registro u obtención de la información almacenada en las bases de datos. La consulta SELECT
es utilizada por los usuarios para obtener datos almacenados, seleccionados según los criterios y
condiciones que acompañan la instrucción.
Dentro de las opciones de las consultas, es posible obtener resultados en un determinado orden o
extraer aquella información que entra dentro de los parámetros establecidos por el usuario. Estos
parámetros son definidos mediante operadores de comparación, lógicos o de precedencia. Otra de
las posibilidades de la sentencia SELECT consiste en anidar consultas, con lo que se consigue que una
petición sea aplicada sobre el resultado de una consulta anterior.
61
Bases de datos
1. La sentencia SELECT (seleccionar) es, sin duda, la menos utilizada en una base
de datos. Su objetivo es obtener la información que precisemos de la base de
datos, y su complejidad dependerá de la consulta que realicemos.
2. Los sinónimos son un recurso para facilitar la construcción de sentencias. Si que-

remos efectuar operaciones entre diferentes tablas, debemos concatenar la ta-
bla con sus respectivos campos, utilizando el punto (.).
3. La precedencia es única para cada operando, y define el orden en el que la con-
sulta calcula las operaciones aritmético-lógicas.
4. La cláusula JOIN realiza una función parecida a UNION pero es más sencilla y
ofrece la posibilidad de unir más de dos tablas.
5. Las composiciones externas se utilizan para realizar consultas uniendo dos o

más tablas; pero es necesario que cada registro de una tabla tenga una corres-
pondencia con las demás.
6. Una subconsulta es una instrucción SELECT anidada dentro de otra instrucción

SELECT, INSERT, DELETE o UPDATE, o incluso dentro de otra subconsulta, for-
mando de esta manera una cadena de consultas anidadas.
7. Se realizan operaciones lógicas para comparar un valor de la fila actual con el
valor devuelto por la subconsulta. En este tipo de operación, las subconsultas
deben hacerse en varias columnas.
8. Las funciones de agregado son el complemento para realizar las _________

resumen. Se trata de funciones que aplican ______________ a un conjunto de
valores y devuelven un único ______________.
9. La cláusula existencia comprobará si la ______________ produce algún resul-

tado. Si esta devuelve algún ______________ , la operación devolverá el valor
______________.
62
10. Si realizamos una consulta en una sola tabla, el ______________ deduce que
la columna a la que queremos acceder es la ______________ que hemos de-
finido con la cláusula ______________.

63
4. TRATAMIENTO DE DATOS
En este apartado analizaremos el tratamiento de datos, que consiste en intro-

ducir, modificar y eliminar la información de las bases de datos. Sin embargo, en
el tratamiento de datos no sólo influyen factores como la simple obtención de
información, sino también los permisos y los problemas de acceso simultáneo.
4.1 Tratamiento de datos
Para poder realizar consultas a bases de datos, deberemos previamente haber

introducido toda la información necesaria de manera estructurada y ordenada,
teniendo en cuenta los numerosos factores relacionados con los permisos de ac-
ceso a la información y evitando la modificación simultánea de los datos. Podemos
definir el tratamiento de datos en tres fases principales:
●● Inserción de registros. Se trata de subir a la base de datos toda la información que

queremos almacenar. Deberemos tener en cuenta el tipo de datos que acepta la
base de datos (número, cadena de caracteres, etc.) y también el tamaño de éstos,
puesto que tendremos un espacio limitado para albergar los datos (Figura 4.1).
●● Modificación de registros. Consiste en manipular la información ya existente

en la base de datos con el fin de modificar los datos a consultar.
●● Eliminación de registros. Para el buen mantenimiento de la base de datos es

conveniente proceder a la eliminación de registros innecesarios con el fin de
liberar espacio en el disco duro y mejorar la indexación.
Figura 4.1
Introducción de información de
varios usuarios en la base de datos.
64
Tratamiento de datos
4.2 Herramientas gráficas proporcionadas por el sistema gestor

para la edición de la información
El tratamiento de los datos puede resultar complicado debido a una serie de fac-
tores que deberemos tener en cuenta, como es el caso de la eliminación de datos
dependientes. Por ello, los sistemas gestores proporcionan herramientas grafi-
cas para poder realizar las funciones de mantenimiento y tratamiento de la infor-
mación de manera sencilla e intuitiva a fin de evitar al usuario tener que utilizar
consultas construidas a mano.
Los datos se representan generalmente en forma de tabla, lo que ofrece al usuario

la opción de insertar nuevos registros. En ese caso, aparecerá en nuestra tabla una
nueva fila con la información que acabamos de añadir.
Una de las principales ventajas que ofrecen las herramientas gráficas es el trata-
miento de la información por bloques; es decir, podemos crear, eliminar y modifi-
car varios registros en un solo paso, en lugar de realizar varias consultas para cada
una de las filas.
4.3 Inserción de registros. Inserciones a partir de una consulta
A pesar de disponer de las herramientas graficas para el tratamiento de la informa-

ción, es preciso saber cómo podremos modificar los datos mediante la utilización Para saber más
de las consultas. Deberemos utilizar dichas consultas cuando tengamos que inser- Una vez insertado un
tar nueva información mientras ejecutamos un programa. La consulta encargada nuevo registro, solo
de insertar información en una base de datos se llama INSERT (insertar). podremos introducir
nueva información
Veamos a continuación cuál es la sintaxis básica de una consulta INSERT (Figura 4.2): mediante una consulta
de modificación, puesto
●● INSERT INTO (insertar en). Crea un nuevo registro. Seguido de la sentencia IN- que la sentencia INSERT
SERT INTO definiremos la tabla en la que se creará el registro, y enumeraremos sirve para crear nuevos
registros.
entre paréntesis los campos en los que queremos insertar los datos.
●● VALUES (valores). Introduciremos entre paréntesis los valores con los que que-
ramos inicializar el registro que estamos creando.
INSERT INTO [nombre tabla](columna1,columna2)

Figura 4.2
VALUES (valor1,valor2) Estructura de una sentencia
INSERT.
65
Cuando ejecutamos la consulta INSERT, crearemos una nueva fila en la tabla defi-
nida. Deberemos introducir los datos de todas las columnas que componen dicha
tabla, pues, de lo contrario, los datos que insertemos obtendrían el valor NULL (nulo),
que, a veces, puede producir un error, ya que no todos los campos aceptan este
valor. Veamos en la tabla de la figura 4.3 un ejemplo de cómo insertar un registro.

Figura 4.3 1 Sánchez Pablo Barcelona
Tabla PERSONAS antes de 2 Martínez Sergio Madrid
insertar la fila. 3 Pérez Álex Santander
Para insertar una nueva persona en nuestra tabla (Figura 4.4) bastará con ejecutar
la siguiente sentencia:
INSERT INTO PERSONAS

P_Id, Apellido, Nombre, Ciudad
values
4,Pérez, Juan, Málaga

1 Sánchez Pablo Barcelona
Figura 4.4 2 Martínez Sergio Madrid
Tabla PERSONAS después de 3 Pérez Álex Santander
insertar la fila. 4 Pérez Juan Málaga
4.4 Borrado y modificación de registros
Otros tratamientos de datos fundamentales para el mantenimiento de la base de

datos es el borrado de registros innecesarios y la modificación de registros
para actualizar la información almacenada.
4.4.1 Borrado de registros
El borrado de registros es una operación que muchas veces se pasa por alto, pues se
tiende a creer que si una determinada información no nos interesa basta con no acce-
der a ella. Sin embargo, eso comporta una masificación de la base de datos, que, con el
tiempo, puede almacenar gran cantidad de información innecesaria y ocupar un con-
siderable espacio de almacenamiento. Por ello, una vez nos hayamos asegurado de
que los datos son realmente innecesarios es conveniente proceder a su eliminación.
Para ello, podemos realizar el borrado desde las herramientas gráficas proporcionadas
por el sistema gestor o mediante la consulta DELETE (eliminar) (Figura 4.5):
66
DELETE FROM [tabla] Figura 4.5

WHERE [condición] Estructura de una sentencia
DELETE.
●● DELETE FROM. Elimina un registro que se encuentra en la tabla definida.
●● WHERE. Definiremos las condiciones que tienen que cumplir los registros que de- Para saber más
seamos borrar. Es especialmente útil en los casos en los que los registros tienen un
número de identificación único, para que la consulta aplique las modificaciones Si al eliminar un registro
no defines una condición
de los datos sólo en el registro que deseamos. Podremos eliminar más de un re-
en la cláusula WHERE, se
gistro en una misma consulta si sus datos coinciden con la condición establecida. borrarán todos los datos
de la tabla seleccionada.
En la misma tabla obtenida en el apartado anterior, vamos a ejecutar una senten-
cia para eliminar uno de sus registros (Figura 4.6).

1 Sánchez Pablo Barcelona
2 Martínez Sergio Madrid Figura 4.6
3 Pérez Álex Santander Tabla PERSONAS antes de borrar
4 Pérez Juan Málaga la fila.
Según esta sentencia:
DELETE FROM Personas

WHERE Apellido=’Pérez’ AND Nombre=’Juan’
Obtendremos la tabla de la figura 4.7.

1 Sánchez Pablo Barcelona Figura 4.7
2 Martínez Sergio Madrid Tabla PERSONAS después de
3 Pérez Álex Santander borrar la fila.
Si a la tabla original le aplicamos esta sentencia:
DELETE FROM Personas

WHERE Apellido=’Pérez’ OR Apellido=’Martínez’
Obtendremos la tabla de la figura 4.8.

Figura 4.8
P_Id Apellido Nombre Ciudad Tabla PERSONAS después de
1 Sánchez Pablo Barcelona borrar varias filas.
67
4.4.2 Modificación de registros
Una vez creados los registros resultará indispensable disponer de la opción de mo-
dificar dicha información. Desde las herramientas gráficas, podremos modificar el
contenido de los registros, pero también podremos utilizar la consulta UPDATE
(actualizar) (Figura 4.9):
●● UPDATE. Modifica los datos de un registro. Seguida de esta cláusula definiremos

la tabla en la que se encuentran los registros que deseamos modificar.
●● SET. Definiremos tanto el campo que queremos modificar como el nuevo valor
que deseamos introducir. Podremos definir más de un campo que deseemos
modificar, separándolo por comas.
●● WHERE. Definiremos las condiciones que tienen que cumplir los registros que
deseamos modificar. Es especialmente útil en los casos en los que los registros
tienen un número de identificación único, con el fin de que las consultas apli-
quen las modificaciones de los datos sólo al registro que deseemos. Podremos
modificar más de un registro en una misma consulta si sus datos coinciden con
la condición establecida.
UPDATE [nombre tabla]

Figura 4.9 SET [campo1] = [valor1],[campo2] = [valor2],
Estructura de una sentencia
WHERE [condición del registro]
UPDATE.
A modo de ejemplo, tenemos las siguientes tablas:
Tabla de ciudades (Figura 4.10):
Ciudad País
Barcelona España
Madrid Alemania
Figura 4.10 Santander Francia
Tabla de ciudades y países. Málaga Rusia
Tabla de personas (Figura 4.11):
P_Id Apellido Nombre Ciudad País

1 Sánchez Pablo Barcelona España
2 Martínez Sergio Madrid Alemania
Figura 4.11 3 Pérez Álex Santander Francia
Tabla de personas. 4 Pérez Juan Málaga España
68
Podemos aplicar la sentencia UPDATE haciendo referencia a las dos tablas:
UPDATE Personas, Ciudades

SET Pais=’España’
WHERE Ciudad=’Madrid’
Veremos entonces que en las dos tablas ha cambiado el País por España en los
registros en los que el valor de la ciudad es Madrid.
Ciudad País
Barcelona España Figura 4.12
Madrid España
Santander Francia Tabla Ciudades antes de
Málaga España actualizar las filas.

1 Sánchez Pablo Barcelona España Figura 4.13
2 Martínez Sergio Madrid España
3 Pérez Álex Santander Francia Tabla Personas antes de
4 Pérez Juan Málaga España actualizar las filas.
Si no ponemos ninguna condición al ejecutar la sentencia UPDATE, se cambiarán

todos los registros de la tabla:
UPDATE Personas, Ciudades

SET Pais=’España’
Ciudad País
Barcelona España Figura 4.14
Madrid España
Santander España Tabla Ciudades después de
Málaga España actualizar las filas.

1 Sánchez Pablo Barcelona España Figura 4.15
2 Martínez Sergio Madrid España
3 Pérez Álex Santander España Tabla Personas después de
4 Pérez Juan Málaga España actualizar las filas.
69
4.5 Borrados y modificaciones, integridad referencial. Cambios

en cascada
El mayor inconveniente cuando realizamos cambios en los datos mediante el bo-

rrado y la modificación de registros es la integridad referencial. Debemos tener
en cuenta que las bases de datos siguen un modelo relacional (Figura 4.16), lo que
significa que las tablas están interconectadas entre sí. Si elimináramos un registro
al que hace referencia otra tabla, no haríamos más que dejar dicha tabla “huérfa-
na”, lo que pondría en peligro la integridad estructural de la base de datos. Para
solucionar este problema, deberíamos repasar todas las tablas y modificar esos
registros, lo que supondría un insigne trabajo e, incluso, en bases de datos de gran
tamaño, resultaría inviable. Por esta razón, los sistemas gestores ofrecen la función
que permite realizar los cambios en cascada, una tarea que consiste en analizar
todas las tablas de la base de datos y aplicarles, de manera automática, los cambios
necesarios a aquellos registros que hagan referencia a los datos modificados.
Figura 4.16
Estructura del modelo relacional
y la dependencia de datos.
Para que esto sea posible, es necesario establecer correctamente las relaciones
entre claves primarias y claves foráneas entre las tablas.
En el siguiente ejemplo vemos como la tabla padre tiene la clave primaria id “PRI-
MARY KEY (id)” y que la tabla hijo tiene la instrucción “FOREIGN KEY (padre_id)” que
indica que su atributo padre_id está vinculado a la id de la tabla padre “REFEREN-
CES padre(id)”. Esto significa que, si eliminamos el registro padre (o modificamos
70
la ID), existirá un registro hijo que quedará huérfano y se producirá un error de

integridad referencial. Para solucionarlo, disponemos de las instrucciones ON UP-
DATE y ON DELETE, que se encargan de modificar automáticamente el registro de
la tabla hijo, al realizar modificaciones en la tabla padre. Los cambios pueden ser:
FOREIGN KEY [id] (nombre_índice, ...)

REFERENCES nombre_de_tabla (nombre_índice, ...)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
Dichos cambios soportan los siguientes modificadores:
●● CASCADE: modifica el valor de la clave foránea por el nuevo valor.

●● SET NULL: modifica la clave foránea y pone el valor NULL.
●● NO ACTION: omite la sentencia ON UPDATE y ON DELETE, con lo que no se rea-
liza ninguna acción.

●● RESTRICT: es equivalente a NO ACTION.
CREATE TABLE padre(

id INT NOT NULL,
PRIMARY KEY (id)
) ENGINE=INNODB;
CREATE TABLE child(

id INT,
padre_id INT,
nombre CHAR
FOREIGN KEY (padre_id)
REFERENCES padre(id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=INNODB;
4.6 Subconsultas y composiciones en órdenes de edición
Las órdenes de edición son ejecuciones de consultas realizadas en el núcleo del

servidor sin necesidad de implicar al usuario.
Se ejecutan al cumplir cierta condición definida previamente y suelen utilizarse

para el mantenimiento de los datos; por ejemplo, eliminar una tabla de datos tem-
porales al llegar a un número determinado de registros.
71
4.7 Transacciones. Sentencias de procesamiento de transacciones
Las transacciones son unidades de trabajo independiente. Si una unidad de tra-

bajo se realiza con éxito, todas las modificaciones de datos realizadas durante la
transacción se harán efectivas. Esto es especialmente útil para el control de errores:
en un proceso en el que se realizan varias operaciones, se utiliza el sistema de tran-
sacciones con el fin de que, en el caso de que se produzca algún error durante el
proceso, todos los datos vuelvan a su estado inicial.
Un ejemplo claro es una transacción bancaria, en la que antes de descontar el dinero

de una cuenta origen hay que confirmar que se ha ingresado en el banco de destino:
BEGIN TRANSACTION transfer2;

INSERT INTO Cuenta2 VALUES(100);
INSERT INTO Cuenta1 VALUES(-100);
ROLLBACK;
COMMIT TRANSACTION transfer2;
BEGIN TRANSACTION transfer1;
INSERT INTO Cuenta2 VALUES(100);
INSERT INTO Cuenta1_noexiste VALUES(-100);
*Comprobación de Cuenta1_noexiste
**Si hay algun error se deshace únicamente transfer1
ROLLBACK;
Al ejecutar esta sentencia se realizará la transfer2 que ha sido confirmada median-

te la sentencia COMMIT antes de ejecutar el ROLLBACK , mientras que la transfer1
no se ejecutará debido a que la cuenta destino no exite.
4.8 Problemas asociados al acceso simultáneo a los datos
Un problema común en el tratamiento de datos es el acceso simultáneo. Los

usuarios que están modificando datos pueden afectar a otros usuarios que están
leyendo o modificando dichos datos. (Figura 4.17). Veamos cómo:
●● Mediante actualizaciones perdidas. Sucede cuando varios usuarios modifican

los mismos datos. El sistema sólo guardará la última modificación realizada y
perderá el resto.
●● Mediante una dependencia no confirmada. Sucede cuando un usuario lee un

dato que está siendo modificado por una transacción. Es posible que la transac-
ción sea errónea y devuelva el valor a su estado original.
72
Figura 4.17
Acceso simultáneo a los datos.
Un ejemplo claro al respecto podemos verlo en las páginas web de reserva de ho-
teles, en las que varias personas pueden ver que la Suite Nupcial está libre e iniciar
la reserva, pero al terminar de rellenar los datos el sistema impide que se finalice el
proceso porque otro usuario ha realizado la reserva con anterioridad. Si no se con-
trolase esta situación, la última persona que ha reservado la habitación sustituiría
la reserva de la primera, produciéndose un caso de actualización perdida.
4.9 Bloqueos compartidos y exclusivos. Políticas de bloqueo
En las bases de datos es habitual que varios usuarios accedan a los mismos datos
simultáneamente. Por ello, hay que tener en cuenta qué políticas de acceso debe-
mos aplicar en el caso de realizar modificaciones sin que afecten al resto de usua-
rios, es decir, tenemos que decidir cuál es nuestra política de gestión de bloqueos.
Veamos cuáles son:
●● Bloqueo compartido. Se utiliza para operaciones de lectura que no cambian ni

actualizan datos, como la instrucción SELECT.
●● Bloqueo exclusivo. Se utiliza para operaciones de modificación de datos, como

INSERT, UPDATE o DELETE. Garantiza que no puedan realizarse varias actualiza-
ciones simultáneamente en el mismo recurso.
Podemos dividir las políticas de bloqueo de acceso en dos tipos:
●● Control de simultaneidad optimista. Las operaciones de lectura no bloquean

las operaciones de modificación de datos; es decir, un usuario puede modificar
los datos aunque otro los esté leyendo en ese momento.
73
●● Control de simultaneidad pesimista. Es aquel que garantiza que las operacio-

nes de lectura tengan acceso a los datos actuales y los bloques para que no
puedan ser modificados por otros usuarios (Figura 4.18).
Figura 4.18
Restricción a los otros usuarios
por parte del cliente A mientras
modifica los datos.
Si tomamos el ejemplo anterior, un control de simultaneidad pesimista sería el

ideal para asegurarse de que otros usuarios no puedan reservar la Suite Nupcial
una vez iniciado el propio proceso de reserva. Al realizar una lectura de la infor-
mación de la Suite y hacer clic en “Reservar”, el sistema creará un bloqueo en ese
registro que no permitirá que nadie más modifique los datos. Una vez hecha la
reserva o cerrada la página, el bloqueo terminará.
74
Resumen
Como en el caso de la obtención de datos, existen consultas para realizar modificaciones en las bases
de datos, como la inserción o eliminación de registros. La inserción de un nuevo registro se lleva a
cabo mediante la sentencia INSERT, en la que estableceremos la tabla en la que deseamos introducir
los datos, así como cada una de las columnas con su respectivo valor.
La modificación se realiza con la consulta UPDATE, y al igual que con la sentencia INSERT, será nece-
sario definir la tabla y cada una de las columnas a las que se desea aplicar la modificación, así como
también el nuevo valor. Hay que tener muy en cuenta que, además de la tabla a la que pertenece el
registro, deberemos introducir una condición para seleccionar el registro que será modificado, ya que
de lo contrario se realizarían sobre todos los registros. En estos casos, es especialmente útil una clave
primaria que identifique inequívocamente cada fila de la tabla.
La eliminación se lleva a cabo mediante la consulta DELETE, en la que, como en la modificación, de-
beremos especificar mediante una cláusula condicional el registro que deseamos borrar.
Generalmente, a las bases de datos acceden varios usuarios, por lo que hay que tener en cuenta las
políticas de restricción y uso exclusivo a la hora de realizar modificaciones en los datos. De esta ma-
nera evitaremos errores de acceso en el momento de realizar la modificación.
Por último, deberemos tener en cuenta que la naturaleza de las bases de datos relacionales implica
que varias tablas, y por lo tanto sus datos, estén interrelacionadas, por lo que es posible borrar un
registro que esté siendo referenciado desde otra tabla; si esto ocurre se genera un error de integridad
referencial. Para solucionar estas situaciones, las bases de datos ofrecen la opción de los cambios en
cascada con los que, al realizarse un cambio en un registro referenciado, la modificación es aplicada
a todas las demás tablas de manera automática.
75
1. Para crear un nuevo registro, seguido de la sentencia INSERT INTO definiremos el

registro en el que se creará la tabla, y enumeraremos entre paréntesis los cam-
pos en los que queremos insertar los datos.
2. UPDATE modifica los datos de un registro. Seguida de esta cláusula definiremos

la tabla en la que se encuentran los registros que deseamos modificar.
3. Las órdenes de edición son ejecuciones de consultas realizadas en el núcleo del

servidor, con la necesidad de implicar siempre al usuario.
4. Si una unidad de trabajo se realiza con éxito, todas las modificaciones de datos
realizadas durante la transacción se harán efectivas.
5. Los usuarios que están modificando datos no afectan a otros usuarios que están
leyendo o modificando dichos datos.
6. El control de simultaneidad pesimista es aquel que garantiza que las operacio-
nes de lectura tengan acceso a los datos actuales y los bloques para que sí pue-
dan ser modificados por otros usuarios
7. La eliminación se lleva a cabo mediante la consulta DELETE, en la que, como en

la modificación, deberemos especificar mediante una cláusula condicional el
registro que deseamos borrar.
8. Para el buen mantenimiento de la base de datos es conveniente proceder a la

______________ de registros innecesarios con el fin de ______________ espa-
cio en el disco duro y mejorar la ______________.
9.
Cambios en cascada: es una tarea que consiste en analizar todas las
______________ de la base de datos y aplicarles, de manera ______________ ,
los cambios necesarios a aquellos registros que hagan referencia a los datos
______________.
76
10. En las bases de datos es habitual que ______________ usuarios accedan a
los mismos datos ______________. Por ello, hay que tener en cuenta qué
______________ debemos aplicar en el caso de realizar modificaciones sin
que afecten al resto de usuarios, es decir, tenemos que decidir cuál es nuestra
______________.

77

Unidad 3
1. F. La sentencia SELECT (seleccionar) es, sin duda, la más utilizada en una base
de datos. Su objetivo es obtener la información que precisemos de la base de
datos, y su complejidad dependerá de la consulta que realicemos.
2. V
3. V
4. F. La cláusula JOIN realiza una función parecida a UNION pero es más compleja y
ofrece la posibilidad de unir más de dos tablas.
5. F. Las composiciones externas se utilizan para realizar consultas uniendo dos o
más tablas; pero no es necesario que cada registro de una tabla tenga una co-
rrespondencia con las demás.
6. V
7. F. Se realizan operaciones lógicas para comparar un valor de la fila actual con el
valor devuelto por la subconsulta. En este tipo de operación, las subconsultas
deben hacerse en una única columna.
8. consultas, cálculos, resultado.
9. subconsulta, resultado, verdadero.
10. sistema, tabla, FROM.
Unidad 4
1. F. Para crear un nuevo registro, seguido de la sentencia INSERT INTO definiremos
la tabla en la que se creará el registro, y enumeraremos entre paréntesis los cam-
pos en los que queremos insertar los datos.
2. V
3. F. Las órdenes de edición son ejecuciones de consultas realizadas en el núcleo
del servidor sin necesidad de implicar al usuario.
4. V
5. F. Los usuarios que están modificando datos pueden afectar a otros usuarios que
están leyendo o modificando dichos datos.
6. F. El control de simultaneidad pesimista es aquel que garantiza que las opera-
ciones de lectura tengan acceso a los datos actuales y los bloques para que no
puedan ser modificados por otros usuarios.
7. V
8. eliminación, liberar, indexación.
9. tablas, automática, modificados.
10. varios, simultáneamente, políticas de acceso, política de gestión de bloqueos.
78
Índice
Índice
MÓDULO: BASES DE DATOS
UNIDAD FORMATIVA 2
3. Realización de consultas ............................................................................................................................................................ 42

3.1 Herramientas gráficas proporcionadas por el sistema gestor para la realización de consultas ..... 42
3.2 La sentencia SELECT ...................................................................................................................................................................... 44
3.3 Consultas calculadas. Sinónimos ........................................................................................................................................... 45
3.3.1 Consultas calculadas .......................................................................................................................................................... 46
3.3.2 Sinónimos ................................................................................................................................................................................. 46
3.4 Selección y ordenación de registros .................................................................................................................................... 46
3.5 Operadores .......................................................................................................................................................................................... 48
3.5.1 Operadores de comparación ........................................................................................................................................ 48
3.5.2 Operadores lógicos ............................................................................................................................................................. 49
3.5.3 La precedencia ..................................................................................................................................................................... 49
3.6 Tratamiento de valores nulos ................................................................................................................................................... 50
3.7 Consultas de resumen y funciones de agregado ........................................................................................................ 50
3.8 Agrupamiento de registros. ....................................................................................................................................................... 51
3.9 Unión de consultas ......................................................................................................................................................................... 52
3.10 Composiciones internas y nombres cualificados ...................................................................................................... 52
3.10.1 Composiciones internas ............................................................................................................................................. 53
3.10.2. Nombres cualificados .................................................................................................................................................. 55
3.11 Composiciones externas ........................................................................................................................................................... 55
3.12 Subconsultas. Ubicación de subconsultas. Subconsultas anidadas .............................................................. 57
3.12.1 Comparación ..................................................................................................................................................................... 58
3.12.2 Comparación cuantificada ........................................................................................................................................ 58
3.12.3 Pertenencia a conjunto (IN) ...................................................................................................................................... 59
3.12.4 Existencia (EXISTS) .......................................................................................................................................................... 59
Resumen ........................................................................................................................................................................................................ 61
4. Tratamiento de datos .................................................................................................................................................................... 64

4.1 Tratamiento de datos .................................................................................................................................................................... 64
79
4.2 Herramientas gráficas proporcionadas por el sistema gestor para la edición de la información . 65
4.3 Inserción de registros. Inserciones a partir de una consulta ................................................................................. 65
4.4 Borrado y modificación de registros .................................................................................................................................... 66
4.4.1 Borrado de registros ........................................................................................................................................................... 66
4.4.2 Modificación de registros ................................................................................................................................................ 68
4.5 Borrados y modificaciones, integridad referencial. Cambios en cascada ..................................................... 70
4.6 Subconsultas y composiciones en órdenes de edición .......................................................................................... 71
4.7 Transacciones. Sentencias de procesamiento de transacciones ....................................................................... 72
4.8 Problemas asociados al acceso simultáneo a los datos ........................................................................................... 72
4.9 Bloqueos compartidos y exclusivos. Políticas de bloqueo .................................................................................... 73
Resumen ........................................................................................................................................................................................................ 75
80
uNIDAD FORMATIVA 3
• Programación de base de datos
• Interpretación de diagramas Entidad/Relación
• Uso de bases de datos relacionales

5. PROGRAMACIÓN DE BASES DE DATOS
En esta unidad estudiaremos los conceptos necesarios para introducirnos en los

lenguajes de programación. La programación está estrechamente relacionada
con las bases de datos, ya que la información que se extrae de estas últimas es po-
sible manejarla mediante las sentencias y los flujos de control que proporcionan
los lenguajes de programación.
De la misma manera, los lenguajes de programación carecerían de sentido en al-

gunas situaciones si no tuviesen la posibilidad de acceder a datos almacenados
fuera del código que se está ejecutando.
Las bases de datos nos proporcionan la posibilidad de programar sentencias que

se ejecuten internamente en el servidor de manera desatendida por parte del
usuario. En este caso, no basta con saber ejecutar consultas, sino que es necesario
tener un buen nivel de programación para desarrollar estructuras de instrucciones
que funcionen correctamente.
5.1 Introducción. Lenguaje de programación
Los lenguajes de programación son idiomas concebidos para poder crear expre-
siones que posteriormente serán interpretadas por un ordenador.
Estos lenguajes suelen ser utilizados por los administradores de las bases de datos
para automatizar tareas de mantenimiento, al poder ser ejecutadas por el sistema
Para saber más de manera desatendida. Además, los lenguajes permiten la creación de estructu-
Entendemos por ras de control para ejecutar unas determinadas consultas según las necesidades e
sistema desatendido la incluso programar procesos de almacenamiento. Cada tipo de base de datos tiene
aplicación de cambios su propio lenguaje de programación. En esta unidad estudiaremos el lenguaje PL/
en el sistema sin que sea
SQL para las bases de datos PostgresSQL.
necesaria la supervisión
ni intervención por
parte de ningún usuario
o administrador. Las 5.2 Palabras reservadas
ejecuciones de tareas
desatendidas se emplean Las palabras reservadas son aquellas expresiones que forman parte del propio
en tareas mecánicas lenguaje de programación y no pueden ser utilizadas por el usuario durante el pro-
o repetitivas en las ceso de programación. Varían según el lenguaje y deberemos tenerlas muy pre-
que no es necesaria la sentes a la hora de programar, puesto que tienen una función determinada en ese
intervención de ninguna lenguaje y no es posible utilizarla fuera de su contexto. En el lenguaje PL/SQL se
persona.
utilizan, por ejemplo, las palabras BEGIN y END para definir el inicio y el fin de una
82
Programación de base de datos
zona de ejecución respectivamente. En la figura 5.1 podemos ver algunas de las

palabras reservadas más comunes de los lenguajes de programación.
Figura 5.1
Lista de variables reservadas.
5.3 Variables del sistema y variables de usuario
Las variables de entorno forman un conjunto de valores dinámicos que normalmen-

te afectan el comportamiento de los procesos. Las variables son elementos de la pro-
gramación compuestos por valores dinámicos que serán utilizados por los procesos
de un programa. Normalmente, dispondremos de dos tipos de variables: del sistema
y de usuario (Figura 5.2).
Figura 5.2
Variables del sistema
y de usuario.
83
5.3.1 Variables del sistema
Son creadas por el entorno para almacenar información del sistema. Un ejemplo
sería la variable DATE, que almacena la fecha actual, o SYSTEM, con información del
sistema que ejecuta la aplicación.
5.3.2 Variables del usuario
Son creadas por el programador para almacenar datos que puedan utilizarse a lo
largo de la ejecución de la aplicación. Estas variables pueden dividirse en tres tipos:
●● Tipo preexistentes. Define una variable copiando el tipo de dato de una es-
tructura ya existente. Hace uso de la cláusula %TYPE% para obtener el tipo de
dato almacenado en una tabla. Por ejemplo, si tenemos una fila id en la tabla
alumno. Para declarar la variable con el mismo tipo que id, bastaría con ejecutar
el siguiente código:
declare
variable alumno.id%TYPE%;
La sintaxis para declarar estas variables es:
<nombre_variable> [constante] <nombre_variable_PL/

PgSQL>%type [NOT NULL] [:= <expresión>];
●● Tipo fila (row type). PL/PgSQL nos permite almacenar datos tipo tupla, de ma-
nera que podemos almacenar las filas de una tabla en una variable. En este caso,
en los campos de la variable obtendrás los valores y los tipos de datos de las
columnas, de la tabla o vista.
La sintaxis para declarar estas variables es:
<nombre_variable> <esquema.tabla>%rowtype;
Veamos un ejemplo de declaración de variable tipo fila de una tabla alumnos:
Declare v_alumnos alumnos%ROWTYPE%;
Después accederíamos a los datos almacenados mediante:
V_alumnos.n.id;
84
Donde si hemos guardado las diferentes filas de la tabla alumnos, “n” sería el nú- Para saber más
mero del registro o fila, e “id” el nombre de la columna.
Las variables del sistema
se utilizan desde los
●● Tipo registro (record type). Tipo de variable parecido al tipo fila, en el que pode-
primeros sistemas
mos almacenar el resultado de una sentencia SELECT. A diferencia del tipo fila, el operativos.
registro no tiene una estructura predefinida. La estructura de esta variable es:
nombre RECORD;
5.4 Comentarios
Los comentarios son un recurso para el programador y permite introducir notas

informativas a lo largo del programa, con el objetivo de facilitar su comprensión
por parte de otros programadores que colaboren en el proyecto o incluso para él
mismo. Es muy habitual tener que realizar cambios en un programa un tiempo
después de haberlo desarrollado; y es comprensible que, después de ese tiempo,
el programador no recuerde las razones por las que desarrolló el código de una
manera determinada. Los comentarios proporcionan la ventaja de que son de fácil
integración y no intervienen en la ejecución del programa, puesto que son ignora-
dos por el sistema a la hora de ejecutarlo; además, los editores que se utilizan para
programar resaltan dichos comentarios con un color de letra distinto para que no
entorpezcan la lectura del resto del código. Cada lenguaje de programación defi-
ne los comentarios de una manera diferente. En SQL, se define como comentario
el texto que sigue a dos barras // (Figura 5.3).
Figura 5.3
Código en el que aparecen
numerosos comentarios.
85
Para saber más 5.5 Funciones

Los lenguajes que Las funciones son bloques de código que realizan una tarea determinada cuando
utilizan funciones
son ejecutadas. Normalmente, se pasa un valor a la función y, al finalizar la eje-
para estructurarse se
llaman lenguajes de cución, devuelve un resultado. En el lenguaje PL/PSQL existen funciones prede-
programación modular. finidas en el núcleo del lenguaje que nos permiten ejecutar algoritmos útiles sin
necesidad de programarlos.
Ejemplos de ello serían las funciones matemáticas (cos, sen, PI, etc.) y la manipu-
lación y la comparación de caracteres (comparar cadenas, codificación de carac-
teres, etc.).
Las ventajas de las funciones son principalmente dos:
●● Evitar la repetición de código, llamando a las funciones tantas veces como se

desee sin añadir ni una línea más.
●● Dividir un programa en funciones, puesto que ayuda a estructurar la programa-

ción por bloques y a mejorar la lectura del código.
5.6 Estructuras de control de flujo: alternativas y bucles
Las estructuras de control de flujo permiten indicar a la máquina que ejecute

una parte del código bajo unas determinadas condiciones. Veamos cuáles son:
●● If-Then-Else. La estructura If-Else es un control de flujo que establece dos vías

diferentes de ejecución del programa según una condición establecida: si se
cumple dicha condición, se ejecutará el código que sigue a la instrucción If; en
caso contrario, se ejecutará el código que se escribe a continuación del Else.
Dependiendo del lenguaje de programación que utilicemos, podremos ver la
cláusula Then acompañando a la estructura, cuya función es crear una separa-
ción entre la condición de la estructura y el bloque de código a ejecutar. En la
figura 5.4 podemos ver un esquema de esta estructura en la que, si la condición
es verdadera, se ejecuta el bloque de sentencias 1; de lo contrario, no ejecutará
ninguna instrucción, puesto que la alternativa que acompaña a Else es opcional,
por lo que podremos crear estructuras condicionales en las que no exista esta
cláusula. La estructura en el lenguaje PL/PSQL sería:
IF <condición> THEN
<sentencias>;
END IF;
86
Figura 5.4
Estructura de un IF.
●● LOOP. La estructura LOOP crea un bucle donde existen varias condiciones de salida.
LOOP
<sentencia>
exit when <condición_salida>
<sentencia>
exit when <condición_salida>
<sentencia>
END LOOP;
●● WHILE … LOOP. Esta estructura genera un bucle con una sola condición de sa-
lida; en este caso, si dicha condición se cumple desde el principio, el código en
su interior no llegará a ejecutarse una primera vez (Figura 5.5):
WHILE <condición> LOOP

<sentencia>
END LOOP;
Figura 5.5
Estructura WHILE ... LOOP.
87
●● FOR. El bucle FOR genera un número determinado de repeticiones definidas

mediante los parámetros “min” y “max”. Dichos parámetros no podrán modificar-
se durante la ejecución del FOR. La cláusula reverse es optativa y define el bucle
desde max a min.
FOR <variable> IN [reverse] <min>..<max> LOOP

< sentencías>
END LOOP;
5.7 Herramientas para creación de guiones. Procedimientos de

ejecución
Los guiones (en inglés scripts) son pequeños archivos que contienen código eje-
cutable desde el programa principal. Existen varias herramientas para crear guio-
nes, a las que puede accederse de manera visual e intuitiva en las librerías, funcio-
nes y demás recursos necesarios para poder construir nuestros propios guiones.
Los procedimientos de ejecución son un conjunto de instrucciones repetidas que

se engloban en una función o procedimiento para poderlas llamar durante la ejecu-
ción del programa, con el fin de poder realizar una operación determinada. Normal-
mente, los procedimientos de ejecución suelen englobarse en librerías (Figura 5.6).
Figura 5.6
Ejemplo de una herramienta
para la creación de guiones y
procedimientos de ejecución.
88
5.8 Procedimientos almacenados. Funciones de usuario
Los procedimientos almacenados son programas guardados en una base de da-

tos. Al ser instanciados por el usuario, tales programas se ejecutan dentro del sistema
que alberga la base de datos, lo que permite acceder a todos los datos y reducir
considerablemente el tráfico entre la máquina cliente y el servidor (Figura 5.7).
Figura 5.7
Esquema de un proceso
almacenado.
5.9 Subrutinas. Variables locales y globales
Las subrutinas forman parte del algoritmo principal y realizan una tarea específica
dentro de la ejecución del programa. En algunos lenguajes de programación se les
llama funciones. Cuando utilizamos funciones o subrutinas, aparecen los concep-
tos de variable local y variable global:
●● Por un lado, las variables locales se crean y utilizan durante la ejecución de la

subrutina y son eliminadas al finalizar ésta. Sólo se puede acceder a ellas desde
la función donde se declaran.
Para saber más
●● Por otro lado, las variables globales existen a lo largo de todo el programa, in- Algunos autores
cluidas las subrutinas. recomiendan no
abusar de las variables
Las funciones de usuarios son aquellas consultas creadas por un usuario para adap- globales, puesto que
tar los resultados de las consultas a sus necesidades. Se realiza para simplificar gran- consumen una gran
des consultas u operaciones periódicas, de manera que el usuario sólo tendrá que cantidad de memoria
del sistema.
llamar a la función, y el sistema hará todas las consultas programadas previamente.
89
Para saber más 5.10 Eventos y disparadores

Se llaman eventos los Los disparadores son procedimientos almacenados en la base de datos que se ejecu-
programas que son
tan automáticamente al realizar operaciones de modificación sobre una tabla deter-
ejecutados en función
de los sucesos que minada (INSERT, DELETE, UPDATE) sin que el usuario realice la modificación ni pueda
ocurran en el sistema. saber cómo es el procedimiento que se está lanzando en el sistema (Figura 5.8).
Se llaman disparadores
las condiciones que Los disparadores suelen utilizarse para asegurar la integridad de la tabla, compro-
deben existir en el bando que un registro no llegue a un valor máximo, o que el usuario introduzca el
sistema para que se tipo de dato correcto. La sintaxis para crear un disparador sería la siguiente:
ejecute un evento.
CREATE TRIGGER nombre { BEFORE | AFTER } { suceso [ OR ...
] }
ON tabla [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE PROCEDURE nombre_funcion ( parámetros )
Los parámetros que soporta la instrucción CREATE TRIGGER son:
●● BEFORE | AFTER. Define si el disparador se ejecutará antes o después del suceso.

●● SUCESO. Define cuándo se lanzará el disparador (INSERT, UPDATE o DELETE).
●● FOR EACH ROW | FOR EACH STATEMENT. Define si el disparador ha de ejecu-
tarse por cada fila afectada o por cada suceso.
Veamos el siguiente ejemplo para comprobar cómo funcionaría:
Si tenemos la siguiente tabla:
CREATE TABLE alumnos (

Id nun; /*Autoincremento*/
DNI num;
nombre_alumno text,
);
crearemos la función que se ejecutaría con el disparador:
CREATE FUNCTION num_max() RETURNS TRIGGER AS $maximo$

BEGIN
-- Comprueba que no se superen los 10 alumnos
IF NEW.Id IS 11 THEN
RAISE EXCEPTION ‘Ya hay demasiados alumnos en la clase’;
END IF;
END;
90
A continuación se definiría el disparador:
CREATE TRIGGER maximo BEFORE INSERT ON alumnos

FOR EACH ROW EXECUTE PROCEDURE num_max();
Para probarlo, insertaríamos un nuevo alumno:
INSERT INTO alumnos VALUES (‘47159698N’,’Marta Sánchez’);
Si intentamos realizar esta inserción cuando ya hay diez alumnos, el sistema

nos devolverá un error y la sentencia no se ejecutará correctamente, precisa-
mente por haber definido que se haga la comprobación antes de la inserción
del registro.
Figura 5.8
Disparadores o triggers que lan-
zarán una serie de instrucciones.
5.11 Excepciones. Tratamiento de excepciones
Se llaman excepciones a los problemas que surgen en la ejecución de un código.

Suelen ocurrir cuando una variable o instrucción tiene un valor que no está con-
templado en el programa.
Para tratar dichas excepciones, podemos optar, según lo crítica que sea la ex-
cepción, por detener la ejecución del programa o ignorar el error y seguir con la
ejecución
Por este motivo, los lenguajes de programación suelen tener instrucciones especí-
ficas para definir el comportamiento ante las excepciones.
91
Para saber más La sintaxis adecuada para definir excepciones sería la siguiente:
En SQL se utiliza la BEGIN
sentencia EXCEPTION
consultas
para definir
comportamientos ante EXCEPTION
errores. WHEN [condición] THEN
Sentencia de la excepción
WHEN [condición] THEN
Sentencia de la excepción
END;
5.12 Cursores. Funciones de tratamiento de cursores
Los cursores son pilas de punteros que apuntan a cada una de las filas del re-
sultado de una consulta. Entendemos por pila de punteros un vector en el que
no almacenamos valores, sino direcciones de memoria donde el sistema puede
encontrar los resultados obtenidos en una consulta. Esto es útil para reducir la
carga de memoria del cliente cuando deseamos procesar los datos de una con-
sulta que ha generado un gran volumen de resultados. De esta manera, cuando
queremos procesar uno a uno los 10.000 registros devueltos por una consulta,
no necesitamos tener todos los datos cargados en local, sino que iremos reco-
rriendo la pila con las 10.000 direcciones de memoria donde encontraremos los
datos que buscamos.
La forma de declarar y utilizar los cursores es la siguiente:
1. Declaración de cursor
name [ [ NO ] SCROLL ] CURSOR [ ( argumentos ) ] FOR query ;
2. Abrir cursor
OPEN unbound_cursorvar [ [ NO ] SCROLL ] FOR query ;
Al abrir el cursor, se ejecuta la consulta definida.
3. Ejecutar el cursor
a) FETCH. Recupera la siguiente fila almacenada en el cursor:
FETCH [ direction { FROM | IN } ] cursor INTO target;
92
b) MOVE. No devuelve ningún valor, si no que reposiciona el cursor:
MOVE [ direction { FROM | IN } ] cursor ;
c) UPDATE/DELETE WHERE CURRENT OF. Elimina o modifica la fila de la tabla

que almacena el cursor:
UPDATE TABLE SET ... WHERE CURRENT OF cursor ;

DELETE FROM TABLE WHERE CURRENT OF cursor ;
d) CLOSE. Cierra el cursor:
CLOSE cursor ;
5.13 API para lenguajes externos
Interfaz de programación de aplicaciones o API (Application Programming In-

terface). Los API son programas que realizan la función de intermediarios en la
comunicación entre dos plataformas diferentes.
Dentro de la programación de las bases de datos, los API se utilizan para poder
gestionar bases de datos mediante sentencias de SQL. Los propios API se encar-
garán de gestionar los diferentes protocolos de comunicación para que lleguen al
servidor de destino en un formato estándar que éste pueda entender.
Algunos estándares de API más utilizados en bases de datos son los ODBC, que
permiten a los SGBD mantenerse conectados al servidor y hacerle llegar peticio-
nes, desde consultas hasta modificaciones en la base de datos.
93
Resumen
Los sistemas de bases de datos incorporan lenguajes de programación con los que pueden gestio-
narse operaciones más complejas que no pueden llevarse a cabo mediante consultas. Las estructuras
de control de flujo, como los bucles, permiten repetir la misma consulta varias veces y aplicarla inclu-
so a un gran número de registros con sólo un par de líneas de código. Las sentencias condicionales
sólo permiten aplicar las consultas si se han dado una serie de condiciones en la base de datos. Estos
controles de flujo permiten crear programas de mantenimiento en los que no es necesaria la inter-
vención de ninguna persona durante todo el proceso.
La función es otra de las estructuras de los lenguajes de programación que hace posible ordenar el
código en bloques, los cuales serán ejecutados al ser llamados por el programa.
De esta manera, se reduce el código repetido y se crea un programa más estructurado y ordenado.
Los guiones son código de programación, que será ejecutado internamente por el servidor. Estos
guiones pueden ser lanzados por los disparadores, que pueden ser, programados para ser ejecuta-
dos, al reunirse unas condiciones determinadas en la base de datos. Por ejemplo, lanzar un vaciado
de los cien registros más antiguos de una tabla temporal mediante un script, al llegar a un número
máximo de registros.
Las excepciones son programadas para evitar que, en caso de errores inesperados, el sistema se
vuelva inestable. Generalmente, se programan para lanzar un mensaje que explica el error que se ha
producido. Si es un error grave, la ejecución del programa se detendrá; en caso contrario el mensaje
será mostrado pero no se detendrá el programa.
Por último, las API son pequeños códigos de programación que son utilizados para transmitir la in-
formación y las funcionalidades entre diferentes plataformas. De esta manera, no es necesario que
todas las plataformas estén escritas en el mismo lenguaje, o con las mismas características, ya que las
API hacen de puente para que se puedan comunicar entre ellas.
94
1. Las palabras reservadas son aquellas expresiones que forman parte del propio
lenguaje de programación y no pueden ser utilizadas por el usuario durante el
proceso de programación.
2. Las variables son elementos de la programación compuestos por valores diná-

micos que serán utilizados por los procesos de un programa.
3. Las funciones son bloques de código que realizan una tarea dispersa cuando
son ejecutadas. Normalmente, se pasa un valor a la función y, al finalizar la eje-
cución, devuelve un resultado.
4. El bucle FOR genera un número indeterminado de repeticiones definidas me-

diante los parámetros “min” y “max”. Dichos parámetros no podrán modificarse
durante la ejecución del FOR.
5. Los guiones (en inglés scripts) son pequeñas bases que contienen código ejecu-
table desde el programa principal.
6. Las variables locales se crean y utilizan durante la ejecución de la subrutina y son

eliminadas al finalizar esta. Solo se puede acceder a ellas desde la función donde
se declaran.
7. Las funciones de usuarios son aquellas consultas creadas por el sistema para
adaptar los resultados de las consultas a sus necesidades.
8. Los comentarios son un recurso para el ______________ y permite introducir

notas ______________ a lo largo del programa, con el objetivo de facilitar su
______________ por parte de otros programadores que colaboren en el pro-
yecto o incluso para él mismo.
9. Las subrutinas forman parte del ______________ principal y realizan una tarea
específica dentro de la ejecución del ______________ . En algunos lenguajes
de programación se les llama ______________.
95
10.
Las bases de datos nos proporcionan la posibilidad de programar
______________ que se ejecuten internamente en el ______________ de
manera desatendida por parte del usuario.

96
Interpretación de diagramas Entidad/Relación
6. INTERPRETACIÓN DE DIAGRAMAS
ENTIDAD/RELACIÓN
Un diagrama entidad/relación es una representación gráfica usada para modelar
los datos de un sistema de información. Es una manera de plasmar en forma de
diagrama una situación de la vida real para facilitar la posterior construcción de
una base de datos (Figura 6.1).
Figura 6.1
Esquema de un diagrama
entidad/relación.
6.1 Entidades y relaciones. Cardinalidad
Como su propio nombre indica, este tipo de diagrama se compone de entidades

y relaciones, si bien también debemos enumerar los atributos, que son las carac-
terísticas que tiene una entidad (Figura 6.2):
Figura 6.2
Ejemplo de diagrama E/R con
atributos, entidades, relaciones
y cardinalidad.
97
●● Entidades. Representan objetos del mundo real, diferentes al resto de cosas,

y tienen unas características determinadas. Una persona sería un ejemplo de
entidad.
●● Atributos. Son las características que definen una entidad. Siguiendo el ejemplo
anterior, podríamos decir que son atributos de una persona: su nombre, su edad,
su peso y su altura.
●● Relación. Describe la asociación que existe entre varias entidades, e incluso su

dependencia si ésta existiese.
La cardinalidad representa el número de relaciones que existen entre varias en-

tidades. Ésta se representa mediante una etiqueta en el exterior de la relación. Las
relaciones pueden ser entre uno y uno (1:1), entre uno y varios (1:N), o entre
varios y varios (N:M).
Veamos algunos ejemplos:
●● 1:1. Es aquella relación que une dos entidades de manera única; es decir, nin-
guna de ellas está relacionada con una tercera entidad. Por ejemplo, un marido
(entidad) está casado (relación) con una única mujer y viceversa.
●● 1:N. Es la relación en la que una entidad está relacionada con varias entidades,
pero éstas, a su vez, sólo pueden estar conectadas con la primera, pero con nin-
guna más. Para entenderlo mejor, podemos imaginarnos que una persona (en-
tidad) puede tener (relación) varios coches, pero un coche sólo puede tener un
dueño.
●● N:M. Es la relación en la que todas las entidades pueden estar relacionadas con
varias entidades. Es el caso, por ejemplo, de un supermercado, en el que un pro-
ducto (entidad) puede ser comprado (relación) por varios clientes (entidad), así
como varios clientes pueden comprar varios productos.
6.2 Simbología de los diagramas E/R
Para la representación del diagrama Entidad/Relación (E/R), es conveniente se-

guir una nomenclatura estándar: representar las entidades mediante un rectángu-
lo; las relaciones, mediante un rombo con un verbo en su interior; y los atributos,
con un círculo.
98
A continuación, veremos las etiquetas que representan la cardinalidad en las rela- Para saber más
ciones de las entidades junto a un ejemplo de ellas:
El Dr. Peter Pin-Shan Chen
fue el creador del modelo
●● 1:1. Un marido (entidad) está casado (relación) con una única mujer y viceversa.
Entidad/Relación.
●● 1:N. Una persona (entidad) puede tener (relación) varios coches, pero un coche
sólo puede tener un dueño.
●● N:M. Un producto (entidad) puede ser comprado (relación) por varios clientes
(entidad), así como varios clientes pueden comprar varios productos.
6.3 Debilidad
En el modelo E/R es posible que una de las entidades de cualquier relación tome
Recuerda
una posición de debilidad. Se trata de aquellas entidades que no pueden ser iden- Las entidades débiles
tificadas por sus atributos y que necesitan de otras entidades para tener un senti- nunca pueden ir solas,
do. Por ejemplo, en un préstamo que se devuelve en varios pagos, la entidad PAGO sino que necesitan
de otra entidad para
carece de sentido si no está unida a la entidad PRÉSTAMO; ya que PAGO contiene
adquirir un sentido.
el identificador del recibo, pero no el del préstamo al que pertenece (Figura 6.3).
Figura 6.3
Ejemplo de entidad débil.
6.4 El modelo E/R ampliado: reflexión y jerarquía
Los modelos E/R no son capaces de representar totalmente algunas situaciones

de la vida real debido a una serie de limitaciones semánticas. Por ello, en algunos
casos, se opta por utilizar modelos ampliados o extendidos que añaden nuevas
funcionalidades al modelo original (Figura 6.4).
99
Para ampliar este

tema, puedes ver
el videotutorial
Creación de diagramas
con workbench, que
encontrarás en el
Campus online.
Figura 6.4
Diagrama E/R en modelo
extendido.
6.4.1 La reflexión
Las entidades reflexivas son aquellas que están relacionadas con ellas mismas,
y suelen emplearse para representar las relaciones entre personas. Por ejemplo,
la entidad EMPLEADOS puede ser reflexiva si se utiliza la relación Jefe, ya que un
empleado puede ser jefe de otros empleados (Figura 6.5).
Figura 6.5
Entidad reflexiva que apunta
sobre sí misma.
6.4.2 La jerarquía
La jerarquía es una manera de estructurar el modelo E/R en forma de árbol, de

modo que se acerque a la programación orientada a objetos. Las entidades que
100
provienen de una entidad padre heredan sus atributos y relaciones, de manera

que no es necesario volverlos a representar en el diagrama. Sólo puede existir una
entidad padre, pero ésta puede tener varios hijos (Figura 6.6).
Documento
Figura 6.6
Libro Artículo
Ejemplo de modelo
E/R jerárquico.
En algunos casos, será necesario representar situaciones que no pueden ser in-
terpretadas mediante la estructura de árbol; en ese caso el modelo E/R jerárquico
puede romper el esquema de manera puntual y permitir las relaciones entre nodos
hermanos haciendo que el esquema jerárquico se convierta en un grafo dirigido.
6.5 Paso del diagrama E/R al modelo relacional
Una vez construido nuestro diagrama E/R, que representa las relaciones de los ele-
mentos de la “vida real”, el siguiente paso, a la hora de construir una base de datos,
es el cambio del diagrama E/R al modelo relacional, esto es, transformar los es-
quemas que tenemos en tablas que contengan los atributos más representativos
de las entidades. Puede parecer complejo al principio, pero se puede realizar de
manera sistemática realizando los siguientes pasos (Figura 6.7):
●● Cada entidad se transformará en una tabla.

●● Cada atributo se transformará en una columna de la tabla a la que pertenece.
●● El identificador de la entidad será la clave primaria de la tabla.
●● Una relación N:M se convierte en una tabla en la que la clave primaria serán las
dos claves primarias de las entidades que se asocian.
En una relación 1:N se pasa la clave primaria de la entidad con cardinalidad 1 a la

entidad con cardinalidad N.
101
Recuerda ●● En las relaciones N:M existen tres posibilidades:

Si la cardinalidad es (0,1) en ambas entidades, se crea una tabla.
Hay que estudiar las Si la cardinalidad es (0,1) y la otra es (1,1), se pasa la clave primaria de (1,1) a la
cardinalidades N:M
de (0,1).
antes de pasar del
modelo E/R al modelo Si la cardinalidad de ambas es (1,1), se pasa la clave de cualquiera de ellas a la otra.
relacional.
Figura 6.7
Paso del diagrama E/R al
modelo relacional.
6.6 Formas normales
Las formas normales son una manera de dividir los atributos según su depen-
dencia respecto de la clave principal. Se trata de una nomenclatura que permite
estructurar los atributos de manera estándar para facilitar el trabajo con las bases
de datos en proyectos complejos.
6.6.1 Primera forma normal
Una tabla se halla en la 1ª NF (Normal Form) si todos sus atributos son atómicos, es
decir, indivisibles. Un ejemplo muy claro sería el del DNI (Figura 6.8).
Figura 6.8 DNI Apellido Nombre Dirección Ciudad

Tabla DNI
102
6.6.2 Segunda forma normal
Una tabla se encuentra en 2ª NF si está en 1ª NF y cada atributo que NO es clave

es totalmente dependiente de la clave. La siguiente tabla no estaría en la 2ª NF,
ya que no sabemos si la descripción se refiere al curso o al estudiante (Figura 6.9).
id_estudiante departamento id_curso descripción calificación Figura 6.9

Tabla que no está en la 2ª NF.
Para pasar la tabla a la 2ª NF, deberíamos dividirla en dos tablas, tal como se mues-
tra en la figura 6.10.
Figura 6.10
Dos tablas separadas para poder
estar en la segunda forma normal.
6.6.3 Forma normal de Boyce-Codd
Una relación está en la forma normal de Boyce-Codd (FNBC) si está en 2ª FN y

todos los determinantes son claves candidatas. Imaginemos un centro comercial
donde se guardan los alimentos en diferentes cámaras frigoríficas según el tipo
de alimento (carne, pescado, verduras). Además, en el interior de cada cámara se
dividen los espacios para guardar los palés por fabricante (Figura 6.11).
Vendedor Tipo Cámara Ubicación

FresCO Verduras 10 FFF
Hacendado Pescado 15 HHH
Carrefour Carne 20 CCC Figura 6.11
FresCO Carne 20 FFF Ejemplo de tabla donde
Hacendado Pescado 15 HHH
guardamos tipos de alimentos
Carrefour Verduras 10 CCC
por fabricantes.
Esta tabla podría definirse como:
ALMACEN (__Vendedor__, __ Tipo__, Camara, Ubicacion)
103
La relación ALMACEN no se encuentra en FNBC, ya que Cámara es determinante

en la relación y Tipo tiene dependencia funcional absoluta de Cámara; pero Cá-
mara no es clave candidata, puesto que no define unívocamente ningún registro,
puesto que para ello es necesaria la clave Ubicación.
Para poder pasar la relación a FNBC, es preciso localizar los atributos que depen-
den de los determinantes y que no son claves candidatas y, a partir de ellos, crear
nuevas relaciones sin perder la información inicial.
ALMACEN (vendedor, camara, ubicacion)

TIPO_NAVE (nave, Tipo)
6.6.4 Cuarta forma normal (4FN)
La siguiente tabla corresponde a una relación en FNBC; sin embargo, es evidente la

redundancia, ya que, al relacionar Asignatura y Deporte, se produce una repetición de
los datos para poder mostrar todas las asignaturas y deportes que realiza el alumno.
Cuando esto sucede, se le llama dependencias multivalentes (Figura 6.12).
D.N.I. Asignatura Deporte

000000001A Cálculo Fútbol
000000001A Geometría Fútbol
000000001A Cálculo Basquet
000000001A Geometría Basquet
Figura 6.12
000000002B Inglés Atletismo
Ejemplo de tabla con
redundancia en los datos. 000000002B Alemán Atletismo
Para poder solucionar este problema, se creó la cuarta forma normal (4FN), que
consiste en dividir la relación en dos relaciones diferentes que separen los elemen-
tos que provocan la dependencia multivalente.
ASIGNATURAS (__Dni, Asignatura __)

DEPORTES (__Dni, Deporte __)
6.6.5 Quinta forma normal (5FN)
La quinta forma normal se crea para las relaciones en FNBC que tienen depen-
dencias multivalentes pero que no pueden ser resueltas por la 4FN.
104
Podemos verlo claramente en el siguiente ejemplo: un centro de estudios que

tiene varios edificios autoriza a sus profesores a impartir diferentes materias; pero,
además, aparte de dar clases, los profesores pueden realizar otras tareas (correc-
ción de exámenes, tutorías, descansos, clases, etc.) (Figura 6.13).
ID_Profesor Edificio Especialidad Tarea

P1 E1 Ciencias Tutoría
P1 E2 Ciencias Tutoría
P1 E2 Biología Corregir exámenes Figura 6.13
Ejemplo de tabla que muestra
P2 E1 Inglés Clase
que los profesores pueden
P2 E2 Francés Tutoría impartir diferentes asignaturas.
Si lo analizamos, podríamos utilizar la 4FN y descomponerlo en tres relaciones:
EDIFICIO-PROFESOR (ID_Profesor, Edificio)

ESPECIALIDAD-PROFESOR (_ID_Profesor, Especialidad)
TAREA-PROFESOR (__ID_Profesor, Tarea)
El problema de esta descomposición es que, al realizar un Natural-Join, no obten-

dremos la relación original, sino una tabla mucho más grande y con un gran nú- Para saber más
mero de permutaciones repetidas. Cuando esto sucede, se llama dependencias La cláusula NATURAL
mutuas entre los atributos de la relación. JOIN realiza la misma
función de combinación
Por lo tanto, la 5FN sería: que la cláusula JOIN, es
decir, se comparan las
EDIFICIO-PROFESOR-ESPECIALIDAD (ID_Profesor, Edificio, Es- columnas con el mismo
pecialidad) nombre en ambas
tablas. La diferencia
EDIFICIO-PROFESOR-TAREA (ID_Profesor, Edificio, Especiali-
entre ellas es que
dad-Tarea)
NATURAL JOIN muestra
ESPECIALIDAD-PROFESOR-TAREA (_ID_Profesor, Especialidad- en la tabla resultante
Tarea) sólo una columna por
cada par de columnas
Si realizamos el Natural-Join de estas tres relaciones, obtendremos la tabla original. con el mismo nombre.
6.7 Normalización de modelos relacionales
El proceso de normalización consiste en seguir las reglas de las bases de datos y

aplicarlas a las relaciones que hemos obtenido al pasar del modelo E/R al modelo
relacional.
105
Para saber más Las ventajas de normalizar un modelo relacional son las siguientes:
Normalizar los modelos ●● Evitar la redundancia de datos, es decir, datos duplicados e innecesarios.
relacionales nos acerca
un poco más a la
estructura de las bases
●● Proteger la integridad de los datos. No dejar huérfano ningún atributo o tabla
de datos. que tenga alguna clase de dependencia.
●● Igualar la estructura del modelo relacional al sistema de base de datos: tablas con
nombres únicos y columnas y atributos del mismo tipo.
106
Resumen
Los diagramas entidad/relación permiten interpretar las características de los datos y sus interrela-
ciones en las que están basadas las bases de datos relacionales. De este modo, es posible, de una
manera visual, entender la estructura de los datos y cómo se interpretan en la vida real. Estos dia-
gramas son utilizados generalmente en el proceso de desarrollo de una base de datos, antes de su
creación e implantación, ya que facilitan la concepción de todo el proyecto y están especialmente
diseñados para convertirse en una especie de planos a seguir a la hora de crear la base de datos. Para
ello, es importante seguir unas reglas, tanto en la simbología como en la estructura del diseño y la
distribución de los elementos. Es preciso definir en el diagrama las características que tendrá la base
de datos, como tipo de datos que almacenará o el tipo de relación que tendrán las diferentes tablas
y sus claves primarias. La cardinalidad, por ejemplo, define el número de relaciones existentes entre
las diferentes tablas.
Una vez creado el diagrama con la conceptualización de la situación de la vida real que se quiere tras-
pasar a la base de datos, resultará relativamente sencillo traspasarlo al modelo relacional mediante
una serie de pasos según las características del diagrama y las relaciones de las tablas.
La normalización del modelo relacional consiste en seguir unas pautas en la distribución de los datos
para que no exista duplicidad de éstos y, al mismo tiempo, sean más eficiente las consultas realizadas
a las tablas, mediante la aplicación de políticas como, por ejemplo, definir que todos los atributos de
una tabla sean dependientes de una única clave primaria.
107
1. La cardinalidad representa el número de relaciones que existen entre varias en-
tidades. Ésta se representa mediante una etiqueta en el interior de la relación.
2. Un diagrama entidad/relación es una representación gráfica usada para modelar

los datos de un sistema de información. Es una manera de plasmar en forma de
diagrama una situación de la vida real para facilitar la posterior construcción de
una base de datos
3. Para la representación del diagrama entidad/relación (E/R), es conveniente seguir una

nomenclatura estándar: representar las entidades mediante un rombo; las relaciones,
mediante un rectángulo con un verbo en su interior; y los atributos, con un círculo.
4. Las entidades reflexivas son aquellas que están relacionadas con ellas mismas, y
suelen emplearse para representar las relaciones entre personas.
5. La jerarquía es una manera de estructurar el modelo E/R en forma de árbol, de

modo que se acerque a la programación orientada a personas.
6. Una relación está en la forma normal de Boyce-Codd (FNBC) si está en 1ª FN y

todos los determinantes son claves candidatas.
7. Para poder pasar la relación a FNBC, es preciso localizar los atributos que de-
penden de los determinantes y que no son claves candidatas y, a partir de ellos,
crear nuevas relaciones sin perder la información inicial.
8. Los modelos E/R no son capaces de representar totalmente algunas situaciones

de la vida real debido a una serie de limitaciones ______________. Por ello, en al-
gunos casos, se opta por utilizar modelos ______________ o ______________
que añaden nuevas funcionalidades al modelo original.
9. La quinta forma normal se crea para las relaciones en ______________ que
tienen dependencias ______________ pero que no pueden ser resueltas por
la ______________.
108
10. El proceso de normalización consiste en seguir las reglas de las bases de datos
y ______________ a las relaciones que hemos obtenido al pasar del modelo
______________ al modelo ______________.

109
7. USO DE BASES DE DATOS RELACIONALES
7.1 Características de las bases de datos objeto-relacionales
Las bases de datos objeto-relacionales son una evolución de las bases de datos
del modelo relacional que dan lugar a otro tipo más amplio que incorpora con-
ceptos del lenguaje orientado a objetos (Figura 7.1).
Figura 7.1
Representación de una base de
datos orientada a objetos.
Es importante remarcar que la idea de las bases de datos orientadas a objeto es un

concepto que se está desarrollando en la actualidad y todavía no es soportado por
la mayoría de los lenguajes de bases de datos.
Por lo tanto, los ejemplos de este tema no son ejecutables desde MySQL.
7.2. Tipos de datos objeto: atributos, métodos, sobrecarga

y constructores
Los sistemas objeto-relacionales permiten al usuario crear nuevos tipos de da-

tos a partir de los tipos básicos del sistema. Éstos pueden ser:
●● Colecciones o conjuntos. Este tipo de datos clasifican los vectores (Arrays) en

elementos que pueden aparecer varias veces.
110
Uso de bases de datos relacionales
●● Tipos estructurados. Permiten realizar una representación de los atributos en

los diagramas entidad-relación.
●● Objetos de gran tamaño. Permiten almacenar atributos de gran tamaño para

suplir la necesidad que existe actualmente de almacenar grandes cantidades de
información (vídeos, imágenes de alta resolución, etc.) (Figura 7.2).
En los elementos que componen las bases de datos objeto-relacionales cabe destacar:
●● Atributos. Como las variables, un atributo se define mediante un tipo y un nom-

bre único dentro del tipo de objeto.
●● Métodos. Los métodos se especifican junto a la creación de su tipo y ejecutan

una serie de sentencias para realizar una función determinada.
●● Sobrecarga. Los métodos del mismo tipo pueden sobrecargarse; es decir, se

puede utilizar el mismo nombre para métodos distintos si su número, orden o
tipo de parámetros no son iguales.
●● Constructores. Son los métodos cuyo nombre coincide con el nombre del tipo.
Todos los tipos de objeto tienen asociado un método que inicializa nuevos ob-
jetos de ese tipo.
Figura 7.2
Los objetos dentro de una base
de datos.
7.3 Definición de tipos de objeto. Definición de métodos
En todo objeto es necesario definir tanto su estructura como sus parámetros. Para
ello, utilizaremos la sentencia CREATE TYPE (crear tipo), en la que definiremos el
111
tipo de objeto para, posteriormente, utilizarlo en la definición del método que

emplee dicho objeto (Figura 7.3). Igual que la definición de los tipos de datos que
almacena un objeto, podemos definir métodos que, al ser llamados, ejecutarán
las instrucciones programadas en su definición. Su cometido es el mismo que las
funciones, con la diferencia que deberán ser llamadas a través de los objetos, pues
es en su interior donde son definidas.
CREATE TYPE Departamento AS OBJECT (

number INTEGER ,
Figura 7.3 manager REF Employee ,
Ejemplo de instrucción para . . .
) ;
crear un tipo objeto.
7.4 Herencia
En ocasiones, es necesario trabajar con tipos de objetos muy parecidos pero no

iguales. En estos casos es conveniente utilizar la herencia, que es una característi-
ca del paradigma orientado a objetos. Ésta se basa en crear nuevos tipos utilizando
para ello otro tipo como padre, del que se obtendrán los mismos atributos. Por
ejemplo, podríamos poner el tipo Persona con los atributos color de ojos, pelo, altu-
ra, etc.; y, al crear los tipos Español, Francés y Alemán, éstos heredarán los mismos
atributos que el tipo Persona, puesto que son comunes en todos ellos (Figura 7.4).
Figura 7.4
Administrativo, docente y
PersonaLimpieza heredan
atributos de Persona.
7.5 Identificadores; referencias
Cuando se utilizan objetos grandes, resulta ineficaz pasar copias de él entre pro-
gramas. Por ello, se opta por compartir el objeto pasando su referencia; y esto sólo
es posible si el objeto cuenta con un identificador único.
112
Los identificadores permiten que la información no se duplique innecesariamente,

ya que sólo hay un lugar en la base de datos donde tenemos guardada la infor-
mación. Por tanto, si tenemos que hacer un cambio, sólo lo hacemos en un lugar.
7.6 Tablas de objetos y tablas con columnas tipo objeto
Es posible crear un tipo de tabla que almacene los objetos que hemos creado.
Cada fila de la tabla representará un objeto, y cada columna almacenará un atribu-
to del tipo de objeto (Figura 7.5).
Figura 7.5
CREATE TABLE clientes_año_tab OF cliente_t (clinum PRIMARY KEY);
Ejemplo de instrucción para
CREATE TABLE clientes_antiguos_tab ( año NUMBER, cliente cliente_t); crear tablas que almacenan un
tipo objeto.
7.7 Tipos de datos colección
Las colecciones son un tipo de datos que almacena un conjunto de datos. Existen
dos tipos de colecciones:
●● Varray. Colección ordenada de datos, cada uno asociado a un índice para ac-
ceder a ellos. Al definir un Varray (vector), es necesario definir el número de ele-
mentos que contendrá.
●● Tablas anidadas. No se especifica un máximo de datos, pero los datos almacena-

dos no están ordenados y es más difícil acceder a ellos que con el Varray (Figura 7.6).
Figura 7.6
Ejemplo de tabla anidada.
113
7.8 Declaración e inicialización de objetos
Una vez hayamos definido cómo será el tipo de objeto que utilizaremos, debere-
mos declarar los objetos e inicializarlos.
Para declarar un objeto, basta con definir de qué tipo será y asignarle un nom-
bre, igual que lo haríamos al crear una variable. Una vez creado el objeto, se dice
que es un objeto atómicamente nulo, puesto que debemos inicializarlo con la
llamada al constructor. De esta manera se definirán los valores del tipo objeto
(Figura 7.7).
DECLARE
r Racional ;
BEGIN
r : = Racional ( 6 , 8 ) ;
DBMS_OUTPUT. PUT_LINE( r . num);
END
DECLARE
Figura 7.7
r Racional:=Racional(2,3)
declarar un objeto e inicializarlo.
7.9 Uso de la sentencia SELECT
La sintaxis básica de una consulta en un entorno de objeto-relación es muy pa-

recida a la de las bases de datos relacionales porque siguen la misma estructura.
En este caso, las consultas necesitan un punto de entrada, que suele ser el nombre
de un objeto o la extensión de una clase. Cuando se utiliza una extensión como
punto de entrada, es necesario emplear una variable iteradora que adquiera los
valores de los diferentes objetos de la colección (Figura 7.8).
SELECT struct(tit: t.titulo,

año: t.año,
Figura 7.8 esc: t.escuela)
FROM t in e.titulos
consultar una base de datos
objeto-relacional.
114
7.10 Navegación a través de referencias
Del mismo modo que existen las claves primarias y foráneas en las bases de datos
objeto-referencia, existe también la posibilidad de almacenar en una columna la
referencia a un objeto que se halle en una tabla referenciada.
En este caso, para poder mantener la integridad referencial, los objetos a los que se
hace referencia deben haberse creado previamente.
7.11 Llamadas a métodos
Para poder invocar los métodos que hayamos definido a lo largo del programa,
bastará con utilizar la notación punto sobre el tipo del objeto (Figura 7.9).
Figura 7.9
La llamada al método
hello_virtual() que existe en la
Clase Base.
7.12 Inserción de objetos
Para insertar una instancia de cualquier tipo de objeto, es necesario utilizar el mé-
todo constructor, tal y como se hace con los objetos (Figura 7.10).
115
INSERT INTO estrellas VALUES(‘Sol’,23, tab planeta(

planeta(
‘Neptuno’,
10,
tab satelite(
satelite(‘Proteus’,67),
satelite(‘Triton’,82)
)
),
planeta(
‘Jupiter’,
189,
tab satelite(
satelite(‘Calisto’,97),
satelite(‘Ganimedes’,22)
Figura 7.10 )
Ejemplo para insertar en una )
));
tabla un tipo objeto.
7.13 Modificación o borrado de objetos
La sintaxis de la eliminación y modificación de objetos también sigue la misma

estructura que en las bases de datos relacionales (Figura 7.11).
Para el borrado de objetos se utiliza la sentencia DELETE y la cláusula WHERE para

eliminarlos selectivamente.
Muy parecida es la sentencia que se encarga de la modificación de los objetos

almacenados en la base de datos, cuyo formato se muestra en la figura 7.11.
DELETE FROM personas

WHERE p.direccion=’avenida’;
Figura 7.11. UPDATE personas SET p.direccion=’avenida’

Código para eliminar y modifi- WHERE p.apellido=’Sanchez’;
car un registro de tipo objeto.
116
Resumen
Las bases de datos objeto-relacionales pretenden acercarse un poco más al paradigma de los len-
guajes de programación orientados a objetos. Se definen de esta manera nuevos tipos de bases de
datos capaces de almacenar datos de tipo objeto mucho más complejos que los tipos habituales
empleados hasta el momento como enteros, caracteres, fechas, etc.
Para realizar este cambio de paradigma en las bases de datos se crean dos nuevas maneras de al-
macenar los datos de tipo objeto. La primera, mediante tablas de objeto en la que cada una de ellas
representa una clase, y cada columna un atributo de ésta.
De modo que una clase coche que esta compuesta por color, modelo y marca es almacenada de
modo que cada uno de los atributos corresponda a una columna de la tabla. Cada uno de los nuevos
objetos creados a partir de la clase coche, es almacenado en la tabla como un registro nuevo. La se-
gunda manera es mediante las tablas de columnas tipo objeto, en la que todo el contenido de una
clase es almacenado en una única columna de la base de datos.
Para poder acceder a los datos almacenados mediante el sistema de tablas con columnas tipo objeto
deberemos utilizar la notación punto, hasta llegar a los datos almacenados mediante la estructura de
la clase. Para la realización de consultas y modificaciones en los datos de las bases de datos objeto-
relacionales se utilizan las mismas consultas SELECT, UPDATE, INSERT, etc., teniendo siempre en cuen-
ta la notación punto para poder introducir los datos en las columnas de tipo objeto.
117
1. Los sistemas objeto-relacionales permiten al usuario crear nuevos tipos de datos

a partir de los tipos básicos del sistema.
2. Los constructores son los métodos cuyo nombre coincide con el nombre del
tipo. Todos los tipos de objeto tienen asociado un método que inicializa nuevos
objetos de ese tipo.
3. En ocasiones, es necesario trabajar con tipos de objetos iguales. En estos ca-
sos es conveniente utilizar la herencia, que es una característica del paradigma
orientado a objetos.
4. Varray es una colección desordenada de datos, cada uno asociado a un índice

para acceder a ellos. Al definir un Varray (vector), es necesario definir el número
de elementos que contendrá.
5. Una vez creado el objeto, se dice que es un objeto atómicamente nulo, puesto
que debemos inicializarlo con la llamada al constructor. De esta manera se defi-
nirán los valores del tipo objeto.
6. Para insertar una instancia de cualquier tipo de objeto, es necesario utilizar el

método constructor, tal y como se hace con los objetos.
7. Para el borrado de objetos se utiliza la sentencia DELETE y la cláusula FROM para

eliminarlos selectivamente.
8. Las bases de datos objeto-relacionales son una evolución de las bases de datos
del ______________ relacional que dan lugar a otro tipo más amplio que incor-
pora conceptos del ______________ orientado a objetos.
9. Respecto a la sobrecarga, los métodos del mismo tipo pueden sobrecargarse; es

decir, se puede utilizar el mismo ______________ para métodos distintos si su
número, orden o tipo de ______________ no son ______________.
118
10.
La herencia se basa en crear nuevos ______________ utilizando para
ello otro tipo como ______________ , del que se obtendrán los mismos
______________.

119

Unidad 5
1. V
2. V
3. F. Las funciones son bloques de código que realizan una tarea determinada
cuando son ejecutadas. Normalmente, se pasa un valor a la función y, al finalizar
la ejecución, devuelve un resultado.
4. F. El bucle FOR genera un número determinado de repeticiones definidas me-
diante los parámetros “min” y “max”. Dichos parámetros no podrán modificarse
durante la ejecución del FOR.
5. F. Los guiones (en inglés scripts) son pequeños archivos que contienen código
ejecutable desde el programa principal.
6. V
7. F. Las funciones de usuarios son aquellas consultas creadas por un usuario para
adaptar los resultados de las consultas a sus necesidades.
8. programador, informativas, comprensión
9. algoritmo, programa, funciones.
10. sentencias, servidor, usuario.
Unidad 6
1. F. La cardinalidad representa el número de relaciones que existen entre varias

entidades. Ésta se representa mediante una etiqueta en el exterior de la relación.
2. V
3. F. Para la representación del diagrama entidad/relación (E/R), es conveniente
seguir una nomenclatura estándar: representar las entidades mediante un rec-
tángulo; las relaciones, mediante un rombo con un verbo en su interior; y los
atributos, con un círculo.
4. V
5. F. La jerarquía es una manera de estructurar el modelo E/R en forma de árbol, de
modo que se acerque a la programación orientada a objetos.
6. F. Una relación está en la forma normal de Boyce-Codd (FNBC) si está en 2ª FN y
todos los determinantes son claves candidatas.
7. V
8. semánticas, ampliados, extendidos,
9. FNBC, multivalentes, 4FN.
10. aplicarlas, E/R, relacional.
120
Soluciones a los ejercicios de autocomprobación
Unidad 7
1. V
2. V
3. F. En ocasiones, es necesario trabajar con tipos de objetos muy parecidos pero
no iguales. En estos casos es conveniente utilizar la herencia, que es una carac-
terística del paradigma orientado a objetos.
4. F. Varray es una colección ordenada de datos, cada uno asociado a un índice
para acceder a ellos. Al definir un Varray (vector), es necesario definir el número
de elementos que contendrá.
5. V
6. V
7. F. Para el borrado de objetos se utiliza la sentencia DELETE y la cláusula WHERE
para eliminarlos selectivamente.
8. modelo, lenguaje, objetos.
9. nombre, parámetros, iguales.
10. t ipos, padre, atributos.
121
Índice
Introducción al módulo
Esquema de contenido
5. Programación de base de datos .......................................................................................................................................... 82

5.1 Introducción. Lenguaje de programación ....................................................................................................................... 82
5.2 Palabras reservadas ......................................................................................................................................................................... 82
5.3 Variables del sistema y variables de usuario ................................................................................................................... 83
5.3.1 Variables del sistema .......................................................................................................................................................... 84
5.3.2 Variables del usuario ........................................................................................................................................................... 84
5.4 Comentarios ........................................................................................................................................................................................ 85
5.5 Funciones .............................................................................................................................................................................................. 86
5.6 Estructuras de control de flujo: alternativas y bucles ................................................................................................ 86
5.7 Herramientas para creación de guiones. Procedimientos de ejecución ...................................................... 88
5.8 Procedimientos almacenados. Funciones de usuario .............................................................................................. 89
5.9 Subrutinas. Variables locales y globales ............................................................................................................................. 89
5.10 Eventos y disparadores ............................................................................................................................................................... 90
5.11 Excepciones. Tratamiento de excepciones .................................................................................................................... 91
5.12 Cursores. Funciones de tratamiento de cursores ....................................................................................................... 92
5.13 API para lenguajes externos .................................................................................................................................................... 93
Resumen ........................................................................................................................................................................................................ 94
6. Interpretación de diagramas entidad/relación ....................................................................................................... 97

6.1 Entidades y relaciones. Cardinalidad ................................................................................................................................... 97
6.2 Simbología de los diagramas E/R .......................................................................................................................................... 98
6.3 Debilidad ............................................................................................................................................................................................... 99
6.4 El modelo E/R ampliado: reflexión y jerarquía ............................................................................................................... 99
6.4.1 La reflexión ............................................................................................................................................................................... 100
6.4.2 La jerarquía ............................................................................................................................................................................... 100
6.5 Paso del diagrama E/R al modelo relacional ................................................................................................................... 101
6.6 Formas normales .............................................................................................................................................................................. 102
6.6.1 Primera forma normal ....................................................................................................................................................... 102
122
Índice
6.6.2 Segunda forma normal .................................................................................................................................................... 103

6.6.3 Forma normal de Boyce-Codd .................................................................................................................................... 103
6.6.4 Cuarta forma normal (4FN) ............................................................................................................................................ 104
6.6.5 Quinta forma normal (5FN) ............................................................................................................................................ 104
6.7 Normalización de modelos relacionales ........................................................................................................................... 105
Resumen ........................................................................................................................................................................................................ 107
7. Uso de bases de datos relacionales ................................................................................................................................... 110

7.1 Características de las bases de datos objeto-relacionales ...................................................................................... 110
7.2 Tipos de datos objeto: atributos, métodos, sobrecarga y constructores ...................................................... 110
7.3 Definición de tipos de objeto. Definición de métodos ........................................................................................... 111
7.4 Herencia ................................................................................................................................................................................................. 112
7.5 Identificadores; referencias ........................................................................................................................................................ 112
7.6 Tablas de objetos y tablas con columnas tipo objeto .............................................................................................. 113
7.7 Tipos de datos colección .............................................................................................................................................................. 113
7.8 Declaración e inicialización de objetos .............................................................................................................................. 114
7.9 Uso de la sentencia SELECT ....................................................................................................................................................... 114
7.10 Navegación a través de referencias .................................................................................................................................... 115
7.11 Llamadas a métodos .................................................................................................................................................................... 115
7.12 Inserción de objetos ................................................................................................................................................................... 115
7.13 Modificación o borrado de objetos .................................................................................................................................. 116
Resumen ........................................................................................................................................................................................................ 117
123

DAM MP02 Bases de Datos

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

DAM MP02 Bases de Datos

Cargado por

Copyright:

Formatos disponibles

Ciclos Formativos de Grado

Módulo: Bases de datos / Desarrollo de aplicaciones web

© Planeta DeAgostini Formación, S.L.U.

En este módulo desarrollaremos las habilidades necesarias para estructurar, crear

Estudiaremos las consultas de las bases de datos y aprenderemos a utilizarlas para

Otro aspecto importante es cómo manipular la información de nuestra base

• Base de datos relacionales

En esta unidad estudiaremos lo que son las bases de datos y profundizaremos en

Veremos también cuándo es importante almacenar la información en bases de

●● Ficheros planos. Aquellos que almacenan los registros de datos en formato de

●● Ficheros indexados. Aquellos que asignan un índice o clave a los registros y

1.2 Bases de datos

Los datos almacenados en una base de datos se guardan en disco en forma de

●● Modelos lógicos basados en objetos. Se utilizan para describir datos en el ni-

●● Modelos lógicos basados en registros. Se utilizan para describir datos en el nivel

●● El diccionario de datos es el lugar donde se almacena información acerca de

CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,

SELECT persona FROM empresa WHERE sueldo>1000;

●● Los mecanismos para garantizar la seguridad e integridad de los datos sirven

●● El administrador de la base de datos es la persona que posee el máximo nivel de

1.4 Sistemas gestores de bases de datos comerciales y libres

Actualmente, existe en el mercado una gran variedad de sistemas gestores de ba-

Cuando los datos se encuentran distribuidos entre diversos puntos, la relación

Indica si las siguientes afirmaciones son verdaderas (V) o falsas (F):

5. El lenguaje de definición de datos (LDD o DDL) lo emplean los diseñadores y

Completa las siguientes afirmaciones:

8. Los datos almacenados en una base de datos se guardan en ______________

9. El administrador de la base de datos es la persona que posee el ______________

Las soluciones a los ejercicios de autocomprobación se encuentran al final de esta Unidad

2. BASE DE DATOS RELACIONALES

El modelo relacional de una base de datos fue introducido en 1970 por el

2.1 Modelo de datos

El modelo de datos es un lenguaje orientado a describir una base de datos (Figu-

●● Estructuras de datos. Son los tipos de datos contenidos en la base y la forma en

●● Operaciones de manipulación. Son aquellas operaciones de agregado, borra-

La clasificación de los modelos de datos se realiza según el nivel de abstracción

●● Lógicos. Son los orientados a las operaciones. Normalmente se implementan en

2.2 Terminología del modelo relacional Recuerda

●● Atributo (attribute). Corresponde a las divisiones verticales de la relación. El

Sistemas gestores Sistemas gestores

Relación Tabla Fichero

2.3 Características de una relación

●● El orden de las filas de una tabla es irrelevante.

●● Todas las entradas de cualquier columna son de un solo tipo.

●● A cada columna se le asigna un nombre que refleje la característica correspon-

●● El orden de las columnas no es importante para la tabla.

A continuación, podremos ver la relación que existe entre la Tabla director y la

Cada empleado tiene un director asociado mediante la columna “Director” (Figura

manera, se crea una dependencia de la tabla foránea, y así si eliminamos al director

2.4 Tipos de datos

La teoría de bases de datos relacionales no establece ninguna norma concreta con

Los sistemas gestores de bases de datos incorporan sus propias especificacio-

●● Numéricos. Los tipos de datos numéricos pueden dividirse en numéricos ente-

●● Cadena. Los tipos de datos cadena pueden dividirse en alfanuméricos o en

2.5 Juegos de caracteres

Existen extensiones que utilizan 8 bits para proporcionar caracteres adicionales,

2.6 Claves primarias

Se denomina clave candidata (candidate key) al conjunto no vacío de atributos que

DNI Apellido Nombre Ciudad

00000000 A Sánchez Pablo Barcelona Figura 2.8

La tabla de la figura 2.8 representa un listado de personas y en ella podremos de-

En ella definiremos tres claves candidatas:

Diremos que una clave primaria es simple cuando el conjunto de atributos no

5. El lenguaje de definición de datos (LDD o DDL) lo emplean los diseñadores y

8. Los datos almacenados en una base de datos se guardan en ______________

9. El administrador de la base de datos es la persona que posee el ______________

7. Una clave alternativa es aquella clave candidata que no ha sido seleccionada

8. NULL indica un valor asignado a un ______________ que no contiene ninguno

9. Las claves foráneas no necesitan ser claves ______________ en la tabla referida,

10. Un privilegio es un permiso dado a un ______________ dentro de la base de