Cerrar

Enviar mensaje

twitter FaceBook You Tube Git Hub Docs.com Enviar email

Manual de Administración de Bases de Datos

[1]
Fundamentos de los Sistemas Gestores de Bases de Datos

Publicidad

[1.1] Funcionamiento los Sistemas Gestores de Bases de Datos

[1.1.1]Sistemas Gestores de Bases de Datos

Un Sistema Gestor de Base de Datos (SGBD) es el software que permite gestionar bases de datos, ocultando la física de la misma y permitiendo su gestión desde un nivel más conceptual. Dicho software permite separar las aplicaciones (los programas) de los datos; de modo que los programas negocian con el SGBD el acceso a los datos.

En definitiva se trata de un software complejo, pero de gran importancia por lo delicado de la rama de la información a la que se dedica. Los SGBD han crecido de manera exponencial estos últimos años por el éxito de Internet, que ha provocado el acceso a miles y miles de bases de datos por parte de millones de usuarios cada día.

[1.1.2]modelo ANSI/X3/SPARC

El grupo de trabajo SPARC de la sección X3 del organismo de estándares ANSI, diseño un modelo en el que indicaba cómo debía funcionar un SGBD para asegurar la separación entre datos y aplicaciones. Este organismo definió tres y así especificó tres niveles:

Arquitectura ANSI de los Sistemas Gestores de Bases de Datos

Arquitectura ANSI de los Sistemas Gestores de Bases de Datos

