民俗数据库设计：物理结构与逻辑结构相分离的例子

民俗数据库设计：物理结构与逻辑结构相分离的例子

在民俗数据库的设计中，应该做到物理结构与逻辑结构相分离，先实施前者，在前者基础上再实施后者。这里以民间宫庙的普查登记为例。

假设要普查登记一个地域内的民间宫庙，并建设宫庙数据库，出品宫庙名录。现实问题是，宫庙虽然在一定时限内有稳定性，但长期来看是变化的：会有新的宫庙建造出来，会有老的宫庙废弃破败。更要考虑到，性质、规模、名称也都可能发生变化，比如新请进了几位神，加盖了一座侧殿之类的。所以这个“宫庙数据库”也好，“宫庙名录”也好，不可能像某一时刻拍了一张全家福一样，而是动态去巡礼、记录的。

在实际调查中，人们很难做到定期对宫庙作全盘普查或复查，只能靠平时零星的探访或小规模的调查行动；因为宫庙的情况可能发生变化，所以对同一个宫庙也可能定期或不定期多次复查到。

所以要建设数据库，首先是关注“宫庙调查”这件事的“物理结构”，也就是顺次记录每一次宫庙探访，何年何月何日，谁谁谁调查了哪座庙，相关资料附上。这样形成一本流水账。我们不妨称为“流水库”。在流水库的基础上，我们可以加以分析，比如一共收录了哪些庙，对某座庙都在什么时候进行过调查，把历次探访到的情况综合起来。这就是基于流水库(物理结构)，进一步进行的逻辑分析，形成了宫庙调查的逻辑结构，不妨称为“正册库”。正册库是从流水库中，以宫庙出发提取汇集了各种信息而形成的。

从正册库中就可以方便地导出许多东西。首先想到的就是宫庙名录。也可以针对某次考察活动，直接出具考察报告；甚至可以针对具体的调查人，出具TA的宫庙考察名录；也可以针对某座宫庙，给出所有调查过该庙的人员名单。还可以搞更复杂的分析，说起来就无法无天了，这里不作展开。只要数据完备，你可以分析任何话题，只要是已有的数据能够支持的。比如你可以知道，在星期六探访过道教宫庙最多的人是谁，哪座有三进院落的佛教庙宇在工作日被大学生调查员造访得最少。如此种种，尽情去想。

但如果我们一上来就考虑逻辑结构，直接以宫庙为对象设计数据库，就面临着要把历次调查的结果塞进宫庙条目下，会有损于数据原貌，还丢失很多变迁信息。这种方式就很死板，因为宫庙下面某项属性只能填一个结果，不能容纳更多，就会把其余信息排挤出数据库。

比如要调查宫庙门前有几棵树，如果以宫庙角度出发来设计，可能只留了“树木棵数：__”，只能填写一个数，无法反映变化信息。要么就往里写一大串：“2014年6月有3棵，2016年2月砍了一棵，17年八月栽了4棵”，很不利于分析。但如果先建立流水库，就可以直接去流水库里检索该庙的历次调查数据，看看历次调查时树木都是几棵。这个思路就很顺畅，符合数据本来存在的样子。

我们做研究，本来就是从真实的大千世界出发，记录、归纳、分析。那么反映在数据上，也同样是先忠实地记录数据本来的自然存在的样子，然后再检索筛选，归纳分析。

顺便一说，把原来杂糅在一起的东西相分离，是一种成功有效的趋势。以前的网页，内容和样式杂糅在一起，非常不便于维护。后来把样式单独分离出去，成为CSS(层叠样式表)，就可以分别控制网页的样式和内容。这是网页技术的一次伟大突破。同理，如果在设计数据库时做到物理结构和逻辑结构相分离，也会让我们利用数据库的思路回归本原，轻装上阵，更容易把握客观存在，找出内在规律。

羊牧东岭

2018.11.3 - 4