UNIDAD I. FUNDAMENTOS DE BASES DE DATOS 1.1 Conceptos

UNIDAD I. FUNDAMENTOS DE BASES DE DATOS
1.1 Conceptos Básicos
1.1.1 Definición
Colección organizada de datos, relativa a un problema concreto, que puede ser compartida por un
conjunto de usuarios/aplicaciones.
1.1.2
Historia
Las aplicaciones informáticas de los años sesenta acostumbraban a darse totalmente por lotes
(batch) y estaban pensadas para una tarea muy específica relacionada con muy pocas entidades
tipo.
A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros y fue
necesario eliminar la redundancia. El nuevo conjunto de fi- cheros 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 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,
especial- mente durante la segunda mitad de los años setenta, fue saliendo al mercado software
más sofisticado: los Data Base Management Systems, que aquí denominamos sistemas de gestión
de BD (SGBD).
Los SGBD de los años sesenta y setenta (IMS de IBM, IDS de Bull, DMS de Univac, etc.) eran sistemas
totalmente centralizados, como corresponde a los sistemas operativos de aquellos años, y al
hardware para el que estaban hechos: un gran ordenador para toda la empresa y una red de
terminales sin inteligencia ni memoria.
Los primeros SGBD –en los años sesenta todavía no se les denominaba así– estaban orientados a
facilitar la utilización de grandes conjuntos de datos en los que las interrelaciones eran complejas.
El arquetipo de aplicación era el Bill of materials o Parts explosion, típica en las industrias del
automóvil, en la construcción de naves espaciales y en campos similares. Estos sistemas trabajaban
exclusivamente por lotes (batch).
Los ordenadores minis, en primer lugar, y después los ordenadores micros, extendieron la
informática a prácticamente todas las empresas e instituciones.
Esto exigía que el desarrollo de aplicaciones fuese más sencillo. Los SGBD de los años setenta eran
demasiado complejos e inflexibles, y sólo los podía utilizar un personal muy cualificado.
La aparición de los SGBD relacionales supone un avance importante para facilitar la programación
de aplicaciones con BD y para conseguir que los programas sean independientes de los aspectos
físicos de la BD.
Todos estos factores hacen que se extienda el uso de los SGBD. La estandarización, en el año 1986,
del lenguaje SQL produjo una auténtica explosión de los SGBD relacionales.
Al acabar la década de los ochenta, los SGBD relacionales ya se utilizaban prácticamente en todas
las empresas.
A finales de los ochenta y principios de los noventa, las empresas se han encontrado con el hecho
de que sus departamentos han ido comprando ordenadores departamentales y personales, y han
ido haciendo aplicaciones con BD. El resultado ha sido que en el seno de la empresa hay numerosas
BD y varios SGBD de diferentes tipos o proveedores. Este fenómeno de multiplicación de las BD y
de los SGBD se ha visto incrementado por la fiebre de las fusiones de empresas.
La necesidad de tener una visión global de la empresa y de interrelacionar diferentes aplicaciones
que utilizan BD diferentes, junto con la facilidad que dan las redes para la intercomunicación entre
ordenadores, ha conducido a los SGBD actuales, que permiten que un programa pueda trabajar con
diferentes BD como si se tratase de una sola. Es lo que se conoce como base de datos distribuida.
1.1.3 Tipos de Modelos
a) Jerárquico
Una base de datos jerárquica es un tipo de sistema de gestión de bases de datos que almacenan
la información en una estructura jerárquica que enlaza los registros en forma de estructura de
árbol en donde un nodo padre de información puede tener varios nodos hijo. De la misma
manera se puede establecer relación entre los nodos hermanos En este caso la estructura en
forma de árbol se convierte en una estructura en forma de grafo dirigido.
El modelo jerárquico se clasifica en estructuras lineales y arborescentes. La primera clase de
estructura, cada tipo de registro padre sólo puede tener un tipo de registro hijo. La segunda, un
tipo de registro padre puede tener varios tipos de registros hijos. El producto comercial de tipo
Jerárquico más extendido y el único que ha llegado hasta nuestros días es el IMS de IBM
El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del
modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En
justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un
empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero
no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos
hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial
por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de
un departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea
Una de las principales limitaciones de este modelo es su incapacidad de representar
eficientemente la redundancia de datos. De la misma manera, otra limitación es, no garantiza
la inexistencia de registros duplicados. Esto también es cierto para los campos “clave”. Es decir,
no se garantiza que dos registros cualesquiera tengan diferentes valores
b)
Red
Este modelo representa los datos mediante colecciones de registros y sus relaciones se
representan por medio de ligas o enlaces, los cuales pueden verse como punteros. Los registros
se organizan en un conjunto de gráficas arbitrarias.
c) Relacional
Durante los años ochenta apareció una gran cantidad de SGBD basados en el modelo relacional
propuesto en 1969 por E.F. Codd, de IBM, y prácticamente todos utilizaban como lenguaje
nativo el SQL. El modelo relacional se basa en el concepto matemático de relación, que aquí
podemos considerar de momento equivalente al término tabla (formada por filas y columnas).
La mayor parte de los SI que actualmente están en funcionamiento utilizan SGBD relacionales,
pero algunos siguen utilizando los jerárquicos o en red (especialmente en SI antiguos muy
grandes).
d) Orientada a Objetos
Las Bases de datos orientados a objetos se propusieron con la idea de satisfacer las necesidades de
las aplicaciones más complejas. El enfoque orientado a objetos ofrece la flexibilidad para cumplir
con algunos de estos requerimientos sin estar limitado por los tipos de datos y los lenguajes de
consulta disponibles en los sistemas de bases de datos tradicionales.
Como cualquier Bases de Datos programable, una Base de Datos Orientada a Objetos (BDOO)
proporciona un ambiente para el desarrollo de aplicaciones y un depósito persistente listo para su
explotación. Una BDOO almacena y manipula información que puede ser digitalizada (presentada)
como objetos, además proporciona un acceso ágil y permite una gran capacidad de manipulación.
e) Documental
Una base de datos documental está constituida por un conjunto de programas que almacenan,
recuperan y gestionan datos de documentos o datos de algún modo estructurados. Este tipo de
bases de datos constituyen una de las principales subcategorías dentro de las denominadas bases
de datos no SQL. A diferencia de las bases de datos relacionales, estas bases de datos están
diseñadas alrededor de una noción abstracta de "Documento".
1.1.4

