Could anyone help me on anyone of the following areas

1. What are the methods or practices that can be used to extend the lifecycle of a schema
2. How costly is a schema change in a production database - is there any matrix that can be used for the evaluation
3. what are the methods available to address the problem of schema changes in a database
4. is there a (formal) classification of types of changes that may be required in a schema
5. Are there any other data models or systems which handle schema changes more economically and efficiently than Relational model or RDBMSs.

Thanks

1. What are the methods or practices that can be used to extend the lifecycle of a schema

make sure it is designed by a competent data architect

2. How costly is a schema change in a production database - is there any matrix that can be used for the evaluation

LIFECYCLE STAGE COST/CHANGE
design ............... $ 0.50
development .......... $ 3.95
implementation ..... $ 900.03
production ...... $ 29,937.00

3. what are the methods available to address the problem of schema changes in a database

make sure it is touched only by a competent database administrator in consultation with an equally competent data architect

4. is there a (formal) classification of types of changes that may be required in a schema

yes: 1=trivial, 2=inconsequential, 3=moderately disruptive, 4=impossible

5. Are there any other data models or systems which handle schema changes more economically and efficiently than Relational model or RDBMSs.

if you are thinking of anything with "object" in the name, no

1. What are the methods or practices that can be used to extend the lifecycle of a schema

make sure it is designed by a competent data architect
- I agree. It solves the problem to a certain extent - but in systems where the requirements evolve over time, schema changes become inevitable - hence the need to address the issue in other ways.

2. How costly is a schema change in a production database - is there any matrix that can be used for the evaluation

LIFECYCLE STAGE COST/CHANGE
design ............... $ 0.50
development .......... $ 3.95
implementation ..... $ 900.03
production ...... $ 29,937.00

- I think you know that I need the basis/source etc, to attach any value to this response

3. what are the methods available to address the problem of schema changes in a database

make sure it is touched only by a competent database administrator in consultation with an equally competent data architect
- somehow I feel that you are totally ignorant to the issues of schema evolution and temporal databases, so I suggest you should read a bit.

4. is there a (formal) classification of types of changes that may be required in a schema

yes: 1=trivial, 2=inconsequential, 3=moderately disruptive, 4=impossible

- read my comment in 3 above. In any case, "impossible" is a bit too extreme.

5. Are there any other data models or systems which handle schema changes more economically and efficiently than Relational model or RDBMSs.

if you are thinking of anything with "object" in the name, no
- Actually "object" was just one. But why do you think the Object Data model is worse that the relational model in this respect?

