设计一个好的数据架构(DA)通常意味着一个设计良好的应用程序的不同。学习设计支持企业项目的最佳逻辑和物理数据模型的策略。
在设计DA时，Salesforce与其他平台之间存在一些关键差异，对于理解这些差异至关重要。
了解Salesforce与其他数据库应用程序之间的差异。
- Salesforce看起来和感觉像传统的OLTP关系数据库。但是，在幕后，它的架构有很大不同，以支持多租户，动态更改和特定于平台的功能。不要假设数据模型从旧世界无缝过渡到新世界。
- 您的数据与其他租户位于同一位置。尽管这可能会引起安全问题，但在学习平台上的可伸缩性阈值和调控器限制方面，它将对您造成更大的影响。
- 与传统数据库不同，Salesforce数据无法通过其查询引擎进行动态连接。而是“连接”基于对象之间的预定义关系。因此，数据模型设计至关重要，了解UP-FRONT的报告要求是成功的关键因素。
- Salesforce不是数据仓库（也不打算这样做）。建议的数据策略是拥有所需的数据，并删除不需要的数据。虽然这听起来像一个非常简单的概念，但要实现起来却要困难得多。
让我们逐步完成设计企业数据架构的过程。一个有效的DA设计将经历以下大多数（如果不是全部）步骤：
步骤1 –定义逻辑数据模型（LDM）
良好的DA始于良好的逻辑设计。这意味着您已经花了时间记录您的业务对业务的描述。您具有对业务有意义且至关重要的业务实体和关系的目录。您应该在不考虑逻辑基础的情况下构建逻辑模型。目的是定义将指导您完成数据设计过程的LDM。确保考虑任何与行业相关的标准（HL7，Party Model等）。
步骤2 –定义您的企业数据策略（包括主数据管理）
超出本文范围（但对于企业实施完全必要）的是定义您的企业数据策略。从理论上讲，Salesforce应该是一个关键组成部分，但也应服从于您的企业数据策略。它将通过以下某些方式影响Salesforce DA：
- 是否有客户主数据或主数据管理系统，如果有，涉及哪些LDM实体？
- 数据保留要求是什么？
- 企业数据仓库如何以及何时接收数据？
- 是否有运营数据存储可用于将实时数据推入或拉出到Salesforce？
步骤3 –记录LDM中每个实体的数据生命周期
LDM中的每个实体都有其自己的生命周期。捕获，记录和分析每个特定实体至关重要。这样做将帮助您以后了解如何将实体整合（或不整合）到对象中，如何构建分层策略，甚至如何构建治理模型。
- 每个实体的真理之源在哪里？Salesforce是记录系统还是它的使用者？
- 如何创建，编辑和删除数据？Salesforce是这些行动的唯一场所吗？这些动作中是否会发生在Salesforce之外？
- 该实体需要什么类型的指标和报告？这些指标当前从何处提取数据，并且将来会从何处获取数据？
- 谁从业务角度“拥有”数据？谁能告诉您数据是对还是错？谁来管理实体并确保其质量？
- 该实体启动了哪些业务流程？哪些受到影响？
- 获得有关主实体和交易的数据大小的一些估计。当涉及大数据量（LDV）时，这将非常重要。
步骤4 –将实体和基数转换为对象和关系
是时候开始将LDM转换为物理数据模型（PDM）了。这是一门艺术，而不是一门科学，我绝对建议与在Salesforce平台上知识渊博的人紧密合作。
- 合并对象和关系是可能的。评估折叠实体的合理位置，尤其是基于与其他对象的公共关系。
- 在这里，记录类型成为Salesforce设计的重要方面。可以使用记录类型，页面布局和条件逻辑设计来对一个公共对象进行分叉。我使用的一个通用架构原则是：“ 解决方案越通用，解决方案就变得越灵活”
- 合并对象的权衡是要考虑将使用该对象的LOB和您的（即将推出的）分层策略。出于技术，治理和/或变更管理的原因，将实体隔离可能是有意义的。
- 合并对象的另一个缺点是需要对自定义进行分区。准备在逻辑实体级别编写不同的类/ Web服务/集成。例如，如果有6个实体要覆盖“帐户”对象，则您将需要“业务客户”，“设施位置”，“业务合作伙伴”等的自定义逻辑，所有逻辑都在“封面”下打到“帐户”对象。
步骤5 –确定是否覆盖标准对象
另一个困难的决定是何时覆盖标准对象与构建自定义对象。再说一遍，这是一门艺术，而不是科学，但与此主题相关的一些重要考虑因素：
- 为什么需要标准对象功能？如果您使用自定义对象路线，Salesforce是否提供开箱即用的功能，您必须构建自己的功能？（例如，案件升级规则，客户团队，社区访问权限等）
- 考虑自定义与标准之间的许可证影响。平台许可证不提供机会和案例之类的标准对象。
- 世界上的每个“事物”都可以归纳为一个帐户对象，而世界上的每个“事件”都可以归纳为一个案例。这些类型的实现很难维护。
步骤6 –定义企业对象分类和分层策略
对象分类和分层是企业Salesforce DA的重要组成部分。我尝试将对象分为3个不同的类别–但是，根据您的体系结构设计，您可能会有更多或更少的对象。
- 核心数据 –这是系统的核心数据，在工作流，顶点，visualforce，集成，报告等方面具有很多复杂性。对这些对象的更改必须格外谨慎，因为它们是整个组织的基础。通常，它们在多个业务线（例如帐户对象）之间共享，具有LDV（例如任务）或复杂性（例如共享对象）。信息技术应严格锁定这些对象的元数据和安全性。IT部门负责维护这些对象中的数据。
- 托管数据 –这是特定LOB的核心数据，但不影响系统的其他区域。根据系统中LOB的数量，这可能会与“机会”或“案例”对象类似，也可能不会。对象在其工作流程和自定义要求方面仍然具有很高的复杂性，但是对象和代码被区域化为单个LOB。在此层中，您可以使业务管理员能够管理其LOB的数据。实际上，将这些对象的数据管理推入业务对于您在平台上进行扩展的能力至关重要。
- 委托的管理数据 –这些通常是为特定的LOB创建的自定义对象，并且与系统的其他区域完全隔离。它们通常是具有非常简单的工作流和业务流程的“电子表格应用程序”或小型应用程序。因此，应将这些对象的数据和元数据交给业务和委派的管理员。这些对象非常适合企业内的Citizen Developers，因为您使企业能够在复杂的环境中制作自己的应用程序。
您还可以使用分层策略来协助归档（如下）。由于可以将数据移出核心层并移入委托层，因此可以提高可伸缩性，敏捷性甚至性能。只要确保您没有在DA中创建数据重复和冗余即可。
步骤7 –设计您的安全模型和数据可见性标准
我为企业DA建议的另一个架构原则是“ 最小权限原则 ”。 这意味着除非特别要求，否则任何配置文件都不应被授予对应用程序，对象或字段的访问权限。但是，我不建议将整个共享模型设为私有。这会在共享设计中造成重大而不必要的复杂性。不必要的私有数据将导致数据重复问题，并可能导致性能影响。
步骤8 –设计物理数据架构
现在是构建PDM的时候了。我将其称为“框架”，因为这将是您第一次开始在Salesforce中看到您的解决方案。
- 开始为您的LDM中的每个合并实体映射一个对象。
- LDM的哪些实体对于在Salesforce中保持持久性是必需的？哪些实体可以与平台隔离？不用于调用业务流程（工作流/触发器/等）的数据是应保留在平台之外的候选对象。
- 请勿在可能的情况下为查询创建对象。尽可能多地利用选择列表和多选择列表，以“扁平化”数据模型。
- Salesforce对象更像大型电子表格。与更传统的规范化数据库相比，在许多情况下将有许多列和非规范化数据。
- 对LDM进行先前的批量估算，然后将其重新应用于您的合并设计。现在，对于您正在考虑的每个合并实体，您应该有一个大致的数量级。此时，请尝试获取特定的卷。这对于许可和LDV变得非常重要。
- 确保您已经考虑了多对多关系，因为这些“连接对象”具有在企业环境中增长很大的能力。
- 数量在百万级的任何对象都应考虑受到LDV的影响。虽然不在本文讨论范围之内，但您可能需要考虑对PDM进行更改，以尽可能地减少交易量。
- Salesforce中的数据复制和复制是可以的。（数据架构师请坐下。）有时有必要使用这些皱眉的方法来支持业务流程。当您打破企业数据架构的某些传统规则（尤其是规范化）时，Salesforce的运行效果最佳。
就平台外的数据而言……我建议将数据保留在不需要的平台外。您希望Salesforce成为企业中的护卫舰（快速，敏捷，性感）而不是实用车（缓慢，僵硬，令人毛骨悚然）。
步骤9 –定义企业范围和组织范围内的数据标准
现在是时候为数据模型建立一套标准了。您需要考虑字段标签和API名称，以及要在每个对象上维护的公共字段。为您的记录类型提供企业模型也很重要。
以下是我想做的事情：
- 我在每个对象上创建记录类型。第一个记录类型通常具有通用名称，例如<Company Name>。（例如Dell，IBM，Google等）。如果从头开始使用记录类型，将来重构对象会容易得多。
- LOB特定的记录类型始终以LOB标记开头（例如CC –“联系中心”的事件）
- LOB特定的对象和字段的API名称中应带有LOB标记。（例如CC_Object__c，CC_Field_Name__c）
- 根据您期望在给定对象上具有的字段数，考虑对API名称进行标记（例如CC_FldNm__c）。当您达到SOQL查询中可以提交的字符数限制时，这将极大地节省您的时间。
- 我在每个对象上创建公共字段。“标签”和“超链接”之类的字段可以包含易于在相关列表，报告和电子邮件模板上使用的业务友好名称和URL。
- 我通常使用工作流或触发器将ID字段复制到自定义字段。稍后在尝试将完整副本沙箱数据与其他系统集成时，这将为您提供极大的帮助。（如果可以避免的话，我从不使用Salesforce ID进行集成）。
您可能会或可能不想遵循这些。关键是创建您的标准，从一开始就以这种方式实施，并控制您的实施以确保您的标准得到遵守。
第10步–定义存档和保留策略
尽管Salesforce在保护数据安全方面拥有悠久的历史和声誉，但是您仍然对组织有责任从Salesforce中复制和归档数据。以下是一些注意事项：
- 您可能会破坏自己的Salesforce数据，而不是使它们遭受数据丢失。如果您需要尝试将数据恢复到较早的状态，但是成熟的企业需要具备在这一领域自给自足的能力，那么Salesforce将为您提供帮助。
- 从Salesforce提供每周备份，对于SMB可能很好，但是我建议每晚复制一次。有合作伙伴解决方案可以简化这一过程，或者您可以使用Salesforce API构建自定义解决方案。
- 我会将复制的副本用于2个目的。一种是根据需要提供数据仓库。另一个用于恢复目的。我不会将复制的副本用于报告，也不会尝试将复制的副本用于任何实时集成需求。这给您的技术环境增加了不适当的负担，并将您的云解决方案与内部部署基础架构联系在一起。将Salesforce与您现有的IT基础架构紧密耦合可能会削弱您在云中的敏捷性和灵活性。
步骤11 –定义您的报告策略
您的架构已定义。您知道哪些数据将在平台上，哪些数据将在平台外，以及所有这些数据的最佳来源在哪里。是时候为您的Salesforce数据定义报告策略了。根据您的数据体系结构，您的策略将有所不同-但我将建议在大型企业中成功使用的以下准则。
- 如果可能，应在平台上进行操作报告。支持业务流程所需的数据有望在平台上运行足够长的时间，以运行您的运营报告。
- 分析报告应在平台之外完成。使用构建在数据仓库上的传统BI工具来获得长期运行，趋势和复杂的报告。
- 尽可能使用现成的报告和仪表板。尝试让您的主管和利益相关者直接从Salesforce获得他们需要的报告。
- 考虑用于平台外报告解决方案的混搭策略。某些第三方提供的应用程序将无缝集成到Salesforce UI中，因此用户无需离开应用程序。
- 考虑在适当的地方使用Visual Force或Canvas构建自定义报告。您将用户留在平台中的次数越多，您将保持的影响力和动力就越大。随着用户转向使用其他报告工具，他们的兴趣，注意力和资金也将随之而来。
- 不要报告您已复制的Salesforce数据库。如果需要分析数据，则将该数据移入数据仓库，并将用户保留在Salesforce中以获取实时数据。离线Salesforce报表只会使用户感到困惑，并导致有关数据延迟和质量的不当问题。
步骤12 –重复
就像企业体系结构一样，定义数据体系结构是迭代的，并且会不断改进。每次您进行迭代时，都会增加对平台的了解，成熟度和能力。随着您改善数据体系结构，Salesforce部署的商业价值也将增加。