Actores
Administrador de la base de datos: se encarga del diseño físico de la base de datos y de
su implementación, realiza el control de la seguridad y de la concurrencia, mantiene el
sistema para que siempre se encuentre operativo y se encarga de que los usuarios y las
aplicaciones obtengan buenas prestaciones. El administrador debe conocer muy bien el

SGBD que se esté utilizando, así como el equipo informático sobre el que esté
funcionando.
Diseñadores de la base de datos: realizan el diseño lógico de la base de datos, debiendo
identificar los datos, las relaciones entre datos y las restricciones sobre los datos y sus
relaciones. El diseñador de la base de datos debe tener un profundo conocimiento de
los datos de la empresa y también debe conocer sus reglas de negocio. Las reglas de
negocio describen las características principales de los datos tal y como las ve la empresa.
El diseñador de la base de datos debe implicar en el desarrollo del modelo de datos
a todos los usuarios de la base de datos, tan pronto como sea posible. El diseño lógico de
la base de datos es independiente del SGBD concreto que se vaya a utilizar,
es independiente de los programas de aplicación, de los lenguajes de programación y
de cualquier otra consideración física.


1.1.5
Programadores de aplicaciones: se encargan de implementar los programas de aplicación
que servirán a los usuarios finales. Estos programas de aplicación son los que permiten
consultar datos, insertarlos, actualizarlos y eliminarlos. Estos programas se escriben
mediante lenguajes de tercera generación o de cuarta generación.
Usuarios finales: consultan, actualizan y generan reportes de la base de datos. A los
usuarios finales también se les llama clientes de la base de datos o usuarios generales.
Objetivos
Los SGBD que actualmente están en el mercado pretenden satisfacer un conjunto de objetivos
directamente deducibles de lo que hemos explicado hasta ahora. A continuación los comentaremos,
pero sin entrar en detalles que ya se verán más adelante en otras asignaturas.
a) Consultas no predefinidas o complejas:
El objetivo fundamental de los SGBD es permitir que se hagan consultas no predefinidas (ad hoc) y
complejas.
Consultas que afectan a más de una entidad:


Se quiere conocer el número de alumnos de más de veinticinco años y con nota media
superior a siete que están matriculados actualmente en la asignatura Bases de datos I.
De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el nombre, el
número de matrícula, el nombre de las asignaturas y el nombre de profesores de estas
asignaturas.
Los usuarios podrán hacer consultas de cualquier tipo y complejidad directamente al SGBD. El SGBD
tendrá que responder inmediatamente sin que estas consultas estén preestablecidas; es decir, sin
que se tenga que escribir, compilar y ejecutar un programa específico para cada consulta.
El usuario debe formular la consulta con un lenguaje sencillo (que se quede, obviamente, en el nivel
lógico), que el sistema debe interpretar directamente. Sin embargo, esto no significa que no se
puedan escribir programas con consultas incorporadas (por ejemplo, para procesos repetitivos).
La solución estándar para alcanzar este doble objetivo (consultas no predefinidas y complejas) es el
lenguaje SQL, que explicaremos en otro módulo didáctico.
b) Flexibilidad e independencia
La complejidad de las BD y la necesidad de irlas adaptando a la evolución del SI hacen que un
objetivo básico de los SGBD sea dar flexibilidad a los cambios.
Interesa obtener la máxima independencia posible entre los datos y los procesos usuarios para que
se pueda llevar a cabo todo tipo de cambios tecnológicos y variaciones en la descripción de la BD,
sin que se deban modificar los programas de aplicación ya escritos ni cambiar la forma de escribir
las consultas (o actualizaciones) directas.
Para conseguir esta independencia, tanto los usuarios que hacen consultas (o actualizaciones)
directas como los profesionales informáticos que escriben programas que las llevan incorporadas,
deben poder des- conocer las características físicas de la BD con que trabajan. No necesitan saber
nada sobre el soporte físico, ni estar al corriente de qué SO se utiliza, qué índices hay, la compresión
o no compresión de datos, etc.
De este modo, se pueden hacer cambios de tecnología y cambios físicos para mejorar el rendimiento
sin afectar a nadie. Este tipo de independencia recibe el nombre de independencia física de los
datos.
c) Problemas de la redundancia
En el mundo de los ficheros tradicionales, cada aplicación utilizaba su fichero. Sin embargo, puesto
que se daba mucha coincidencia de datos entre aplicaciones, se producía también mucha
redundancia entre los ficheros. Ya hemos dicho que uno de los objetivos de los SGBD es facilitar la
eliminación de la redundancia.
Seguramente pensáis que el problema de la redundancia es el espacio perdido. Antiguamente,
cuando el precio del byte de disco era muy elevado, esto era un problema grave, pero actualmente
prácticamente nunca lo es. ¿Qué problema hay, entonces? Simplemente, lo que todos hemos
sufrido más de una vez; si tenemos algo apuntado en dos lugares diferentes no pasará demasiado
tiempo hasta que las dos anotaciones dejen de ser coherentes, porque habremos modificado la
anotación en uno de los lugares y nos habremos olvidado de hacer- lo en el otro.
Así pues, el verdadero problema es el grave riesgo de inconsistencia o incoherencia de los datos; es
decir, la pérdida de integridad que las actualizaciones pueden provocar cuando existe redundancia.
Por lo tanto, convendría evitar la redundancia. En principio, nos conviene hacer que un dato sólo
figure una vez en la BD. Sin embargo, esto no siempre será cierto. Por ejemplo, para representar
una interrelación entre dos entidades, se suele repetir un mismo atributo en las dos, para que una
haga referencia a la otra.
d) Concurrencia de usuarios
Un objetivo fundamental de los SGBD es permitir que varios usuarios puedan acceder
concurrentemente a la misma BD.
Cuando un usuario o más de uno están actualizando los datos, se pueden producir problemas de
interferencia que tengan como consecuencia la obtención de datos erróneos y la pérdida de
integridad de la BD.
Para tratar los accesos concurrentes, los SGBD utilizan el concepto de transacción de BD, concepto
de especial utilidad para todo aquello que hace referencia a la integridad de los datos, como
veremos a continuación.
1.2 Análisis de requerimientos
Ver diapositivas Requerimientos.pptx