MÓDULO 1 – BASE DE DATOS I

INGENIERÍA DE SOFTWARE
MODALIDAD A DISTANCIA
UNIVERSIDAD DE CARTAGENA

UNIDAD 1 – INTRODUCCIÓN A LAS BASES DE DATOS I

1.1. INTRODUCCIÓN A LA ASIGNATURA

En el entorno del mercado actual, la

competitividad y la rapidez de maniobra de una
empresa son imprescindibles para su éxito.
Para conseguirlo existe cada vez una mayor
demanda de datos y, por tanto, más necesidad
de gestionarlos. Esta demanda siempre ha
estado patente en empresas y sociedades,
pero en estos años se ha disparado debido al
acceso multitudinario a las redes integradas en
Internet y a la aparición de los dispositivos
móviles que también requieren esa
información.

En informática se conoce como dato a cualquier elemento informativo que tenga

relevancia para un usuario. Desde su nacimiento, la informática se ha encargado de
proporcionar herramientas que faciliten la manipulación de los datos. Antes de la aparición
de las aplicaciones informáticas, las empresas tenían como únicas herramientas de gestión
de datos los ficheros con cajones, carpetas y fichas de cartón. En este proceso manual, el
tiempo requerido para manipular estos datos era enorme. Pero la propia informática ha
adaptado sus herramientas para que los elementos que el usuario utiliza en cuanto a
manejo de datos se parezcan a los manuales. Por eso se sigue hablado de ficheros,
formularios, carpetas, directorios,….

La clientela fundamental del profesional informático es la empresa. La empresa se puede

entender como un sistema de información formado por diversos objetos: el capital, los
recursos humanos, los inmuebles, los servicios que presta, etc.

Los sistemas de información actuales se basan en bases de datos (BD) y sistemas de

bases de datos (SGBD) que se han convertido en elementos imprescindibles de la vida
cotidiana de la sociedad moderna.

Los predecesores de los sistemas gestores de bases de datos fueron los sistemas gestores
de ficheros o sistemas de archivos tradicionales.

Archivos tradicionales. Consiste en almacenar los datos en archivos

individuales, exclusivos para cada aplicación particular. En este sistema los datos

Elaborado por: Ing. Vladimir Roa Pérez

 pueden ser redundantes (repetidos innecesariamente) y la actualización de los
archivos es más lenta que en una base de datos.

Base de datos. Es un almacenamiento de datos formalmente definido, controlado

centralmente para intentar servir a múltiples y diferentes aplicaciones. La base de
datos es una fuente de datos que son compartidos por numerosos usuarios para
diversas aplicaciones.

Así, en un Sistema de archivos tradicional la información está dispersa en varios ficheros

de datos y existe un cierto número de programas que los recuperan y agrupan. Aunque los
sistemas de ficheros o archivos supusieron un gran avance sobre los sistemas manuales,
tienen inconvenientes bastante importantes que se solventaron, en gran medida, con la
aparición de los sistemas de bases de datos.

Coincidiendo con la evolución histórica de las bases de datos éstas han utilizado distintos
modelos:

• Jerárquicos
• En red.
• Relacionales.
• Multidimensionales.
• De objetos.

ACTIVIDAD 1.

1. Identifique los términos en la sopa de letras

1.2. DEFINICIÓN DE BASE DE DATOS

Cada día, la mayoría de nosotros nos encontramos con actividades que requieren algún
tipo de interacción con una base de datos (ingreso en un banco, reserva de una entrada
para el teatro, solicitud de una suscripción a una revista, compra de productos, …). Estas
interacciones son ejemplos de lo que se llama aplicaciones tradicionales de bases de datos

Elaborado por: Ing. Vladimir Roa Pérez

(básicamente información numérica o de texto), aunque los avances tecnológicos han
permitido que también existan: bases de datos multimedia, sistemas de información
geográfica (GIS), almacenes de datos, sistemas de proceso analítico on-line, …

• Una base de datos se entenderá como una colección de datos relacionados entre
sí y que tienen un significado implícito.
• Por datos queremos decir hechos conocidos que pueden registrarse y que tienen
un significado implícito.

Ejemplo

Una agenda con los nombres y teléfonos de un conjunto de personas conocidas es una base
de datos, puesto que es una colección de datos relacionados con un significado implícito.

La definición presentada anteriormente hace referencia a dos elementos para que un

conjunto de datos constituya una Base de Datos:

1. Relaciones entre datos, tema que se tratará en las secciones siguientes.

2. Significado implícito de los datos que se atribuye dependiendo del contexto en
que se utilizan los mismos. Por ejemplo, el dato fecha en una base de datos de
VENTAS puede referirse a la fecha de emisión de las facturas, mientras que si la
base de datos es de MÚSICA quizás corresponda a la fecha en que se grabó un
tema musical. Es decir, el significado de un dato, depende de la BD que lo
contenga.

Para manipular y gestionar las bases de datos surgieron herramientas software

denominadas: sistemas gestores de bases de datos (SGBD en lo sucesivo) sobre los que
se profundizará en las siguientes secciones.

ACTIVIDAD 2

1. Consulte y conceptualice los siguientes términos para bases de datos. Elabore un

documento en Word, usando las normas ICONTEC:
• Base de Datos
• Sistema de Gestión de Base de Datos
• Gestores de bases de datos más utilizados, clasificarlos en los que son
gratuitos y los que son con licencia paga
• Tabla en una base de datos
• Dato en una base de datos, ejemplo
• Campo en una base de datos, ejemplos
• Registro en una base de datos, ejemplos
• Clave, Clave principal
• Tipos de bases de Datos
• Modelo de Bases de Datos

2. Haga una tabla en la que identifiquey señale: dato, campo, Tabla, registro y archivo.
3. Elabore un cuadro comparativo con las ventajas ydesventajas de un SGBD.

Elaborado por: Ing. Vladimir Roa Pérez

 4. Relacione al menos 4 SGBD, gratuitos y al menos 4 licenciados, que existan enel
mercado, incluya sus características.
5. Construya la línea de tiempo la historia y las generaciones de las bases de datos
sistematizadas.

1.3. BASES DE DATOS RELACIONALES Y NO RELACIONALES.

FUNDAMENTOS Y CONCEPTOS

Es muy común que los desarrolladores de software estemos en la situación de elegir entre
bases de datos relacionales y no relacionales. No es para verlo como un dilema o pensar
que dependiendo de la decisión vamos a fracasar, en realidad con cualquiera de las dos
opciones, es posible construir nuestro sistema, dependiendo de lo que queramos.

Entonces surgen diferentes interrogantes: ¿Es importante saber las diferencias entre
ambas bases de datos? ¿Cuál deberíamos usar en cada caso? Estas son preguntas
bastante interesantes, puesto que un buen diseño de la base de datos es un factor de alta
influencia con respecto a la calidad del proyecto. Dependiendo de la naturaleza de éste, se
debe elegir la base de datos, ya que las dos tienen diferentes características. Lee: 3 tipos
de análisis de datos para mejorar la toma de decisiones

Para conocer un poco de historia, las bases de datos relacionales se comenzaron a utilizar
en los años 80; a diferencia de las no relacionales que se están empezando a usar y
tuvieron un importante crecimiento entre 2012 y 2015. Sin embargo, hoy sigue siendo más
popular la primera opción.

1.3.1. Bases de Datos relacionales

Son una colección de elementos de datos organizados en un conjunto de tablas
formalmente descritas, desde donde se puede acceder a los datos o volver a montarlos de
muchas maneras diferentes sin tener que reorganizar las tablas de la base. La interfaz

Elaborado por: Ing. Vladimir Roa Pérez

estándar de programa de usuario y aplicación a una base de datos relacional, es el
Lenguaje de Consultas Estructuradas (SQL). Los comando SQL se utilizan tanto para
consultas interactivas como para obtener información de una base de datos relacional y la
recopilación de datos para informes.

Las bases de datos relacionales se basan en la organización de la información en partes

pequeñas que se integran mediante identificadores; a diferencia de las bases de datos no
relacionales que, como su nombre lo indica, no tienen un identificador que sirva para
relacionar dos o más conjuntos de datos. Además son más robustas, es decir, tienen mayor
capacidad de almacenamiento, y son menos vulnerables ante fallas, estas son sus
principales características.

1.3.2. Bases de datos no relacionales

Están diseñadas específicamente para modelos de datos específicos y tienen esquemas
flexibles para crear aplicaciones modernas. Son ampliamente reconocidas porque son
fáciles de desarrollar, tanto en funcionalidad como en rendimiento a escala. Usan una
variedad de modelos de datos, que incluyen documentos, gráficos, clave-valor, en-memoria
y búsqueda.

Las bases de datos no relacionales (NoSQL) son las que, a diferencia de las relacionales,
no tienen un identificador que sirva de relación entre un conjunto de datos y otros. Como
veremos, la información se organiza normalmente mediante documentos y es muy útil
cuando no tenemos un esquema exacto de lo que se va a almacenar.

Con relación a formatos, la información de una base de datos puede ser almacenada en
tablas o documentos. Cuando los datos son organizados en un archivo de Excel, es en
formato tabla, pero cuando simplemente son datos escritos como cartas, fórmulas o
recetas, son datos en formato documento. Esto aplica para los dos tipos de bases de datos.

Habitualmente los datos almacenados en tablas son bases de datos relacionales, porque
existe la posibilidad de enlazar los datos de una tabla con los de otra y los datos
almacenados en documentos son no relacionales, aunque no siempre tiene que ser así.

Elaborado por: Ing. Vladimir Roa Pérez

Por ejemplo, los datos de una tabla pueden ser transcritos a un documento, todo depende
del punto de vista y la necesidad del problema que se vaya enfrentar.

Para ilustrar una de las diferencias entre bases de datos SQL y NOSQL, vamos a dar un
ejemplo. Imaginemos por un momento una ciudad como Medellín (Colombia), donde todas
las personas hablan el mismo idioma, por tanto es la única forma de que todos los
residentes se comuniquen e interactúen. Si se cambia ese idioma se perjudican todos los
residentes.

Las bases de datos relacionales utilizan un lenguaje de consulta estructurado para la

manipulación de datos, estas se conforman por filas, columnas y registros y se almacenan
por tablas. Para manipular los datos en SQL, se requiere primero determinar la estructura
de estos, si se cambia la estructura de uno de los datos, puede perjudicar todo el sistema,
ya que las tablas están relacionadas.

Ahora imaginemos otra ciudad como Bogotá (Colombia) y pensemos hipotéticamente que
en cada uno de los hogares se habla un idioma diferente, todos interactúan distinto y no
hay entendimiento entre todos, pero nadie afecta a nadie. Las bases de datos no
relacionales tienen un esquema dinámico, no se requiere la estructura de los datos para su
manipulación. Los datos se pueden almacenar de cualquier manera, columnas,
documentos, gráficos, etc, y cada documento puede tener su propia estructura, sin afectar
los demás, puede agregar más campos a medida que se avanza. Están conformadas por
documentos, campos y datos del documento, además, se almacenan por colecciones.

Tanto SQL como NoSQL son tipos de bases de datos recomendadas para utilizar a la hora
de comenzar con tus proyectos, cada una de ellas con ventajas y desventajas.

Por ejemplo los sistemas contables, o de inventario, son sistemas que requieren
transacciones de varias filas, para este tipo de trabajos la mejor opción son las bases de
datos SQL (MySq). Si los sistemas son de gestión de contenido, aplicaciones móviles,
sistemas de análisis en tiempo real, bases de datos con un crecimiento rápido, con un
esquema descentralizado, la mejor opción son bases de datos NOSQL (MongoDB).

Algunas de las ventajas de SQL: mayor soporte y más variedad de herramientas debido a
que lleva más tiempo en el mercado, es útil para manejar y obtener los datos, permite

Elaborado por: Ing. Vladimir Roa Pérez

agregar otros servidores de SQL, por ejemplo una persona puede acceder a la base de
datos de otra.

Como desventajas de SQL están: No es flexible (antes de ingresar los objetos, deben estar
correctamente validados), mientras más compleja sea la base de datos, requiere mayor
procesamiento y eso se puede ver reflejado en el rendimiento y consumo de recursos.

Ahora, conozcamos algunas de las ventajas de las bases de datos NOSQL: permite una
alta escalabilidad (ayuda a reducir la carga de trabajo), flexible a diferentes tipos de datos,
los datos deben cumplir con el tipo de dato definido, y algunas desventajas: la integridad de
los datos se afecta por el poco soporte, menos seguridad al ejecutar consultas, no existe
estandarización, en la mayoría de los casos son poco compatibles con las bases de datos
SQL, casi todo su mantenimiento se debe realizar por consola debido a que existen pocas
herramientas.

Muchas personas piensan que deben migrar sus bases de datos a tecnologías NOSQL ya
que es lo “nuevo”, pero es un pensamiento errado. NOSQL no es el reemplazo de SQL,
simplemente es un modelo diferente que ofrece ventajas y soluciones a problemas que
poseen las bases de datos relacionales.

Para ilustrar una de las diferencias entre bases de datos SQL y NOSQL, vamos a dar un
ejemplo. Imaginemos por un momento una ciudad como Medellín (Colombia), donde todas
las personas hablan el mismo idioma, por tanto es la única forma de que todos los
residentes se comuniquen e interactúen. Si se cambia ese idioma se perjudican todos los
residentes.

Las bases de datos relacionales utilizan un lenguaje de consulta estructurado para la

manipulación de datos, estas se conforman por filas, columnas y registros y se almacenan
por tablas. Para manipular los datos en SQL, se requiere primero determinar la estructura
de estos, si se cambia la estructura de uno de los datos, puede perjudicar todo el sistema,
ya que las tablas están relacionadas.

Elaborado por: Ing. Vladimir Roa Pérez

Ahora imaginemos otra ciudad como Bogotá (Colombia) y pensemos hipotéticamente que
en cada uno de los hogares se habla un idioma diferente, todos interactúan distinto y no
hay entendimiento entre todos, pero nadie afecta a nadie. Las bases de datos no
relacionales tienen un esquema dinámico, no se requiere la estructura de los datos para su
manipulación. Los datos se pueden almacenar de cualquier manera, columnas,
documentos, gráficos, etc, y cada documento puede tener su propia estructura, sin afectar
los demás, puede agregar más campos a medida que se avanza. Están conformadas por
documentos, campos y datos del documento, además, se almacenan por colecciones.

ACTIVIDAD 3

Realice los ejercicios descritos a continuación. Para cada uno de los ejercicios siguientes,
obtener el esquema lógico relacional correspondiente a la especificación de requisitos. Para
algunos ejercicios se ha adjuntado un esquema conceptual. En cada esquema lógico se deben
señalar los atributos que son clave primaria y los que son clave ajena, especificando para
estos últimos si aceptan nulos o no y sus reglas de comportamiento ante el borrado y
modificación de tuplas de la relación a la que referencian.

Ejercicio 1

Se quiere diseñar una base de datos relacional para almacenar información sobre los
asuntos que lleva un gabinete de abogados. Cada asunto tiene un número de expediente
que lo identifica, y corresponde a un solo clientve. Del asunto se debe almacenar el período
(fecha de inicio y fecha de archivo o finalización), su estado (en trámite, archivado, etc.),
así como los datos personales del cliente al que pertenece (DNI, nombre, dirección, etc.).
Algunos asuntos son llevados por uno o varios procuradores, de los que nos interesa
también los datos personales.

Ejercicio 2

Se quiere diseñar una base de datos relacional que almacene información relativa a los
zoos existentes en el mundo, así como las especies animales que éstos albergan. De cada
zoo se conoce el nombre, ciudad y país donde se encuentra, tamaño (en m2) y presupuesto
anual. De cada especie animal se almacena el nombre vulgar y nombre científico, familia a
la que pertenece y si se encuentra en peligro de extinción. Además, se debe guardar
información sobre cada animal que los zoos poseen, como su número de identificación,
especie, sexo, año de nacimiento, país de origen y continente.

Ejercicio 3

Se quiere diseñar una base de datos relacional para gestionar los datos de los socios de
un club náutico. De cada socio se guardan los datos personales y los datos del barco o
barcos que posee: número de matrícula, nombre, número del amarre y cuota que paga por
el mismo. Además, se quiere mantener información sobre las salidas realizadas por cada

