BASE DE DATOS

Es una colección de información organizada de forma que un programa de ordenador pueda seleccionar rápidamente los fragmentos de datos que necesite. Una base de datos es un sistema de archivos electrónico.

Las bases de datos tradicionales se organizan por campos, registros y archivos. Un campo es una pieza única de información; un registro es un sistema completo de campos; y un archivo es una colección de registros.

SISTEMA MANEJADOR DE BASE DE DATOS

El sistema de gestión de bases de datos es esencial para el adecuado funcionamiento y manipulación de los datos contenidos en la base. Se puede definir como: "El Conjunto de programas, procedimientos, lenguajes, etc. que suministra, tanto a los usuarios no informáticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad".

Funciones:

Las funciones esenciales de un SGDB son la descripción, manipulación y utilización de los datos.

- Descripción: Incluye la descripción de los elementos de datos, su estructura, sus interrelaciones, sus validaciones. Tanto a nivel externo como lógico global e interno esta descripción es realizada mediante un LDD o Lenguaje de Descripción de Datos.

- Manipulación: Permite: Buscar, Añadir, Suprimir y Modificar los datos contenidos en la Base de Datos. La manipulación misma supone: Definir un criterio de selección, Definir la estructura lógica a recuperar, Acceder a la estructura física. Esta manipulación es realizada mediante un LMD o Lenguaje de Manipulación de Datos.

- Utilización: La utilización permite acceder a la base de datos, no a nivel de datos sino a la base como tal, para lo cual: Reúne las interfaces de los usuarios y suministra procedimientos para el administrador.

OBJETIVOS DE LO (SMBD)

El sistema  manejador de la base de datos es responsable de las siguientes tareas:

1. Interacción con el manejador de archivos: Los datos en la base se guardan en disco mediante el sistema de archivos, proporcionado comúnmente por el sistema operativo. El manejador de la base, traduce las diferentes proposiciones del manejo de datos en comandos del sistema de archivos de bajo nivel. De esta forma el manejador se puede encargar del almacenamiento, recuperación y actualización de los datos en la base.

2. Implantación de la integridad: Los valores de los datos que se almacenan en la base, deben satisfacer ciertas limitantes de consistencia, estas limitantes deben ser determinadas por el administrador, pero es el manejador el encargado de verificar que las actualizaciones que se hagan a la base cumplan con dichas normas.

3. Puesta en práctica de la seguridad: El manejador de la base es quien verifica que los accesos a la base sean realizados por las personas autorizadas.

4. Respaldo y recuperación: Entre las labores que debe ejecutar el manejador está la de verificar de forma constante la integridad de la base, y lograr recuperación de datos y/o mejoras en caso que se requieran.

5. Control de concurrencia: Se podría entender, esta, como la principal tarea del manejador de la base, o por lo menos la más difícil. Cuando varios usuarios están accesando la base al mismo tiempo, es posible que la consistencia de los datos no se conserve. El manejador debe encargarse de coordinar los accesos de los diferentes usuarios, de forma que los datos en la base no se dañen.

En términos ideales, un DBMS debe contar con estas funciones, sin embargo, no todos las poseen, así existen algunos manejadores que no cumplen la función de respaldo o de seguridad, dejándola al usuario o administrador; sin embargo un DBMS que sea completo y que deba manejar una base de datos multiusuario grande, es conveniente que cuente con todas estas operaciones.

EVOLUACIÓN DE LOS (SMBD)

Inicialmente, en los años 40s,  los Sistemas de Archivos generados a través de lenguajes de programación no propietarios como Cobol y Fortran (vigentes en la actualidad), permiten almacenar los datos a través de archivos planos con funciones básicas de lectura y escritura sobre ellos.  En 1964, se conciben los primeros Gestores de Base de Datos (DBMS: Database Management System), por medio de los cuales se pretende dar un viraje a los Sistemas de Archivos,  los cuales se limitan a la estructuración del almacenamiento físico de los datos.  Con los DBMS se crea el concepto de Administración de los datos, por medio de actividades integradas que permiten verlos físicamente en un solo almacenamiento pero lógicamente se manipulan a través de esquemas compuesto por estructuras donde se  establecen  vínculos de integridad, métodos de acceso y organización física sobre los datos, permitiendo así obtener valores agregados de utilización tales como: manejo de usuarios, seguridad, atomicidad e independencia física y lógica de los datos, entre otros. 

