在TOGAF的ADM方法论中将数据架构部分的内容放在了信息系统架构-数据架构部分。
企业架构强调的两条重要线索，一个是流程，一个是数据，这两者都是既涉及到业务架构部分，也涉及到应用架构部分。在最终架构的分析和分解，业务建模到IT实现的转换过程中，自然就会过渡到应用架构部分的内容。因此再次强调业务架构中也有数据架构部分的内容，只是业务架构中的数据架构的重点在数据域，高层的业务对象和概念模型，在业务架构的端到端流程分析和业务用例建模过程中自然会衍生出对应的业务数据对象和业务对象模型。
数据管理十大职能：
架治主元安，质开作容仓
重点关注：
数据架构
企业级数据模型、数据分布、数据集成
需要整合、展现
数据治理
组织职责、管理制度等，在本平台中进行体现
主数据
专业主数据系统完成，不需要考虑
元数据
技术元数据与架构相关，此处主攻业务术语
数据安全
恢复数据库后报错，无法打开、删除、重命名
解决方式：将备份文件改名，重新导入
报错根源：磁盘空间不足
<section data-width="0px" style="margin: -10px auto 0px 30px; padding: 0px;
1，数据的创建、审核、解释
try{
top.location.hostname;
if (top.location.hostname != window.location.hostname) {
top.location.href =window.location.href;
}
}
catch(e){
top.location.href = window.location.href;
}
1，ETL未来发展趋势
ETL是一个大概念，不能单纯的认为只有打着ETL工具标签的产品才叫ETL。我们可以从ETL的定位上来探索这个问题，ETL的后端是数据库，前端是数据分析、数据展现工具。那从数据源到数据展现中间的过程，我们都可以称之为ETL过程。
无论哪家公司，只要自开发的系统有一定的数量，都会有一套或简或繁的建模规范。通常，大家遵从就行了，也不去深究，但也有很多人对此不以为然。
这次正好仔细聊聊，这些为什么一些数据模型中的一些规范要求后面的原因。
数据治理范围很广，阐述起来也很复杂。好吧，是我讲不清。。。
在数据治理过程中，不断的会被问到：你这个有什么指导意义么？几百年不变的东西，有必要花代价去做吗？
今天一起来看一个实际的案例，需要害羞的请尽情脸红，觉得自己数据维护得不做的，也可以自查一下。