Elaborado por: Ing. Vladimir Roa Pérez

barco, como la fecha y hora de salida, el destino y los datos personales del patrón, que no
tiene porque ser el propietario del barco, ni es necesario que sea socio del club.

1.4. FUNDAMENTOS DE ANÁLISIS Y MODELADO DE BASES DE

DATOS RELACIONALES

Un concepto capital del modelo relacional es el de relación, postulado por el matemático y

teórico de bases de datos Edgar F. Codd. Siguiendo al científico británico, una relación
representa un conjunto de entidades con las mismas propiedades. Cada relación se
compone de una serie de filas o registros (las llamadas tuplas), cuyos valores dependen de
ciertos atributos (columnas).

Para definir los atributos de una relación y el tipo de dato (dominio) permitido para estos
valores, se utiliza un esquema con esta sintaxis:

R = (A1:D1, A2:D2,… , An:Dn)

Aquí, la relación R comprende de los atributos A1a An y cada atributo corresponde a un tipo
de dato o dominio (D1, D2 , etc.).

Veámoslo a la luz de un ejemplo concreto. El siguiente esquema define los atributos de la

relación “Empleados”:

Elaborado por: Ing. Vladimir Roa Pérez

segundo apellido, nombre, número de la seguridad social (nº SS), calle, código postal y
municipio, y podría utilizarse para la gestión interna de los datos personales de la plantilla
de una empresa.

A cada atributo le corresponde un tipo de dato, string o integer, lo que indica que hay
atributos que esperan cómo valor una secuencia de caracteres (string) y otros que solo
aceptan números enteros (integer).

Una relación con el esquema explicado arriba podría contener la siguiente tupla (fila):

La tabla, concepto clásico de la organización de la información, es el formato que utiliza el

modelo relacional para explicar de un modo visual la ordenación de los valores de una tupla
en función de los atributos definidos en la relación. Una base de datos relacional no es otra
cosa, entonces, que un conjunto de tablas interrelacionadas.

Las tablas son sistemas de clasificación constituidos por filas horizontales y columnas
verticales que permiten agrupar datos y presentarlos de forma ordenada. Cada fila de una
tabla se denomina tupla. Los valores que contiene cada tupla vienen determinados por los
atributos definidos en el esquema relacional.

Elaborado por: Ing. Vladimir Roa Pérez

En el modelo de bases de datos relacional se llama relación a un conjunto de tuplas con los
mismos atributos

En el siguiente ejemplo se muestra una tabla tal como resultaría del esquema anterior:

Esta tabla guarda los datos de la plantilla de una empresa y se compone de cuatro registros,
cada uno de los cuales contiene información sobre un solo empleado.

¿Cómo funcionan las bases de datos relacionales?

Los datos estructurados en tablas constituyen la BD de un sistema relacional. El SGBD

define su estructura y gestiona también los permisos de escritura y lectura y para interactuar
con él, los usuarios utilizan un lenguaje de bases de datos. Todo gestor de bases de datos

Elaborado por: Ing. Vladimir Roa Pérez

relacionales soporta al menos un lenguaje formal que permite ejecutar las siguientes
operaciones:

• Definir la estructura de datos: en la definición de los datos se guarda una

descripción con metadatos de la estructura de datos en el diccionario del sistema.
Cuando un usuario crea una tabla nueva, en el diccionario de datos se almacena su
correspondiente esquema. El vocabulario de un lenguaje de bases de datos que se
utiliza para definir los datos se denomina Data Definition Language (DDL), lenguaje
de definición de datos.

• Definir derechos: todos los lenguajes de bases de datos proporcionan una sintaxis
que permite otorgar o retirar permisos. En este contexto se habla de Data Control
Language (DCL) o lenguaje de control de datos, un vocabulario integrado en el
lenguaje de bases de datos.

• Definir condiciones de integridad: por condiciones de integridad se entienden los

requisitos de estado que se exigen a un banco de datos. Si se definen condiciones
para su integridad, la BD garantiza que se cumplan en todo momento. Se habla
entonces de un estado consistente. Una condición básica de integridad en una base
de datos relacional es, por ejemplo, que cada registro (tupla) pueda identificarse de
forma inequívoca.

• Definir transacciones: cuando se lleva a una BD de un estado consistente a otro

diferente se habla de transacción. Estas transacciones contienen una serie de
instrucciones que deben ejecutarse siempre de forma íntegra. Si una se interrumpe,
la BD vuelve a su estado original (Rollback). Cada transacción comienza con una
orden para crear una conexión con la BD a la que siguen otras que inician las
operaciones de datos en sí, así como un paso de comprobación (Commit) que
asegura la integridad de la BD. Las operaciones que pongan en peligro la integridad
de la tabla no se consignan (committed), es decir, no se escriben en la base de
datos de forma permanente. Por último, se cierra la conexión con la BD. Al
vocabulario del lenguaje de bases de datos con el que se manipulan los datos se le
conoce como Data Manipulation Language (DML).

• Definir vistas: las llamadas views son vistas virtuales de un subconjunto de los
datos de una tabla. Para crear una vista, el SGBD genera una tabla virtual (relación
lógica) sobre la base de las tablas físicas. En estas vistas pueden emplearse las
mismas operaciones que se utilizarían en tablas físicas. Según la función de la vista
de datos pueden distinguirse distintos tipos de vista. Las más habituales son
aquellas que filtran determinadas filas (consulta de selección) o columnas (vista de
columnas) de una tabla, así como las que conectan diversas tablas entre sí (vista
de conjunto).

