The Birth of Data Marts and Data Warehouses: Transforming Decision Support Systems (1980-1990)

Recap: Data Architecture Advancements: Operational Systems ????? (1980-1990): The preceding article delved into the evolution of Data Architecture from 1980 to 1990, emphasizing the progress in Operational Systems. During this time, there was a shift from monolithic to modular designs, the advent of relational databases, and the emergence of client-server architecture, all of which greatly enhanced the efficiency and scalability of operational systems. Additionally, the article discussed the rise of ERP and CRM systems, the move from bespoke interfaces to standardized protocols, and the establishment of Data Quality, Metadata, Data Governance, and Data security practices. These developments formed the cornerstone of contemporary data management and decision-making processes. For an in-depth understanding of this critical era, please consult the full article.. Part 3.1: Data Architecture Advancements in the 1980-1990 Era -> ??? Operational Systems ??

Executive Summary and Introduction ??

Have you ever considered the origins of the data systems we depend on today? This article guides you through the captivating evolution of data management, starting with the early Decision Support Systems (DSS) from 1960 to 1980, and progressing to the advanced Data Marts and Data Warehouses of the 1980 to 1990 period. Explore how these developments established the groundwork for the state-of-the-art technologies we utilize today, and understand the pivotal innovations that revolutionized data accessibility, storage, and analysis. Although reading the entire article is recommended for comprehensive insight, you are welcome to navigate directly to the sections of greatest interest to you.

In the early days of data management, Decision Support Systems (DSS) were the pioneers, helping organizations make informed decisions. As technology advanced, these systems evolved into more specialized and powerful tools, leading to the creation of Data Marts and Data Warehouses. This article explores this remarkable journey, highlighting the key milestones and innovations that shaped the data landscape. Understanding this evolution is essential for appreciating the sophisticated data management frameworks we have today. Join us as we delve into the history and significance of these transformative advancements.

Section Summaries

1. Executive Summary and Introduction ??: Provides an overview of the article’s focus on the evolution of data management from the early Decision Support Systems (DSS) of 1960-1980 to the advanced Data Marts and Data Warehouses of 1980-1990.
2. Technological Advancements (1980-1990) ??: Discusses the significant technological advancements in data storage, processing, and analysis during the 1980s and 1990s. Covers the introduction of Relational Database Management Systems (RDBMS), reporting tools, and advanced analytics tools.
3. The Rise of Decision Support Systems (1980-1990) ??: Explores the development and adoption of Decision Support Systems (DSS) during the 1980-1990 period. Highlights the key features and functionalities of early DSS and the challenges they faced, leading to the development of more advanced tools and systems.
4. The Emergence of Data Marts and Data Warehouses ??: Examines the need for centralized data management systems to handle growing data volumes. Discusses the development of Data Marts and Data Warehouse Architecture Frameworks, providing centralized data storage and improved data accessibility.
5. Centralized Data Management Architecture (1980-1990) ???: Outlines the key components and practices involved in building a centralized data management system during the 1980-1990 era. Covers steps such as learning operational systems, selecting RDBMS, designing layered architecture, implementing data quality measures, and more.
6. Data Warehouse ??: Defines what a Data Warehouse is and explains why organizations built them. Discusses the development and purpose of Enterprise Data Warehouses (EDW) and Operational Data Stores (ODS), along with their use cases and analytics.
7. Data Marts ??: Defines what a Data Mart is and explains why organizations built them. Discusses the different types of Data Marts (Independent, Dependent, Hybrid), their development, purpose, and use cases. Covers the RDBMSs considered for Data Marts.
8. Data Warehouse/Data Marts Concepts and Frameworks ????: Explains the concepts and frameworks behind Data Warehouses and Data Marts, including schema representation (Star Schema, Snowflake-Star Schema), Slowly Changing Dimensions (SCD), and the ETL approach. Discusses data modeling and data layered architecture.
9. The Emergence of Reporting Tools from Model-Driven Decision Support Systems (1980-1990) ??: Explores the development of reporting tools for analytics and data visualization, replacing the need for permanent data storage systems. Discusses the design of reporting tools architecture, data consumption methods, and tools and vendors.
10. Knowledge-Driven DSS to Advanced Analytics Tools (1980-1990) ??: Discusses the integration of Knowledge-Driven DSS with advanced analytics tools to provide deeper insights. Covers the development of separate advanced analytics tools for statistical analysis and modeling, along with tools and vendors.
11. Document-Driven DSS (1980-1990) ??: Explores the development of Document-Driven DSS to manage and retrieve unstructured and semi-structured data. Discusses the architecture integration, tools and vendors, content management patterns, and use cases.
12. Collaboration-Driven DSS to Collaborative Platforms (1980-1990) ??: Examines the development of collaborative platforms to facilitate communication and collaboration among team members. Discusses the architecture integration, tools and vendors, collaboration patterns, and use cases.
13. Hierarchical Structure and Roles (1980-1990) ??: Outlines the hierarchical structure and roles involved in managing centralized data management systems during the 1980-1990 era. Covers roles such as CIO, Data Management Director, Data Architect, DBA, ETL Developer, Data Analyst, Data Governance Manager, and Project Manager.
14. Pain Points Resolved and New Challenges (1980-1990) ??: Highlights the key pain points resolved from the 1960-1980 era, such as data redundancy and manual processing, and introduces new challenges faced in the 1980-1990 era, including scalability issues and performance bottlenecks.
15. Conclusion ??: Summarizes the key points discussed in the article and emphasizes the transformative impact of the advancements in data management and analysis during the 1980-1990 era.
16. Call to Action ??: Encourages readers to reflect on the historical advancements and consider how these lessons can be applied to current and future data architecture projects. Invites readers to share their thoughts, questions, and experiences, and to stay tuned for the next article in the series, which will explore the evolution of data systems from 1990 to 2000.

Technological Advancements (1980-1990) ??

During the 1980s and 1990s, significant technological advancements revolutionized data storage, processing, and analysis. The introduction of Relational Database Management Systems (RDBMS) provided a more flexible and efficient way to manage data. Additionally, the development of Reporting (analytics) tools and Advanced Analytics tools further enhanced data analysis capabilities. These advancements included:

• Data Storage and Processing Systems (RDBMS): Modern RDBMS (Relational Database Management Systems) technologies like Teradata, Oracle, Microsoft SQL Server, IBM DB2, and Sybase.
• Data Objects and SQL Commands: Various above mentioned RDBMS database objects such as tables, views, macros, triggers, and stored procedures, along with SQL commands like DDL, DML, SELECT, and DCL.
• Data Extraction and Loading Tools: ETL (Extract, Load and Transform) tools and frameworks for extracting and integrating data within the systems. Some of the RDBMSs come up with their own ETL Tools.
• Data Retrieval Tools: Tools and frameworks for accessing and viewing data from the respective RDBMSs.
• Proprietary and Closed Platform Features: Many RDBMSs were closed platforms, meaning they were proprietary and managed their own operating systems. This made integration and consumption more challenging compared to today’s more open systems.
• Administrative and Management Tools: Each RDBMS came with its own set of tools for administration, performance management, and monitoring.

RDBMS (Relational Database Management Systems) Technologies

Teradata: Known for its scalability and parallel processing capabilities, Teradata was widely used for large-scale data warehousing.

• Data Objects and SQL Commands: Supported tables, views, macros (for automating repetitive tasks), and primary and secondary indexes. SQL commands included DDL (CREATE, DROP, ALTER), DML (INSERT, UPDATE, DELETE), SELECT, and DCL (GRANT, REVOKE).
• Data Extraction and Loading Tools: FastLoad, MultiLoad, TPump, BTEQ. These tools used batch processing, file transfer, and ODBC methods.
• Data Retrieval Tools: BTEQ (Basic Teradata Query) for querying and reporting.
• Proprietary and Closed Platform Features: Teradata managed its own proprietary operating system, making it a closed platform. This proprietary nature meant that integration with other systems was more challenging and required specific tools and methods.
• Administrative and Management Tools: Teradata Manager, Teradata Workload Manager, Teradata Performance Monitor for system administration, performance management, and monitoring.

Oracle: Oracle’s RDBMS was popular for its robustness and support for SQL. Oracle also introduced Oracle Data Warehouse, which provided advanced data warehousing features.

• Data Objects and SQL Commands: Supported tables, views, triggers (for enforcing business rules), stored procedures (for encapsulating business logic), and B-tree and bitmap indexes. SQL commands included DDL, DML, SELECT, and DCL.
• Data Extraction and Loading Tools: SQL*Loader, Oracle Data Integrator (ODI). These tools used batch processing, file transfer, ODBC, and JDBC methods.
• Data Retrieval Tools: SQL*Plus for querying and reporting.
• Proprietary and Closed Platform Features: Oracle had its own proprietary features and tools, including its own operating system (Oracle Solaris). This proprietary nature made integration with other systems more complex, although Oracle gradually became more open to integration over time.
• Administrative and Management Tools: Oracle Enterprise Manager for database administration, performance tuning, and monitoring.

Microsoft SQL Server: Offered a comprehensive data management solution with integrated tools for data warehousing and business intelligence.

• Data Objects and SQL Commands: Supported tables, views, triggers, stored procedures, and clustered and non-clustered indexes. SQL commands included DDL, DML, SELECT, and DCL.
• Data Extraction and Loading Tools: Data Transformation Services (DTS). These tools used batch processing, file transfer, ODBC, and JDBC methods.
• Data Retrieval Tools: SQL Server Management Studio (SSMS) for querying and reporting.
• Proprietary and Closed Platform Features: Microsoft SQL Server was built to run on Windows operating systems, making it a closed platform. This proprietary nature meant that integration with non-Windows systems was more challenging.
• Administrative and Management Tools: SQL Server Enterprise Manager for database administration, performance monitoring, and tuning.

IBM DB2: A powerful RDBMS that supported large-scale data warehousing and provided advanced analytics capabilities.

• Data Objects and SQL Commands: Supported tables, views, triggers, stored procedures, and B-tree indexes. SQL commands included DDL, DML, SELECT, and DCL.
• Data Extraction and Loading Tools: IBM InfoSphere DataStage, QMF. These tools used batch processing, file transfer, ODBC, and JDBC methods.
• Data Retrieval Tools: QMF (Query Management Facility) for querying and reporting.
• Proprietary and Closed Platform Features: IBM DB2 was designed to run on IBM mainframes and AS/400 systems, making it a closed platform. This proprietary nature meant that integration with non-IBM systems was more challenging.
• Administrative and Management Tools: IBM DB2 Control Center for database administration, performance tuning, and monitoring.

Sybase: Sybase’s Adaptive Server Enterprise (ASE) was known for its performance and reliability in data warehousing.

• Data Objects and SQL Commands: Supported tables, views, triggers, stored procedures, and B-tree indexes. SQL commands included DDL, DML, SELECT, and DCL.
• Data Extraction and Loading Tools: Sybase Replication Server, Sybase IQ. These tools used batch processing, file transfer, ODBC, and JDBC methods.
• Data Retrieval Tools: Sybase Central for querying and reporting.
• Proprietary and Closed Platform Features: Sybase ASE was designed to run on Unix and Windows operating systems, making it more open compared to other RDBMSs. However, it still had proprietary features that made integration with other systems more complex.
• Administrative and Management Tools: Sybase Central for database administration, performance monitoring, and tuning.

?? The Rise of Decision Support Systems (1980-1990)

Decision Support Systems (DSS) originated in the 1960s as computerized aids for decision-makers to use data and models in addressing unstructured problems. They supported business and organizational decision-making processes, offering insights and facilitating complex data analysis. For an in-depth review of DSS development from 1960 to 1980, please see my preceding article. --> ?? Decision Support Systems Evolution (1960-1980)

Development and Adoption

Between 1980 and 1990, Decision Support Systems (DSS) experienced significant development and became widely adopted across diverse industries.. The advancements in computer technology and the increasing availability of data led to the creation of more sophisticated DSS. These systems evolved from simple model-driven tools to more complex systems that integrated with Management Information Systems (MIS) and supported group decision-making.

Key Features and Functionalities

Early DSS had several key features and functionalities that made them valuable tools for decision-makers:

• Model-Driven DSS: Focused on providing decision-makers with access to and manipulation of statistical, financial, optimization, or simulation models. Early applications included financial planning systems, budgeting systems, and simulation models for various industries.
• Data-Driven DSS: Emphasized access to and manipulation of large datasets. Examples included sales analysis systems, inventory management systems, and customer relationship management (CRM) systems.
• Communication-Driven DSS: Focused on supporting communication and collaboration among decision-makers. Early applications included group decision support systems (GDSS) and collaborative planning tools.
• Document-Driven DSS: Emphasized the management and retrieval of unstructured information in various formats, such as documents, reports, and presentations. Examples included document management systems and report generation tools.
• Knowledge-Driven DSS: Focused on providing specialized problem-solving expertise stored as facts, rules, procedures, or similar structures. Early applications included diagnostic systems, expert advisory systems, and rule-based systems.

