L3业务对象的数据owner部门和描述为必填项，L1和L2为非必填项。 数据owner人员展示该空间下的所有人员，也可以手动输入owner人员名称。 左侧列表页选中某一层级后只展示下一层级所有数据，选中L3业务对象展示该业务对象基本信息。 从文件导入 架构设计师进入到对应空间和方案后，选择对应信息架构的主题设计。

查看更多 →

提交审核 架构设计完成后提交审核。 提交审核：将方案和设计提交给华为和伙伴的架构师审核。 架构选择：选择需要评审的架构名称。 方案审核责任人：一般选择华为和伙伴的的架构师。 图13 提交方案设计审核 提交后由华为和伙伴侧架构师对方案进行审核，如审核通过，则方案设计完成；如审核未通过须按照评审意见修改后再提交。

查看更多 →

VN设计 通过对不同的业务划分为不同的VN，实现生产业务、办公业务、多媒体业务的同类型业务正常互通，不同类型业务隔离不互通。 同时为生产、办公、多媒体、等不同业务分配不同比例带宽，保障网络拥塞时各业务流量都能得到调度。 父主题： 用户业务设计

查看更多 →

目录：在上一步中，如果通过方法一和方法二新建Markdown，目录初始内容为空，可以手动选择；如果通过方法三新建Markdown，目录会自动生成为选中的目录，也可以手动修改。 名称：可根据业务需要自定义命名，不能为空。命名规则：只支持中文、英文、下划线、数字和“.”，且以中英文开头，长度为3-64个字符。

查看更多 →

支持创建100个项目中根目录。 请求方式 定义接口的请求方式，制定了客户端对服务端资源操作的方法，在API设计过程中，需要根据业务和操作类型选择合适的请求方式。 GET（获取）：用于获取指定资源，使用查询参数传递参数，适用于读取资源和查询数据。 POST（提交）：用于提交数据。POST请求可以传递请求体参数，

查看更多 →

API设计 API设计 接口审核 编辑模式与API规范检查 公共模型 Markdown设计 API调试 脚本能力

查看更多 →

API设计 创建API设计 API设计配置 管理API设计

查看更多 →

VPC网络地址范围需要考虑多Region和多AZ，VPC可以跨AZ，子网不能跨AZ，需要为多个AZ 预留子网和地址。 VPC设计原则 端到端业务划分到同一个VPC； 强隔离业务创建单独的VPC； 内外部业务划分不同VPC； 生产和测试划分不同VPC； 管理面和业务面划分不同VPC。 命名设计原则： 环境代

查看更多 →

目录：在上一步中，如果通过方法一和方法二新建Markdown，目录初始内容为空，可以手动选择；如果通过方法三新建Markdown，目录会自动生成为选中的目录，也可以手动修改。 名称：可根据业务需要自定义命名，不能为空。命名规则：只支持中文、英文、下划线、数字和“.”，且以中英文开头，长度为3-64个字符。

查看更多 →

owner=zhangsan”。 请求方式 定义接口的请求方式，制定了客户端对服务端资源操作的方法，在API设计过程中，需要根据业务和操作类型选择合适的请求方式。 GET（获取）：用于获取指定资源，使用查询参数传递参数，适用于读取资源和查询数据。 POST（提交）：用于提交数据。POST请求可以传递请求体参数，

查看更多 →

API设计 API设计 API审核 编辑模式与API规范检查 公共模型 Markdown设计 API调试 脚本能力

查看更多 →

主题设计 主题设计是通过分层架构表达对数据的分类和定义，帮助厘清数据资产，明确业务领域和业务对象的关联关系。 单击左侧导航栏“主题设计”并进入主题设计页面。 图1 主题设计1 单击导入，单击下载主题导入模板。 图2 主题设计2 下载模板如下： 表1 下载模板 上级流程 *名称 *编码

查看更多 →

快速的添加任务、网关、事件、注释或连接线等。 如图1所示，添加四个组件，开始事件、结束事件和“用户任务”，并使用箭头进行连接。更多组件说明请参考组件介绍。 图1 创建流程节点 为组件添加属性及监听器。 选择“用户任务”组件，在右侧“常规”页签中设置“名称”“责任人”“责任群组”等信息。

查看更多 →

设计流程 需求理解 设计思路 设计原则 总体架构

查看更多 →

约束设计 DEFAULT和NULL约束 【建议】如果能够从业务层面补全字段值，则不建议使用DEFAULT约束，避免数据加载时产生不符合预期的结果。 【建议】给明确不存在NULL值的字段加上NOT NULL约束，优化器会在特定场景下对其进行自动优化。 【建议】给可以显式命名的约束显式命名。除了NOT

查看更多 →

huffle，可以减少网络压力，使数据的处理本地化，提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择存储方案 【建议】表的存储类型是表定义设计的第一步，用户业务类型是决定表的存储类型的主要因素，表存储类型的选择依据请参考表1。

查看更多 →

第2个收费站，通过的第6个收费站），（通过的第1个收费站，通过的第7个收费站），（通过的第3个收费站，通过的第8个收费站）] 如果车牌号1和车牌号2通过相同收费站是顺序排列的（比如收费站3、4、5是车牌1通过的第1、2、3个收费站，是车牌2通过的第6、7、8个收费站）且数量大于同行车要求的数量则这两辆车是同行车。

查看更多 →

表设计 总体上讲，良好的表设计需要遵循以下原则： 【关注】减少需要扫描的数据量。通过分区表的剪枝机制可以大幅减少数据的扫描量。 【关注】尽量减少随机I/O。通过聚簇/局部聚簇可以实现热数据的连续存储，将随机I/O转换为连续I/O，从而减少扫描的I/O代价。 选择存储方案 【建议】

查看更多 →

e占用了大量宝贵的网络资源，减小不必要的数据shuffle，可以减少网络压力，使数据的处理本地化，以提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择分布方案 表的分布方式的选择如表2 表的分布方式及使用场景所示。

查看更多 →

约束设计 DEFAULT和NULL约束 如果能够从业务层面补全字段值，那么，不建议使用DEFAULT约束，避免数据加载时产生不符合预期的结果。 给明确不存在NULL值的字段加上NOT NULL约束，优化器会在特定场景下对其进行自动优化。 给可以显式命名的约束显式命名。除了NOT

查看更多 →

约束设计 DEFAULT和NULL约束 【建议】如果能够从业务层面补全字段值，那么，就不建议使用DEFAULT约束，避免数据加载时产生不符合预期的结果。 【建议】给明确不存在NULL值的字段加上NOT NULL约束，优化器会在特定场景下对其进行自动优化。 【建议】给可以显式命名的约束显式命名。除了NOT

查看更多 →