For details on SQLITE, see: http://sqlite.org/index.html.
Schemas and views are the main SQL data-modeling components used to represent content stored in a MarkLogic Server database to SQL clients. Schemas and views are created in memory from schema and view specifications, which are XML documents stored on MarkLogic Server in the Schemas database in a protected collection.
A schema is a naming context for a set of views and user access to each schema can be controlled with a different set of permissions. Each view in a schema must have a unique name. However, you can have multiple views of the same name in different schemas. For example, you can have three views, named ‘Songs,' each in a different schema with different protection settings.
A view is a virtual read-only table that represents data stored in a MarkLogic Server database. Each column in a view is based on a range index in the content database, as described in Columns and Range Indexes. User access to each view is controlled by a set of permissions.
Each view has a specific scope that defines the documents from which it reads the column data. The view scope constrains the view to a specific element in the documents (localname + namespace) or to documents in a particular collection. The figure below shows a schema called ‘main' that contains four views, each with a different view scope. The view 'My Songs' is constrained to documents that have a
song element in the
my namespace; the view 'Your Songs' is constrained to documents that have a
song element in the
your namespace; the view 'Songs' is constrained to documents that are in the
http://view/songs collection, and the view 'Names' is constrained to documents that have a
name element in the
As described above, schemas and views are stored as documents in the schema database associated with the content database for which they are defined. The default schema database is named ‘Schemas.' If multiple content databases share a single schema database, each content database will have access to all of the views in the schema database.
For example, in the figure below, you have two content databases, Database A and Database B, that both make use of the Schemas database. In this example, you create a single schema, named ‘main,' that contains two views, View1 and View2, on Database A. You then create two views, View3 and View4, on Database 3 and place them into the ‘main' schema. In this situation, both Database A and Database B will each have access to all four views in the ‘main' schema.
The range indexes that back the columns defined in views 1, 2, 3, and 4 have to be defined in both content databases A and B for the views to work. You will get a runtime error if you attempt to use a view that contains a column based on a non-existent range index.
A more 'relational' configuration is to assign a separate schema database to each content database. In the figure below, Database A and Database B each have a separate schema database, SchemaA and SchemaB, respectively. In this example, you create a ‘main' schema for each content database, each of which contains the views to be used for its respective content database.
|Column||A value in range index||column spec|
|Row||A sequence of range index values over the same document||view spec columns|
|Table/view||A document element or collection of documents||view spec|
|Database||A logical database||schema spec|
Each column in a view is based on a range index in the content database. Range indexes are described in the Range Indexes and Lexicons chapter in the Administrator's Guide. This section provides examples of what type of range index you might use to store your column data.
<book> <title subject="oceanography">Sea Creatures</title> <pubyear>2011</pubyear> <keyword>science</keyword> <author> <name>Jane Smith</name> <university>Wossamotta U</university> </author> <body> <name type="cephalopod">Squid</name> Fascinating squid facts... <name type="scombridae">Tuna</name> Fascinating tuna facts... <name type="echinoderm">Starfish</name> Fascinating starfish facts... </body> </book>
You can create columns based on an element range indexes for the
university elements without violating any of the 'relational behavior' rules listed in Guidelines for Relational Behavior. Creating a column based on an element range index for the
name element would violate the relational rules. However, you could use a path range index to create a column for the
/book/author/name element without violating the relational rules. You might also want to create a column based on an attribute range index for the
subject attribute in the
You may chose to model your data so that it is not truly relational. In this case, you could create columns based on a path range index for the
book/body/name element and