UNIVERSIDAD AUTÓNOMA ESPAÑA

DE DURANGO

INGENIERIA TECNOLOGÍA Y SISTEMAS DE LA

INFORMACIÓN

QUINTO CUATRIMESTRE

BASE DE DATOS II

TRABAJO DE INVESTIGACIÓN BASE DE DATOS

RELACIONAL

CATEDRATICO; MTRO.JOSÉ RAMON CALLEJAS

FRANCO

ALUMNO; JESUS ABRAHAM FLORES FERNANDEZ

Durango dgo, 16 de junio del 2019
 2

Contenido
INTRODUCCIÓN ............................................................................................................. 3

BASES DE DATOS .......................................................................................................... 4

¿POR QUÉ INTERESA USAR UNA BASE DE DATOS? ..................................... 4

Modelos De BD ......................................................................................................... 6

ADMINISTRACIÓN DE BD .................................................................................... 7

Los Ficheros Tradicionales De Las BD ..................................................................... 9

OBJETIVOS DE LAS BASES DE DATOS RELACIONADAS ............................. 9

VISIÓN INFORMAL DE UNA RELACIÓN ......................................................... 10

VISIÓN FORMAL DE UNA RELACIÓN ............................................................. 11

DIFERENCIAS ENTRE RELACIONES Y FICHEROS ....................................... 12

CLAVE CANDIDATA, CLAVE PRIMARIA Y CLAVE ALTERNATIVA DE LAS

RELACIONES ............................................................................................................. 13

CLAVES FORÁNEAS DE LAS RELACIONES ................................................... 14

CONCLUSIONES ........................................................................................................... 16

Bibliografía ...................................................................................................................... 17
 3

INTRODUCCIÓN
Las bases de datos son parte esencial de cualquier sistema informático, puesto que todos
los programas necesitan recurrir a diversos datos mientras se ejecutan o generan otros que se
han de almacenar de forma fiable, sin contradicciones y a largo plazo. Esto es posible
en bases de datos (BD) estructuradas y gestionadas por sistemas de gestión de bases de datos
(SGBD), aplicaciones de software que interactúan con el usuario o con otros programas para
poner a su disposición un segmento de la información guardada en la base de datos.

El diseño de bases de datos tiene también un capítulo dedicado a aprender a modelar y

representar gráficamente una base de datos, a detectar los posibles problemas de diseño antes
de que éstos afecten a la aplicación, y a construir bases de datos óptimas para los distintos
casos de relaciones entre entidades que formarán nuestra base de datos.
 4

BASES DE DATOS

Entendemos como Base de Datos un conjunto de datos estructurado y almacenado de

forma sistemática con objeto de facilitar su posterior utilización. Una base de datos puede,
por tanto, constituirse con cualquier tipo de datos, incluyendo los de tipo puramente espacial
(geometrías, etc.) tales como los que se utilizan en un SIG, así como, por supuesto, datos
numéricos y alfanuméricos como los que constituyen la componente temática de la
información geoespacial. Los elementos clave de la base de datos son esa estructuración y
sistematicidad, pues ambas son las responsables de las características que hacen de la base
de datos un enfoque superior a la hora de gestionar datos.

• Una base de datos de un SI es la representación integrada de los conjuntos de

entidades instancia correspondientes a las diferentes entidades tipo del SI y de sus
interrelaciones. Esta representación informática (o conjunto estructurado de datos)
debe poder ser utilizada de forma compartida por muchos usuarios de distintos
tipos.

Cada aplicación (una o varias cadenas de programas) utilizaba ficheros de movimientos

para actualizar (creando una copia nueva) y/o para consultar uno o dos ficheros maestros o,
excepcionalmente, más de dos. Cada programa trataba como máximo un fichero maestro,
que solía estar sobre cinta magnética y, en consecuencia, se trabajaba con acceso secuencial.
Cada vez que se le quería añadir una aplicación que requería el uso de algunos de los datos
que ya existían y de otros nuevos, se diseñaba un fichero nuevo con todos los datos necesarios
(algo que provocaba redundancia) para evitar que los programas tuviesen que leer muchos
ficheros. A medida que se fueron introduciendo las líneas de comunicación, los terminales y
los discos, se fueron escribiendo programas que permitían a varios usuarios consultar los
mismos ficheros on-line y de forma simultánea. Más adelante fue surgiendo la necesidad de
hacer las actualizaciones también on-line.

¿POR QUÉ INTERESA USAR UNA BASE DE DATOS?

