CODEWITHSUNDEEP
databaserelational-database
user721588
user721588

Reputation:

Data independence in relational database

Can anybody explain how data independence in ensured in a relational database? What says that nothing will change for the user if the database structure changes?

For example, I have relation R (and have created an application which uses this relation) and the database admin decides to make a decomposition of R to R1 and R2. How is application inalterability ensured for the end user?

Upvotes: 6

Views: 8944

Answers (4)

Quassnoi
Quassnoi

Reputation: 425471

For example, I have relation R (and created application which uses this relation) and the database admin desides to make a decomposion of R to R1 and R2. How the application inalternability is ensured for the end user?

The admin should create a view which would represent R1 and R2 as the original R.

Upvotes: 0

Carlos Gavidia-Calderon
Carlos Gavidia-Calderon

Reputation: 7253

I asked myself exactly the same question during my Database class.

According Codd's 12 rules, there are two kinds of data independence:

  • Physical Data Independence requires that changes at the physical level (like data structures) have no impact in the applications that consume the database. For example, let's say you decide to stop using a Hash Index in your table and decide to use a B-Tree Index instead: Your application that executes queries against this table doesn't have to change at all.
  • Logical Data Independence states that changes at the logical level (tables, columns, rows) will have no impact in the applications that access the database. As you already noticed, this feature is harder to implement that Physical Data Independence but there are still cases when this feature works. For example, if you add Tables, Columns or Rows to your current scheme the already working queries aren't affected at all.

Upvotes: 5

Pleun
Pleun

Reputation: 8920

what says that nothing will change for the user if the database structure changes?

Well, database structures can change for many reasons. On a high level, I see two possibilities:

  1. Performance / internal database reasons
  2. Business rules / the world outside the application changed

@1: in this case, the DBA has decided to change some structure for performance or ... In that case an extra layer, for example using stored procedures, views etc. can help to "hide" the change to the application/user. Or a good data-layer on the application side could be helpfull.

@2: if the outside world changes, or your business rules change, NOTHING you can do on the database level can keep that away from the user. For example a company that always has used only ONE currency in the database is suddenly going international: in that case your database has to be adopted to support multi currency and it will need serious alteration in the database and for the user.

Upvotes: 1

Gordon Linoff
Gordon Linoff

Reputation: 1270011

Your question is not phrased very clearly. I don't see the relationship between between "data independence" and "application inalterability".

A proper relational structure decomposes data into entities and relationships. The idea is that when a value changes, it only changes in one place. This is the reasoning behind the various "normal forms" of data.

Most user applications do not want to see data in a normalized form. They want to see data in a denormalized form, often with lots of fields gathered together on one line. Similarly, an update might involve several fields in different entities, but to a user, it is just one thing.

A relational database can maintain the structure of the data and allow you to combine data for different viewpoints. It has nothing to do with your second point. Application independence (I think this is a better word than "inalterability") depends on how the application is designed. A well-designed application has a well-design application programming interface (also known as an API).

It seems that a lot of database developers think that the physical data structure is good enough as an API. However, this is often a bad design decision. Often, a better design decision is to have all database operations performed through stored procedures, views, and user defined functions. In other words, don't directly update a table. Create a stored procedure called something usp_table_update that takes fields and updates the table.

With such a structure, you can modify the underlying database structure and maintain user applications at the same time.

Upvotes: 2

Related Questions