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

Question

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

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

Answer 1

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

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

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

Answer 2

你的问题没有说清楚。我没有看到“数据独立性”和“应用程序不可更改性”之间的关系。

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

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

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

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

使用这样的结构，您可以修改底层数据库结构并同时维护用户应用程序。

Answer 3

  

什么说如果数据库没有任何改变将为用户   结构变化？

嗯，数据库结构可能会因多种原因而发生变化。在很高的层面上，我看到了两种可能性：

1. 性能/内部数据库原因
2. 业务规则/应用程序之外的世界已更改

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

@ 2：如果外部世界发生变化，或者您的业务规则发生变化，那么您在数据库级别上可以做的事情可以使其远离用户。例如，一直在数据库中只使用一种货币的公司突然变得国际化：在这种情况下，必须采用数据库来支持多种货币，并且需要对数据库和用户进行严格的更改。

Answer 4

  

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

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