了解Oracle物化视图

ALLSTARS_ORACLE

了解Oracle物化视图

概要管理的必要性
可以使用许多广为人知的技术来提高查询性能。例如，可以创建附加索引，或者对数据进行分区。
许多数据仓库还使用概要。创建概要的基本过程如下：预先计算长时间运行的查询的结果并将此结果存储在称为概要表的数据库表中；这可与 CREATE TABLE AS SELECT (CTAS) 语句相媲美。用户可以直接访问概要表，无需多次预先计算同一查询结果。虽然此方法具有缩短查询响应时间的优点，但也有很多缺点。用户需要知晓概要表确已存在后，才能重写查询以改用该表。此外，概要表中包含的数据是“冻结”的，必须在实际的表发生修改后手动进行刷新。
利用 Oracle DB 的概要管理，最终用户不再需要了解概要表是否确已定义。而是由数据库管理员 (DBA) 创建实体化视图，然后系统在重写 SQL 查询时自动使用。与手动创建概要表相比，使用实体化视图还具有另外一个优点，即数据可以自动刷新。


使用概要提高性能
概要是为了缩短查询执行时间而创建的聚集视图。使用概要时，将在执行查询之前计算联接和聚集操作的结果并将结果存储到数据库表。在 Oracle DB 中，使用实体化视图实施概要。
可以使用许多广为人知的技术来提高查询性能。例如，可以创建附加索引，或者对数据进行分区。
注：术语“概要”源于以下事实：数据仓库环境中的用户大多数时候需要计算开销巨大的联接和聚集。使用 Oracle DB 中的实体化视图创建概要后，无需使用联接或聚集。


概要管理
概要管理是数据仓库实施中最重要的考虑因素之一。如果使用得当，它可以显著缩短查询响应时间，只需几秒（而不是几小时）即可完成查询。管理概要是使数据库仓库实施具有良好性能的关键所在。
概要（即聚集）是存储事实表和维表中数据的预聚集和预联接结果的表。聚集存储计算结果，如总和、计数和平均值。概要表（物理设计的扩展）在数据仓库的设计中非常重要，原因如下：
通过提供缩短分析查询响应时间，改进最终用户服务
改进和优化资源、存储和 CPU 使用
增强分析过程，可以从较高的明细级别细化，以及从较低的明细级别汇集
实施概要
在概要管理过程中，通常先确定描述业务关系的维和层次以及数据库中的常见查询模式。
定义概要的必要性通常源自降低成本和提高性能这一最重要的需求。由于细粒度数据的存储需求（在五到十年间保持代数级增长）导致成本不断增加，因此必须实现某一形式的容量规划。而且使用聚集更容易实现可伸缩性。



概要导航
在开发了概要表后，现在面临的挑战是如何正确使用这些表。所用的工具或查询机制必须可识别概要表。也就是说，查询必须了解概要表确已存在。
概要（聚集）导航器：概要导航器是一个软件组件，用于截取最终用户的 SQL 并对其进行转换，以便使用最佳的可用概要（通常是可答复用户请求的最小可用表）。概要导航器维护特殊的元数据，这些元数据描述存储在数据仓库中的概要表的当前概要文件。此外，它还将维护查询的统计信息，这些统计信息显示正在使用哪些聚集以及为加快运行慢的查询应构建哪些聚集。
概要导航方法：概要导航器可位于：
数据仓库数据库引擎。这是最佳方案，因为这种方法使概要重定向（或查询重写）可供所有应用程序访问。例如，Oracle DB 包含自己的内置概要导航器
最终用户查询工具。近几年来，这种方法最为普及，这主要是因为实际上很少有数据库引擎包含自己的导航器。但是，这种方法要求所有查询工具维护自己的概要导航工具和元数据层。例如，Oracle 提供的即席查询工具 OracleBI Discoverer 就具有这种创建和管理概要的能力
可简化概要表导航的中间件工具（早期系统）
使用 3GL 代码和元数据的、定制的概要导航技术（早期系统）




