惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 叶小钗
O
OpenAI News
V
V2EX
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
S
Schneier on Security
C
CXSECURITY Database RSS Feed - CXSecurity.com
小众软件
小众软件
L
LINUX DO - 热门话题
C
Cybersecurity and Infrastructure Security Agency CISA
博客园 - Franky
Security Latest
Security Latest
S
SegmentFault 最新的问题
Project Zero
Project Zero
Spread Privacy
Spread Privacy
K
Kaspersky official blog
J
Java Code Geeks
V
Vulnerabilities – Threatpost
C
Cisco Blogs
C
CERT Recently Published Vulnerability Notes
月光博客
月光博客
T
The Exploit Database - CXSecurity.com
L
Lohrmann on Cybersecurity
人人都是产品经理
人人都是产品经理
博客园 - 三生石上(FineUI控件)
Scott Helme
Scott Helme
WordPress大学
WordPress大学
量子位
T
Threat Research - Cisco Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
宝玉的分享
宝玉的分享
Hugging Face - Blog
Hugging Face - Blog
AWS News Blog
AWS News Blog
Help Net Security
Help Net Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Simon Willison's Weblog
Simon Willison's Weblog
S
Secure Thoughts
博客园 - 【当耐特】
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
V
Visual Studio Blog
Last Week in AI
Last Week in AI
T
Tailwind CSS Blog
腾讯CDC
Cyberwarzone
Cyberwarzone
IT之家
IT之家
GbyAI
GbyAI
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
云风的 BLOG
云风的 BLOG
T
Troy Hunt's Blog
D
Docker

博客园 - 经霄

Microsoft ProClarity 6.3 releases to manufacturing Windows Services中使用MSBuild实现Build Automation Management VSS Object Model Google Service 使用反射动态创建类的实例 - 经霄 - 博客园 AS2005中的维度安全性简介【转】 学位英语通过,特此庆祝一下 VS2005常用插件 AMO编程 - 经霄 - 博客园 Analysis Management Object对象模型 华为前员工:揭密华为“薪酬真相”【转】 VS2005中读写配置文件(一) 微软笔试试题——11月13日,2005年 Structure of the Basic MDX Query(转) 使用ADOMD.NET建立与Analysis Services的连接 IT公司薪水调查 ADOMD.net概述 AdventureWorks数据库的安装 多维联机数据分析模型和系统设计方法[转]
SQL与MDX语法的比较
经霄 · 2005-10-14 · via 博客园 - 经霄

          Comparison of SQL and MDX Syntax

The Multidimensional Expressions (MDX) syntax is similar to the syntax of Structured Query Language (SQL). In many ways, the functionality supplied by MDX is also similar to that of SQL; with effort, you can even duplicate some of the functionality provided by MDX in SQL.

However, there are some striking differences between SQL and MDX. Here we provide a guide to these conceptual differences between SQL and MDX, from the perspective of an SQL developer.

Dimensions

The principal difference between SQL and MDX is the ability of MDX to reference multiple dimensions. Although it is possible to use SQL exclusively to query cubes in SQL Server 2000, MDX provides commands that are designed specifically to retrieve data as multidimensional data structures with almost any number of dimensions.

SQL refers to only two dimensions when processing queries: columns and rows. Because SQL was designed to handle only two-dimensional tabular data, the terms "column" and "row" have meaning in SQL syntax.

MDX, in comparison, can process one, two, three, or more dimensions in queries. Each dimension is referred to as an axis. The terms "column" and "row" in MDX are used only as aliases for the first two axis dimensions in an MDX query. Other dimensions are also aliased, but the aliases "column" and "row" hold no meaning to MDX. MDX supports such aliases for display purposes; many OLAP tools are incapable of displaying a result set with more than two dimensions. MDX can even process "zero-axis" queries that return only one cell from a cube, determined by a tuple constructed from the default member of each dimension in the cube.

SELECT and WHERE Clauses

In SQL, the SELECT clause is used to define the column layout for a query, and the WHERE clause is used to define the row layout. However, in MDX the SELECT clause can be used to define several axis dimensions, while the WHERE clause is used to restrict multidimensional data to a specific dimension or member.

In SQL, the WHERE clause is used to filter the data returned by a query. In MDX, the WHERE clause is used to provide a slice of the data returned by a query. While the two concepts are similar, they are not equivalent.

The SQL query uses the WHERE clause to contain an arbitrary list of items that should (or should not) be returned in the result set. Although a long list of conditions in the filter can narrow the scope of the data that is retrieved, there is no requirement that the elements in the clause will produce a clear and concise subset of data.

