每个 OData 服务须要都数据模型定义（模型提供者类）。
在客户开发我的项目的状况下，开发过程总是从事后定义的数据模型开始（由外而内的办法）。
SEGW 反对下列几种 OData 模型定义形式：
手动定义数据模型
提供最大的灵活性，须要手动定义单个数据模型元素及其属性。
下图就是手动创立的数据模型的一个例子：
Import – 导入
反对下图这几种导入形式：
- DDIC 构造（ABAP 数据字典）：这种形式可能缩小在数据模型中创立实体类型和简单类型所需的工夫；
- RFC/BOR 接口：使开发人员可能重用现有的 RFC/BOR 参数以轻松创立实体类型。通过这种形式，能够利用业务对象存储库中的大量现有近程函数调用 (RFC) 和业务利用程序接口 (BAPI)。导入现有接口定义后，能够映射来自同一个 RFC 或 BAPI 的操作以取得您须要的服务操作，而无需编写额定的 ABAP 源代码。
- 数据模型：容许重用现有的数据模型。能够为多个服务重用数据模型。
- 导入搜寻帮忙：容许重用零碎中现有的搜寻帮忙作为数据源来创立新的实体类型。
服务重定义
这个性能可能从新定义现有 SAP 网关服务或从 SAP 零碎环境中的框架创立的服务。例如，服务提供者接口 (SPI)、SAP 业务信息仓库 (BW 查问)、通用交互层 (GenIL)。从新定义服务功可能重用 SAP 零碎环境中存在的各种业务对象和服务。此外，它连贯现有的服务操作，因而无需创立独自的服务实现。
服务蕴含 – Include
可能蕴含现有的 SAP Gateway 服务，这样就防止了从新创立其数据模型的步骤。为了更好地重用，它容许将一个或多个现有服务组合到一个新服务中。如果抉择蕴含现有服务，则无需执行服务施行阶段。
服务援用 Reference
服务援用可能通过 Service Builder 中的 Reference 选项在援用的数据源中获取数据模型。这样的数据模型在 Service Builder 中不是长久的，而是在调用 Service Builder 时通过援用获取它们，这与在 Service Builder 中的其余办法中导入的工件不同。援用的模型始终是只读模式。