• Mayor independencia. Los datos son independientes de las aplicaciones que los
usan, así como de los usuarios.
 5

• Mayor disponibilidad. Se facilita el acceso a los datos desde contextos, aplicaciones

y medios distintos, haciéndolos útiles para un mayor número de usuarios.

• Mayor seguridad (protección de los datos). Por ejemplo, resulta más fácil replicar
una base de datos para mantener una copia de seguridad que hacerlo con un conjunto
de ficheros almacenados de forma no estructurada. Además, al estar centralizado el
acceso a los datos, existe una verdadera sincronización de todo el trabajo que se haya
podido hacer sobre estos (modificaciones), con lo que esa copia de seguridad servirá
a todos los usuarios.

• Menor redundancia. Un mismo dato no se encuentra almacenado en múltiples

ficheros o con múltiples esquemas distintos, sino en una única instancia en la base de
datos. Esto redunda en menor volumen de datos y mayor rapidez de acceso.

• Mayor eficiencia en la captura, codificación y entrada de datos.

Esto tiene una consecuencia directa sobre los resultados que se obtienen de la explotación
de la base de datos, presentándose al respecto ventajas como, por ejemplo:

• Mayor coherencia. La mayor calidad de los datos que se deriva de su mejor gestión
deriva en mayor calidad de los resultados.
• Mayor eficiencia. Facilitando el acceso a los datos y haciendo más sencilla su
explotación, la obtención de resultados es más eficiente.
• Mayor eficiencia. Facilitando el acceso a los datos y haciendo más sencilla su
explotación, la obtención de resultados es más eficiente.

Por último, los usuarios de la base de datos también obtienen ventajas al trabajar con
estas, entre los que cabe citar:

• Mayor facilidad y sencillez de acceso. El usuario de la base de datos se debe

preocupar únicamente de usar los datos, disponiendo para ello de las
herramientas adecuadas y de una estructura sólida sobre la que apoyarse.

• Facilidad para reutilización de datos. Esto es, facilidad para compartir.

 6

Modelos De BD

Una BD es una representación de la realidad (de la parte de la realidad que nos interesa
en nuestro SI). Dicho de otro modo, una BD se puede considerar un modelo de la realidad.
El componente fundamental utilizado para modelar en un SGBD relacional son las tablas
(denominadas relaciones en el mundo teórico). Sin embargo, en otros tipos de SGBD se
utilizan otros componentes.

Todo modelo de BD nos proporciona tres tipos de herramientas;

1. Estructuras de datos con las que se puede construir la BD: tablas, árboles, etc.
2. Diferentes tipos de restricciones (o reglas) de integridad que el SGBD tendrá que
hacer cumplir a los datos: dominios, claves, etc.
3. Una serie de operaciones para trabajar con los datos. Un ejemplo de ello, en el
modelo relacional, es la operación SELECT, que sirve para seleccionar (o leer) las
filas que cumplen alguna condición. Un ejemplo de operación típica del modelo
jerárquico y del modelo en red podría ser la que nos dice si un determinado registro
tiene “hijos” o no.

A principios de los setenta surgieron SGBD basados en un modelo en red. Como en el

modelo jerárquico, hay registros e interrelaciones, pero un registro ya no está limitado a ser
“hijo” de un solo registro tipo. El comité CODASYLDBTG propuso un estándar basado en

este modelo, que fue adoptado por muchos constructores de SGBD*. Sin embargo, encontró
 7

la oposición de IBM, la empresa entonces dominante. La propuesta de CODASYL-DBTG

ya definía tres niveles de esquemas.

Así como en los modelos prerracionales (jerárquico y en red), las estructuras de datos
constan de dos elementos básicos (los registros y las interrelaciones), en el modelo relacional
constan de un solo elemento: la tabla, formada por filas y columnas. Las interrelaciones se
deben modelizar utilizando las tablas. Otra diferencia importante entre los modelos
prerracionales y el modelo relacional es que el modelo relacional se limita al nivel lógico (no
hace absolutamente ninguna consideración sobre las representaciones físicas). Es decir, nos
da una independencia física de datos total. Esto es así si hablamos del modelo teórico, pero
los SGBD del mercado nos proporcionan una independencia limitada. Estos últimos años se
está extendiendo el modelo de BD relacional con objetos. Se trata de ampliar el modelo
relacional, añadiéndole la posibilidad de que los tipos de datos sean tipos abstractos de datos,
TAD. Esto acerca los sistemas relacionales al paradigma de la OO.

