第234章　ICAI数据生命周期

234.1 数据生命周期的提出

ICAI（Individual Cognitive AI，个体认知人工智能）中的数据不是创建以后永久静止的数据。

一个认知对象从产生开始，通常要经历：

创建 → 读取 → 修改 → 验证 → 保存 → 更新 → 历史记录

其中，数据的运行状态与数据库中的持久化状态并不完全相同。

因此，ICAI数据生命周期（ICAI Data Lifecycle）定义为：

认知数据从领域对象创建开始，经过读取、运行时修改、验证、持久化保存、数据库更新以及历史记录形成的完整数据演化过程。

基本模型：

创建
 ↓
读取
 ↓
运行
 ↓
修改
 ↓
验证
 ↓
保存
 ↓
更新
 ↓
历史记录
 ↓
形成新的当前数据状态

但需要特别注意：

保存（Save）与更新（Update）不是同一个概念。

保存是将领域对象状态持久化到数据库。

更新是已经存在的持久化记录发生变化后，对数据库原有记录进行修改。

234.2 ICAI数据生命周期的基本对象

ICAI数据生命周期涉及三个不同层次。

第一层：领域对象

Domain Object是ICAI运行时真正使用的对象。

例如：

Individual
Object
State
Goal
Capability
Method
Decision
Behavior
Action
Result
Feedback
Memory
Experience
Risk
Conflict
Abnormality
Diagnosis
Protection
Repair
Relation

第二层：持久化对象

Persistence Object是Repository准备写入数据库的数据结构。

Domain Object
      ↓
Mapper
      ↓
Persistence Data

第三层：数据库记录

Database Row是MySQL中的实际记录。

Persistence Data
      ↓
PDO
      ↓
MySQL Row

因此完整关系：

Domain Object
      ↓
Mapper
      ↓
Persistence Object
      ↓
Repository
      ↓
PDO
      ↓
MySQL

234.3 创建

创建（Create）是生命周期的起点。

创建表示ICAI系统产生了一个新的领域对象。

例如创建一个Object：

Object
object_code = OBJ-0001
object_type = device
state = active

创建过程：

认知条件
   ↓
对象定义
   ↓
生成Domain Object
   ↓
分配Domain Identity
   ↓
初始化State
   ↓
进入Runtime

创建并不等于已经写入数据库。

这是一个非常重要的区别：

Create ≠ Save

例如：

new Object()

只表示PHP运行时已经创建对象。

只有经过Repository：

Object
 ↓
ObjectMapper
 ↓
ObjectRepository
 ↓
INSERT

之后，才形成数据库持久化记录。

234.4 创建时的身份生成

根据第233章建立的统一身份规则，ICAI对象至少具有：

id
object_code
object_type

其中：

id

属于数据库身份。

而：

object_code

属于领域对象身份。

例如：

object_code = OBJ-0001

数据库保存以后：

id = 81

形成：

Domain Identity
OBJ-0001
      ↓
Persistence Identity
81

二者保持独立。

234.5 读取

读取（Read / Load）表示从持久化层取得已经存在的数据。

基本流程：

MySQL
 ↓
Repository
 ↓
Persistence Data
 ↓
Mapper
 ↓
Domain Object

例如：

ObjectRepository
      ↓
loadByCode('OBJ-0001')
      ↓
MySQL
      ↓
object record
      ↓
ObjectMapper
      ↓
Object

读取的目的不是改变数据，而是恢复运行时认知对象。

因此：

Read ≠ Update

正常读取不会改变领域数据。

234.6 读取与当前状态

ICAI读取数据时必须区分：

Current Data

与：

Historical Data

例如：

Object
   ↓
Current State

表示当前状态。

而：

State History
   ├── State A
   ├── State B
   ├── State C
   └── State D

表示历史状态。

因此：

读取当前状态

不能直接等同于：

读取全部历史状态

Repository应该根据查询目标进行明确读取。

234.7 修改

修改（Modify）发生在领域对象进入运行时以后。

例如：

State
active

经过认知计算后变为：

State
inactive

这首先是Domain Object发生变化：

Object
 ↓
Current State
 ↓
Modify
 ↓
New Current State

此时数据库可能还没有变化。

因此：

Modify ≠ Database Update

修改首先发生在运行时对象层。

234.8 修改前后数据

对于重要认知数据，修改不能只保存修改后的结果。

应该明确：

Before
+
Change
+
After

例如：

State Before
active

经过：

Event
failure_detected

得到：

State After
failed

完整变化：

State Before
      ↓
Event
      ↓
Rule / Condition
      ↓
State Change
      ↓
State After

可以表示为：

$St+1=F(St,E,C,R)S_{t+1}=F(S_t,E,C,R)$

其中：

$StS_t$ ：修改前状态
$EE$ ：事件
$CC$ ：条件
$RR$ ：规则
$St+1S_{t+1}$ ：修改后的状态

234.9 保存

保存（Save）表示将Domain Object当前状态持久化。

基本过程：

Domain Object
      ↓
Validate
      ↓
Mapper
      ↓
Repository
      ↓
PDO
      ↓
MySQL

例如：

Object
object_code = OBJ-0001
state = inactive

经过：

ObjectRepository->save($object)

写入数据库。

保存的本质是：

把运行时对象的有效状态转换成持久化数据。

234.10 Save与Insert

工程上需要区分：

Create

和：

Insert

Create属于Domain层。

Insert属于Persistence层。

因此：

Create
 ↓
Domain Object
 ↓
Save
 ↓
INSERT

是一条完整链路。

不能直接把：

Create = INSERT

因为Domain Object可能先创建、修改、验证，然后才持久化。

234.11 更新

更新（Update）表示已经存在数据库记录发生变化。

例如数据库中：

id = 81
object_code = OBJ-0001
state = active

运行时修改为：

state = inactive

经过验证后：

UPDATE objects
SET state = 'inactive'
WHERE id = 81

这才是数据库层面的Update。

因此：

Modify
   ↓
Validate
   ↓
Save
   ↓
Update

这里：

Modify是对象变化。

Save是持久化动作。

Update是数据库记录变化。

234.12 Save与Update的统一定义

为了避免后续章节术语混乱，ICAI统一定义：

Save

Save是Repository层的持久化入口。

它根据对象是否已经存在决定具体数据库操作。

save()
 ├── New Object → INSERT
 └── Existing Object → UPDATE

因此：

Save = Persistence Operation

Update

Update是针对已经存在记录的数据库修改操作。

UPDATE

属于SQL/Persistence层操作。

因此：

Save ≠ Update

但：

Save
  └── Existing Record
          ↓
        Update

可以成立。

234.13 历史记录

历史记录（History Record）是ICAI数据生命周期中非常重要的组成部分。

历史记录不是当前数据的复制品，而是：

记录某个数据对象过去发生过什么变化、为什么变化、变化前是什么、变化后是什么以及变化依据是什么。

例如：

Object OBJ-0001

发生：

active → inactive

历史记录可以保存：

before = active
event = failure_detected
after = inactive
evidence = EV-001
time = T1

因此：

Current State
      ↓
Change Event
      ↓
History Record

234.14 History不是Current Data

必须明确：

Current Data ≠ History

例如：

objects

保存当前对象。

而：

history_records

保存对象过去发生的事件。

假设：

T1 active
T2 inactive
T3 active

当前状态可能是：

active

但是历史仍然应该保留：

T1 → active
T2 → inactive
T3 → active

因此历史记录原则上不能因为当前状态恢复而删除。

234.15 历史记录的基本结构

结合第231章建立的History模型，可以统一使用：

History
=
Target
+
Event
+
Before
+
After
+
Evidence
+
Time

对应：

history_code
target_type
target_code
event_type
data_before
data_after
event_data
evidence
occurred_at
created_at

其中：

target_type

确定历史属于什么对象。

例如：

object
goal
method
decision
behavior
memory
experience
risk
abnormality
diagnosis
repair
relation

而：

target_code

确定具体是哪一个对象。

因此可以统一采用：

target_type + target_code

作为历史目标标识。

234.16 统一对象生命周期

ICAI对象可以统一采用：

Created
   ↓
Loaded
   ↓
Ready
   ↓
Running
   ↓
Modified
   ↓
Validated
   ↓
Saved
   ↓
Updated
   ↓
Historized
   ↓
Released

但是这不是要求每一次数据操作都机械经过所有节点。

例如新对象：

Created
 ↓
Validated
 ↓
Saved
 ↓
INSERT

已有对象：

Loaded
 ↓
Modified
 ↓
Validated
 ↓
Saved
 ↓
UPDATE
 ↓
History

234.17 更新与历史记录的关系

ICAI不能简单执行：

UPDATE

