INSTITUTO

TECNOLOGICO DE
COLIMA
INGENIERIA EN SISTEMAS COMPUTACIONALES

ADMINISTRACION DE BASES DE DATOS

JORGE ESTEBAN GONZALEZ VALLADARES

ARQUITECTURA Y ADMINISTRACIÓN DEL SGBD

MARIO RUBÉN MANCILLA TINOCO

VILLA DE ALVAREZ, COLIMA

01/MARZO/2019
Contenido
Introducción ...................................................... Error! Bookmark not defined.
Arquitectura de SQL Server ............................................................................. 4
Arquitectura de MySQL ................................................................................... 6
Arquitectura de Oracle .................................................................................... 9
Conclusión..................................................................................................... 13
BIbliografía .................................................................................................... 14
Introducción

En el entorno del mercado actual, la competitividad y la rapidez de maniobra de una

empresa son imprescindibles para su éxito. Para conseguirlo existe cada vez una
mayor demanda de datos y, por tanto, más necesidad de gestionarlos. Esta
demanda siempre ha estado presente en empresas y sociedades, pero en estos
años se ha disparado debido al acceso masivo a las redes integradas en Internet y
a la aparición de los dispositivos móviles que también requieren esa información.

Desde su nacimiento, la informática se ha encargado de proporcionar herramientas

que faciliten la manipulación de los datos. Antes de la aparición de las aplicaciones
informáticas, las empresas y asociaciones tenían como únicas herramientas de
gestión de datos los ficheros con cajones y gabinetes, carpetas y una cantidad
ridícula de hojas de papel. En este proceso manual, el tiempo requerido para
manipular estos datos era enorme, pero la propia informática ha adaptado sus
herramientas para que los elementos que el usuario utiliza en cuanto a manejo de
datos se parezcan a los manuales.

Los sistemas de información actuales se basan en bases de datos (BD) y sistemas

gestores de bases de datos (SGBD) que se han convertido en elementos
imprescindibles de la vida cotidiana de la sociedad moderna.

En el presente trabajo se detalla la arquitectura genérica de 3 de los principales

sistemas gestores de bases de datos, los cuales son SQL Server, MySQL y Oracle,
explicando sus componentes y funcionalidades.
Desarrollo

Arquitectura de SQL Server

Como ya se sabe, SQL Server es un potente gestor de bases de datos para la

creación de soluciones empresariales mediante la copia o descarga de archivos, la
actualización de almacenamiento de bases de datos, limpieza y minería de datos.

El sistema gestor de bases de datos es uno de los más famosos y usados entre la
gran variedad de SGBD, ya que permite crear soluciones de integración de datos
de alto rendimiento, incluidas la extracción, la transformación y la carga (ETL) de
datos para almacenes de datos.

SQL server está diseñado para trabajar con grandes cantidades de información y la
capacidad de cumplir con los requisitos de los procesos de información para
aplicaciones comerciales y sitios Web.

Este sistema gestor utiliza una arquitectura de tipo Cliente - Servidor. El cliente es
responsable de la parte lógica y de presentar la información al usuario. SQL Server
usa Transact – SQL para mandar peticiones entre un cliente y el SQL Server.

La arquitectura Cliente – Servidor se basa en un conjunto de nodos que realizan la

función clientes y de otros que realizan la función de servidores. La lógica del
negocio está distribuida entre clientes y el servidor. Los clientes llaman a los
servicios. Es un modelo de sistemas distribuido que muestra como los datos y el
procesamiento se distribuyen a lo largo de varios procesadores.

La arquitectura interna de las bases de datos en SQL Server está compuesta por 2
tipos de estructura, la estructura lógica y la estructura física.

En la estructura lógica se debe de tener al menos 1 FIleGroup el cual contiene toda

la metadata de la misma base de datos (tablas y vistas del sistema). Todos los
objetos de usuario que contengan data, ya sean tablas o índices, deben estar
ligados a un “FileGroup”.
La estructura lógica incluye diferentes propósitos por la cual existe y es tan
importante, los cuales se muestran a continuación:

 Poder distribuir la data a través de varios discos duros físicos.

 Esconder la ubicación física real de la información a los programadores
encargados de la base de datos.
 Puede contener 1 o más “DataFiles”, y de cada uno de estos datafiles se
puede encontrar en discos diferentes, lo cual también agilizará las consultas
y los ingresos de información.

Por otro lado, en la estructura física la datafile contiene toda la información de la

base de datos. Un “DataFile” solo puede pertenecer a 1 “FileGroup”. Los datafiles
están divididos en “Extends” y estos a su vez en “Pages”. Las paginas o pages son
la unidad mínima de almacenamiento dentro de la base de datos, con un tamaño en
disco de 8kb. Un Extend contiene 8 paginas por lo que su tamaño puede ser de
64kb.

