User Defined Data Types (UDT)

● SQL provides user-defined types (UDTs)

 to allow the creation of complex-structured objects

 to separate the declaration of a class/type from the
creation of a table

● A UDT may be specified in its simplest form using the

following syntax:
 CREATE TYPE TYPE_NAME AS OBJECT
(<component declarations>);
 Example for an UDT
CREATE TYPE address_t AS OBJECT (

street VARCHAR2(20),

city VARCHAR2(10),

state CHAR(2),

zip VARCHAR2(10));
 Example for an UDT
CREATE TYPE dept_t AS OBJECT (

deptno NUMBER,

deptname VARCHAR2(20),

address address_t );
 Object Table
● A table based on a single object serves as a data
type of each of the rows within that table.
● Such a table is referred to as an object table, and it
contains row objects. In other words, each row is an
object instance.
● Row object tables can be queried by using standard
SQL.
Creating a Table using UDT
CREATE TABLE table obj_dept OF dept_t (

CONSTRAINT const1 primary key(deptno));

DESC obj_dept;
 Object Table
● INSERT INTO obj_dept VALUES(500, 'Admin',
address_t('ABC st','Chennai','TN','600063'));
● INSERT INTO obj_dept VALUES(501, 'HR',
address_t('XYZ st','Mumbai','MH','405006'));
 Encapsulation
Observer and Mutator Functions
● You can encapsulate each attribute of structured types by
providing a pair of functions to access the attribute.
● an observer (get) function and a mutator (set) function.

● The observer function returns the current value of the

attribute; the mutator function sets the value of the attribute
to a value specified as a parameter.

FUNCTION fName(p PersonType) RETURNS VARCHAR(15)

RETURN p.fName;
Encapsulation: Observer and Mutator Functions
FUNCTION fName(p PersonType RESULT, newValue VARCHAR(15))

RETURNS PersonType

BEGIN

p.fName = newValue;

RETURN p;

END;
Member Functions in an Object
CREATE OR REPLACE TYPE person_typ AS OBJECT (

idno NUMBER,

name VARCHAR2(30),

phone VARCHAR2(20),

MAP MEMBER FUNCTION get_idno RETURN NUMBER,

MEMBER PROCEDURE display_details ( SELF IN OUT NOCOPY

person_typ ) );
 Defining Object Body
CREATE OR REPLACE TYPE BODY person_typ AS
MAP MEMBER FUNCTION get_idno RETURN NUMBER IS
BEGIN
RETURN idno;
END;
MEMBER PROCEDURE display_details ( SELF IN OUT NOCOPY person_typ ) IS
BEGIN
-- use the PUT_LINE procedure of the DBMS_OUTPUT package to display
details
DBMS_OUTPUT.PUT_LINE(TO_CHAR(idno) || ' - ' || name || ' - ' || phone);
END;
END;
 Constructor Functions
● A (public) constructor function is automatically defined to create new
instances of the type.

● The constructor function has the same name and type as the UDT, takes
zero arguments, and returns a new instance of the type with the attributes
set to their default value.

● User-defined constructor methods can be provided by the user to initialize a

newly created instance of a structured type.

● Each method must have the same name as the structured type but the
parameters must be different from the system-supplied constructor.

● In addition, each user-defined constructor method must differ in the number

of parameters or in the data types of the parameters.
 Constructor Functions
CREATE CONSTRUCTOR METHOD PersonType (fN VARCHAR(15),

lN VARCHAR(15), sx CHAR) RETURNS PersonType SELF AS RESULT

BEGIN

SET SELF.fName = fN;

SET SELF.lName = lN;

SET SELF.sex = sx;

RETURN SELF;

END;
 Constructor Functions
SET p = NEW PersonType();

SET p = NEW PersonType(‘John’, ‘White’, ‘M’);

Inserting NULLs for Objects in a Table
CREATE TABLE contacts (
contact person_typ,
contact_date DATE );

INSERT INTO contacts VALUES (

person_typ (NULL, NULL, NULL), '24 Jun 2003' );

INSERT INTO contacts VALUES (

NULL, '24 Jun 2003' );
 Object Identifier
● Every row object in an object table has an associated logical
object identifier (OID), which by default is a unique system-
generated identifier assigned for each row object.

● The purpose of the OID is to uniquely identify each row object in

an object table.
● To do this, Oracle implicitly creates and maintains an index on
the OID column of the object table.
● The OID column is hidden from users and there is no access to
its internal structure.
 Object Identifier
● Although OID values in themselves are not very meaningful, the
OIDs can be used to fetch and navigate objects.
● Note, objects that appear in object tables are called row objects
and objects that occupy columns of relational tables or as
attributes of other objects are called column objects.

● Oracle requires every row object to have a unique OID.

● SELECT object_id FROM obj_dept;

 Object Identifier
● The unique OID value may be specified to come from
the row object’s primary key or to be system-
generated, using either the clause OBJECT
IDENTIFIER IS PRIMARY KEY or OBJECT
IDENTIFIER IS SYSTEM GENERATED (the default)
in the CREATE TABLE statement.
● create table test_dept_obj of dept_t (deptno primary key)
OBJECT IDENTIFIER IS PRIMARY KEY;
● SELECT object_id FROM obj_dept;
 Reference Type
● Oracle provides a built-in data type called REF to encapsulate
references to row objects of a specified object type.
● In effect, a REF is used to model an association between two row
objects. A REF is a logical "pointer" to a row object.
● A REF can be used to examine or update the object it refers to
and to obtain a copy of the object it refers to.
● The only changes that can be made to a REF are to replace its
contents with a reference to a different object of the same object
type or to assign it a null value.
 Reference Type
● At an implementation level, Oracle uses object identifiers to
construct REFs.

● However, when two or more users are accessing the database

simultaneously and at least one is updating data, there may be
interference that can result in inconsistencies.
 Reference Type

CREATE TYPE empType AS OBJECT (

empNo VARCHAR2(4),

address AddressType,

dept REF dept_t);

 Reference Type

CREATE TYPE BranchType AS OBJECT (

branchNo VARCHAR2(4),

address AddressType,

manager REF StaffType);

 Collection Types
● For modeling multi-valued attributes and many-to-
many relationships, Oracle currently supports two
collection types:
 array types

 nested tables
 Array Types
● An array is an ordered set of data elements that are all of the
same data type.

● Each element has an index, which is a number corresponding to

the element’s position in the array.

● An array can have a fixed or variable size, although in the latter

case a maximum size must be specified when the array type is
declared.

● CREATE TYPE TelNoArrayType AS VARRAY(3) OF

VARCHAR2(13);
 Array Types
● The creation of an array type does not allocate space
but instead defines a data type that can be used as:
 the data type of a column of a relational table

 an object type attribute

 a PL/SQL variable, parameter, or function return type

 Array Types
● To model the requirement that a branch has up to three
telephone numbers, we could implement the column as an
ARRAY collection type:

telNo VARCHAR(13) ARRAY[3]

● We could now retrieve the first and last telephone numbers at

branch B003 using the following query:

SELECT telNo[1], telNo[CARDINALITY (telNo)] FROM Branch

WHERE branchNo 5 ‘B003’;

 Nested Tables
● A nested table is an unordered set of data elements
that are all of the same data type.

● It has a single column of a built-in type or an object

type.

● If the column is an object type, the table can also be

viewed as a multicolumn table, with a column for
each attribute of the object type.
 Nested Tables
CREATE TYPE NextOfKinType AS OBJECT (

fName VARCHAR2(15),

lName VARCHAR2(15),

telNo VARCHAR2(13));

CREATE TYPE NextOfKinNestedType AS TABLE OF

NextOfKinType;
 Nested Tables
CREATE TABLE Staff OF StaffType (
PRIMARY KEY staffNo)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE nextOfKin STORE AS NextOfKinStorageTable (
(PRIMARY KEY(Nested_Table_Id, lName, telNo))
ORGANIZATION INDEX COMPRESS)
RETURN AS LOCATOR;
 Nested Tables
● The rows of a nested table are stored in a separate
storage table that cannot be directly queried by the
user but can be referenced in DDL statements for
maintenance purposes.
 Row Types
