Download Antes

Índice
SISTEMAS OPERATIVOS Y SISTEMAS DE INFORMACIÓN
Sistemas operativos
Lo primero que cabría decir es que la historia de los sistemas operativos corre paralela a
la de la arquitectura de los computadores.
Podemos decir que hasta que no aparecieron los circuitos integrados y el sistema
operativo OS/360 de IBM (1965), no se popularizaron varias técnicas fundamentales, de
las que la más importante es la multiprogramación.
Otra de las características del OS/360 (y otros de su generación), era la capacidad de
leer trabajos de las tarjetas al disco, de maneras que estos quedaban encolados a la
espera de que el sistema operativo concluyera con un trabajo, cargando un nuevo trabajo
del disco en la partición de memoria que había quedado desocupada. Esta técnica se
llama spooling.
Posteriormente, surgió otra técnica relacionada con la multiprogramación: la de tiempo
compartido. Se trata de que en un sistema donde hay varios usuarios con sesiones
abiertas, la CPU puede ser asignada a los que requieran servicio. Así, unos mandarán
trabajos cortos, como la compilación de programas de cinco páginas, y otros requerirán
del sistema que ordene un millón de registros de una cinta. La computadora podría dar
un servicio rápido e interactivo a varios usuarios y realizar los trabajos más largos
cuando esté más inactiva. En este sentido, quizás el sistema operativo más
representativo fue MULTICS (MIT, Bell Labs y General Electric), con el que se
pretendía soportar cientos de sesiones con tiempo compartido. El proyecto se fue
abandonado poco a poco y sólo en cierto ambiente de producción del MIT llegó
realmente a ejecutarse. Sin embargo muchas de las ideas de MULTICS tuvieron una
enorme influencia en sistemas subsecuentes.
Con el desarrollo de los circuitos LCI (Large Scale Integration), chips con miles de
transistores en un cm2 de silicio, se inició la era de la computadora personal.
La amplia disponibilidad del poder de cómputo, que dio lugar a que podían contarse con
gráficos excelentes, condujo al crecimiento de una gran industria de producción de
software para computadoras personales. Gran parte de este software es amigable con el
usuario, lo que indica que está destinado al usuario que no sabe nada acerca de
computadores.
Dos sistemas operativos han dominado la escena de las computadoras personales y las
estaciones de trabajo (en realidad, computadoras personales grandes): MS-DOS de
Microsoft y UNIX. MS-DOS tiene un amplio uso en la IBM PC y otras máquinas con la
CPU de la familia Intel (del 8088 al último Pentium o Itanium).
UNIX domina en las computadoras que no utilizan a Intel, así como en las estaciones de
trabajo (en especial las que poseen chips de alto desempeño RISC).
Concepto de sistema operativo
Los programas de computador se pueden dividir es dos grupos: los programas del
sistema, que gestionan las actividades del computador en sí, y los programas de
aplicación, que resuelven los problemas de los usuarios.
Si cada programador se tuviera que preocupar de cómo funciona el controlador del
disco y de la gran cantidad de errores que pueden ocurrir al leer un bloque de disco, es
muy probable que muchos programas no se llegasen a escribir. Precisamente, uno de los
programas de sistema más importante, el sistema operativo, se encarga de administrar
todos los recursos del computador y proporcionar el soporte necesario para escribir los
programas de aplicación.
En otras palabras: el sistema operativo es la capa de software sobre el hardware, que se
encarga de gestionar todos los elementos del sistema y presentar al usuario una interfaz
(funciones de llamadas al sistema), o máquina virtual más fácil de entender y programar.
Pero el sistema operativo, como se ha señalado, no sólo proporciona soporte a los
programadores, también (y quizás sea su labor más importante), administra los recursos
del computador.
Un computador consta de procesadores, memorias, temporizadores, discos, terminales,
unidades de disco, interfaz a redes de comunicación, impresoras, etc. El sistema
operativo debe asignar, de forma ordenada, los procesadores, memorias y dispositivos
de E/S a los diversos programas (procesos) que compiten por ellos.
Por último digamos, que la perspectiva que se utiliza aquí (y en el resto de temas
relacionados) es la de los sistemas operativos llamados "tradicionales" o centralizados,
en contraposición de los "distribuidos". Un sistema operativo distribuido realiza las
mismas funciones que el centralizado pero utilizando un gran número de CPU (con
todas sus memorias, discos, etc., y demás recursos asociados), y que están conectados
mediante una red de alta velocidad.
Objetivos y funciones de un sistema operativo
Podemos afirmar que todo sistema operativo tiene dos objetivos:
Comodidad: Un sistema operativo hace que un computador sea más fácil y cómodo de
utilizar.
Eficiencia: Un sistema operativo permite que los recursos del computador se utilicen de
forma eficiente.
Las funciones o servicios que proporciona un sistema operativo se llevan a cabo en las
siguientes áreas:
Creación de programas: El sistema operativo proporciona cierta variedad de servicios y
medios para ayudar al programador en la elaboración de programas. Usualmente, estos
servicios son utilidades que no son propiamente del sistema operativo, pero se accede a
ellos a través del mismo.
Ejecución de programas: Para ejecutar un programa es preciso realizar una serie de
tareas. Las instrucciones y datos deben cargarse en memoria principal, los dispositivos
de E/S y los ficheros deben iniciarse, y deben prepararse otros recursos. El sistema
operativo proporciona todo eso al usuario.
Acceso a los dispositivos de E/S: El sistema operativo se encarga del conjunto particular
de instrucciones y señales de control que necesitan los dispositivos de E/S para operar.
De esta manera, el programador piensa sólo en términos de lecturas y escrituras.
Acceso controlado a los ficheros: El sistema operativo se ocupa de los detalles sobre la
naturaleza del dispositivo donde están almacenados los ficheros (disco fijo, CD-ROM,
etc.), así como del formato de los mismos. También, en el caso de sistemas
multiusuarios, el sistema operativo proporciona mecanismos de protección para
controlar el acceso a los ficheros compartidos.
Detección de errores: Mientras el computador está funcionando, se pueden producir
errores de hardware, internos y externos, tales como errores de memoria, o
comportamientos incorrectos de los dispositivos, y errores diversos de software, tales
como desbordamientos, el intento de acceso a una posición de memoria no permitida.
En cada caso, el sistema operativo debe responder de forma que se supere el error con el
menor impacto para las aplicaciones que se estén ejecutando. Normalmente, lo que hará
el sistema operativo es abortar el programa que causó el error, reintentar la operación o
notificar el error a la aplicación.
Contabilidad: El sistema operativo debe almacenar la estadística de uso de los distintos
recursos. Esta información es útil para anticipar la necesidad de futuras ampliaciones, y
ajustes que mejoren las prestaciones del sistema.
Tipos de sistemas operativos
Para distinguir entre los distintos tipos de sistemas operativos, existen ciertas
características clave. La primera característica clave es si se trata de un sistema de colas
(batch) o interactivo. En un sistema interactivo, el usuario interactúa directamente con el
computador, para solicitar la ejecución de un trabajo o realizar una transacción. Un
sistema de colas, es lo opuesto. El programa usuario se introduce en una cola junto con
programas de otros usuarios. Después de que el programa ha terminado, los resultados
se proporcionan al usuario.
La otra característica clave es si el sistema utiliza multiprogramación o no. Con la
multiprogramación se intenta mantener al procesador ocupado tanto como sea posible,
haciéndolo trabajar en más de un programa al mismo tiempo. La alternativa es un
sistema de monoprogramación, que trabaja sólo en un programa en cada momento.
Hay muchas clasificaciones de sistemas operativos, dependiendo del criterio en que se
basen.
Según el punto de vista del usuario
Sistemas monousuario: Tienen un solo usuario y están dedicado, generalmente, a una
sola función. El interfaz del SO constará básicamente de un gestor de ficheros sencillo,
utilidades que proporcionen facilidades de E/S y un intérprete de comandos también
sencillo. Sus cualidades son fiabilidad, eficacia, sencillez de uso y facilidad de
extensión.
Sistemas de tiempo real: Dan respuesta a unas entradas con un tiempo de proceso
limitado. Sus funciones principales son: interactuar con dispositivos externos (sensores,
válvulas, etc.), reaccionar de forma inmediata ante cualquier suceso externo, registrar la
información, tener noción de tratamientos prioritarios y realizar una planificación
eficiente. Su cualidad principal es la tolerancia a fallos y la disponibilidad. Los campos
de aplicación son gestión de centralitas telefónicas, pilotaje de aviones o vigilancia
médica.
Sistemas transaccionales: Sus funciones son gestionar un gran volumen de información
desde distintos y numerosos puntos de acceso, gestión de un gran número de
transacciones que se desarrollan simultáneamente. Sus cualidades son fiabilidad y
disponibilidad. Ejemplos de estos sistemas los tenemos en los de reservas de plazas en
líneas aéreas, gestión de cuentas bancarias o consultas de documentos.
Sistemas time-sharing/multiprogramados: Se caracterizan por prestar servicio a un
conjunto de usuarios simultáneamente, dividiendo el tiempo de máquina en "quantums"
para cada usuario (a diferencia de los sistemas multiprogramados en el que el
procesamiento es concurrente). El SO es el encargado de conmutar entre los diversos
procesos.
Sistemas multiprocesador: Se caracterizan por la existencia de varios procesadores
centrales compartiendo a veces memoria y periféricos en la ejecución de instrucciones
en paralelo. Sus funciones son las mismas que las de los sistemas timesharing/multiprogramados.
Según la arquitectura del computador
Sistemas monolíticos: Están diseñados como un conjunto de rutinas compiladas por
separado, que pueden llamarse entre sí y que se montan para formar el SO, que será la
rutina principal. Como ejemplos tenemos DOS y UNIX. El principal problema de los
sistemas monolíticos es su diseño poco apropiado para sistemas operativos grandes, son
difíciles de especificar, codificar, probar y depurar.
Sistemas por niveles o capas: Se introdujeron para mejorar los monolíticos. Estos
sistemas están diseñados como una jerarquía de niveles, en la que cada nivel hace uso
de las facilidades que le proporcionan el hardware y los niveles inferiores a él. Están
constituidos por una serie de módulos pequeños y fáciles de manejar. Un ejemplo de
este tipo de SO es MINIX (véase [3]). La principal ventaja de este tipo de sistema es su
facilidad de mantenimiento. La principal dificultad es elegir las funciones que deben de
asignarse a cada nivel.
Tipología de los sistemas de información
La tarea de los SI consiste en procesar la entrada, mantener archivos de datos en
relación con la empresa y producir información, informes y otras salidas.
Estos sistemas están constituidos por otros subsistemas que incluyen el hardware,
software y almacenamiento de datos para los archivos y bases de datos.
Llamaremos aplicación de un sistema de información al conjunto formado por equipos,
programas, archivos y procedimientos. Por lo tanto, los sistemas de información podrán
tener aplicaciones de compras, contabilidad, ventas, etc.
Los analistas, a la hora de diseñar los sistemas de información se ayudan de
organigramas que describen las relaciones de los componentes de una empresa. Sin
embargo, existen otros datos que no pueden reflejarse utilizando dichos organigramas,
pero que un analista tendrá que tener en cuenta. Algunos de estos datos son:
¿Qué interacciones existen entre el personal y los departamentos, pero que no aparecen
en los organigramas?
¿En qué otros departamentos y componentes de la empresa se encuentra una de
pendencia específica?
¿Cuáles son los individuos y elementos del sistema más importantes para alcanzar con
éxito los trabajos?
¿Cómo circulan la información y las instrucciones entre los componentes de la empresa,
y cómo interactúan las diferentes áreas con las demás?
En las empresas, los analistas desarrollan dos tipos diferentes de sistemas de
información:
Los sistemas de procesamiento de transacciones que se ocupan de tareas rutinarias que
es necesario efectuar periódicamente.
Los sistemas de información para la gestión que hacen referencia a la parte de los SI que
no se dedica al procesamiento y tratamiento de transacciones, sino a los niveles
operativo, táctico y estratégico de la dirección. Son llamados también Sistemas de
decisiones administrativas se utilizan para dar apoyo directo a los gerentes responsables
de la toma de decisiones de la empresa. Les ayudan proporcionándoles información
importante que servirá de entrada al proceso de decisión.
Los sistemas de apoyo para la toma de decisiones son un tipo de sistemas de decisiones
administrativas: apoyan las decisiones que están menos estructuradas y que no es
rutinaria.
Sistemas de apoyo para la toma de decisiones
Los Sistemas de Apoyo de Decisiones son usados por los directivos para realizar
análisis de los datos de la empresa, y tomar las mejores decisiones. Proporcionan bases
de datos y herramientas de análisis y modelado.
El propósito de estos sistemas es ayudar a la administración para que marque tendencias,
señale problemas y tome decisiones inteligentes. El origen de estos sistemas es anterior,
incluso, a la existencia de computadores, y la idea básica es recolectar datos
operacionales del negocio, y reducirlos a una forma que pudiera ser usada para analizar
el comportamiento del mismo y modificarlo inteligentemente.
En la década de los setenta las propias empresas construyeron varios sistemas
personalizados de apoyo para la toma de decisiones. Fueron implantados usando
generadores de informes como RPG, o productos de recuperación de datos como Focus,
Datatrieve y NOMAD. Con estos sistemas los gerentes de la empresa formulaban
consultas sin requerir ayuda del departamento de procesamiento de datos.
Las bases de datos para el apoyo de toma de decisiones tienen características especiales:
generalmente son sólo de lectura. Otras características destacables de dichas bases son:
No preocupa la integridad.
Tienden a ser grandes.
Están muy indexadas.
Contienen a menudo redundancias controladas
La redundancia es controlada cuando es controlada por el SGBD y está oculta a los
usuarios. Hay dos tipos de estas redundancias:
Mediante el mantenimiento de réplicas de los datos.
Mediante el mantenimiento de datos derivados, muy frecuentes en las tablas resumen o
columnas derivadas calculadas.
Las tablas resumen son tablas que guardan totales (sumas, promedios, etc.) de los
valores que están en otras tablas.
Preparación de datos
Los datos en los sistemas de apoyo para la toma de decisiones deben de ser extraídos de
diversas fuentes, limpiados, transformados y consolidados, así como cargados en la base
de datos de apoyo. Además, serán actualizados periódicamente:
La extracción es el proceso de capturar datos de las bases de datos operacionales
(tratadas más adelante) o de otras fuentes.
La limpieza incluye el llenado de valores faltantes, la corrección de errores tipográficos,
etc. Los datos que son erróneos y que no pueden ser limpiados serán reemplazados.
La transformación y consolidación puede involucrar la división o la combinación de los
registros fuente. Llamamos consolidación al proceso mediante el cual se mezclan varias
fuentes de datos.
Las operaciones de carga incluyen: el movimiento de los datos transformados y
consolidados hacia la base de datos de apoyo para la toma de decisiones; la verificación
de su integridad; y la construcción de cualquier índice necesario.
La actualización se refiere a que la mayoría de las bases de datos de apoyo de decisiones
requiere periódicamente: una carga parcial, y a menudo la eliminación de la base y una
carga completa.
Los almacenes de datos operacionales son un tipo especial de bases de datos. Están
orientados a un tema: los datos en cuestión tienen que ver con alguna área temática
(como por ejemplo: clientes o productos). Son a menudo áreas transitorias para la
reorganización física de los datos operacionales extraídos o para apoyar la toma de
decisiones operacionales.
Data warehouses y data marts
Los sistemas de apoyo para la toma de decisiones tienen requerimientos de rendimiento
variables, cargas de trabajo impredecibles, y una utilización errática. Sin embargo, a
pesar de estas diferencias con respecto a los sistemas operacionales, los datos de apoyo
para la toma de decisiones necesitan ser recolectados a partir de los operacionales, y
mantenidos en un almacén de datos propio en una plataforma independiente. A dichos
almacenes se les conoce como data warehouse.
Un almacén data warehouse es un tipo especial de base de datos. Surgieron por dos
razones: la necesidad de proporcionar una única fuente de datos limpia y consistente
para datos de apoyo de toma de decisiones; y la necesidad de hacerlo sin afectar a los
sistemas operacionales.
Pronto se hizo evidente que los usuarios realizaban amplias operaciones de informes y
análisis de datos sobre un subconjunto relativamente pequeño de los data warehouse.
Por lo que se vio la necesidad de construir algún tipo de almacén a medida para ciertos
propósitos. Estos almacenes son los data marts.
Esquemas dimensionales
Los primeros sistemas de apoyo para la toma de decisiones mantenían generalmente un
simple archivo como historial de las transacciones de negocios a efectos de análisis.
Más tarde, por medio de exploración secuencial, se podría acceder al mismo. Sin
embargo, conforme el volumen de información aumenta, se hace necesario el mantener
desde varias perspectivas diferentes, un acceso directo a dicho archivo. Por ejemplo,
encontrar las transacciones que involucran a un producto en particular.
Se llamó multicatálogo al método de organización que soporta este tipo de acceso
directo. El archivo se convirtió en uno general que mantenía los datos de las
transacciones de negocios y tres archivos: para productos, periodos y clientes. Estos
últimos archivos se parecen a los archivos de índice, aunque las entradas pueden ser
colocadas explícitamente por el usuario, y pueden contener información suplementaria
(por ejemplo, la dirección del cliente). Bajo el punto de vista del modelo relacional, a
los archivos de datos se les llama tablas de hechos y a los de catálogo tablas de
dimensión. Al diseño general se le llama esquema dimensional.
Minería de datos
Con el término minería de datos se entiende un análisis de datos exploratorio. El
propósito es buscar patrones interesantes en los datos, que pueden usarse para
especificar la estrategia del negocio, o para identificar comportamientos fuera de lo
común. Las herramientas de minería de datos aplican técnicas estadísticas a una gran
cantidad de datos almacenados para buscar patrones.
Consideremos la siguiente tabla:
Transacción Cliente Marca de tiempo
Producto
TX1 1
D1
ZAPATOS
TX1 1
D1
CALCETINES
TX1 1
D1
CORBATAS
TX2 2
D2
CALCETINES
TX2 2
D2
CORBATAS
TX2 2
D2
CINTURONES
TX2 2
D2
CAMISAS
TX3 3
D2
ZAPATOS
TX3 3
D2
CORBATAS
TX4 2
D3
ZAPATOS
TX4 2
D3
CALCETINES
TX2 2
D3
CINTURONES
Al negocio le gustaría realizar un análisis de canasta de mercado sobre los datos de la
tabla (canasta de mercado se refiere al conjunto de productos comprados en una sola
transacción). De ese modo, espera descubrir correlaciones como: un cliente que compra
zapatos, también compra calcetines. A dicha correlación se la conoce como regla de
asociación, y puede expresarse como:
FORALL TX (ZAPATOS  TX => CALCETINES  TX)
Otra terminología en minería de datos es: llamamos población en el ejemplo, al
conjunto de todas las transacciones de ventas. El nivel de soporte es el fragmento de
población que satisface la regla. El nivel de confianza es la fracción de la población en
la que, si se cumple el antecedente, también se satisface el consecuente.
En el ejemplo, dada la regla:
FORALL TX (CALCETINES  TX => CORBATAS  TX)
La población es 4, el soporte es del 50% y la confianza es del 66.67%.
También podríamos definir otros tipos de reglas. Una regla de correlación de secuencia
podría ser usada para identificar patrones de compras a lo largo del tiempo: si un cliente
compra zapatos hoy, es probable que compre calcetines dentro de los 5 días siguientes.
BIBLIOGRAFIA
[1] James A. Senn. Análisis y Diseño de Sistemas de Información. 1988, McGraw-Hill.
[2] Date, C.J. Introducción a los Sistemas de Bases de Datos, Addison Wesley, 2001,
(7ª Edición).
[3] Mario G. Piattini y otros. Análisis y diseño detallado de aplicaciones informáticas de
gestión. RA-MA, 1996.
SISTEMAS GESTORES DE BASES DE DATOS.
Resumen
Los sistemas gestores de bases de datos (SGBD) surgieron ante la necesidad que tenían
las grandes compañías de manejar convenientemente sus datos. Existían una serie de
motivaciones que se detallan primeramente (como problemas de redundancia e
inconsistencia, difícil acceso y aislamiento de los datos, etc.), que dieron origen a dichos
sistemas.
Antes de pasar a tratar las funciones y componentes de un SGBD, estudiamos algunos
de las definiciones que se han dado de un SGBD, y las ventajas e inconvenientes de
utilizarlos en grandes compañías (que es donde realmente tiene sentido que se usen).
En cuanto a las funciones de un SGBD, quizás las más importantes sean el acceso y
modificación de los datos (que, normalmente, realizan los usuarios del sistema), aunque
hay otras como la descripción destinada a los administradores, que permiten definir los
esquemas que va a manejar el sistema.
Las componentes son muy variadas, y dependen del modelo que su utiliza.
La arquitectura de referencia es la ANSI/SPARC que propone 3 niveles bien
diferenciados para la estructura de cualquier SGBD: nivel físico, donde se manipulan
las estructuras de almacenamiento de los datos (ficheros indexados, árboles B, etc.); el
nivel conceptual, donde se ocultan los detalles del almacenamiento y se tratan las
distintas entidades que van a manejar los usuarios; y el nivel de vistas, donde sólo son
visibles diferentes vistas de la base de datos destinadas a ciertos grupos de usuarios.
Entre cada dos niveles se ha de definir las reglas de transformación de datos entre
niveles.
A continuación hacemos una descripción de un SGBD real, DB2, que se ajusta bastante
a la arquitectura ANSI/SPARC.
Por último, se relacionan distintos tipos de SGBD utilizando diferentes criterios de
clasificación.
Sistemas gestores de bases de datos
Antes de que se comenzase a emplear el término de bases de datos, las organizaciones
contaban con un gran número de archivos donde tenían almacenados los datos en muy
variados formatos, y con programas de aplicación específicos para cada archivo,
escritos en los más diversos lenguajes de programación. Lo cierto era que el panorama
era bastante desolador. La relación que hacemos a continuación muestra algunas de las
dificultades con las que se tenían que enfrentar los usuarios de dichos sistemas (que se
han dado en llamar de procesamiento de archivos):
Redundancia e inconsistencia de los datos:
Dado que los diferentes archivos tenían distintos formatos, y los programas que los
manipulaban estaban escritos en leguajes diferentes; ocurría con frecuencia que la
misma información estaba repetida en distintos archivos. Esta redundancia tenía como
consecuencia un aumento en el coste de almacenamiento y en el de acceso de los datos.
Pudiendo conducir a inconsistencias de los mismos: si se cambiaba un dato en un
archivo, los datos eran inconsistentes al no modificarlos en el resto de archivos.
Difícil acceso a los datos:
Para las operaciones no previstas solicitadas por un usuario, que consisten generalmente
en buscar unos datos que cumplan ciertas propiedades, era necesario listarlos todos y
filtrar los que no cumplían dichas propiedades, con lo que la tarea de encontrar datos se
hacía bastante tediosa.
Aislamiento de los datos:
Debido a que los datos están dispersos en varios archivos, resultaba difícil escribir
aplicaciones que recuperaran los datos adecuados.
Problemas de integridad:
Es necesario garantizar que los usuarios autorizados realicen operaciones correctas
sobre los datos. En general, decimos que los datos deben cumplir ciertas propiedades
llamadas ligaduras de integridad. Para hacerlas cumplir es necesario añadir el código
apropiado a las diferentes aplicaciones, resultando muy difícil esta adición si estas
ligaduras deben cumplirse entre elementos de datos que están en diferentes archivos.
Problemas frente a fallos del sistema:
Algunas operaciones realizadas con datos del sistema deben de ocurrir o no de manera
completa (la operación debe ser atómica), de manera que si ésta fue, por ejemplo, de
transferencia de una cantidad desde una cuenta a otra, debemos evitar las situaciones en
las que, se reste la cantidad del saldo de la primera cuenta sin que haya aumentado en la
misma cantidad el saldo de la segunda cuenta. Esto es difícil de controlar en un sistema
tradicional de procesamiento de archivos. La dificultad reside, sobre todo, en garantizar
que las operaciones serán deshechas si hay un fallo. A este tipo de operaciones se las
denominará más adelante transacciones.
Problemas en el acceso concurrente:
Muchos sistemas permiten el acceso simultáneo de múltiples usuarios para actualizar
los datos, de manera que pueden darse situaciones en que los datos sean inconsistentes.
Así podrían dos usuarios intentar a la vez retirar 100 € y 200 € de una cuenta que tenga
1000 €. De manera que si las operaciones pueden realizarse de forma simultánea, ambos
usuarios ven un saldo de 1000 €, por lo que la primera operación daría un saldo de 900
€, que podría actualizarse después de que se realizase completamente la segunda
operación, resultado que el saldo final es de 900 €. El proceso de supervisión que
evitaría estos errores, resultará bastante más difícil de implementar, si se pueden acceder
a los datos desde muchos programas de aplicación diferentes.
Problemas de seguridad:
No todos los usuarios deben de tener acceso a todo tipo de información. Como las
aplicaciones se añadían cubriendo diferentes necesidades conforme van apareciendo, y
para distintos tipos de usuarios, es difícil controlar las ligaduras de seguridad.
Para salvar la mayor parte de estos inconvenientes que hemos apuntado, surgieron los
Sistemas de Gestión de Bases de Datos (DBMS, en inglés).
El primer objetivo de cualquier sistema de gestión de bases de datos es proporcionar un
entorno práctico y eficiente para la recuperación y almacenamiento de los datos.
La importancia de la información en las organizaciones, ha conducido al desarrollo de
una gran cantidad de conceptos y técnicas para la gestión eficiente de los datos. De todo
ello nos vamos a ocupar en el resto de apartados del presente tema.
Conceptos de base de datos
A continuación, se muestran algunas de las definiciones clásicas de bases de datos en
orden cronológico (subrayamos los conceptos más relevantes que introdujeron cada una
de ellas):
Colección de datos interrelacionados almacenados en un conjunto sin redundancias
perjudiciales o innecesarias; su finalidad es servir a una aplicación o más, de la mejor
manera posible; los datos se almacenan de manera que resulten independientes de los
programas que los usan; se emplean métodos determinados para incluir nuevos datos y
para modificar o extraer los datos almacenados.
Conjunto de datos de la empresa memorizado por una computadora, que es utilizado por
numerosas personas, y cuya organización está regida por un modelo de datos.
Colección no redundante de datos compatibles entre diferentes sistemas de aplicación.
Conjunto de archivos maestros, organizados y administrados de una manera flexible de
modo que los archivos pueden ser fácilmente adaptados a nuevas tareas imprevisibles.
Ninguna de estas definiciones resulta completa para lo que hoy en día se entiende por
bases de datos. Una definición completa, podría ser:
"Colección de datos integrados, con redundancia controlada y con una estructura que
refleja las interacciones y restricciones existentes en el mundo real; los datos, que han
de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse
independientes de éstas, y su definición y descripción, únicas para cada tipo de datos,
han de estar almacenadas junto con los mismos. Lo procedimientos de actualización y
de recuperación, comunes y bien determinados, habrán de ser capaces de conservar la
integridad, seguridad y confidencialidad del conjunto de los datos."
Concepto de SGBD
Un SGBD se define como "el conjunto coordinado de programas, procedimientos,
lenguajes y otros recursos, que suministra, tanto a los usuarios no informáticos como a
los analistas, programadores o al administrado del sistema, los medios necesarios para
describir, recuperar y modificar los datos almacenados en la base, manteniendo su
integridad, confidencialidad y seguridad."
Ventajas de los SGBD
Como ya se ha indicado los SGBD surgieron para evitar muchos de los inconvenientes
que presentaban los sistemas de almacenamiento de archivos, sin perder de vista su
finalidad última. Esta es la relación casi completa de los problemas que ya se han
superado en gran medida:
Independencia de los datos respecto a los tratamientos y viceversa
De manera que un cambio en el tratamiento de los datos, no imponga un nuevo diseño
lógico o físico de la base de datos. Así mismo, la inclusión de nuevas informaciones,
desaparición de otras, cambios en la estructura física o en la forma de acceso, etc., no
deben obligar a alterar los programas. Esta independencia entre las estructuras de la
base de datos y los programas de aplicación, supone una gran ventaja frente al esfuerzo
de tener que reprogramar cuando se producen cambios en los datos. De esta manera, sin
costes excesivos, el sistema se adaptará a la evolución de la organización que lo esté
usando.
La característica que permite que los programas y los datos que los manejan sean
independientes se llama abstracción de datos. De manera que el usuario de la base de
datos no tiene que conocer cómo están almacenados los datos ni los detalles de cómo
están implementadas las operaciones sobre los mismos (como, en realidad, ocurría de
alguna forma con los sistemas primeros que aparecieron).
En los SGBD los detalles de la estructura y organización de cada archivo se almacenan
en el Catálogo. Los usuarios utilizan la representación conceptual de los archivos, y es
el propio sistema quien se encarga de extraer los detalles de almacenamiento de dicho
Catálogo cuando los requieran las aplicaciones escritas para el SGBD.
Coherencia de los resultados
En todos los tratamientos dentro de un SGBD se utilizan los mismos datos, por lo que
todos son coherentes y compatibles. Además, al no existir (o al menos disminuir en gran
mediada) la redundancia de los datos, desaparece el problema del enfoque clásico en el
que era necesario actualizar los archivos para evitar este tipo de problemas.
Disponibilidad de los datos para el conjunto de usuarios
Un usuario no es propietario de ningún dato, sino que todos tendrán acceso a todos los
datos (siempre que tengan las autorizaciones oportunas). De nuevo, utilizando el
Catálogo (o diccionario), los datos podrán ser difundidos y accedidos por distintos
medios informáticos.
Valor de la información
Puesto que los datos son tratados en conjunto, éstos adquieren mayor valor, que si
fuesen tratados de forma independiente.
Documentación normalizada e integrada con los datos
Tradicionalmente, la documentación de los datos era efectuada por un analista o
programador aparte de la propia base de datos. Actualmente se tiende a que la
descripción de los datos esté incluida dentro del sistema y a que sea lo más completa
posible.
Eficiencia en la recogida, validación y entrada de datos en el sistema
Al no existir apenas redundancia, los datos se recogen y validan una vez, de manera que
el proceso de almacenamiento tiene un rendimiento mucho mayor que en los sistemas
tradicionales.
Reducción del espacio de almacenamiento
De nuevo, al no haber apenas redundancia y aplicando, además, técnicas de
compactación de datos, se obtienen SGBD con una menor ocupación en disco.
Posibilidad de múltiples vistas de los datos
Los datos son manipulados por muy diferentes tipos de usuarios. Una vista puede
consistir en un subconjunto de la base de datos o en datos virtuales, derivados de los
datos almacenados pero que no están grabados físicamente en el Catálogo. Un SGBD
debe incluir la posibilidad de definir múltiples vistas.
Restricción del acceso a los usuarios autorizados
La seguridad se entiende como un mecanismo de protección de los datos. El SGBD
dispone de un subsistema de seguridad, antes de permitir el acceso a los datos por un
usuario, se encarga de revisar las restricciones de seguridad almacenadas en el Catálogo.
Inconvenientes de los SGBD
Sin embargo todas estas mejoras no iban a obtenerse sin un coste adicional. A
continuación mostramos la relación de los inconvenientes con los que habrá de
enfrentarse cualquier organización que desee implantar un SGBD:
Instalación costosa
La instalación de un SGBD implica elevados costes tanto a nivel físico (nuevas
instalaciones o aplicaciones), como a nivel lógico (sistemas operativos, programas,
compiladores, etc., que son necesarios para su uso).
Personal especializado
Sobre todo para la administración del SGBD, será necesario un personal especializado
que será difícil de encontrar, y de formar. Muchas veces, este problema es clave cuando
una organización se plantea utilizar el sistema.
Implantación larga y complicada
Las dificultades que van apareciendo a lo largo del desarrollo de la implantación de un
SGBD, llevan, casi siempre, a que se superen los plazos inicialmente previstos.
Falta de rentabilidad a corto plazo
El coste que implica tanto de personal como de equipos la implantación de un SGBD,
hace que no resulte rentable a corto plazo. Así, en instalaciones muy grandes el plazo
para que sea rentable puede ser de varios años.
Ausencia de normas
No existe un estándar, realmente, que facilite a los usuarios el manejo de los sistemas de
bases de datos. En el campo de las bases de datos relacionales, ya empieza a imponerse
un lenguaje estándar: el SQL ISO (9075).
Desfase entre teoría y práctica
Los usuarios, sobre todo directivos, tienen una resistencia a cambiar un sistema de
información basado en archivos por uno más avanzado enfocado a las bases de datos.
Además, debido al desconocimiento de las posibilidades que ofrece un SGBD, pueden
sentir cierta frustración cuando lo implantan en sus organizaciones.
Funciones
Un SGBD debe ser capaz de describir, recuperar y modificar los datos, por lo tanto, las
principales funciones que deben poderse realizar con el mismo están claras. También
hemos de incluir aquí otras funciones propias de la administración del sistema.
Función de descripción
Esta función debe de permitir al administrador especificar los elementos de los datos
que la integran, su estructura y las relaciones que existen entre ellos. Así mismo, el
administrador podrá establecer las reglas semánticas, los controles a efectuar antes de
autorizar los accesos a una base, etc. También con esta función, podrá dar las
características de tipo físico y las vistas lógicas de los usuarios.
Esta función se realiza mediante un lenguaje de descripción de datos (DDL, Data
Description Language), que será propio de cada SGBD. Con el DDL podemos definir
las tres estructuras de datos (externa, lógica e interna, como veremos al tratar la
arquitectura del sistema), especificando las características de los datos para cada uno de
estos niveles.
En el nivel interno, indicamos el espacio (volúmenes, cilindros y pistas) reservado para
la base; la longitud de los campos o elementos de los datos, su modo de representación
(binario, decimal, alfanumérico, punto fijo o flotante, etc.) Además deben definirse los
caminos de acceso: punteros, índices, etc.
Para las estructuras externa y lógica, esta función debe permitir la definición de las
entidades y su identificación, los atributos de las mismas, interrelaciones entre ellas,
autorizaciones de acceso, restricciones de integridad, etc. El SBDG se ocupará de la
función de correspondencia (mapping) de las estructuras lógicas externas y de la
relación entre la estructura externa y la interna (mediante las llamadas reglas de
transformación, como veremos al estudiar la arquitectura).
Función de acceso y modificación
Permite a los usuarios (informáticos o no), buscar, añadir, suprimir o modificar los
datos de la misma.
Esta función se llevará a cabo mediante el lenguaje de manipulación de datos (DML,
Data Manipulation Language). Muchas veces se trata de un conjunto de instrucciones
que son admitidas por un lenguaje de programación, y otras de un lenguaje desarrollado
especialmente para el SGBD. La mayoría de los SGBD contienen ambos tipos de
lenguajes.
Función de utilización
Esta función reúne a todos los interfaces que necesitan los diferentes usuarios para
comunicarse con la base, proporcionando una serie de procedimientos al administrador.
Algunas de las operaciones que realiza esta función son: cambiar la capacidad de los
archivos, obtener estadísticas de utilización, cargar archivos, etc. Otras operaciones
están relacionadas, principalmente, con la seguridad física (copias de seguridad,
rearranque en caso de caída del sistema, etc.) y de protección frente a accesos no
autorizados.
Componentes
Un sistema de bases de datos se divide en módulos que se encargan de cada una de las
funciones del sistema completo. Algunas de éstas, incluso, puede asumirlas el propio
intérprete de mandatos del sistema operativo.
Hay que distinguir entre componentes de procesamiento de consultas y componentes de
gestión de almacenamiento.
Componentes de procesamiento de consultas
El compilador de DDL
Procesa las definiciones de esquemas, especificadas en el lenguaje DDL, y almacena
estos esquemas en el Catálogo.
A menudo, el DDL lo constituyen dos subconjuntos de instrucciones: un lenguaje de
definición del almacenamiento de los datos (DSDL: Data Strorage Definition Language),
que permite especificar características físicas de la base de datos (volúmenes y archivos
donde van a ser almacenados los datos, etc.), y un lenguaje de control de datos (DCL:
Data Control Language), encargado del control y seguridad de los datos (privilegios,
modos de acceso, etc.)
El procesador de la base de datos en tiempo de ejecución
Se encarga de los accesos a la base de datos durante la ejecución, recibiendo peticiones
del usuario. Cuando haya que acceder al disco, éste componente llamará al gestor de
datos almacenados. Para las consultas, se dispone de un componente, el compilador de
consultas, que será invocado ante las peticiones del usuario. Éste último, analiza la
sintaxis y el contenido de las consultas, generando llamadas al procesador en tiempo de
ejecución para atender a la solicitud (optimizándolas, como veremos más adelante en el
tema 36).
El procesador precompilador
Extrae órdenes en DML para convertirlas en código objeto para el acceso a la base de
datos. El código objeto y el resto del programa escrito en el lenguaje anfitrión (lenguaje
de propósito general que puede utilizarse para programar aplicaciones del SGBD), se
enlazan, formando una transacción programada, cuyo código ejecutable incluye
llamadas al procesador en tiempo de ejecución.
El compilador VDL
Procesa las definiciones de las distintas vistas de los usuarios especificadas en un
lenguaje VDL (View Definition Languague), y las almacena en el Catálogo.
Componentes de gestión de almacenamiento
El gestor de datos almacenados
Las bases de datos y el Catálogo se suelen almacenar en disco. El acceso al disco lo
controla el propio sistema operativo. En un SGBD el acceso se hace con un componente
esencial: el gestor de datos almacenados, que realiza las funciones de extracción y
almacenamiento de las bases de datos y el Catálogo en disco. También controla otros
aspectos de la transferencia de datos, como el manejo de áreas de almacenamiento
intermedio (buffers) en la memoria principal.
El gestor de seguridad e integridad
Comprueba que se satisfagan las ligaduras de integridad y seguridad de los usuarios
para acceder a los datos. Aunque a veces se confunden, son dos conceptos bien distintos:
mientras que la seguridad significa proteger los datos ante usuarios no autorizados
(infiltrados); la integridad significa protegerlos de los autorizados.
El gestor de transacciones
Que asegura que la base de datos quede en un estado consistente a pesar de los fallos del
sistema, y que las ejecuciones de transacciones concurrentes ocurran sin conflictos.
Interfaces de los SGBD
Dentro del apartado de componentes de un SGBD merece una mención los llamados
interfaces amables con el usuario que se presentan con muy diversas formas:
Interfaces basadas en menús
Presentan opciones (menús) que guían al usuario para formular solicitudes
Interfaces gráficas
Presentan los esquemas en forma gráfica pudiendo el usuario especificar una consulta
manipulando el diagrama.
Interfaces basadas en formas
Se presentan al usuario formas para que rellene los espacios vacíos. Suelen ser
transacciones programadas.
Interfaces en lenguaje natural
Permiten interpretar frases en lenguaje natural trasladándolas a consultas de alto nivel.
Generalmente el sistema mantiene un diálogo con el usuario para esclarecer las
solicitudes.
Interfaces para usuarios paramétricos
Son un conjunto de operaciones específicas para realizarlas repetitivamente.
Generalmente se suelen programar las teclas de funciones del teclado para que el
usuario tenga que escribir lo mínimo posible.
Arquitecturas de referencia y operacionales
Entendemos por arquitectura de referencia a la llamada arquitectura de tres esquemas,
propuesta por el llamado Grupo de Estudios en Sistemas de Administración de Bases de
Datos, que definió el estándar conocido como: arquitectura de referencia ANSI/SPARC
(American National Standard Institute / Standards Planning And Requirements
Comitee). Las arquitecturas operacionales son las arquitecturas concretas de SGBD
reales (en el siguiente apartado nos ocuparemos de detallar el SGBD: DB2, como
ejemplo de arquitectura operacional).
Es probable que los sistemas "pequeños" no manejen todos los aspectos de la
arquitectura de referencia. Sin embargo, los SGBD comerciales más conocidos se
ajustan bastante al estándar.
Arquitectura ANSI/SPARC
Hemos de distinguir tres niveles en toda arquitectura ANSI/SPARC:
Nivel físico o de implementación: Los esquemas internos describen la estructura física
de almacenamiento de la base de datos. Este nivel emplea un modelo físico de los datos
y describe todos los detalles para su almacenamiento, así como los medios de acceso a
los datos.
Nivel conceptual o lógico: describe la estructura de la base de datos para una comunidad
de usuarios. el esquema conceptual oculta los detalles de las estructuras físicas de
almacenamiento, y se concentra en describir entidades, tipos de datos, vínculos
(relaciones o dependencias entre datos), operaciones de usuarios y restricciones.
Nivel externo o de vistas: Incluye esquemas externos o vistas de usuario. Cada esquema
externo describe la parte de la base de datos que interesa a un determinado grupo de
usuarios, ocultando a dicho grupo el resto de la base de datos.
La mayoría de los SGBD no distinguen totalmente entre los tres niveles. Así, algunos
incluyen detalles del nivel físico en los esquemas conceptuales. Los esquemas externos
se especifican con el mismo modelo de datos que los del nivel conceptual. Algunos
SGBD permiten utilizar distintos modelos de datos a nivel conceptual y a nivel externo.
Los esquemas no son más que descripciones de los datos. Los verdaderos datos sólo
están en el nivel físico.
Transformaciones
La arquitectura también comprende ciertas transformaciones que determinan la
correspondencia entre las distintas informaciones que manejan los tres niveles
apuntados.
El SGBD debe transformar una petición expresada a nivel externo en su equivalente a
nivel conceptual, y ésta en su equivalente a nivel físico:
La transformación conceptual/interna define la correspondencia entre la vista
conceptual y la base de datos almacenada a nivel interno.
Es posible que en un momento dado sea necesario modificar el esquema interno por la
necesidad de reorganizar ciertos archivos físicos (por ejemplo, crear nuevos archivos de
índices), para así mejorar las operaciones de obtención o modificación. Si la base de
datos aún contiene los mismos datos, no será necesario cambiar los esquemas
(La imagen representa un esquema de las componentes de un SGBD (tomada de [2]))
conceptuales. La independencia física respecto a los datos se refiere a la separación
entre las aplicaciones y la estructura física almacenada, y resuelta más fácil de conseguir
que la independencia lógica.
La transformación externa/conceptual define la correspondencia entre una vista externa
en particular y la vista conceptual. Así por ejemplo, los campos en uno u otro nivel
pueden tener diferentes tipos de datos; los nombres de los registros y campos pueden ser
cambiados en un nivel, sin que se afecten los del otro; varios campos conceptuales
pueden ser combinados en un sólo registro externo; etc.
Podemos cambiar el esquema conceptual para ampliar o reducir la base de datos. Esto
no debe afectar a las vistas que se refieran al resto de datos que no han sido modificados.
Sólo será necesario modificar la definición de la vista y las correspondencias. Los
programas de aplicación que hagan referencias a los elementos del esquema externo,
deberán funcionar igual que antes después de una reorganización lógica del esquema
conceptual. Además, las restricciones podrán modificarse en el esquema conceptual sin
afectar a los esquemas externos.
(Arquitectura ANSI/SPARC (imagen tomada de [2]). SDL es equivalente a DDL)
Por lo tanto, las transformaciones de tipo conceptual/interna son fundamentales para la
independencia física de los datos, y las transformaciones de tipo externa/conceptual son
fundamentales para la independencia lógica de los datos.
Arquitectura operacional: DB2
DB2 es una abreviatura de Database 2. Originalmente fue un sistema relacional de IBM
para el sistema operativo VMS.
Las bases de datos DB2 se pueden utilizar desde programas de aplicación escritos en
COBOL o PL/I (entre otros). Como sublenguaje de datos se tiene el SQL.
Procesamiento de consultas en DB2
Todos los datos se perciben como tablas. Las tablas son de dos tipos: tablas base, que
son los esquemas conceptuales; y vistas, que son tablas virtuales.
Las consultas se hacen en SQL, por lo tanto SQL es también un lenguaje autocontenido
en DB2. Los principales componentes del flujo de la aplicación SQL son:
El precompilador: genera dos tipos de salidas: el programa fuente original donde las
instrucciones SQL son reemplazadas por llamadas en el lenguaje anfitrión (módulo
fuente modificado); y módulos de solicitud a la base de datos (llamados DBRM) que
son instrucciones SQL en forma de árbol sintáctico, que se usan de entrada para el
siguiente proceso.
El enlazador: se utiliza tanto en consultas en forma de aplicaciones ya programadas,
como en consultas ad hoc. En las primeras, se analizan y se optimizan los distintos
DBRM, se compilan produciendo un plan de aplicación. Si la aplicación (como es de
esperar) se ejecuta muchas veces, con este código objeto (obtenido una sola vez), se
amortiza el coste de haber programado la aplicación.
También el enlazador toma el módulo fuente modificado, lo compila y enlaza para
producir el módulo de carga.
El supervisor de la aplicación: con él se controla la ejecución. Al ejecutarse el módulo
de carga el supervisor obtendrá del plan de aplicación la información necesaria, para
solicitar que el gestor de datos almacenados tenga acceso real a la base de datos.
Gestor de datos almacenados: maneja la base de datos física. Este componente actualiza
los índices si es necesario.
Durante el procesamiento de las consultas también se realizan algunas otras funciones,
entre las que destacamos:
La optimización que se realiza por el enlazador consultando en el Catálogo la
información sobre los índices, de manera que la consulta se realizará de forma más
eficiente.
La comprobación de autorización, de la que se ocupa el enlazador, que comprueba si el
usuario está autorizado para llevar a cabo las operaciones incluidas en los módulos
DBRM.
Definición de los datos en DB2
Para crear, eliminar o actualizar las tablas base, los índices y las vistas, disponemos de
las instrucciones correspondientes en SQL.
Por ejemplo, con CREATE TABLE crearemos una tabla, y con ALTER TABLE,
actualizaremos una tabla.
DB2 maneja el concepto de valores nulos, a menos que se explicite el valor NOT NULL.
Manipulación de los datos en DB2
Los datos se pueden manipular mediante un gran número de instrucciones presentes en
SQL. Un ejemplo de consulta sencilla (el esquema conceptual está en la página
siguiente):
SELECT
NSS
FROM
TRABAJA_EN
WHERE
HORAS>40 AND NUMP = 5;
que se corresponde con la consulta: lista el número de la Seguridad Social de los
empleados que trabajaron más de 40 horas en el proyecto 5.
Procesamiento de vistas en DB2
Una vista es una tabla derivada de tablas base o de otras vistas. Las vistas se usan para
referirnos a una tabla (la vista) que se refiere muy a menudo; o que no tiene realidad
física. Así, en vez de combinar las tablas EMPLEADO, TRABAJA_EN y PROYECTO,
cada vez que necesitemos datos de todas ellas juntas, creamos una vista que sea el
resultado de dicha combinación, y que contenga solo los atributos que deseamos obtener
con frecuencia, cumpliéndose ciertas condiciones. Las tablas de entrada se llaman tablas
de definición de la vista:
CREATE VIEW
TRABAJA_EN1 AS SELECT NOMBREE, APELLIDO,
NOMBREP, HORAS
FROM EMPLEADO, PROYECTO, TRABAJA_EN WHERE
EMPLEADO.NSS=TRABAJA_EN.NSS AND NUMP=NUMEROP;
La siguiente consulta:
SELECT
NOMBREE, APELLIDO, NOMBREP
FROM TRABAJA_EN1
WHERE
NOMBREP=’PROYECTO1’;
obtiene la restricción con las columnas indicadas y para el nombre de proyecto indicado.
También puede utilizarse la vista para crear tablas a las que tendrán acceso cierto grupo
de usuarios (mientras que a las tablas base no). De manera, que limitamos los campos, o
les cambiamos los nombres, o combinamos diversas tablas, etc.
Almacenamiento de datos en DB2
DB2 llama espacio de tablas al almacenamiento de las tablas de datos y espacio de
índices al almacenamiento de índices. El segundo se diferencia del primero, entre otras
características, porque se crea automáticamente. Los índices en DB2 son árboles B+.
Características internas de DB2
Seguridad y autorización
Las vistas pueden servir para ocultar datos confidenciales a los usuarios no autorizados.
DB2 tiene un subsistema de autorización que da privilegios específicos a ciertos
usuarios (órdenes GRANT (otorgar) y REVOQUE (denegar). Para que DB2 reconozca
los usuarios legítimos interviene un identificador de autorización llamado AUTHID,
asignado por los administradores del sistema (se verán más detalles en temas siguientes).
Procesamiento de transacciones
DB2 admite, como ya sabemos, instrucciones escritas en un sublenguaje de PL/I. Uno
de los mandatos de dicho sublenguaje es COMMIT (confirmación), que señala que una
transacción se ha llevado a efecto. Este mandato se colocará después de las operaciones
que determinan la transacción. Al ejecutarse se ordena al gestor de transacciones que
confirme la modificación de los datos, haciendo que dicha modificación sea permanente,
dejando de esta manera a la base de datos en un estado consistente (detallaremos más
esta problemática en el tema 42).
Tipos de sistemas
Existen varios criterios de clasificación de los SGBD:
Modelo de datos en el que están basados
Relacionales
Las características más destacables de estos sistemas son:
Los datos son percibidos por el usuario como tablas.
Los operadores disponibles para el usuario son operadores que generan nuevas tablas a
partir de las anteriores. Así, la operación de seleccionar (restringir) obtiene una tabla en
la que sólo aparecen un subconjunto de filas de la tabla sobre la que se opera.
En este tipo de sistemas, la palabra relación se entiende en términos matemáticos, ya
que una relación se define matemáticamente mediante tuplas, y la tuplas son la forma
más usual de expresar los datos que se encuentran en la misma fila de una tabla.
Los sistemas que se basan en el modelo relacional, son los dominantes del mercado
actual de las bases de datos. La mayor parte de la investigación en bases de datos de los
últimos 30 años, se ha basado en este modelo.
Jerárquicos
En estos sistemas, los datos son representados mediante un conjunto de estructuras de
árbol (jerarquías), y los operadores incluyen operadores para apuntadores de recorrido;
es decir, los apuntadores que permiten recorrer el árbol hacia arriba o hacia abajo (en las
relacionales no existen tales apuntadores).
En red
Los datos son representados mediante un conjunto de estructuras de grafo (red), y los
operadores incluyen operadores para apuntadores de recorrido; es decir, los apuntadores
que permiten recorrer el grafo.
Ambos tipos de sistemas: Jerárquicos y en red, se consideran obsoletos (fueron los
primeros que aparecieron cronológicamente). Sin embargo, algunos SGBD comerciales
(como IMS de IBM), son todavía muy utilizados por grandes compañías.
Orientadas a objeto
Por último, incluimos en esta relación a los sistemas de bases de datos orientadas a
objeto. Tienen su origen en los lenguajes de programación orientados a objetos. La idea
fundamental que subyace en estos sistemas es aumentar el nivel de abstracción. El
usuario (cliente), ha de pensar en objetos que contienen operaciones asociadas a los
mismos (de creación, acceso y modificación), en vez de en registros y funciones aparte
que los manipulan. Otra idea interesante subyacente, es la de que unos objetos pueden
ser colecciones de otros (un departamento contiene objetos empleado); así como el
llamado mecanismo de la herencia por el que los subtipos (subclases) heredan atributos
y métodos de sus supertipos (superclases).
Número de sitios en que se encuentra distribuida la base de datos
Centralizados
Generalmente son multiusuarios (soportan más de un usuario accediendo de forma
concurrente al sistema), pero el sistema y la base de datos residen totalmente en un
único sitio.
Distribuidos
Son, por definición, multiusuarios. Los datos están en dispersos en varias bases de datos,
son administrados por varios SGBD, implantados en varias máquinas distintas con
distintos sistemas operativos, y conectadas por varias redes de comunicación.
A su vez, los distribuidos se clasifican en:
Homogéneos: Si el software del sistema es el mismo en todos los sitios.
Heterogéneos: Es la tendencia actual. Requiere el desarrollo de aplicaciones que
permitan comunicar a los distintos sistemas.
La arquitectura (distribución física, en este contexto), de la mayoría de los sistemas
distribuidos recibe el nombre de cliente-servidor.
Enfoque dado a los datos
Tradicional
Los datos representan hechos ciertos, y están recogidos en forma de objetos
almacenados u objetos virtuales (vistas).
Temporales
Contienen datos históricos en vez de datos actuales, es decir, los datos sólo serán
insertados y nunca actualizados o eliminados (a diferencia de los datos instantáneos o
normales, que se actualizan o borran al dejar de ser ciertos). En una base de datos
temporal todos los datos tienen una marca de tiempo. Así, las relaciones serán
temporales, incluyendo cada tupla una marca de tiempo.
Orientados a la lógica
Son capaces, aplicando axiomas deductivos o reglas de inferencia, de deducir o inferir
hechos adicionales a partir de hechos dados en la base de datos.
Estadísticas
Tienen que ver con cuestiones relacionadas con la seguridad de los datos. Permiten
consultas que proporcionan información general (la media de edad de los empleados),
pero no proporcionan información individual (la edad de un empleado).
Bibliografía
[1] Abraham Silberschatz y otros, Fundamentos de bases de datos, Mc Graw Hill, 1998
[2] Date, C.J. Introducción a los Sistemas de Bases de Datos, Addison Wesley, 2001,
(7ª Edición)
[3] Elmasri-Navathe. Fundamentos de Sistemas de Bases de Datos, Addison Wesley,
2000 (2ª Edición).
[4] Georges Gardarin. Bases de datos. Paraninfo, 1990 (2ª edición).
Índice alfabético