Download to read offline
Uploaded bySoumyajit Dutta
Er model
The document discusses key concepts in entity-relationship (ER) modeling including: - Entities can represent real-world objects and have attributes that identify them. Common entities in a school database may be students, teachers, classes, and courses. - Relationships define associations between entities, such as a student enrolling in a course. Relationships have cardinalities that specify how many entities can be connected. - Attributes of entities can be simple, composite, derived or multi-valued. Keys uniquely identify entities and can be candidate or primary keys. - ER diagrams visually represent these concepts through entities, relationships, and attributes.
More Related Content
Er model
- 2. Introduction The ERmodel defines the conceptual view of a database. It works around real-world entities and the associations among them. At view level, the ER model is considered a good option for designing databases.
- 3. Basic Terms Anentity can be a real-world object, either animate or inanimate, that can be easily identifiable. For example, in a school database, students, teachers, classes, and courses offered can be considered as entities. All these entities have some attributes or properties that give them their identity
- 4. Basic Terms Entitiesare represented by means of their properties, called attributes. All attributes have values. For example, a student entity may have name, class, and age as attributes.
- 5. Types of Attributes Simple attribute − Simple attributes are atomic values, which cannot be divided further. For example, a student's phone number is an atomic value of 10 digits. Composite attribute − Composite attributes are made of more than one simple attribute. For example, a student's complete name may have first_name and last_name. Derived attribute − Derived attributes are the attributes that do not exist in the physical database, but their values are derived from other attributes present in the database. For example, average_salary in a department should not be saved directly in the database, instead it can be derived. For another example, age can be derived from data_of_birth.
- 6. Types of Attributes Single-value attribute − Single-value attributes contain single value. For example − Social_Security_Number. Multi-value attribute − Multi-value attributes may contain more than one values. For example, a person can have more than one phone number, email_address, etc.
- 7. Basic Terms Entity-Setand Keys Key is an attribute or collection of attributes that uniquely identifies an entity among entity set. For example, the roll_number of a student makes him/her identifiable among students. Super Key − A set of attributes (one or more) that collectively identifies an entity in an entity set.
- 8. Basic Terms CandidateKey − A minimal super key is called a candidate key. An entity set may have more than one candidate key. Primary Key − A primary key is one of the candidate keys chosen by the database designer to uniquely identify the entity set.
- 9. Basic Terms Relationship The association among entities is called a relationship. For example, an employee works_ata department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.
- 10. Basic Terms RelationshipSet A set of relationships of similar type is called a relationship set. Like entities, a relationship too can have attributes. These attributes are called descriptive attributes.
- 11. Basic Terms Degreeof Relationship The number of participating entities in a relationship defines the degree of the relationship. Binary = degree 2 Ternary = degree 3 n-ary
- 12. Basic Terms MappingCardinalities Cardinality defines the number of entities in one entity set, which can be associated with the number of entities of other set via relationship set.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. Weak and StrongEntity A weak entity is an entity that depends on the existence of another entity. In more technical terms it can defined as an entity that cannot be identified by its own attributes. It uses a foreign key combined with its attributed to form the primary key. An entity like order item is a good example for this. The order item will be meaningless without an order so it depends on the existence of order.
- 27. Weak and StrongEntity
- 28. Weak and StrongEntity An entity set that has a primary key is called as Strong entity set. Consider an entity set Payment which has three attributes: payment_number, payment_date and payment_amount. Although each payment entity is distinct but payment for different loans may share the same payment number. Thus, this entity set does not have a primary key and it is an entity set
- 29. Weak and StrongEntity A weak entity set does not have a primary key but we need a means of distinguishing among all those entries in the entity set that depend on one particular strong entity set. The discriminator of a weak entity set is a set of attributes that allows this distinction be made. For example, payment_number acts as discriminator for payment entity set.
- 30. Weak and StrongEntity A member of a strong entity set is called dominant entity and member of weak entity set is called as subordinate entity.
- 31. Weak and StrongEntity
- 32. Total and PartialParticipation
- 33. Total and PartialParticipation Relationships between entities can be optional or compulsory. In our example, we could decide that a person is considered to be a customer only if they have bought a product. On the other hand, we could say that a customer is a person whom we know about and whom we hope might buy something—that is, we can have people listed as customers in our database who never buy a product
- 34. Total and PartialParticipation In the first case, the customer entity has total participation in the bought relationship (all customers have bought a product, and we can’t have a customer who hasn’t bought a product), while in the second case it has partial participation (a customer can buy a product). These are referred to as the participation constraints of the relationship.
- 35. Total and PartialParticipation Employee head of department Not all employees become a head, but department will always be headed by one employee. So employee participated partially in relationship.
- 36.
- 37. Example of ERDiagram In case of college, a college contain many departments Each dept. can offer any number of courses Many instructor can work in a dept. An instructor can work only in one dept. For each dept. there is head An instructor can be head of only one dept. Each instructor can take any no. of courses A course can be taken by only one instructor A student can enroll for any no. of courses Each course can have any no. of students
- 38. Example of ERDiagram Step 1 : Identify the Entities What are the entities here? From the statements given, the entities are Department Course Instructor Student
- 39. Example of ERDiagram Step 2 : Identify the relationships One department offers many courses. But one particular course can be offered by only one department. hence the cardinality between department and course is One to Many (1:N) One department has multiple instructors . But instructor belongs to only one department. Hence the cardinality between department and instructor is One to Many (1:N) One department has only one head and one head can be the head of only one department. Hence the cardinality is one to one. (1:1) One course can be enrolled by many students and one student can enroll for many courses. Hence the cardinality between course and student is Many to Many (M:N) One course is taught by only one instructor. But one instructor teaches many courses. Hence the cardinality between course and instructor is Many to One (N :1)
- 40. Example of ERDiagram Step 3: Identify the key attributes "Departmen_Name" can identify a department uniquely. Hence Department_Name is the key attribute for the Entity "Department". Course_ID is the key attribute for "Course" Entity. Student_ID is the key attribute for "Student" Entity. Instructor_ID is the key attribute for "Instructor" Entity.
- 41. Example of ERDiagram Step 4: Identify other relevant attributes For the department entity, other attributes are location For course entity, other attributes are course_name,duration For instructor entity, other attributes are first_name, last_name, phone For student entity, first_name, last_name, phone
- 42. Example of ERDiagram
- 43.
- 44.
- 45.
- 46.
- 47. Aggregation Aggregation isa process when relation between two entity is treated as a single entity. Here the relation between Center and Course, is acting as an Entity in relation with Visitor.
- 48.
- 49. Aggregation The E-Rmodel cannot express relationships among relationships. When would we need such a thing? Consider a DB with information about employees who work on a particular project and use a number of machines doing that work.
- 50.
- 51. Aggregation Relationship setswork and uses could be combined into a single set. However, they shouldn't be, as this would obscure the logical structure of this scheme. The solution is to use aggregation. An abstraction through which relationships are treated as higher-level entities. For our example, we treat the relationship set work and the entity sets employee and project as a higher-level entity set called work.
- 52.