Manual de Gestin de Bases de Datos

[1]
Sistemas Gestores de Bases de Datos
[1.1] datos y archivos
[1.1.1]la necesidad de gestionar informacin

En el mundo actual existe una cada vez mayor demanda de gestin de la

informacin. No es una demanda nueva, todas las sociedades a lo largo de la
historia han tenido esta necesidad. Desde el principio de los tiempos se ha
necesitado disponer de herramientas que facilitaran la gestin de los datos ya que,
como herramienta, el ser humano al principio slo dispona de su memoria y clculo
inmediato y, como mucho, de la ayuda de sus dedos.

La escritura fue la herramienta que permiti al ser humano almacenar informacin

y realizar clculos sobre ella. Adems de permitir compartir esa informacin entre
diferentes personas, tambin posibilit que los datos se guardaran de manera
continua e incluso estuvieran disponibles para las siguientes generaciones. Los
problemas actuales con la privacidad ya aparecieron con la propia escritura y as el
cifrado de datos es una tcnica tan antigua como la propia escritura para conseguir
uno de los todava requisitos fundamentales de la gestin de datos, la seguridad.

Cuanto ms se han desarrollado las sociedades, mejores mtodos se han

desarrollado para gestionar la informacin y, a la vez, ms datos se han necesitado
gestionar. Para poder almacenar datos y cada vez ms datos, el ser humano ide
nuevas herramientas: archivos, cajones, carpetas y fichas en las que se
almacenaban los datos.

Antes de la aparicin de las computadoras, el tiempo requerido para manipular estos

datos era enorme. Sin embargo el proceso de aprendizaje era relativamente
sencillo, ya que se usaban elementos que las personas manejaban desde su
infancia.

Por esa razn, la informtica se adapt para que la terminologa en el propio

ordenador se pareciera a los trminos de organizacin de datos clsicos. As, en
informtica se sigue hablado de ficheros, formularios, carpetas, directorios,....

En estos ltimos aos, la demanda ha crecido a niveles espectaculares debido al

acceso multitudinario a Internet y a los enormes flujos de informacin que generan
los usuarios. Cada ao la necesidad de almacenar informacin crece
exponencialmente en un frenes que, por ahora, no parece tener fin.

Desde la aparicin de las primeras computadoras, se intent automatizar la gestin

de los datos. El propio nombre Informtica hace referencia al hecho de ser una
ciencia que trabaja con informacin. Por ello las bases de datos son una de las
aplicaciones ms antiguas de la informtica.
[1.1.2]datos e informacin

Tradicionalmente siempre se ha separado el concepto de dato sobre el

de informacin.

Un dato es una propiedad en crudo, es decir, sin contextualizar. Por

ejemplo Snchez y 32 son datos. Desde el punto de vista de la computacin, ambos
datos se pueden almacenar. Sin embargo, no podemos considerarlos informacin
hasta que no les demos significado. Si decimos que Snchez es mi primer apellido
y que 32 son los grados centgrados de temperatura que hace ahora en la calle,
esos datos pasan a ser informacin.

La informacin tiene una importancia humana, es interpretable, reconocible,

presentable,.. El dato es simplemente el paso previo. Resumiendo: todo dato debe
de ser procesado para obtener informacin, y es la informacin lo que nos interesa
a los seres humanos.

Como veremos ms adelante, los datos se convierten en informacin gracias a

los metadatos: datos que sirven para describir otros datos.

[1.1.3]Sistemas de Informacin
la empresa como sistema

Segn la RAE, la definicin de sistema es Conjunto de cosas que ordenadamente

relacionadas entre s contribuyen a un determinado objeto .

La clientela fundamental del profesional de la informtica es la empresa, sin

distinguir entre la empresa privada y las entidades pblicas. Una empresa est
formada por diversos elementos que son comunes: el capital, los recursos
humanos, los inmuebles, los servicios que presta, etc. Todos ellos forman el
sistema de la empresa.

El sistema completo que forma la empresa, por otra parte, se suele dividir en los
siguientes subsistemas:

Subsistema productivo. Tambin llamado subsistema real o fsico.

Representa la parte de la empresa encargada de gestionar la produccin de
la misma.
Subsistema financiero. Encargado de la gestin de los bienes econmicos
de la empresa
Subsistema directivo. Encargado de la gestin organizativa de la empresa

Hay que hacer notar que cada subsistema se asocia a un departamento concreto
de la empresa.
Sistemas de Informacin

Los sistemas que aglutinan los elementos que intervienen para gestionar la
informacin que manejan los subsistemas empresariales es lo que se conoce como
Sistemas de Informacin. Se suele utilizar las siglas SI o IS (de Information Server)
para referirse a este concepto.

Vale tambin para gestionar la informacin de cualquier sistema, aunque no sea

empresarial. Pero la teora est basada en el sistema empresarial.

Realmente un sistema de informacin slo incluye aquello que nos interesa de la

empresa y los elementos necesarios para gestionar esa informacin.

Un sistema de informacin genrico est formado por los siguientes elementos:

Recursos fsicos. Carpetas, documentos, equipamiento, discos,...

Recursos humanos. Personal que maneja la informacin
Protocolo. Normas que debe cumplir la informacin para que sea manejada
(formato de la informacin, modelo para los documentos,...)

Las empresas necesitan implantar estos sistemas de informacin debido a la

competencia que las obliga a gestionar de la forma ms eficiente sus datos para
una mayor calidad en la organizacin de las actividades de los subsistemas
empresariales.

componentes de un Sistema de Informacin Electrnico

En el caso de una gestin electrnica de la informacin (lo que actualmente se

considera un sistema de informacin electrnico), los componentes son:

Datos. Se trata de la informacin relevante que almacena y gestiona el

sistema de informacin. Ejemplos de datos son: Snchez, 12764569F, Calle
Mayo 5, Azul
Hardware. Equipamiento fsico que se utiliza para gestionar los datos. cada
uno de los dispositivos electrnicos que permiten el funcionamiento del
sistema de informacin: servidores, mquinas de los clientes, routers,
switches, impresoras,
Software. Aplicaciones informticas que se encargan de la gestin de la
base de datos y de las herramientas que facilitan su uso.
Recursos humanos. Personal que maneja el sistema de informacin.
[1.2] tipos de gestin de informacin mediante el ordenador
En la evolucin de los sistemas de informacin ha habido dos puntos determinantes,
que han formado los dos tipos fundamentales de sistemas de informacin
electrnico.

[1.2.1]sistemas de gestin de ficheros

Este tipo de sistemas hace referencia a la forma que inicialmente se desarroll en

la informtica para gestionar ficheros (y que an se usa). En realidad, es una forma
que traduca la manera clsica de gestionar sistemas de informacin (con sus
archivadores, carpetas,) al mundo electrnico.

La idea es que los datos se almacenan en ficheros y se crean aplicaciones (cuyo

cdigo posee la empresa que crea dichas aplicaciones) para acceder a los ficheros.
Cada aplicacin organiza los datos en los ficheros como le parece mejor y si
incorporamos aplicaciones nuevas, estas usarn sus propios ficheros.

Cada aplicacin almacena y utiliza sus propios datos de forma un tanto catica. La
ventaja de este sistema (la nica ventaja), es que los procesos son independientes
por lo que la modificacin de uno no afecta al resto. Pero tiene grandes
inconvenientes:

Programacin de aplicaciones compleja. Ya que los programadores se

deben de encargar de lo que tiene que hacer la aplicacin y adems de
estructurar los datos en disco.
Datos redundantes. Ya que se repiten continuamente. Podra, por ejemplo,
ocurrir que una segunda aplicacin utilice datos de personales, que resulta
que ya estaban almacenados en los ficheros de una primera aplicacin, pero
como ambas son independientes, los datos se repetirn.
Datos inconsistentes. En relacin con el problema anterior, ya que un
proceso cambia sus datos y no los del resto. Por lo que la misma informacin
puede tener distintos valores segn qu aplicacin acceda a l.
 Difcil acceso a los datos. Cada vez que se requiera una consulta no
prevista inicialmente, hay que modificar el cdigo de las aplicaciones o
incluso crear una nueva aplicacin. Esto hace imposible pensar en nuevas
consultas e instantneamente obtener sus resultados; inviable para
aplicaciones que requieren grandes capacidades de consultas y anlisis de
datos.
Coste de almacenamiento elevado. Al almacenarse varias veces el mismo
dato, se requiere ms espacio en los discos. Adems, las aplicaciones
tambin ocupan mucho al tener que pensar en todas las posibles consultas
sobre los datos que la organizacin precisa.
Dependencia de los datos a nivel fsico. Para poder saber cmo se
almacenan los datos, es decir qu estructura se utiliza de los mismos,
necesitamos ver el cdigo de la aplicacin; es decir el cdigo y los datos no
son independientes.
Dificultad para el acceso simultneo a los datos. El acceso simultneo
requiere que varios usuarios al puedan acceder a la misma informacin. Con
este tipo de sistemas es extremadamente difcil conseguir esta capacidad.
Dificultad para administrar la seguridad del sistema. Ya que cada
aplicacin se crea independientemente. Es, por tanto, muy difcil establecer
criterios de seguridad uniformes. Es decir, los permisos que cada usuario
tiene sobre los datos, se establecen de forma muy confusa (y nada uniforme
ya que cada aplicacin puede variar la seguridad).

Se consideran tambin sistemas de gestin de ficheros, a los sistemas que utilizan

programas ofimticos (como Word o Excel por ejemplo) para gestionar sus datos.
Esta ltima idea, la utilizan muchas pequeas empresas para gestionar los datos,
debido al presupuesto limitado del que disponen. Gestionar la informacin de esta
forma produce los mismos (si no ms) problemas.

[1.2.2]Sistemas de Bases de Datos

Estos sern los sistemas que estudiaremos en estos apuntes.

En este tipo de sistemas, los datos se centralizan en una base de datos comn a
todas las aplicaciones. Un software llamado Sistema Gestor de Bases de Datos
(SGBD) es el que realmente accede a los datos y se encarga de gestionarlos. Las
aplicaciones que creen los programadores, no acceden directamente a los datos,
de modo que la base de datos es comn para todas las aplicaciones.

De esta forma, hay, al menos, dos capas a la hora de acceder a los datos. Las
aplicaciones se abstraen sobre la forma de acceder a los datos, dejando ese
problema al SGBD. As se pueden concentrar exclusivamente en la tarea de
conseguir una interfaz de acceso a los datos para los usuarios.
Cuando una aplicacin modifica un dato, la modificacin ser visible
inmediatamente para el resto de aplicaciones; ya que todas utilizarn la misma base
de datos.

ventajas

Independencia de los datos y los programas. Esto permite modificar los

datos sin modificar el cdigo de las aplicaciones y viceversa.
Menor redundancia. Este modelo no requiere que los datos se repitan para
cada aplicacin que los requiera., en su lugar se disean los datos de forma
independiente a las aplicaciones. Los programadores de aplicaciones
debern conocer la estructura creada para los datos y la forma en la que
deben acceder a ellos.
Integridad de los datos. Al estar centralizados, es ms difcil que haya datos
incoherentes. Es decir, que una aplicacin muestre informacin distinta al
resto de aplicaciones, ya que los datos son los mismos para todas.
Mayor seguridad en los datos. El SGBD es el encargado de la seguridad y
se puede centrar en ella de forma independiente a las aplicaciones. Como
las aplicaciones deben atravesar la capa del SGBD para llegar a los datos,
no se podrn saltar la seguridad.
Visiones distintas segn el usuario. Nuevamente, centralizar los datos
facilita crear polticas que permitan que los usuarios vean la informacin de
la base de datos de forma distinta.
Datos ms documentados. Las bases de datos tienen mucho mejor
gestionados los metadatos, que permiten describir la informacin de la base
de datos y que pueden ser consultados por las aplicaciones.
 Acceso a los datos ms eficiente. Esta forma de organizar los datos
produce un resultado ms ptimo en rendimiento ya que los sistemas
gestores centralizan el acceso pudiendo ejecutar polticas diferentes en
funcin de la demanda.
Menor espacio de almacenamiento. Puesto que hay muy poca
redundancia.
Acceso simultneo a los datos. Nuevamente el SGBD tiene ms
capacidad de conseguir esto. Cuando hay varias aplicaciones que intentan
acceder a los datos en los sistemas orientados a los ficheros, compiten por
los datos y es fcil el bloqueo mutuo. En el caso de los sistemas orientados
a bases de datos, toda peticin pasa la capa del SGBD y esto permite evitar
los bloqueos.
desventajas

Instalacin costosa. El control y administracin de bases de datos requiere

de un software y hardware poderoso.
Requiere personal cualificado. Debido a la dificultad de manejo de este tipo
de sistemas.
Implantacin larga y difcil. En relacin a los puntos anteriores. La
adaptacin del personal y del equipamiento es mucho ms complicada y lleva
bastante tiempo.
Ausencia de estndares totales. Lo cual significa una excesiva
dependencia hacia los sistemas comerciales del mercado. Aunque, hoy en
da, hay un funcionamiento base y un lenguaje de gestin (SQL) que desde
hace tiempo se considera estndar (al menos en las bases de datos
relacionales).
[1.3] funcionamiento de un Sistema Gestor de Bases de Datos
[1.3.1]funciones. lenguajes de los SGBD

Los SGBD tienen que realizar tres tipos de funciones para ser considerados vlidos.
A continuacin se describen estas tres funciones.

funcin de descripcin o definicin

Permite al diseador de la base de datos crear las estructuras apropiadas para

integrar adecuadamente los datos. Se dice que esta funcin es la que permite definir
las tres estructuras de la base de datos (relacionadas con los tres niveles de
abstraccin de las mismas).

Estructura interna
Estructura conceptual
Estructura externa
Ms adelante se explican estas tres estructuras, relacionadas con las tres formas
(o niveles) de ver la base de datos.

Realmente la funcin de definicin lo que hace es gestionar los metadatos. Los

metadatos son la estructura de la dispone el sistema de base de datos para
documentar cada dato. Los metadatos tambin son datos que se almacenan en la
propia base de datos; pero su finalidad es describir los datos.

Un metadato nos permite para saber a qu informacin real se refiere cada dato.
Por ejemplo: Snchez, Rodrguez y Crespo son datos. Pero Primer Apellido es un
metadato que, si est correctamente creado, nos permite determinar
que Snchez, Rodrguez y Crespo son primeros apellidos.

Dicho de otra forma, sin los metadatos, no podramos manejar los datos como
informacin relevante. Por ello son fundamentales. Son, de hecho, la base de la
creacin de las bases de datos.

Los metadatos pueden indicar cuestiones complejas. Por ejemplo, que de

los Alumnosalmacenamos su dni el cual lo forman 9 caracteres. Incluso podremos
indicar que en el dni los 8 primeros son nmeros y el noveno un carcter en
maysculas que adems cumple una regla concreta y sirve para identificar al
alumno.

Por lo tanto, en realidad, la funcin de definicin sirve para crear, eliminar o

modificar metadatos.

Resumiendo: con la funcin de definicin podremos:

Especificar el significado de los datos

Organizar la informacin en estructuras ms complejas
Relacionar los datos de forma precisa
Especificar reglas especiales que deben cumplir los datos
Crear todos los elementos estructurales de la base de datos (incluidos los
usuarios)

Un lenguaje conocido como lenguaje de descripcin de datos o DDL, es el que

permite realizar la funcin de definicin en las bases de datos.

funcin de manipulacin

Permite cambiar y consultar los datos de la base de datos. Se realiza mediante

un lenguaje de modificacin de datos o DML. Mediante este lenguaje se puede:

Aadir datos
 Eliminar datos
Modificar datos
Consultar datos

Actualmente se suele diferenciar la funcin de consulta de datos, diferencindola

del resto de operaciones de manipulacin de datos. Se habla de que la funcin de
consulta se realiza con un lenguaje de consulta de datos o DQL (Data Query
Language).

funcin de control

Mediante esta funcin los administradores poseen mecanismos para proteger los
datos. De manera que se permite a cada usuario ver ciertos datos y otros no, o bien
usar ciertos recursos concretos de la base de datos y prohibir otros. Es decir, es la
funcin encargada de establecer los permisos de acceso a los elementos que
forman parte de la base de datos.

El lenguaje que implementa esta funcin es el lenguaje de control de

datos o DCL.

[1.3.2]utilidad de los sistemas gestores de bases de datos

Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar ms a

menudo en los libros especializados las siglas DBMS procedentes del ingls, Data
Base Management System) es el software que permite a los usuarios procesar,
describir, administrar y recuperar los datos almacenados en una base de datos.

En estos sistemas se proporciona un conjunto coordinado de programas,

procedimientos y lenguajes que permiten a los distintos usuarios realizar sus tareas
habituales con los datos, garantizando adems la seguridad de los mismos.

El xito del SGBD reside en mantener la seguridad e integridad de los datos.

Lgicamente tiene que proporcionar herramientas a los distintos usuarios.

Adems de las tres funciones principales comentadas anteriormente, hoy en da los

SGBD son capaces de realizar numerosas operaciones. Para ello proporcionan
numerosas herramientas, muchas de ellas permiten trabajar de una forma ms
cmoda con las . Las ms destacadas son:

Herramientas para la creacin y especificacin del diccionario de datos.

El diccionario de datos es la estructura de la base de datos que almacena los
metadatos. Es decir el diccionario de datos contiene la descripcin de todos
los datos de la base de datos.
Herramientas para administrar y crear la estructura fsica de la base de
datos. El SGBD proporciona herramientas para especificar la forma en la
 que se almacenarn los datos en la computadora (o computadoras) que
alojen la base de datos. Estas herramientas nos permitirn disear una forma
de almacenamiento centrada en optimizar el acceso a los datos.
Herramientas para la manipulacin de los datos. Nos permitirn aadir,
modificar, suprimir o consultar datos (funcin de manipulacin) de la forma
ms sencilla posible.
Herramientas de recuperacin en caso de desastre. Si ocurre un mal
funcionamiento del sistema, un fallo en la alimentacin del sistema, errores
de red, etc. En ese caso los buenos SGBD poseen y proporcionan
mecanismos para que se recupere la mxima informacin posible y se
asegure su integridad.
Herramientas para la creacin y restablecimiento de copias de
seguridad. Es una de las tareas fundamentales, ya que permite recuperar la
informacin en caso de prdida de datos.
Herramientas para la gestin de la comunicacin de la base de datos.
Encargadas de configurar el hardware y software de conexin a la red. As
como los mecanismos necesarios para configurar adecuadamente el
software que se encarga de recibir y comunicar las peticiones de los clientes.
Herramientas para la creacin de aplicaciones de usuario. Es decir,
herramientas para los programadores de aplicaciones, los cuales crean el
software con el que los usuarios accedern de forma cmoda a la base de
datos.
Herramientas de instalacin y configuracin de la base de datos.
Herramientas para la exportacin e importacin de datos a o desde otros
sistemas.
Herramientas para gestionar la seguridad. Permiten establecer privilegios
y permisos diferentes para los usuarios, as como impedir el acceso no
deseado (funcin de control).
[1.3.3]niveles de abstraccin de una base de datos
introduccin

En cualquier software siempre hay dos puntos de vista:

Nivel externo. Esta es la visin del software que tienen los usuarios
Nivel interno. Visin de los creadores del software, que determina su forma
de funcionar.

Esta separacin distingue al usuario o usuaria, del programador o programadora

que ha creado la aplicacin, y es crucial que sea as. La persona que utiliza el
software evita tener que Del mismo modo una casa se la puede observar desde el
punto de vista del inquilino de la misma o bien de las personas que la construyeron.
Los primeros ven la funcin real de la misma y los constructores nos podrn hablar
de los materiales empleados por ejemplo.

En el caso de las bases de datos hay ms niveles, ms formas de observar la base

de datos y estos niveles son manejados por los distintos usuarios de la base de
datos. A eso se le llama los niveles de abstraccin porque nos permite
efectivamente abstraernos para observar la base de datos en base a diferentes
intereses. Los usuarios podrn entender la base de datos sin conocer los entresijos
tcnicos y los administradores podrn trabajar con base de datos sin conocer la
forma en la que los usuarios realmente aaden los datos.

Los niveles habituales son:

Nivel fsico. Nos permite saber la forma en la que est almacenada la base
de datos. Por ejemplo en qu discos duros, qu archivos utiliza, de qu tipo
son los archivos, bajo qu sistema operativo, Este nivel es el que est ms
cercano a la visin de la base de datos que posee la computadora, por lo que
es absolutamente dependiente del hardware y el software (especialmente del
Sistema Operativo).
Nivel interno. Un poco ms cercano a la visin que tenemos las personas.
Permite observar la base de datos como un conjunto de estructuras que
relacionan la informacin humana con la informacin digital. A este nivel no
se depende del hardware concreto que tengamos; es decir, no se habla de
discos, servidores, archivos, sino de las estructuras que disponemos en
nuestro SGBD en particular para organizar los datos.
Nivel conceptual. Es el nivel de mayor abstraccin y el ms importante. Se
trata de una visin organizativa de los datos independientes tanto del
hardware como del software que tengamos. Es el plano o modelo general de
la base de datos y a este nivel es al que trabajan las o los analistas y
diseadores cuando crean el primer esquema de la base de datos. En ningn
momento queda influido por el SGBD en particular que usemos.
Nivel externo. Se trata de la visin de los datos que poseen los usuarios y
usuarias finales de la base de datos. Esa visin es la que obtienen a travs
de las aplicaciones. Las aplicaciones creadas por los desarrolladores
abstraen la realidad conceptual de modo que el usuario no conoce las
relaciones entre los datos, como tampoco conoce dnde realmente se estn
almacenando los datos. Es la forma en la que cualquier persona desea
manejar una base de datos a travs de formularios, informes, listas,

La idea de estos niveles procede de la normalizacin hecha en el

modelo ANSI/X3/SPARC(Vase [a2] estndares y modelo ANSI en la pgina 46) y
sigue estando muy presente en la gestin actual de las bases de datos.

Este modelo dict que podemos pasar de unos modelos a otros de manera casi
automtica utilizando un software adecuado. El modelo ANSI llama a ese
software procesador de modelosy hoy en da es lo que se conoce
como herramientas CASE (Computer Aided for Software
Engineering, Asistente Computerizado para Ingeniera del Software). Para cada
nivel se realizan esquemas relacionados con ellos. As hay esquemas
externos (varios), esquema conceptual, esquema interno y esquema fsico que
forman todos los aspectos de la base de datos.

En la Ilustracin 3 se observa la distancia que poseen los usuarios de la base de

datos respecto a la realidad fsica de la base de datos (representada con el cilindro).
La fsica son los datos en crudo, es decir en formato binario dentro del disco o discos
que los contienen. El esquema fsico es el que se realiza pensando ms en esa
realidad y los esquemas externos los que se crean pensando en la visin de los
usuarios.

Las dos columnas que aparecen en la imagen reflejan dos fronteras a tener en
cuenta:

Independencia Lgica. Los esquemas de los niveles conceptual y externo

son independientes del software concreto de base de datos que usemos; no
dependen en absoluto de l. Por ello esos esquemas nos valdran para
cualquier SGBD que utilicemos.
Independencia Fsica. La da la barrera entre el esquema fsico y el interno
e indica que el esquema interno es independiente del hardware concreto que
usemos. El esquema fsico se disea en base a un hardware concreto, pero
l interno no. Eso permite concentrarse en detalles ms conceptuales.
[1.3.4]recursos humanos de las bases de datos
Intervienen (como ya se ha comentado) muchas personas en el desarrollo y
manipulacin de una base de datos. Se describen, a continuacin, los actores ms
importantes.

informticos

Lgicamente, son los profesionales que definen y preparan la base de datos.

Pueden ser:

Directivos/as. Organizadores y coordinadores del proyecto a desarrollar y

mximos responsables del mismo. Esto significa que son los encargados de
decidir los recursos que se pueden utilizar, planificar el tiempo y las tareas,
la atencin al usuario y de dirigir las entrevistas y reuniones pertinentes.

Son especialistas en gestin de recursos, tanto materiales como humanos.

Analistas. Son los encargados de controlar el desarrollo de la base de datos

aprobada por la direccin. Dirigen a los desarrolladores y operadores.
Normalmente son, adems, los diseadores de la base de datos: es decir,
crean el esquema conceptual de la misma.
Administradores/as de las bases de datos. Encargados de crear el
esquema interno de la base de datos. Tambin gestionan el correcto
funcionamiento del SGBD. Sus tareas incluyen la planificacin de copia de
seguridad, gestin de usuarios y permisos, optimizacin del rendimiento,
monitorizacin de problemas y creacin de los objetos de la base de datos.
Desarrolladores/as o programadores/as. Encargados de la realizacin de
las aplicaciones de usuario para que estos accedan a la base de datos.
Equipo de mantenimiento. Tambin se les llama operadores. Encargados
de dar soporte a los usuarios en el trabajo diario (suelen incorporar adems
tareas administrativas como la creacin de copias de seguridad por ejemplo
o el arreglo de problemas de red por ejemplo).
usuarios

Expertos/as. Realizan operaciones avanzadas sobre la base de datos.

Normalmente conocen el lenguaje de manipulacin de datos (DML) para
acceder a la base de datos. Son usuarios, por lo tanto, con conocimientos
informticos que se encargan en las empresas de los clientes de algunas
acciones ms complejas sobre la base de datos que las que realizan los
usuarios habituales.
Habituales. Utilizan las aplicaciones creadas por los desarrolladores para
consultar y actualizar los datos. Son los que trabajan en la empresa a diario
con estas herramientas y el objetivo fundamental de todo el desarrollo de la
base de datos.
 Ocasionales. Son usuarios que utilizan un acceso mnimo a la base de datos
a travs de una aplicacin que permite consultar ciertos datos. Seran por
ejemplo los usuarios que consultan el horario de trenes a travs de Internet.
Aunque se les llama ocasionales son el ncleo del trabajo con la base de
datos ya que son los que ms la utilizan (ya que son sus usuarios ms
numerosos) y son, por ejemplo, los que visitan la base de datos para realizar
compras o para informarse del negocio representado en la base de datos.

[1.3.5]proceso de creacin y manipulacin de una base de datos

fase de creacin:

[1]El analista o diseador crea el esquema conceptual. En muchas ocasiones,

utilizando una herramienta CASE para disear el esquema de forma ms
cmoda.

[2]El administrador de la base de datos (DBA) recoge ese esquema y crea el

esquema interno de la base de datos. Tambin se encarga, previamente, de
determinar el SGBD idneo y de configurar el software del SGBD as como de
establecer las polticas de copia de seguridad.
 [3]Los desarrolladores tambin recogen el esquema conceptual y utilizan las
aplicaciones necesarias para generar los esquemas externos, que realmente
se traducirn en programas y aplicaciones, que necesitan los usuarios.

fase de manipulacin:

Ocurre con la base de datos ya creada y en funcionamiento.

[1]El usuario realiza una operacin sobre la base de datos (una consulta, modifica
o aade un dato, etc.)

[2]Las aplicaciones las traducen a su forma conceptual utilizando el diccionario de

datos, que posee todos los metadatos necesarios.

[3]El esquema conceptual es traducido por la SGBD a su forma interna,

nuevamente con ayuda del Diccionario de Datos.

[4]EL SGBD se comunica con el Sistema Operativo para pedir que acceda al disco
(estamos, por lo tanto ya en el nivel fsico) y recoja los datos requeridos
(siempre con ayuda del Diccionario de Datos).

[5]El Sistema Operativo accede al almacenamiento fsico correspondiente y

devuelve los datos al SGBD.

[6]El SGBD transforma los datos internos en datos conceptuales y los entrega a la
aplicacin.

[7]La aplicacin muestra los datos habindolos traducido a una forma (externa)
amigable y apta para ser entregada al usuario que hizo la peticin.

[1.3.6]estructura multicapa
El proceso que realiza un SGBD para acceder a los datos est en realidad formado
por varias capas que actan como interface. El usuario nunca accede a los datos
directamente. Estas capas son las que consiguen implementar los niveles de
abstraccin de la base de datos.

Fue el propio organismo ANSI (en su modelo ANSI/X3/SPARC) la que introdujo una
mejora de su modelo de bases de datos en 1988 a travs de un grupo de trabajo
llamado UFTG (User Facilities Task Group, grupo de trabajo para las facilidades de
usuario). Este modelo toma como objeto principal al usuario habitual de la base de
datos y modela el funcionamiento de la base de datos en una sucesin de capas
cuya finalidad es ocultar y proteger la parte interna de las bases de datos.

Desde esta ptica, para llegar a los datos hay que pasar una serie de capas que
desde la parte ms externa poco a poco van entrando ms en la realidad fsica de
la base de datos. Esa estructura se muestra en la Ilustracin 5.

Este marco sigue teniendo vigencia actualmente e indica que el acceso a los datos
no es instantneo, que los datos estn protegidos de los usuarios que pasan (sin
saberlo) por varias capas de proceso antes de que sus peticiones a la base de datos
sean atendidas.

Se explican las capas en detalle

aplicaciones de usuario

Es la capa a la que acceden los usuarios. Proporciona el SGBD a los usuarios un

acceso ms sencillo a los datos. Son, en definitiva, las pginas web y los programas
con las que los usuarios manejan la base de datos. Permite abstraer la realidad de
la base de datos a las usuarias y usuarios, mostrando la informacin de una forma
ms humana.

capa de acceso a datos

La capa de acceso a datos es la que permite comunicar a las aplicaciones de

usuario con el diccionario de datos. Es un software (un driver o controlador, en
realidad) que se encarga traducir las peticiones del usuario para que lleguen de
forma correcta a la base de datos y sta pueda responder de forma adecuada.

diccionario de datos

Se trata de una estructura interna del SGBD que contiene todos los metadatos. Esta
estructura es la que permite pasar de un nivel a otro.

ncleo

El ncleo de la base de datos es la capa encargada de traducir todas las

instrucciones requeridas y prepararlas para su correcta interpretacin por parte del
sistema. Realiza la traduccin fsica de las peticiones.

sistema operativo

Es una capa externa al software SGBD pero es la nica capa que realmente accede
a los datos en s. En realidad los SGBD no acceden directamente al disco, sino que
piden al Sistema Operativo que lo haga, ya que es el que maneja el sistema de
discos.

[1.3.7]funcionamiento del SGBD

La Ilustracin 6 presenta el funcionamiento tpico de un SGBD. En ella se reproduce

la comunicacin entre un usuario que desea acceder a los datos y el SGBD:

[1]Los usuarios utilizan una aplicacin para acceder a los datos. Estamos en el
nivel externo de la base de datos, por lo que la propia aplicacin traduce la
peticin que hizo el usuario de forma sencilla, a una peticin entendible por la
capa de acceso a los datos.

[2]El proceso cliente es el software de acceso a la base de datos y que est

instalado en el lado del cliente. Se encarga simplemente de recoger y enviar la
 peticin (comprobando antes si hay comunicacin con el servidor de la base de
datos).

[3]A travs de la red (normalmente) el proceso cliente se comunica con el proceso

servidor, que es el software de comunicacin instalado en el lado del servidor.
Ambos procesos (cliente y servidor) forman la capa de acceso a los datos.

[4]Estando ya en el servidor, la peticin pasa al software del Sistema Gestor de

Bases de Datos (habr aqu, como se ha visto en el apartado anterior una
traduccin de datos, desde el nivel externo al nivel interno).

[5]El SGBD, comprobando el diccionario de datos, comprueba si la peticin es

correcta.

[6]El SGBD tambin revisa el diccionario de datos (si la peticin es correcta) para
saber con exactitud en qu archivos y en qu parte dentro de ellos, se
encuentran los datos requeridos

[7]Con la informacin sobre dnde estn los datos, el SGBD hace una peticin al
Sistema Operativo, que es el que tiene capacidad realmente de acceder a los
archivos de datos. Por ello la peticin del SGBD se traduce al formato utilizado
por el Sistema Operativo.El Sistema Operativo accede a los datos.

[8]El Sistema Operativo recibe los datos.

[9]Se entregan los datos al Sistema Gestor de Bases de Datos o, si ha habido un

error al acceder a los datos, se indica el error ocurrido.
 [10]El SGBD traduce los datos a una forma ms conceptual y se los entrega al
proceso servidor.

[11]Los datos se entregan al proceso cliente.

