BD1: 04 Arquitectura de bases de datos

Arquitectura de bases de datos

Resumen de la sección: En esta sección se habla sobre la arquitectura de bases de datos y cómo se busca dar una estructura de comunicación para cada una de las partes. Se menciona que la arquitectura no solo afecta la parte del manejo del DBMS, sino también otras perspectivas como la estrategia de desarrollo.

Las capas iniciales

• La teoría relacional definió dos tipos de capas: una capa lógica y otra capa física.

• A mediados de los 70, Peter Hill agregó una tercera capa llamada "capa conceptual" que hace falta para comunicar el mundo real con la capa lógica.

• Esta tercera capa forma un modelo entidad-relación.

Diseño arquitectónico

• El diseño de datos es fundamental en cualquier sistema de información o software.

• La pirámide muestra diferentes elementos del diseño arquitectónico, siendo el diseño de datos o clases lo más importante en la base.

• En ediciones más nuevas del libro, se agrega el diseño de clases a la base.

Modelo Entidad-Relación

Resumen de la sección: En esta sección se habla sobre el modelo entidad-relación y cómo este puede ser utilizado en diferentes etapas del proceso de análisis y diseño. También se menciona la diferencia entre los diagramas de clase de análisis y diseño, así como la importancia de tener cuidado con los términos utilizados para evitar confusiones.

Etapas del proceso

• El modelo entidad-relación es utilizado conceptualmente en el proceso de análisis y diseño.

• En la parte del análisis, se utilizan diagramas de clase para representar las funciones que tiene la empresa, mientras que en la parte del diseño se utiliza un diseño de clases con más detalles cercanos a cómo va a ser implementado en el sistema.

• En el paradigma relacional, el análisis podría ser un modelo de relación y en la parte del diseño podría ser un esquema relacional.

• Es importante tener cuidado con los términos utilizados para evitar confusiones.

Diseño por capas

• Se muestra una arquitectura por capas donde cada capa está relacionada con el modelo de datos que soportará todas las capas encima.

• La vista externa representa la comunicación con los usuarios y corresponde a la vista conceptual. Existe una correspondencia entre ambas vistas mediante un mapeo externo conceptual.

• Existe una correspondencia hacia abajo entre la parte conceptual interna y debería haber un mapeo conceptual interno dentro de la parte lógica.

Arquitectura de bases de datos

Resumen de la sección: En esta sección se habla sobre la arquitectura de bases de datos y cómo los usuarios hacen uso de ellas. Se mencionan diferentes grados de abstracción y cómo estos están relacionados con la arquitectura de desarrollo que se utiliza.

Grados de abstracción

• Existen diferentes grados de abstracción en la arquitectura de bases de datos.

• El modelo relacional es independiente del hardware pero dependiente del software.

• En el nivel más bajo, hay una dependencia tanto del hardware como del software.

Diseño conceptual, lógico y físico

• Se habla sobre el diseño conceptual, lógico y físico en la arquitectura de bases de datos.

• El esquema relacional es independiente del hardware pero dependiente del software.

• En el diseño físico hay una dependencia tanto del hardware como del software.

Arquitectura DMS

• La arquitectura DMS está enfocada en cómo se comportan los diferentes procesos en un DMS.

• Hay un cliente que hace una solicitud a un escuchador para hacer una consulta.

Arquitectura de un DMS

Resumen de la sección: En esta sección se habla sobre la arquitectura de un DMS (Sistema de Gestión de Bases de Datos). Se mencionan las diferentes bibliotecas y características que maneja el DMS, así como su comunicación con la base de datos física. También se explica la importancia del manejador de almacenamiento y el diccionario de datos.

Elementos del DMS

• El DMS maneja bibliotecas para elementos administrativos como la memoria caché, el optimizador y el manejador de bloqueos.

• El DMS tiene operaciones de entrada y salida con la base de datos física, que puede estar almacenada en un disco duro.

• El manejador de almacenamiento es responsable del acceso a las tablas y tiene sus propias bibliotecas, como el manejador de archivos y luz woofers.

• Dentro del manejador de almacenamiento también se encuentra el manejador de transacciones, que gestiona las transacciones utilizadas.

Arquitecturas en capas

• La arquitectura en capas permite separar los procesos del cliente y servidor. En una arquitectura en dos capas, encontramos nuestro sistema base dentro del servidor.

• El diccionario de datos es importante porque contiene información sobre todo lo que está almacenado en la base.

Protección contra conexiones directas

• En una arquitectura en tres capas, se separa la parte del servidor en dos: un servidor de aplicaciones y el servidor de la base de datos.

• La arquitectura Spark proporciona una vista externa para proteger la conexión directa entre la aplicación y la base de datos.

Bloqueos en bases de datos

