基于关系数据库的汉字构形分析及其应用，本文主要内容关键词为：汉字论文,及其应用论文,关系论文,数据库论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
一 引言 随着计算机技术的发展，数据库技术已经广泛应用到各个领域。建立汉字数据库，对于汉字本体研究和各种相关研究都有着重要的意义。一个汉字数据库，应当能够全面、准确地描述出汉字的各种信息，实现从不同角度对汉字进行快捷的检索和分类，从而为汉字本体研究与各相关领域的研究和应用提供便利。要实现这个目标，数据库的设计是关键。对于汉字数据库而言，数据库设计首先应当以汉字结构理论为基础，但是由于数据库理论和汉字理论属于两个不同的领域，简单地将一种现成的汉字结构理论搬到数据库设计中并不能很好地解决问题，因此有必要探索一种适于数据库处理的汉字结构分析模式。本文以目前应用最为广泛的关系数据库为平台，结合汉字构形学理论，尝试建立一种适于关系数据库处理的汉字构形分析模式。 二 实体联系模型和关系模型 使用计算机来处理现实世界的各种信息，需要用数据模型将对象描述出来。这个过程一般需要经过两级抽象：第一级抽象是人脑对现实世界的初步抽象，得到的是概念数据模型；第二级抽象是将概念数据模型转换为计算机能够处理的逻辑模型，即结构数据模型。 （一）实体联系模型的基本概念 常用的概念数据模型是陈品山（Chen，1976提出的实体联系模型（Entity-Relationship Model），简称E-R模型。该模型用E-R图（样式见下文汉字构造E-R模型图）来描述数据对象。下面简单介绍E-R模型的几个基本概念及其在E-R图中的表示法。 1.实体（entity）。指任何客观存在的事物或抽象的概念。如汉字、笔画。同一类型的实体构成一个实体集（entity set）。实体在E-R图中用矩形框表示。 2.属性（attribute）。指实体或联系的特征。如汉字有读音、部首、笔画数等属性。属性在E-R图中用椭圆形框表示。 3.实体标识符（identifier）或键（key）。指能唯一标识一个实体的属性或属性集。比如《说文》540部的序号可以作为《说文》部首的实体标识符。实体标识符通常用下划线标明。 4.联系（relationship）。指实体之间的关系。如笔画和汉字之间是组成关系。联系在E-R图中用菱形框表示。联系分为一对一（1:1）、一对多（1:n）和多对多（n:m）三种。比如一个汉字可以由多个笔画组成，一个笔画可以出现在多个汉字中，所以汉字和笔画之间是多对多的关系。 （二）关系模型的基本概念 计算机不能直接处理E-R模型，需要将其转换为结构数据模型。常见的结构数据模型有层次模型、网状模型和关系模型。关系数据库以关系模型为基础。关系模型有如下几个基本概念： 1.关系（relation）。是由行和列组成的二维表，对应于关系数据库中的表（table）。 2.元组（tuple）。表中的行称为元组，对应于关系数据库中的记录（record）。 3.属性（attribute）。表中的列称为属性，对应于关系数据库中的字段（field）。 4.键（key）。关系中可以唯一确定一个元组的属性或属性组，对应于关系数据库中的主键（key）。关系中的任何一个元组在组成主键的属性上都不能为空。 一个关系可以表示为
。R是关系名，A是关系的属性名。如汉字（字形，读音，部首，笔画数）。 （三）将E-R模型转换为关系模型的规则 E-R模型中所有的实体和联系在关系模型中都要转换为相应的关系。 1.每一个实体集都应转换为一个关系，实体的标识符就是这个关系的主键。这个关系中的一个元组代表一个实体，主键能够唯一确定一个实体。 2.联系有不同的处理方式： （1）一对多的联系将“一方”的主键纳入“多方”的关系，如果联系有属性也一并纳入多方的关系中。 （2）多对多的联系需要为联系单独建立一个关系，这个关系要包含被它联系的两个实体集的主键，关系的主键是两个实体集主键的组合。如果联系有属性也要纳入这个关系中。 （3）一对一的联系可以将其中任何一方的主键纳入另外一方的关系，也可以为联系单独建立一个关系。 三 汉字构造的数据模型 建立汉字数据库首先要把汉字的构造用关系模型描述出来，这个工作需要以汉字结构理论为基础。 （一）六书说不适于关系模型 传统的六书说影响很大，但是以六书说为基础来建立关系会遇到一些困难。 1.六书说本身存在不足。（1）六书不能涵盖所有汉字。（2）六书中的转注含义不明。（3）六书中的假借不涉及汉字的构造。（4）六书中的象形、指事、会意三类之间的界线不明确。（裘锡圭，1988：97-104） 2.元组的属性难以确定。如果我们以《说文》中的小篆为对象建立关系，一个元组应该描述一个小篆，那么通过哪些属性来描述一个小篆呢？《说文》中每个小篆所属的部首和六书的类型大致是确定的，因此部首和六书可以作为这个关系的属性，但是仅仅用这两个属性来描述小篆显然是不充分的。如果把形旁和声旁看做属性，由于一个小篆可以有多个形旁（会意字都属此类），也可以有多个声旁（如“竊”“
”），那么属性的数量是不确定的，相应的表的结构就是不确定的，这是数据库设计的大忌。如果取形旁和声旁可能的最大值来建立关系，例如： 小篆（部首，六书，声旁1，声旁2，形旁1，形旁2，形旁3，形旁4） 会出现以下问题：（1）声旁1、声旁2、形旁1、形旁2……是人为规定的，没有道理可言，所以如果一个字有多个声旁或形旁，它们分别属于哪个属性就是不确定的，这样会造成关系的混乱。（2）在声旁、形旁的属性上必然会出现很多空值，造成大量的数据冗余。（3）查询复杂，如果要按声旁和形旁查找一个小篆，就需要从2个声旁和4个形旁共6个字段中检索。因此，对于这种多值属性一般不宜在一个关系中处理，而是需要为多值属性单独建立一个关系。那么，声旁和形旁就需要各建立一个关系，这两个关系还需要各自再用一个关系与小篆关联起来，这就使得整个关系结构非常复杂。 3.缺乏可以作为主键的属性。如果按照“小篆（声旁1，声旁2，…，形旁1，形旁2……）”的模式建立关系，所有的声旁和形旁组合起来才能唯一确定一个小篆，而声旁和形旁中必然会出现空值，所以这个组合不能作为主键。更重要的是，六书说只分析了偏旁的功能，没有分析偏旁的组合方式，因此无法从结构上区分有些偏旁相同并且偏旁的功能也相同的字，比如“怡”和“怠”按照《说文》的分析都是“从心台声”。那么，在关系中就不存在能够唯一标识一个元组的属性，在数据库中也就无法准确地定位一条记录。 如果我们从E-R模型出发去分析，上述问题的症结在于六书说中实体和属性的界线不清楚。声旁和形旁都不是小篆必须具备的，因此不应当是小篆的属性。而把声旁和形旁作为实体也有问题，因为不论表声还是表形都不是偏旁的固有特征，而是偏旁在参与某一个具体的小篆的构造时才具有的。 （二）用实体联系模型描述汉字构造 汉字构形学理论主张从部件、功能和组合方式几个方面来分析汉字的构造。这一理论对汉字结构的描述比六书说更为准确，更便于转换为数据模型。我们首先在汉字构形学理论的基础上用E-R模型描述汉字的构造。 描述汉字的构造，需要考虑以下几个方面：第一，一个汉字由哪些部件组成。第二，每个部件在参与构字时形体有没有变化。第三，每个部件处在什么位置（部件的组合方式）。第四，每个部件具有什么样的功能。 用E-R模型来分析，这里包含汉字、部件和部件变体三个实体集。一个部件可以有多个变体，一个变体可以对应多个部件。如“册”在“删”中是“册”的变体，在“珊”中是“删”的变体。所以部件和部件变体之间是多对多关系。一个汉字可以由多个部件构成，一个部件可以参与多个汉字的构字，所以汉字和部件之间是多对多的关系。直接参与构字的是部件的变体，所以汉字和部件的关系实际上是汉字和部件变体的关系。部件的位置和功能都是在构字的过程中实现的，因此不是实体“部件”本身的属性，而是联系“构字”的属性。 基于以上的分析可以把汉字的构造用E-R模型图表示出来：
（三）汉字构造的关系模型 按照E-R模型向关系模型转换的规则，上图中的实体和联系应当转换为5个关系：
目前的技术条件下不宜用其值为汉字字符的属性充当主键。这主要有以下两个原因：第一，目前任何一个字符集都不能涵盖所有的汉字和汉字的部件。第二，已经编码的汉字字符的处理也还受操作平台、字库和应用程序等因素的制约，比如目前多数字库还不能支持UNICODE规定的所有汉字，多数数据库软件还不能很好地支持UNICODE规定的四字节汉字。因此，我们给汉字、部件和部件变体各设了一个ID号，在不同的关系中用各自的ID或ID的组合来充当主键。这个ID可以使用汉字字符的UNICODE码，对于UNICODE尚未规定的汉字和部件可以按照UNICODE的编码规则临时指定一个代码。使用UNICODE编码有两个优点：第一，无需另外制订编码规则；第二，UNICODE是国际标准，通用性好。 为了简化数据库的结构，我们可以把前三个关系合并为一个：
因为涉及部件的功能，有些同形字就需要加以区分。如姥（mǔ）中的“老”是表义的，姥（lǎo）中的“老”是表音的，在字形层面无法区分。因此，需要把汉字分为字形和字两个关系。一个字形可以表示多个字，而一个字只能有一个字形，所以字形和字是一对多的关系。为了简化，可以把字形的主键纳入字的关系，并把二者合并为一个关系：
在这个关系中ID不能简单地取UNICODE码，因为同形字的UNICODE码是相同的，处理办法见下文。 四 部件位置和功能的描述 （一）部件的定义 部件是由笔画组成、相对独立并具有一定构字能力的汉字结构单位，部件在构字时承担一定的构意功能。相对独立有两层意思：其一是说部件在书写上相对独立，其二是说部件不论成字与否都能够独立地承担一定的构意功能。具有一定的构字能力，是说部件作为汉字的结构单位在构字时应该是可以重复使用的。比如小篆的
（廾），虽然未必单独成字，但是表示双手动作的构意十分明确，而且《说文》廾部除其自身外有16字，其他部首中从廾的字还有很多，可见廾的构字能力很强，所以应该是一个独立的部件。部件在构字时承担一定的构意功能，因此在进行部件分析时要依照构形的理据。比如“街”应当分析为表义的“行”和表音的“圭”两个部件，而不能分析成“彳”“圭”“亍”三个部件。从构意的角度出发，应当只分析直接部件，间接部件不参与构意，所以不分析。比如“街”中的“行”不必再分析为“彳”和“亍”，因为这两个部件都与“街”字的构意无关。 按照上面的定义，通常所说的合体象形字（眉、果）和指事字（本、末）都属于独体字。因为：第一，合体象形字和指事字中不成字的部分独立性都很差，往往不能独立承担某种构意功能；第二，合体象形字和指事字中不成字的部分构字能力都很弱，仅仅出现在个别字中。所以合体象形字和指事字中不成字的部分不具备成为部件的条件，应当与成字部分作为一个整体来看待。其实合体象形字和指事字与普通象形字一样，都是用图画的方式表达单纯的名词性概念，都应归入象形字一类。另外，这两类字的部件难以拆分，勉强拆分只会增加不必要的麻烦，所以从操作方便考虑也应当把这两类字归入独体字。 （二）部件位置的描述 部件在汉字中的位置是相对的，因此，要描述部件的位置首先需要对汉字的结构模式进行分类。汉字的结构模式非常复杂，我们首先选择《说文》中的小篆作为主要的分析对象，因为小篆的形体基本确定，而且构形的理据也比较清楚。通过分析小篆的结构特征，我们把汉字的结构类型分为24种，并给每一种结构类型设定一个编号，给每一种结构类型中的每一个部件的位置设定一个编号，具体情况见表1。这样，通过部件位置编号就可以唯一确定一个部件在其所组成之字中的位置。比如一个部件的位置编号是021，代表它处在左右型的左边；一个部件的位置编号是112，代表它处在右上包型的左下角。
表1中例字给出隶定字形是为了便于对照，分析字形都是依照小篆的形体。此外，还有几点需要说明： 第一，分析结构要依照构形的理据。比如，上中下型和上下中型在平面图示上是一样的，但是部件数量和组合方式都不同。又如，“颖”和“颒”在平面图示上也是一样的。但是“颖”字从禾顷声，属于右上包型；而“颒”从水、廾、页，属于立品型Ⅱ。
（三）部件功能的描述 部件在构字时都承担着一定的功能。我们按照功能的不同把部件分为以下六类： 1.独符（Mono Component，缩写为MC），指一个部件独立构成一个字。如：水、木。 2.义符（Signific Component，缩写为SC），指提示字义的部件。如：“桂”和“沐”的左旁。 3.声符（Phonetic Component，缩写为PC），指提示字音的部件。如：“桂”和“沐”的右旁。 4.区别符（Distinctive Component，缩写为DC），指为分化文字而添加的部件。如“右”和“君”分别是从“又”和“尹”加区别符“口”分化而来的。 5.饰符（Additional Component，缩写为AC），指为了字形的匀称、美观等与构意无关的目的添加的部件。如“高”字像高台之形，其下所从的“口”为饰符。 6.记号（Mark，缩写为MA），指由于字形演变而丧失了其最初功能的部件。如金文的“须”字描绘出人的面部及胡须，小篆中表示胡须的笔画与表示面部的“页”分离，《说文》分析为从页从彡，其中的“彡”已经演变为记号。 （四）构形分析需要注意的问题 分析汉字的构形应当以共时的文字资料为基本对象，同时为了能够尽可能准确地反映文字的构意，也需要适当兼顾文字的历时发展。 上文提出的24种结构类型是分析小篆的形体得出的，隶变以后汉字的结构类型大致不超出这个范围。不过，隶变以后汉字的构形系统发生了一系列变化，这是我们对隶变后的汉字进行构形分析时需要注意的。 1.不同的部件隶变后合并为一个部件。例如：“朏”“肌”“服”小篆分别从“月”“肉”“舟”，隶变后左旁混同为“月”。对于这类部件应该分析为体现其原构意的部件的变体，如“朏”“肌”“服”中的“月”分别是“月”“肉”“舟”的变体。 2.同一部件分化为多个变体。最典型的就是有的部件在作偏旁时与独立成字时形体不同，如：水—氵，火—灬，心—忄。 3.部件的位置发生变化，造成相关汉字的结构类型也发生了变化。如从“辵、辶”的字在小篆中一般属于左右型，而隶变后属于左下包型；从“宀”的字在小篆中一般属于上三包型，而隶变后属于上下型。 4.由于形体的演变，多个部件融合为一个部件，这也会造成相关汉字的结构类型发生变化。如“暴”字中间的“出”和“升”融合为“共”，由四叠型演变为上中下型；“舂”字上部的“午”和“升”融合为“”，由上中下型演变为上下型。 5.一部分部件隶变后丧失了原有的构意功能，演变为记号。如“暴”和“春”中的“共”和“”由原来的表义部件演变为记号。
可见，在不同的演变阶段，同一个汉字所包含的部件以及部件的数量、位置和功能都可能会有所不同。 以上讲的是从小篆到今文字的演变，其实类似的演变在早期的古文字到小篆的发展过程中也不同程度地发生过。小篆之前的古文字图画意味更浓，组合模式也更为复杂，以上的24种结构类型还不能完全涵盖，有待于进一步的研究。 五 汉字字形数据库的实现 （一）表的设计 按照上文设计的汉字构造的关系模型和部件位置与功能的描述方式，我们使用数据库软件Microsoft Office Access（2003版）尝试建立一个汉字字形数据库的样本。这个数据库包含三个表。 1.部件表。包含部件变体ID（主键）、部件UNICODE、部件变体和部件四个字段。上文设计的关系6是以部件ID和部件变体ID的组合作为主键。多个字段组合作为主键会使数据库的查询变得复杂，因此我们对关系6稍加改造，即以部件变体的UNICODE码加上一位区别码作为主键，命名为“部件变体ID”。区别码的编码规则是：如果一个部件变体只对应一个部件，其区别码为“0”；如果一个部件变体对应多个部件，其区别码从1顺序编号。如果需要提取部件变体的UNICODE码，在查询中使用函数“LEFT（部件、部件变体ID，LEN（部件.部件变体ID）-1）”即可，因此表中不需要再单独设计一个“部件变体UNICODE”的字段。表2是部件表的片断。
2.汉字表。包含汉字ID（主键）、汉字和结构类型三个字段。前文设计的关系7是以字形ID和字ID的组合作为主键的，如果这两个ID是用UNICODE码的话，是不能作主键的，因为同形字的UNICODE码是相同的。我们把关系7也做了改造，用汉字的UNICODE码加上一位区别码作为主键，命名为“汉字ID”。区别码的编码规则是：如果一个字形只对应一个字，其区别码为“0”；如果一个字形对应多个字，其区别码从1顺序编码。结构类型也可以从构字表中的部件位置推出，但是为了简明我们还是在汉字表中单独设计了一个字段。表3是汉字表的片断。
3.构字表。包含汉字ID、部件变体ID、部件位置和部件功能四个字段。这个表不设主键，通过汉字ID和部件变体ID分别同汉字表和部件表建立关系。表4是构字表的片断。
如果某字的某个部件同时具有多种功能，那么该部件的每一个功能要单独作为一条记录。如表4中第二条和第三条记录都是“仔”的右旁“子”，一条的功能是表义，另一条的功能是表音。 （二）查询的设计 有了上面的三个表，我们就可以通过部件、部件位置、部件功能等不同的条件来查询需要的数据。 1.查询包含某个部件的汉字。比如要查询包含部件“女”的汉字，可以通过以下SQL（Structured Query Language）语句实现： SELECT DISTINCT汉字.汉字ID，汉字.汉字 FROM（汉字INNER JOIN构字ON汉字.汉字ID=构字.汉字ID）INNER JOIN部件ON构字.部件变体ID=部件.部件变体ID WHERE部件.部件变体=“女”；（查询一） 查询结果如表5③：
如果要限定左旁是“女”，只需将WHERE子句改为 WHERE部件.部件变体=“女”AND构字.部件位置=“021”。 结果就会排除“汝”字。 2.查询包含某个特定功能部件的汉字。比如要查询“册”作声符的汉字，可以通过以下SQL语句实现： SELECT DISTINCT汉字.汉字ID，汉字.汉字，部件.部件，部件.部件变体 FROM（汉字INNER JOIN构字ON汉字.汉字ID=构字.汉字ID）INNER JOIN部件ON构字.部件变体ID=部件.部件变体ID WHERE部件.部件变体=“册”AND构字.部件功能=“PC”；（查询二） 查询结果如表6：
这个查询是以部件变体为“册”作条件的，所以结果中实际上是同时包含了从册声和从删省声的字。栅1（zhà）从册声，栅2（shan）从删省声，所以是两条记录。如果把WHERE子句中的“部件.部件变体”改为“部件.部件”，那么查询的结果就只有栅1一条。 3.按照部件和部件位置查询汉字。比如要查询左旁为“木”、右旁为“册”的字，可以通过以下SQL语句实现： SELECT DISTINCT LEFT（a.汉字ID，LEN（a.汉字ID）-1）AS汉字UNICODE，汉字 FROM（SELECT汉字.汉字ID，汉字.汉字 FROM（汉字INNER JOIN构字ON汉字，汉字ID=构字，汉字ID）INNER JOIN部件ON构字，部件变体ID=部件.部件变体ID WHERE构字.部件位置=“021”AND部件.部件变体=“木”）AS a INNER JOIN （SELECT汉字.汉字ID FROM（汉字INNER JOIN构字ON汉字，汉字ID=构字，汉字ID）INNER JOIN部件ON构字，部件变体ID=部件，部件变体ID WHERE构字.部件位置=“022”AND部件，部件变体=“册”）AS b ON a.汉字ID=b.汉字ID；（查询三） 查询结果如表7：
因为这个查询已经指向了唯一的汉字字符，汉字ID不能准确标识其身份，所以我们在查询中用函数截取出该字的UNICODE码。 六 基于构形分析的汉字表达式 通过24种结构类型定义了部件在字中的位置，那么我们就可以通过部件和部件的位置准确地描述一个汉字的字形。在此基础上，我们设计了一种可以唯一表达一个汉字字形的汉字表达式： 结构类型代码（UNICODE_部件1，……，UNICODE_部件n） 其中部件代码的排列顺序与表1中各种结构类型中部件位置编号的顺序相同。 下面是几个汉字的表达式： 木：01（6728）；桂：02（6728，572D）；街：05（884C，572D）；颒：20（6C34，SEFE，9875） 在汉字字形数据库中，汉字表达式可以通过查询生成。以左右型汉字为例，可以通过以下SQL语句查询汉字表达式： SELECT DISTINCT b.汉字，b.a& LEFT（构字，部件变体ID，LEN（构字，部件变体ID）-1）&“）”AS表达式 FROM构字INNER JOIN（SELECT DISTINCT汉字.汉字ID，汉字，汉字，汉字，结构类型&“（”&LEFT（构字.部件变体ID，LEN（构字，部件变体ID）-1）&“，”AS a FROM汉字INNER JOIN构字ON汉字.汉字ID=构字.汉字ID WHERE构字.部件位置=“021”）AS b ON构字.汉字ID=b.汉字ID WHERE构字.部件位置=“022”；（查询四） 表8是查询结果：
七 结语 本文提出了一种适于关系数据库处理的汉字构形分析模型和一个汉字字形数据库设计方案，通过在Access中的测试，数据库运行效果良好。 建立这样一个汉字字形数据库的意义在于可以全面地储存汉字的结构信息，实现对汉字结构多角度的检索，从而为汉字以及相关领域的理论研究和应用研究提供便利。 第一，传统的音序、笔画、部首、四角号码等检字手段都存在局限性。以汉字字形数据库为基础，可以制作辅助的检字和输入工具，实现通过部件和部件位置对汉字进行检索，从而弥补传统检索手段的不足，提高检字效率。 第二，通过数据库可以对部件在特定字集中出现的频率、每个部件在构字时位置和功能的规律进行分析，为汉字本体研究提供便利。 第三，数据库中储存了部件和部件位置的信息，以此为基础可以实现从部件生成汉字。 本文还提出了一种通过结构类型和部件代码描述汉字的表达式。同其他的汉字表达式（如孙星明等，2002）相比，由于只拆分到直接部件，拆分次数少而且是根据构形的理据，所以这种表达式更简单，也更容易避免由于主观性造成的分歧。 出于古籍整理和出土文献研究的需要，目前的汉字字符集还有必要扩展。在对汉字字符集进行扩展时，利用汉字字形数据库和汉字表达式可以有效避免出现重复的字符。 计算机的工作是模拟人脑的。人在学习和识别汉字时一般首先分析其直接部件，虽然由于知识背景的不同，分析的结果不完全相同，但通常都不会一上来就把一个字拆分到最小的部件。所以本文提出的汉字构形分析模型和汉字表达式更接近自然。这个模型的不足之处在于部件的数量太大（理论上所有的汉字都可以充当部件）。解决这个问题，可以在数据库中通过查询对部件的结构进行递规的分析。例如，在汉字和构字表中分析了“符”是由“”和“付”两个部件组成的，然后再从汉字表中分别检索“”和“付”，如果结构类型是“01”（即独体字）即停止分析，如果不是就继续检索，直到所有层级上的部件都是“01”结构为止，那样就可以检索到“付”是由“亻”和“寸”组成。 数据库的设计是同用户的需求密切相关的。本文偏重于汉字、汉语的研究，注重构形的理据，所以对部件、部件变体、部件功能等分析得比较细致。如果面对不同的用户，出于不同的目的，数据库的结构可以有所调整。 ①加下划线的是主键。 ②此例为古文，非小篆。《尚书·顾命》：“王乃洮颒水。”《释文》：“颒，音悔。《说文》作‘沫’，云古文作‘颒’。”今大徐本《说文》古文作“湏”，不从“廾”。此处据段注本。 ③示例数据库中只录入了少量数据，查询结果只在这些数据范围内。
标签：unicode论文; 汉字结构论文; 关系模型论文; 汉字演变论文; 实体关系图论文; 汉字六书论文; 功能分析论文;
基于关系数据库的汉字构形分析及其应用_unicode论文
下载Doc文档