DSS Challenges Faced (1960-1980)

Despite their usefulness, early DSS faced several challenges:

• Data Redundancy: Each type of DSS required its own data storage and processing systems, leading to significant data redundancy and duplication. Managing duplicate data across multiple systems was inefficient and prone to errors.
• Data Integration: Integrating data from various sources was a complex and time-consuming process.
• Scalability: Early DSS struggled to handle large volumes of data, limiting their scalability.
• Resource Constraints: The hardware and software required for DSS were expensive and resource-intensive.
• User Accessibility: DSS were often difficult to use, requiring specialized knowledge and training.
• Fragmentation: The existence of multiple standalone systems led to fragmented data management and analysis processes.

Transitioning to Tools of the New Era

The difficulties encountered by initial Decision Support Systems (DSS) spurred the creation of more sophisticated tools and systems in the 1980s and 1990s. Organizations acknowledged the necessity for improved data management and analytical abilities, which resulted in the development of numerous pivotal tools and systems:

Thought Process and Integration Envisioning: Organizations started to conceptualize a unified approach to data management and decision support. They recognized that by modularizing and isolating the different elements of Decision Support Systems (DSS), they could build systems that were more efficient and scalable. The objective was to create independent systems with centralized data management, which would enhance data integration, accessibility, and analytical capabilities. The reasoning included:

• Identifying Redundancies: Recognizing that each DSS type had its own data storage and processing systems, leading to data redundancy and inefficiencies.
• Centralizing Data Management: Envisioning a centralized data management system that could store and process data from various sources, reducing redundancy and improving data quality.
• Modularizing Capabilities: Separating the different functionalities of DSS (e.g., data analysis, reporting, collaboration) into specialized, standalone tools that could be integrated seamlessly.
• Adopting New Technologies: Companies began adopting new technologies and tools that addressed the limitations of early DSS.
• Integrating Systems: Efforts were made to integrate new tools with existing systems, ensuring seamless data flow and accessibility.

These challenges enforced the need to start thinking about a new era of data management, focusing on centralized data management for analytics and decision-making.

Summary

In summary, the evolution of DSS involved the development of Data Marts and Data Warehouses, with each type of DSS transitioning into more specialized tools and systems:

• Model-Driven DSS: Evolved into reporting tools and integrated with Data Marts/Data Warehouses.
• Data-Driven DSS: Laid the groundwork for Data Marts and introduced SQL for data retrieval.
• Communication-Driven DSS: Evolved into collaborative platforms and integrated with Data Marts/Data Warehouses.
• Document-Driven DSS: Evolved into content management systems for unstructured data.
• Knowledge-Driven DSS: Evolved into AI applications and integrated with Data Marts/Data Warehouses.

The Emergence of Data Marts and Data Warehouses from Data-Driven Decision Support Systems (1980-1990) ??

In the 1980s and 1990s, organizations encountered substantial challenges with Data-Driven Decision Support Systems (DSS). These systems frequently resulted in data silos, redundancy, and inconsistencies, complicating the achievement of a unified organizational data perspective.

Envisioning Central Data Management Systems: Organizations recognized the need for centralized data management systems to handle the growing volumes of data. This led to the development of Data Marts and Data Warehouse Architecture Frameworks, which provided centralized data storage and improved data accessibility.

Centralized Data Management Architecture (1980 to 1990) ???

In the 1980-1990 era, organizations grappled with the task of managing and integrating large volumes of data from diverse sources. To tackle these challenges, centralized data management architectures were developed. These systems offered a structured method for storing, integrating, and analyzing data, which guaranteed data quality, consistency, and accessibility. The subsequent steps delineate the essential components and practices that were integral to constructing a centralized data management system in that timeframe.

Step 1: Understand Your Operating Systems

Vision: Understand your operational systems and have a clear vision of your end analytics/reporting use cases. This helps in designing a data management system that meets the specific needs of the organization.

• Example: A retail company might need to track sales performance across multiple stores, requiring a system that can consolidate sales data from various point-of-sale (POS) systems.

Step 2: Choose the appropriate RDBMS for your Data Marts and Data Warehouse needs.

RDBMS Options: Choose the appropriate RDBMS based on your data marts and data warehouse requirements. Common options during this era included Teradata, Oracle, Microsoft SQL Server, IBM DB2, and Sybase.

• Example: A financial institution might choose IBM DB2 for its advanced analytics capabilities and support for large-scale data warehousing.

Step 3: Select the Appropriate Data Model Schema for the Use Case

Schema Design: Decide whether to use data marts or a data warehouse, and choose between star schema and snowflake schema based on the use case.

• Example: A marketing department might use a star schema to analyze campaign performance, with a central fact table for campaign data and dimension tables for time, products, and customer segments.

Data Modeling: Perform conceptual, logical, and physical data modeling based on the selected RDBMS.

• Example: A conceptual data model might define entities such as customers, products, and sales, while a logical data model would specify the relationships between these entities.

Step 4: Choose ETL Tools and Integrate Them with Source Systems

ETL Tools: Use the given RDBMS ETL tools to connect to respective source systems. Options included ODBC, file transfer, etc.

• Example: Using ODBC to extract sales data from a POS system and load it into the data warehouse.

Integration pattern: Verify the integration based on the required data extraction and loading patterns (batch - daily, weekly, monthly, quarterly, yearly) and incremental, full load, etc.

• Example: Scheduling daily batch processing to load sales data into the data warehouse every night.

Step 5: Develop a Layered Architecture

Staging Layer: Design the staging layer for temporary storage of raw data before transformation.

• Example: A telecommunications company might load raw call data records into the staging layer before cleaning and transforming the data.

History Layer: Design the history layer to store historical data for auditing and analysis.

• Example: Using Slowly Changing Dimensions (SCD) techniques to track changes in customer subscription plans over time.

Consumption Layer: Design the consumption layer to store transformed and aggregated data for reporting and analysis.

• Example: Organizing sales data in a star schema with a central sales fact table and dimension tables for time, products, stores, and customers.