[12]Los datos llegan a la aplicacin.

[13]La aplicacin de usuario traduce los datos recibidos en informacin presentada

de la forma ms conveniente para el usuario.

[1.3.8]formas de ejecucin de un SGBD

SGBD monocapa

Se trata de Sistemas Gestores instalados en una mquina desde la que se conectan

los propios usuarios y administradores. Es decir, todo el sistema est en una sola
mquina.

Es un modelo que slo se utiliza con bases de datos pequeas y poca cantidad de
conexiones. La popular Access de Microsoft es considerada un sistema gestor
monocapa (aunque tiene algunas posibilidades para utilizar en dos capas).

SGBD bicapa
Usa un modelo de funcionamiento tipo cliente/servidor. La base de datos y el
sistema gestor se alojan en un servidor al cual se conectan los usuarios desde
mquinas clientes. Un software de comunicaciones se encarga de permitir el acceso
a travs de la red. Los clientes deben instalar el software cliente de acceso segn
las instrucciones de configuracin del administrador.

Hay dos posibilidades:

Arquitectura cliente/servidor nico. Un solo servidor gestiona la base de

datos, todos los clientes se conectan a l para realizar las peticiones a la
base de datos.
Arquitectura cliente/multiservidor. La base de datos se distribuye entre
varios servidores. El cliente no sabe realmente a qu servidor se conecta; el
software de control de comunicaciones se encargar de dirigir al usuario al
servidor adecuado. De forma lgica, es como si se tratara de un solo servidor
aunque fsicamente sean muchos (el cliente no percibe que haya ms de un
servidor).
SGBD de tres o ms capas

En este caso entre el cliente y el servidor hay al menos una capa intermedia (puede
haber varias). Esa capa (o capas) se encarga de recoger las peticiones de los
clientes y luego de comunicarse con el servidor (o servidores) de bases de datos
para recibir la respuesta y enviarla al cliente.

El caso tpico es que la capa intermedia sea un servidor web, que recibe las
peticiones a travs de aplicaciones web; de este modo para conectarse a la base
de datos, el usuario solo requiere un navegador web, que es un software muy
habitual en cualquier mquina y por lo tanto no requiere una instalacin de software
adicional en la mquina cliente.
Este modelo es el que ms se est potenciando en la actualidad por motivos de
seguridad y portabilidad de la base de datos.

[1.4] tipos de SGBD

[1.4.1]introduccin

Como se ha visto en los apartados anteriores, resulta que cada SGBD puede utilizar
un modelo diferente para los datos. Por lo que hay modelos conceptuales diferentes
segn que SGBD utilicemos. Esto da lugar a un diagrama de trabajo para los
profesionales de la base de datos que permite saber qu esquemas hay que realizar
(y en qu orden) para crear una base de datos.
El punto de partida es el uso en el mundo real que tendr la base de datos. Ese
punto es en el que estn los usuarios y es crucial tenerle muy claro. El punto final
es el almacenamiento fsico de la base de datos.

En este esquema aparece el llamado Esquema lgico, que permite pasar de forma
ms gradual del esquema conceptual al esquema interno.

No obstante existen modelos lgicos comunes, ya que hay SGBD de diferentes

tipos. En la realidad el modelo conceptual clsico se modifica para que existan dos
modelos internos: el modelo lgico (referido a cualquier SGBD de ese tipo) y el
modelo conceptual propiamente interno (aplicable slo a un SGBD en particular).
De hecho, en la prctica, al definir las bases de datos desde el mundo real hasta
llegar a los datos fsicos se pasa por todos los esquemas sealados en la Ilustracin
10.

Por lo tanto la diferencia entre los distintos SGBD est en que proporcionan
diferentes modelos lgicos.

diferencias entre el modelo lgico y el conceptual

El modelo conceptual es independiente del DBMS que se vaya a utilizar. El

lgico depende de un tipo de SGBD en particular
El modelo lgico est ms cerca del modelo fsico, el que utiliza internamente
el ordenador
El modelo conceptual es el ms cercano al usuario, el lgico es el encargado
de establecer el paso entre el modelo conceptual y el modelo fsico del
sistema.

Algunos ejemplos de modelos conceptuales son:

Modelo Entidad Relacin

Modelo RM/T
Modelo UML

Ejemplos de modelos lgicos son:

Modelo relacional
Modelo Codasyl
Modelo Jerrquico

A continuacin se comentarn los modelos lgicos ms importantes.

[1.4.2]modelo jerrquico
Era utilizado por los primeros SGBD, desde que IBM lo defini para su IMS
(Information Management System, Sistema Administrador de Informacin) en 1970.
Se le llama tambin modelo en rbol debido a que utiliza una estructura en rbol
para organizar los datos.

La informacin se organiza con un jerarqua en la que la relacin entre las entidades

de este modelo siempre es del tipo padre / hijo. De esta forma hay una serie de
nodos que contendrn atributos y que se relacionarn con nodos hijos de forma que
puede haber ms de un hijo para el mismo padre (pero un hijo slo tiene un padre).

Los datos de este modelo se almacenan en estructuras lgicas

llamadas segmentos. Los segmentos se relacionan entre s utilizando arcos.

La forma visual de este modelo es de rbol invertido, en la parte superior estn los
padres y en la inferior los hijos.

Este esquema est en absoluto desuso ya que no es vlido para modelar la mayora
de problemas de bases de datos. Su virtud era la facilidad de manejo ya que slo
existe un tipo de relacin (padre/hijo) entre los datos; su principal desventaja es que
no basta para representar la mayora de relaciones. Adems no mantena la
independencia con la fsica de la base de datos.

[1.4.3]modelo en red (Codasyl)

Es un modelo que ha tenido una gran aceptacin (aunque apenas se utiliza

actualmente). En especial se hizo popular la forma definida por el estndar Codasyl
a principios de los 70 que se convirti en el modelo en red ms utilizado.
El modelo en red organiza la informacin en registros (tambin llamados nodos)
y enlaces. En los registros se almacenan los datos, mientras que los enlaces
permiten relacionar estos datos. Las bases de datos en red son parecidas a las
jerrquicas slo que en ellas puede haber ms de un padre.

En este modelo se pueden representar perfectamente cualquier tipo de relacin

entre los datos (aunque el Codasyl restringa un poco las relaciones posibles), pero
hace muy complicado su manejo.

Posea un lenguaje poderoso de trabajo con la base de datos. El problema era la

complejidad para trabajar con este modelo tanto para manipular los datos como
programar aplicaciones de acceso a la base de datos. Tampoco mantena una
buena independencia con la fsica de la base de datos.

[1.4.4]modelo relacional

Es el modelo ms popular. Los datos se organizan en tablas y estas en columnas y

filas de datos. Las tablas se relacionan entre s para ligar todos los datos.

Se basa en la teora de conjuntos y consigue una gran separacin entre lo

conceptual y lo fsico, consiguiendo su total independencia. Tiene un lenguaje
considerado estndar, el SQL y una enorme red de usuarios y documentacin que
facilita su aprendizaje. Adems dota de una gran facilidad para establecer reglas
complejas a los datos.

El problema es que la simplicidad de manejo y la independencia que consigue se

logra a base de un software muy complejo que requiere tambin un hardware
poderoso.

[1.4.5]modelo de bases de datos orientadas a objetos

Desde la aparicin de la programacin orientada a objetos (POO u OOP) se empez
a pensar en bases de datos adaptadas a estos lenguajes. La programacin
orientada a objetos permite cohesionar datos y procedimientos, haciendo que se
diseen estructuras que poseen datos (atributos) en las que se definen los
procedimientos (operaciones) que pueden realizar con los datos. En las bases
orientadas a objetos se utiliza esta misma idea.

A travs de este concepto se intenta que estas bases de datos consigan arreglar
las limitaciones de las relacionales. Por ejemplo el problema de la herencia (el hecho
de que no se puedan realizar relaciones de herencia entre las tablas), tipos definidos
por el usuario, disparadores (triggers) almacenables en la base de datos, soporte
multimedia...

Se supone que son las bases de datos de tercera generacin (la primera fue las
bases de datos en red y la segunda las relacionales), lo que significa que el futuro
parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las
relacionales, aunque son el tipo de base de datos que ms est creciendo en los
ltimos aos.

Su modelo conceptual se suele disear usando la notacin UML y el lgico

usando ODMG(Object Data Management Group, grupo de administracin de
objetos de datos), organismo que intenta crear estndares para este modelo.

Sus ventajas estn en el hecho de usar la misma notacin que la de los programas
(lo que facilita la tarea de su aprendizaje a los analistas y desarrolladores) y que el
significado de los datos es ms completo. Lo malo es que no posee un lenguaje tan
poderoso como el modelo relacional para manipular datos y metadatos, que tiene
ms dificultades para establecer reglas a los datos y que al final es ms complejo
para manejar los datos.

[1.4.6]bases de datos objeto-relacionales

Tratan de ser un hbrido entre el modelo relacional y el orientado a objetos. El

problema de las bases de datos orientadas a objetos es que requieren reinvertir
capital y esfuerzos de nuevo para convertir las bases de datos relacionales en bases
de datos orientadas a objetos. En las bases de datos objeto relacionales se intenta
conseguir una compatibilidad relacional dando la posibilidad de integrar mejoras de
la orientacin a objetos.

Estas bases de datos se basan en el estndar ISO SQL 2000 y los siguientes. En
ese estndar se aade a las bases relacionales la posibilidad de almacenar
procedimientos de usuario, triggers, tipos definidos por el usuario, consultas
recursivas, bases de datos OLAP, tipos LOB,...

Las ltimas versiones de la mayora de las clsicas grandes bases de datos

relacionales (Oracle, SQL Server, DB2, ...) son objeto relacionales.
[1.4.7]bases de datos NoSQL

Bajo este nombre se agrupan las bases de datos (con arquitecturas muy diversas)
pensadas para grabar los datos de manera veloz para as poder atender a miles y
miles de operaciones DML de escritura de datos. Es decir, es el modelo de las bases
de datos que se utilizan en los grandes servicios de Internet
(como twitter, Facebook, Amazon,).

La razn de su xito actual es que, en las bases de datos que reciben miles de
peticiones por minuto, los modelos anteriores no daran abasto al tener que validar
los datos de forma intensa. Por lo que, la mayora, usan otro tipo de esquemas
conceptuales e internos para poder atender a estas peticiones.

En las bases de datos NoSQL (llamadas as porque rompen con el lenguaje SQL y,
por lo tanto, con el modelo relacional) prima la velocidad. Por ello se almacenan los
datos usando formatos de datos compatibles con los lenguajes XML y/o JSON que
permiten trabajar en modo texto con los datos y facilitar el transporte de los mismos
por la red.

Al final los datos se organizan de forma jerrquica con la ventaja de que,

especialmente mediante XML, se pueden presentar fcil y rpidamente en un
formato entendible por el usuario como PDF o HTML.

apndices
[a1] archivos
[a1.1]introduccin

Los ficheros o archivos son la herramienta fundamental de trabajo en una

computadora todava a da de hoy. Las computadoras siguen almacenando la
informacin en ficheros; eso s, su estructura es cada vez ms compleja.

Los datos deben de ser almacenados en componentes de almacenamiento

permanente, lo que se conoce como memoria secundaria (discos duros u otras
unidades de disco). En esas memorias, los datos se estructuran en archivos
(tambin llamados ficheros).

Un fichero es una secuencia de nmeros binarios que organiza informacin

relacionada a un mismo aspecto.

En general sobre los archivos se pueden realizar las siguientes operaciones:

Abrir (open). Prepara el fichero para su proceso.

Cerrar (close). Cierra el fichero impidiendo su proceso inmediato.
Leer (read). Obtiene informacin del fichero.
 Escribir (write). Graba informacin en el fichero.
Posicionarse (seek). Coloca el puntero de lectura en una posicin concreta
del mismo (no se puede realizar en todos los tipos de ficheros).
Comprobar fin de fichero (eof). Indica si hemos llegado al final del fichero.
[a1.2]uso de archivos para grabar datos

Los archivos, como herramienta para almacenar informacin, tomaron la

terminologa del mundo de la oficina empresarial. As la palabra dato hace
referencia a un valor sea un nmero o un texto o cualquier otro tipo de datos
almacenable.

Cuando podemos distinguir datos referidos a una misma propiedad real a la que
podemos poner un nombre, hablamos de campos.
As: Snchez, Rodrguez, Serrat y Crespo son datos que perfectamente podran
encajar en un campo llamado Primer Apellido.

Los datos que se refieren al mismo elemento real (una persona, una factura, un
movimiento bancario,) se agrupan en registros. En un fichero de datos
personales, cada registro sera una persona; cada campo sera cada propiedad
distinguible en la persona.

[a1.3]tipos de archivos
ficheros secuenciales

En estos ficheros, los datos se organizan secuencialmente en el orden en el que

fueron grabados. Para leer los ltimos datos hay que leer los anteriores. Es decir
leer el registro nmero nueve, implica leer previamente los ocho anteriores.

ventajas

Rpidos para obtener registros contiguos de una base de datos

No hay huecos en el archivo al grabarse los datos seguidos, datos ms
compactos.
desventajas

Consultas muy lentas al tener que leer todos los registros anteriores en el
orden del archivo respecto al que queremos leer. Es decir, que si queremos
leer el quinto registro, hay que leer los cuatro anteriores.
Algoritmos de lectura y escritura complejos. No es fcil hacer operaciones
avanzadas con los datos
No se pueden eliminar registros del fichero (se pueden marcar de manera
especial para que no sean tenidos en cuenta, pero no se pueden borrar)
 El borrado provoca archivos que no son compactos
La ordenacin de los datos requiere leer todos los datos, reorganizarlos en
memoria y volver a grabarles en el archivo en el orden correcto. Se trata de
una operacin excesivamente lenta
ficheros de acceso directo o aleatorio

En estos ficheros se puede leer una posicin concreta directamente; bastar saber
la posicin exacta (normalmente en bytes) del dato a leer para obtenerle. Es decir,
posicionarnos en el quinto registro se hara de golpe, con una sola instruccin. Lo
nico que necesitamos saber el tamao de cada registro, que en este tipo de
ficheros debe de ser el mismo. Suponiendo que cada registro ocupa 100 bytes, el
quinto registro comenzar en la posicin 400. A partir de esa posicin podremos
leer todos los datos del registro.

ventajas

Acceso rpido a un registro concreto. No necesita leer los datos anteriores

La modificacin de datos es ms sencilla
Permiten acceso secuencial adems del aleatorio (por lo que mejoran el caso
anterior)
Permiten tanto leer como escribir a sin necesidad de cerrar el archivo.
Aptos para organizaciones relativas directas, en las que la clave del registro
se relaciona con su posicin en el archivo.
desventajas

Salvo en archivos relativos directos, no es apto por s mismo para usar en

bases de datos, ya que los datos se organizan en base a una clave que casi
nunca coincide con la posicin del registro en el archivo
No se pueden borrar datos (s marcar para borrado, pero generarn huecos)
Las consultas sobre multitud de registros son ms lentas que en el caso
anterior.
ficheros secuenciales encadenados

Son ficheros con registros grabados secuencialmente que podramos recorrer

registro a registro o de forma aleatoria. Adems cada registro posee un campo que
contiene la direccin de otro registro (a este tipo de campos se les llama punteros).
Cada registro usa su puntero para indicar la direccin del siguiente registro. Usando
los punteros podremos recorrer los registros en un orden concreto.

Cuando aparece un nuevo registro, se aade al final del archivo, pero los punteros
se reordenan para que se mantenga el orden.
ventajas

El fichero mantiene el orden en el que se aadieron los registros y un

segundo orden en base a una clave. Incluso aadiendo ms punteros a cada
registro podremos establecer ms formas de ordenar los registros.
La operacin de ordenacin no requiere reorganizar todo el fichero, sino slo
modificar los punteros
Posee las mismas ventajas que el acceso secuencial y el acceso aleatorio
desventajas

No se borran los registros, sino que se marcan para ser ignorados. Por lo que
se malgasta espacio
Aadir registros o modificar las claves son operaciones que requieren
recalcular los punteros por lo que llevan ms tiempo que en los casos
anteriores
ficheros secuenciales indexados

