Relationship Models Chapter_2 (1 / 26) ___________________________________________________________________________________

Chapter 2

RELATIONSHIP MODELS
Entity Relationship (E-R) Model
The entity_relationship (E-R) model is based on a perception of a real world which consist of a set of basic objects called entities and relationships among these objects. The E-R model for data uses 3 features to describe the data: ENTITIES : which specify distinct real world items in an application. RELATIONSHIPS: which connect entities. ATTRIBUTES: which specify properties of entities and relationships.

Entities & Entity Sets

An entity is an object that exists and is distinguihable from other objects. For example, Omer with social security number 89-123 is an entity, similarly, account number 401 at the National bank is an entity that uniquely identifies one particular account. An entity may be concrete, such as a person or a book, or it may be abstract, such as a holiday or a concept. An entity set is a set of entities of the same type. The set of all persons having an account at a bank, for example, can be defined as the entity set customer. Similarly, the entity set account might represent the set of all accounts in a particular bank. An entity is represented by a set of attributes. Possible attributes of the customer entity set are customer_name, social_security, street, and city. For each attribute there is a set of permitted values, called the domain of that attribute. The domain of attribute customer_name might be the set of all text strings of a certain length. Similarly, the domain of the attribute account_number might be the set of all positive integers. Every entity is described by a set of (attribute, data value) pairs, one pair for each attribute of the entity set. A particular customer entity is described by the set {(name, Omer), (social_security, 89-123), ( street, North), (city, Aden)}. A database thus includes a collection of entitiey sets each of which contains any number of entities of the same type.

Relationships & Relationship Sets

A relationship is an association among several entities. For example, we may define a relationship which associates customer John with account 401. This specifies that John with bank account number 401.
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (2 / 26) ___________________________________________________________________________________

A relationship set is a set of relationships of the same type. Formally, it is a mathematical relation on n 2 entity sets. If E1, E2, ,En are entity sets, then a relarionship set R is a subset of

{ ( e1, e2, ,en) / e1 E1, e2 E2, , en En }

where ( e1, e2, ,en) is a relation. Consider the two entity sets customer and account shown below. We define the relation set CustAcct to denote the association between customers and the bank accounts that they have. The relation CustAcct is an example of a binary relation set (i.e. one which involves two entity sets). Most of the relationship sets in a databease system are binary. A relationship may also have descriptive attributes. For example, date could be an attribute of the CustAcct relationship set. This specifies the last date on which a customer has accessed the account.
c_name John Brill Marsh Evers Customer social_security 645-123 121-222 664-191 111-211 street North Park Main Main city account Account_number balance 200 30000 115 10000 700 2000 915 550 467 30000 118 10000

Example : A vendor supplying items to a company, is an entity. The item he

supplies is another entity. The act of supplying defines a relationship.
V.no

V.Code

V.Addr

VENDOR

V.Code

Qty_Supply

Item_Code

SUPPLY

Date_of_Supply

Item_Code

ITEM

Item_Name

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (3 / 26) ___________________________________________________________________________________

Mapping Constraints
An E-R scheme may define certain constraints to which the contents of a database must conform. One important constraint is mapping cardinalities, which express the number of entities to which another entity can be associated via a relationship set. For a binary relationship set R between entity sets A and B, the mapping may be: One-to-one (1:1) : an entity in A is associated with the most one entity in B, and an entity in B is associated with at most one entity in A. One-to-many (1:M) : an entity in A is associated with any number of entities in B, and an entity in B, however, can be associated with at most one entity in A. Many-to-one (M:1) : an entity in A is associated with at most one entity in B, and an entity in B, however, can be associated with any number of entities in A. Many-to-many (M:M) : an entity in A is associated with any number of entities in B, and an entity in B, however, can be associated with any number of entities in A.
1: 1 Department 1: M Manager
M: M

Students

Courses Manager Employee