Step 6: Implement Data Extraction and Loading Patterns

Patterns and Schedules: Extract and load the data based on patterns and schedules, and populate the data marts or data warehouse.

• Example: Using incremental updates to load only the new or changed transaction data into the data warehouse every hour.

Step 7: Implement Data Quality Measures

Auditing Framework: Implement the workflow/mappings or pipelines auditing framework and capture logs for exceptions of integration, data quality, and transformation exception rules.

• Example: Capturing logs for data quality issues such as missing values or duplicate records and sending them to the respective teams for resolution.

Monitoring System: Have a monitoring system in place to monitor and rerun failed jobs.

Example: Setting up alerts to notify the data team of any failed ETL jobs and automatically rerunning the jobs.

Step 8: Document Data Lineage

Documentation: Manually document the lineage of objects, workflows, mappings, and jobs with respect to ETL and consumptions.

• Example: Creating a data lineage diagram to track the flow of data from source systems to the data warehouse and reporting tools.

Step 9: Manage Data Catalog and Metadata

Metadata Management: Each RDBMS had its own data dictionary and auditing objects of metadata to capture every activity performed in the RDBMS.

• Example: Using the data dictionary to document the schema, tables, columns, and relationships in the data warehouse.

Step 10: Implement Data Governance and Security

Performance Monitoring: Build performance monitoring dashboards to measure ETL workload, user query performance, and resource usage.

• Example: Monitoring the performance of ETL jobs and user queries to identify and resolve bottlenecks.

User Management: Monitor and manage users, and use views to secure data projection and selection of data sets.

• Example: Creating views to restrict access to sensitive data and ensure that users only see the data they are authorized to access.

Step 11: Utilize Reporting Tools

RDBMS Clients: The reporting tools of their own RDBMS systems (clients) were connected to their servers to retrieve data for viewing and managing data sets.

• Example: Using Oracle SQL*Plus to execute SQL queries and generate formatted reports from Oracle databases.

Third-Party Reporting Tools: There were limited third-party reporting tools available during this era. Most organizations relied on built-in reporting tools provided by the RDBMS vendors.

• Example: Using IBM Query Management Facility (QMF) to create and run SQL queries and generate reports from IBM’s DB2 database.

Step 12: Support for Advanced Analytics Tools

Integration: The architecture supported advanced analytics tools (formerly known as Knowledge-Driven DSS) to connect and build respective models and procedures.

• Example: Using SAS for advanced analytics, business intelligence, data management, and predictive analytics.

++++++++++++++++++++++++++++++++++++++++++++++++

Data Warehouse ??

A Data Warehouse is a centralized repository that aggregates data from multiple sources into a single, consistent data store. It is designed for query and analysis rather than transaction processing.

Why Build Data Warehouses?: Organizations needed a centralized system to manage and analyze large volumes of data from various sources. Data Warehouses provided a single source of truth, enabling more accurate and consistent decision-making. Data Warehouse systems were used for two aspects:

Enterprise Data Warehouse (EDW)

An Enterprise Data Warehouse (EDW) is a centralized repository that stores data from various sources across an organization. It is designed to support decision-making processes by providing a unified view of data with full history.

• Development: The concept of Data Warehousing emerged in the 1980s. Bill Inmon, often referred to as the “Father of Data Warehousing,” defined a data warehouse as a subject-oriented, integrated, time-variant, and non-volatile collection of data.
• Purpose: EDWs were developed to address the limitations of traditional databases, which were not optimized for complex queries and reporting. They allowed organizations to consolidate data from multiple sources and perform analytics and advanced analytics.

Enterprise Data Warehouse (EDW) Industries Use Cases and Analytics

• Banking and Finance: Institutions used EDWs for risk management, customer segmentation, and fraud detection. They utilized these systems to identify fraudulent activities, segment customers based on their transaction history, and assess credit risk. This allowed them to make informed decisions and improve their overall financial stability.
• Retail: Companies leveraged EDWs for inventory management, sales analysis, and customer behavior analysis. By tracking sales trends, managing stock levels, and analyzing customer purchase patterns, they were able to optimize their marketing strategies and ensure that they had the right products available for their customers.
• Healthcare: Organizations used EDWs for patient care management, treatment outcome analysis, and resource allocation. They evaluated treatment outcomes, managed patient records, and optimized resource allocation in hospitals, which helped them provide better care for their patients and improve overall efficiency.

Operational Data Store (ODS)

An Operational Data Store (ODS) is a database designed to integrate data from multiple sources and provide a current snapshot of operational data. It is used for operational reporting and analysis. This is basically simulating the previous DSS capabilities to support both Operational and Analytical requirements.

• Development: The concept of ODS emerged in the late 1980s and early 1990s as organizations needed real-time access to operational data for decision-making.
• Purpose: ODSs were created to support light-duty analytical processing and operational reporting and serving the customers. They provided a way to access the most recent data without affecting the performance of transactional systems.

Operational Data Store (ODS) Use Cases and Analytics

• Telecommunications: Companies used ODSs for network performance monitoring, customer service management, and billing. They monitored network performance in real-time, managed customer service interactions, and ensured accurate billing. This allowed them to maintain high levels of customer satisfaction and ensure the smooth operation of their networks.
• Manufacturing: Firms utilized ODSs for production monitoring, quality control, and supply chain management. By monitoring production processes, ensuring product quality, and managing supply chain operations, they were able to maintain high standards of production and ensure that their products met customer expectations.

RDBMSs Considered for Data Warehouses

• Teradata: Scalability and Parallel Processing: Teradata, known for its scalability and parallel processing capabilities, allowed for high-speed data loading and querying, making it ideal for large-scale data warehousing and suitable for real-time analytics.
• Oracle: Advanced Features and SQL Support: Oracle provided advanced data warehousing features such as partitioning, indexing, and materialized views to optimize query performance. Its robust support for SQL allowed for complex data transformations and analytics, making it a powerful choice for data warehousing.
• IBM DB2: Large-Scale Support and Advanced Analytics: IBM DB2 supported large-scale data warehousing with features like multi-temperature data management and in-memory computing. It offered advanced analytics capabilities, including support for big data and integration with other systems, making it a versatile option for data warehousing.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Data Marts ??

A Data Mart is a specialized subset of a data warehouse focused on a specific functional area or department within an organization. It provides a simplified and targeted view of data, addressing specific reporting and analytical needs.

