本文通过一个简单的零售场景阐述如何根据传统的表数据进行图建模，从而得到图数据。

表数据

零售场景中最基础的三张表分别是客户表、商户表、交易表。其中交易表记录了客户在购买商品时向商户支付钱款的转账行为。

• 客户表 CUSTOMER 字段：

• 商户表 MERCHANT 字段：

• 交易表 TRANSCTION 字段：

TRANSCTION 中的“外键”如果超出了 CUSTOMER、MERCHANT 中“主键”的范围，入图时可将该外键所在的交易数据视为无效，或先创建该外键所代表的客户或商户之后将该外键所在的交易数据视为有效，对于这一点，Manager 和 Transporter 的处理方式不同。

图数据

将表数据转为图数据的过程即为图建模。最简单的建模方法是将表数据划分为实体表和关系表两类，将每一张实体表作为图的一个点 schema，将每一张关系表作为图的一个边 schema，表中的字段作为其所对应 schema 的属性。

实体表通常比较容易识别，上面的客户表 CUSTOMER 和商户表 MERCHANT 就是实体表，它们分别代表了零售场景下的客户、商户这两类实体。

关系表的识别则依赖于实体表，因为关系表体现的是多张实体表之间的关系，所以，一张关系表中需要有至少两个代表实体表主键的外键。上面的交易表 TRANSACTION 的两个外键分别为客户表主键 cust_no 和商户表主键 merchant_no，因此可以将交易表视为一张关系表。

有时为了业务需要，可能会将关系表也定性为实体表，评判的依据包括但不限于图模型的可扩展性、业务 UQL 语句的复杂程度以及运行效率等，此处不做深入讨论。

将上面的客户表和商户表分别作为点 schema customer 和 merchant，将交易表作为边schema transfer。请注意，这里边 schema 没有延用交易表的名称，而是使用了一个动词，原因是 Ultipa 图系统中的边是有方向的，即边是由起点指向终点的，边上的动词代表起点发出的动作，这能更好地从语义层面解释边的方向。

以下分别是 customer、merchant、transfer 这三个 schema 的属性：

• 点 schema customer

系统属性 _id 是图集内点的唯一标识符（不隶属于schema），在此处就是原先客户表的主键 cust_no，其数据类型 string 的最大长度为 128；其余自定义属性的数据类型 string 的最大长度为 65535。Ultipa 支持的小数类型有 float 和 double，所占字节数和数据精度各不相同，请根据数据要求、数据量以及磁盘大小等合理选择。

• 点 schema merchant

此处的系统属性 _id 就是原先商户表的主键 merchant_no。

• 边 schema transfer

系统属性 _from 是边起点的 _id，此处就是外键之一 cust_no；_to 是边终点的 _id，此处就是另一个外键 merchant_no。入图时必须提供这两个属性的值。

schema 和属性的命名规则：2~64个字符，以字母开始，由字母、数字、下划线构成。

有时为了业务需要，可能会将原始数据表中的某个字段定义为 schema，评判的依据包括但不限于图模型的可扩展性、业务 UQL 语句的复杂程度以及运行效率等。这部分与前面提到的“将关系表定性为实体表”的情况类似，不做深入讨论。