El primer gestor de bases de datos (DBMS) comercial, IDS:  Integrated Data Store , se crea bajo el concepto del Modelo de Datos de Red (Bachgman, 1965); luego se desarrolla el IMS: Information Management System , sobre el concepto del Modelo de Datos Jerárquico.  Estos DBMSs eran accesados normalmente por lenguajes de programación como Cobol usando interfases de bajo nivel haciendo que las tareas de creación de aplicaciones y mantenimiento de los datos  fuesen controlables, pero aún complejas.
 

A medida que evolucionaban los DBMS, los lenguajes de programación también lo hacían.  En 1967 surge el primer lenguaje de programación orientado a objetos, Simula, el cual fue propuesto para simulación  de actividades.  En este los procedimientos podían ser asociados a un tipo para representar el comportamiento de una instancia, introduciendo así el concepto de Clase.  Simula, soporta paralelismo permitiendo muchas entidades interactivas en una simulación.  Además comparte objetos acoplando datos y procedimientos.
            Luego se genera una nueva noción, donde las bases de datos deben almacenar por medio de una estructura tabular llamada relación o tabla (Codd,1970), compuesta por filas y columnas, accesando dichas relaciones a través de un lenguaje de alto nivel no procedural  (declarativo).  De esta forma en los años 80s surgen varios productores de DBMS Relacionales (RDBMS) como Oracle, Informix, Ingres y DB2, además de otros lenguajes orientados a objetos como el C++, Java (antes el Oak), Eiffel, y Smalltalk adoptando y mejorando el concepto de clase pero su desarrollo se hace independiente de los DBMSs. 

            Comenzando los años 80’s ya se siente la necesidad de que los DBMS actuales manipulen objetos complejos y estructuras como las usadas en sistemas CAD y CASE, entre otras.  A partir de esto se da inicio a dos grandes tendencias: los ORDBMS (Object Relational Database Management System) los cuales se proyectan como una extensión de los RDBMS hacia el paradigma OO, y los OODBMS (Object Oriented Database Management System) estarían disponibles para almacenar y manipular las clases, los objetos, la asociación entre ellos y sus métodos.  Así, finalizando los años 80s se crean los OODBMSs por medio de productores como O2, ObjectDesign y Objectivity, entre otros.  Pero realmente se puede decir que estos no se hicieron tan comerciales como los existentes RDBMS ya que el concepto de Orientación a Objetos se seguía manejando muy a nivel del lenguaje de programación, sin que se trabajaran estructuras de almacenamiento Orientadas a Objetos dependientes de estos .  Así, en 1991 surge la ODMG (Object Database Management Group) el cual estandariza los OODBMSs a partir del ODMG-93 y luego en 1992 el comité ANSI X3H2 inicia un trabajo en SQL3, del cual surgen los DBMS objeto relacional ORDBMS.  Este trabajo fue programado para finalizarse en 1995, pero aún se sigue trabajando en este con un tiempo límite de terminación, en el año 1999. 

SISTEMA DE BASE DE DATOS RELACIONAL

Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario están organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan sobre estas tablas. Estas bases de datos son percibidas por los usuarios como una colección de relaciones normalizadas de diversos grados que varían con el tiempo. Permiten establecer interconexiones (relaciones) entre los datos (que están guardados en tablas), y a través de dichas conexiones relacionar los datos de ambas tablas, de ahí proviene su nombre: "Modelo Relacional".

En términos tradicionales una relación se asemeja a un archivo, una tupla a un registro, y un atributo a un campo. Pero estas correspondencias son aproximadas, en el mejor de los casos. Una relación no debe considerarse como ``solo un archivo'', sino más bien como un archivo disciplinado, siendo el resultado de esta disciplina una simplificación considerable de las estructuras de datos con las cuales debe interactuar el usuario, lo cual a su vez simplifica los operadores requeridos para manejar esas estructuras.

Características:

- Una Base de Datos Relacional se compone de varias tablas o relaciones.

- No pueden existir dos tablas con el mismo nombre ni registro.

- Cada tabla es a su vez un conjunto de registros (filas y columnas.

- La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o foráneas).

- Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben cumplir con la integridad de datos.

- Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de éstas se hacen las relaciones. 

        Así, todos los datos en una base de datos relacional se representan de una y solo una manera, a saber, por su valor explícito (esta se denomina en ocasiones ``principio básico del modelo relacional''). En particular, las conexiones lógicas dentro de una relación y entre las relaciones se representan mediante esos valores; no existen ``ligas'' o apuntadores visibles para el usuario, ni ordenamientos visibles para el usuario, ni grupos repetitivos visibles para el usuario, etc.

