October 10, 2005

Limitations of the Relational Model

In my October Computerworld column, I tried to explain some of the reasons why I don’t think the pure Relational Model should be as absolutely dominant as its most fervent proponents assert.

The key points were:

1. Logical and physical modeling will never be completely separable.
2. “True relational” DBMSs are very unlikely ever to be practically useful, except perhaps in narrow niches.
3. Enterprises don’t fully control their data models.
4. Duplicated data is not inherently bad.
5. Saying that the relational model (RM) is based on mathematics proves almost nothing.
6. IT isn’t just concerned with facts.

For details see the link above.

And while I’m at it, here’s a link to my September Computerworld column, on three life-and-death apps that won’t get built with a relational architecture.

Comments

30 Responses to “Limitations of the Relational Model”

  1. Eric on October 13th, 2005 9:28 am

    I read your Computerworld article “Counterpunching in the DBMS2 Debate” and have a few comments:

    In point 1:

    To say that logical modeling need not take performance into account is to say that DDL/DML programming need not take performance into account.

    Since “is to say” presumably means implication, you’re implying that the non-needs of logical modeling imply the non-needs of DDL/DML programming? Nonsense. While modeling has implications for programming, programming has concerns which don’t overlap with those of modeling (or else it would be just more modeling). Positive assertions in the logical model have implications for programming, but that doesn’t mean that the logical model has to say SOMETHING about every aspect of programming.

    No matter how great your optimizing compiler is, you still can write a slow program; the same principle applies to DBMSs. Indeed, it’s even more valid for data modeling than for some other kinds of programming.

    So data modeling IS programming? While all are DESCRIPTION, they’re not of the same kind. Logical modeling (“specification” is a better word) states the predicates with which the system is concerned, verifies consistency with requirements, and provides approprate limits / guidance for design and programming. Design introduces software-only concepts of which the logical model “knows” nothing.

    And you’re saying, then, that it’s possible to “write a slow logical data model?” That’s… odd, to say the least. I would argue in kind that it’s possible to write purple-and-green programs. Prove they’re not!

    In point 2:

    The gurus claim that a true relational DBMS would allow the complete separation of logical and physical modeling.

    That separation is possible now, under SQL.

    But as noted above, that will never be practical, at least not in a broad-spectrum, industrial-strength product.

    This is truly a groundless speculation, especially with the qualifying terms “broad-spectrum” and “industrial-strength” (phrases which can and have been used to “argue” against anything with less than the largest slice of market share).

    I agree with point 3: That enterprises don’t fully control their data models. Absolutely. That’s why integration is critical, and in order to ease integration, consistent semantics (and preferably syntax) are extremely productive. Integration in the face of XML, O-O, SQL, and (maybe) relational DBMSs is an expensive nightmare (as we’re experiencing). How does DBMS2 ease that burden?

    Point 4 is almost correct, but I disagree that

    Duplicated data is bad only insofar as the effort to keep it consistent is burdensome.

    Keeping duplicated data consistent is a burden, and also imposes a risk: if it’s not done right, answers to questions (reports, queries, data screens, cubes, other analyses) will be wrong.

    Point 5 is a poor response to the claim that the RM’s scientific and mathematical basis makes it the most useful data model.

    But ensuring data integrity is only one part of the programming challenge. You also have to create actual functionality and user interfaces, and the whole thing has to perform in real-world environments.

    Functionality can and has been written around tables and views (relations’ undernourished cousins), and much more could be done with relations. Data entry screens can and have been generated using tables and views (at least as a bootstrap). “Functionality” is always written in terms of some sort of data element (objects, relations, ADTs, records, primitive language scalars, etc.) Performance is another issue, of course.

    To my knowledge, there has been very little in the way of theorem-proving that has shown the RM to necessarily be ideal for those aspects of the development task.

    Has such theorem-proving been done for other models, languages, etc? I doubt any theorem can prove X is ideal, whatever the X. The RM’s straightforward mapping to sets and predicates, and the elegance of the relational algebra and calculus, demonstrate a lot of value (as you acknowledge) without such “proof.” The absence of “industrial-strength” products based soundly on the RM is similarly not a “proof.”

    Point 6 makes a strange assertion: that “IT isn’t just concerned with facts.” Of course it is. Systems allow users (and their other systems) to assert facts which are consistent, and to answer questions about those facts.

    What on earth does it mean to say “the whole point of any nontrivial ‘analysis’ is to produce conclusions that, while fact-based, aren’t absolutely certain”? That’s ludicrous. While the users may not trust the system or the data in the system (sometimes for good reason), the point of the system IS to provide conclusions that are correct, or at least better than anything else the users can derive, at least within the domains they concern. When the facts prove false, they need to be corrected. None of that implies we shouldn’t be deriving conclusions from what we believe are facts.

    The primary difficulty in analysis is knowing what question to ask, and ensuring that you ask it correctly. Even fuzzy-logic systems have certainty thresholds that are use to derive boolean conclusions from probabilities; otherwise the probabilities would have no value whatsoever.

    – Eric

  2. Curt Monash on October 13th, 2005 10:16 am

    Dang. Lost a long response to a browser crash.

    If you read this before I write another one, Eric, please answer me this:

    Is your ideal future True Relational system going to generate physical models AUTOMATICALLY from logical models, or not? If it is, then creating a logical model IS tantamount to programming DDL, and specifying a great deal about the
    behavior of the programs using the data.

  3. Eric on October 13th, 2005 11:09 am

    Is your idea future True Relational system going to generate physical models AUTOMATICALLY from logical models, or not?

    There would at least have to be 1 other input to that generation step (a la MDA); if not, then there would be no need for such generation. But I do think DBMSs should do much more of the work; for example, based on query statistics and cost, a RDBMS could restructure the data into different base relations (e.g. if 90% of the query time was spent on London suppliers, the RDBMS could split the SUPPLIERS relation into LONDON_SUPPLIERS and OTHER_SUPPLIERS at convenient time, and substitute (LONDON_SUPPLIERS UNION OTHER_SUPPLIERS) when SUPPLIERS was asked for. Or, of course, if the query contained “WHERE CITY=’LONDON'”, just use LONDON_SUPPLIERS. But it’s the relational algebra and integrity rules that make such substitution feasible.

    If it is, then creating a logical model IS tantamount to programming DML,

    Do you mean DDL (Data Definitional Language), such as CREATE TABLE? DML (Data Manipulation Language) consists of SELECT, UPDATE, etc. Just want to make sure we’re talking about the same thing.

    and specifying a great deal about the behavior of the programs using the data.

  4. Curt Monash on October 13th, 2005 11:14 am

    Sorry. I was typing quickly in frustration. I’ll go and edit “DML” to “DDL”, because that’s of course what I meant. Thanks for catching it!

    CAM

  5. Curt Monash on October 13th, 2005 11:22 am

    As for the intelligence you’re asking for — I think it’s still a long way off.
    Oracle put a lot of new optimization functionality into 10G Release 1, which
    indeed leapfrogged the competition. Go back and take a look at how primitive
    the actual new functionality is, however, and you’ll probably share my guess
    that what you’re asking for is a decade or more off.

    By the way, I’m working on a white paper on memory-centric data management,
    so I’m pretty focused on how primitive commerical RDBMS’ caching algorithms are
    too. Blech. Optimizing an RDBMS is a lot harder than one would naively think it is.
    But then, I can’t think of any other kind of automatic optimization that’s the
    least bit sophisticated either. It turns out to be much, much harder to solve
    the general case of a problem than it is to solve any particular example.

  6. Eric on October 13th, 2005 11:35 am

    Sorry, neglected to answer the last point fully.

    … then creating a logical model IS tantamount to programming DML [DDL?], and specifying a great deal about the behavior of the programs using the data.

    So the answer, I think, is no – the physical requires more information than the logical can provide (just like programming requires more than just an architecture and design can provide). That information will either be provided by the designer, or by runtime information (assuming that a prototype is run and generates usage profiles), though more likely the former until DBMSs are able to do the latter.

  7. Curt Monash on October 13th, 2005 11:40 am

    Anyhow, on Points 1 and 2 — I stand by my assertion that data architects will
    always have to be aware of the performance implications of what they’re
    designing, just as programmers have to be. That doesn’t quite prove “FROM”
    isn’t an abomination in a SELECT clause, but it’s at least a plausibility
    argument in that direction … which is actually a digression.

    The real point is this. What was wrong with the old navigational data models
    wasn’t that programmers had to do updates navigationally. It’s that all the
    queries had to be navigational too. But these days, people do SQL queries
    against object and/or XML databases all the time. So the benefits in some
    parts of the development process of the relational model are less than they
    might at first appear, and thus it is plausible that they can be
    outweighed by benefits of, say, an object model to other parts of the
    development process.

    And I don’t just think it’s plausible — in increasingly many apps, I think
    it’s actually true. E.g., some of the most sophisticated medical records
    systems in the world are built on Cache’ rather than on an RDBMS. I think
    the most sophisticated text applications will be built on XML DBMS. In both
    cases, I think the reason is both performance AND programmer productivity.

  8. Eric on October 14th, 2005 7:01 am

    As for the intelligence you’re asking for — I think it’s still a long way off … you’ll probably share my guess
    that what you’re asking for is a decade or more off.

    You’re probably right – I would just wager that a DBMS and language with some semblance of closure (Tutorial D’s is a decent one, though not the only one) would offer a far better formal basis for this than the innumerable nooks and crannies of SQL. But given how little SQL has really “advanced” in the last decade, such optimizations would be a feat.

  9. Eric on October 14th, 2005 7:09 am

    … I stand by my assertion that data architects will always have to be aware of the performance implications of what they’re designing, just as programmers have to be.

    “Aware” is much weaker than saying “Logical and physical modeling will never be completely separable.” In any event, the same person can perform multiple roles (logical data modeling and physical data modeling), but that doesn’t mean they’re not distinct.

    That doesn’t quite prove “FROM” isn’t an abomination in a SELECT clause, but it’s at least a plausibility argument in that direction …

    Not sure what you mean…

  10. swiss army watches on February 9th, 2006 11:18 am

    Well, that’s acccurate imho, and it’s also good to see this great blog is getting better. ;). Thanks
    Elandar

    THIS IS THE KIND OF SPAM I HAVE TO EDIT/MODERATE OUT ALL THE TIME — CAM

  11. Curt Monash on February 10th, 2006 1:47 pm

    Eric,

    My point was that the FROM clause likely adds a lot to performance. Thus the relational purists who whine about are, once again, ignoring technological reality except in the narrow aspects that they focus on.

  12. Anthony Youngman on April 13th, 2006 3:20 am

    “Logical and physical modelling will never be completely separate”.
    Okay, here’s a simple proof.

    Logical modelling is a mathematical activity. Mathematics has NO
    CAUSATIVE LINK WHATSOEVER with the real world. Physical modelling lies
    within the real world. The link between the physical model and the
    mathematical model is the scientific bit.

    By completely separating physical and logical modelling, you’ve just
    placed yourself in the realm of ivory towered theoreticians, your
    database completely in the realm of pure mathematics, and made
    the statement “I don’t care whether my database and reality coincide,
    that’s not relevant to the problem”.

    Cheers,
    Wol

  13. Curt Monash on April 13th, 2006 3:40 am

    Wol,

    I think the true point is stronger than one that can be proved by that
    kind of abstract observation.

    It’s obvious that ANY computer system is in some way restricted by
    physical-world limitations. I think even Chris Date and Fabian Pascal
    understand that, at least on their good days.

    What I’m asserting is that those limitations will indeed, for a significant
    fraction of applications, be relevant in practice. To see why that’s true
    requires a further observation:

    Not only are there physical-world limitations, but our demand for
    computing power is such that we keep pushing up against them.

    That’s as much my Point #2 on the list as it is my Point #1.

    And it’s not just machine capacity, either. There are lots of policy
    restrictions as to where data can be physically stored. And as the
    recent disclosure of NSA snooping at AT&T demonstrates, those policy
    restrictions are by no means all silly.

    CAM

  14. Anthony Youngman on April 13th, 2006 6:29 pm

    I think we’re talking slightly at cross purposes :-)

    You’re saying that it’s impossible to separate the logical and physical.

    I’m saying it’s pointless to try, because to succeed would prove (in a narcissistic way) that you are totally irrelevant to the real world.

    That’s why I hammer the point that the RM, as championed by Pascal and Date, is a (crap :-) exercise in Pure Mathematics. As such, it denies any links to the real world and should be ignored by anybody in the real world (such as programmers trying to solve real problems :-).

    Cheers,
    Wol

  15. McKay Salisbury on April 24th, 2006 2:34 am

    Wow, I couldn’t disagree with you more.

    1. Logical and physical modeling will never be completely separable.
    Why not? Optimization? Seems as if you haven’t seen any of the absurdly slow OODBs out there. There are TRDBMSs out there. Ones that support Logical data independance and physical data independence. That’s the goal. Once you have true pysical data independance, then the optimization comes in being able to change the phusical layer based on need. Then we have the best possible optimization. A storage mechanism built for the specific logical layer!

    2. “True relational” DBMSs are very unlikely ever to be practically useful, except perhaps in narrow niches.
    So what if they’re a little slow. The ease of use generated from them is worth it, if for no other reason than data modeling. And it actually can be faster. (your webpage data entry sucks, stuff goes off the screen on large resolutions. I can’t see what I’m typing. [database interface? You've lost at least some Database cred in my book.]).

    McKay Salisbury

    3. Enterprises don’t fully control their data models.
    Not “Enterprises can’t” but “don’t”. It is possible.

    4. Duplicated data is not inherently bad.
    This is *not* an argument against the relational model, but an argument against normalization. Fully-Normalized database schemas aren’t for all aplplications

    5. Saying that the relational model (RM) is based on mathematics proves almost nothing.
    Saying that “Saying that the relational model (RM) is based on mathematics proves almost nothing” proves almost nothing. 2000 years of mathematics has gone strides to optimize things. Mathematitians have been banging their heads against Set theory for forever. We know what we’re up against because of that. Perversions that go against established set theory (SQL not actually returning relations) is where we go into trouble.

    6. IT isn’t just concerned with facts.
    What you’re saying in your article is “IT isn’t cocerned with incomplete facts”. Seems like you need an Enterprise controlled database.

    Oh, let’s go to September!
    Saying you have “several” examples then only showing 3? Is that really “several” it’s pusing it, oh, wait, you really only have 2.
    You mention several (and *I* mean several) relevant datatypes, are you confusing “Relational” with “first-normal-form relational”? Cuz I think you are.
    How is a “Comprehensive and accessable data bank” a problem with the relational model. You said yourself, that it’s a problem in computational linguistics and security. Integration and Data type support *are* trivial, maybe you need a new DBMS that supports real-world datatypes.

    Why can’t concept-based searches exist in a DBMS? oh, wait, *they do*. Sounds like you need a better DBMS. Your DBMS2 Might actually solve these problems you mention, but it doesn’t have to axe the relational model. Semantic ideas can be present in relational databases. The kinds of things most people mean when they want to add “object-oriented” principles to databases can be done relationally, but it isn’t at a cost of the relational model, it’s at a cost to Objects, in favor of tables.

  16. Curt Monash on April 26th, 2006 9:54 am

    McKay,

    I have trouble finding something there to respond to that hasn’t already been covered at length in the blog.

    Well, some of your statements are just factually incorrect or otherwise silly, but I’m not referring to those. The substantive ones have, I think, been largely addressed.

    One thing I do struggle with is all the different sects of relational worshippers, each believing they have True Understanding of the words and concepts. You evidently don’t agree with Chris Date and Fabian Pascal on how to use the terms, although you’re closer to them than to sloppy industry-standard marketingese usages.

    As to your paraphrases of me, I can only say “Huh?” I also don’t see what relevance your comments about OO have to any of this.

    And as for your claim that enterprises “can” control their data models — yeah, they can, if they don’t have purchased software or legacy systems. But not a lot fall into that category.

  17. McKay Salisbury on May 18th, 2006 2:46 am

    I apologize if I wasn’t entirely clear. This is what I did:
    I went through both of your columns and I countered each of your arguments. So if I made a comment, I don’t think it was covered well enough in the columns you wrote.
    I also made fun of your website.

    I did make comments about Object-Oriented principles, because in your September Article, you mention that DBMS2 will combine Relational with Semantic and OO philosophies.

    My summary is that you state no *actual* limitations on the relational model. While the model does have limitations, you don’t state them. Calling your article “Limitations of the Relational Model” just isn’t true.

    I am a relationist. I side with Chris Date on most of what he thinks, possibly because I was trained in his ways. I don’t generally side with the way Fabian goes about doing what he does.

    Oh, and if I’m “factually incorrect or otherwise silly” please point it out so I can defend what I said, or see my mistakes so that I won’t make them again.

    I guess I’ll restate some of what I said above:

    I personally believe that it is important to seperate the logical and physical layers. The physical implementation should be abstracted away from database schema designers.

    I agree with you when you say that duplicated data is not inherently bad. But this doesn’t mean that the relational model is bad. The relational model supports duplicate data if you want to design your schema in such a way. If you want to denounce the complete elimination of duplicate data, don’t say that the relational model is in your way. The relational model allows you do duplicate your data if that’s what you wish.

    The relational model doesn’t prevent you from having complex data types in your database.

    McKay Salisbury

    (oh, and your data entry form is *really* annoying me.)

  18. Curt Monash on May 19th, 2006 7:30 am

    Mckay,

    If you so strongly dislike the lousy wrapping “functionality” on the comments here, I suggest you:

    A. Complain to the author of the WordPress “Sharepoint-Like” theme that I’m currently using (I’ve done VERY little hacking to the software here, so I’m pretty sure I didn’t introduce that behavior myself).

    B. Stop posting here directly (perhaps pointing back from a blog of your own, although I must confess trackbacks is another currently questionable piece of functionality).

    C. Write in the editor of your choice and paste your comments here.

    As for your apparent belief that enterprises should seriously aspire to perfect, perfectly controlled data models, please let me check:

    Are you referring to large enterprises, with decades of legacy systems, that make multiple acquisitions of other companies each year, that are in many businesses, that find it desirable to buy packaged software from many different vendors, and that are constantly looking for ways to capture and exploit new kinds of information more quickly than their competitors do?

    If so, how exactly do you propose they do it?

  19. McKay Salisbury on May 19th, 2006 4:27 pm

    In my last post, I made no mention of controlling the data model.

    You are correct in that regard. Many companies have several legacy systems, or prepackaged software. Expanding can be difficult in such circumstances.

    If they need to capture and exploit new kinds of information either they need a system that can be expanded in such a manner.

    Are you aware of the ITIL CMDB specificaiton? In it’s fullest extent, it allows for growth to cover virtually all aspects of a corporation. Such a system can be made in a relational database.

    No, this doesn’t really solve integrating several legacy systems, but VDBMSs can.

    How does DBMS2 handle the situation?

    You still haven’t answered my real question: “What are the limits of the relational model?” I’ve yet to read anything by you that gives limitations of the relational model. Complex data types and duplicate data can be stored in relational databases, and you appear to claim that they cannot.

    Also, I think the beauty of the relational model is that it provides an abstraction between the physcial layer and the logical layer, so that the databse designer doesn’t have to even think about the physical layer. What’s the harm in that?

    McKay

  20. McKay Salisbury on May 29th, 2006 2:23 am

    I read through your posts again, and I’m trying to discover what you meant by “You evidently don’t agree with Chris Date and Fabian Pascal on how to use the terms” I coudn’t find anything I wrote that is in disagreement from a glossary perspective with anything that I wrote. The closest thing I could think of is what I said about something being “relational” when compared to “first-normal-form relational” And I’m not entirely sure where Date and Pascal are on the matter, I do remember in some of Date’s earlier textbooks on Relational theory implying that the Relational model requires first normal form, but I attended a lecture by Hugh Darwen, where both Date and Pascal were in attendence and apparently in agreement, where Darwen talked about “Non-first-normal-form relations” were actually in first normal form. Or more simply, the silliness of first normal form. Which is, in effect saying that Relational does not mean Atomic datatypes. But you are correct in saying that the term “relational” is understood by many to mean many different things.

    In any case, I want to come to a greater understanding of where your and my opinions differ, but you’ve written in such vague terms, that I’m not understanding, and I’m forced to take stabs in the dark like this.

    McKay Salisbury

    P.S. I hate to mention this, because when I do, it seems as if you get sidetracked and neglect (or don’t fully expound on) other issues I bring up, but and with regard to your commenting about my comments about WordPress, I have no desire to contact the makers of this theme you’re using. It shouldn’t be my concern that your webpage has this nasty bug in it. It should be yours. Your problem is is that you use this “purchased software” or “legacy systems”. And you’re having trouble yourself controlling your system. My criticism of you pinning this blame on others, is the same as your criticism of me saying the relational model can’t handle this, except that the relational model wasn’t designed to integrate legacy systems with purchased software, it was designed to provide an easier access at the data.

  21. Curt Monash on May 29th, 2006 3:31 pm

    McKay,

    I’m not aware of a “nasty bug” in the commenting technology.

    A “nasty bug” might be one that lost every 20th word in a comment.

    What we have here is a UI weakness that makes it desirable for your to hit
    your own line breaks rather than rely on the software to do it for you.

    I.e., all we have is the absence of a desirable feature.

    I tolerate it because other software at the same price which has this
    feature unfortunately lacks other features that I regard as more important.

    That said, if you indeed are suffering data loss from some aspect of the UI,
    please let me know and I’ll take action accordingly.

  22. Curt Monash on May 29th, 2006 3:34 pm

    McKay,

    My sense is that Date and Pascal would now say first-normal form is utterly
    required for something to be relational.

    Date freely concedes that definitions and understanding have evolved over the
    years, but that seems to be the current, emphatic position.

    That’s indeed what I was referring to.

    CAM

  23. McKay Salisbury on June 4th, 2006 2:18 am

    Re: Nasty Bug.
    So maybe saying “nasty bug” is a bit
    excessive. But this is clearly the
    case of a UI bug. I imagine a system
    that lacked this feature you speak
    of would be a lot like Windows’s
    notepad without a word wrap feature.
    In Notepad’s no-word-wrap mode (and
    WordPerfect for DOS, and other
    “text” editors without a wrap
    feature) typing when there is no
    longer any available space scrolls
    the visible text to the right, but
    the text currently being typed is
    visible. It is a basic prinicple of
    UI design to allow the user some way
    of seeing what he types.

    Sure you can say that I should put
    in line feeds myself, but, as you
    can see, this then removes control
    from the viewer. Virtually all
    modern web browsers have a word-wrap
    feature. In most web pages, if one
    wants to have text lines bigger,
    they can make the window bigger. But
    if the person who created the text
    put his own line feeds in, the
    reader has no more control.

    McKay

  24. McKay Salisbury on June 4th, 2006 2:33 am

    I’m not
    convinced
    that Date
    and Pascal
    would agree
    with you on
    that
    statement of
    the first-
    normal form.
    I would have
    to admit that
    I’m not
    entirely sure
    on the
    matter. Hugh
    Darwen on the
    other hand
    would almost
    certainly
    disagree with
    you, unless
    you were
    willing to
    make a
    concession.

    Maybe this is
    the wrong
    place to be
    discussing
    this (and
    especially at
    this
    resolution of
    mine.) But
    I’m very
    curious what
    you mean by
    “first-normal
    form”. Darwen
    makes a great
    argument for
    databases
    that you
    would claim
    aren’t first-
    normal form
    being first-
    normal form.

    But yes, the
    definition
    has changed
    quite a bit
    over the
    years.

    McKay
    Salisbury

    P.S. The fact
    that the text
    is inputted
    in a fixed-
    width font
    and the text
    is viewed in
    a variable-
    width font
    means that
    even if I
    try to stay
    consistent in
    my column
    widths, I am
    unable to
    preserve that
    spacing in
    the resulting
    text.

  25. McKay Salisbury on June 4th, 2006 2:41 am

    Oh, but my *real* question remains. WHAT ARE THE LIMITATIONS OF THE RELATIONAL MODEL? I don’t think you’ve even tried to answer this very real question of mine. You haven’t actually established and real limitations with this model. It’s a point I thought I brought up very clealy in my first post here (April 24), and on every subsequent set of postings since then. It’s my real fault with your article. I don’t believe that you’ve actually pointed out any weaknesses with the model. You have bene unable to give me one shred of evidence that you’ve even understood the question I’m posing. I (obviously) believe that the relational model is great. You appear to have serious qualms with it, and I’ve rebutted all of your claims against the relational model, and I’d like to hear your responses on the matter.

    McKay Salisbury

  26. Curt Monash on June 11th, 2006 3:20 am

    McKay,

    I’m really not interested in your general rants, falsely asserting I haven’t answered your question. Why don’t you instead go comment on the answers I’ve provided, and explain why you think they’re inadequate?

    Maybe you could start with http://www.dbms2.com/2005/12/09/relational-dbms-versus-text-data/

  27. François Cartier on August 18th, 2006 9:35 pm

    There is an logical/physical modeling area where ths RDBMS, and the DDL that supports them, usually fall flat on their faces: subtyping.

    Why can’t we have, with the corresponding DBMS functionality, a DDL statment of the type like:
    ALTER TABLE
    ADD FOREIGN KEY ( [,])
    SUBTYPE OF ( [,])
    ON = ;
    where a new keyword, SUBTYPE OF … ON, replaces the keyword REFERENCES.
    The last column name is in the 2nd named table. The constraint rule would always be an implicit ON [PARENT] DELETE CASCADE.

    This would be better than the current R.I. constraint plus R.I. trigger set, which is 100% effective only when combined.

    François

  28. The Memory Leak » Blog Archive » Layers and Holism on August 30th, 2006 5:08 pm

    [...] I submit that the FeatureLayer concept is really joined at the hip with Codd’s relational model.  There’s been a lot written about the shortcomings of the relational model, for example here.  Usually the criticism is followed by some sort of proposal for an xml database.  What is needed is an ILayer for xml. [...]

  29. nadeeem on February 12th, 2007 3:54 pm

    good but point not clear for students of mba

  30. Hanan on November 12th, 2011 7:08 pm

    I am with you nadeem , but i really intersted in this fighting with and against .. :)
    and i get confuse what to write in the report

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.