En el modelo relacional se utiliza de forma estándar para estas operaciones el lenguaje de

bases de datosSQL (Structured Query Language), basado en el álgebra relacional.

Las operaciones típicas de las BD como consultar, crear, actualizar o borrar datos se
realizan por medio de las llamadas sentencias SQL (SQL statements), una combinación
de órdenes SQL, semánticamente vinculadas al inglés y por este motivo bastante
elocuentes. La siguiente tabla contiene términos fundamentales del modelo de datos
relacional y su equivalente en terminología SQL:

Elaborado por: Ing. Vladimir Roa Pérez

Para ejecutar una consulta sencilla con SQL podemos utilizar este esquema:

Utilizamos SELECT en primer lugar para ordenar al SGBD relacional que consulte ciertos
datos. A continuación definimos los datos que queremos consultar proporcionando tanto la
tabla como la columna que deseamos seleccionar. Con WHERE integramos una condición
en la sentencia SQL porque no queremos abrir todos los valores en esta columna, sino solo
el valor de un determinado registro.

Volviendo a nuestra tabla “Empleados”, esta sentencia SQL podría resultar así:

Esta declaración indica al gestor de la BD que invoque un valor de la columna nº SS de la

tabla “Empleados”. La condición que hemos definido es que se seleccione el valor del
registro cuyo valor de atributo de la columna e_ID equivalga al valor 3.

Como resultado, la base de datos entrega el valor 25 091225 46, el número de la seguridad
social de Gonzalo Expósito Hernández, el empleado identificado con el número 3.

Normalización

Cuando se trabaja con bases de datos relacionales, rara vez se hace con una única tabla.
Normalmente se manejan arquitecturas en las cuales los datos se clasifican en tablas
separadas en función de su significado. La necesidad de hacer consultas cruzadas para
obtener datos guardados en tablas diferentes es la que da origen al concepto que sustenta
el modelo relacional de bases de datos.

Elaborado por: Ing. Vladimir Roa Pérez

En principio, la información de una base de datos relacional podría guardarse sin problemas
en una sola tabla, con la ventaja de que no sería necesario interconectar diversas tablas ni
utilizar la compleja sintaxis derivada de las consultas a varias tablas diferentes. Sin
embargo, es aquí precisamente donde reside la fuerza del modelo relacional, pues el
reparto de información en varias tablas contribuye a reducir las entradas dobles (las
llamadas anomalías), un proceso que se conoce como “normalización”. El grado de
normalización de una tabla puede definirse a partir de varias formas normales:

• Primera forma normal (1FN)

• Segunda forma normal (2FN)
• Tercera forma normal (3NF)
• Forma normal de BoyceCodd (FNBC)
• Cuarta forma normal (4FN)
• Quinta forma normal (5FN)

Los requisitos de cada una de estas formas normales y la translación de una base de datos
de una forma normal a otra son temas de nuestro artículo sobre la normalización.

En este modelo de datos se llama “relaciones” (relationships) a las relaciones entre tablas
separadas por medio de claves. Estas claves son las que conectan las tablas entre sí y
permiten que los datos de tablas diferentes puedan consultarse o modificarse siempre con
la misma sentencia.

Claves

Las tablas como la de nuestro ejemplo permiten consultar valores o registros de distintas
formas, pero en todas ellas el componente principal son las claves. En el modelo relacional
se conoce como claves a los atributos que sirven para identificar un registro de forma
inequívoca.

Volviendo a nuestra tabla “Empleados”, la siguiente clave permite identificar una tupla:

Con los datos de la tabla, la siguiente clave serviría para identificar de forma única el registro
del empleado Gonzalo Expósito:

A estas llaves se las conoce como superclaves, si bien en la práctica tienen poca
relevancia, entre otras cosas porque a menudo contienen más atributos de los necesarios.
En cambio, en el contexto de las bases de datos relacionales, acostumbra a trabajarse con
los fragmentos más pequeños de una superclave, los llamados candidatos a clave. Una
tabla puede contener varios candidatos a clave que identifican a las tuplas
inequívocamente.

Como hemos visto en nuestra consulta anterior, los registros de la tabla “Empleados”
pueden identificarse solo con el número de identificación (e_ID). Otro candidato a clave
podría ser el número de la seguridad social (nº SS). Una clave como {apellido, nombre}, en
cambio, no sería un buen candidato, ya que esta pareja de atributos no puede asignarse

Elaborado por: Ing. Vladimir Roa Pérez

con seguridad a un solo empleado (en una empresa podría encontrarse a varios empleados
con el mismo nombre y el mismo primer apellido). En consecuencia, una identificación con
esta clave no estaría libre de duda. Sin embargo, no puede haber dos empleados que
compartan el ID o número de la seguridad social.

Así, para nuestra tabla pueden definirse los siguientes candidatos a clave:

Las bases de datos relacionales suelen estructurarse de tal forma que uno de los posibles
candidatos a clave indique el orden de los registros. Este candidato a clave se convierte
entonces en clave primaria (primary key) y suele tratarse de números identificativos
consecutivos. En nuestra tabla sería e_ID.

Por su capacidad para identificar los registros en las bases de datos relacionales, las claves
se ajustan a la perfección para interconectar las diferentes tablas que componen una BD.
Para hacerlo, la clave primaria de una tabla se convierte en la clave ajena (foreign key) de
otra.

