背景：如图，有人问到这个功能分组是怎么存储的，之前没了解过，我们来寻找下。
分析：
苍穹都是通过实体储存数据的，名称一般也都是一致的，我们第一步应该去设计器里搜索：功能分组。然后我们一眼看到这个基础资料，其他都是动态表单，不能存储数据，那肯定是这个。（太乐观了，直接踩坑了）
找到这个实体的物理表，我们看到一共才298条数据，隐约觉得太少了。搜索下我们自己的分组编码。发现竟然找不到。
奇了怪了，难道不在这里？没办法，继续寻找。ctrl+alt+g进入到新增功能分组的页面。发现标识是bos_devp_metadataunit，是个动态表单。那我们要找到他的插件，kd.bos.devportal.plugin.BizUnitPlugin。
进入插件，我们找到确定按钮的点击，发现在beforeClick事件中有逻辑。
我们找到新增分组的实现逻辑。分组是存储在应用元数据中的，应用元数据我们比较熟悉，实体是bos_devportal_bizapp，物理表是t_meta_bizapp。
我们找打物理表t_meta_bizapp，再找到我们的测试应用，发现fdata存储的元数据中就包括了我们的功能分组菜单信息。此刻我们找到了功能分组的存储位置，那页面是怎么关联到分组的呢？
我们思考一下，应该是页面创建完成的时候建立的关系，那我们通过ctrl+alt+g找到页面创建向导。发现这是个动态表单，我们找到插件kd.bos.devportal.page.plugin.BizPageNewTemplatePcPlugin，并找到完成创建的按钮。
进入插件我们找按钮的事件，发现调用到finish事件。
继续分析我们发现，都是调用了DevportalUtil.buildNewPage这个方法保存的数据。
进入该方法我们发现这里有个bos_devportal_unitrelform的实体，见名知意，感觉和我们找的关联表很像。
设计器里搜索，发现这是个基础资料，表名T_meta_bizunitrelform，有三个字段。
在数据库验证下，根据我们之前找到的应用元数据中的功能分组过滤下数据，发现是有数据的，FFORMID也能对应上我们的实体页面id。到此完成。
总结：
功能分组本身的信息是存储到应用元数据 bos_devportal_bizapp 中的。
分组和页面的关联信息在 bos_devportal_unitrelform 这个实体中。
有个功能分组的基础资料 bos_devportal_bizunit，实际上没有用到，应该是旧的逻辑，防止踩坑。
推荐阅读