What is an Aspect Oriented Database?

An aspect oriented database is an object oriented database that supports the concepts of aspect orientation. An object oriented database is a relational database that supports the cpncepts of object orientation. So everyone knows what an RDBMS is? A tabular approach to defining data that is to be persisted or stored for long term storage and retrieval. Tables can be related to each other by queries that use fields from one table as keys to another table. Queries applied to these fields can make the data in the database correspond to a larger structure that can be defined as ann object model. An object oriented class diagram can be implemented in an RDBMS by mapping fields to collumns, and relationships to columns and by creatign extra tables to manage the relationships between many to many relations between classes. The various types of relationships, that is associations, aggregation can be mapped with hints such as cascade delete so that when a containing row is deleted, the child objects that connect to that row get deleted as well. This resempls an aggregation relationship. An object oriented database would provide a declarative approach to indicating that the relationship is a certain kind of relationship of type "aggregation". Object orentated databases support the notions of OO as direct concepts in the database. As well, they integrate naturally into the programming environment of the language they are supporting.

So the first description of an AODBMS is that it fits naturally into an aspect oriente4d programming language. Aspect oriented languages support concerns that are cross cutting. This means that a programming dependency occurs in many places of the program. This concept applied to a database would be that an aspect oriented database supports directly the concerns of data management accross multiple classes. One such example of a crosscutting data concern would be that "all tables have a column time_modified". This is needed to suport the export and tracking of what has been exported to another location. The crosscutting concern is that the modification time column is placed on many tables, and the value is updated to be the time of the last commit to that row. This can be concidered a "feature" of tables or classes that exist withing the context of an application. Time_modified is not really a domain value of a "customer". So should it be placed in a table called "customer"? Instead concider maybe the time_modified should be available to the query engine, and tracked for all objects in the classes in the "CRM" context. So the data declaration for CRM could be CRM.classes.time_modified. If the field is moved to an aspect that woudl define the feature of ModifiedObjects, then the ability to query this would need to be supported, so an AODBMS would support a query language that allowed queries based on this new "field", but it isn't realy a customer field, but just a filter value bound to the customer.