CUDL Language Semantics, Liven Up the FDB Data Model Nikitas N. Karanikolas, Maria Nitsiou, Emmanuel J.

Download Report

Transcript CUDL Language Semantics, Liven Up the FDB Data Model Nikitas N. Karanikolas, Maria Nitsiou, Emmanuel J.

CUDL Language
Semantics,
Liven Up the FDB Data
Model
Nikitas N. Karanikolas,
Maria Nitsiou,
Emmanuel J. Yannakoudakis
and Christos Skourlas
FDB framework
We have a new database framework that supports
dynamically evolving database environments and corresponding schemata,
allowing storage and manipulation of
variable length data,
a variable number of fields per record,
variable length records,
manipulation of authority records,
links between records and fields, and
dynamically defined objects (relations in the traditional sense)
multi-value fields
multi-attribute fields
a combination of the last two above
Eliminates completely the need for reorganisation at both logical and
internal levels
The structure of the FDB model allows easy schema evolution
FDB MODEL SCHEMA
The improved basic schema of the proposed framework has the
following form (note that primary keys are underlined):
•
•
•
•
•
Languages
Datatypes
(language_id, lang_name)
(datatype_id, datatype_name)
Messages
(message_id, language, message)
Entities
(frame_entity_id, title)
Tag_attributes
(entity, tag, title, occurrence, repetition,
authority, language, datatype, length)
• Subfield_attributes (entity, tag, subfield, title, occurrence,
repetition, language, datatype, length)
FDB MODEL SCHEMA (CONT.)
• Catalogue
(Entity, Frame_object_number,
Frame_object_label, Temp_stamp)
• Tag_data
(Entity, Frame_object, Tag, Repetition, Chunk,
Tdata)
• Authority_links
(From_entity, Auth_tag1, To_entity,
Auth_tag2, mn_data_loc)
• Subfield_data
(Entity, Frame_object, Tag, Tag_repetion,
Subfield, Subfld_Repetition, Chunk,sdata)
ONE database schema for any application
There are no
new tables for each new entity
Metadata of an FDB database
defining the project entity
Messages
Tag_attributes
Message_id Language Message
Entity
Tag
Project_
code
1
1
2
M
N
N
1
1
8
1
2
3
M
R
N
1
1
30
1
1
Projects
2
1
Title Occurrence Repetition Authority Language Datatype
Length
3
1
Title
1
3
4
M
N
N
1
2
NULL
4
1
Budget
1
4
5
M
R
N
1
6
NULL
5
1
Actions
…
…
…
…
…
…
…
…
…
6
1
Employee_
code
7
1
Action
8
1
Deadline
….
….
….
Entities
Subfield_attributes
Entity Tag Subfield Title Occurrence Repetition Language Datatype Length
1
4
1
6
M
R
1
1
8
1
4
2
7
M
N
1
1
40
Frame_entity_id
Title
1
4
3
8
M
N
1
5
NULL
1
1
….
….
….
….
….
….
….
….
….
…
…
Metadata explained of an FDB
database defining the project entity
Datatypes
Tag_attributes
Datatype_id Datatype_n
ame
1
Char
2
Int
3
Float
4
Double
5
Date
6
Combo
….
….
Entity
Tag
Title
Occurrence
Repetition
Authority
Language Datatype
Length
Projects
1
Project_
code
Mandatory
No
No
English
Char
8
Projects
4
Actions
Mandatory
Repetitons
No
English
Combo
NULL
…
…
…
…
…
…
…
…
…
Subfield_attributes
Entity
Tag
Subfield
Title
1
Projects
…
…
Occurrence Repetition Language Datatype Length
Employee_
Mandatory Repetitons
code
Projects Actions
1
Projects Actions
2
Action
Mandatory
Projects Actions
3
Deadline
….
….
Entities
Frame_entity_id
Title
….
….
English
Char
8
No
English
Char
40
Mandatory
No
English
Date
NULL
….
….
….
….
….
We have inserted the value NULL in the length attribute because in certain
datatypes (such as int, date, etc) we can not define a specific length
Complicated in use
The framework is complicated and the
management and operation of it is difficult,
laborious and time-consuming
It requires from the user a very good acquaintance
of the
proposed framework,
the structures and organisation of it
(metadata and data)
the processes of the management of the
elements that compose it.
CUDL Language
(Conceptual Universal Database
Language)
The CUDL language uses simple statements
to manipulate the applications that have been created
based on the proposed FDB framework
With CUDL the user
will not be compelled to know in-depth all the details of the
structure of information that are supported by this model
The user conceives the data as a extension of the relational
model with fields of variable length, multiple values,
subfields, table in the place of a field value, etc
CUDL language
The CUDL language undertakes the
management of the complicated
structures of the FDB model
By the use of CUDL, access in the
information of an FDB application
becomes very simple with the use of
particularly simple statements.
How the user conceives the structure
of a project frame
(tuple)
Projects
Project_code
Proj001
Title
Dept A
Budget
300,000
Actions
Employee_ code
Action
Deadline
Emp01
Software analysis
17/10/2007
Emp04
Software requirements
22/01/2008
Emp12
Emp13
Program code
23/04/2008
The language deals with
Schema definition, to declare the structures, integrity
constraints, and access privileges of a database
Schema manipulation, to alter a schema definition
Data manipulation, to populate a database and access
FDB data
Transaction management, to define and manage FDB
transactions
Connection management, to establish and manage
FDB connections
Session management, to set the attributes of an FDB
session
Schema and Data
Manipulation Language
We will focus on the
Schema and Data Manipulation Language
Both aspects of the language use variations of the
statements:
FIND
ALTER
DELETE
ADD
to manipulate values from the
meta-data and
data sets
of the model
Find
The most frequently used operation in data sources is the data retrieval
operation which retrieves instances from a set
The FIND statement specifies which instances to include in the result
set and it is used to retrieve zero or more instances from one or
more sets in a data source
In specifying a FIND query, the user specifies a description of the
desired result set,
but he does not specify what physical operations must be executed to
produce that result set.
The result from the implementation of a FIND statement is a new
virtual set that contains the elements that were asked by the user or
the value NULL, if no values meet the requirements of the Find
statement.
Find
1. Find values in the meta-data sets
(example 1)
# Find tag_attributes when title = ‘DVD_code’
Entity
Tag
Title
Occurrence Repetition Authority Language Datatype
Length
Videos
4
DVD_code
M
N
N
English
Char
6
Customer
5
DVD_code
M
R
N
English
Char
6
Find
1. Find values in the meta-data sets
(example 2)
# Find tag_attributes when entity = ‘customer’ and repetition=‘r’
and datatype=‘char’
Entity
Customer
Tag Title Occurrence Repetition Authority Language Datatype Length
5
DVD
_code
M
R
N
English
Char
6
Find
2. Find values in the data sets
(example 1)
# Find data when entity = ‘customer’ and tag =‘cust_code’
Entity
Frame_object
Tag
Repetion
Chunk
Tdata
customer
1
cust_code
1
1
Cust0001
2
3
1
1
1
1
Cust0002
Cust0003
4
1
1
Cust0004
Informally this statement takes the sequence of all customers and creates a sequence of
their ‘cust_code’. The result of typing in this query is that a sequence of ‘cust_CODE’ is
printed out.
Find
2. Find values in the data sets
(examples 2, 3, 4)
# Find data when entity = ‘videos’ and tag = ‘title’
This statement retrieves the titles of the videos (the projected field is ‘title’).
# Find data when entity = ‘videos’ and tag = ‘title’ frame
Notice that by adding the keyword frame we take all the data of all the tags for every
frame that meets the user requirements. The condition and tag=‘title’ is unnecessary
and can be excluded from the statement.
# Find data when entity = ‘videos’ and tag = ‘title’ restr data
like ‘M%’ and tag = ‘year’ restr data = ‘2003’
We have to mention that the conditions can be composed by a where part and a
restriction part. For example the condition and tag = ‘title’ restr data like ‘M%’ has a
where part tag = ‘title’ and a restriction part restr data like ‘M%’. The fields that take
place in the where part of the conditions also participate in the results (projected
fields).
Add
The ADD statement specifies which values to include in a database set
In specifying an ADD query, the user specifies the desired values to be
inserted in a specific desired set,
but he does not specify what physical operations must be executed for
the insertion
The result from the implementation of an ADD statement is
a new augmented set that contains also the new elements that were
asked by the user or
merely the old set if the new values can not de added
Add
1. Addition of meta-data
Let us for example assume that there is no tag ‘language’ for the entity
‘videos’. The statement in the CUDL language :
# Add tag_attributes entity = ‘videos’ title = ‘language’
will result in the tuple shown in Table 5 stored in the tag attributes set.
Entity Tag Title
1
7
9
Occurrence Repetition Authority Language
O
R
N
1
Datatype
Length
1
100
Add
2. Addition of data
(example of the creation and population of a whole
frame)
# Add data set 'title' = ' A Movie ' when entity = ‘videos’ new frame
# Add data set 'year' = '2007' when entity = ‘videos’ and tag = ‘title’
restr data = ‘A Movie’
…
# Add data set ‘actor1’ = ‘Al Patsino’ when entity = ‘videos’ and tag =
‘title’ restr data = ‘A Movie’
# Add data set ‘actor2’ = ‘Robert DeNiro’ when entity = ‘videos’ and
subfield = ‘actor1’ restr data = ‘Al Patsino’
Note that by adding the key-phrase ‘new frame’ the data are inserted in a new frame. Otherwise if
those keywords are omitted the data are inserted in an already existing frame that the user must
specify by adding the keywords when tdata = ‘<some value>’. If the user does not use the
specification referred above then a suitable message is presented to him and the statement is not
executed.
Delete
The DELETE statement specifies which values to exclude from a
database set
In specifying a DELETE query, the user specifies the desired values to
be removed from a specific set,
but he does not specify what physical operations must be executed for
the removal
The result from the implementation of a DELETE statement is
a new set that does not contain the elements that the user asked to
be removed or
the old set if the values can not de removed
Delete
1. Deletion from a metadata set:
# Delete tag_attributes when entity = ‘videos’ and title =
‘actors’
This will result in the deletion from the set tag_attributes of all the values that
correspond to the combination of the entity ‘videos’ and the tag (title) ‘actors’.
In the simplified relational view that the user conceives these statements
remove the field actors from the table videos.
The deletion will only occur under the condition that there do not exist data for
the ‘actors’ tag and also the specified tag does not participate in any authority
link (set authority_links).
Delete
2. Deletion from a data set:
# Delete data ‘category’ when entity = ‘videos’ and tag =
‘DVD_code’ restr tdata = ‘Vid01’
# Delete data whole_frame when entity = 'videos' and tag =
'DVD code' restr data = 'Vid01‘
We have to mention that the set ‘catalogue’ is affected as well, by this delete
statement. As the set catalogue is used to keep the values of the entity
and each frame for this entity that the set tag_data contains, since a
whole frame from the set tag_data was erased the corresponding entity
and frame from the set catalogue should be erased too.
Alter
The ALTER statement specifies which values to alter in a database set
In specifying a ALTER query, the user specifies the desired values to be
modified from a specific set,
but he does not specify what physical operations must be executed for
the modification
The result from the implementation of an ALTER statement is
a new set that does not contain the altered elements that the user
asked for or
the old set if the values can not de modified
Alter
1. Alter values in a metadata set
# Alter tag_attributes set occurrence = ‘M' when entity =
‘customer’ and title = ‘address’
Alter
2. Alter values in a data set
# Alter data set ‘title’ = ‘Movie1’ when entity = ‘videos’ and
tag= ‘DVD_code’ restr data = ‘Vid01’ and tag = ‘title’
restr data = ‘A Movie’
This statement modifies the data value of the tag title ‘A Movie’ to the data
value ‘Movie1’ . This will only occur under the condition that the
specified tag (in the specified frame) has no tag repetitions under the tag
title
Conclusions
The FDB model can form the basis for the
creation and maintenance of dynamically
evolving database environments
The CUDL language
undertakes the management of the complicated
structures of the FDB model and the user
experiences a simple extension of the relational
model with the usage of very simple statements
Thank you for your
attention !!!
[email protected]
[email protected]