In MDX, however, the concept of a slice means that each member in the WHERE clause identifies a distinct portion of data from a different dimension. Because of the organizational structure of multidimensional data, it is not possible to request a slice for multiple members of the same dimension. Because of this, the WHERE clause in MDX can provide a clear and concise subset of data.

Creating Queries

The process of creating an SQL query is also different from that of creating an MDX query. The creator of an SQL query visualizes and defines the structure of a two-dimensional rowset and writes a query on one or more tables to populate that rowset. In contrast, the creator of an MDX query usually visualizes and defines the structure of a multidimensional dataset and writes a query on a single cube to populate it. This could result in a multidimensional dataset with any number of dimensions; a one-dimensional dataset is possible, for example.

The visualization of an SQL result set is very intuitive; the set is a two-dimensional grid of columns and rows. The visualization of an MDX result set is not necessarily intuitive, however. Because a multidimensional result set can have more than three dimensions, it can be challenging to visualize the structure. To refer to such two-dimensional data in SQL, the name of a column and the unique identification of a row are used to refer to a single cell of data, called a field. However, MDX uses a very specific and uniform syntax to refer to cells of data, whether the data forms a single cell or a group of cells.

Although SQL and MDX share similar syntax, the MDX syntax is remarkably robust, and it can be complex. However, because MDX was designed to provide a simple, effective way of querying multidimensional data, it addresses the conceptual differences between two-dimensional and multidimensional querying in a consistent and easily understood fashion.

Structure of the Basic MDX Query

To specify a dataset, a Multidimensional Expressions (MDX) query must contain the following information:

  • The number of axes (up to 128)
  • The members from each dimension to include on each axis
  • The name of the cube that sets the context
  • The members from a slicer dimension on which data is sliced for members from the axis dimensions

This information can be complex. MDX syntax provides the information in a simple and straightforward manner, using the MDX SELECT statement.

Basic MDX Syntax: SELECT Statement

In MDX, the SELECT statement is used to specify a dataset that contains a subset of multidimensional data. A basic MDX query is structured in the following way:

SELECT [<axis_specification>
       [, <axis_specification>...]]
  FROM [<cube_specification>]
[WHERE [<slicer_specification>]]

The basic MDX SELECT statement contains a SELECT clause and a FROM clause, with an optional WHERE clause. These syntax elements are shown in the following example:

SELECT
   { [Measures].[Unit Sales], [Measures].[Store Sales] } ON COLUMNS,
   { [Time].[1997], [Time].[1998] } ON ROWS
FROM Sales
WHERE ( [Store].[USA].[CA] )

The SELECT clause determines the axis dimensions of an MDX SELECT statement. Two axis dimensions are defined in this MDX query example. The FROM clause determines which multidimensional data source is to be used when extracting data to populate the result set of the MDX SELECT statement.

A WHERE clause optionally determines which dimension or member to use as a slicer dimension; this restricts the extracting of data to a specific dimension or member. The WHERE clause in this example restricts the data extract for the axis dimensions to a specific member of the Store dimension. An MDX SELECT statement supports other optional syntax elements, such as the WITH keyword, and the use of MDX functions to construct members by calculation for inclusion in an axis or slicer dimension.

SQL and MDX

The syntax format of the MDX SELECT statement is similar to that of SQL syntax; however, there are several primary differences:

  • MDX syntax distinguishes sets by surrounding tuples or members with braces (the { and } characters.)
  • MDX queries can have up to 128 axis dimensions in the SELECT statement, but only the first 5 axes have aliases. An axis can be referred to either by its ordinal position within an MDX query, or by its alias if it has been assigned an alias. In the previous example, the COLUMNS and ROWS axis aliases are used. The example query could also have been written in the following way, using the ordinal position of each axis:
  • SELECT
       { [Measures].[Unit Sales], [Measures].[Store Sales] } ON AXIS(0),
       { [Time].[1997], [Time].[1998] } ON AXIS(1)
    FROM Sales
    WHERE ( [Store].[USA].[CA] )
  • As with an SQL query, the FROM clause names the source of the data for the MDX query. However, unlike an SQL query, the FROM clause in an MDX query is restricted to a single cube. Information from other cubes can be retrieved, however, on a value-by-value basis using the LookupCube function.
  • In the MDX query, the WHERE clause describes the slicer dimensions. If a dimension is not mentioned as part of the WHERE clause, Microsoft SQL Server 2000 Analysis Services assumes that any dimension not assigned to an axis dimension is a slicer dimension, and the dimension is filtered on its default members. The WHERE clause can change the filtering process for specified dimensions, allowing fine control of included data.