Keys
It is important to be able to specify how entities and relationships are distinguished. Conceptually, individual entities and relationships are distinct, but from a database perspective the difference among them must be expressed in terms of their attributes. The concept of a superkey allows us to make such distinction. A superkey is a set of one or more attributes which, taken collectively, allow us to identify uniquely an entity in the entity set. For example, the social_security attribute of the entity set customer is sufficient to distiguish one customer entity from another. Thus, the social_security is a superkey for the entity in the entity set customer. The customer_name attribute of the customer is not a superkey, as several people might have the same name. However, the combination of the social_security and the attribute customer_name is a superkey.
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (4 / 26) ___________________________________________________________________________________

However, if K is a superkey, then so is any superset of K. We often interested in superkeys for which no proper subset is a superkey. Such a minimal superkeys are called candidate keys. It is possible that several distinct sets of attributes could serve as a candidate key. For examples, both {social_security} and {customer_name, street} are candidate keys. We shall use the term primary key to denote a candidate key that is chosen by the database designer as the principal means of identifying entities within an entity set. It is possible that an entity set does not have sufficient attributes to form a primary key. Such an entity set is term a weak entity set. An entity set which has a primary key is term a strong entity set. In order for a weak entity set to be meaningful, it must be part of a one-to-many relationship set. The attributes of a relationship set R involving entity sets E1, E2,, En is the union of all the primary keys of these entity sets besides the descriptive attributes {a1,a2,,am} of the relationship set R it self. That is ; Primary_key(E1) Primary_key(E2) Primary_key(E1 ) {a1,a2,,am} For example, consider the relationship set CustAcct defined before, which involves the following two entity sets : customer : with primary key social_security, account : with the primary key account_number. Since the relationship set has the attribute date, the set attribute(CustAcct) consists of the three attributes social_security, account_number, and date.

street city

Account_number balance date

Social_security
name customer

CustAcct

account

Entity-Relationship Diagram
Consider the above diagram which consists of two entity sets, customer and account, related through a binary relationship set CustAcct. The attributes associated with customer are name, social_security, city, and street. The attributes associated with account are account_number, and balance. The relationship set CustAcct may be
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (5 / 26) ___________________________________________________________________________________

many-to-many, one-to-many, many-to-one, or one-to-one. To distinguish among these, a directed arc line () or an undirected line ( __ ) between the relationship set and the entity set is used. A directed line from the relationship to an entity set specifies that the entity set participates in either a one-to-one or a many-to-one relationship with the other entity sets. It can not participate in either a many-to-many or one-to-many relationship. An undirected line from the relationship set to an entity set specifies that the entity set participates in either a many-to-many or a many-to-one relationship with the other entity sets. If the relationship set CustAcct were one-to-many, from customer to account, then the line from CustAcct to customer would be directed with an arrow pointing to the customer entity set (Fig A). Similarly, if the relationship set CustAcct were many-toone from customer to account, then the line from CustAcct to account would have an arrow pointing to the account entity set (Fig B). The one-to-one relationship is shown in Fig C.
street city Account_number balance date

Social_security
name customer

CustAcct

account

Fig A : One-to-many relationship

street city

Account_number balance date

Social_security
name customer

CustAcct

account

Fig B : Many-to-One relationship

street city

Account_number balance date

Social_security
name customer

CustAcct

account

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Fig C : One-to-One relationship

Relationship Models Chapter_2 (6 / 26) ___________________________________________________________________________________

A database which conforms to an E-R diagram can be represented by a collection of tables. For each entity set and for each relationship set in the database, there is a unique table which is assigned the name of the corresponding entity set, or relationship set. Each table has a number of columns which , again, have unique names.

customer
name Salem Omer Ali Abdulla Ali Social_security 52-382 89-123 52-394 11-222 12-121 Street Main North Main North South City Abian Aden Aden Sanaa Sanaa

account
Account_number 259 630 401 199 210 118 117 183 Balance 1,000 2,000 1,200 2,200 22,500 62,000 3,000 100,000

CustAcct
Social_security 52-382 89-123 52-394 11-222 12-121 89-123 Account_number 259 630 401 199 118 177 Date 17 June 1994 17 May 1994 23 May 1994 19 June 1994 19 June 1994 26April1996

The function that an entity plays in a relationship is called its role. Roles are normally implicit and are not usually specified. However, they are useful when the meaning of a relationship needs clarification. Such is the case when the entity sets of a relationship set are not distinct. For example, the relationship set works-for might be modeled by ordered pairs of employee entities.

