BASES DE DATOS

STANDARD

INDICE

Portada.........................................................................................................1

Indice............................................................................................................2

Estandarizacion de las bases de datos........................................................3

Arquitectura ANSI/X3/SPARC y el modelo conceptual................................8

Definición de Base de datos.........................................................................10

Manipulación de las Bases de datos............................................................11

Modelos de referencia ANSI........................................................................14

Introducción O.S.I..........................................................................................21

Teoría de la normalizacion............................................................................30

LA ESTANDARIZACION DE LAS BASES DE DATOS

Desde comienzos de los años setenta, diversos grupos de informáticos se han ocupado del tema de la estandarización de las bases de datos, entre ellos son dignos de destacar el Grupo Guide/Share de usuarios de equipos IBM, el Club de Banco de Datos del INRIA (Institut National de Recher che en Informatique et Automatique) y algunos comités nacionales de estandarización como el GESC canadiense o el BSI británico, entre otros. Sin embargo, las dos principales instituciones que han trabajado en la normalización de las bases de datos, cuyos estudios han tenido una amplia transcendencia y han influido considerablemente a nivel práctico en la in- vestigación y desarrollo de los sistemas de gestión de bases de datos son el grupo Codasyl y el ANS1/X3/SPARC, además de ISO, cuya actividad en este campo se ha intensificado últimamente.

La oportunidad y conveniencia de la estandarización de los sistemas de gestión de bases de datos es un tema controvertido, ya que una prematura fijación de estándares puede coartar posteriores desarrollos. Una normalización a posteriori tendría una incidencia favorable en el desarrollo de las bases de datos al no introducir cortapisas que dificulten el avance en distintas direcciones, pero será muy difícil (más bien imposible) imponer en la práctica unas normas a sistemas que han sido ya desarrollados y se encuentran en el mercado. Por el contrario, una estandarización previa orientará a los diseñadores y será más fácil de aplicar, pero probablemente no dejará que surjan nuevas ideas y será un freno a la imaginación de los creadores de SGBD.

Tal dilema, que no es privativo de las bases de datos, exige cautela en todo proceso de estandarización, a fin de conseguir el oportuno balance entre los pros y los contras de dicho proceso. Creemos, sin embargo, que la tecnología de las bases de datos está ya lo suficientemente madura para admitir una estandarización que, en nuestra opinión, ya se ha dilatado bastante más de lo debido.

La estandarización tiene como objetivo proteger las inversiones y defender la independencia del usuario frente a los suministradores de SGBD. Los estándares, por tanto, se concretan en especificaciones de cara al usuario, o sea, en el interfaz del sistema con el entorno, sin que en ningún caso impongan la forma en que se debe instrumentar el sistema, ya que este tema se deja por completo en manos del diseñador, que será quien se ocupe de conseguir un diseño óptimo en lo que se refiere a rendimiento operativo y a ahorro de recursos.

Las especificaciones de Codasyl, que definen y detallan los lenguajes de descripción y de manipulación de los SGBD, han sido aplicadas en mayor o menor medida a diversos SGBD comerciales, aun cuando constructores importantes, en especial IBM, nunca han seguido dicha normativa.

La historia de Codasyl, que inició sus tareas a principios de los años sesenta, y publicó diversos informes con sucesivas revisiones, será estudiada junto con sus principales propuestas cuando se analice el modelo de datos Codasyl y sus lenguajes de descripción

Y ANSI/X3/SPARC es un grupo de estudio del Standard Planning and Requirements Committee (SPARC) del ANSI (American National Standards Institute), dentro del Comité X3, que se ocupa de ordenadores e informática. La situación del Grupo de Estudio sobre Sistemas de Gestión de Bases de Datos en el ANSI y su relación con ISO (International Standards Organization)

Por su parte, los organismos de estandarización internacionales ISO (International Organisation for Standarisation) e IEC (International Elec-trotechnical Commission) han establecido para las tecnologías de la información un comité conjunto denominado JTC1 (Joint Technical Commit-tee). Dentro de este comité (véase Figura 4.4) hay una serie de subcomités, entre los que destaca el SC 21 dedicado a los sistemas abiertos. Dentro de los subcomités existen grupos de trabajo que se dedican a distintos temas; en concreto, dentro del SC 21 existen varios grupos de trabajo, entre los que se encuentra el WG 3, dedicado a las bases de datos.