管理数据仓库中的历史概要数据
制定一个策略来管理数据仓库中的概要表是设计的另一个主要考虑因素。由于数据使用情况是确定应创建哪些概要的最重要因素，因此无法立即确定此策略。
在数据仓库内应用的概要不一定要保持一致。例如，相比较早的数据，近期数据可能需要较高的详细程度。因此，可能会保存最近十二个月的每日数据以及汇总的每月数据。较早的数据可能会按月、季度或年进行汇总。


使用 Oracle DB 进行概要管理
实体化视图
Oracle 数据仓库使用实体化视图来存储概要数据。（在 Oracle 8i DB 中引入了实体化视图。）对数据仓库中大型数据库的查询通常涉及表之间的联接和/或聚集，如 SUM。实体化视图可提高查询性能，因为它在执行查询之前会预先计算开销巨大的联接和聚集操作并将结果存储到数据库。查询优化程序会自动识别何时可以及何时应该使用现有实体化视图来满足请求（查询）。然后，以透明方式重写请求以使用实体化视图。可以使用 CREATE MATERIALIZED VIEW SQL 语句创建实体化视图。


Oracle DB 提供了许多可简化概要管理的功能。例如，已向 DBMS_MVIEW 中添加了 EXPLAIN_MVIEW 过程，以便分析实体化视图。Oracle Database 11g 包含一些过程，如已添加到 DBMS_OLAP 程序包的 GENERATE_MVIEW_REPORT（用于生成包含 Summary Advisor 所提供建议的 HTML 报表）和 GENERATE_MVIEW_SCRIPT（用于根据建议生成需要使用的 SQL 语句）。同样，DBMS_ADVISOR 也包含一些用于管理工作量和其它任务的过程，如 CREATE_SQLWKLD、IMPORT_SQLWKLD_SCHEMA、DELETE_SQLWKLD 等。
注：在 Oracle DB 中引入概要管理之前，管理员不得不花大量的时间和精力来手动创建概要表、确定要创建的概要表、为概要表编制索引、对概要表进行更新并向用户建议要使用的概要表。在 Oracle DB 中引入的概要管理可减轻管理员的工作量；而 Oracle9i 和 Oracle 11g 数据库会进一步简化这一过程。



使用实体化视图进行概要管理
概要管理的一种典型方法是由数据库管理员创建实体化视图。在最终用户查询表和视图时，Oracle 服务器的“查询重写机制”会自动重写 SQL 查询以使用实体化视图。实体化视图的使用对于查询数据的最终用户或应用程序来说是透明的。
注：本课稍后将介绍查询重写。  
创建实体化视图的准则
创建可满足最大数量查询的实体化视图。例如，如果确定对从表或事实表应用的查询通常有 20 个，则使用五六个明确定义的实体化视图就可以满足要求。实体化视图定义可以包含任意数量的聚集（SUM、COUNT(x)、COUNT(*)、COUNT(DISTINCT x)、AVG、VARIANCE、STDDEV、MIN 和 MAX）。还可以包含任意数量的联接。
定义包括所有度量的单一实体化视图，而不要基于相同的表定义多个 GROUP BY 列相同而度量不同的实体化视图。
使用聚集度量 AVG(x) 时，包括 COUNT(x) 以支持增量刷新。同样，如果存在 VARIANCE(x) 或 STDDEV(x)，则始终应包括 COUNT(x) 和 SUM(x) 以支持增量刷新。


