M359 Block4 - Lecture11 Eng/ Waleed Omar. Database life cycle

Size: px

Start display at page:

Download "M359 Block4 - Lecture11 Eng/ Waleed Omar. Database life cycle"

Franklin Chapman
5 years ago
Views:

Database life cycle EXERCISE 3.3 What is the principal difference between a conceptual data model and the relational representation of the conceptual data model?

several values per occurrence. Wards:- "The hospital is organized into a number of wards, each of which may be empty or may be occupied by one or more patients.

1 Database life cycle EXERCISE 3.3 What is the principal difference between a conceptual data model and the relational representation of the conceptual data model? SOLUTION The conceptual data model describes what relationships exist between the data, whereas the relational representation of the conceptual data model describes how these relationships could be implemented using foreign keys. Distinguishing SVFs & MVFs A Single-Valued Fact (SVF) is a fact of an entity type which can take a single values per occurrence A multi-valued fact (MVF), is a fact of an entity type which can take several values per occurrence. Wards:- "The hospital is organized into a number of wards, each of which may be empty or may be occupied by one or more patients. Each ward is identified by a ward number; it has a name and contains a fixed number of beds. Each ward is staffed by one or more nurses." Ward(WardNo,WardName,NumberOfBeds) اكتشاف الجداول والحقول والعلاقات من السیناریو:- Nurses Each nurse is identified by a staff number and has a name. A nurse is assigned to a single ward. Some nurses are designated to supervise one or more other nurses on the same ward. A nurse has at most one supervisor. Page 1

Nurse(StaffNo,NurseName) Patients "Each patient in the hospital has a

responsibility of) a single doctor who must have a position of consultant.

2 Nurse(StaffNo,NurseName) Patients "Each patient in the hospital has a patient identification number and name recorded, their gender, height and weight is kept on record. Each patient is assigned to a single ward and is under the care of (is the responsibility of) a single doctor who must have a position of consultant... A patient may receive more than one treatment from each doctor..." Patient(PatientID,PateintName,Gender,Height,Weight) Page 2

v single-valued properties of an entity type are represented in the E-R model by either: oan attribute of that entity type oor a :1 relationship with another (or the same) entity type.

3 v single-valued properties of an entity type are represented in the E-R model by either: oan attribute of that entity type oor a :1 relationship with another (or the same) entity type. v multi-valued properties of an entity type are represented by: oa :n relationship with another (or the same) entity type. ==================================================================== Optional properties If a single-valued property is optional, we represent it by a new entity type connected by a relationship with optional participation. Example: We represent the single valued property that Consultants must have a specialism, but registrars and house officers are not specialists and do not have a specialism by introducing the Specialist entity type to record the specialisms of consultants. The 1:1 relationship IsA between Doctor and Specialist has optional participation with respect to Doctor, denoting that not every doctor will be a specialist ==================================================================== مھم Weak entity types whose entities cannot exist without there being occurrences of another related entity type. 1. Have a mandatory relationship with another entity type (the owner). 2. The identifier of that entity type is the same as, or a subset of, the weak entity type, and 1 3. The owner entity type is at the :1 end of this relationship. In the Hospital conceptual data model, Specialist is a weak entity type since: 1. it has mandatory participation with respect to the relationship IsA with the Doctor entity type, 2. it has the same identifier as the Doctor entity type, and 3. Its owner is at a :1 end with the IsA relationship Doctor(StaffNo,DoctorName,Position) Specialist(StaffNo,Specification) Page 3

4 EXERCISE 3.13 Why is Treatment a weak entity type? Solution: Because it has mandatory participation with respect to the n:1 relationships with the Doctor and Patient entity types, Provides and Receives respectively, and the identifiers of the Doctor and Patient entity types are subsets of the identifier of the Treatment entity type. Entity subtypes Entity supertypes are abstract concepts and have no occurrences and serve solely to define the properties common to all of their subtypes. The properties of a supertype are inherited by all of its subtypes. Entity subtypes, of which there must be at least two, are concrete concepts in that they may have occurrences and define the properties specific to that particular entity subtype. Entity Supertype Entity Subtype Doctor (StaffNo, DoctorName) JuniorDoctor (Position) Consultant (Specialism) Mutual exclusivity As the identifier is defined in the supertype, occurrences of all of the subtypes are mutually exclusive. Replacing attributes by subtypes Doctor (StaffNo, DoctorName) JuniorDoctor ( ) HouseOfficer ( ) Registrar ( ) Consultant (Specialism) Page 4

