关系数据库中的数据独立性答案

【问题标题】：Data independence in relational database关系数据库中的数据独立性
【发布时间】：2016-01-14 20:36:44
【问题描述】：

谁能解释在关系数据库中如何确保数据独立性？什么说如果数据库结构发生变化，用户什么都不会改变？

例如，我有关系 R（并创建了一个使用此关系的应用程序）并且数据库管理员决定将 R 分解为 R1 和 R2。如何确保最终用户的应用程序不可更改性？

【问题讨论】：

【解决方案1】：

我在数据库课上问了自己完全相同的问题。

根据Codd's 12 rules，数据独立有两种：

物理数据独立性要求物理级别的更改（如数据结构）对使用数据库的应用程序没有影响。例如，假设您决定停止在表中使用哈希索引并决定使用 B-Tree 索引：您的应用程序对该表执行查询根本不需要更改。
逻辑数据独立性指出逻辑级别（表、列、行）的更改不会影响访问数据库的应用程序。正如您已经注意到的那样，此功能更难实现物理数据独立性，但仍然存在此功能有效的情况。例如，如果您将表、列或行添加到当前方案中，则已经工作的查询根本不会受到影响。

【讨论】：

【解决方案2】：

你的问题表述的不是很清楚。我看不出“数据独立性”和“应用程序不可更改性”之间的关系。

适当的关系结构将数据分解为实体和关系。这个想法是，当一个值发生变化时，它只会在一个地方发生变化。这就是各种“正常形式”数据背后的原因。

大多数用户应用程序不希望以规范化形式查看数据。他们希望以非规范化的形式查看数据，通常将许多字段聚集在一行上。同样，一次更新可能涉及不同实体中的多个字段，但对用户而言，这只是一件事。

关系数据库可以维护数据的结构，并允许您针对不同的观点组合数据。这与你的第二点无关。应用程序独立性（我认为这是一个比“不变性”更好的词）取决于应用程序的设计方式。设计良好的应用程序具有设计良好的应用程序编程接口（也称为 API）。

似乎很多数据库开发人员认为物理数据结构作为 API 已经足够好了。然而，这通常是一个糟糕的设计决策。通常，更好的设计决策是通过存储过程、视图和用户定义的函数来执行所有数据库操作。换句话说，不要直接更新表。创建一个名为 usp_table_update 的存储过程，它接受字段并更新表。

有了这样的结构，你可以同时修改底层数据库结构和维护用户应用程序。

【讨论】：

【解决方案3】：

什么说如果数据库不会改变用户结构变化？

嗯，数据库结构可能会因多种原因而改变。在高层次上，我看到了两种可能性：

@1：在这种情况下，DBA 决定更改某些结构以提高性能或...在这种情况下，额外的层，例如使用存储过程、视图等，可以帮助“隐藏”对应用程序/用户。或者应用程序端的良好数据层可能会有所帮助。

@2：如果外部世界发生变化，或者您的业务规则发生变化，您在数据库级别上做的任何事情都无法让用户远离。例如，一家在数据库中一直只使用一种货币的公司突然走向国际化：在这种情况下，您的数据库必须采用支持多种货币，并且需要对数据库和用户进行重大更改。

【讨论】：

【解决方案4】：

例如，我有关系 R（并创建了使用此关系的应用程序），数据库管理员打算将 R 分解为 R1 和 R2。如何确保最终用户的应用程序不可更改性？

管理员应该创建一个将R1 和R2 表示为原始R 的视图。

【讨论】：