在不使用实体化视图的情况下使用概要：示例
在 Oracle DB 中引入实体化视图之前，使用概要的组织需要花大量的时间来手动创建概要。此外，还需要确定要创建的概要、为概要编制索引、对概要进行更新并向用户建议要使用的概要。
在本幻灯片示例中，DBA 创建一个名为 CUST_SALES_SUM 的概要表以提高初始查询的性能。DBA 向用户告知概要表已存在，然后用户查询该概要表，而不执行原始查询。
与原始 SQL 查询相比，使用概要表执行 SQL 查询所需的时间最少。
但是，必须让用户了解概要表确已存在，并且用户需要重写应用程序才能使用概要表。
此外，DBA 必须手动刷新概要表，使其与对应的原始表保持同步。


使用实体化视图进行概要管理：示例
Oracle DB 中的概要管理减轻了数据库管理员的工作量，并且最终用户无需了解概要是否确已定义。数据库管理员创建一个或多个等同于概要表的实体化视图。使用实体化视图来代替 CREATE TABLES AS SELECT (CTAS) 的优点在于，实体化视图不仅将查询结果实体化到数据库表中，而且还生成查询重写引擎所使用的元数据信息以自动重写 SQL 查询，从而使用概要表。数据仓库中的实体化视图对于最终用户和数据库应用程序而言是透明的。此外，实体化视图还提供了自动刷新数据的可能性。
在本幻灯片示例中，用户可以在 DBA 创建名为 CUST_SALES_MV 的实体化视图后执行原始查询。只要用户或应用程序执行 SQL 查询，Oracle DB 就会以透明方式重写查询以使用实体化视图。
查询响应时间与 CTAS 方法的相同，但无需重写应用程序。重写阶段由系统自动处理。此外，定义实体化视图的 SQL 语句并不一定要与查询本身的 SQL 语句一致。



确定要创建的实体化视图
您已了解查询重写可以使用同一实体化视图满足不同的查询。反之，不同的实体化视图可以满足一个特定的查询。给定一组查询时，可能很难确定要创建的最佳实体化视图。作为 DBA，必须在查询性能和存储实体化视图所用的磁盘空间之间找到平衡。
可以使用 SQL 访问指导为给定工作量确定一套适当的实体化视图、实体化视图日志和索引。
此外，还可以使用 DBMS_MVIEW.EXPLAIN_REWRITE 过程了解有关在解析 SQL 查询时使用或忽略了哪些视图的更多信息。
注：有关其它类型的实体化视图的信息，请参加由教师引导的培训课程“Oracle Database 11g：管理数据仓库”，或参阅《Data Warehousing Guide》。

使用 CREATE SQL 语句创建实体化视图：示例

CREATE MATERIALIZED VIEW cust_sales_mv  -- Name
  PCTFREE 0  TABLESPACE example    -- Storage options  STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0)
  BUILD DEFERRED       –- When to build it
  REFRESH COMPLETE     –- How to refresh the data
  ENABLE QUERY REWRITE –- Use this for query rewrite
  AS SELECT c.cust_id，s.channel_id，  –- Detail query
            SUM(amount_sold)  
     FROM   sales s，customers c       –- Detail tables
     WHERE  s.cust_id = c.cust_id
     GROUP BY c.cust_id，s.channel_id  –- MV keys
     ORDER BY c.cust_id，s.channel_id;

         
         

使用 CREATE SQL 语句创建实体化视图：示例
有关 CREATE MATERIALIZED VIEW 语句的完整说明，请参阅《Oracle Database SQL Reference Guide》。
除非实体化视图基于用户定义的预建表，否则它将需要和占用数据库中的存储空间。
虽然默认情况下对整个数据库都启用了查询重写，但如果要使实体化视图可用于重写查询，则必须指定 ENABLE QUERY REWRITE 子句。可在以后使用 ALTER MATERIALIZED VIEW 语句变更此设置。请注意，只有实体化视图中所有用户定义的 PL/SQL 函数均为 DETERMINISTIC 时，才可以启用查询重写。
可以在 CREATE MATERIALIZED VIEW 语句中指定 ORDER BY 子句。该子句仅用在实体化视图的初始创建过程中，不被视为实体化视图定义的一部分。按指定顺序来存储行可能有助于提高查询性能，因为这为数据提供了物理聚类，而这在使用索引时非常有用。


