Common Data Service是一个基于云的低代码数据服务和应用程序平台，它使您可以利用Microsoft服务的安全性和连接性。 Common Data Service可以轻松连接到Power Platform的各个方面，因此您可以完全控制，自动化和增强业务。 借助标准实体和字段，以及轻松定义数据之间关系的能力，Common Data Service专为强大，可扩展的解决方案而构建。
在本模块中，您将：
- 说明通用数据服务CDS中的环境，实体，字段和关系
- 描述通用数据服务CDS和通用数据模型CDM之间的区别
- 解释用例以及业务规则和流程流的限制
Common Data Service概览
通用数据服务是一种基于云的解决方案，可以轻松地构建各种数据和业务逻辑，以安全且合规的方式支持互连的应用程序和流程。 Common Data Service由Microsoft管理和维护，在全球范围内可用，但在地理位置上进行部署以符合您潜在的数据驻留权限。 它不是为在您的服务器上独立使用而设计的，因此您将需要Internet连接才能访问和使用它。
通用数据服务被设计为您的业务数据中央数据存储库，甚至您可能已经在使用它。 在幕后，它为许多Microsoft Dynamics 365解决方案提供了支持，例如现场服务，市场营销，客户服务和销售。 它也可以作为Power Apps和Power Automate的一部分使用，并具有内置的本机连接性。PowerPlatform的AI Builder和Portals功能还利用了Common Data Service。
以下是将Common Data Service的许多产品组合在一起的可视化展示。
如您所见，Common Data Service提供了很多功能。 以下是每种功能类别的简要说明。
Security：Common Data Service使用Azure Active Directory（Azure AD）处理身份验证，以支持条件访问和多因素身份验证。 它支持行和字段级别的授权，并提供丰富的审核功能。
Logic：Common Data Service使您可以轻松地在数据级别应用业务逻辑。 无论用户如何与数据进行交互，都适用相同的规则。 这些规则可能关联到重复检测、业务规则、工作流或其它模块。
Data：Common Data Service为您提供控制数据形态的控件，使您能够对数据进行发现，建模，验证和报告。 该控件可确保您的数据无论使用方式如何，都将按照您想要的方式显示。
Storage：公共数据服务将您的物理数据存储在Azure云中。这种基于云的存储消除了担心数据存在何处或如何扩展的负担。这些问题都已经为您解决了。
Integration：Common Data Service以不同的方式连接以支持您的业务需求。 API，webhooks，事件和数据导出使您可以灵活地输入和输出数据。
如您所见，Common Data Service是一个非常强大的基于云的解决方案，用于存储和处理您的业务数据。 在以下各节中，您将从Power Platform的数据存储角度看一下Common Data Service，从这里开始您的旅程。 请记住，上面讨论的其他丰富功能可以随着使用量的增加而进一步探索。
首先，Common Data Service使您可以创建一个或多个标准化数据库的基于云的实例。 该数据库包括预定义的表和字段，这些表和字段存储几乎在所有组织和企业中常见的数据。 您可以通过添加新的字段或表（在Common Data Service中称为实体）来自定义和扩展存储的内容。易于设置公共数据服务数据库，并对其中的数据模型标准化，从而简化了您集中精力构建解决方案的能力，而无需担心基础架构、存储和数据集成。 将您的数据存储在Common Data Service中后，可以通过许多不同的方式来访问它。 您可以使用Power Apps或Power Automate之类的工具在本地处理数据。 或通过连接器和API，您可以从任何业务解决方案连接到通用数据服务。 借助基于角色的安全性和业务规则等功能，无论如何访问数据，您都可以信任您的数据是安全的。
Common Data Service定义
通用数据服务数据库是通用数据服务的单个实例，该实例将数据存储在称为实体的一组标准和自定义数据结构中。 实体是用于存储数据的逻辑记录集。 实体就像关系数据库中的表一样，但是存在细微的差异。 实体中的记录包含许多字段，用于管理有关单个记录的各个信息。
可扩展性
通用数据服务数据库支持大型数据集和复杂的数据模型。 实体可以容纳数百万个条目，并且您可以将Common Data Service数据库的每个实例中的存储空间扩展到4TB。 您的Common Data Service实例中可用的数据量取决于与其关联的许可证的数量和类型。 数据存储在所有获得许可的用户之间池化，因此您可以根据需要为所构建的每个解决方案分配存储。 如果您需要的存储空间超出标准许可中提供的存储空间，则可以购买额外的存储空间。
Common Data Model vs. Common Data Service
Common Data Service数据库中的标准实体设计基于称为Common Data Model的开放数据模型标准。 通用数据模型是一种逻辑设计，其中包括Microsoft及其合作伙伴在称为“开放数据计划”的全行业计划中发布的一组开源、标准化、可扩展的数据实体和关系。 预定义实体、属性、语义元数据和关系的这种集合构成了通用数据模型的基础。
开放数据倡议
通用数据模型是开放数据倡议的输出。 它提供了一个平台，可对您的数据进行单一，全面的查看，将您所有业务部门，整个系统中的数据汇总在一起并加以充实，以将实时情报返回到您的应用程序和服务中。 微软已经与SAP和Adobe在开放数据计划方面建立了合作关系。
通用数据服务的结构和优势
公共数据服务数据库的结构基于公共数据模型中的定义和架构。 使用公共数据模型作为公共数据服务数据库的基础的主要好处是简化了使用公共数据模型架构的任何解决方案的集成，因为解决方案的标准实体是相同的。 您还将能够利用供应商通过使用通用数据模型构建的丰富解决方案生态系统。 最重要的是，您可以将通用数据服务数据库扩展的范围几乎没有限制。
识别CDS中的实体和字段
实体在存储数据方面类似于数据库或Excel工作簿中的表。 它是一个逻辑结构，其中包含由字段组成的记录，或更简单地说，就是由行和列组成的记录。
在下面，您可以看到标准客户实体及其包括的各种类型的字段的屏幕截图。
实体类型
实体的两种类型为：
- Standard - 为Common Data Service数据库的每个实例创建的基本实体集。您可以向任何实体添加更多字段，但只能从自定义实体删除字段。
- Complex - 包含复杂的服务器端业务逻辑的实体，包括实时工作流或插件。 Dynamics 365应用程序中使用的某些实体很复杂。 如果添加服务器端逻辑，则必须小心以确保用户具有使用复杂实体的适当许可证。 通过单击此模块的摘要单元内的链接，可以访问有关复杂实体的其他信息。
字段
字段是一种在实体的记录中存储离散信息的方法。 您可以将其看作是Excel中的一列。 字段具有类型，这意味着您可以将某种类型的数据存储在与该数据类型匹配的字段中。 例如，如果您有一个需要日期的解决方案，则可以将日期存储在Date类型的字段中。 同样，如果要存储数字，则将数字存储在具有Number类型的字段中。
实体中字段的数量从几个字段到一百个或更多不等。 如果一个实体中需要数百个字段，则可能需要重新考虑如何为解决方案构建数据存储，因为可能有更好的方法。
Common Data Service中的每个数据库都以一组标准的实体开始，并且每个标准实体都有一组标准的字段。
请尽可能使用标准实体和字段。 您可以重命名实体，以使实体在解决方案的上下文中更易于理解。 在创建新实体之前，请一定要查看标准实体的列表，并确保标准实体不能满足您的需求。
理解关系
为了为您构建的大多数解决方案提供高效且可扩展的解决方案，您需要将数据拆分到不同的容器（实体）中。 尝试将所有内容存储在单个容器中可能会效率低下，并且难以使用和理解。
下面的例子有助于说明此概念。
假设您需要创建一个系统来管理销售订单。你需要一份产品清单，包括库存、成本和售价。您还需要一个包含客户地址和信用评级的主列表。最后，您将需要管理您所制作的销售发票，因此您将需要一种存储发票数据的方法。发票应该包括诸如日期、发票编号和销售人员、客户信息(包括地址和信用等级)以及发票上每个项目的行项目。订单项应包含对您所售产品的引用，并能够为每种产品提供适当的成本和价格，并根据您在该订单项中售出的数量减少现有数量。
尝试创建单个实体来支持先前描述的功能将是低效的。 解决此业务场景的更好方法是创建以下四个实体：
- Customers
- Products
- Invoices
- Line Items
为这些项目中的每一个创建一个实体并将它们相互关联，将使您能够构建一个可扩展的有效解决方案，同时保持高性能。 将数据拆分为多个实体还意味着您将不必存储重复数据或支持包含大量空白数据的庞大记录。 此外，如果您将数据拆分为单独的实体，报告将变得更加容易。
彼此相关的实体具有关系连接。 实体之间的关系以多种形式存在，但最常见的两种是一对多和多对多，这两种都由通用数据服务支持。
一对多关系也称为父子关系。 在前面的发票示例中，发票实体将是父实体，而订单项将是子实体。 一张发票可以有零个，一个或多个行项目（子记录），但是该行项目始终仅与一个发票（父记录）相关。 通常，如果没有父记录，则子记录将不存在。
一个只允许唯一值(如发票号)的字段用于标识父记录。这个惟一的字段称为键。相同的值(父键)存储在相关的子记录中。当使用子记录存储父键值时，此字段称为外键。用户可以巧妙地使用筛选来显示子记录，该子记录中的外键的值与父记录中的键值匹配。 这允许应用程序显示属于特定父记录（上一示例中的发票）的子记录（上一示例中的行项目）。 这个概念是许多商业软件应用程序的基础。
将数据拆分为不同的实体可以实现可扩展的高效解决方案设计，但是要知道如何将数据拆分为实体可能很困难。 值得庆幸的是，通用数据服务已经包含了大多数组织所需的许多实体。 使用标准实体并对其进行扩展将确保您以一种可靠的，可扩展的方式存储解决方案所使用的数据的方式来构建解决方案。
Common Data Service中的环境
环境用于在Power Platform中存储，管理和共享组织的业务数据，应用程序和流程。 每种环境都允许您提供一个Common Data Service数据库以在该环境中使用。 公共数据服务环境使您可以管理用户访问，安全设置以及与该数据库关联的存储。
每个环境都是在Microsoft Azure Active Directory（Azure AD）租户下创建的，其资源只能由该租户内的用户访问。 环境也绑定到地理位置，例如美国。 在环境中创建通用数据服务数据库时，该数据库是在该地理位置的数据中心内创建的。 您在该环境中创建的所有项目（包括连接，网关，使用Power Automate的流等）也都绑定到其环境的位置。
您可以创建多个环境来管理解决方案开发和数据存储，如设置一个开发环境、一个测试环境和一个生产环境，另外，您可以根据地理位置设置环境。 例如，您可能为欧洲和亚洲建立了一个环境。 这些环境中的每一个将具有零个或只有一个Common Data Service实例。
业务规则
在Common Data Service中，您可以定义业务规则。 业务规则允许您在数据层而不是应用程序层应用和维护业务逻辑。 简而言之，如果您在通用数据服务中创建业务规则，则无论您如何与数据进行交互，它们都有效。
业务规则用法的一个示例是当它们在画布或模型驱动的应用程序中设置或清除实体中一个或多个字段中的值时。 它们还可以用于验证存储的数据或显示错误消息。 模型驱动的应用程序可以使用业务规则来显示或隐藏字段、启用或禁用字段以及基于商业智能创建建议。
业务规则通常是为实体定义的，并且适用于所有表单，但是您可以为特定的模型驱动的表单定义业务规则。 Canvas应用程序不能将业务规则应用于特定的表单，但是在与数据进行交互时仍会强制执行。
业务规则为您提供了一种强大的方法来强制执行规则，设置值或验证数据，而不管用于输入数据的形式如何。 此外，业务规则可以有效地帮助提高数据的准确性，简化应用程序开发并简化呈现给最终用户的表单。
画布应用程序或模型驱动的应用程序可以使用业务规则来执行以下操作：
- 设置字段值
- 清除字段值
- 验证数据并显式错误信息
模型驱动的应用程序还可以使用业务规则来：
- 显示或隐藏字段（仅适用于模型驱动的应用）
- 启用或禁用字段（仅适用于模型驱动的应用）
- 根据商业智能创建商业建议（仅适用于模型驱动的应用）
下面是一个简单但功能强大的业务规则用法的示例。 如果将信用额度设置为大于$ 1,000,000，则业务规则配置为将“信用额度VP批准者”字段更改为必填字段。
如果信用额度小于$ 1,000,000，则此字段为可选。
通过在数据级别而不是应用程序级别应用此业务规则，您可以更好地控制数据，并且可以确定数据遵循您的业务逻辑，无论是直接从Power Apps还是Power Automate甚至通过API访问数据。 规则与数据而不是应用程序相关。
管理员
Common Data Service具有一组丰富的管理选项，可用于创建数据库的新实例或定制可用于每个Common Data Service数据库实例的用户的访问和功能。 您可以使用几个管理门户来管理通用数据服务设置。
本单元讨论Power Apps Admin中心，因为它可以满足您的大多数管理需求。 但是，还有一些其他管理选项可用，它们在“Manage permissions and administration for Common Data Service”学习路径中进行了介绍。
Power Apps管理中心
Power Apps Admin中心提供了您所需的大多数管理设置。 当您寻求管理Common Data Service时，应该始终检查管理设置。
设置分为以下几大类，可以通过选择门户网站左侧的链接来访问设置，如下图所示。
- Environments - 本部分列出了通用数据服务的所有实例。
- Data policies - 本部分允许您设置策略以限制哪些数据连接器可与Common Data Service一起使用，从而限制哪些数据可以流入或流出Common Data Service实体。
- Data integration - 本部分允许您创建或添加预定义的连接，并监视Common Data Service与其他数据存储（例如Salesforce或SQL Server）之间的这些连接。
- Tenant - 本部分允许您监视许可证和配额。
通过进入管理中心并打开门户左侧的每个部分，花一些时间来研究这些选项：
- 打开Power Apps并登录
- 选择齿轮图标下的管理中心，如图所示。
- 选择管理中心门户左侧的选项。
Power Apps Admin中心使您可以管理设置用户，权限以及Common Data Service的许多其他重要功能的任务。
Knowledge check
How can business rules be used in a canvas or model-driven app?
To validate data and show error messages.
【Correct.】 Common Data Service allows business rules to be set to apply and maintain business logic at the data layer.
Show or hide fields.
Manage solution development and data storage.
Your manager has built a solution using the Common Data Service using a few of the standard Entities included out of the box. He wants to capture the date that new records are added to the Entity, but he isn’t sure how. He notices that a “Date” field is already inside his Entity, but he wants the field to have a custom name of “Date Confirmed”. What would you recommend he do?
Create a new Entity with the name “Date Confirmed”.
Use the built-in Date field within the Entity to store the date values, but rename the field to “Date Confirmed”.
【Correct.】 When building a solution in the Common Data Service, it is best practice to use the out-of-the-box entities and fields where possible. In this case, the Entity already has a “Date” field. Best practices also state that you simply rename the existing fields if needed, so that would be the recommended solution here.
Create a new Environment with the name “Date Confirmed”.
One of your co-workers has set up a Model-driven application using the Common Data Service. The app captures information about computer hardware assets, including their price. Your co-worker is concerned that users of the application are going to put incorrect values into fields - for instance, they might put in the wrong cost center when submitting a new record. How could this be prevented?
Use Business Rules to automatically validate the cost center for the currently-logged in user.
【Correct.】 A business rule could be set up to validate that the cost center the user has entered into the Model-driven app matches the cost center that is assigned to their department.
Use Power Automate to validate that the field value matches what the table is expecting.
Use a Canvas App instead of a Model-driven app.
总结
Common Data Service是基于云的数据存储，可让您利用Microsoft程序的安全性和连接性。 Common Data Service可以轻松连接到Power Platform的各个方面，因此您可以完全控制，自动化和增强业务。 借助标准实体和字段，以及轻松定义数据之间关系的能力，Common Data Service专为那些需要功能强大，可扩展的解决方案的用户而构建。
现在，您已经阅读了本模块，您应该能够：
- 描述通用数据服务
- 描述通用数据模型
- 识别实体，字段和关系
- 创建环境
- 定义业务规则
关键点
- Common Data Service使用标准实体，字段和关系来帮助您构建功能强大的可扩展数据解决方案
- 使数据为您服务，以便将数据分成多个逻辑块，从而充分利用数据。
- 使用通用数据服务，您可以将数据分为各种环境，以更好地管理和保护重要信息。
资源
Common Data Service
- Introduction to Common Data Service
- Common Data Service Documentation
- Common Data Model
- [Licensing](https://download.microsoft.com/download/9/5/6/9568EFD0-403D-4AE4-95F0-7FACA2CCB2E4/Power Apps and Power Automate Licensing Guide - Nov 2019.pdf)
Entities, fields, and relationships
- Create and Manage Entities in Common Data Service
- Complex entities
- Restricted entities requiring Dynamics 365 licenses
- Create and manage fields within an entity in Common Data Service
- Create a relationship between entities in Common Data Service