Why Build Data Marts?: Organizations recognized the need for more focused and efficient data analysis for specific business units or departments. Data Marts allowed teams to quickly access critical insights without sifting through an entire data warehouse.

Initially, some organizations built Independent Data Marts to meet the immediate needs of specific departments. Over time, they realized the benefits of integrating these data marts into a centralized data warehouse, leading to a top-down and bottom-up approach in data warehousing. There are three types of Data Marts:

Independent Data Mart

An Independent Data Mart is created and maintained separately from the data warehouse. It is designed to meet the specific needs of a business unit.

• Development: Independent Data Marts are often the first step in data warehousing for organizations with limited use cases. They are developed when a business unit requires specialized data that is not available in the central data warehouse. Over time, these independent data marts may be integrated into a larger data warehouse.
• Purpose: The primary purpose of an Independent Data Mart is to provide tailored data solutions for a specific business unit, allowing for more focused and efficient data analysis.
• Use Case and Analytics Example: Marketing departments may use an Independent Data Mart to analyze campaign performance and customer demographics, performing detailed customer segmentation, tracking marketing campaign effectiveness, and analyzing customer behavior patterns.

Dependent Data Mart

A Dependent Data Mart is generated from an existing data warehouse. It leverages the data integration, quality, and consistency provided by the data warehouse.

• Development: Dependent Data Marts are developed by extracting data from the central data warehouse. They ensure that the data used by different business units is consistent and accurate.
• Purpose: The primary purpose of a Dependent Data Mart is to provide a consistent and integrated view of data across the organization, ensuring data quality and consistency.
• Use Case and Analytics Example: Finance departments may use a Dependent Data Mart to analyze financial performance and generate reports, conducting financial analysis, generating budget reports, and monitoring key financial metrics.

Hybrid Data Mart

A Hybrid Data Mart combines features of both independent and dependent data marts. It uses the centralized data warehouse for core data integration while incorporating additional data sources specific to a business unit.

• Development: Hybrid Data Marts are developed by integrating data from the central data warehouse with additional data sources specific to the business unit. This approach provides flexibility while maintaining data quality.

• Purpose: The primary purpose of a Hybrid Data Mart is to offer the flexibility of independent data marts while maintaining the consistency and quality of dependent data marts.
• Use Case and Analytics Example: Sales departments may use a Hybrid Data Mart to analyze sales performance and customer interactions, analyzing sales trends, tracking customer interactions, and forecasting sales performance.

RDBMSs Considered for Data Marts

• Microsoft SQL Server: Integrated Tools and Scalability: Microsoft SQL Server, introduced in 1989, offered integrated tools for data warehousing and business intelligence, making it a popular choice for data marts. It was suitable for small to medium-sized data marts with the ability to scale as needed.
• IBM DB2: Advanced Analytics and Performance: IBM DB2, introduced in 1983, provided advanced analytics capabilities and supported large-scale data warehousing. It was known for its high performance and reliability in handling large volumes of data, making it suitable for data marts.
• Sybase: Performance and Reliability: Sybase, founded in 1987, was known for its performance and reliability in data warehousing. It offered features like data compression and partitioning to enhance performance and provided seamless integration with other systems and solutions, making it a reliable choice for data marts.

Data Warehouse & Data Marts Concepts &Frameworks ????

Data Warehouses and Data Marts are essential components of modern data management and analytics. They provide a structured and efficient way to store, organize, and analyze large volumes of data from various sources. Understanding the concepts and frameworks behind Data Warehouses and Data Marts is crucial for designing and implementing effective data solutions that meet the needs of different business units and departments.

Schema: What is Schema?

A schema in data warehousing is a logical description of the entire database. It defines how data is organized, stored, and related, ensuring efficient data integration and querying. Schemas are crucial for organizing data, reducing data redundancy, and improving query performance. Schemas are represented using two main components: Dimensions and Facts.

• Dimensions: Provide context for the facts, such as the time, location, or product involved in the event.
• Facts: Numerical values that represent a business event, such as sales revenue or customer visits.

Schema Representation

Star Schema: A type of database schema where a single fact table references a number of dimension tables, forming a pattern that resembles a star. It is optimized for querying large data sets and is simple to design and maintain.

• Example: In a retail business, a star schema might have a central fact table for sales, with dimension tables for time, products, stores, and customers.

Snowflake Schema: A more complex variation of the star schema, where dimension tables are normalized, leading to multiple related tables forming a pattern similar to a snowflake. It reduces data redundancy and improves data integrity but requires more complex queries.

• Example: In the same retail business, a snowflake schema might have normalized dimension tables for products, breaking them down into separate tables for product categories and suppliers.

Dimensions History Management - Slowly Changing Dimensions (SCD)

Slowly Changing Dimensions (SCD) are techniques used in data warehousing to manage and track changes in dimension data over time. These methods ensure that historical data is preserved and accurately reflects the state of the data at different points in time.

SCD Type 1: Overwrite Old Data with New Data: In this approach, the old data is overwritten with the new data. This means that the historical data is not preserved, and only the most recent data is available.

• Use Case: This method is used when historical data is not important, and only the current state of the data is needed.
• Example: If a customer’s address changes, the old address is replaced with the new address in the database.

SCD Type 2: Maintain Historical Data: This approach maintains historical data by creating multiple records for each entity, with each record representing a different version of the data. There are several ways to implement SCD Type 2:

• Time Range: Each record has a start time and end time to indicate the period during which the data was valid.
• Flagging: A flag (e.g., valid/invalid) is used to indicate the current version of the data.
• Versioning: Each record is assigned a version number to indicate the sequence of changes.
• Use Case: This method is used when it is important to track changes over time and maintain a history of the data.
• Example: If a customer’s address changes, a new record is created with the new address, and the old record is marked as invalid or given an end date.

SCD Type 3: Maintain Limited Historical Data: This approach maintains limited historical data by adding new columns to the existing record. This allows for tracking changes to a specific attribute without creating multiple records.

• Use Case: This method is used when only a limited history of changes is needed, and it is sufficient to track changes to specific attributes.
• Example: If a customer’s address changes, a new column is added to store the previous address, while the current address is updated in the existing column.

Data Extraction, Transformation, and Loading (ETL) Approach

For centralizing the data, ETL tools provided by the respective RDBMSs were used. ETL scripts (command line scripts), pipelines, or workflows were designed to take care of end-to-end data extraction, loading, integration, transformation, and building the consumption objects.

