On 23/12/10 16:29, Shawn Hayes wrote: > I don't know a lot about fully normalized relational database but I do know > you > can read the the schema of a database. (Again - just thinking out loud) > They > have Master Data Management (MDM) tools that collect, aggregate, match, > consolidates, persists and distributes data to ensure consistency and > control > of this information.
The whole point of a relational database, though, is that it "simplifies" things. But when Occam said "don't multiply entities unnecessarily" he didn't say "don't multiply entities at all". Einstein added the corollary "but don't simplify *too* *much*". > By using this kind of tool, theoretically, you could re-build your schema in > an > MV format that would take advantage of MV technology. To Ross's point, the > technology might not be there for real-time processing across databases, > however, you could get near-time. And outside of transactional processing, > near-time meets the needs of most projects. No. Theoretically you are *sunk*. Once the data has been converted into relational (first normal) form, your relational schema is *useless* for designing an MV schema, because all the *most* *important* (meta)data has been thrown away. Without that metadata, no database can be provably efficient, and *by* *design* relational databases throw that information away - which is why they are so terribly inefficient. By the way, don't abuse the phrase "real time". MV is far more "real time" than relational because (a) it is fast - which is pretty irrelevant, but (b) because it is also *deterministic*. "Real time" means you can guarantee a response in a given time frame - "you MUST shut down the reactor in under ten seconds, because otherwise there won't be a reactor to shut down". By its very design, and inability to guarantee ANY response (other than "completion is inevitable, given enough time"), relational is NOT a real-time database. > I just see a lot of people looking to migrate data off of MV, I think by > creating an "easy" migration path to (and from) an MV environment, you would > draw more attention. > > > Not to get to far into this discussion (at this time) I respectfully disagree > with those who have said that your data needs to be application specific. > This > thought puts the emphasis on the application and not on the data. And it's > all > about the data! Applications are easy to build and they SHOULD be much more > dynamic then they currently are and that is because business is dynamic. Actually, I'd disagree with you. Applications are all about the METAdata, which a relational database throws away. ALL relational APPS contain an awful lot of logic to manage stuff that SHOULD be managed in the database - except an RDBMS has no way of managing that information so it can't be managed in an RDBMS. I talked about adjectives out there in the real world. Adjectives describe nouns. What's the database equivalent of a noun? That's right, in an RDBMS there is NO SUCH EQUIVALENT. In the database/programming world in general, it's called an object. Which is why, DONE PROPERLY, MV databases fly. They store one object per record, properly normalised. The result is that accessing any attribute promptly caches any other *tightly*-*related* attributes. And it ignores any loosely related attributes. (But it also provides an easy "drill-down" to get at those loosely related attributes.) RDBMSs have no concept of "noun". To paraphrase Einstein, they are "too simple". And that is why you cannot go from a relational schema to an MV schema. Because MV needs to know the difference between tightly-coupled relationships and loosely-coupled relationships. And that information is NOT stored in an RDBMS, but in the apps that run on the RDBMS. Cheers, Wol _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