Este grupo de trabajo internacional, en el que se integran representantes de los organismos oficiales de estandarización de distintos paises (en España, AENOR CTN 71/SC 21/ GT 3, ya que la estructura nacional es paralela a partir del CTN 71, que corresponde al JTC 1), se dedica a cuatro proyectos principales:

• Lenguajes de bases de datos, en especial el SQL

• Modelos de referencia

• Acceso remoto a datos

• Sistemas de diccionarios de recursos de información

El Comité ANSI/X3/SPARC desde muy finales de los años sesenta era consciente de la importancia creciente de los SGBD y de la necesidad de investigar sobre ellos, pero hasta el otoño de 1972 no se decidió a iniciar sus tareas en este campo, respondiendo a la necesidad, claramente percibida, de racionalizar la creciente confusión y abordar el trabajo con vistas a una potencial normalización. Se estableció un grupo de estudio ad hoc que, sabiendo que una normalización a destiempo puede fácilmente constituir un freno para los avances tecnológicos, se propuso como objetivo estudiar qué aspectos de los SGBD, si los había, podían ser en aquellos momentos candidatos a una estandarización y emitir un conjunto de recomendaciones para una acción en tales áreas. Se produjeron una serie de informes parciales, hasta que en el año 1975 se llegó al informe provisional (interim reporf), ampliamente difundido y discutido, en el que se presentaba una arquitectura de un sistema de gestión de bases de datos que incluía la identificación y descripción de sus múltiples interfaces. La finalidad de este informe era presentar un marco para el análisis y refinamiento de dicha arquitectura y de sus interfaces. En el año 1977 se publicó el informe final, en el que se detalla el análisis de la arquitectura y de algunos de los 42 interfaces que habían sido identificados.

En 1979, el National Bureau of Standards contrató a la CCA (Com-puter Corporation of América) para desarrollar una arquitectura basada en los estándares que se habían especificado para los SGBD. En 1982, el DAFTG (Datábase Architecture Framework Task Group) del DBSSG (Datábase System Study Group) de ANS1/SPARC propuso una arquitectura que incorpora un entorno distribuido. Por último, en 1985, el citado grupo publicó un informe final proponiendo un modelo de referencia (MR) para la estandarización de los SGBD.

A diferencia de las primitivas especificaciones del grupo CODASYL (1971); que establecían solamente dos estructuras, lógica y física, el grupo de estudio ANSI/X3/SPARC, en sus propuestas de normalización del año 1977 [ANSI (1977)] e incluso en su informe provisional [ANSI (1975)], Íntroduce en la arquitectura de bases de datos un tercer nivel, el conceptual, que se interpone entre las dos estructuras anteriores ayudando a conseguir el objetivo de independencia. También el grupo Codasyl, en otro informe posterior que vio la luz en el año 1978 [CODASYL (1978)] presenta la arquitectura a tres niveles. El club de banco de datos del INRIA (1973) y el grupo GUIDE/SHARE de usuarios de IBM [GUIDE (1970)] con anterioridad a las propuestas de ANSI distinguen los tres niveles en la arquitectura de bases de datos, aunque su terminología es distinta y existen asimismo diferencias en la definición de los niveles.

CLUB BANQUE DE

ANSI/SPARC CODASYL DONNEES (1NR1A) GUIDE/SHARE

EXTERNO ..............SUBESQUEMA........LOGICO...............................LOGICO CONCEPTUAL.......ESQUEMAR.............VIRTUAL .............................ENTIDAD

INTERNO...............ESQUEMA ...............FISICO.................................ALMACENADO-

DE ALMACENAMIENTO

ARQUITECTURA ANSI/X3/SPARC Y EL MODELO CONCEPTUAL

La arquitectura a tres niveles del grupo ANSI, con su esquema conceptual, ha marcado una clara línea de investigación en el campo de las bases de datos. Aun cuando en trabajos y propuestas de normalización anteriores ya se había indicado la conveniencia de separar los tres niveles de estructuras, ninguno de estos estudios había tenido un impacto semejante al del esquema conceptual de ANSI. Consideramos, por tanto, de interés presentar dicha arquitectura.

Una de las primeras tareas del grupo de estudio consistió en buscar una terminología común e intentar desarrollar un vocabulario consistente y comprensible. Otro trabajo que se abordó desde las primeras etapas fue el análisis de los componentes

