There are following topics described in this chapter.
1. The “four step dimensional design process”
According to this book, there are four basic steps to do dimensional modeling. First, to select the business process, second , to define the granularity of the data, third, to find out the dimensions, fourth, to find out the facts. We discuss each in the following.
1.1, to select the business process
The basic step of data modeling is to think about the scope and influence of the new model. One principle is to avoid publishing the same data multiple times. This book discusses about having the model per business process rather than per department. The idea behind is that, if having the models per department, the same data may have to be published more than once as different business processes may require similar data on the same department. However, it is not enough to just have one data model per business process, one still has to reach the step of consolidating these business process into a unified model at certain time point in the future. But I agree that, given most situations that data marts are required in a short time frame, focusing on a specific business process is the most optimal way to take. However, one must take a serious step later to consolidate the “quickly-designed” data mart into a large data warehouse. That step, as I can see from my experience, is missing in most of the industry implementations.
1.2, to define the grain of the business process
The question is “how to define a single row in the fact table?” It is a question on how detail we should devolve into in the data model. And here is the place that we consider the balance between the scalability of data and the performance requirement. In many cases, if one uses the most detailed data in the data model, it means that, if there are new requirements to the model, it is very easy to adapt those requirements as we already have all the data (otherwise, a major re-work has to be called). On the other hand, when having the most detailed data, that brings extra maintenance cost (you have to pay people to “watch” and “fix” you disks to yield the best performance in order to satisfy the users).
This step also helps people to understand the content of the dimensions.
1.3, to define the dimensions
It is about to find out and group the categories. The tricky part is how can we make the grouping in a generic way so that it is very easy to scale the model to include more different sets of data in the future?
1.4, to identify the facts
What are we measuring? There are some columns that are generated based on calculations over other columns. Do we need these extra columns that seem to be waster of disk space? It depends on the requirement on the performance as well as how often the data is used.
2 A case study on the retail business
I have the following reflection from the case study.
First, it is always necessary to start by understanding, from the business points of view, what is required exactly. There are many business processes in a case, but to choose the right one is the most important thing.
Second, when you have defined the grain of data, the dimensions seem to be self-clarified. Just read and analyze the definition of the grain and use the terms in the that definition, for example, “prodoctu,” “store,”, “promotion.” And remember that date is always a dimension in all data warehouses (otherwise you would not call it a data warehouse).
Third, in the design of fact tables, for those additive measures, it is a kind of belief to add an additive measure to a fact table. Knowing that this will bring storage cost but still deciding to do it, you have to have a belief. In fact, it is up to how the value of the measure is used and how that piece of architecture is designed to let people use the data.
Fourth, as long as you can do the join operation, it is a good idea to have the date dimension. You cannot rely on special functions to tell you when a special public holiday is in a certain country. They have to be documented in the date table.
Fifth, I think what has been misleading in the book is that you should not always add as many attributes to the dimensional tables as possible. In the physical world, there is a limitation of row size, and by adding more columns to each row, the performance for doing queries is getting worse. One has to take a very serious step to consider whether to add a new column or to find out ways so that you can do the calculation without adding anything at all.
Sixth, apparently only the “happened” facts are recorded in the fact table. What about those that are not “happened?” For example, what are the products that are in promotion but are not sold by any amount? There can be multiple ways to cope with this request. Either you run a query to find out those that are sold and then filter out the unsold, or you add a column to the Sales fact table with a lot of “0” values in it. Because the unknown things also have hierarchies, what the book suggests is to add another fact table to carry such information. The difference of this fact table is that you do not have to be one the same grain as the Sales table. By doing this, you can record the information in an easy (for query) way and save the disk cost by rolling-up the grain. Note that this fact table may just look like a many-to-many table without facts (a factless fact table).
Seventh, regarding degenerating dimensions, it is OK and normally allowed to have them. In the example given by the book, the “transaction number” is just added to the fact table (and actually there can be a transaction dimension to record more things if needed).
Eighth, what brings the most difficulty to the dimensional design is not the initial requirement, but the new requirements after the initial design has been established. It takes a modeling team much more time to just consider how to add the new requirements to the existing star-schema model. If new fields are added, what happens to the corresponding values of those records that are already there? Should each of the records always have “not available” value on the new fields? This is a place where best practices should be collected. And I do not believe that there is always a single method that can solve all the problems. The best practices have to be selected and used case-by-case.
Ninth, what should be bared in mind for dimensional modelers, is that the nature of dimensional model is for business users to be able to query on but not for systems to efficiently update. So this model is and should not be quite normalized. So snow-flaking is in fact a risk for dimensional models. In addition to bring extra cost on joining the different tables, you cannot even create bitmap indexing on necessary fields. Business users will also find it difficult to see through the snow flake tables because there is too much snow flake. J
Tenth, I do not quite like the claim that “most business processes can be represented with less than 15 dimensions in the fact table.” Perhaps Kimall is right but an exact value brings nothing but difficulty in a modeler’s struggle with managers who do not know much about modeling but just want things done in the way the book says.
3. Surrogate Keys
Surrogate keys make so much benefit in dimensional models and please bear in mind that it is the best if one can just use small integer numbers for the surrogate keys (instead of writing a hashing function). Using surrogate keys also means that data warehouse people do not have to rely on the operational system people on the natural keys. This situation gets even worse when the people in operational systems decide to re-cycle the account number or product numbers that are inactive for a certain period of time (but the data warehouse’ life is much longer than this period).
Sometimes you just cannot rely one the natural keys to keep the data clean. For example, a product number plus a date can be a combined natural key. But the value for the “date” field may be unknown for a period, what do we do with the record during this period? How to identify them?
One deep performance problem with having a star-schema model, is the cost of making join operations. So one wise idea is to use single keys, like surrogate keys, instead of having compound or concatenated keys because you then have to join on multiple columns and that is much more complicated.
4. Market Basket Analysis
What is interesting in this part, is the book shows how to use the star-schema model for analysis purposes. The idea is to generate regular reports based on a join operation between the fact table and several dimensional tables. Actually I would think an OLAP tool will make this work much easier.
Showing posts with label The Data Warehouse Toolkit. Show all posts
Showing posts with label The Data Warehouse Toolkit. Show all posts
Tuesday, May 20, 2008
Tuesday, March 18, 2008
Notes for reading "The Data Warehouse Toolkit"
The second edition of "'The Data Warehouse Toolkit" by Ralph Kimball and Margy Ross is a great book about dimensional modeling. It is presumed as an industry-must-read material by most data warehouse people.
Here comes the reading notes for Ch. 1
Chapter 1 Dimensional Modeling Primer
Do you need a background to work with data warehouse? Yes, definitely. This whole chapter is talking about what you have to understand to be able to understand the data warehouse.
The first thing to clarify is the difference between "operational systems" and the data warehouse. In general, an operational system deals with one record at a time. It takes orders, register customers, or log complaints. It does not do a lot of summary or aggregations or dash board things like data warehouse does. It is a rigid system. It works with transactions if necessary. It repeats the same procedures over and over to finish the same business processes. Operational systems also keep historical records of data, but for a different purpose from the data warehouse. These historical records are only used for validation, recovery, but not for summarization. Data warehouse is where the historical data is re-organized, conformed, and summarized. Data warehouse is used in a more dynamic way. I admit that, there are quite a lot of similar reports that a data warehouse must present. But the power the data warehouse is that, when users come up with new questions, it is able to answer the questions easily. When the same thing happens to the operation systems, that requires a re-development of the platform which is very expensive.
So, what is the role of a data warehouse in an enterprise? There are following answers.
a. It should make all the data "easily accessible" which means a data warehouse is not another castle in the enterprise that everybody must try hard to learn and understand. It should be easily understood and used by most business folks.
b. It is a place to keep all the data consistent. Nowadays, people are talking about "one version of the truth." The data warehouse is definitely the best place to keep the truth of all the data.
c. The data warehouse should be ready for any changes. That is also one big difference between the data warehouse and operational systems.
d. As I quote from the book. "An organization's informational crown jewels are stored in data warehouse." The data warehouse must have effective control on the confidential information of the enterprise.
e. The data warehouse must ensure the correctness and completeness of the information it contains in order to serve the decision-making of the enterprise.
f. Once created, the data warehouse must be used. So the data warehouse must be widely accepted by the business community in the beginning of its life cycle.
So, to make a successful data warehouse, it is important that your team must take knowledge and skills from both DBA side and MBA side.
We can try to think data-warehouse-publishing-data as the process of an editor trying to publish a magazine. Apparently you need to talk to the audience, understand their attention, and provides the right information at the right time. Usually you have to come to people to collect new requests for improvement. You need to find new source of information. You need to develop and manage a good network of people working with the magazine. You need to keep all relevant people (esp. those at business sides) happy. Data warehousing is about publishing the right data at the right time to the right people.
So, if we begin to talk about the data warehouse (I mean, seriously, not things around the data warehouse but the things very nearby and inside the data warehouse). What are the parts that make up a complete data warehouse environment? There are four distinctive types of components, source systems, data staging area, data presentation area, and data access tools.
Let us discuss each in the following.
1. Source systems. What can be source systems? I would say any applications that deliver data to the data warehouse. Is source system equal to operational system? The answer may be “no,” because nowadays people are talking about collecting data from Internet or certain ERP, CRM systems (which can be assumed to be a kind of BI appliance) into the data warehouse. But most of the source systems are operational ones. If an enterprise takes efforts to do EAI (enterprise application integration) which means these systems are re-engineered to have a consistent view on processes or functionalities or data or all of them, the data warehousing task will become much easier.
2. Data staging area. I like very much the example provided in the book. Just imagine the data staging area as the kitchen of a restaurant. One thing to keep in mind is that this is a both storage area and an area of many processes. By “processes” I mean those that do the extract-transform-load (ETL) jobs. It is, as described in the book, everything between the source systems and the data presentation area. One thing that normally should not happen is to let the customers come into the kitchen or eat directly in the kitchen. That’s a rule-of-thumb. As to the book’s point of view, those in industry that talks about “enterprise data warehouse” are actually talking about something in the staging area. A more general meaning of enterprise data warehouse includes both the staging area and the presentation area and perhaps also the source systems.
3. Data presentation area. The usage of dimensional model is a bit kind of nature because people tend think of this as a very simple way of understanding things. So you have to accept that dimensional modeling is successful and has to be the only modeling way used at the data presentation area. Regarding the data marts in the presentation area, I would agree that the “bus” structure is a kind of natural choices when it comes to different BI applications with great challenges to conform everything into single dimensions and facts. However, there has to be a place where the “one version of the truth” of the data is kept. If you cannot hold them in the data presentation area, then they have to be at the data staging area. That is perhaps why a lot of people nowadays are talking about establishing a RDM 3NF model at an EDW before everything is mapped into dimensional models. As we all know that Start Schema is used very widely to support dimensional model in relational database. Actually another way of making the presentation area is the multidimensional database or OLAP. I believe that, not in the far future, OLAP applications will become more and more mature so that the “star-schema” time will be over very soon.
4. Data access tools. This is normally called BI applications nowadays. Excel and the front-end query tools like SQL Server- Query analyzer are also part of the data access tool.
Are there other possible components? Yes according to the current trend. Examples include metadata repository and ODS and data quality tools.
Regarding metadata, it has been reaching a stage that the whole data warehousing industry realizes its importance and quite a few tools are emerging to support centralized, unified metadata framework. Most people knew that metadata is of great importance but did not realize how bad it could be without doing anything about it. That was why a lot of enterprises are eagerly looking for a metadata solution. To work out metadata management, the first thing is the scope, i.e., how much you want the metadata framework to be. You need a complete conceptual framework to support the implementation of the metadata system. How to define the scope of metadata framework? That depends on your ambition and budget. Do you want to have a framework that is scalable for the next 20 years? Or just something that is able to help you in the next 5 years? Not a lot of people are mentally strong enough to support a very long-term metadata framework. At least, you need to figure out the relevant metadata around the data warehouse, and to corral, catalog, integrate these varieties of metadata. And this is like a resource library. Compared to the dimensional data modeling, metadata model is much more complicated.
Next, ODS, operational data store. ODS normally stays at the data staging area. It is kept frequently updated and it is a place where the data from source systems are somewhat integrated. It is a database with 3NF design. Sometime ago, I was confused by the ODS and the “enterprise-data-warehouse” that I described above. In fact, if you have an 3NF relational data model at the EDW, this EDW is actually part of the data staging area and is actually equally to the ODS to some extent. The difference between ODS and the “EDW” is where you put a lot of business calculations defined by the BI applications. There should not be so many such calculations between the source systems and the ODS. People need ODS normally because they need some kinds of immediate report which needs to integrate a lot of data from difference source systems. Real-time BI may be a requirement to have ODS. There are trends that people put ODS as a specially-administrated part of the conventional data warehouse.
Vocabulary of dimensional modeling
A fact table is where the numerical performance measurements of the business are stored. Normally measurement data is the largest portion of any data mart. What is important for defining a fact table is the grain of the data. It must comply to the same grain of all the relevant dimension tables. What can become difficult to build a fact table is to decide the columns in the fact table. There are additive facts and semi-additive facts that seem to be difficult to put, either in a fact table or a dimension table. It is also possible that a fact can be textual type. But normally developers would try to put it to dimensional tables.
Dimension tables contain the description of business. Each dimension table may have more than 50 attributes. These attributes are used to divide, group, merge different business entities which is then joined with the fact tables to have a business-oriented calculation. The result of such calculation may lead to a report, a performance report, a business decision, or a new business product.
There are few things that always stay around the dimension table design. a) Operational codes (suffix, etc.) b) The hierarchy behind a business area, such as family relations, organization relations, etc., is normally stored by the dimension table (although it brings redundancy) c) A snow flake design may let the business understanding a bit clearer, but it is definitely a performance disaster. d) The granularity of data must be clarified before the data model is designed. Normally people come to the finest grain as much as possible. e) There is also an issue about time and updates, i.e., the so-called slowly-changing-dimension (SCD) problem.
The dimensional model, compared to an ER diagram, may be simpler. Normally ER diagrams combines and conforms to a lot of business scenarios together. When making dimensional model based on the ER diagrams, those many-to-many relationships in the ER diagrams that contain numeric and additive non-key fields are mostly facts and should be put into fact tables. The remaining tables then should be de-normalized into flat tables like the dimension tables.
There are quite a few things to be careful when doing dimensional modeling in the industry.
1. The grain of data in the dimensional model should be the finest, not for summary. And the dimensional model should have data of the whole history.
2. One should be very careful with how to scope the dimensional models. It can be departmental or process-oriented (i.e., one model for one business process). Some people support the approach of spide-web (or Hub-spoke) approach that you always have a central place to feed data to all the data marts, but Kimbal seems to disagree with this idea and support the idea of multiple feeds. I would agree with a hub-spoke way because, if we look at the data from a senior management point of view, it is very important that you have an easy way of managing the data flow and the “bus” architecture seems to bring a lot more correlations and connections than the “hub-spoke” one. And it is better to use the “hub-spoke” if you are serious about the “one-version-of-the-truth.”
3. Dimensional model can be applied to many different industries.
4. It is better to have the usage pattern when you are designing a dimensional model. But it is not compulsory. A dimensional model can still be successful without knowing how it is going to be used exactly in the beginning of the design. Anyways, the designer can coach the user.
5. Be focused more on business requirements and goals when developing a data warehouse as they are more important than technologies.
6. Make sure that you include influential, accessible, and reasonable business sponsors in the project.
7. It may be more useful to consider an iterative project process to develop a data mart.
8. Make sure that the data presentation area is considered equally important to the staging area by th project, and allocate time on the data presentation area as much as you can.
9. Be aware that, many requirements and analytics around the data warehouse is changing over the time.
10. The success of a data warehouse is ultimately decided by the users.
This the end of my note on Ch. 1.
Here comes the reading notes for Ch. 1
Chapter 1 Dimensional Modeling Primer
Do you need a background to work with data warehouse? Yes, definitely. This whole chapter is talking about what you have to understand to be able to understand the data warehouse.
The first thing to clarify is the difference between "operational systems" and the data warehouse. In general, an operational system deals with one record at a time. It takes orders, register customers, or log complaints. It does not do a lot of summary or aggregations or dash board things like data warehouse does. It is a rigid system. It works with transactions if necessary. It repeats the same procedures over and over to finish the same business processes. Operational systems also keep historical records of data, but for a different purpose from the data warehouse. These historical records are only used for validation, recovery, but not for summarization. Data warehouse is where the historical data is re-organized, conformed, and summarized. Data warehouse is used in a more dynamic way. I admit that, there are quite a lot of similar reports that a data warehouse must present. But the power the data warehouse is that, when users come up with new questions, it is able to answer the questions easily. When the same thing happens to the operation systems, that requires a re-development of the platform which is very expensive.
So, what is the role of a data warehouse in an enterprise? There are following answers.
a. It should make all the data "easily accessible" which means a data warehouse is not another castle in the enterprise that everybody must try hard to learn and understand. It should be easily understood and used by most business folks.
b. It is a place to keep all the data consistent. Nowadays, people are talking about "one version of the truth." The data warehouse is definitely the best place to keep the truth of all the data.
c. The data warehouse should be ready for any changes. That is also one big difference between the data warehouse and operational systems.
d. As I quote from the book. "An organization's informational crown jewels are stored in data warehouse." The data warehouse must have effective control on the confidential information of the enterprise.
e. The data warehouse must ensure the correctness and completeness of the information it contains in order to serve the decision-making of the enterprise.
f. Once created, the data warehouse must be used. So the data warehouse must be widely accepted by the business community in the beginning of its life cycle.
So, to make a successful data warehouse, it is important that your team must take knowledge and skills from both DBA side and MBA side.
We can try to think data-warehouse-publishing-data as the process of an editor trying to publish a magazine. Apparently you need to talk to the audience, understand their attention, and provides the right information at the right time. Usually you have to come to people to collect new requests for improvement. You need to find new source of information. You need to develop and manage a good network of people working with the magazine. You need to keep all relevant people (esp. those at business sides) happy. Data warehousing is about publishing the right data at the right time to the right people.
So, if we begin to talk about the data warehouse (I mean, seriously, not things around the data warehouse but the things very nearby and inside the data warehouse). What are the parts that make up a complete data warehouse environment? There are four distinctive types of components, source systems, data staging area, data presentation area, and data access tools.
Let us discuss each in the following.
1. Source systems. What can be source systems? I would say any applications that deliver data to the data warehouse. Is source system equal to operational system? The answer may be “no,” because nowadays people are talking about collecting data from Internet or certain ERP, CRM systems (which can be assumed to be a kind of BI appliance) into the data warehouse. But most of the source systems are operational ones. If an enterprise takes efforts to do EAI (enterprise application integration) which means these systems are re-engineered to have a consistent view on processes or functionalities or data or all of them, the data warehousing task will become much easier.
2. Data staging area. I like very much the example provided in the book. Just imagine the data staging area as the kitchen of a restaurant. One thing to keep in mind is that this is a both storage area and an area of many processes. By “processes” I mean those that do the extract-transform-load (ETL) jobs. It is, as described in the book, everything between the source systems and the data presentation area. One thing that normally should not happen is to let the customers come into the kitchen or eat directly in the kitchen. That’s a rule-of-thumb. As to the book’s point of view, those in industry that talks about “enterprise data warehouse” are actually talking about something in the staging area. A more general meaning of enterprise data warehouse includes both the staging area and the presentation area and perhaps also the source systems.
3. Data presentation area. The usage of dimensional model is a bit kind of nature because people tend think of this as a very simple way of understanding things. So you have to accept that dimensional modeling is successful and has to be the only modeling way used at the data presentation area. Regarding the data marts in the presentation area, I would agree that the “bus” structure is a kind of natural choices when it comes to different BI applications with great challenges to conform everything into single dimensions and facts. However, there has to be a place where the “one version of the truth” of the data is kept. If you cannot hold them in the data presentation area, then they have to be at the data staging area. That is perhaps why a lot of people nowadays are talking about establishing a RDM 3NF model at an EDW before everything is mapped into dimensional models. As we all know that Start Schema is used very widely to support dimensional model in relational database. Actually another way of making the presentation area is the multidimensional database or OLAP. I believe that, not in the far future, OLAP applications will become more and more mature so that the “star-schema” time will be over very soon.
4. Data access tools. This is normally called BI applications nowadays. Excel and the front-end query tools like SQL Server- Query analyzer are also part of the data access tool.
Are there other possible components? Yes according to the current trend. Examples include metadata repository and ODS and data quality tools.
Regarding metadata, it has been reaching a stage that the whole data warehousing industry realizes its importance and quite a few tools are emerging to support centralized, unified metadata framework. Most people knew that metadata is of great importance but did not realize how bad it could be without doing anything about it. That was why a lot of enterprises are eagerly looking for a metadata solution. To work out metadata management, the first thing is the scope, i.e., how much you want the metadata framework to be. You need a complete conceptual framework to support the implementation of the metadata system. How to define the scope of metadata framework? That depends on your ambition and budget. Do you want to have a framework that is scalable for the next 20 years? Or just something that is able to help you in the next 5 years? Not a lot of people are mentally strong enough to support a very long-term metadata framework. At least, you need to figure out the relevant metadata around the data warehouse, and to corral, catalog, integrate these varieties of metadata. And this is like a resource library. Compared to the dimensional data modeling, metadata model is much more complicated.
Next, ODS, operational data store. ODS normally stays at the data staging area. It is kept frequently updated and it is a place where the data from source systems are somewhat integrated. It is a database with 3NF design. Sometime ago, I was confused by the ODS and the “enterprise-data-warehouse” that I described above. In fact, if you have an 3NF relational data model at the EDW, this EDW is actually part of the data staging area and is actually equally to the ODS to some extent. The difference between ODS and the “EDW” is where you put a lot of business calculations defined by the BI applications. There should not be so many such calculations between the source systems and the ODS. People need ODS normally because they need some kinds of immediate report which needs to integrate a lot of data from difference source systems. Real-time BI may be a requirement to have ODS. There are trends that people put ODS as a specially-administrated part of the conventional data warehouse.
Vocabulary of dimensional modeling
A fact table is where the numerical performance measurements of the business are stored. Normally measurement data is the largest portion of any data mart. What is important for defining a fact table is the grain of the data. It must comply to the same grain of all the relevant dimension tables. What can become difficult to build a fact table is to decide the columns in the fact table. There are additive facts and semi-additive facts that seem to be difficult to put, either in a fact table or a dimension table. It is also possible that a fact can be textual type. But normally developers would try to put it to dimensional tables.
Dimension tables contain the description of business. Each dimension table may have more than 50 attributes. These attributes are used to divide, group, merge different business entities which is then joined with the fact tables to have a business-oriented calculation. The result of such calculation may lead to a report, a performance report, a business decision, or a new business product.
There are few things that always stay around the dimension table design. a) Operational codes (suffix, etc.) b) The hierarchy behind a business area, such as family relations, organization relations, etc., is normally stored by the dimension table (although it brings redundancy) c) A snow flake design may let the business understanding a bit clearer, but it is definitely a performance disaster. d) The granularity of data must be clarified before the data model is designed. Normally people come to the finest grain as much as possible. e) There is also an issue about time and updates, i.e., the so-called slowly-changing-dimension (SCD) problem.
The dimensional model, compared to an ER diagram, may be simpler. Normally ER diagrams combines and conforms to a lot of business scenarios together. When making dimensional model based on the ER diagrams, those many-to-many relationships in the ER diagrams that contain numeric and additive non-key fields are mostly facts and should be put into fact tables. The remaining tables then should be de-normalized into flat tables like the dimension tables.
There are quite a few things to be careful when doing dimensional modeling in the industry.
1. The grain of data in the dimensional model should be the finest, not for summary. And the dimensional model should have data of the whole history.
2. One should be very careful with how to scope the dimensional models. It can be departmental or process-oriented (i.e., one model for one business process). Some people support the approach of spide-web (or Hub-spoke) approach that you always have a central place to feed data to all the data marts, but Kimbal seems to disagree with this idea and support the idea of multiple feeds. I would agree with a hub-spoke way because, if we look at the data from a senior management point of view, it is very important that you have an easy way of managing the data flow and the “bus” architecture seems to bring a lot more correlations and connections than the “hub-spoke” one. And it is better to use the “hub-spoke” if you are serious about the “one-version-of-the-truth.”
3. Dimensional model can be applied to many different industries.
4. It is better to have the usage pattern when you are designing a dimensional model. But it is not compulsory. A dimensional model can still be successful without knowing how it is going to be used exactly in the beginning of the design. Anyways, the designer can coach the user.
5. Be focused more on business requirements and goals when developing a data warehouse as they are more important than technologies.
6. Make sure that you include influential, accessible, and reasonable business sponsors in the project.
7. It may be more useful to consider an iterative project process to develop a data mart.
8. Make sure that the data presentation area is considered equally important to the staging area by th project, and allocate time on the data presentation area as much as you can.
9. Be aware that, many requirements and analytics around the data warehouse is changing over the time.
10. The success of a data warehouse is ultimately decided by the users.
This the end of my note on Ch. 1.
Subscribe to:
Posts (Atom)