ADMINISTRACIÓN DE BD
Los administradores de BD son los responsables del correcto funcionamiento de la BD y
velan para que siempre se mantenga útil. Intervienen en situaciones problemáticas o de
emergencia, pero su responsabilidad fundamental es velar para que no se produzcan
incidentes. Una empresa o institución que tenga SI construidos en torno a BD necesita que
alguien lleve a cabo una serie de funciones centralizadas de gestión y administración, para
asegurar que la explotación de la BD es la correcta. Este conjunto de funciones se conoce
con el nombre de administración de BD (ABD), y los usuarios que hacen este tipo especial
de trabajo se denominan administradores de BD.

Lista de tareas típicas del ABD (Administrador de bases de datos);

1. Mantenimiento, administración y control de los esquemas. Comunicación de los

cambios de usuarios.
2. Asegurar la máxima disponibilidad de los datos; por ejemplo; haciendo copias
(back-ups), administrando diarios de los datos (journals o logs), reconstruyendo
las bases de datos etc.
3. Resolución de emergencias.
4. Vigilancia de la integridad y calidad de los datos.
 8

5. Diseño físico, estrategia de caminos de acceso y restructuraciones.

6. Control rendimiento y decisiones relativas a las modificaciones en los esquemas
y/o en los parámetros de SGBD y del SO, para mejorarlo.

BASES DE DATOS RELACIONADAS

El estudio del modelo relacional sirve, además, de base para los contenidos de otra unidad,
dedicada al lenguaje SQL. Este lenguaje permite definir y manipular bases de datos
relacionales. Los fundamentos del modelo relacional resultan imprescindibles para conseguir
un buen dominio del SQL.

A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros
y fue necesario eliminar la redundancia. El nuevo conjunto de ficheros se debía diseñar de
modo que estuviesen interrelacionados; al mismo tiempo, las informaciones redundantes
(como, por ejemplo, el nombre y la dirección de los clientes o el nombre y el precio de los
productos), que figuraban en los ficheros de más de una de las aplicaciones, debían estar
ahora en un solo lugar.

El acceso on-line y la utilización eficiente de las interrelaciones exigían estructuras físicas

que diesen un acceso rápido, como por ejemplo los índices, las multilistas, las técnicas de
hashing, etc. Estos conjuntos de ficheros interrelacionados, con estructuras complejas y
compartidos por varios procesos de forma simultánea (unos on-line y otros por lotes),
recibieron al principio el nombre de Data Banks, y después, a inicios de los años setenta, el
de Data Bases. Aquí los denominamos bases de datos (BD). El software de gestión de
ficheros era demasiado elemental para dar satisfacción a todas estas necesidades. Por
ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible que varios
usuarios actualizaran datos simultáneamente, etc. La utilización de estos conjuntos de
ficheros por parte de los programas de aplicación era excesivamente compleja, de modo que,
especialmente durante la segunda mitad de los años setenta.

• En otras palabras, una base de datos es un conjunto estructurado de datos que

representa entidades y sus interrelaciones. La representación será única e
integrada, a pesar de que debe permitir utilizaciones varias y simultáneas.
 9

Los Ficheros Tradicionales De Las BD

Aunque de forma muy simplificada, podríamos enumerar las principales diferencias entre
los ficheros tradicionales y las BD tal y como se indica a continuación:

1) Entidades tipos:

• Ficheros: tienen registros de una sola entidad tipo.

• BD: tienen datos de varias entidades tipo.

2) Interrelaciones:

• Ficheros: el sistema no interrelaciona ficheros.

• BD: el sistema tiene previstas herramientas para interrelacionar entidades.

3) Redundancia:

• Ficheros: se crean ficheros a la medida de cada aplicación, con todos los datos
necesarios, aunque algunos sean redundantes respecto de otros ficheros.
• BD: todas las aplicaciones trabajan con la mismo BD y la integración de los
datos es básica, de modo que se evita la redundancia.

4) Usuarios

• Ficheros: sirven para un solo usuario o una sola aplicación. Dan una sola
visión del mundo real.
• BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias
visiones del mundo real.

OBJETIVOS DE LAS BASES DE DATOS RELACIONADAS

• Conocer los fundamentos del modelo de datos relacional.

• Saber distinguir las características que debe tener un sistema de gestión de bases
de datos relacional para que sea coherente con los fundamentos del modelo
relacional.
 10