• A row type is a sequence of field name/data type
pairs that provides a data type to represent the types
of rows in tables, so that complete rows can be stored
in variables, passed as arguments to routines, and
returned as return values from function calls.
• A row type can also be used to allow a column of a
table to contain row values.
• In essence, the row is a table nested within a table.
 Example for a Row Type
CREATE TABLE Branch (
branchNo CHAR(4),
address ROW(street VARCHAR(25),
city VARCHAR(15),
postcode ROW(cityIdentifier VARCHAR(4),
subPart VARCHAR(4))));

INSERT INTO Branch

VALUES (‘B005’, ROW(‘23 Deer Rd’, ‘London’, ROW(‘SW1’, ‘4EH’)));
UPDATE Branch
SET address = ROW (‘23 Deer Rd’, ‘London’, ROW (‘SW1’, ‘4EH’))
WHERE address = ROW (‘23 Deer Rd’, ‘London’, ROW (‘SW1’, ‘4EH’));
 Types of Methods
• The methods of an object type are classified as
 Member
 Static
 explicit comparison

• A member method is a function or a procedure that

always has an implicit or explicit SELF parameter as its
first parameter, whose type is the containing object.
 Types of Methods
• A static method is a function or a procedure that does
not have an implicit SELF parameter.
• Such methods are useful for specifying user-defined
constructors or cast methods
• Static methods may be invoked by qualifying the method
with the type name, as in typename.method().
 Types of Methods
• A comparison method is used for comparing instances
of object types.
• Two types of Comparison Methods:
 a map method uses Oracle’s ability to compare built-in types.
 an order method uses its own internal logic to compare two
objects of a given object type.
 It returns a value that encodes the order relationship.
 For example, it may return −1 if the first is smaller, 0 if they
are equal, and 1 if the first is larger.
 Types of Methods
• For an object type, either a map method or an order
method can be defined, but not both.
• If an object type has no comparison method, Oracle
cannot determine a greater than or less than relationship
between two objects of that type.
 Rules for Comparing Objects
• if all the attributes are nonnull and equal, the objects are
considered equal;
• if there is an attribute for which the two objects have
unequal nonnull values, the objects are considered
unequal;
• otherwise, Oracle reports that the comparison is not
available (null).
Subtypes and Supertypes
● SQL allows UDTs to participate in a subtype and
supertype hierarchy using the UNDER clause.
● A type can have more than one subtype but currently
only one supertype (that is, multiple inheritance is not
supported).
● A subtype inherits all the attributes and behavior
(methods) of its supertype and it can define additional
attributes and methods like any other UDT and it can
override inherited methods.
Subtypes and Supertypes
 Polymorphism
• Different routines may have the same name; that is, routine names
may be overloaded, for example to allow a UDT subtype to redefine a
method inherited from a supertype.

• No two functions in the same schema are allowed to have the same
signature, that is, the same number of arguments, the same data types
for each argument, and the same return type.

• No two procedures in the same schema are allowed to have the same
name and the same number of parameters.
Instance method invocation
● The mechanism for determining the appropriate
invocation of an instance method is divided into two
phases representing static analysis and runtime
execution.
Method Invocation – Static Analysis
• All routines with the appropriate name are identified (all remaining routines are
eliminated).
• All procedures/functions and all methods for which the user does not have
EXECUTE privilege are eliminated.
• All methods that are not associated with the declared type (or subtype) of the
implicit SELF argument are eliminated.
• All methods whose parameters are not equal to the number of arguments in the
method invocation are eliminated.
• For the methods that remain, the system checks that the data type of each
parameter matches the precedence list of the corresponding argument,
eliminating those methods that do not match.
• If there are no candidate methods remaining a syntax error occurs.
 Runtime Phase
● If the most specific type of the runtime value of the implicit
argument to the method invocation has a type definition that
includes one of the candidate methods
 then that method is selected for execution.

● If the most specific type of the runtime value of the implicit

argument to the method invocation has a type definition that
does not include one of the candidate methods
 then the method selected for execution is the candidate
