Re: What does this NULL mean?

Alfredo Novoa schrieb:

>>Catalog and (user defined) database belong to different layers. They
>>have so big differences that cannot be viewed as one data model. Just
>>for example:

They can but only at some common low level of abstraction. For example, semiconductors and humans are one and the same at the level of atomic structure because you are able to manage them using the same theory and tools at this level. And you are not able to find any differences until you go higher. At the level of molecular structure they are already different and require different modeling and management methods. 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).

>>For example, delete a row from a table in your database catalog. What
>>happens then?

Right. But who said that it should happen? I, as a developer of this database, did not say that. 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. This is only one example that catalog does not strictly obey to the normal laws of user-defined data.

>>Currently there are no appropriate tools for modeling catalogs and other
>>types of meta information.

Yes, 20 or more years ago it was so. Nowdays any more or less complex system needs to use custom solutions for managing its catalog. In other words, currently almost any system includes its own hand-made catalog. The problem is that this is done without any theory, i.e., any developer invents his own way how to do it. I would say, that developers simply create their own database systems within another database system.

>>That is not a simple issue. It is one of the most complex open problems.

If the problem could be (correctly) formulated then it would be almost its solution. There exist only lists of inconsistencies, design goals, local problems, observations, partical solutions, patterns etc.

>>For example, what if I need to create a catalog of catalogs?

For example, assume you have several databases in your system and each has its own catalog. You want to transparently access and process information in the system as if it were one database. So you must create a kind of global catalog. Normally it is a hand made (sometimes ugly, sometime really nice) layer that is create without any theory proceeding directly from what has to be developed.

>>>We can manage the schema applying all the power of the RM on the
>>>catalog relvars.

>>That would be the same as applying, say OOP, to the problem of
>>manipulating data in general and schema in particular.

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. 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.

> If the RM is the best way to manage any kind of data, and schema data
> is data then the conclusion is obvious.

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.

-- 
http://conceptoriented.com