phone

employee-name

manager
employee Works-for ________________________ _________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

worker

Relationship Models Chapter_2 (7 / 26) ___________________________________________________________________________________

DATABASE
Network Model

MODELS

A network database consists of a collection of records which are connected to one another through links. A record is in many respects similar to an entity in the E-R model. Each record is a collection of fields (attributes), each of which contains only one data value. A link is an association between precisely two records. Thus a link can be viewed as a binary form of relationship in the sense of the E-R model.

DATA-STRUCTURE DIAGRAMS
A data-structure diagram is a scheme representing the design of a network database. Such a diagram consists of two basic components: Boxes , which correspond to record types Lines , which correspond to links.

A data-structure diagram serves the same purpose as an E-R diagram; namely, it specifies the overall logical structure of the database. The figure shown below, illustrate an example of the E-R diagram and its corresponding data-structure diagram. The record type customer corresponds to the entity set customer. It include the fields name, street, and city . Similarly, account is the record type corresponding to the entity set account. It includes the two fields number and balance. Finally the relationship CustAcct has been replaced with the link CustAcct.
street city number balance

name customer CustAcct account

customer
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

account CustAcct

________________________ _________________________________________________________ name street city number balance

Relationship Models Chapter_2 (8 / 26) ___________________________________________________________________________________

The relationship CustAcct is many-to-many. If the relationship were one-tomany from customer to account, then the link would have an arrow pointing to customer record type. Similarly, if the relationship CustAcct were one-to-one, then the link would have two arrows, one pointing to account record type and one pointed to customer record type. A database corresponding to the above scheme may thus contain a number of customer records linked to a number of account records as illustrated in the figure shown below which is corresponding to the many-to-many relationship.

customer

account Main Aden 259 630 177 1000 2000 3000 1200

Ali Omer
Abdulla

North

Aden

North

Sanaa 401

A simple database corresponding to a data structure diagram of one-to-one is shown below.

customer Ali Main Aden 259 account 1000

Omer

North

Aden

630

2000

Abdulla

North

Sanaa

177

3000

If the relationship includes descriptive attributes, the tranformation from the E_R daigram to a data_structure diagram a new record type needs to be created and links need to be established as described below. Consider the E-R diagram shown below. To transform this diagram to a data-structure diagram we need to: 1. Replace entities customer and account with record types customer and account, respectively. 2. Create the following many-to-one links: CustDate from the date record type to the customer record type. AccDate from the date record type to the account record type.
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (9 / 26) ___________________________________________________________________________________

The resulting data-structure diagram is shown below.

street city date name customer CustAcct account number balance

customer name street city number balance

account

CustDate date date

AccDate

DBTG Data Retrieval Facility

In the late 1960s, several commerial database systems based on the network model emerged. These systems were studied extensively by the Database Task Group (DBTG) within the CODASYL group. In the DBTG model, only many-to-one links can be used. The data manipulation language of the DBTG model consists of a number of commands. These commands access and manipulate database variables as well as locally declared variables. Each application program executing in the system consists of a sequence of statements; some are Pascal statements while other are DBTG command statements. Each such program is called a run unit. For each such application program, the system maintains a program work_area, a buffer storage are which contains the following variables:

Record Templates : a record for each record type . Currency Pointers : a set of pointers to various database records most recently accessed by the application. Currency pointers are of the following types: 1. Current of record type

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (10 / 26) ___________________________________________________________________________________

2. Current of set type.

3. Current of run unit.

Status Flags : a set of variables used by the system, (e.g. DB_status flag which set to 0 if the most recent operation succeeded, otherwise, it is set to an error-code).

customer Omer North account 119 branch Arwa 10000 customer account branch CustAcc BrnAcc Run unit Aden 2000 Aden

Omer Aziz Ali Arwa Nation a 119 45 119

North North North 10000 44499 2000 5000 2000

Aden Abian Sanaa Aden Aden 117 245 119 1290 1200 2000

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (11 / 26) ___________________________________________________________________________________

Find and Get Commands

find, which locates a record and sets the appropriate pointers get, which copies the record find from the storage to the work_area.

The find command has a number of forms.

