Talk:Multidimensional database

From Wikipedia, the free encyclopedia

References to the Pick operating system, and the external link to pickwiki may be unintentionally misleading. Pick supports a multi-value, not multi-dimensional data model, concepts which I beleive are very different.

--Burt Harris 05:48, 26 August 2006 (UTC)

I would agree; it seems that multivalue (or 'post-relational', which I prefer because it sounds more advanced!) databases have been lumped in together with multidimentionals. The first paragraph shows the different usages of 'multidimensional', so I don't think this is a minor difference. I vote we split the multivalue ones out. As far as I know, this means we take out Pick, OpenQM, U2, UniVerse and UniData, and leave the rest. Karaken12 08:18, 26 August 2006 (UTC)
Yes I agree too (although I disagree with Karaken12 that multivalue is 'post-relational', it is in fact 'pre-relational', and I would say it is less advanced). I also think there is a confusion between hierarchical or network databases and multidimensional databases. I think the confusion is primary due to fact that OLAP systems offer both multidimensional access patterns and hierarchical navigation. Wikiolap 16:48, 26 August 2006 (UTC)
Technically it is post-relational (whether you think it is more advanced or not!) since it breaks one of the axioms of relational databases. Unfortunately I'm no database expert, so I can't say with great certainty, but afaik a post-relational database is one where multiple values (n-tuples) can be referenced in a single field; essentialy, multivalues.
Just out of interest, I notice that a google search for 'post-relational' throws up Caché as it's first result. Karaken12 10:53, 28 August 2006 (UTC)
I promised to myself I'd steer clear of my professional fields whilst on WP, but I can't help but nose around. The separation is necessary.
Pick, et al are commonly referred to as multi-value, or post-relational databases (the latter being coined, IIRC at a Pick vendor conference). Merely breaking one of Codd's tenets does not make a database post-relational, it merely makes it non-relational. "Post-relational" is simply market speak for "newer than relational", which it both is (as the model and products have been subsequently developed and improved) and is not (since it dates back to the late 1960s). Cain Mosni 02:28, 25 October 2006 (UTC)

[edit] Proposal to merge with Dimensional database

  • Support as nominator Wikiolap 22:52, 8 December 2006 (UTC)

I agree that it is confusing to have both PICK (and MUMPS) databases, which often use the term "multidimensional" (while Pick is also formally termed "MultiValue") together with multidimensional databases built exclusively for business intelligence, for example. The former are multidimensional in a way that pre-dates relational theory (although they are termed "post-relational"), while the later are multidimensional based on what was found to be missing in typical relational databases when it comes to data analysis, if I understand correctly.

Because both categories of databases really do exhibit a multidimensional model (even if different ones--MUMPS and PICK have different multidimensional models too), I think it is OK to keep them in the same document, but make clear the distinction. There is some small amount of overlap in that those using Pick have no need for another multidimensional database (other than for related tools). A Pick (logical) file with a multi-part key is a virtual fact table with the dimensions being the parts of the key. [This is my first talk page comment, so apologies if anything is amiss.] Dwolt 22:43, 9 April 2007 (UTC)

  • Neutral: But something definitely needs to be done. There seems to be significant overlap with dimensional database, but also some unrelated material in here. I think we need some experts. Mdotley 22:18, 16 April 2007 (UTC)
  • Opposed: I think there should be categories of multidimensional, but we should not bump products out unless they really do not permit multiple dimensions, something that both PICK and MUMPS products permit.