Se utilizan dos ficheros para los datos, uno posee los registros almacenados de
forma secuencial, pero que permite su acceso aleatorio. El otro posee una tabla con
punteros a la posicin ordenada de los registros. Ese segundo fichero es
el ndice, una tabla con la ordenacin deseada para los registros y la posicin que
ocupan en el archivo.

El archivo de ndices posee unas cuantas entradas slo en las que se indica la
posicin de ciertos valores claves en el archivo (cada 10, 15 ,20,... registros del
archivo principal se aade una entrada en el de ndices). El archivo principal tiene
que estar siempre ordenado y as cuando se busca un registro, se busca su valor
clave en la tabla de ndices, la cual poseer la posicin del registro buscado. Desde
esa posicin se busca secuencialmente el registro hasta encontrarlo.

Existe un tercer archivo llamado de desbordamiento u overflow en el que se

colocan los nuevos registros que se van aadiendo (para no tener que ordenar el
archivo principal cada vez que se aade un nuevo registro) este archivo est
desordenado. Se utiliza slo si se busca un registro y no se encuentra en el archivo
principal. En ese caso se recorre todo el archivo de overflow hasta encontrarlo.

Para no tener demasiados archivos en overflow (lo que restara velocidad ya que no
utilizaramos el archivo de ndices que es el que da velocidad), cada cierto tiempo
se reorganiza el archivo principal, ordenando los datos en el orden correcto y
recalculando el archivo de ndices. Ejemplo:
ventajas

El archivo est siempre ordenado de forma secuencial en base a una clave.

Por lo que la simple lectura secuencial del archivo obtiene un listado
ordenado de los datos.
La bsqueda de datos es rapidsima
Permite la lectura secuencial (que adems ser en el orden de la clave)
Aadir un solo registro no conlleva un tiempo extra como en el caso anterior
desventajas

Para un uso ptimo hay que reorganizar el archivo principal cada cierto
tiempo y esta operacin es muy costosa ya que hay que reescribir de nuevo
y de forma ordenada todo el archivo con el rea primeria, adems de
reorganizar el rea de ndices y eliminar el fichero de desbordamiento. Es tan
costosa que se hace muy poco a menudo, pero en archivos de datos que se
modifican muy a menudo, no reorganizar provocara un rea de
desbordamiento enorme y perderamos las ventajas de este modelo.
ficheros indexado-encadenados

Utiliza punteros e ndices, es una variante encadenada del caso anterior. Hay un
fichero de ndices equivalente al comentado en el caso anterior y otro fichero de tipo
encadenado con punteros a los siguientes registros. La diferencia est en que este
segundo fichero que contiene el rea primaria de los datos, no est ordenado
secuencialmente, sino que el orden se realizara recorriendo un puntero (como en
el caso de los ficheros secuencialmente encadenados).

Cuando se aaden registros se aaden en un tercer fichero llamado de

desbordamiento u overflow. En el rea de desbordamiento los datos se almacenan
secuencialmente, se accede a ellos si se busca un dato y no se encuentra el rea
primaria.

ventajas

Posee las mismas ventajas que el modelo anterior adems de que la

reordenacin es ms rpida ya que slo requiere modificar los punteros y el
rea de ndices (no requiere reordenar todos los datos del rea primaria).
desventajas

Requieren compactar los datos a menudo para reorganizar ndices y quitar

el fichero de desbordamiento y es una operacin lenta (aunque mucho menos
lenta que en el caso anterior)

Ilustracin 16. Ejemplo fichero secuencial indexado y encadenado

[a1.4]operaciones relacionadas con uso de archivos en bases de datos

borrado y recuperacin de registros

Algunos de los tipos de ficheros vistos anteriormente no admiten el borrado real de

datos, sino que slo permiten aadir un dato que indica si el registro est borrado o
no. Esto es interesante ya que permite anular una operacin de borrado. Por ello
esta tcnica de marcar registros, se utiliza casi siempre en todos los tipos de
archivos.

En otros casos los datos antes de ser eliminados del todo pasan a un fichero
especial (conocido como papelera) en el que se mantienen durante cierto tiempo
para su posible recuperacin.

fragmentacin y compactacin de datos

La fragmentacin en un archivo hace referencia a la posibilidad de que ste tenga

huecos interiores debido a borrado de datos u a otras causas. Causa los siguientes
problemas:

Mayor espacio de almacenamiento

Lentitud en las operaciones de lectura y escritura del fichero

Por ello se requiere compactar los datos. Esta tcnica permite eliminar los huecos
interiores a un archivo. Las formas de realizarla son:

Reescribir el archivo para eliminar los huecos. Es la mejor, pero

lgicamente es la ms lenta al requerir releer y reorganizar todo el contenido
del fichero.
Aprovechar huecos. De forma que los nuevos registros se inserten en esos
huecos. Esta tcnica suele requerir un paso previo para reorganizar esos
huecos.
compresin de datos

En muchos casos para ahorrar espacio de almacenamiento, se utilizan tcnicas de

compresin de datos. La ventaja es que los datos ocupan menos espacio y la
desventaja es que al manipular los datos hay que descomprimirlos lo que hace que
las operaciones bsicas con el fichero se ralentizan.

cifrado de datos

Otra de las opciones habituales sobre ficheros de datos es utilizar tcnicas de

cifrado para proteger los ficheros en caso de que alguien no autorizado se haga con
el fichero. Para leer un fichero de datos, hara falta descifrar el fichero. Para descifrar
necesitamos una clave o bien aplicar mtodos de descifrado; lgicamente cuanto
mejor sea la tcnica de cifrado, ms difcil ser descifrar los datos.

[a2] estndares y modelo ANSI

Es uno de los aspectos que todava sigue pendiente. Desde la aparicin de los
primeros gestores de base de datos se intent llegar a un acuerdo para que hubiera
una estructura comn para todos ellos, a fin de que el aprendizaje y manejo de este
software fuera ms provechoso y eficiente.

El acuerdo nunca se ha conseguido del todo, no hay estndares aceptados del todo.
Aunque s hay unas cuentas propuestas de estndares que s funcionan como tales.

[a2.1]organismos de estandarizacin

Los intentos por conseguir una estandarizacin han estado promovidos por
organismos de todo tipo. Algunos son estatales, otros privados y otros promovidos
por los propios usuarios. Los tres que han tenido gran relevancia en el campo de
las bases de datos son ANSI/SPARC/X3, CODASYL y ODMG (ste slo para las
bases de datos orientadas a objetos). Los organismos grandes (que recogen
grandes responsabilidades) dividen sus tareas en comits, y stos en grupos de
trabajo que se encargan de temas concretos.

[a2.2]ISO/JTC1/SC21/WG3

ISO (International Organization for Standardization). Es un organismo

internacional de definicin de estndares de gran prestigio.
IEC (International Electrotechnical Commission). Organismo de definicin de
normas en ambientes electrnicos. Es la parte, en definitiva de ISO, dedicada
a la creacin de estndares.
JTC 1 (Joint Technical Committee). Comit parte de IEC dedicado a la
tecnologa de la informacin (informtica). En el campo de las bases de
datos, el subcomit SC 21 (en el que participan otros organismos nacionales,
como el espaol AENOR) posee un grupo de trabajo llamado WG 3 que se
dedica a las bases de datos. Este grupo de trabajo es el que define la
estandarizacin del lenguaje SQL entre otras cuestiones.

Entre los trabajos que realiza el grupo WG3 est la normalizacin de SQL, adems
de otras normas de estandarizacin.

[a2.3]DBTG/Codasyl

Codasyl (COnference on DAta SYstem Languages) es el nombre de una

conferencia iniciada en el ao 1959 y que dio lugar a un organismo con la idea de
conseguir un lenguaje estndar para la mayora de mquinas informticas.
Participaron organismos privados y pblicos del gobierno de Estados Unidos con la
finalidad de definir estndares. Su primera tarea fue desarrollar el
lenguaje COBOL y otros elementos del anlisis, diseo y la programacin de
ordenadores.

La tarea real de estandarizar esos lenguajes se la cedieron al organismo ANSI, pero

las ideas e inicios de muchas tecnologas se idearon en el consorcio Codasyl.
En 1967 se crea un grupo de tareas para bases de datos (Data Base Task Group)
y este grupo defini el modelo en red de bases de datos y su integracin con
COBOL. A este modelo en red se le denomina modelo Codasyl o modelo DBTG y
fue finalmente aceptado por la ANSI.

[a2.4]ANSI/X3/SPARC

ANSI (American National Standards Institute) es un organismo cientfico de Estados

Unidos que ha definido diversos estndares en el campo de las bases de
datos. X3 es la parte de ANSI encargada de los estndares en el mundo de la
electrnica. Finalmente SPARC, System Planning and Repairments
Committee, comit de planificacin de sistemas y reparaciones es una subseccin
de X3 encargada de los estndares en Sistemas Informticos en especial del campo
de las bases de datos. Su logro fundamental ha sido definir un modelo de referencia
para las bases de datos (que se estudiar posteriormente).

En la actualidad ANSI para Estados Unidos e ISO para todo el mundo son nombres
equivalentes en cuanto a estandarizacin de bases de datos, puesto que se habla
ya de un nico modelo de sistema de bases de datos.

[a2.5]modelo ANSI/X3/SPARC

El organismo ANSI ha marcado la referencia para la construccin de SGBD. El

modelo definido por el grupo de trabajo SPARC se basa en estudios anteriores en
los que se definan tres niveles de abstraccin necesarios para gestionar una base
de datos. ANSI profundiza ms en esta idea y define cmo debe ser el proceso de
creacin y utilizacin de estos niveles.

En el modelo ANSI se indica que hay tres

modelos: externo, conceptual e interno. Se entiende por modelo, el conjunto de
normas que permiten crear esquemas (diseos de la base de datos).

Los esquemas externos reflejan la informacin preparada para el usuario final, el

esquema conceptual refleja los datos y relaciones de la base de datos y el esquema
interno la preparacin de los datos para ser almacenados.

El esquema conceptual contiene la informacin lgica de la base de datos. Su

estructuracin y las relaciones que hay entre los datos.

El esquema interno contiene informacin sobre cmo estn almacenados los datos
en disco. Es el esquema ms cercano a la organizacin real de los datos.

En definitiva el modelo ANSI es una propuesta terica sobre cmo debe de

funcionar un sistema gestor de bases de datos (sin duda, la propuesta ms
importante). Su idea es la siguiente:

Ilustracin 18. Niveles en el modelo ANSI

En la Ilustracin 18, el paso de un esquema a otro se realiza utilizando una interfaz

o funcin de traduccin. En su modelo, la ANSI no indica cmo se debe realizar esta
funcin, slo que debe existir.

La arquitectura completa (Ilustracin 19) est dividida en dos secciones, la zona de

definicin de datos y la de manipulacin. Esa arquitectura muestra las funciones
realizadas por humanos y las realizadas por programas.
En la fase de definicin, una serie de interfaces permiten la creacin de
los metadatos que se convierten en el eje de esta arquitectura. La creacin de la
base de datos comienza con la elaboracin del esquema conceptual realizndola el
administrador de la empresa (actualmente es el diseador, pero ANSI no lo llam
as). Ese esquema se procesa utilizando un procesador del esquema conceptual
(normalmente una herramienta CASE, interfaz 1 del dibujo anterior) que lo convierte
en los metadatos (interfaz 2).

La interfaz 3 permite mostrar los datos del esquema conceptual a los otros dos
administradores: el administrador de la base de datos y el de aplicaciones (el
desarrollador). Mediante esta informacin construyen los esquemas internos y
externos mediante las interfaces 4 y 5 respectivamente, los procesadores de estos
esquemas almacenan la informacin correspondiente a estos esquemas en los
metadatos (interfaces 6 y 7).
En la fase de manipulacin el usuario puede realizar operaciones sobre la base de
datos usando la interfaz 8 (normalmente una aplicacin) esta peticin es
transformada por el transformador externo/conceptual que obtiene el esquema
correspondiente ayudndose tambin de los metadatos (interfaz 9). El resultado lo
convierte otro transformador en el esquema interno (interfaz 10) usando tambin la
informacin de los metadatos (interfaz 11). Finalmente del esquema interno se pasa
a los datos usando el ltimo transformador (interfaz 12) que tambin accede a los
metadatos (interfaz 13) y de ah se accede a los datos (interfaz 14). Para que los
datos se devuelvan al usuario en formato adecuado para l se tiene que hacer el
proceso contrario (observar dibujo).
 Manual de Gestin de Bases de Datos
[2]
Modelo Entidad/Relacin
PUBLICIDAD
[1.1] introduccin

Ya hemos visto anteriormente que existen varios esquemas a realizar para poder
representar en forma de base de datos informtica un problema procedente del
ordenador.

El primero de esos esquemas es el llamado esquema conceptual, que representa

la informacin de forma absolutamente independiente al Sistema Gestor de Base
de Datos. Los esquemas internos de las diferentes bases de datos no captan la
semntica del mundo real, ya que se centran ms en estructura de almacenamiento
ms cercanas a la computadora; de ah que primero haya que pasar por uno o dos
esquemas previos, ms cercanos al mundo real y que permitiran adaptar el
problema a todo tipo de sistemas.

El hecho de saltarse el esquema conceptual conlleva un problema de prdida de

percepcin con el problema real, ya que nos aproximamos demasiado al ordenador
y nos alejamos de la informacin como la entiende el ser humano y eso, a la larga,
provoca problemas de incoherencia en los datos. El esquema conceptual debe
reflejar todos los aspectos relevantes del mundo a real a modelar.

[1.1.1]Peter P. Chen y el modelo

entidad/relacin

En 1976 y 1977 dos artculos de Peter P. Chen detallaron un modelo para realizar
esquemas con la idea de proveer una visin unificada de los datos de un sistema
de base de datos. Este modelo es el modelo
entidad/interrelacin (entity/relationship en ingls) que actualmente se conoce
ms con el nombre de entidad/relacin (Modelo E/R o ME/R, en ingls E/RM).

Posteriormente otros autores han aadido mejoras a este modelo, lo que ha

producido toda una familia de modelos basados en el modelo Entidad/Relacin
original. La ms aceptada actualmente es el modelo entidad/relacin
extendido (ERE) que complementa algunas carencias del modelo original. No
obstante las diversas variantes del modelo hacen que los esquemas que dibujan los
profesionales no sigan un verdadero estndar y sean dispares, aunque hay ideas
muy comunes a todos los dialectos del modelo entidad/relacin.

Hay que insistir en que este modelo no tiene nada (o muy poco) que ver con las
bases de datos relacionales, los esquemas entidad/relacin se pueden utilizar (en
principio) con cualquier SGBD ya que son conceptuales. Puede que nos confunda
el uso de la palabra relacin, ya que est tambin presente en el modelo relacional
de las bases de datos de Edgar F. Codd; pero el concepto de relacin en este
esquema no tiene nada que ver con la idea de relacin expuesta por Codd en su
modelo relacional.

[1.2] componentes del modelo

[1.2.1]entidad

Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda
almacenar informacin en la base de datos. Es decir cualquier elemento informativo
que tenga importancia para una base de datos.

Ejemplos de entidades son: una persona que se llama Pedro, la factura nmero
32456, el coche matrcula 3452BCW, etc. Una entidad no es un propiedad concreta,
sino un objeto que puede poseer mltiples propiedades (atributos). Es
decir Snchez es el contenido del atributo Primer Apellido de la entidad que
representa a la persona Pedro Snchez Crespo con DNI 12766374,...

Las entidades son objetos completos, con todos los valores de las propiedades de
dicho objeto. Descubrir entidades es la tarea principal del diseo de esquemas
Entidad/Relacin

[1.2.2]conjuntos de entidades

Las entidades que poseen las mismas propiedades, porque se refieren al mismo
tipo de ente, forman conjuntos de entidades. Ejemplos de conjuntos de entidades
son: personas, facturas, coches,...

En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como

conjunto de entidades, seguramente por una cuestin de ahorro en el lenguaje. De
este modo hablaramos de la entidad PERSONAS. Mientras que cada persona en
concreto sera una ocurrencia o un ejemplar de la entidad persona.

Esta terminologa es la que actualmente vamos a utilizar en este manual: los

conjuntos de entidades sern entidades a secas, y lo que Chen llamaba entidades,
sern ejemplares de dicha entidad.

[1.2.3]representacin grfica de las entidades

En el modelo entidad relacin los conjuntos de entidades se representan con un

rectngulo dentro del cual se escribe el nombre de la entidad:

[1.3] relaciones
[1.3.1]qu es una relacin

Representan asociaciones entre entidades, es decir entidades de un conjunto que

tienen contacto con entidades de otro conjunto. Es el elemento del modelo que
permite relacionar en s los datos del mismo; de otro modo tendramos informacin
aislada. Por ejemplo, en el caso de que tengamos una entidad personas y otra
entidad trabajos. Ambas se relacionan ya que las personas trabajan y los trabajos
son realizados por personas.
En el dibujo anterior, trabajar podra ser el nombre del conjunto de relaciones entre
las entidades personas y trabajos.

En una relacin (Chen llamaba conjunto de relaciones a lo que ahora vamos a

llamar relacin a secas) cada ejemplar (cada relacin en la terminologa de Chen)
asocia un elemento de una entidad con otro de la otra entidad.

Una regla fundamental es que en una relacin no pueden aparecer dos veces
relacionados los mismos ejemplares de cada entidad. Una relacin estable una
asociacin entre un ejemplar de una entidad con un ejemplar de otra entidad, una
vez. Es decir; en el ejemplo anterior, en la relacin no puede aparecer dos veces el
mismo trabajador asociado al mismo trabajo.

Si detectamos que nuestra base de datos requiere asociar dos veces a los mismos
ejemplares y solo hemos hecho una relacin, no hay que dudar: nuestro diseo no
es correcto.

[1.3.2]representacin grfica

La representacin grfica de las entidades se realiza con un rombo al que se le unen

lneas que se dirigen a las entidades, las relaciones tienen nombre (se suele usar
un verbo). En el ejemplo anterior podra usarse como nombre de relacin, trabajar:

[1.3.3]ejemplos de relaciones

Relaciones Binarias. Son las relaciones tpicas. Se trata de relaciones que

asocian dos entidades.
Relaciones Ternarias. Relacionan tres entidades. A veces se pueden
simplificar en relaciones binarias, pero no siempre es posible.
Relaciones n-arias. Relacionan n entidades (por ejemplo relaciones
cuaternarias, quinquenarias,...). Son muy raras
Relaciones dobles. Se llaman as a dos relaciones distintas que sirven para
relacionar a las mismas relaciones. Son las ms difciles de manejar ya que
al manipular las entidades hay que elegir muy bien cul es la relacin
adecuada para hacerlo.
Relacin reflexiva. Es una relacin que sirve para relacionar dos ejemplares
de la misma entidad (personas con personas, piezas con piezas, etc.)
[1.3.4]cardinalidad

Indica el nmero de relaciones en las que una entidad puede aparecer. Se anota en
trminos de:

cardinalidad mnima. Indica el nmero mnimo de asociaciones en las que

aparecer cada ejemplar de la entidad (el valor que se anota es de cero o
uno, aunque tenga una cardinalidad mnima de ms de uno, se indica slo
un uno)
cardinalidad mxima. Indica el nmero mximo de relaciones en las que
puede aparecer cada ejemplar de la entidad. Puede ser uno, otro valor
concreto mayor que uno (tres por ejemplo) o muchos (se representa con n).
Normalmente la cardinalidad mxima es 1 n

En los esquemas entidad / relacin la cardinalidad se puede indicar de muchas

formas. Quiz la ms completa (y la que se utiliza en este documento es sta)
consiste en anotar en los extremos la cardinalidad mxima y mnima de cada
entidad en la relacin.

Ejemplo de uso de cardinalidad:

En el ejemplo un jugador tiene una cardinalidad mnima de 0 (puede no estar en
ningn equipo) y una mxima de 1 (como mucho est en un equipo, no puede estar
en dos a la vez). Cada equipo tiene una cardinalidad mnima de uno (en realidad
sera una cardinalidad mnima ms alta, pero se anota un uno) y una mxima
de n (en cada equipo hay muchos jugadores)

[1.3.5]roles

A veces en las lneas de la relacin se indican roles. Los roles representan el papel
que juega una entidad en una determinada relacin. Son imprescindibles cuando
las relaciones son complejas, ya que ayudan a entender el sentido de la relacin.

Ejemplo:

[1.4] atributos

Describen propiedades de las entidades y las relaciones. Son fundamentales y

establecen la informacin que deseamos almacenar de cada objeto de la base de
datos. El modelo Entidad/Relacin clsico los representa con elipses, dentro de las
cuales se coloca el nombre del atributo. La elipse se une con una lnea a las
entidades. Ejemplo:
[1.4.1]tipos de atributos
compuesto

Se trata de atributos que se pueden descomponer en otros ms sencillos:

mltiples

Pueden tomar varios valores (varios telfonos para el mismo cliente):

Otra forma de representar atributos que pueden tomar mltiples valores es sta:

opcionales

Lo son si pueden tener valor nulo (es decir, si pueden quedar vacos, sin valor):

Otra forma de representarlos es:

[1.4.2]identificador principal o clave

Se trata de uno o ms atributos de una entidad cuyos valores son nicos en cada
ejemplar de la entidad. Es decir todos los elementos de una entidad tienen en ese
(o esos) atributo, un valor diferente (y nunca vaco).

Este tipo de atributos son fundamentales y se marcan en el esquema subrayando

el nombre del identificador.

Para que un atributo sea considerado un buen identificador tiene que cumplir con
los siguientes requisitos:

[1]Deben distinguir a cada ejemplar de la entidad o relacin. Es decir no puede

haber dos ejemplares con el mismo valor en el identificador.

[2]Todos los ejemplares de una entidad deben tener el mismo identificador.

[3]Un identificador puede estar formado por ms de un atributo.

[4]Puede haber varios identificadores candidatos, en ese caso hay que elegir el
que tenga ms importancia en nuestro sistema (el resto pasan a
ser alternativos).

Todas las entidades deben de tener un identificador, en el caso de que una

entidad no disponga de un identificador (puede ocurrir, pero hay que ser cauteloso,
a veces se trata de entidades que estn mal modeladas) entonces hay que aadir
un atributo que haga de identificador. Los futuros valores de este atributo no nos
interesan, lo nico que necesitamos de l es que disponga de un valor diferente
para cada ejemplar de la entidad. El nombre de este atributo artificial es la
palabra id seguida del nombre de la entidad. Por ejemplo id_personas.

[1.4.3]identificador alternativo

Se trata de uno o ms atributos en la entidad cuyos valores son nicos para cada
ejemplar de una entidad, pero que no son identificadores ya que hay atributos que
resultan ser mejores identificadores. Los identificadores alternativos se marcan con
un subrayado discontinuo (ejemplo de subrayado discontinuo)
[1.4.4]eleccin de buenos identificadores principales

Como hemos visto en los dos puntos anteriores, es habitual disponer de varios
identificadores candidatos para la misma entidad. Por ello cul elegir como
identificador principal?

[1]Siempre debemos elegir el candidato que tenga ms que ver con el problema
que estamos resolviendo. Es decir entre un documento nacional de identidad y
un cdigo que slo se usa en la empresa (cdigo cliente, cdigo de socio, n
de personal,), hay que elegir la segunda opcin. La razn es que seguro que
en la empresa se tienen ms en consideracin este segundo nmero. Como
razn tcnica : los cdigos internos siempre son ms cortos que los generales.

[2]Realmente en el modelo conceptual la nica razn a tener en cuenta es la

expuesta en el punto anterior. Sin embargo, podemos ahorrar trabajo cuando
hagamos el esquema lgico si ya cumplimos estas reglas (que en realidad son
tcnicas):

Slo debemos elegir como identificadores principales, a atributos (sea uno o

varios cuyos valores son nicos) a fechas, nmeros enteros y textos cortos y
de tamao fijo.
De los posibles candidatos observados (que cumplan el punto anterior),
elegir el que tenga ms relacin con el problema que estamos resolviendo.
Si no encontramos una diferencia conceptual, entonces elegir el que tenga
un tamao ms corto.
Si ningn candidato cumple estas reglas, es mejor incluso inventarse un
identificador (al final contendr un nmero entero diferente para cada
elemento de la entidad).

[3]En todo caso, cuando pasemos el modelo E/R a su forma lgica (por ejemplo
utilizando el modelo relacional) podemos cambiar de idea respecto al
identificador; por lo que lo dicho en el apartado anterior puede no ser tenido en
cuenta.

[1.5] modelo entidad relacin extendido

En el modelo entidad relacin extendido aparecen nuevos tipos de relaciones. Son

las relaciones ISA (es un) y las entidades dbiles

[1.5.1]entidades dbiles

Se dice que una entidad dbil es aquella cuya existencia depende de otra
(considerada su entidad fuerte). Se trata de entidades totalmente supeditadas a
otras, de modo que si un ejemplar de la entidad fuerte desaparece, todos los
ejemplares de la entidad dbil relacionados, desparacern tambin del sistema.
Las entidades dbiles ocurren cuando hay una entidad ms fuerte de la que
dependen, en el sentido de que la propia existencia de la entidad dbil est
supeditada a la existencia de su entidad fuerte. Lgicamente tienen relacin con esa
entidad, y es esa relacin es la que marca el hecho de que una entidad es dbil y
la otra fuerte.

En la Ilustracin 27, la relacin entre las tareas y los trabajos es 1 a n (cada trabajo
se compone de n tareas). Una tarea obligatoriamente est asignada a un trabajo,
es ms no tiene sentido hablar de tareas sin hablar del trabajo del que forma parte.
La relacin que tienen las tareas con los trabajos es de debilidad, puesto que no
podemos referirnos a una tarea de forma independiente.

En el ejemplo anterior hay incluso (aunque no siempre) una dependencia de

identificacin ya que las tareas se identifican por un nmero de tarea y el nmero
de trabajo al que se asignan. Cuando eso ocurre, es un sntoma definitivo de que
se trata de una entidad dbil. Por ello es tan importante determinar correctamente
los identificadores de las entidades.

La cardinalidad de una entidad dbil siempre es la siguiente:

(1,1). En el lado de la entidad fuerte, haciendo referencia a que cada

elemento de la entidad dbil se relaciona con uno y solamente uno de los
ejemplares de la entidad fuerte.
(0,n) o (1,n). En el lado de la entidad fuerte. Lo habitual es (0,n) indicando
que los ejemplares de la entidad fuerte no tienen por qu relacionarse con
ninguno de los ejemplares de la entidad dbil. De todos modos las
cardinalidades en este tipo de relaciones no se indican, por lo que no es tan
importante acertar con ellas.

La forma de representar estas relaciones es la siguiente:

No hace falta dibujar el rombo de la relacin ni la cardinalidad, se sobreentiende el
tipo y cardinalidad (1 a n) que posee. En este caso adems hay dependencia de
identificacin (no siempre la hay)

[1.5.2]relaciones ISA o relaciones de herencia

Son relaciones que indican relaciones que permiten distinguir tipos de entidades,
es decir tendremos entidades que son un (is a, en ingls) tipo de entidad respecto
a otra entidad ms general.

Se utilizan para unificar entidades agrupndolas en una entidad ms general

(generalizacin) o bien para dividir una entidad en entidades ms especficas
(especificacin): aunque hoy en da a todas ellas se las suele llamar generalizacin
e incluso (quiz incluso ms adecuadamente) relaciones de herencia.

Se habla de superentidad refirindonos a la entidad general sobre las que derivan

las otras (que se llaman subentidades). En la superentidad se indican los atributos
comunes a todas las subentidades, se sobreentiende que las subentidades tambin
tienen esos atributos, pero no se indican de nuevo esos atributos en el diagrama.

Normalmente cuando tenemos una especializacin, las subentidades comparten

clave con la superentidad (adems de los atributos comunes); esto es muy
matizable y de hecho hoy en da ningn diseador intenta distinguir entre si tenemos
una especializacin o una generalizacin, porque al final ambas implican el mismo
esquema interno en la base de datos.

La forma clsica de representar una ISA en el modelo Entidad/Relacin es:

En general se suelen indicar las cardinalidades en las relaciones ISA, pero se suele
sobreentender (cuando no se indican explcitamente) que hay un (0,1) encima de
cada subentidad (que significa que cada ejemplar de la subentidad solo puede
relacionarse como mucho con uno de la subentidad e incluso con ninguno; un
empleado de personal podra ser o no ser un profesor).

Pero se puede perfectamente indicar la cardinalidad (se usa ya la notacin de ISA

con tringulo hacia abajo que es la ms popular en Espaa actualmente):

Las cardinalidades que aparecen en el esquema anterior son las habituales (de
hecho no se suele indicar ya que se sobrentiende), pero cualquier cardinalidad sera
vlida.

En la relacin ISA anterior, los profesores, bedeles y tcnicos heredan el atributo id

personal y el nombre, el resto son atributos propios slo de cada entidad
(trienios pertenece slo a los profesores, en este ejemplo)
En la ilustracin anterior se utiliza una clave distinta para cada subentidad (es
decir, discos, libros y merchandising tienen clave propia), no la heredan.

Adems, es un caso en el que no hay relacin obligatoria con la superentidad; es

decir, un disco podra no ser un artculo (porque a lo mejor quiero meter discos en
mi base de datos que no vendo en la tienda). No es muy habitual utilizar de esta
forma relaciones ISA, pero desde luego es posible.

Normalmente en los esquemas no se indican las cardinalidades de las relaciones

ISA y se sobrentiende que la superentidad tiene un 1,1 y las subentidades 0,1; es
la cardinalidad habitual.
[1.5.3]cundo hay que utilizar relaciones ISA?

Cuando los diseadores principiantes conocen las relaciones ISA, suele ocurrir un
exceso de uso de ellas en los diseos. No es conveniente abusar de este tipo de
relaciones, ya que aumentan en exceso el nmero de entidades.

No todos los tipos de entidades suponen la aparicin de una generalizacin o una

especializacin. A veces basta diferenciar los tipos de entidad con el uso de un
simple atributo tipo o, como mucho, una entidad que contenga los tipos de
entidades.

Lo recomendable es utilizar relaciones ISA cuando ocurre cualquiera de estas

situaciones:

Las subentidades tienen atributos distintos.

Las subentidades tienen relaciones distintas.

En otros casos, se puede concluir que no resulta necesaria la creacin de relaciones

ISA.

[1.5.4]exclusividad

En las relaciones ISA (y tambin en otros tipos de relaciones) se puede indicar el

hecho de que cada ejemplar slo puede participar en una de entre varias ramas de
una relacin. Este hecho se marca con un arco entre las distintas relaciones. En las
relaciones ISA se usa mucho para indicar que cada ejemplar de la superentidad
slo se relaciona con una subtentidad, por ejemplo:
En el ejemplo, el personal slo puede ser o bedel o profesor o tcnico; una y slo
una de las tres cosas (es por cierto la forma ms habitual de relacin ISA).

Se pueden marcar relaciones de exclusividad en otras relaciones. Significar lo

mismo, es decir que solo uno de las situaciones enmarcadas por un arco se pueden
dar a la vez.

Por ejemplo:

En la Ilustracin anterior, solo puede ocurrir a ala vez una de las dos
relaciones: Participar o Competir. Significa que en las competiciones o participan
personas o compiten equipos. Es verdad, que en este caso a lo mejor se podra
generalizar indicando una superentidad llamada Competidores para las personas y
los equipos, que sera mucho ms clarificadora.

No obstante no siempre se puede reflejar de otra forma una relacin de exclusividad

sobre relaciones normales.
[1.5.5]tipos de relaciones ISA

Realmente lo que hay que matizar bien en las relaciones ISA es la forma de
relacionarse la superentidad con la subentidad. Eso se matiza en base a dos
conceptos:

Obligatoriedad. Indica si los ejemplares obligatoriamente se relacionan con

ejemplares de las subentidades. Es decir si hay personal que no es profesor
ni bedel ni tcnico o si fijo es alguna de esas tres profesiones. Hay dos
posibilidades:
o Relaciones de jerarqua parcial. Indican que hay ejemplares de la
superentidad que no se relacionan con ningn ejemplar de las
subentidades (por ejemplo, hay personal que no es ni profesor,
ni bedel ni tcnico). Se indican con un crculo encima del tringulo de
la relacin ISA.
o Relaciones de jerarqua total. Indican que todos los ejemplares de
la superentidad se relacionan con alguna subentidad (no hay personal
que no sea ni profesor, ni bedel ni tcnico).
Nmero de relaciones. En este caso se mide con cuntas subentidades se
relaciona la subentidad; es decir, si hay personal que pueda ser profesor y
bedel a la vez o si slo puede ser una cosa. Posibilidades:
o Relaciones de jerarqua solapada. Indican que un ejemplar de la
superentidad puede relacionarse con ms de una subentidad (el
 personal puede ser profesor y bedel). Ocurren cuando no hay dibujado
