The conceptual approach to the data warehouse implementation lifecycle is illustrated in the following figure. This diagram illustrates the sequence of high-level tasks required for the design, development and deployment of a data warehouse. The diagram shows the overall project roadmap, in which each box can serve as a milestone.<\/p>\n\n\n\n
![\"Launching](\"https:\/\/stage.momentum-tech.ca\/wp-content\/uploads\/2024\/07\/Processus-DW.drawio.png\")
Project planning <\/h2>\n\n\n\n
The lifecycle begins with project planning. Project planning covers the definition and scope of the data warehouse project, including readiness assessment and business justification. These are critical tasks because of the high visibility and costs associated with most BI projects.<\/p>\n\n\n\n
From here, project planning focuses on resource requirements (material and personnel) coupled with the duration and sequence of project tasks. It is the cornerstone of ongoing data warehouse project management. Project planning depends on business requirements, as indicated by the bidirectional arrow between these activities in the figure above.<\/p>\n\n\n\n
Defining business needs<\/h2>\n\n\n\n
The scope of the data warehouse initiative should be determined by business requirements. The requirements will determine what data must be available in the data warehouse, how it will be organized and how often it will be updated. Although architecture design sounds like a technology-driven activity, business requirements, such as the number of warehouse users and their location, have a significant impact on the architecture. Clearly, end-user application models are defined by requirements. Finally, deployment, maintenance and growth plans must be user-driven. We begin to formulate answers to all these lifecycle questions based on an understanding of users’ business requirements.<\/p>\n\n\n\n To better understand business needs, we have to start by talking to users. We can’t simply ask users what data they’d like to see in the data warehouse. Instead, we need to talk to them about their work, their goals and their challenges, and try to understand how they make decisions, now and in the future. As we gather requirements from business users, we also need to interweave some data reality into the process by interviewing key IT personnel. We need to consider business needs alongside data availability to meet these requirements.<\/p>\n\n\n\n We must first help define the business problem the customer is trying to solve. Understanding the customer’s BI objectives should ensure an indispensable approach before committing valuable resources.<\/p>\n\n\n\n Variables that can have a significant impact on project duration include the following:<\/p>\n\n\n\n Now that we’ve gathered the business requirements and conducted an overview of the data, we are ready to begin the logical and physical design of the data warehouse. This design will transform the existing data resources into final data warehouse structures. From these designs, we can plan the steps for data extraction and transformation. We can also estimate the overall size and business needs of the central database and begin planning and prototyping the final applications.<\/p>\n\n\n\n There are many types of data modeling, each with specific objectives and purposes. As organizations evolved their data structures to support reporting and analysis, a new data modeling technique emerged, now known as dimensional modeling.<\/p>\n\n\n\n Imagine a business leader describing her core business as “we sell products in various markets and measure our performance over time.” Dimensional designers carefully listen to the emphasis on product, territory, and time. Most people find it intuitive to consider such a business as a data cube, with the edges labeled product, market, and time. One can imagine slicing and dicing along each of these dimensions. The points inside the cube are where measures, such as sales volume or profit, for that combination of product, market, and time, are stored. The ability to visualize something as abstract as a dataset in a concrete and tangible way is the secret to understandability.<\/p>\n\n\n\n A data model that starts simple has a chance of remaining simple by the end of the design process. A model that starts complicated will likely end up too complex, leading to slow query performance and user dissatisfaction.<\/p>\n\n\n\n The first step in this process is to identify each target audience and the type of usage they require. Each different audience may have distinctly different requirements for the results they need to see. Who needs to look at which data? The data used for analysis by the marketing department to plan promotions for the next year is different from what a sales representative running a set of reports needs to support an account review.<\/p>\n\n\n\n While developers often have a lot of knowledge about what the BI application needs to do, it’s still worth it for us to get feedback from other members of the business community. This helps to reinforce ownership by the groups that will use the BI application.<\/p>\n\n\n\n Report and visualization design can be done through design sessions, or individual and\/or group meetings. Design should focus on highly prioritized business areas identified during the initial requirements gathering and should be within the project scope. Based on our project team’s experience, much of this work can be done within the team. However, it’s important for us to continue to develop support, which can be done by sharing ideas with other business representatives.<\/p>\n\n\n\n Here are the key tasks we anticipate during this stage:<\/p>\n\n\n\n Understanding who will use the reports and what information they are seeking.<\/p>\n\n\n\n Written by Sanzio Castor,Data Analyst<\/em><\/p>\n\n\n\n A conceptual lifecycle helps to organize and plan the project efficiently. It provides a structure for the data warehousing project, and helps define the various stages required to achieve the final objective, enabling progress to be monitored and controlled. The conceptual approach to the data warehouse implementation lifecycle is illustrated in the following figure. This […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[15],"tags":[],"class_list":["post-913","post","type-post","status-publish","format-standard","hentry","category-news-momentum"],"acf":[],"yoast_head":"\n
Users and their needs have an impact on almost every decision made throughout the implementation of a data warehouse. As shown in the figure below, business requirements are at the heart of our data warehouse development process.<\/p>\n\n\n\n![\"Defining](\"https:\/\/stage.momentum-tech.ca\/wp-content\/uploads\/2024\/07\/Exigences-daffaires.drawio-1.drawio.png\")
\n
Data Modeling<\/h2>\n\n\n\n
What is a Data Model?<\/h2>\n\n\n\n
A data model is an abstraction of how individual data elements are related to each other. It visually describes how data should be organized and stored in a database. A data model provides the mechanism for documenting and understanding data organization.<\/p>\n\n\n\n![\"What](\"https:\/\/stage.momentum-tech.ca\/wp-content\/uploads\/2024\/07\/Star-Schema.drawio-1.drawio.png\")
\u00c0 droite, la repr\u00e9sentation conceptuelle du cube \u00e9quivalent.<\/em><\/figcaption><\/figure>\n\n\n\nReporting and Analysis Tools Definition<\/h2>\n\n\n\n
The design of BI applications is likely to be performed shortly after the completion of dimensional modeling. Our project team has spent time learning and documenting the business requirements, and the dimensional model provides details on the data elements that will be available. It is now time for us to consider what needs to be delivered.<\/p>\n\n\n\nDesigning the Physical Data Structure<\/h2>\n\n\n\n
For the physical model, it should be kept as simple and similar to the logical model as possible. However, differences between physical and logical models are inevitable. They may be necessary to support specific access\/security requirements, to enhance query performance, and even to maintain the maintenance cycle within an acceptable window.<\/p>\n\n\n\nETL System Design and Development<\/h2>\n\n\n\n
In the design and development of the ETL (Extract, Transform, Load) system, we acknowledge that it is often underestimated work in a data warehouse project. We understand that the ETL process is rarely straightforward. We identify several important steps in developing an ETL:<\/p>\n\n\n\n\n
Reporting Development<\/h2>\n\n\n\n
The reporting development stage in our data warehouse project is essential as it allows us to transform raw data into valuable business insights. Our goal is to provide reports that facilitate data-driven decision-making and offer a clear view of various aspects of the business.<\/p>\n\n\n\n\n
Deployment and Maintenance<\/h2>\n\n\n\n
The deployment and maintenance phase in a data warehouse project are vital for the following reasons:<\/p>\n\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Launching a data warehouse project is a complex task that requires careful planning and a deep understanding of business needs. It is essential to start with a detailed analysis of requirements, followed by identifying relevant data sources. Once these steps are completed, it is possible to design and build the data warehouse ensuring it meets business needs. Finally, it is crucial to establish processes to maintain and improve the data warehouse over time. By following these steps, businesses can maximize the value of their data and make informed decisions based on accurate and up-to-date information.<\/p>\n\n\n\n <\/h4>\n\n\n\n
<\/h4>\n\n\n\n
References<\/h4>\n\n\n\n
\n