然后丢失原始数据。

对于具有认知价值的数据，应当形成：

Before
 ↓
Change
 ↓
After
 ↓
History

例如：

Method M-001

原条件：

condition_A

修改为：

condition_B

那么：

methods

保存当前：

condition_B

而：

history_records

保存：

condition_A
→
condition_B

这样系统才能回答：

以前是什么？
为什么发生变化？
什么时候变化？
变化后是什么？
依据是什么？

234.18 历史记录与记忆

历史记录最终可以参与Memory形成，但两者不能直接等同。

生命周期：

History
   ↓
Analysis
   ↓
Memory Candidate
   ↓
Verification
   ↓
Memory

因此：

History ≠ Memory

History保存过去事实。

Memory保存经过筛选、验证并具有后续使用价值的信息。

234.19 历史记录与经验

同样：

History
   ↓
Memory
   ↓
Comparison
   ↓
Pattern
   ↓
Experience

因此：

History ≠ Experience

Experience需要从多个事实、记忆、条件和结果中形成可重复使用的结构。

234.20 历史记录与学习

学习继续建立在：

History
 ↓
Memory
 ↓
Experience
 ↓
Evidence
 ↓
Learning

之上。

因此：

History

不是自动等于：

Learning

一次数据变化不能直接改变ICAI的知识、能力或方法。

必须经过：

History
 ↓
Analysis
 ↓
Evidence
 ↓
Experience
 ↓
Learning Candidate
 ↓
Verification
 ↓
Update

这样才能形成有效学习。

234.21 数据生命周期与Repository

Repository负责生命周期中的持久化边界。

例如：

ObjectRepository

主要负责：

create
load
save
update
delete
exists
query

但Repository不应该决定：

为什么修改？
是否应该修改？
哪个方法更好？
是否形成经验？
是否需要学习？

这些属于Engine和Service。

因此：

Repository
    ↓
Data Persistence

Engine
    ↓
Calculation

Service
    ↓
Process Coordination

234.22 数据生命周期与Mapper

Mapper负责：

Domain Object
      ↕
Persistence Data

例如：

class ObjectMapper
{
    public function toPersistence($object)
    {
        return array(
            'object_code' => $object->getCode(),
            'object_type' => $object->getType(),
            'state' => $object->getState()
        );
    }

    public function toDomain($data)
    {
        return new Object($data);
    }
}

因此：

Domain Object
      ↓
Mapper
      ↓
array
      ↓
Repository
      ↓
PDO

避免让Domain Object直接操作SQL。

234.23 数据生命周期与历史写入

对于需要追踪的数据，推荐：

Modify
   ↓
Before Snapshot
   ↓
Change
   ↓
Validate
   ↓
Save / Update
   ↓
History Record

其中History应该记录实际发生的变化，而不是预测变化。

因此：

Expected Change ≠ History

只有已经发生并被系统记录的事件才能进入正式History。

234.24 事务边界

当一次认知操作同时涉及：

Current Data
+
Update
+
History

应该尽量保证三者的一致性。

例如：

BEGIN
   ↓
读取当前数据
   ↓
计算新状态
   ↓
验证
   ↓
UPDATE current data
   ↓
INSERT history
   ↓
COMMIT

如果更新失败：

ROLLBACK

这样避免：

Current Data已经更新

但：

History没有写入

造成数据生命周期断裂。

234.25 生命周期完整模型

ICAI数据生命周期可以统一表示为：

                 Create
                   ↓
                Domain Object
                   ↓
                 Read/Load
                   ↓
                 Runtime
                   ↓
                 Modify
                   ↓
                Validate
                   ↓
                  Save
                   ↓
             ┌─────┴─────┐
             ↓           ↓
          INSERT       UPDATE
             │           │
             └─────┬─────┘
                   ↓
             Current Data
                   ↓
             History Record
                   ↓
              Memory Candidate
                   ↓
               Experience
                   ↓
                Learning
                   ↓
                 Update
                   ↓
            New Current Data

这里最后的：

Update

是认知层面的更新时，可能再次触发下一轮：

History

从而形成持续的数据生命周期。

234.26 ICAI数据生命周期的统一公式

可以将一次数据生命周期抽象为：

$L=(C,R,M,V,S,U,H)L=(C,R,M,V,S,U,H)$

其中：