Extraction: Data was extracted from various operational systems using ETL tools. Connectivity frameworks like ODBC (Open Database Connectivity) or File Transfer Protocol (FTP) were often used to facilitate data extraction.

• Example: Extracting sales data from a point-of-sale (POS) system using ODBC to connect to the POS database.

Transformation: Data was cleaned, transformed, and structured to fit the data mart or data warehouse schema.

• Example: Converting date formats, removing duplicates, and aggregating sales data by region.

Loading: Transformed data was loaded into the data mart or data warehouse using batch processing or incremental updates.

• Example: Loading the cleaned and transformed sales data into the sales fact table in the data warehouse.

Loading Patterns and Schedules

Batch Processing: Data was loaded in batches, often scheduled daily, weekly, or monthly.

• Example: A retail company might schedule batch processing to load sales data into the data warehouse every night.

Incremental Updates: Data was updated incrementally based on the last extraction timestamp or Period.

• Example: A finance department might use incremental updates to load only the new or changed transaction data into the data warehouse every hour.

Data Modeling

Data Modeling is the process of creating a visual representation of either a whole information system or parts of it to communicate connections between data points and structures. The goal of data modeling is to illustrate the types of data used and stored within the system, the relationships among these data types, the ways the data can be grouped and organized, and its formats and attributes.

Purpose: Data modeling helps in understanding and organizing data requirements, ensuring data quality, and supporting business processes and planning IT architecture and strategy.

• Conceptual Data Model: Provides a high-level overview of the data landscape, focusing on the main concepts (entities) and their relationships. It is used to define the scope of a business solution without going into details.
• Logical Data Model: Delves deeper into data structures and relationships, including entities, attributes, primary keys, and foreign keys. It defines the structure of the data elements and sets the relationships between them.
• Physical Data Model: Translates the logical model into a database-specific schema, organizing the data into tables and accounting for access, performance, and storage details. The Physical data models are coupled with respective databases like Teradata, Oracle, Microsoft SQL Server, etc.

Data Layered Architecture

The centralization systems needed to store, integrate, and transform the data, hence it was managed using various layers. Each layer serves a specific purpose in the data management process, ensuring data quality, consistency, and accessibility.

Staging Layer: The staging layer is a temporary storage area for raw data before it undergoes transformation. It acts as a buffer between the source systems and the data warehouse.

• Data Loading: Data is typically loaded into the staging layer using truncate and insert methods to ensure that the staging tables are refreshed with the latest data.
• Example: A retail company might load raw sales data from various point-of-sale (POS) systems into the staging layer, where it is temporarily stored before being cleaned and transformed.

History Layer: The history layer stores historical data for auditing and analysis. It ensures that changes to data over time are tracked and preserved.

• Techniques: Slowly Changing Dimensions (SCD) techniques are used to manage historical data. These techniques allow for the tracking of changes to dimension attributes over time.
• Example: A telecommunications company might use SCD Type 2 to track changes in customer subscription plans, storing each change as a new row in the history layer with a timestamp.

Consumption Layer: The consumption layer stores transformed and aggregated data for reporting and analysis. It provides a denormalized view of the data, optimized for query performance.

• Schema Representation: Data in the consumption layer is often stored using star schemas or snowflake schemas to facilitate efficient querying and reporting.
• Example: A sales department might use the consumption layer to analyze sales performance, with data organized in a star schema that includes a central sales fact table and dimension tables for time, products, stores, and customers.

Data Integration: The layered architecture ensures that data from various sources is integrated and transformed consistently. This integration is crucial for providing a unified view of the data across the organization.

Data Quality: Each layer in the architecture plays a role in ensuring data quality. The staging layer allows for data cleansing and transformation, the history layer preserves historical accuracy, and the consumption layer provides a reliable source for reporting and analysis.

Scalability: The layered approach allows for scalability, as each layer can be optimized and scaled independently based on the organization’s needs.

The Emergence of Reporting Tools from Model-Driven Decision Support Systems (1980-1990) ??

Model-Driven DSS Recap: These are computerized systems that use mathematical, statistical, or simulation models to support decision-making processes. They help users analyze complex data and make informed decisions by providing insights and recommendations. Refer details here.

Why Build New Reporting Tools Instead of Model-Driven DSS?

Organizations realized they didn’t need another permanent data storage system for reporting. Instead, they could use system memory to run queries and generate reports. This led to the development of reporting tools for analytics and data visualization, allowing users to access, analyze, and visualize data without extensive data storage systems.

Thanks to the Emergence of Client-Server Architecture, in the late 1980s, client-server architecture revolutionized reporting tools. This architecture separated data storage, processing, and presentation layers, enabling more efficient data management and reporting. Organizations could store only the reporting data and connect to RDBMSs through ODBC or file transfer protocols.

Design of Reporting Tools Architecture

Reporting tools in the 1980-1990 era often followed a client-server architecture, allowing for efficient data management and reporting. The initial tools are designed for querying the data, report writing, and analysis of the data sets.

• Storage and Model Area: Tools had their own storage systems to store and process data, including areas to store analytics reports and perform transformations.
• Cache: Some tools included caching mechanisms to improve performance by storing frequently accessed data in memory.
• Transformation and Design: Tools allowed users to perform transformations and design custom reports, providing flexibility and customization options.

Data Consumption from Reporting Tools

Users could consume data through various methods:

• ODBC Connections: Seamless integration with different database management systems.
• File Transfer Protocol: Data transfer between systems for reporting purposes.
• Ad-Hoc Queries: Generating reports on-demand.
• Scheduled Reports: Running reports at specific intervals (daily, weekly, monthly, quarterly).

Tools and Vendors

Lotus 1-2-3: A popular spreadsheet program introduced in 1983 for creating reports and performing data analysis.

• Features: Spreadsheet functionality, built-in functions, graphing, macros, data import/export.
• Capabilities: Creating reports, managing budgets, visualizing data, automating tasks.
• Popularity: Industry standard in the 1980s and 1990s, widely used in business, finance, and education.

dBASE: A DBMS introduced in 1979-80 by Ashton-Tate, known for its ease of use and powerful features.

• Reporting Capabilities: Creating and running reports based on stored data.
• Popularity: Widely used in various industries for inventory management, customer tracking, and financial reporting.

R:BASE: An early RDBMS introduced in 1981 by Microrim, known for its relational database capabilities.

