barcode vb.net 2010 Part I in Software

Paint QR Code JIS X 0510 in Software Part I

Dimensions Product Product Description SKU Brand Code Brand Brand Manager Category Code Category Order Date Month of Order Quarter of Order Fiscal Period of Order Year of Order Salesperson Salesperson ID Territory Territory Code Territory Manager Region Region Code Region VP Customer Customer ID Headquarters State of Customer Billing Address Billing City Billing State Billing Zip SIC Code of Customer Industry Name of Customer

Salesperson Salesperson Salesperson ID Territory Territory Code Territory Manager Region Region Code Region VP

Customer Customer Customer ID Headquarters State of Customer Billing Address Billing City Billing State Billing Zip SIC Code of Customer Industry Name of Customer

A dimensional design for a relational database is called a star schema. Related dimensions are grouped as columns in dimension tables, and the facts are stored as columns in a fact table. The star schema gets its name from its appearance: when drawn with the fact table in the center, it looks like a star or asterisk. Figure 1-5 shows a simple star schema, based on the facts and dimensions for the orders process.

In a star schema, a dimension table contains columns representing dimensions. As discussed, these columns will provide context for facts. Sometimes, dimension table is simply shortened to dimension. This may give rise to confusion, since that word can also describe the individual columns. For example, when describing the schema shown in Figure 1-5, one might refer to the columns product, product_description, and SKU as dimensions, but it is also common practice to refer to the table itself as the product dimension. Generally, you can tell from the context whether the word dimension refers to a table or column. When it would not otherwise be clear, this book will use the terms dimension attribute and dimension table to make the distinction. The dimension tables serve to provide the rich context needed for the study of facts. In queries and reports, the dimensions will be used to specify how facts will be rolled up their level of aggregation. Dimension values may be used to filter reports. They will be used to provide context for each measurement, usually in the form of textual labels that precede facts on each row of a report. They may also be used to drive master-detail relationships, subtotaling, cross-tabulation, or sorts.

PRODUCT product_key product product_description sku brand brand_code brand_manager category category_code

SALESPERSON salesperson_key salesperson salesperson_id territory territory_code territory_manager region region_code region_vp

ORDER_FACTS product_key salesperson_key customer_key day_key quantity_ordered order_dollars cost_dollars

CUSTOMER customer_key customer customer_id headquarters_state billing address billing_city billing_state billing_zip sic_code industry_name

Figure 1-5

Readers with experience designing operational systems will notice that the dimension tables are not in third normal form. At first, many developers find this disconcerting. For example, there may be a strong desire to move brand, brand_code, and brand_manager into a separate table called brand, Remember, though, that a dimensional model serves a different purpose from an ER model. It is not necessary to isolate repeating values in an environment that does not support transaction processing. Designers do occasionally perform additional normalization within dimensions, although they usually avoid doing so. In such cases, the schema is referred to as a snowflake. The additional tables that result are sometimes called outriggers. Situations in which snowflaking may be useful are discussed in 7, Hierarchies and Snowflakes. Because the dimensions in a dimension table are often loosely related, it can sometimes be difficult to decide how to group things. For example, should sales region be part of the salesperson dimension, or does it belong as a separate geographical dimension Issues like this are tackled in 6.

In a star schema, each dimension table is given a surrogate key. This column is a unique identifier, created exclusively for the data warehouse. Surrogate keys are assigned and maintained as part of the process that loads the star schema. The surrogate key has no intrinsic meaning; it is typically an integer. Surrogate keys are sometimes referred to as warehouse keys. The surrogate key is the primary key of the dimension table.