Database Reference
In-Depth Information
could vary but aren't really relevant to this discussion—the bottom line is that you
must create a SSAS solution using Oracle, db2, Sybase, Teradata, or another rela-
tional platform. This complicates development because you must learn at least the
basics of SQL flavor, used by the relational data source, to define named queries
and calculations. Additionally, you must also become familiar with errors that the re-
lational data source might raise during processing (and queries, in case you use a
ROLAP storage). The transaction isolation levels supported by each RDBMS can
also be different, and the various classes of objects can be implemented using a
different nomenclature. For example, the SQL Server implements ROLAP aggrega-
tions as indexed views, but db2 does not support indexed views—similar objects in
db2 are called Materialized Query Tables ( MQT ). Lastly, not every database vendor
allows looking under the hood as Microsoft does using Profiler, and majority of the
vendors offer support for textual (not graphical) query execution plans.
In this section, I will cover a few "gotchas" in case you find yourself developing SSAS
solutions against nonSQL Server data sources.
SSAS data structures
Most SSAS solutions are built using fact and dimension tables. If you must develop
against a database using the third normal form, you may have to define the neces-
sary objects in your data source views as named queries and/or named calculations.
This is relatively straightforward as long as you have the necessary permissions to
the underlying objects (tables or views) and you are comfortable using the SQL syn-
tax of a given RDBMS. Additionally, you'll need the parameters for connecting to the
relational data source using a .NET or OLEDB provider supplied either by Microsoft
or another vendor. Keep in mind that Microsoft will not support third-party providers.
If you have any issues during processing or ROLAP queries, you'll have to work dir-
ectly with the vendor who supplied the driver.
Transaction isolation levels
By default, Analysis Services uses a read-committed transaction isolation level. With
this level enforced, you should never experience data consistency issues. You could
improve processing performance by using a read-uncommitted transaction isolation
level, because the relational database wouldn't have the locking overhead while
reading the fact and dimension table data. To ensure that each processing com-
mand reads uncommitted data, you can edit the cartridge corresponding to the re-
Search WWH ::




Custom Search