La Ilustración 1, muestra la idea de los niveles en el modelo ANSI. Los tres niveles usan un modelo de trabajo para crear los esquemas (diagramas) de trabajo de la base de datos. La idea es que pasar de un nivel a otro sea un proceso automatizado (mediante lo que ANSI llama funciones de traducción.

La Ilustración 2 muestra la propuesta arquitectónica del modelo ANSI/X3/SPARC. En ella se observa el proceso de creación de una base de datos dividida en la fase de definición y la de creación. Los números del esquema expresan el funcionamiento:

[1.1.3]Niveles de abstracción actuales

Hoy en día se definen más niveles de trabajo con las bases de datos. Se habla de cinco (a veces incluso de más) niveles. Estos niveles son (empezando desde el más cercano al usuario):

[1.1.4] funciones del SGBD

Cualquier Sistema Gestor de Bases de Datos debe de ser capaz de realizar tres funciones básicas:

[1.1.5]tareas del DBA

Estos apuntes están dedicados a la labor del administrador de bases de datos o DBA. Las tareas más comúnmente aceptadas como implícitas a la labor de un DBA son:

[1.2] opciones de funcionamiento de un SGBD

[1.2.1]SGBD monocapa

Se trata de Sistemas Gestores instalados en una máquina desde la que se conectan los propios usuarios y administradores. Es decir todo el sistema está en una sola máquina.

La ventaja es la seguridad y la clara desventaja la baja disponibilidad e incomodidad de trabajo.

Es un modelo que sólo se utiliza con bases de datos pequeñas y poca cantidad de conexiones. El software Access de Microsoft es considerada un sistema gestor monocapa (aunque tiene algunas posibilidades para utilizar en dos capas).

Sistema monocapa

[1.2.2]SGBD de dos capas

Usa un modelo de funcionamiento tipo cliente/servidor. La base de datos y el sistema gestor se alojan en un servidor, mientras que los clientes acceden desde máquinas distintas a través de la red (sea local o global).

Los usuarios requieren disponer de un software de acceso denominado cliente de base de datos. En el servidor hay procesos encargados de atender a estas peticiones.

SGBD de dos capas

En los sistemas bicapas hay dos posibilidades:

[1.2.3]SGBD de tres o más capas

En este caso entre el cliente y el servidor hay al menos una capa intermedia (puede haber varias). Esa capa (o capas) se encarga de recoger las peticiones de los clientes y luego de comunicarse con el servidor (o servidores) de bases de datos para recibir la respuesta y enviarla al cliente.

SGBD de tres capas

El caso típico es que la capa intermedia sea un servidor web, que recibe las peticiones a través de aplicaciones web; de este modo para conectarse a la base de datos, el usuario solo requiere un navegador web, que es un software muy habitual en cualquier máquina y por lo tanto no requiere una instalación de software adicional en la máquina cliente.

Este modelo es el que más se está potenciando en la actualidad por motivos de seguridad y ocultación de la base de datos.

El servidor intermedio, en muchos casos, realmente es el que aloja la interfaz de manejo de los usuarios de la base de datos. En términos del modelo ANSI, es el que almacena y sirve los esquemas externos de la base de datos.

1interfaces de acceso a las bases de datos

El servidor intermedio se suele comunicar con el servidor de bases de datos a través de un componente (un driver) que proporciona a los programadores una interfaz (API) de acceso a la base de datos. Las interfaces más populares son:

[1.3] repaso del modelo relacional

[1.3.1]fundamentos del modelo relacional

El Modelo Relacional fue enunciado por Edgar F. Codd en los años 70 y, todavía, sigue siendo el modelo más utilizado por los Sistemas Gestores de Bases de Datos comerciales.

Codd se basó en los teoremas de conjuntos de Cantor y Childs para crear un modelo flexible, entendible y eficiente de base de datos. Las implementaciones iniciales de este modelo fueron muy costosas, pero ahora hay cientos de sistemas comerciales que usan este modelo.

Los detalles fundamentales de este modelo son:

Ejemplo de base de datos relacional

[1.4] Sistemas Gestores de Bases de Datos Comerciales de tipo Relacional

[1.4.1]licencias de software

El gurú del software libre, Richard Stallman denomina al software propietario (software cuyo uso y explotación se rige por un contrato privado emitido por la empresa fabricante) software privativo. La razón es que la licencia de uso de ese software no permite ver ni editar el código fuente original y, por lo tanto, impide modificar el mismo y adaptarlo a nuevas funcionalidades.

Por otro lado, el propio Stallman define al software que sí permite este proceso, software libre. En ambos casos el software no tiene por qué ser gratuito. Es decir, la diferencia no es la gratuidad sino la libertad de utilizar el código fuente del software.

Una definición, quizá menos tendenciosa, es la que diferencia al software en: software de código abierto (aquel cuyo código fuente está a disposición del cliente) y software de código cerrado u oculto. Está diferencia de software se debe a dos formas diferentes de entender la fabricación de software.

Los defensores del código cerrado argumentan que es lógico protegerle para evitar copiar su tecnología por parte de la competencia e incluso por razones de seguridad del mismo, al no poder asegurar su correcto funcionamiento ante modificaciones de terceros.

Los defensores del código abierto están a favor porque ofrece la posibilidad de poder modificar el código por parte de miles de programadores en todo el mundo que pueden compartir dichas mejoras y así rápidamente y de manera dinámica perfeccionar el producto. Argumentan que es más seguro este software ya que permite detectar problemas y virtudes más rápidamente.

[1.4.2]SGBD de código cerrado

Normalmente las licencias de uso de Sistemas Gestores de Bases de Datos con código cerrado usan licencias tipo CLUF o EULA, acrónimos equivalentes (en español y en inglés respectivamente de) de contrato de licencia de usuario final.

En estas licencias, el usuario firma unas condiciones de uso por el software, entre las que siempre figuran el hecho de no poder distribuir libremente el mismo y que está restringido a unas condiciones de trabajo concretas . Por ejemplo se restringe el número de máquinas en el que se puede instalar o el número de usuarios que la pueden utilizar.

Ejemplos de SGBD de este tipo son:

[1.4.3]SGBD de código abierto

1licencias de código abierto

2productos comerciales de código abierto

[1.5] bases de datos NoSQL. modelos diferentes del relacional

[1.5.1]introducción

Las bases de datos relacionales han sido el modelo más popular desde finales de los años 70 por su solidez y gran facilidad para diseñar sistemas complejos. Sin embargo en estos últimos años empiezan a estar desbordadas ante el uso de bases de datos que tienen que dar servicio veloz y concurrente a miles de usuarios, los cuales son capaces de generar enormes cantidades de información en poco tiempo.

Esta información en una base de datos relacional habría que validarla con las reglas e integridad que se imponen en esas bases de datos, indexarla y asegurar su uso en transacciones, etc.

En un sistema con miles de entradas por minuto (como ocurre con las bases de datos de las redes sociales), el sistema se colapsaría. Por ello se han diseñado bases de datos que se saltan el modelo relacional y que ya no utilizan el lenguaje SQL. De ahí el nombre de sistemas NoSQL.

Aunque este término se utiliza para designar a las bases de datos documentales, gráficas y otros esquemas de bases de datos; actualmente se utiliza especialmente para designar a las bases de datos que requieren tantas transacciones por segundo, que el esquema relacional tradicional no daría abasto para ello.

La base teórica de este modelo se basa en el teorema de CAP o de Brewer, que indica que en un sistema distribuido no se pueden asegurar simultáneamente estas tres reglas:

Un sistema relacional de base de datos podría asegurar la C y la A, pero no la disponibilidad en caso de una gran demanda de peticiones. Las bases de datos NoSQL siempre son tolerantes a fallos a cambio de no asegurar la consistencia (como ocurre con CouchDB o Cassandra) o la disponibilidad (como ocurre con MongoDB o Redis).

[1.5.2]diferencias con bases de datos SQL

Las bases NoSQL utilizan un modelo diferente en el que los datos se almacenan de forma menos estricta, en especial no siguen estas reglas:

[1.5.3]usos habituales de las bases de datos NoSQL

[1.5.4]tipos de bases de datos NoSQL

Base de datos NoSQL de clave/valor

Se consideran dentro de esta clasificación a estos tipos de bases de datos:

Ejemplo de base de datos NoSQl de tipo documental

Los documentos se asocian a un valor clave (key) que permite su in–dexación. Algunas bases de datos comerciales de tipo documental son:

Base de Datos NoSQL de tipo wide column

Base de Datos NoSQL basada en grafos

[1.5.5]BigData y MapReduce

1idea del Big Data

Big Data es un término que se utiliza para hacer referencia a los datos que son tan enormes y complejos que requieren métodos de gestión y consulta sobre los mismos que escapa a las técnicas clásicas de trabajo con bases de datos.

El uso de este término se ha potenciado debido a la producción masiva de información digital que se realiza continuamente desde Internet.

Para que un conjunto de datos sean considerados Big Data, tienen que ser enormes en cuanto a cantidad, muy variados en tipo y estructura, producidos a gran velocidad y veraces (información real).

Funcionamiento de Map Reduce

2MapReduce

Se trata de un modelo de programación que permite procesar enormes volúmenes de datos. Se basa en computación distribuida.

Muchas bases de datos NoSQL poseen funciones de tipo MapReduce, pero la implementación de este modelo es especialmente utilizada en sistemas de trabajo con BigData.

MapReduce no utiliza un modelo lógico de base de datos, sino que trabaja con sistemas de ficheros directamente. En este sentido hay dos soluciones muy populares para almacenar los ficheros:

3soluciones comerciales

Se pueden utilizar ambos marcos (Spark y Hadoop) a la vez.