Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 2 years ago
viewed 5999 times
Share this article

Data Types, Domains, and Inheritance in CUBRID RDBMS

In the previous article I have explained how data is stored in CUBRID RDBMS. I have described the concept of objects, classes, inheritance, and OID in CUBRID. In this article I will talk about the data types available in CUBRID and how they are stored in the database. Since CUBRID is an object-relational DBMS, it allows you to define your own custom data type, and I will show you in this article how to that.


A relational database system is designed to manage limited number of data types such as integer, floating point value number, string, boolean, date, time, and currency. In other words, it is not designed to manage the data types which users have custom created. On the other hand, one of the core points of the object-oriented data model is that the functions to create custom and new data types are supported in a consistent way. Moreover, the object-oriented data model supports encapsulation of data and the programs that access the data, and the framework for user-defined data types, as well as the structure, relations, and constraints of data expressed on the relational model. With encapsulation and inheritance (reuse), it essentially relieves the difficulty of designing a complex software system.

In CUBRID, the attributes (columns) defined in classes (tables) have their names and domains. The name is used as an identifier of a column and the domain specifies the type of data that the column can have. The data type defines the format to save the data to the database. In addition to the following default data types that can be used as domains, other classes (tables) in a database can also be specified as a domain. If you want to use a class (table) as a domain, instead of the default data type, use the class name (table name) as the name of the data type. But there is one more unique way to use the class as a domain: to use any class as a domain of the column, specify the domain to OBJECT type.

Default Data Types

Each data type in a database has its value, which denotes the allowed size a user can enter for this data type, as well as a specific format this data type can have.

  • The INTEGER data type, for instance, is a 32-bit integer, i.e. 4 bytes, which is the value of this INTEGER data type.
  • The STRING data type is a string with a variable length, i.e., bytes with a specific length.

In other words, a data type is a method to interpret the number of bytes the data of the column occupies in a record. When the data type of a column is INTEGER, the value of the column is 4 bytes and the 4 bytes are interpreted as an integer value. When the data type of a column is STRING, it is a string with a variable length. The length of the string is saved at the beginning of the string which is followed by the string itself. If the length of a string is 255 or less, which can be saved in 1 byte, the first byte indicates the length of this string and the following bytes are the string data. If the length of a string is longer than 255, 0xFF is saved in the first byte while the actual length is saved in the integer form in the next 4 bytes. In this matter, a data type or a domain stands for the format of saving various types of values in the database.

Class Domains (or tables as data types)

You now know how default data types are stored in CUBRID. But which storage format will be used for the column that has classes (tables) as domains (data types)? Will the column save the structure of a class specified as a domain as it is?

For example, as illustrated in the following Figure 1, if the person class is specified as a domain of the emp attribute of the employee class, you may think that the storage type of the emp column would be the sum of name, dob, ssn, and marital_status columns. However, it is not in CUBRID. From the storage format side, the emp column has OID (Object Identifier) only. This is the difference between CUBRID and Oracle or SQL3 (SQL:1999) standard. If a database has the object-oriented concept, there are two ways:

  1. Oracle defines a new complex data type using simple data types and specifies it as the data type of a column.
  2. CUBRID refers to other classes.


Figure 1: Example of Using a Class (Table) as a Domain (Data Type).

So, as mentioned earlier, each data type has a value (number of bytes) as well as a specific format. In a database, a unique value is defined regardless of the data type. It is NULL. This value has neither value nor a data type. For example, the ‘PARK.K.E’ string, one of the values of the name column in the person table in the above figure, belongs to the domain whose data type is VARCHAR(30). The domain with the VARCHAR(30) data type starts from an empty string ‘ ’ of which length is 1 to 'ÿÿ…ÿ’ filled with ÿ, the last character of ISO 8859-1 Latin 8-bit character set of which length is 30. However, NULL can be the value of a type such as INTEGER, NUMERIC, STRING and BLOB. In other words, all domains of a database include NULL value. The INTEGER type has an integer value which can be expressed by using 4 bytes + NULL value as its domain.

Let's get back to the class domain. CUBRID allows specifying other classes (tables) as domains (data types). However, the value which is actually saved is an OID value which indicates the physical address of an instance object of the class which is specified as a domain.

Here you may think that all class domains have an identical structure and there is no distinction among them, but it is not true. The user-defined schema information saves the information about which class was specified as a domain. Whenever a user tries to set a value to a column, the data type is checked. For the class domain, it is checked whether the object of the class specified in the schema is referred to or not. In CUBRID, the type was defined and built into the system in advance and the domain is specified by a user at the database design phase. Therefore, the domain is declared and defined for the default data types in advance. In the source code, the data structure that shows the domain information is the TP_DOMAIN structure defined in the object/object_domain.h file. In this object/object_domain.h file, the domain data structure for a default data type, such as tp_Integer_domain, is already defined. The default data type such as INTEGER and STRING has its pre-defined global variable in the TP_DOMAIN type. When a user specifies a class as a domain, the default data type dynamically creates and saves the data structure of the TP_DOMAIN structure. This is how class domains are stored and referred in CUBRID RDBMS. I will discuss more about TP_DOMAIN data structure in one of the coming articles.


This concludes the talk about Data Types, Domains, Classes and Attributes in CUBRID. You now know that in CUBRID you can easily create custom data types which represent one of the existing tables which is a really great and convenient feature. This allows you to inherit certain attributes of base tables and extend them.

In the next article I will explain about different modes of execution in CUBRID such as client-server and standalone modes. The client-server architecture of CUBRID enhances the processing speed and allows to distribute database functions to multiple hosts as several clients cache the database object saved in the server. I will explain more about the advantages of this client-server concept in the next article.

comments powered by Disqus