Resumen de la sección: En esta sección, el orador habla sobre los bloqueos en una base de datos y cómo se pueden utilizar para granularizar y controlar el acceso a la información. También explica diferentes niveles de bloqueo, desde un grano grueso hasta un grano fino.

Niveles de bloqueo

• Los bloqueos en una base de datos permiten granularizar el acceso a la información.

• Se pueden utilizar diferentes niveles de bloqueo, desde un grano grueso hasta un grano fino.

• El nivel más grueso es cuando se bloquea toda la base de datos, como en un backup en frío.

• Para backups en caliente o para conexiones concurrentes, se pueden utilizar niveles más finos como el bloqueo a nivel de tabla o fila.

• Incluso hay un nivel aún más fino que es solo bloquear uno de los campos a la vez.

Concurrencia vs Paralelismo

Resumen de la sección: En esta sección, el orador explica las diferencias entre concurrencia y paralelismo y cómo afectan al rendimiento del servidor.

Concurrencia vs Paralelismo

• La concurrencia es simulada mientras que el paralelismo es físico.

• La concurrencia puede ser útil cuando hay muchos usuarios conectados al mismo tiempo realizando diferentes peticiones.

• El paralelismo requiere de múltiples servidores para funcionar correctamente.

Arquitecturas de bases de datos

Resumen de la sección: En esta sección, el orador habla sobre las diferentes arquitecturas que han existido en el desarrollo de las bases de datos y cómo han evolucionado con el tiempo.

Evolución de las arquitecturas

• Las bases de datos han evolucionado a lo largo del tiempo y han tenido diferentes arquitecturas.

• Se pueden ver diferentes perspectivas al analizar una arquitectura, como la interacción entre los roles y usuarios o las capas de diseño.

• En la época de los mainframes, se utilizaban terminales tontas conectadas por red para acceder a la base de datos.

• Con la aparición de las computadoras personales, cada usuario tenía su propia computadora y se conectaba a través de una red local.

Arquitectura de aplicaciones web

Resumen de la sección: En esta sección, el instructor habla sobre la evolución de la arquitectura de las aplicaciones web y cómo ha cambiado con el tiempo. También explica cómo funciona una arquitectura cliente-servidor y cómo se han desarrollado nuevas capas en la arquitectura para mejorar su eficiencia.

Evolución de la arquitectura web

• Las aplicaciones web han reemplazado a las aplicaciones de escritorio debido a su independencia de plataforma.

• La aparición de servidores de aplicaciones ha permitido separar las capas del servidor y mejorar su escalabilidad.

• La utilización del software como servicio (SaaS) permite conectar con bases de datos en la nube sin necesidad de un servidor propio.

Modelo Vista Controlador

• El modelo vista controlador es una abstracción que separa las partes del controlador, vista y modelo para mejorar su escalabilidad y comunicación independiente.

• En el caso específico del desarrollo móvil, por ejemplo, se espera que los programadores utilicen este modelo para separar la interfaz gráfica del código.

Capa acceso a datos

• El modelo se conecta con una capa acceso a datos que busca información en una base física.

Arquitectura de bases de datos

Resumen de la sección: En esta sección se habla sobre la arquitectura de bases de datos y cómo se pueden manejar las conexiones primarias y secundarias, así como la separación entre la capa del front-end y el back-end. También se mencionan diferentes tipos de arquitecturas paralelas y distribuidas.

Conexión primaria y secundaria

• Se puede tener una conexión primaria a través de una red, con bases de datos en un bajo conectado a ella.

• El bajo puede tener una copia exacta de la base de datos para recuperar información después de una pérdida en la parte primaria.

• Es importante manejar adecuadamente esta arquitectura para evitar problemas.

Separación entre front-end y back-end

• La capa del front-end es lo que los usuarios ven, mientras que el back-end contiene toda la información en la base de datos.

• Existen diferentes arquitecturas paralelas dependiendo del tipo de base de datos que se esté manejando.

Arquitecturas paralelas

• Las arquitecturas paralelas pueden ser memoria compartida o disco compartido.

• También pueden ser distribuidas, donde cada sucursal tiene su propia base de datos.

• Existe también una parte jerárquica donde se definen las conexiones.

Arquitecturas distribuidas

• Las arquitecturas distribuidas pueden tener bases de datos totalmente distintas en diferentes sitios.

• Cada uno puede manejar su propia memoria y base de datos.

Cloud computing

• El cloud computing es una forma de independizarse totalmente de la parte física.

• Existen diferentes formas, como el software como servicio o la plataforma como servicio.

Arquitectura de Base de Datos

Resumen de la sección: En esta sección se habla sobre la arquitectura de base de datos, que es una estructura abierta y flexible que permite incluir diferentes tipos de fuentes de datos. Se mencionan las partes principales del modelo, como los datos fuentes, la transformación y carga, el modelo dimensional y las salidas. También se habla sobre otras arquitecturas relacionadas con bases de datos, como la arquitectura OSSes y la arquitectura federada.

