Schema

Schema

A Schema is the way AQL has to describe the structure, the topology of a database. It describes which are the entities considered in the database, which are their attributes and how entities are linked with each other.

Syntax

A typical example of a Schema could be the following:

schema MySchema = literal : MyTypeside {
	entities
		Employe
		Department
	foreign_keys
		manager   : Employee -> Employee
		worksIn   : Employee -> Department
		secretary : Department -> Employee
	path_equations
        manager.worksIn = worksIn
        secretary.worksIn = Department
    attributes
        first last	: Employee -> String
        age			: Employee -> Integer
        name 		: Department -> String
}

where MySchema is the name of the Schema, MyTypeSide is the Typeside on which the Schema is built.

Then we have a list of entities, which specifies the concepts considered in the database. In a relational setting, this could be seen as the list of tables.

Then we can provide a list of foreign_keys, described as functions between entities. In our example worksIn : Employee -> Department means that from a Employee we can retrieve a Department. The concept is analogous to the one in relational databases, where in the Employee table we would have a column refering the Department table with a foreign key.

The list of path_equations describes equalities between parallel paths in the disgram of the schema. For example, manager.worksIn = worksIn means that using the manager foreign key and then the worksIn one, it is the same as going directly through the worksIn one.

The following list of attributes describes the data constituting the single entities. In our example, the Employee entity would have three attributes first, last and age, the first two being of type String, and the third of type Integer (the types come from the MyTypeSide Typeside). In a relational database analogy, attributes correspond to columns containing data.

Categorical interpretation

A schema tries to describe the concept of finitely presented category.

The idea goes more or less as follows. From a graph, where vertices correspond to entities and edges correspond to foreign keys, we can build a free category, where objects are the vertices of the graph and morphisms are paths on the graph.

Then we can state that some parallel (i.e. they have the same origin and the same destination) paths in the category are actually equal, imposing some conditions on the free category and actually going to work in a quotient category.

In this setting, entities correspond to objects of the category, foreign_keys correspond to morphisms and path_equations correspond to equalities between paths which need to be satisfied.