La tabla que presentamos a continuación contiene los datos que una empresa podría haber
registrado sobre su parque móvil. La clave primaria de la tabla llamada “Vehículos” es
un coche_ID consecutivo:

Ahora, para mostrar el coche que conduce cada empleado debería conectarse la tabla
“Vehículos” con la tabla “Empleados”. Una forma de hacerlo sería integrando la clave
primaria de la tabla del automóvil (coche_ID) como clave ajena en la tabla con los datos
sobre la plantilla:

Ahora sabemos que el trabajador García Fernández conduce un automóvil con el ID 3, la

señora Casas González uno con el ID 2 y que Josefa y Gonzalo comparten el coche con el
ID 1.

Elaborado por: Ing. Vladimir Roa Pérez

Si se tratara de saber qué trabajador llevará la próxima vez el coche al taller y cuándo lo
hará, se deberá consultar tanto la tabla “Empleados” como la tabla “Vehículos”. Pero como
se han conectado mediante la clave ajena, esta consulta puede hacerse una sola vez. Las
operaciones de BD que abarcan varias tablas se realizan en el modelo relacional con ayuda
de las llamadas sentencias JOIN.

JOIN

JOIN puede traducirse como la acción de “unir” o “combinar” y en este contexto hace
referencia a una operación que permite consultar varias tablas de
datos simultáneamente. Los datos que se extraen de las tablas seleccionadas se agrupan
en un subconjunto con todos los posibles resultados (espacio de muestreo en matemáticas)
y se entregan en función de las condiciones que se han definido.

El fundamento matemático del JOIN de SQL lo componen dos operaciones del álgebra
relacional: el producto cartesiano y la selección. Los usuarios deciden con la elección del
tipo de JOIN y con ayuda de una condición de selección qué datos se extraen de las
tablas.

Los JOIN se dividen en EQUI JOIN y NON EQUI JOIN.

Entre los tipos de JOIN más importantes se cuentan:

• INNER JOIN (combinación interna)

• OUTER JOIN (combinación externa)
• SELF JOIN (una tabla enlaza consigo misma)

En nuestro artículo sobre los JOIN de SQL conocerás cómo funcionan los JOIN de
SQL en las tablas de bases de datos relacionales y qué has de tener en cuenta al escoger
el tipo de JOIN.

Diferencias con otros modelos de bases de datos

Las bases de datos relacionales basadas en SQL se diferencian de los conceptos que
rompen con la estructura fija de las tablas y persiguen un enfoque alternativo a la hora de
organizar los datos. Entre los más importantes se encuentran las bases de datos
orientadas a objetos y los sistemas basados en documentos.

Con las bases de datos orientadas a objetos (BDOO) entra en escena a finales de la década
de 1980 un nuevo modelo que retoma elementos de la programación orientada a objetos y
permite el almacenamiento de los datos en forma de objetos. Aunque este principio no logra
consolidarse, algunas de sus ideas consiguen colarse en el desarrollo de sistemas de bases
de datos relacionales. El resultado son productos con extensiones objeto-relacionales que
facilitan el almacenamiento de tipos abstractos de datos en el modelo relacional de base de
datos.

Con los cambios en el uso de Internet que trajo consigo el nuevo siglo y la web 2.0, el
modelo relacional volvió a ser objeto de críticas. En el marco del movimiento NoSQL (Not
only SQL), cuyo objeto era crear sistemas de BD de gran rendimiento aptos para
aplicaciones con un uso masivo de datos, comienzan a desarrollarse entonces modelos

Elaborado por: Ing. Vladimir Roa Pérez

alternativos como el de las bases de datos orientadas a documentos (BDOD). Estos dos
modelos, los orientados a objetos y a documentos, se diferencian del modelo relacional
sobre todo en la forma como se almacenan y se accede a los datos.

Bases de datos orientadas a objetos

El modelo orientado a objetos considera el almacenamiento de datos como objetos, los

cuales se procesan de forma análoga a como sucede en la programación orientada a
objetos. Un objeto define a una entidad y contiene:

• los atributos necesarios para describir a la entidad,

• conexiones (relaciones) con otros objetos,
• funciones que permiten acceder a los datos almacenados (métodos).

Un objeto es, así, una combinación de datos en la cual también se define el punto de acceso
a estos datos. Los objetos se consideran tipos abstractos de datos.

El SGBD orientado a objetos (ODBMS, object database management system) asigna

automáticamente un ID a cada objeto que permite identificarle de forma única y dirigirse a
él con métodos. Este ID es independiente del estado del objeto y está desvinculado de sus
valores. Esto permite asignar ID diferentes a dos objetos con los mismos datos, esto es,
con un mismo estado. El modelo orientado a objetos se aleja así del relacional, modelo en
el que cada tupla puede identificarse a partir de sus datos, por ejemplo, con una clave
primaria.

Otra característica del modelo orientado a objetos es el aislamiento de los datos: la única
forma de acceder a los datos guardados es utilizando los métodos que el usuario ha definido
previamente. Esto protege a los datos de cambios procedentes de puntos de acceso no
definidos.

Por otro lado, las estructuras de bases de datos se definen aquí por medio de un sistema
de clases jerárquico. En el contexto de la programación orientada a objetos, una clase es
un conjunto de objetos que poseen las mismas propiedades y a cada clase de objetos le
subyace una definición de clases. Este esquema prescribe los atributos y los métodos de
todos los objetos de la misma clase, determinando así cómo se crean y se modifican.