La arquitectura ANSI/X3/SPARC está parcialmente basada en el concepto de máquinas anidadas (lo que se llama a veces tipo cebolla). El flujo de datos pasa a través de las distintas capas, que están separadas por inter-faces y cuyas funciones se describen con cierto detalle en el documento. Los múltiples interfaces, cuyo número se ha considerado excesivo, tienden a aislar los diversos componentes del sistema con vistas a conseguir el objetivo de independencia.

En la arquitectura propuesta (ver Figura 4.6) se distinguen dos partes, la superior, para la definición de la base de datos, y la inferior, para su manipulación.

En esta arquitectura se definen distintas funciones: humanas, representadas en la Figura por hexágonos; funciones de programa, que se presentan por medio de rectángulos; interfaces, que se representan mediante líneas y para cuya instrumentación el informe no dicta ninguna norma, pu-diendo ser, por tanto, interfaces físico, lógico, microprogramador, etc., y metadatos o diccionario de datos, representado por medio de un triángulo y que tiene un papel fundamental en esta arquitectura.

Definición de la base de datos. La parte de definición se facilita por medio de una serie de funciones de programa e interfaces, dando lugar a un conjunto de datos llamados metadatos (datos acerca de los datos) que se almacenan en el diccionario anteriormente citado. Este diccionario de datos es el eje principal de la arquitectura alrededor del cual giran los demás elementos.

Una base de datos se define especificando primeramente el esquema conceptual a través del interfaz 1, que podría ser un lenguaje de definición del esquema conceptual —o bien una herramienta CASE integrada—. Este esquema conceptual es compilado por el procesador del esquema conceptual y se almacena por medio del interfaz 2 en la metabase de datos.

El procesador del esquema conceptual es capaz de mostrar la información acerca del esquema conceptual utilizando el interfaz 3, que podría consistir, por ejemplo, en un conjunto de menús. Utilizando esta información pueden definirse los esquemas externo e interno a través de los interfaces 4 y 13, que serían controlados por los procesadores correspondientes y almacenados en la base de datos a través de los interfaces 5 y 14. Estos tres tipos claramente diferenciables de esquemas llevan a ANSI/SPARC a proponer la existencia de tres tipos de administradores: El administrador

de la empresa, el administrador de la base de datos y el administrador de las aplicaciones.

Estas tres clases de administración distintas no presuponen tres administradores diferentes; puede ser la misma persona (o grupo) la que asuma las diversas funciones, pero con conciencia de que existe esta triple funcionalidad.

Manipulación de la base de datos. El usuario puede entonces manipular (insertar, borrar, modificar y seleccionar) los datos utilizando el in-terfaz 12, que podría ser un lenguaje de manipulación, como SQL, QUEL... Una petición de datos por parte del usuario es ejecutada por los transformadores conceptual/externo, interno/conceptual y almacenamiento/interno, que utilizan los metadatos por medio de los interfaces 38, 36 y 34, respectivamente. La solicitud del usuario en el interfaz 12 la convierten los transformadores en peticiones a las interfaces 31, 30 y 21, que devuelven el resultado al usuario. Estos últimos interfaces constituirían la función de vínculo (binding) entre los distintos niveles (conceptual, interno y de almacenamiento).

Los interfaces los suministra el SGBD, pero ANSI no especifica la forma de instrumentación; insistimos en que podrían estar instrumentados de las diversas formas antes citadas.

Es importante [Yormark, (1977)] saber de qué forma una arquitectura: — Permite que el sistema de información evolucione fácilmente.

— Ayuda a una utilización óptima del ordenador y de los recursos humanos.

— Preserva las inversiones de la empresa en los programas existentes, los cuales, lógicamente, son correctos de cara a una reestructuración de la base de datos.

La arquitectura a tres niveles de ANSI/SPARC responde positivamente a estas exigencias, ya que el nivel conceptual ha de ser flexible ante la evolución por cambios en la empresa, siempre que éstos no sean tan drásticos que obliguen a un diseño totalmente nuevo de la estructura conceptual; los cambios en la estructura conceptual serán admitidos por el SGBD, que proporcionará nuevas funciones de correspondencia (mapping) de forma que los programas de usuario no adviertan siquiera que dichos cambios se han producido. De igual modo, el añadir vistas externas que permitan abordar nuevas funciones de la empresa o el introducir cambios en el esquema interno sólo afectará a los procesadores del SGBD, que mediante los correspondientes interfaces tendrán que modificar las funciones de correspondencia adaptándolas a las nuevas circunstancias. De esta forma, la arquitectura ANSI/SPARC responde a las exigencias de evolución del sistema de información, ayudando a una mejor utilización de los recursos (humanos y de máquina) y preservando las inversiones realizadas.