创建实体化视图时的可用刷新模式
可以指定以下刷新执行模式：
ON DEMAND（默认设置）：在用户需要时使用 DBMS_MVIEW 程序包进行刷新。此程序包提供多个用于管理实体化视图的过程和函数，其中包括 REFRESH、REFRESH_DEPENDENT 和 REFRESH_ALL_MVIEWS 过程。
ON COMMIT：在修改实体化视图 (MV) 的某一从表的事务处理提交时自动执行刷新。只要实体化视图可快速刷新，就可指定此模式。使用此模式时需要具有 ON COMMIT 权限。如果未能在提交时刷新实体化视图，则用户必须先解决跟踪文件中指定的错误，然后使用 DBMS_MVIEW 程序包明确调用刷新过程。在完成此操作之前，将不再在提交时自动刷新该视图。由于必须用所做的更改来更新实体化视图，因此完成提交的时间将稍长一些。
NEVER：NEVER 刷新机制禁止使用任何 Oracle DB 刷新机制或过程来刷新实体化视图。
注：有关刷新实体化视图的可用方法的其它信息，请参阅《Oracle Database Data Warehousing Guide 11g Release 1 (11.1)》。



使用 DBMS_MVIEW 程序包过程的手动刷新
通过指定 ON DEMAND 刷新，可以控制执行实体化视图刷新的时间。在这种情况下，只能通过调用 DBMS_MVIEW 程序包中的某一过程来刷新实体化视图：
DBMS_MVIEW.REFRESH：刷新一个或多个实体化视图。
DBMS_MVIEW.REFRESH_ALL_MVIEWS：刷新所有实体化视图。
DBMS_MVIEW.REFRESH_DEPENDENT：刷新所有基于表的实体化视图，这些视图依赖于指定的从表或从表列表。
可以使用作业队列来并行刷新多个实体化视图。如果队列不可用，则快速刷新将通过前台进程按顺序刷新每个视图。这无法保证实体化视图的刷新顺序。要使队列可用，必须将 JOB_QUEUE_PROCESSES 参数设置为等于大于 1 的值。此参数定义后台作业队列进程数 (Jnnn)，并确定可同时刷新的实体化视图数。仅当将 DBMS_MVIEW 过程的 atomic_refresh 参数设置为 FALSE 时，此参数有效。在后面几页中将提供其它信息。
注：如果执行 DBMS_MVIEW.REFRESH 的进程中断，或者实例关闭，则在作业队列进程中执行的所有刷新作业都将重新入队并继续运行。要删除这些作业，请使用 DBMS_JOB.REMOVE 过程。



使用 DBMS_MVIEW 程序包：可用的 ON DEMAND 刷新方法
定义实体化视图时，可以通过选择以下选项之一来指定如何按从表刷新实体化视图：
COMPLETE：COMPLETE 刷新机制可删除或截断实体化视图，然后根据从表重新执行实体化视图查询以重新计算内容。
FAST：此选项以增量方式添加已插入或更新到表中的新数据来执行刷新。从以下日志中获取新数据：
直接路径日志：直接路径加载通过在 ALL_SUMDELTA 视图中记录已加载数据的行 ID 范围来支持实体化视图。刷新使用此视图来“了解”已添加到从表中的内容，而使用行 ID 可以加快刷新。在加载后必须立即执行手动刷新才能避免日志内容失效。
注：
有关 DBMS_MVIEW 程序包的其它信息，请参阅《Oracle Database PL/SQL Packages and Types Reference 11g Release 1 (11.1)》。
有关刷新选项的其它信息，请参阅《Oracle Database SQL Language Reference 11g Release 1 (11.1)》。