method whose associated type is the nearest supertype of
all supertypes having such a method.
Creation of a subtable using the
UNDER clause
CREATE TABLE Staff OF StaffType UNDER Person;
• When we insert rows into the Staff table, the values of
the inherited columns are inserted into the Person table.
• Similarly, when we delete rows from the Staff table, the
rows disappear from both the Staff and Person tables.
• As a result, when we access all rows of Person, this will
also include all Staff details.
 Subtables
● There are restrictions on the population of a table
hierarchy:
 Each row of the supertable Person can
correspond to at most one row in Staff.
 Each row in Staff must have exactly one
corresponding row in Person.
 Subtables
● When a row is inserted into a subtable,
● then the values of any inherited columns of the table
are inserted into the corresponding supertables,
ascading upwards in the table hierarchy.
● For example, if we insert a row into PTStudentStaff,
then the values of the inherited columns are inserted
into Student and Staff, and then the values of the
inherited columns of Student/Staff are inserted into
Person.
 Subtables
● When a row is updated in a subtable, a procedure to the
previous one is carried out to update the values of inherited
columns in the supertables.
● When a row is updated in a supertable, then the values of
all inherited columns in all corresponding rows of its direct
and indirect subtables are also updated accordingly.
● As the supertable may itself be a subtable, the previous
condition will also have to be applied to ensure consistency
 Subtables
● When a row is deleted in a subtable/supertable,
the corresponding rows in the table hierarchy are
deleted.
● For example, if we deleted a row of Student, the
corresponding rows of Person and
Undergraduate/Postgraduate/PartTimeStudent/PT
StudentStaff are deleted.
Using a Reference Type to Define a Relationship

● The relationship between PropertyForRent and Staff is

modeled using the traditional primary key/foreign key
mechanism.
● However, we have used a reference type, REF(StaffType),
to model the relationship.
● The SCOPE clause specifies the associated referenced
table.
● REFERENCES ARE CHECKED indicates that referential
integrity is to be maintained (alternative is REFERENCES
ARE NOT CHECKED).
Using a Reference Type to Define a Relationship

● ON DELETE CASCADE corresponds to the normal

referential action.
● Note that an ON UPDATE clause is not required, as
the column staffID in the Staff table cannot be
updated.
Using a Reference Type to Define a Relationship
CREATE TABLE PropertyForRent(
propertyNo PropertyNumber NOT NULL,
street Street NOT NULL,
city City NOT NULL,
postcode PostCode,
type PropertyType NOT NULL DEFAULT ‘F’,
rooms PropertyRooms NOT NULL DEFAULT 4,
rent PropertyRent NOT NULL DEFAULT 600,
staffID REF(StaffType) SCOPE Staff
REFERENCES ARE CHECKED ON DELETE CASCADE,
PRIMARY KEY (propertyNo));
Use of ONLY to restrict selection
SELECT p.lName, p.fName FROM ONLY (Person) p
WHERE p.age > 65;

• Only the details of the specific instances of the

Person table, excluding any subtables.
Use of the dereference operator
• References can be used in path expressions that permit
traversal of object references to navigate from one row
to another.
• To traverse a reference, the dereference operator (–>) is
used.
SELECT p.staffID–>fName AS fName, p.staffID–>lName
AS lName
FROM PropertyForRent p WHERE p.propertyNo = ‘PG4’;
Use of the dereference operator
• To retrieve the member of staff for property PG4, rather
than just the first and last names, we would use the
following query instead:

SELECT DEREF(p.staffID) AS Staff

FROM PropertyForRent p WHERE p.propertyNo = ‘PG4’;
MULTISET Collection Type
• A multiset is an unordered collection of elements, all
of the same type, with duplicates permitted.
• Because a multiset is unordered there is no ordinal
position to reference individual elements of a
multiset.
• Unlike arrays, a multiset is an unbounded collection
with no declared maximum cardinality (although
there will be an implementation-defined limit).
MULTISET Collection Type
• Although multisets are analogous to tables, they are
not regarded as the same as tables, and operators
are provided to convert a multiset to a table
(UNNEST) and a table to a multiset (MULTISET).

nextOfKin NameType MULTISET

 NO SQL