Se habla mucho de la próxima generación de SGBD, sin embargo hasta ahora la arquitectura a tres niveles no se ha impuesto totalmente, y muchos de los sistemas actuales no responden claramente a una arquitectura triesquemática como la propuesta por ANSI. En un plano comercial no se advierte aún la incidencia real que cabía esperar de las propuestas de estandarización; únicamente el lenguaje relacional de datos SQL se está introduciendo en la inmensa mayoría de los nuevos SGBD, e incluso sistemas semirelacionales están ofreciendo, junto con sus propios lenguajes, el SQL estándar.

De todas formas, en nuestra opinión, el marco a tres niveles presentado por ANSI/SPARC está teniendo un fuerte, aunque gradual, impacto en la arquitectura de los sistemas de bases de datos, por lo que su comprensión por parte de los técnicos que tienen a su cargo la gestión de datos, reviste un interés fundamental.

El estudio no es, sin embargo, completo ni está totalmente terminado, y el Grupo ANSI ha hecho varias llamadas a la comunidad de usuarios de bases de datos, estimulándolos a que presenten sus ideas y sus demandas, abriendo nuevos caminos de investigación.

Además de las críticas a que ha dado lugar el elevado número de interfaces, esta arquitectura deja bastantes cuestiones por resolver, en especial con referencia al modelo conceptual y a los metadatos, como: ¿Son los metadatos diferentes de los datos? ¿Se almacenan separadamente? ¿Se describen de forma distinta? ¿Existen interfaces distintas para los metadatos?, etc. A estas y otras preguntas tratan de responder otros informes surgidos posteriormente y que se describen en el siguiente epígrafe.

MODELOS DE REFERENCIA DE ANSI

La organización ANSI/X3/SPARC sacó a la luz en mayo de 1985 un informe del DBSG (DataBase System Study Group) en donde se presentaba un modelo de referencia (MR) para la estandarización de los SGBD que fue publicado en Sigmod Record, VoL 15, No 1; marzo, 1986.

Se entiende por MR, según dicho informe, una estructura conceptual que facilita el trabajo de estandarización, identificando una serie de componentes y viendo cómo se interrelacionan.

El informe comienza exponiendo un conjunto de objetivos que el MR pretende alcanzar, entre los cuales queremos destacar el de formación: el MR, al presentar un marco común para la descripción de los SGBD, facilita su estudio y análisis de forma sistemática.

Además de este objetivo (para nosotros fundamental) el MR se propone ayudar en la labor de estandarización, para impulsar la compatibilidad de los distintos componentes de los SGBD, para facilitar la comparación y evaluación de sistemas de gestión de bases de datos, etc.

Para alcanzar estos objetivos de manera eficaz, el MR debe cumplir unos requisitos, como son: la adaptación al desarrollo tecnológico (micro SGBD, Bases de Datos Distribuidas (BDD), nuevas arquitecturas), la unificación de los modelos de datos, la compatibilidad con otro modelos de referencia y estándares, simplificación de la arquitectura ANSI/SPARC, etc. Como resultado de estos objetivos y requisitos, el MR proporciona una serie de beneficios, tanto en la portabilidad de las aplicaciones como en la productividad de la empresas.

El MR, que no es por si mismo un estándar pero sienta las bases para futuras estandarizaciones, se contempla, en el informe desde tres puntos de vista distintos: el de los componentes que integran un SGBD, el de las funciones que se deben especificar y el de los datos que se deben describir y utilizar.

El enfoque de los componentes consiste en dividir el SGBD en piezas que, al tener interfaces, podrían ser adquiridas a distintos suministradores buscando un objetivo de compatibilidad entre los varios módulos de un SGBD, y de compatibilidad en el mercado (estrategia de sistemas abiertos). Este es el enfoque que habría de aplicarse en el diseño de un SGBD, mientras que el de funciones es más apropiado cuando se trata de analizar un SGBD.

