02年研究dw相关的产品和业务时第一次听说了元数据的概念,很多资料上是这样描述元数据的概念的:元数据是定义或者描述数据的数据。言外之意是先有元数据再有数据。在构建数据仓库前期建模的过程其实就是定义元数据的过程。如果说oltp的产生是源于业务驱动的,那么olap的产生完全是由数据驱动最终为业务服务的,他们其实最后是一个圆周,根本就没有终点,所以搞信息化,db和dw是没有尽头的,我觉得是一个闭环:)闲言少叙,下面看看oracle中数据和元数据的概念,oracle中其实把数据和元数据分的非常清楚,只是没有明确的用这2个概念界定出来,在11.2版本中参数deferred_segment_creation的出现更是把元数据和数据分的非常清楚了。
--===============================
C:>sqlplus test/test
SQL*Plus: Release 11.2.0.1.0 Production on 星期日 7月 29 19:08:15 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning option
SQL> show parameter def
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
deferred_segment_creation boolean TRUE
SQL> create table t(id int ,name varchar2(10)) tablespace users;
表已创建。
SQL> select object_id,data_object_id from dba_objects where owner='TEST' and object_name='T';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
21030 21030
SQL> select count(*) from dba_segments where owner='TEST' and segment_name='T';
COUNT(*)
----------
0
--create table之后发现数据段并不存在,这就是deferred_segment_creation的作用,段被延迟创建了,正常都是在插入数据时创建的,这里发现move之后段也随即被创建了,其实表里这时候还是没有数据的,之所以move一下,主要是我观查到dba_objects中段的id在创建表的时侯已经分配好了,而并没有在创建段的时侯再分配,所以在段不存在的时侯move一下我是想验证move之后data_object_id是否会发生变化,结果是move之后data_object_id确实和段存在的情况下move的结果一样,发生了变化。
SQL> alter table t move;
表已更改。
SQL> select object_id,data_object_id from dba_objects where owner='TEST' and object_name='T';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
21030 21031
SQL> select count(*) from dba_segments where owner='TEST' and segment_name='T';
COUNT(*)
----------
1
SQL>
--=================================
这里大家注意create table...定义的就是元数据,元数据是存放着system表空间里的,数据是保存在我们create table时指定的表空间users里,另外我们是否可以这样认为dba_objects里面的object_id是元数据的id,而data_object_id是数据段的id这个倒是不用怀疑。
下面简单举个例子来帮助我们理解数据和元数据:
--=================================
SQL> insert into t values(1,'a');
已创建 1 行。
SQL> insert into t values(2,'b');
已创建 1 行。
SQL> commit;
提交完成。
SQL> select * from t;
ID NAME
---------- ----------
1 a
2 b
SQL> alter tablespace users offline;
表空间已更改。
SQL> select * from t;
select * from t
*
第 1 行出现错误:
ORA-00376: 此时无法读取文件 4
ORA-01110: 数据文件 4: 'E:ORACLEORADATATESTUSERS01.DBF'
SQL> drop table t;
表已删除。
SQL>
--================================
这里清楚的看到tablespace users被offline之后,不能查询t表里面的数据,但是缺可以drop table t,原因就是drop table的时侯oracle只是删除了t的元数据,而并不会去修改表里的数据。
--================================
有关锁的情况也是一样的,用户在修改一条数据的时侯会在表上同时加上tx和tm锁,其中tm锁锁定的就是元数据,tx锁定的是数据,要想锁定数据首先要锁定元数据。防止在修改数据的时侯其它session把元数据修改了。可见在oracle里把数据和元数据的概念也是体现的淋漓尽致。E.F.CODE在提出RDBMS理论的时侯不知道是否已对这2个概念了然于胸,在他提出olap概念的时侯不知道他老人家是否对oracle熟悉,但是我们真的很敬佩这位2次获得图灵奖的关系型数据库的鼻祖是根据什么理论能够提出这么精髓的概念。我们也不知道oracle的设计者又是参照什么理论能在olap概念之前就把元数据和数据运用的如此之精妙。
真是让人震撼。