un arco de exclusividad.
o Relaciones de jerarqua exclusiva. Indican que un ejemplar de la
superentidad slo puede relacionarse con una subentidad (el personal
no puede ser profesor y bedel). Ocurren cuando hay dibujado un arco
de exclusividad.

La forma grfica ms aceptada actualmente para representar este tipo de relaciones

es la mostrada en la Ilustracin 35.

[1.6] otras formas de representacin del modelo Entidad/Relacin

Las herramientas CASE actuales no suelen utilizar la forma de dibujar del modelo
clsico. Las razn fundamental est en la dificultad de dibujar los atributos ya que
ocupan un excesivo espacio en el diagrama. Como, adems, los analistas estn
acostumbrados a representar diagramas lgicos basados en el modelo relacional
de bases de datos, se usan diagramas entidad relacin en los que la representacin
de entidades y relaciones se hace de esta forma:

Las entidades son rectngulos en los que la primera fila se dedica al nombre
de la entidad y las siguientes filas a cada uno de sus atributos.
Las relaciones son rombos y sus atributos cuelgan en una caja que contiene
el nombre de dichos atributos. En algunos casos ni siquiera se representa la
relacin con un rombo, sino que simplemente se indica su nombre.

Ejemplo:
 En las entidades dbiles es el rombo de la relacin el que se dibuja con borde
doble y la lnea que va hacia la entidad dbil, tambin se dibuja doble.
Finalmente las relaciones de tipo ISA (relaciones de herencia o
generalizaciones) se representan de la misma forma, con un tringulo
(aunque en estos diagramas el vrtice est al revs)

Manual de Gestin de Bases de Datos

[3]
Modelo Relacional
[3.1] el modelo relacional
[3.1.1]introduccin

Durante los primeros aos de las bases de datos, se utiliz el modelo

jerrquico como la primera forma de describir de forma ms humana una base de
datos. Despus rein el modelo en red especialmente en su norma Codasyl. As
a principios de los 70 pareca que el modelo a aplicar al implementar bases de datos
sera Codasyl y lo sera por muchos aos.

Sin embargo, Edgar Frank Codd defini las bases del modelo relacional a finales
de los 60. En 1970 publica el documento A Relational Model of data for Large
Shared Data Banks (Un modelo relacional de datos para grandes bancos de datos
compartidos). Actualmente se considera que ese es uno de los documentos ms
influyentes de toda la historia de la informtica. Lo es porque en l se definieron las
bases del llamado Modelo Relacional de Bases de Datos. Anteriormente el nico
modelo terico estandarizado era el modelo Codasyl que se utiliz masivamente
en los aos 70 como paradigma del modelo en red de bases de datos.

Codd se apoya en los trabajos de los matemticos Cantor y Childs (cuya teora de
conjuntos es la verdadera base del modelo relacional). Segn Codd, los datos se
agrupan en relaciones(actualmente llamadas tablas), las cuales son una
estructura que aglutina datos referidos a una misma entidad de forma organizada.
Las relaciones, adems, estructuran los datos de forma independiente respecto a
su almacenamiento real en la computadora. Es decir, es un elemento conceptual,
no fsico.

Lo que Codd intentaba fundamentalmente es evitar que las usuarias y usuarios de

la base de datos tuvieran que verse obligadas a aprender los entresijos internos del
sistema. Esto es lo que ocurra con el modelo en red, dominante cuando Codd
dise el modelo relacional, que era bastante fsico. Su enfoque fue revolucionario
al evitar conceptos del mundo de la computacin en su modelo.
Aunque trabajaba para IBM, esta empresa no recibi de buen grado sus teoras. De
hecho, IBM continu trabajando en su sistema gestor de bases de datos en red IMS.
Fueron otras empresas (en especial Oracle) las que implementaron sus teoras.

Pocos aos despus, el modelo se empez a utilizar cada vez ms hasta,

finalmente, ser el modelo de bases de datos ms popular. Hoy en da casi todas las
bases de datos siguen este modelo, aunque en estos aos han aparecido rivales
cada vez ms fuertes en las llamadas bases de datos NoSQL, que han demostrado
un gran eficacia en bases de datos que necesitan una enorme cantidad de
instrucciones de modificacin por minuto.

[3.1.2]objetivos del modelo

Codd persegua estos objetivos con su modelo relacional:

Independencia fsica. La forma de almacenar los datos, debe ser

absolutamente independiente del modelo conceptual de los mismos. Si la
forma de almacenar los datos cambia (si cambia el esquema fsico) , no es
necesario cambiar los esquemas lgicos, funcionan perfectamente. Esto
permite que los usuarios y usuarias se concentren en qu resultados desean
obtener de la base de datos independientemente de cmo estn realmente
almacenados los datos.
Independencia lgica. Se refiere a que la lgica de la base de datos debe
de ser independiente de la forma externa de acceso a la base de datos (los
esquemas externos). Las aplicaciones que utilizan la base de datos no deben
ser modificadas porque se modifique el esquema lgico de la misma. De una
manera ms precisa: gracias a esta independencia el esquema externo de la
base de datos es realmente independiente del modelo lgico. En la prctica,
esta independencia es difcil de conseguir.
Flexibilidad. La base de datos ofrece fcilmente distintas vistas en funcin
de los usuarios y aplicaciones. La visin de los datos se adapta al usuario
que los requiere.
Uniformidad. Las estructuras lgicas siempre tienen una nica forma lgica
(las tablas). Es decir, manejar el modelo relacional es manejar las tablas.
Sencillez. Facilidad de manejo (algo cuestionable, pero ciertamente
verdadero si comparamos con los sistemas gestores de bases de datos
anteriores a este modelo).
[3.1.3]historia del modelo relacional
Ao Hecho
1970 Codd publica las bases del modelo relacional
1971-
Primeros desarrollos tericos
72
Ao Hecho
Primeros prototipos de base de datos relacional. Son el System R de IBM.
1973-
En ese sistema se desarrolla Sequel que con el tiempo cambiar su
78
nombre a SQL.
La Universidad de Berkeley desarrolla Ingres, SGBD relacional basado en
1974 clculo relacional. Utilizaba el lenguaje Quel desarrollado en las
universidades y muy popular en la poca en mbitos acadmicos.
Aparece el lenguaje QBE (Query By Example) lenguaje de acceso
1978
relacional a los archivos VSAM de IBM
Aparece Oracle, el primer SGBD comercial relacional (ganando en unas
semanas al System/38 de IBM). Implementa SQL y se convertir en el
1979 sistema gestor de bases de datos relacionales lder del mercado.
Codd revisa su modelo relacional y lanza el modelo RM/T como un intento
de subsanar sus deficiencias.
1981 Aparece Informix como SGBD relacional para Unix
1983 Aparece DB2, el sistema gestor de bases de datos relacionales de IBM
Aparece la base de datos Sybase que lleg a ser la segunda ms popular
1984
(tras Oracle)
ANSI normaliza el SQL (SQL/ANSI). SQL es ya de hecho el lenguaje
1986
principal de gestin de bases de datos relacionales.
1987 ISO tambin normaliza SQL. Es el SQL ISO(9075)
1988 La versin 6 de Oracle incorpora el lenguaje procedimental PL/SQL
ISO revisa el estndar y publica el estndar SQL Addendum.
Microsoft y Sybase desarrollan SQL Server para el sistema
1989
operativo OS/2 de Microsoft e IBM. Durante aos Sybase y SQL Server
fueron el mismo producto.
Versin dos del modelo relacional (RM/V2) realizada por Codd.
1990 Propuesta de Michael Stonebraker para aadir al modelo relacional
capacidades de orientacin a objetos.
1992 ISO publica el estndar SQL 92 (todava el ms utilizado)
Manifiesto de Darwen y Date en el que animan a reinterpretar el modelo
relacional desde una perspectiva de objetos. Aparece el modelo
objeto/relacional.
1995
Aparece MySQL una base de datos relacional de cdigo abierto con
licencia GNU que se hace muy popular entre los desarrolladores de
pginas web.
ANSI normaliza el lenguaje procedimental basado en SQL y lo
llaman SQL/PSM. Permite tcnicas propias de los lenguajes de
1996 programacin estructurada.
Aparece el SGBD abierto PostgreSQL como remodelacin de la antigua
Ingres, utilizando de forma nativa el lenguaje SQL (en lugar de Quel).
ISO publica un nuevo estndar que incluye caractersticas ms avanzadas.
1999
Se llama SQL 99 (tambin se le conoce como SQL 2000)
 Ao Hecho
Richard Hipp disea SQLite base de datos relacional que ocupa muy
2000 poco, pero que ofrece prestaciones propias de sistemas ms grandes. Es
muy utilizada en aplicaciones, especialmente en los dispositivos mviles.
2003 ISO publica el estndar SQL 2003. En l se aade SQL/PSM al estndar.
2006 Estndar ISO. SQL 2006
2008 Estndar ISO. SQL 2008
2011 Estndar ISO. SQL 2011
[3.2] estructura de las bases de datos relacionales
[3.2.1]relacin o tabla

Segn el modelo relacional (desde que Codd lo enunci) el elemento fundamental

del modelo es lo que se conoce como relacin, aunque ms habitualmente se le
llama tabla (o tambin array o matriz). Codd defini el significado de las relaciones
utilizando un lenguaje matemtico. Para comprender visualmente este concepto
siempre se han utilizado las tablas, ya que permiten representar la informacin de
las relaciones en forma de filas y columnas.

No hay que confundir la idea de relacin segn el modelo de Codd, con lo que
significa una relacin en el modelo Entidad/Relacin de Chen. No tienen nada que
ver

Las relaciones constan de:

Atributos. Es cada una de las propiedades de los datos de la relacin

(nombre, dni,...). Las relaciones representan conjuntos de objetos o
elementos reales, cada atributo es propiedad o caracterstica de dicho
elemento.
Tuplas. Referido a cada ejemplar, objeto o elemento de la relacin. Por
ejemplo si una relacin almacena personas, una tupla representara a una
persona en concreto.

Puesto que una relacin se representa como una tabla; podemos entender que las
columnas de la tabla son los atributos; y las filas, las tuplas.

atributo 1 atributo 2 atributo 3 .... atributo n

valor 1,1 valor 1,2 valor 1,3 .... valor 1,n <-- tupla 1
valor 2,1 valor 2,2 valor 2,3 .... valor 2,n <-- tupla 2
..... ..... ...... .... ..... ....
valor m,1 valor m,2 valor m,3 .... valor m,n <-- tupla m

La tabla superior representa la estructura de una relacin segn el modelo de Codd.

Ejemplo:

cod_empleado nombre apellido1 apellido2 salario

1 Juan Marcos Serra 35000
2 Adela Heredia Castro 28500
3 Carlos Martnez Jurez 21000
4 Sandra Andrez Pereira 41000
5 Izan Mancho Arrieta 34000
6 Petra Pacheco Castelo 25500

La forma de representar relaciones es mediante tablas regulares en las que las

columnas se corresponden con los atributos y las filas con las tuplas. Esta forma es
ms visual y entendible.

[3.2.2]tupla

Se llama tupla a cada uno de los elementos de una relacin. Hablando en trminos
de tabla, una tupla es una fila. Las tuplas, en el modelo relacional, cumplen estas
premisas:

Cada tupla se debe corresponder con un elemento del mundo real.

No puede haber dos tuplas iguales (con todos los valores iguales).
[3.2.3]dominio

Un dominio contiene todos los posibles valores que puede tomar un determinado
atributo. Dos atributos distintos pueden tener el mismo dominio.

Un dominio esta formado por un conjunto finito de valores del mismo tipo. A los
dominios se les asigna un nombre y as podemos referirnos a ese nombre en ms
de un atributo, facilitando la aplicacin de los mismos.

Por ejemplo si tenemos un atributo llamado Fecha_nac que sirve para almacenar
fechas de nacimiento, podremos entender que el valor Hola no tiene sentido en
ese atributo. Tcnicamente se dice que Hola no pertenece al dominio de las fechas.
S pertenece el valor: 3/9/1982. Una expresin como 34/3/1982 tampoco pertenece
al dominio, no es vlida (no hay meses de 34 das). Es decir, un dominio expresa
de forma inequvoca los valores posibles dentro de un atributo.

Se confunde la idea entre tipo de datos y dominio. Lo cierto es que son conceptos
semejantes, pero no iguales. La diferencia es que el dominio impone ms
restricciones que los tipos de datos.

Por ejemplo, el texto Hola, est claro que no puede ser un valor para el
atributo fecha_nac, porque no es una fecha. Sin embargo si tuviramos un atributo
llamado pas el texto Holatampoco forma parte de los valores posibles para ese
atributo, porque Hola no es un pas; y, sin embargo, tanto la expresin Hola como
el nombre de los pases pertenecen al mismo tipo de datos (son textos).

Evidentemente ,el ejemplo del dominio para el atributo pas es ms complejo. No

solo almacena textos sino que slo valen textos concretos, los que representan uno
de los pases existentes en el planeta: lgicamente este dominio es mucho ms
difcil de definir.

Otro ejemplo de dominio: el que hace que un valor para el atributo dni slo se
considere perteneciente a su dominio si tiene ocho nmeros, una letra y adems la
letra cumple una regla matemtica concreta sobre los nmeros.

La forma de indicar un dominio se puede hacer utilizando dos posibles tcnicas:

Intensin. Se define el nomino indicando la definicin exacta de sus posibles

valores. Por intensin se puede definir el dominio de edades de los
trabajadores como: nmeros enteros entre el 16 y el 65 (un trabajador slo
podra tener una edad entre 16 y 65 aos).
Extensin. Se indican algunos valores y se sobreentiende el resto gracias a
que se autodefinen con los anteriores. Por ejemplo el dominio localidad se
podra definir por extensin as: Palencia, Valladolid, Villamuriel de Cerrato,...

Adems pueden ser:

Generales. Los valores estn comprendidos entre un mximo y un mnimo y

pueden tomar cualquier valor intermedio.
Restringidos. Solo pueden tomar un conjunto de valores.
[3.2.4]grado

Indica el tamao de una relacin en base al nmero de columnas (atributos) de la

misma. Lgicamente cuanto mayor es el grado de una relacin o tabla, mayor es su
complejidad de manejo.

[3.2.5]cardinalidad

Nmero de tuplas de una relacin, o nmero de filas de una tabla. Hay tablas que
pueden tener una enorme cardinalidad: cientos, miles e incluso millones de filas.

[3.2.6]sinnimos

Los trminos vistos anteriormente tienen distintos sinnimos segn la nomenclatura

utilizada. A ese respecto se utilizan tres nomenclaturas:
 Trminos 1 Trminos 2 Trminos 3
(nomenclatura (nomenclatura (nomenclatura
relacional) tabla) ficheros)
relacin = tabla = fichero
tupla = fila = registro
atributo = columna = campo
grado = n de columnas = n de campos
cardinalidad = n de filas = n de registros

Se han subrayado en la tabla los trminos que se usan ms frecuentemente.

[3.2.7]propiedades de las tablas (o relaciones)

Cada tabla debe tener un nombre distinto

Cada atributo de la tabla solo puede tener un valor en cada tupla
Cada atributo tiene un nombre distinto en cada tabla (aunque puede coincidir
en tablas distintas)
Cada tupla es nica (no hay tuplas duplicadas)
El orden de los atributos no importa
El orden de las tuplas no importa
[3.2.8]tipos de tablas

Persistentes. Son las tablas que crean los usuarios (normalmente los
administradores). Slo pueden ser borradas por los usuarios Se dividen en
tres tipos:
o Bases. Son tablas independientes. Se crean indicando su estructura
y despus se les aaden los datos. Cuando alguien habla de tablas,
se refiere a este tipo de tablas.

