This is just a reminder of the blog I started this month. You can be notified of new postings using an atom feed, but I thought I'd make another announcement here. There are now three entries in the series starting with "Is Codd Dead?".
Since I don't like discussing by means of blog comments I'll post my reaction here. As you probably know I'm in the pro-RM and anti-dbdebunk camp, so although I'm probably mostly crticial, it is certainly not meant as an attack.
> [...] If we were to implement a data model what would we have? Let's > take a look at a recent definition of data model from Date.
> A data model is an abstract, self-contained, logical definition of > the objects, operators, and so forth, that together constitute the > abstract machine with which users interact. The objects allow us to > model the structure of data. The operators allow us to model its > behavior. (C. J. Date, An Introduction to Database Systems, Addison > Wesley, 8e, 2003, p 15-16)
> I conclude from this that the implementation of a data model is a > programming language, whether a general purpose programming language > or not.
While I don't think that what you say here is strictly speaking incorrect, I do believe that it is misleading. In programming languages one is often rather more concrete about how the data is stored and how the operators do their work, in fact that is often the whole purpose fo the programming language, whereas Date stresses rightly here that it has to be an *abstract* definition. Another important aspect is the extent to which the definition is *logical*, which implies that the definition of constraints and manipulations should be more declarative, whereas in programming languages this is often more done in an operational way. Of course there are no black and whites here because these things vary in different programming languages, but simply equating the concept of "data model" as Date and Codd define it and "programming language" is cutting a few corners too many.
> My beef with the RM is related both to normalization theory as taught > in colleges and universities, discussed in the Is Codd Dead? blog > and to the way the RM, or parts thereof, are used in the practice of > software development and maintenance today. It shapes the thinking of > software developers in ways that are often not the most effective.
I have really no idea where this comes from. When I teach normalization I do that in the context of the relational model. It is part of the theory that you should know if you have to deal with an RDBMS. Obviously, if you have to deal with another type of DBMS you should not apply it, or at least not in exactly the same way. Are you now telling me that most computer science students in the United States massively fail to get this when they take their database courses? And those people are allowed to build critical information systems? :-)
> And, by the way, if you are thinking that the RM need not be obvious > in a developer's programming language but could be hidden behind the > scenes, then my work is done. That would mean that no computer > language would need to use the Information Principle, and neither you > nor I would need to use the RM as a data model. We can use any > programming language that does not represent itself as an > implementation of the RM to employ an alternative data model.
Again, I have no idea what you are talking about here. Who on earth has ever claimed that the RM would be the best data model for programming languages? The claim of the RM is that it is a good data model for a DBMS, and even that claim is usually qualified.
-- Jan Hidders
PS. Apologies in advance if I don't reply this week, I'll be mostly off-line then.
> Since I don't like discussing by means of blog comments I'll post my > reaction here.
I have never been a blog-comment person either, but since there are some students reading my blog, it is good for them to see comments with it too, so I'm encouraging that. I'm happy to get feedback from you in this forum too, however.
> > [...] If we were to implement a data model what would we have? Let's > > take a look at a recent definition of data model from Date.
> > A data model is an abstract, self-contained, logical definition of > > the objects, operators, and so forth, that together constitute the > > abstract machine with which users interact. The objects allow us to > > model the structure of data. The operators allow us to model its > > behavior. (C. J. Date, An Introduction to Database Systems, Addison > > Wesley, 8e, 2003, p 15-16)
> > I conclude from this that the implementation of a data model is a > > programming language, whether a general purpose programming language > > or not.
> While I don't think that what you say here is strictly speaking > incorrect, I do believe that it is misleading. In programming languages > one is often rather more concrete about how the data is stored and how > the operators do their work, in fact that is often the whole purpose fo > the programming language, whereas Date stresses rightly here that it has > to be an *abstract* definition.
I definitely think that a data model is abstract. That is why I said that an implementation of the data model (for our purposes of developing software) is a programming language. That is why when countering SQL, claiming it not to be a good implementation of the RM, Date introduces Tutorial-D, another language. I am stating that a data model is the abstraction of a programming language (or sublanguage).
> Another important aspect is the extent > to which the definition is *logical*, which implies that the definition > of constraints and manipulations should be more declarative,
I suppose that is the intent, but I see nothing in Codd's definition of a data model that would lead me to believe that a data model must be implemented in a declarative language.
> whereas in > programming languages this is often more done in an operational way.
OK-ish.
> Of > course there are no black and whites here because these things vary in > different programming languages, but simply equating the concept of > "data model" as Date and Codd define it and "programming language" is > cutting a few corners too many.
I did not intend to equate them but to claim that a data model is implemented via a programming language. That language could be declarative, functional, set-based, procedural, OO, ...
> > My beef with the RM is related both to normalization theory as taught > > in colleges and universities, discussed in the Is Codd Dead? blog > > and to the way the RM, or parts thereof, are used in the practice of > > software development and maintenance today. It shapes the thinking of > > software developers in ways that are often not the most effective.
> I have really no idea where this comes from. When I teach normalization > I do that in the context of the relational model. It is part of the > theory that you should know if you have to deal with an RDBMS. > Obviously, if you have to deal with another type of DBMS you should not > apply it,
and that is obvious to your students? If so, three cheers.
> or at least not in exactly the same way. Are you now telling > me that most computer science students in the United States massively > fail to get this when they take their database courses?
I cannot speak for most students, but when looking at text books (rather than listening to professors) and to employees entering a space where they need not employ the RM, it is my guess that the bulk of the college grads in CS in the US think that the RM is the way one should model data, period.
> And those people > are allowed to build critical information systems? :-)
Not until we have beat the theory out of them and introduced them to the real world :-) [P.S. Don't quote me on that -- this is a private conversation, right?]
> > And, by the way, if you are thinking that the RM need not be obvious > > in a developer's programming language but could be hidden behind the > > scenes, then my work is done. That would mean that no computer > > language would need to use the Information Principle, and neither you > > nor I would need to use the RM as a data model. We can use any > > programming language that does not represent itself as an > > implementation of the RM to employ an alternative data model.
> Again, I have no idea what you are talking about here. Who on earth has > ever claimed that the RM would be the best data model for programming > languages?
I didn't intend to suggest that. Whenever I mention that I want to work with such data structures as ordered lists with associated insert and delete functions, I am informed that I am talking about representation and that what I want is possible with the data modeled via the RM and then handled with another product in front of that. I'm showing that the RM is all about representation. As soon as you decide to use another representation, you are moving away from the RM.
> The claim of the RM is that it is a good data model for a > DBMS,
Yes, that is the claim. I'm claiming in this blog that it isn't necessary, a point that no one contests (I suspect) since we know we can build software systems without it. I don't think many will contest the claim that is it not sufficient either. But (I think) I'm going to claim that there other data models that are sufficient for developing software and then ask if it is important enough to use the RM that we want to suffer the mismatch with whatever other data models we use.
> and even that claim is usually qualified.
> -- Jan Hidders
> PS. Apologies in advance if I don't reply this week, I'll be mostly > off-line then.
Jan Hidders wrote: > Since I don't like discussing by means of blog comments I'll post my > reaction here. As you probably know I'm in the pro-RM and anti-dbdebunk > camp, so although I'm probably mostly crticial, it is certainly not > meant as an attack.
>>[...] If we were to implement a data model what would we have? Let's >>take a look at a recent definition of data model from Date.
>>A data model is an abstract, self-contained, logical definition of >>the objects, operators, and so forth, that together constitute the >>abstract machine with which users interact. The objects allow us to >>model the structure of data. The operators allow us to model its >>behavior. (C. J. Date, An Introduction to Database Systems, Addison >>Wesley, 8e, 2003, p 15-16)
>>I conclude from this that the implementation of a data model is a >>programming language, whether a general purpose programming language >>or not.
> While I don't think that what you say here is strictly speaking > incorrect, I do believe that it is misleading. In programming languages > one is often rather more concrete about how the data is stored and how > the operators do their work, in fact that is often the whole purpose fo > the programming language, whereas Date stresses rightly here that it has > to be an *abstract* definition. Another important aspect is the extent > to which the definition is *logical*, which implies that the definition > of constraints and manipulations should be more declarative, whereas in > programming languages this is often more done in an operational way. Of > course there are no black and whites here because these things vary in > different programming languages, but simply equating the concept of > "data model" as Date and Codd define it and "programming language" is > cutting a few corners too many.
>>My beef with the RM is related both to normalization theory as taught >>in colleges and universities, discussed in the Is Codd Dead? blog >>and to the way the RM, or parts thereof, are used in the practice of >>software development and maintenance today. It shapes the thinking of >>software developers in ways that are often not the most effective.
> I have really no idea where this comes from. When I teach normalization > I do that in the context of the relational model. It is part of the > theory that you should know if you have to deal with an RDBMS. > Obviously, if you have to deal with another type of DBMS you should not > apply it, or at least not in exactly the same way.
Anecdote time:
When I learned about normalisation in 1984 in a post-doc IT curriculum, we were to some extend free to do our own explorations. One nice, enlightening excercise was this one:
From a normalised data model (based on an earlier design case, so "real" - or at least our own - analysis, complete with interviews, prioritisation, integration etcetera - remember James Martins integration bubble charts?) we made, in several workgroups, different implementation plans: one for a purely batch processing (only sequential files) environment, one for ISAM/online, (we skipped RDBMS implementation as being both being trivial and not yet feasible for performance reasons at that time :-), and eventually one hybrid plan.
Some crucial parts of those plans were actually coded and tested later in the course.
One thing I learned was that when you get your data right, you can pretty much build a working system with any tools available. A DBMS just makes the job easier. Database: Find the base for your design in data.
In short: To me the connection between RM and normalisation is mainly historical.
> Are you now telling > me that most computer science students in the United States massively > fail to get this when they take their database courses? And those people > are allowed to build critical information systems? :-)
>>And, by the way, if you are thinking that the RM need not be obvious >>in a developer's programming language but could be hidden behind the >>scenes, then my work is done. That would mean that no computer >>language would need to use the Information Principle, and neither you >>nor I would need to use the RM as a data model. We can use any >>programming language that does not represent itself as an >>implementation of the RM to employ an alternative data model.
> Again, I have no idea what you are talking about here. Who on earth has > ever claimed that the RM would be the best data model for programming > languages? The claim of the RM is that it is a good data model for a > DBMS, and even that claim is usually qualified.
> -- Jan Hidders
> PS. Apologies in advance if I don't reply this week, I'll be mostly > off-line then.
>>>[...] If we were to implement a data model what would we have? Let's >>>take a look at a recent definition of data model from Date.
>>>A data model is an abstract, self-contained, logical definition of >>>the objects, operators, and so forth, that together constitute the >>>abstract machine with which users interact. The objects allow us to >>>model the structure of data. The operators allow us to model its >>>behavior. (C. J. Date, An Introduction to Database Systems, Addison >>>Wesley, 8e, 2003, p 15-16)
>>>I conclude from this that the implementation of a data model is a >>>programming language, whether a general purpose programming language >>>or not.
>>While I don't think that what you say here is strictly speaking >>incorrect, I do believe that it is misleading. In programming languages >>one is often rather more concrete about how the data is stored and how >>the operators do their work, in fact that is often the whole purpose fo >>the programming language, whereas Date stresses rightly here that it has >>to be an *abstract* definition.
> I definitely think that a data model is abstract. That is why I said > that an implementation of the data model (for our purposes of > developing software) is a programming language. That is why when > countering SQL, claiming it not to be a good implementation of the RM, > Date introduces Tutorial-D, another language. I am stating that a data > model is the abstraction of a programming language (or sublanguage).
That's not how I would formulate it. SQL is not an implementation of a data model, it *is* a data model (as defined above by Chris Date). SQL and the relational model are at the same abstraction level, so it doesn't make much sense to me to say that one would be an implementation of the other. In the same way I don't see what the data model of, say, Java would be, and what it would abstract from i.e. what it leaves out. If I take the definitions of the objects, operators and everything that makes up the abstract machine that the user / programmer of Java interacts with, (not to be confuseed with the JVM) that *is* the definition of Java. To me it seems absurd to say that a data model is an abstraction of a programming language.
>>>My beef with the RM is related both to normalization theory as taught >>>in colleges and universities, discussed in the Is Codd Dead? blog >>>and to the way the RM, or parts thereof, are used in the practice of >>>software development and maintenance today. It shapes the thinking of >>>software developers in ways that are often not the most effective.
>>I have really no idea where this comes from. When I teach normalization >>I do that in the context of the relational model. It is part of the >>theory that you should know if you have to deal with an RDBMS. >>Obviously, if you have to deal with another type of DBMS you should not >>apply it,
> and that is obvious to your students? If so, three cheers.
Might have to do with the fact that we also teach some stuff on other types of databases, object-oriented and object-relational in the past, now mostly XML databases. And, of course, Belgian students are incredibly smart. :-)
> [...] Whenever I mention that I want to > work with such data structures as ordered lists with associated insert > and delete functions, I am informed that I am talking about > representation and that what I want is possible with the data modeled > via the RM and then handled with another product in front of that. I'm > showing that the RM is all about representation. As soon as you decide > to use another representation, you are moving away from the RM.
I don't know who told you that lists are somehow only representation while sets are not, but that is nonsense. The reason to avoid lists is far more mundane and practical; it would make the DBMS more complex and make tasks such as query optimization, concurrency control and integrity maintenance harder. It would also make the theory more complex, which in the long term usually also translates into practical problems.
>>The claim of the RM is that it is a good data model for a >>DBMS,
> Yes, that is the claim. I'm claiming in this blog that it isn't > necessary, a point that no one contests (I suspect) since we know we > can build software systems without it.
Sure, bathing regularly is also not necessary. It's still a good idea though. :-)
> >>>[...] If we were to implement a data model what would we have? Let's > >>>take a look at a recent definition of data model from Date.
> >>>A data model is an abstract, self-contained, logical definition of > >>>the objects, operators, and so forth, that together constitute the > >>>abstract machine with which users interact. The objects allow us to > >>>model the structure of data. The operators allow us to model its > >>>behavior. (C. J. Date, An Introduction to Database Systems, Addison > >>>Wesley, 8e, 2003, p 15-16)
> >>>I conclude from this that the implementation of a data model is a > >>>programming language, whether a general purpose programming language > >>>or not.
> >>While I don't think that what you say here is strictly speaking > >>incorrect, I do believe that it is misleading. In programming languages > >>one is often rather more concrete about how the data is stored and how > >>the operators do their work, in fact that is often the whole purpose fo > >>the programming language, whereas Date stresses rightly here that it has > >>to be an *abstract* definition.
> > I definitely think that a data model is abstract. That is why I said > > that an implementation of the data model (for our purposes of > > developing software) is a programming language. That is why when > > countering SQL, claiming it not to be a good implementation of the RM, > > Date introduces Tutorial-D, another language. I am stating that a data > > model is the abstraction of a programming language (or sublanguage).
> That's not how I would formulate it. SQL is not an implementation of a > data model, it *is* a data model (as defined above by Chris Date).
Both SQL and QUEL were implementations based (however loosely) on the Relational Model. So, a single data model can have multiple implementations. Similarly an oject data model can be implemented by both Java and C++ in different ways, with varying degress of purity.
> SQL > and the relational model are at the same abstraction level,
An instance of the SQL programming language (e.g. SQL as implemented in Oracle 8i) is an implementation, an actual language that I can use to perform a query against a database.
> so it > doesn't make much sense to me to say that one would be an implementation > of the other. In the same way I don't see what the data model of, say, > Java would be, and what it would abstract from i.e. what it leaves out. > If I take the definitions of the objects, operators and everything that > makes up the abstract machine that the user / programmer of Java > interacts with, (not to be confuseed with the JVM) that *is* the > definition of Java. To me it seems absurd to say that a data model is an > abstraction of a programming language.
Multiple programming languages, each with a different syntax, can each implement the same data model, wouldn't you say? Maybe "implement" is too strong. SQL, QUEL, and Tutorial-D can all be based on the RM. The RM is the abstraction and each of these others has a different syntax.
> >>>My beef with the RM is related both to normalization theory as taught > >>>in colleges and universities, discussed in the Is Codd Dead? blog > >>>and to the way the RM, or parts thereof, are used in the practice of > >>>software development and maintenance today. It shapes the thinking of > >>>software developers in ways that are often not the most effective.
> >>I have really no idea where this comes from. When I teach normalization > >>I do that in the context of the relational model. It is part of the > >>theory that you should know if you have to deal with an RDBMS. > >>Obviously, if you have to deal with another type of DBMS you should not > >>apply it,
> > and that is obvious to your students? If so, three cheers.
> Might have to do with the fact that we also teach some stuff on other > types of databases, object-oriented and object-relational in the past, > now mostly XML databases. And, of course, Belgian students are > incredibly smart. :-)
I knew that. They are close to those Dutch folks.
> > [...] Whenever I mention that I want to > > work with such data structures as ordered lists with associated insert > > and delete functions, I am informed that I am talking about > > representation and that what I want is possible with the data modeled > > via the RM and then handled with another product in front of that. I'm > > showing that the RM is all about representation. As soon as you decide > > to use another representation, you are moving away from the RM.
> I don't know who told you that lists are somehow only representation > while sets are not, but that is nonsense.
Agreed.
> The reason to avoid lists is > far more mundane and practical; it would make the DBMS more complex and > make tasks such as query optimization, concurrency control and integrity > maintenance harder.
Harder for whom?
> It would also make the theory more complex, which in > the long term usually also translates into practical problems.
The language I speak also has a very complicated theory behind it, if any at all (IIRC Chomsky or others have worked on a mathematical theory behind languages). But it still might make sense for me to speak it.
> >>The claim of the RM is that it is a good data model for a > >>DBMS,
> > Yes, that is the claim. I'm claiming in this blog that it isn't > > necessary, a point that no one contests (I suspect) since we know we > > can build software systems without it.
> Sure, bathing regularly is also not necessary. It's still a good idea > though. :-)
Yup. So, that is what we are left with -- decisions on whether it is obvious to bathe regularly or not, or maybe it is more like curling your hair with a curling iron. It might make complete sense to a whole group of women, but it has never made sense to me and I get ready much faster ignoring it altogether. cheers! --dawn
> > >>>[...] If we were to implement a data model what would we have? Let's > > >>>take a look at a recent definition of data model from Date.
> > >>>A data model is an abstract, self-contained, logical definition of > > >>>the objects, operators, and so forth, that together constitute the > > >>>abstract machine with which users interact. The objects allow us to > > >>>model the structure of data. The operators allow us to model its > > >>>behavior. (C. J. Date, An Introduction to Database Systems, Addison > > >>>Wesley, 8e, 2003, p 15-16)
> > >>>I conclude from this that the implementation of a data model is a > > >>>programming language, whether a general purpose programming language > > >>>or not.
> > >>While I don't think that what you say here is strictly speaking > > >>incorrect, I do believe that it is misleading. In programming languages > > >>one is often rather more concrete about how the data is stored and how > > >>the operators do their work, in fact that is often the whole purpose fo > > >>the programming language, whereas Date stresses rightly here that it has > > >>to be an *abstract* definition.
> > > I definitely think that a data model is abstract. That is why I said > > > that an implementation of the data model (for our purposes of > > > developing software) is a programming language. That is why when > > > countering SQL, claiming it not to be a good implementation of the RM, > > > Date introduces Tutorial-D, another language. I am stating that a data > > > model is the abstraction of a programming language (or sublanguage).
> > That's not how I would formulate it. SQL is not an implementation of a > > data model, it *is* a data model (as defined above by Chris Date).
> Both SQL and QUEL were implementations based (however loosely) on the > Relational Model. So, a single data model can have multiple > implementations.
Not in that sense. Your example is not a really good one because the RM is strictly speaking not a data model (using Date's definition) but rather a description of a class of data models. It lists some requirements, and sketches a few things, but doesn't exactly define how the abstract machine looks and what the complete set of operations is.
> Similarly an oject data model can be implemented by > both Java and C++ in different ways, with varying degress of purity.
Not in the definition of data model that we are using at the moment. The semantics of Java and C++ describe different state machines and different operations, so they define different data models. Of course there are some comonalities and things they share, but that is different from saying they represent the same data model.
> > SQL > > and the relational model are at the same abstraction level,
> An instance of the SQL programming language (e.g. SQL as implemented in > Oracle 8i) is an implementation, an actual language that I can use to > perform a query against a database.
Yes, but a particular implementation is yet again at another lower abstraction level.
Perhaps there is a small lesson here. Saying that A is an abstraction of B, or that A is abstract is meaningless until you have explain in what way exactly you are abstracting or what it is that you are abstracting from.
> > > [...] Whenever I mention that I want to > > > work with such data structures as ordered lists with associated insert > > > and delete functions, I am informed that I am talking about > > > representation and that what I want is possible with the data modeled > > > via the RM and then handled with another product in front of that. I'm > > > showing that the RM is all about representation. As soon as you decide > > > to use another representation, you are moving away from the RM.
> > I don't know who told you that lists are somehow only representation > > while sets are not, but that is nonsense.
> Agreed.
I currently do some research in bioinformatics. Lists of nucleotides and proteins all over the place, and measurement series are also very often much more naturally represented as lists.
> > The reason to avoid lists is > > far more mundane and practical; it would make the DBMS more complex and > > make tasks such as query optimization, concurrency control and integrity > > maintenance harder.
> Harder for whom?
The implementors of the DBMS. And if their job gets hard that leads to more missed opportunities for the query optimizer so slower performance, more difficult algorithms for concurrency control that allows less concurrency, and more overhead for more complex integrity constraints.
> > It would also make the theory more complex, which in > > the long term usually also translates into practical problems.
> The language I speak also has a very complicated theory behind it, if > any at all (IIRC Chomsky or others have worked on a mathematical theory > behind languages). But it still might make sense for me to speak it.
That's because you don't have to build the Language Management System as they already exist. But if you were faced with the task of designing such language processing systems from scratch then you would probably try to design this language as simple as possible, but, to paraphrase Einstein, not simpeler.
-- Jan Hidders
PS. I'm really signing off now as my train leaves within a few hours. Expect a reply after a week or so.
> > > >>>[...] If we were to implement a data model what would we have? Let's > > > >>>take a look at a recent definition of data model from Date.
> > > >>>A data model is an abstract, self-contained, logical definition of > > > >>>the objects, operators, and so forth, that together constitute the > > > >>>abstract machine with which users interact. The objects allow us to > > > >>>model the structure of data. The operators allow us to model its > > > >>>behavior. (C. J. Date, An Introduction to Database Systems, Addison > > > >>>Wesley, 8e, 2003, p 15-16)
> > > >>>I conclude from this that the implementation of a data model is a > > > >>>programming language, whether a general purpose programming language > > > >>>or not.
> > > >>While I don't think that what you say here is strictly speaking > > > >>incorrect, I do believe that it is misleading. In programming languages > > > >>one is often rather more concrete about how the data is stored and how > > > >>the operators do their work, in fact that is often the whole purpose fo > > > >>the programming language, whereas Date stresses rightly here that it has > > > >>to be an *abstract* definition.
> > > > I definitely think that a data model is abstract. That is why I said > > > > that an implementation of the data model (for our purposes of > > > > developing software) is a programming language. That is why when > > > > countering SQL, claiming it not to be a good implementation of the RM, > > > > Date introduces Tutorial-D, another language. I am stating that a data > > > > model is the abstraction of a programming language (or sublanguage).
> > > That's not how I would formulate it. SQL is not an implementation of a > > > data model, it *is* a data model (as defined above by Chris Date).
> > Both SQL and QUEL were implementations based (however loosely) on the > > Relational Model. So, a single data model can have multiple > > implementations.
> Not in that sense. Your example is not a really good one because the RM > is strictly speaking not a data model (using Date's definition) but > rather a description of a class of data models. It lists some > requirements, and sketches a few things, but doesn't exactly define how > the abstract machine looks and what the complete set of operations is.
> > Similarly an oject data model can be implemented by > > both Java and C++ in different ways, with varying degress of purity.
> Not in the definition of data model that we are using at the moment. > The semantics of Java and C++ describe different state machines and > different operations, so they define different data models.
Because I was making an effort to get a handle on the term "data model" as found in the phrase "Relational Data Model" I'm working with a different "data model" than you are. Mine is more abstract (or as you stated, it is a description of a class of data models). Using the term the way I am using it, you can have a "Relational Data Model" and an "Object Data Model," for example. Can you name a bunch of data models using your definition?
> Of course > there are some comonalities and things they share, but that is > different from saying they represent the same data model.
> > > SQL > > > and the relational model are at the same abstraction level,
> > An instance of the SQL programming language (e.g. SQL as implemented in > > Oracle 8i) is an implementation, an actual language that I can use to > > perform a query against a database.
> Yes, but a particular implementation is yet again at another lower > abstraction level.
And a data model is at a higher level of abstraction. Again, recall that I was trying to get a handle on the meaning of "Relational Data Model." What is this "data model" when you remove the adjective? It is more abstract that what you are referring to.
> Perhaps there is a small lesson here. Saying that A is an abstraction > of B, or that A is abstract is meaningless until you have explain in > what way exactly you are abstracting or what it is that you are > abstracting from.
It isn't meaningless, but it isn't very helpful simply to state that something is an abstraction of something else. It is a bit more concrete to state that something is an implementation of something else. So if you take Relational Data Model and want to get a handle on this data model, you can at least see that if you were to implement it, you would have a programming language (or sublanguage).
> > > > [...] Whenever I mention that I want to > > > > work with such data structures as ordered lists with associated insert > > > > and delete functions, I am informed that I am talking about > > > > representation and that what I want is possible with the data modeled > > > > via the RM and then handled with another product in front of that. I'm > > > > showing that the RM is all about representation. As soon as you decide > > > > to use another representation, you are moving away from the RM.
> > > I don't know who told you that lists are somehow only representation > > > while sets are not, but that is nonsense.
> > Agreed.
> I currently do some research in bioinformatics. Lists of nucleotides > and proteins all over the place, and measurement series are also very > often much more naturally represented as lists.
Perhaps you are beyond me on that one. I've read Bioinformatics for Dummies ;-)
> > > The reason to avoid lists is > > > far more mundane and practical; it would make the DBMS more complex and > > > make tasks such as query optimization, concurrency control and integrity > > > maintenance harder.
> > Harder for whom?
> The implementors of the DBMS.
BINGO! Having been on the applications side of the house, I am aware that choices are made on user interface design decisions are sometimes made due to the cost of implementation or support for the developers. But for an entire industry to fix on that strategy when the user is a programmer is really dreadful. It seems someone could look at how to make the end-user (in this case a software developer) as productive as possible.
> And if their job gets hard that leads to > more missed opportunities for the query optimizer so slower > performance,
That would make more sense to me if I did not work with a non-1NF (non-relational) product that provides good performance.
> more difficult algorithms for concurrency control that > allows less concurrency, and more overhead for more complex integrity > constraints.
That one I agree with.
> > > It would also make the theory more complex, which in > > > the long term usually also translates into practical problems.
> > The language I speak also has a very complicated theory behind it, if > > any at all (IIRC Chomsky or others have worked on a mathematical theory > > behind languages). But it still might make sense for me to speak it.
> That's because you don't have to build the Language Management System > as they already exist. But if you were faced with the task of designing > such language processing systems from scratch then you would probably > try to design this language as simple as possible, but, to paraphrase > Einstein, not simpeler.
Then there is that philosophy of making products easy for users. The RM isn't getting us there it seems. Cheers! --dawn
> -- Jan Hidders
> PS. I'm really signing off now as my train leaves within a few hours. > Expect a reply after a week or so.
Have a good trip. (Or, rather, I hope you had a good trip and enjoyed your time away from the screen and keyboard.)
> > [...] Whenever I mention that I want to > > work with such data structures as ordered lists with associated insert > > and delete functions, I am informed that I am talking about > > representation and that what I want is possible with the data modeled > > via the RM and then handled with another product in front of that. I'm > > showing that the RM is all about representation. As soon as you decide > > to use another representation, you are moving away from the RM.
> I don't know who told you that lists are somehow only representation > while sets are not, but that is nonsense. The reason to avoid lists is > far more mundane and practical; it would make the DBMS more complex and > make tasks such as query optimization, concurrency control and integrity > maintenance harder. It would also make the theory more complex, which in > the long term usually also translates into practical problems.
I do not agree with this. Conventional ordering (and hence listing) is mathematically impossible in the relational model period, due to the Codd's redefinition of RM-relations and the model's closure. Dawn is hence correct imo - lists must be interpreted by a process external to the RM, not for the sake of simplicity, or query optimization, but rather because the very the nature of that data model precludes their implementation.
JOG wrote: > Jan Hidders wrote: > [snip] > > > [...] Whenever I mention that I want to > > > work with such data structures as ordered lists with associated insert > > > and delete functions, I am informed that I am talking about > > > representation and that what I want is possible with the data modeled > > > via the RM and then handled with another product in front of that. I'm > > > showing that the RM is all about representation. As soon as you decide > > > to use another representation, you are moving away from the RM.
> > I don't know who told you that lists are somehow only representation > > while sets are not, but that is nonsense. The reason to avoid lists is > > far more mundane and practical; it would make the DBMS more complex and > > make tasks such as query optimization, concurrency control and integrity > > maintenance harder. It would also make the theory more complex, which in > > the long term usually also translates into practical problems.
> I do not agree with this. Conventional ordering (and hence listing) is > mathematically impossible in the relational model period, due to the > Codd's redefinition of RM-relations and the model's closure. Dawn is > hence correct imo - lists must be interpreted by a process external to > the RM, not for the sake of simplicity, or query optimization, but > rather because the very the nature of that data model precludes their > implementation.
I agree (I guess it makes sense that I would agree with you agreeing with me). While ordering functions (SORT) may be defined on sets, those are orderings on values. There is no ordering within the relational structure itself.
Of course you can simulate an ordered list using relations by adding in ordering attributes and related functions such as insert & delete. That could all be done behind the scenes without the programmer touching the ordering attribute at all. But once the interface to the user (programmer) has these features, it is no longer an RM interface because it supports ordered lists. --dawn
In article <1138380152.680513.293...@g49g2000cwa.googlegroups.com>, j...@cs.nott.ac.uk says...
> Jan Hidders wrote: > [snip] > I do not agree with this. Conventional ordering (and hence listing) is > mathematically impossible in the relational model period, due to the > Codd's redefinition of RM-relations and the model's closure.
Can you elaborate on this? I can't immediately see why lists are harder than arrays, special cases of which even today's SQL systems can handle.
> Dawn is > hence correct imo - lists must be interpreted by a process external to > the RM, not for the sake of simplicity, or query optimization, but > rather because the very the nature of that data model precludes their > implementation.
...though of course if you view the type system as "external to the RM", you are correct---but I don't really see the point of the argument in that case. -- Jon
I do respect many of your opinions, but maybe you could give me more insight. It seems in many of your past postings, that:
1) You think that throwing data control (I mean real life 'facts' here, not bits on a hard drive) into the domain of the developer (who is a person that really has no connection with the data) is a good thing. In other words,
Me: 'Hey, developer, build me a sandwich'
D: 'OK, I can do that, what do you have in the fridge?'
Me: 'I don't know, go look at it and figure it out. Oh, and here's a knife if you need it'
D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe you might want to know if somebody else wants mustard? Wait a second ... is there somebody else?'
Me: 'Well, that's not important right now, is it?'
2) You seem to sing 'convenience' in many of your posts (under the hoods). Personally, and perhaps unfortunately, I think we can't always be convenient when it comes to modelling reality.
3) It's almost like you're trying to say that RM is this thing that we have to 'put up' with. You could be correct in a 'convenient' way, but wrong in a 'correct' way. Think about it.
4) Keep up the discussion. I enjoy it immensely. I'll certainly be perusing your blog every now and again.
> I do respect many of your opinions, but maybe you could give me more > insight. It seems in many of your past postings, that:
> 1) You think that throwing data control (I mean real life 'facts' here, > not bits on a hard drive) into the domain of the developer (who is a > person that really has no connection with the data) is a good thing.
Perhaps we need to define developer. I am calling anyone who is developing software a "developer." Perhaps we need to define software? It is everything "stored on" a computer that is not hardware. Does that work for you? That would be "soft stuff" that can change, compared to the hardware. I haven't thought long and hard about that definition, but that is how I perceive it.
Some parts of this software could be like propositions that can be used as input or output, while other aspects of this software could be functions that operate on input to produce output. But it's all software.
> In other words,
> Me: 'Hey, developer, build me a sandwich'
--d: smile when you call me that
> D: 'OK, I can do that, what do you have in the fridge?'
--d: how hungry are you? are you a vegetarian? do you prefer whole wheat? Does anyone else need a sandwich? ...more attempts to ascertain requirements.
> Me: 'I don't know, go look at it and figure it out. Oh, and here's a > knife if you need it'
--d: at this point I tell you to make it yourself, but I'll play along
> D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe > you might want to know if somebody else wants mustard? Wait a second > ... is there somebody else?'
I know I'll often miss something in spite of considerable efforts in requirements elicitation, but hopefully not something that big.
> Me: 'Well, that's not important right now, is it?'
Sure it is. I might have to be careful how much of the cheese I use up on your sandwich.
> 2) You seem to sing 'convenience' in many of your posts (under the > hoods).
Productivity for software developers as users of various tools. If you call that convenience...
> Personally, and perhaps unfortunately, I think we can't always > be convenient when it comes to modelling reality.
No, but we can usually improve on user experience and productivity when we decide those are important.
> 3) It's almost like you're trying to say that RM is this thing that we > have to 'put up' with.
In fact, I think it is something that we DON'T have to put up with ;-)
> You could be correct in a 'convenient' way, but > wrong in a 'correct' way. Think about it.
Oh, you know I do.
> 4) Keep up the discussion. I enjoy it immensely. I'll certainly be > perusing your blog every now and again.
> Perhaps we need to define developer. I am calling anyone who is > developing software a "developer." Perhaps we need to define > software? > It is everything "stored on" a computer that is not hardware. Does > that work for you? That would be "soft stuff" that can change, > compared to the hardware. I haven't thought long and hard about that > definition, but that is how I perceive it.
That definition would of course aso include the "end user" who only punches data into a shrink-wrapped software package. In my view, a "developer" should be one who is making software. You may of course include the end users who produce nifty macros to facilitate daily work. The border is certainly a fluid one. Most of us have started as "end users", I guess. -- Leif Biberg Kristensen http://solumslekt.org/
> > Perhaps we need to define developer. I am calling anyone who is > > developing software a "developer."
I still agree with myself on this one
> Perhaps we need to define > > software? > > It is everything "stored on" a computer that is not hardware. Does > > that work for you? That would be "soft stuff" that can change, > > compared to the hardware. I haven't thought long and hard about that > > definition, but that is how I perceive it.
> That definition would of course aso include the "end user" who only > punches data into a shrink-wrapped software package. In my view, a > "developer" should be one who is making software.
That is my view as well and I see where my definitions are not tight enough to make that clear. If someone is using software, providing input or using output, but not developing any functions, then I guess I would say they are not developing software. However, if that input is in the form of specs... (e.g. the user type in a bunch of xml documents and dtds and then clicks a button to generate an application), then what?
Anyway, I'm good with saying that a developer is someone developing software, I'm not as happy with the definiion of software. What is a nice crisp definition of software?
> You may of course > include the end users who produce nifty macros to facilitate daily > work. The border is certainly a fluid one. Most of us have started as > "end users", I guess.
And developers are end-users of language compilers, interpreters, dbms interfaces, etc. Cheers! --dawn
dawn wrote: > Todd wrote: > > 1) You think that throwing data control (I mean real life 'facts' here, > > not bits on a hard drive) into the domain of the developer (who is a > > person that really has no connection with the data) is a good thing.
> Perhaps we need to define developer. I am calling anyone who is > developing software a "developer." Perhaps we need to define software? > It is everything "stored on" a computer that is not hardware. Does > that work for you? That would be "soft stuff" that can change, > compared to the hardware. I haven't thought long and hard about that > definition, but that is how I perceive it.
What works for you then? Flexibility or stability? Can we achieve both? Don't get me wrong. I think you are flexing some good muscle.
> Some parts of this software could be like propositions that can be used > as input or output, while other aspects of this software could be > functions that operate on input to produce output. But it's all > software.
> > In other words,
> > Me: 'Hey, developer, build me a sandwich'
> --d: smile when you call me that
Coincidence. D was supposed to mean Developer, not Dawn. Sorry about that if you took it that way.
> > D: 'OK, I can do that, what do you have in the fridge?'
> --d: how hungry are you? are you a vegetarian? do you prefer whole > wheat? Does anyone else need a sandwich? ...more attempts to ascertain > requirements.
> > Me: 'I don't know, go look at it and figure it out. Oh, and here's a > > knife if you need it'
> --d: at this point I tell you to make it yourself, but I'll play along
> > D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe > > you might want to know if somebody else wants mustard? Wait a second > > ... is there somebody else?'
> I know I'll often miss something in spite of considerable efforts in > requirements elicitation, but hopefully not something that big.
> > Me: 'Well, that's not important right now, is it?'
> Sure it is. I might have to be careful how much of the cheese I use up > on your sandwich.
Well, I suppose I was getting at the fact that it seems that some of what you suggest screams lack of data integrity, and in trying to get that point across, I dropped into a client situation (the dialog above would have me as the client) which is frequent in any kind of database design. I was simply trying to say that some of what you suggest may be putting a scarier load on the developer. Chaos where something should be stable. Initial condition: client gives you bad data, or no data; client gives you bad metadata; Result: chaos gives you a terrible headache as everything may spin out of control. Sensitivity to initial conditions, you get the idea...
> > 2) You seem to sing 'convenience' in many of your posts (under the > > hoods).
> Productivity for software developers as users of various tools. If you > call that convenience...
Productivity. What is that exactly. I assume you mean that developers make money for a small amount of time spent, ease of maintenance of software, blah blah. Well, at this point, I still need some convincing.
Todd wrote: > dawn wrote: > > Todd wrote: > > > 1) You think that throwing data control (I mean real life 'facts' here, > > > not bits on a hard drive) into the domain of the developer (who is a > > > person that really has no connection with the data) is a good thing.
> > Perhaps we need to define developer. I am calling anyone who is > > developing software a "developer." Perhaps we need to define software? > > It is everything "stored on" a computer that is not hardware. Does > > that work for you? That would be "soft stuff" that can change, > > compared to the hardware. I haven't thought long and hard about that > > definition, but that is how I perceive it.
> What works for you then? Flexibility or stability?
Yes. And the needs for each must be taken into account when assessing risks. Sometimes there is a need for such incredible stability that you would not want to risk any instability for a little flexibility. You still would want optimal flexibility within your extreme stability, however.
> Can we achieve > both? Don't get me wrong. I think you are flexing some good muscle.
> > Some parts of this software could be like propositions that can be used > > as input or output, while other aspects of this software could be > > functions that operate on input to produce output. But it's all > > software.
> > > In other words,
> > > Me: 'Hey, developer, build me a sandwich'
> > --d: smile when you call me that
> Coincidence. D was supposed to mean Developer, not Dawn. Sorry about > that if you took it that way.
Ah, yes, I misinterpreted, but since I'm from the developer side of the house (if we must choose sides), that read OK.
> > > D: 'OK, I can do that, what do you have in the fridge?'
> > --d: how hungry are you? are you a vegetarian? do you prefer whole > > wheat? Does anyone else need a sandwich? ...more attempts to ascertain > > requirements.
> > > Me: 'I don't know, go look at it and figure it out. Oh, and here's a > > > knife if you need it'
> > --d: at this point I tell you to make it yourself, but I'll play along
> > > D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe > > > you might want to know if somebody else wants mustard? Wait a second > > > ... is there somebody else?'
> > I know I'll often miss something in spite of considerable efforts in > > requirements elicitation, but hopefully not something that big.
> > > Me: 'Well, that's not important right now, is it?'
> > Sure it is. I might have to be careful how much of the cheese I use up > > on your sandwich.
> Well, I suppose I was getting at the fact that it seems that some of > what you suggest screams lack of data integrity,
I understand why you say that. There is more than one way to achieve data integrity, however. There are also many different aspects to data integrity. A system designed to handle only the "most prevelent color" (or some other attribute) rather than a list of colors because that would be less expensive is sacrificing data integrity, perhaps with a good business case for doing so when the DBMS doesn't support attribute lists.
> and in trying to get > that point across, I dropped into a client situation (the dialog above > would have me as the client) which is frequent in any kind of database > design. I was simply trying to say that some of what you suggest may > be putting a scarier load on the developer.
Yup, I followed your reasoning.
> Chaos where something > should be stable. Initial condition: client gives you bad data, or no > data; client gives you bad metadata; Result: chaos gives you a terrible > headache as everything may spin out of control. Sensitivity to initial > conditions, you get the idea...
I understand that different things are scary when choosing different toolsets. There are tradeoffs.
> > > 2) You seem to sing 'convenience' in many of your posts (under the > > > hoods).
> > Productivity for software developers as users of various tools. If you > > call that convenience...
> Productivity. What is that exactly.
More, better, faster. An individual or team is able to accomplish more with less, for the long haul.
> I assume you mean that developers > make money for a small amount of time spent, ease of maintenance of > software, blah blah. Well, at this point, I still need some > convincing.
> JOG wrote: > > Jan Hidders wrote: > > [snip] > > > > [...] Whenever I mention that I want to > > > > work with such data structures as ordered lists with associated insert > > > > and delete functions, I am informed that I am talking about > > > > representation and that what I want is possible with the data modeled > > > > via the RM and then handled with another product in front of that. I'm > > > > showing that the RM is all about representation. As soon as you decide > > > > to use another representation, you are moving away from the RM.
> > > I don't know who told you that lists are somehow only representation > > > while sets are not, but that is nonsense. The reason to avoid lists is > > > far more mundane and practical; it would make the DBMS more complex and > > > make tasks such as query optimization, concurrency control and integrity > > > maintenance harder. It would also make the theory more complex, which in > > > the long term usually also translates into practical problems.
> > I do not agree with this. Conventional ordering (and hence listing) is > > mathematically impossible in the relational model period, due to the > > Codd's redefinition of RM-relations and the model's closure. Dawn is > > hence correct imo - lists must be interpreted by a process external to > > the RM, not for the sake of simplicity, or query optimization, but > > rather because the very the nature of that data model precludes their > > implementation. > I agree (I guess it makes sense that I would agree with you agreeing > with me). While ordering functions (SORT) may be defined on sets, > those are orderings on values. There is no ordering within the > relational structure itself. > Of course you can simulate an ordered list using relations by adding in > ordering attributes and related functions such as insert & delete. > That could all be done behind the scenes without the programmer > touching the ordering attribute at all. But once the interface to the > user (programmer) has these features, it is no longer an RM interface > because it supports ordered lists. --dawn
Talking about the relational model of data and the "list model of data" instead of the relational data model and the "list data model" what is the advantage of one over the other when modeling the following problems:
a) The problem is naturally formulated in terms of named lists of items and lists operations. How would you implement this with sets and sets operations ?
b) The problem is naturally formulated in terms of named sets of items and set operations. How would you implement this with lists and lists operations ?
c) The problem is naturally formulated in terms of sets and lists with their operations. How would you implement this with lists and lists operations ? How would you implement this with sets and sets operations ?
There is a need for an efficient model to support both sets and lists ? What are the basic operations for combining lists and sets ?
Where do we stop ? Why not asking for a model to support all mathematics ?
> > > Perhaps we need to define developer. I am calling anyone who is > > > developing software a "developer."
> I still agree with myself on this one
> > Perhaps we need to define > > > software? > > > It is everything "stored on" a computer that is not hardware. Does > > > that work for you? That would be "soft stuff" that can change, > > > compared to the hardware. I haven't thought long and hard about that > > > definition, but that is how I perceive it.
> > That definition would of course aso include the "end user" who only > > punches data into a shrink-wrapped software package. In my view, a > > "developer" should be one who is making software. > That is my view as well and I see where my definitions are not tight > enough to make that clear. If someone is using software, providing > input or using output, but not developing any functions, then I guess I > would say they are not developing software. However, if that input is > in the form of specs... (e.g. the user type in a bunch of xml documents > and dtds and then clicks a button to generate an application), then > what? > Anyway, I'm good with saying that a developer is someone developing > software, I'm not as happy with the definiion of software. What is a > nice crisp definition of software?
Do you think of a virtual machine as software or hardware ? Software = ware that can be easily changed and provide a function only when used with some hardware. Hardware= ware that is hard to change and provide a function only when used with some software. The soft or hard quality is relative.
> > > > Perhaps we need to define developer. I am calling anyone who is > > > > developing software a "developer."
> > I still agree with myself on this one
> > > Perhaps we need to define > > > > software? > > > > It is everything "stored on" a computer that is not hardware. Does > > > > that work for you? That would be "soft stuff" that can change, > > > > compared to the hardware. I haven't thought long and hard about that > > > > definition, but that is how I perceive it.
> > > That definition would of course aso include the "end user" who only > > > punches data into a shrink-wrapped software package. In my view, a > > > "developer" should be one who is making software.
> > That is my view as well and I see where my definitions are not tight > > enough to make that clear. If someone is using software, providing > > input or using output, but not developing any functions, then I guess I > > would say they are not developing software. However, if that input is > > in the form of specs... (e.g. the user type in a bunch of xml documents > > and dtds and then clicks a button to generate an application), then > > what?
> > Anyway, I'm good with saying that a developer is someone developing > > software, I'm not as happy with the definiion of software. What is a > > nice crisp definition of software?
> Do you think of a virtual machine as software or hardware ?
software
> Software = ware that can be easily changed and provide a function only when > used with some hardware.
It would be great if software could be defined as being easy to change, but I don't think that can be part of the definition.
> Hardware= ware that is hard to change and provide a function only when used > with some software. > The soft or hard quality is relative.
A feature could be in hardware or software, if that is what you mean by relative. I don't really like your definitions however. Hardware is hard bz you can kick it, not because it is hard to change. But not everything you can kick is hardware.
Hardware: All components of a computer that can be kicked Software: All components of a computer that cannot be kicked
??
> For example the mathematics is hardware ;-)
Mathematics is everywhere, in both hardware and software. Cheerss! --dawn
> > JOG wrote: > > > Jan Hidders wrote: > > > [snip] > > > > > [...] Whenever I mention that I want to > > > > > work with such data structures as ordered lists with associated > insert > > > > > and delete functions, I am informed that I am talking about > > > > > representation and that what I want is possible with the data > modeled > > > > > via the RM and then handled with another product in front of that. > I'm > > > > > showing that the RM is all about representation. As soon as you > decide > > > > > to use another representation, you are moving away from the RM.
> > > > I don't know who told you that lists are somehow only representation > > > > while sets are not, but that is nonsense. The reason to avoid lists is > > > > far more mundane and practical; it would make the DBMS more complex > and > > > > make tasks such as query optimization, concurrency control and > integrity > > > > maintenance harder. It would also make the theory more complex, which > in > > > > the long term usually also translates into practical problems.
> > > I do not agree with this. Conventional ordering (and hence listing) is > > > mathematically impossible in the relational model period, due to the > > > Codd's redefinition of RM-relations and the model's closure. Dawn is > > > hence correct imo - lists must be interpreted by a process external to > > > the RM, not for the sake of simplicity, or query optimization, but > > > rather because the very the nature of that data model precludes their > > > implementation.
> > I agree (I guess it makes sense that I would agree with you agreeing > > with me). While ordering functions (SORT) may be defined on sets, > > those are orderings on values. There is no ordering within the > > relational structure itself.
> > Of course you can simulate an ordered list using relations by adding in > > ordering attributes and related functions such as insert & delete. > > That could all be done behind the scenes without the programmer > > touching the ordering attribute at all. But once the interface to the > > user (programmer) has these features, it is no longer an RM interface > > because it supports ordered lists. --dawn
> Talking about the relational model of data and the "list model of data" > instead of the relational data model and the "list data model" what is the > advantage of one over the other when modeling the following problems:
> a) The problem is naturally formulated in terms of named lists of items and > lists operations. > How would you implement this with sets and sets operations ?
> b) The problem is naturally formulated in terms of named sets of items and > set operations. > How would you implement this with lists and lists operations ?
> c) The problem is naturally formulated in terms of sets and lists with their > operations. > How would you implement this with lists and lists operations ? > How would you implement this with sets and sets operations ?
> There is a need for an efficient model to support both sets and lists ?
Yes.
> What are the basic operations for combining lists and sets ?
The ones that come with any general purpose programming language.
> Where do we stop ?
I'm good with programming languages as a "stopping point" building up from there to higher levels with libraries of code.
> Why not asking for a model to support all mathematics ?
Again, I'm good with programming languages and libraries thereof. smiles. --dawn
> > > JOG wrote: > > > > Jan Hidders wrote: > > > > [snip] > > > > > > [...] Whenever I mention that I want to > > > > > > work with such data structures as ordered lists with associated > > insert > > > > > > and delete functions, I am informed that I am talking about > > > > > > representation and that what I want is possible with the data > > modeled > > > > > > via the RM and then handled with another product in front of that. > > I'm > > > > > > showing that the RM is all about representation. As soon as you > > decide > > > > > > to use another representation, you are moving away from the RM.
> > > > > I don't know who told you that lists are somehow only representation > > > > > while sets are not, but that is nonsense. The reason to avoid lists is > > > > > far more mundane and practical; it would make the DBMS more complex > > and > > > > > make tasks such as query optimization, concurrency control and > > integrity > > > > > maintenance harder. It would also make the theory more complex, which > > in > > > > > the long term usually also translates into practical problems.
> > > > I do not agree with this. Conventional ordering (and hence listing) is > > > > mathematically impossible in the relational model period, due to the > > > > Codd's redefinition of RM-relations and the model's closure. Dawn is > > > > hence correct imo - lists must be interpreted by a process external to > > > > the RM, not for the sake of simplicity, or query optimization, but > > > > rather because the very the nature of that data model precludes their > > > > implementation.
> > > I agree (I guess it makes sense that I would agree with you agreeing > > > with me). While ordering functions (SORT) may be defined on sets, > > > those are orderings on values. There is no ordering within the > > > relational structure itself.
> > > Of course you can simulate an ordered list using relations by adding in > > > ordering attributes and related functions such as insert & delete. > > > That could all be done behind the scenes without the programmer > > > touching the ordering attribute at all. But once the interface to the > > > user (programmer) has these features, it is no longer an RM interface > > > because it supports ordered lists. --dawn
> > Talking about the relational model of data and the "list model of data" > > instead of the relational data model and the "list data model" what is the > > advantage of one over the other when modeling the following problems:
> > a) The problem is naturally formulated in terms of named lists of items and > > lists operations. > > How would you implement this with sets and sets operations ?
> > b) The problem is naturally formulated in terms of named sets of items and > > set operations. > > How would you implement this with lists and lists operations ?
> > c) The problem is naturally formulated in terms of sets and lists with their > > operations. > > How would you implement this with lists and lists operations ? > > How would you implement this with sets and sets operations ?
> > There is a need for an efficient model to support both sets and lists ? > Yes.
OK.
> > What are the basic operations for combining lists and sets ? > The ones that come with any general purpose programming language.
Can you make a list or a set with them and post it ?
> > Where do we stop ? > I'm good with programming languages as a "stopping point" building up > from there to higher levels with libraries of code.
Well, the programmig languages are many. :-) What programming languages are you refering to ? The future ones ?
> > Why not asking for a model to support all mathematics ? > Again, I'm good with programming languages and libraries thereof.
A variable SET of variable LISTs of symbols and a variable SET of variable LISTs of substitution rules LISTed in some order is what you propose ? Or the other way around ? Can you make such a thing declarative (specifying the data, not the process of getting the data) ?
> > > JOG wrote: > > > > Jan Hidders wrote: > > > > [snip] > > > > > > [...] Whenever I mention that I want to > > > > > > work with such data structures as ordered lists with associated > > insert > > > > > > and delete functions, I am informed that I am talking about > > > > > > representation and that what I want is possible with the data > > modeled > > > > > > via the RM and then handled with another product in front of that. > > I'm > > > > > > showing that the RM is all about representation. As soon as you > > decide > > > > > > to use another representation, you are moving away from the RM.
> > > > > I don't know who told you that lists are somehow only representation > > > > > while sets are not, but that is nonsense. The reason to avoid lists is > > > > > far more mundane and practical; it would make the DBMS more complex > > and > > > > > make tasks such as query optimization, concurrency control and > > integrity > > > > > maintenance harder. It would also make the theory more complex, which > > in > > > > > the long term usually also translates into practical problems.
> > > > I do not agree with this. Conventional ordering (and hence listing) is > > > > mathematically impossible in the relational model period, due to the > > > > Codd's redefinition of RM-relations and the model's closure. Dawn is > > > > hence correct imo - lists must be interpreted by a process external to > > > > the RM, not for the sake of simplicity, or query optimization, but > > > > rather because the very the nature of that data model precludes their > > > > implementation.
> > > I agree (I guess it makes sense that I would agree with you agreeing > > > with me). While ordering functions (SORT) may be defined on sets, > > > those are orderings on values. There is no ordering within the > > > relational structure itself.
> > > Of course you can simulate an ordered list using relations by adding in > > > ordering attributes and related functions such as insert & delete. > > > That could all be done behind the scenes without the programmer > > > touching the ordering attribute at all. But once the interface to the > > > user (programmer) has these features, it is no longer an RM interface > > > because it supports ordered lists. --dawn
> > Talking about the relational model of data and the "list model of data" > > instead of the relational data model and the "list data model" what is the > > advantage of one over the other when modeling the following problems:
> > a) The problem is naturally formulated in terms of named lists of items and > > lists operations. > > How would you implement this with sets and sets operations ?
> > b) The problem is naturally formulated in terms of named sets of items and > > set operations. > > How would you implement this with lists and lists operations ?
> > c) The problem is naturally formulated in terms of sets and lists with their > > operations. > > How would you implement this with lists and lists operations ? > > How would you implement this with sets and sets operations ?
> > There is a need for an efficient model to support both sets and lists ? > Yes.
OK.
> > What are the basic operations for combining lists and sets ? > The ones that come with any general purpose programming language.
Can you make a list or a set with them and post it ?
> > Where do we stop ? > I'm good with programming languages as a "stopping point" building up > from there to higher levels with libraries of code.
Well, the programmig languages are many. :-) What programming languages are you refering to ? The future ones ?
> > Why not asking for a model to support all mathematics ? > Again, I'm good with programming languages and libraries thereof.
A variable SET of variable LISTs of symbols and a variable SET of variable LISTs of substitution rules LISTed in some order is what you propose ? Or the other way around ? Can you make such a thing declarative (specifying the data, not the process of getting the data) ?
> > > Leif B. Kristensen wrote: > > > > dawn skrev:
> > > > > Perhaps we need to define developer. I am calling anyone who is > > > > > developing software a "developer."
> > > I still agree with myself on this one
> > > > Perhaps we need to define > > > > > software? > > > > > It is everything "stored on" a computer that is not hardware. Does > > > > > that work for you? That would be "soft stuff" that can change, > > > > > compared to the hardware. I haven't thought long and hard about that > > > > > definition, but that is how I perceive it.
> > > > That definition would of course aso include the "end user" who only > > > > punches data into a shrink-wrapped software package. In my view, a > > > > "developer" should be one who is making software.
> > > That is my view as well and I see where my definitions are not tight > > > enough to make that clear. If someone is using software, providing > > > input or using output, but not developing any functions, then I guess I > > > would say they are not developing software. However, if that input is > > > in the form of specs... (e.g. the user type in a bunch of xml documents > > > and dtds and then clicks a button to generate an application), then > > > what?
> > > Anyway, I'm good with saying that a developer is someone developing > > > software, I'm not as happy with the definiion of software. What is a > > > nice crisp definition of software? > > Do you think of a virtual machine as software or hardware ? > software > A feature could be in hardware or software, if that is what you mean by > relative. I don't really like your definitions however. Hardware is > hard bz you can kick it, not because it is hard to change. But not > everything you can kick is hardware.
Do you think that hammers are hardware ? Do you think that CD-ROMs are hardware/software ? The instructions on how to build a chair are software ?
> Mathematics is everywhere, in both hardware and software. Cheerss!
|