Para interactuar con el sistema gestor de estas bases de datos, los usuarios utilizan un
lenguaje de consultas inspirado en SQL, el lenguaje de consultas a objetos u
OQL (Object Query Language). El resultado de una consulta OQL no es, como en SQL, un
espacio de resultados posibles, sino una lista de todos los objetos que satisfacen las
condiciones de la declaración OQL.

Algunas implementaciones conocidas del modelo de BDOO son Realm, ZODB y Perst.

El desarrollo de las BDOO pretendía solucionar un problema de la programación de

aplicaciones, la incompatibilidad de impedancia objeto-relacional (Object-relational
impedence mismatch), que se produce inevitablemente si se guardan objetos de un
lenguaje orientado a objetos como C#, C++ o Java en una base de datos relacional y resulta
de las diferencias fundamentales entre ambos paradigmas de programación, como son:

Elaborado por: Ing. Vladimir Roa Pérez

 • Las bases de datos relacionales no soportan conceptos orientados a objetos como
las clases y la herencia.
• El modelo relacional no permite la identificación de objetos independiente del
estado.
• El modelo relacional tampoco cuenta con el mecanismo de protección que aporta el
aislamiento de datos.

Una forma de evitar estos problemas de incompatibilidad consiste en no utilizar bases de

datos relacionales y optar por una BDOO cuando se programan aplicaciones orientadas a
objetos. Sin embargo, la desventaja de esta opción es que los datos encapsulados en
objetos dejan de estar disponibles fuera de la aplicación. A esto se añade la reducida
expansión de este tipo de bases de datos. La mayoría de herramientas e interfaces que se
utilizan para analizar bancos de datos sigue estando diseñada para bases de datos
relacionales y no soportan el modelo orientado a objetos.

Pese a todo, los programadores de aplicaciones que no quieran prescindir de las ventajas
del modelo relacional tienen la posibilidad de compensar estas incompatibilidades con
ayuda del mapeo objeto-relacional (O/R mapping o object-relational mapping, ORM).
Las funcionalidades para la representación objeto-relacional se implementan con
bibliotecas que crean una capa de abstracción entre la aplicación orientada a objetos y los
datos guardados en las tablas.

Asimismo, hay muchos fabricantes de sistemas relacionales que equipan sus productos
con funciones para compensar estas incompatibilidades con la programación orientada a
objetos. Estos sistemas se conocen como objeto-relacionales.

Las BDOO trasponen los principios de la orientación a objetos a la tecnología de bases de

datos y por ello son adecuadas sobre todo en la programación de aplicaciones orientada a
objetos, pero los sistemas de bases de datos de este tipo son poco frecuentes y aún muy
nuevos para el mercado.

Bases de datos objeto-relacionales

Los sistemas mixtos son sistemas de bases de datos relacionales que se han ampliado
con conceptos del modelo orientado a objetos. De este modo los principios probados
del modelo relacional se ampliarían a tipos abstractos de datos como los objetos.

Para poder gestionar estos tipos abstractos de datos, las bases de datos objeto-relacionales
amplían las bases de datos relacionales con:

• Tipos de datos complejos y personalizables: mientras que las bases de datos

relacionales solo pueden procesar datos alfanuméricos, con los tipos de datos
personalizables también se pueden gestionar archivos multimedia estructurados de
forma compleja.
• Constructores de tipos: permiten derivar tipos nuevos de los tipos básicos ya
existentes.
• Funciones y métodos: como SQL no permite crear funciones, los sistemas objeto-
relacionales han de proveer extensiones con las cuales puedan definirse funciones
de acceso y edición de tipos de datos complejos.

Elaborado por: Ing. Vladimir Roa Pérez

A partir del cambio de siglo se incluyen extensiones objeto-relacionales, como los tipos
estructurados, en las últimas versiones del estándar SQL, pero no los soportan todos los
SGBD. Algunos sistemas conocidos que disponen de estas extensiones son IBM Db2,
Oracle Database y Microsoft SQL Server.

Bases de datos orientadas a documentos

Si en las bases de datos relacionales los datos se almacenan en tablas, el modelo orientado
a documentos se basa en un conjunto heterogéneo de datos compuesto por documentos,
que pueden ser estructurados, como archivos JSON, YAML o XML, o no estructurados,
como Binary Large Objects (BLOB) –archivos de imagen, vídeo o audio.

En el caso de los documentos estructurados, el almacenamiento tiene lugar por medio

de pares clave/valor donde a cada clave se le asigna un valor concreto. En este
contexto se utiliza el término “clave” como sinónimo de atributo y no tiene nada que
ver con las claves del modelo relacional. Los valores pueden equivaler a cualquier tipo
de información. Las listas o las matrices también podrían ser valores.

Un documento en formato JSON para almacenar los datos de nuestra plantilla podría tener
esta construcción:

Varios documentos pueden agruparse en una colección de documentos, una

llamada collection. Este documento con datos de empleados podría unirse a otra parte de
la colección “Empleados”.

Las consultas tienen lugar utilizando funciones, lo que puede hacerse con JavaScript. Los
SGBD que trabajan orientados a documentos otorgan un ID único a cada documento, pero,
a diferencia de como ocurre en el modelo relacional, aquí no existe ningún esquema que
abarque a la base de datos por completo. Los documentos en una base de datos basada
en documentos no han de observar ninguna forma normal ni existen propiedades
estructurales que hayan de cumplirse en todos los documentos. En principio, cada
documento puede tener una estructura diferente. Pese a todo, en lo que hace al desarrollo
de aplicaciones, se recomienda crear los documentos en uno de los esquemas adecuados
a la aplicación para lograr los requisitos necesarios para poder realizar consultas.