• Comprender las ventajas del modelo relacional que derivan del alto grado de
independencia de los datos que proporciona, y de la simplicidad y la uniformidad
del modelo.
• Conocer las operaciones del álgebra relacional.
• Saber utilizar las operaciones del álgebra relacional para consultar una base de
datos.

El principal objetivo del modelo de datos relacional es facilitar que la base de datos sea
percibida o vista por el usuario como una estructura lógica que consiste en un conjunto de
relaciones y no como una estructura física de implementación. Esto ayuda a conseguir un
alto grado de independencia de los datos. Un objetivo adicional del modelo es conseguir que
esta estructura lógica con la que se percibe la base de datos sea simple y uniforme. Con el fin
de proporcionar simplicidad y uniformidad, toda la información se representa de una única
manera: mediante valores explícitos que contienen las relaciones (no se utilizan conceptos
como por ejemplo apuntadores entre las relaciones). Con el mismo propósito, todos los
valores de datos se consideran atómicos; es decir, no es posible descomponerlos.

VISIÓN INFORMAL DE UNA RELACIÓN

En primer lugar, presentaremos el concepto de relación de manera informal. Se puede
obtener una buena idea intuitiva de lo que es una relación si la visualizamos como una tabla
un fichero. En la figura 1 se muestra la visualización tabular de una relación que contiene
datos de empleados.
 11

Cada fila de la tabla contiene una colección de valores de datos relacionados entre sí; en
nuestro ejemplo, son los datos correspondientes a un mismo empleado. La tabla tiene un
nombre (EMPLEADOS) y también tiene un nombre cada una de sus columnas (DNI,
nombre, apellido y sueldo). El nombre de la tabla y los de las columnas ayudan a entender el
significado de los valores que contiene la tabla. Cada columna contiene valores de un cierto
dominio; por ejemplo, la columna DNI contiene valores del dominio números DNI. Si
definimos las relaciones de forma más precisa, nos daremos cuenta de que presentan algunas
características importantes que, en la visión superficial que hemos presentado, quedan
ocultas. Estas características son las que motivan que el concepto de relación sea totalmente
diferente del de fichero, a pesar de que, a primera vista, relaciones y ficheros puedan parecer
similares.

VISIÓN FORMAL DE UNA RELACIÓN

A continuación, definimos formalmente las relaciones y otros conceptos que están
vinculados a ellas, como por ejemplo dominio, esquema de relación, etc.

Un dominio D es un conjunto de valores atómicos. Por lo que respecta al modelo

relacional, atómico significa indivisible; es decir, que por muy complejo o largo que sea un
valor atómico, no tiene una estructuración interna para un SGBD relacional. Existen tres tipos
de dominio;

1. Dominios predefinidos, que corresponde a los tipos de datos que normalmente

proporcionan los lenguajes de bases de datos, como por ejemplo los enteros, las
cadenas de caracteres, los reales, etc.

2. Dominios definidos por el usuario, que pueden ser más específicos. Toda
definición de un dominio debe constar, como mínimo, del nombre del dominio y
de la descripción de los valores que forman parte de éste.

Una relación se compone del esquema (o intensión de la relación) y de la extensión.

 12

Si consideramos la representación tabular anterior (figura 1), el esquema correspondería

a la cabecera de la tabla y la extensión correspondería al cuerpo:

El esquema de la relación consiste en un nombre de relación R y un conjunto de atributos

{A1, A2, ..., An}.

DIFERENCIAS ENTRE RELACIONES Y FICHEROS

A primera vista, relaciones y ficheros resultan similares. Los registros y los campos que
forman los ficheros se parecen a las tuplas y a los atributos de las relaciones, respectivamente.
A pesar de esta similitud superficial, la visión formal de relación que hemos presentado
establece algunas características de las relaciones que las hacen diferentes de los ficheros
clásicos. A continuación, describimos estas características;

• Atomicidad de los valores de los atributos: los valores de los atributos de una
relación deben ser atómicos; es decir, no deben tener estructura interna. Esta
característica proviene del hecho de que los atributos siempre deben tomar un valor
de su dominio o bien un valor nulo, y de que se ha establecido que los valores de
los dominios deben ser atómicos en el modelo relacional.

El objetivo de la atomicidad de los valores es dar simplicidad y uniformidad al modelo

relacional.

• No-repetición de las tuplas: en un fichero clásico puede ocurrir que dos de los
registros sean exactamente iguales; es decir, que contengan los mismos datos. En
el caso del modelo relacional, en cambio, no es posible que una relación contenga
tuplas repetidas. Esta característica se deduce de la misma definición de la
 13