Estructura Abierta

• La arquitectura de base de datos es abierta y flexible.

• Permite incluir diferentes tipos de fuentes de datos.

• Ganando mucho auge en el mercado.

Transformación y Carga

• El proceso ETL (Extracción, Transformación y Carga) es importante para procesar información desde diferentes fuentes.

• Los datos son almacenados en un modelo dimensional.

• Este proceso permite hacer consultas para análisis gerencial.

Salidas

• Las salidas pueden ser reportes o incluso Business Intelligence a nivel móvil o desktop.

• Se puede construir un cubo para dar vueltas horizontal o verticalmente cambiando jerarquías dentro del modelo.

Arquitecturas Relacionadas

OSSes

• La arquitectura OSSes describe cómo se comunica el cliente con el servidor para hacer consultas en una base de datos.

• Utiliza un escuchador llamado Post Master para recibir las solicitudes del cliente.

Federada

• La arquitectura federada une información proveniente desde diferentes bases de datos.

• Es similar a la arquitectura distribuida, pero puede unir diferentes tipos de bases de datos.

Arquitectura de bases de datos federadas

Resumen de la sección: En esta sección, el orador explica cómo funciona una base de datos federada y cómo Google trabaja con servidores en diferentes países. También menciona que cada país tiene su propia empresa y servidor, lo que permite tener una base de datos federal.

Funcionamiento de una base de datos federada

• Una base de datos federada es como una representación distribuida donde cada país tiene su propio servidor y empresa.

• Cada servidor debe estar basado en alguna empresa nacional, incluso si es multinacional.

• Si juntamos toda la información de todos los países, tendríamos una base de datos federal.

• La parte federal es más independiente y puede haber empresas totalmente diferentes con plataformas diferentes.

Ejemplo: Google

• Cuando hacemos una búsqueda en Google, nos conectamos a un servidor que puede estar en otro país.

• Google trabaja con servidores en diferentes países para tener una base de datos federal.

Ejemplo gubernamental

• El gobierno podría tener su propia base de datos tipo federal para acceder a información relevante.

• El Bono Familia utiliza diferentes bases de datos para reunir información relevante.

Arquitectura orientada a objetos y documental

Resumen de la sección: En esta sección, el orador habla sobre la arquitectura orientada a objetos y documental. Explica cómo MongoDB almacena cada uno de los esquemas y cómo funciona la estabilidad horizontal.

Arquitectura orientada a objetos

• La arquitectura orientada a objetos es una forma diferente de almacenar información.

• Cada módulo puede tener una parte primaria y varias partes secundarias para tener un alto rendimiento o disponibilidad.

Arquitectura documental

• MongoDB almacena cada uno de los esquemas en diferentes lugares.

• La arquitectura documental no es transaccional en sentido estricto, lo que significa que habría que tener cuidado con la redundancia.

Ontología del framework Rey Mor

Resumen de la sección: En esta sección, el orador habla sobre el framework Rey Mor y su ontología. Explica las relaciones semánticas entre las diferentes partes del framework.

Framework Rey Mor

• El framework Rey Mor desaparece un 87% y es más una metodología que un marco de trabajo.

• La ontología del framework explica cómo se reúnen las diferentes partes del mismo.

Arquitectura de Desarrollo

Resumen de la sección: En esta sección, se discute la arquitectura de desarrollo que se utilizará durante todo el curso. Se mencionan las tres capas importantes: conceptual, lógica y física.

Capas importantes del marco de trabajo

• La arquitectura tiene autoría y no es posible compartir imágenes originales.

• Las capas importantes son la conceptual, lógica y física.

• El artículo menciona que la parte conceptual le pertenece al cliente, mientras que la parte lógica es responsabilidad del diseñador.

• El rol del constructor puede ser separado del diseñador.

Importancia del modelo conceptual

• El modelo entidad-relación es importante para crear la capa conceptual.

• Las empresas crecen y cambian, por lo que el modelo conceptual debe ser flexible para adaptarse a los cambios.

Arquitectura de desarrollo

• La arquitectura de desarrollo consta de tres capas: conceptual, lógica y física.

• Para la capa conceptual se crea el modelo entidad-relación.

• Para la capa lógica se necesita el esquema relacional propuesto por CCOO.

• Para la capa física se requiere un script SQL para implementarla.

Orden recomendado para trabajar en las capas

• Es recomendable trabajar primero en la capa física, luego en la lógica y finalmente en la conceptual.

• Muchas fuentes bibliográficas recomiendan este orden porque ayuda a entender cómo está establecido el sistema antes de llegar a su diseño.