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

表数据

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

• 客户表CUSTOMER字段：

• 商户表MERCHANT字段：

• 交易表TRANSCTION字段：

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

图数据

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

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

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

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

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

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

• 点Schema customer

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

• 点Schema merchant

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

• 边Schema transfer

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

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

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