Las relaciones, como la conexión de tablas de bases de datos en el modelo relacional, no

son posibles aquí. Aunque es posible añadir manualmente el ID de un documento como
referencia en un documento diferente, los SGBD orientados a documentos no ofrecen
JOIN, con lo que estas posibilidades de consulta deben programarse a propósito.

Elaborado por: Ing. Vladimir Roa Pérez

En definitiva, los sistemas orientados a documentos son la mejor opción si se han de
procesar grandes cantidades de datos con estructura heterogénea y escasa
interconexión. Esto hace a este modelo apto sobre todo para el trabajo con big data.

Los sistemas relacionales controlan en todo momento que se cumplan las condiciones
indicadas en las definiciones de las tablas, lo que, al procesar grandes volúmenes de datos,
conduce a una menor velocidad de escritura. Los sistemas NoSQL no presentan unos
requisitos de consistencia de datos tan estrictos, condición que los hace adecuados para
grandes arquitecturas en las cuales se han de gestionar de forma paralela muchas
instancias de base de datos.

También las aplicaciones web recurren con frecuencia creciente a las bases de datos
orientadas a documentos. Pero si se requiere una fuerte interconexión, el almacenamiento
basado en documentos va ligado a un esfuerzo mucho mayor. En este caso sería más
conveniente utilizar sistemas relacionales.

Algunos ejemplos de bases de datos orientadas a documentos son BaseX, CouchDB, eXist,
MongoDB y RavenDB.

ACTIVIDAD 4

Realice los ejercicios descritos a continuación. Para cada uno de los ejercicios siguientes,
obtener el esquema lógico relacional correspondiente a la especificación de requisitos. Para
algunos ejercicios se ha adjuntado un esquema conceptual. En cada esquema lógico se deben
señalar los atributos que son clave primaria y los que son clave ajena, especificando para
estos últimos si aceptan nulos o no y sus reglas de comportamiento ante el borrado y
modificación de tuplas de la relación a la que referencian.

Ejercicio 4

Se desea diseñar una base de datos relacional que almacene la información sobre los
préstamos de las películas de un vídeo club. En la actualidad la gestión de esta información
se lleva cabo del siguiente modo: Cuando se hace un préstamo se rellena una ficha en la
que se anota el socio que se lleva la película, la fecha y el número de la cinta que se lleva,
que es único (de cada película hay varias copias en cintas distintas). Esta ficha se deposita
en el archivador de películas prestadas. Cuando el socio devuelve la cinta, la ficha se pasa
al archivador de películas devueltas. El vídeo club tiene, además, un archivador con fichas
de películas ordenadas por título; cada ficha tiene además el género de la película
(comedia, terror, ...), su director y los nombres de los actores que intervienen. También se
tiene un archivador con las fichas de los socios, ordenadas por el código que el vídeo club
les da cuando les hace el carné; cada ficha tiene el nombre del socio, su dirección y
teléfono, los nombres de sus directores favoritos, los nombres de sus actores favoritos y los
géneros cinematográficos de su preferencia. Cuando un socio quiere tomar prestada una
película de la que no hay copias disponibles, se le puede anotar en la lista de espera de
esa película. Cada vez que se devuelve una película, se comprueba si hay alguien en su
lista de espera, y si es así se llama por teléfono al primer socio de la lista para decirle que
ya puede pasar a recogerla, borrándolo después de la lista.

Elaborado por: Ing. Vladimir Roa Pérez

 Ejercicio 5

Se desea almacenar la información de una compañía aérea en una base de datos

relacional. La compañía aérea tiene tres recursos principales: aviones, pilotos y miembros
de tripulación. De cada piloto se desea conocer su código, nombre y horas de vuelo. De los
miembros de tripulación sólo mantendremos su código y nombre. Todos ellos (pilotos y
miembros) tienen una base a la que regresan después de los vuelos de una jornada. Un
vuelo que va desde un origen a un destino y a una hora determinada, tiene un número de
vuelo (por ejemplo, el vuelo de Palma a Alicante de las 13:50 es el vuelo IB-8830). De cada
vuelo que se va a realizar durante los próximos tres meses, así como de los vuelos que ya
se han realizado, se desea saber el avión en que se va a hacer o en el que se ha hecho, el
piloto y cada uno de los miembros de la tripulación. Cada avión tiene un código, es de un
tipo (por ejemplo, BOEING-747) y tiene una base donde es sometido a las revisiones
periódicas de mantenimiento.

Elaborado por: Ing. Vladimir Roa Pérez

 Ejercicio 6

El servicio de estudiantes de la universidad proporciona información sobre las asignaturas

de cada titulación e información sobre los profesores, mediante los tipos de informe que se
muestran más adelante.

Para ello, posee un fichero de asignaturas y un fichero de profesores, con los

correspondientes programas que se encargan de gestionarlos y que generan dichos
informes. Dados los problemas de inconsistencia de datos que el sistema de ficheros
conlleva, se desea diseñar una base de datos relacional que lo sustituya.

Algunas aclaraciones que el servicio de estudiantes nos ha hecho son las siguientes: en
cada departamento hay varias áreas de conocimiento, cada una de las cuales imparte una
serie de asignaturas distintas en una o varias titulaciones. Cada profesor pertenece a un
único área de conocimiento de un departamento e imparte clases en una o varias
asignaturas de ese área.

Elaborado por: Ing. Vladimir Roa Pérez