diff --git a/README.md b/README.md index c3ec8678..2457da7f 100644 --- a/README.md +++ b/README.md @@ -1 +1,86 @@ -# Latex template for students thesis of MatCom +## Writting a Chapter +### Chapter Structure +Each chapter will be structured as follows: +- An **introduction section** which should be concise and no longer than one page. This section must provide answers to the following questions: + + - What topic are you going to discuss in the chapter? (Definitions) + - Why is it relevant to discuss that topic? (Context and real life applications) + - How is structured the current chapter? (Content of the rest of the sections) + +- **Content sections** in a logical order so each one refers to sections that the reader is already familiar with. + +To work in parallel in the same chapter we need to stablish some conventions. All the chapters of the thesis will be in the `document\MainMatter\` directory. I will use the chapter called *"Sistemas de Inteligencia de Negocios"* to illustrate how these conventions will work. + +- Each `chapter` will have his own directory with a descriptive name. In this case we will have the `document\MainMatter\BusinessIntelligence\` directory. +- Each `chapter` directory will have the following files: + + - A `.tex` main file with the same name as the directory. In this file we will write the introductory section of the chapter and include the files of the chapter's sections. This is how this file should look like: + + ```LaTex + % Set the name of the chapter and its label + \chapter{Sistemas de Inteligencia de Negocios}\label{chapter:bi-systems} + + % Write here the introductory section content + + % These commands include the content of the sections files + \include*{MainMatter/BusinessIntelligence/TransactionalSystems} + \include*{MainMatter/BusinessIntelligence/AnalyticalSystems} + \include*{MainMatter/BusinessIntelligence/ETL} + ``` + + - A `.tex` file for each section, each one with a descriptive name and structured as follows: + + ```LaTex + % Set the name of the section and its label + \section{Online Analytical Processing (OLAP)} \label{section:olap} + + % Write here the introduction to the section + + % Subsections for the contents + \subsection{Objetivos de los sistemas OLAP} + % Write here... + \subsection{Arquitectura de los sistemas OLAP} + % Write here... + \subsection{Almacenes de datos} + % Write here... + \subsection{Modelo Dimensional} + % Write here... + \subsection{Arquitectura de un almac\'en de datos} + % Write here... + \subsection{Herramientas OLAP} + % Write here... + + ``` + + Having separate files for the sections of a chapter will allow us to work together in the same chapter but in different sections. This way we can avoid merge conflicts while working in parallel. + + We include the chapters in the main thesis `.tex` file like this: + + ```LaTex + \include{MainMatter/BusinessIntelligence/BusinessIntelligence} + \include{MainMatter/AutomaticETL/AutomaticETL} + \include{MainMatter/Proposal/Proposal} + \include{MainMatter/Implementation/Implementation} + ``` + + > The difference between `\include{file}` and `\include*{file}` is that the first one will create a new page for the content of the file. + +### Tracking progress + +For trackign the progress we will use GitHub issues. We will create an issue for each section of a chapter (including the introductory section). Each issue will contain a task list including all the subsections to complete the section. + +Each milestone of the project will be completing a chapter and each one will have a provisional deadline. + +### Writting a chapter + +To write a chapter we will create branches with the following naming convention: + +`//
/` + +For example: + +`vicmc99/BusinessIntelligence/TransactionalSystems/Add-Relational-Database-Subsection` + +In each pull request you will have to assign me as reviewer + +It should never happen to have two branches open on the same section of the same chapter at the same time. \ No newline at end of file diff --git a/document/Bibliography.bib b/document/Bibliography.bib index e69de29b..5ed638f0 100644 --- a/document/Bibliography.bib +++ b/document/Bibliography.bib @@ -0,0 +1,171 @@ +@misc{foote_brief_2018, + title = {A {Brief} {History} of the {Data} {Warehouse}}, + url = {https://www.dataversity.net/brief-history-data-warehouse/}, + abstract = {A Data Warehouse (DW) stores corporate information and data from operational systems and a wide range of other data resources. Data Warehouses are designed to support the decision-making process through data collection, consolidation, analytics, and research.}, + language = {en-US}, + urldate = {2023-03-10}, + journal = {DATAVERSITY}, + author = {Foote, Keith D.}, + month = apr, + year = {2018}, + keywords = {History}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\A36IKVEL\\brief-history-data-warehouse.html:text/html}, +} + +@misc{naeem_data_2020, + title = {Data {Warehouse} {Concepts}: {Kimball} vs. {Inmon} {Approach}}, + shorttitle = {Data {Warehouse} {Concepts}}, + url = {https://www.astera.com/type/blog/data-warehouse-concepts/}, + abstract = {Inmon vs Kimball: Which data warehouse concept should you use to design a data warehouse. Find out in this blog.}, + language = {en-US}, + urldate = {2023-03-10}, + journal = {Astera}, + author = {Naeem, Tehreem}, + month = feb, + year = {2020}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\DVQ44NVM\\data-warehouse-concepts.html:text/html}, +} + +@misc{noauthor_snowflake_2018, + title = {Snowflake {Schema} in {Data} {Warehouse} {Model}}, + url = {https://www.geeksforgeeks.org/snowflake-schema-in-data-warehouse-model/}, + abstract = {A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.}, + language = {en-us}, + urldate = {2023-03-10}, + journal = {GeeksforGeeks}, + month = aug, + year = {2018}, + note = {Section: DBMS}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\QXG6SE7S\\snowflake-schema-in-data-warehouse-model.html:text/html}, +} + +@misc{noauthor_kimball_nodate, + title = {Kimball vs. {Inmon} in {Data} {Warehouse} {Architecture}}, + url = {https://www.zentut.com/data-warehouse/kimball-and-inmon-data-warehouse-architectures/}, + abstract = {We will discuss about the Kimball vs. Inmon in data warehouse architecture and design approach. We also answer the question of how to choose Kimball or Inmon's architecture to build data warehouse.}, + language = {en-US}, + urldate = {2023-03-12}, + journal = {zentut}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\VP7BZI6R\\kimball-and-inmon-data-warehouse-architectures.html:text/html}, +} + +@book{diaz2012introduccion, + title={Introducci{\'o}n al business intelligence}, + author={D{\'\i}az, Josep Curto}, + year={2012}, + publisher={Editorial UOC} +} + +@book{kimball2011data, + title={The data warehouse toolkit: the complete guide to dimensional modeling}, + author={Kimball, Ralph and Ross, Margy}, + year={2011}, + publisher={John Wiley \& Sons}, +} + +@book{inmon2005building, + title={Building the data warehouse}, + author={Inmon, William H}, + year={2005}, + publisher={John wiley \& sons} +} + +@misc{oltpAzure, + title = {Online transaction processing ({OLTP}) - {Azure} {Architecture} {Center} {\textbar} {Microsoft} {Learn}}, + url = {https://learn.microsoft.com/en-us/azure/architecture/data-guide/relational-data/online-transaction-processing}, + urldate = {2023-08-08}, + file = {Online transaction processing (OLTP) - Azure Architecture Center | Microsoft Learn:C\:\\Users\\Chuchi\\Zotero\\storage\\R94PD4QG\\online-transaction-processing.html:text/html}, +} + +@misc{oltpOracle, + title = {¿{Qué} es {OLTP}?}, + url = {https://www.oracle.com/ar/database/what-is-oltp/}, + abstract = {OLTP implica insertar, actualizar y/o suprimir pequeñas cantidades de datos en un almacén de datos para recopilar, gestionar y proteger transacciones.}, + language = {es}, + urldate = {2023-08-08}, + keywords = {OLTP vs OLAP}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\UBC7LXYA\\what-is-oltp.html:text/html}, +} + +@book{garcia2008database, + title={Database systems: the complete book}, + author={Garcia-Molina, Hector}, + year={2008}, + publisher={Pearson Education India} +} + +@book{silberschatz2005database, + title={Database systems concepts}, + author={Silberschatz, Abraham and Korth, Henry and Sudarshan, Shashank}, + year={2005}, + publisher={McGraw-Hill, Inc.} +} + +@misc{helenclu_database_2023, + title = {Database normalization description - {Microsoft} 365 {Apps}}, + url = {https://learn.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description}, + abstract = {Describe the method to normalize the database and gives several alternatives to normalize forms. You need to master the database principles to understand them or you can follow the steps listed in the article.}, + language = {en-us}, + urldate = {2023-08-18}, + author = {helenclu}, + month = jul, + year = {2023}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\WH495648\\database-normalization-description.html:text/html}, +} + +@misc{noauthor_what_nodate, + title = {What is a relational database?}, + url = {https://www.oracle.com/database/what-is-a-relational-database/}, + abstract = {Learn the definition of a relational database and how it can help your business.}, + language = {en}, + urldate = {2023-08-18}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\QEGMHW8Q\\what-is-a-relational-database.html:text/html}, +} + +@misc{raunakjhawar_ETL_microsoft, + title = {Extract, transform, and load ({ETL}) - {Azure} {Architecture} {Center}}, + url = {https://learn.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl}, + abstract = {Learn about extract-transform-load (ETL) and extract-load-transform (ELT) data transformation pipelines, and how to use control flows and data flows.}, + language = {en-us}, + urldate = {2023-08-20}, + author = {raunakjhawar}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\6H8TPS9C\\etl.html:text/html}, +} + +@misc{ETL_amazon, + title = {¿{Qué} es {ETL}? - {Explicación} de extracción, transformación y carga ({ETL}) - {AWS}}, + shorttitle = {¿{Qué} es {ETL}?}, + url = {https://aws.amazon.com/es/what-is/etl/}, + abstract = {Descubra qué es ETL y cómo utilizar Amazon Web Services para ETL}, + language = {es-ES}, + urldate = {2023-08-20}, + journal = {Amazon Web Services, Inc.}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\SVTF2I4D\\etl.html:text/html}, +} + +@misc{etl_vs_elt_amazon, + title = {{ETL} vs {ELT} - {Difference} {Between} {Data}-{Processing} {Approaches} - {AWS}}, + url = {https://aws.amazon.com/compare/the-difference-between-etl-and-elt/}, + abstract = {What's the Difference Between ETL and ELT? How to Use ETL and ELT with AWS.}, + language = {en-US}, + urldate = {2023-08-20}, + journal = {Amazon Web Services, Inc.}, + file = {Snapshot:C\:\\Users\\Chuchi\\Zotero\\storage\\QHYSBE8G\\the-difference-between-etl-and-elt.html:text/html}, +} + +@misc{BI_powerBI_Microsoft, + title = {What {Is} {Business} {Intelligence} {\textbar} {Microsoft} {Power} {BI}}, + url = {https://powerbi.microsoft.com/en-us/what-is-business-intelligence/}, + abstract = {Learn what business intelligence is and how to use business intelligence tools to uncover actionable insights that drive strategic business decisions.}, + language = {en}, + urldate = {2023-08-23}, +} + +@misc{IBM_bi, + title = {What is {Business} {Intelligence} and {How} {Does} it {Work}? {\textbar} {IBM}}, + shorttitle = {What is {Business} {Intelligence} and {How} {Does} it {Work}?}, + url = {https://www.ibm.com/topics/business-intelligence}, + abstract = {Business intelligence (BI) is software that ingests business data and presents it in user-friendly views such as reports, dashboards, charts and graphs."}, + language = {en-us}, + urldate = {2023-08-23}, +} \ No newline at end of file diff --git a/document/Graphics/dimension.png b/document/Graphics/dimension.png new file mode 100644 index 00000000..0f149686 Binary files /dev/null and b/document/Graphics/dimension.png differ diff --git a/document/Graphics/hechos.png b/document/Graphics/hechos.png new file mode 100644 index 00000000..2f7acb00 Binary files /dev/null and b/document/Graphics/hechos.png differ diff --git a/document/Graphics/star schema.png b/document/Graphics/star schema.png new file mode 100644 index 00000000..2b941cfd Binary files /dev/null and b/document/Graphics/star schema.png differ diff --git a/document/MainMatter/AutomaticETL/AutomaticETL.tex b/document/MainMatter/AutomaticETL/AutomaticETL.tex new file mode 100644 index 00000000..876cfd46 --- /dev/null +++ b/document/MainMatter/AutomaticETL/AutomaticETL.tex @@ -0,0 +1 @@ +\chapter{Generaci\'on Autom\'atica de Procesos ETL}\label{chapter:auto-etl} diff --git a/document/MainMatter/Background.tex b/document/MainMatter/Background.tex deleted file mode 100644 index 70d0236a..00000000 --- a/document/MainMatter/Background.tex +++ /dev/null @@ -1 +0,0 @@ -\chapter{Estado del Arte}\label{chapter:state-of-the-art} diff --git a/document/MainMatter/BusinessIntelligence/AnalyticalSystems.tex b/document/MainMatter/BusinessIntelligence/AnalyticalSystems.tex new file mode 100644 index 00000000..91279a5b --- /dev/null +++ b/document/MainMatter/BusinessIntelligence/AnalyticalSystems.tex @@ -0,0 +1,230 @@ +\section{Online Analytical Processing (OLAP)} \label{section:olap} + +El Procesamiento Anal\'itico en L\'inea (\textbf{OLAP}) es una tecnología de organización de grandes bases de datos +comerciales que facilita a los usuarios el an\'alisis de grandes conjuntos de datos multidimensionales de manera +eficiente y efectiva. A diferencia de las bases de datos relacionales tradicionales, que se centran en el procesamiento +de transacciones y la actualización de datos en tiempo real, OLAP se enfoca en el análisis de datos históricos y la +identificación de patrones y tendencias. + +\subsection{Objetivos de los sistemas OLAP} + +En términos generales, el objetivo principal de OLAP es proporcionar una plataforma para el análisis de datos +multidimensionales de manera eficiente y efectiva. De forma m\'as espec\'ifica OLAP tiene el objetivo de: + +\begin{itemize} + \item Brindar a los analistas de datos flexibilidad a la hora de realizar sus labores, permitiendoles analizar los datos desde + diferentes perspectivas y dimensiones, así como la capacidad de agregar o desagregar los datos según sea necesario. + \item Ofrecer an\'alisis de forma r\'apida y eficiente, incluso cuando se manejan grandes cantidades de datos. + \item Ser fácilmente accesible para los usuarios finales, incluso si no tienen experiencia en programación o en el + manejo de bases de datos. Esto se logra a través de interfaces de usuario intuitivas y herramientas de análisis + visuales que permiten a los usuarios explorar los datos de manera interactiva. + \item Ser f\'acilmente integrable con otras aplicaciones de análisis y reporting, lo que permite a las organizaciones + utilizar la tecnología en conjunto con otras herramientas de análisis de datos y visualización. + \item Otorgar seguridad permitiendo a las organizaciones controlar quiénes tienen acceso a los datos y qué acciones + pueden realizar. Esto es especialmente importante en el caso de datos confidenciales o críticos para el negocio. +\end{itemize} + +\subsection{Arquitectura de los sistemas OLAP} + +La arquitectura de un sistema OLAP consiste en múltiples componentes que trabajan en conjunto para brindar un entorno +analítico integral. Estos son los componentes fundamentales de un sistema OLAP: + +\subsubsection{Fuentes de Datos:} +El primer componente de un sistema OLAP son las fuentes de datos. Estas pueden ser cualquier número de diferentes +tipos de fuentes de datos, como bases de datos relacionales o archivos planos. Las fuentes de +datos son típicamente el punto de partida para el proceso ETL (Extraci\'on, Transformaci\'on, Carga), que extrae datos +de los sistemas fuente y los carga en el sistema OLAP. + +\subsubsection{ETL:} +El siguiente componente son los procesos ETL. Estos son los procesos que hacen posible +que los datos sean extra\'idos de los sistemas fuente, se transformen en el formato requerido por el sistema OLAP y luego se +cargan en el sistema OLAP. Los procesos ETL son los responsables de garantizar la calidad y consistencia de los datos, +así como de realizar cualquier limpieza o agregación de datos necesarios. + +\subsubsection{Almacén de datos:} +El tercer componente de un sistema OLAP es el almacén de datos, Data Warehouse en ingl\'es. Aquí es donde se almacenan y +organizan los datos de manera optimizada para consultas analíticas. M\'as adelante se profundizar\'a en las especificidades +de los Almacenes de Datos. + +\subsubsection{Motor OLAP:} +El motor OLAP es el responsable de responder consultas analíticas de forma rápida y eficiente sobre +los datos en el almacén de datos. El motor OLAP consiste en un conjunto de algoritmos y estructuras de datos +optimizadas para consultas analíticas, como cubos multidimensionales, índices de bits y esquemas en estrella. + +\subsubsection{Herramientas de cliente:} +El último componente de un sistema OLAP son las herramientas de cliente. Estas son las herramientas que utilizan los +usuarios finales para interactuar con el sistema OLAP y realizar consultas analíticas. Las herramientas de cliente pueden +incluir desde simples paneles basados en web hasta herramientas sofisticadas de visualización y análisis de datos. + +\subsection{Almacenes de datos} + +El término \emph{Data Warehouse} fue acuñado por primera vez por Bill Inmon en 1990. William H. Inmon planteó que: +“Un \textbf{\emph{Data Warehouse}} es una colección de datos integrada, orientada a sujetos, variante en el tiempo y +no volátil, utilizada como apoyo para los procesos de toma de decisión.” + +Analizando cada uno de los elementos principales de esta definición, se puede obtener una mejor comprensión de qué es un +almacén de datos: + +\subsubsection{Orientados a sujetos:} +% +Hace referencia a un sistema que est\'a organizado en base a temas o conceptos especiales, permitiendo que los datos y la +información de un mismo tipo quede siempre conectada. + +\subsubsection{Integrados:} +Los datos se obtienen de fuentes diferentes, por ejemplo de los diferentes departamentos de una organización, por lo que se +deben aplicar técnicas que permitan determinar las interrelaciones existentes entre los datos, para luego guardarlos en el +almacén y que puedan ser accedidos eficientemente durante las consultas. + +\subsubsection{No Vol\'atiles:} +La información contenida en un almac\'en de datos existe para ser leída, pero no modificada. + +\subsubsection{Variables con el tiempo:} +Los cambios producidos en los datos a lo largo del tiempo quedan registrados, para que los informes que se generen reflejen +esas variaciones. + + +No se puede hablar de Almacenes de Datos sin mencionar los modelos dimensionales. A trav\'es de los a\~{n}os, la industria +a conclu\'ido que el modelado dimensional es la t\'ecnica m\'as apropiada para entregar datos a los usuarios de los +almacenes de datos. En la siguiente sección profundizaremos en el modelo dimensional. + +\subsection{Modelo Dimensional} + +Un modelo dimensional contiene la misma información que un modelo normalizado, pero empaqueta los datos en un formato +distinto, que tiene como objetivos de diseño la comprensión del usuario, el rendimiento de las consultas y la resiliencia +al cambio. Un modelo dimensional se compone de dos elementos fundamentales: las tablas de hechos y las tablas de dimensi\'on. +% +\subsubsection{Tablas de Hechos: } +% +Una tabla de hechos es la tabla principal en un modelo dimensional, en la cual se almacenan las mediciones de desempeño del +negocio, generalmente valores num\'ericos\cite{kimball2011data}. Una fila en una tabla de hechos corresponde a una medida. +% +\begin{figure}[ht] + \centering + \includegraphics[width=0.5\textwidth]{../document/Graphics/hechos.png} + \caption{Tabla de Hechos Daily Sales (Ventas Diarias) \cite{kimball2011data}} + \label{fig:facts} + \end{figure} +% + +La Figura\ref{fig:facts} muestra un ejemplo de una tabla de hechos que contiene datos sobre las ventas de un producto, en una fecha dada, +en una tienda determinada. N\'otese que los atributos Quantity Sold (Cantidad Vendida) y Dollar Sales Amount (Cantidad de +Ventas en Dólares), son atributos num\'ericos que pueden ser de gran ayuda para analizar la rentabilidad y otros indicadores +del negocio. + +Las tablas de hechos normalmente ocupan el $90\%$\cite{kimball2011data} del espacio de las bases de datos dimensionales, por tanto, +los desarrolladores deben tener bien en cuenta el espacio que ocupa la tabla. Es inconveniente almacenar +registros num\'ericos que no vayan a aportar nada relevante a los an\'alisis. Esto tambi\'en se aplica para los atributos +de tipo texto, ya que ocupan mayor espacio que los datos num\'ericos y por su naturaleza heterog\'enea es conveniente +mantenerlos fuera de las tablas de hechos; aunque esto no es absoluto\cite{kimball2011data}. + +Las tablas de hechos contienen dos o m\'as llaves for\'aneas, que conectan con las llaves primarias de las tablas de +dimensiones. +% +\subsubsection{Tablas de Dimensiones: } +% +Las tablas de dimensiones contienen los descriptores textuales del negocio. Cada dimensión se identifica por su llave +primaria, la cual es \'unica y sirve como base para asegurar la integridad referencial en cualquier tabla de hechos con +la que se interrelaciona. Los atributos de las tablas de dimensi\'on son la fuente fundamental de restricciones en las +consultas al modelo dimensional, son fundamentales para hacer que el almacén de datos sea utilizable y comprensible. Las +dimensiones implementan la interfaz de usuario para el almacén de datos, por tanto, cuánto más tiempo se dedique a +proporcionar atributos con información detallada y terminología comercial, mejor es el almacén de datos. + +\begin{figure}[ht] + \centering + \includegraphics[width=0.5\textwidth]{../document/Graphics/dimension.png} + \caption{Tabla de Dimensi\'on Producto \cite{kimball2011data}} + \label{fig:dimension} + \end{figure} + +La Figura\ref{fig:dimension} muestra un ejemplo de la tabla de la dimensi\'on Product (Producto). +% +\subsubsection{Esquema Estrella y Esquema Copo de Nieve: } + +Las tablas de hechos y tablas de dimensiones se combinan para formar un modelo dimensional. Como se puede observar en la +Figura\ref{fig:dimmodel}, la tabla de hechos Ventas, que almacena las medidas de inter\'es, se encuentra en el centro del esquema, +interrelacionada a las tablas de dimensiones, que le proporcionan a las medidas atributos descriptivos. + +\begin{figure}[ht] + \centering + \includegraphics[width=1\textwidth]{../document/Graphics/star schema.png} + \caption{Modelo Dimensional \cite{kimball2011data}} + \label{fig:dimmodel} +\end{figure} + +A esta estructura se le conoce como Esquema Estrella (\emph{Star Schema}). Debido a su simplicidad, son f\'aciles de leer +y de comprender los procesos que intentan modelar. Adem\'as tienen un rendimiento sobresaliente, con pocas operaciones se +pueden manejar consultas complicadas sobre los hechos. Sin embargo, tienen una deficiencia, con tal de mantener la +simplicidad, permiten redundancia de datos en las tablas de dimensiones. + +Ejemplo de esto es la tabla de la dimensi\'on Product, Figura\ref{fig:dimension}. N\'otese que se puede almacenar varios productos de una +misma marca, por tanto, la información de Brand Descriptor (Descriptor de Marca) se repetir\'ia por cada producto de la +misma marca. Lo mismo sucede con Category Description (Descriptor de Categor\'ia) y otros de los atributos. Es decir, la +información en esta tabla ser\'a redundante. Sin embargo, con el objetivo de optimizar el rendimiento de las consultas y +de mantener la legibilidad del modelo, se abstiene de crear una tabla aparte con la informaci\'on de las marcas, y unirla +a la dimensi\'on Product mediante una llave for\'anea. Si se realiza esta transformaci\'on en las tablas de dimensi\'on, +el Esquema Estrella converge al Esquema Copo de Nieve (\emph{Snowflake Schema}). + +En el esquema Copo de Nieve, las dimensiones se encuentran normalizadas en varias tablas relacionales. El efecto Copo de Nieve solo afecta a las tablas de +dimensiones, las tablas de hechos permanecen iguales que en el Esquema Estrella, en el centro del modelo. La ventaja de este esquema es que puede ayudar a reducir +la redundancia y mejorar la integridad de los datos. Sin embargo, en este esquema las consultas pueden resultar menos eficientes que en el Esquema Estrella, debido +a que intervienen un mayor número de tablas en las operaciones. Adem\'as, el Esquema Copo de Nieve puede resultar m\'as dif\'icil de entender y mantener, pues incrementa la complejidad del +dise\~{n}o del modelo. + +La decisi\'on de usar uno u otro esquema depende de los requerimientos espec\'ificos del proyecto y de las compensaciones entre rendimiento de las consultas, +la complejidad del esquema y la integridad de los datos. + + +\subsection{Arquitectura de un almac\'en de datos} + +La estructura de un Almac\'en de Datos puede ser separada por capas. Aunque esto es un tema pol\'emico. Los mismos Inmon y Kimball tienen posiciones dispares +con respecto a este tema. Seg\'un Inmon los Data Marts est\'an f\'isicamente separados del Almac\'en de Datos y la forma de acceder a los datos es a trav\'es de los Data Marts \cite{inmon}. +Por otro lado, Kimball no concibe esta separaci\'on y los usuarios acceden a los datos del almac\'en directamente \cite{kimball2011data}. + +Cada autor propone diferentes nombres para las capas, pero de manera general pueden distinguirse 3 capas: + +\subsubsection{Sistemas Operacionales:} +Son las fuentes de datos primarias del Almac\'en de Datos. + +\subsubsection{Almac\'en de Datos Empresarial:} +Es la capa fundamental del almac\'en. Almacena los datos reconciliados, extra\'idos de los sistemas operacionales. De acuerdo con Kimball esta capa est\'a compuesta +por los datos integrados de los distintos Data Marts. En cambio, seg\'un Inmon es una estructura en tercera forma normal y los Data Marts derivados, separados f\'isicamente. + +\subsubsection{Capa de Reportes:} Es donde los usuarios interact\'uan con el Almac\'en de Datos. + +\subsection{Herramientas OLAP} + +En el campo del Procesamiento Analítico en Línea (OLAP), existen varias herramientas y plataformas establecidas que +proporcionan capacidades sólidas para el análisis de datos y el apoyo a la toma de decisiones. Estas herramientas ofrecen +una amplia gama de características y funcionalidades para empoderar a las organizaciones en la obtención de conocimientos a +partir de sus datos. A continuaci\'on discutiremos algunas de las m\'as conocidas: + +\subsubsection{Microsoft SQL Server Analysis Services (SSAS): } + +Microsoft SQL Server Analysis Services (SSAS) es una herramienta OLAP que forma parte del conjunto de herramientas +de Microsoft SQL Server. Brinda capacidades de análisis multidimensionales y minería de datos, permitiendo a los +usuarios crear y gestionar cubos OLAP para un análisis avanzado de datos. SSAS admite tanto el modelo multidimensional +como el modelo tabular, brindando flexibilidad en la modelización y consultas de datos. + +\subsubsection{Oracle Essbase: } + +Oracle Essbase es una herramienta OLAP ofrecida por Oracle Corporation. Proporciona un sistema de gestión de bases de datos +multidimensionales que permite realizar análisis y pronósticos complejos. Admite diversas técnicas de modelado de datos, incluyendo +dimensiones densas y dispersas, así como capacidades avanzadas de cálculo. Essbase se integra con otras herramientas y +plataformas de Oracle, ofreciendo una solución integral para análisis empresarial. + +\subsubsection{IBM Cognos TM1: } + +IBM Cognos TM1 es una potente herramienta OLAP diseñada para la gestión del rendimiento y la planificación. Permite a las +organizaciones crear modelos multidimensionales y realizar análisis en tiempo real de datos financieros y operativos. TM1 +ofrece un entorno dinámico y flexible para presupuestar, pronosticar y modelar escenarios. Proporciona capacidades +avanzadas de consolidación de datos, análisis "what-if" y análisis predictivo. TM1 se integra con otras herramientas de +IBM Cognos, mejorando las capacidades generales de inteligencia empresarial. + +\subsubsection{Pentaho Mondrian: } + +Pentaho Mondrian es un servidor OLAP de código abierto que forma parte de la plataforma de análisis empresarial Pentaho. +Permite a los usuarios la creación e implementaci\'on de cubos OLAP para el análisis interactivo de datos. Mondrian es +compatible con el lenguaje de consulta MDX (Multi-Dimensional eXpressions) y proporciona una interfaz basada en web +para consultar y explorar datos. Ofrece características que permiten la navegaci\'on en datos multidimensionales como +desglose, segmentación y pivotar. Mondrian se integra con otras herramientas de Pentaho, brindando una +suite integral para la integración de datos, informes y análisis. diff --git a/document/MainMatter/BusinessIntelligence/BusinessIntelligence.tex b/document/MainMatter/BusinessIntelligence/BusinessIntelligence.tex new file mode 100644 index 00000000..f031f9aa --- /dev/null +++ b/document/MainMatter/BusinessIntelligence/BusinessIntelligence.tex @@ -0,0 +1,40 @@ +\chapter{Sistemas de Inteligencia de Negocios}\label{chapter:bi-systems} + +Business Intelligence (BI) es un conjunto de metodologías, tecnologías, procesos y arquitecturas que convierten datos +en bruto en información útil para tomar decisiones comerciales y descubrir conocimientos estratégicos para los negocios. +Las herramientas de BI analizan tanto datos históricos como actuales para dar una panor\'amica completa del comportamiento +de un negocio a lo largo del tiempo y adem\'as presentan sus hallazgos en formatos visuales atractivos e intuitivos. +Con el uso de las herramientas de BI, las empresas son capaces de reducir las ineficiencias, detectar problemas potenciales, +encontrar nuevas fuentes de ingresos e identificar áreas de crecimiento futuro. + +Las soluciones de BI est\'an presentes en diversas industrias, como la medicina, las finanzas, el comercio minorista y la +fabricación. En la salud, las soluciones de BI son utilizadas para analizar datos de los pacientes y as\'i mejorar los +diagn\'osticos y tratamientos. En el \'area de las finanzas, las soluciones de BI explotan los datos financieros para +descubrir tendencias y as\'i mejorar las decisiones de inversi\'on. En la fabricación, los datos de producción son aprovechados +por las herramientas de BI para mejorar la eficiencia operativa y reducir costos de producción. Por \'ultimo, en la +venta minorista, las soluciones de BI analizan los datos de los clientes con el fin de mejorar su experiencia y +aumentar las ventas. + +Los componentes principales de una solución de BI son los mecanismos integración de datos, el almacenamiento de datos y +las herramientas de análisis y generaci\'on de informes. Los mecanismos de integración recopilan y +consolidan los datos provenientes de diversas fuentes, estos mecanismos pueden ser procesos ETL o ELT. +El almacenamiento de datos, como su nombre lo indica, es un depósito centralizado de los datos que utiliza la solución +de BI, este depósito puede ser un Almac\'en de Datos, Data Marts u otras estructuras. Las herramientas de análisis +son las encargadas de extraer información de los datos almacenados mediante estadísticas y analíticas, adem\'as de generar +informes que presenten de forma clara y entendible los resultados de los an\'alisis. + +Las secciones en las que se estructura el resto del cap\'itulo recogen un estudio de los distintos componentes de una +soluci\'on de Business Intelligence de forma respectiva. La secci\'on \ref{section:oltp} presenta los Sistemas +Transaccionales; presenta el concepto de los Sistemas OLTP, su arquitectura as\'i como una explicaci\'on de los principales +conceptos del Modelo Relacional. La secci\'on \ref{section:olap} presenta los Sistemas Anal\'iticos; +expone las ideas detras de los Sistemas OLAP, su arquitectura; explica las ideas detr\'as de los Almacenes de Datos y el +Modelo Dimensional y menciona algunas de las herramientas OLAP m\'as utilizadas en la actualidad. Por \'ultimo, la +secci\'on \ref{section:etl} brinda explicaciones sobre los Procesos ETL, sus objetivos y las operaciones que componen +estos procesos; hace una comparaci\'on entre ETL y ELT y expone algunas de las herramientas ETL m\'as utilizadas. + +\include*{MainMatter/BusinessIntelligence/TransactionalSystems} +\include*{MainMatter/BusinessIntelligence/AnalyticalSystems} +\include*{MainMatter/BusinessIntelligence/ETL} + + + diff --git a/document/MainMatter/BusinessIntelligence/ETL.tex b/document/MainMatter/BusinessIntelligence/ETL.tex new file mode 100644 index 00000000..f7a6a9f0 --- /dev/null +++ b/document/MainMatter/BusinessIntelligence/ETL.tex @@ -0,0 +1,110 @@ +\section{Procesos ETL}\label{section:etl} + +ETL son las siglas de Extract, Transform, Load, en español Extraer, Transformar y Cargar. Es un proceso fundamental en la +integración y gestión de datos. Implica extraer datos desde varios or\'igenes, generalmente con formatos distintos, +conciliarlos, mediante tecnicas de transformación y validaci\'on, en un formato compatible con un almacenamiento destino +predefinido y luego cargarlos en dicho sistema destino. Lo que permite aumentar la cantidad y la calidad de los datos +disponibles para los an\'alisis adem\'as de permitir la integración con sistemas heredados. ETL est\'a presente en la +industria desde la década de 1970 y empez\'o a ganar popularidad con el auge de los almacenes de datos\cite{etl_vs_elt_amazon}. + +\subsection{Objetivos de los procesos ETL} + +El objetivo fundamental de los procesos ETL es garantizar la calidad, consistencia y confiabilidad de los datos para +fines anal\'iticos y de toma de decisiones. Adem\'as, cumple con otros objetivos clave. En una primera instancia, +tienen el objetivo de consolidar datos de m\'ultiples fuentes, d\'igase bases de datos, hojas de c\'alculo, APIs, +archivos planos y sistemas externos, en un formato unificado y estandarizado. La consolidación de los datos facilita +los procesos de an\'alisis y de generación de informes de datos. En segundo lugar, con los procesos ETL se busca +limpiar y transformar los datos, asegurando que sean precisos, completos y cumplan con las reglas y requisitos comerciales. +Por \'ultimo, ETL permite la integración con datos en tiempo real e históricos, lo cual brinda a las organizaciones una visión +completa de sus datos a lo largo del tiempo, mejorando la obtenci\'on de conocimiento y la toma de decisiones. + +\subsection{ETL vs ELT} + +Extraer, Cargar y Transformar, ELT por sus siglas en ingl\'es es un proceso derivado de ETL solo que invierte las operaciones +de carga y transformación. En ELT se cargan los datos en el sistema destino justo despu\'es de ser extra\'idos de la fuente +o\'igen. La transformaciónde los datos extr\'idos es responsabilidad del sistema destino. La mayor parte de las +transformaciones se realizan en la etapa de análisis y se cargan los datos en bruto mínimamente procesados en el +almacenamiento de datos. + +El uso m\'as tipico de ELT yace en el \'ambito del Big Data\cite{raunakjhawar_ETL_microsoft}. La adopción de la +infraestructura en la nube, que proporciona a las bases de datos de destino la potencia de procesamiento necesaria +para realizar las transformaciones, hacen que la variante ELT sea elegida cada vez con m\'as frecuencia. + +Comparando ambos enfoques, con ELT se simplifica la arquitectura pues se elimina del proceso el motor de transformación. +Tambi\'en, al escalar el almacenamientode datos de destino también se escala el rendimiento del proceso ELT pues es all\'i +donde se realizan las transformaciones. ELT omite el paso de copia presente en ETL que puede ser una operaci\'on muy costosa +si el conjunto de datos es grande. Pero solo es efectivo usar este enfoque si el sistema destino es lo suficientemente +potente como para transformar los datos de manera eficiente. + +Por otro lado, ETL es la mejor opci\'on para el tratamiento de datos estructurados\cite{etl_vs_elt_amazon}. Con +ETL se transforma el formato de los datos, pero se mantiene su naturaleza estructurada. ETL es una tecnología madura +con m\'as de 20 años de explotaci\'on, sus protocolos y buenas pr\'acticas son conocidos y bien documentados. Como principal +desventaja le acompaña el hecho de que requiere m\'as definici\'on al principio, pues deben definirse los tipos de datos +del destino, estructuras y relaciones. + +\subsection{Operaciones de los Procesos ETL} + +Como su nombre lo indica, las operaciones que conforman los Procesos ETL son: + +\subsubsection{Extracci\'on} + +Es el primer paso de ETL. En este paso se extraen datos desde m\'ultiples fuentes y se colocan en un \'area de preparaci\'on +en donde ser\'an transformados. Cada fuente de datos puede usar una organizaci\'on diferente de los datos o formatos distintos. +El proceso de extracci\'on debe generar un impacto m\'inimo en el sistema or\'igen, si se extraen muchos datos se podr\'ia +exceder la capacidad de carga del r\'igen, provocando que colapse y no est\'e disponible para su uso. Por esta los grandes +sistemas consumidores de datos programan sus actividades de extracci\'on para d\'ias u horarios donde su impacto sea +m\'inimo. + +La frecuencia con la que se realiza la extracci\'on desde el or\'igen depende del mecanismo implementado de captura de datos +modificados. Algunos sistemas or\'igen notifican cuando se ha cambiado un registro de datos. A continuaci\'on se ejecuta el +proceso de extracci\'on para ese cambio. Algunos sistemas no son capaces de identificar cambios en los datos, por lo que +la estrategia se simplifica a volver a extraer todos los datos del or\'igen. + +\subsubsection{Transformaci\'on} + +El paso de Tranformaci\'on es el encargado de consolidar los datos para prepararlos para el almacenamiento de datos destino. +Esta fase puede implicar los siguientes tipos de cambios de datos: + +\begin{itemize} + \item Seleccionar solo algunas columnas para ser cargadas. + \item Traducir c\'odigos (por ejemplo, si la fuente almacena una "M" para Masculino y "F" para Femenino pero el destino + tiene que guardar "1" para Masculino y "2" para Femenino) + \item Codificar valores, ejemplo de esto es convertir "Principal" en "P" o "Secundario" en "S" + \item Eliminar datos duplicados. + \item Revisi\'on de los formatos de los datos. Un caso com\'un de esto es la conversi\'on de unidades de medida + o la conversi\'on de los formatos de fecha/hora. +\end{itemize} + +También se pueden realizar transformaciones m\'as avanzadas, que siguen las reglas del negocio para optimizar los datos y +facilitar los análisis: + +\begin{itemize} + \item Aplicar directamente reglas comerciales a los datos, por ejemplo convertir los ingresos en ganancias restando los + gastos. + \item Vincular datos de diferentes or\'igenes. Por ejemplo, calcular el costo total de compra de un producto + sumando el valor de compra de los diferentes proveedores y almacenando solo el total final en el sistema de destino. + \item Cifrar datos confidenciales para cumplir con las leyes de datos o de privacidad antes de cargar la informaci\'on + en el sistema destino. +\end{itemize} + + +\subsubsection{Carga} + +La fase de Carga es el momento en que los datos resultantes de la fase de Transformaci\'on son cargados en sistema destino. +En dependencia de los requisitos de cada organización, el proceso de carga abarca una variedad de acciones diferentes. +En ocasiones se sobrescribe la información antigua de la bases de datos con nuevos datos. En cambio, los Almacenes de Datos +conservan todos los datos con el objetivo de mantener un historial. La mayoría de las organizaciones que utilizan ETL, +tienen este proceso automatizado, correctamente definido, continuo y por lotes\cite{ETL_amazon}. La carga de datos puede +ser de forma completa donde todos los datos de la fuente se transforman y se mueven al almacenamiento de datos, o bien +puede ser de forma progresiva donde se carga la diferencia entre los sistemas de origen y destino a intervalos regulares. + +\subsection{Herramientas para Procesos ETL} + +Actualmente existen varias herramientas ETL en el mercado, cada una posee características propias y capacidades \'unicas. +Entre las m\'as populares encontramos a Talend Data Fabric, Informatica PowerCenter, Fivetran, Stitch y Xplenty. Estas +herramientas ofrecen gestión de datos basada en la nube, la integración basada en metadatos y soporte para varias bases +de datos relacionales y no relacionales + +Además de las opciones anteriores, existen varias opciones populares de c\'odigo abierto, como son Apache NiFi, AWS Glue +e Informatica. Estas herramientas ofrecen casi todas las funcionalidades de sus contrapartes comerciales y a menudo +son m\'as personalizables y flexibles. \ No newline at end of file diff --git a/document/MainMatter/BusinessIntelligence/TransactionalSystems.tex b/document/MainMatter/BusinessIntelligence/TransactionalSystems.tex new file mode 100644 index 00000000..125531fd --- /dev/null +++ b/document/MainMatter/BusinessIntelligence/TransactionalSystems.tex @@ -0,0 +1,164 @@ +\section{Online Transaction Processing (OLTP)} \label{section:oltp} + +En el ámbito de los sistemas de administración de bases de datos, el Procesamiento de Transacciones en Línea (OLTP) es un +tipo de procesamiento de datos que consiste en ejecutar una serie de transacciones que ocurren simultáneamente y en +tiempo real. Los sistemas OLTP están diseñados para garantizar la integridad y coherencia de los datos en un entorno de +múltiples usuarios. + +Los datos transaccionales son información que rastrea las interacciones relacionadas con las actividades de una +organización. Estas interacciones pueden ser transacciones comerciales, como pagos de clientes, pagos realizados +a proveedores, movimientos en el inventario de una organización, pedidos recibidos o servicios entregados. Los eventos +transaccionales, usualmente contienen una dimensión de tiempo, algunos valores +numéricos y referencias a otros datos\cite{oltpAzure}. Aunque, con el paso de los años, especialmente desde la llegada de +Internet, la definición de transacción +se ha expandido para poder abarcar todas las posibles formas de interacción digital entre un usuario y un negocio a través +de cualquier sensor conectado a la web. Además, incluye cualquier tipo de acción, como descargar pdfs en una +página web, ver un video específico, entre otros\cite{oltpOracle}. + +Los sistemas OLTP se centran principalmente en respaldar las operaciones comerciales diarias. Las transacciones que procesan +son brebes y sencillas, que normalmente implican la inserción, modificación o recuperación de cantidades pequeñas de datos. + +\subsection{Objetivos de los sistemas OLTP} + +El objetivo fundamental de los sistemas OLTP es brindar rapidez en las consultas de los usuarios y +garantizar que los datos permanezcan consistentes y actualizados. De forma m\'as espec\'ifica, los objetivos de +los sistemas OLTP son: + +\begin{itemize} + \item Posibilitar el procesamiento de transacciones en tiempo real. La rapidez que brinda OLTP en el procesamiento de + las transacciones, permite a las organizaciones mantener datos actualizados y + confiables. + + \item Mantener la integridad y la coherencia de los datos durante todo el proceso transaccional. Los sistemas OLTP + cumplen las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad), por tanto garantizan un + procesamiento de datos confiable y sin errores. + + \item Recuperar y manipular datos de forma eficiente para respaldar las operaciones transaccionales. Los sistemas OLTP + est\'an optimizados para responder consultas e implementan mecanismos de indexación que proporcionan rapidez y presici\'on + a la hora de recuperar datos. Adem\'as, ofrecen capacidades s\'olidas de manipulaci\'on de datos, lo que permite + insertar, eliminar o actualizar registros de forma segura. + + \item Proporcionar alta disponibilidad y escalabilidad. Es necesario que los sistemas OLTP sean capaces de manejar una + gran cantidad de usuarios y transacciones concurrentes sin verse afectado su rendimiento. + + \item Mantener la seguridad y la privacidad de los datos es un objetivo fundamental de los sistemas OLTP. Con este fin, + estos sistemas implementan medidas de seguridad, como controles de acceso, encriptación y mecanismos de autenticación, + para proteger los datos de manipulaciones o accesos no autorizadas. +\end{itemize} + +\subsection{Arquitectura de los sistemas OLTP} + +Los sistemas OLTP se basan en una arquitectura cliente-servidor, donde los clientes envían solicitudes al servidor para +realizar transacciones en la base de datos. El servidor procesa estas solicitudes y actualiza la base de datos en tiempo +real. Los sistemas OLTP también utilizan técnicas de concurrencia y control de transacciones para garantizar la integridad +de los datos y prevenir problemas como la corrupción de datos o la pérdida de información. Por tanto la arquitectura de los +sistemas OLTP puede ser separada, generalmente, en los siguientes componentes: + +\begin{itemize} + \item \textbf{Interfaz de usuario:} Este componente permite la interacci\'on entre los usuarios y sistema OLTP. Seg\'un + los requisitos del sistema, la interfaz puede ser basada en la web, una aplicaci\'on m\'ovil o de escritorio. + + \item \textbf{Lógica del Negocio:} Este componente alberga las reglas comerciales y la lógica + que rige el procesamiento de las transacciones. Es la encargada de validar los datos entrados por los usuarios, + garantizar el cumplimiento de las restricciones de integridad y organizar la distribuci\'on de los datos entre los + distintos componentes del sistema. + + \item \textbf{Administrador de transacciones:} El administrador de transacciones es el encargado de asegurar la + la coherencia y atomicidad de las transacciones. Implementa mecanismos para el manejo de múltiples transacciones + simultáneas, garantizando as\'i su ejecuci\'on de forma aislada y que los cambios que generen sean confirmados o + revertidos. Implementa mecanismos de control de concurrencia y tolerancia a fallos. + + \item \textbf{Almacenamiento de datos:} Por norma general, los sistemas OLTP suelen hacer uso de sistemas de gestión + de bases de datos relacionales (RDBMS) para almacenar datos transaccionales, aprovechando as\'i las bondades del + Modelo Relacional. +\end{itemize} + +\subsection{Modelo Relacional} + +En los primeros años de las bases de datos, cada aplicaci\'on defin\'ia su propia estructura para almacenar sus datos. +Si otros desarrolladores querían crear aplicaciones que usen esos datos, primero deb\'ian familiarizarse a fondo con +la estructura de datos particular que les servir\'ia de fuente. Estas estructuras particulares, eran ineficientes, difíciles +de mantener y optimizar. El Modelo Relacional fue concebido para dar soluci\'on al problema de las m\'ultiples estructuras +de datos arbitrarias. + +El Modelo Relacional impuso un estándar para representar datos y consultarlos que cualquier aplicación pod\'ia usar. +Desde sus inicios, fue reconocido por la comunidad de desarrolladores que la principal fortaleza del Modelo Relacional +estaba en el uso de tablas, que eran una forma intuitiva, eficiente y flexible de almacenar y acceder a +información estructurada. + +Con el paso del tiempo, surgió otro de los pilares del Modelo Relacional, el Lenguaje de Consulta Estructurado, SQL por +sus siglas en ingl\'es. Durante años, SQL ha sido ampliamente utilizado como lenguaje para escribir y consultar las bases +de datos. El basamento de SQL es el \'algebra relacional, por lo cual es un lenguaje matemático coherente que mejora el +rendimiento de todas las consultas. + + +\subsubsection{Ventajas del Modelo Relacional} + +Existen varias ventajas al usar el modelo relacional para administrar datos: + +\begin{itemize} + \item \textbf{Flexibilidad:} Las operaciones de inserción, modificación y eliminaci\'on son realizadas sin interrumpir + todo el sistema. + + \item \textbf{Escalabilidad:} Las bases de datos relacionales pueden escalar tanto vertical como horizontalmente, + asegurando el manejo de grandes volúmenes de datos de forma eficiente. Esta característica es primordial en el + mundo actual basado en datos. + + \item \textbf{Integridad de los datos:} El diseño de las relaciones y restricciones del Modelo Relacional garantiza + el cumplimiento de la integridad de los datos. +\end{itemize} + + +\subsubsection{Componentes del Modelo Relacional} + +El Modelo Relacional consta de varios componentes claves. En primer lugar tenemos las Tablas. En el Modelo Relacional +los datos son almacenados en tablas. Cada tabla representa una entidad o concepto. Las tablas est\'an formadas por filas +y columnas, lo cual permite el almacenamiento estructurado de los datos. + +Por otra parte est\'an los Atributos. Estos definen las características o propiedades de una entidad. Cada columna de una +Tabla corresponde a un Atributo de la entidad que representa dicha Tabla. Cada Atributo posee su propio tipo de datos y +ayudan a definir la naturaleza y la estructura de los datos. Además, hay atributos llamados llaves primarias cuyos +valores son \'unicos para cada registro y sirven para identificarlos univocamente. También, las llaves for\'aneas son +otro tipo de atributo que referencian a registros de otras tablas. + +Por \'ultimo, encotramos las Relaciones. Estas representan asociaciones entre tablas y definen como las Tablas interactúan +entre si. Además, juegan un papel fundamental en el mantenimiento de la integridad de los datos y en su recuperación de forma +eficiente. + +Pero organizar los datos en Tablas, sin seguir alguna regla puede contribuir a la aparici\'on de datos redundantes en la +base de datos. La redundancia en las bases de datos se manifiesta cuando se tienen varias copias de los mismos datos en la +base de datos, por ejemplo, si se tiene una tabla que representa a la entidad Estudiante que est\'a relacionada con otra +tabla Departamento, almacenar los detalles completos del departamento como id\_departamento, nombre\_departamento y +jefe\_departamento repetidamente por cada registro de estudiante es redundante y mal aprovecha los recursos de +almacenamiento. La soluci\'on a este problema yace en el proceso de Normalización. + + +\subsubsection{Normalización en el Modelo Relacional} + +La Normalización es el proceso de dividir tablas m\'as grandes en otras m\'as pequeñas y manejables, siguiendo +un conjunto de reglas llamadas formas normales. Su objetivo es organizar los datos para evitar la redundancia y +eliminar anomalías en los datos. + + +\subsubsection{Formas Normales} + +El proceso de normalizaci\'on consta de una serie de pasos, donde en cada uno se le realizan modificaciones a las tablas de +la base de datos con el objetivo de que cumplan con las restricciones de una Forma Normal específica: + +\begin{itemize} + \item \textbf{Primera Forma Normal:} Una tabla se encuentra en Primera Forma Normal si todos los valores de los atributos + son at\'omicos. + + \item \textbf{Segunda Forma Normal:} Una tabla se encuentra en Segunda Forma Normal si est\'a en Primera Forma Normal + y todos los atributos no llaves dependen completamente de la llave. + + \item \textbf{Tercera Forma Normal:} Una tabla se encuetra en Tercera Forma Normal si est\'a en Segunda Forma Normal + y los atributos no llaves son mutuamente independientes. +\end{itemize} + +Las Formas Normales continuan con la Forma Normal de Boyce-Codd, cuarta y quinta Forma Normal. Llevar el proceso +de normalizaci\'on hasta Formas Normales superiores a la tercera es cuesti\'on de diseño de los desarrolladores, cada forma +normal superior aporta un grado m\'as de especializac\'on bajo una p\'erdida de expresividad en el diseño. + +Con el proceso de Normalización se logra mejorar la consistencia y la integridad de los datos. Se eliminan las anomal\'ias +en la inserción, eliminaci\'on y modificación de los registros. Se eliminan datos redundantes y se optimiza el almacenamiento. diff --git a/document/MainMatter/Implementation.tex b/document/MainMatter/Implementation/Implementation.tex similarity index 100% rename from document/MainMatter/Implementation.tex rename to document/MainMatter/Implementation/Implementation.tex diff --git a/document/MainMatter/Proposal.tex b/document/MainMatter/Proposal/Proposal.tex similarity index 100% rename from document/MainMatter/Proposal.tex rename to document/MainMatter/Proposal/Proposal.tex diff --git a/document/Thesis.tex b/document/Thesis.tex index 7f16e298..56448073 100644 --- a/document/Thesis.tex +++ b/document/Thesis.tex @@ -14,6 +14,7 @@ \usepackage{xcolor} \usepackage{multicol} \usepackage{graphicx} +\usepackage{newclude} \floatstyle{plaintop} \restylefloat{table} \addbibresource{Bibliography.bib} @@ -89,9 +90,12 @@ \mainmatter \include{MainMatter/Introduction} -\include{MainMatter/Background} -\include{MainMatter/Proposal} -\include{MainMatter/Implementation} + +% Business Intelligence section +\include{MainMatter/BusinessIntelligence/BusinessIntelligence} +\include{MainMatter/AutomaticETL/AutomaticETL} +\include{MainMatter/Proposal/Proposal} +\include{MainMatter/Implementation/Implementation} \backmatter diff --git a/document/uhthesis.cls b/document/uhthesis.cls index e5b37e1f..01a7bde8 100644 --- a/document/uhthesis.cls +++ b/document/uhthesis.cls @@ -23,7 +23,7 @@ \RequirePackage{csquotes} \RequirePackage[ style=apa, - citestyle=authoryear, + citestyle=numeric, hyperref=true, backref=true ]{biblatex} @@ -77,14 +77,14 @@ \DeclareCiteCommand{\cite} {\usebibmacro{prenote}} {\usebibmacro{citeindex}% - \printtext[bibhyperref]{\usebibmacro{cite}}} + \printtext[bibhyperref]{[\usebibmacro{cite}]}} {\multicitedelim} {\usebibmacro{postnote}} \DeclareCiteCommand*{\cite} {\usebibmacro{prenote}} {\usebibmacro{citeindex}% - \printtext[bibhyperref]{\usebibmacro{citeyear}}} + \printtext[bibhyperref]{\usebibmacro{cite}}} {\multicitedelim} {\usebibmacro{postnote}}