El MR está basado en la arquitectura ANSI/SPARC que se ha visto en el epígrafe anterior, pero dado el elevado número de interfaces de la primitiva arquitectura y su excesiva complejidad, en el MR se revisa este aspecto con fines de simplificación, ocupándose del qué, por qué y para qué, pero nunca del cómo, es decir, el objetivo es describir las interrelaciones del SGBD, pero no indicar nada acerca de su instrumentación. También el MR intenta contestar algunas de las preguntas acerca de los metadatos y de su naturaleza que, como hemos visto, la arquitectura ANSI del 75 deja sin responder.

El MR, en el que se distingue el sistema de control de transformación de datos (SCTD), que es el núcleo (kernef) del SGBD y que provee operadores para la descripción y manipulación de datos. También se distinguen dos tipos de interfaces:

— el interfaz de lenguaje de datos (LD), que permite a los usuarios y a los procesadores especificar sus peticiones para la recuperación de los datos por el SGBD.

— el interfaz de lenguaje de datos interno (LD-i), que permite el uso de los servicios de los procesadores que soportan el funcionamiento de los SGBD, en especial los del SO.

En el entorno del SGBD destacan las herramientas de gestión de datos (HGD), que son componentes de soporte lógico, como los lenguajes de cuarta generación (L4G), soporte para ayuda a la decisión, facilidades para realizar el ajuste (tuning), utilidades para el volcado de ficheros, sistemas de diccionario de datos, etc.

El informe llama la atención sobre la necesidad de que el SGBD facilite a cada tipo de usuario los instrumentos precisos para que pueda realizar su trabajo.

Se destaca en el informe el conflicto entre las facilidades para los usuarios y la eficiencia de los procesadores, recomendando para resolverlo un único interfaz eficiente para los procesadores e instrumentar sobre él una serie de interfaces amistosos destinados a los usuarios finales.

Otra recomendación importante que es preciso destacar es la que aconseja que todos los datos relacionados con el control centralizado de la BD (reglas de integridad y de seguridad) deben encontrarse en la metabase y no se deben dejar en manos de los usuarios (sean éstos finales o progra-madores).

Respecto al núcleo (kernel) del SGBD, está soportado en un modelo de datos (sin especificar ninguno en concreto). El MR presenta un análisis bidimensional de los datos atendiendo a dos aspectos:

— dimensión del punto de vista: Constituye la arquitectura a tres niveles que se ha tratado anteriormente, pero bastante simplificada.

• dimensión intensión/extensión: Presenta cuatro niveles para la descripción de los datos, donde cada nivel es la extensión (datos) del nivel superior y, al mismo tiempo, la intensión (esquema) del nivel inferior.

Esta dimensión de intensión/extensión, que en nuestra opinión es posiblemente la parte más original del informe, considera que cualquier me-tadato o esquema, es a su vez (en su extensión), un conjunto de datos que puede ser considerado como una BD, con su correspondiente descripción.

Esta descripción recursiva nos lleva a una jerarquía de niveles de esquemas, el más alto de los cuales ha de quedar embebido en el equipo lógico.

La autodescripción, resultado de extender la arquitectura ANSI/SPARC, es uno de los conceptos clave del MR.

Termina el informe con unas conclusiones que más bien podrían considerarse como un resumen y con dos recomendaciones referidas a la estandarización de cada uno de los dos interfaces, LD y LD-i, a fin de conseguir así una clara separación entre las herramientas de gestión de datos (HGD) y el núcleo del SGBD, y entre éste y el sistema operativo (SO). Todo ello con objeto de proporcionar al usuario una mayor libertad e independencia frente a los suministradores.

Asimismo, se realiza en el informe un análisis de las funciones de un SGBD a los cuatro niveles de la descripción recursiva. Las funciones se considera que pueden ser de tres tipos distintos.

Se describe también un conjunto de herramientas para la administración, así como la interacción con el SO. Se llama la atención sobre las duplicidades que existen en la actualidad entre los SGBD y los SO, expresándose el deseo de que los diseñadores del futuro sean más sensibles respecto a este problema y traten de evitar esta duplicación de funciones que tan perjudicial resulta.