• Reporting Features: Generating reports from data, supporting complex queries, creating customized reports.
• Relational Capabilities: Defining relationships between data tables for efficient data management.

IBM Query Management Facility (QMF): A tool for creating and running SQL queries and generating reports from IBM’s DB2 database.

• Features: SQL query creation, report generation, interactive design, DB2 integration.
• Capabilities: Running complex SQL queries, generating detailed reports, analyzing DB2 data.
• Popularity: Widely used in enterprises relying on IBM’s DB2 database.

Oracle SQL*Plus: A command-line tool for executing SQL queries and generating formatted reports, introduced in the early 1980s.

• Features: Command-line interface, scripting, report formatting, Oracle integration.
• Capabilities: Executing SQL queries, generating reports, automating tasks, managing Oracle databases.
• Popularity: Standard tool for Oracle database users, widely used by administrators and developers.

Teradata BTEQ: Basic Teradata Query (BTEQ) for interacting with the Teradata server, running queries, and generating reports.

• Features: Command-line interface, data export/import, report formatting, Teradata integration.
• Capabilities: Executing SQL queries, generating reports, exporting/importing data, automating tasks.
• Popularity: Widely used by organizations utilizing Teradata for data warehousing.

Reporting Schedules/Patterns and Consumption

• Patterns: Ad-hoc reporting, scheduled reports.
• Schedules: Daily, weekly, monthly, quarterly.

Use Cases/Dashboard Types

• Financial Reporting: Generating financial statements, budgeting reports, and financial forecasts.
• Sales and Marketing Analysis: Analyzing sales performance, tracking marketing campaigns, and generating sales forecasts.
• Inventory Management: Monitoring inventory levels, tracking stock movements, and generating inventory reports.

Knowledge-Driven DSS to Advanced Analytics Tools (1980-1990) ??

Knowledge-Driven DSS: These systems integrated with advanced analytics tools to provide deeper insights. Machine learning models were developed and deployed to analyze data and provide recommendations. Insights were delivered through dashboards and reports, enabling data-driven decision-making.

Why Build Separate Advanced Analytics Tools? Organizations realized they didn’t need another permanent data storage system for advanced analytics. Instead, they could use system memory to run complex algorithms and models. This led to the development of Advanced Analytics tools for statistical analysis and modeling.

Tools and Vendors

SAS: Provided advanced analytics, business intelligence, data management, and predictive analytics. SAS was further developed in the 1980s with the addition of new statistical procedures and components.

• Design/Architecture: SAS was written in the C programming language, which allowed it to be platform-independent and run on various operating systems, including Unix. The architecture included a graphical point-and-click user interface for non-technical users and a robust programming language for advanced users.

SPSS: A statistical analysis tool widely used in social science research. SPSS became the first in its class to make applications available on individual PCs in the 1980s.

• Design/Architecture: SPSS had a two-tier, distributed architecture that separated client and server operations. Memory-intensive operations were performed on the server, while the client provided the graphical user interface for data access and analysis. This architecture allowed for efficient handling of large datasets without overloading the client computer

MATLAB: A numerical computing environment used for data analysis, visualization, and algorithm development. MATLAB became a commercial product in the early 1980s.

• Design/Architecture: MATLAB was initially a simple interactive matrix calculator but evolved to include toolboxes for various applications4. The architecture supported component-based modeling and modular design, allowing users to segment their models into independent components for parallel development and testing.

Integration, Reporting Patterns and Schedules

• Connection Methods: Supported both ODBC connections and file loading.
• Patterns: Ad-hoc analysis, scheduled analysis.
• Schedules: Daily, weekly, monthly, quarterly.

Use Cases/Dashboard Types

• Predictive Analytics: Forecasting future trends and behaviors.
• Statistical Analysis: Analyzing data to identify patterns and relationships.
• Machine Learning Models: Developing and deploying machine learning algorithms for various applications.

Document-Driven DSS (1980-1990) ??

Document-Driven DSS: These systems were designed to manage and retrieve unstructured and semi-structured data, such as documents, reports, and presentations. They provided users with the ability to store, organize, and access documents efficiently.

Why Develop Document-Driven DSS? Organizations needed a way to manage and retrieve unstructured and semi-structured data. Document-Driven DSS provided advanced search capabilities, document management features, and facilitated better information management.

Architecture Integration

• Connection Methods: Supported integration with data storage systems and reporting tools.
• Content Management: Enabled advanced search capabilities, document version control, and information management.

Tools and Vendors

IBM’s Document Management System (DMS): IBM developed early document management systems that allowed organizations to store and retrieve documents electronically. These systems provided basic document management features such as indexing, search, and retrieval.

• Design/Architecture: IBM’s DMS utilized a client-server architecture, where documents were stored on a central server and accessed through client applications. This architecture allowed for efficient document management and retrieval.

Wang Laboratories’ Office Information Systems (OIS): Wang Laboratories developed OIS in the 1980s, which included document management capabilities. OIS allowed users to create, store, and retrieve documents electronically.

• Design/Architecture: OIS used a centralized architecture, where documents were stored on a central server and accessed through client terminals. The system provided features such as document indexing, search, and version control.

Content Management Patterns and Schedules

• Patterns: Document storage, retrieval, and version control.
• Schedules: On-demand, scheduled updates.

Use Cases

• Document Management: Storing, retrieving, and managing documents and files.
• Information Governance: Ensuring compliance with information management policies.
• Collaboration: Facilitating collaboration on documents and projects.

Collaboration-Driven DSS to Collaborative Platforms (1980-1990) ??

Collaboration-Driven DSS systems were developed to facilitate communication and collaboration among team members. This led to the development of collaborative platforms that supported real-time communication, file sharing, and collaborative analysis.

Why Build Collaborative Platforms? Organizations recognized the need for tools that facilitated communication and collaboration among team members. This led to the development of collaborative platforms that supported real-time communication, file sharing, and collaborative analysis.

Architecture Integration

• Connection Methods: Supported integration with data storage systems and reporting tools.
• Collaboration: Enabled real-time communication, file sharing, and collaborative analysis.

Tools and Vendors

Lotus Notes: An early email and collaboration system developed by Lotus Development Corporation. Its initial release, Lotus Notes 1.0, came out in 1989. It allowed users to share documents, calendars, and emails.

• Design/Architecture: Lotus Notes used a client-server architecture, where the server stored the data and the client provided the user interface. This architecture supported email, calendaring, and document sharing.