I propose at least two, possibly three, categories under this topic. We could handle Multidimensional like the term MultiValue. MultiValue is trademarked as an umbrella term for products in the MultiValue family tree (see pdf from http://www.tincat-group.com/mv/familytree.html ). MUMPS is also multivalued (or multi-valued) but does not classify as MultiValued (Cache' is now both MUMPS and PICK, so it is, therefore, a MultiValue database).
We could use big-M Multidimensional as an umbrella term for a type of product or data model and a small-m multi-dimensional (or multidimensional) for multidimensional products that are "different". I do not know what distinguishing characteristics products under the big-M umbrella have that PICK and MUMPS do not, but I'm guessing there are some, so we should identify these. Also, there might be some under the big-M umbrella that are built on a relational model and others that are not, possibly splitting that into two categories.
I have not seen a compelling reason to boot any databases that claim "multidimensional" as a feature from this page, but if we want to make the call about each database, then perhaps we should identify what, precisely, distinguishes a database as multidimensional. Dwolt 00:52, 23 April 2007 (UTC)

I just deleted the MUMPS related DBSs from the list. However, I was unaware that there is an ongoing discussion. So here is my explanation: The term "Multidimensional database" was coined in the context of OLAP in the 90ies. One of the core criteria for multidimensional databases was that they provide independent dimensions of access. With MUMPS and related products this is not the case: The "dimensions" of a MUMPS global are actually hierarchy levels: You need to know the first level before you can access the second level. In addition, Caché and GT.M are aimed at OLTP and not at OLAP. 137.248.254.151 08:52, 27 April 2007 (UTC)

Oh, well, I didn't expect that. I understand that some people are only aware of the term multidimensional used with OLAP. I might be one of the handful of people who has worked both with multidimensional databases doing OLTP and with multdimensional databases with OLAP. I know PICK better than MUMPS. It is NOT the case that these two concepts are independent. In fact, those with PICK databases have been less likely to use tools specifically designed for OLAP because they could do OLAP-ish with their virtual cubes in their multidimensional OLTP databases. I don't have to press this issue, but I think it was a poor decision in that it is a political decision to remove multidimensional OLTP databases from this topic. I will leave it in the hands of the other editors, but my impression was that we were supposed to aim for accuracy and I think we lost some when eliminating all of the PICK and MUMPS products from this topic. --207.199.203.183 16:16, 3 May 2007 (UTC)
I think terms are defined by the market, not by precision. You would be hard-pressed in the current literature to find multidimensional database to refer to anything other than Essbase, Powerplay, TM/1 or Microsoft AS. Historically, there were more, such as Express, Pilot Lightship Server and others I've long since forgotten about. I don't know where to put Oracle's OLAP capabilities. I also have a problem with the first sentence, "difficult to model in SQL." First of all, no one models in SQL. Second, I don't think the schema in a MDDB are necessarily hard to model in a relational database (take the star schema for example). I think they don't perform well and that is primarily why MDDB's get used. Neil Raden 21:07, 14 September 2007 (UTC) —Preceding unsigned comment added by Nraden (talk • contribs)
Can someone explain to me why even though I sign my comments with 4 tildes, I still get this SineBot message?? Neil Raden 15:32, 20 September 2007 (UTC) —Preceding unsigned comment added by Nraden (talk • contribs)

[edit] Which definition of the term is assumed in the article?

The article starts with a somewhat convoluted sentence, pointing out that there are several different definitions of "Multivalued Databases (MDDBs). It then goes on to tell us how useful MDDBs are for analysis of time series, without telling which of the definitions it is using.

The article then goes on to describe the "data cube" concept, without telling us how it relates to the various meanings of MDDB.

Next comes a unsubstantiated claim about MDDBs being better than relational databases for some tasks, follwoed by a lot of vague handwaving about the shortcomings. Still we are not told which definition is being used.

Bottom line: Could someon please insert a paragraph after the first one of the form "In the rest of this article, MDDB is taken to mean X". NisJorgensen 18:39, 3 July 2007 (UTC)

[edit] Split the Article

Lets start this discussion. We should probably start with a taxonomy, splitting between storage architecture, access method, semantics. For example, a hybrid MDDB stores data in a proprietary format, relational indexed and pure relational. Access methods can be MDX or proprietary (are there others?). We should distinguish between a star schema, which is not a MDDB, and a MDDB, even though they may have the same semantics. These are just suggestions and I hope they can be refined in true Wiki fashion. Neil Raden (talk) 20:58, 30 January 2008 (UTC)