• When people use the term “NoSQL database,” they
typically use it to refer to any non-relational database.

• Some say the term “NoSQL” stands for “non SQL” while
others say it stands for “not only SQL.”

• Either way, most agree that NoSQL databases are

databases that store data in a format other than
relational tables
NoSQL Database Features
• Each NoSQL database has its own unique features. At a
high level, many NoSQL databases have the following
features:
 Flexible schemas
 Horizontal scaling
 Fast queries due to the data model
 Ease of use for developers
 Types of NoSQL databases
• Document databases store data in documents similar to JSON
(JavaScript Object Notation) objects.
• Each document contains pairs of fields and values. The values can
typically be a variety of types including things like strings, numbers,
booleans, arrays, or objects.
• Key-value databases are a simpler type of database where each item
contains keys and values.
• Wide-column stores store data in tables, rows, and dynamic columns.
• Graph databases store data in nodes and edges. Nodes typically
store information about people, places, and things, while edges store
information about the relationships between the nodes.
 CAP Theorem
• CAP theorem or Eric Brewers theorem states that
we can only achieve at most two out of three
guarantees for a database:
 Consistency
 Availability
 Partition Tolerance
 CAP Theorem
• Here Consistency means that all nodes in the
network see the same data at the same time.
• Availability is a guarantee that every request
receives a response about whether it was successful
or failed. However it does not guarantee that a read
request returns the most recent write.The more
number of users a system can cater to better is the
availability.
 CAP Theorem
• Partition Tolerance is a guarantee that the system
continues to operate despite arbitrary message loss
or failure of part of the system.
• In other words, even if there is a network outage in
the data center and some of the computers are
unreachable, still the system continues to perform.
 CAP Theorem
• In a NOSQL distributed data store, a weaker
consistency level is often acceptable, and guaranteeing
the other two properties (availability, partition tolerance)
is important.

• Hence, weaker consistency levels are often used in

NOSQL system instead of guaranteeing serializability.

• In particular, a form of consistency known as eventual

consistency is often adopted in NOSQL systems
 MongoDB Data Model
• MongoDB documents are stored in BSON (Binary
JSON) format, which is a variation of JSON with
some additional data types and is more efficient for
storage than JSON.

• Individual documents are stored in a collection.

db.createCollection(“project”, { capped : true, size :

1310720, max : 500 } )
 MongoDB Data Model
• The first parameter “project” is the name of the
collection, which is followed by an optional document
that specifies collection options.

• In our example, the collection is capped; this means it

has upper limits on its storage space (size) and number
of documents (max).

• The capping parameters help the system choose the

storage options for each collection.
 MongoDB Data Model
• Each document in a collection has a unique ObjectId field,
called _id, which is automatically indexed in the collection
unless the user explicitly requests no index for the _id field.

• The value of ObjectId can be specified by the user, or it can be

system-generated if the user does not specify an _id field for a
particular document.

• System-generated ObjectIds have a specific format, which

combines the timestamp when the object is created (4 bytes, in
an internal MongoDB format), the node id (3 bytes), the process
id (2 bytes), and a counter (3 bytes) into a 16-byte Id value.
Example: Company Database
• In this example, the workers information is
embedded in the project document; so there
is no need for the “worker” collection.
• This is known as the denormalized pattern,
which is similar to creating a complex object
or an XML document.
• A list of values that is enclosed in square
brackets [ … ] within a document represents a
field whose value is an array.
• The _id values are user-defined, and the
documents whose _id starts with P (for
project) will be stored in the “project”
collection, whereas those whose _id starts
with W (for worker) will be stored in the
“worker” collection.
 Example: Company Database
• Another option is to use the design where worker references are
embedded in the project document, but the worker documents
themselves are stored in a separate “worker” collection.
Example: Company Database
• A third option would use a
normalized design, similar to First
Normal Form relations.

• The choice of which design option

to use depends on how the data
will be accessed.
MongoDB CRUD Operations
• Documents can be created and inserted into their
collections using the insert operation:
db.<collection_name>.insert(<document(s)>)

• The parameters of the insert operation can include

