Re: dbdebunk 'Quote of Week' comment




"Alexandr Savinov" <spam@xxxxxxxxxxxxxxxxxxx> wrote in message
news:4312e49d$1@xxxxxxxxxxxxxx


> You have only one serious flaw in your reasoning:
>
> we need an element in our model that will denote an end-user

> In this sense I find your approach to defining meaningfulness rather
> useful but unfortunately I do not know a formal theory that could deal
> with end-users as an integral part of the model. We can dras boxes,
> arrows, circles but it will not be a formal model.

But we have the three level architecture of DBMSs.
About formal models, I don't know either but I found this
http://people.cs.vt.edu/~jaburge/abstract.html .

> In general I think that we lack information on "identtity modeling"
> althoug it is as important as data modeling itself. Identity modeling is
> a separate topic, a dual part for data modeling. In other words, we can
> model identity ignoring object properties. And it may well be rather
> complex model. It will involve entities without properties - only
> identities. The following properties of identity make this task rather
> difficult:
>
> - Identity is distributed among many entites. It can be hierarchical.
> For example, an element of categorization might have several segments
> each specifying relative position. A fully qualified identifier then is
> composed of several identifiers (for example, several primary keys taken
> from different tables - having one primary key is not enough).
>
> - Identity cannot be considered without its scope. For example, a
> physical address is retricted by the scope of one computer, a primary
> key might be restricted by one database etc.
>
> - Logical/physical is a relative characterization rather than absolute.
> Memory handle is really physical for an application program that uses
> it, but it is logical for operating system w.r.t. to absolute offsets
> in physical memory (offset may change while memory handle does not
> change). In this sense all those disputes about lgoical/physical are
> meaningless without specifying the context. Primary key may well be
> viewed as a physical identifier from the point of view of some higher
> level identification mechanism, say, global id. This means that global
> id is permanent while primary key it substitues may change.
>
> - Any identifier is based on some environemnt that provides a coordinate
> system that it uses to produce its own identifiers. In other words, any
> new identification system is based on some lower level identification
> system (environemtn or context) with its scope and structure.

Thank you for this list.



.



Relevant Pages

  • Re: How to serialize/restore a large data structure?
    ... I have a large hash table, whose keys are words, and the values are dicts, that contain integer pairs. ... I am creating this structure in memory, taking care to reuse objects as much as possible, with the result occupying ~ 1.3GB of memory. ... Is there some reason for the *id* to be the PRIMARY KEY and not the ...
    (comp.lang.tcl)
  • Re: joins
    ... Please read a book on data modeling and the ISO-11179 Standards. ... Let's do a clean up on schema first. ... (prod_type INTEGER NOT NULL PRIMARY KEY, ...
    (microsoft.public.sqlserver.programming)
  • Re: dbdebunk Quote of Week comment
    ... primary key is a pointer. ... In this sense the question about the meaning of pointers/keys relates to data modeling in general rather than to the RM. ... Possibly you mean an illusion of direct access like in OOP where we manipulate object like if they were directly accessible. ... meaningless without specifying the context. ...
    (comp.databases.theory)
  • Re: Updating the SQL key value
    ... field "order" as the primary key. ... 'normal' autonumbering Primary Key. ... I never heard of a database that changes the values of other rows if you ... tblorder in memory, but that is independent from the database, it is PHP's ...
    (comp.lang.php)
  • Re: How to serialize/restore a large data structure?
    ... I have a large hash table, whose keys are words, and the values are ... I am creating this structure in memory, ... $database onecolumn "SELECT id FROM words WHERE word='$word'" ... Is there some reason for the *id* to be the PRIMARY KEY and not the ...
    (comp.lang.tcl)