基于主表创建的实体化视图日志：此日志是由 CREATE MATERIALIZED VIEW LOG 命令创建的表。对主表数据进行数据操纵语言 (DML) 更改后，Oracle 服务器会将描述这些更改的行存储到实体化视图日志中，然后使用该日志刷新基于该主表的实体化视图。如果为实体化视图指定 REFRESH FAST，则必须已为基础表创建了实体化视图日志，否则该命令将失败。
分区更改跟踪 (PCT) 刷新：在已分区的从表上执行了分区维护操作时，Oracle 服务器会使用一种名为“分区更改跟踪”的专用快速刷新方式。该刷新方式会自动确定实体化视图的陈旧部分，并重新计算陈旧行，而无需刷新整个实体化视图。
FORCE：如果可能，此机制将应用 FAST 刷新；否则将应用 COMPLETE 刷新。
ALWAYS：此机制强制执行完全刷新。它等同于完全刷新。

按调度时间执行刷新：使用 START WITH 和 NEXT 子句

CREATE MATERIALIZED VIEW emp_data  
   PCTFREE 5
   TABLESPACE example  
   STORAGE (INITIAL 50K NEXT 50K)
   REFRESH FAST NEXT sysdate + 7  
   AS SELECT . . .;  

   
CREATE MATERIALIZED VIEW all_customers
   . . .
   USING INDEX STORAGE (INITIAL 25K NEXT 25K)
   REFRESH START WITH ROUND(SYSDATE + 1) + 11/24  
   NEXT NEXT_DAY(TRUNC(SYSDATE)，'MONDAY') + 15/24  
   AS SELECT * FROM sh.customers@remote  
         UNION
      SELECT * FROM sh.customers@local;  

          

按调度时间执行刷新：使用 START WITH 和 NEXT 子句
可以创建按调度时间刷新的 MV。例如，通过使用 START WITH 和 NEXT 子句，可以在每周一上午 9:00 点执行此刷新操作。要执行此类刷新，实例必须使用 JOB_QUEUE_PROCESSES 参数启动作业进程。如果指定 ON COMMIT 或 ON DEMAND，则无法同时指定 START WITH 或 NEXT。
本幻灯片中的第一个示例创建主键实体化视图 emp_data 并用 hr.employees 示例表的数据填充该视图。语句中不包括 START WITH 参数，因此 Oracle DB 使用当前 SYSDATE 计算 NEXT 值，进而确定首次自动刷新的时间。已为雇员表创建了实体化视图日志，因此 Oracle DB 会从创建实体化视图的七天后开始，每七天对实体化视图执行一次快速刷新。由于实体化视图符合快速刷新的条件，因此数据库会执行快速刷新。
第二个示例阐释如何指示 Oracle DB 在第二天上午 11:00 点自动刷新实体化视图，并在以后的每周一下午 3:00 点执行刷新。


查询重写概览
当基表包含大量数据时，计算必需的聚集或计算这些表之间的联接不仅开销巨大而且非常费时。在这样的情况下，查询可能需要数分钟甚至数小时。由于实体化视图已经包含了预先计算过的聚集和联接，因此 Oracle DB 采用了功能非常强大的名为查询重写的过程，以使用实体化视图快速响应查询。
创建并维护实体化视图的一个主要优点在于：可以利用查询重写将以表或视图表述的 SQL 语句转换为访问基于从表定义的一个或多个实体化视图的语句。这种转换过程对于最终用户或应用程序来说是透明的，不需要用户的任何干涉，也不需要在 SQL 语句中引用任何实体化视图。因为查询重写是透明的，所以可以像索引那样添加或删除实体化视图，而不会导致应用程序代码中的 SQL 变得无效。查询会执行几次检查来确定是否可以对其进行查询重写。如果查询在执行任意检查时失败，则将对从表而不是实体化视图应用该查询。这会导致响应时间过长和大量增加处理负担。
优化程序使用两种不同方法来识别何时以实体化视图来重写查询。第一种方法是，将查询的 SQL 文本与实体化视图定义的 SQL 文本进行匹配。如果第一种方法失败，优化程序将使用更通用的方法，对查询和实体化视图的联接、选择、数据列、分组列和聚集函数进行比较。



