Talk:Data model

From Wikipedia, the free encyclopedia

 This article is within the scope of WikiProject Databases.
Stub rated as Stub-Class on the assessment scale
High rated as high-importance on the assessment scale

Contents

[edit] Remarks

I have the impression, that the whole area of data model, database model and database management system might have to be made clearer and restructured. The practical use of terms often is unclear and leads to inproper use of terms.

Proposal:

Database model: everything what is related to general design/concepts how data can be structured (relational, hierarchical, network, object-oriented, ...)

Database Management Systems: technical aspects of the implementation of database models (e.g. languages like SQL, indexing, ...)

Data model: aspects of designing a specific application (Entity-Relationship- Diagramm, UML, ...)

Database: the implementation/instance of a data model

... --Udo Altmann 15:15, 17 Oct 2004 (UTC)

[edit] Wrong examples of two meanings?

I'm not sure I agree with the examples. They seem to imply that the relational model is a data model in the first meaning and that the ER model, FDM, UML and ORM all fall within the second meaning, but that would not be correct. All are examples of data models in the first meaning and in both models you can describe data models that are specific for a certain application. -- Jan Hidders 11:52, 18 Oct 2004 (UTC)

It is correct, that the relational model is a database model. The ER model is part of design methods used to create a domain specific data model especially for relational databases. I'm not sure about the exact meaning of functional data model and object role model that the previous authors of this article had in mind since terminology depends on opinion leaders. I think it is better to make an extra section for design tools. --Udo Altmann 13:35, 18 Oct 2004 (UTC)
 ?? Where did I say that the RM is not a database model? The point is that the RM, FDM, ORM, UML class diagrams, et cetera are all data models in the same sense of the word, i.e., they are not application specific and give you a notation to model data. Of course the RM is closer to the physical level than the ERM and therefore less abstract, but they are definitely both data models. But the term is also often used to refer to a specific data model for a certain application, organization or bussiness, (as in "the data model of my company") which is then written down in the notation of either ORM, UML, IDEF1X or whatever. From this point of view the ERM is actually a meta-model because it gives a model of how your application-specific models look. (But the terms meta-model and meta-modelling already have another well-established meaning.) So those should be the two meanings that are discussed on this page, but you seem to identify the first non-application-specific meaning of data model with that of "database model" which is not correct because not all data models are database models. The ORM and FDM data models are well-known and well-defined data models that can be readily found in the relevant scientific literature. Why you claim that the interpretation of these terms depends upon opinion leaders is a mystery to me. -- Jan Hidders 12:04, 19 Oct 2004 (UTC)
A data model is not necessarily a database model. For instance, IDEF1x is most certainly a data modeling paradigm, but there is no database management system that implements it as the core representation of data in its database engine. Data modeling is, by its nature, an abstraction. We don't have to have a database engine that implements the data model paradigm for it to be considered a true, and useful, data modeling paradigm. KeyStroke 14:19, 2004 Oct 19 (UTC)
Well I didn't say that Jan Hidders said that the RM is not a database model - I agreed with him. But nevertheless. I think it is important to distinguish between the model how a database management system works, the idea how data structures can be defined - relational, network, hierarchical - and the methods to design a specific model. As you say, ORM and UML are notations and so I would say is the ERM Method. So we have the methods in which (data) models can be defined - the meta-level (?) - and for example the concrete entity-relationship diagram (sometimes also called entity-relationship model; it is clear, a pure diagram does not contain all details about the data definitions of an application). But meta-level is not meant as "is-a" relationship, so I don't say that data models are database models and I don't say that concrete entity-relationship models are specializations of the entity-relationship model method. It's simply the relationship between methodology and applying a methodology. This is, what I wanted to clarify - hope you can agree. --Udo Altmann 14:30, 19 Oct 2004 (UTC)
I think you are over-analyzing this. The "common vernacular" when referring to what we are talking about here is "data models". If I were to lay a diagram from ER-Win in front of an experienced data modeler and ask him/her "What is that?" the answer would be "a data model". The answer would not be "the result of applying the data modeling methodology". Remember, K.I.S.S. Lets not get overly academic about this. KeyStroke 15:37, 2004 Oct 19 (UTC)
Sure. I just felt a little misunderstood and wanted to clear that point. The only point which we should discuss about is, whether the article should be improved and if yes how. In my opinion it is not too much academic. --Udo Altmann 16:13, 19 Oct 2004 (UTC)
There was indeed a misunderstanding on my behalf and I think I now know what caused this, so allow me to overanalyse this even more. :-) There are in fact two important distinctions that need to be made when talking about data models and I thought Udo was talking about another one than he really was. The first distinction is the one between a data modelling paradigm (such as the ER model) and a concrete instance of that paradigm (such as a certain ERD). Both are often called "data models" and I thought this is what Udo meant because he talked about a "domain specific model" and "data of a specific application". Note, by the way, that this distinction is important enough for it to be discussed by Chris Date in his "An Introduction to Database Systems". But what Udo apparently meant was the distinction between more concrete data models (such as the RM) and more abstract data models (such as the ER model). Although I certainly agree that this distinction should be made, I also claim that it is important to realize that this is a gradual distinction and not a fundamental one. As a case in point look at the Functional Data Model (FDM) which was originally introduced as a database model but is in fact at a higher abstraction level than the RM and now is mostly used as just a data model. Another example is ORM (or NIAM which actually is a method and not just a data model) which is not just a notation but has a well-defined formal semantics and could easily be used as database model, and finally the database models that were proposed for object-oriented databases that were at the same time concrete (because database models) and abstract (because at a higher abstraction level than the RM). So, Udo, do you agree with this analysis of the situation and that this should be explained better in the article? --- Jan Hidders 17:25, 19 Oct 2004 (UTC)
So I myself have to admit that I had somehow a too narrow definition of data model in my mind since I thought mainly of the data aspect (I think many people do so since this is the persistent aspect). In fact some methods have a specific part dedicated to data modelling. I think we could agree that the article has to make clear the distinction between the datamodelling methods/paradigms and the instances. References could be made to the most popular and well-known paradigms like relational, hierarchical, ... since these are the theoretical foundation of Database management systems (although theory often not completely implemented). In this sense they are models for databases (database models). I'm not sure, whether the version of September 12th is the better starting point or the current version. --Udo Altmann 20:29, 19 Oct 2004 (UTC)

[edit] Data Model and Data model

What about http://en.wikipedia.org/wiki/Data_Model and http://en.wikipedia.org/wiki/Data_model ? —The preceding unsigned comment was added by 82.200.65.190 (talk • contribs) 2006-03-23 10:11:42 (UTC)

[edit] Marketing Material

The External Links section looks like an advertisement.

"Swiss based ECOFIN is a leading company providing financial solutions...."

152.119.41.164 13:19, 20 September 2006 (UTC) Greg

Commented out the ECOFIN content that looks like blatant advertising. Please provide authoritative reference or an explanation for why this should not be permanently deleted from the article. Dreftymac 05:50, 11 October 2006 (UTC)

[edit] from the Data Model article

A data model is a concrete representation of an information model. It represents the entities, properties, relationships and operations defined in an information model in a manner that allows actual instances of those entities to be managed, manipulated, stored, operated upon and verified.

-- phoebe 03:58, 22 November 2006 (UTC)

[edit] Check the article

Please check the article. I reversed some content due to vandalism. —The preceding unsigned comment was added by 194.117.36.2 (talk) 14:59, 28 February 2007 (UTC).