Posteriormente, en junio de 1988, otro subgrupo del DBSSG, el UFTG (User Facility Task Group) ha propuesto un modelo de referencia para facilidades de usuario (MRFU) que puede considerarse como una prolonga-ción (véase Figura 4.9) del modelo de referencia descrito anteriormente, y que fue publicado en Sigmod Record, Vol. 17, Nº 2; junio, 1988.

Basándose en modelos gráficos, de psicología cognitiva, tecnología de las bases de datos, de informática teórica y otros, el UFTG ha elaborado un modelo de referencia en el cual el usuario es el elemento más importante. En este informe se deja de considerar a los usuarios como administradores, programadores o usuarios finales y se examinan atendiendo al papel que en un momento determinado pueden desempeñar, y al interfaz que cada uno de estos papeles requiere.

Para aislar al usuario de detalles concretos sobre las herramientas de gestión de Datos (HGD), el MRFU propone interponer entre el SGBD y el usuario unas componentes, denominadas Facilidades de Usuario, que serían las encargadas de transformar una demanda de usuario, para obtener información de la base de datos en una petición funcional a las HGD, y transformar la salida de éstas en un formato de presentación al usuario. En el modelo se introducen además dos nuevos interfaces, LDU (Lenguajes de Datos de Usuario) y LDU-i (Lenguaje interno de Datos de Usuario), que, como sus homólogos LD y LD-i, son candidatos a una posible estandarización.

O.S.I. Introducción

Las siglas O.S.I. cuyo significado es Open System Interconnection o, en castellano, Interconexión de Sistemas Abiertos, se formó en el año 1983 y es el resultado del trabajo de la ISO (International Standard Organization) para la estandarización internacional de los protocolos de comunicación como necesidad de intercambiar información entre sistemas heterogéneos, entre sistemas cuyas tecnologías son muy diferentes entre sí , llevó a la ISO a buscar la manera de regular dicho intercambio de información.

Se consideró que los protocolos y modelos de la OSI llegarían a dominar las comunicaciones entre computadores, reemplazando eventualmente las

implementaciones particulares de protocolos así como a modelos rivales tales como TCP/IP o el Protocolo de Control de Transmisión y Protocolo Internet.

Pero esto no ha sucedido así, aunque se han desarrollado muchos protocolos de utilidad dentro del contexto de OSI, el modelo de las siete capas en su conjunto no ha prosperado. Por el contrario, la arquitectura TCP/IP se ha convertido en la dominante.

No tenemos que descartar que la agencia que se encargó de esta tarea, la ISO consiguió obtener grandes avances en lo dedicado a la comunicación entre los computadores aunque su trabajo se extiende desde 1946 hasta hoy día con el objetivo de promociar el desarrollo de normalizaciones que abarcan un gran abanico de materias siguiendo a su vez unas determinadas normas para la creación de un estándar ISO.

LAS CAPAS DE O.S.I

El comité de la ISO definió una serie de capas y servicios realizados por cada una de esas capas que podemos ver a continuación de forma esquemática :

NIVEL 7: - APLICACIÓN : Provee servicios generales relacionados con aplicaciones (pj.: transmisión de ficheros)

NIVEL 6 : - PRESENTACIÓN : formato de datos (p.ej : ASCII)

NIVEL 5 : - SESIÓN : Coordina la interacción en la sesión (diálogo) de los usuarios

NIVEL 4 : - TRANSPORTE : Provee la transmisión de datos confiable de punto a punto

NIVEL 3 : - RED : Enruta unidades de información

NIVEL 2 : - ENLACE DE DATOS : Provee intercambio de datos entre los dispositivos del mismo medio

NIVEL 1 : - FÍSICO : Transmite un flujo de bits a través del medio físico

A continuación pasaremos a una descripción más profunda sobre cada una de las capas.

CAPA FÍSICA

La capa física abarca el conjunto físico propiamente dicho del que consta toda comunicación y también abarca las reglas por las cuales pasan los bits de uno a otro. Sus principales características son las siguientes :

- Mecánicas: relaciona las propiedades físicas del interfaz con el medio de transmisión. A veces, incluye la especiflcación de un conector que une una o más señales del conductor, llamadas circuitos.

• Eléctricas: relaciona Ia representación de los bits (por ejemplo, en términos de niveles de tensión) y Ia tasa de transmisi6n de datos. Maneja voltajes y pulsos eléctricos.

• Funcional: especifica las funciones realizadas por los circuitos individuales del interfaz físico entre un sistema y el medio de transmisión.

• De procedimiento: especifica Ia secuencia de eventos por los que se intercambia un flujo de bits a través del medio físico.

CAPA DE ENLACE DE DATOS

Mientras Ia capa física proporciona solamente un servicio bruto de flujo de datos, Ia de enlace de datos intenta hacer el enlace físico seguro y proporciona medios para activar, tener y desactivar el enlace. El principal servicio proporcionado por Ia capa de enlace de datos a las superiores es el de detección de errores y control. Así con un protocolo de Ia capa de enlace de datos completamente operacional, Ia capa adyacente superior puede suponer

transmisión libre de errores en el enlace. Sin embargo, si Ia comunicación es entre dos sistemas que no están directamente conectados, Ia conexión constará de varios enlaces de datos unidos, cada uno operando independientemente. De este modo no se libera a la capa superior de la responsabilidad del control de errores.

CAPA DE RED

La capa de red proporciona los medios para la transferencia de información entre los sistemas finales a través de algún tipo de red de comunicación. Libera a las capas superiores de la necesidad de tener conocimiento sobre la transmisión de datos subyacente y las tecnologías de conmutación utilizadas para conectar los sistemas. En esta capa, el sistema computador está envuelto en un diálogo con la red para especificar la dirección de destino y solicitar ciertas facilidades de la red, como prioridad.

Existe un espectro de posibilidades para que las facilidades de comunicación intermedias sean gestionadas por la capa de red. En un extremo, existe en enlace punto a punto (from point to point) directo entre las estaciones. En este caso, no existe Ia necesidad de una capa de red ya que Ia capa de enlace de datos puede proporcionar las funciones necesarias de gestión del

enlace. Lo siguiente puede ser un sistema conectado a través de una única red, coma una red de conmutación de circuitos a de conmutación de paquetes.

En el otro extremo, dos sistemas finales prodrían desear comunicarse, pero sin estar conectados ni siquiera a la misma red. Pero están conectados a redes que, que directa o indirectamente, están conectadas unas a otras. Este caso requiere el uso de alguna técnica de interconexión entre redes.

CAPA DE TRANSPORTE

La capa de transporte proporciona un mecanismo para intercambiar datos entre sistemas finales. El servicio de transporte orientado a conexión asegura que los datos se entregan libres de errores, en secuencia y sin pérdidas o duplicados. La capa de transporte puede estar relacionada con Ia optimización del uso de los servicios de red y proporcionar una calidad del servido solicitada. Por ejemplo, Ia entidad de sesión puede especificar tasas de error aceptables, retardo máximo, prioridad y seguridad.

El tamaño y Ia complejidad del protocolo de transporte dependen de cómo seguras o inseguras sean las redes y sus servicios. De acuerdo a esto, ISO ha

creado una familia de 5 estándares de protocolos de transporte, cada uno orientado a los diferentes servicios subyacentes. En Ia arquitectura de protocolos TCP/IP, existen dos protocolos comunes de Ia capa de transporte: el orientado a conexión TCP y el no orientado a conexión UDP (User Datagram Protocol).

CAPA DE SESIÓN

Las cuatro capas más bajas del modelo OSI proporcionan un medio para el intercambio rápido y seguro de datos. Aunque para muchas aplicaciones este servicio básico es insuficiente. Por lo tanto , se tuvo que mejorar algunos aspectos proporcionando unos mecanismos para controlar el diálogo entre aplicaciones en sistemas finales. En muchos casos, habrá poca o ninguna necesidad de la capa de sesión, pero para algunas aplicaciones, estos servicios se utilizan.

Los servicios clave proporcionados por la capa de sesión incluyen los siguientes puntos :

Disciplina de Diálogo : esta puede ser simultánea en dos sentidos o fullduplex o alternada en los dos sentidos o semi-duplex.

Agrupamiento: El flujo de datos se puede marcar para definir grupos de datos. Por ejemplo, una tienda de venta al por menor esta transmitiendo datos de ventas a una oficina regional, estos se pueden marcar para indicar el final de los datos de ventas de cada departamento. Esto indicaría al computador que finalice Ia cuenta de totales para ese departamento y comience una nueva cuenta para el departamento siguiente.