find any < record type> using <record-field> find duplicate < record type> using <record-field> find first < record type> within <set-type> find next < record type> within <set-type> find owner within <set-type> find for update any < record type> using <record-field> find for update first < record type> within <set-type>

Example : Construct a DBTG query that prints the street name of Abdulla.
customer.name := Abdulla; find any customer using name; get customer; print (customer.street);

There may be several records with the specified value. The find any command locates the first of these. To locate other database records which match the <recordfield>, we use the command (find duplicate <record type> using <record-field>)

Example : Construct a DBTG query that prints the names of all the customers
who live in Aden. customer.city := Aden; find any customer using city; while DB_status = 0 do begin get customer; print (customer.name); find duplicate customer using city; end;

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (12 / 26) ___________________________________________________________________________________

The previous find commands locate any database record of type <record type>, we may concentrate on find that locate records in a particular DBTG-set. There are three different types of commands: find first .., find next , and find owner..

Example : Construct a DBTG query that prints the total balance of all the
accounts belonging to Omer. sum := 0; customer.name := Omer; find any customer using name; find first account within CustAcct; while DB_status = 0 do begin get account; sum := sum + account.balance; find next account within CustAcct; end; print (sum); The previous find commands locate records within a particular DBTG-set. There are many circumstances, where it may be necessary to locate the owner of a particular DBTG-set. This can be accomplished through the command (find owner within <set-type>).

Example : Construct a DBTG query that prints all the customers names of the
Arwa branch. branch.name := Arwa; find any branch using name; find first account within BrncAcct; while DB_status = 0 do begin find owner within CustAcct; get customer; print (customer.name); find next account within BrncAcct; end;

Example :
As a final example, consider the DBTG query that prints the names of all customers of the bank. Such a query cannot be formed easily since no one single set has all the customer records as its members. We can define a sigular set consisting of members of type customer as:

set name is AllCust; owner is system;

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (13 / 26) ___________________________________________________________________________________

member is customer;

Then we can form the query as: find first customer within AllCust; while DB_status = 0 do begin get customer; print (customer.name); find next account within AllCust; end;

Example : Construct a DBTG query that prints the total number of accounts in
the Arwa branch with a balance greater than $10,000. Count := 0; branch.name := Arwa; find any branch using name; find first account within BrncAcct; while DB_status = 0 do begin get account; if account.balance > 10000 then count := count +1; find next account within BrncAcct; end; print(count);

Creating New Records

In order to create a new record, we insert the appropriate values in the record template of the work_area. We then add this new record to the database through the command Store <record type> . The record are added only one at a time.

Example : Construct a DBTG query for adding a new customer, Aziz, to the
database. customer.name := Aziz; customer.street := Old road; customer.city := Taiz; store customer;

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (14 / 26) ___________________________________________________________________________________

Modifying Records
In order to modify a record, we must find that record in the database, get it into the work_area memory and then change the desired fields in the template of the record. Then this modification can be reflected through the command (modify <record type>)

Example : Construct a DBTG query to change the street address of Omer to

Last_Road. customer.name := Omer; find for update any customer using name; get customer; customer.street := Last_Road; modify customer;

Deleting Records
In order to delete a record, the currency pointer of that type must point to the record in the database to be deleted. Then we can delete the record by (erase <record type>).

Example : Construct a DBTG query to delete account 199 belonging to Abdulla.

finish := false; customer.name := Abdulla; find any customer using name; find for update first account within CustAcct; while DB_status = 0 and not finish do begin get account; if account.number = 199 then begin erase account ; finish := true; end; else find for update next account within CustAcct; end;

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (15 / 26) ___________________________________________________________________________________

It is possible to delete an entire set occurrence by finding the owner of the set , say, a record of type <record type>, and then execute (erase all <record type>). This will delete the owner of the set and all of its members.

Example : Construct a DBTG query to delete customer Amir and all of his
accounts. customer.name := Amir; find for update any customer using name; erase all customer;

Connect / Disconnect / Reconnect Statements