Microsoft Mail: Before the release of Microsoft Exchange, Microsoft Mail was used for email and collaboration. It was replaced in 1991 by "Microsoft Mail for PC Networks v2.1".

• Design/Architecture: Microsoft Mail used a client-server architecture and supported email, calendaring, and basic collaboration features.

Bulletin Board Systems (BBS): BBS allowed users to connect and share messages and files over a network. They were popular in the 1980s and early 1990s.

• Design/Architecture: BBS used a centralized server where users could dial in using modems to access message boards, share files, and communicate with other users.

Collaboration Patterns and Schedules

• Patterns: Real-time collaboration, asynchronous communication.
• Schedules: On-demand, scheduled meetings.

Use Cases

• Team Collaboration: Facilitating communication and collaboration among team members.
• Document Sharing: Sharing and collaborating on documents and files.
• Project Management: Managing and tracking project tasks and milestones.

Hierarchical Structure and Roles (1980-1990) ??

Chief Information Officer (CIO)

The CIO was responsible for establishing and managing the organization’s IT department, developing IT strategies aligned with business goals, overseeing data management, security, and compliance, and reporting to the CEO while collaborating with other C-level executives.

Data Management Director

The Data Management Director supervised data management teams, ensured data quality, consistency, and accessibility, developed data governance policies, and reported to the CIO.

• Data Architect: Responsible for designing and implementing the overall data architecture, defining data models, schemas, and data integration strategies, ensuring data quality and consistency, and collaborating with stakeholders to understand data requirements.
• Database Administrator (DBA): Manages and maintains the database systems, performs database tuning, optimization, and backup, ensures data security and compliance, and monitors database performance while troubleshooting issues.
• ETL Developer: Designs and develops ETL processes to extract, transform, and load data, integrates data from various source systems into the data warehouse, ensures data quality and consistency during the ETL process, and optimizes ETL workflows for performance and efficiency.
• Data Analyst: Analyzes data to generate insights and support decision-making, creates reports and dashboards for business users, performs data validation to ensure accuracy, and collaborates with stakeholders to understand data requirements.
• Data Governance Manager: Develops and enforces data governance policies and procedures, ensures data quality, security, and compliance with regulations, manages data stewardship and data ownership roles, and monitors data usage to address data-related issues.

Project Manager: Oversees the implementation of the data management system, manages project timelines, budgets, and resources, coordinates with various teams and stakeholders, and ensures project goals and objectives are met. The Project Manager typically reports to the Data Management Director.

End-User Teams

1. Marketing Team

The Marketing Team utilized data to analyze campaign performance, generated insights for targeted marketing strategies, and collaborated with data analysts for reporting needs.

2. Sales Team

The Sales Team tracked sales performance and trends, used data to identify sales opportunities and challenges, and collaborated with BI developers for sales dashboards.

3. Finance Team

The Finance Team analyzed financial data for budgeting and forecasting, ensured data accuracy for financial reporting, and collaborated with data engineers for data integration.

4. Operations Team

The Operations Team monitored operational efficiency and performance, used data to optimize processes and resource allocation, and collaborated with data architects for data modeling.

5. Human Resources Team

The Human Resources Team analyzed employee data for workforce planning, used data to improve recruitment and retention strategies, and collaborated with data stewards for data quality.

These roles and hierarchical structures were essential for the successful implementation and management of centralized data management systems during the 1980-1990 era. Each role brought unique skills and expertise to ensure data was effectively managed, monitored, and utilized to support business objectives.

Pain Points Resolved and New Challenges (1980-1990) ??

Points Resolved from 1960-1980

• Data Redundancy and Inconsistency: Centralized data management reduced redundancy and ensured consistency across the organization.
• Complex Data Integration: The development of ETL tools and processes streamlined data integration from various sources.
• Limited Data Accessibility: Centralized architectures improved data accessibility for business users, enabling better decision-making.
• Manual Data Processing: Automation of data extraction, transformation, and loading reduced manual intervention and errors.

New Challenges in the 1980-1990 Era

• Scalability Issues: As data volumes grew, scaling systems to handle the increased load became challenging.
• Performance Bottlenecks: Hardware and software limitations led to performance issues, especially with complex queries.
• Closed Operating Systems: Proprietary operating systems limited flexibility and scalability.
• Data Silos: Despite centralized architectures, data silos and redundancy issues persisted.
• Limited Third-Party Integration Tools: The availability of third-party integration tools was limited, making it difficult to integrate diverse data sources.
• Data Quality Management: Ensuring data quality and consistency across various sources remained a significant challenge.
• Security Concerns: Protecting sensitive data and managing user access required robust security measures.

Conclusion ??

The emergence of Data Marts and Data Warehouses between 1980 and 1990 represented a significant leap forward in data management and analysis. These systems equipped organizations with the means to handle and scrutinize vast amounts of data, fostering more informed decision-making processes. Understanding the progression and development of these systems allows organizations to enhance this foundation and utilize contemporary technologies to meet current and future challenges. The centralized data management structures instituted during this time formed the basis for the advanced data warehousing and analytics solutions we depend on today. Despite encountering issues like scalability, performance bottlenecks, and data silos, the breakthroughs of that era continue to influence the domain of data management profoundly.

Call to Action ??

I trust you found the exploration of data architecture from 1980 to 1990 enlightening. Whether you're a data professional, a tech enthusiast, or simply interested in the evolution of data management, this article has insights for all. For a thorough understanding, I recommend reading the entire piece, though you're welcome to focus on sections that pique your interest.

Should you wish to share thoughts, questions, or personal experiences, please contribute to the comments section below. Let's foster a dialogue and enrich our knowledge with shared perspectives. Remember to follow for more content on data architecture and related fields. Your readership is greatly appreciated!

Look forward to the upcoming article delving into the progression of data systems from 1990 to 2000. It will highlight novel discoveries, technologies, frameworks, and milestones that influenced the data realm in that decade. Continuing the theme, it will also discuss the progress in Enterprise Architecture from 1980-1990 and subsequent advancements into 2000.

As we advance our data management techniques and integrate contemporary tools and technologies, we can overcome historical challenges and establish strong, scalable, and effective data systems for tomorrow. Let's harness historical lessons and apply them to forge an improved data-centric future.

Thank you for accompanying me on this historical voyage of data architecture. Maintain your curiosity and continue your exploration!

Regards,

Mohan