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

  • 1
    Hello Crizly, we don't know the book you are reading or the context of your cite - and only there is probably the answer to your question. – Doc Brown Mar 29 '14 at 15:07
  • They seem to leave it on a cliff hanger unfortunately, i'm not looking for a specific answer just a general idea of how these features work if possible – Crizly Mar 29 '14 at 15:20
  • 1
    If you don't want your question to be closed soon, you should seriously consider to give some clarification - in the current form your question invites for wild guessing, and this is not welcome here on this site. For example, you could edit your question and add from which book you took your cite. – Doc Brown Mar 29 '14 at 15:25
  • Hopefully thats cleared it up a bit – Crizly Mar 29 '14 at 15:37
  • 2
    @MikeBrown - have a look at the wikipedia article I link in my answer. Essentially, it's a variant of a standard n-tier architecture. – user53019 Mar 30 '14 at 13:35

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.

  • Oh I see, yeah that makes more sense when you put it like that, between the quote and the question I've been given i wasn't sure what it was getting at, but ah ah, thank you! – Crizly Mar 30 '14 at 2:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.