Behavioral Database

Based on a conversation on comp.object (usenet):

 > A Relational data *value* base (the typical SQL products like Oracle etc)
 > could not be a general OODB, because you cannot provide user-defined
 > ADTs whose properties are complex computational processes, not mere
 > data values.

But this attribute-orientation is what allows relational data to be readily *sharable* and query-able across *different* and diverse tools and languages. Behaviorism has less known math beyond it, at least as far as managing the relationships *between* behavioral units. There are more known "maths" for manipulating relationships between (properly defined) attributes than ADT's. Thus, a sharable ADT repository that has database-like abilities is hard to build.

I must admit to curiousity as to how this "more known 'maths'" is of any real benefit. It would only take one "math" for systematically describing ADTs to make them usable.

The "self-handling noun" approach of encapsulation and ADT's makes it difficult to factor together common verbs and common needs for consistent manipulation. ADT's make very powerful independent little machines, but they are not very social.

This is a big philosophical sticking point. Attributism has its downsides, but the up-sides outweigh them (at least in my domain).

How would one go about building an ADT-centric database? What would it look like from the database user's side?

I'm open to the idea of merging the best of both worlds, but I don't see how. Consistency across objects and a relaxation of encapsulation would probably be needed, along with a very complex query language. We may have to water down both sides to get such a marriage.

--top

Typical SQL databases certainly make implementing behavioural aspects awkward, but this is a product flaw rather than a conceptual one. Implementing behaviour is essentially a solved problem in the "true" relational world. See TheThirdManifesto, TutorialDee, etc.

Making domain-specific "maths" that fit relational are described under DoesRelationalRequireTypes. But still one has to make sacrifices, or at least satisfy certain requirements, before such can be done. Plus, efficiency dictates some integration between different operations or "types". This is against the independence required for ADT's.

Behavioral-centric interfaces simply have a different "flavor" than attribute-centric interfaces. For example, a "stack" ADT is sort of the antithesis of relational. You couldn't query the insides without lots of push and pops. Otherwise, it wouldn't be a true stack. Relational views a "stack" as merely one view among many for the same data. ADT's are about "hard" packaging, while relational tends to assume EverythingIsRelative, and thus shuns hard packaging. If you want security to keep Johny from doing something, you add requirements on top of Johny's login, not lock up the interface in a global way. Encapsulation (if any) is relative under relational, but absolute for ADT's.

--top

"[R]elational tends to assume EverythingIsRelative"??? What does that mean? You appear to regard "behavioural-centric interfaces" as somehow in competition with the RelationalModel. They are not, unless you are still caught in the OODB vs Relational DBMS debate that long ago lost steam among serious theoreticians. Modern OO and Relational thinking recognises that these approaches are complementary rather than contradictory. As evidence, note that current implementations of the RelationalModel are often built using object oriented languages, and that features of object orientation and the RelationalModel can be seamlessly reconciled, e.g., as in TutorialDee.

Databases being built using OOP languages proves nothing about the actual externally-observable nature of the database. As if the impedance-mismatch been resolved, how about a good demo application.

I happen to agree that an 'ADT database' is likely a no go. It isn't the idea of ADTs that is the problem, but rather the communication and serialization of them. Communication and serialization immediately breaks encapsulation. That said, since you don't need to transport mutable objects between systems, you achieve a great deal of what AbstractDataTypes provide by use of CoinductiveDataTypes. Such types don't require encapsulation, though they do encourage it naturally (in that peeking inside one starts getting iffy for type safety).

That said, the notion of a 'BehavioralDatabase' is perfectly possible. I'd love the ability to store functions and behavior information in a Database, to integrate them with queries or triggers, and so on. But the solution simply won't involve ADTs (it's not as if they're the only choice). Behaviors can be represented in a manner that is understood, in common, between both the Database and its Clients, without encapsulation. Some such approaches are discussed in CrossToolTypeAndObjectSharing.

Likely, the behaviors in common between clients and database would be chosen based on utility and LowestCommonDenominator ability to implement them in most languages. For functions over values, one might expect substitution (for lambdas), projection (for records), simple pattern matching for union values, etc. For communication, the LCD is a bit more difficult to identify... but utility would include such things as get/put/post behavior to URIs (which might include a query back to the database itself), sequences, conditionals. If demand arises, support for exceptions and parallel behavior might also be added, but there would be a tradeoff between the complexity of database connectivity libraries and the featureset.

