聊一聊元数据

这个话题来自我的MSN Space。这是原文:

元数据(metadata)这个词现在到处泛滥。其实我对元数据充其量只能说有自己的理解而已,并不能确信这个理解是正确的。

我认为,数据结构分为三个层次(UML可是四层哦):
实例层:直接描述特异化的数据场景;
元数据层:描述实例的结构的一组数据;
元数据的元数据层:描述元数据的结构的一组数据。
元数据就是用来描述实例或者描述元数据的一种结构。
元数据的特征有这样几个:第一是元数据一定不依赖业务反而被业务所依赖,相当业务的多变性,元数据是相对稳定的;第二是元数据具有广泛的可复用性,而业务的可复用性极差;第三是元数据注重结构,而业务注重行为。

在Xml中,元数据就是模式(Schema),在数据库中,元数据就是数据库对象定义,包括表、视图、关系约束、存贮过程、触发器、函数、数据库用户、数据库角色等等定义。在对象空间,元数据就是类型、接口、方法、方法参数、属性的定义。在结构化程序空间,元数据就是函数及函数的参数。

我之所以反复强调参数,是因为我们在定义一个接口或者方法的参数时总是非常随便,但定义一个Xml文档模式或者数据库对象时总是小心翼翼的,很受束缚。这显然有一定的不合理之处。仔细推敲,我的结论就是:第一,我们设计每个方法的参数时,特别是设计每个虚拟方法的参数时一定要小心一点,尽量不要滥用参数重构。第二,我们在设计一个Xml文档结构或者数据库结构的时候可别那么畏首畏尾的,就象平时写程序时设计一个方法的参数那样。这样就平衡了。

总结以往多年的数据库设计,我归纳为两个原则和两个方法:
降冗优先原则(降冗是数据库设计时的首要要素);
平行引用原则(所有的关系都必须是单向的并且不能交叉);
依职责拆分方法(同一基数不同职责或者不同的维护方法或者不同的维护期必须拆分);
依基数合并方法(同一基数且职责相同必须合并)。

忽然发现,其实这些原则和方法在整个元数据层都适用,不仅仅只针对数据库设计。

posted @ 2005-08-18 11:44  双鱼座  阅读(3763)  评论(2编辑  收藏  举报