apunte 2

Vista previa del material en texto

Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 8 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
TEMA 2. SISTEMAS ADMINISTRADORES DE BASES DE DATOS. 
 
ARQUITECTURA DE UN SISTEMA ADMINISTRADOR DE BASES DE DATOS. 
 
PAUTAS Y NORMAS. INTEGRIDAD. SEGURIDAD. 
 
El DBMS es un conjunto de programas que maneja todo el acceso a la base de datos. 
 
Esto lo hace siguiendo ciertas pautas y normas que definen un proceso como el siguiente: 
 
1. un usuario solicita un acceso, 
2. el DBMS interpreta y analiza la solicitud, 
3. el DBMS consulta el catálogo almacenado, 
4. el DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada. 
 
Las pautas y normas que intervienen son las que aseguran el desempeño eficiente del DBMS en 
cuanto a tiempo de respuesta, interfaz con el usuario, etc. 
 
Estas pautas y normas contienen referencias específicas a dos aspectos importantes: 
 
 Integridad: el DBMS debe ser capaz de entender y de hacer cumplir un conjunto de 
restricciones sobre los datos, llamadas restricciones de integridad. Por ejemplo, 
verificaciones de tipo a un ingreso de datos, verificaciones de relaciones entre datos, 
verificaciones de valores de los datos. 
Es de hacer notar que ningún DBMS puede descubrir automáticamente un error. Si el 
usuario ingresó 10 en lugar de 100 y el tipo de dato coincide y está dentro del rango 
esperado, el DBMS lo admitirá. 
 Seguridad: implica el control de los accesos a la base de datos. Este control se hace 
usualmente asignando contraseñas a los usuarios y/o un sistema de control y revocación de 
privilegios. Este último sistema es controlado por el DBMS. 
 
Para poder cumplir su función, el DBMS se apoya en una arquitectura. 
 
Presentaremos una arquitectura, llamada arquitectura de tres esquemas, o de tres niveles, o 
ANSI/SPARC por el comité que la aprobó en 1.978, que permite a un DBMS cumplir con las 
pautas y normas para realizar su tarea, en especial con las referidas a la integridad y a la 
seguridad y permite tener en cuenta las características distintivas del DBMS que permiten: 
 
1. asegurar la independencia de los datos y la independencia de las operaciones, 
2. manejar las vistas distintas que pueden tener distintos usuarios sobre la misma base de 
datos, 
3. emplear un catálogo para el almacenamiento de la descripción de la base de datos. 
 
El objetivo de esta arquitectura es el de separar las aplicaciones del usuario de la base de datos 
almacenada, para lo cual propone esquemas definidos a diferentes niveles. 
 
 
 
 
 
 
 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 9 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
 
NIVELES. CORRESPONDENCIA ENTRE NIVELES. PROCESOS. 
 
 El Nivel Externo. Incluye varias vistas del usuario, que utiliza la parte de los datos 
almacenados que es de su interés. 
Cada esquema o vista externa muestra al usuario los datos que necesita y le oculta el resto. 
 El Nivel Conceptual. Contiene el esquema conceptual, que describe la estructura de toda la 
base de datos, ocultando los detalles de almacenamiento. 
 El Nivel Interno. Tiene un esquema interno que describe la estructura de almacenamiento de 
la base de datos. 
 
En la mayoría de los casos, los DBMS no distinguen específicamente los tres niveles, pero acepta 
los esquemas señalados. 
 
El proceso de transformar solicitudes y resultados de un nivel a otro se denomina 
correspondencia, o transformación, o mapping. 
 
Si bien la arquitectura de los DBMS no se ha estandarizado tanto como lo puede estar, por 
ejemplo, la de un compilador, la gran mayoría de los sistemas incluyen los siguientes módulos: 
 
