Thursday, August 18, 2016

lntroduction to Relational Database

The relational model defined by E.C.Codd in the early seventies is a theoretical model of a database. The model appealed to the computer science community because of its mathematical basis and to the computing industry at large because of the simple way in which it represented information by the well understood convention of tables of values.

Three parls of the Relational Model

So what exactly is a relational model? A good characterize it is as follows: The Relational model is a way of looking at data- that is, it is a prescription for a way of representing data(namely by means of tables), and prescription for a way of manipulating such a representation(namely, by means of operators such as JOIN). More Precisely the relational Model is concerned with three aspects of data : Data Structure, Data Manipulation, Data Integrity.

A structural part - the type of structure from which the database is constructed.

A manipulative part - the operations which are used for retrieving and updating data in the database.

An integrity part- the rule that all valid database must obey

Relational Data structure

We can view the table to be the basic object of the relational model. Relational model tables confirm to the intuitive notion of tables with columns of values and a header name for each column with which we are all familiar. The following are the components of the relational data structure:

Relation:

A set of tuple defined on a number of attributes.

Attribute: Attributes are like the columns of a conventional table. Each attribute has an attribute name(like the column heading) and attribute values(like column entries).

Tuple: A tuple can be likened to a row in a conventional table. Each tuple is a set of attribute values one for each attribute of the relation. Furthermore, each tuple has the same number of attributes.

Header and Body: Table has two distinct parts, a header part, and a body part. The header part of the
table is a simple mathematical set, including a list of attribute name for each column. Each attribute name must be unique within a table. The body part consist of a number of tuples. The intersection of a tuple with each column of the table holds an attribute value. Each Column in the body part of the table holds attributes values corresponding to only one type of attribute. The list of values which attributes in one column can take is referred to as the Domain of the that attributes.


Domains and Keys

Domains- This is a set of values of a given type. For example, the domain of an attribute named Supplier Number is the set of all possible supplier numbers, the domain of shipment quantities is the set of all integers greater than zero and less than 10,000. Thus domains are pool of values, from which the actual values appearing in attributes are drawn. Every attribute must be defined on exactly one underlying domain, meaning that attribute must be drawn from that domain.

One aspects of the significance of domains is that domain constrain comparisons. For example, it makes sense to compare two part numbers which make up attribute in two separate relations, but not make sense to compare a weight with quantity. Both of these are numbers, but different kinds of numbers. The weight and quantity domains would therefore be distinct. We can state that if two attributes draw their values from the same domain, then comparisons - hence JOINS, UNIONS, and many other operations - involving those two attributes make sense because they are comparing like with like.

Keys:
A set of attributes whose values , uniquely identify each tuple of a relation.

Candidate Key:
Any attribute which satisfies the above definitions. A relations may have many keys.

Primary Key and Alternate key:
Among all the candidate keys of a given relation. one will be chosen to be the primary key, and the others are called alternate keys. Remember that the primary key values are used identify uniquely each tuple within a table. Therefore, the values of i primary key attribute must each be unique within the domain of that attribute.

Composite Key:
when more than one attribute column is needed to establish unique identification for tuples within a table, the resulting primary key is referred to as a concatenated primary key.

Foreign Key:
These are attributes used to cross reference tuples using the tuples' primary key values. In other words, a primary key for one table is Known as a foreign key in the table into which it is embedded for the purpose of identifying relationship occurrences.

Foreign Key are used to represent relationships. There are no links or pointers connecting one table to another. In non relational systems, by contrast, such information is typically represented by some kind of physical link or pointer that is explicitly visible to the user.

Properties of Relations

Relation posses certain properties, all of them immediate consequences of the definition of relation. Within any given relation:


  • There are no duplicate tuples: This property follows from the fact that the body of the relation is a mathematical set, and sets in mathematics by definition do not include duplicate elements.


  • Tuples are unordered: This properly'also follows from the fact that the body of the relation is a mathematical set. Set in the mathematics are not ordered. Thus, the order of the tuples in the relation is unordered.


  • Attributes are unordered: This property follows from the fact that the heading of a relation is also defined as a set. Each attribute is always referenced by its name not by its relative positioning within the header.


  • All attribute values are atomic: At every row and column position within the table, there always exists precisely one value, never list of values.


The Procedure for Designing Relational Databases

Having discussed the relational data structure, it is useful to review the basic procedure for designing a relational database.

Identify data and user needs(System Analysis)
Construct Entity- Relationship(E-R) models
Normalize the Data
Transformed the normalized ER models to a relational one

No comments:

Post a Comment

Important Notice!

Dear students and friends. When you commenting please do not mention your email address. Because your email address will be publicly available and visible to all. Soon, it will start sending tons of spams because email crawlers can extract your email from feed text.

To contact me directly regarding any inquiry you may send an email to info@bcslectures.website and I will reply accordingly.