Las tablas base contienen tanto datos como metadatos. Por ello
(debido a los datos) pueden ocupar mucho espacio en disco. Son el
fundamento del modelo relacional

o Vistas. Contienen una instruccin (normalmente en lenguaje SQL) la

cual provoca una consulta sobre los datos de las tablas base,
haciendo que se muestren los datos que cumplen las condiciones
especificadas en dicha instruccin.

No ocupan mucho espacio en disco (ya que no almacenan datos). Si

los datos de las tablas base cambian, los de las vistas que utilizan
esos datos tambin cambian.
 Las vistas permiten una visin de los datos ms cmoda para los
usuarios.

o Instantneas o vistas materializadas. Son vistas (es decir,

consultas) que adems de almacenar la instruccin SQL, almacenan
una copia de los datos que muestra. De modo que la siguiente vez
que usemos la instantnea, utilizar la copia de los datos (no leer los
datos originales). Las instantneas, a diferencia de las vistas, no
siempre muestran los datos actualizados.

Las instantneas actualizan los datos, refrescando el resultado cada

cierto tiempo. La ventaja es que son ms veloces que las vistas al no
tener que acudir a los datos base; la parte mala, es que los datos que
muestran pueden ser obsoletos (ya que pueden haber variado en las
tablas base originales).

Temporales. Son tablas que se eliminan automticamente por el sistema.

Las utiliza el SGBD como almacn intermedio de datos (resultados de
consultas, por ejemplo) para acelerar la ejecucin del sistema o como
almacn auxiliar para instrucciones complejas.

Hay tablas temporales de tipo base, vista o instantneas; al igual que ocurre
con las persistentes.

[3.2.9]claves
clave candidata

Conjunto de atributos que identifican inequvocamente cada tupla de la relacin. Es

decir columnas cuyos valores no se repiten en ninguna otra fila de esa tabla. Toda
tabla, en el modelo relacional, debe tener al menos una clave candidata, pero puede
haber muchas ms.

clave primaria

Clave candidata que se escoge como identificador de la tabla (para identificar cada
fila de la misma). Se elige como primaria la candidata que identifique mejor a cada
tupla en el contexto de la base de datos. Adems se debe dar prioridad a atributos
cuyos dominios sean ms eficientes de cara al tamao que ocupan en disco y a la
facilidad de proceso por parte de la mquina.

Por ejemplo, en una base de datos de una empresa de venta de productos, un

campo con el DNI sera clave candidata de una tabla de clientes; si esa tabla tiene
un campo de cdigo de cliente, ste sera mejor candidato (y por lo tanto clave
principal) porque es mejor identificador para ese contexto.
Las claves primarias son los nicos datos en el modelo relacional que provocan
redundancia ya que se duplican en las claves secundarias para establecer las
relaciones entre las tablas. Por ello hay que intentar que las claves primarias
contengan datos pequeos, nunca textos largos y de tamao variable (como
nombres, ttulos,).

Buenos tipos de datos para claves primarias son las fechas, nmeros enteros y
textos, si son cortos y de tamao fijo.

clave alternativa

Cualquier clave candidata que no es elegida como primaria. Hay que tenerlas en
cuenta para, al menos, aplicar las restricciones correspondientes (se explican ms
adelante).

clave externa, ajena o secundaria

Son los datos de atributos de una tabla cuyos valores estn relacionados con
atributos de otra tabla. Por ejemplo en la tabla equipos tenemos estos datos:

Equipo N Equipo
Real Madrid 1
F.C. Barcelona 2
Athletic Bilbao 3

En la tabla anterior la clave principal es el atributo n equipo. En otra tabla tenemos:

N Jugador Jugador N Equipo

1 Muniain 3
2 Messi 2
3 Cristiano Ronaldo 1
4 Bale 1

El atributo N Equipo sirve para relacionar el Jugador con el equipo al que

pertenece. Ese campo en la tabla de jugadores es una clave secundaria. En el
detalle siguiente se resalta la relacin entre las claves primarias (en la base de las
flechas) y las claves secundarias (en la punta de las flechas):
[3.2.10]nulos

En los lenguajes de programacin se utiliza el valor nulo para reflejar que un

identificador (una variable, un objeto,..) no tiene ningn contenido. Por ejemplo,
cuando un puntero (elemento del lenguaje que sirve para sealar a datos) en
lenguaje C seala a null, se entiende que no est sealando a nadie.

Ese significado tambin se usa en las bases de datos pero, en este caso, para
indicar la ausencia de valor en un atributo. Un atributo null, es un atributo vaco.
Para Codd el nulo era un valor fundamental ya que otorga de significado al atributo
tanto como si tuviera un valor numrico o textual.

Por ejemplo, un valor null puesto en una clave secundaria, indica que la fila que
donde se ha puesto ese valor, no tiende ninguna clave principal asociada. En un
atributo para indicar el telfono de una persona, significara que esa persona no
tiene telfono.

Es importante indicar que el texto vaco , no significa lo mismo que el valor nulo.
Tampoco el valor numrico cero (0) significa nulo.

Puesto que los nulos se utilizan continuamente, resulta imprescindible saber cmo
acta cuando se emplean operaciones lgicas sobre ellos. Eso significa definir un
tercer valor en la lgica booleana, adems de los clsicos verdadero y falso. Un
valor nulo no es ni verdadero ni falso (se suele interpretar como un quizs, o usando
la aritmtica clsica en valores lgicos, el 1 es verdadero, el 0 falso y el 0,5 nulo).

El uso de operadores lgicos con el nulo da lugar a que:

verdadero Y (AND) nulo da como resultado, nulo. Siguiendo la aritmtica

planteada antes: 10,5=0,5
 falso Y (AND) nulo da como resultado, falso (00,5=0)
verdadero O (OR) nulo da como resultado, verdadero (1+0,5>1)
falso O nulo da como resultado nulo (0+0,5=0,5)
la negacin de nulo, da como resultado nulo

Se utiliza un operador en todas las bases relacionales llamado es nulo (is null) que
devuelve verdadero si el atributo con el que se compara tiene valor nulo.

[3.3] restricciones

Se trata condiciones de obligado cumplimiento para que un dato forme parte de una
tabla

[3.3.1]inherentes

Son aquellas que no requieren que se establezcan de forma explcita, sino que son
definidas por el propio hecho de que la base de datos sea relacional. Las ms
importantes son:

No puede haber dos filas iguales

El orden de las filas no es significativo
El orden de las columnas no es significativo
Cada atributo slo puede tomar un valor en la interseccin entre fila y
columna
[3.3.2]semnticas

El modelo relacional permite incorporar restricciones personales a las tablas. Son

las ms importantes y son fundamentales para que la informacin de la base de
datos sea coherente y eficiente. Se comentan a continuacin las principales
restricciones semnticas:

restriccin de clave principal (primary key)

Tambin llamada restriccin de clave primaria. Marca uno o ms atributos como

identificadores de la tabla (lo cual es imprescindible en toda tabla del modelo
relacional).

Esta restriccin (adems de marcar los datos identificativos de una tabla) prohbe
que las columnas que forman la clave primaria puedan contener valores repetidos
en distintas filas o que queden vacas (nulos) en alguna fila. Es decir el contenido
de las claves primarias es nico y distinto de nulo.

restriccin de unicidad (unique)

Impide que los valores de los atributos marcados de esa forma, puedan repetirse en
distintas filas. Esta restriccin debe indicarse en todas las claves alternativas (las
primarias la tienen de forma implcita).

obligatoriedad (not null)

Prohbe que el atributo marcado de esta forma quede vaco (es decir impide que
pueda contener el valor nulo, null) en alguna fila. Tambin se debe de indicar en las
columnas que son clave alternativa.

clave alternativa (alternate key)

Salvo en algunas bases de datos (muy pocas), no es posible marcar esta restriccin,
que indicara sobre una o ms columnas, el hecho de que no pueden repetir valores
ni quedar vacas en cada fila. Es decir, restringen igual que las claves principales,
pero, en este caso, no son las idneas para identificar cada fila y por ello habr otra
clave principal.

Un conjunto de atributos que forman una clave alternativa poseern las restricciones
de unicidad (unique) y obligatoriedad (not null)

integridad referencial (foreign key)

Sirve para indicar una clave externa (tambin llamada secundaria o fornea) sobre
uno o ms atributos. Los atributos marcados de esta forma slo podrn contener
valores que estn relacionados con la clave principal de la tabla que relacionan
(llamada tabla principal). Dichos atributos s podrn contener valores nulos.

Alquileres
Cod_alquiler Fecha cod_cliente
1 12/9/2008 121
2 12/9/2008 121
3 15/9/2008 97
4 16/9/2008 113
5 16/9/2008 129

Clientes
Nombre Apellidos Cod_cliente
Arturo Crespo 97
Sara lvarez 113
Josu Lopetegi 121
 Alba Pereira 123
Gonzalo Prez 129

Eso causa problemas en las operaciones de borrado y modificacin de registros; ya

que si se ejecutan esas operaciones sobre la tabla principal (si se modifica o borra
un cliente) quedarn filas en la tabla secundaria con la clave externa haciendo
referencia a un valor que ya no existe en la tabla principal.

Es decir si en el ejemplo anterior, borramos la fila en clientes que hace referencia al

cliente que se llama Josu, la base de datos reaccionar prohibiendo esta operacin
ya que hay dos alquileres relacionados con ese cliente. Lo mismo ocurre si
intentamos cambiar el cdigo de cliente de Josu.

Para solventar esta situacin se puede hacer uso de estas polticas al crear la
restriccin:

Prohibir la operacin (no action). Esto no permitira hacer en las claves

principales ninguna operacin si hay claves secundarias relacionadas con
ellas. Suele ser la opcin por defecto.
Transmitir la operacin en cascada (cascade). Es decir si se modifica o
borra un cliente; tambin se modificarn o barrarn los alquileres
relacionados con l.
Colocar nulos (set null) Las referencias al cliente en la tabla de alquileres se
colocan como nulos (es decir, alquileres sin cliente) al hacer las operaciones
de actualizar o borrar los datos
Usar el valor por defecto (default). Se colocan un valor por defecto en las
claves externas relacionadas cuando se borre o modifique la clave principal
relacionada. Este valor por defecto se indica al crear la tabla (opcin default).

No todas las bases de datos admiten todas estas posibles polticas a aplicar en
operaciones de actualizar o eliminar. Adems podemos indicar una poltica al
actualizar y otra al eliminar.

regla de validacin (check)

Condicin lgica que debe de cumplir un dato concreto en una o ms columnas (a

las que se aplicar esta restriccin) para darlo por vlido. Por ejemplo, podramos
restringir la columna llamada sueldo para que siempre acepte valores mayores
de 1000; no se permitira entonces indicar sueldos menores de 1000.

A veces las reglas implican a varias columnas, como por ejemplo que la fecha de
inicio sea mayor que la fecha final.

disparadores o triggers
Son restricciones ms complejas presentes en sistemas avanzados de bases de
datos. Se trata de cdigo almacenado en la base de datos, cuyas instrucciones se
ejecutan automticamente cuando ocurre un determinado evento (aadir una fila,
modificar filas, iniciar sesin por parte del usuario,...).

Las instrucciones pueden realizar cualquier operacin permitida. Por ejemplo,

podemos hacer que ningn usuario pueda aadir datos de 12 de la noche a 5 de la
maana, o que no podamos aadir una cuenta bancaria si sus dgitos de control no
cumplen la compleja regla que se les aplica.

Los triggers permiten realizar restricciones muy potentes, pero son las restricciones
ms complejas de definir ya que implican conocimientos de programacin.

[3.4] las 12 reglas de Codd

Preocupado por los productos que decan ser sistemas gestores de bases de datos
relacionales (RDBMS) sin serlo, Codd publica 12 reglas que debe cumplir todo
Sistema Gestor de Bases de Datos para ser considerado relacional ; lo hace en el
ao 1985.

Las doce reglas en la prctica las cumplen pocos sistemas relacionales, pero s los
mejores. El inters actual de estas reglas, cuando el propio modelo relacional se
est revisando, es que permiten detallar la manera de funcionar de un sistema de
bases de datos relacional.

Las reglas son:

[1]Informacin. Toda la informacin de la base de datos (metadatos) debe estar

almacenada explcitamente en el esquema lgico. Es decir, todos los datos se
almacenan en las tablas base del sistema. Dicho de otro modo: no pueden
existir datos a los que tengamos que acceder por una va diferente a la de las
tablas del modelo relacional.

[2]Acceso garantizado. Todo dato en la base de datos es accesible sabiendo el

valor de su clave principal y el nombre de la columna o atributo que contiene el
dato. No hace falta saber, por ejemplo, ni el nmero de fila ni el de columna.
Esto implica que todas las tablas tienen que tener identificador y eso nos
permite acceder a una fila concreta; la columna es accesible por su nombre y
no por el orden que tiene.

[3]Tratamiento sistemtico de los valores nulos. El DBMS (Sistema Gestor de

bases de datos) debe permitir el tratamiento adecuado de estos valores. Esto
significa que los valores nulos se manejan como una informacin ms de la
base de datos; se podr utilizar como informacin en s y por lo tanto operar
con estos valores no producir error alguno. Se permitir realizar operaciones
lgicas y de todo tipo con ellos, haciendo que el resultado sea coherente.
[4]Catlogo en lnea basado en el modelo relacional. El catlogo en lnea es
otro nombre para el diccionario de datos. Esta regla indica que los metadatos
deben de ser accesibles usando un esquema relacional. Es decir la forma de
acceder a los metadatos es la misma que la forma de acceder a los datos. Dicho
de otra forma, tambin los metadatos se almacenan en tablas.

[5]Sublenguaje de datos completo. Al menos, debe de existir un lenguaje que

permita el manejo completo de la base de datos. Mediante este lenguaje
podremos realizar cualquier operacin sobre la base de datos, sea del tipo que
sea.

[6]Actualizacin de vistas. El SGBD debe encargarse de que las vistas muestren

la ltima informacin. En ningn caso las vistas mostrarn informacin
obsoleta. Esto implica una enorme potencia por parte del Sistema Gestor de
Bases de Datos.

[7]Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier

operacin de modificacin debe actuar sobre conjuntos de filas o registros,
nunca deben actuar registro a registro. Por lo tanto los lenguajes que realizan
estas tareas (DML) son de cuarta generacin y no pueden ser lenguajes como
C o Java por ejemplo (de tercera generacin) que normalmente utilizaran
recorridos fila a fila y bucles para modificar los datos, provocando un manejo
menos humano de la base de datos.

[8]Independencia fsica. El esquema lgico y los externos (las aplicaciones de

usuario) no se deben modificar por los cambios que se realicen en la base de
datos fsica. Es decir aunque, por ejemplo, cambiemos el nombre de un fichero
de la base de datos, por ejemplo, no tendremos que modificar ni los programas
de los usuarios ni siquiera la lgica (las tablas) de la base de datos.

[9]Independencia lgica. Los cambios en la lgica de la base de datos (en las

tablas), no afectan a la forma en la que el usuario accede a la base de datos.
Es decir, las aplicaciones de usuario son independientes de la propia lgica.
Esta independencia en la prctica no se consigue tan fcilmente como la
anterior.

[10]Independencia de integridad. Las reglas de integridad deben almacenarse

en la base de datos (en el diccionario de datos), no en los programas de
aplicacin. Eso permite que dichas reglas sobre los datos se cumplan siempre
independientemente de la forma de acceder a los mismos.

[11]Independencia de la distribucin. El sublenguaje de manipulacin de datos

(DML) debe permitir que sus instrucciones funcionen igualmente en una base
de datos distribuida que en una que no lo es. Los programas y aplicaciones de
usuarios se crean de la misma forma. Es decir las bases de datos distribuidas
permiten trabajar en ellas como si fueran una base de datos normal y local.
 [12]No subversin. Si el SGBD dispone de un lenguaje de bajo nivel
(normalmente ser un lenguaje de tipo procedimental) para trabajar en la base
de datos (como por ejemplo el PL/SQL de Oracle), este lenguaje no se puede
saltar ninguna regla de las anteriores. Puede que facilite la realizacin de tareas
este tipo de lenguaje, pero en ningn caso podr trabajar con los datos de forma
incompatible con el modelo relacional.

Manual de Gestin de Bases de Datos

[4]
Diseo lgico de bases de datos relacionales
PUBLICIDAD
[4.1] introduccin

Disear bases de datos es un proceso metdico que parte del esquema conceptual.
Pero que luego requiere realizar al menos dos esquemas ms para acercarnos a la
forma final en la que el ordenador representar la base de datos. El diagrama
comentado en los apartados anteriores es el siguiente:

En esta unidad partiremos de un esquema conceptual (de tipo Entidad/Relacin) ya

creado para conseguir el siguiente esquema que ser el esquema relacional. Por
supuesto suponemos que necesitamos una base de datos de tipo relacional (de otro
modo necesitaremos otro modelo lgico).

El esquema interno (que sera el siguiente a realizar) se ver en posteriores

unidades. En el caso de este manual, ser un esquema compatible con el sistema
de bases de datos de Oracle.

[4.2] representacin de esquemas de bases de datos relacionales

[4.2.1]forma clsica de representacin

La manera clsica de representar esquemas relacionales es usando esta notacin:

TABLA(Columna1, Columna2,.)

En la que adems las claves primarias se representan subrayadas y las alternativas

con un subrayado discontinuo.

Ejemplo:

PIEZAS(Tipo, Modelo, Nombre, Apellido1, Apellido2)

EMPRESAS(CIF, Cod_Empresa, Nombre, Direccin)
SUMINISTROS(Tipo,Modelo, Cod_Empresa, Precio)
EXISTENCIAS(Tipo, Modelo, N_Almacen, Cantidad)

Adems se pueden indicar con otros smbolos las restricciones de unicidad

(UNIQUE) y de obligatoriedad (NOT NULL).

En ese tipo de esquemas es difcil ver las relaciones en los datos, algo que s se
ve muy bien en los esquemas entidad relacin. Por ello se suelen complementar
los esquemas clsicos con lneas y diagramas que representan esa informacin.
[4.2.2]grafos relacionales

Es un esquema relacional en el que hay lneas que enlazan las claves principales
con las claves secundarias para representar mejor las relaciones. A veces se
representa en forma de nodos de grafos y otras se complementa el clsico.

Ejemplo:

[4.2.3]esquemas relacionales derivados del modelo entidad/relacin

Hay quien los llama esquemas entidad/relacin relacionales por su similitud con
los esquemas entidad/relacin. Lo cierto es que intentan representar todo lo que los
esquemas conceptuales son capaces de representar y adaptarlo a las premisas del
Modelo Relacional.

Sin embargo la mayora no son capaces de representar lo mismo que el modelo

entidad/relacin de Chen, la razn estriba en que el modelo relacional no tiene
tantas formas de relacin. Por ello el modelo entidad/relacin debe de seguir siendo
una referencia que implicar crear restricciones apropiadas para reflejar la
profundidad de las relaciones del modelo conceptual.
notacin de patas de gallo

Quiz la forma ms popular en todo tipo de herramientas CASE para representar

esquemas relacionales es la notacin de patas de gallo (crows foot es el trmino
con el que se conoce en ingls) utilizado en diversas metodologas y herramientas
de trabajo como la notacin Barker1 (utilizada en gran medida por la propia
empresa Oracle), en la metodologa SSADM2, en la metodologa Information
Engineering (Ingeniera de la Informacin) y en otras metodologas y notaciones
formales. Adems est presente en la mayora de herramientas CASE.

De hecho es una mezcla entre los esquemas relacionales y los entidad/relacin.

Hoy en da se utiliza mucho, en especial por las herramientas CASE de creacin de
diseos de bases de datos.

En el diagrama anterior (Ilustracin 41) se puede examinar un modelo sencillo estilo

pata de gallo. En estos diagramas la cardinalidad mxima n se dibuja con las
famosas patas de gallo, la cardinalidad mnima de tipo cero con un crculo y la
cardinalidad de tipo uno con una barra vertical. El hecho de
que suministros y existencias tengan las esquinas redondeadas es para remarcar
que representan relaciones entre entidades (no siempre se remarca).

En cualquier caso tampoco hay un estndar unnimemente aceptado para este tipo
de notacin.

notacin de estilo Access

Se ha hecho muy popular la forma de presentar esquemas relacionales del
programa Microsoft Access, la cual se puede observar en la Ilustracin 42.

Es otra forma muy clara de representar relaciones y cardinalidades (aunque tiene

problemas para representar relaciones de dos o ms atributos como se observa en
la Ilustracin 42).

completando esquemas

Sin duda los esquemas ms completos son los que reflejan no slo las
cardinalidades sino tambin todas las restricciones (e incluso los tipos de datos,
aunque esto ya es una competencia del esquema interno). Vase el esquema de
la Ilustracin 43. En ese esquema los smbolos funcionan de esta forma:

Smbolo Ejemplo Significado

Subrayado DNI Clave principal
Subrayado discontinuo Clave2 Clave alternativa
Nombre No admite valores nulos

(restriccin NOT NULL)
Nombre
* No admite duplicados (restriccin UNIQUE)
*

Adems los campos que estn el final de una flecha son claves secundarias.
En el esquema anterior las flechas representan cardinalidades n y los crculos
cardinalidades de tipo cero. Las de tipo uno no tienen ningn smbolo asignado. A
este tipo de diagramas (los de flechas y ceros) se les llama diagramas en notacin
Bachman.

En muchas herramientas CASE, los diagramas relacionales suelen representar las

restricciones con letras. De hecho, esta notacin es la ms habitual actualmente
puesto que son las ms completas. Aunque visualmente ocupen ms espacio.

Ejemplo de notacin en pata de gallo con las restricciones usando abreviaturas:

En este caso los smbolos PK significan Primary Key (clave

principal), FK es Foreign Key (clave secundaria) UK (o simplemente
U) es Unique (unicidad) y CK es restriccin de validacin (check). Los nmeros
sirven para aclarar los atributos que forman parte de la restriccin. As sabemos que
en la tabla de prestamos, dni forma una clave fornea y n_copia otra distinta; y
que fecha_prestamo, dni y n_copia forman juntos una restriccin de unicidad.

[4.3] conversin de esquemas conceptuales entidad/relacin a esquemas

lgicos relacionales
[4.3.1]transformacin de las entidades fuertes
Como norma base, las entidades fuertes del modelo Entidad Relacin son
transformadas al modelo relacional siguiendo estas instrucciones:

Entidades. Las entidades pasan a ser tablas

Atributos. Los atributos pasan a ser columnas o atributos de la tabla.
Identificadores principales. Pasan a ser claves primarias.
Identificadores alternativos. Pasan a ser claves alternativas (tendrn
restricciones UNIQUE y NOT NULL.

En este esquema se explica de forma ms visual la transformacin

[4.3.2]transformacin de relaciones

Las relaciones no son tan sencillas de transformar. El modelo relacional no tiene la

capacidad de representar tantos tipos de relaciones como en el esquema
entidad/relacin.

Hay que diferenciar cada tipo de relacin. Por ello se estudian a continuacin todos
los casos

relaciones varios a varios

En las relaciones varios a varios (son aquellas que tienen n a n en la cardinalidad

mayor, la cardinalidad menor no cuenta para esta situacin), la relacin se
transforma en una tabla cuyos atributos son:

Los atributos de la relacin

Los atributos que son claves principales de las entidades relacionadas. Estos
atributos formarn (juntos) la clave principal de la nueva tabla y adems cada
 uno de ellos ser clave externa respecto a la tabla en la que son clave
principal.
Las cardinalidades mnimas se anotan en el nuevo diseo (aunque no
implican aadir ninguna relacin en las tablas)

Hay que tener cuidado con las cardinalidades mnimas. La razn, es que en el dibujo
final, lo que era una sola relacin se convierte en dos relaciones, ya que lo que se
indican en un diagrama relacional son las relaciones entre las tablas y ahora habr
tres tablas.

La tabla que representa la relacin contendr a su izquierda y derecha la nueva

cardinalidad.

Todos los casos se exponen a continuacin:

Relacin (1,n) a (1,n). Se convierte en dos relaciones (1,1) a (1,n)

Relacin (1,n) a (0,n). Se transforma en una relacin (1,1) a (1,n) y en otra

(1,1) a (0,n). Como en el entidad relacin las cardinalidades se colocan al
lado de las entidades y ahora se colocan en las tablas, habr que tener en
cuenta que ahora las cardinalidades se colocan ms cerca que antes, lo que
provoca que se crucen las cardinalidades.
 Se ve ms claro este efecto en el dibujo siguiente en el que se ha dibujado
una flecha morada sealado donde estaba antes la cardinalidad mnima de
cero y donde aparece ahora.

Relacin (0,n) a (0,n). Se convierte en dos relaciones (1,1) a (0,n)

relaciones de orden n
Las relaciones ternarias, cuaternarias y n-arias que unen ms de dos entidades, se
transforman en una tabla que contiene los atributos de la relacin, ms los
identificadores de las entidades relacionadas. La clave principal la forman todos los
identificadores juntos.

En este caso la cardinalidad mnima no vara en lo ms mnimo el resultado, aunque

s habra que tenerla en cuenta, su clculo es excesivamente complicado por lo que
no se interpreta en este manual (insistiendo en la escasa o inclusa nula influencia
que tienen en el esquema final).

relaciones uno a varios

Las relaciones binarias de tipo uno a varios (slo una cardinalidad mxima vale n)
no requieren ser transformadas en una tabla en el modelo relacional. En su lugar la
tabla del lado varios(tabla relacionada) incluye como clave externa3 el identificador
de la entidad del lado uno(tabla principal).
La cardinalidad mnima hay que revisarla bien ya que en caso de que la clave
externa se relacione obligatoriamente con la principal (cardinalidad mnima de uno),
habr que indicar una restriccin de tipo NOT NULL para indicar esa situacin.

Se describen todas las posibilidades de forma grfica.

relaciones uno a uno
En el caso de las relaciones entre dos entidades con todas las cardinalidades a 1;
hay dos posibilidades:

Colocar la clave de una de las entidades como clave externa de la otra tabla
(da igual cul), teniendo en cuenta que dicha clave ser clave
alternativa adems de ser clave secundaria.
Generar una nica tabla con todos los atributos de ambas entidades
colocando como clave principal cualquiera de las claves de las dos
entidades. La otra clave ser marcada como clave alternativa. El nombre de
la tabla sera el de la entidad ms importante desde el punto de vista
conceptual.

relaciones cero a uno

Se trata de relaciones entre dos entidades con cardinalidad mxima de 1 en ambas
direcciones, pero en una de ellas la cardinalidad mnima es 0. En este caso la
solucin difiere respecto a la anterior solucin. No conviene generar una nica tabla
ya que habra numerosos valores nulos en la tabla (debido a que hay ejemplares
que no se relacionan en las dos tablas).

La solucin pasa por generar dos tablas: una para cada entidad. En la tabla con
cardinalidad 0, se coloca como clave secundaria, la clave principal de la otra (dicha
clave secundaria ser, adems, clave alternativa de esa tabla):

relaciones cero a cero

En el caso de que en ambos extremos nos encontremos con relaciones 0 a 1,

entonces la solucin es la misma, pero la clave que se copia en la tabla para ser
clave secundaria, debe de ser tomada de la entidad que se relacione ms con la
otra (la que est ms cerca de tener la cardinalidad 1 a 1 en el otro extremo). Dicha
clave secundaria, en este caso, no ser clave alternativa (pero s tendr restriccin
de unicidad, ya que sus valores no se repiten).
La razn de este movimiento es cuanto ms cerca est del valor uno la
cardinalidad mnima, menos huecos vacos dejaremos en las tablas (base de datos,
por lo tanto, ms eficiente).

En la clave secundaria no se indica ninguna restriccin NOT NULL, ya que no todos

los datos se relacionan.

relaciones recursivas

Las relaciones recursivas se tratan de la misma forma que las otras, slo que hay
que imaginar que la tabla se divide en dos, una por cada rol. Teniendo en cuenta
eso, la solucin es idntica a lo ya resuelto en los casos anteriores slo que es una
sola tabla la participante.

Es fcil confundirse en este tipo de relaciones por lo que hay que imaginarse esta
situacin:
Visto de esa forma se trabaja como si la entidad en realidad fueran dos distintas (en
realidad no lo es), una por cada rol. De esa forma es ms fcil considerar la
transformacin.

El esquema completa de transformacin de relaciones recursivas es el siguiente:

Ilustracin 58. Exposicin de todas las posibles relaciones recursivas de tipo 1 a n
y n a n y su solucin al pasarle a un diagrama relacional

En el caso de las relaciones recursivas con cardinalidades mximas de 1 a 1 hay

que tomar ms precauciones, ya que es ms fcil equivocarse:

[4.3.3]entidades dbiles

Toda entidad dbil incorpora una relacin implcita con una entidad fuerte de tipo 1
a n. Por ello simplemente se pasa como tabla la entidad fuerte y la dbil, bastar
con aadir como atributo y clave fornea en la entidad dbil, el identificador de la
entidad fuerte.

En ocasiones el identificador de la entidad dbil tiene como parte de su identificador

al identificador de la entidad fuerte (por ejemplo si para identificar lneas de factura
utilizamos el nmero de lnea y el nmero de factura, clave de la entidad factura).
En esos casos no hace falta aadir de nuevo como clave externa el identificador de
la entidad fuerte.

El paso se expresa en el siguiente esquema:

[4.3.4]relaciones ISA

En el caso de las relaciones ISA, se siguen estas normas:

[1]Cada entidad de las relaciones ISA (sin importar si es super o subentidad) se

convierte en una tabla que contendr cada uno de los atributos de la entidad
(en el caso de que la ISA sea de tipo total, se podra incluso no hacer una tabla
para la superentidad y pasar todos sus atributos a sus subentidades, pero no
es recomendable porque dificulta el trabajo en la base de datos y adems
refleja peor este tipo de relacin).

[2]Si las subentidades no tienen clave propia, se colocar como clave, la clave de
su superentidad. Esta clave heredada ser clave externa (foreign key), adems
de clave principal.

[3]En el caso de que las subentidades tengan clave principal propia. Se colocar
en las subentidades el identificador de la superentidad como clave externa que
adems ser clave alternativa.

Ilustracin 62. Entidad dbil cuyo identificador contiene el de la entidad fuerte. En

este caso se usa esa columna como clave externa (no se requiere aadir de nuevo
el identificador de la tabla principal)

[4]Que la relacin ISA sea exclusiva o no, no cambia el esquema relacional, pero
s habr que tenerlo en cuenta para las restricciones futuras en el esquema
interno (casi siempre se realizan mediante triggers), ya que en las exclusivas
no puede haber repeticin de la clave de la superentidad en ninguna subentidad
(por ello si es posible se sigue dibujando el arco en este esquema).
 [5]No vara el resultado porque la relacin ISA sea total o parcial; el modelo
relacional no tiene capacidad para marcar esa posibilidad. Pero es interesante
tenerlo en cuenta (se suele aadir un comentario al diseo relacional para
posibles restricciones, nuevamente mediante triggers, a crear)

[4.3.5]notas finales

El modelo conceptual entidad/relacin es el verdadero mapa de la base de datos. Y

en todo momento hay que mantenerlo dentro de la documentacin de la base de
datos ya que refleja aspectos que, desgraciadamente, el modelo relacional no
puede.

Sin embargo el modelo relacional concreta aspectos de los datos muy importantes,
como son las restricciones. Tiene adems la virtud de que se entiende muy bien
(sigue siendo muy conceptual) ya que es ms simple

En definitiva ambos esquemas son fundamentales para todo profesional de la base

de datos; por ello muchas empresas utilizan un esquema hbrido relacional que
refleja tambin aspectos del modelo conceptual (la mayora de las herramientas
CASE llaman a esos esquemas, esquemas ERD (de Entity Relationship Diagram)
aunque son ms relacionales que conceptuales de tipo Entidad/Relacin).

Sin embargo, la costumbre actual es hacer directamente el esquema relacional. Eso

supone perder informacin y, adems, atarse a un modelo que, aunque sigue siendo
el ms popular con diferencia, empieza a tener serios rivales en las bases de datos
de tipo NoSQL.

1 Vase http://www.entitymodelling.org/
2Structured systems analysis and design method, Anlisis de sistemas estructurado
y mtodo de diseo
3 Clave externa, clave ajena, clave fornea, clave secundaria y foreign key son
sinnimos