OTOH, if you don't need (or reject) LowestCommonDenominator support, you might just have a KillerApplication for a language or OperatingSystem.

Wouldn't it be natural to represent behaviour in the database in form of relations between 'operational atoms'? What I mean is kind of a Lisp for database procedures: Do not store procedures as 'procedures' but as command tables referencing command tables (or at least make them accessible that way).

(MAPCAR 'PRINT '(ALL THE NEWS THAT FITS))

table lists id position element 11 1 1 -- MAPCAR 11 2 12 -- QUOTED PRINT 11 3 13 -- QUOTED list 12 1 0 -- QUOTE 12 2 2 -- PRINT 13 1 0 -- QUOTE 13 2 14 -- list below 14 1 3 -- list ALL 14 2 4 -- THE 14 3 5 -- NEWS 14 4 6 -- THAT 14 5 7 -- FITS

table atoms id name 0 QUOTE 1 MAPCAR 2 PRINT 3 ALL 4 THE ...

Yes I agree that this is much too long to write programs in but it is fully accessible relationally.

Giving lists 'IDs' and breaking them down by position isn't "relational" so much as it is driven by the limited structural types available to SQL. If you believe this makes the components 'more accessible' to queries, that is also due to limitations on SQL. There isn't much advantage to destructuring behavior descriptions in the manner you suggest unless you plan to manipulate behavior descriptions much like you manipulate other mutable objects... e.g. to change atom '0' from 'QOUTE' to 'EVAL', or to change id 11, pos 2 to represent item 13 instead of item 12. If behavior descriptions are themselves to be 'immutable values' (like strings), then you gain no advantage at all. Well... that is presuming you are using a query language capable of relational programming.

You may find it worth looking up the sort of 'relational programming' described in ConceptsTechniquesAndModelsOfComputerProgramming (Chapter 9) and practiced (in refined forms) in languages such as PrologLanguage, MercuryLanguage, and DataLog (see CTM Chapter 12). If you are aiming for a relational representation of behavior forms, it is worth learning how one would represent and process arbitrary behavior descriptions in a more advanced relational database that is, more or less, already capable of limited behavior.

If you do plan on mutating 'parts of' a program in this form you suggest, I believe I would aim to use a more GraphicalProgrammingLanguage. Modular extension, procedures, et al. is performed by treating common subgraphs as points that expose entry and exit edges (which might be used for data entry or anything else). The semantics could vary quite a bit, of course... you'd likely have "primitive" points that do certain forms of processing (such as printing or breaking down lists, sources that provide data representations, etc.), but you could have anything from LabView to ActorModel to executable UML. (Language design issues never go away.) In any case, the use of a GraphicalProgrammingLanguage would much better fit and take advantage of the relational medium than does a language designed for expression in the more limited text-based linear format (such as Lisp).

Being "relational" does not necessarily mean one has to manipulate everything with a relational query language or a table browser itself. The human-interaction side can still be anything that can be built in top of tables and queries. It's all a matter of "view" management. Some things are nice to actually manipulate and study as tables, and some are not. Boolean expressions are generally not pleasant to manipulate as tables themselves, but under the hood they could be stored that way. --top

Agreed. For a GraphicalProgrammingLanguage, the natural view for manipulation would be to tweak a 2D or 3D layout of nodes and edges, but the representation for graphs is usually table driven - e.g. a set of nodes and a set of edges. Of course, there is some extra complications in a GraphicalProgrammingLanguage to support such things as OnceAndOnlyOnce description of reusable subgraph components.

In any case, a 'BehavioralDatabase' doesn't require that the behaviors themselves are manipulated or stored as tables. It only requires that the behavior descriptions possess a standard representation and semantics on both server and clients. For effective manipulation, query, and composition, representing behavior descriptions with structured values or tables is preferential to strings, but if you are willing to sacrifice NonFunctionalRequirements (speed, safety, communications costs, etc.) then even flat strings (formatted in accordance with a standard language) can do the job.