Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    May 2004
    Posts
    9

    Lifecycle of a Relational Database Schema

    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

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    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
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    May 2004
    Posts
    9
    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?

  4. #4
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    Quote Originally Posted by sidath
    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
    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.
    Quote Originally Posted by sidath
    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.
    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).
    Quote Originally Posted by sidath
    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.
    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!

  5. #5
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by andrewst
    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!

  6. #6
    Join Date
    Sep 2003
    Location
    Dumfries, VA USA
    Posts
    8
    Quote Originally Posted by r937
    LIFECYCLE STAGE COST/CHANGE
    I think you forgot the 2 cents for testing

    Frank

  7. #7
    Join Date
    May 2004
    Posts
    9
    Quote Originally Posted by andrewst
    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.
    You hoped right.. and I am looking for ways of reducing the escalation.

    Quote Originally Posted by andrewst
    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).
    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.

    Quote Originally Posted by andrewst
    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.
    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.

    Quote Originally Posted by andrewst
    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!
    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?

  8. #8
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Quote Originally Posted by sidath
    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

  9. #9
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    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:
    - 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.
    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.

  10. #10
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Quote Originally Posted by andrewst
    On reflection I think I was being particularly crusty yesterday.
    We'll have none of that here! I'm the resident curmudgeon!

    Quote Originally Posted by andrewst
    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.
    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

  11. #11
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by sidath
    I feel that you are totally ignorant
    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...
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  12. #12
    Join Date
    May 2004
    Posts
    9
    Quote Originally Posted by andrewst
    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.
    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..

  13. #13
    Join Date
    May 2004
    Posts
    9
    Quote Originally Posted by r937
    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...
    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.

  14. #14
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by sidath
    I'm sorry if I offended you.
    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?
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  15. #15
    Join Date
    May 2004
    Posts
    9
    Quote Originally Posted by r937
    no offence taken
    Thanks..

    Quote Originally Posted by r937
    you must admit that your initial post did look a lot like an RFH (request for homework)
    I admit. Sorry

    Quote Originally Posted by r937
    it seems you may know a lot more than most people about temporal issues -- how about writing an article for us?
    I'will try when I have more knowledge. I will be grateful if you share your experience with the rest of us.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •