Relational extensions:

object-relational, XML and JSON

José Miguel Gonźalez Ayala
jmgonzalezay@gmail.com

1 Abstract
The relational model has shown its versatility and
potential over years. For many years, any scenario
demanding data persistence was properly mapped
and implemented according to the relational
principles. Nowadays, we can say that the relational
model is not enough to model any kind of data or
environment. Relational extensions mainly focus on
incorporating complex objects into the database. In
this paper we will focus on tree of these extensions:
the object-oriented. XML and JSON.

2 Object-Oriented Database
Systems
The object oriented database systems (OODBS)
differ from relational databases in the use of internal
object identifiers or OIDs instead of candidate keys
and provide a natural integration between object-
oriented programing languages (OOPL) and stored
data. In the OODBS, the OOPL provides a uniform
natural way to access object- oriented data, whereas
relational database have to develop specific object-
oriented interfaces to communicate with SQL.
The characteristics that any OODBMS should
contain are:
• OO Data model: Data must be internally
organized according to the object-oriented
data model. Objects as means to represented
data and universally identified by an object
identifier (OID). Encapsulation, in terms of
function, is mandatory as well as traditional
object-oriented features such as inheritance
and extensibility, overriding/overloading
operators and late binding. All in all,
providing computational completeness.
• DBMS: A database management system
should provide persistence and therefore, it
must deal with issues such as secondary
storage management, concurrency, recovery
and ad hoc query facilities.
Object-Oriented Database System
2.1 Object-Relational Database
Systems
Although the OO paradigm provides a
revolutionary concept for data modeling, all the
efforts put in the relational technology should not
be put aside. Instead, relational databases should be
extended with object features to deal with OO
principles. According to this a ORDBMS should
provide the following features:
• User defined data types.
• Objects tables formed from user-defined
types.
• Hierarchies and support OIDs.
A model is composed of a data structure, a set of
integrity constraints and a set of operators to handle
data. As explained, the object-relational model is an
extension of the relational model and, thus, it relies
on it.
The operators used to manipulate the object-
relational data are those already available in the
relational algebra and, at a higher level of
abstraction, SQL. In this sense , thus, there is no
new contribution.

1
 2.4 Object Types and User
Defined Objects
In Oracle, a statement create type is used to create a
new data type (object type) that can be user as a
generic type to create a table using the statement
create table or to create another data type. The
general syntax for this create statements is:

Object-Relational Database Systems

Regarding additional extensions on the relational

data structure and integrity constraints, the SQL-99
introduced a set of elements (see previous section). An example is:
Unfortunately, there is no RDBMS in the market that
implements the standard. Every system has decided
to model the ORDM in this own way and none of
them is even close to what the standards states.
We will overlook on a specific relational system,
Oracle, and elaborate on the object-relational
features introduced to extend the relational data
structure.

Note that or replace is optional. By having this

2.2 The Object-Relational Model in
Oracle
In Oracle, the OODM mainly consists of user
defined types (UDTs), REFs and means to
implement collections. Oracle UDTs are different
from standard in that they resemble C++ or Java
classes. Thus, they are not types, as proposed in the
SQL-99. REFs are rather similar to the standard
concept and collections are supported by means of
VARRAYS, similar to the array concept in the
standard, and nested tables, a new concept with no
correspondence in the standard.
2.3 User defined Types (UDTs)
In Oracle, structure type, also know as user defined
types, are layer of abstraction on top of relational
technology. Consequently, the object-related data
structures and integrity constraints are eventually
translated in terms of tables and columns. As a
general rule, object are translated as relation tables,
each object attribute as a column, but with the
following overheads:
• An extra column to store the mandatory OID
• Extra space to store NULL pointers
Oracle calls them object types to distinguish them
from traditional basic types.
additional phrase, an object with the same name
will automatically be replaced with the newest
version of the object type.
The create type … as object syntax tells Oracle it is
an object type. Thus, besides regular attributes it
contains two method headers in the form of a
function (get_id) and a procedure
(generate_full_name).
In this paper we do not intend to revisit the object-
oriented paradigm and thus, we will not get into
details when talking about object methods and class
properties, because the mechanism is similar to the
class mechanism found in most object-oriented
programing languages.
Nevertheless, find below an example of how to
define methods in Oracle. It uses the create type
body statement, which must be used to define the
member methods (procedures and functions)
specified in the object definition. The syntax is as
follows:
For example:

2

The create type body … as is used to define those
type of methods (functions and procedures) declared
in the fullname object type definition.
Now, we can use this type as any other type. For
example:
Artist automatically inherits all methods and
attributes from person, and extends it with its own
attributes country and genre.
Inheritance is an interesting feature that provides
more semantics than object references or foreign
keys.
2.6 Polymorphism
Object views allow exploiting polymorphism
through type hierarchies. Thus, a polymorphic
expression can take the declared type or any of its
subtypes as values.
For example, suppose we had the following
relational table:

In this example, the fullname type is nested in the

person type that, in turn, is nested in the release
type.
Now, we can create a table containing such type as
an attribute:

First, we must create an object type mapping the

relational data we want to manipulate mirroring the
object-oriented features. For example:

2.5 Inheritance
The under clause can be used to define subtypes.
The syntax is as follows:

We can now create an object-view mapping the

desired relational data. The general syntax is as
follows:

By definition, subtypes inherit the features of the

parent type and extend its definition with new Where name is the view name and type is an
attributes and / or methods (possibly redefining existing type and the select statement maps the
methods inherited). Furthermore, we can define it as relational data onto the type specified. For
FINAL / NOT FINAL (so it cannot be extended with example:
any subclass) or INSTANCIABLE / NOT
INSTANCIABLE (whether it is an abstract type or
not). For example, suppose we want to extend the
person object type previously defined as follows:

3
2.7 References between Objects object-oriented programing languages.

REFs are essential mechanism to reference objects The general syntax to define VARRAYs is as
and therefore, a basic tool to enforce integrity follows:
constraints, like foreign keys in the relational model.
The main differences between both concepts are: Where name is the name of the new VARRAY
• Foreign key points to primary or candidate type, limit is the number of elements this collection
keys, whereas REFs point to objects. can contain and finally, after the OF keyword, we
must specify a built-in datatype or user-defined
• In the object-relational model dangling type this collection is made of.
REFs are allowed (it means that the pointed
object could no longer exists). However, a For example:
foreign key is never dangling and guarantees
that the candidate key pointed does exists.
The REF type allows referencing objects and it is
implemented as an object pointer. This type contains:
• The OID of the referenced object-oriented. Alternatively, we could create the song object type
• The OID of the table or view containing and declare a VARRAY of songs:
that object.
REFs can be defined as scoped or unscoped ones.
Scope REFs are strongly typed and point to an object
table. Oppositely, the pointed object type is unknown
for unscoped REFs.
For example, consider yet another possibility to
model the song and artist types:

2.8.2 Nested Tables

A interesting feature of the Oracle ORDM is that
the type of a column can be a table-type. That is a
value of an attribute in one tuple can be an entire
relation. Nested table are defined as follows:

In this example, a type artist is created and referred

from the relational table storing singles. Thus, to fill
the REF attribute properly, we use the REF keyword.
2.8 Collections
Oracle provides two types to support collections: the
VARRAY and nested tables. While the first one
nicely suits the ARRAY type, nested tables happen
to be much more interesting and provide new and
powerful alternatives.
Where name is the name of the table containing the
NESTED TABLE columns. This table defined a set
of attribute , some of them being nested tables. To
define a nested table we need to previously create
an object table. Now, we simply have to provide a
column name of that object table type. Later, we
must specify that this NESTED TABLE column is
stored in a relation whose name is provided after
the STRORE AS keywords. For example:

2.8.1 Varray
A Varray is an ordered collection of elements where
each element is associated to an index, in other
words, it maps the traditional array concept of

4
Nested tables can have any number of elements
(unlike VARRAYs, which require a maximum
number of elements at definition time) and they are
handle as an ordinary table. We can use triggers,
index or any statement available for regular tables.
For example we can create index over it: If we use the object relational extensions, which
supports inheritance using the under keyword, we
can create Student and Staff subclasses under the
superclass.

Nested tables represent a powerful tool and provide

an alternative to store objects., which open a whole
new bunch of alternatives.

2.9 Case study: inheritance

implementation
The concept of inheritance, where an object or a
relation inherits the attribute of another object, is not
supported in the relational model. The
implementation of an inheritance relationship is
established using primary-key and foreign-key
relationships in order to simulate the relationship
between a superclass and its subclasses.
The following figure shows an inheritance
relationship

2.10 Case study: association

In order to simulate the inheritance, Student and
Staff will carry the primary key of the superclass,
Person, in their relational tables. The primary key of
the superclass becomes a foreign key in the
subclasses.
relationships
Relational data structures can be related to the
concepts of sets through the fact that tuples are not
in any particular order and duplicate tuples are not
allowed. Therefore, the implementation of
association relationships with a set semantic into
object-relational tables is identical to the well-
known transformation of many-to-many or one-to-
many relationships from relational modeling to
relational tables.
In relational modeling, many-to-many relationships
are converted into tables in which the primary key
is a composite key obtained from the participating
entities. Should there be any attributes of the
relationships, these will automatically be added to
the tables that represent the many-to-many
relationships.
Likewise, in object modeling, if a class has a set

5
relationship with another class and the inverse
relationship is also a set, the transformation of such
an association is identical to the many-to-many
relationships’ transformation from relational
modeling to relational tables where a table is created
to represent the set relationship. This transformation
strategy also enforces that each element within a set
cannot be duplicated, which is realized by the Implementation of one-to-one using a primary-key
implementation of the composite primary key of the and foreign-key relationship :
relationship tables.
In one-to-many relationships, as in relational
modeling, the primary key of the one side is copied
to the many side to become a foreign key. In other
words, there is no special treatment necessary for the
transformation of association relationships having a
set semantic.
In Oracle there are two ways of implementing an Implementation of many to many using object
association relationship: by primary-key and foreign- references :
key relationships and by object references. Each of
these methods will be described as follows.

diagram for association relationships

Implementation of many to many using a primary-

key and foreign-key relationship:
Implementation of one to many using object
references :

Implementation of one to many using a primary-key

and foreign-key relationship :
Implementation of one to one using object
references :

6
 Note that there is neither the concept of a primary
key nor the integrity constraint in the part nested
table. For example, if a particular HD controller is
used by another HD from the whole table, then all
the details of the HD controller will be written
again as a separate record within the nested table.

2.11 Case study: Aggregation Nested table also facilitates multilevel and thus can
Relationships using the be used for implementing a multilevel aggregation
Nesting Technique relationship. A PC is an aggregation of several
HDs, and a HD is an aggregation of several HD
Aggregation is a tightly coupled form of association. controllers. In this case, the inner table is a nested
The main difference between aggregation and table of HD controller, and the outer table is a
association is the underlying semantic strength. nested table of HD. The implementation of this
While an aggregation forms a method of aggregation is:
organization that exactly maps human thinking, an
association is a mere mapping between objects in an
application. Aggregation is a composition or part-of
relationship, in which a composite object (whole)
consists of other component objects (parts).
In an aggregation relationship, in which one whole
can have many parts associated with it through a
part-of relationship, the entire part-of relationship is
viewed as one composition, not several association
relationships.

This is not a standard table; no additional

constraints can be attached to this table and no
direct access can be performed to this table without
going through the Hard Disk table.
aggregation relationship

7
2.12 Case study: objects views
Object views are used to access relational data using
object-related features, in this way we can access
objects that belong to an object view in the same
way if they were objects in an object table. For
example we have a heap table with the following
data and structure:
We define an object type to represent the rows of the
table in the object view:
An finally, we create a view with a query that
defines which data of the relational table will
contain the view. Also I specify the OID based on
one of the attributes of the underlaying data, to allow
REFS to the objects (rows) of the object view:
8
The object view looks to user like an object table
whose underlying type is comics_t. Each row
contains an object of type comics_t. As yo can see,
each row has a unique object identifier:
3 The XML extension
Recently, XML has also been proposed as a
possible model for data storage and retrieval,
although only a few database systems based on
XML have been develop so far. This paper focus
on describing the XML data model and it
associated languages, and how data extracted from
relational databases can be formatted as XML
documents.
The XML data model is based on hierarchical
structures as compared to the flat relational model
structures. we focus on the structures of XML
documents and the languages for specifying the
structure of these documents such as DTD and
XML Schema.
3.1 XML Fundamentals
XML stands for eXtensible Markup Language and
it is a very flexible text format derived from
SGML. It provides a set of rules for encoding
documents in a machine-readable form. Thus, each
individual piece of information is marked up (a
marker show the meaning of the associated data)
with a tag attached that is called element. This
elements consist of a start tag, text and a end tag.
XML represents data in text format and encloses
data items between user understandable and
meaningful tags. For example, the address of a
student is described as follows:
The data item in this case is “123 Main Street,
Atlanta, GA 30002” and is enclosed between the
start tag <address> and the end tag </address>. The
tag name “address” is user-defined and is descriptive
of the data item that it is enclosing.
The entire string starting with the start tag, including
the data item, and ending with the end tag is referred
to as an XML element. XML elements can be nested
as in the following example which includes sub-
components of the address:
Here, the <address> XML element has four sub-
elements, <street>, <city>, <state>, and <zipcode>.
Notice that all sub-elements are completely enclosed
with the start and end tags of the main element.
Occasionally, there is a need to have an element
without any contents. Such elements are called
empty elements. For example, the following empty
element may be used in a situation where the phone
number is not known:
The above empty element can also be represented in
the shorter notation:
There is no restriction in XML for repeating the sub-
element tags. So, a list of phone numbers for an
individual can be described as follows:
In addition to the element syntactic structure, XML
also provides an additional mechanism to describe
9
data. XML attributes are name-value pairs that are
introduced in the start tag of elements. The
following is an example of attributes in use within
an element description:
Here, the cost of some item is being described. The
cost (25.20) is being described using an XML
element <cost>. The start tag includes a name-
value pair currency=”USD” indicating that the
currency of the cost is in US dollars. In contrast to
XML elements, attribute names cannot be repeated
within the same start-tag. So, the following will be
an error:
XML syntax also allows mixing of elements and
text outside of the element context. This is a left
over feature from the document world in mark up
languages are still used. For example, consider the
following XM fragment code:
In this description of a person, the text “This is my
cousin!” appears outside of the context of any
element of sub-element. Such annotations are
usually ignored by XML parsers. Comments in
XML are introduced as follows:
XML documents usually begin with a version
statement as follows:
The CDATA construct allows one to include special
characters such as the < or > symbols as part of
text. For example, to include XML tags as part of
the content of elements, the CDATA construct can
be used as follows:
3.1.1 Well-formed XML
Following with this basic syntax, the XML
specification defines an XML document as a text
that is well formed. It satisfies a list of syntax rules
provided in the specification. The main rules that a
well-formed XML document should satisfy are:
• It contains only properly encoded legal
Unicode characters.
• None of the special syntax characters such
as '<' and '&' appear except when performing
their mark-up delineation roles.
• The beginning, end and empty-element tags
that mark the elements are correctly nested,
with none missing and none overlapping.
Unfortunately, you have also used the element
name nuclyanalitics in your XML but for a
different purpose and thus with a different
structure. In order to avoid these name clashes,
XML incorporate naming spaces. Using an XML
Namespace resolves name collisions or ambiguities
in an XML document.
These alias are usually defined at the beginning of
the XML document thought they can be defined for
an element and apply to that element and all its
subelements. Aliases are defined using a special
attribute that starts with xmlns: and then the alias.

