数据库的三级模式结构

结论： 三阶段数据库模式：
内部模式：物理数据库存储和访问方式，与DBMS和硬件绑定，定义存储格式、索引、路径和权限。

概念模型：全局逻辑结构，独立于具体环境，描述逻辑结构、关系和完整性约束。

外部模式：本地数据逻辑对用户可见，提供安全性和封装性，不同用户有不同的看法。

什么是DAO模式

DAO模式，坦率地说，是处理数据库时使用的一种技术。

抽象接口就是定义一个接口，比如UserDAO，并在里面写一些方法，比如getUserById()、saveUser()等。
这个接口不直接和MySQL打交道，而是对其进行封装。
在实际使用中，会有MySQLUserDAO或者OracleUserDAO来实现这个接口。
具体来说，如何验证数据库，如何存储数据，都要写在实现类中。

数据访问抽象，坦率地说，意味着不直接将数据库操作写入业务代码中。
比如你搭建一个电商网站，现在用的是MySQL，两年后想改用Oracle，如果直接在业务代码中写mysql.query()，换数据库的时候就得做大改动。
采用DAO模型，只需要替换实现类，业务代码不用改。

它包含两个子模式。
DataAccessor就是刚才提到的实现类，它定义了如何操作数据。
DataObject 是一个数据对象，例如 User 类，包含 ID 和 Name 等字段，这些字段对应于数据库中的表。

使用场景：比如你在构建一个应用程序，需要验证用户信息和改变订单状态，那么你定义OrderDAO接口，然后根据使用的数据库编写MySQLOrderDAO。
业务逻辑就说orderDAO.getUser(1 00)，不管是MySQL还是Oracle，业务代码不管。

说实话，当时我不明白为什么这么复杂，但是后来我发现这样做的好处是代码清晰。
业务人员和数据库流程分离，维护方便。
如果要改变查询条件，只需改变DAO实现类即可。
无需更改使用此查询的每个业务方法。

仅此而已，没有别的。

数据库的三级模式

说实话，刚开始学习3 级模式的时候我很困惑。
但后来当我真正使用它时，我发现它很有趣。
以我之前参与的一个ERP系统项目为例。
当时的数据库设计是严格按照这三个步骤进行的。
外部模式层说白了就是用户看到的唯一界面。
我们正在为销售部门设计一个报告系统。
他们只需要看订单表和客户表，其他项目、财务等都被屏蔽了。
我特地调整了权限，让sales只能访问这些视图，而不能直接创建底层表。
你看，这是一个典型的外部模式应用程序——不同的角色看到不同范围的数据。

概念模型层非常复杂。
我记得项目初期，我们在画概念模型的时候，技术部门和商务部门矛盾很大。
业务人士表示，要妥善体现需求，技术部门在数据库的实施上要规范。
最终协议：所有业务对象都用E-R图来描述，但有些关系更简单。
当时，技术总监说，“这就像一个城市规划。
这是一个概念模型设计。
它基于如何修建道路的内部模型。
”我对内部模型关系不大，但印象最深的是系统崩溃和重建。
操作和维护调整在修改日志文件和索引时直接在活动中进行。
这次他告诉我，他在地下管道中工作，他必须了解如何放置每块砖。
他们把B+树索引变成了哈希表，查询速度确实快了3 0%，但数据库的备份时间却字面增加了一倍——这是一个常见的物理独立性问题。

ANSI标准建议已经提出，但实际上许多系统仍然很简单。
在我最近拥有的旧系统中，外部规划和概念设计直接合并到一个表中，逻辑隔离完全基于应用层。
开发人员告诉我：“老板想做什么，就做什么。
”我有。
这提醒我，理论应用的时候，应该有折扣。
不过话说回来，三层模型的分层思想其实很实用。
它帮助我们在“用户视图和系统实现”之间搭建一座桥梁，避免业务需求和物理存储之间的直接冲突。
尽管现在许多数据库系统自动处理许多底层细节，但是理解这三层模式对于解决问题和优化性能仍然非常有帮助。