EXERCISE 3.16 As both doctors and nurses can be considered as medical staff working in the hospital. Introduce a new supertype named, say, MedicalStaff, to represent the staff structure.

5 EXERCISE 3.16 As both doctors and nurses can be considered as medical staff working in the hospital. Introduce a new supertype named, say, MedicalStaff, to represent the staff structure. Solution:- MedicalStaff (StaffNo, Name) Doctor ( ) JuniorDoctor ( ) HouseOfficer ( ) Registrar ( ) Consultant (Specialism) Nurse ( ) ==================================================================== Exclusive and inclusive relationships:- Exclusive relationships are two or more relationships connecting a single entity type with two or more other (possibly the same) entity types where each occurrence of the single entity type participates in exactly one (or possibly none) of the relationships. تعني أن الجدول یرتبط بجدول واحد من الاثنین ولا یمكن یرتبط مع الاثنین في نفس الوقت. Inclusive relationships are two or more relationships connecting a single entity type with two or more other (possibly the same) entity types where each occurrence of the single entity type participates in all (or possibly none) of the relationships. The relationships R1 and R2 could have a degree of 1:1, 1:n or m:n, and the participation conditions of B1 and B2 with respect to R1 and R2 could be either optional or mandatory. Optional exclusive If R1 and R2 are optional exclusive relationships with respect to A, then we use the condition: Either or none: An occurrence of A is associated either with an occurrence of B1 via the R1 relationship or with an occurrence of B2 via the R2 relationship, or with neither, but not with both. الجدول A یرتبط مع الجدول B1 أو الجدول B2 أو لا یرتبط بھم الاثنین ولكن لا یرتبط مع الاثنین في نفس الوقت. Page 5

Mandatory exclusive If R1 and R2 are mandatory exclusive relationships with respect to A, then we use the condition: Optional inclusive Either: An occurrence of A is associated either with an

If R1 and R2 are optional inclusive relationships with respect to A, then we use the condition: Both, or none: An occurrence of A is associated with both an occurrence of B1 via the R1 relationship

6 Mandatory exclusive If R1 and R2 are mandatory exclusive relationships with respect to A, then we use the condition: Optional inclusive Either: An occurrence of A is associated either with an occurrence of B1 via the R1 relationship or with an occurrence of B2 via the R2 relationship, but not with both. الجدول A یرتبط مع الجدول B1 أو الجدول B2 ولابد أن یرتبط مع أحدھم فقط. If R1 and R2 are optional inclusive relationships with respect to A, then we use the condition: Both, or none: An occurrence of A is associated with both an occurrence of B1 via the R1 relationship and an occurrence of B2 via the R2 relationship, or with neither. Mandatory inclusive الجدول A یرتبط مع الجدولین B1 و B2 في نفس الوقت أو لا یرتبط مع الجدولین. If R1 and R2 are mandatory inclusive relationships with respect to A, then: Both: It means that each occurrence of A participates in both relationships B1 and B2. No need for additional constraints الجدول A لابد أن یرتبط مع الجدولین B1 و B2 في نفس الوقت Exclusivity and inclusivity between two entity types Exclusivity and inclusivity are properties of the roles that the single entity type (A) plays. We must specify which direction we are reading the diagram, i.e. which one is considered this single entity type ConsistsOf and HeadedBy are mandatory inclusive relationships with respect to the Team entity type because Team has mandatory participation with respect to both relationships. These inclusive relationships represent the following requirements specified in the Hospital scenario: ConsistsOf and HeadedBy are mandatory exclusive relationships with respect to the Doctor entity type because of the following condition that is specified in the additional constraints section of the Hospital conceptual data model: c.3 A consultant must head a team. Doctors who are not consultants must be members of a team. That is, every doctor will have to participate in either relationships, but not both. Page 6

7 EXERCISE 3.19 How do we distinguish between occurrences of the StaffedBy relationship, one from another? SOLUTION Each occurrence of the StaffedBy relationship represents a particular nurse assigned to a particular ward, which is identified by the combination of WardNo and StaffNo values of the corresponding occurrences of the Ward and Nurse entity types involved in that occurrence of the StaffedBy relationship. Example:- Suppose we wish to add a date on which a particular nurse was assigned to a particular ward. This is a property of the relationship type StaffedBy One approach would be simply to add an attribute, say StartDate, to the entity type Nurse at the :n end of the StaffedBy relationship; Nurse (StaffNo, NurseName, StartDate) Another approach is to represent the StaffedBy relationship by an intersection entity type, and record the date by a non-identifying attribute. Ward (WardNo, WardName, NumberOfBeds) WardStaff (StaffNo, StartDate) Nurse (StaffNo, NurseName) Page 7

