Typically, my organisation's SAS database design is a mix of approaches depending on the developer who designed it. I've been searching for a long time about the preferred style of physical table design within DI which will marry up with the use of the BI tools. I feel that there is too much focus on how things were done about 5 years ago to navigate around problems with I/O and space constraints. Currently, many of the tables that are used by analysts with my organisation are monthly tables with a date suffix at the end of either YYYYMM or MON_YYYY. I feel that these don't naturally progress through into the BI tools - would people agree? This also leads to problems with (that is unable to) opening tables within DI as the preferences of tables have macro variables within them. Please can people share what they think is the best physical table structure within DI which will then allow users to get maximum benefit from the BI tool (OLAP cubes, Web Reports etc). I personally think that it should be.... Reception Layer contains the unformatted information from either raw files or SQL database connections.   Q: Do people retain the information within SAS? If so, how? Date suffixed tables? (I ask as a SAS form of the raw data might need to be retained in circumstances and doubt people would store in dimensions etc?) Foundation Layer contains a star schema type approach of dimensions and fact tables using custom transformations (as SCD works slowly). Exploitation Layer would be tables the analysts frequently use with single table containing multiple observation points allowing trend analysis etc. Are there any good SAS papers out there for this type of topic? Many thanks in advance. Clark ... View more