Sunteți pe pagina 1din 16

Data Base Notes Chapter_2 (1 / 16) ___________________________________________________________________________________

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

Data Base Notes Chapter_2 (2 / 16) ___________________________________________________________________________________

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

Data Base Notes Chapter_2 (3 / 16) ___________________________________________________________________________________

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

Data Base Notes Chapter_2 (4 / 16) ___________________________________________________________________________________

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 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
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chapter_2 (5 / 16) ___________________________________________________________________________________

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

Fig C : One-to-One relationship


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

Data Base Notes Chapter_2 (6 / 16) ___________________________________________________________________________________

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

worker

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

Data Base Notes Chapter_2 (7 / 16) ___________________________________________________________________________________

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 name street city CustAcct number

account balance

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

Data Base Notes Chapter_2 (8 / 16) ___________________________________________________________________________________

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

Data Base Notes Chapter_2 (9 / 16) ___________________________________________________________________________________

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. 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).

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

Data Base Notes Chapter_2 (10 / 16) ___________________________________________________________________________________

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; 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..
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chapter_2 (11 / 16) ___________________________________________________________________________________

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 customer of the Arwa
branch of the National bank. 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; member is customer;

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

Data Base Notes Chapter_2 (12 / 16) ___________________________________________________________________________________

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 account 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

Data Base Notes Chapter_2 (13 / 16) ___________________________________________________________________________________

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;

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.
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chapter_2 (14 / 16) ___________________________________________________________________________________

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; get account; find owner within CustAcct; disconnect account from CustAcct;
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University

Data Base Notes Chapter_2 (15 / 16) ___________________________________________________________________________________

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

Aziz

55-88

Sanaa

199

30000

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

Data Base Notes Chapter_2 (16 / 16) ___________________________________________________________________________________

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.

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

S-ar putea să vă placă și