基于成本的查询重写过程
只有基于成本的优化程序能够使用查询重写。Oracle 使用重写和不使用重写对输入查询     进行优化，然后选择成本最低的一种方案。优化程序通过一次重写一个或多个查询块来重写查询。
如果重写逻辑在重写查询块时可以在多个实体化视图间进行选择，它将选择读取数据量最小的一种方案。
在选择了用于重写的实体化视图后，优化程序执行重写，然后测试重写的查询是否可以利用其它实体化视图进一步重写（只有在存在嵌套实体化视图的情况下才会出现此情况）。此过程会持续进行，直到无法再执行进一步的重写。会尝试以递归方式进行查询重写，以利用嵌套的实体化视图。


Oracle 重写查询所需的条件
只有在满足一定数量的条件时才会重写查询：
必须已为会话启用了查询重写。
必须启用实体化视图供查询重写使用。
重写完整性级别应该允许使用实体化视图。例如，如果实体化视图不是最新的，而且查询重写完整性设置为 ENFORCED，则不会使用实体化视图。
查询请求的所有结果或部分结果必须可以从存储在一个或多个实体化视图中的、预先计算的结果中获得。
运行查询的用户必须具有查询重写权限。
查询请求的所有结果或部分结果必须可以从存储在实体化视图中的、预先计算的结果中获得。要确定这一点，优化程序可能需要依赖用户使用约束条件和维声明的一些数据关系。这类数据关系包括层次、引用完整性、键数据的唯一性等。




查询重写

SELECT c.cust_id, s.channel_id,SUM(amount_sold)  
       AS amount  
FROM   sales s, customers c
WHERE  s.cust_id = c.cust_id
GROUP BY c.cust_id, s.channel_id


OPERATION              NAME
---------------------- -----------------
SELECT STATEMENT      
MAT_VIEW REWRITE ACCESS FULL    cust_sales_mv  



查询重写
访问实体化视图会明显快于访问底层基表，因此基于成本的优化程序将在查询允许的情况下重写查询来访问视图。查询重写是实体化视图实现的主要优点。
查询重写活动对应用程序透明。在这方面，它的用法类似于使用索引。
用户无需对实体化视图具有明确权限即可使用视图。具有基础表访问权限的任意用户所执行的查询都可以通过重写来访问实体化视图。
可以启用或禁用实体化视图。启用的实体化视图可供查询重写使用。
示例
在本幻灯片示例中，优化程序能够执行查询重写，并且使用以前创建的概要而非基表来满足查询。


什么是维
维是一种结构，用来将数据分类以使用户能够回答业务问题。常用的维是 CUSTOMERS、PRODUCTS 和 TIME。例如，服饰零售商的每个销售渠道可以收集和存储其各类服饰的销售和退货情况。零售连锁管理人员可以构建一个数据仓库来分析一段时间内其产品在所有店铺中的销售情况，并帮助回答本幻灯片中提出的问题。
零售商的数据仓库系统中的数据有两个重要组成部分：维和事实。维包括 PRODUCTS、CUSTOMERS、PROMOTIONS、CHANNELS 和 TIME。可以通过查看引用表（如包含有关产品信息的产品表，或包含有关促销信息的促销表）来确定维。事实是销售额（售出数量）和利润。数据仓库包含有关每种产品每天销售额的事实。
此类数据仓库的典型关系实施为星形方案。事实信息存储在事实表中，而维信息存储在维表中。在此处的示例中，每个销售事务处理记录由每个客户、产品、销售渠道、促销和每天（时间）唯一定义。



