About hemant04gulati

One very simple option is making a boolean formatted conditional formatting rule:   If End Date < Start Date THEN 1 ELSE 0 ENDIF   The End Date cell will become red when the End Date < Start Date   We can add a rule drive text besides that which says: End Date can't be less than Start Date   Note: Shared this just as a quick alternative. ... View more

Thanks @Jared Dolich !   Yes, I have been using the Anaplan tableau connector from its pilot phase. I will try exploring things through Power BI as I do get a chance sooner than later.   The underlying temptation to have something like D3, Force, or Highcharts within Anaplan Dashboards or Pages is "Doing Visualizations the Anaplan Way, Right There Right Then". And avoiding any manual bridges like updating tableau extract for pulling the data changes from Anaplan. ... View more

https://en.wikipedia.org/wiki/Star_schema   Star Schema Model   The star schema separates business process data into facts, which hold the measurable, quantitative data about a business, and dimensions which are descriptive attributes related to fact data. Examples of fact data include sales price, sale quantity, and time, distance, speed, and weight measurements. Related dimension attribute examples include product models, product colors, product sizes, geographic locations, and salesperson names. A star schema that has many dimensions is sometimes called a   centipede schema.[4]   Having dimensions of only a few attributes, while simpler to maintain, results in queries with many table joins and makes the star schema-less easy to use.   Fact tables Fact tables record measurements or metrics for a specific event. Fact tables generally consist of numeric values, and foreign keys to dimensional data where descriptive information is kept.   Fact tables are designed to a low level of uniform detail (referred to as "granularity" or "grain"), meaning facts can record events at a very atomic level. This can result in the accumulation of a large number of records in a fact table over time. Fact tables are defined as one of three types: Transaction fact tables record facts about a specific event (e.g., sales events) Snapshot fact tables record facts at a given point in time (e.g., account details at month-end) Accumulating snapshot tables record aggregate facts at a given point in time (e.g., total month-to-date sales for a product) Fact tables are generally assigned a   surrogate key   to ensure each row can be uniquely identified. This key is a simple primary key. Dimension tables Dimension tables usually have a relatively small number of records compared to fact tables, but each record may have a very large number of attributes to describe the fact data. Dimensions can define a wide variety of characteristics, but some of the most common attributes defined by dimension tables include: Time dimension tables describe time at the lowest level of time granularity for which events are recorded in the star schema Geography dimension tables describe location data, such as country, state, or city Product dimension tables describe products Employee dimension tables describe employees, such as salespeople Range dimension tables describe ranges of time, dollar values or other measurable quantities to simplify reporting Dimension tables are generally assigned a   surrogate primary key, usually, a single-column integer data type, mapped to the combination of dimension attributes that form the natural key.   Benefits Star schemas are   denormalized, meaning the normal rules of normalization applied to transactional relational databases are relaxed during star schema design and implementation. The benefits of star schema denormalization are: Simpler queries – star schema join logic is generally simpler than the join logic required to retrieve data from a highly normalized transactional schema. Simplified business reporting logic – when compared to highly normalized schemas, the star schema simplifies common business reporting logic, such as period-over-period and as-of reporting. Query performance gains – star schemas can provide performance enhancements for read-only reporting applications when compared to highly   normalized   schemas. Fast aggregations – the simpler queries against a star schema can result in improved performance for aggregation operations. Feeding cubes – star schemas are used by all   OLAP   systems to build proprietary   OLAP cubes   efficiently; in fact, most major OLAP systems provide a   ROLAP   mode of operation that can use a star schema directly as a source without building a proprietary cube structure. ... View more

Hi @Misbah    Would like to get a quick gist about, did you get a chance to build star schema-based models in the past? Otherwise, I can write a quick introduction to that approach.   Thanks! ... View more