extensión de una relación. La extensión es un conjunto de tuplas y, en un conjunto,

no puede haber elementos repetidos.
• No-ordenación de las tuplas: de la definición de la extensión de una relación
como un conjunto de tuplas se deduce también que estas tuplas no estarán
ordenadas, teniendo en cuenta que no es posible que haya una ordenación entre los
elementos de un conjunto

La finalidad de esta característica es conseguir que, mediante el modelo relacional, se

puedan representar los hechos en un nivel abstracto que sea independiente de su estructura
física de implementación. Más concretamente, aunque los SGBD relacionales deban
proporcionar una implementación física que almacenará las tuplas de las relaciones en un
orden concreto, esta ordenación no es visible si nos situamos en el nivel conceptual.

• No-ordenación de los atributos: el esquema de una relación consta de un nombre

de relación R y un conjunto de atributos {A1, A2, ..., An}. Así pues, no hay un
orden entre los atributos de un esquema de relación, teniendo en cuenta que estos
atributos forman un conjunto.

CLAVE CANDIDATA, CLAVE PRIMARIA Y CLAVE ALTERNATIVA DE LAS

RELACIONES
Toda la información que contiene una base de datos debe poderse identificar de alguna
forma. En el caso particular de las bases de datos que siguen el modelo relacional, para
identificar los datos que la base de datos contiene, se pueden utilizar las claves candidatas de
las relaciones. A continuación, definimos qué se entiende por clave candidata, clave primaria
y clave alternativa de una relación. Para hacerlo, será necesario definir el concepto de
superclase.

1. Una superclave de una relación de esquema R (A1, A2, ..., An) es un subconjunto
de los atributos del esquema tal que no puede haber dos tuplas en la extensión de
la relación que tengan la misma combinación de valores para los atributos del
subconjunto.
2. Una clave candidata de una relación es una superclave C de la relación que cumple
que ningún subconjunto propio de C es superclave.
 14

Habitualmente, una de las claves candidatas de una relación se designa clave primaria de
la relación. La clave primaria es la clave candidata cuyos valores se utilizarán para identificar
las tuplas de la relación.

• El diseñador de la base de datos es quien elige la clave primaria de entre las claves
candidatas.
• Las claves candidatas no elegidas como primaria se denominan claves alternativas.

CLAVES FORÁNEAS DE LAS RELACIONES

Las claves foráneas permiten establecer conexiones entre las tuplas de las relaciones. Para
hacer la conexión, una clave foránea tiene el conjunto de atributos de una relación que
referencian la clave primaria de otra relación (o incluso de la misma relación).

Las claves foráneas tienen por objetivo establecer una conexión con la clave primaria que
referencian. Por lo tanto, los valores de una clave foránea deben estar presentes en la clave
primaria correspondiente, o bien deben ser valores nulos. En caso contrario, la clave foránea
representaría una referencia o conexión incorrecta.
15
 16

CONCLUSIONES
Los aspectos más relevantes del modelo relacional que hemos descrito son los siguientes:
En lo que respecta a la estructura de los datos: Consiste en un conjunto de relaciones. Una
relación permite almacenar datos relacionados entre sí. La clave primaria de una relación
permite identificar sus datos. Las claves foráneas de las relaciones permiten referenciar
claves primarias y, de este modo, establecer conexiones entre los datos de las relaciones.

En lo que respecta a la integridad de los datos: La regla de integridad de unicidad y de

entidad de la clave primaria: las claves primarias no pueden contener valores repetidos ni
valores nulos. La regla de integridad referencial: los valores de las claves foráneas deben
existir en la clave primaria referenciada o bien deben ser valores nulos. La regla de integridad
de dominio: los valores no nulos de un atributo deben pertenecer al dominio del atributo, y
los operadores que es posible aplicar sobre los valores dependen de los dominios de estos
valores.
 17

Bibliografía
Date, C. (2001). Introducción a los sistemas de bases de datos (7°ed.). Prentice Hall.

Silberschatz, A., Korth, H., & Sudarshan, S. (1998). Fundamentos de bases de datos (3.a
ed.). Madrid: McGraw-Hill.

Documentación de PHP: http://www.php.net/docs.php

PEAR :: The PHP Extension and Application Repository: http://pear.php.net/

Pear::DB Database Abstraction Layer: http://pear.php.net/package/DB