什么是维对象
维对象定义成对列集之间的层次（父/子）关系，其中列集包含的所有列必须来自同一个表。维是在 Oracle 服务器中定义的引用完整性约束条件的超集。维可以是规范化维，也可以是非规范化维。在规范化维中，在多个维表之间定义关系。在非规范化维中，在同一个维表中定义所有的关系。规范化维在全局等同于主键（非空值）与外键之间的关系。对于非规范化维，建立的关系针对于同一个表的列集，并确定任何子端列值是否具有相应的父端列值。
维比传统的引用完整性约束条件更常用，因为可以在多列和多列之间定义关系，也可以在具有不同数据类型的两列之间定义关系。维和约束条件之间的另一个差别是：维从来不强制执行，而约束条件强制执行。
此外，数据库对象维有助于将维信息组织和划分到层次中。这表示列或列组（层次的级别）之间天然存在的一对多关系，而这无法使用约束条件加以表示。在层次中向上移动一个级别称为累计数据，在层次中向下移动一个级别称为细化数据。



维为什么重要
可以在维中基于表的现有列定义零个或多个层次。维是根据现有数据库表中的列定义层次的数据字典结构。出于以下原因会创建尽可能多的层次：
维允许进行不使用约束条件的其它重写。由于性能原因，在数据仓库中实施约束条件可能不太有利。
维有助于明确说明维和层次。
维可以由联机分析处理 (OLAP) 工具使用。
如果应用程序使用维建模，则可以创建维，因为维有助于查询重写执行更复杂的重写类型。
维也有利于执行特定类型的实体化视图刷新操作而且可以与 SQL 访问指导结合使用。


维和层次
维：维以分层、分类方式描述分析性业务实体，如产品、部门和时间。维可以包含一个或多个层次。在所示示例中，TIME 维包含一个日历层次。
层次：一个层次包含多个级别。层次中较低级别的各个值是下一个较高级别中的父级的子级，而且有且仅有一个父级。层次包含级别之间的一对多关系，父级别表示子级别的聚集级别。在本示例中，日历层次包含销售日期、月、季度和年。箭头指示遍历层次的方向是累计一个级别中的数据来获取下一级别的聚集信息。例如，累计每日数据将得到每月数据，累计每月数据将得到每季度数据，依此类推。
级别关键字和属性：级别关键字用于标识层次中的级别。代理关键字用于在维设计阶段标识层次元素，以进一步利用级别关键字提供的性能优势。
一个级别可能会有根据级别关键字确定的其它属性。属性可用作级别的别名。
在本示例中，Month_Key（定义为两位数字）是用于标识月的级别关键字，Month_Desc 是可用作月别名的属性。


维示例
维以及在维之间建立的层次关系，可以基于单个表中的列（采用规范化方案或雪花方案时还可基于多个表中的列）。
在本示例中，TIME_DIM 维基于 Time 表，具有四个级别：
层次中的最高级别是 YEAR_KEY 列。
下一级别派生自 QUARTER_KEY 列。
第三级别将 MONTH_DESC 列作为级别关键字，并将 MONTH_KEY 作为属性。
最低级别基于 SALES_DATE 列。


定义维和层次
在用户自己的方案中基于其方案内的表创建维需要系统权限 CREATE DIMENSION。另一个新权限 CREATE ANY DIMENSION 允许用户在任意方案中创建维。在所示示例中，TIME_DIM 维基于 Time 表。


具有多个层次的维
上例显示的 TIME 维只有一个层次，但它可以有多个层次。例如，可以在单个维中创建本幻灯片中显示的层次对。执行此操作的语句如下：
CREATE DIMENSION time_dim
LEVEL dt IS time.sales_date
  LEVEL wk IS time.week_key
  LEVEL mon IS time.month_key
  LEVEL qtr IS time.quarter_key
  LEVEL yr IS time.year_key
HIERARCHY cal (
  dt CHILD OF
  mon CHILD OF
  qtr CHILD OF yr)
HIERARCHY week (
  dt CHILD OF
  wk child of yr);


  
  

DB_BLOCK

看了半天没看懂。