Recuperación : Ia capa de sesión puede proporcionar un mecanismo de puntos de comprobación, de forma que si ocurre algún tipo de fallo entre puntos de comprobación, Ia entidad de sesión puede retransmitir todos los datos desde el último punto de comprobación.

CAPA DE PRESENTACIÓN

La capa de presentación define el formato de los datos que se van a intercambiar entre las aplicaciones y ofrece a los programas de aplicación un conjunto de servicios de transformación de datos. La capa de presentación define Ia sintaxis utilizada entre entidades de aplicación y proporciona los medios para Ia selección y las subsecuentes modificaciones de Ia representación utilizada. Algunos ejemplos de los servicios específicos que se podrían realizar en esa capa son los de compresión y encriptado de datos.

CAPA DE APLICACIÓN

La capa de aplicación proporciona un medio a los programas de aplicación para que accedan al entorno OSI. Esta capa contiene funciones de administración y generalmente mecanismos útiles para admitir aplicaciones distribuidas. Además, se considera que residen en esta capa las aplicaciones de uso general como transferencia de ficheros correo electrónico y acceso terminal a computadores remotos.

Para concluir con este apartado podemos recoger un par de notas sobre las capas del modelo OSI :

• Cada una de las capas desempeña funciones bien definidas.

• Los servicios proporcionados por cada nivel son utilizados por el nivel superior.

• Existe una comunicación virtual entre 2 mismas capas, de manera horizontal.

• Existe una comunicación vertical entre una capa de nivel N y la capa de nivel N + 1.

• La comunicación física se lleva a cabo entre las capas de nivel 1.

O.S.I. Funciones y parámetros

Nos referimos a los Servicios Principales a aquellos servicios y en la arquitectura entre las capas adyacentes. Los parámetros se utilizan para pasar datos e información de control y las funciones nos referimos a las funciones que se van a llevar a cabo.

Se utilizan cuatro funciones principales para definir las interacciones entre las capas adyacentes en la arquitectura.

PETICIÓN : es aquella que se utiliza para invocar algún servicio y pasar los parámetros necesarios para especificar el servicio solicitado.

INDICACIÓN : para indicar que ha sido invocado un procedimiento por el usuario de servicio paritario en la conexión y para suministrar los parámetros asociados o para notificar al usuario de servicio de una acción iniciada por el suministrador

RESPUESTA : una función emitida por un usuario de servicio para confirmar o completar algún procedimiento invocado previamente mediante una indicación de ese usuario.

CONFIRMACIÓN : una función emitida por un suministrador de servicio para confirmar o completar algún procedimiento invocado previamente mediante una petición por el usuario de servicio.

TEORIA DE LA NORMALIZACION

Cuando se diseña una base de datos mediante el modelo relacional, al igual que ocurre en otros modelos de datos, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales y no todos son equivalentes, ya que algunos van a representar la realidad mejor que otros.

Es necesario conocer qué propiedades debe tener un esquema relacional para representar adecuadamente una realidad y cuáles son los problemas que se pueden derivar de un diseño inadecuado.

La teoría de la Normalización es un método objetivo y riguroso que se aplica en el diseño de bases de datos relacionales.

Cuando estudiamos la estructura del modelo relacional, nos dimos cuenta que la base de datos puede representarse por medio de un conjunto de objetos (dominios y relaciones) y de un conjunto de reglas de integridad.

El esquema relacional puede obtenerse de dos formas distintas:

• Directamente a partir de la observación de nuestro universo del discurso, en donde especificamos conjuntos de atributos, relaciones y restricciones que corresponden a los observados en el mundo real.

• Realizando el proceso de diseño en dos fases, primero el diseño conceptual (E/R) obteniendo el esquema conceptual y posteriormente transformar éste a un esquema relacional, siguiendo algunas reglas generales, que fueron dadas anteriormente.

Algunos problemas que se pueden presentar son:

• Incapacidad para almacenar ciertos hechos

• Redundancias y por tanto, posibilidad de incoherencias

• Ambigüedades

• Pérdida de información (aparición de tuplas espúreas)

• Pérdida de dependencias funcionales, es decir, ciertas restricciones de integridad que dan lugar a interdependencias entre los datos.

• Aparición en la BD de estados no válidos, es decir, anomalías de inserción, borrado y modificación.

En conclusión el esquema relacional obtenido debe ser analizado para comprobar que no presenta los problemas anteriores.