Unidad I – Simbología y Definición de los Modelos de Datos

Sistemas  Gestor de Bases de Datos

Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos inter-relacionados y un conjunto de programas para acceder a dichos datos. La colección de datos, normalmente denominada base de datos, contiene información relevante para una empresa. El objetivo principal de un SGBD es proporcionar una forma de almacenar y recuperar la información de una base de datos de manera que sea tanto práctica como eficiente. Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de información. La gestión de los datos implica tanto la definición de estructuras para almacenar la información mas de bases de datos deben proporcionar la fiabilidad de la información almacenada, a pesar de las caídas del sistema o los intentos de acceso sin autorización. Si los datos van a ser compartidos entre diversos usuarios, el sistema debe evitar posibles resultados anómalos.

Conceptos Fundamentales

Entidad

Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

Hay dos tipos de entidades: fuertes y débiles.

Una entidad débil es una entidad cuya existencia depende de la existencia de otra entidad.

Una entidad fuertees una entidad cuya existencia es independiente de la existencia de otra entidad.

Atributo

Una entidad se representa mediante un conjunto de atributos. Los atributos describen propiedades que posee cada miembro de un conjunto de entidades. La designación de un atributo para un conjunto de entidades expresa que la base de datos almacena información similar concerniente a cada entidad del conjunto de entidades; sin embargo, cada entidad puede tener su propio valor para cada atributo. Posibles atributos del conjunto de entidades cliente son id-cliente, nombre-cliente, calle-cliente y ciudad-cliente. En la vida real, habría más atributos, tales como el número de la calle, el número del portal, la provincia, el código postal, y la comunidad autónoma, pero no se incluyen en el ejemplo simple. Posibles atributos del conjunto de entidades préstamo son número-préstamo e importe.

Cada entidad tiene un valor para cada uno de sus atributos. Por ejemplo, una entidad cliente en concreto puede tener el valor 32.112.312 para id-cliente, el valor Santos para nombre-cliente, el valor Mayor para calle-cliente y el valor Peguerinos para ciudad-cliente. El atributo id-cliente se usa para identificar unívocamente a los clientes, dado que no hay más de un cliente con el mismo nombre, calle y ciudad. En los Estados Unidos, muchas empresas encuentran conveniente usar el número seguridad-social de una persona1 como un atributo cuyo valor identifica unívocamente a la persona.

En general la empresa tendría que crear y asignar un identificador a cada cliente. Para cada atributo hay un conjunto de valores permitidos, llamados el dominio, o el conjunto de valores, de ese atributo. El dominio del atributo nombre-cliente podría ser el conjunto de todas las cadenas de texto de una cierta longitud. Análogamente, el dominio del atributo número-préstamo podría ser el conjunto de todas las cadenas de la forma «P-n», donde n es un entero positivo.

Una base de datos incluye así una colección de conjuntos de entidades, cada una de las cuales contiene un número de entidades del mismo tipo. En la Figura 2.1 se muestra parte de una base de datos de un banco que consta de dos conjuntos de entidades, cliente y préstamo. Formalmente, un atributo de un conjunto de entidades

es una función que asigna al conjunto de entidades un dominio. Como un conjunto de entidades puede tener diferentes atributos, cada entidad se puede describir como un conjunto de pares (atributo,valor), un par para cada atributo del conjunto de entidades. Por ejemplo, una entidad concreta cliente se puede describir mediante el conjunto {(id-cliente, 67.789.901), (nombre-cliente, López), (calle-cliente, Mayor), (ciu-dad-cliente, Peguerinos)}, queriendo decir que la entidad describe una persona llamada López que tiene D.N.I. número 67.789.901, y reside en la calle Mayoren Peguerinos. Se puede ver, en este punto, que existe una integración del esquema abstracto con el desarrollo real de la empresa que se está modelando. Los valores de los atributos que describen una entidad constituirán una porción significante de los datos almacenados en la base de datos.

Tipos de atributo.

• Atributos simples y compuestos. En los ejemplos considerados hasta ahora, los atributos han sido simples; es decir, no están divididos en subpartes. Los atributos compuestos, en cambio, se pueden dividir en subpartes (es decir, en otros atributos). Por ejemplo, nombre-cliente podría estar estructurado como un atributo compuesto consistente en nombre, primer-apellido y segundo-apellido. Usar atributos compuestos en un esquema de diseño es una buena elección si el usuario desea referirse a un atributo completo en algunas ocasiones y, en otras, a algún componente del atributo. Se podrían haber sustituido los atributos del conjunto de entidades cliente, calle-cliente y ciudad-cliente, por el atributo compuesto dirección-cliente, con los atributos calle, ciudad, provincia, y código-postal 2. Los atributos compuestos ayudan a agrupar los atributos relacionados, haciendo los modelos más claros. Nótese también que un atributo compuesto puede aparecer como una jerarquía. Volviendo al ejemplo del atributo compuesto dirección-cliente, su componente calle puede ser a su vez dividido en número-calle, nombre-calle y piso. Estos ejemplos de atributos compuestos para el conjunto de entidades cliente se representa en la Figura 2.1.

• Atributos monovalorados y multivalorados. Los atributos que se han especificado en los ejemplos tienen todos un valor sólo para una entidad concreta. Por ejemplo, el atributo número-préstamo para una entidad préstamo específico, referencia a un único número de préstamo. Tales atributos se llaman monovalorados. Puede haber  ocasiones en las que un atributo tiene un conjunto de valores para una entidad específica. Considérese un conjunto de entidades empleado con el atributo número-teléfono. Cualquier empleado particular puede tener cero, uno o más números de teléfono. Este tipo de atributo se llama multivalorado. En ellos, se pueden colocar apropiadamente límites inferior y superior en el número de valores en el atributo multivalorado. Como otro ejemplo, un atributo nombre-subordinado del conjunto de entidades empleado sería multivalorado, ya que un empleado en concreto podría tener cero, uno o más subordinados.

Cuando sea apropiado se pueden establecer límites superior e inferior en el número de valores de un atributo multivalorado. Por ejemplo, un banco puede limitar el número de números de teléfono almacenados para un único cliente a dos. Colocando límites en este caso, se expresa que el atributo número-teléfono del conjunto de entidades cliente puede tener entre cero y dos valores.

• Atributos derivados. El valor para este tipo de atributo se puede derivar de los valores de otros atributos o entidades relacionados. Por ejemplo, sea el conjunto de entidades cliente que tiene un atributo préstamos que representa cuántos préstamos tiene un cliente en el banco. Ese atributo se puede derivar contando el número de entidades préstamo asociadas con ese cliente. Como otro ejemplo, considérese que el conjunto de entidades empleado tiene un atributo edad, que indica la edad del cliente. Si el conjunto de entidades cliente tiene también un atributo fecha-de-nacimiento, se puede calcular edad a partir de fecha-de-nacimiento y de la fecha actual. Así, edad es un atributo derivado. En este caso, fecha-de-nacimiento y antigüedad pueden serlo, ya que representan el primer día en que el empleado comenzó a trabajar para el banco y el tiempo total que el empleado lleva trabajando para el banco, respectivamente. El valor de antigüedad se puede derivar del valor de fecha-comienzo y de la fecha actual. En este caso, fecha-comienzo se puede conocer como atributo base o atributo almacenado. El valor de un atributo derivado no se almacena, sino que se calcula cuando sea necesario.

Relación

Una relación es una asociación entre diferentes enti­dades. Por ejemplo, se puede definir una relación que asocie al cliente López con el préstamo P-15. Esta rela­ción especifica que López es un cliente con el préstamo número P-15. Un conjunto de relaciones es un conjunto de rela­ciones del mismo tipo. Formalmente es una relación matemática con n > = 2 de conjuntos de entidades (posi­blemente no distintos). Si E₁, E₂,…,E_n son conjuntos de entidades, entonces un conjunto de relaciones R es un subconjunto de:

{(e₁, e₂,…,e_n) | e₁ D E₁, e₂ D E₂,…,eD E_n}

n

donde (e₁,e₂,…e_n) es una relación. Considérense las dos entidades cliente y préstamo de la Figura 2.1. Se define el conjunto de relaciones prestatario para denotar la asociación entre clientes y préstamos bancarios que los clientes tengan. Esta aso­ciación se describe en la Figura 2.3.

Cardinalidades

La correspondencia de cardinalidades, o razón de cardinalidad, expresa el número de entidades a las que otra entidad puede estar asociada vía un conjunto de relaciones.

La correspondencia de cardinalidades es la más útil describiendo conjuntos de relaciones binarias, aunque ocasionalmente contribuye a la descripción de conjuntos de relaciones que implican más de dos conjuntos de entidades. Este apartado se centrará en conjuntos de relaciones binarias únicamente. Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de cardinalidades debe ser una de las siguientes:

• Uno a uno. Una entidad en A se asocia con a lo sumo una entidad en B, y una entidad en B se asocia con a lo sumo una entidad en A (véase la Figura).

• Uno a varios. Una entidad en A se asocia con cualquier número de entidades en B (ninguna o varias). Una entidad en B, sin embargo, se puede asociar con a lo sumo una entidad en A (véase la Figura 2.4b).

• Varios a uno. Una entidad en A se asocia con a lo sumo una entidad en B. Una entidad en B, sin embargo, se puede asociar con cualquier número de entidades (ninguna o varias) en A (véase la Figura 2.5a).

•Varios a varios. Una entidad en A se asocia con cualquier número de entidades (ninguna o varias) en B, y una entidad en B se asocia con cualquier número de entidades (ninguna o varias) en A (véase la Figura 2.5b).

La correspondencia de cardinalidades apropiada para un conjunto de relaciones particular depende obviamente de la situación del mundo real que el conjunto de relaciones modelo.

HISTORIA DE LOS SISTEMAS DE BASES DE DATOS

El procesamiento de datos impulsa el crecimiento de los computadores, como ocurriera en los primeros días de los computadores comerciales. De hecho, la automatización de las tareas de procesamiento de datos precede a los computadores. Las tarjetas perforadas, inventadas por Hollerith, se usaron en los principios del siglo xx para registrar los datos del censo de los EE.UU., y se usaron sistemas mecánicos para procesar las tarjetas y para tabular los resultados. Las tarjetas perforadas posteriormente se usaron ampliamente como medio para introducir datos en los computadores.

Las técnicas del almacenamiento de datos han evolucionado a lo largo de los años:

Década de 1950 y principios de la década de 1960. Se desarrollaron las cintas magnéticas para el almacenamiento de datos. Las tareas de procesamiento de datos tales como las nóminas fueron automatizadas, con los datos almacenados en cintas. El procesamiento de datos consistía en leer datos de una o más cintas y escribir datos en una nueva cinta. Los datos también se podían introducir desde paquetes de tarjetas perforadas e impresos en impresoras. Por ejemplo, los aumentos de sueldo se procesaban introduciendo los aumentos en las tarjetas perforadas y leyendo el paquete de cintas perforadas en sincronización con una cinta que contenía los detalles maestros de los salarios. Los registros debían estar igualmente ordenados. Los aumentos de sueldo tenían que añadirse a los sueldos leídos de la cinta maestra, y escribirse en una nueva cinta; esta nueva cinta; se convertía en la nueva cinta maestra.

Las cintas (y los paquetes de tarjetas perforadas) sólo se podían leer secuencialmente, y los tamaños de datos eran mucho mayores que la memoria principal; así, los programas de procesamiento de datos tenían que procesar los datos según un determinado orden, leyendo y mezclando datos de cintas y paquetes de tarjetas perforadas

• Finales de la década de 1960 y la década de 1970. El amplio uso de los discos fijos a finales de la década de 1960 cambió en gran medida el escenario del procesamiento de datos, ya que los discos fijos permitieron el acceso directo a los datos. La ubicación de los datos en disco no era importante, ya que a cualquier posición del disco se podía acceder en sólo decenas de milisegundo. Los datos La ubicación de los datos en disco no era importante, ya que a cualquier posición del disco se podía acceder en sólo decenas de milisegundo. Los datos se liberaron de la tiranía de la secuencialidad. Con los discos pudieron desarrollarse las bases de datos de red y jerárquicas, que permitieron que las estructuras de datos tales como listas y árboles pudieran almacenarse en disco. Los programadores pudieron construir y manipular estas estructuras de datos.

Un artículo histórico de Codd [1970] definió el modelo relacional y formas no procedimentales de consultar los datos en el modelo relacional, y nacieron las bases de datos relacionales. La simplicidad del modelo relacional y la posibilidad de ocultar completamente los detalles de implementación al programador fueron realmente atractivas. Codd obtuvo posteriormente el prestigioso premio Turing de la ACM (Association of Computing Machinery, asociación de maquinaria informática) por su trabajo.

• Década de 1980. Aunque académicamente interesante, el modelo relacional no se usó inicialmente en la práctica debido a sus inconvenientes por el rendimiento; las bases de datos relacionales no pudieron competir con el rendimiento de las bases de datos de red y jerárquicas existentes. Esta situación cambió con System R, un proyecto innovador en IBM Research que desarrolló técnicas para la construcción de un sistema de bases de datos relacionales eficiente. En Astrahan et al. [1976] y Chamberlin et al. [1981] se pueden encontrar excelentes visiones generales de System R. El prototipo de System R completamente funcional condujo al primer producto de bases de datos relacionales de IBM: SQL/DS. Los primeros sistemas de bases de datos relacionales, como DB2 de IBM, Oracle, Ingres y Rdb de DEC, jugaron un importante papel en el desarrollo de técnicas para el procesamiento eficiente de consultas declarativas. En los principios de la década de 1980 las bases de datos relacionales llegaron a competir con los sistemas de bases de datos jerárquicas y de red incluso en el área de rendimiento. Las bases de datos relacionales fueron tan sencillas de usar que finalmente reemplazaron a las bases de datos jerárquicas y de red; los programadores que usaban estas bases de datos estaban forzados a tratar muchos detalles de implementación de bajo nivel y tenían que codificar sus consultas de forma procedimental. Aún más importante, debían tener presente el rendimiento durante el diseño de sus programas, lo que implicaba un gran esfuerzo. En cambio, en una base de datos relacional, casi todas estas tareas de bajo nivel se realizan automáticamente por la base de datos, liberando al programador en el nivel lógico. Desde su escalada en el dominio en la década de 1980, el modelo relacional ha conseguido el reinado supremo entre todos los modelos de datos.

La década de 1980 también fue testigo de una gran investigación en las bases de datos paralelas y distribuidas, así como del trabajo inicial en las bases de datos orientadas a objetos.

•Principios de la década de 1990. El lenguaje SQL se diseñó fundamentalmente para las aplicaciones de ayuda a la toma de decisiones, que son intensivas en consultas, mientras que el objetivo principal de las bases de datos en la década de 1980 fue las aplicaciones de procesamiento de transacciones, que son intensivas en actualizaciones. La ayuda a la toma de decisiones y las consultas reemergieron como una importante área de aplicación para las bases de datos. Las herramientas para analizar grandes cantidades de datos experimentaron un gran crecimiento de uso. Muchos vendedores de bases de datos introdujeron productos de bases de datos paralelas en este periodo, así como también comenzaron ofrecer bases de datos relacionales orientadas a objeto.

•Finales de la década de 1990. El principal acontecimiento fue el crecimiento explosivo de World Wide Web. Las bases de datos se implantaron mucho más extensivamente que nunca antes. Los sistemas de bases de datos tienen ahora soporte para tasas de transacciones muy altas, así como muy alta fiabilidad y disponibilidad 24×7 (disponibilidad 24 horas al día y 7 días a la semana, que significa que no hay tiempos de inactividad debidos a actividades de mantenimiento planificadas). Los sistemas de bases de datos también tuvieron interfaces Web a los datos.

SISTEMAS DE BASES DE DATOS FRENTE A SISTEMAS DE ARCHIVOS

Antes de la llegada de los sistemas de gestión de bases de datos (SGBDs), las organizaciones normalmente han almacenado la información usando tales sistemas.

Mantener información de la organización en un sistema de procesamiento de archivos tiene una serie de inconvenientes importantes:

•Redundancia e inconsistencia de datos. Debido a que los archivos y programas de aplicación son creados por diferentes programadores en un largo período de tiempo, los diversos archivos tienen probablemente diferentes formatos y los programas pueden estar escritos en diferentes lenguajes. Más aún, la misma información puede estar duplicada en diferentes lugares (archivos). Por ejemplo, la dirección y número de teléfono de un cliente particular puede aparecer en un archivo que contenga registros de cuentas de ahorros y en un archivo que contenga registros de una cuenta corriente. Esta redundancia conduce a un almacenamiento y coste de acceso más altos. Además, puede conducir a inconsistencia de datos; es decir, las diversas copias de los mismos datos pueden no coincidir. Por ejemplo, un cambio en la dirección del cliente puede estar reflejado en los registros de las cuentas de ahorro pero no estarlo en el resto del sistema.