· Gestor de archivos: interactúa con el sistema de archivos provisto por el sistema operativo. 
Se ocupa del manejo de las estructuras físicas de almacenamiento, de la administración del 
espacio de memoria secundaria y de los métodos de acceso y búsqueda. Si el gestor de 
archivos del sistema operativo fuera considerado ineficiente, los diseñadores del DBMS 
diseñan e implementan sus propias rutinas de acceso a archivos. 
· Gestor de datos: se encarga de la interfaz entre los datos y las aplicaciones o consultas de 
los usuarios. 
Vista 
Externa 2 
Vista 
Externa 1 
Vista 
Externa n 
Usuarios finales Usuario 1 Usuario 2 Usuario n 
Nivel Externo 
Correspondencia 
Externa / Conceptual 
Nivel Conceptual 
Correspondencia 
Conceptual / Interna 
Nivel Interno 
Esquema Conceptual 
Esquema Interno 
Base de datos almacenada 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 10 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
· Procesador de consultas: este módulo se encarga de traducir el lenguaje de alto nivel en 
que se formulan las consultas a un conjunto de instrucciones básicas que interpreta el 
gestor de datos. Esta traducción la hace siempre optimizando la consulta, esto es, 
implementa la consulta de la manera más eficiente. 
· Controlador del paralelismo: cuando el motor soporta múltiples procesos accediendo y/o 
modificando en paralelo a una misma base de datos, este controlador se encarga de que 
tales procesos no interfieran unos con otros. 
· Sistema de recuperación: junto con el controlador del paralelismo, este módulo se encarga 
del manejo de las transacciones, garantizando así que la base de datos quedará en un 
estado consistente en caso de falla total o parcial. 
 
 
 
CLASIFICACIÓN DE LOS SISTEMAS ADMINISTRADORES 
DE BASES DE DATOS. 
 
Un DBMS puede clasificarse de acuerdo a varios criterios. 
 
1. Según el modelo de datos en que se basa. 
Un modelo de datos es la forma en que se representan los datos, es una descripción de la 
realidad con el propósito de estudiarla. 
 
1.1. Relacionales, 
1.2. De Red, 
1.3. Jerárquicos, 
1.4. Orientados a los objetos. 
 
2. Según el número de usuarios a los que presta servicio. 
 
2.1. Monousuarios: solo atienden a un usuario a la vez, 
2.2. Multiusuarios: atienden a varios usuarios al mismo tiempo. 
 
3. Según la cantidad de sitios donde se encuentra almacenada la base de datos. 
 
3.1. Centralizados: la base de datos y el DBMS se encuentran en un solo computador, 
3.2. Distribuidos: la base de datos y el DBMS están en varios sitios, conectados por una 
red. 
 
4. Según su propósito. 
 
4.1. De propósito general, se diseñan para cualquier aplicación de gestión de bases de 
datos. 
4.2. De propósito especial, se diseñan para una aplicación específica. 
 
 
 
LENGUAJES E INTERFACES DE LOS 
SISTEMAS ADMINISTRADORES DE BASES DE DATOS. 
 
Como hemos visto, un DBMS puede ser utilizado por diferentes tipos de usuarios. Por lo tanto, 
deberá manejar lenguajes e interfaces apropiadas para cada categoría. 
 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 11 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
Estos lenguajes deberán ser tales que nos permitan las especificaciones de los esquemas 
externo, conceptual e interno asociados a cada uno de los tres niveles de la arquitectura del 
DBMS, y las correspondencias entre estos niveles. 
 
Para la especificación de las vistas de los usuarios y la correspondencia externa-conceptual, se 
utiliza un lenguaje denominado VDL: View Definition Languaje. 
La especificación del esquema conceptual y de la correspondencia conceptual-interna, se realiza 
en lenguaje DDL: Data Definition Languaje. El DBMS cuenta con un compilador cuya misión es 
procesar los enunciados DDL para identificar la descripción de los elementos del esquema 
conceptualen el catálogo almacenado. 
 
El SDL: Storage Definition Languaje es utilizado para la especificación del esquema interno y 
también se puede utilizar este lenguaje para especificaciones de la correspondencia conceptual-
interna, tal como el DDL. 
 
Una vez que se han compilado los esquemas de la base de datos y se han introducido los datos, 
se requerirá de algún mecanismo que permita la manipulación de los datos persistentes. Las 
operaciones de manipulación más comunes son la obtención, inserción, eliminación y modificación 
de los datos almacenados. Para tal propósito, el DBMS ofrece el DML: Data Manipulation 
Languaje. 
 
Como dijimos, los DBMS actuales no distinguen una clara separación entre los niveles, por ello les 
basta con un DDL y de un DML para las especificaciones de los tres esquemas y lo ofrecen en 
forma de un lenguaje integrado. Un ejemplo representativo es el lenguaje de bases de datos 
relacionales SQL, que estudiaremos con todo detalle en el tema siguiente. 
 
Con respecto a las interfaces, el lenguaje de un DBMS ofrece las siguientes: 
 
1. Interfaces basadas en menúes desplegables: presentan al usuario una lista de opciones que 
lo guían en la formulación de solicitudes. La ventaja de este tipo de interfaz es que brinda al 
usuario la posibilidad de formular peticiones sin necesidad de memorizar la sintaxis 
específica para cada una. 
2. Interfaces gráficas: presentan al usuario los esquemas en forma de diagrama y le permite la 
selección de la parte del diagrama que se exhibe. 
3. Interfaces basadas en formas: presentan al usuario un formulario estandarizado en el cual 
es posible agregar datos nuevos y recuperar datos persistentes. 
4. Interfaces de lenguaje natural: aceptan solicitudes e intentan entenderlas a través de un 
análisis sintáctico y léxico de las mismas. Si la interpretación tiene éxito, la interfaz genera 
una consulta de alto nivel y la envía al DBMS para que se encargue de su procesamiento, 
de lo contrario inicia un diálogo con el usuario para esclarecer la petición. 
5. Interfaces para usuarios paramétricos: son un conjunto pequeño de operaciones, como las 
disponibles en el cajero de un banco. Este tipo de interfaces son diseñadas por los analistas 
del sistema para una clase de usuarios simples. 
6. Interfaces para el DBA.: especiales para éste, como órdenes para crear cuentas, asignar 
niveles de seguridad, modificar esquemas, parametrizar el sistema y reorganizar la 
estructura de almacenamiento. 
 
 
INDEPENDENCIA DEL CONOCIMIENTO. 
 
En una aplicación de bases de datos se utiliza el motor o DBMS para realizar la gestión de los 
datos almacenados en la misma en distintos niveles. 
 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 12 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
Como vimos anteriormente, la arquitectura de los sistemas administradores de bases de datos, 
conocida como ANSI/SPARC, establece tres niveles, interno, conceptual y externo además de las 
correspondencias entre los niveles mencionados. 
 
Utilizando este modelo obtenemos independencia de almacenamiento, dejando los detalles al 
nivel interno. El nivel conceptual de la base de datos, es el mismo para cualquier implementación 
física. 
 
De manera similar, las aplicaciones, se comunican con el nivel externo de la base de datos. 
Dichas aplicaciones poseen en su código un contenido semántico que define el comportamiento 
de los datos almacenados. 
 
El concepto de la independencia del conocimiento sugiere que tal conocimiento semántico, 
que es común a todas las aplicaciones, se puede definir en la base de datos misma. De esa 
forma, se puede obtener un cierto conocimiento fuera de las aplicaciones y dentro de un 
esquema. 
 
Esto traerá un beneficio muy importante pues, al estar definidas dentro de la base de datos las 
reglas que definen el comportamiento de los datos, que son además las reglas de la organización, 
serán las mismas para todas las aplicaciones. 
 
En un DBMS relacional podemos implementar estas reglas a través de triggers o store procedures 
ofunciones. 
 
Esto produce un beneficio para las aplicaciones de base de datos en varios sentidos. Por un lado 
todas las aplicaciones que accedan a las bases de datos trabajarán con el mismo conjunto de 
reglas. Por otro lado, las aplicaciones no necesitan ocuparse de la integridad de los datos. 
 
Además tenemos una ventaja tecnológica adicional, las aplicaciones pueden tomar ventajas de las 
vistas y consultas derivadas automáticamente de los datos almacenados. Tengamos en cuenta 
que un sistema de bases de datos con arquitectura cliente/servidor, las vistas se ejecutan más 
eficientemente del lado del servidor. 
 
Veamos un ejemplo: en una organización que realiza ventas en cuenta corriente a clientes, se 
puede definir la siguiente regla: “Si el saldo de un cliente supera los $ 2.000 el crédito se bloquea”. 
 
