一种电子产品码信息服务数据的定义和存储方法 【技术领域】
本发明涉及RFID(Radio Frequence Identified，无线射频识别)领域，尤其涉及一种EPCIS(EPC Information Service，电子产品码信息服务)数据的定义及存储的方法。
背景技术
RFID技术作为一种新兴技术，正在得到快速的应用，特别是在物流领域。EPCglobal(电子产品码全球)组织作为RFID领域的标准组织，致力于推广该技术的广泛应用，其相继推出了RFID技术应用系统的标准框架、ALE(Application Level Event，应用级别事件)标准、EPCIS标准等，极大地推动了RFID技术的商用进程。
EPCIS的目标就是在物联网上共享EPC(Electronic Product Code，电子产品码)数据。而要使得数据的提供者和使用者都能够理解这些EPC数据，就必须采用统一的、标准的数据格式。EPCIS标准采用XML(eXtension MarkupLanguage，扩展标记语言)schema(文档模型)来描述数据类型，并用XML来承载数据实体，通过WSDL(Web Service Description Language，网络服务描述语言)的方式在数据提供者和数据使用者之间进行传递。
EPCIS标准中，有两类重要的抽象数据模型：事件数据模型和主数据模型。事件数据模型包括如下概念：事件类型、事件实体、事件域类型、事件域实体；主数据模型包括如下概念：词汇类型、词汇实体、词汇属性类型、词汇属性实体。为了理解这些概念，首先要理解信息模型与信息实体的概念，另外，由于EPCIS标准是采用XML schema来描述所有的数据模型，因此，对于XML中的一些概念，例如：元素、属性、简单类型、复杂类型等，请参见XML相关说明，此处将不再赘述。本文涉及到的一些概念介绍如下：
信息模型：描述信息实体结构的数据信息；
信息实体：依照某种信息模型，有具体取值的数据信息；
元数据：即描述信息模型的数据；
实体数据：即描述信息实体的数据；
事件类型：描述事件实体结构的信息模型；
事件实体：依照某种事件类型，有具体取值的信息实体，下文提到的事件等同于事件实体；
事件域类型：描述事件域结构的信息模型，在XML schema中被描述为一种元素，既然是元素，就有简单和复杂两种类型，如果是复杂类型的元素，则还会含有子元素，我们称之为子事件域类型，并且，事件域类型还可以有自己的属性；
事件域实体：依照某种事件域类型，有具体取值的信息实体；
词汇类型：描述词汇实体结构的信息模型，在XML schema中也被描述为一种元素，但没有子词汇类型的说法，一种词汇类型含有多个词汇属性类型；
词汇实体：依照某种词汇类型，有具体取值的信息实体；
词汇属性类型：描述词汇属性实体结构的信息模型，在XML schema中也描述为一种元素，同事件域类型一样，也有简单和复杂之分，因此也就有子词汇属性类型，或者说子元素，并且，词汇属性类型可以有自己的属性；
词汇属性实体：依照某种词汇属性类型，有具体取值的信息实体；
其中，事件实体与事件域实体之间是整体与部分的关系，一个事件由多个事件域组成；词汇实体与词汇属性实体之间也是整体与部分的关系，一个词汇实体除了有自己的URI(Unified Resource Identity，通用资源标识符)取值之外，还包含有多个词汇属性实体。事件实体与事件域实体之间的关系是在事件类型定义中体现的。同样，词汇实体与词汇属性实体之间的关系也是在词汇类型定义中体现的。依据EPCIS标准，事件类型由若干事件域类型组成，复杂的事件域类型由若干子事件域类型组成，同样，词汇类型是由若干词汇属性类型组成，复杂词汇属性类型是有若干子词汇属性类型组成
另外，事件域类型与词汇类型之间还可以有某种对应关系，有些事件域类型就是某种词汇类型，其取值就是该词汇类型的某一词汇实体的URI。
EPCIS标准采用XML schema来描述这两类数据模型，或者说定义这两类数据模型，但我们在构建符合EPCIS标准的软件系统时，一般都采用数据库来记录数据。而且在实际的系统中，可能还会存在对数据模型的更新、删除等操作，如直接使用XML schema的话，会存在以下问题：
A、不方便将信息模型和信息实体结合起来。信息类型相当于一个模板，而信息实体就是根据该模板生成的一个个实例。信息实体肯定是采用数据库来记录，而如果信息模型仍采用XML schema来记录的话，其与信息实体之间的结合就会变得比较困难；
B、在程序中不方便对文件进行修改以实现信息模型的新增、修改和删除操作；
C、安全问题。在采用XML schema文件的描述方式时，一旦该文件被无意或者恶意修改的话，系统就会出现异常。
【发明内容】
本发明要解决技术问题是提供一种实现电子产品码信息服务数据的定义与存储方法，以提高电子产品码信息服务数据使用的方便性和安全性。
为解决上述问题，本发明提供了一种电子产品码信息服务数据的定义和存储方法，包括以下步骤：
提取描述事件数据模型和主数据模型的元数据，其中，所述元数据用于定义事件类型、事件域类型、词汇类型和词汇属性类型；根据这些元数据及其之间的关系创建实体数据表。
进一步地，上述方法还包括：
将所述电子产品码信息服务数据写入到相应的所述实体数据表中。
进一步地，上述方法还可具有以下特征：
在提取所述元数据时，将事件类型、事件域类型、词汇类型、词汇属性类型统一视为元素，对等考虑；且将所述元素与元素的属性分别用不同的实体数据表来表示，将元素自身与元素之间的关系分别用不同的实体数据表来表示。
进一步地，上述方法还可具有以下特征：
所述实体数据表中一个用于描述所述元素和/或属性所属的命名空间。
进一步地，上述方法还可具有以下特征：
所述描述元素自身的实体数据表中还包括一个用于描述事件类型之间的继承关系的字段。
采用本发明后，由于利用数据库来记录模型和实体信息，因此数据库本身地安全机制就能保证其数据不容易被非法修改或者删除，保证了数据的安全性。
【附图说明】
图1是本发明实施例中EPCIS数据的定义及存储的方法流程图。
【具体实施方式】
下面将结合附图及实施例对本发明的技术方案进行更详细的说明。
本发明提出了一种采用关系数据库来定义和存储电子产品码信息服务数据的方法。该方法可以在系统构建过程中实施，也可以在系统运行的情况下实施，前者被称为静态方式，后者被称为动态方式。理想情况下，如果能够采用动态方式实施，效果会更好。本发明给出了这两种方式下共有的流程。需要注意的是，不管是静态方式、还是动态方式，都必须遵循先定义后使用的顺序，并且一旦使用，就不允许随意进行修改或者删除。
本方法如图1所示，包括以下步骤：
S01、提取描述事件数据模型和主数据模型的元数据，利用这些元数据就可以定义事件类型、事件域类型、词汇类型和词汇属性类型；而元数据的提取应遵循以下原则：
●将事件类型、事件域类型、词汇类型、词汇属性类型统一视为元素，对等考虑；
●将元素与元素的属性分开描述，元素自身与元素之间的关系分开描述，分别给出元数据。这样做，是考虑到元素与元素之间可能存在多对多的关系(如一个元素可以是多个元素的子元素)，从而达到复用元素自身的定义的目的，避免了定义冗余，使用起来会相对灵活一些；
●在XML中有一个命名空间(nameSpace)的概念，一个命名空间下可以有多个元素或者属性，为了避免数据冗余，并且为了限定同一命名空间采用相同的前缀(prefix)，将命名空间单独描述，在元素或者元素属性中应用；
●考虑到元素之间的继承关系，例如：事件类型之间的继承关系，设定extendElement_id元数据；
S02、将提取出的元数据保存下来，此时可进行对各元数据的增、删或改操作；
S03、根据这些元数据及其之间的关系创建实体数据表，例如：事件实体表、事件域实体表、词汇实体表、词汇属性实体表。对于简单类型的事件域或子事件域，不需要另外创建一个表来存储其子事件域实体数据，而只需要将其作为实体数据表中的字段就可以了；而对于复杂类型的事件域或子事件域，可以再创建一个表以存储其子事件域实体数据，父子之间通过外键关联。对于词汇类型、词汇属性类型，也是按照这个原则创建实体数据表；
S04、实体数据表建立之后，就可以对该表进行写入数据和读取数据操作，但此时，与这些表对应的元数据不能随意修改或者删除了。
下面列出遵照以上原则所给出存储元数据的表结构，不同实现者给出的表结构可能不一样，但并不能脱离采用数据库表来记录元数据的范畴。
描述命名空间的表：
NAME_SPACE(id，prefix，nameSpace)
其中，prefix为前缀，namespace为命名空间名。每个元素的名称elementName都要求是在某一个命名空间之下，每一个命名空间又都有自己的前缀prefix。从数据库设计的角度考虑，为避免数据冗余，设计上将NAME SPACE单独拿出来作为一个表。但这个namespace也可以与下述描述元素自身的表中的elementName字段放到一起。
描述元素自身的表：
ELEMENT_SELF(id，elementName，elementTypeName，nameSpace_id，extendElement_id，infoModeType，structureType，isVocabulary，vocabularyID)
其中，elementName：元素名称；
elementTypeName：元素类型名称，如：readpointType；
extendElement_id：继承元素id，表示该元素是从哪个父元素继承而来，它拥有父元素的所有子元素和属性；
infoModeType：该元素描述的信息模型类型，取值可为event(事件类型)、eventField(事件域类型)、vocabularyAttribute(词汇属性类型)、或vocabularyAttributeField(词汇属性域类型)；
structureType：用于描述该元素是简单类型(simpleType)还是复杂类型(complexType)，当为简单类型时，其取值才能为int(整型)、float(浮点型)、time(时间)、string(字符串)；
isVocabulary：用yes/no描述其该元素的取值是否来自主数据中的词汇。该参数可选，可用于说明事件域类型元素与词汇类型元素之间的关系，以表明注明该元素是否是词汇；
vocabularyID：词汇ID，也就是词汇的URI，只有当isVocabulary为yes的时候，该字段才有效。
描述元素属性的表：
ATTRIBUTE(id，attributeName，attributeTypeName，namespace_id，isVocabulary，vocabularyID)
其中，attributeName：属性名称；
attributeTypeName：属性类型名称；
isVocabulary：是否是主数据中的词汇，yes/no；
vocabularyID：词汇ID，也就是词汇的URI，只有当isVocabulary为yes的时候，该字段才有效。
描述元素关系的表：
ELEMENT_RELATION(id，element_id，childElement_id，attribute_id，occurs，order，sequence)
其中，element_id：元素自身的id；
childElement_id：孩子元素的id，当描述的是元素与孩子元素之间的关系时，该字段有效；
attribute_id：属性的id，当描述的是元素与属性之间的关系时，该字段有效，它与childElement_id互斥；
occurs：子元素出现频率，其取值可以为0～1/1/0～*/1～*，取值0～1表示该子元素可有可无，如果有，只有一个；取值1表示该子元素有且只能有一个；取值0～*表示该子元素可以没有，也可以有多个；取值1～*表示该子元素至少有一个；
order：是否排序，yes/no。
sequence：顺序号，只有当order取值为yes的时候，该字段才有效，从1开始，只记录自身的孩子元素的顺序。
在前面的考虑下，采用数据库中的视图来描述一个元素的完整信息，而描述某一个元素完整信息的视图如下，其中包括继承的元素所包含的信息：
ELEMENT(id，elementName，elementTypeName，namespace，extendElement_id，infoModeType，structureType，isVocabulary，vocabularyID，childElement_id，childElementName，childElementTypeName，childElementNameSpace，childElementInfoModeType，childElementStructureType，childElementIsVocabulary，childElementVocabularyID，childElementOccurs，childElementOrder，childElementSequence，attributeName，attributeTypeName，attributeNameSpace，attributeIsVocabulary，attibuteVocabularyID)
其中，字段childElementSequence 的取值不能直接从ELEMENT RELATION表中获取，而应该考虑到继承的父元素中所包含的子元素，首先排序父元素中的子元素，然后是自己的子元素，因此自己的子元素的sequence需要加上所有父元素的子元素个数。
本发明可以在系统构建过程中实施，也可以在系统运行过程中实施，不同的是，要做到在系统运行过程中定义信息模型，并立刻就能使用，该系统需要采用较复杂的技术，例如：在程序中动态创建数据库表，并能够动态形成数据库操作语句，而系统构建过程中实施，则不需要处理这么复杂的流程。
当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。