•Dificultad en el acceso a los datos. Supóngase que uno de los empleados del banco necesita averiguar los nombres de todos los clientes que viven en el distrito postal 28733 de la ciudad. El empleado pide al departamento de procesamiento de datos que genere dicha lista. Debido a que esta petición no fue prevista cuando el sistema original fue diseñado, no hay un programa de aplicación a mano para satisfacerla. Hay, sin embargo, un programa de aplicación que genera la lista de todos los clientes. El empleado del banco tiene ahora dos opciones: bien obtener la lista de todos los clientes y obtener la información que necesita manualmente, o bien pedir al departamento de procesamiento de datos que haga que un programador de sistemas escriba el programa de aplicación necesario. Ambas alternativas son obviamente insatisfactorias. Supóngase que se escribe tal programa y que, varios días más tarde, el mismo empleado necesita arreglar esa lista para incluir sólo aquellos clientes que tienen una cuenta con saldo de 10.000 Bs. o más. Como se puede esperar, un programa para generar tal lista no existe. De nuevo, el empleado tiene que elegir entre dos opciones, ninguna de las cuales es satisfactoria. La cuestión aquí es que el entorno de procesamiento de archivos convencional no permite que los datos necesarios sean obtenidos de una forma práctica y eficiente. Se deben desarrollar sistemas de recuperación de datos más interesantes para un uso general.

•Aislamiento de datos. Debido a que los datos están dispersos en varios archivos, y los archivos pueden estar en diferentes formatos, es difícil escribir nuevos programas de aplicación para recuperar los datos apropiados.

•Problemas de integridad. Los valores de los datos almacenados en la base de datos deben satisfacer ciertos tipos de restricciones de consistencia. Por ejemplo, el saldo de una cuenta bancaria no puede nunca ser más bajo de una cantidad predeterminada (por ejemplo 25 Bs.). Los desarrolladores hacen cumplir esas restricciones en el sistema añadiendo el código apropiado en los diversos programas de aplicación. Sin embargo, cuando se añaden nuevas restricciones, es difícil cambiar los programas para hacer que se cumplan. El problema es complicado cuando las restricciones implican diferentes elementos de datos de diferentes archivos.

•Problemas de atomicidad. Un sistema de un computador, como cualquier otro dispositivo mecánico o eléctrico, está sujeto a fallo. En muchas aplicaciones es crucial asegurar que, una vez que un fallo ha ocurrido y se ha detectado, los datos se restauran al estado de consistencia que existía antes del fallo. Consideremos un programa para transferir 50 Bs. desde la cuenta A a la B. Si ocurre un fallo del sistema durante la ejecución del programa, es posible que los 50 Bs. Fueron eliminados de la cuenta A pero no abonados a la cuenta B, resultando un estado de la base de datos inconsistente. Claramente, es esencial para la consistencia de la base de datos que ambos, el abono y el cargo tengan lugar, o que ninguno tenga lugar. Es decir, la transferencia de fondos debe ser atómica: ésta debe ocurrir en ellos por completo o no ocurrir en absoluto. Es difícil asegurar esta propiedad en un sistema de procesamiento de archivos convencional.

•Anomalías en el acceso concurrente. Conforme se ha ido mejorando el conjunto de ejecución de los sistemas y ha sido posible una respuesta en tiempo más rápida, muchos sistemas han ido permitiendo a múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un entorno de interacción de actualizaciones concurrentes puede dar lugar a datos inconsistentes. Considérese una cuenta bancaria A, que contiene 500 Bs. Si dos clientes retiran fondos (por ejemplo 50 Bs. y 100 Bs. respectivamente) de la cuenta A en aproximadamente el mismo tiempo, el resultado de las ejecuciones concurrentes puede dejar la cuenta en un estado incorrecto (o inconsistente). Supongamos que los programas se ejecutan para cada retirada y escriben el resultado después. Si los dos programas funcionan concurrentemente, pueden leer ambos el valor 500 Bs., y escribir después 450 Bs. y 400 Bs., respectivamente. Dependiendo de cuál escriba el último valor, la cuenta puede contener bien 450 Bs. o bien 400 Bs., en lugar del valor correcto, 350 Bs. Para protegerse contra esta posibilidad, el sistema debe mantener alguna forma de supervisión. Sin embargo, ya que se puede acceder a los datos desde muchos programas de aplicación diferentes que no han sido previamente coordinados, la supervisión es difícil de proporcionar.

•Problemas de seguridad. No todos los usuarios de un sistema de bases de datos deberían poder acceder a todos los datos. Por ejemplo, en un sistema bancario, el personal de nóminas necesita ver sólo esa parte de la base de datos que tiene información acerca de varios empleados del banco. No necesitan acceder a la información acerca de las cuentas de clientes. Como los programas de aplicación se añaden al sistema de una forma ad hoc, es difícil garantizar tales restricciones de seguridad.

Abstracción de datos

Para que el sistema sea útil debe recuperar los datos eficientemente. Esta preocupación ha conducido al diseño de estructuras de datos complejas para la representación de los datos en la base de datos. Como muchos usuarios de sistemas de bases de datos no están familiarizados con computadores, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema:

•Nivel físico: El nivel más bajo de abstracción describe cómo se almacenan realmente los datos. En el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel.

•Nivel lógico: El siguiente nivel más alto de abstracción describe qué datos se almacenan en la base de datos y qué relaciones existen entre esos datos. La base de datos completa se describe así en términos de un número pequeño de estructuras relativamente simples. Aunque la implementación de estructuras simples en el nivel lógico puede involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Los administradores de bases de datos, que deben decidir la información que se mantiene en la base de datos, usan el nivel lógico de abstracción.

•Nivel de vistas: El nivel más alto de abstracción describe sólo parte de la base de datos completa. A pesar del uso de estructuras más simples en el nivel lógico, queda algo de complejidad, debido a la variedad de información almacenada en una gran base de datos. Muchos usuarios del sistema de base de datos no necesitan toda esta información. En su lugar, tales usuarios necesitan acceder sólo a una parte de la base de datos. Para que su interacción con el sistema se simplifique, se define la abstracción del nivel de vistas. El sistema puede proporcionar muchas vistas para la misma base de datos.

MODELOS DE LOS DATOS

Bajo la estructura de la base de datos se encuentra el modelo de datos: una colección de herramientas conceptuales para describir los datos, las relaciones, la semántica y las restricciones de consistencia. Para ilustrar el concepto de un modelo de datos, se describen dos modelos de datos: el modelo entidad-relación y el modelo relacional. Los diferentes modelos de datos que se han propuesto se clasifican en tres grupos diferentes: modelos lógicos basados en objetos, modelos lógicos basados en registros y modelos físicos.

Base de datos jerárquica

Una Base de datos jerárquica es un tipo de Sistema Gestor de Bases de Datos que, como su nombre indica, almacenan la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de información puede tener varios nodos hijo.

Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden establecerse relaciones entre nodos hermanos. En este caso la estructura en forma de árbol se convierte en una estructura en forma de grafo dirigido. Esta variante se denomina Bases de datos de red.

Las bases de datos jerárquicas fueron concebidas en los años 1960. El primer metamodelo de base de datos propuesto fue la mencionada Base de datos en red, concebida bajo el auspicio de CODASYL (COnference on DAta SYstems Languages). Posteriormente se refinó la idea dando lugar a la base de datos jerárquica. La primera implementación de este metamodelo fue IMS (Information Management System). Se trata de un diseño de IBM y otros colaboradores en 1966 para el Programa Apollo de la NASA. IMS aún se encuentra en activo. El sector de la banca y las Administraciones Públicas adoptaron rápidamente esta tecnología, sin la cual, no hubiese sido posible el grado de automatización que tienen hoy día. Estos sectores eran los únicos con capacidad económica suficiente para adquirir los enormes mainframe para la automatización de bases de datos, única solución posible en la época.

A diferencia del modelo relacional, el modelo jerárquico no diferencia una vista lógica de una vista física de la base de datos. De manera que las relaciones entre datos se establecen siempre a nivel físico, es decir, mediante referencia a direcciones físicas del medio de almacenamiento (sectores y pistas).

Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional. Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type, en inglés), el equivalente a las tablas del modelo relacional.