In order to insert a new record of type <record type> into a particular occurrence of <set type>, we must first insert the record into the database. Then, we need to set the currency pointers of the <record type> and the <set type> to point to the selected record and set. Then the new record can be inserted to the set by ( connect <record type> to <set type>). In order to remove a record from a set we need to set the cuurency pointer of the <record type> and <set type> to point to the selected record and set. Then the record can be removed by (disconnect <record type> from <set type>). Note that this operation only removes a record from a set not from the database.

In order to move a record from one set occurrence to another set occurrence, we need to find the selected record and the owner of the set to which that record is to be moved. Then we can move the record by : ( reconnect <record type> to <set type>).

Example : Construct a DBTG query for creating new account 401 which belongs
to Ali. account.number := 401; account.balance := 0; store account; customer.name := Ali; find any customer using name; connect account to CustAcct;

Example : Assume we wish to close account 177.

account.number := 177; find for update any account using number;
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Relationship Models Chapter_2 (16 / 26) ___________________________________________________________________________________

get account; find owner within CustAcct; disconnect account from CustAcct;

Example : Construct a DBTG query to move all accounts of Omer that are
currently at the Aden branch to the Taiz branch. customer.name := Omer; find any customer using name; find first account within CustAcct; while DB_status = 0 do begin find owner within BrncAcct; get branch; if branch.name = Aden then begin branch.name = Taiz; find any branch using name; reconnect account to BrncAcct; end; find next account within CustAcct; end;

Mapping Networks to Files

A network database consists of records and links. Links are implemented by adding pointer fields to records that are associated via a link. Each record must have one pointer field for each link with which it is associated. Since the CustAcct link is many-to-many, each record may be associated with an arbitrary number of records. Thus, it is not possible to limit the number of pointer fields in a record. These complications led the DBTG model to restrict links to be either one-toone or one-to-many. So it is possible to retain fixed-length records.

Omer

89-123 Aden

117

1000

Ali

12-333

Aden

401

200

300

2000

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla 55-88 Sanaa Computer Sci & Engg. Department, Aden University

199

30000

Relationship Models Chapter_2 (17 / 26) ___________________________________________________________________________________

Aziz

Rather than using multiple pointers , we can use a ring structure to represent the entire occurrence of the DBTG set-type. In a ring structure, the records of both the owner and the member types for a set occurrence are organized into a circular list. There is one circular list for each set occurrence. So, each record will contains exactly one pointer for each DBTG-set it is involve in, regardless of whether it is of the owner type or member type. Finally, two of the most pupolar network systems are Total and IDMS.

Omer

89-123 Aden

117

1000

Ali

12-333

Aden

401

200

300

2000

Aziz

55-88

Sanaa

199

30000

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (18 / 26) ___________________________________________________________________________________

Hierarchical Model
In the network model, the data is represented by collections of records and relationships among data are represented by links. This is true of the hierarchical model as well. The only difference is that in the hierarchical model, records are organized as collection of trees rather than as arbitrary graphs. A hierarchical database consists of a collection of records which are connected to one another through links. Each record is a collection of fields (attributes), each of which contains only one data value. A link is an association between precisely two records. Consider a database representing a customer-account relationship in a banking system. There are two record types, customer and account. A simple database is shown in the figure below. It shows that customer Omer has account 119, customer Ali has accounts 180 and 45, and customer Aziz has account 245.

Omer

North

Aden

Ali

South

Sanaa

Aziz

Road3

Taiz

119

2000

180

1250

45

120

245

4000

A DBMS belonging to the hierarchical data model uses tree structures to represent relationship among records. Here, the set of all customer and account records is organized in form of a rooted tree where the root of the tree is a dummy node. The hierarchical database (called as database tree) is a collection of such rooted trees, and hence forms a forest.

Consider the example of an institute which has a number of programs to offer. Each program has a number of courses. Each course has a number of students registered in it.

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (19 / 26) ___________________________________________________________________________________

Institute

Programs

Courses

Students

Institute
Program A Program B

Course A1

Course A2

Course B1

Course B2

Course B3

Student 1

Student 2

The content of a particular record may have to be replicated in several different locations. For example, an account may belong to several customers. The information pertaining to that account or the information to the various customers to which it may belong, will have to be replicated. Record replication has two major drawbacks: Data inconsistency may result when updating takes place. Waste of space is unavoidable.