Para ello podemos implementar dos reglas en la base de datos. Una que, sin importar que 
aplicación se utilice, al registrar un movimiento en la cuenta corriente, verifique el saldo y, si éste 
supera los $ 2.000, ponga un atributo estado de la cuenta en valor “bloqueado”. 
 
Otra regla impedirá que se puedan registrar movimientos en la cuenta corriente del cliente si el 
atributo en cuestión es igual a bloqueado. 
 
Así ninguna aplicación podrá registrar un movimiento en una cuenta corriente bloqueada y esta 
última se bloqueará instantáneamente al superar el máximo permitido. 
 
 
 
EL PROCESO DE DISEÑO DE BASES DE DATOS. 
MODELO CONCEPTUAL. MODELO LÓGICO. MODELO FÍSICO. 
 
Para abordar el tema, lo primero que debemos preguntarnos es: ¿ qué es diseñar ?. 
 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 13 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
Diseñar significa construir modelos. 
 
Parece que no hemos avanzado mucho, porque ahora tenemos que preguntarnos ¿ qué es un 
modelo ?. Un modelo es un vehículo para describir la realidad con el propósito de estudiar parte 
de ella. 
 
Nuestra realidad es la organización en la cual va a ser implementada la base de datos que 
pretendemos diseñar y la parte de la organización que nos interesa concretamente es el conjunto 
de datos persistentes. 
 
Entonces, el proceso de diseño de bases de datos es el proceso de construcción de modelos que 
muestren la estructura de la base de datos. 
 
Cuando abordamos el tema de arquitectura de los sistemas administradores de bases de datos, 
vimos que puede mirarse la base de datos desde tres niveles diferentes: externo, conceptual e 
interno. Por lo tanto, nuestro proceso de diseño deberá ser tal que permita mostrar la estructura 
de la base de datos pero vista desde sus tres niveles de arquitectura. 
 
El proceso de diseño de una base de datos consta de seis fases: 
Fase 1: recolección y análisis de requerimientos. 
Fase 2: diseño conceptual de la base de datos. 
Fase 3: elección del DBMS. 
Fase 4: diseño lógico de la base de datos. 
Fase 5: diseño físico de la base de datos. 
Fase 6: implementación de las aplicaciones. 
 
Esta enumeración de las fases indica, en principio, un orden secuencial de ejecución, lo cual es 
cierto. Ello no quita que a la altura de cualquiera de las fases no surjan detalles que haga 
necesaria una vuelta atrás. Por lo tanto, la salida producida por una fase puede ser alimentación 
para la fase siguiente o bien retroalimentación para alguna de las anteriores. 
 
Por otra parte, el proceso puro de diseño de bases de datos se limita a las fases 2, 3, 4 y 5, siendo 
la fase 1 la que nutre el comienzo del proceso y la fase 6 una continuación del proceso de 
construcción del software. 
 
Fase 1. Recolección y análisis de requerimientos. 
 
La actividad de recolección y análisis de requerimientoses una actividad previa al diseño que se 
realiza para todo el sistema de información que desea implementarse en una determinada 
organización. 
 
Al final de esta actividad, deberá tenerse en claro cuáles son los requerimientos del usuario y cuál 
es la necesidad: 
 
 de datos persistentes y 
 de procesos, 
 
que permitirán que el software cumpla con su función. 
 
La necesidad de datos persistentes y de procesos son una función de la otra: 
 
 los datos persitentes serán procesados para producir información, 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 14 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
 los procesos actúan sobre los datos persistentes para satisfacer los requerimientos del 
usuario, 
 
y, por ello, es lógico que la recolección y el análisis de los requerimientos del usuario se realice 
teniendo en cuenta tanto a los datos como a los procesos. Pero, al final de la fase, es posible 
separar ambos. 
 
Fase 2. Diseño conceptual de la base de datos. 
 
El objetivo de esta fase es la construcción del modelo conceptual de la base de datos. 
 
Un modelo conceptual es el que muestra la estructura de la base de datos desde el punto de vista 
del contenido. 
 
Este contenido se refiere a: 
 
 las estructuras de los datos persistentes, 
 la semántica o significado de los datos, 
 las relaciones entre los datos. 
 
