Ralph Kimball > Quotes

“Dimensional models implemented in relational database management systems are referred to as star schemas because of their resemblance to a star-like structure. Dimensional models implemented in multidimensional database environments are referred to as online analytical processing (OLAP) cubes, as illustrated in Figure 1.1. Figure 1.1 Star schema versus OLAP cube. If your DW/BI environment includes either star schemas or OLAP cubes, it leverages dimensional concepts. Both stars and cubes have a common logical design with recognizable dimensions; however, the physical implementation differs. When data is loaded into an OLAP cube, it is stored and indexed using formats and techniques that are designed for dimensional data. Performance aggregations or precalculated summary tables are often created and managed by the OLAP cube engine. Consequently, cubes deliver superior query performance because of the precalculations, indexing strategies, and other optimizations. Business users can drill down or up by adding or removing attributes from their analyses with excellent performance without issuing new queries. OLAP cubes also provide more analytically robust functions that exceed those available with SQL. The downside is that you pay a load performance price for these capabilities, especially with large data sets.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Crucial Conversations: Tools for Talking When Stakes are High, 2nd edition,”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“The Quick and Easy Way to Effective Speaking by Dale Carnegie”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“Grain Declaring the grain is the pivotal step in a dimensional design. The grain establishes exactly what a single fact table row represents. The grain declaration becomes a binding contract on the design. The grain must be declared before choosing dimensions or facts because every candidate dimension or fact must be consistent with the grain. This consistency enforces a uniformity on all dimensional designs that is critical to BI application performance and ease of use. Atomic grain refers to the lowest level at which data is captured by a given business process. We strongly encourage you to start by focusing on atomic-grained data because it withstands the assault of unpredictable user queries; rolled-up summary grains are important for performance tuning, but they pre-suppose the business's common questions. Each proposed fact table grain results in a separate physical table; different grains must not be mixed in the same fact table.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Each business process is represented by a dimensional model that consists of a fact table containing the event's numeric measurements surrounded by a halo of dimension tables that contain the textual context that was true at the moment the event occurred. This characteristic star-like structure is often called a star join, a term dating back to the earliest days of relational databases. Figure 1.5 Fact and dimension tables in a dimensional model. The first thing to notice about the dimensional schema is its simplicity and symmetry. Obviously, business users benefit from the simplicity because the data is easier to understand and navigate. The charm of the design in Figure 1.5 is that it is highly recognizable to business users. We have observed literally hundreds of instances in which users immediately agree that the dimensional model is their business. Furthermore, the reduced number of tables and use of meaningful business descriptors make it easy to navigate and less likely that mistakes will occur. The simplicity of a dimensional model also has performance benefits. Database optimizers process these simple schemas with fewer joins more efficiently. A database engine can make strong assumptions about first constraining the heavily indexed dimension tables, and then attacking the fact table all at once with the Cartesian product of the dimension table keys satisfying the user's constraints. Amazingly, using this approach, the optimizer can evaluate arbitrary n-way joins to a fact table in a single pass through the fact table's index. Finally, dimensional models are gracefully extensible to accommodate change. The predictable framework of a dimensional model withstands unexpected changes in user behavior. Every dimension is equivalent; all dimensions are symmetrically-equal entry points into the fact table. The dimensional model has no built-in bias regarding expected query patterns. There are no preferences for the business questions asked this month versus the questions asked next month. You certainly don't want to adjust schemas if business users suggest new ways to analyze their business.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“On Writing Well: The Classic Guide to Writing Nonfiction by William Zinsser (Collins, 2006)”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“The Elements of Style by William Strunk Jr. and E.B. White”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“Dimensions for Descriptive Context Dimensions provide the “who, what, where, when, why, and how” context surrounding a business process event. Dimension tables contain the descriptive attributes used by BI applications for filtering and grouping the facts. With the grain of a fact table firmly in mind, all the possible dimensions can be identified. Whenever possible, a dimension should be single valued when associated with a given fact row. Dimension tables are sometimes called the “soul” of the data warehouse because they contain the entry points and descriptive labels that enable the DW/BI system to be leveraged for business analysis. A disproportionate amount of effort is put into the data governance and development of dimension tables because they are the drivers of the user's BI experience. Chapter 1 DW/BI and Dimensional Modeling Primer Chapter 3 Retail Sales Chapter 11 Telecommunications Chapter 18 Dimensional Modeling Process and Tasks Chapter 19 ETL Subsystems and Techniques”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Integration via Conformed Dimensions One of the marquee successes of the dimensional modeling approach has been to define a simple but powerful recipe for integrating data from different business processes.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“architect Mies van der Rohe is credited with saying, “God is in the details.” Delivering”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Four-Step Dimensional Design Process The four key decisions made during the design of a dimensional model include: 1. Select the business process. 2. Declare the grain. 3. Identify the dimensions. 4. Identify the facts.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“there are four separate and distinct components to consider in the DW/BI environment: operational source systems, ETL system, data presentation area, and business intelligence applications.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Keys to Great Writing by Stephen Wilbers”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“Basic Fact Table Techniques The techniques in this section apply to all fact tables. There are illustrations”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Business Processes Business processes are the operational activities performed by your organization, such as taking an order, processing an insurance claim, registering students for a class, or snapshotting every account each month. Business process events generate or capture performance metrics that translate into facts in a fact table. Most fact tables focus on the results of a single business process. Choosing the process is important because it defines a specific design target and allows the grain, dimensions, and facts to be declared. Each business process corresponds to a row in the enterprise data warehouse bus matrix.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Presentation Zen: Simple Ideas on Presentation Design and Delivery by”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“Dimensional designers listen carefully to the emphasis on product, market, and time. Most people find it intuitive to think of such a business as a cube of data, with the edges labeled product, market, and time. Imagine slicing and dicing along each of these dimensions. Points inside the cube are where the measurements, 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 set of data in a concrete and tangible way is the secret of understandability. If”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“This asset is almost always used for two purposes: operational record keeping and analytical decision making. Simply speaking, the operational systems are where you put the data in, and the DW/BI system”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Dimensions provide the “who, what, where, when, why, and how” context surrounding a business process event. Dimension tables contain the descriptive attributes used by BI applications for filtering and grouping the facts.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Enterprise Data Warehouse Bus Matrix The enterprise data warehouse bus matrix is the essential tool for designing and communicating the enterprise data warehouse bus architecture. The rows of the matrix are business processes and the columns are dimensions. The shaded cells of the matrix indicate whether a dimension is associated with a given business process. The design team scans each row to test whether a candidate dimension is well-defined for the business process and also scans each column to see where a dimension should be conformed across multiple business processes. Besides the technical design considerations, the bus matrix is used as input to prioritize DW/BI projects with business management as teams should implement one row of the matrix at a time.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Facts for Measurements Facts are the measurements that result from a business process event and are almost always numeric. A single fact table row has a one-to-one relationship to a measurementevent as described by the fact table's grain. Thus a fact table corresponds to a physical observable event, and not to the demands of a particular report. Within a fact table, only facts consistent with the declared grain are allowed. For example, in a retail sales transaction, the quantity of a product sold and its extended price are good facts, whereas the store manager's salary is disallowed.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Basic Dimension Table Techniques The techniques in this section apply to all dimension tables. Dimension tables are discussed and illustrated in every chapter.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“When asked about the best way to design and build the ETL system, many designers say, “Well, that depends.” It depends on the source; it depends on limitations of the data; it depends on the scripting languages and ETL tools available; it depends on the staff’s skills; and it depends on the BI tools. But the “it depends” response is dangerous because it becomes an excuse to take an unstructured approach to developing an ETL system, which in the worse-case scenario results in an undifferentiated spaghetti-mess of tables, modules, processes, scripts, triggers, alerts, and job schedules. This “creative” design approach should not be tolerated. With the wisdom of hindsight from thousands of successful data warehouses, a set of ETL best practices have emerged. There is no reason to tolerate an unstructured approach.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling

“Data warehouse support people should be physically located in the business user departments, and while on assignment, should spend all their waking hours devoted to the business content of the departments they serve. Such a relationship engenders trust and credibility with the business users, which ultimately is the “gold coin” for IT. Mistake”
― Ralph Kimball, The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence Remastered Collection

“final step of the ETL process is the physical structuring and loading of data into the presentation area's target dimensional models. Because the primary mission of the ETL system is to hand off the dimension and fact tables in the delivery step, these subsystems are critical. Many of these defined subsystems focus on dimension table processing, such as surrogate key assignments, code lookups to provide appropriate descriptions, splitting, or combining columns to present the appropriate data values, or joining underlying third normal form table structures into flattened denormalized dimensions. In contrast, fact tables are typically large and time consuming to load, but preparing them for the presentation area is typically straightforward. When the dimension and fact tables in a dimensional model have been updated, indexed, supplied with appropriate aggregates, and further quality assured, the business community is notified that the new data has been published.”
― Ralph Kimball, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling