Complex Data Types in DBMS: Object-based databases

What are complex data types? How do we use them in Object-based databases? Today, I will tell you about these data types and how they work. So let's begin-



Complex Data Types in DBMS Object-based databases
Complex Data Types

Complex Data Types

Traditional database applications have conceptually easy data types . The fundamental data types are records that are fairly tiny and whose fields are atomic - that's , they're not additionally structured , and initial normal type holds . 

Further , there are solely few record varieties . In recent years , demand has full-grown for methods to agitate more complex data types

Consider , as an example , addresses .Whereas a complete address might be viewed as an atomic information item of type string , this view would hide details like the road address , city , state , and zip code , that might be of interest to queries . 

On the opposite hand , if an address were delineate by breaking it into the parts ( address , city , state , and zip code ) , writing queries would be additional sophisticated since they'd got to mention every field . 

A much better alternative is to permit structured data types that allow a sort address with subparts address , city , state , and zip code . 

As another example , take into account multivalued attributes from the E - R model . Such attributes are natural , as an example , for representing phone numbers , since folks may have more than one phone . 

The choice of social control by making a replacement relation is pricey and artificial for this  instance. 

With complicated sort systems we are able to represent E - R model ideas , like composite attributes , multivalued attributes , generalization , and specialization directly , without a complex translation to the relative model . 
Complex Data Types in DBMS: Object-based databases
Non-1F books relation, books.

In Relation Database Design , we outlined first normal form ( 1NF ) , which needs that aa attributes have atomic domains . Recall that a domain is atomic if components of the domain are considered to be indivisible by units . 


The belief of 1NF may be a natural one within the database application examples we've thought-about . However , not all applications are best shapely by INF relations . 

For instance , instead of viewing a database as a collection of records , users of certain applications read it as a collection of objects ( or entities ) . 

These objects could need many records for their illustration . An easy , simple - to - use interface needs a one - to - one correspondence between the user's intuitive notion of an object and therefore the database system's notion of an data item . 

Consider , for instance , a library application , and suppose we  want to store the subsequent data for every book : 

  • Book title
  • List of authors
  • Publisher
  • Set of keywords 
We can see that , if we outline a relation for the preceding info , many domains are going to be nonatomic .

  • Authors. A book could have an inventory of authors , that we are able to represent as an array . Nevertheless , we might want to search out all books of that Jones was one amongst the authors. Thus , we have an interest in a component part of the domain element " authors. "
  • Keywords. If we tend to store a group of keywords for a book , we expect to be ready to retrieve all books whose keywords embody one or a lot of such specified keywords . Thus , we view the domain of the set of keywords as nonatomic.
  • Publisher. Not like keywords and authors , publisher doesn't have a set - valued domain . However , we could read publisher as consisting of the subfields name and branch . This view makes the domain of publisher nonatomic .
Complex Data Types in DBMS Object-based databases

4NF version of the relation books

For simplicity , we tend to assume that the title of a book uniquely identifies the book . We will then represent an equivalent data using the subsequent schema , wherever the primary key attributes are underlined :
  • authors ( title , author , position ) 
  • keywords ( title , keyword )
  • books4 ( title , pub_name , pub_branch ) 
The above schema satisfies 4NF . Image above shows the normalized illustration of the info from Non-1F books relation . 

Though our example book info will be adequately expressed while not using nested relations , the use of nested relations results in an easier - to - perceive model . 

The everyday user or programmer of an data - retrieval system thinks of the info in terms of books having sets of authors , because of the non - 1NF style models . 

The 4NF style needs queries to hitch multiple relations , whereas the non - INF style makes many varieties of queries easier . 

On the opposite hand , it may be better to use a primary traditional type illustration in alternative situations . As an example , contemplate the takes relationship in our university example . 

The relation is many - to - many between student and section . We could conceivably store a collection of sections with every student , or a collection of scholars with every section , or both . 

If we tend to store both , we'd have information redundancy ( the connection of a specific student to a specific section would be stored twice ) . 

The power to use complex data types like sets and arrays may be helpful in several applications however ought to be used with care.


Check out my other posts related to DBMS:

Deadlock Handling

Serializability

Remote Backup System

Aries Recovery Algorithm

Buffer Management



If you enjoyed and got some knowledge through this post, please share it with your friends and family members and if you don't want to miss my articles, you can subscribe us by sharing your email id through FeedBurner(click on the subscribe button in the right ). Comment below if you got any query related to this article. 


Previous
Next Post »

No comments:

Post a Comment

Please do not enter any spam links in comment box.