Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Entity-Relationship Model ER-Diagrams Weak entity sets 1 Outline: Conceptual modeling using ER-model •Data modeling •Entity-relationship model - Entity types - strong entities (regular) - weak entities - Relationships among entities - Attributes - attribute classification - Constraints - degree - cardinality constraints - participation constraints -… 2 Database design Database design is an important and challenging task. The relational model is the model used by RDMBS. Is the relational model the best model used by businessmen to describe their business (logics)? 3 Is relational model suitable for database designers? While a simple data model that is consisting of only a few tables can be created "manually“, a large application needs a more systematic approach. While the relational data model of the RDBMS still hides many details, it is nonetheless closer to how the RDBMS stores data than to how a user thinks about the underlying enterprise. 4 Different levels call for different data models Good design requires a thorough understanding the data associated with an enterprise and how they are used, as well as a solid understanding of the functionalities of your DBMS (Oracle in our case) At least two levels understanding here! • Application • implementation 5 Conceptual Semantic data models are needed to bridge the gap and assist the database design process. Being syntactically correct does not mean being semantically correct. 6 Conceptual modeling A high-level conceptual model provides concepts for describing the database structure that are close to the way users perceive data. A conceptual schema describes the structure of the database by hiding the details of physical storage structures. Conceptual modeling is the process of creating a conceptual schema using a highlevel conceptual model. 7 The main phases of database application Design Functional Analysis Functional Analysis Mini World Requirements Collection and Analysis Database Requirements High level transaction specification Conceptual Design Conceptual Schema (high level) DBMS-independent Logical Design (Data Model Mapping) DBMS-specific APPLICATION PROGRAM DESIGN Logical Schema (in the data model of a sepcific DBMS) Physical Design TRANSACTION IMPLEMENTATION Internal Schema Application programs 8 Example The company database keeps track of a company’s employees, departments, and projects: Requirements: concerning the department: 1. 2. 3. 4. 5. The company is organized into departments Each department has a unique name, a unique number, and a specific employee is its’ manager we track the start date for the manager function a department may be in several locations a department controls a number of projects concerning the project: 6. a project has a unique name, a unique number, and is in a single location 9 example continued concerning the employee: 7. each employee has a name, social insurance number, address, salary, sex, and birth date 8. an employee is assigned to one department but may work on several projects which are not necessarily controlled by the same department 9. we track the number of hours per week that an employee works on each project 10. we keep track of the direct supervisor of each employee 11. we track the dependents of each employee (for insurance purposes) concerning the dependent: 12. we record each dependent’s first name, sex, birth date, and relationship to the employee 10 ER model concepts The Entity-Relationship (ER) model is a popular high-level conceptual model which helps describe a real application scenario in a pictorial format. It employees the notions of entities, attributes and relationships, as well as constraints. This model and its variations are frequently used for the conceptual design of database applications, and many database design tools employ its concepts. It was introduced by P. Chen (bit.csc.lsu.edu/~chen) in "The Entity-Relationship model - Toward a Unified Views of Data", TODS 1:1, March 1976. 11 Purpose of E/R Model The E/R model allows us to sketch the design of a database informally. Designs are pictures called entityrelationship diagrams. Fairly mechanical ways to convert E/R diagrams to real implementations like relational databases exist. 12 Entity (entities) Entity = “thing” or object. An entity is a specific object or thing in the mini-world (for instance, a company) with an independent existence. Example: the EMPLOYEE entity David, the research DEPARTMENT, the product X PROJECT 13 Entity Set & Entity type Entity type defines the data type of a collection of entities having the same attributes (that are of the same type). Similar to a class in object-oriented languages. Entity set = collection of similar entities of a particular entity type in the database at any point in time. The same name is used for both the entity type and its entity set. They are interchangeably used when the context is clear. 14 Attributes Attribute = property of an entity set. Generally, all entities in a set have the same properties. Attributes are simple values, e.g. integers or character strings. Attributes are properties used to describe an entity. Example: an EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate. A specific entity has a value for each of its attributes. Example: a specific EMPLOYEE entity may have name='Kelly David', SSN='12321312', Address='733 Spruce str. Oneonta, NY', Sex='M', Birthdate='08-Jan-1980'. 15 Types of attributes Simple (Atomic) Vs. Composite (compound) Single-valued vs. Multi-valued Stored vs. Derived Attributes Nesting composite and Multi-valued attributes. 16 Atomic vs. Composite Atomic attri: Each entity has a single atomic value for the attribute. These attributes are not divisible. Example: SSN or Sex Composite attribute: The attribute may be composed of several components. Example: • Address (Apt#, House#, Street, City, State, ZipCode, Country) • Name (FirstName, MiddleName, LastName) The value of a composite attributes is the concatenation of the values of its component simple attributes. 17 Composition may form a hierarchy where some components are themselves composite. 18 Single-valued vs. Multivalued Single-valued attri: It has a single value for a particular entity. Example: Age. Mutli-valued: An entity may have multiple values for that attribute. Example: Color of a Car or PreviousDegrees of a STUDENT. Set Notation: {color} or {previous degrees} 19 Stored vs. Derived Attributes Derived attribute: An attribute whose value can be derived from the value of another attribute (the latter is called stored attribute). Example: Age(Derived) and BirthDate(Stored) attributes. Remark: The values of some attributes can be derived from related entities. Example: The attribute NumberofEmployees of a DEPARTMENT entity can be derived by counting the EMPLOYEE entities of this department. 20 Nesting composite and Multivalued attributes Depending on how you model attributes, won’t be discussed here. 21 Null values In some cases a particular entity may not have an applicable value for an attribute. In such situations a special value NULL is used. Example, for the ApartmentNumber attribute of an address of a student 22 When NULL values will be used. There are different meanings and reasons for null values. NULL Not applicable missing unknown Not known 23 E/R Diagrams In an entity-relationship diagram, each entity set is represented by a rectangle. Each attribute of an entity set is represented by an oval, with a line to the rectangle representing its entity set. 24 Example name salary Employee Entity set (Entity type) employees has two attributes, name and salary (manufacturer). Each specific employee entity has values for these two attributes (name an example). 25 The entities: employee dependent department project 26 The entities: fname minit lname name sex ssn dependent salary address employee name sex birthdate relationship bdate name number location department project name number location 27 Relationship types A relationship type among n entity types E1,…,En defines a set of associations ( a relationship set) among entities from these types. Example: For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. 28 Relationship Types A relationship set is a set of relationship instances where each relationship instance associates entities, one from each participating entity type. 29 Relationship Set The current “value” of an entity set is the set of entities that belong to it. Example: the set of all employees in our database. The “value” of a relationship is a set of lists of currently related entities, one from each of the related entity sets. 30 Example For the relationship works_on, we might have a relationship set like: Employee 112322 Project project1 31 Relationships A relationship connects two or more entity sets. It is represented by a diamond, with lines to each of the entity sets involved. 32 With relationships: 1 N department works for 1 1 employee supervisee manages 1 supervision controls N supervisor N 1 N M works on 1 project dependents of N dependent partial constraint total constraint 33 name number With attributes, etc: fname name ssn 1 lname minit sex startdate employee N 1 1 hours supervisee N M 1 supervision number of employees controls manages 1 supervisor department works for N salary address bdate degree location location works on dependents of project name number location N dependent name sex birthdate relationship 34 ERD symbols Entity Weak entity Relationship Identifying relationship name Attribute name Key attribute 35 ERD symbols name Composite attribute name Derived attribute name Mutlti-valued attribute Partial participation Total participation 1:N Cardinality 36 There are several ways of classifying relationships, according to the degree, cardinality, participation constraint (mandatory or optional), whether recursion is involved, and whether or not relationship is identifying weak entities. 37 Relationship types The degree of a relationship type is the number of participating entity types. When we speak of a student enrolling in a course, we are discussing a relationship, enroll in, where two entity sets (STUDENT and COURSE) are involved; the relationship is of degree 2 because each instance of enroll in will always involve one student entity and one course entity. Both MANAGES and WORKS_ON are binary relationship types. 38 Multiway Relationships Sometimes, we need a relationship that connects more than two entity sets. Suppose that suppliers will provide parts for projects. binary relationships do not allow us to make this distinction. But a 3-way (ternary) relationship would. 39 Example name license addr name supplier id parts supply projects name addr 40 Cardinality ratio The cardinality ratio for a binary relationship specifies the number of relationship instances an entity can participate in. Some times cardinality ratio is also called “Multiplicity” or “cardinality” Possible cardinality ratios for binary relationships are 1:1, 1:N, M:N. 41 One-One Relationships In a one-one relationship, each entity of either entity set is related to at most one entity of the other set. Example: Relationship couple 42 Many-One Relationships Some binary relationships are many one from one entity set to another. Each entity of the first set is connected to at most one entity of the second set. But an entity of the second set can be connected to zero, one, or many entities of the first set. 43 Example Let us assume manages, from department to employee is many-one. A department has at most one employee as its head. But an employee can head any number of departments, including zero. 44 Many-Many Relationships Think of a relationship between two entity sets, such as works_on between employees and projects. In a many-many relationship, an entity of either set can be connected to many entities of the other set. E.g., an employee works on many projects; a project needs many employees. 45 In Pictures many-many M:N many-one one-one N:1 1:1 46 An example of an Entity Relationship Model: Entities are indicated using rectangular shapes, and relationships between entities are shown with a diamond shape on a line connecting the entities. m n Enroll-in Students Course Entity sets are shown with a rectangular shape. Relationship sets are shown with a diamond shape. The "m" indicates that one course may have many students enrolled in it. The "n" indicates that one student may have enrolled in many courses. 47 Suppose we know of four student entities and two courses entities. For example, four students named John, Amelia, Lee, and April, and two courses “Intro to Art” and “Intro to History”. Information about these is listed below. 48 Students Name Id# Phone John Amelia Lee April 184 337 876 901 283-4984 838-3737 933-2211 644-3838 Course Name Course# Dept Intro to Art 661 Intro to History 765 Art History 49 We can represent these two sets of entities using set diagrams. John Intro to Art Amelia Intro to History Lee April set of students set of courses Relationships describe how entities relate to one another 50 Suppose we have the two courses and four students listed previously. Suppose also that - John and Amelia are enrolled in Intro to Art - John and Lee are enrolled in Intro to History - April is not enrolled in any course. Below, we depict a relationship set and show the four instances of an enroll in relationship. 51 John Amelia Lee Intro to Art Intro to History April 52 Participation Constraints Two types: Total participation (also called existence dependency) and Partial participation. The participation of an entity type E to a relationship type is a total participation if every instance of E is associated with an instance of the relationship type. Otherwise, it is a partial participation. 53 Participation Example: The participation of Department to manages is total; while the participation of Employee to Manages is partial. 54 Recursive Relationships If an entity has a relationship with another entity of the same entity set, then we have a recursive relationship. Of the relationship types, these are the most difficult to master. Some situations where recursive relationships can be used: • An employee supervises other employees • A person marries another person • A person is a child of a person • A course is a prerequisite for another course • A team plays against another team • Organizational units report to other organizational units • A bill-of-materials system, where a part is composed of other parts. 55 Recursion in a data model is an especially difficult topic. We have a recursive relationship if the same entity set appears more than once in a relationship. superviser Employee 1 N supervised supervises Any instance of this relationship involves two employees, and so it is a recursive relationship. In this relationship, one employee is designated the ‘supervisor’ and the other as the ‘supervised’. Employee fills two roles in this relationship. 56 Previously, we briefly examined the first case above: “An employee supervises another employee”. An instance of the supervises relationship involves two entities from the same entity set. See the following figure, where five examples of the supervise relationship are depicted in a reporting hierarchy. John Lee Peter Don Noel Mary The reporting hierarchy informs us: John does not have supervisor John supervises Lee John supervises Peter John supervises Noel Lee does not supervise anyone Noel does not supervise anyone Peter supervises Don Peter supervises Mary Don does not supervise anyone Mary does not supervise anyone 57 superviser Employee 1 N supervised supervises ERD for the supervises relationship. Optionality specifications allow for: at least one employee does not have a supervisor some employees do not supervise others 58 Now consider the second example listed above: “A person marries another person”. You must be certain of the business rules that are valid for the miniworld you are concerned with. Depending on that miniworld, you model marries as 1:1, 1:m, or m:n. Is the relationship “A person marries another person”, 1:1, 1:m, or m:n? Person 1 1 marries What is the cardinality of this relationship? 1:1 ? 1:m ? m:m ? 59 Now consider the second example listed above: “A person marries another person”. You must be certain of the business rules that are valid for the miniworld you are concerned with. Depending on that miniworld, you model marries as 1:1, 1:m, or m:n. Is the relationship “A person marries another person”, 1:1, 1:m, or m:n? Person 1 1 marries What is the cardinality of this relationship? 1:1 ? 1:m ? m:m ? 60 If you say 1:1, then only the current marriage for people is of interest in your miniworld. A recursive 1:1 relationship allows two entities of the same entity set to be related, but a given entity can only be related to one other entity. Consider the following figure, where we illustrate 5 persons, and the relationship set showing two marriages involving two people each. The fifth person is not related to another person through this relationship. Does the model allow for a person marrying themselves? Yes, it does, but that would be against the ‘rules’. To ensure that no one accidentally records such an instance in your database, you would need supporting code in the database to ensure it doesn’t occur. 61 A person can be represented using the following diagram. perFirstName perInitials personId perName perLastName Person perGender 62 Since marries is an association between two people (two instances of Person) we understand marries is a recursive relationship perFirstName perInitials personId perName 1 marries perLastName Person 1 perGender Since we are only interested in someone’s current marriage partner, we understand that a person is associated with at most one other person via marries 63 John April Lee Alex Each person is involved in no more than one ‘marries’ relationship Amelia Entity Set Person Relationship Set marries 64 If you said m:n, then you are tracking of all marriages, past and present, for people in your miniworld; you are allowing for people to remarry and you are keeping track of all their marriages. The following figure shows John and Amelia being involved in two marries relationships. A datum that is recorded for marriages, is the date the ceremony occurred. Where would that be kept in the model? We will address that soon, in the section on attributes of relationships. John April Two of these entities are involved in more than one ‘marries’ relationship. Lee Alex Amelia Entity Set Person Relationship Set marries 65 Since marries is an association between two people (two instances of Person) we understand marries is a recursive relationship perFirstName perInitials personId perName N marries perLastName Person M perGender Since we are only interested in someone’s current marriage partner, we understand that a person is associated with at most one other person via marries 66 Weak Entity Sets Occasionally, entities of an entity set need “help” to identify them uniquely. Entity set E is said to be weak if in order to identify entities of E uniquely, we need to follow one or more manyone relationships from E and include the key of the related entities from the connected entity sets. 67 Example name is almost a key for football players, but there might be two with the same name. number is certainly not a key, since players on two teams could have the same number. But number, together with the Team related to the player by Plays-on should be unique. 68 In E/R Diagrams name number Players n name Playson Teams 1 • Double diamond for supporting many-one relationship. • Double rectangle for the weak entity set. 69 Weak Entity-Set Rules The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets. E.g., player-number and team-name is a key for Players in the previous example. 70 Weak entity types An entity type that does not have a key attribute A weak entity type must participate in an identifying relationship type with an owner or identifying entity type. Entities are identified by the combination of: A partial key of the weak entity type. The particular entity they are related to in the identifying entity type. 71 One more example of weak entity type Suppose that a DEPENDENT entity is identified by the dependent’s first name, and the specific employee that the dependent is related to. DEPENDENT is a weak entity type with EMPLOYEE as its identifying entity type via the identifying relationship type DEPENDENT_OF. 72 Attributes on Relationships Sometimes it is useful to attach an attribute to a relationship. Think of this attribute as a property of tuples in the relationship set. 73 A convention some modelling tools and designers use is shown below. In this case, they are using a composite entity set (the relationship symbol is enclosed in the entity set symbol). Their intention is to show that marries is both a relationship and an entity set. We will be using this notation. MarDate Person N M marries MarLocn MarOfficial 74 Example Employees Works_on Projects Hours Hours is an attributes of works_on, not … 75 Roles (related to recursion) Sometimes an entity set appears more than once in a relationship. Label the edges between the relationship and the entity set with names called roles. 76 Example Relationship Set Husband Bob Joe … Married husband Wife Ann Sue … wife 1 employees 1 77 Example Relationship Set Buddies B A Buddya Bob Joe Ann Joe … Buddyb Ann Sue Bob Moe … employees 78 Keys A key is a set of attributes for one entity set such that no two entities in this set agree on all the attributes of the key. It is allowed for two entities to agree on some, but not all, of the key attributes. We must designate a key for every regular entity set. A weak entity set alone might not have keys. 79 Keys in E/R Diagrams Underline the key attribute(s). 80 Example: name is Key for Beers SSN employee name 81 Example: a Multi-attribute Key dept number hours room Courses • Note that hours and room could also serve as a key, but we must select only one key. 82 remarks A key of an entity type is a constraint that all instances of the entity type have to satisfy. 83 Example: Good name projects ssn Works_on name Employee This design gives the name of each manufacturer exactly once. 84 Example: Bad name projects ssn Works_on name employee Employee name This design states the employee name twice. 85 Example: Bad Projct name ssn Employees name Works_on This design repeats the projects name once for each participating employee; loses the project if there are temporarily no participants. 86 Entity, Relationship or attributes How deep you understand ER model Rule of Thumb, (informal rules) a noun could be modeled as entity or an attributes An action (transitive verb) could be modeled as an relationship. An action (intransitive verb) could be an attributes or an relationship Practice & Experience 87 Various constraints Degree Cardinality Participation Weak entity Roles … 88 Design Techniques 1. Avoid redundancy. 2. Minimum null values in tuples 3. Limit multivalued attributes 1. If you have to, make sure how to map them to tables, attribute values should be atomic. 4. Limit the use of weak entity sets. 1. If you have to, make sure how to map them to tables. 5. Don’t use an entity set when an attribute will do. 89 Avoiding Redundancy Redundancy occurs when we say the same thing in two different ways. Redundancy wastes space and (more importantly) encourages inconsistency. The two instances of the same fact may become inconsistent if we change one and forget to change the other, related version. 90