一、信息架构概念
1、企业架构的产生：企业管理体系的信息化建设驱动了EA的产生和发展
没有IT技术时，流程和管理体系已经存在（Taylor科学管理）；随着IT技术的发展并在企业中得到应用，逐步产生了EA（1987年Zackman）；企业要真正发挥IT的价值，必须从技术架构转到业务视角，从企业架构规划开始考虑IT和业务的融合，从根本上改善IT带来的价值。EA（Enterprise Architecture）企业架构。
2、信息架构是企业架构的四个子集（四个A）中重要组成部分
业务架构（BA）：BA是业务的结构化表达，描述组织如何运用业务的关键要素来实现其战略意图和目标
信息架构（IA）：IA是以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范
应用架构（AA）：AA描述了各种用于支持业务架构并对数据架构所定义的各种数据进行处理的应用功能
技术架构（TA）：TA代表了各种可以从市场或组织内部获得的软件和硬件组件
3、信息架构与BA、AA、TA之间的关系
（1）通过业务价值流设计业务对象，基于业务对象设计数据标准，流程BI引用数据标准实现流程与数据的拉通设计
（2）以业务对象和数据标准为输入，设计数据模型并在IT落地
（3）通过元数据管理，实现业务元数据与技术元数据的握手，支撑流程、数据、IT一体化设计
二、数据分类及识别方法
1、数据分类框架
2、内部数据和外部数据的识别方法
3、基础数据识别方法
4、主数据识别方法
5、判断下面数据的类型
三、信息架构设计
1、通过信息架构四个组件定义、管理公司的各种数据
信息架构（Information Architecture）：企业级信息架构是以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范。
信息架构包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件。
2、数据资产目录
3、数据标准：从业务、技术、管理三个方面定义数据标准
数据标准是Business data standard（数据标准）的缩写，用于描述公司层面需共同遵守的属性层数据含义和业务规则。其描述了公司层面对某个数据的共同理解，这些理解一旦确定下来，就应作为企业层面的标准在企业内被共同遵守。
数据标准定义一个数据属性有三方面的要求和规格：
业务视角：
主题域（CHN）
主题域（ENG）
业务对象（CHN）
业务对象（ENG）
逻辑数据实体（CHN）
逻辑数据实体（ENG）
数据分类
业务属性（CHN）
业务属性（ENG）
业务定义及用途
业务规则
同义词
技术视角：
数据类型
数据长度
是否有允许值列表
允许值
数据示例
引用标准（引用、新建）
管理视角：
业务规则责任主体
数据维护责任主体
数据监控责任主体
4、数据源：定义数据的唯一源头，牵引数据同源共享【数据分布】
数据源（Data Source）是指业务上首次正式发布某项数据的应用系统，经过数据管理专业组织认证，作为唯一数据源头被周边系统调用。
数据源管理原则：
（1）所有关键数据必须认证数据源。关键数据是指影响公司经营、运营报告的数据，通过数据字典在公司范围内统一发布。
（2）数据管理专业组织为关键数据指定源头，数据源必须遵循信息架构和标准，经IA SAG（信息架构专家委员会）认证后成为数据源。
（3）所有关键数据仅能在数据源录入、修改，全流程共享，其他调用系统不能修改。下游环节发现的数据源质量问题，应当在数据源进行修正。
（4）所有系统必须从数据源或数据源镜像获取关键数据。数据Owner确保数据源的数据质量，对不符合数据质量标准的数据源，必须限期整改。
5、信息链：定义数据在不同流程之间的流动情况【数据分布】
信息链是一个指定范围内的端到端流程，或流程中活动间信息流的表述。包括信息被创建（Create），读取（Read），更新（Update），删除（Delete）
主要包含要素：业务对象、逻辑数据实体、属性、价值流阶段、BPA、CRUD描述
6、数据流：定义数据在不同系统之间的流动情况【数据分布】
数据流是用于描述某一数据在应用系统中的如何被创建（Create），读取（Read），更新（Update），删除（Delete）
主要包含要素：业务对象、逻辑数据实体、属性、应用系统、CRUD描述
价值：用于数据质量的根因分析，指导系统的集成。
7、业务对象识别是信息架构中最核心的管理要素
业务对象是企业不可缺少的、重要的人、事、物，承载了业务运作和管理涉及的重要信息
8、业务对象识别原则
9、业务对象独立性判断示例-根据生命周期判断
根据业务管理方式的不同，业务对象的独立性会有所不同。
当流程失效，流程所包含的活动全部也变为失效时，只有一个流程业务对象
当流程失效，流程所包含的活动不会失效，仍可以被其他流程所调用时，两个业务对象。
10、业务对象独立性判断示例-根据重组关系判断
11、业务对象的作用
（1）划分业务的边界，保持跨领域信息一致性，避免重复建设。
（2）明确数据Owner，明确每一份数据有相应的责任人。
（3）指引IT系统设计，指引应用系统模块/服务化子系统的设计
12、业务对象识别方法（Top Down）
13、业务对象识别方法（Bottom Up）
14、业务对象辅助判断方法
四、数据模型设计
1、从Idea到实现的过程
2、什么是模型？
3、什么是数据模型？
数据模型：
在用IT系统管理业务信息时，根据业务需求抽取信息的主要特征，模拟和抽象出一个能够反映业务信息（对象）之间关联关系的模型，即数据模型。
数据模型应满足三方面要求：
能比较真实地模拟业务场景；
容易为人所理解；
便于在IT系统中实现。
4、为什么要数据建模？
5、数据模型层级
6、概念数据模型：建立业务对象联接
设计要点：
（1）圈定描述业务范围的起始点和结束点
（2）根据业务流转的顺序从上到下，从左到右来布局
（3）已建立的联接，不需要在下个环节重复联接
（4）要关注业务场景和述求对架构设计的影响
7、逻辑数据模型设计
8、业务含义的差异（可为空 VS 不可为空）
9、第一范式（1NF，属性的原子性）
范式一：有效标识符（主键）、原子性、属性不能重复、属性不允许多值
确保每个实体都有有效标识符，所有的属性都应该是原子性的，即每个属性只能存储不可分割的原子数据项，而不能是集合、数组、记录等。
10、第二范式（2NF，不能包含部分依赖）
范式二：属性完全依赖于标识符（消除部分依赖）
逻辑数据实体的属性完全依赖于主标识符，所谓完全依赖是指不能存在仅依赖主标识符一部分的属性。如果存在，那么这些属性和主标识符的对应部分应该分离出来形成一个新的逻辑数据实体。
11、第三范式（3NF，不能包含传递依赖）
范式三：属性不依赖于其它非主属性（不存在A->B->C）
任何非标识符属性不依赖于其它非标识符属性。任何非标识符属性不得传递依赖于主标识符属性。如果存在，那么这些属性应该分离出来形成一个新的逻辑数据实体。
12、逻辑数据实体设计规范
13、标识符设计规范
标识符设计规范（Must）：每个逻辑数据实体都必须设计标识符，可以使用有业务含义的属性（物理模型中称作业务主键）作为标识符，也可以生成无业务含义的替代属性（序列号或类似序列号，例如：XXX_ID）作为标识符
标识符设计原则：
（1）标识符要唯一能识别一条实例
（2）标识符不能更改
（3）标识符要属性最小化
14、属性设计规范
15、关系设计规范
16、反范式冗余设计规范
反范式是指为了提升系统性能、简化开发和运维难度，对已经范式化的逻辑数据实体、属性、关系进行重新反范式冗余处理的过程和一系列操作。反范式设计过程中必须首先考虑清楚设计的重点是确保数据的准确性、参照完整性，还是减轻数据库性能压力和开发运维难度。反范式是通过构建索引、分区、SQL语句优化等方法无法满足执行速度要求时采取的方式。
五、经验总结
1、架构设计常见误区
（1）架构设计是由架构师完成的，所以只跟架构设计师有关系，跟业务、IT没有关系。
（2）架构设计不是设计完成就结束了，还要确保架构要真正的落地，并且还要持续的做好架构管控或看护，否则就成了"空中阁楼"。
2、关于架构设计的一些体会
（1）"一万个读者有一万个哈姆雷特"，架构的设计是一门学问，也是一门艺术，但更像是一门哲学。业务对象的识别没有绝对的对于错，没有绝对的判断标准，架构只有合理与不合理，更多的是一种权衡。
（2）架构是会随着业务的发展、公司的管理变革等会不断演进变化的，架构最重要的就是要贴合业务，任何不基于业务设计的架构都是"耍流氓"，架构设计还要考虑扩展性、灵活性、相对稳定性等。所以说一个好的架构应该具备高可用，可扩展，可灵活迭代等特点。
（3）架构设计是一个整体到部分的过程。
标签：架构,数据,建模,信息,业务,数据源,标识符,属性 From： https://www.cnblogs.com/qq1035807396/p/17177682.html