Ventajas e inconvenientes del SGBDD
En la siguiente tabla se muestran las principales ventajas e inconvenientes de los SGBDD:
VENTAJAS | INCONVENIENTES |
Se asemeja a la estructura real de una empresa o institución. | Complejidad. La arquitectura es más compleja que un SGBD estándar. |
Mayor disponibilidad. Un fallo en un nodo no influye en los demás. | Innovador. Aún no es muy extendido el uso de los SGBDD. |
Mejores prestaciones. Mucha de la demanda al SGBD será local. | Seguridad en el sistema de comunicaciones. |
Mayor escalabilidad. Más sencillo y menos costoso ampliar la información. | Coste. Lógicamente, la inversión debe ser mayor. |
Ventajas e inconvenientes SGBDD
Aplicación práctica
Una empresa familiar desea usar un sistema de información para gestionar sus datos. El negocio cuenta con dos establecimientos, cada uno con cuatro equipos informáticos. ¿Qué arquitectura de SGBD recomendaría? ¿Es necesario que el SGBD sea multihilo?
SOLUCIÓN
La solución que mejor se adaptaría sería un SGBD centralizado con una arquitectura cliente-servidor de dos capas, no siendo importante el hecho de que el SGBD sea multihilo. Se puede deducir por los datos aportados que el tamaño de la empresa es muy pequeño, y la opción más eficiente sería la propuesta, descartando completamente el modelo de tres capas cliente-servidor o los SGBDD con un SGBD central y dos SGBD locales, cada uno en uno de los establecimientos.
4.4.Gestión de los procesos: multiproceso y multihilo
Los SGBD pueden clasificarse por la gestión de procesos que ofrezcan, es decir, si son multihilo o no lo son. En primer lugar hay que definir el concepto de multiproceso y multihilo. Ambos están muy ligados.
Por un lado, el multiprocesamiento es una característica de la arquitectura hardware de una máquina, PC o clúster de máquinas. Consiste en tener más de un procesador para realizar las diferentes tareas de forma paralela, y así ganar en eficiencia y rendimiento. Puede darse el caso de que una sola máquina tenga varios procesadores o también que varias máquinas se comporten de cara a algún procesamiento concreto como una sola máquina, paralelizando el desarrollo de dicha tarea, lo que se conoce en el ámbito de los sistemas de información como clúster. También hay casos donde un monoprocesador tiene multiprocesamiento, aunque no son casos habituales.
Por otro lado, el concepto de multihilo sería la capacidad de una tarea o subproceso de poderse dividir o paralelizar en “n” hilos, en este caso, la capacidad de un SGBD para poder paralelizar sus diferentes procedimientos. Como se observa ambos conceptos están muy ligados: si un SGBD es multiproceso, pero la máquina donde está alojado es monoprocesador, el SGBD no podrá realizar la gestión de procesos eficientemente, y aunque podría ejecutarse, no tendría el mismo rendimiento.
En la siguiente imagen se observa la comparativa entre ejecutar un proceso de manera secuencial con un solo procesador, y ejecutarlo en cuatro procesadores de forma paralela.
Destacar que el hecho de que un proceso o tarea se divida en cuatro, no conlleva que sea cuatro veces más rápido, ya que al paralelizar hay un tiempo extra que se pierde.
Actividades
7.Buscar en internet algún SGBD que tenga una gestión de procesos multihilo.
5.Definición de la arquitectura de un SGBD atendiendo al modelo de tres capas propuesto por el comité ANSI-SPARC
En 1971 DBTG (Data Base Task Group) elaboró una de las primeras propuestas sobre la arquitectura y terminología en los sistemas de bases de datos. Basándose en esta primera aproximación el comité SPARC (Standard Planning and Requirements Committee) de ANSI (American National Starndars Institute) publica en 1975 ANSI-SPARC: una arquitectura basada en tres capas o niveles. Este modelo es la base para comprender la funcionalidad de un SGBD.
Los tres niveles de la arquitectura ANSI-SPARC son el nivel interno o físico, el nivel externo o de visión, y el nivel conceptual. El nivel interno interactúa con los SGBD para almacenar físicamente los datos, el nivel externo es la forma en la que los usuarios perciben la base de datos y el nivel conceptual enlaza ambos niveles.
Nota
La primera arquitectura para los SGBD se basaba en dos niveles o capas. Fue DBTG la que planteó el nuevo modelo. Esta arquitectura tenía una capa llamada esquema y una serie de vistas de usuario denominadas subesquemas.
5.1.Concepto de nivel físico o interno
La implementación física de la base de datos es el nivel interno o físico. En este nivel están las diferentes estructuras y organizaciones de archivos para almacenar físicamente todos los datos relativos al SGBD. Las siguientes funciones o tareas se realizan dentro del nivel físico:
Los SGBD no se comportan exactamente igual en este nivel, ya que hay SGBD que aprovechan las funciones que ya usa el sistema operativo para la gestión y organización de archivos, y otros SGBD usan algunas funciones base del sistema operativo y añaden funciones propias. Por ejemplo, Oracle añade varias funciones propias. En su versión 11 introduce el concepto de ASM, una herramienta que entre otras funciones gestiona el particionado de discos con procesos y funciones propias.
5.2.Concepto de nivel externo o de visión
El nivel externo se compone de diferentes vistas de la base de datos. Una vista no es más que un subconjunto de la base de datos original que permite a cada usuario la posibilidad de abstraerse de la información que no sea necesaria o de facilitar una consulta determinada. También se usa por motivos de seguridad. Un ejemplo sencillo del uso de vistas podría darse cuando se produce una consulta muy usada y que involucra a varias tablas y restricciones, pues bien, al convertir esa consulta en una vista se facilita bastante el trabajo al usuario interesado.
La vista incluye únicamente aquellos datos de interés para el usuario, eliminando las relaciones, atributos o entidades que no sean de su interés. El usuario puede que ni siquiera tenga constancia de que existan.
Ejemplo
Dentro de la información almacenada en una base de datos, respecto a una empresa cualquiera, es muy probable que se almacenen los datos personales de empleados. Uno de ellos podría ser la fecha de nacimiento, teniendo algo parecido a esto:
Ejemplo tabla empleados | ||
Nombre | Apellido | Fecha_nac |
Angie | García | 05/07/1975 |
Jesús | Fuentes | 29/12/1988 |
Javier | Morales | 05/08/1974 |
María
|