The document provides an overview of entity relationship diagrams (ERDs) including their basic components, different notations, and how to implement various relationship types in a relational database. ERDs depict entities, attributes, and relationships in a conceptual database design. Key points covered include the three main notations of ERDs, solving multi-valued attributes and many-to-many relationships, and how to implement one-to-one, one-to-many, and many-to-many relationships through primary and foreign key constraints.
Informational Referential Integrity Constraints Support in Apache Spark with ...Databricks
An informational, or statistical, constraint is a constraint such as a unique, primary key, foreign key, or check constraint that can be used by Apache Spark to improve query performance. Informational constraints are not enforced by the Spark SQL engine; rather, they are used by Catalyst to optimize the query processing. Informational constraints will be primarily targeted to applications that load and analyze data that originated from a data warehouse. For such applications, the conditions for a given constraint are known to be true, so the constraint does not need to be enforced during data load operations.
This session will cover the support for primary and foreign key (referential integrity) constraints in Spark. You’ll learn about the constraint specification, metastore storage, constraint validation and maintenance. You’ll also see examples of query optimizations that utilize referential integrity constraints, such as Join and Distinct elimination and Star Schema detection.
Informational Referential Integrity Constraints Support in Apache Spark with ...Databricks
An informational, or statistical, constraint is a constraint such as a unique, primary key, foreign key, or check constraint that can be used by Apache Spark to improve query performance. Informational constraints are not enforced by the Spark SQL engine; rather, they are used by Catalyst to optimize the query processing. Informational constraints will be primarily targeted to applications that load and analyze data that originated from a data warehouse. For such applications, the conditions for a given constraint are known to be true, so the constraint does not need to be enforced during data load operations.
This session will cover the support for primary and foreign key (referential integrity) constraints in Spark. You’ll learn about the constraint specification, metastore storage, constraint validation and maintenance. You’ll also see examples of query optimizations that utilize referential integrity constraints, such as Join and Distinct elimination and Star Schema detection.
Entity type
Entity sets
Attributes and keys
Relationship model
Mapping Constraints
The ER Model
Cardinality Constraints
Generalization, Specialization and Aggregation
ER Diagram & Database design with the ER Model
Introduction
Relational Model
Concepts
Characteristics
Guidelines for ER to Relational Mapping.
Mapping rules/ guidelines for mapping various ER constructs to Relational model with appropriate examples
Relational Query Languages Formal Query Languages
Introduction to Relational Algebra
Relational operators
Set operators
Join operators
Aggregate functions.
Grouping operator
Relational Calculus concepts
Relational algebra queries for data retrieval with sample relational schemas. relational algebra operations.
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...Mustafa Kamel Mohammadi
In this chapter you will learn
Relational data model concepts
What is entity?
What is attribute and it’s types
What is relationship?
What is an Entity-Relationship data model?
Relational data model constraints
Characteristics of relation
in these slides i have explained the Abstract Factory Design pattern. slides includes definition, explanation and then implementation by code examples.
OOP - Understanding association, aggregation, composition and dependencyMudasir Qazi
In these slides i have tried to explains some confusing topics in object oriented programming like association, aggregation, composition and dependency. it's also a comparison oriented presentation.
In these slide i have tried to explains an interesting topic of programming, which is always a topic of discussion among programmers that is "variables and objects are passed-by-value or passed-by-reference in Java?" These slides will prove that Java is completely pass-by-value thing. There is nothing like pass-by-reference in Java.
In these slides i have explained an important design pattern that is "singleton pattern".
slides includes everything required about it, from definition to implementation and also different ways to achieve it according to situation and requirements.
in these slides i have explained the Observer design pattern. slides includes the complete definition, explanation and then implementation with code examples.
in these slides i have explained the difference between MVC, MVP and MVVM design patterns. slides includes definition, explanation and then implementation with code examples. it is a comparison oriented presentation.
in these slides i have explained the factory method design pattern. slides contains complete notes on this pattern from definition to implementation by code example.
Design Pattern - Chain of ResponsibilityMudasir Qazi
in these slides i have explained the Chain of Responsibility design pattern. slides includes definition, explanation and then implementation by code examples.
Industrial Training at Shahjalal Fertilizer Company Limited (SFCL)MdTanvirMahtab2
This presentation is about the working procedure of Shahjalal Fertilizer Company Limited (SFCL). A Govt. owned Company of Bangladesh Chemical Industries Corporation under Ministry of Industries.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
6th International Conference on Machine Learning & Applications (CMLA 2024)ClaraZara1
6th International Conference on Machine Learning & Applications (CMLA 2024) will provide an excellent international forum for sharing knowledge and results in theory, methodology and applications of on Machine Learning & Applications.
1. Entity Relationship Diagram
A complete guide to design ER Diagrams
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 1
2. Contents / Agenda
• Definition
• Basic Components
• ERD Representations
• Chen’s Notation Symbols
• Crow’s foot Notation Symbols
• UML Notation Symbols
• Type of Entities
• Types of Attributes
• How to solve multivalued attributes
• Types of Relationships
• Implementation of 1:1
• Implementation of 1:M
• Implementation of M:M
• Connectivity and Cardinalities
• Summary
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 2
3. Definition
• The Relational Database Model (ERM-database containing tables)
forms on the basis of an ERD. The ERD represents the conceptual
database as viewed by the end user.
• ERDs depict the database’s main components: entities, attributes, and
relationships. Because an entity represents a real-world object, the
words entity and object are often used interchangeably. Thus, the
entities (objects) of the Tiny College database design (mostly discussed
in these slides) include students, classes, teachers and classrooms.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 3
4. Basic Components of ERD
• Entities:
• An entity is an object of interest to the end user. At the ER modeling level, an entity actually refers to the entity set and
not to a single entity occurrence. In other words, the word entity in the ERM corresponds to a table—not to a row—in
the relational environment. The ERM refers to a table row as an entity instance or entity occurrence.
• In both the Chen and Crow’s Foot notations, an entity is represented by a rectangle containing the entity’s name. The
entity name, a noun, is usually written in all capital letters.
• Attributes:
• Attributes are characteristics of entities. For example, the STUDENT entity includes, among many others, the attributes
STU_LNAME, STU_FNAME, and STU_INITIAL. In the original Chen notation, attributes are represented by ovals and are
connected to the entity rectangle with a line. Each oval contains the name of the attribute it represents.
• In the Crow’s Foot notation, the attributes are written in the attribute box below the entity rectangle. Because the Chen
representation is rather space-consuming, software vendors have adopted the Crow’s Foot style attribute display.
• Relationships:
• A relationship is an association between entities. The entities that participate in a relationship are also known as
participants, and each relationship is identified by a name that describes the relationship. The relationship name is an
active or passive verb; for example, a STUDENT takes a CLASS, a PROFESSOR teaches a CLASS and an AIRCRAFT is flown
by a CREW.
• Relationships between entities always operate in both directions. That is, to define the relationship between the entities
named CUSTOMER and INVOICE, you would specify that:
1. A CUSTOMER may generate many INVOICEs.
2. Each INVOICE is generated by one CUSTOMER.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 4
5. ERD Representations
• There are three main notations to represent and ERD
1. The Chen notation favors conceptual modeling.
2. The Crow’s Foot notation favors a more implementation-oriented approach.
3. The UML notation can be used for both conceptual and implementation
modeling.
• Because of its implementation emphasis, the Crow’s Foot notation can
represent only what could be implemented.
• We will also be using a new Short Hand notation that is easy to
understand and takes less place.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 5
8. UML Notation Symbols
Primary Keys are followed by [PK]
Foreign Keys are followed by [FK]
Relationships:
Cardinality 1 for ‘One’.
Cardinality * for ‘Many’.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 8
9. Advantages and Usage
• Advantages:
1. ERD tells us that how many tables you need and what would be the
relationship between them (you also have to do Normalization to know
finally how many tables would be in your database but still first step is ERD).
2. ERD is simple and understandable representation of a database. It helps a lot
to understand the whole database.
• Usage:
1. An ERD leads to ERM, means when ever you need to build a database with
tables, firstly, you need to create an ERD.
2. Crow’s foot notation is used most of all because its easy to understand in
implementation point of view.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 9
10. Types of Entities
• Existence Dependent
An entity is said to be existence-dependent if it can exist in the database
only when it is associated with another related entity occurrence. In
implementation terms, an entity is existence-dependent if it has a
mandatory foreign key—that is, a foreign key attribute that cannot be
null.
• Existence Independent.
If an entity can exist apart from one or more related entities, it is said to
be existence-independent (Sometimes designers refer to such an entity
as a strong or regular entity). Here foreign key attribute can be null.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 10
11. Types of Attributes (1)
• Required
A required attribute is an attribute that must have a value; in other words, it cannot be left
empty.
• Optional
An optional attribute is an attribute that does not require a value; therefore, it can be left empty.
• Domains
Attributes have a domain, a domain is the set of possible values for a given attribute. For
example, the domain for the grade point average (GPA) attribute is written (0,4) because the
lowest possible GPA value is 0 and the highest possible value is 4. The domain for the gender
attribute consists of only two possibilities: M or F (or some other equivalent code).
• Identifiers
The ERM uses identifiers, that is, one or more attributes that uniquely identify each entity
instance. In the relational model, such identifiers are mapped to primary keys (PKs) in tables.
There are Simple(Primary Key) and Composite (Composite Key) identifiers.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 11
12. Types of Attributes (2)
• Composite
A composite attribute, not to be confused with a composite key, is an attribute that can be further subdivided to yield
additional attributes. For example, the attribute ADDRESS can be subdivided into street, city, state, and zip code.
• Simple
A simple attribute is an attribute that cannot be subdivided. For example, age, sex, and marital status would be classified
as simple attributes.
• Single-Valued
A single-valued attribute is an attribute that can have only a single value. For example, a person can have only one Social
Security number, and a manufactured part can have only one serial number. Keep in mind that a single-valued attribute is
not necessarily a simple attribute. For instance, a part’s serial number, such as SE-08-02-189935, is single-valued, but it is
a composite attribute because it can be subdivided into the region in which the part was produced (SE), the plant within
that region (08), the shift within the plant (02), and the part number (189935).
• Multi-Valued
Multivalued attributes are attributes that can have many values. For instance, a person may have several college degrees,
and a household may have several different phones, each with its own number. Similarly, a car’s color may be subdivided
into many colors (that is, colors for the roof, body, and trim).
• Derived
A derived attribute is an attribute whose value is calculated (derived) from other attributes. The derived attribute need
not be physically stored within the database; instead, it can be derived by using an algorithm. For example, an
employee’s age, EMP_AGE, may be found by computing the integer value of the difference between the current date and
the EMP_DOB.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 12
13. How to Solve Multi-Valued attributes (1)
• Although the conceptual model can handle M:N relationships and
multivalued attributes, you should not implement them in the RDBMS.
Because in the relational table, each column/row intersection represents a
single data value. So if multivalued attributes exist, the designer must
decide on one of two possible courses of action:
1. Within the original entity, create several new attributes, one for each of the original
multivalued attribute’s components. For example, the CAR entity’s attribute
CAR_COLOR can be split to create the new attributes CAR_TOPCOLOR,
CAR_BODYCOLOR, and CAR_TRIMCOLOR, which are then assigned to the CAR entity.
(Not good).
2. Create a new entity composed of the original multivalued attribute’s components.
The new (independent) CAR_COLOR entity is then related to the original CAR entity
in a 1:M relationship. Note that such a change allows the designer to define color
for different sections of the car like top, body, interior etc. (Best solution).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 13
14. How to Solve Multi-Valued attributes (2)
Entity CAR contains a multivalued
attribute CAR_COLOR.
Solution 1: (Not good)
Solution to Multi-Valued attribute
by adding new attributes to CAR
entity.
Solution 2: (Best)
Solution to Multi-Valued attribute
by adding new entity with 1:M
relation to CAR entity.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 14
15. Relationships
• Ways of Classifying Relationships Types
A relationship type can be classified by the number of entity types involved, and by the degree of the
relationship type.
Following is a brief picture showing all types of relationships.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 15
16. Types of Relationships (1)
• One-to-One
• When both participants can have only one instance of each other. (less used but stable).
• For Example, HUSBAND can have only one WIFE and WIFE can have only one HUSBAND. This
is 1:1 relationship between HUSBAND and WIFE participants.
• One-to-Many
• When one participant can have multiple instances of other participants but other participant
can have only one instance of first participants. (mostly used and stable).
• For Example, CUSTOMER may generate many ORDERs but each ORDER is generated by one
CUSTOMER. This is 1:M relation between CUSTOMER and ORDER.
• Many-to-Many
• When both participants can have multiple instances of each other. (not practice).
• For Example, STUDENT can be enrolled in many SUBJECTs and one SUBJECT can be chosen
by many STUDENTs. This is M:M relation between STUDENT and SUBJECT.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 16
17. Types of Relationships (2)
• Weak relationship
Also known as a non-identifying relationship, exists if the PK of the related entity does not
contain a PK component of the parent entity. By default, relationships are established by having
the PK of the parent entity appear as an FK on the related entity (implemented in right picture).
• Strong relationship
Also known as an identifying relationship, exists when the PK of the related entity contains a PK
component of the parent entity (implemented in left picture).
• Recursive relationship
• A recursive relationship is one in which a relationship can exist between occurrences of the
same entity set (Naturally, such a condition is found within a unary relationship).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 17
18. Relationships (1:1) – Implementation (1)
• An example of a one-one relationship type is a person and his or her birth
certificate. We assume that everyone has one and that a certificate registers the
birth of one person only.
• Where there is a one-one relationship type we have the option of merging the
two entity types. The birth certificate attributes may be considered as attributes
of the person and placed in the person entity type. The birth certificate entity
type would then be removed.
• There are two reasons for not merging them:
1. The majority of processing involving PERSON records might not involve any or many of
the BIRTH_CERTIFICATE attributes. The BIRTH_CERTIFICATE attributes might only be
subject to very specific processes which are rarely executed.
2. the BIRTH_CERTIFICATE entity type has relationship types to other entity types that the
PERSON entity type does not have. The two entity types have different relationship types
to other entity types.
• Merging is not very harmful practically. so, its just a matter of choice which
implementation you want.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 18
19. Relationships (1:1) – Implementation (2)
• Following is implementations for 1:1 relationship.
One table has PK and other table must have same PK as well as FK.
Department Table has Department_ID as PK.
And Manager Table must have Department_ID as
PK as well as FK (You can change the name of
column but it should have same data).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 19
20. Relationships (1:M) - Implementation
• The common column is DEPARTMENT_ID (which is the primary key in
the DEPARTMENT table) should be as a foreign key in the EMPLOYEE
table. One individual DEPARTMENT_ID can relate to many rows in the
EMPLOYEE table.
Business Rule for this is:
“one department can relate to one or
many employees (or even no
employees) and that an employee is
associated with only one department
(or, in some cases, no department).”
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 20
21. Relationships (M:N) – Implementation (1)
• Consider the EMPLOYEE and PROJECT tables. The business rule is as follows:
One employee can be assigned to multiple projects, and one project can be
supported by multiple employees. Therefore, it is necessary to create an
M:M relationship to link these two tables.
• In the relational database we don’t implement the M:N relation by just
giving FKs to each other and the reason is we don’t want two sided links
(circles). So, we create a new entity called Bridge Entity and its PK is a
composite key made up with PKs of both tables. It may or may not have any
other attributes but composite key is must.
• After doing this, there becomes two 1:M relations.
1. One between Bridge and EMPLOYEE table (1:M).
2. One between Bridge and PROJECT table (1:M).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 21
22. Relationships (M:N) – Implementation (2)
In this example we made Bridge Table
under name EMPLOYEE_PROJECT
containing PKs of both above tables. It
has one more attribute for some extra
information.
Now, it becomes like this and we have
three tables now.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 22
23. Removing Ternary and Hire order relations
• It is advantageous (but not necessary) to remove ternary and higher order relationship types. One
reason is that it might be considered more `natural' to think of entity types having attributes than
relationship types having them. It is in fact always possible to remove these high-order relationship
types and replace them with an entity type. A ternary relationship type is then replaced by an
entity type and three binary relationship types linking it to the entity types which were originally
linked by the ternary. A quaternary relationship type would be replaced by an entity type and four
relationship types and so on.
Ternary Relation Ternary Relation Solved into binary relations
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 23
24. Connectivity and Cardinalities
• Connectivity:
The term connectivity is used to describe the relationship classification. Just to show the relation
existence and type of relation between entities.
• Cardinalities:
Cardinality expresses the minimum and maximum number of entity occurrences associated with
one occurrence of the related entity. In the ERD, cardinality is indicated by placing the
appropriate numbers beside the entities, using the format (min , max).
1. Cardinality / mandatory:
maximum cardinality.
2. Modality / optional:
minimum cardinality or optionality.
Picture says, one PROFESSOR can teach one (min 1)
or more (max 4) CLASSes but each single (min 1)
CLASS can be taught by one (max 1) PROFESSOR at
time.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 24
25. Summary
• Following are main steps to create an ERD
1. Decide what are the entitles in your database.
2. Decide attributes for each entity.
3. Describe relationships between entities.
1. If there is any M:N relation, solve it into 1:M relationships.
• Note: ERD will not output a complete blue print to your database until
you do its Normalization. But, ERD + Normalization will give you
complete set of tables, attributes and relationships you need in your
database.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 25