使用 JDBC 链接 InterSystems ：

然后就可以像其他关系型数据库使用的方式来使用Kettle。

    我的几个孩子都很喜欢手工艺品，您可能会觉得作为一个父亲我会用夸张的表情表扬他们很有创意然后还拍照片发到Pinterest（世界上最大的图片社交分享网站）上去，但是我从来都没这么做过。我肯定爱我的孩子，我也确实认为他们有创意，但老实讲如果你有一个正上小学的孩子，你肯定很清楚他们实际的水平。

亲爱的社区开发者们，大家好！

欢迎积极参与新一轮InterSystems开发者竞赛！

随着 InterSystems IRIS 2021.2 预览版 的发布和全新的 LOAD DATA 功能，我们希望将其与最新的竞赛（数据集）结合起来！ 

🏆 InterSystems 数据集竞赛🏆

竞赛时间: 2021年12月27日-2022年1月16日

奖金总额: $9,450

    如果您经常阅读我们的博客，您可能记得去年夏天我们进行了 InterSystems 速度测试，该测试由 ESG 验证，旨在测试数据库可以同时摄取和查询的数据量，以及这表现出的具体的影响。从那以后，我们 GitHub 页面的许多访问者一直在根据自己的想法重复验证这个测试

    我经常发现自己与现存客户和潜在客户就他们在访问数据方面的挫败感进行对话。他们最常见的话题是围绕对“速度的需求”展开的——可以理解，这是非常正确的。

    在医疗领域，开发创新可以挽救更多的生命。

    这也是为什么我们更需要去倾听负责构建未来的人：开发人员。 他们需要什么工具才能更有效地使应用程序更加高效？ 他们面对着什么样的障碍？

    InterSystems 不想去做无用的猜测，因此我们推动进行了一项研究，该研究综合了 200 名医疗行业开发者的反馈，深入了解了他们的最大需求。我们认为，这些研究结果为医疗单位和医疗技术公司提供了一个机会，可以帮助他们的开发团队为业务带来新机遇，同样也为临床医生和患者带来更光明的未来。

    以下是三个关键要点：

    1. 开发人员想要一个统一的医疗平台。

    在接受本次研究采访的 200 名开发人员中，有88% 的受访者表示他们是医疗 IT 领域的专家或该领域的技术人员——他们都希望能有最好的、为他们的行业量身定制的开发工具。 这就是为什么一半的受访者将统一的、专注于医疗的数据平台列为购买新开发工具的关键原因。

    一个合适的医疗行业开发平台应该包括互操作性/集成引擎、分析工具、面向医疗行业的自然语言处理功能、机器学习工具和 FHIR 服务器，以及其他组件。

    如果一家公司能够提供一个包含所有上述组件的平台，那么超过 90% 的开发人员将对这项技术非常感兴趣。

    2. 临床数据模型必不可少

Gartner Peer Insight 一直持续公开对各类第三方软硬件的对比，是IT行业的“大众点评“。综合转载如下，仅供参考。

原文链接：https://www.gartner.com/reviews/market/cloud-database-management-system…

Gartner Peer Insights 是Gartner 提供的由专业最终用户用来对企业级技术解决方案进行打分和评估供企业使用的平台。Gartner 会将用户意见和他们的专业意见综合起来形成魔力象限。

https://www.appeon.com/products/powerbuilder

Appeon PowerBuilder 是一个企业级开发工具，可以用来建立数据驱动的商业应用程序和组件。它是Appeon产品套件之一，同时提供了开发C/S、Web、移动和分布式应用程序的工具。

在这篇文章中，我将展示通过使用ODBC用Appeon PowerBuilder连接Caché的步骤。

步骤1 :
确保在安装IRIS时选择ODBC驱动程序选项。

步骤2:
通过使用ODBC数据源管理器配置ODBC IRIS数据源 

步骤 3: 配置InterSystems ODBC 数据源