En una página o page solo puede haber información de 1 sola tabla, es decir el
espacio no es compartido entre tablas o índices. En el caso de los extends pueden
ser mixtos (compartidos hasta por 8 objetos) o uniformes (pertenecen a 1 solo
objeto).

En caso del LogFile está ligado directamente a la base de datos. Las bases de datos
de SQL Server solo pueden tener un solo “LogFile” activo al mismo tiempo, solo 1
puede ser escrito. Cuando este archivo se llene, la base de datos pasara a escribir
al siguiente archivo de transacciones, y así sucesivamente.

La arquitectura de SQL contiene los siguientes componentes:

 External Protocols.
 Query Protocols.
 Storage Engine.
 Access Methods.
 SQL OS.
Arquitectura de MySQL

Al igual que SQL Server, MySQL es un sistema gestor de base de datos muy
utilizados y conocido, y este último debe su grandeza a su gran potencial, fácil
manejo y agregando que es open source y gratuito. MySQL es un sistema de
gestión de base de datos relacional, multihilo y multiusuario con más de seis
millones de instalaciones.

Hablando acerca de su arquitectura, La arquitectura de MySQL tiene como

característica más notable el separar el motor de almacenamiento (que se encarga
de los detalles de entrada-salida y representación de la información en memoria
secundaria) del resto de los componentes de la arquitectura. Es decir, el diseño del
gestor está preparado para que se pueda cambiar el gestor de almacenamiento.
Esto permite incluso crear nuevos motores de almacenamiento especializados para
ciertas tareas o tipo de aplicaciones.

A continuación, se muestra una imagen que ilustra la arquitectura del presente

sistema gestor de base de datos.

Imagen 1.0: arquitectura del SGBD MySQL

En la figura 1.0 se hace una división entre los componentes que conforman el
servidor, las aplicaciones cliente que lo utilizan y las partes del sistema operativo en
las que se basan el almacenamiento físico. Componentes que se explicarán a
continuación.

Conectores

Los conectores de MySQL son los drivers que utilizan los programas cliente para
conectarse al servidor. Para poder ofrecer la conectividad las aplicaciones y
herramientas a utilizar deben de ser compatibles con estándares de la industria
ODBC y JDBC si son compatibles pueden utilizar MySQL.

Servidor MySQL

Es el encargado de gestionar el acceso a la base de datos en el disco y en la

memoria. Es multi-tarea y multi-usuario. Soporta distintos motores de
almacenamiento que pueden gestionar distintos tipos de tablas.

Utilidades y herramientas

Son los programas y aplicaciones que se incluyen con la distribución del gestor o
que pueden instalarse como aplicaciones adicionales como:

 Backup
 El navegador de consultas (Querybrowser)
 Aplicaciones administrativas de interfaz grafico
 Herramienta de diseño (workbench)

Gestor de conexiones

Es el responsable de mantener las múltiples conexiones de los clientes. Si no

existiera el gestor de conexiones se crearía una conexión por cada cliente
conectado haciendo que se consuman recursos en la máquina.
Crear estas conexiones y destruirlas es un proceso costoso. Por eso el gestor de
conexiones puede limitar conexiones concurrentes y también implementa un pool
de conexiones.

Procesador de consultas

En el momento de cuando una consulta llega, se analiza detalladamente y se

produce una representación intermedia de la misma consulta, posteriormente
MySQL toma una serie de decisiones que puede incluir el determinar la lectura del
orden de las tablas, el uso de ciertos índices o la re-escritura de la consulta de una
forma más eficiente.

Optimizador de consultas

MySQL utiliza un optimizador basado en costos para determinar la mejor manera

de resolver una consulta

En muchos casos MySQL puede calcular el mejor plan de consulta posible, pero
muchas veces MySQL no tiene suficiente información y tiene que hacer
suposiciones sobre los datos.

Cache de consultas

MySQL implementa un caché de consultas, donde guarda consultas y sus

resultados enteros. De este modo, el procesador de consultas, busca la consulta en
la caché, para evitarse realizar el trabajo en el caso de que tenga suerte y encuentre
la consulta en la caché

Control de concurrencia

Es un gestor de bases de datos es simplemente el mecanismo que se utiliza para

evitar que lecturas o escrituras simultáneas a la misma porción de datos terminen
en inconsistencias o efectos no deseados. El mecanismo que se utiliza para
controlar este acceso es el de los bloqueos

Gestión de transacciones
El gestor de transacciones es responsable de cerciorarse de que la transacción está
registrada y ejecutada.

Si existiera algún error, estas podrías ser por:

 Error lógico (violación de restricciones, tiposincompatibles, etc.).

 Error del sistema (interbloqueos, espacio insuficiente, etc.).

Motores de almacenamiento

