Re: What does this NULL mean?

Alfredo Novoa schrieb: 
When we
are talking about catalogs and (conventional) databases then the
situation is the same. In principle, they can be viewed as one database.
However, they are at different levels so it is more appropriate to apply
different representation and manipulation methods for them (which do not
exist).



A clear non sequitur. Like Paul said, there is an evident leverage if
the schema can be managed like any other database.


A relvar attribute is deleted in case of no integrity constraints
violation.


Right. But who said that it should happen?


The catalog's designer. 
I, as a developer of this
database, did not say that.



As a developer you are a catalog's user, and users don't dictate the
rules.

In many cases I need to develop my own environemnt with my own rules for the purposes of the problem being solved. It is a change of paradigm which takes place in very different areas of computer science.

It happens because some anonimous developer
of this concrete DBMS implemented it so. I cannot influence this
bechaviou because it is hard coded. It is not part of my model. It is
not part of my database. It is part of catalog hard-coded bahvior.



Just the same as your database for your users.


This
is only one example that catalog does not strictly obey to the normal
laws of user-defined data.



I see a very strict obedience, only the roles change.


Yes. And apply any concrete data model including RM to the problem of
global data management (catalogs, meta-info etc.) is also not very
appropriate.



Why not?

What is the alternative?

The Hierarchical Model?

Catalogs, meta-info, etc are data like any other. They don't have
anything in special.


You simply create a new database using tools provided by
another database. For example, I could create a complex multi-level
system using Oracle. But the main problem is that Oracle database is
unaware what kind of system it manages. It thinks that it is relational
model while in reality it is something different. Instead, we need to
have a theory or a model that would allow us to create such multi-level
data models.



You are missing the point. You don't have to create anything. The
catalog design is a part of the DBMS implementation, and the developers
don't have to design their own catalogs.

You are absolutely right from the currently dominating paradigm. But there is also an emerging direction (not only in data modeling). It has different formulations in different areas. For example, in programming it is being developed within language-oriented programming and reflective programming. The main assumption is that for efficient programming we need to develop our own custom languages which reflect our problem domain (language-oriented programming). Or, we need to be able to access and manipulate the existing programming language mechanisms (reflective programming). The same idea exists in data modeling (although much weaker because data modeling is much more conservative and orthodoxal). The main idea in this case would be that data modeling (for complex systems) is in great extent modeling meta-info. We cannot delegate this work to DBMS developers because each concrete system, each concrete problem domain requires its own environemnt with its own laws and bahviour. It is a shift of paradigm. Modeling entities is the simplest part. More complex is modeling multiple layers (within one integrated model) where one layer establishes laws for other layers.

What you could do is to design a better DBMS than Oracle.

No. I do not want to develop yet another database. An internal database is part of my system. For each concrete problem domain I need to develop its own database. That is the point. Just like for each concrete problem domain I need to describe my own programming language rather than do everything in C++. Actually, it happens already in practice. People are repeatedly develop their own databases and languages but they do not have special tools and theories for that.

Yes, of course we can apply RM to any data. But as I already mentioned
above, this model will be unaware that the data it represents has much
more complex meaning and hence it will not be able to help us in
managing this data. In this case we need to implement most of complex
issues ourselves. That is not the best way and hence the conclusion
could be that we need something new.



I don't see any sense here. Any DBMS is completely unaware of the
meaning of the data. DBMS only can check consistency and to perform
symbolic manipulation.

That is a classical definition. In programming an analogue is that a programming language is a sequence of operations. But now assume that I want to reflect the properties of my problem domain in my database or in my programming language. Then this hand-made database and programming language is an integral part of the whole system I have developed. For example, in many cases we need to develop a new or modified query language and this is precisely what I am talking about. It is a part of a classical database and we need to intervine this level.

Actually, we discuss the following issue:

1. [your point of view]. It is enough to have one universal mechanism (data model, programming language, query language etc.) for modeling most of problem domains and solving most of tasks.

2. [my point of view]. It is better to have an approach for creating custom mechanisms for each concrete problem domain (reflective systems, meta-modeling, language-oriented programming, aspect-oriented programming etc.)

--
http://conceptoriented.com
.

Relevant Pages

  • Re: More on lists and sets
    ... programming language = the language the client uses to manipulate data. ... provide new data for the database), and the format for the data ... So direct embedding of queries in the programming language, ... you're using Dawn's definiton of normalization. ...
    (comp.databases.theory)
  • Re: C#3 changes
    ... No doubt the coming MSSQLServer uses it in stored procedures. ... The goal seems to me that you use a single language for writing procs ... The database itself should provide all the type information. ... http://mindprod.com Again taking new Java programming contracts. ...
    (comp.lang.java.advocacy)
  • Re: Encapsulation vs separation of concerns
    ... One really doesn't want to rewrite entire applications when the ... > Did you really rewrite the application in the same language four times? ... > changes in programming languages are many. ... > programming languages have changed about every 5th year, while database ...
    (comp.object)
  • Re: Minsky still posting
    ... > I think this is another case of falling for the hype of Prolog rather ... Prolog is just another little programming ... > language, It isn't magic, it isn't intelligent, it is in fact rather ... If I want a database, I think of it as a thing with certain ...
    (comp.lang.prolog)
  • Re: Theres got to be a better way
    ... I work with annoyingly complex database tables whose structure ... Programming is all about reinventing the wheel. ... But we're still writing code must like we did 40 years ago. ...
    (comp.lang.php)