Tree-Structure Diagrams
A tree-structure is the scheme for Hierarchical Database. Such a diagram consists of two basic components: Boxes , which correspond to record types, Lines, which correspond to links.

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (20 / 26) ___________________________________________________________________________________

A tree-structure diagram serves the same purpose as an entity-relationship diagram; namely, it specifies the overall logical structure of the database. It is similar to the data-structure diagram in the network model. The main difference is that the record types are organized in the form of a rooted tree. In a rooted tree, there can be no cycles, and the relationships formed in the tree must be such that only one-to-many or one-to-one relationships exist between a parent and a child. The database scheme is represented as a collection of tree-structure diagrams. For each such diagram, there exists one single instance of a database tree. Consider the entity-relationship diagram shown below, which consist of three entity sets customer, account and branch, related through the general relationship set CAB. This diagram specifies that a customer may have several accounts each located in a specific bank branch, and that an account may belong to several different customers. There are a number of different ways to transform this E-R diagram to a treestructure diagram. The most straightforward transformation is to create two treestructure diagrams as shown below.

assets name city street city branch name customer CAB account number balance

branch name assets city name assets

branch city

customer name street city number

account balance

account number balance name street

customer city

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (21 / 26) ___________________________________________________________________________________

An instance of the database corresponding to the above described scheme is illustrated below. It shows that Omer has account 200 in the arwa branch and the account 300 in the national bank, Ali has the accounts 256 and 119 in the arwa branch, and that Aziz has the same account 300 of Omer in the national branch and the account 160.

arwa

100000

aden

national

9999999

Sanaa

Omer

Road1 Ali

aden Main Taiz Aziz Road2

Omer aden

Road1

aden

256 200 55

10000 119 33450

300

10000 160 3000

300

10000

Data Retrieval Facility

Here, we present a query language for hierarchical databases which is derived from DL/I, the data manipulation language of IMS. We consider the simple example of a customer-account-branch scheme. The tree-structure diagram for this example is shown below. It specifies that a branch may have several customers each of which may have several accounts. An account, however, may belong to only one customer, and the customer can belong to only one branch.
branch name assets city

customer name street city

account number balance

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (22 / 26) ___________________________________________________________________________________

Each application program executing in the system consists of a sequence of statements which access and manipulate database items as well as locally declared variables. For each such application program, the system maintains a program workarea, a buffer storage area which contains the following variables: Record templates, a record for each record type . Currency pointers, a set of pointers, one for each database tree, containing the address of the record in that particular tree most recently accessed. Status flag, a variable set by the system to indicate to the application program the outcome of the last database operation. We call this flag DB-status.

The Get command

Data retrieval is accomplished through the get command. The actions taken with get are as follows: Locate a record in the database and set the currency pointer to it. Copy that record from the database to the program area template. Suppose that a get command was issued to locate the customer record belonging to Omer. Once this command successfully executes, the changes that occur are (1) the currency pointer points now to record of Omer, (2) The information of Omer is copied into the customer record work-area template, (3) DB-status is set to the value 0. To scan all records in a consistent manner, we must impose an ordering on the records. The one commanly used is preorder. A preorder traversal of the tree is one way of traversing the tree. Here, the node is processed first, followed by the leftmost subtree then the rigthmost subtree, recursively. Thus, we start at the root, visit the leftmost child, visit its leftmost child, and so on, until we reach a leaf (childless) node. We then move back to the parent of the leaf and visit the leftmost unvisited child. We proceed in this manner until the entire tree is visited. For axample, consider the tree with the root at A shown below. The preorder traversal of this tree is A-B-E-F-C-G-D-H-I-J. Now, each occurrence of a hierarchical tree can be stored as a physical record of variable length. The nodes of the tree are being stored in preorder.

A B E F C G H D I J E B F C G

A D H I J

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Tree

Preorder Traversal

Data Base Notes Chap ter_2 (23 / 26) ___________________________________________________________________________________

There are two different get commands for locating records in a database tree. The simplest command has the form : get first < record type> where <condition> The where clause is optional. The attached <condition> is a predicate that may involve any record type which is either an ancestor of <record type> or the <record type> itself. The get command locates the first record (in preorder) of the type <record type> in the database that satisfies the <condition> of the where clause. If the where clause is omitted, then the first record of type <record type> is located. Once such a record is found, the currency pointer is set to point to that record, and the content of that record is copied into the program work-area. If no record exists in the database, then the search is fials and the variable DB-status is set to error message.