• The element tags are case-sensitive; the The value of the attribute is the URI it refers to.
beginning and end tags must match exactly. Finally, there is the default namespace, which is
defined using the xmlns attribute and applies to all
• Tag names cannot contain any of the elements that do not explicitly define their
characters " # $ % & ' ( ) * + , / ; < = > ? @ [ namespace. Elements and attributes define their
\ ] ^ ` { | } ~, nor a space character, and namespace by prepending the namespace alias plus
cannot start with - . or a numeral. ':' to the element or attribute name
• There is a single root element that contains
all the other elements, which might be
nested. Altogether, the XML syntax encodes
an underlying tree data structure.
A well-formed XML document is syntactically
correct. This allows it to be processed by generic
processors that traverse the document and create an
internal tree representation.

3.1.2 Namespaces
namespace declaration
A namespace is identified by a URI (Uniform
Resource Identifier) and as long as you define a
unique URI for your namespace, you can then use 3.1.3 Full XML example
whatever element and attribute names inside it. The
best way to get a unique URI is to use part of your One possible XML representation of the
organization or own domain name to build a custom COMPANY database is discussed in this section.
URL for your namespace. For instance, for someone The overall structure of the XML document is as
who works in NULCI it is possible to pick the follows:
nucliexperts.com domain name and build a URI for
the namespace like:
http://www.nucliexperts.com/subjects/adb/ ns/custom#

name ambiguity
Let's imagine that you want to combine a piece of
XML with another piece you have generated.
The document contains three main sections, one
each for the list of departments, employees, and
projects. Each section describes the individual

10
entities within the classes along with relationships
with other entities.
The <departments> element contains one or more
<department> elements that describe the individual
department along with its relationships with other
entities. The following XML code fragment shows
the details for department 5:

The <projects> element contains one or more

<project> elements that describe the individual
As can be seen, the department element contains an projects along with its relationships with other
attribute dno and several sub-elements, each entities. The following XML code fragment shows
describing either a simple attribute or a relationship. the details for project 1:
The <dname> sub-element describes the department
name, the <locations> sub-element encloses one or
more <location> elements, each describing a
department location. The <manager>, <employees>,
and <projectsControlled> sub-elements describe
relationships with other entities and all these are
represented by XML attributes.
The <employees> element contains one or more
<employee> elements that describe the individual
employees along with its relationships with other
entities. The following XML code fragment shows We will use more XML description of database in
the details for employee 333445555: subsequent sections to discuss XML querying.

3.1.4 Storing XML documents in

Oracle XML DB
Oracle XML DB is the name for a set of Oracle
Database technologies that provide XML support
by encompassing both SQL and XML data models
in an interoperable manner. The Oracle XML DB
Repository is the component of Oracle Database
that handles XML data. It contains resources,
which can be either folders or files. Each resource
is identified by a path and name. In the case of
files, their content can be XML data but need not
be.
One key decision to make when using Oracle XML
DB for persisting XML documents is whether to
use structured or unstructured storage:
• Unstructured storage provides rightest

11
 throughput when inserting and retrieving application domain.
entire XML documents. It also provides the
Although XML DTD is quite adequate for
greatest degree of flexibility in terms of the
specifying tree structures with required, optional,
structure of the XML that can be stored.
and repeating elements, and with various types of
XML is stored using CLOB, BLOB, BFILE
attributes, it has several limitations:
or VARCHAR2.
1. The data types in DTD are not very
• Structured storage is based on the general.
XMLType, a new type that makes database
aware that XML is being stored. It has a 2. DTD has its own special syntax and thus
number of advantages, including optimized requires specialized processors. It would be
memory management, reduce storage advantageous to specify XML schema
requirements and B-tree indexing. These documents using the syntax rules of XML
advantages are at cost of a greater itself so that the same processors used for
processing overhead during ingestion and XML documents could process XML
retrieval and reduce flexibility in terms of schema descriptions.
the structure of the XML. 3. All DTD elements are always forced to
To load into Oracle XML DB using an unstructured follow the specified ordering of the
approach: document, so unordered elements are not
permitted.

To load into Oracle XML DB using the structured

approach:
These drawbacks led to the development of XML
schema, a more general but also more complex
language for specifying the structure and elements
of XML documents.

3.2.1 Basics concepts

3.2 XML Schema
The XML schema language is a standard for
An XML defines a set of new names called
specifying the structure of XML documents. It uses
vocabulary, if a XML document is well formed and
the same syntax rules as regular XML documents,
it is structured following one of these XML
so that the same processors can be used on both. To
vocabularies, it is said to be a valid XML document.
distinguish the two types of documents, we will use
There are two main ways of defining XML
the term XML schema document for a document
vocabularies:
that specifies an XML schema.
• DTD (Document Type Definition): this is XML schema is based on the tree data model, with
the first standardized way of doing. It is elements and attributes as the main structuring
simpler but less expressive so mos of the concepts. However, it borrows additional concepts
modern standards based on XML, which from database and object models, such as keys,
define XML vocabulary to build meaningful references, and identifiers
documents in the particular application
domain of the standard, use the next
alternative instead. 3.2.2 Declaration
• XML Schema: this second option is more An XML schema is a document with an opening
complex than DTD but it is more expressive root element like:
and thus allows defining vocabularies that
better capture the particularities of the

12

The namespace prefix has no significance and can be
anything that you choose. The prefixes in the
preceding examples are most commonly used. An
XML Schema declares vocabularies; therefore, the
optional targetNamespace attribute helps to uniquely
identify a vocabulary, and requires a matching
namespace declaration to be used with references to
declarations within the same XML Schema.
3.2.3 Declaring an element
The XML Schema language uses the <element>
component to declare an XML element. The
attributes of <element> are:
• The name attribute for specifying the tag
name for the element
• The type attribute to specify the content
type, or type of data contained in the
element
• The ref attribute for referencing global type
names in the schema document
• The form attribute that can be used to
override the elementFormDefault attribute
value used in the <schema> element
• The minOccurs attribute that specifies the
minimum number of times the element must
appear in the XML instance document. A
value of zero indicates that the element is
optional.
• The maxOccurs attribute that indicates the
maximum number of times the element can
appear in the XML instance document. A
value of unbounded means that there is no
limit to the number of element occurrences.
• The default attribute that specifies a default
value for the element if it does not appear in
the XML instance document. The default is
not applied to an element with a value.
• The fixed attribute indicates that the content
of the element must be equal to this value.
13
• string type
• int type
• decimal type
• others (boolean, float, integer ...)
examples are:
3.2.3 Declaring a simple types
The <simpleType> declaration includes atomic or
built-in types provided by the XML Schema
Recommendation. An example of a built-in-type is
integer, which requires numeric data in a document
instance. A <simpleType> declaration can be:
• For a derived type that extends a built-in or
other simpleType declaration .
• For an element that contains data, and may
not contain attributes or child elements .
• Refined by using facets or properties .
In the example:
• A <simpleType> called empid is declared
as a <restriction> type
• The <restriction> uses the base attribute to
identify the built-in type from which the
<simpleType> is derived
• The base type is positiveInteger,
representing non-negative values
• The maxInclusive facet sets a maximum
value of 1000 for this data type
• The <element> for employee_id references
the empid <simpleType> as its data type,
restricting employee_id elements to
contain positive integers less than or equal
to 1000.
3.2.4 Declaring a complex types
A <complexType> declaration is a powerful
construct that enables you to create simple to
complex structures. A <complexType> that is
declared globally in the XML Schema document
must be identified by a name attribute. A locally
declared <complexType> is called an anonymous
complex type, where the name attribute is not
required. Setting the mixed attribute to true allows
both text and element content to be included in the
content for the element.
The <complexType> declaration specifies different
content models that enable the content to be mixed,
empty, or contain element hierarchies. A content
model can contain:
• Simple content, for data without child
elements .
• A <sequence> declaration, to specify an
ordered sequence of child elements .
• A <choice> declaration, for providing a
choice of child elements .
• A reference to a global <group>, for reusing
a group of elements to define the complex
type structure .
• An <all> declaration, to allow all elements
in the content model to be used in any
order .
3.2.5 Registering an XML schema in
Oracle XML DB
An XML schema must be registered with the Oracle
XML DB before it can make use of it. To register an
XML schema, the user should call PL/SQL
procedure DBMS_XMLSCHEMA.register_schema:
When XML schemas are registered with Oracle
XML DB, a set of default tables are created and used
to store XML instance documents associated with
the schemas. These documents can be viewed and
accessed in Oracle XML DB Repository.
XMLType is a native server datatype that lets the
database understand that a column or table contains
XML. This similar to the way that date and
timestamps datatypes let the database understand
that a columns contains a date. Datatype XMLXType
also provides methods that allow common
operations such as XML schema validation.
14
XMLType tables or columns can be constrained
and conform to an XML schema. This has several
advantages:
• The database will ensure that only XML
documents that validate against the XML
schema can be stored in the column or
table.
• Since the contents of the table or column
conform to a known XML structure, Oracle
XML DB can use the information
contained in the XML schema to provide
more intelligent query and update
processing of the XML.
• Constraining the XMLType to an XML
schema provides the option of storing the
content of the document using structured-
storage techniques.
Structured storage decomposes the content of the
XML document and stores it as a set of SQL
objects rather than simply storing the document in
an unstructured way, such as text in a CLOB.
3.3 XML Languages
There have been several proposals for XML query
languages, and two query language standards have
emerged. The first is XPath, which provides
language constructs for specifying path expressions
to identify certain nodes (elements) or attributes
within an XML document that match specific
patterns. The second is XQuery, which is a more
general query language. XQuery uses XPath
expressions but has additional constructs. We give
an overview of each of these languages.
3.3.1 XPath
An XPath expression generally returns a sequence
of items that satisfy a certain pattern as specified by
the expression. These items are either values (from
leaf nodes) or elements or attributes. The most
common type of XPath expression returns a
collection of element or attribute nodes that satisfy
certain patterns specified in the expression.
The names in the XPath expression are node names
in the XML document tree that are either tag
(element) names or attribute names, possibly with
additional qualifier conditions to further restrict the
nodes that satisfy the pattern.
Two main separators are used when specifying a
path: single slash (/) and double slash (//). A single
slash before a tag specifies that the tag must appear
as a direct child of the previous (parent) tag, whereas
a double slash specifies that the tag can appear as a
descendant of the previous tag at any level.
XML path model
XPath is an important specification language used to
traverse and locate nodes in an XML document. It is
not a full-fledged query language, but is used to
specify a set of nodes in the XML tree structure, very
much like the file specification in the directory
hierarchy of a Unix operating system. XPath
expressions are used in other query languages such
as XQuery.
3.3.2 XQuery
XQuery is the official W3C (World Wide Web
Consortium) standard query language for XML data.
It is a high-level functional language for formulating
ad hoc queries on XML data.
XPath allows us to write expressions that select
items from a tree-structured XML document.
XQuery permits the specification of more general
queries on one or more XML documents. The typical
form of a query in XQuery is known as a FLWR
expression, which stands for the four main clauses of
XQuery and has the following form:
FOR <variable bindings to individual nodes
(elements)>
LET <variable bindings to collections of
nodes (elements)>
WHERE <qualifier conditions>
RETURN <query result specification>
There can be zero or more instances of the FOR
clause, as well as of the LET clause in a single
XQuery. The WHERE clause is optional, but can
appear at most once, and the RETURN clause must
appear exactly onc e. Let us illustrate these clauses
with the fol- lowing simple example of an XQuery:
15
1. Variables are prefixed with the $ sign. In
the above example, $d, $x, and $y are
variables.
2. The LET clause assigns a variable to a
particular expression for the rest of the
query. In this example, $d is assigned to the
document file name. It is possible to have a
query that refers to multiple documents by
assigning multiple variables in this way.
3. The FOR clause assigns a variable to range
over each of the individual items in a
sequence. In our example, the sequences
are specified by path expressions. The $x
variable ranges over elements that satisfy
the path expression $d/company/
project[projectNumber = 5]/projectWorker.
The $y variable ranges over elements that
satisfy the path expression $d/company/
employee. Hence, $x ranges over
projectWorker elements, whereas $y ranges
over employee elements.
4. The WHERE clause specifies additional
conditions on the selection of items. In this
example, the first condition selects only
those projectWorker elements hat satisfy
the condition (hours gt 20.0). The second
condition specifies a join condition that
combines an employee with a
projectWorker only if they have the same
ssn value.
5. Finally, the RETURN clause specifies
which elements or attributes should be
retrieved from the items that satisfy the
query conditions. In this example, it will
return a sequence of elements each
containing <firstName, lastName, hours>
for employees who work more that 20
hours per week on project number 5.
XQuery has very powerful constructs to specify
complex queries. In particular, it can specify
universal and existential quantifiers in the
conditions of a query, aggregate functions, ordering
of query results, selection based on position in a
sequence, and even conditional branching. Hence,
in some ways, it qualifies as a full-fledged
proramming language.
3.4 Case study: XPath and XQuery
to retrieve data from XML
documents
1. For the implementation, we will first create a
schema validation of XML documents
(XSD) for the purpose of the whole XML
document structure meets certain conditions.
An XML schema must be registered with the
Oracle XML DB before it can make use of
it. To register an XML schema, the user
should call PL/SQL procedure
DBMS_XMLSCHEMA.register_schema:

4. Finally we can use XPATH and XQUERY

As you can see, the schema is registered.
to query the data from a SQL session.
XPATH is a language that allows us to
construct expressions in order to go a XML
document and deliver the nodes of the
document containing the information we
want. Using XPATH We can see the price
of all orders:

2. Now, we need to create a table to store the

XML data.
Or we can see the description of the articles
with cod equal 2.

3. We insert an XML document that meets the

specification of XSD schema defined. The
insert statement is an standard insert that
containing a valid XLM document.

16
 XQuery is a query language designed to JSON includes a way to describe arrays. So, the
work with collections of XML data, which JSON text might look like this:
provides tools to extract and manipulate
information from XML documents
Using XQUERY we want to know
which article is more expensive than 100 €

The squiggly brackets surround the entire object.

We see the typical form of a query with the
FLWR expression.
4 JSON data model
Like XML, JSON can be thought of as a data model.
An alternative to the relational data model that is
more appropriate for semi-structured data.
Now among the three models - the relational model,
XML, and JSON - JSON is by a large margin the
newest, and it does show there aren't as many tools
for JSON as we have for XML and certainly not as
we have for relational.
JSON stands for Javascript object notation. Although
it's evolved to become pretty much independent of
Javascript at this point. JSON was designed
originally for what's called serializing data objects.
That is taking the objects that are in a program and
sort of writing them down in a serial fashion,
typically in files. One thing about json is that it is
human readable, similar to the way xml is human
readable and is often use for data interchange.
Also, just more generally, because json is not as rigid
as the relational model, it's generally useful for
representing and for storing data that doesn't have
rigid structure that we've been calling semi-
structured data.
4.1 A Simple Example: A List of
Movies
Let’s say we wanted to store the first five Friday the
13th movies for later access. In most programming
languages, an array would be appropriate. Arrays
hold an ordered collection of similar data.
Whereas an array holds a list in a certain order, an
object is an unordered collection. Objects hold
attributes that point to values. A value could be one
number or a single line of text. Or, a value can be
an array, like it is here.
Our object has one attribute, named “movielist.”
Attributes are in quotes, because they are a string
that holds the name of the attribute. After the
quotes comes a colon, which separates the attribute
from the value. The square brackets contain an
array, which holds our ordered list of other values.
4.2 Comparing JSON and the
relational model
The relational model is based on tables. We set up
structure of table, a set of columns, and then the
data becomes rows in those tables. JSON is based
instead on sets, the sets of label pairs and arrays
and they can be nested.
One of the big differences between the two models,
of course, is the scheme. So the Relational model
has a Schema fixed in advance, you set it up before
you have any data loaded and then all data needs to
confirm to that Schema. Jason on the other other
hand typically does not require a schema in
advance.
In fact, the schema and the data are mix together
just like an xml, and this is often referred to as self-

17
describing data, where the schema elements are
within the data itself. And this is of course typically
more flexible than the to a model.
But there are advantages to having schema? as well,
definitely. As far as queries go, one of the nice
features of the relational model is that there are
simple, expressive languages for clearing the
database. In terms of json, although a few New
things have been proposed; at this point there's
nothing widely used for querying Jason data.
One aspect of the relational model is that it's an
unordered model. It's based on sets and if we want to
see relational data in sorted order then we put that
inside a query. In JSON, we have arrays as one of
the basic data structures, and arrays are ordered.
4.3 Comparing JSON and XML
Both of them are very good for putting semi-
structured data into a file format and using it for data
interchange. And so because there's so much overlap
in what they're used for.
XML is in general, a little more verbose than Jason.
So the same data expressed in the 2 formats will tend
to have more characters in XML than JSON and you
can see that in the following example:
XML being a bit more verbose largely has to do
18
actually with closing tags, and some other features.
Second is complexity most people would say that
XML is a bit more complex than JSON. If you look
at the subset of XML that people really use, you've
got attributes, sub elements and text, and that's
more or less it. If you look at Json, you got your
basic values and you've got your objects and your
arrays.
Now let's turn to validity. And by validity, I mean
the ability to specify constraints or restriction or
schema on the structure of data in one of these
models, and have it enforced by tools or by a
system.
Specifically in XML we have the notion of
document type descriptors, or DTDs, we also have
XML Schema which gives us XSD's, XML Schema
Descriptors. And these are schema like things that
we can specify, and we can have our data checked
to make sure it conforms to the schema.
For JSON, there's something called JSON Schema.
And, you know, similar to XML Schema, it's a way
to specify the structure and then we can check that
JSON conforms
One of the original criticisms of relational database
systems is that the data structures used in the
database, specifically tables, didn't match directly
with the data structures and programming
languages.
So there had to be some manipulation at the
interface between programming languages and the
database system and that's the mismatch. So that
same impedance mismatch is pretty much present
in XML wherein JSON is really a more direct
mapping between many programming languages
and the structures of JSON.
Finally, let's talk about querying. JSON does not
have any mature, widely used query languages at
this point. for XML we do have XPath, we have
XQuery, we have XSLT. Maybe not all of them are
widely used but there's no question that XPath at
least and XSL are used quiet a bit. As far as Json
goes there is a proposal called Json path. It looks
actually quiet a lot like XPath maybe he'll catch on.
There's something called JSON Query. Doesn't
look so much like XML Query,
As conclusion we can say that JSON is most useful
with simple, structured data. XML is useful for
both structured and semi-structured data. JSON is
generally data-centric, not document-centric; XML
can be either. JSON is not a markup language; it is
designed only for data representation. XML is both
a document markup language and a data
representation language.
4.4 Case of study: JSON in Oracle
database
Oracle Database queries are declarative. You can
join JSON data with relational data. And you can
project JSON data relationally, making it available
for relational processes and tools. You can also
query, from within the database, JSON data that is
stored outside the database, in an external table.
Unlike XML data, which is stored using SQL data
type XMLType, JSON data is stored in Oracle
Database using SQL data types VARCHAR2,CLOB,
and BLOB. Oracle recommends that you always use
an is_json check constraint to ensure that column
values are valid JSON instances.
1. Creating the table hold JSON
2. With the table in place, it is possible to insert
data into the JSON column like any other
VARCHAR2 or CLOB column.
19
3. Querying JSON data
JSON data can be used in Oracle Database 12c.
Unlike relational data, can be stored, indexed, and
queried in the database without any need for a
schema that defines the data.
Oracle Database 12c supports JSON natively with
relational database features, including transactions,
indexing, declarative querying, and views.
5 Summary
In this paper we have introduced three relational
extensions; object-relational XML and JSON. Each
of these extensions tackles a precise problem but in
essence, they have the same objective: extend the
relational model to other areas where the relational
model does not naturally fit in.
Nowadays, things are changing with the arrival of
alternative non-relational solutions embraced under
the umbrella of what is known as NOSQL.
The NOSQL wave is somehow repeating the same
steps as the OODBSs or XML back in the 80s and
90s, and it claims that the relational model is not
the solution to every possible scenario . However,
the approach is subtly different, as NOSQL arises
as an alternative to relational databases, whereas
OODBSs claimed for replacing relational
databases.
6 Bibliography
• Object-oriented Oracle / Wenny Rahayu,
David Taniar and Eric Pardede 2006
• Object-Relational and XML Extensions,
Oscar Romero 2009
• XML and JSON data model, Jennifer
Widom 2011
• Oracle Database Online Documentation 11g
Release 1 (11.1) / XML DB Developer's
Guide 2009
• Manejando XMLType en Oracle Database
11gR2 a través del componente XDB,
Francisco Riccio 2013
• Oracle-base, JSON Data in Oracle Database
12c Release 1 (12.1.0.2) 2013
• Oracle Database Online Documentation 12c
Release 1 (12.1) / Application Development
2013

20