Re: What does this NULL mean?
Date: Fri, 16 Dec 2005 14:43:12 +0100
Message-ID: <43a2c492_at_news.fhg.de>
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:
- [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.
- [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.comReceived on Fri Dec 16 2005 - 14:43:12 CET