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

推荐订阅源

cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
L
LINUX DO - 最新话题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Forbes - Security
Forbes - Security
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
W
WeLiveSecurity
Jina AI
Jina AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
N
News and Events Feed by Topic
V
V2EX
Stack Overflow Blog
Stack Overflow Blog
Engineering at Meta
Engineering at Meta
PCI Perspectives
PCI Perspectives
Martin Fowler
Martin Fowler
T
The Exploit Database - CXSecurity.com
F
Full Disclosure
WordPress大学
WordPress大学
S
Security Affairs
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
S
SegmentFault 最新的问题
P
Privacy International News Feed
IT之家
IT之家
M
MIT News - Artificial intelligence
G
GRAHAM CLULEY
Hacker News: Ask HN
Hacker News: Ask HN
D
DataBreaches.Net
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google Online Security Blog
Google Online Security Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
C
Check Point Blog
美团技术团队
Security Latest
Security Latest
Cyberwarzone
Cyberwarzone
N
News and Events Feed by Topic
MyScale Blog
MyScale Blog
H
Help Net Security
宝玉的分享
宝玉的分享
The Hacker News
The Hacker News
The Last Watchdog
The Last Watchdog
The Cloudflare Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
爱范儿
爱范儿
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
I
Intezer
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
AI
AI
I
InfoQ
N
News | PayPal Newsroom
TaoSecurity Blog
TaoSecurity Blog

博客园 - 经霄

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.