ARQUITECTURA CLIENTE/SERVIDOR

El modelo Cliente/Servidor es una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma. En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio). En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.  En otras palabras la arquitectura Cliente/Servidor es una extensión de programación modular en la que la base fundamental es separar una gran pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar su mantenimiento. Esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.

·           CLIENTE

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se le conoce con el término front-end. El Cliente normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de una red. Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

-          Administrar la interfaz de usuario.

-           Interactuar con el usuario.

-          Procesar la lógica de la aplicación y hacer validaciones locales.

-          Generar requerimientos de bases de datos.

-          Recibir resultados del servidor.

-          Formatear resultados.

         
        SERVIDOR

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se le conoce con el término back-end. El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:

-          Aceptar los requerimientos de bases de datos que hacen los clientes.

-          Procesar requerimientos de bases de datos.

-          Formatear datos para trasmitirlos a los clientes.

-          Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

CARACTERÍSTICAS DE LA ARQUITECTURA CLIENTE/SERVIDOR

Las características básicas de una arquitectura Cliente/Servidor son:

- Combinación de un cliente que interactúa con el usuario, y un servidor que interactúa con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor actúa como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, módems, etc.

- Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cómputo como velocidad del procesador, memoria, velocidad y capacidades del disco y input-output devices Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red.

- Existe una clara distinción de funciones basada en el concepto de "servicio", que se establece entre clientes y servidores.

- La relación establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos.

- Los clientes corresponden a procesos activos en cuanto a que son éstos los que hacen peticiones de servicios a los servidores. Estos últimos tienen un carácter pasivo ya que esperan las peticiones de los clientes.

- No existe otra relación entre clientes y servidores que no sea la que se establece a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicio.

- El ambiente es heterogéneo. La plataforma de hardware y el sistema operativo del cliente y del servidor no son siempre la misma. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas.

• El concepto de escalabilidad tanto horizontal com o vertical es aplicable a cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite agregar más estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las características del servidor o agregar múltiples servidores

Ventajas del esquema Cliente/Servidor

          Entre las principales ventajas del esquema Cliente/Servidor están:

- Uno de los aspectos que más ha promovido el uso de sistemas Cliente/Servidor, es la existencia de plataformas de hardware cada vez más baratas. Esta constituye a su vez una de las más palpables ventajas de este esquema, la posibilidad de utilizar máquinas considerablemente más baratas que las requeridas por una solución centralizada, basada en sistemas grandes. Además, se pueden utilizar componentes, tanto de hardware como de software, de varios fabricantes, lo cual contribuye considerablemente a la reducción de costos y favorece la flexibilidad en la implantación y actualización de soluciones.

- El esquema Cliente/Servidor facilita la integración entre sistemas diferentes y comparte información permitiendo, por ejemplo que las máquinas ya existentes puedan ser utilizadas pero utilizando interfaces más amigables al usuario. De esta manera, podemos integrar PCs con sistemas medianos y grandes, sin necesidad de que todos tengan que utilizar el mismo sistema operacional.

- Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo este esquema tienen mayor interacción y más intuitiva con el usuario. En el uso de interfaces gráficas para el usuario, el esquema Cliente/Servidor presenta la ventaja, con respecto a uno centralizado, de que no es siempre necesario transmitir información gráfica por la red pues esta puede residir en el cliente, lo cual permite aprovechar mejor el ancho de banda de la red.

- Una ventaja adicional del uso del esquema Cliente/Servidor es que es más rápido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las herramientas existentes (por ejemplo los servidores de SQL o las herramientas de más bajo nivel como los sockets o el RPC ).

- La estructura inherentemente modular facilita además la integración de nuevas tecnologías y el crecimiento de la infraestructura computacional, favoreciendo así la escalabilidad de las soluciones.

- El esquema Cliente/Servidor contribuye además, a proporcionar, a los diferentes departamentos de una organización, soluciones locales, pero permitiendo la integración de la información relevante a nivel global.

 Desventajas del esquema Cliente/Servidor

         Entre las principales desventajas del esquema Cliente/Servidor están:

- El mantenimiento de los sistemas es más difícil pues implica la interacción de diferentes partes de hardware y de software, distribuidas por distintos proveedores, lo cual dificulta el diagnóstico de fallas.

- Se cuenta con muy escasas herramientas para la administración y ajuste del desempeño de los sistemas.

- Es importante que los clientes y los servidores utilicen el mismo mecanismo (por ejemplo sockets o RPC), lo cual implica que se deben tener mecanismos generales que existan en diferentes plataformas.

