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