通过Techopedia Staff，2016年9月28日
要点：主持人Rebecca Jozwiak与OSTHUS的Eric Little，First San Francisco Partners的Malcolm Chisholm和IDERA的Ron Huizenga讨论了数据架构解决方案。
您目前尚未登录。请登录或注册以观看视频。
丽贝卡·乔兹维克（Rebecca Jozwiak）：女士们，先生们，您好，欢迎来到2016年热门技术。今天，我们正在讨论“构建业务驱动的数据体系结构”，这绝对是一个热门话题。 我叫Rebecca Jozwiak，我将主持您今天的网络广播。 我们会使用#HotTech16的标签发布推文，因此，如果您已经在Twitter中，请随时加入。 如果您有任何问题，请将其发送到屏幕右下方的“问答”窗格，我们将确保为您解答。 如果没有，我们将确保我们的客人为您找到他们。
所以今天我们有了一个非常有趣的阵容。 今天有很多沉重的打击者与我们同在。 我们有OSTHUS数据科学副总裁Eric Little。 我们拥有首席创新官Malcolm Chisholm，这对于First San Francisco Partners来说是一个非常酷的头衔。 我们还有IDERA的高级产品经理Ron Huizenga。 而且，您知道IDERA确实提供了全套的数据管理和建模解决方案。 今天，他将向我们演示其解决方案的工作原理。 但是在开始之前，埃里克·利特尔，我将球传给你。
埃里克·利特尔：好的，非常感谢。 因此，我将在这里讨论几个主题，这些主题与Ron的演讲有一些联系，并希望为其中一些主题以及一些问答环节打下基础。
因此，令我对IDERA所做的事情感兴趣的是，我认为他们正确地指出，当今复杂的环境确实在推动着许多商业价值。 所谓复杂环境，是指复杂的数据环境。 技术的发展日新月异，很难跟上今天的商业环境。 因此，那些在技术领域工作的人经常会看到您的客户正在解决以下问题：“我如何使用大数据？ 如何整合语义？ 我该如何将其中的一些新内容与我的较旧数据关联起来？”等等，这种情况如今使我们进入了许多人都非常熟悉的大数据的这四个维度，而且我知道可以有四个以上有时-我看过多达八到九个-但是通常，当人们谈论大数据之类的东西时，或者如果您谈论大数据，那么通常您会看到的是企业规模的东西。 因此，人们会说，好吧，请考虑一下您的数据量，这通常是重点-就是您拥有的数据量。 数据的速度与我可以移动数据的速度或查询或获得答案的速度等等有关。 我个人认为，左侧是通过许多不同方法可以相对快速地解决和处理的问题。 但是在右侧，我看到了很多改进功能和许多新技术真正地应运而生。 这实际上与第三列有关，即数据种类。
换句话说，当今大多数公司都在研究结构化，半结构化和非结构化数据。 图像数据开始成为热门话题，因此能够使用计算机视觉，查看像素，能够抓取文本，NLP，实体提取，您所拥有的图形信息要么来自统计模型，要么来自语义在模型中，您具有表中现有的关系数据，依此类推。 因此，将所有这些数据以及所有这些不同类型汇总在一起确实是一个巨大的挑战，并且您会在Gartner和其他追随行业趋势的人们中看到这一点。
然后，人们在大数据中谈论的最后一件事通常是可变性的概念，这实际上是数据的不确定性和模糊性。 您对数据的了解程度如何，对数据的了解程度如何，您知道吗？ 使用统计信息的能力和使用围绕您可能知道的信息的某种类型的信息或使用某些上下文的能力在这里可能会很有价值。 因此，您可以通过这种方式查看数据的能力，包括您拥有的数据量，迁移或获取数据所需的速度，企业中可能拥有的所有数据类型以及对位置的确定性它是什么，它是什么质量，等等。 确实，这需要大量个人之间进行大量协调的工作才能有效地管理其数据。 因此，数据建模在当今世界中变得越来越重要。 因此，好的数据模型确实在企业应用程序中取得了很多成功。
就像我们所说的那样，您拥有来自各种来源的数据源，这实际上需要进行许多不同类型的集成。 因此，将所有内容汇总在一起对于能够例如跨多种类型的数据源运行查询并向后拉信息非常有用。 但是，要做到这一点，您需要良好的映射策略，因此映射这些类型的数据并保持这些映射可能是一个真正的挑战。 然后，您遇到了一个问题，如何将旧数据链接到所有这些新数据源？ 因此，假设我有图表，是否可以将所有关系数据放入图表中？ 通常这不是一个好主意。 那么人们如何管理正在发生的所有这些数据模型呢？ 实际上，必须对许多不同种类的数据源及其组合进行分析。 因此，由此得出的答案，人们真正做出良好业务决策所需的答案至关重要。
因此，这不仅仅是为了技术而构建技术，而是，我将要做什么，该如何做，可以进行什么样的分析以及因此而拥有的能力，一直在谈论，把这些东西放在一起，整合起来是非常非常重要的。 然后，这些类型的分析之一就可以在联合搜索和查询之类的东西上运行。 这真的成为必须。 您的查询通常必须跨多种源进行处理，并以可靠的方式拉回信息。
经常（尤其是人们）会看一下诸如语义技术之类的关键要素，这是我希望罗恩（Ron）在IDERA方法中谈论的一些要素-您如何分离或管理是从数据层本身还是从原始数据中获取数据的模型层？ 因此，在数据层下面，您可能有数据库，可能有文档数据，可能有电子表格数据，可能有图像数据。 如果您在制药行业等领域，则拥有大量的科学数据。 然后，在此基础之上，人们通常会寻找一种构建模型的方法，该模型可以使他们快速集成数据，而实际上，当您在寻找数据时，您现在并不想将所有数据都放入模型层中，您正在查看模型层要做的是，为您提供事物，通用词汇表，实体和关系的常见类型以及真正进入数据所在位置的能力的良好逻辑表示。 因此，它必须说出它是什么，并且必须说出它在哪里，并且必须说出如何去获取它并将其带回。
因此，这种方法在推动语义技术向前发展方面非常成功，这是我经常工作的领域。 因此，我想为罗恩（Ron）提出一个问题，并且我认为该问题将在“问答”部分中有用，以查看IDERA平台如何完成此工作？ 那么模型层实际上是与数据层分开的吗？ 它们更整合了吗？ 这是如何工作的，他们从他们的方法中看到的结果和收益是什么？ 因此，参考数据实际上也变得至关重要。 因此，如果要使用这些类型的数据模型，并且要能够联合起来并在各个事物之间进行搜索，则实际上必须具有良好的参考数据。 但是问题是参考数据确实很难维护。 因此，经常为它们本身命名标准是一个困难的挑战。 一组将称为X，一组将称为Y，现在您遇到的问题是，某人在寻找此类信息时如何找到X和Y？ 因为您不想只给他们一部分数据，所以想给他们所有相关的信息。 同时更改术语，弃用软件，依此类推，如何随着时间的推移保持和维护参考数据？
再者，语义技术，特别是使用分类法和词汇表，数据字典之类的东西，已经提供了一种标准的空间方式来做到这一点，它确实非常健壮，它使用了某些标准，但是数据库社区却这样做了。时间长了，只是方式不同。 我认为这里的关键之一是考虑如何使用实体关系模型，如何使用图形模型或某种类型的方法，这实际上希望为您提供一种标准的空间方式来处理参考数据。 当然，一旦有了参考数据，映射策略就必须管理各种各样的名称和实体。 因此，主题专家通常喜欢使用自己的术语。
因此，这始终是一个挑战，您如何给某人提供信息，但使其与他们谈论信息的方式相关？ 因此，一个小组可能有一种看待事物的方式，例如，您可能是从事某种药物的化学家，您可能是从事同一药物的结构生物学家，并且对于相同类型的实体您可能使用不同的名称与您的领域有关。 您必须找出将这些个性化术语组合在一起的方法，因为另一种方法是，您必须强迫人们放弃他们的术语，而使用他们通常不喜欢的其他术语。 这里的另一点是，处理大量同义词变得很困难，因此许多人的数据中有许多不同的词可以引用同一事物。 您在使用多对一关系集时存在参考问题。 专业术语因行业而异，因此，如果您要针对此类数据管理提出一种总体解决方案，那么从一个项目或一个应用程序到另一个应用程序的移植性有多容易？ 那可能是另一个挑战。
自动化很重要，这也是一个挑战。 手动处理参考数据非常昂贵。 必须保持手动映射是很昂贵的，而让主题专家停止日常工作又不得不继续修改数据字典和重新更新定义等等，这是很昂贵的。 可复制的词汇表确实具有很大的价值。 因此，这些词汇通常可以在组织外部找到。 例如，如果您在原油中工作，那么您可以从开源空间中借用某些种类的词汇，与制药，银行业和金融业以及许多此类领域一样，您可以从开源空间中借用。 人们将可重用的，通用的，可复制的词汇摆在那里供人们使用。
而且，再次看一下IDERA工具，我很好奇看到他们在使用各种标准方面是如何处理的。 在语义世界中，您经常会看到诸如SKOS模型之类的事物，这些事物至少为关系提供了比关系更广泛/更狭窄的标准，而这些事情在ER模型中可能很难做到，但您知道，并非没有，这取决于其中的多少机械和那些您可以在这些类型的系统中处理的链接。
因此，最后，我只想与我在行业中看到的一些语义引擎进行比较，然后问Ron并给他一些介绍，以谈论IDERA的系统如何与任何语义技术结合使用。 它能够与三重存储，图形数据库集成吗？ 使用外部资源有多么容易，因为语义世界中的这些东西通常可以使用SPARQL端点来借用？ 您可以将RDF或OWL模型直接导入模型中-重新引用它们-例如，基因本体或蛋白质本体，它们可以通过自己的治理结构生活在自己的空间中，而我可以简单地导入所有或因为我需要将其纳入我自己的模型中 我很想知道IDERA如何解决这个问题。 您是否必须在内部维护所有内容，或者是否有办法使用其他类型的标准化模型并将其引入，以及它如何工作？ 我在这里提到的最后一件事是，构建词汇表和元数据存储库实际上需要多少人工工作？
因此，我知道Ron将会向我们展示这些事情的一些演示，这将非常有趣。 但是我经常看到的与客户协商的问题是，如果人们使用自己的定义或元数据来编写，则会发生很多错误。 因此，您会拼错拼写，会遇到胖手指错误，这是一回事。 您还会得到一些人，他们可能会从Wikipedia或某些来源中获取某些信息，这些信息不一定具有您定义中想要的质量，或者您的定义仅出于一个人的角度，因此并不完整，因此不清楚治理流程如何运作。 当然，无论何时您在谈论参考数据以及何时在谈论参考数据如何适合某人的主数据，他们将如何使用其元数据，以及治理，这都是一个非常非常大的问题。以此类推。
所以我只想把其中一些话题放在那儿。 我在业务领域中看到的这些项目涉及许多不同类型的咨询业务和许多不同的领域，我真的很想知道Ron将通过IDERA向我们展示什么，以指出其中一些主题。 非常感谢您。
丽贝卡·乔兹维克（Rebecca Jozwiak）：非常感谢埃里克（Eric），我非常喜欢您的评论，如果人们编写自己的定义或元数据，可能会发生许多错误。 我知道在新闻界，有一种咒语是“很多眼睛几乎不会犯错误”，但是当涉及到实际应用时，饼干罐中的太多手会留下很多碎饼干，对吗？
埃里克·利特尔（Eric Little）：是的，还有细菌。
丽贝卡·乔兹维克（Rebecca Jozwiak）：是的。 这样，我将继续将其传递给Malcolm Chisholm。 马尔科姆，地板是你的。
马尔科姆·奇斯霍尔姆：非常感谢，丽贝卡。 我想稍微回顾一下Eric一直在谈论的内容，并补充一些观察结果，您知道，Ron可能还会在回应“迈向业务驱动的数据体系结构”时做出回应” –业务驱动意味着什么，为什么如此重要？ 还是仅仅是某种形式的炒作？ 我认为不是。
如果我们观察一下发生了什么事，您知道，大型机实际上是在1964年左右才对公司可用的，直到今天，我们可以看到发生了很多变化。 这些变化我可以概括为从以流程为中心向以数据为中心的转变。 这就是使业务驱动的数据体系结构在当今如此重要且如此相关的原因。 而且我想，您知道，这不仅是一个流行词，而且是绝对真实的东西。
但是，如果我们重温历史，我们会更加欣赏它，因此可以追溯到1960年代，此后的一段时间里，大型机占据了主导地位。 然后，这些方法让位给了PC，在PC出现时，您实际上已经在反叛用户。对集中IT的反叛（他们认为他们不能满足他们的需求）还不够敏捷。 当PC连接在一起时，很快就产生了分布式计算。 然后，互联网开始发生，这模糊了企业的边界-它现在可以在数据交换方面与自身外部的各方进行交互，这是以前从未发生过的。 现在我们进入了云计算和大数据时代，其中云是真正使基础设施商品化的平台，因此，我们不再需要运行大数据中心的IT，因为我们知道我们已经拥有了可用的云容量，并且与埃里克（Eric）如此雄辩地讨论的大数据相伴。 总体而言，正如我们所看到的，随着技术的变化发生，它已经变得更加以数据为中心，我们更在乎数据。 与互联网一样，数据是如何交换的。 对于大数据，数据本身具有四个或更多的v。
同时，也许更重要的是，业务用例发生了变化。 首次引入计算机时，它们被用来使书籍和记录等自动化。 涉及分类帐或类似内容的任何手动过程，基本上都在内部进行编程。 到了80年代，这种方式转向了可操作的软件包。 您不再需要编写自己的工资单，您可以购买完成此任务的产品。 这导致许多IT部门当时的规模缩小或重组。 但是随后出现了带有数据仓库之类的商业智能，大多出现在90年代。 其次是互联网狂热的商业模式。 然后是MDM。 使用MDM，您开始发现我们不考虑自动化。 我们实际上只是专注于将数据作为数据进行管理。 然后进行分析，代表您可以从数据中获得的价值。 在分析中，您会看到非常成功的公司，其核心业务模型围绕数据展开。 谷歌，推特，脸谱网将是其中的一部分，但您也可以说沃尔玛就是其中之一。
因此，企业现在正在真正考虑数据。 我们如何从数据中获取价值？ 数据如何驱动业务，战略以及我们正处在数据的黄金时代。 因此，鉴于此，如果不再只是将数据视为仅来自应用程序后端的精疲力尽，而是对我们的业务模型至关重要的数据，那么就我们的数据体系结构而言，这是怎么回事？ 嗯，我们要实现的部分问题实际上是IT真正滞留在过去的系统开发生命周期中，这是由于在IT早期必须迅速处理该流程自动化阶段并在项目是类似的事情。 对于IT来说（这有点讽刺意味），但是我想说的是，获得业务驱动的数据体系结构的一些障碍是因为我们已经不加批判地接受了IT文化这源于过去的年龄。
所以一切都是一个项目。 告诉我您的详细要求。 如果事情不起作用，那是因为您没有告诉我您的要求。 嗯，今天这对数据不起作用，因为我们不是从非自动化的手动流程开始，或者不是业务流程的技术转换，而是我们经常从我们正在尝试的现有生产数据开始以获得价值。 但是，没有谁赞助以数据为中心的项目的真正了解该数据的深度。 我们必须进行数据发现，我们必须进行源数据分析。 而且，这与系统开发并没有真正的契合，瀑布式，SDLC生命周期，我认为敏捷是一种更好的版本。
重点是技术和功能，而不是数据。 例如，当我们在测试阶段进行测试时，我的功能是否正常运行（例如，我的ETL），但我们并未在测试数据。 我们不会测试关于输入源数据的假设。如果这样做，我们的状态可能会更好，并且作为完成数据仓库项目并遭受上游变更，破坏我的ETL的人，我将不胜感激。 实际上，我们希望看到的是测试，这是持续监控生产数据质量的第一步。 因此，由于我们受制于以流程为中心的时代，因此我们有很多态度很难实现业务驱动的数据架构。 我们需要过渡到以数据为中心。 您知道，这并不是一个完全的过渡，仍然有很多流程工作要做，但是我们并没有真正在需要时以数据为中心进行思考，而在真正必须这样做。
现在，企业意识到数据的价值，他们想解锁数据，那么我们该如何做呢？ 那么我们如何进行过渡呢？ 好吧，我们将数据置于开发流程的核心。 并且，我们让业务领先于信息需求。 而且我们了解到，在项目开始时没有人了解现有的源数据。 您可能会争辩说数据结构和数据本身分别是通过IT和运营到达的，所以我们应该知道，但实际上，我们没有。 这是以数据为中心的开发。 因此，我们必须考虑在以数据为中心的世界中在何处以及如何进行数据建模，在进行数据发现和数据剖析时，我们必须在优化用户信息需求方面向用户提供反馈环，预见源数据分析，以及随着我们逐渐获得关于数据的越来越确定性。 现在，我说的是一个更传统的项目，例如MDM集线器或数据仓库，不一定是大数据项目，尽管我认为这仍然非常接近。 因此，这些反馈回路包括数据建模人员，您知道这些数据建模人员逐步推进他们的数据模型并与用户进行交互，以确保根据可能的，可用的，来自源数据的信息需求来完善信息需求，因为他们更好地了解了这些信息，因此您知道，数据模型不再存在或处于未完成状态，这是逐渐成为其关注焦点的情况。
同样，在下游，我们有质量保证，我们在其中制定数据质量测试规则，以确保数据在我们假设的参数范围内。 进入时，Eric指的是参考数据中可能发生的更改。 您并不想成为该领域某种不受管理的变更的下游受害者，因此质量保证规则可以用于后期制作，连续数据质量监控。 因此，您可以开始看看我们是否将以数据为中心，我们如何进行以数据为中心的开发与基于功能的SDLC和Agile完全不同。 然后，我们还必须注意业务视图。 我们拥有了一个数据模型，为我们的数据库定义了一个数据故事蓝图，这再次回应了埃里克（Eric）的说法。但是，与此同时，我们需要那些概念性的模型，以及那些传统上无法在数据库中完成的业务视图。过去。 我认为有时我们认为数据模型可以完成所有工作，但是我们需要具有概念性视图，语义，并查看数据，然后通过抽象层将其渲染，该抽象层将存储模型转换为业务视图。 而且，再次，Eric在语义方面谈论的所有事情都变得很重要，因此我们实际上还有其他建模任务。 我想这很有趣，如果您像我一样以数据建模人员的身份晋升，并且又有了新的东西。
最后，我想说的是更大的体系结构也必须反映出这个新现实。 例如，传统的客户MDM很好，让我们将客户数据放入一个中心，我们可以在其中了解后台应用程序的数据质量。 从业务战略的角度来看，这是一种打哈欠。 但是，今天，我们正在寻找具有更多客户配置文件数据的客户MDM集线器，而不仅仅是静态数据，后者确实具有与客户交易应用程序的双向接口。 是的，他们仍然支持后台，但是现在我们也了解了客户的这些行为。 建造成本更高。 构建起来比较复杂。 但这是业务驱动的，而传统的客户MDM则不是。 您正在权衡针对企业的定位和易于实现的较简单设计，但是对于企业而言，这就是他们想要看到的。 我们真的处在一个新时代，我认为必须对业务驱动的数据体系结构做出许多反应，并且我认为这是一个非常激动人心的时刻。
因此，谢谢您，丽贝卡。
丽贝卡·乔兹维克（Rebecca Jozwiak）：谢谢马尔科姆（Malcolm），我真的很喜欢您所说的数据模型必须满足业务视图的需要，因为，与您所说的不同，IT掌管了很长时间，这种情况已经不复存在了，文化确实需要转变。 而且我非常确定背景中有一只狗会100％同意您的意见。 然后我将球传给罗恩。 我很高兴看到您的演示。 罗恩，地板是你的。
罗恩·休曾加（Ron Huizenga）：非常感谢，在我们开始之前，我将先浏览几张幻灯片，然后再进行一些演示，因为正如埃里克（Eric）和马尔科姆（Malcolm）指出的那样，这是一个非常广泛而深入的话题，并且在我们今天谈论的内容中，我们只是将其表面化，因为我们真的需要从业务驱动的体系结构中考虑和研究很多方面和很多事情。 我们的方法是真正基于该模型并从模型中获得真实价值，因为您可以将它们用作通信工具以及用作启用其他系统的层。 无论您是在进行面向服务的体系结构，还是其他事物，该模型都将成为运行中的命脉，周围的所有元数据以及您业务中的数据。
不过，我要谈论的几乎是向后退一步，因为Malcolm谈到了解决方案发展方式和这类事情的一些历史。 真正指出拥有完善的数据体系结构的重要性的一种方法是，在我担任产品管理职位之前，我经常在咨询过程中碰到一个用例，也就是说，我会进入组织无论是进行业务转型还是只是替换某些现有系统和这类事情，组织很快就很清楚组织对自己数据的理解程度。 如果您采用这样一个特定的用例，无论您是咨询顾问，还是一个刚开始使用某个组织的人，或者您的组织是多年来通过收购其他公司而建立的，那么您最终会随之而来的是一个非常复杂的环境，很快，它具有许多新技术，旧技术，ERP解决方案以及其他所有功能。
因此，我们使用建模方法真正可以做的一件事就是回答以下问题：我如何理解所有这些？ 我们真的可以开始将信息整理在一起，以便企业可以充分利用我们拥有的信息。 结果表明，在这些环境中我们所拥有的是什么？ 如何使用模型排除我需要的信息并更好地理解该信息？ 然后，对于所有不同的事物，我们都有传统的元数据类型，例如关系数据模型，并且我们习惯于看到诸如定义和数据字典之类的东西，您知道数据类型以及那种类型的事物。 但是，要捕获以真正赋予其更多含义的其他元数据呢？ 例如，哪些实体实际上应该是参考数据对象的候选者，应该是主数据管理对象以及那些类型的事物并将它们联系在一起。 信息如何在组织中流动？ 从流程的角度来看，数据的使用方式不仅取决于数据的消耗方式，而且还涉及数据沿袭的范围，包括信息在我们企业中的传播历程以及如何通过不同的系统或通过数据存储来传播，因此我们知道当我们构建智能解决方案或这些类型的事物时，实际上是在为手头的任务使用正确的信息。
然后非常重要的是，我们如何才能使所有这些利益相关者，尤其是业务利益相关者进行协作，因为它们确实为我们提供了数据的真实含义。 最终，企业拥有数据。 它们提供了Eric所谈论的词汇和事物的定义，因此我们需要一个地方将所有这些联系在一起。 我们这样做的方法是通过我们的数据建模和数据存储库体系结构。
我要谈几件事。 我将要谈论ER / Studio Enterprise Team Edition。 首先，我将要讨论的是数据架构产品，我们将在其中进行数据建模以及这类事情，但是我将简要介绍一下套件中的许多其他组件。 您将看到Business Architect的一个片段，可以在其中执行概念模型，但也可以执行业务流程模型，并且可以将这些流程模型绑定在一起，以链接数据模型中的实际数据。 这确实有助于我们将这种纽带结合在一起。 Software Architect允许我们做一些额外的构造，例如一些UML建模和那些类型的事情，以便为我们正在谈论的其他系统和过程中的某些提供支持逻辑。 但是非常重要的是，当我们向下移动时，我们有了存储库和团队服务器，而我将把这看作是同一件事的两半。 存储库是我们根据业务词汇表和术语存储所有建模元数据以及所有业务元数据的地方。 而且由于我们拥有基于存储库的环境，因此我们可以在同一环境中将所有这些不同的东西缝合在一起，然后我们实际上可以将这些东西供消费使用，不仅对技术人员来说，对商人也一样。 这就是我们真正开始推动协作的方式。
然后，我将简要讨论的最后一部分是，当您进入这些环境时，不仅存在于数据库中。 您将拥有许多数据库，数据存储，并且还将有很多（我称之为传统工件）。 也许人们已经使用Visio或其他图表来绘制一些东西。 也许他们有其他建模工具和类似的东西。 因此，我们使用MetaWizard所做的实际上是提取一些信息并将其引入我们的模型中，使其成为当前的并且能够使用，再次以当前的方式使用，而不是仅仅呆在那里。 现在，它已成为我们工作模型的重要组成部分，这一点非常重要。
就像我说的那样，当您进入一个组织时，会出现许多不同的系统，许多ERP解决方案，错配的部门解决方案。 许多组织也在使用SaaS解决方案，这些解决方案也受外部控制和管理，因此我们不控制数据库以及这些主机上主机中的那些类型的事物，但是我们仍然需要知道数据的外观，当然，周围的元数据。 我们还发现，由于Malcolm所说的基于项目的方法，许多旧系统尚未被清除。 近年来，组织如何启动项目，替换系统或解决方案是令人惊讶的，但是通常没有足够的项目预算来淘汰过时的解决方案，所以现在它们就在路上。 我们必须弄清楚我们在环境中可以实际摆脱的是什么，以及将来有用的东西。 这与不良的退役策略有关。 那是同一件事的一部分。
我们还发现，由于从所有这些不同的解决方案中建立了许多组织，因此，我们看到了许多点对点接口，其中许多数据在许多地方四处移动。 我们需要能够对此进行合理化处理，并弄清楚我之前简要提到的数据沿袭，以便我们可以采用更紧密的策略，例如利用面向服务的体系结构，企业服务总线以及这些类型的事物，以传递正确的信息。到我们在整个业务中正确使用的发布和订阅类型的模型。 然后，当然，无论我们是使用数据仓库，具有传统ETL的数据集市还是使用一些新的数据湖，我们仍然需要进行某种分析。 这全都归结为同一件事。 这是所有数据，无论是大数据，还是关系数据库中的传统数据，我们都需要将所有这些数据放在一起，以便我们可以对其进行管理并知道我们在整个模型中要处理的内容。
同样，我们要做的复杂性是我们要执行许多步骤。 首先，您走进去，可能没有关于信息前景的蓝图。 在像ER / Studio Data Architect这样的数据建模工具中，您首先要进行很多逆向工程，要让我们指向那里的数据源，将它们引入，然后实际上将它们缝合在一起，以更具代表性。代表整个业务的模型。 重要的是，我们希望能够沿业务线分解这些模型，以便我们可以将它们与较小的部分相关联，而这些部分也可以与我们的业务人员以及我们的业务分析师和其他利益相关者相关联在上面。
命名标准非常重要，在这里我以几种不同的方式谈论它。 根据我们如何在模型中命名事物来命名标准。 在逻辑模型中，这很容易做到，在逻辑模型中，我们为模型提供了良好的命名约定和良好的数据字典，但是随后，对于要引入的许多物理模型，我们也看到了不同的命名约定。逆向工程师，我们经常会看到缩写名称以及我将要谈论的那种类型的东西。 而且，我们需要将其转换回对业务有意义的有意义的英文名称，以便我们能够了解环境中所有这些数据片段。 然后，通用映射就是我们将它们缝合在一起的方式。
最重要的是，我们将进一步记录和定义，在这里我们可以使用称为附件的东西对数据进行进一步分类，下面将向您展示几张幻灯片。 然后结束循环，我们想要应用该业务含义，这是我们绑定业务词汇表的地方，可以将它们链接到我们的不同模型工件，因此，当我们谈论某个业务术语时，我们知道在整个组织的数据中实施。 最后，我已经谈到了以下事实：我们需要所有这些都基于具有很多协作和发布功能的存储库，以便我们的涉众可以利用它。 我将很快谈论逆向工程。 我已经为您提供了一个非常快速的亮点。 我将在一个实际演示中向您展示，仅向您展示我们可以带入其中的一些东西。
我想谈谈在这种情况下我们将产生的一些不同的模型类型和图表。 显然，我们将在很多情况下进行概念模型的构建。 我不会在这上面花费很多时间。 我真的很想谈谈我们可以创建的逻辑模型，物理模型和特殊类型的模型。 而且很重要的一点是，我们可以在同一建模平台上全部创建它们，以便可以将它们缝合在一起。 这包括维度模型，也包括利用某些新数据源的模型，例如我将向您展示的NoSQL。 然后，数据沿袭模型是什么样的？ 接下来，我们将讨论如何将这些数据缝合到业务流程模型中。
我将在这里切换到建模环境，只是为了给您一个非常高而又快速的概述。 而且我相信您现在应该可以看到我的屏幕。 首先，我只想谈谈传统的数据模型类型。 当我们引入模型时，我们想要组织模型的方式是我们希望能够分解它们。 因此，您在左侧看到的是此特定模型文件中的逻辑和物理模型。 接下来的事情是，我们可以将其分解为业务分解，这就是为什么看到文件夹的原因。 浅蓝色的是逻辑模型，绿色的是物理模型。 我们还可以进行深入分析，因此在ER / Studio中，如果您进行了业务分解，则可以根据需要进行多个级别的深入或子模型处理，而在较低级别进行的更改将自动在较高级别反映出来水平。 因此，它很快就变成了功能非常强大的建模环境。
我还想指出的一点是，开始将这些信息汇总在一起非常重要的一点是，我们也可以拥有对应于一个逻辑模型的多个物理模型。 通常，您可能有一个逻辑模型，但是您可能在不同平台上以及这种类型的事物上都有物理模型。 也许是一个SQL Server实例，也许另一个是Oracle实例。 我们有能力在一个相同的建模环境中将所有这些联系在一起。 再说一遍，我在这里得到的是一个实际的数据仓库模型，它可以再次位于同一建模环境中，或者我们可以将其放在存储库中，也可以将其链接到不同的事物中。
我真正想向您展示的是我们所涉及的模型的其他内容和其他变体。 因此，当我们进入这样的传统数据模型时，我们习惯于看到带有列和元数据的典型实体以及那种类型的事物，但是当我们开始处理其中一些较新的NoSQL技术时，这种观点会迅速变化。 ，或者像某些人仍然喜欢称呼他们的大数据技术。
现在让我们说我们的环境中也有Hive。 如果我们在Hive环境中进行逆向工程，并且可以使用此完全相同的建模工具从Hive中进行正向工程和逆向工程，则我们会发现有些不同。 我们仍然将所有数据视为此处的构造，但我们的TDL不同。 那些曾经看过SQL的人，现在看到的是Hive QL，它非常像SQL，但是有了相同的工具，您现在可以开始使用不同的脚本语言。 因此，您可以在此环境中建模，并将其生成到Hive环境中，但同样重要的是，在我所描述的场景中，您可以对其进行反向工程并使其有意义并开始将其拼接在一起。
让我们再来一点不同。 MongoDB是我们本地支持的另一个平台。 当您开始使用具有文档存储区的JSON类型的环境时，JSON是另一种动物，并且其中包含与关系模型不对应的结构。 当您开始查询JSON并且传统的关系表示法中不存在这些概念时，您很快就会开始处理诸如嵌入式对象和嵌入式对象数组之类的概念。 我们在这里所做的是实际上已经扩展了表示法和目录，以便能够在相同的环境中进行处理。
如果您在此处向左看，则没有看到诸如实体和表之类的东西，而是将它们称为对象。 您会看到不同的表示法。 您仍然可以在此处看到典型的引用符号类型，但是我在此特定图中显示的这些蓝色实体实际上是嵌入式对象。 而且我们显示出不同的基数。 菱形基数表示它是一端的对象，但基数1意味着我们在发布者中拥有一个如果遵循该关系的对象，则具有嵌入式地址对象。 在查询JSON时，我们发现它与赞助人嵌入的对象结构完全相同，但实际上是作为对象数组嵌入的。 我们看到的不仅是通过连接器本身，而且如果您查看实际的实体，您会看到在赞助人下看到的地址也将其归类为对象数组。 您对如何将其引入有非常描述性的观点。
再说一次，到目前为止，我们在短短几秒钟内就已经看到了多层的传统关系模型，我们可以用Hive做同样的事情，我们可以用MongoDB和其他大数据源做同样的事情。好。 我们还可以做的是，我将很快向您展示这一点，我谈到了从其他不同领域引入事物的事实。 我假设我将从数据库中导入模型或对其进行逆向工程，但是我将从外部元数据中引入模型。 只是为了让您快速了解我们可以开始引入的所有不同类型的事物。
如您所见，我们有无数事物，实际上可以将元数据带入建模环境。 从诸如Amazon Redshift，Cassandra以及许多其他大数据平台之类的东西开始，所以您会看到其中列出的很多内容。 这是按字母顺序排列的。 我们看到了很多大数据源以及类似的东西。 我们还看到了许多传统的或更旧的建模环境，我们可以实际使用这些元数据。 如果我经过这里-并且我不会花时间在其中的每一个上-我们会在建模平台和数据平台方面看到很多可以借鉴的东西。 当我们开始谈论数据沿袭时，我们需要做的另一部分是非常重要的事情，在企业团队版上，我们还可以询问ETL源，无论是Talend还是SQL Server Information Services映射，我们都可以实际上也将其引入到我们的数据沿袭图表中，并对这些转换中发生的情况进行了描绘。 开箱即用，我们实际上有超过130个这些不同的桥梁实际上是Enterprise Team Edition产品的一部分，因此，它确实有助于我们将所有工件快速组合到一个建模环境中。
最后但并非最不重要的一点是，我还想谈一谈我们在进行数据仓库或任何类型的分析时需要其他类型的构造这一事实。 我们仍然希望有能力进行维模型之类的事情，其中有事实表，有维和那些类型的事物。 我还想向您展示的一件事是，我们还可以对元数据进行扩展，以帮助我们对维的类型以及其他所有内容进行分类。 因此，例如，如果我在此处查看“维度数据”标签，例如，其中的一个，它将根据它所看到的模型模式自动进行检测，并为您提供一个起点，让您确定它是维度还是事实表。 但是除此之外，我们可以做的是在维度之内，并且在这种类型的事物中，我们甚至拥有不同类型的维度，我们也可以使用这些维度对数据仓库类型的环境中的数据进行分类。 如此强大的功能，我们将其完美地结合在一起。
由于我现在处于演示环境中，因此我将跳到这一部分，并在回到幻灯片之前向您展示其他几件事。 我们最近添加到ER / Studio Data Architect中的一件事是，我们遇到了一些情况–这是在您处理项目时的非常常见的用例–开发人员以对象的方式思考，而我们的数据建模者倾向于根据表和实体以及此类事物进行思考。 这是一个非常简单的数据模型，但是它代表了一些基本概念，开发人员甚至业务分析师或业务用户可能会将其视为不同的对象或业务概念。 到目前为止，对这些分类一直非常困难，但是我们在2016年ER / Studio Enterprise Team Edition中实际完成的工作就是现在有了一个称为业务数据对象的概念。 允许我们做的是允许我们将实体或表的组封装到真正的业务对象中。
例如，我们在此新视图上看到的是Purchase Order标头和Order Line现在被拉到一起，它们被封装为一个对象，当我们保留数据时，我们会将它们视为工作单元，我们将它们组合在一起，因此现在很容易将其与不同的受众群体联系起来。 它们可在整个建模环境中重复使用。 它们是一个真实的对象，不仅是一个图形构造，而且还具有一个额外的好处，当我们从建模角度进行实际交流时，可以有选择地折叠或展开它们，以便为与特定利益相关者的受众对话提供汇总视图，当然，我们也可以保留更详细的视图，就像我们在这里看到的那样，以吸引更多的技术受众。 它确实为我们提供了一种非常好的交流工具。 现在，我们看到的是将多种不同的模型类型进行组合，并通过业务数据对象的概念对其进行扩充，现在我将要讨论的是，我们如何实际将更多含义应用于这些类型的事物，以及如何将它们组合在一起整体环境。
我只是想在这里找到我的WebEx，以便能够做到这一点。 然后我们回到热门技术幻灯片。 我将在此处快进一些幻灯片，因为您已经在模型演示本身中看到了它们。 我想非常快速地谈论命名标准。 我们要应用并执行不同的命名标准。 我们想要做的是，我们有能力将命名标准模板实际存储在我们的存储库中，从而通过单词或短语甚至缩写来基本建立该含义，并将它们重新绑定到有意义的英语类型的单词上。 我们将使用业务术语以及每个术语的缩写，我们可以指定顺序，大小写并添加前缀和后缀。 典型的用例是在人们建立逻辑模型然后实际创建物理模型的情况下，他们可能一直在使用缩写词和其他所有东西。
美丽的是，它同样强大，反之亦然，如果我们只能说出我们反向工程的某些物理数据库上的那些命名标准，我们可以取这些缩写，将它们变长单词，然后将它们倒退为英语短语。 实际上，我们现在可以为数据的外观派上专有名称。 就像我说的那样，典型的用例是我们将向前发展，从逻辑到物理，然后映射数据存储和此类事物。 如果您看一下右侧的屏幕快照，您会发现源名称中有缩写名称，并且当我们应用命名标准模板时，实际上我们有更多的全名。 如果需要，我们可以放置空格和类似的内容，这取决于我们使用的命名标准模板。 我们可以使其外观，但我们希望将其引入模型中。 只有知道了所谓的东西后，我们才能真正开始对它附加定义，因为除非我们知道它是什么，否则我们如何才能对其应用含义？
令人高兴的是，当我们做各种各样的事情时，我们实际上可以调用它。 我谈到了逆向工程，我们实际上可以在进行逆向工程时同时调用命名标准模板。 因此，在通过向导的一组步骤中，我们能够做的是，如果我们知道约定是什么，我们就可以对物理数据库进行反向工程，它将把它作为建模环境中的物理模型带回去，并且也将应用这些命名约定。 因此，我们将看到环境中相应逻辑模型中名称的类似英语的表示形式。 我们还可以做到这一点，并将其与XML Schema生成相结合，因此我们可以采用一个模型，甚至可以使用我们的缩写将其推出，而不管我们是在做SOA框架还是在进行此类事情，因此我们还可以推出不同的命名约定我们实际上已经存储在模型本身中。 它为我们提供了许多非常强大的功能。
再次，这是一个示例，如果我有一个模板，它将看起来像什么。 这实际上表明在命名标准公约中，我有EMP表示“员工”，SAL表示“工资”，PLN表示“计划”。 我还可以应用它们使它们在构建模型和放入模型时以交互方式运行。如果我使用此缩写，并且我在实体名称上键入“ Employee Salary Plan”，它将使用命名标准模板我已经在这里定义了，它在创建实体时会给我EMP_SAL_PLN并立即给我相应的物理名称。
同样，这对于我们进行设计和正向工程设计时也非常有用。 我们有一个非常独特的概念，这是我们真正开始将这些环境整合在一起的地方。 它被称为通用映射。 将所有这些模型引入环境后，假设我们现在已经应用了这些命名约定并且很容易找到它们，我们便可以执行此操作，我们现在可以在ER中使用一种称为通用映射的构造/工作室。 我们可以跨模型链接实体。 无论我们在哪里看到“客户”，我们都可能在许多不同的系统和许多不同的数据库中拥有“客户”，我们可以开始将所有这些链接在一起，以便在一个模型中使用时可以看到其他模型中客户的表现形式。 并且由于我们具有表示该模型的模型层，因此我们甚至可以将其绑定到数据源，并将其引入到我们使用过的数据库所在的查询中。 它确实使我们能够将所有这些紧密地结合在一起。
我已经向您展示了业务数据对象。 我还想非常快地谈论元数据扩展，我们称其为附件。 它的作用是使我们能够为模型对象创建其他元数据。 我经常会设置这些类型的属性，以从数据治理和数据质量的角度排除很多不同的事物，并帮助我们制定主数据管理和数据保留策略。 基本思想是创建这些分类，并且可以将它们附加在表级别，列级别和此类类型的任何位置。 当然，最常见的用例是实体是表，然后我可以定义：什么是主数据对象，什么是引用表，什么是事务表？ 从数据质量的角度来看，我可以按照对业务的重要性进行分类，以便我们可以对数据清理工作和此类事情进行优先排序。
经常被忽略的是，我们组织中不同类型的数据的保留策略是什么？ 我们可以进行设置，并且实际上可以将它们附加到我们的建模环境中，当然还有我们的存储库中的不同类型的信息工件中。 好处是，这些附件是否存在于我们的数据字典中，因此当我们在环境中利用企业数据字典时，可以将它们附加到多个模型中。 我们只需定义一次即可，并且可以在环境中的不同模型之间反复使用它们。 这只是一个快速屏幕截图，显示了您实际上可以在执行附件时指定要附加附件的所有内容。 这个示例实际上是一个值列表，因此当它们进入时，您可以从值列表中进行选择，您可以在建模环境中对所选择的内容进行很多控制，甚至可以设置默认值value是如果未选择值。 那里有很多力量。 他们生活在数据字典中。
我想在此屏幕上向您展示一些内容，此外，您会看到附件显示在顶部，在其下方您会看到数据安全性信息。 实际上，我们也可以将数据安全策略应用于环境中的不同信息。 对于不同的合规性映射，数据安全分类，我们提供了许多现成的功能，您可以直接生成并开始使用它们，但是您也可以定义自己的合规性映射和标准。 无论您正在执行HIPAA还是其他任何主动行动。 您实际上可以开始在您的环境中构建非常丰富的元数据集。
然后是术语表和术语-这就是业务含义的所在。我们经常有数据字典，组织经常以此为起点开始使用术语表，但是术语和术语是通常非常技术性。 因此，我们可以做的是，如果愿意的话，我们可以以此为出发点淘汰词汇表，但我们确实希望企业拥有这些词汇表。 我们在团队服务器环境中所做的事情是赋予人们创建业务定义的能力，然后我们可以将它们链接到它们在建模环境中对应的不同模型工件。 我们还认识到前面讨论的要点是，您输入的人越多，人为错误的可能性就越大。 我们在词汇表结构中还要做的是，我们确实支持词汇表的层次结构，因此我们可以在组织中使用不同的词汇表类型或不同类型的事物，但同样重要的是，如果您已经拥有这些资源中的一部分在这里定义了术语和所有内容之后，我们实际上可以进行CSV导入，以将其拉入我们的建模环境，团队服务器或词汇表中，然后从那里开始链接。 每次更改内容时，就定义和其他方面而言，都有完整的审核跟踪，包括前后映像的内容，以及不久的将来您还会看到的授权流程因此，我们可以真正控制谁来负责，委员会或个人的批准以及此类事务，从而使治理流程在我们前进的过程中更加健全。
当我们在团队服务器词汇表中拥有这些词汇表术语时，这对我们也起作用，这是我在此处提出的在模型本身中的实体中进行编辑的示例。 它可能具有链接的术语，但是我们也要做的是，如果该词汇表中的单词出现在此处实体的注释或描述中，这些单词会自动以较浅的超链接颜色显示，并且如果我们将鼠标悬停在它们上面，我们实际上还可以从业务词汇表中看到定义。 当我们使用信息本身时，它甚至为我们提供了更丰富的信息，其中包含所有词汇表术语。 它确实有助于丰富经验并将其含义应用到我们正在使用的所有内容中。
因此，再次，这是一个非常快的飞越。 显然，当我们深入研究不同部分时，我们可能会花很多时间，但这是飞越表面的快速过程。 我们真正要做的是了解那些复杂的数据环境。 我们希望提高所有这些数据工件的可见性，并与ER / Studio合作将其淘汰。 我们希望实现更有效和自动化的数据建模。 这就是我们正在讨论的所有类型的数据，无论是大数据，传统关系数据，文档存储还是其他任何数据。 再一次，我们实现了这一目标，因为我们对不同的平台以及您可能拥有的其他工具具有强大的正向和反向工程能力。 而这全是与参与的所有利益相关者在整个组织内共享和沟通的方式。 那就是我们通过命名标准应用含义的地方。 然后，我们通过业务词汇表应用定义。 然后，我们可以使用元数据扩展（例如数据质量扩展，主数据管理的分类或要应用于该数据的任何其他类型的分类）对所有其他治理功能进行进一步的分类。 然后，我们可以进一步总结并进一步增强与业务数据对象，不同利益相关者受众之间的交流，尤其是在建模人员和开发人员之间。
再者，对此非常重要的是，其背后是具有非常强大的变更管理功能的集成存储库。 我今天没有时间显示它，因为它相当复杂，但是该存储库具有非常强大的变更管理功能和审计跟踪。 您可以进行命名发布，可以进行命名版本，并且我们还可以为那些进行变更管理的人员提供功能，我们可以将其与您的任务联系起来。 今天，我们有能力放入任务并将您的模型更改与任务相关联，就像开发人员会将其代码更改与他们正在使用的任务或用户案例相关联一样。
同样，这是一个非常快速的概述。 我希望这足以激起您的胃口，以便我们在将来进行讨论时，可以就这些主题进行更深入的对话。 谢谢您的宝贵时间，再给您Rebecca。
丽贝卡·乔兹维克（Rebecca Jozwiak）：谢谢罗恩 ，那太好了，听众有很多问题要问，但是我想给我们的分析师一个机会，让他们全心投入您的发言。 埃里克（Eric），我要继续前进，也许如果您想对这张幻灯片或另一张幻灯片进行演讲，为什么不先开始？ 或其他任何问题。
埃里克·利特：当然。 抱歉，丽贝卡在问什么？ 您要我问一些具体问题还是……？
丽贝卡·乔兹维克（Rebecca Jozwiak）：我知道您最初对罗恩（Ron）有疑问。 如果您现在想让他解决这些问题，或者您的幻灯片上有一些问题，或者其他激起您想问的兴趣的事情？ 关于IDERA的建模功能。
埃里克·利特尔（Eric Little）：是的，罗恩（Ron）是其中之一，你们怎么样，看来您所显示的图是通常在数据库构造中使用的一般类型的实体关系图，对吗？
Ron Huizenga：是的，一般来说，但是我们当然有文档存储的扩展类型以及这种类型的东西。 实际上，我们从纯粹的关系表示法中有所变化，实际上我们还为其他商店添加了其他表示法。
埃里克·利特尔（Eric Little）：你们有没有办法利用基于图形的建模类型，有没有办法进行整合，例如，让我们假设我拥有像上象限，TopBraid作曲家工具之类的东西，或者我已经做了一些事情在Protégé中，或者像FIBO中的财务人员一样，他们在语义，RDF方面做了大量工作–有没有办法将这种类型的实体关系图类型建模引入该工具，并加以利用它？
Ron Huizenga：实际上，我们正在研究如何处理图形。 今天，我们没有明确处理图数据库和这类事情，但是我们正在寻找可以扩展元数据的方法。 我的意思是，如果我们至少可以做某种形式的XML导入来作为起点，那么我们现在就可以通过XML引入这类东西。 但是我们正在寻找更优雅的方法来实现这一点。
我还向您展示了我们在那里也有的逆向工程桥梁列表，因此我们一直在寻找针对特定平台的那些桥梁的扩展。 如果可以的话，这是一个持续不断的工作，要开始接受很多这些新结构和不同的平台。 但是我可以说，我们绝对是这样做的最前沿。 例如，我在MongoDB上展示过的东西以及类似的东西，我们是第一个真正在自己的产品中真正做到这一点的数据建模供应商。
埃里克·利特尔（Eric Little）：好的，是的。 因此，我要问您的另一个问题是治理和维护–就像您使用该示例时，当您演示该示例中的“雇员”时，我相信这是一个“薪水”，然后有一个“计划”，有没有办法，例如，如何管理可能拥有的不同种类的人–假设您拥有一个大型架构，对，假设您拥有一个大型企业，人们开始使用此工具将事情汇总在一起，您在这里有一个小组用“雇员”一词，在这儿有一组用“工人”一词。这里一个人说“薪水”，另一个人说“工资。”
你们如何调和，管理和治理这些区别？ 因为我知道我们如何在图形世界中做到这一点，所以您可以使用同义词列表，或者可以说有一个概念并且它具有多个属性，或者可以说在SKOS模型中我有一个首选标签，我可以使用许多替代标签。 你们是怎么做到的？
Ron Huizenga：我们以几种不同的方式来做，首先让我们先谈谈术语。 当然，我们要做的一件事就是我们想要定义或批准的术语，而在业务术语表中，显然是我们想要它们的地方。 而且我们也允许在业务词汇表中链接到同义词，因此您可以做的就是说这是我的术语，但是您也可以定义这些同义词的所有同义词。
当然，现在有趣的事情是，当您开始查看拥有庞大的所有这些不同系统的广阔数据环境时，您不能只是走到外面更改相应的表和那些类型的东西对应于该命名标准，因为它可能是您购买的软件包，因此您根本无法控制更改数据库或进行任何操作。
除了能够关联词汇表定义之外，我们在那里还能做的是通过我所讨论的那些通用映射，我们将做什么以及一种推荐的方法是拥有一个总体逻辑模型，该逻辑模型列出了什么您正在谈论这些不同的业务概念。 将业务词汇表术语绑定到这些术语中，很高兴的是，您现在已经拥有了表示逻辑实体的构造，然后可以开始从该逻辑实体链接到该逻辑实体的所有实现。不同的系统。
然后您需要查看的地方，哦，在此系统中，这里的“人”称为“雇员”。 在此其他系统中，此处的“工资”在此处称为“工资”。 因为您将看到它们，所以您将看到它们的所有不同表现形式，因为它们已将它们链接在一起。
埃里克·利特尔（Eric Little）：好的，是的，知道了。 从这个意义上讲，可以肯定地说这有点像一些面向对象的方法吗？
Ron Huizenga：有点。 比我想说的要复杂得多。 我的意思是，您可以采用手动链接并进行检查和全部处理的方法。 我真正没有机会谈论的一件事-因为我们又拥有很多功能-我们在Data Architect工具本身中也具有完整的自动化界面。 还有宏功能，它实际上是该工具中的一种编程语言。 因此，我们实际上可以做一些事情，例如编写宏，让其退出并询问事物并为您创建链接。 我们可以使用它来导入和导出信息，也可以使用它来更改事物或添加属性，基于模型本身的事件，也可以使用它来批量运行以实际运行和查询事物，并在其中填充不同的构造。模型。 因此，有一个完整的自动化界面，人们也可以利用。 并且将通用映射与这些映射一起使用将是一种非常有效的方法。
丽贝卡·乔兹维克（Rebecca Jozwiak）：好的， 谢谢罗恩 ，也感谢埃里克。 这些是很好的问题。 我知道我们已经超出了小时的上限，但是我想给Malcolm一个机会，向Ron提出一些问题。 马尔科姆？
马尔科姆·奇斯霍尔姆：谢谢丽贝卡。 所以，罗恩，这很有趣，我发现这里有很多功能。 我非常感兴趣的领域之一是，例如，如果我们有一个开发项目，那么您如何看待数据建模者使用这些功能，以及如何与业务分析师，数据剖析器和数据质量分析师合作？ ，并由商业赞助商最终负责项目中的实际信息需求。 您知道，数据建模人员如何真正利用我们所关注的功能使项目更有效，更高效？
罗恩·休曾加（Ron Huizenga）：我认为您要做的第一件事就是作为数据建模师-我并不是要挑选某些建模师，但无论如何我还是会-有些人仍然有这样的印象：数据建模者实际上就是角色的网守，我们正在定义它的工作方式，我们是确保一切正确的守卫。
现在有一个方面，您必须确保正在定义声音数据架构以及其他所有内容。 但是，更重要的是，作为数据建模人员-我在咨询时发现这一点很明显-是您必须成为促进者，所以您必须将这些人召集在一起。
不再需要预先设计，生成和构建数据库–您需要做的就是能够与所有这些不同的利益相关者群体合作，进行诸如逆向工程，导入信息，不管是在词汇表还是在文档上，其他人都可以进行协作，并且可以像其他人那样将其拉入存储库中，并将概念链接到存储库中，并与这些人一起工作。
实际上，这实际上是协作类型的环境，即使通过任务或讨论线程的定义或团队服务器中我们拥有的那种类型的东西，人们也可以实际协作，提出问题并获得最终的最终产品需要他们的数据架构和组织。 有没有这样的答案？
马尔科姆·奇斯霍尔姆：是的，我同意。 您知道，我认为便利化技能是数据建模人员真正需要的。 我同意我们并不总是看到这种情况，但是我认为这是必要的，我建议有时候在进行数据建模时可能会碰壁，但是您确实需要与其他利益相关者团体一起工作或者您只是不了解要处理的数据环境，我认为该模型将因此遭受损失。 但那只是我的个人意见。
Ron Huizenga：有趣的是，您在幻灯片的前面提到了一些有关企业如何远离IT的历史的信息，因为他们没有及时提供解决方案以及这类事情。
有趣的是，在后来成为产品经理之前，我从事咨询工作的时候，我在过去两年中所做的大多数项目都是业务赞助的，而真正的业务推动了它和数据架构师建模者不是IT的一部分。 我们是一个由企业赞助的小组的成员，我们作为促进者与其他项目团队一起工作。
马尔科姆·奇斯霍尔姆：所以我认为这是非常有趣的一点。 我认为我们已经开始看到业务领域正在发生变化，业务正在询问，或者思考的过程可能不像我要做的那么多，但是他们也开始考虑数据是什么与我一起工作，我的数据需求是什么，作为数据处理的数据是什么，以及在多大程度上我们可以获得IDERA产品和功能来支持这种观点，我认为企业的需求，甚至尽管还有些新生。
罗恩·许曾加（Ron Huizenga）：我同意你的看法，而且我认为我们正在以越来越多的方式发展。 我们已经看到了唤醒，您已经在数据重要性方面更早地谈到了它。 我们早在IT部门或数据库的发展过程中就已经意识到了数据的重要性，然后正如您所说，我们进入了整个流程管理周期-流程非常重要，请不要误解我-但现在发生了什么当这种情况发生时，数据就失去了焦点。
现在，组织已经意识到数据确实是焦点。 数据代表了我们在业务中所做的一切，因此我们需要确保我们拥有准确的数据，可以找到做出决策所需的正确信息。 因为并非所有事物都来自定义的过程。 其中一些信息是其他事物的副产品，我们仍然需要能够找到它，知道它的含义，并能够将我们在那里看到的数据最终转换成可以用来更好地推动业务发展的知识。
Malcolm Chisholm：对，现在我一直在努力的另一个领域是我所说的数据生命周期，这就是你知道的，如果我们看一下贯穿企业的数据供应链，我们将从数据采集或数据捕获，这可能是数据条目，但可能同样是，我从企业外部从一些数据供应商那里获取数据。
然后，从数据捕获到数据维护，我正在考虑将这些数据标准化并将其传送到需要的地方。 然后使用数据，即数据所在的实际点，您将从数据中获取价值。
过去，这都是以一种单独的方式完成的，但是今天，您可能知道，例如，它是一个分析环境，然后是一个档案库，一个商店，当我们不再使用这些数据时，我们会将数据放到这里需要它，最后是一种清除过程。 您如何看待数据建模适合整个数据生命周期的管理？
罗恩·休曾加（Ron Huizenga）：这是一个很好的问题，我今天真的没有时间在这里进行任何细节研究，而这是我们真正开始谈论的是数据沿袭。 因此，我们真正能够做的是，我们的工具中具有数据沿袭功能，就像我说的，我们实际上可以从ETL工具中提取其中的一部分，但是您也可以通过绘制沿袭来映射它。 我们已经捕获并带入模型的任何这些数据模型或数据库，都可以在数据沿袭图中引用其构造。
我们能够做的就是像您所说的那样，从源到目标绘制一个数据流，并贯穿整个生命周期，即数据如何在不同系统之间传输以及您将要找到的是，让我们雇用员工数据-根据几年前的项目，这是我的最爱之一。 我曾与一个在30个不同系统中拥有员工数据的组织合作。 我们在那里结束的工作-丽贝卡弹出了数据沿袭幻灯片-这是一个相当简单的数据沿袭幻灯片，但是我们能够做的是引入所有数据结构，在图中引用它们，然后我们可以真正开始查看什么是流之间的流，以及这些不同的数据实体如何在流中链接在一起？ 我们也可以超越此范围。 这是我们在此处看到的数据流或血统图的一部分。 如果您想超越此范围，我们还拥有此套件中的业务架构师部分，同样适用于此。
我们在数据建模环境中捕获的任何数据结构，都可以在业务建模工具中引用，因此即使在您的业务模型图或业务流程图中，也可以引用单个数据存储（如果希望不在其中）数据建模环境，并且在业务流程模型的文件夹中使用它们时，甚至还可以在这些模型上指定CRUD，以了解如何使用或产生该信息，然后我们就可以开始生成诸如影响，分析报告和图表之类的东西。
我们的目标是达到目标，并且已经拥有很多功能，但是随着我们不断发展我们的工具，我们所要解决的事情之一就是我们正在寻找的目标。能够绘制出端到端的组织数据沿袭以及数据的整个生命周期。
马尔科姆·奇斯霍尔姆：好的。 丽贝卡，我可以再允许一个吗？
丽贝卡·乔兹维克（Rebecca Jozwiak）：马尔科姆，我再允许你，继续。
马尔科姆·奇斯霍尔姆：非常感谢。 考虑数据治理和数据建模，我们如何使这两个小组有效地合作并相互理解？
埃里克·利特尔（Eric Little）：有趣的是，我认为这实际上取决于组织，这可以追溯到我以前的概念，即那些将计划与业务紧密联系在一起的组织，例如，我领导着一个数据架构团队，但我们与业务用户紧密联系在一起，实际上我们正在帮助他们建立他们的数据治理计划。 同样，更多的是咨询方法，但实际上更多的是业务功能。
您真正需要做的就是需要真正了解业务，可以与业务用户建立联系，然后帮助他们站起来围绕其进行治理的数据建模人员和架构师。 企业希望做到这一点，但总的来说，我们拥有技术知识，能够帮助他们脱颖而出。 它确实必须是一个协作，但是它必须是企业所有。
马尔科姆·奇斯霍尔姆：好的，太好了。 谢谢。
埃里克·利特尔博士：好的。
丽贝卡·乔兹维克（Rebecca Jozwiak）：好的，非常感谢。 观众成员，恐怕我们没有解决您的问题，但我将确保他们确实会转发给我们今天在电话上遇到的合适客人。 我要非常感谢Eric，Malcolm和Ron今天成为我们的客人。 伙计们，这真是棒极了。 如果您喜欢今天的IDERA网络广播，那么如果您想参加下周三的会议，IDERA也将成为热门技术，讨论索引和Oracle的挑战，这是另一个有趣的话题。
谢谢大家，保重，我们下次再见。 再见。
