I'm currently reading about database schemas about how the three-level ANSI-SPARC architecture works and i'm a bit confused about a concept it's talking about. My question is what would happen if an application was modified so it could store data for a column not defined in the logical schema? The book i'm reading talks about: ... the addition or removal of new entities, attributes or relationships should be possible without having to change existing external schemas or having to rewrite application programs. - Database Systems: A practical Approach to Design, Implementation and Management. Page: 40 (Part: 2.1.5)How does the logical schema handle input (columns) from applications for which it is not defined in the logical schema?ANSI-SPARC architecture: http://en.wikipedia.org/wiki/ANSI-SPARC_Architecture
Database Schema Data Independence
database design;schema
For those who don't have that reference handy, the Wikipedia article on ANSI-SPARC provides a decent overview.How does the logical schema handle input (columns) from applications for which it is not defined in the logical schema?The short answer is that the logical schema can't handle (store) input if it doesn't have columns defined for it.The long answer is that I think the problem is that you've got the frame of reference backwards.  The internal or logical schema needs to have a representation for all of the data that all of the applications (external schemas) may present.  But the external schemas don't need to know of all of the potentialities that are possible within the logical schema.What that quote is focusing on is adding a new, external view onto the existing database.  That will likely require the logical schema to be extended to handle the new bits of data that the new view will require.  But the changes required for this new external view will have zero bearing upon the existing external views and their perception of what the database schema looks like.To use a concrete example...Say I have an application that tracks ticket sales.  I have all sorts of wonderful schemas built around pricing, history, seating, sellers, and buyers.  So my ticket sales app has a view of what it perceives the database schema to be.Later on, I'm talking with another business partner and realize that with a little modification to the database and a new external view, I can easily track auction results.  The premise of that quote is that I should be able to make changes to the logical schema (my database) to support my new auction results application without having to make any changes to my ticket sales tracking application.