La idea de esa arquitectura es hacer una interfaz abstracta con funciones comunes
de gestión de datos en el nivel físico. De ese modo, el gestor de almacenamiento
puede intercambiarse, e incluso un mismo servidor MySQLpuede utilizar diferentes
motores de almacenamiento para diferentes bases de datos o para diferentes tablas
en la misma base de datos. Esto permite utilizar el motor de almacenamiento más
adecuado para cada necesidad concreta.

Arquitectura de Oracle

Para comunicar con el servidor de bases de datos, Oracle Database proporciona un

sistema de al menos dos capas. Lo que implica a un cliente y a un servidor, los
cuales utilizar alguna red de computadoras para conectar. Sin embargo, es muy
habitual que entre la capa del cliente y la del servidor haya que atravesar otra capa,
formando un modelo de tres capas (según lo visto en el capítulo anterior).
 Imagen 1.2: elementos de la comunicación Cliente/Servidor en un entorno de Oracle
Database.

La comunicación entre el cliente y el servidor se realiza a través de dos procesos:

 Proceso de usuario. Software que se ejecuta en el lado del cliente y se

encarga de recoger las instrucciones lanzadas por el usuario y enviarlas al
servidor.
 Proceso servidor. Software que se ejecuta en el servidor de bases de datos
y que se encarga de procesar el código lanzado por el usuario.

Normalmente, hay un proceso servidor para cada usuario que conecte con la base
de datos. Es decir, si hay diez conexiones, habrá diez procesos de usuario y diez
procesos servidores.

Oracle, no obstante, proporciona un modo de trabajo llamado servidor compartido,

en el que un mismo proceso servidor atiende a varios procesos de usuario. La razón
es ahorrar memoria, aunque no sea tan eficiente como el modo dedicado.

En principio, la forma de trabajar de Oracle Database es la que se conoce como

modo de servidor dedicado. En ella por cada proceso servidor atiende a un único
proceso de usuario. Dicho de otro modo, hay tantos procesos servidores como
procesos de usuario.
Sin embargo, existe la posibilidad de trabajar en modo de servidor compartido. En
este caso cada proceso servidor atiende a varios procesos de usuario. Uno, o más,
procesos, llamados dispatchers (repartidores), se encargan de asignar a cada
proceso de usuario el proceso servidor adecuado.

En este modo se ahorra memoria, ya que la memoria de usuarios se almacena en

la zona global compartida (llamada SGA).

La conexión típica a Oracle comienza con una petición de acceso desde el lado del
cliente.

Un proceso conocido como Listener, consigue “escuchar” dicha petición. El Listener

es uno de los elementos fundamentales de Oracle Database. Su labor es gestionar
el tráfico de las peticiones del cliente.

Una vez el Listener detecta la nueva petición, se establece conexión y comenzarán

a comunicarse el proceso de usuario con su proceso servidor correspondiente.

Un servidor Oracle Database es el conjunto formado por estos dos elementos:

 La instancia de Oracle. Formada por el conjunto de procesos y las estructuras

de datos en memoria que requiere el servidor cuando está en
funcionamiento.
 Archivos de la base de datos. Los archivos en disco que almacenan de forma
permanente la información de la base de datos. La base de datos en sí, la
forman los archivos de datos, los de control y los Redo Log.

Un servidor de Oracle puede poseer más de una instancia, pero en general en estos
apuntes trabajaremos bajo la hipótesis de tener un sistema de instancia simple. Las
instancias múltiples se dan en sistemas distribuidos, en los que es posible disponer
de más de una instancia (alojada en diferentes servidores) para la misma base de
datos.
Imagen 1.3: Esquema de la arquitectura general de Oracle Database.
Conclusiones

Durante alrededor de 1 año y medio se ha estado trabajando con el Structured

Query Language en los gestores de SQL Server y MySQL, y últimamente se ha
usado el SGBD de Oracle. Aunque ya se haya tenido toda esa experiencia, el
conocer la arquitectura de dichos sistemas gestores era algo que se desconocía
hasta la elaboración de este trabajo.

Gracias a estos sistemas gestores la parte de la información o los datos pueden

comunicarse con los usuarios para consultarlos, modificarlos, eliminarlos o incluso
agregar nuevos. Los SGBD son un puente entre estas dos capas, haciendo del
manejo de una base datos una tarea más fácil y dándoles un enorme potencial.

Es por eso que darnos cuenta de la gran importancia que tiene conocer la
arquitectura de los sistemas gestores de base de datos es fundamental si se quiere
aprender a usar muy bien y a profundidad el manejo de los datos en sus dichas
bases.
Bibliografía

https://prezi.com/in1iuwkmuvid/arquitectura-sql-server/

https://rzamurianos.wordpress.com/2011/07/07/introduccin-al-sql-server/

https://docplayer.es/94404155-Arquitectura-de-mysql.html

https://prezi.com/p-y94gcdtdmj/arquitectura-de-la-base-de-datos-mysql/

https://jorgesanchez.net/manuales/abd/arquitectura-oracle.html