La virtud de este modelo conceptual es que puede mostrar los datos persistentes desde su 
semántica y es justamente por ello que surge como primer modelo pues, a esta altura del proceso 
de diseño de la base de datos, tenemos en claro solamente cuál es el conjunto de datos que 
deberán ser almacenados. 
Esta fase de diseño conceptual de la base de datos se realiza en forma paralela con el diseño de 
los procesos, cuyo objetivo es la construcción de los modelos de tales procesos. Y es natural que 
ambas actividades sean paralelas, por la dependencia datos-procesos en la etapa de diseño. 
 
Fase 3. Elección del DBMS. 
 
¿ Por qué elegir un DBMS en medio de un proceso de diseño ?. Porque el modelo conceptual 
aporta conocimiento a un muy alto nivel de abstracción. 
 
Ahora debemos, gradualmente bajar ese nivel de abstracción aplicando un proceso de 
refinamiento que agrega nivel de detalle en cada etapa, tal que partiendo del modelo conceptual 
produce el modelo físico de la base de datos. 
 
Pero este modelo físico tiene que ver con el DBMS elegido y, por lo tanto, este es el momento de 
decidir qué tipo de DBMS utilizaremos. No entraremos en el detalle del tipo de variables que 
intervienen al momento de elegir el DBMS, pues ese punto ya lo hemos discutido en incisos 
anteriores. 
 
Fase 4. Diseño lógico de la base de datos. 
 
El objetivo de esta fase es la construcción del modelo lógico de la base de datos. 
 
Un modelo lógico es el que muestra la estructura de la base de datos que puede procesar el 
DBMS. 
 
Consiste sencillamente en un conjunto de enunciados escritos en el DDL del lenguaje del DBMS 
elegido, que especifican el nivel externo y el nivel conceptual de la arquitectura de tal DBMS. 
 
Fase 5. Diseño físico de la base de datos. 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 15 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
 
El objetivo de esta fase es la construcción del modelo físico de la base de datos. 
 
Un modelo físico es el que muestra la estructura que adquiere la base de datos en su 
almacenamiento secundario y los caminos de acceso. 
 
Para poder efectuar estas definiciones, debemos contar con pautas sobre requerimientos 
especiales como: 
 
 tiempo de respuesta y 
 productividad de la consulta, 
 
que son tenidos en cuenta en la actividad de diseño de los procesos, justamente para que estos 
logren la optimización. 
 
Otro factor que ya hemos considerado como de primordial importancia es el de asegurar la 
independencia del conocimiento. Por ello, un conjunto de procesos modelados durante el diseño 
de los procesos deberán ser el conjunto de reglas a incorporar a la base de datos física para 
asegurar esa independencia del conocimiento. 
 
El modelo físico de la base de datos consiste en un conjunto de enunciados escritos en el SDL del 
lenguaje del DBMS elegido, que especifican el nivel interno de la arquitectura de tal DBMS. 
 
Fase 6. Implementación de las aplicaciones. 
 
Con el modelo físico de la base de datos y otros modelos generados como resultado de la 
actividad de diseño de los procesos, podemos continuar con el proceso de construcción del 
software, implementando las aplicaciones de acuerdo a los modelos señalados. 
 
Lo expuesto anteriormente se resume en el siguiente mapa conceptual: 
 
 
Universidad Nacional de Salta. Facultad de Ciencias Exactas. Página 16 
Departamento de Informática. Licenciatura en Análisis de Sistemas. 
BASES DE DATOS I 
Lic. Patricia Mac Gaul – Lic. Martín Díaz – Lic. Guillermo Villanueva. Año 2.015. 
 
Requerimientos 
especiales + 
reglas de la 
organización 
Fase 1 Recolección y análisis de requerimientos 
Diseño conceptual 
de la base de datos 
Diseño de 
los procesos 
Fase 2 
Necesidad de datos Necesidad de procesos 
Modelo conceptual 
Elección del 
DBMS 
Fase 3 
Fase 4 
Diseño lógico 
de la base de datos 
Modelo lógico 
Diseño físico 
de la base de datos 
Modelo físico 
Fase 5 
Fase 6 
Otros modelos 
Implementación de las aplicaciones