Page 1 of 4 123 ... LastLast
Results 1 to 15 of 46
  1. #1
    Join Date
    Dec 2004
    Posts
    18

    The Concept-Oriented Database Model - what do you think about that?

    Hi,

    what do you think about the new concept-oriented data model described here: http://conceptoriented.com? Does it make sense?

    alex

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    No, not really. The best I can make out of it is an overly-complicated set of rules for schema design.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Apr 2004
    Location
    Toronto, Canada
    Posts
    249
    I had a brief look at the website. It does not seem to be very clear.

    Please remember that relattional database theory is based on Predicate Logic and Set theory, two well established branches of mathematics. Based on this, we can make assertions about the data integrity and, to some extent, the meaning of the data.

    Any new paradigm that is suggested must be shown to be at least as good as relational theory, and must have a good theoretical basis.

    Concept Orientation does not seem to be anything different. I agree with Teddy's opinion.

    Our profession is full of people who are "buzzword compliant and content-free." Therefore, as software professionals, we should look at new ideas with a healthy dose of scepticism, since a lot of software is marketing, and eventually turns to vapourware.

    Ravi

  4. #4
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by Teddy
    No, not really. The best I can make out of it is an overly-complicated set of rules for schema design.
    Actually, there is only one such rule used to describe schema:

    a table is a combination of its supertables

    Or, equivalently, each table is included into its subtables. Add formally top table and bottom table in order to get a lattice and that is all. All other mechamisms such as attributes, values, relationships, inheritance, multidimensionality, hierarchy, grouping, aggregation, inference, single and many valued variables and many others can be derived from this rule. Actually the main design goal of this approach was to simplify the model as much as possible by removing numerous unnecessisary elements.

    The description provided is not the best, I agree, but it is the initial version. The complexity of the description is due to the desire to describe all possible mechanisms that can be implemented in or derived from this model.

    alex

  5. #5
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by rajiravi
    I had a brief look at the website. It does not seem to be very clear.
    Yes, sorry for that. This is, particularly, why I was asking for your opnions.

    Please remember that relattional database theory is based on Predicate Logic and Set theory, two well established branches of mathematics. Based on this, we can make assertions about the data integrity and, to some extent, the meaning of the data.
    In contrast, the proposed approach is based on lattice theory and ordered sets. One consequence is that the model is intrinsically hierarchical and multidimensional - we are not able to separate these two properties in the model. This means that at the syntactic (schema) level each table is simulatniously included into several its subtables while at the semantic level each record is included into a set of its subrecords. Most of the practical advantages can be seen only by considering concrete mechanisms (including integrity).

    Any new paradigm that is suggested must be shown to be at least as good as relational theory, and must have a good theoretical basis.
    I hope it is so for the concept-oriented approach, i.e., it has a good theoreitcal basis and allows us to model very different existing mechanisms and practical use cases.

    Our profession is full of people who are "buzzword compliant and content-free." Therefore, as software professionals, we should look at new ideas with a healthy dose of scepticism, since a lot of software is marketing, and eventually turns to vapourware.
    You are absolutely right.

    But believe me that I was not waiting for a "positive" response (it would be too native). The only goal of this post is to collect some responses in order to enhance the description and to distribute information about "something different" for those who is interested.

    Generally, if people are satisfied with the existing models (absolutely natural situation) then it does not make sense for them to evaluate alternatives. (It is like for a Christian to evaluate Islam.) I have friends who are absolutely satisfied with programming in machine codes and there exists no force including rational arguments that could convince them in using, say, OO techniques. This is because such arguments do not exist (OOP is definitely more restrictive).

    In proposing the concept-oriented model the motivating factor was (very strong) dissatisfaction with the current models both from theoretical and practical point of views. The idea then is to reduce the number of basic concepts to the minimum. Here I presented my own version. May be I am wrong, but I would like to hear some constructive criticism.

    Anyway, thanks that you looked at the site and for your response.

    alex

  6. #6
    Join Date
    Apr 2004
    Location
    Toronto, Canada
    Posts
    249
    Here is something in one of the FAQs suggested by the original poster and creator of the concept-oriented model (http://conceptoriented.com/faqs/codm-faq.html):

    The concept-oriented model is intrinsically multidimensional and hierarchical while the relational model in this sense has a flat structure.
    This statement shows that the author/creator has absolutely no idea about what relational database theory is.

    Why, then, should anybody bother to read the rest of his material? How can we be sure that he has understood "lattice theory" as he says and can make valid comparisons between his theory and relational databases?


    The concept-oriented data is globally connected, i.e., it is one complete model where parts cannot separated without influence the model semantics. The relational model is much less connected.
    What exactly does "globally connected" mean? If it is true that "parts cannot separated without influence the model semantics", is it an advantage or a disadvantage of the proposed model? I see that as a big handicap. Changes will be very difficult to make. Is that an advantage?

    Here's another:

    but the difference [between reference and primary key] from primary key is in the role of the identifier
    Well, a primary key is much more than an identifier. A non-surrogate primary key is a guarantee that there will be no duplicate rows in the database. So a concept-oriented database permits, nay, encourages, duplicates. Thanks, but no thanks!

    In the FAQ section 9.2, I tried to understand the similarities between OO and concept-oriented databases, and failed.

    All I can say is that after a significant amount of time going through the material, it seems that the author is attempting to create a seamless integration between the relational database world and Object Oriented world. In other words, he is trying to create an Object-relational model.

    I do not plan to spend any further time looking at this.

    Ravi

  7. #7
    Join Date
    Apr 2004
    Location
    Toronto, Canada
    Posts
    249
    Sorry for the critical nature of the last post. I do believe that it was objective, though not necessarily constructive.

    I am still not able to understand the basic concepts behind the model. What is "lattice theory"? And where can I read information about it?

    Ravi

  8. #8
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by rajiravi
    This statement shows that the author/creator has absolutely no idea about what relational database theory is.
    May be. But the problem is that we are discussing the method - not the authour :-) You take things too personally :-)

    Why, then, should anybody bother to read the rest of his material? How can we be sure that he has understood "lattice theory" as he says and can make valid comparisons between his theory and relational databases?
    You probably started reading from the rest of the paper because comparisons are at the end :-) So the question should be formulated why anybody should read the start of the paper :-) They are rather shallow or even somewhat incorrect-- read the description itself. This is my fault - I had to predict such a case. Writing politically correct comparisons is an art.

    What exactly does "globally connected" mean? If it is true that "parts cannot separated without influence the model semantics", is it an advantage or a disadvantage of the proposed model? I see that as a big handicap. Changes will be very difficult to make. Is that an advantage?
    Globally connected means that items do not exist in isolation without other items. Moreover, an item semantics is made of other items. So it does not make sense to consider an item (ok, a tuple :-) without other items. Such a model has a formal semantics and if we change one item then it may well influence the semantics of other items directly or indirectly and we know how to interpret this change. I consider such an approach as an advantage (may be I am wrong). But I hardly doubt that such type of very general arguments can convince anybody in advantages or disadvantages.

    Well, a primary key is much more than an identifier. A non-surrogate primary key is a guarantee that there will be no duplicate rows in the database. So a concept-oriented database permits, nay, encourages, duplicates. Thanks, but no thanks!
    You overestimate importance of duplication or misunderstood the mechanism of references and duplucation control. References are a different mechanism, which is more fundamental and important because it reflects an object existence: no reference - no object (sorry, tuple). As far as I remember I have written nothing about duplication control because it is a minor mechanism -- obviously we can always impose such a constraint. It is not clear what you do not like in this context.

    In the FAQ section 9.2, I tried to understand the similarities between OO and concept-oriented databases, and failed.
    Again, comparisons are very shallow. I am positive and productive - I never critisize, negate and try not to compare (partly because it is very dangerous).

    All I can say is that after a significant amount of time going through the material, it seems that the author is attempting to create a seamless integration between the relational database world and Object Oriented world. In other words, he is trying to create an Object-relational model.
    Yes. to some extent you are right here. But probably the most similar thing is Microsoft Longhorn WinFS model. Yet, it has some drawbacks in comparison with the concept-oriented model.

    I do not plan to spend any further time looking at this.
    You do not have to. You take it too emotially. You are not reviewer, you are not religious cleric, I am not a heretic and, probably most important, I am not against relational model. You do not have to read and evaluate this stuff. I did not want to insult you. Sorry for that. :-(

    alex

  9. #9
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by rajiravi
    Sorry for the critical nature of the last post. I do believe that it was objective, though not necessarily constructive.
    Ravi

    I have nothing against your style. The only notice is that I do not care if I am wrong or I am right. I am not paid for this work so consider it as an open source public project. If you demonstrate that something is wrong in the model then I will give it up. Particularly, I am not going to attract people to some project or to (commertically) advertise this model. I want to have some response and that is all. Yet, I am developing it as a set of technologies including the concept-oriented programming approach so in future there could be some result but generally I am satisfied when get some nice result (in my opinion).

    Quote Originally Posted by rajiravi
    I am still not able to understand the basic concepts behind the model. What is "lattice theory"? And where can I read information about it?
    Just like for set theory I hardly can explain here the basics of the lattice theory. It is described in many textbooks. The idea is that we can establish an order on elements. After that if this order satisfies some criteria (namely, transitive, reflective and distributive) then we get a lattice, which is considered a "good" structure. After that mathematicians build very different theories around this structure (and weaker structures), which are in fact lead to other braches of mathematics such boolean algebra, geometry etc.

    Fortunately, to understand the proposed apporach the mathematics is not needed. (Here the situation is the same as for relational model and set theory.) It is necessary to understand that any table (I am writing in relational terms) has several supertables (parents) -- this is a definition. It follows then that tables have also subtables (children). The only common parent for all tables is the top table (emtpy or null). The only common child is the bottom table (directly or indirectly includes all other tables). The fundamental distinguishing feature of this model is that we have to thing in terms of lattice, i.e., if you create a real model then provide for each table a set of its supertables (the paper describes how to choose them).

    At the sematnic level the model consists of items. And here again an item by itself is nothing. It has not fields, no properties - it has only its reference. The item semantics is defined by other items, namely, an item is a combination of its superitems taken from the superconcepts.

    You might want to look at somewhat shorter article in wikipedia: http://wikipedia.org/wiki/Concept-oriented_model

    Ask me if you have some further questions of any kind.

    alex

  10. #10
    Join Date
    Apr 2004
    Location
    Toronto, Canada
    Posts
    249
    But the problem is that we are discussing the method - not the authour
    That still does not invalidate my criticism of your effort. Or the fact that you have not refuted my point.

    I browsed through the beginning parts, and then jumped to the part that deals with comparisons between existing technology/knowledge and the proposed one.

    As somebody with a finite amount of time, it pays to optimize my efforts. If the comparisons are not clear or convincing enough, what use is it reading the rest? Your FAQ seems to be "globally connected", making it imposiible to understand something without understanding everything else. FAQs by their very nature ought to be granular. I just want the answer to the exact question I am looking for. If it leads to global dependencies, then there is a problem.

    That is one of the points I was making. Software, by its very nature, should be soft, that is, easily changeable. When a change to one part of the model necessarily affects every other part, then it is no longer "software". Such design also violates the "loose coupling" nature of well designed software.


    The absence of duplicate data is one of the key features of relational database theory, assuring integrity.
    To clarify, suppose I enter two customers with exactly the same information but make them have different customerId. Then, let us say that I add some addresses (home, office, etc.) to that customer by selecting one of the two customerIds. When you ask the database the question: How many addresses are there for my customer? Now what is the answer? Is it zero, or n? It depends! It depends on which customerId my query picked up.

    I hope that simple example shows you the importance of not having duplicates in the database, and the value of having primary keys vs object references.

    As far as I remember I have written nothing about duplication control because it is a minor mechanism -- obviously we can always impose such a constraint
    Well, that shows that important issues have been treated in a cavalier manner. Again, I believe that some work needs to be done in this respect.

    As I said, I believe my criticism was objective. If you disagree, please say so and explain why. Let us argue about facts and issues and not about whether criticism must always be positive and construcutive.

    Actually, severe criticism also has its merits. If something is not worthy of consideration by others, then pointing it out saves the time and effort of a large number of people.

    Ravi
    Last edited by rajiravi; 12-07-04 at 15:31.

  11. #11
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by rajiravi
    I browsed through the beginning parts, and then jumped to the part that deals with comparisons between existing technology/knowledge and the proposed one.
    The comparisons are supposed to be read after the idea of the approach is more or less clear. In addition, they are very concise and rather shallow as I mentioned. I tried to emphasize only very general distinctions but the accents may not be very accurate. May be I will remove this section at all...

    Quote Originally Posted by rajiravi
    As somebody with a finite amount of time, it pays to optimize my efforts. If the comparisons are not clear or convincing enough, what use is it reading the rest? Your FAQ seems to be "globally connected", making it impossible to understand something without understanding everything else. FAQs by their very nature ought to be granular. I just want the answer to the exact question I am looking for. If it leads to global dependencies, then there is a problem.
    I agree but unfortunately this is precisely what I am not able to fix, i.e., I am not able to remove this global connectivity and there are several serious reasons for that: (i) I am the author and therefore I simply do see what you see and, particularly, what is wrong, (ii) I am trying to describe a general paradigm (being it correct or wrong) and this general level requires the whole new layer of terms, underlying notions and principles, which need to be a part of the description, (iii) it is the initial stage so many aspects are not finished or are rather vague.

    Quote Originally Posted by rajiravi
    The absence of duplicate data is one of the key features of relational database theory, assuring integrity.
    To clarify, suppose I enter two customers with exactly the same information but make them have different customerId. Then, let us say that I add some addresses (home, office, etc.) to that customer by selecting one of the two customerIds. When you ask the database the question: How many addresses are there for my customer? Now what is the answer? Is it zero, or n? It depends! It depends on which customerId my query picked up.

    I hope that simple example shows you the importance of not having duplicates in the database, and the value of having primary keys vs object references.

    Well, that shows that important issues have been treated in a cavalier manner. Again, I believe that some work needs to be done in this respect.
    It seems that I understand what you mean but I do not think that there is problem here. Representation (and access) are primary issues in the concept-oriented model. What is an object? Is a reference? Is it its attribute values? Is it its remote reference, name, address in physical or virtual memory, position on disk or a proxy object? How objects exhibit themselves? In the concept-oriented model object (data item) and its representation are separated. We can define an object semantics as a combination of other objects. But how is it represented? It depends, because we have different mechanisms for that. To define how an object is represented we have to describe its reference structure. Reference is defined as a separable part of an object passed by value intended to substitute the object in other parts of the space. There are several important aspects in this definition. References are a separable part so we cannot treat them as a set of columns. In practice this may result in subtle but very serious problems because they have different life cycle, e.g., a reference can be create and well exist without the corresponding object (lazy creation), or they can be a sequence (stack) of reference consisting of several segments. Another aspect that references are passed by value and therefore they are objects because they do not have their own references and thus have no coordinates so they live out of any space. For each type of objects we can define the format of reference. The simplest way is to accept the system format (unknown). Yet we can define our own custom format, e.g., a reference might consist of two identifiers. An extreme case is where an object represents itself, i.e., its reference is equivalent to the object itself. In this case the object is said to be passed by value.

    Yet again, the problem of data semantics is separate from the problem of object representation, i.e., in order to describe and analyse what data means we do not need to know how data items are represented. The problem of objects and references you touch is in fact the corner stone of the concept-oriented paradigm but it is described in more details (where it is more important) within the concept-oriented programming where we have facilities for describing custom references just like any other object classes. (Unfortunately for certain reasons I cannot describe this mechanism here, sorry.)

    Returning to your example, if we need to avoid duplication of customers why not to impose such a constraint directly? In this case we will still have customer objects represented by reference but customers with identical properties will not be allowed. An alternative approach would be to declare a reference type equal to the object structure, i.e., to pass it by value. (But I do not think it is a good idea.) Although this issue has to be studied in deeper I think that the method of representation (reference format) and avoidance of duplication (constraint) are two different mechanisms, but since reference are unique by definition we are trying to solve the latter (duplication) by means of the former (references) what is not the best way. This is not an issue specific of my model only. If we ignore this for a while then the model still provides data syntax, semantics and other facilities required for any data model.

    When we are talking about duplication then we mean property values, which are not allowed to take the same values. But what are those property/column/attribute/variable values? In the concept-oriented model they are other items taken from higher level (closer to the root). So we need to impose constraints on possible combinations of these items. In fact, the constraints can be much more complex and involve items in other parts of the structure.

    As I said, I believe my criticism was objective. If you disagree, please say so and explain why. Let us argue about facts and issues and not about whether criticism must always be positive and construcutive.
    Your criticism helps me to view the problem differently. And believe me that I appreciate your time and efforts. The more you ask questions the better I understand what is wrong in the model. The model itself involves many issues (grouping and aggregation, relationships, semantics propagation to name a few) and each issue has several levels (abstract and formal, technological, implementation) so it is very difficult for (and probably almost impossible for other people) to grasp the whole picture. We need to narrow an issue to consider it constructively.

    Actually, severe criticism also has its merits. If something is not worthy of consideration by others, then pointing it out saves the time and effort of a large number of people.
    There exist different approaches here. An alternative approach is to simply ignore what is interpreted as a negative reaction. It is a weaker methods, which is less efficient but simultaniously less destructive (less damage). Your method is more efficient but the price of errors is higher. However, anybody is free to choose his own method so I do not complain :-) I have my own principle: the best criticism of any existing thing is to do it better.

    alex

  12. #12
    Join Date
    Mar 2001
    Location
    Lexington, KY
    Posts
    606
    My question is simple:
    Why can't you do what you are trying to do in the Relational Model?
    Thanks,

    Matt

  13. #13
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by MattR
    My question is simple:
    Why can't you do what you are trying to do in the Relational Model?
    The question is very general and hence simple and complex simultaneously so I will provide several answers.

    The first point is that there exist no things that cannot be done in the relational model, i.e., I really believe that the relational model is enough to implement any data structures (ok, almost any). But if we accept this point of view, then we have to conclude that we do not need the relational model itself because everything can be implemented by means of older technologies such as file systems. So your question can be reduced to the question why we are still not using file system to store the data? The answer is clear: because it is not natural, it is not convenient, it is not efficient. The same situation exists in almost any other new area. For example, everything (and even more) can be implemented in machine codes so the question is why do we need OO techniques if they only restrict our capabilities? And again an answer is clear: because it is more natural, it is more efficient, it is more compact and expressive. It is simply a new view of the world. Notice any new technology is more restrictive because it has stronger discipline and does not allow doing many things possible in older technologies. For example, you probably do not ask why relational database does not allow me to write into an arbitrary location in file although a file system engineer would say that such a technology is not acceptable since it is too restrictive. You also do not ask why I cannot write into any block on disk although some time ago it was absolutely natural. We gradually create layers of functionality over the existing layers. The problem is that the relational view of the world is not too high-level and we need something that describes the data better.

    More concretely, nobody asks for example why we need entity-relationship method, object-role modelling, EJBs, multidimensional databases and OLAP to name only a few technologies. Notice that all these technologies exist in parallel with relational model and over it in great extent relying on it. Approximately the same situation with the concept-oriented approach. It does not negate the relational model at all. It provides a new view on data, its syntax and semantics and such a view is much more simple, efficient and natural (IMO). With only a few basic mechanisms we can model very different existing approaches so the concept-orientation is going to be a unifying method, which does not deny existing technologies but providing a new view on them. Simplicity is the most difficult thing to reach in any system. It is almost trivial to add new component, new subsystem, new method for any new feature we need. But is almost impossible to remove them and to reduce the functionality to a smaller number of elements. So the main general advantage of the proposed model is its simplicity. Real advantages however are visible only in considering details.

    alex

  14. #14
    Join Date
    Mar 2001
    Location
    Lexington, KY
    Posts
    606
    Alex:

    Thanks for your reply.

    I agree that there is little data that cannot be represented in a set-theoretic fashion and therefore cannot be represented in the relational model. I also agree that storing data in a DBMS is the ‘right’ thing to do; those that understand computing history will know that the logical/physical abstraction is the ultimate reason for the creation of the DBMS in the first place. The ability to place a bit of data in a specific block is less important than ensuring that your data is logically correct; the DBMS will do the physical moving of bits around but your application need only concern itself with getting the data into and out of the DBMS.

    So the relational model is, amongst other things, a model which can be utilized by a Relational DBMS to improve and simplify data management. The RM is sort of useless without a RDBMS that implements it.

    And actually, many argue that MultiDimensional DBMS and OLAP are useless given a properly implemented RDBMS.

    In any case:
    In your opinion, where does the Relational Model show deficiencies?

    How does the “Concept-Oriented” approach (COA) provide a more “simple, efficient, and natural” approach to data than the Relational Model?

    How does the COA it ensure data correctness?

    How does the COA provide a simpler model than predicate logic and set theory?

    Your paper discusses “Relational tables” vis-ŕ-vis “concepts”; what is the difference between a table and a relation?
    Thanks,

    Matt

  15. #15
    Join Date
    Dec 2004
    Posts
    18
    Quote Originally Posted by MattR
    In your opinion, where does the Relational Model show deficiencies?
    I fill dissatisfaction with the relational model on many levels starting from physical when I am implementing a complex system (say, persistence layer) and ending with the formal things. Here are some more concrete remarks:

    - Assume we have 100 tables with 500 connections. So what? Where is the start and where is the end? Where is the top and where the bottom? Where are objects and where are relations? Where are abstractions and where are details? If am a good designer then I can somehow intuitively produce a good model but if not? I have too much (uncontrolled) freedom in the relational model with a weak accents on what is the most important in it.

    Quote Originally Posted by MattR
    How does the “Concept-Oriented” approach (COA) provide a more “simple, efficient, and natural” approach to data than the Relational Model?
    The most difficult thing as I mentioned in the previous post is removing unncessary things and reducing lost functionality to (deriving it from) a small number of existing elements. So here is how the concept-oriented model does it:

    - Syntax. Any table defined as combination of supertables gets a concrete position among all the tables, particularly, some level, i.e., it can be higher or lower positioned among other tables. This is a primary principle and absolutely necessary thing for any designer (absent in the relational model, at not formulated explicitly in such a form): define the level of each table. (This principle requires the absence of cycles in this structure and formally it is better to add the top and the bottom tables interpreted as the most abstract and the most specific/detailed elements, respectively.)

    - Semantics. Any item defined as a combination of its superitems taken by one from the supertables has a concrete position among other items. Such a thing as an item by itself does not exist (semantically). Each item is defined only by its connections with other items. If we ask what an order item is then we can say that it is a combination of delivery address item, a customer item and so on. It is very important that only a single superitem can be used in the combinations - no arrays or other tricks (we derive the collectional semantics from the basic semantics, see below).

    - Why such a syntax and semantics are natural? There can be no proof for that. This a fundamental assumption of this approach that the world is hierarchical, i.e., each item, say, order, is composed (logical AND) of other items, and dually (logical OR), consists of lower level items. Understanding this principle means understanding the whole paradigm in general. Each problem domain can be considered at the most abstract level as a single item, e.g., a state as one item, a company as one item, an organisation as one item. And any problem domain needs to have the lowest most specific level where we see its details, e.g., a company consists of its personnel, its products and so on. What is important is that this is a task of the database, not me, to manage this global multilevel and multidimensional structure.

    - Relations do not exist in the concept-oriented model. I think that dealing with relations is the corner stone of any modelling technique. So what are relations? For example, what is 'employed by' relation, is it an object or something else? In the concept-oriented model to be a relation is a relative role, i.e., we intentionally do not introduce relations as a primary means. The fundamental principle is that "an item is interpreted as a relation instance for its superitems but it is a normal object for its subitems, which are then relation instances connecting it with other items". We never can say if an item is a relation instance or an entity because it depends on the level we are currently considering. An order is a relation instance for the delivery address and customer items considered as entities. However, this very order is already an entity for its subitems such as order part.

    Quote Originally Posted by MattR
    How does the COA it ensure data correctness?
    We always know what our data means because we have a formal semantics for that. If we delete/add/update something then we know concretely what changes in the model. We can of course to impose constraints and control item's life cycle. It does not mean that we cannot do the same in the relational model but I mean that in COA it might be somewhat more natural and simpler.

    Quote Originally Posted by MattR
    How does the COA provide a simpler model than predicate logic and set theory?
    The set theory allows us to manipulate sets of records and in this sense it is a powerful mechanism that can be used for anything. But why and when do we need to apply these operations? This is already not controlled by the database model because it is another issue. So here the problem is not in the mechanism but in understanding what does our data mean. In COA we have a global network, which represents the whole problem domain in its integrity. Once we have such a gobal view, we can transform it to other model by means queries. For example, we could simplify the representation by removing some parts of this global model or we could aggregate some parameters and so on. In the relational model I have to do all these things manually because database knows not enough about the real meaning of data. Indeed, how many problems we have the joins? All forums are full of questions and systems are full of errors because of that. Although it is quite simple thing people are frequently confused and the model does not protect them from misuse. It is too powerful. It is tool for everything. The concept-oriented approach reduce necessary mechanisms to a smaller number of things. What we need in practice? To find an item, then to get its properties (go up in the concept-oriented model), then to get items it consists of (to go down in the model) and so on. That we go up and down, up and down. If we go up then we get abstract entities, if go down then we get specific entities.

    Quote Originally Posted by MattR
    Your paper discusses “Relational tables” vis-ŕ-vis “concepts”; what is the difference between a table and a relation?
    I described the treatment of relations above. There is only one type of basic relation: inclusion. This means that at syntactic level (schema) we include tables in other tables and at semantic level we include items in other items. That is all -- we do not need other mechanism to build the most interesting existing mechanisms. Higher level relations is the role or interpretation. It is relative, not fixed. The database does not distinguish relations. The principle is that any relation (instance) is simply a lower level table (record). The lower position an item has, the higher probability that we will interpret it is an instance of some relation. On the other hand, higher level items are normally interpreted as entities. In the relational model we do not have a hierarchy of relations.

    One more remark. The model does not have the mechanism of multi-valued attributes, i.e., we cannot define, say, a column, which stores a list of a person's addresses. Instead, this mechanism is derived from the basic semantics (simplicity). In the model, if an arrow points up then this is a single-valued (traditional) attribute. If it points down then this is a multiple-valued attribute. It is a very important modelling pattern that can be applied in any model including the relational one but COA has it as a primary principle. For example, if an Order may include multiple parts, then Parts is its subtable, i.e., has a lower level. (Much more complex cases are possible of course.)

    A star schema is a very simple particular case of the concept-oriented schema. Here the center is a common subtable for all the detail tables (which are supertables). Drawing such a schema as a real star is very misleading and confusing. The center must be below all the detail tables and all arrows must be directed upward from the center. The detail tables are not allowed to reference the center table and so on. We can then develop this structure further horizontally and vertically. So having this vertical and horizontal arrangement is extremely important for understanding the model. Try to model some real cases and you understand what is the difference.

    Sorry for too long answers.

    alex

Posting Permissions

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