Tables - Physical??? Was: Use of the term "hierarchy" (and table/class)
Date: Sun, 28 Aug 2005 00:59:12 +0200
Message-ID: <4310efbb$0$11079$e4fe514c_at_news.xs4all.nl>
Alexandr Savinov wrote:
> mAsterdam schrieb:
>
>> You did not yet answer the question about the class/table mix-up. >> As this is an area whith many misunderstandings I would >> ask you to please reconsider answering it.
>
> The issue being discussed has nothing to do with the "class/table mix-up".
First: Why mix them up at all?
Second: Are you sure? I sense a sort of 'school' border here,
but I may very well be wrong.
>>> but the problem is that there is two fundamentally different ways to >>> represent a set: >>> >>> - as a physical collection/container, for example, where records are >>> placed in a table (considered a set). >> >> Strange example. I am aware that you below you state that >> "*any* element in the model has a physical part and a logical part >> simultaniously*", but /table/ is a concept (and I do have criticisms >> towards it, but I'll sidestep those for now) specifically introduced >> to *not* oblige everybody to consider the physical aspects of data.
>
> So what is the problem? Terminological?
Maybe. Terminological differences tend to cloud other issues, so let's try to unravel.
Current suspect terms: physical, logical, table, class. Definitions would be nice, of course, but not always possible.
Aside: I don't mind some unusual use of words (sometimes necessary to explain ideas), but I don't like to be caught off-guard.
> If so, then the term concept is
> taken from concept lattices and formal concept analysis (if explanation
> of term origin is an important issue at all).
What does this have to do with tables being a physical container?
> Or you do not aggree that placing a record into an Order table reflects
> the fact that it belongs to a set of orders just like setting a field
> recordType="orders" says that this record belongs to a class of Orders?
What do you mean with /setting a field recordType="orders/ ? What is the context?
>>> - as a logical collection/container, for example, where one record >>> (say, order part) is assigned a parent record (an order) considered a >>> set. >> >> ISTM these "fundamentally different ways to represent a set" are >> really different ways to look at the same things. You can look at >> and study the landscape architecture or the construction or the >> chemical structure of the composing materials of one bridge. >> When building a bridge, all of those aspects are considered at >> different times, by different people. When it is finished, it's >> all there at the same time in one thing. >> http://www.hsba.go.jp/bridge/e-akasi.htm
>
>
> Yes, if you like this way you can use it. But for data modeling I find
> it more convenient to view things as follows:
>
> any element belongs to one parent element physically, and to a number of
> other elments logically.
Ah yes, you snipped the part about single parents and heterarchies (please mark snips as such). What's physical about single-parentness? You really have a (to me) strange way of using words.
> I actually do not invent anything new when say that membership can be
> modeled (i) pby utting records into a table, or (ii) by setting its
> column value. Do not you agree?
I agree. When it's just that what you were saying then it might be a just terminology problem after all.
>>> If we recognize this as an important alternative the following >>> questions arise (mostly open and only a small subset): >>> - what is the semantics of our data in the case of two types of sets? >>> - how can we manipulate data from different types of containers? >>> - how can we transform sets between these two types so that the data >>> semantics does not change. For example, if I decided that I do not >>> want to keep records in a table as a set but instead want to keep >>> those records in a parent record as a set. >> >> You can do both (or at least appear to do both) at the same time.
>
> We always do both (if I correctly understand what do you mean by
> "both"). It is a trade off or a design alternative: either to represent
> different departments by different tables (and then place persons in
> them), or to represent them by records (and then assign them as column
> value for persons). Or, if you meant physical/logical membership then,
> as I mentioned, any element belongs to one parent element physically and
> to a number of elements logically, so we cannot aovid that.
This also sounds really strange to me (e.g. "and then place persons in them"). Maybe it's that terminology again, but I don't understand this.
>> How does this all affect the problem "when to represent a thing by >> normal record/row/object or by table/class"? (BTW still not clear what >> you mean here, maybe due to the table/class mix-up).
>
> Here is a couple of examples clarifying what we were talking about.
>
> Assume we have different types of figures (circle, square, etc.) Design
> alternatives:
> - create one class (in OOP) or one table (in data modeling) for each
> type of figure. After that each figure (instance) will belong to one
> class or exist in one table.
> - define one field/column with values of figure type.
This is clear. I'll repeat my original statement about it: It depends on our information needs: For the tables: what do we want to know about the circles, the squares. For classes: what does it need to be able to do. Which data are needed to accomplish their tasks? The answers to these questions will not leave alternatives wether to attribute properties to members or to sets.
> Assume we have different departments. Design alternatives:
> - create a table for each department and place employees in it as records,
> - define a column with department type as a value
The same works here: This question will be answered long before it could arise if we base our design on information needs: establish what we want to know about departments, department types and employees before putting stuff into tables.
[snip partitioning]
>>> An important distinguishing feature of this approach (a principle) is >>> that *any* element in the model has a physical part and a logical >>> part simultaniously and we can separate them (but can consider only >>> one part). In particular, a table and a record have some physical >>> representation (a physical reference, name or whatever permanent and >>> normally hidden identifier is used). However, any table and any >>> record have also a logical representation >> >> Assuming table in the SQL / cdt sense, a table must have >> some (or several) physical representation at any time, for sure. >> Its logical representation, though, is *not* its /also/ >> representation. It is its primary representation, its raison d'etre. >> Why do you want to change that?
>
> What? Sorry but I do not understand what you do not understand.
Could it be because I do? I didn't ask for clarification, but for motivation. Why do you insist on the physical aspects of tables ? Is it somehow essential for your argumentation? If so, how - maybe we can find more accepted terms. If not, please drop it, and accept: tables are logical things (however flawed), aimed at hiding physical aspects.
>> Or are you using the word 'table' to mean something else? >> >>> which is a position among other elements. >> >> The position of rows in a table is abstracted away. >> /There is no such thing/ is the implied common illusion at >> the logical level. >> >>> Using the logical representation elements can be accessed via other >>> elements. In contrast to physical position, the logical position may >>> change (reflecting the changes in our model). >>> elements. Using the logical representation elements can be accessed >>> via other elements. In contrast to physical position, the logical >>> position may change (reflecting the changes in our model).
>
> Please, define concretely what do you mean by "physical" (position) and
> "logical" position. In the concept-oriented model these are formally
> defined terms. I suppose that you use these terms mostly informally.
Ah the 'formal' trenches. If this is so, the concept-oriented model
people should have done some reading before they started
wildly redefining terms in good use.
The sense of 'school' borders strengthens.
>> The physical location of bytes may change without affecting the >> data represented by them (in any DBMS, not just RDBMS). >> >>> Here is another analogy. We can position our elements by placing them >>> into their physical containers like tables >> >> What is physical about tables?
>
> I do not know. It is too general question and everything depends on
> context. In COM table (concept) like any other element has a physical
> parent and representation in it (reference, identity).
Ok. Please say COM table if you mean COM table. In an earlier post I summarized the usage in cdt:
>> [Table/Row/Column] (SQL-DBMS) >> Table: A collection of columns (the table header) and rows (the body). >> Row: A collection of values, conforming to the table header columns. >> >> One table may contain data about one entity, >> about several entities, about one or several >> relationships or any combination. >> A column can be seen as the attribute of the >> entity/one of the entities/relationships >> about which the table is concerned. >> Where did you get the idea that tables are physical containers?
>
> We define so in the model so it is an assumption. But actually what are
> tables if not a physical container for records? Probably it is term
> conflict but I think I defined concretely what I mean by physical and
> logical parts of the model: all tables physically belong to one root of
> the model, and records belong to their records, while logical structure
> is defined column values. All other (with bridges etc.) associations are
> not desirable.
Table is not the right word for this, then (at least in databasia).
>>> (or database, or object container or whatever parent element that >>> cannot be then changed easily and is responsible for references and >>> physical access). And we can position our elments logically by >>> specifying their coordinates w.r.t. to other elments. This position >>> may change and reflects the model semantics. It is precisely what we >>> do when specify object field values or set this object as a value for >>> some other objects. >>> >>>>> - hierarchy between physical elements of higher level (say, tables) >>>>> impose constraints on its child elements (say, records) >>>> >>>> >>>> >>>> Lower level constraints may also propagate to >>>> constraints on higher levels. >>> >>> >>> >>> How? Any example? >> >> The chemical bonding forces of materials put limits on the >> size of constructions. To stay within the databases realm: >> a filesize limits the number of rows of tables.
>
> Please, in terms of data modeling with the minimal set of main
> constructs. In this anything can be confirmed or refuted.
The redefiniton damage is worse in that regard.
Constructs high to low:
1. tables (with a property number of rows) 2. rows (with a property size in bytes) 3. files (with a property size in bytes)
Assume one table per file: the number of rows has an upper bound due to (is constrained by) the filesize. More tables and files complicate the formula, but not the principle.
> It is interesting but very time consuming.
Same here.
> I think I tried to be very
> concrete. Namely, the only I said is that
>
> - an attribute value is a set for all objects that have it
>
> - in the concept-oriented data model any element is (i) a collection of
> other elements, and (ii) a combination of other elements. Or,
> equivalently, any element has one physical parent set, and a number of
> logical parent sets.
>
> This can be shown to be useful for modeling hierarchies discussed in
> this thread because the model defined in this way is intrinsically
> hierarchical.
>
> --
> http://conceptoriented.com
I can understand that you would like to have comments on 'the concept-oriented data model' - but I asked no question whatsoever about it (yet). I replied to the OP (Use of the term "hierarchy") with my own remarks, and I questioned your unfamiliar use of familiar terms.
BTW I also said something about heterarchies, but you chose to ignore that. Received on Sun Aug 28 2005 - 00:59:12 CEST