Download Introducción a las Bases de Datos

Document related concepts

Modelo de base de datos wikipedia , lookup

SQLite wikipedia , lookup

Área Global del Sistema wikipedia , lookup

Sistema de gestión de bases de datos relacionales wikipedia , lookup

Base de datos wikipedia , lookup

Transcript
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
Introducción a las Bases de Datos (BDs)
Una base de datos (BD) se define como un “conjunto de datos relacionados entre sí”.
Los conceptos relevantes en esta definición son “datos” y “relacionados”.
“Datos”:
Conjunto de hechos relevantes que pueden ser registrados de algún modo, y
que cuentan con un significado implícito.
Reflejan situaciones del mundo real y cambios en esas situaciones.
“Relacionados”:
Debe existir homogeneidad en la colección de datos que conforma una BD.
No se trata de un conjunto seleccionado de forma aleatoria.
Los datos se recopilan y registran con una finalidad.
Los datos deben ser relevantes con respecto a esa finalidad.
La particularidad definitiva que convierte a un conjunto de datos en una base de datos es
la siguiente: una BD se controlan por medio de Sistemas de Gestión de Bases de Datos
(SGBDs).
Sistema de Gestión de Bases de Datos: Conjunto de programas de propósito general,
que proporcionan funcionalidades horizontales para facilitar la gestión de la
información contenida en una base de datos.
Los SGBDs actúan de intermediarios entre los datos y los programas de aplicación (y
sus usuarios) que los procesan y utilizan.
Programas de
aplicación
SGBD
Base de
datos
Usuarios
Usuarios
En ocasiones, los usuarios también podrán acceder a los datos interaccionando
directamente con el SGBD.
Necesidad de los SGBDs
La pregunta a realizar es ¿por qué son necesarios los SGBDs para gestionar las
colecciones de datos (las BDs)?
En el enfoque tradicional (el adoptado en los albores de la informática), se sumía que
cada quien se construía los programas de aplicación que necesitaba; y para cada
programa se creaban un conjunto de ficheros en el almacenamiento secundario
(discos...) donde se registraban y mantenían los datos que se necesitaban. Cada uno de
estos ficheros se creaba con la estructura y formato internos que se ajustasen más a las
necesidades del programa. Por ejemplo, un programa para la gestión de la matriculación
Autor: Juan Ramón López Rodríguez
1
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
de una universidad podría mantener la información sobre los alumnos en un fichero de
texto, con una línea por alumno, y los diferentes datos separados por símbolos
especiales.
DNI || Nombre || FNacimiento || Dirección || CP || Localidad
76.666.999 || Pedro Pérez || 03-07-1913 || Plaza Conchiñas 5678 || 23.879 || A Coruña
01.000.009 || María Blasco || 31-02-1878 || Plaza Armas 329 || 99.369 || Ferrol
...
Y un programa de gestión de socios de la biblioteca de la misma universidad podría
mantener su propio fichero con información sobre los mismos, aunque almacenada en
diferente orden y formato, con separadores diferentes, e incluso con cierta información
diferente.
DNI @ Apellidos @ Nombre @ Dirección @ CP @ Localidad @ Teléfono
76.666.999 @ Pérez @ Pedro @ Plaza Conchiñas 5678 @ 23.879 @ A Coruña @ 981 123456
01.000.009 @ Blasco @ María @ Plaza Armas 329 @ 99.369 @ Ferrol @ 981 654321
...
También podría existir un fichero con información sobre los fondos disponibles en la
biblioteca:
ISBN @ Titulo @ Autor @ Ejemplares disponibles
12-4567-321 @ Base de Datos @ Ramez Elmasri @ 3
12-3128-510 @ XML @ Peter Schönk @ 0
...
Y, finalmente, otro fichero con información sobre los préstamos de libros realizados
hasta la fecha
DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución
76.666.999 @ 12-4567-321 @ 05/01/2003 @ 09/01/2003
76.666.999 @ 12-4567-321 @ 09/01/2003 @ 12/01/2003
01.000.009 @ 12-3128-510 @ 10/01/2003 @ --...
Este enfoque presenta ciertos problemas, que pasaremos a analizar a continuación:
El problema más importante es el de la redundancia: es posible mantener
información repetida en múltiples ficheros. Eso puede implicar que cuando
se produzcan modificaciones de información se puedan dar problemas de
inconsistencia. En el ejemplo de la universidad, podría darse el caso de que
un alumno (por ejemplo Pedro) cambie de domicilio, y que notifique ese
cambio a la administración de su centro. Los administrativos utilizarán su
programa de gestión de datos para modificar la información recogida en su
fichero. Pero si no notifican el cambio a los bibliotecarios, el fichero de datos
de la biblioteca mantendrá la información antigua sobre el domicilio del
alumno, que ahora será errónea. Se trata de un caso de flagrante
inconsistencia entre la información recogida en uno y otro fichero; y de
inconsistencia entre la información recogida en el fichero de la biblioteca y
la realidad.
Un problema relacionado es el del aislamiento de datos: al estar dispersos en
varios ficheros, utilizados probablemente por usuarios diferentes, los datos
son difíciles de conseguir. Es posible que un usuario desconozca que una
información que necesita está disponible en alguno de los ficheros
informatizados de la organización en la que trabaja. En el caso de nuestro
Autor: Juan Ramón López Rodríguez
2
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
ejemplo bien podría suceder que los administrativos de la universidad,
necesitando en un momento dado contactar urgentemente con un alumno,
desconozcan que los bibliotecarios disponen de su teléfono en su fichero de
gestión de usuarios.
La solución al aislamiento de datos podría pasar por centralizar la
información, y por poner de acuerdo a todos los integrantes de una
organización para determinar aquellos ficheros necesarios y la estructura de
la información que deberían mantener. Aún así, persistirían otros problemas;
por ejemplo, problemas de dificultad de acceso. Los programas de
aplicación están diseñados para proporcionar una funcionalidad específica.
¿qué sucede si de repente surge una necesidad nueva, específica, puntual, de
información? Se hace necesario corregir y rescribir los programas de
aplicación para satisfacerla, algo que no necesariamente va a ser trivial, y
que posiblemente requeriría de personal especializado (informáticos). En
nuestro ejemplo, podría suceder que los bibliotecarios necesiten conocer la
media de préstamos por usuario del último mes, información que el
programa de gestión no está preparado para calcular: no quedaría más
remedio que acudir al fichero mismo y calcular la información “a mano”. El
problema de la dificultad de acceso consiste, pues, en que no existe un modo
práctico y sencillo, en este enfoque, de adaptarse a nuevas necesidades de
información de forma rápida y sencilla.
Otro problema, aunque no exclusivo del enfoque tradicional basado en
ficheros, es el del control de la integridad de los datos. Los hechos que se
recogen en una BD han de ser un fiel reflejo de la realidad para ser de
utilidad. Sin embargo, es posible que se produzcan errores durante la
recopilación de los datos, o durante su introducción (errores al teclear la
información, por ejemplo) en los ficheros. Se hace necesario introducir, en lo
posible, mecanismos de control en los programas de aplicación para
asegurarnos que la información recogida en los ficheros es correcta y veraz.
Esos mecanismos de control se basan en la aplicación de una serie de reglas,
o restricciones, que garantizan esa integridad de los datos. Reglas como por
ejemplo “ningún usuario puede tener más de tres libros en préstamo”; o
“todo usuario tiene un DNI, con formato 99.999.999”. Cada vez que un
programa de aplicación modifique los datos almacenados en los ficheros,
deberá comprobarse que la nueva información no viole ninguna de esas
reglas. Por ejemplo, los programas de gestión administrativo y de la
biblioteca de nuestro ejemplo deben incluir sendos controles referentes a la
corrección de los DNIs de los alumnos y socios de la biblioteca que manejen,
respectivamente. A partir de este ejemplo es fácil descubrir el mayor
inconveniente del enfoque tradicional de gestión de ficheros: un mismo
control ha de ser incluido (y realizado) en múltiples programas de aplicación,
cuando lo ideal sería que fuese realizado una única vez.
Algo a preguntarse es ¿qué sucede cuando varios usuarios acceden al mismo
tiempo (a través de los correspondientes programas de aplicación) a los
mismos ficheros? Esas situaciones pueden acabar dando lugar a situaciones
de inconsistencia de datos, que serán consecuencia de problemas de
concurrencia de acceso y manipulación de los datos. Para verlo con nuestro
ejemplo, supongamos el siguiente escenario:
- Supongamos que en la biblioteca disponemos de tres ejemplares
del mismo libro, el que tiene por ISBN 12-3128-510 y por título
Autor: Juan Ramón López Rodríguez
3
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
‘Bases de datos’, que no están actualmente en préstamo; y así lo
reflejamos en el fichero correspondiente a los fondos.
ISBN @ Titulo @ Autor @ Ejemplares disponibles
...
12-4567-321 @ Base de Datos @ Ramez Elmasri @ 3
...
-
-
-
-
Supongamos ahora que dos usuarios de la biblioteca pretenden
llevarse en préstamo dos ejemplares de ese mismo libro. Cada
uno acude a un bibliotecario para efectuar la operación.
El primer bibliotecario accede desde su PC, con su programa de
gestión, al fichero de fondos y comprueba que efectivamente hay
3 ejemplares disponibles en la actualidad. El programa conserva
ese dato para no tener que acceder nuevamente al fichero para
consultarlo.
El segundo bibliotecario procede de la misma forma. Su
programa de gestión, en su PC, también conserva con el dato de
los 3 ejemplares disponibles.
El primer bibliotecario usa el programa para registrar el préstamo
del libro en el fichero de préstamos. Y, a continuación, el
programa calcula, a partir del número de ejemplares disponibles
que había recuperado del fichero (3) el número de ejemplares que
ahora queda libres (3-1=2) y lo graba en el fichero de fondos para
actualizarlo.
ISBN @ Titulo @ Autor @ Ejemplares disponibles
...
12-4567-321 @ Base de Datos @ Ramez Elmasri @ 2
...
-
El segundo bibliotecario procede de idéntica forma: usa su
programa para registrar el préstamo del libro en el fichero de
préstamos; y, a continuación, el programa calcula, a partir del
número de ejemplares disponibles que había recuperado del
fichero (¡que vuelve a ser 3!) el número de ejemplares que ahora
quedan libres (3-1=2) y lo graba en el fichero de fondos para
actualizarlo.
ISBN @ Titulo @ Autor @ Ejemplares disponibles
...
12-4567-321 @ Base de Datos @ Ramez Elmasri @ 2
...
-
Las consecuencias: tenemos un fichero (el de fondos) que
contiene información que no es cierta: el fichero indica que hay
dos ejemplares disponibles del libro ‘Bases de datos’, cuando
hemos visto que ahora en realidad solo hay dos. Es fácil ver que
si las dos operaciones (los dos préstamos) hubiesen sido
realizados de forma secuencial, una después de otra, la
inconsistencia no se habría producido: el problema surge de
combinar dos operaciones que van realizando actualizaciones
parciales de los datos, y que no deberían mezclarse: mientras una
no hubiese concluido y hubiese completado todos los cambios
Autor: Juan Ramón López Rodríguez
4
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
necesarios de forma definitiva, y no parcial, la otra no debería
comenzar. Se hace pues necesario incluir en todos nuestros
programas mecanismos que detecten si otros programas están
accediendo en un momento dado a los datos que necesitamos, y
evitar estas situaciones.
Un problema íntimamente ligado al anterior es el de la atomicidad de las
operaciones a realizar sobre los ficheros. Hemos visto que una operación
realizada sobre los ficheros esté compuesta de una serie de pequeñas
actualizaciones sobre los datos contenidos en los mismos: en el caso del
programa de gestión de la biblioteca, hemos visto que el préstamo de una
libro implica cambios sobre el fichero de préstamos y el fichero de fondos.
Para ver un ejemplo de este tipo de problema, supongamos ahora el siguiente
escenario:
-
Un usuario solicita el préstamo del libro ‘Bases de datos’, del que
nos queda un ejemplar en la biblioteca.
ISBN @ Titulo @ Autor @ Ejemplares disponibles
...
12-4567-321 @ Base de Datos @ Ramez Elmasri @ 1
...
-
El bibliotecario utiliza su programa de gestión para ejecutar el
préstamo. El programa registra, en primer lugar, el hecho en el
fichero de préstamos.
DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución
...
76.666.999 @ 12-4567-321 @ 09/02/2004 @ --...
-
Y a continuación, se dispone a modificar la información sobre el
número de ejemplares disponibles. Comprueba el número de
ejemplares disponibles hasta ese momento (1), y en ese
momento... se produce un corte de energía. La operación se ha
completado sólo parcialmente, con lo que la información de los
ficheros vuelve a quedar en un estado inconsistente.
Nos encontramos, por lo tanto, ante un nuevo problema: las operaciones a
realizar sobre los ficheros deberían presentar un carácter atómico: deben ser
realizadas por completo, y en caso de no completarse, ser anulados los
cambios realizados hasta ese momento. ¿Cómo conseguir eso con nuestros
programas de aplicación?
Nuevos problemas a considerar son los de seguridad: La información que se
almacena en los ficheros y que manejan los programas es de muy diferente
tipología. También es habitual encontrarse con diferentes categorías de
usuarios de esos programas. En nuestro ejemplo, es posible suponer que en
la biblioteca, además del personal fijo, se cuente también con algún becario/a
que los ayude en la gestión. Podría ser razonable pensar que los becarios no
deberían tener acceso a toda la información almacenada en los ficheros
informatizados (por ejemplo, la información contable relativa a los
Autor: Juan Ramón López Rodríguez
5
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
presupuestos de la biblioteca). Esa información debe ser también protegida
de aquellos usuarios externos que sí tengan acceso a la información del
catálogo, por ejemplo. Por lo tanto, se hace patente la necesidad de
establecer diferentes niveles de acceso a la información, que deben ser
mantenidos por medio de mecanismos de control implementados en los
programas de aplicación.
Un último caso a considerar: problemas de respaldo y recuperación: los
datos, y los ficheros que los contienen, se almacenan en algún tipo de soporte
informático, que, por diversos motivos, es susceptible de sufrir daños de
forma accidental: a causa de un problema físico, por culpa de un virus
informático, por un incendio... Es necesario, por lo tanto, establecer
mecanismos para la realización, de forma regular, de copias de seguridad,
que permitan la recuperación de los ficheros, con los datos existentes con
anterioridad al accidente. Eso implicará, probablemente, la construcción de
programas de aplicación especializados que automaticen la realización de
dichas copias, y su restauración en caso necesario.
Todos estos problemas que hemos presentado tienen dos cosas en común: en primer
lugar, son independientes de un dominio o área de aplicación determinada (a pesar de
haberlos presentado empleando un ejemplo correspondiente a la gestión de una
universidad, en general, y de una biblioteca universitaria en particular); y en segundo
lugar, su resolución pasa por modificar nuestros programas de aplicación para poder
detectarlos y solventarlos. La pregunta que surge es: ¿es necesario replicar todos estos
controles y mecanismos de resolución en todos nuestro programas? Ya que
centralizamos e uniformizamos los ficheros, y por tanto los datos que contienen, ¿por
qué no hacer lo mismo con la resolución de estos problemas.
Esa es la idea que dio lugar a la construcción de los SGBDs: un conjunto de programas
destinados exclusivamente a la resolución de estos problemas: a partir de ahora,
podemos destinar nuestros esfuerzos a construir eficientemente aquellos programas de
aplicación que necesitemos, centrándonos exclusivamente en la funcionalidad que
deben proporcionar (la gestión de una biblioteca, de un hospital, de un banco...) Los
problemas generales asociados a la gestión de datos de cualquier tipo (precisamente
aquellos que acabamos de presentar) ya estará resuelta por cualquier SGBD, que
eximirá a nuestros programas de esa responsabilidad.
Soluciones proporcionadas por los SGBDs
Como hemos visto, el uso de un SGBD no elimina la aparición de los problemas de
carácter general asociados al tratamiento de datos y de ficheros; pero si elimina la
necesidad de resolverlos, ya que el SGBD proporcionará los mecanismos necesarios
para hacerlo. Dedicaremos ahora un tiempo a explicar alguno de estos mecanismos, a
partir de la lista de problemas que acabamos de presentar en la sección anterior.
Redundancia y aislamiento: Estos problemas se resuelven por medio de una
gestión centralizada de los datos. Los datos se mantienen ahora en un conjunto
único de ficheros gestionados por el SGBD, de los que habrá sido eliminada
cualquier tipo de redundancia. Cualquier acceso a los datos debe ser realizado a
través del SGBD; las modificaciones o ampliaciones de los ficheros deben ser
gestionados por un conjunto de personas (los administradores) que serán
Autor: Juan Ramón López Rodríguez
6
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
responsables del SGBD y de sus ficheros; y serán los administradores los
encargados de resolver cualquier duda de los usuarios acerca de la información
mantenida en la base de datos (resolviendo así el problema del aislamiento).
Dificultad de acceso: los SGBDs presentan a los usuarios (y a sus programas de
aplicación) diferentes interfaces 1 de acceso a la información. Entre esas interfaces
se encontrarán:
- Menús (programas genéricos de consulta y actualización de datos.)
- Lenguajes de consulta y actualización de bajo (APIs) y de alto nivel (SQL)
Lenguajes como SQL (siglas de Structured Query Language, lenguaje de consulta
estructurado) permiten a cualquier usuario recuperar información de una BD no
prevista en los programas de aplicación que utiliza de un modo sencillo. Se dice que
SQL es un lenguaje de alto nivel – y además no procedimental - porque permite
especificar, en un lenguaje muy próximo al inglés, la definición de todo tipo de
consultas sin necesidad de indicar cómo debe ser recuperada la información: solo
hay que especificar qué información se necesita. De ese modo se simplifica el
problema de la dificultad de acceso: proporcionando un procedimiento simple y
flexible de responder a nuevas necesidades de información.
Control de integridad: los SGBDs permiten definir, por medio de lenguajes
especiales, reglas que expresen restricciones de integridad: condiciones que deben
ser cumplidas por los datos almacenados en una BD. De este modo, el SGBD libera
a los programas de la comprobación de estas condiciones; cada vez que se realice
alguna modificación de la BD, será el propio SGBD el que se encargue de verificar,
una por una, cada una de las restricciones previamente establecidas. De no ser así,
os cambios serán rechazados.
Concurrencia: el SGBD impedirá que se produzcan situaciones de concurrencia
susceptibles de producir inconsistencias. Para ello se encargará de bloquear el
acceso a ciertos datos si fuese necesario (y será el propio gestor quien decida, en la
mayoría de los casos, cuándo es necesario el bloqueo). En el caso de nuestro
ejemplo, el gestor bloquearía temporalmente la reserva del segundo libro hasta que
la del primero hubiese concluido totalmente.
Paso 1: Comprobación del número de ejemplares libres (3) por parte del primer bibliotecario.
¡Bloqueo automático de esta información!
Paso 2: Grabación de la reserva por parte del primer bibliotecario
Paso 3: Grabación del nuevo número de ejemplares libres (2) por parte del primer bibliotecario.
Desbloqueo automático de esta información.
Paso 4: Comprobación del número de ejemplares libres (2) por parte del segundo bibliotecario,
una vez desbloqueada esta información.
Paso 5: Grabación de la reserva por parte del segundo bibliotecario.
Paso 6: Grabación del nuevo número de ejemplares libres (1) por parte del segundo bibliotecario.
Atomicidad: el SGBD se encargará de almacenar toda la información necesaria
para conseguir que, si una operación compleja se queda a medias, los cambios
realizados hasta ese momento sean invalidados y la BD se devuelva al estado válido
y consistente inmediatamente anterior a la ejecución de la operación. En el caso de
nuestro ejemplo, la grabación de la reserva en el fichero de préstamos sería borrada,
al no haberse completado la operación en su total integridad.
1
En este contexto, mecanismos o modos de acceso (N del T)
Autor: Juan Ramón López Rodríguez
7
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución
...
76.666.999 @ 12-4567-321 @ 09/02/2004 @ --...
Seguridad: El SGBD distingue diferentes perfiles de usuario, y para cada perfil o
para cada usuario concreto de una BD, permite establecer:
- Los datos a los que tiene acceso
- El tipo de acceso permitido a esos datos (consulta, modificación...)
Para poder identificar el perfil de cada usuario, cada uno habrá de contar con una
cuenta personal de acceso, validada normalmente a través de una contraseña.
Respaldo: Los SGBDs vienen normalmente acompañados de herramientas que
automatizan la realización de copias de seguridad de todas las BDs bajo su
“responsabilidad”.
Arquitectura en tres niveles
Además de toda la funcionalidad que acabamos de ver, el SGBD se encarga de la
gestión de los ficheros en los que se almacenan los datos, incluida la intermediación en
todas las operaciones de acceso y actualización a los mismos.
El problema que surge es el siguiente: la organización y gestión de los ficheros en los
que se mantiene la información puede resultar muy compleja, e incluye aspectos como
el número de ficheros utilizados, el espacio ocupado, su estructura interna... Por
ejemplo, en el caso de la biblioteca que hemos utilizado como ejemplo, hemos estado
utilizando dos ficheros separados para almacenar los datos de los libros y sus préstamos;
aunque nada nos habría impedido utilizar sólo uno:
ISBN @ Titulo @ Autor @ Ejemplares disponibles
DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución
12-4567-321 @ Base de Datos @ Ramez Elmasri @ 3
76.666.999 @ 12-4567-321 @ 05/01/2003 @ 09/01/2003
76.666.999 @ 12-4567-321 @ 09/01/2003 @ 12/01/2003
12-3128-510 @ XML @ Peter Schönk @ 0
01.000.009 @ 12-3128-510 @ 10/01/2003 @ --...
Este formato de almacenamiento agilizaría la búsqueda de información sobre los
préstamos de un determinado libro realizados hasta la fecha: Bastaría con localizar la
línea correspondiente a un libro dentro del fichero, y las líneas siguientes
corresponderían a todos sus préstamos. En el formato anterior (dos ficheros) sería
necesario (1) localizar la línea correspondiente al libro en el fichero de fondos
bibliográficos; y (2) localizar todas las líneas correspondientes al libro en el fichero de
préstamos (lo que podría implicar comprobar una por una todas las líneas del fichero).
En cambio, el formato con un único fichero complicaría enormemente otras
operaciones. Por ejemplo, el registro de un nuevo préstamo. Eso implicará (1) hacer
sitio en el fichero para incluir una nueva línea (lo cual requerirá desplazar una a una
todas las líneas siguientes que haya en el fichero); y (2) grabar la línea correspondiente
al nuevo préstamo. Cuando en el formato anterior, era suficiente con añadir una nueva
línea al final del fichero de préstamos.
Como se ve, la organización de los ficheros de la BD influye enormemente en la
eficiencia de las operaciones realizadas sobre los datos. Los SGBDs organizarán la
Autor: Juan Ramón López Rodríguez
8
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
información de la forma que la eficiencia de dichas operaciones sea mayor, a veces
utilizando estructuras de almacenamiento realmente complejas.
Esas estructuras complejas deberán ser entendidas por los usuarios de la BD y por los
técnicos encargados de elaborar los programas de aplicación para poder utilizar
convenientemente cada BD; algo que supone una complicación a la hora de desarrollar
su trabajo.
Para evitarlo, los SGBD cumplen una función más: la de enmascarar los datos. Mejor
dicho, la de enmascarar la estructura de bajo nivel de los datos y las operaciones a ese
nivel (los métodos de acceso). El SGBD nos va a proporcionar un nivel de abstracción
superior, una visión conceptual (virtual, en el sentido de no real) de los datos, que no es
la real, pero que facilita nuestro acceso a la información. Por ejemplo, los SGBDs más
comunes son los relacionales, los cuales, sea cual sea la organización de sus ficheros,
nos muestran la información de forma que los datos parecen estar contenidos en tablas,
sobre las que operaremos directamente. De ese modo nos olvidamos de que estamos
trabajando sobre ficheros, y de problemas como, por ejemplo, la necesidad de hacer
”sitio” en los mismos para introducir nuevas líneas. Esas cuestiones serán
responsabilidad del SGBD, que las llevará a cabo de forma automática.
Para poder dar esa visión abstracta de los datos, nos basamos habitualmente en modelos
de referencia (el modelo relacional es un ejemplo), que definen formas de organizar la
información de una forma más comprensible y manejable. Se trata de herramientas
conceptuales, que definen conceptos o elementos genéricos para organizar y describir la
información.
Por otro lado, habíamos comentado que no todos los usuarios de una BD tendrán el
mismo nivel de acceso a los datos contenidos en la misma, en cuanto a la información a
la que tendrán acceso, y en cuanto a las operaciones que podrán realizar sobre la misma.
Dicho de otro modo, no todos los usuarios tendrán la misma visión de los datos. Eso
significa que podemos definir un tercer punto de vista de los datos, unido al punto de
vista físico (los ficheros) y conceptual (las tablas, por ejemplo): el punto de vista de
cada perfil de usuario, al que se conoce con la denominación genérica de punto de vista
externo. Siguiendo con el caso de los SGBDs relacionales, cada perfil de usuario tendrá
asociada una vista externa formada por aquellas tablas o secciones de las tablas - de
entre todas las que constituyan la BD - a las que un usuario con ese perfil tendrá acceso.
A este triple punto de vista de los datos (la visión física, la visión conceptual y la visión
externa) se la conoce como la arquitectura en tres niveles de la información: ya que
los tres puntos de vista originan tres niveles de abstracción de los datos. Para cada nivel
es posible desarrollar un esquema de datos: una descripción de la organización de los
datos tal y como son vistos a ese nivel de abstracción. Por analogías con la teoría de
conjuntos, a los esquemas se los conoce también como la intensión de los datos,
mientras que los datos se pueden ver como la extensión (las instancias) de un esquema.
Por supuesto, la finalidad de estos esquemas es ayudarnos a comprender, de una forma
sencilla e inmediata, la organización de la información en la BD.
La figura siguiente esquematiza la arquitectura en tres niveles de la información y sus
principales características:
Autor: Juan Ramón López Rodríguez
9
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
Nivel externo
Usuario (perfil 1)
Esquema externo 1
Usuario (perfil 2)
Esquema externo 2
- A este nivel se describen las diferentes visiones que
de los datos tiene cada usuario de un determinado
perfil o tipo, por medio de un conjunto de esquemas
externos.
- Cada esquema externo omite aquellos datos que el
usuario correspondiente no necesita, o a los que no
tiene permiso de acceso; describe sólo los datos a los
que se tiene acceso.
- Se basa en un modelo de referencia de alto nivel.
Nivel conceptual
Esquema conceptual
- A este nivel se describe la organización de la BD al
completo, a partir de un modelo de datos de referencia
de alto nivel.
- La descripción se ciñe exclusivamente a los datos, y
omite de forma intencionada los detalles referentes al
modo de almacenamiento y de acceso a los mismos.
- La descripción constituye el esquema conceptual de
la BD.
Nivel interno
- A este nivel se describe la organización real de la BD
al completo.
- La descripción constituye el esquema físico de la
BD, e incluye los ficheros que la componen, la
organización de los mismos, y los métodos de acceso
utilizados.
- Los usuarios de la BD no necesitan conocer esta
información. Es el administrador de la BD el que
gestiona estos ficheros.
SQL
Como explicábamos en el apartado anterior, los SGBDs nos proporcionan la
transparencia necesaria para no tener que conocer, como usuarios de una BD, los
detalles de su organización física. La visión que tendremos de la información será de
más alto nivel: todas las operaciones que realicemos sobre una BD serán realizadas
tomando como referencia la descripción establecida en el esquema conceptual. El
SGBD se encargará, de forma automática, de hacer posible esa ilusión.
Uno de los modelos de referencia más utilizados para construir una visión de los datos a
tan alto nivel es el modelo relacional. Como se ha comentado también en el apartado
anterior, el modelo relacional implica la organización de los datos en forma de tablas.
Se trata de uno de los modelos más utilizados por los SGBDs comerciales, y al que se
ha dedicado un mayor esfuerzo de investigación. Tal es su importancia que se ha
acabado convirtiendo en un estándar: es el modelo de datos de alto nivel de referencia
en el mundo de las bases de datos.
Buena parte del éxito de este modelo se debe al lenguaje SQL (Structured Query
Language): se trata de un lenguaje, también de alto nivel, que permite construir todo
Autor: Juan Ramón López Rodríguez
10
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
tipo de consultas sobre la información contenida en una BD relacional, con una sintaxis
muy similar a la del inglés.
Todos los SGBDS basados en el modelo relacional van a soportar este lenguaje. Eso
significa que si aprendemos a utilizar SQL podremos realizar consultas sobre múltiples
SGBDs diferentes, aunque estos estén construidos de diferente manera y organicen
internamente la información de acuerdo a estructuras muy distintas. De ahí la
importancia que ha cobrado este lenguaje.
En realidad, SQL es un lenguaje muy completo: no solo permite consultar la
información almacenada en una base de datos, sino que también:
- Permite gestionar la estructura de las tablas que forman la BD, e incluso definir
nuevas tablas si es necesario, o eliminar alguna de las ya existentes.
- Permite actualizar el contenido de las tablas, insertando o eliminando filas, o
modificando los valores de las ya existentes.
Autor: Juan Ramón López Rodríguez
11
Grao en Información e Documentación: Bases de datos documentais
Curso 2013 – 2014
Bibliografía
-
R. Elmasri y S. Navathe. Fundamentos de los Sistemas de Bases de Datos (3ª
edición). Addison-Wesley, 2002.
A. Silberschatz, H. F. Korth y S. Sudarshan. Fundamentos de Bases de Datos (4ª
edición). McGraw Hill, 2002
Autor: Juan Ramón López Rodríguez
12