La arquitectura de datos es un conjunto de reglas, políticas y modelos que determinan qué tipo de datos se recopilan y cómo se utilizan, procesan y almacenan en un sistema de base de datos. La integración de datos, por ejemplo, depende de Arquitectura de datos para obtener instrucciones sobre el proceso de integración. Sin el cambio de un paradigma de programación a un paradigma de arquitectura de datos, las computadoras modernas serían mucho más torpes y lentas.
En los primeros días de las computadoras, se crearon programas simplistas para hacer frente a tipos específicos de problemas informáticos, y ni siquiera se consideraron conceptos como la integración de datos. Cada programa fue aislado de otros programas. Desde la década de 1940 hasta principios de la de 1970, el procesamiento de programas fue la principal preocupación. Por lo general, no se le dio mucha (o ninguna) consideración a una estructura arquitectónica para los datos. El enfoque principal de un programador era hacer que una computadora realizara acciones específicas que respaldaran los objetivos a corto plazo de una organización. Solo se usaron los datos definidos como "necesarios para el programa", y no se usaron computadoras para el almacenamiento de datos a largo plazo. La recuperación de datos requería la capacidad de escribir programas capaces de recuperar información específica, lo que requería mucho tiempo y dinero.
APRENDA CÓMO CONSTRUIR UN PROGRAMA DE ALFABETIZACIÓN DE DATOS
Desarrollar la alfabetización de datos es clave para convertirse en una organización basada en datos: eche un vistazo a nuestros cursos en línea para comenzar.
Pasando de un paradigma de programación a un paradigma de arquitectura de base de datos
En 1970, Edgar F. Codd publicó un artículo (Un modelo relacional de datos para grandes bancos de datos compartidos) que describe un procedimiento relacional para organizar datos. La teoría de Codd se basó en las matemáticas utilizadas en la teoría de conjuntos, combinada con una lista de reglas que aseguraban que los datos se almacenaran con un mínimo de redundancia. Su enfoque creó con éxito estructuras de bases de datos que agilizaron la eficiencia de las computadoras. Antes del trabajo de Codd, los programas COBOL y la mayoría de los demás tenían sus datos ordenados jerárquicamente. Este arreglo obligó a iniciar una búsqueda en las categorías generales y luego buscar en categorías cada vez más pequeñas. El enfoque relacional permitió a los usuarios almacenar datos de una manera más organizada y eficiente utilizando tablas bidimensionales (o, como las llamó Codd, "relaciones").
En 1976, mientras trabajaba en el MIT, Peter Chen publicó un artículo (El modelo entidad-relación: hacia una vista unificada de los datos) presentando el "modelado de entidad/relación", más comúnmente conocido hoy en día como "modelado de datos". Su enfoque representó estructuras de datos gráficamente. Dos años más tarde, Oracle anunció el primer sistema de administración de bases de datos relacionales (RDBMS) diseñado para empresas.
Las personas que trabajaban con computadoras comenzaron a darse cuenta de que estas estructuras de datos eran más confiables que las estructuras de programas. Esta estabilidad fue respaldada por el rediseño del medio del sistema y el aislamiento de los procesos entre sí (similar a la forma en que los programadores mantienen sus programas aislados). La clave de este rediseño fue la adición de búferes de datos.
Amortiguadores originalmente eran un sistema de almacenamiento de memoria temporal diseñado para eliminar datos de las memorias de una computadora primitiva rápidamente, para que la computadora no se atascara y pudiera continuar trabajando en problemas. Luego, los datos se transfirieron del búfer a una impresora, que "lentamente" imprimió los cálculos más recientes. La versión actual de un búfer de datos es un área compartida por dispositivos, o procesos de un programa, que operan a diferentes velocidades o con diferentes prioridades. Un búfer moderno permite que cada proceso o dispositivo funcione sin conflictos. Similar a un caché, un búfer actúa como un "espacio de almacenamiento intermedio", pero también ayuda a coordinar actividades separadas, en lugar de simplemente simplificar el acceso a la memoria.
La comunidad empresarial reconoció rápidamente las ventajas de las ideas de Edgar F. Codd y Peter Chen. Los nuevos diseños de estructuras de datos fueron notablemente más rápidos, más flexibles y más estables que las estructuras de programas. Además, sus ideas provocaron un cambio cultural en la comunidad de programación de computadoras. La estructura de los datos ahora se consideraba más importante que los programas.
Supuestos perdidos durante el cambio de paradigma
La evolución de la arquitectura de datos requirió la eliminación de tres suposiciones basicas. (Suposición: algo que se da por sentado; una conjetura, que carece de pruebas sólidas y se trata como un hecho).
Suposición 1: Cada programa debe estar aislado de otros programas. Esta filosofía de aislamiento condujo a la duplicación de códigos de programa, definiciones de datos y entradas de datos. El enfoque relacional de Codd resolvió el problema de la duplicación innecesaria. Su modelo separó el esquema o diseño de la base de datos del almacenamiento de información física (convirtiéndose en el estándar para los sistemas de bases de datos). Su modelo relacional señaló que no era necesario almacenar los datos en programas separados y aislados, y que no era necesario duplicar innecesariamente las entradas de datos y la codificación de programas. Se podría utilizar una sola base de datos relacional para almacenar todos los datos. Como resultado, la consistencia podía estar (casi) garantizada y era más fácil encontrar errores.
Suposición 2: La entrada y la salida son iguales y deben diseñarse con pares coincidentes. Tanto los dispositivos de salida como los de entrada actualmente tienen tasas de procesamiento de datos que pueden variar enormemente. Esto es bastante diferente de la expectativa de que ambos operarán a la misma velocidad. El uso de búferes iniciados en la realización de la salida podría, y debería, tratarse de manera diferente a la entrada. Las innovaciones de Peter Chen sacaron a la luz las diferencias entre los creadores de datos y los consumidores de datos. Los consumidores de datos generalmente quieren ver grandes cantidades de información de diferentes partes de la base de datos subyacente para comparar y extraer eclécticamente la información más útil. Los creadores de datos, por otro lado, se enfocan en manejarlos, un proceso a la vez. Los objetivos de los creadores de datos (entrada) y los consumidores de datos (salida) son completamente diferentes.
Suposición 3: La organización de una empresa debe reflejarse en sus programas informáticos. Con el uso de búferes y una base de datos relacional, la noción de “programas” debería imitar la estructura de una empresa, cambiando gradualmente. Las bases de datos más flexibles asumieron el papel de proporcionar una estructura útil para que las empresas la siguieran, mientras recopilaban y procesaban la información. Un modelo de datos moderno reflejará tanto la organización de una empresa como las herramientas utilizadas para alcanzar sus objetivos.
SQL y arquitectura de datos
El enfoque relacional de Codd resultó en la lenguaje de consulta estructurado (SQL), convirtiéndose en el lenguaje de consulta estándar en la década de 1980. Las bases de datos relacionales se hicieron bastante populares e impulsaron el mercado de las bases de datos, lo que a su vez provocó una gran pérdida de popularidad de los modelos de bases de datos jerárquicas.
A principios de la década de 1990, muchas de las principales empresas informáticas (todavía enfocadas en programas) intentaron vender costosas y complicadas bases de datos.
productos En respuesta, empresas nuevas y más competitivas comenzaron a lanzar herramientas y software (Oracle Developer, PowerBuilder) para mejorar la arquitectura de datos de sistemas. A mediados de la década de 1990, el uso de Internet promovió un crecimiento significativo en la industria de bases de datos y la venta general de computadoras.
Un resultado de las bases de datos diseñadas arquitectónicamente es el desarrollo de Administración de datos. Las organizaciones y las empresas han descubierto que la información en sí misma es valiosa para la empresa. Durante la década de 1990, comenzaron a aparecer los títulos "administrador de datos" y "administrador de base de datos". El administrador de datos es responsable de la calidad e integridad de los datos utilizados.
Los sistemas de administración de bases de datos relacionales han hecho posible crear una base de datos que presenta un esquema conceptual (una especie de mapa) y luego ofrece diferentes perspectivas de la base de datos, diseñadas tanto para los creadores como para los consumidores de datos. Además, cada sistema de administración de bases de datos puede ajustar sus parámetros de almacenamiento físico por separado de la estructura de columnas y la tabla.
NoSQL y arquitectura de datos
NoSQL no es un programa Es un sistema de gestión de base de datos y utiliza una arquitectura bastante simple. Puede ser útil cuando manejo de grandes datos y no se necesita un modelo relacional. Los sistemas de bases de datos NoSQL son bastante diversos en los métodos y procesos que utilizan para administrar y almacenar datos. Los sistemas SQL a menudo tienen más flexibilidad en términos de funcionalidad que los sistemas NoSQL, pero carecen de la escalabilidad por la que los sistemas NoSQL son famosos. Sin embargo, ahora hay numerosos paquetes comerciales disponibles que combinan un enfoque de "lo mejor de ambos mundos", y cada vez llegan más al mercado.
Varias organizaciones cubiertas recientemente en artículos y entrevistas sobre DATAVERSITY® (hay muchas otras posibilidades disponibles) ofrecen una solución de arquitectura de datos para procesar big data con herramientas comunes a las bases de datos relacionales. Perspectivas de Kyvos vende software que funciona con sistemas de almacenamiento Hadoop. Su combinación Hadoop/OLAP promueve el procesamiento de datos "y" estructurados no estructurados en una variedad de escalas, lo que permite que los grandes datos se analicen con relativa facilidad.
Hackolada también vende un paquete de software, con un modelo de datos fácil de usar que ofrece herramientas "altamente funcionales" para manejar NoSQL. El software fusiona NoSQL con la simplicidad de los gráficos visuales. Esto, combinado con otras herramientas de Hackolade, reduce el tiempo de desarrollo y aumenta la calidad de la aplicación. Actualmente, su software es compatible con los esquemas Couchbase, DynamoDB y MongoDB (tienen planes para incluir bases de datos NoSQL adicionales).
RedisLabs combina el acceso a su nube con su paquete de software, Redis Pack, para proporcionar otra solución arquitectónica. Los tres puntos fuertes que ofrece Redis Pack y su nube son la velocidad, la persistencia (guardar su información) y la variedad de tipos de datos que tienen disponibles. Esencialmente, Redis es un NoSQL "extremadamente rápido", almacén de datos de valor-clavey actúa como una base de datos, un caché y un intermediario de mensajes.
relación proporciona un servicio. Han creado una plataforma de administración en la nube y brindan las herramientas y los servicios necesarios para lograr procesar big data. Proporcionan investigadores, fusionan grandes datos de múltiples fuentes con Master Data Management (MDM) y desarrollan objetivos unificados. Los sistemas de Reltio son compatibles con una variedad de industrias, incluidas la venta minorista, las ciencias de la vida, el entretenimiento, la atención médica y el gobierno.
La arquitectura de datos ha cambiado por completo desde sus inicios, y probablemente debido a las nuevas tendencias, como la Internet de las Cosas, la computación en nube, microservicios, análisis avanzado, máquina de aprendizaje y la inteligencia artificial, y las tecnologías emergentes como blockchain continuarán modificándose aún más en el futuro.
Imagen utilizada bajo licencia de Shutterstock.com