Example : Construct the database query that prints the address of customer
Omer. get first customer where customer.name = Omer ; print (customer.street, customer.city);

Example : Construct the database query that prints an account belonging to Ali
with balance greater than $1000 (if one such exist). get first account where customer.name = Omer and account.balance >1000 ; if DB-status =0 then print (account.number);

There may be several similar records in the database that we wish to retrieve. The get first command locate one of these. In order to locate the other database records, the following command can be used: get next < record type> where <condition> This command locates the next record that satisfies <condition>. If the where clause is omitted, then the next record of the type <record type> is located.

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (24 / 26) ___________________________________________________________________________________

Example : Construct the database query that prints the account number of all
the account with a balance greater than $500 (if one such exist). get first account where account.balance >500 ; while DB-status =0 do begin print (account.number); get next account where account.balance > 500; end.

There are many circumstances where we wish to locate one record within a particular subtree. That is, we want to limit the search to one specific subtree rather than the entire database tree. The root of the subtree in question is the last record which was located with either the get first or get next command. The get command to locate a record within that subtree has the form get next within parent < record type> where <condition> which locates the next record (in preorder) which satisfies <condition> in the subtree whose root is the parent of current of <record type>. If the where clause is omitted, then the next record of type <record type> within the designed subtree is located.

Example : Construct the database query that prints the total balance of all
account belonging to Abdulla. Sum := 0; get first customer where customer.name = Abdulla; get next within parent account; while DB-status =0 do begin sum := sum + account.balance; get next within parent account; end; print (sum);

Creating New Records

In order to insert a record of type < record type> into the database, we must first set the appropriate values in the corresponding < record type> work-area template. Once this is done, we add this new record to the database tree by

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (25 / 26) ___________________________________________________________________________________ insert <record type> where <condition> If the where clause is included, the system searches the database tree for a record that satisfies the <condition> in the where clause. Once such a record, say X, is found the newly created record is inserted in the tree as the leftmost child of X. If the where clause is omitted, the record is inserted in the first position (in preorder) in the database tree.

Example :

Adding a new customer, Omer, to the Arwa branch. customer.name := Omer; customer.street := Road_1; customer.city := Aden; insert customer where branch.name = Arwa;

Modifying and Deleting a Record

In order to modify an existing record of type < record type>, we must get that record into the work-area template for <record type> and change the desired fields in that template. Then reflect the changes in the database by executing :

replace

The DL/I language requires that prior to modifying a record, the get command must have additional clause hold so that the system is aware of the fact that a record is to be modified.

Example :

Change the street address of Abdulla to Main_Road. Get hold first customer; where customer.name = Abdulla; customer.street := Main_Road; replace;

In order to delete a record of type <record type>, the currency pointer must be set to point to that record. Following this, we can delete that record by executing:

delete Example :
Delete account 561. Get hold first account; where account.number = 561 ; delete ;

A delete operation deletes not only the record in question but the entire sub_tree rooted by that record.

Virtual Records
We have seen that in the case of many-to-many relationships, record replication is necessary to preserve the tree-structure organization of the database. However, to overcome the drawbacks of this replications a virtual record is used. Such a record contains no data value, it does contain a logical pointer to a particular physical record. When a record is to be replicated in several database trees, we

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chap ter_2 (26 / 26) ___________________________________________________________________________________ keep a single copy of that record in one of the trees and replace every other record with a virtual record containing a pointer to that physical record.

Mapping Hierarchies to Files

A straightforward technique for implementing the instance of a tree-structure diagram is to associate one pointer with a record for each child that the record has. However, it is not an ideal structure for the implementation of the hierarchical database, since a record may have an arbitrary number of children. Thus, fixed-length records become variable-length records. Instead, we may use leftmost-child and next-sibling pointers. A record has only two pointers. The leftmost-child pointer points to one child. The next-sibling pointer points to another child of the same parent.

leftmost next-sibling

leftmost

_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University