Expert Cube Development with Microsoft SQL Server 2008

Usage of schemas
The data warehouse is normally divided into subject areas. The meaning of a
subject area really depends on the specific needs of the solution. Typical subject
areas include:
•
•
•
•
•
Sales
Accounts
Warehouses
Suppliers
Personnel and staff management
[ 33 ]
Chapter 1
Clearly, this list is far from complete and is different for every business. SQL Server
2005 and 2008 provide schemas to arrange tables and – in our experience – the
usage of schemas to assign database objects to subject areas leads to a very clear
database structure.
Some tables will inevitably have no place at all in any subject area, but we can
always define a "COMMON" subject area to hold all these tables.
Naming conventions
A clear and consistent naming convention is good practice for any kind of relational
database and a data mart is no different. As well as making the structure more
readable, it will help us when we come to build our cube because BI Development
Studio will be able to work out automatically which columns in our dimension and
fact tables should join to each other if they have the same names.
Views versus the Data Source View
The Data Source View (DSV) is one of the places where we can create an interface
between Analysis Services and the underlying relational model. In the DSV we
can specify joins between tables, we can create named queries and calculations to
provide the equivalent of views and derived columns. It's very convenient for the
cube developer to open up the DSV in BI Development Studio and make these kind
of changes.
This is all well and good, but nevertheless our opinion about the DSV is clear: it is
almost too powerful and, using its features, we risk turning a clean, elegant structure
into a mess. It is certainly true that there is the need for an interface between the
relational model of the database and the final star schema, but we don't think it's a
good idea to use the DSV for this purpose.
Download at Boykma.Com