- Además, hay que tener estrategias para el manejo de errores y para mantener la consistencia de los datos.

- La seguridad de un esquema Cliente/Servidor es otra preocupación importante. Por ejemplo, se deben hacer verificaciones en el cliente y en el servidor. 

- El desempeño es otro de los aspectos que se deben tener en cuenta en el Cliente/Servidor. Problemas de este estilo pueden presentarse por congestión en la red, dificultad de tráfico de datos, etc.

ARQUITECTURA MULTICAPA

Una arquitectura multicapas es un conjunto  ordenado de subsistemas, cada uno de cuales  está constituido en términos de los que tiene por debajo y proporciona la base de la implementación de aquellos que están por encima de él.

Los objetos de cada capa suelen ser  independientes, aunque suelen haber  dependencias entre objetos de distintas capas. Existe una relación cliente /servidor entre las  capas inferiores, que son las que proporcionan  los servicios, y las capas superiores, los  usuarios de estos servicios.

Una arquitectura multicapa particiona todo el sistema en distintas unidades funcionales: cliente, presentación, lógica-de-negocio, integración, y sistema de información empresarial (EIS). Esto asegura una división clara de responsabilidades y hace que el sistema sea más mantenible y extensible. Los sistemas con tres o más capas se han probado como más escalables y flexibles que un sistema cliente-servidor, en el que no existe la capa central de lógica de negocios. La capa de presentación expone los servicios de la capa de lógica de negocio a los usuarios. Sabe cómo procesar una petición de cliente, cómo interactuar con la capa de lógica de negocio, y cómo seleccionar la siguiente vista a mostrar. La capa de la lógica  de negocio contiene los objetos y servicios de negocio de la aplicación. Recibe peticiones de la capa de presentación, procesa la lógica de negocio basada en las peticiones, y media en los accesos a los recursos de la capa EIS. Los componentes de la capa de lógica de negocio se benefician de la mayoría de los servicios a nivel de sistema como el control de seguridad, de transacciones y de recursos. La capa del cliente es donde se consumen y presentan los modelos de datos. Para una aplicación Web, la capa cliente normalmente es un navegador web. Los clientes pequeños basados en navegador no contienen lógica de presentación; se trata en la capa de presentación.

VENTAJAS Y DESVENTAJAS DE LA ARQUITECTURA MULTICAPAS

Ventajas

- Encapsulación de lógica de negocio.  Diferentes clientes de la aplicación pueden acceder al mismo servidor  intermedio. Esto permite evitar la  redundancia (y coste de mantenimiento)  de duplicar las reglas de negocio para cada aplicación cliente separada.

- Aplicaciones clientes pequeñas. Al delegar las tareas más pesadas en la capa media las aplicaciones clientes ocupan menos y consumen menos procesador y memoria, permitiendo instalarse en máquinas de bajo rendimiento. Esto trae la ventaja de que por muchos clientes que accedan a la aplicación, el motor de bases de datos sólo tiene una conexión, que va directamente al servidor de aplicaciones, evitando así problemas de concurrencia o latencia de datos entre distintas aplicaciones cliente. Estas aplicaciones clientes también pueden funcionar a través de Internet ya que su consumo de ancho de banda es mínimo, al contrario de conectar directamente con el motor de bases de datos.

- Procesar datos distribuidos. Distribuir el trabajo de una aplicación entre varias  máquinas puede mejorar la ejecución, ya  que el balanceo de carga permite reducir la carga de las máquinas que funcionan como servidor de aplicaciones.  

-Incrementar la seguridad. Podemos aislar la funcionalidad en las capas dando restricciones de seguridad. Esto proporciona unos niveles de seguridad configurables y flexibles. Las capas intermedias pueden limitar los puntos de entrada a material protegido, permitiendo controlar el control de acceso más fácilmente. Si usamos HTTP o COM+, podemos utilizar los modelos de seguridad que soportan.

-Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o servidores).

- Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que  un programa cliente defectuoso o no autorizado no pueda dañar el sistema. Esta centralización también facilita la tarea de poner al día datos u otros recursos.

-  Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación.

- Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de empleo.

Desventajas

- Pone más carga a la red, debido al tráfico que genera en la red. La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultaneas al mismo servidor, puede ser que cause muchos problemas para éste (a mayor número de clientes, más problemas para el servidor).

- El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el coste.

- El cliente no dispone de los recursos que puedan existir en el servidor.

- Es mucho más difícil programar y probar el software que en la arquitectura de dos  niveles porque tienen que con más dispositivos para terminar la transacción del usuario.