步骤 4: 测试连接 (确保 IRIS 实例在运行)

步骤 5: 
从 PowerBuilder 打开数据库Profiles, 在列表选中ODB ODBC并单击“新建 New”... 按钮

 

步骤 6: 
选择我们已经用ODBC管理器创建的 "IRISHealth User"数据源

步骤 7: 点击“测试连接Test Connection” 按钮，在Preview页面下测试连接

恭喜! 我们已经成功建立了IRIS链接。现在我们可以用PowerBuilder database painter来看表和数据了

谢谢

大家好， 在本文中，我比较了 Gartner 最新DBMS 魔力象限中的主要领先数据库产品的功能。 请见按现有功能数量排序的列表。 1. InterSystems IRIS 2020.3 - 60 个功能 (https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls) 2. Oracle Database 21c - 54 个功能 (https://docs.oracle.com/en/database/oracle/oracle-database/index.html) 3. Microsoft SQL Server - 45 个功能 (https://docs.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver15) 4. AWS Aurora - PostgreSQL - 34 个功能 (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Auror…)

一个实例中可创建的最大命名空间数量为2048个。这个上限不可修改。

一个实例中可创建的最大数据库数量（包括远程数据库）为15998个。这个上限也不可修改。

一个实例中可创建数据库的总数量还有其他因素制约：

1. 数据库路径信息总量最大为256KB，也就是所有数据库的路径字符加起来不能多于256KB。设置的路径越长，可创建的数据库数量越少。
计算公式：最大数据库数量=258048/(平均数据库路径长度+3)

2. 镜像的数据库一个按两个算。也就是创建一个镜像的数据库，相当于创建了2个非镜像数据库。

更多细节请参考在线文档：
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=G…

请问cahce中所有的数据库访问都是通过cache server完成的吗，比如使用终端访问数据库、studio开发的应用、使用第三方库使用代码都是先访问cache server，然后通过cache server对数据进行存取的吗?使用studio开发的应用程序也是跑在cache server中吗? 如果是的话studio开发的应用程序(比如web程序)如何跟cache server分开部署呢?

有人有将NonStop SQLMP与IRIS连接的经验吗？

如果可能的话，我需要一些参考或技巧，实际上是与JDBC驱动程序连接的，以便互连并解决许多各种各样的问题，例如：

一些查询（不是很多）有空获取，可以正常工作，但没有要获取的内容，而且确定Select 语句是正确的。

上一篇： IRIS中的权限管理

在上一篇文章中，我们介绍了IRIS中的权限控制体系。在本文中我们将以一个常见的实施需求为例介绍如何使用IRIS的权限配置出一个只能使用SQL的用户。

需求的分解

和所有用户需求一样，当用户提出一个需求时，除其语义显式的含义之外，还需分析其是否具有没有明确说明的含义。 对于一个只能使用SQL的用户这样一个需求，即应当结合平台的特征分解成为功能需求： 具有一个合法，可通过用户名和密码使用IRIS的用户 该用户的数据库权限

• 确认项：可以使用SQL访问所有数据库还是某几个特定的数据库？ 该用户的SQL权限
• 确认项：对于特定的数据库，是否可以执行所有的DDL？
• 确认项：对于特定的数据库，是否对每一张表都可以执行Select、Update等所有的DML 该用户的程序权限
• 确认项：用户是否可以通过Portal登录并管理IRIS？

如上所示，一个只能使用SQL的用户，这样一个看似简单的需求，如果需要与用户获得一致的理解并付诸实施，则需要将其分解，对于没有在用户需求中明确约定的部分，应作为待确认项与用户确认。 另外，需要注意的是，IRIS作为一个数据平台，除了提供底层的数据库之外，也提供了Portal等Web应用程序便于使用Sharding、HA、Interoperability等平台功能，通过平台对外提供的Webservice、REST等web接口也受Web应用程序控制。因此，当需要设计权限体系时，不但需要考虑用户使用的数据库相关的权限，也需要考虑是否需要控制Web应用程序的权限。

我们假设需要提供一个严格意义上的只能对某个库的某个Schema下的所有表具有只读权限的用户，即： 具有一个合法，可通过用户名和密码使用IRIS的用户 该用户的数据库权限

• 该用户只能使用DemoSpace命名空间下的数据库 该用户的SQL权限
• 该用户不能执行任何DDL
• 该用户只能对DemoSchema下的所有表执行Select语句 该用户的程序权限
• 该用户不能登录Portal，不能执行Portal中提供的任何管理功能

对数据库的配置

在IRIS中创建数据库时，默认的行为是引用%DB_%DEFAULT这个资源，并引用%DB_%DEFAULT角色（注意，平台中有一个叫做%DB_%DEFAULT的资源，同时还有一个叫做%DB_%DEFAULT的角色。%DB_%DEFAULT角色通过%DB_%DEFAULT资源获得默认的数据库访问权限）。如果直接使用%DB_%DEFAULT角色或%DB_%DEFAULT资源，都有可能影响到之前以默认配置创建的数据库，因此，在需要细粒度控制访问权限时，往往需要自定义资源和角色实现。

创建资源%DB_DemoDB_Res {#3.1}

资源可在创建数据库的同时创建，也可以在使用默认资源创建数据库之后，再给数据库指派其他资源。本例中，我们在创建命名空间DEMOSPACE的同时创建数据库DEMODB并创建资源。

创建角色DemoDB_Read_Role {#3.2}

在创建角色之后，即可为其分配资源。根据资源类型的不同，对资源的操作可以有读、写和使用三种权限。对于数据库引用的资源，是读权限和写权限。在本例中，我们需要创建的是只读用户，因此，资源权限分配读权限即可，不用赋写权限。

创建用户DemoUser并分配角色

通过Portal创建用户之后，即可给用户分配角色。在本例中，需要给这个用户分配之前创建的DemoDB_Read_Role角色。 在经过上述配置之后，用户DemoUser即已拥有对命名空间DEMOSPACE中数据库的访问权限。 此时，用户对数据库拥有读权限，但并没有对表执行查询或建表的权限，如果尝试create table，则会得到如下的权限错误信息： 为继续实验，我们通过Portal执行这SQL语句先创建DemoSchema.Persons这张表

为角色DemoDB_Read_Role分配SQL权限

由于用户具有的权限不足，无法执行SQL操作，因此我们需要对该用户的角色赋予对应的权限（或直接给用户赋权，但平台用户较多时，考虑到用户管理的成本，并不推荐这样做）。可以采用如下手段进行SQL的授权

通过Portal授权

在Portal的用户管理和角色管理功能中，均可指定要授予的SQL权限。 SQL特权栏用于对DDL进行数据库级的授权，例如对DEMOSPACE命名空间下的数据库分配建表、修改表、建视图等DDL操作。在本例中，用户不具有这些权限，因此不对该用户对应的角色授予这些权限。 在SQL表，SQL视图和SQL过程栏中，则是分别对表、视图和存储过程授予查询、执行等权限。在本例中，用户需要对DemoSchema这个Schema下的表拥有select查询权限，即可通过对SQL表授权进行 授权后该角色的SQL表权限如下 此时通过SQL工具已可执行查询 使用Portal授权时是针对单个的表、视图或存储过程进行。在上例中，我们单独对表DemoSchema.Persons进行了授权，如果我们再建立一张DemoSchema.Employee表，当前的角色和用户并不能自动获得读取其数据的权限。

通过SQL授权

超级管理员或拥有SQL授权权限的用户可以通过SQL的GRANT语句对数据库对象（包括库，函数，表，视图和存储过程等）进行授权，SQL GRANT语句的语法和使用详见GRANT，此处不再赘述。 在上面的例子中我们建立了表DemoSchema.Persons，建表的同时建立的Schema DemoSchema。假如现在我们希望对授权进行简化，使角色DemoDB_Read_Role可以直接获得Schema下所有表的读权限，则可以用如下的SQL：

GRANT SELECT ON SCHEMA DemoSchema to DemoDB_Read_Role

执行成功后再查看DemoDB_Read_Role的SQL权限，会发现： 即这个角色已经拥有了Schema级的授权，因此，对整个Schema下的所有表都拥有权限。之后在Schema中如果建立了新的表，则这个角色会自动拥有这些表的读权限。

限制用户登录和使用Portal

上例配置的用户可以用于登录IRIS的Portal，但由于没有任何系统功能的权限，不能执行操作。 IRIS的Web应用程序在创建时默认并不需要额外的资源去访问，这意味着所有合法用户都能登入这个Web应用，但由于支撑应用的后台程序和数据是受到资源的保护的，能登入的用户不一定具有运行程序、访问数据的权限，正如我们建立的用户DemoUser可以登录Portal，但没有功能菜单可用。 如果需要进一步限制用户的行为，禁止其登录，则还需要对应用权限进行控制。 如我们在上一篇文章：IRIS中的权限管理 中所述，Portal是平台提供的Web应用程序，是通过Web应用的权限控制可访问性，因此，需要修改应用的资源要求。 通过菜单: 系统管理 > 安全 > 应用程序 > Web应用程序 可以访问当前系统提供的Web应用列表，其中的/csp/sys即为系统管理门户Portal 其中必要的资源一栏即为该应用的资源需求，默认为空，即访问该应用不需要特定资源，只要是合法用户即可。我们可以为该应用指定所需资源，例如%Development，即只有具有%Development资源的角色及其对应的用户才能够访问该程序。保存设置后，再尝试以用户DemoUser登录Portal，结果是 除非我们为DemoUser引用的角色DemoDB_Read_Role分配资源%Development，该用户都不能登录。 当然，超级管理员由于拥有所有权限，不受这个设置的影响。

总结

通过上述实验，我们创建了一个用户，只能使用SQL连入并查询指定Schema下的表。希望通过这个实验，大家能够掌握IRIS权限管理的基本元素：

• 用户，角色，权限，资源和许可构成的权限控制体系
• 数据库、SQL和应用程序都是权限管理的对象

大家在实际项目中可以根据最终用户的实际需要，灵活应用这些概念，构建满足需求的权限配置。

上一篇： IRIS中的权限管理

下一篇： 案例: 建立只能使用SQL的用户

IRIS通过认证（Authentication）与授权（Authorization）两项机制控制外部用户对系统及应用、数据资源的可访问性。因此。如需要进行权限控制，则需要通过配置认证和授权进行。

IRIS中的认证 {#2}

认证可以验证任何试图连接到InterSystems IRIS®的用户的身份。一旦通过认证，用户就与IRIS建立了通信，从而可以使用其数据和工具。有许多不同的方法可以验证用户的身份；每种方法都称为验证机制。IRIS 通常被配置为只使用其中一种方式。 支持的认证方式

• 实例认证：通过用户名/密码对登录平台，即密码认证
• LDAP：通过第三方LDAP服务器（如Windows Active Directory ）完成认证
• 操作系统认证：建立操作系统用户-平台用户映射，使用操作系统用户登录平台
• Kerberos：使用Kerberos协议进行认证
• 代理认证：使用自定义的代码实现认证过程

系统服务与认证 {#2.1}

在安装时，IRIS会启动一系列系统级的服务用与控制与外部用户或系统的交互，这些服务都绑定了默认的认证机制 图中红框标出的即为系统安装后会自动启用并需经认证才可使用的系统服务，认证手段可配置。 例如，如果变更%Service_Console的身份验证方法，取消密码方法，用户就不能通过输入用户名密码登入Terminal。 通过Portal的菜单 系统管理 > 安全 > 服务 可访问该设置。

账户控制参数 {#2.2}

通过系统管理 > 安全 > 系统安全 > 系统范围的安全参数中的选项可对于用户名/密码认证手段的行为进行更多的约束。

• 非活动限制 - 指定用户账户不活跃的最大天数，它被定义为成功登录之间的时间。当达到此限制时，该帐户将被禁用。值为0（0）表示对登录之间的天数没有限制。[对于最低安全级别的安装，默认为0，对于正常和锁定的安装，默认为90]。
• 无效登录限制 (0-64) - 指定连续不成功的登录尝试的最大次数。在达到此限制后，要么禁用账户，要么对每次尝试进行递增的时间延迟；行动取决于如果达到登录限制字段则禁用账户的值。值为0（零）表示对无效登录的次数没有限制。[默认为5]
• 如果达到登录限制，则禁用账户 - 如果选中，则指定达到无效登录次数（在前一字段中指定）将导致用户账户被禁用。
• 密码有效期天数(0-99999) - 指定密码过期的频率以及用户更改密码的频率(天数)。当初始设置时，指定密码过期的天数。0（0）表示密码永远不会过期。不会影响已设置了下次登录时更改密码字段的用户。[默认为0]

需要特别注意的是，密码有效性、过期和禁用账户等设置会影响IRIS实例的所有账户，包括IRIS超级管理员账户。如触发了控制策略，则在更新这些帐户的信息之前，可能无法进行各种操作，这可能导致意外的结果。如超级管理员账户被锁定，则需要通过紧急模式启动实例再进行修改。

对于系统可用的认证手段的配置和其他可用的安全配置，请参见Security Administration Guide

IRIS中的授权 {#3}

授权模型 {#3.1}

InterSystems公司的授权模式采用基于角色的访问控制。

• Users – 用户
• Roles – 角色
• Privileges – 权限
• Resources – 资源 | Permissions – 许可

在这种模式下，用户拥有与分配给各自用户身份的角色相关的权限。

• 一个角色是一个命名的特权集合
• 一个用户可以拥有一个以上的角色
• 权限分配给角色，角色分配给用户

其中，Roles就是权限的集合，而权限提供对资源的特定类型的访问的许可。

• 可控资源: 数据库，服务，应用（包括Web应用 ）和其他
• 可选用的许可: Read, Write or Use，其中执行代码需要数据库的读权限

资源的定义 {#3.2}

资源是一项相对抽象的概念，用来指代IRIS中的数据库，服务，应用等可被访问的对象。例如，对于数据库，在建立时默认采用%DB_%DEFAULT指代，也可自定义资源（数据库资源必须以%DB_开头）：

对于Web应用，默认不需要通过资源控制，即所有可登录用户都可访问（但该用户进程不一定能访问到数据，还需参照是否具有对数据库的访问权限）。如通过分配资源进行控制，则登录用户还需具有资源才能访问这个Web应用：

因此，一项权限实际上是指对某个资源的一些特定操作的集合。 例如，对于数据库UserDB具有读写操作许可的权限A，对于Web应用/csp/sys具有使用操作许可的权限B。如果我们将这两项权限都赋给角色RoleA，那么这个角色就同时拥有A权限和B权限，从而能够访问数据库UserDB和访问Web应用/csp/sys。

SQL授权 {#3.3}

除了对数据库进行授权外，IRIS作为一个数据平台，需要对外提供数据访问。因此，IRIS也提供了SQL授权对用户可执行的SQL进行细粒度的权限控制。 SQL的授权可以分配给角色或用户。但通常在企业环境中，用户数量会很多，仍然需要对SQL用户进行分组，根据分组规划角色，通过角色进行授权的控制，才能有效降低维护授权所需的工作量。 SQL的授权针对SQL类型，可分为库、表级授权。 对于Create table、drop view、truncate table这一类的DDL，使用库级授权，即用户可在特定的库中执行建表、删除视图等经过授权的操作。如下：

对于Select、update等DML，则使用表级授权，使用户能够通过DML访问特定的表中的数据。如下：

除通过Portal操作之外，对于SQL的授权，还可使用IRIS SQL中的额GRANT语句，例如：

GRANT * ON Schema Test TO TestRole

这个SQL即可以将当前操作数据库下Schema Test中的所有表的所有权限都赋给TestRole这个角色。 关于GRANT语句的用法，可参见GRANT指令

以上即为IRIS中进行权限控制所需掌握的概念和内容，在后续文章中，我们会结合实例向大家介绍其使用。

下一篇： 案例: 建立只能使用SQL的用户

推荐阅读

Security Administration Guide - https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS

在最近的项目里，多方同时连接同一个数据库并执行增删改查等各项数据操作。研发人员不时发现一些数据在不合规的情况下被新增甚至删除。因此，在实际工作中会有监控数据操作以便识别和处理异常操作的需求。本文将以监控和识别删除操作为例，介绍如何通过IRIS的审计功能实现对数据操作的监控和查询。

注意事项

在应用审计功能之前，必须注意的是：

1. 开启审计功能会事无巨细地记录每一条对应的操作（如被执行的SQL），因此对于存储空间的需求将急剧增加。举例而言，仅开启对XDBCStatement的监控后，对于一张只由5个简单（整型，VARCHAR型）字段构成的表中插入100万条记录，在Audit数据库中将占用300～400MB的空间。在因业务所需确实需要开启审计功能时，必须预先分配更多磁盘空间给IRIS Audit数据库，并在审计功能开启期间定时巡检磁盘空间，避免因日志占满磁盘导致其他数据无法写入引发系统挂起的故障。
2. 在研发环境中多人、多单位需要连接数据库时，应为不同的开发者和数据来源分配独立的数据库账户和权限，避免多人共用超级账户，导致数据异常时难以追踪异常操作究竟从何而来。也就意味着为不同角色的开发、测试、用户等参与者开启独立的用户，分配各自所需的的数据库权限以及管理数据库账户这样一系列项目正常运行所依赖的实践并不能被审计功能所替代。在项目进展过程中，您更希望见到的，一定不是出现问题后再来跟踪问题和耽误工期，而是通过良好的协作规程和研发习惯减少非技术问题出现的概率。

IRIS中的审计功能

IRIS提供了丰富的数据库审计功能，用于记录从系统权限变更到数据删除的各类操作，用户可通过我们的官方文档查看系统支持的各类审计事件。 对于SQL操作而言，可用到的审计事件包括三大类：

• %System/%SQL/DynamicStatement 可捕获通过动态SQL执行的SQL操作
• %System/%SQL/EmbeddedStatement 可捕获通过嵌入式SQL执行的SQL操作
• %System/%SQL/XDBCStatement 可捕获通过第三方（JDBC/ODBC）SQL连接执行的SQL操作

开启数据库审计

1. 由于默认安装时IRISAUDIT数据库通常位于IRIS安装目录，空间有限，因此在需要开启审计时，应先将IRISAUDIT数据库从系统安装目录迁移到空间更充裕的数据库目录

2. 在System Administration -> Security -> Auditing -> Configure System Events下，开启对%System/%SQL/XDBCStatement的监控，如下图

3. 预先配置好删除AuditLog的任务，以便在AuditLog过大时清除数据 系统虽然自带定时删除Audit数据库的任务，但其默认的触发条件为在Journal发生切换时才执行，因此不适用于需要扩展监控范围导致审计库将剧增的情况，应配置额外的任务便于随时执行。 并将其设置为按需启动

4. 待可疑操作发生时，使用SQL工具或portal在%SYS命名空间下运行如下SQL：

SELECTID, AuditIndex, Authentication, CSPSessionID, ClientExecutableName, ClientIPAddress, Description, Event, EventData, EventSource, EventType, GroupName, JobId, JobNumber, Namespace, OSUsername, Pid, Roles, RoutineSpec, Status, SystemID, UTCTimeStamp, UserInfo, UsernameFROM %SYS.Auditwhere Description = 'SQL DELETE Statement'order by UTCTimeStamp desc

即可找到最近的删除操作。通过Truncate table或delete语句执行的操作均可由该日志捕获到。如需监控insert或update等操作，在上述Description字段的选择上加入对insert或update语句的筛选即可。 通过这些日志，可以查看到操作发生的时间，来源IP和数据库用户等信息，如下所示：

5. 必须再次提醒各位，一旦开启对语句的监控，Audit数据库会快速增长，需要每日甚至每日多次巡检，确保磁盘空间不会被占满导致系统崩溃。 一旦发现Audit所在磁盘占有量过大（例如大于80%）或Audit库本身的占用过大（例如大于20G），即应运行步骤3中 配置的任务，然后对Audit库进行压缩和截断操作释放空间。

我打算基于实例中的数据实现业务智能。 怎样才是设置数据库和环境来使用 DeepSee 的最佳方法呢？

本教程通过 3 个 DeepSee 架构示例来解决此问题。 首先，我们从基本架构模型开始，并重点说明其局限性。 对于复杂程度中等的业务智能应用，建议使用下一个模型，对于大多数用例而言，该模型应该足矣。 在本教程的最后，我们将说明如何增强架构的灵活性以管理高级实现。

本教程中的每个示例都介绍了新的数据库和全局映射，并讨论了为何以及何时设置它们。 在构建架构时，则重点说明更灵活的示例提供的好处。

开始前

主服务器和分析服务器

为了使数据高度可用，InterSystems 通常建议使用镜像或映射，并将 DeepSee 实现基于镜像/映射服务器。 承载数据原始副本的机器称为“主服务器”，而承载数据副本和业务智能应用程序的计算机通常称为“分析服务器”（有时称为“报告服务器”）。

拥有主服务器和分析服务器至关重要，主要原因是避免任一台服务器出现性能问题。 请查阅有关推荐架构的文档。

数据和应用程序代码

通常，将源数据和代码存储在同一数据库中仅对小型应用程序有效。 对于更大型的应用程序，建议将源数据和代码存储在两个专用数据库中，这样您就可以与运行 DeepSee 的所有命名空间共享代码，同时保持数据分离。 源数据的数据库应从生产服务器镜像。 该数据库可以为只读，也可为读写。 建议为此数据库持续启用日志功能。

源类和自定义应用程序应存储在生产和分析服务器上的专用数据库中。 请注意，这两个用于源代码的数据库不需要同步，甚至不需要运行相同的 Caché 版本。 只要定期将代码备份到其他地方，通常就不需要日志。

在本教程中，我们采用以下配置。 分析服务器上的 APP 命名空间有 APP-DATA 和 APP-CODE 作为默认数据库。 APP-DATA 数据库可以访问主服务器上的源数据数据库中的数据（源表类及其事实数据）。 APP-CODE 数据库存储 Caché 代码（.cls 和 .INT 文件）以及其他自定义代码。 数据和代码的这种分离是一种典型的架构，这允许用户，例如，有效地部署 DeepSee 代码和自定义应用程序。

在不同的命名空间上运行 DeepSee

使用 DeepSee 的业务智能实现通常在不同的命名空间中运行。 在本文中，我们将说明如何设置单个的 APP 命名空间，但是相同的过程适用于运行业务智能应用程序的所有名称空间。

文档

建议熟悉文档页面执行初始设置。 该页面的内容包括：设置 Web 应用程序，如何将 DeepSee 全局变量放置在单独的数据库中，以及 Deepeep 全局变量的替代映射列表。

在本系列的第二部分中，我们将阐述基本架构模型的实现