Documente Academic
Documente Profesional
Documente Cultură
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.
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
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
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
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
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
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
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
street city
Social_security
name customer
CustAcct
account
street city
Social_security
name customer
CustAcct
account
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
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
account balance
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University
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
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
account
AccDate
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University
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
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:
_________________________________________________________________________________
Dr. Mohammed Fadle Abdulla Computer Sci & Engg. Department, Aden University
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);
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
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>)
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>).
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
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;
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 : 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;
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
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