谁能解释在关系数据库中如何确保数据独立性？如果数据库结构发生变化，用户什么都不会改变是什么意思？
例如，我有关系 R（并创建了一个使用此关系的应用程序）并且数据库管理员决定将 R 分解为 R1 和 R2。如何为最终用户确保应用程序的不可更改性？
user721588
问问题
8322 次
4 回答
5
在我的数据库课上，我问了自己完全相同的问题。
根据Codd 的 12 条规则，有两种数据独立性：
- 物理数据独立性要求物理级别的更改（如数据结构）对使用数据库的应用程序没有影响。例如，假设您决定停止在表中使用哈希索引并决定使用 B-Tree 索引：您的应用程序对该表执行查询根本不需要更改。
- 逻辑数据独立性指出逻辑级别（表、列、行）的更改不会影响访问数据库的应用程序。正如您已经注意到的，此功能更难实现物理数据独立性，但仍有一些情况下此功能有效。例如，如果您将表、列或行添加到当前方案中，则已经工作的查询根本不会受到影响。
于 2012-06-02T19:41:11.247 回答
2
你的问题表述的不是很清楚。我没有看到“数据独立性”和“应用程序不可更改性”之间的关系。
适当的关系结构将数据分解为实体和关系。这个想法是，当一个值发生变化时，它只会在一个地方发生变化。这就是各种“正常形式”数据背后的原因。
大多数用户应用程序不希望以标准化形式查看数据。他们希望以非规范化的形式查看数据，通常将许多字段聚集在一行上。同样，更新可能涉及不同实体中的多个字段，但对用户而言，这只是一回事。
关系数据库可以维护数据的结构，并允许您为不同的观点组合数据。这与你的第二点无关。应用程序独立性（我认为这是一个比“不变性”更好的词）取决于应用程序的设计方式。设计良好的应用程序具有设计良好的应用程序编程接口（也称为 API）。
似乎很多数据库开发人员认为物理数据结构作为 API 已经足够好了。然而，这通常是一个糟糕的设计决策。通常，更好的设计决策是通过存储过程、视图和用户定义的函数来执行所有数据库操作。换句话说，不要直接更新表。创建一个名为 usp_table_update 的存储过程，它接受字段并更新表。
有了这样的结构，你可以在修改底层数据库结构的同时维护用户应用程序。
于 2012-06-02T14:14:29.843 回答
1
什么说如果数据库结构发生变化，用户什么都不会改变？
好吧，数据库结构可能会因多种原因而改变。在高层次上，我看到了两种可能性：
- 性能/内部数据库原因
- 业务规则/应用外的世界变了
@1：在这种情况下，DBA 决定更改某些结构以提高性能或......在这种情况下，额外的层，例如使用存储过程、视图等，可以帮助“隐藏”对应用程序/用户的更改. 或者应用程序端的良好数据层可能会有所帮助。
@2：如果外部世界发生变化，或者您的业务规则发生变化，您在数据库级别上做的任何事情都无法让用户远离。例如，一家在数据库中一直只使用一种货币的公司突然走向国际化：在这种情况下，您的数据库必须被采用以支持多种货币，并且需要对数据库和用户进行重大更改。
于 2012-06-02T17:42:48.217 回答
0
例如，我有关系 R（并创建了使用此关系的应用程序），数据库管理员打算将 R 分解为 R1 和 R2。如何为最终用户确保应用程序的不可更改性？
管理员应该创建一个视图来表示R1和R2作为原始R.
于 2012-06-02T20:02:25.257 回答