Representing multi-valued properties A work rota can be represented by extending the E-R model as follows: Ward (WardNo, WardName, NumberOfBeds) WardStaff (StaffNo, StartDate) Shift (StaffNo,

8 Representing multi-valued properties A work rota can be represented by extending the E-R model as follows: Ward (WardNo, WardName, NumberOfBeds) WardStaff (StaffNo, StartDate) Shift (StaffNo, WeekDay, ShiftTime) Nurse (StaffNo, NurseName) ==================================================================== Guidelines for representing the properties of relationships:- A mandatory single-valued property of, a relationship is recorded by an attribute of an intersection entity type. An optional single-valued property of a relationship is represented by a 1:1 relationship between an intersection entity type and another entity type recording the property with optional participation by the intersection entity type. A multi-valued property of a relationship is represented by a 1:n relationship between an intersection entity type and another entity type recording the property. The participation condition of the intersection entity type is determined by whether the property is optional or mandatory for occurrences of the relationship Temporal properties Temporal properties are those multi-valued properties of entity types where each value is dependent on time. For example, the treatment given to a patient is a multi-valued (multiple treatments) and temporal (StartDate) property of Patient. A patient may receive more than one treatment from each doctor, for which the start date and the reason for the treatment... Are recorded. Representing temporal (historical) properties Let us remove the following limitation: l.1 Only the details of a patient s current stay in hospital are recorded (i.e. only as an inpatient with no patient history of previous stays in the hospital). Our approach will be to consider each property of Patient. If it is a temporal property, then we will consider how it can be represented by revising the Hospital conceptual data model Page 8

9 Temporal properties of patient PatientId should not change over time PatientName could change over time Gender is unlikely to change over time. Height could change over time Weight could change over time EXERCISE 3.23 Assuming that a patient s height and weight are always both measured on the same day, how should we modify the Hospital conceptual data model to record a history of changes to a patient s height and weight? Solution:- Since we are representing a multi-valued property, according to our guidelines this should be conveyed by a :n relationship with another entity type that records the series of historical heights and weights for each patient. Because it is a temporal property, the identifier of this entity type will include an attribute that specifies the dates that particular patients heights and weights were measured. Patient (PatientId, PatientName, Gender) Height&Weight (PatientId, Date, Height, Weight) Single-valued properties represented by a :1 relationship:- Each patient is assigned to a single ward. :1 relationship OccupiedBy with the Ward is also a temporal property because a patient may be assigned to different wards Entitytypes Ward(WardNo,WardName,NumberOfBeds) WardPatient(PatientId, StartDate,EndDate) Patient(PatientId,PatientName,Gender,Height,Weight) Derivable properties (secondary data) are properties whose values can be calculated from other data values are not usually included in an entity relationship model Derived data may still be stored in the database for reasons of usability and/or efficiency Page 9

Value sets For each attribute, we need to establish the set of permissible data values that the attribute may hold. A value set may be infinite or finite {n} and {n.

10 Value sets For each attribute, we need to establish the set of permissible data values that the attribute may hold. A value set may be infinite or finite {n} and {n.n} denote positive integers and real numbers, respectively, and {1...n} for the continuous unbounded sequence {1, 2, 3, 4,...}. Note that { } defines a numerical value set, whereas { } defines the value set of all permutations of three digit-strings. Value sets are recorded in the domain of discourse summary ==================================================================== Analyzing text Analyzing the Hospital scenario The first step is to scan the text to identify all the nouns and noun phrases. In the following copy of the Hospital scenario all the nouns and noun phrases are underlined. Second step: Reduce the list of candidate entity types and properties v discard the following: entity types that are outside the scope of the database that will only have one occurrence. entity types that have the same properties as another entity type because they are simply different names for the same thing entity types that that convey implementation details, Values associated with attributes of entity types. Page 10

There are four different kinds of constraint in SQL:- A not null constraint requires that each entry in a column is not NULL.

There are four different kinds of constraint in SQL:- A not null constraint requires that each entry in a column is not NULL. القیود Constraints Constraints are used to preserve the integrity of the database. SQL allows us to define constraints for use by a DBMS in maintaining the integrity of the database. Constraints in SQL