这个话题来自我的MSN Space。这是原文：
元数据(metadata)这个词现在到处泛滥。其实我对元数据充其量只能说有自己的理解而已，并不能确信这个理解是正确的。
我认为，数据结构分为三个层次(UML可是四层哦)：
实例层：直接描述特异化的数据场景；
元数据层：描述实例的结构的一组数据；
元数据的元数据层：描述元数据的结构的一组数据。
元数据就是用来描述实例或者描述元数据的一种结构。
元数据的特征有这样几个：第一是元数据一定不依赖业务反而被业务所依赖，相当业务的多变性，元数据是相对稳定的；第二是元数据具有广泛的可复用性，而业务的可复用性极差；第三是元数据注重结构，而业务注重行为。
在Xml中，元数据就是模式(Schema)，在数据库中，元数据就是数据库对象定义，包括表、视图、关系约束、存贮过程、触发器、函数、数据库用户、数据库角色等等定义。在对象空间，元数据就是类型、接口、方法、方法参数、属性的定义。在结构化程序空间，元数据就是函数及函数的参数。
我之所以反复强调参数，是因为我们在定义一个接口或者方法的参数时总是非常随便，但定义一个Xml文档模式或者数据库对象时总是小心翼翼的，很受束缚。这显然有一定的不合理之处。仔细推敲，我的结论就是：第一，我们设计每个方法的参数时，特别是设计每个虚拟方法的参数时一定要小心一点，尽量不要滥用参数重构。第二，我们在设计一个Xml文档结构或者数据库结构的时候可别那么畏首畏尾的，就象平时写程序时设计一个方法的参数那样。这样就平衡了。
总结以往多年的数据库设计，我归纳为两个原则和两个方法：
降冗优先原则(降冗是数据库设计时的首要要素)；
平行引用原则(所有的关系都必须是单向的并且不能交叉)；
依职责拆分方法(同一基数不同职责或者不同的维护方法或者不同的维护期必须拆分)；
依基数合并方法(同一基数且职责相同必须合并)。
忽然发现，其实这些原则和方法在整个元数据层都适用，不仅仅只针对数据库设计。