El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales.

Modelo entidad-relación

El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre estos objetos. Una entidad es una «cosa» u «objeto» en el mundo real que es distinguible de otros objetos. Por ejemplo, cada persona es una entidad, y las cuentas bancarias pueden ser consideradas entidades.

Las entidades se describen en una base de datos mediante un conjunto de atributos. Por ejemplo, los atributos número-cuenta y saldo describen una cuenta particular de un banco y pueden ser atributos del conjunto de entidades cuenta. Análogamente, los atributos nombre-cliente, calle-cliente y ciudad-cliente pueden describir una entidad cliente.

Un atributo extra, id-cliente, se usa para identificar unívocamente a los clientes (dado que puede ser posible que haya dos clientes con el mismo nombre, dirección y ciudad. Se debe asignar un identificador único de cliente a cada cliente. En los Estados Unidos, muchas empresas utilizan el número de la seguridad social de una persona (un número único que el Gobierno de los Estados Unidos asigna a cada persona en los Estados Unidos) como identificador de cliente.

Una relación es una asociación entre varias entidades. Por ejemplo, una relación impositor asocia un cliente con cada cuenta que tiene. El conjunto de todas las entidades del mismo tipo, y el conjunto de todas las relaciones del mismo tipo, se denominan respectivamente conjunto de entidades y conjunto de relaciones.

La estructura lógica general de una base de datos se puede expresar gráficamente mediante un diagrama ER, que consta de los siguientes componentes:

•Rectángulos, que representan conjuntos de entidades.

•Elipses, que representan atributos.

•Rombos, que representan relaciones entre conjuntos de entidades.

•Líneas, que unen los atributos con los conjuntos de entidades y los conjuntos de entidades con las relaciones.

Cada componente se etiqueta con la entidad o relación que representa.

Como se muestra en la figura, considérese parte de una base de datos de un sistema bancario consistente en clientes y cuentas que tienen esos clientes. En la Figura  se muestra el diagrama E-R correspondiente. El diagrama E-R indica que hay dos conjuntos de entidades cliente y cuenta, con los atributos descritos anteriormente. El diagrama también muestra la relación impositor entre cliente y cuenta. Además de entidades y relaciones, el modelo E-R representa ciertas restricciones que los contenidos de la base de datos deben cumplir. Una restricción importante es la correspondencia de cardinalidades, que expresa el número de entidades con las que otra entidad se puede asociar a través de un conjunto de relaciones. Por ejemplo, si cada cuenta puede pertenecer sólo a un cliente, el modelo puede expresar esta restricción.

Modelo relacional

En el modelo relacional se utiliza un grupo de tablas para representar los datos y las relaciones entre ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene un nombre único. En la Figura se presenta un ejemplo de base de datos relacional consistente en tres tablas: la primera muestra los clientes de un banco, la segunda, las cuentas, y la tercera, las cuentas que pertenecen a cada cliente.

La primera tabla, la tabla cliente, muestra, por ejemplo, que el cliente cuyo identificador es 19.283.746 se llama González y vive en la calle Arenal sita en La Granja. La segunda tabla, cuenta, muestra que las cuentas C-101 tienen un saldo de 500 Bs. y la C-201 un saldo de 900 Bs. respectivamente.

La tercera tabla muestra las cuentas que pertenecen a cada cliente. Por ejemplo, la cuenta C-101 pertenece al cliente cuyo identificador es 19.283.746 (González), y los clientes 19.283.746 (González) y 01.928.374 (Gómez) comparten el número de cuenta A-201 (pueden compartir un negocio).

El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en registros se denominan así porque la base de datos se estructura en registros de formato fijo de varios tipos. Cada tabla contiene registros de un tipo particular. Cada tipo de registro define un número fijo de campos, o atributos. Las columnas de la tabla corresponden a los atributos del tipo de registro. No es difícil ver cómo se pueden almacenar las tablas en archivos. Por ejemplo, un carácter especial (como una coma) se puede usar para delimitar los diferentes atributos de un registro, y otro carácter especial (como un carácter de nueva línea) se puede usar para delimitar registros. El modelo relacional oculta tales detalles de implementación de bajo nivel a los desarrolladores de bases de datos y usuarios. El modelo de datos relacional es el modelo de datos más ampliamente usado, y una amplia mayoría de sistemas de bases de datos actuales se basan en el modelo relacional.

El modelo relacional se encuentra a un nivel de abstracción inferior al modelo de datos E-R. Los diseños de bases de datos a menudo se realizan en el modelo E-R, y después se traducen al modelo relacional; Por ejemplo, es fácil ver que las tablas cliente y cuenta corresponden a los conjuntos de entidades del mismo nombre, mientras que la tabla impositor corresponde al conjunto de relaciones impositor. Nótese también que es posible crear esquemas en el modelo relacional que tengan problemas tales como información duplicada innecesariamente. Por ejemplo, supongamos que se almacena número-cuenta como un atributo del registro cliente. Entonces, para representar el hecho de que las cuentas C-101 y C-201 pertenecen ambas al cliente González (con identificador de cliente 19.283.746) sería necesario almacenar dos filas en la tabla cliente. Los valores de nombre-cliente, calle-cliente y ciudad-cliente de González estarían innecesariamente duplicados en las dos filas.

El modelo de datos orientado a objetos

El modelo de datos orientado a objetos es otro modelo de datos que está recibiendo una atención creciente. El modelo orientado a objetos se puede observar como una extensión del modelo E-R con las nociones de encapsulación, métodos (funciones) e identidad de objeto. El modelo de datos relacional orientado a objetos combina las características del modelo de datos orientado a objetos y el modelo de datos relacional. Los modelos de datos semiestructurados permiten la especificación de datos donde los elementos de datos individuales del mismo tipo pueden tener diferentes conjuntos de atributos. Esto es diferente de los modelos de datos mencionados anteriormente, en los que cada elemento de datos de un tipo particular debe tener el mismo conjunto de atributos. El lenguaje de marcas extensible (XML, eXtensible Markup Language) se usa ampliamente para representar datos semiestructurados.

Unidad 1- Evaluación de los Sistemas Operativos

Concepto de Sistemas Operativos

Un sistema operativo es un software de sistema, es decir, un conjunto de programas de computadora destinado a permitir una administración eficaz de sus recursos. Comienza a trabajar cuando se enciende el computador, y gestiona el hardware de la máquina desde los niveles más básicos, permitiendo también la interacción con el usuario.

(Fuente: wikipedia.com)

Conjunto de programas de base que controla al computador y que actúa de intermediario entre el usuario, el computador y los programas de aplicación, traduciendo las órdenes del usuario o de las aplicaciones en instrucciones que puede entender el computador.

(Fuente:profesionaldelainformacion.com)

Funciones básicas de los Sistemas Operativos

Los sistemas operativos, en su condición de capa software que posibilitan y simplifica el manejo de la computadora, desempeñan una serie de funciones básicas esenciales para la gestión del equipo. Entre las más destacables, cada una ejercida por un componente interno (módulo en núcleos monolíticos y servidor en micronúcleos), podemos reseñar las siguientes:

• Proporcionar comodidad en el uso de un computador.

• Gestionar de manera eficiente los recursos del equipo, ejecutando servicios para los procesos (programas)

• Brindar una interfaz al usuario, ejecutando instrucciones (comandos).

• Permitir que los cambios debidos al desarrollo del propio SO se puedan realizar sin interferir con los servicios que ya se prestaban (evolutividad).

Un sistema operativo desempeña 5 funciones básicas en la operación de un sistema informático: suministro de interfaz al usuario, administración de recursos, administración de archivos, administración de tareas y servicio de soporte y utilidades.

(Fuente: wikipedia.com)

Características

• Conveniencia. Un Sistema Operativo hace más conveniente el uso de una computadora.

• Eficiencia. Un Sistema Operativo permite que los recursos de la computadora se usen de la manera más eficiente posible.

• Habilidad para evolucionar. Un Sistema Operativo deberá construirse de manera que permita el desarrollo, prueba o introducción efectiva de nuevas funciones del sistema sin interferir con el servicio.

• Encargado de administrar el hardware. El Sistema Operativo se encarga de manejar de una mejor manera los recursos de la computadora en cuanto a hardware se refiere, esto es, asignar a cada proceso una parte del procesador para poder compartir los recursos.

• Relacionar dispositivos (gestionar a través del kernel). El Sistema Operativo se debe encargar de comunicar a los dispositivos periféricos, cuando el usuario así lo requiera.

• Organizar datos para acceso rápido y seguro.

• Manejar las comunicaciones en red. El Sistema Operativo permite al usuario manejar con alta facilidad todo lo referente a la instalación y uso de las redes de computadoras.

• Procesamiento por bytes de flujo a través del bus de datos.

• Facilitar las entradas y salidas. Un Sistema Operativo debe hacerle fácil al usuario el acceso y manejo de los dispositivos de Entrada/Salida de la computadora.

Los recursos clave que un sistema operativo administra son:

• Los procesadores

• El almacenamiento

• Los dispositivos de entrada / salida

• Los datos

GENERACIONES DE SISTEMAS OPERATIVOS

Generación Cero (década de 1940)

Los sistemas operativos han ido evolucionando durante los últimos 40 años a través de un número de distintas fases o generaciones que corresponden a décadas. En 1940, las computadoras electrónicas digitales mas nuevas no tenían sistema operativo. Las Máquinas de ese tiempo eran tan primitivas que los programas por lo regular manejaban un bit a la vez en columnas de switch’s mecánicos. Eventualmente los programas de lenguaje máquina manejaban tarjetas perforadas, y lenguajes ensamblador fueron desarrollados para agilizar el proceso de programación. Los usuarios tenían completo acceso al lenguaje de la maquina. Todas las instrucciones eran codificadas a mano.

La primera generacion (1945 – 1955 ) : Tubos de vacio y tableros enchufables

Después del fracaso de los trabajos de Babbage, fueron pocos los avances que se lograron en la construcción de computadoras digitales hasta la Segunda Guerra Mundial. A mediados de la década de 1940, Howard Aiken en Harvard, John von Neumann en el Institute for Advanced Study en Princeton, J. Presper Eckert y William Mauchley en la University of Pennsylvania y Konrad Zuse en Alemania, entre otros, lograron construir máquinas calculadoras usando tubos de vacío. Estas máquinas eran enormes, y ocupaban cuartos enteros con decenas de miles de tubos de vacío, pero eran mucho más lentas que incluso las computadoras personales más baratas de la actualidad.

En esos primeros días, un solo grupo de personas diseñaba, construía, programaba, operaba y mantenía a cada máquina. Toda la programación se realizaba en lenguaje de máquina absoluto, a menudo alambrando tableros de conmutación para controlar las funciones básicas de la máquina. No existían los lenguajes de programación (ni siquiera los de ensamblador). Nadie había oído hablar de los sistemas operativos. La forma de operación usual consistía en que el programador se anotaba para recibir un bloque de tiempo en la hoja de reservaciones colgada en la pared, luego bajaba al cuarto de la máquina, insertaba su tablero de conmutación en la computadora, y pasaba las siguientes horas con la esperanza de que ninguno de los cerca de 20000 tubos de vacío se quemara durante la sesión. Prácticamente todos los problemas eran cálculos numéricos directos, como la producción de tablas de senos y cosenos.

A principios de la década de 1950, la rutina había mejorado un poco con la introducción de las tarjetas perforadas. Ahora era posible escribir programas en tarjetas e introducirlas para ser leídas, en lugar de usar tableros de conmutación; por lo demás, el procedimiento era el mismo.

Caracteristicas

• Monitor residente (Carga de programas a memoria)

• Procesamiento por lotes (ejecutar programas uno a continuación de otro)

• Almacenamiento temporal

La segunda generacion (1955 – 1965 ) : Transistores y sistemas de lote

La introducción del transistor a mediados de la década de 1950 alteró el panorama radicalmente. Las computadoras se hicieron lo bastante confiables como para poderse fabricar y vender a clientes comerciales con la expectativa de que seguirían funcionando el tiempo suficiente para realizar algo de trabajo útil. Por primera vez, había una separación clara entre diseñadores, constructores, operadores, programadores y personal de mantenimiento.
Estas máquinas se encerraban en cuartos de computadora con acondicionamiento de aire especial, con equipos de operadores profesionales para operarias. Sólo las grandes empresas, o las principales dependencias del gobierno o universidades, podían solventar el costo de muchos millones de dólares. Para ejecutar un trabajo (es decir, un programa o serie de programas), un programador escribía primero el programa en papel (en FORTRAN o ensamblador) y luego lo perforaba en tarjetas. Después, llevaba el grupo de tarjetas al cuarto de entrada y lo entregaba a uno de los operadores. Cuando la computadora terminaba el trabajo que estaba ejecutando en ese momento, un operador acudía a la impresora, separaba la salida impresa y la llevaba al cuarto de salida donde el programador podía recogerla después. Luego, el operador tomaba uno de los grupos de tarjeta traídos del cuarto de entrada y lo introducía en el lector. Si se requería el compilador de FORTRAN, el operador tenía que traerlo de un archivero e introducirlo en el lector. Gran parte del tiempo de computadora se desperdiciaba mientras los operadores iban de un lugar a otro, en el cuarto de la máquina.

Dado el alto costo del equipo, no es sorprendente que la gente pronto buscara formas de reducir el desperdicio de tiempo. La solución que se adoptó generalmente fue el sistema por lotes. El principio de este modo de operación consistía en juntar una serie de trabajos en el cuarto de entrada, leerlos y grabarlos en una cinta magnética usando una computadora pequeña y (relativamente) económica, como una IBM 1401, que era muy buena para leer tarjetas, copiar cintas e imprimir salidas, pero no para realizar cálculos numéricos. Otras máquinas, mucho más costosas, como la IBM 7094, se usaban para la computación propiamente dicha.

Después de cerca de una hora de reunir un lote de trabajos, la cinta se rebobinaba y se llevaba al cuarto de la máquina, donde se montaba en una unidad de cinta. El operador cargaba entonces un programa especial (el antepasado del sistema operativo actual), que leía el primer trabajo de la cinta y lo ejecutaba. La salida se escribía en una segunda cinta, en lugar de imprimirse. Cada vez que terminaba un trabajo, el sistema operativo leía automáticamente el siguiente trabajo de la cinta y comenzaba a ejecutarlo. Una vez que estaba listo todo el lote, el operador desmontaba las cintas de entrada y salida, montaba la cinta de entrada del siguiente lote, y llevaba la cinta de salida a una 1401 para la impresión fuera de línea (o sea, no conectada a la computadora principal).

Las computadoras grandes de la segunda generación se usaban primordialmente para cálculos científicos y de ingeniería, como la resolución de ecuaciones diferenciales parciales. Estas máquinas generalmente se programaban en FORTRAN y lenguaje ensamblador. Los sistemas operativos típicos eran FMS (el Fortran Monitor System) e IBSYS, el sistema operativo de IBM para la 7094.

Características

• Multiprogramación.

• Multiprocesamiento.

• Ingenierría de Software: Los sistemas operativos desarrollados durante los 60s tuvieron una enorme conglomeración de software escrito por gente quienes realmente no entendía el software, también como el hardware, tenias que ser ingeniero para ser digno de confianza, entendible y mantenible. Finalmente cuando encontraron y removieron algunos errores que nunca pudieron completar el sistema original. Errores en las fases fáciles de los proyectos no fueron localizados antes de un largo tiempo fueron entregados a los clientes; por este lado los errores fueron enormemente grandes para corregir. La gente obtuvo frecuentemente números grandes de módulos de software empezó a ser fragmentado y reescrito por personas nuevas porque existían módulos que realmente no se entendían. Se tomo mas atención a estos problemas eventualmente científicos de la computación y profesionales en la industria comenzaron a dedicar considerables recursos para el problema de construir sistemas de software. La emergencia de el campo de ingeniería de software y el reconocimiento de la importancia del desarrollo de una disciplinada y desarrollada aproximada a la construcción software digno de confianza, entendible y mantenible fuertemente unidos por la vasta experiencia con algunos de los sistemas operativos desarrollados en los 60s.

La tercera generacion (1965 – 1970 ) : Circuitos integrados ( CI ) y multiprogramacion

A principios de la década de 1960, la mayoría de los fabricantes de computadoras tenían dos líneas de producto distintas y totalmente incompatibles. Por un lado estaban las computadoras científicas a gran escala, orientadas hacia las palabras, como la 7094, que se usaban para cálculos numéricos en ciencias e ingeniería. Por el otro, estaban las computadoras comerciales orientadas hacia los caracteres, como la 1401, que los bancos y las compañías de seguros utilizaban amplia- mente para ordenar e imprimir desde cinta.
IBM trató de resolver simultáneamente ambos problemas introduciendo la System/360. La 360 era una serie de máquinas de software compatible que iban desde tamaños comparables a la 1401 hasta computadoras mucho más potentes que la 7094. Las máquinas diferían sólo en el precio y el rendimiento (memoria máxima, velocidad del procesador, número de dispositivos de E/S permitidos, etc.). Puesto que todas las máquinas tenían la misma arquitectura y conjunto de instrucciones, los programas escritos para una máquina podían ejecutarse en todas las demás, al menos en teoría. Además, la 360 estaba diseñada para manejar computación tanto científica como comercial. Así, una sola familia de máquinas podía satisfacer las necesidades de todos los clientes. En años subsecuentes IBM produjo sucesoras comparables a la línea 360, usando tecnología más moderna, conocidas como series 370, 4300, 3080 y 3090.
A pesar de su enorme tamaño y de sus problemas, os/360 y los sistemas operativos de tercera generación parecidos a él producidos por otros fabricantes de computadoras lograron satisfacer a sus clientes en un grado razonable, y también popularizaron varias técnicas clave que no existían en los sistemas operativos de la segunda generación. Tal vez la más importante de ellas haya sido la multiprogramación.

El problema era el tiempo de espera (en computadores cientificos pocos, pero en los comerciales era muy alto)
La solución a la que se llegó fue dividir la memoria en varias secciones, con un trabajo distinto en cada partición. Mientras un trabajo estaba esperando que terminara su E/S, otro podía estar usando la CPU. Si se podían tener en la memoria principal suficientes trabajos a la vez, la CPU podía mantenerse ocupada casi todo el tiempo. Tener múltiples trabajos en la memoria a la vez requiere hardware especial para proteger cada trabajo contra espionaje o p por parte de los demás, pero la 360 y otros sistemas de tercera generación estaban equipados con este hardware.

Otra característica importante presente en los sistemas operativos de la tercera generación era la capacidad de leer trabajos de las tarjetas al disco tan pronto como se llevaban al cuarto de computadoras. Luego, cada vez que un trabajo terminaba su ejecución, el sistema operativo podía cargar uno nuevo del disco en la partición que había quedado vacía y ejecutarlo. Esta técnica se llama spooling (de “operación simultánea de periféricos en línea”) y también se usaba para la salida. Con spooling, las 1401 ya no eran necesarias, y desapareció una buena parte del transporte de cintas.

Característica

• Multiprogramación: alberga a más de un programa en la memoria

• Tiempo compartido: existen varios usuarios con un terminal en línea.

• Tiempo real: Aceptar y procesar en tiempos muy breves un gran número de operaciones.

• Multiprocesador: Trabajar con máquinas que poseen más de un microprocesador. Gracias a esto, el multiprocesador puede ejecutar simultáneamente varios hilos pertenecientes a un mismo proceso o bien a procesos diferentes.

La cuarta generacion (1980 – a nuestros días) : Computadoras personales

Con la invención de los circuitos integrados a gran escala (LSI), chips que contienen miles de transistores en un cm2 de silicio, nació la era de la computadora personal. En términos de arquitectura, las computadoras personales no eran muy diferentes de las minicomputadoras de la clase PDP- 11, pero en términos de precio sí que eran diferentes. Si bien la minicomputadora hacía posible que un departamento de una compañía o universidad tuviera su propia computadora, el chip microprocesador permitía que un solo individuo tuviera su propia computadora personal. Las computadoras personales más potentes empleadas por empresas, universidades e instalaciones del gobierno suelen llamarse estaciones de trabajo, pero en realidad sólo son computadoras personales grandes. Por lo regular estas máquinas están interconectadas mediante una red.
La amplia disponibilidad de la potencia de cómputo, sobre todo la potencia de cómputo altamente interactiva casi siempre acompañada por excelentes gráficos, dio pie al crecimiento de una importante industria productora de software para computadoras personales. Una buena parte de este software era amistoso con el usuario, lo que significa que estaba dirigido a usuarios que no sólo no sabían nada de computación, sino que además no tenían la mínima intención de aprender. Sin duda, esto representaba un cambio drástico respecto al os/360, cuyo lenguaje de control de trabajos, JCL, era tan arcano que llegaron a escribirse libros enteros sobre él.

Dos sistemas operativos dominaron inicialmente el campo de las computadoras personales y las estaciones de trabajo: MS-DOS de Microsoft y UNIX. MS-DOS se usaba ampliamente en la IBM PC y otras máquinas basadas en la CPU Intel 8088 y sus sucesoras, la 80286, 80386 y 80486 (que en adelante llamaremos la 286, 386 y 486, respectivamente) y más tarde la Pentium y Pentium Pro. Aunque la versión inicial de MS-DOS era relativamente primitiva, versiones subsecuentes han incluido características más avanzadas, muchas de ellas tomadas de UNIX. El sucesor de Microsoft para MS-DOS, WINDOWS, originalmente se ejecutaba encima de MS-DOS (es decir, era más un shell que un verdadero sistema operativo), pero a partir de 1995 se produjo una versión autosuficiente de WINDOWS, WINDOWS 95®, de modo que ya no se necesita MS-DOS para apoyarlo. Otro sistema operativo de
Microsoft es WINDOWS NT, que es compatible con WINDOWS 95 en cierto nivel, pero internamente se reescribió desde cero.
El otro competidor importante es UNIX, que domina en las estaciones de trabajo y otras computadoras del extremo alto, como los servidores de red. UNIX es popular sobre todo en máquinas basadas en chips RISC de alto rendimiento. Estas máquinas por lo regular tienen la potencia de cómputo de una minicomputadora, a pesar de estar dedicadas a un solo usuario, por lo que resulta lógico que estén equipadas con un sistema operativo diseñado originalmente para minicomputadoras, a saber, UNIX.
Una tendencia interesante que apareció a mediados de la década de 1980 fue el crecimiento de redes de computadoras personales en las que se ejecutan sistemas operativos de red o sistemas operativos distribuidos. En un sistema operativo de red los usuarios están conscientes de la existencia de múltiples computadoras y pueden ingresar en máquinas re -motas y copiar archivos de una máquina a otra. Cada máquina ejecuta su propio sistema operativo local y tiene su propio usuario o usuarios locales.

(Fuente: Tanenbaum, Andrew,Sistemas Operativos Diseño e Implementacion)

Clasificación de los Sistemas Operativos

Sistemas de tiempo real

Una forma de sistema operativo de propósito especial es el sistema de tiempo real. Se usa un sistema de tiempo real cuando los requisitos de tiempo de la operación de un procesador o del flujo de datos son estrictos; por ello, a menudo se utilizan como dispositivos de control de aplicaciones dedicadas. Los sensores envían datos al computador, el cual debe analizar estos datos y posiblemente ajustar controles a fin de modificar las entradas de los sensores. Los sistemas que controlan experimentos científicos, los que producen imágenes médicas, los de control industrial y algunos sistemas de exhibición son sistemas de tiempo real. Esta clasificación también incluye algunos sistemas de inyección de combustible para motores de automóviles, controladores de aparatos domésticos y sistemas de armamentos. Un sistema operativo de tiempo real tiene restricciones de tiempo fijas bien definidas. El procesamiento debe efectuarse dentro de los intervalos definidos, o el sistema fallará. Por ejemplo, no es conveniente ordenar a un brazo robot que se detenga después de haber chocado con el automóvil que está construyendo. Se considera que un sistema de tiempo real está funcionando correctamente sólo si produce el resultado correcto dentro de los intervalos de tiempo estipulados. Podemos contrastar este requisito con un con un sistema de tiempo compartido, en el que es deseable (pero no obligatorio) responder rápidamente, o con un sistema por lotes, en el que tal vez no haya restricciones de tiempo.

Hay dos tipos de sistemas de tiempo real:

1. Un sistema de tiempo real duro garantiza que las tareas críticas se terminarán a tiempo. Este objetivo requiere que todos los retardos del sistema estén limitados, desde la obtención de datos almacenados hasta el tiempo que el sistema operativo tarda en atender cada solicitud que se le presenta. Tales restricciones de tiempo determinan los recursos que están disponibles en este tipo de sistemas. El almacenamiento secundario de cualquier índole suele estar limitado o ausente, y los datos se almacenan de preferencia en memoria de corto plazo o en memoria sólo de lectura (ROM, read-only memory). La ROM se encuentra en dispositivos de almacenamiento no volátiles que conservan su contenido aun en caso de fallar el suministro de electricidad; casi todos los demás tipos de memoria son volátiles. También está ausente la mayor parte de las funciones avanzadas de los sistemas operativos, ya que tienden a separar al usuario aún más del hardware, y tal separación causa incertidumbre acerca del tiempo que una operación tarda. Por ejemplo, los sistemas de tiempo real casi nunca tiene memoria virtual. Por ello, los sistemas de tiempo real duros son incompatibles con el funcionamiento de los sistemas de tiempo compartido, y no pueden combinarse con ellos. Puesto que ninguno de los sistemas operativos de propósito general existentes apoya la funcionalidad de tiempo real dura.
2. Un tipo menos restrictivo de sistema de tiempo real es el de tiempo real blando, en ql que una tarea de tiempo real crítica goza de prioridad respecto a otras tareas, y conserva es prioridad hasta que se lleva a cabo. Al igual que en los sistemas de tiempo real duros, es preciso limitar los retardos del núcleo; no es posible mantener a una tarea de tiempo real esperando indefinidamente a que el núcleo la ejecute. El tiempo real blando es una meta alcanzable que puede combinarse con otros tipos de sistemas. No obstante, los sistemas de tiempo real blandos tiene una utilidad más limitada que los duros. En vista de que no apoyan el cumplimiento estricto de plazos, es riesgoso utilizarlos en control industrial y robótica, aunque hay varias áreas en las que pueden ser útiles, como multimedia, realidad virtual y proyectos científicos avanzados como como la exploración submarina y planetaria. Estos sistemas requieren características avanzadas de los sistemas operativos que no pueden incluirse en los sistemas de tiempo real duro. La proliferación del uso de funciones de tiempo real blando ha hecho que se incluyan en la mayor parte de los sistemas operativos actuales, incluidas versiones importantes de UNIX.

Sistemas multiprogramación

Aún con el secuenciamiento automático de los trabajos ofrecido por un sistema operativo sencillo por lotes, el procesador está desocupado a menudo. El problema es que los dispositivos de E/S son lentos comparados con el procesador. La figura 2.5 detalla un cálculo representativo. Los números corresponden a un programa que procesa un archivo de registros y ejecuta, en promedio, 100 instrucciones de máquina por cada registro. En este ejemplo, el computador gasta más del 96% del tiempo esperando a que los dispositivos de E/S terminen de transferir sus datos. La figura 2.6 ilustra esta situación. El procesador gasta parte del tiempo ejecutando hasta que encuentra una instrucción de E/S. Entonces debe esperar a que concluya la instrucción de E/S antes de continuar.

Esta ineficiencia no es necesaria. Se sabe que hay memoria suficiente para almacenar el sistema operativo (el monitor residente) y un programa de usuario. Supóngase que hay espacio suficiente para el sistema operativo y tres programas usuarios. Ahora, cuando un trabajo necesite esperar una E/S, el procesador puede cambiar al otro trabajo, que probablemente no estará esperando a la E/S (figura 2.6c). Además, se podría ampliar la memoria para almacenar tres, cuatro o más programas y conmutar entre todos ellos (figura 2.6c). Este proceso es conocido como multiprogramador o multitarea. Éste es el punto central de los sistemas operativos modernos.

Para ilustrar el beneficio de la multiprogramación, considérese un ejemplo basado en uno de Tumer [TURN86]. Sea un computador con 256K palabras de memoria disponible (no utilizadas por el sistema operativo), un disco, una terminal y una impresora. Tres programas, TRABAJO 1, TRABAJ02 y TRABAJOS, son enviados para su ejecución al mismo tiempo . Se suponen unos requisitos mínimos de procesador para el TRABAJ02 y el TRABAJOS y un uso continuado del disco y de la impresora por parte del TRABAJOS. En un sistema sencillo por lotes, estos trabajos serían ejecutados en secuencia. Así pues, el TRABAJO 1 termina en 5 minutos. El TRABAJ02 debe esperar a que transcurran esos 5 minutos y terminar 15 minutos después. El TRABAJOS comienza después de los 20 minutos para terminar SO minutos después del momento en que fue lanzado. Es evidente que hay una infrautilización neta de todos los recursos cuando se promedian los tiempos de uso en el período exigido de SO minutos.

Supóngase ahora que los trabajos se ejecutan concurrentemente en un sistema operativo con monoprogramación. Como hay poca contención de recursos entre los trabajos, cada uno de los tres puede ejecutarse en un tiempo cercano a 1 mínimo mientras coexiste con los otros en el computador (suponiendo que a TRABAJ02 y TRABAJO3 se les adjudica tiempo suficiente de procesador para mantener activas sus operaciones de E/S). El TRABAJO1 requerirá 5 minutos para terminar, pero al finalizar este tiempo, el TRABAJO2 estará terminado en una tercera parte y el TRABAJO3 estará a la mitad. Los tres trabajos habrán terminado dentro de 15 minutos.

Al igual que un sistema sencillo por lotes, un sistema por lotes con multiprogramación tiene que depender de ciertas características del hardware del computador. La característica adicional más notable y útil para la multiprogramación es que el hardware respalde las interrupciones de E/S y el DMA. Con E/S dirigida por interrupciones y con DMA, el procesador puede enviar una orden de E/S para un trabajo y continuar con la ejecución de otro, mientras la E/S es efectuada por el controlador del dispositivo. Cuando termina la operación de E/S, el procesador es interrumpido y el control pasa a un programa de tratamiento de interrupciones del sis-tema operativo. El sistema operativo le pasa entonces el control a otro trabajo.

Los sistemas operativos con multiprogramación son bastante más sofisticados en comparación con los sistemas de monoprogramación o de un solo programa. Para tener varios trabajos listos para ejecutar, éstos deben mantenerse en la memoria principal, lo que requiere cierto tipo de gestión de memoria. Además, si hay varios trabajos listos para ejecutarse, el procesador debe decidir cuál de ellos va a ejecutar, lo que requiere un algoritmo de planificación.

Sistema Multiproceso

Un sistema operativo multiproceso se refiere al número de procesadores del sistema, que es más de uno y éste es capaz de usarlos todos para distribuir su carga de trabajo. Generalmente estos sistemas trabajan de dos formas: simétrica o asimétricamente. Cuando se trabaja de manera asimétrica, el sistema operativo selecciona a uno de los procesadores el cual jugará el papel de procesador maestro y servirá como pivote para distribuir la carga a los demás procesadores, que reciben el nombre de esclavos. Cuando se trabaja de manera simétrica, los procesos o partes de ellos (threads) son enviados indistintamente a cualesquiera de los procesadores disponibles, teniendo, teóricamente, una mejor distribución y equilibrio en la carga de trabajo bajo este esquema.

MULTIPROCESO: Las computadoras que tienen mas de un CPU son llamadas multiproceso. Un sistema operativo multiproceso coordina las operaciones de la computadoras multiprocesadoras. Ya que cada CPU en una computadora de multiproceso puede estar ejecutando una instrucción, el otro procesador queda liberado para procesar otras instrucciones simultáneamente.

Al usar una computadora con capacidades de multiproceso incrementamos su velocidad de respuesta y procesos. Casi todas las computadoras que tienen capacidad de multiproceso ofrecen una gran ventaja.

Los primeros Sistemas Operativos Multiproceso realizaban lo que se conoce como:

Multiproceso asimétrico: Una CPU principal retiene el control global de la computadora, así como el de los otros procesadores. Esto fue un primer paso hacia el multiproceso pero no fue la dirección ideal a seguir ya que la CPU principal podía convertirse en un cuello de botella.

Multiproceso simétrico: En un sistema multiproceso simétrico, no existe una CPU controladora única. La barrera a vencer al implementar el multiproceso simétrico es que los SO tienen que ser rediseñados o diseñados desde el principio para trabajar en u n ambiente multiproceso. Las extensiones de Unix, que soportan multiproceso asimétrico ya están disponibles y las extensiones simétricas se están haciendo disponibles. Windows NT de Microsoft soporta multiproceso simétrico.

Se dice que un thread es la parte activa en memoria y corriendo de un proceso, lo cual puede consistir de un área de memoria, un conjunto de registros con valores específicos, la pila y otros valores de contexto. Un aspecto importante a considerar en estos sistemas es la forma de crear aplicaciones para aprovechar los varios procesadores. Existen aplicaciones que fueron hechas para correr en sistemas monoproceso que no toman ninguna ventaja a menos que el sistema operativo o el compilador detecte secciones de código paralelizable, los cuales son ejecutados al mismo tiempo en procesadores diferentes. Por otro lado, el programador puede modificar sus algoritmos y aprovechar por sí mismo esta facilidad, pero esta última opción las más de las veces es costosa en horas hombre y muy tediosa, obligando al programador a ocupar tanto o más tiempo a la

paralelización que a elaborar el algoritmo inicial.

Sistemas de tiempo compartido

Con el uso de la multiprogramación, el tratamiento por lotes puede llegar a ser bastante eficiente. Sin embargo, para muchas tareas, es conveniente suministrar un modo en que el usuario interactúe directamente con el computador. De hecho, para algunos trabajos, tales como el proceso de transacciones, este modo interactivo es fundamental.

Hoy en día, los requisitos de un servicio de computación interactiva pueden y suelen llevarse a cabo con el empleo de un computador dedicada. Esta opción no estaba disponible en los años 60, cuando la mayoría de los computadores eran grandes y costosas. En su lugar, se desarrollaron las técnicas de tiempo compartido.

Al igual que la multiprogramación permite al procesador manejar varias tareas por lotes al mismo tiempo, la multiprogramación puede también utilizarse para manejar varias tareas in-teractivas. En este último caso, la técnica se conoce como tiempo compartido, porque refleja el hecho de que el tiempo del procesador es compartido entre los diversos usuarios. La técnica básica de un sistema de tiempo compartido es tener a varios usuarios utilizando simultáneamente el sistema mediante terminales, mientras que el sistema operativo intercala la ejecución de cada programa de usuario en ráfagas cortas de cómputo o cuantos (quantum). De esta manera, si hay n usuarios que solicitan servicio a la vez, cada usuario sólo dispondrá, en promedio, de Un de la atención efectiva del computador, sin contar con la sobrecarga del sistema operativo. Sin embargo, dado el tiempo de reacción relativamente lento que tiene el ser humano, el tiempo de respuesta en un sistema correctamente diseñado debería ser comparable al de un computador dedicada.

Tanto la multiprogramación por lotes como el tiempo compartido utilizan multiprogramación.

Uno de los primeros sistemas de tiempo compartido que se desarrollaron fue el Sistema Compatible de Tiempo Compartido (CTSS, Compatible Time-Sharing System) [CORB62, CORB63], desarrollado en el MIT por un grupo conocido como Proyecto MAC (Machine-Aided Cognition, Multiple-Access Computers)3. El sistema fue desarrollado primero para una IBM 709 en 1961 y luego pasado a una IBM 7094.

Comparado con sistemas posteriores, el CTSS era bastante primitivo y su funcionamiento básico es fácil de explicar. El sistema se ejecutaba en una máquina con una memoria de 32K palabras de 36 bits, con un monitor residente que consumía 5K del total. Cuando había que asignar el control a un usuario interactivo, el programa del usuario y los datos eran cargados en las restantes 27K de la memoria principal. Un reloj del sistema generaba interrupciones a razón de aproximadamente una cada 0,2 segundos (sg). En cada interrupción de reloj, el sistema operativo se adueñaba del control y le podía asignar el procesador a otro usuario. De esta manera, a intervalos regulares, el usuario en curso era expulsado y se cargaba otro usuario en su lugar. Para conservar el estado del usuario anterior, para su reanudación posterior, los programas del usuario anterior y sus datos eran escritos en el disco antes de leer los programas del nuevo usuario y sus datos. En consecuencia, el espacio de memoria del usuario anterior debía ser restaurado cuando le llegara de nuevo su tumo.

Para minimizar el tráfico en el disco, la memoria del usuario se escribía a disco sólo cuando el nuevo programa a cargar podía sobrescribirla. Este principio se ilustra en la figura. Supóngase que hay cuatro usuarios interactivos con los siguientes requisitos de memoria:

• TRABAJO1: 15K
• TRABAJO2: 20K
• TRABAJO3: 5K
• TRABAJO4: I0K

Al principio, el monitor carga el TRABAJOl y le transfiere el control (figura a). Pos-teriormente, el monitor decide transferir el control al TRABAJ02. Puesto que el TRABAJ02 requiere más memoria que el TRABAJOl, éste debe sacarse primero, para luego cargar el TRABAJ02 (figura b). A continuación, se carga el TRABAJO3 para ser ejecutado. Sin embargo, como el TRABAJO3 es más pequeño que el TRABAJ02, entonces una parte del TRABAJ02 puede quedarse en la memoria, lo que reduce el tiempo de escritura en el disco (figura c). Más tarde, el monitor decide transferir de nuevo el control al TRABAJOl. Una parte adicional del TRABAJ02 debe sacarse cuando el TRABAJOl se cargue de nuevo a memoria (figura d). Cuando se cargue el TRABAJ04, parte del TRABAJOl y de la parte remanente del TRABAJO2 se retienen en memoria (figura e). En este punto, tanto si el TRABAJOl como el TRABAJO2 son activados, sólo se necesita una carga parcial. En este ejemplo es el TRABAJ02 el que se ejecuta a continuación. Esto exige que se saquen el TRABAJ04 y la parte remanente que estaba residente del TRABAJOl, para que se pueda leer la parte que falta del TRABAJ02.

El enfoque del CTSS era muy primitivo, si se compara con los sistemas actuales de tiempo compartido, pero funcionaba. Era extremadamente simple, lo que minimizaba el tamaño del monitor. Como un trabajo siempre se cargaba en las mismas posiciones de memoria, no había necesidad de utilizar técnicas de reubicación durante la carga (que se discutirán más adelante). La técnica de escribir en el disco sólo cuándo era necesario minimizaba la actividad con el disco. Ejecutado sobre una 7094, el CTSS daba soporte a un máximo de 32 usuarios.

El tiempo compartido y la multiprogramación plantean una multitud de problemas nuevos para el sistema operativo. Si hay varios trabajos en memoria, entonces deben protegerse de injerencias unos de otros, como, por ejemplo, que uno modifique los datos de otro. Con varios usuarios interactivos, el sistema de archivos debe protegerse de forma que sólo los usuarios autorizados puedan tener acceso a un archivo en particular. La contención de recursos tales como la impresora y los dispositivos de almacenamiento masivo debe estar controlada.

Sistemas para Redes Multiusuarios

Es todo lo contrario a monousuario; y en esta categoría se encuentran todos los sistemas que cumplen simultáneamente las necesidades de dos o más usuarios, que comparten mismos recursos. Este tipo de sistemas se emplean especialmente en redes.

En otras palabras consiste en el fraccionamiento del tiempo (timesharing).

Al igual que un equipo no puede trabajar sin un sistema operativo, una red de equipos no puede funcionar sin un sistema operativo de red. Si no se dispone de ningún sistema operativo de red, los equipos no pueden compartir recursos y los usuarios no pueden utilizar estos recursos.

Dependiendo del fabricante del sistema operativo de red, tenemos que el software de red para un equipo personal se puede añadir al propio sistema operativo del equipo o integrarse con él.

NetWare de Novell es el ejemplo más familiar y famoso de sistema operativo de red donde el software de red del equipo cliente se incorpora en el sistema operativo del equipo. El equipo personal necesita ambos sistema operativos para gestionar conjuntamente las funciones de red y las funciones individuales.

El software del sistema operativo de red se integra en un número importante de sistemas operativos conocidos, incluyendo Windows 2000 Server/Professional, Windows NT Server/Workstation, Windows 95/98/ME y Apple Talk.

Cada configuración (sistemas operativos de red y del equipo separados, o sistema operativo combinando las funciones de ambos) tiene sus ventajas e inconvenientes. Por tanto, nuestro trabajo como especialistas en redes es determinar la configuración que mejor se adapte a las necesidades de nuestra red.

Multitarea

Un sistema operativo multitarea, como su nombre indica, proporciona el medio que permite a un equipo procesar más de una tarea a la vez. Un sistema operativo multitarea real puede ejecutar tantas tareas como procesadores tenga. Si el número de tareas es superior al número de procesadores, el equipo debe ordenar los procesadores disponibles para dedicar una cierta cantidad de tiempo a cada tarea, alternándolos hasta que se completen las citadas tareas. Con este sistema, el equipo parece que está trabajando sobre varias tareas a la vez.