PDF de programación - Tema 1. Introducción - Ficheros y Bases de Datos

Tema 1. Introducción

Ficheros y Bases de Datos

17 de abril de 2002

1.

Introducción

Este documento contiene preguntas del tema 1 recogidas por estudiantes de la asignatura
(Elisa Ortíz López, Laura Pedregosa Valverde y Ernesto Cervera Capdevila) y que han sido
contestadas por el profesorado. En ocasiones, las respuestas son bastante extensas y aportan
información, sobre todo ejemplos, que no se han utilizado en las clases de teoría y que
tampoco aparecen en los apuntes. Esto se ha hecho para intentar responder de un modo más
claro a estas preguntas y, por lo tanto, no son conceptos que se añadan al temario de la
asignatura (no se podrán preguntar en los exámenes).

2. Preguntas y respuestas

2.1.

¿Qué problemas plantean los sistemas de ficheros?

Duplicidad de datos, puesto que, distintos departamentos de una institución pueden
tener los mismos datos en distintos sistemas de ficheros. Este hecho también conlleva
la Separación y aislamiento de datos entre unas aplicaciones y otras.

Problemas de integridad de datos, es decir, pueden haber copias de un mismo dato en
el mismo sistema de ficheros que no coinciden. Por ejemplo, tenemos la dirección de
una misma persona almacenada en dos ficheros distintos y ésta no coincide.
La integridad la deben controlar las aplicaciones puesto que no pueden almacenar reglas
de integridad. Debido a la redundancia de datos al realizar actualizaciones (modifica-
ciones o borrados) puede que se actualice un dato en algún fichero y no en otros.

Dificultad para procesar consultas, puesto que se debe diseñar una aplicación específi-
ca para cada una que se quiera realizar. Esto conlleva la Proliferación de programas
de aplicación que acaba desbordando generalmente al departamento encargado de re-
alizarlas.

1

Problema de consistencia de datos, es decir, datos del mismo tipo almacenados con
formatos distintos. Por ejemplo, guardamos varias veces el teléfono unas veces con
prefijo y otras sin él, con guiones o sin ellos, . . . .

Formatos de ficheros incompatibles, por estar realizadas las aplicaciones en distintos
lenguajes de programación, por estar definidos los datos con diferentes formatos tal y
como se comenta en el anterior punto, . . . .

Falta de independencia de datos(lógica-física), es decir, que las aplicaciones dependen
del tipo de datos que manejan. Una modificación en la definición de los datos obliga
a modificar las aplicaciones que trabajan con los datos modificados (e incluso muchas
de las que trabajan con otros datos).

2.2.

¿Cuáles son las ventajas de los Sistemas de Bases de Datos (SBD)?

Las ventajas de los SBD se obtienen por dos motivos: por la integración de datos y por

la existencia del Sistema Gestor de Bases de Datos (SGBD).

Por la integración de datos:

Existe una menor redundancia de datos, lo cual facilita mantener la integridad de la
BD y permite utilizar menos espacio en disco, cosa especialmente importante cuando
se está trabajando con BD de cientos de miles o millones de registros.
Por otro lado, de esta forma se evitan los problemas de consistencia de datos ya que
normalmente sólo aparecerán una vez en la BD.

Se puede extraer información estadística sobre los datos y las relaciones entre ellos.

Se pueden compartir los datos entre distintas aplicaciones y departamentos.

Se facilita el mantenimiento de los estándares.

Por la existencia del Sistema Gestor de Bases de Datos:

Se reduce el problema de la integridad, puesto que se pueden definir reglas que el SGBD
se encargará de mantener.

Se mejora la seguridad de la Base de Datos, ya que existen diferentes tipos de usuarios
que se deben identificar para poder acceder a la Base de Datos y sobre los que se
pueden definir distintos tipos de permisos (acceso, modificación, borrado, . . . ).

Se pueden realizar consultas de datos simples sin tener que escribir el programa, por
ejemplo mediante sentencias de SQL o QBE (Query By Example).

2

Se mejora la productividad de los programadores, puesto que hay que realizar muchas
menos comprobaciones al hacer actualizaciones de datos.

Proporciona independencia de datos lógica-física, lo cual permite realizar modifica-
ciones en la Base de Datos y en las aplicaciones de un modo mucho más sencillo.

Se aumenta la concurrencia, es decir, el acceso simultaneo de varios usuarios a la Base
de Datos.

Mejora los servicios de copias de seguridad y de recuperación de los datos mediante
aplicaciones propias del SGBD.

2.3. Una de las ventajas de la existencia del SGBD es la reducción del
problema de integridad de datos ¿qué es exactamente la integridad
de datos?

Cuando se almacenan datos, bien sea en un sistema de ficheros o en un sistema de bases
de datos, se pretende que estos datos siempre reflejen la realidad. Por ejemplo, todos los
contratos de alquiler deben ser de inmuebles conocidos (cuyos datos están almacenados en
el sistema) y de clientes conocidos; si se almacenan varias copias de los datos de los clientes,
todas las copias deben coincidir. En un determinado momento, los datos almacenados pueden
ser correctos y que el usuario realice una operación que los lleve a un estado en el que se viola
la integridad: por ejemplo, cuando se borran los datos de un inmueble que tiene contratos de
alquiler: los datos del inmueble ya no están en la base de datos, y los contratos permanencen,
por lo que tenemos contratos de inmuebles que no sabemos en qué calle están ni quién es
su propietario. En los sistemas de ficheros son los programas de aplicación quienes se deben
encargar de mantener la integridad de los datos. Sin embargo, en los SGBD es el propio
sistema el que se encarga de mantener la integridad. Para ello, cuando se crea la base de
datos, se dispone de unas directivas que permiten especificar reglas de integridad. El SGBD
se encargará de hacer que se respeten.

Por ejemplo, para la inmobiliaria se creará una tabla de inmuebles y una tabla de con-
tratos. En la creación de la tabla de contratos se especifica mediante la cláusula CONSTRAINT
que inum es una clave ajena (FOREIGN KEY) a la tabla de inmuebles y que la regla de com-
portamiento es “propagar el borrado” (ON DELETE CASCADES):

CREATE TABLE contratos

(

cnum VARCHAR(5) NOT NULL,
inum VARCHAR(4) NOT NULL,
...,
CONSTRAINT contratos pk PRIMARY KEY (cnum),
CONSTRAINT contratos fk inum FOREIGN KEY (inum)

REFERENCES inmuebles ON DELETE CASCADE

3

);

Nótese que a cada restricción (CONSTRAINT) se le da un nombre que servirá para registrarla
en el diccionario de datos. A partir de este momento, siempre que se borre un inmueble
que tenga contratos, se borrarán todos los contratos de dicho inmueble. Otra posibilidad
es escoger “restringir el borrado”: de este modo sólo será posible borrar inmuebles que no
tengan ningún contrato almacenado. Es siempre el propietario de la información quien debe
indicar cuál es el comportamiento deseado.

2.4.

¿Qué es un SGBD?

El SGBD es una aplicación que permite a los usuarios definir , crear y mantener la base

de datos y proporciona un acceso controlado a la misma.

El acceso a los datos se realiza siempre a través de él. De esta forma:

garantiza independencia lógica-física.

disminuye la redundancia de datos.

mantiene la integridad y consistencia de los datos.

permite el acceso concurrente a los datos

. . .

todo ello de modo transparente a los usuarios y a las aplicaciones, es decir, estos no se

han de preocupar de todos esos aspectos.

2.5. En un SGBD, como por ejemplo, el de la empresa inmobiliaria ¿po-
drías explicar algún ejemplo de reglas o restricciones de integridad
para algunos datos de dicha empresa?

En el ejemplo de la pregunta anterior se está considerando una regla de integridad general
a todas las bases de datos relacionales: la regla de integridad referencial (mantenida gracias
a las claves ajenas). Otros ejemplos de reglas de integridad, esta vez de reglas específicas
de la base de datos de la inmobiliaria, pueden ser: que el identificador del inmueble debe
comenzar por la letra I, que cada inmueble debe tener al menos una habitación y que el tipo
del inmueble sólo puede ser piso, casa o bajo. Para ello, en la sentencia de creación de la
tabla inmueble especificaríamos estas reglas mediante restricciones CHECK:

4

CREATE TABLE inmuebles

(

inum VARCHAR(4) NOT NULL,
tipo VARCHAR(10) NOT NULL,
hab NUMBER(2) NOT NULL,
...,
CONSTRAINT inmuebles pk PRIMARY KEY (inum),
CONSTRAINT inmuebles ck inum CHECK (SUBSTR(inum,1,1)=’I’),
CONSTRAINT inmuebles ck tipo CHECK (tipo IN (’casa’,’piso’,’bajo’)),
CONSTRAINT inmuebles ck hab CHECK (hab >0)

) ;

2.6.

¿Cual ha sido la evolución de los SBD?

Los SBD se pueden dividir en tres generaciones :

La primera generación en la que se utilizaba los sistema jerárquico y más tarde los
sistemas de red. Se basaban en definir los registros y las relaciones entre ellos utilizando
punteros físicos. Requerían complejos programas de aplicación.

En La segunda generación se utiliza el modelo relacional que utiliza tablas para rep-
resentar los datos. Esta basado en un modelo teórico y ha sido el más utilizado en los
últimos años.

La tercera generación incluye los modelo orientados a objetos y modelos relacionales
extendidos. Ambos utilizan las ventajas de la metodología orientada a objetos.

2.7.

¿Cuáles son los problemas de los SBD de la primera generación?

Cabe destacar tres que son bastante importantes:

Requieren complejos programas de aplicación, puesto que deben acceder a la estructura
de punteros de la Base de Datos.

La independencia de datos es mínima, las aplicaciones dependen fuertemente de la
estructura de la Base de Datos.

No tienen un fundamento teórico que avale su comportamiento.

5

2.8.

¿Qué es el diseño lógico?

El diseño de una base de datos se realiza en tres fases: diseño conceptual, diseño lógico
y diseño físico. En el diseño conceptual el objetivo es obtener un esquema (normalmente
representado mediante el m