BASES DE DATOS STANDARD INDICE

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
Bibliografía.....................................................................................................31
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.
1
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
2
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.
3
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
4
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.
5
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.
6
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.
7
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
8
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
9
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.
10
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.
BIBLIOGRAFÍA
MICROSOFT ENCARTA 99
WWW.YAHOO.COM
WWW.ALTAVISTA.COM
WWW.SUPERARCHIVOS.COM
WWW.APRENDIENDOPC.COM
11
2
12