either a single document or an array of documents

• For read queries, the main command is called find,

and the format is:
db.<collection_name>.find(<condition>)
MongoDB CRUD Operations
• An update operation has a condition to select certain
documents, and a $set clause to specify the update.

• It is also possible to use the update operation to

replace an existing document with another one but
keep the same ObjectId
db.inventory.updateOne({ item: "paper" }, {$set:
{ "size.uom": "cm", status: "P" }, $currentDate:
{lastModified: true }})
MongoDB CRUD Operations
• The delete operation is called remove:
db.<collection_name>.remove(<condition>)
Hbase (Hadoop Database) Data Model
• The data model in Hbase organizes data using the
concepts of namespaces, tables, column families,
column qualifiers, columns, rows, and data cells.

• A column is identified by a combination of (column

family:column qualifier).

• Data is stored in a self-describing form by associating

columns with data values, where data values are
strings
 Hbase Data Model
• Hbase also stores multiple versions of a data item,
with a timestamp associated with each version, so
versions and timestamps are also part of the Hbase
data model.

• It is important to note that the use of the words table,

row, and column is not identical to their use in
relational databases, but the uses are related.
 Hbase - Tables and Rows
• Data in Hbase is stored in tables, and each table has a
table name.
• Data in a table is stored as self-describing rows.
• Each row has a unique row key
• Row keys are strings that must have the property that
they can be lexicographically ordered
• Characters that do not have a lexicographic order in the
character set cannot be used as part of a row key.
Column Families and Column Qualifiers
• A table is associated with one or more column families.
• Each column family will have a name, and the column
families associated with a table must be specified when
the table is created and cannot be changed later.
• When the data is loaded into a table, each column
family can be associated with many column qualifiers,
but the column qualifiers are not specified as part of
creating a table.
 Column
• The column qualifiers make the model a self-describing
data model because the qualifiers can be dynamically
specified as new rows are created and inserted into the
table.
• A column is specified by a combination of
ColumnFamily:ColumnQualifier.
Column Families and Column Qualifiers
• Basically, column families are a way of grouping
together related columns (attributes in relational
terminology) for storage purposes, except that the
column qualifier names are not specified during table
creation.

• Rather, they are specified when the data is created

and stored in rows, so the data is selfdescribing
since any column qualifier name can be used in a
new row of data.
Column Families and Column Qualifiers
• The concept of column family is somewhat similar to
vertical partitioning.

• Because columns (attributes) that are accessed

together because they belong to the same column
family are stored in the same files.

• Each column family of a table is stored in its own

files using the HDFS file system.
 Versions and Timestamps
• Hbase can keep several versions of a data item, along
with the timestamp associated with each version.
• The timestamp is a long integer number that represents
the system time when the version was created, so
newer versions have larger timestamp values.
• It is also possible for the user to define the timestamp
value explicitly in a Date format rather than using the
system-generated timestamp
 Cells
• A cell holds a basic data item in Hbase.

• The key (address) of a cell is specified by a combination of (table,

rowid, columnfamily, columnqualifier, timestamp).

• If timestamp is left out, the latest version of the item is retrieved

unless a default number of versions is specified, say the latest
three versions.

• The default number of versions to be retrieved, as well as the

default number of versions that the system needs to keep, are
parameters that can be specified during table creation.
 Namespaces
• A namespace is a collection of tables.
• A namespace basically specifies a collection of one or
more tables that are typically used together by user
applications
• It corresponds to a database that contains a collection
of tables in relational terminology.
 Hbase CRUD Operations
• Creating a table: create <tablename>, <column
family>, <column family>, …

• Inserting Data: put <tablename>, <rowid>, <column

family>:<column qualifier>, <value>

• Reading Data (all data in a table): scan <tablename>

• Retrieve Data (one item): get <tablename>,<rowid>

 Hbase CRUD Operations
• create ‘EMPLOYEE’, ‘Name’, ‘Address’, ‘Details’.

• put ‘EMPLOYEE’, ‘row1’, ‘Name:Fname’, ‘John’

• scan ‘EMPLOYEE’

• get ‘EMPLOYEE’, ‘row1’