Client/Server Architecture and Data Access

Be Sociable, Share!

    Microsoft SQL Server 2008 Analysis Services Unleashed Review Chapter 31

    This chapter begins a new four-chapter section on accessing data in Analysis Services. This chapter has four basic messages, which I will summarize since this first chapter is a summary chapter.

    Message one: XML/A is at the top of the Analysis Services protocol stack (page 570), and is the subject of chapter 32:

    • XML for Analysis (XML/A) = application layer
    • SOAP (Simple Object Access Protocol) = presentation protocol layer
    • TCP (Transmission Control Protocol) = transport protocol layer
    • IPv4 or IPv6 (IP = Internet Protocol) = network protocol layer

    Message two: HTTP provides alternative access to Analysis Services through IIS

    • The protocol is well-known
    • It provides an alternative to NT integrated security
    • It allows full decoupling of the client and the server

    Message three: Users have offline access to data

    • The key to offline data is Microsoft Office (in general) and Excel (in particular)
    • This option has been extended with the introduction (since this book’s publication) of PowerPivot
    • The options will increase as this technology becomes available through SharePoint

    Message four: Four libraries ship with Analysis Services:

    • Query Management, Native Code: OLE DB for OLAP/ADOMD/ADO
    • Query Management, Managed Code: ADOMD.NET
    • Administration, Native Code: DSO
    • Administration, Managed Code: AMO

    The two managed code options are the subjects of chapters 33 and 34. The native code options remain as a legacy support for the many applications written in those languages. Pragmatically though, .NET is about 10 years old, and many people have moved on to the managed code alternatives for the advantages given to developers during development, and for other advantages during code maintenance and auditing. I personally would recommend people to take the managed code route unless an extremely sound case for native code could be made (a strong case would include both a preexisting native code base along with developers already experienced in native code development, who would not only develop new code but would be there to maintain it).

    Query management differs from administration in the goals. Query management aims to provide libraries to acquire data from Analysis Services. Administration libraries allow developers to create, modify, and delete objects within an analysis services database. Separating the libraries allows for better role management when allowing users to access Analysis Services. Focusing on data mining: the typical data miner creates and modifies data mining structures and models, which is an administrative activity (since it alters the analysis services database). Data mining modelers are, in my opinion, doing similar if not identical work to business intelligence architects who build and maintain OLAP cubes. I like class structure pictures, and you can see this administration story on the MSDN documentation, Introducing AMO Classes.

    A good general reference is the MSDN topic, Analysis Services Data Access Interfaces (Analysis Services – Multidimensional Data).

    Gorbach, I., Berger, A., & Melomed, E. (2009). Microsoft SQL Server 2008 Analysis Services Unleashed. Indianapolis, IN: Pearson Education Inc.
    ISBN: 0-672-33001-6

    Be Sociable, Share!