I think you should realise that Rudy had his tongue in his cheek when quoting such specific figures. But you get the point, I hope? i.e. that the earlier in the project the need for change is realised, the lower the cost.
If you are not ignorant of these, why did you ask the question? You would probably do better to Google for those terms than to pose a question here (a question which didn't even refer to the terms "schema evolution" and "temporal databases" explicitly).
Again, the words "tongue" and "cheek" come to mind! And again, you are expecting a lot from a forum like this. If someone has come up with "a (formal) classification of types of changes that may be required in a schema" and how to deal with it, then they will surely have published it, and will probably not be hanging around DBForums waiting for someone to ask about it.

If I were the suspicious kind, I'd wonder if you were doing a college assignment and were trying to avoid the bother of doing your own research!

Good heavens!

I think you forgot the 2 cents for testing

Frank

You hoped right.. and I am looking for ways of reducing the escalation.

I dont think I need to prove that there is a vast difference between theory and practice. I can take care of the theory side pretty well (thats where google search can help a lot). But I only have my and a few of my friends' experience on the practical aspect. I was expecting "practical" experts to give their views on how the problem ('changes in schema' as opposed to academic names for perceived solutions) can be/ has been tackled by them. I do understand "experts" help, but I wanted to know HOW 'experts' help.

I have come across many sitations where experienced people can guide me to off line resources, which I may have not come across, and hence the question. I didn't expect the originator of the resource to help, though this has happend in the past.

I am doing a research with a University (is this something to hide so that only a suspicious soul can guess??), although my questions here are more related to my work.
Besides when did discussion forums become a bad place to get ideas of other real life practitioners?

This kind of forum isn't a bad place at all for getting that kind of feedback and interaction. The way that you presented those questions might be a bit sub-optimal though.

I know that I can speak for Rudy and myself, and I'm pretty sure that I can speak for the collective "we" on the forum... We've been milked by more college kids than we can easily count for homework help, some of it by outright solicitation to do homework for pay. That behavior has made us a rather suspicious lot, especially when it comes to blanket bundles of open ended questions.

If you are serious about your questions, stick around a bit. Answer a few questions as well as asking them. You'll find that the level of expertise is rather good (especially from the folks that have already responded to your question). You just managed to hit a whole bunch of "hot buttons" with a single shot, which seems to have gotten things off on the wrong foot.

-PatP

On reflection I think I was being particularly crusty yesterday. It was this line that got to me, even though it was addressed to Rudy and not me:
Is it me, or does that seem rather antagonistic?

BTW, I thought I had read a little about temporal databases, and what I had read bore no relation to the subject of "schema evolution". From what I've read, it's all about "data evolution" if you like - i.e. effective dates on records. I may well be wrong though.

We'll have none of that here! I'm the resident curmudgeon!

Yeah, that seems rather antagonistic to me too. I'm not sure if sidath just munged the message a bit, or if they are really confused as to what temporal databases really are. Maybe as the discussion evolves we'll get more details.

-PatP

thanks, sidath, i love you too

no, tony, this didn't bother me at all, i've been divorced twice and have been called a lot worse

deadline for the paper must be closer than we thought

i think the "temporal" idea in sidath's reply is probably connected to the concept of slowly changing dimensions

this is actually a fairly interesting side trip off the main road towards modelling for a data warehouse, and involves issues dealing with surrogate keys

in any case, my answer is the same, get a competent modeller to do it

i mean, talk about your open-ended questions...

Temporal data bases are dealing with data evolution, but the concept has expanded to embrace the issue of schema evolution, especially with the growth of enthusiasm on data warehouses. "A Guided tour of Relational Databases and beyond" by Marke Levene and George Loizou just touches on the issue in the chapter for temporal databases. Its quite amazing that the interest in this type of work has been there for over 10 years and yet no widely usable development has happened in this area (may be I am ignorant here - help me).

Then back to my original querries..
I am keen on finding out how the industry tackles / lives with this problem. Let me start by listing my own observations..
1. use "good" data models at the start (use of experts??) - however, this does not entirely address the issue for several reasons. e.g -1 : It is quite possible for an expert to leave one field for "Telephone number". But at a later stage of evolution, it might become necessary to break it down to area code and subscriber number. e.g - 2. I think you would agree that we allow some "denormalization" in database designs to improve efficiency, which later we might have to normalize - need for refactoring of schema
2. scare the customer with "high cost" and reject changes to the schema as "impossible", thereby affecting/delaying her business strategy, since her information system just doesn't allow it - this is an idea i hate in general. I strongly believe IS should be more flexible (at lesser costs).

btw, does anyone know of any research studying how big a problem this really is..

I'm sorry if I offended you.

The term "Temporal databases" often talks about time indexing of data. I think that in it self proves either...
1. the (relational) database academia and industry have not been paying enough attention to the concept of "time indexing the schema"
2. we have learned to live with the problem in the ways I suggested in my earlier post.

The term "slowly changing dimensions" has been used to address the temporal issues. The changes in schema that results (as discusses in work on slowly changing dimensions) is a consequence of attempting to time index data, and not due to an evolution of schema, required by changes in (non time related) business requirements.
I personally feel that it is high time to address this issue, given the use of relational databases even in the high end ERP's. Again I fear the idea of IS's making the business rigid. (may be I am overeacting).
But I know lots of companies who have faced major problems, but publicised case studies on failures are hard to find compared to the number of success stories available.

no offence taken

as people have mentioned, we do seem to get quite a few questions which, on the surface, can only be answered by a response of term-paper length

you must admit that your initial post did look a lot like an RFH (request for homework)

it seems you may know a lot more than most people about temporal issues -- how about writing an article for us?

Thanks..

I admit. Sorry

I'will try when I have more knowledge. I will be grateful if you share your experience with the rest of us.