$CC$ ：Create，创建
$RR$ ：Read，读取
$MM$ ：Modify，运行时修改
$VV$ ：Validate，验证
$SS$ ：Save，持久化保存
$UU$ ：Update，数据库或认知数据更新
$HH$ ：History，历史记录

生命周期函数：

$L:Dt→Dt+1+HtL:D_t \rightarrow D_{t+1}+H_t$

其中：

$DtD_t$ ：当前时刻数据
$Dt+1D_{t+1}$ ：更新后的当前数据
$HtH_t$ ：本次变化产生的历史记录

因此一次有效数据变化不是：

Old → New

而是：

Old
 ↓
Change
 ↓
New
 +
History

234.27 ICAI生命周期的核心原则

第一，创建与保存分离

Create ≠ Save

第二，读取不等于修改

Read ≠ Modify

第三，修改不等于数据库更新

Modify ≠ Update

第四，保存是持久化入口

Save
 ↓
INSERT / UPDATE

第五，历史不能覆盖当前数据

Current Data ≠ History

第六，历史原则上追加

History
   ↓
Append

而不是不断覆盖过去记录。

第七，学习不能直接由修改触发

必须经过：

History
 ↓
Evidence
 ↓
Memory
 ↓
Experience
 ↓
Learning
 ↓
Verification
 ↓
Update

234.28 与前面章节的数据体系连接

第233章解决：

数据之间如何建立关系？

第234章解决：

数据建立关系以后如何产生、读取、变化和保存？

因此：

第233章
Database Relationship
        ↓
第234章
Data Lifecycle
        ↓
Repository
        ↓
Engine
        ↓
Service
        ↓
ICAI Runtime

数据关系解决：

谁与谁有关？

数据生命周期解决：

数据什么时候产生？
什么时候读取？
什么时候变化？
什么时候保存？
什么时候更新？
过去发生了什么？

二者共同构成ICAI数据库运行基础。

234.29 本章总结

ICAI数据生命周期不是简单的CRUD。

传统数据库通常可以表示：

Create
Read
Update
Delete

而ICAI需要进一步扩展为：

Create
   ↓
Read
   ↓
Runtime Modify
   ↓
Validate
   ↓
Save
   ↓
Insert / Update
   ↓
History
   ↓
Memory
   ↓
Experience
   ↓
Learning
   ↓
Verified Update

其中最重要的区分是：

Create = 创建领域对象

Read = 从持久化层恢复数据

Modify = 运行时改变领域对象

Save = 将领域对象持久化

Update = 修改已经存在的持久化记录

History = 保存已经发生的数据变化事实

最终形成ICAI数据生命周期：

创建
 ↓
读取
 ↓
运行
 ↓
修改
 ↓
验证
 ↓
保存
 ↓
更新
 ↓
历史记录
 ↓
记忆
 ↓
经验
 ↓
学习
 ↓
验证更新
 ↓
新的当前数据

因此，ICAI数据库不是只保存“现在是什么”，还必须能够明确记录“以前是什么、发生了什么变化、为什么变化、变化依据是什么，以及变化之后是什么”。

这使数据库从单纯的数据存储层进一步成为ICAI认知系统的状态持续化、变化追踪和认知演化基础。

第234章 ICAI数据生命周期

第234章 ICAI数据生命周期

234.1 数据生命周期的提出

234.2 ICAI数据生命周期的基本对象

第一层：领域对象

第二层：持久化对象

第三层：数据库记录

234.3 创建

234.4 创建时的身份生成

234.5 读取

234.6 读取与当前状态

234.7 修改

234.8 修改前后数据

234.9 保存

234.10 Save与Insert

234.11 更新

234.12 Save与Update的统一定义

Save

Update

234.13 历史记录

234.14 History不是Current Data

234.15 历史记录的基本结构

234.16 统一对象生命周期

234.17 更新与历史记录的关系

234.18 历史记录与记忆

234.19 历史记录与经验

234.20 历史记录与学习

234.21 数据生命周期与Repository

234.22 数据生命周期与Mapper

234.23 数据生命周期与历史写入

234.24 事务边界

234.25 生命周期完整模型

234.26 ICAI数据生命周期的统一公式

234.27 ICAI生命周期的核心原则

第一，创建与保存分离

第二，读取不等于修改

第三，修改不等于数据库更新

第四，保存是持久化入口

第五，历史不能覆盖当前数据

第六，历史原则上追加

第七，学习不能直接由修改触发

234.28 与前面章节的数据体系连接

234.29 本章总结