0% found this document useful (0 votes)
29 views

Unit2Data Models

The document discusses different types of data models including conceptual, logical, and physical models. A conceptual model identifies high-level relationships between entities but does not specify attributes or keys. A logical model describes data in detail including all attributes and primary keys. A physical model represents how the data will be built in a database including table structures. The document also provides examples of each type of model.

Uploaded by

Hom Pathak
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views

Unit2Data Models

The document discusses different types of data models including conceptual, logical, and physical models. A conceptual model identifies high-level relationships between entities but does not specify attributes or keys. A logical model describes data in detail including all attributes and primary keys. A physical model represents how the data will be built in a database including table structures. The document also provides examples of each type of model.

Uploaded by

Hom Pathak
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 106

DATA MODELS

Er. सा हि त बरा ल
May 9/2022
Data Models
Conceptual, Logical and Physical Model
Conceptual Data Model
◦ A conceptual data model identifies the highest-level relationships between the
different entities.
◦ Features of conceptual data model include:
◦ Includes the important entities and the relationships among them.
◦ No attribute is specified.
◦ No primary key is specified.
Data Models
Conceptual Data Model
◦ The figure below is an example of a conceptual data model.

• From the figure above, we can see that the only


information shown via the conceptual data model is
the entities that describe the data and the
relationships between those entities.
• No other information is shown through the
conceptual data model.
Data Models
Logical Data Model
◦ A logical data model describes the data in as much detail as possible, without
regard to how they will be
◦ physical implemented in the database. Features of a logical data model
include:
◦ Includes all entities and relationships among them.
◦ All attributes for each entity are specified.
◦ The primary key for each entity is specified.
◦ Foreign keys (keys identifying the relationship between different entities)
are specified.
◦ Normalization occurs at this level.
Data Models
Logical Data Model
The steps for designing the logical data model are as follows:
1. Specify primary keys for all entities.
2. Find the relationships between different entities.
3. Find all attributes for each entity.
4. Resolve many-to-many relationships.
5. Normalization.
Data Models
Logical Data Model
◦ The figure below is an example of a logical data model.
Data Models
Physical Data Model
◦ Physical data model represents how the model will be built in the database.
◦ A physical database model shows all table structures, including column name,
column data type, column constraints, primary key, foreign key, and
relationships between tables.
Data Models
Physical Data Model
Features of a physical data model include:
◦ Specification all tables and columns.
◦ Foreign keys are used to identify relationships between tables.
◦ Denormalization may occur based on user requirements.
◦ Physical data model will be different for different RDBMS. For example, data
type for a column may be different between MySQL and SQL Server.
Data Models
Physical Data Model
◦ The figure below is an example of a physical data model.

Comparing the physical data model shown above with the


logical data model diagram, we see the main differences
between the two:
• Entity names are now table names.
• Attributes are now column names.
• Data type for each column is specified. Data types can be
different depending on the actual database being used.
E-R Models
Entity and Entity Sets
Entity
◦ An entity is an object that exists and is distinguishable from other objects
◦ Real world thing either living or non-living things
◦ Entity can be place, person, object, event or a concept, Which store data in
database
◦ Tangible Entity: Tangible Entities are those entities which exist in the real
world physically. Example: Person, car, etc.
◦ Intangible Entity: Intangible Entities are those entities which exist only
logically and have no physical existence. Example: Bank Account, etc.
Entity and Entity Sets
◦ Example: If we have a table of a Student (Roll_no, Student_name, Age,
Mobile_no) then each student in that table is an entity and can be uniquely
identified by their Roll Number i.e Roll_no.

Note: In E-R model we don't represent the data but we represent the structure or schema
Entity and Entity Sets
Entity Type
◦ It is a collection of the entity having common attributes

The E-R
representation of the
above Student Entity
Type is done below

Note: We use a rectangle to represent an entity type in the E-R diagram, not entity
Entity and Entity Sets
Entity Sets
◦ Entity Set is a collection of entities of the same entity type
◦ Example: In the below example, two entities E1 (2, Angel, 19, 8709054568)
and E2(4, Analisa, 21, 9847852156) form an entity set
Entity and Entity Sets
Types of Entity type
• Strong Entity Type
• Weak Entity Type

• Strong Entity type


- Strong entity are those entity
types which has a key attribute
- The primary key helps in
identifying each entity uniquely
Entity and Entity Sets
Weak Entity Type
◦ Weak entity type doesn't have a key attribute
◦ It depends upon some other strong entity for its distinct identity
◦ For e.g. There can be children only if the parent exits
Attributes
◦ Attribute are the properties which define the entity type
◦ Types of Attribute
1. Simple attributes Stu_id DOB
2. Composite attributes
3. Single valued attributes
4. Multi valued attributes Attributes
Student
5. Derived attributes
6. Key attributes
7. Null value attributes Stu_name Stu_address
Attributes
Simple Attribute
◦ Simple attributes are those attributes which can not be divided further
Attributes
Composite attributes
◦ Composite attributes are those attributes which are composed of many other
simple attributes

Here, the attributes “Name” and “Address” are composite attributes as they are
composed of many other simple attributes.
Attributes
Single valued attributes
◦ Single valued attributes are those attributes which can take only one value for
a given entity from an entity set
Attributes
Multi valued attributes
◦ Multi valued attributes are those attributes which can take more than one
value for a given entity from an entity set

Here, the attributes “Mob_no” and “Email_id” are multi valued attributes as they can
take more than one values for a given entity
Attributes
Derived attributes
◦ Derived attributes are those attributes which can be derived from other
attribute(s)
Attributes
Key attributes
◦ Key attributes are those attributes which can identify an entity uniquely in an
entity set
Attributes
Null value attributes
◦ An attribute, which has not any value for an entity is known as null valued
attribute
◦ For e.g. one student does not have a phone number
Relationship and Relationship Sets
• Relationship defines an association among several entities
• A relationship set is a set of same type of relationships
‘Enrolled in’ is a relationship that exists between entities Student and Course

◦ Types of Relationship
- Strong Relationship set
- Weak Relationship set
Relationship and Relationship Sets
Strong Relationship Set
• A strong relationship exists between two strong entity sets
• It is represented using a diamond symbol
Weak Relationship Set (Identifying)
• A weak relationship exists between the strong and weak entity set
• It is represented using a double diamond symbol
Relationship and Relationship Sets
Degree of Relationship
◦ Number of entity set that participate in a relationship is called degree of
relationship

Types of Relationship Sets (Degree of Relationship)


◦ Unary Relationship
◦ Binary Relationship
◦ Ternary Relationship
◦ N-ary Relationship
Relationship and Relationship Sets
Unary Relationship
◦ Unary relationship set is a relationship set where only one entity set
participates in a relationship set
Relationship and Relationship Sets
Binary Relationship
◦ Binary relationship set is a relationship set where two entity sets participate in
a relationship set
Relationship and Relationship Sets
Ternary Relationship
◦ Ternary relationship set is a relationship set where three entity sets participate
in a relationship set
Relationship and Relationship Sets
N-ary Relationship
◦ N-ary relationship set is a relationship set where ‘n’ entity sets participate in a
relationship set
Constraints on ER model/Structural Constraints in ER

◦ Mapping Cardinalities
◦ Participation constraints
Mapping Cardinality Constraints
◦ The number of times an entity set participates in a relationship set is known as
cardinality
◦ It is most useful in describing binary relationship sets
◦ One ( ) and many ( )
◦ For binary relationship set R on an entity set A and B, there are four possible
mapping cardinalities
1.One to one (1:1)
2.One to many (1:M)
3.Many to one (M:1)
4.Many to many (M:M)
Mapping Cardinality Constraints
One to One (1:1)
◦ In one-to-one mapping, An entity in A is associated with at most (only) one
entity in B and an entity in B is associated with at most(only) one entity in A
Mapping Cardinality Constraints
One to One (1:1) Relationship

A customer is connected with only one loan using the relationship borrower and a


loan is connected with only one customer using borrower
Mapping Cardinality Constraints
One to Many (1:M) Relationship
◦ An entity in A is associated with any number (zero or more) of entities in
Band an entity in B is associated with at most one (only) entity in A
Mapping Cardinality Constraints
One to Many (1:M) Relationship

In  the one-to-many relationship a loan is connected with only one customer using


borrower and a customer is connected with more than one loans using borrower
Mapping Cardinality Constraints
Many to One (M:1) Relationship
◦ An entity in A is associated with at most (only) one entity in B and an entity in
B is associated with any number (zero or more) of entities in A
Mapping Cardinality Constraints
Many to One (M:1) Relationship

In a  many-to-one relationship a loan is connected with more than one customer


using borrower and a customer is connected with only one loan using borrower
Mapping Cardinality Constraints
Many to Many (M:N) Relationship
◦ An entity in A is associated with any number (zero or more) of entities in B and
an entity in B is associated with any number (zero or more) of entities in A
Mapping Cardinality Constraints
Many to Many (M:N) Relationship

A customer is connected with more than one loan using borrower and a loan is


connected with more than one customer using borrower
Participation Constraints
◦ Participation Constraint is applied on the entity participating in the relationship
set
◦ Participation constraints means whether all or only some entity occurrences
participate in a relationship set
◦ Two types of participation constraints
1. Total participation Constraints
2. Partial participation Constraints
Participation Constraints
Total Participation Constraints
◦ Each entity in the entity set must compulsory participate in at least one
relationship instance in the relationship set
◦ Mandatory Participation
◦ It is represented using double line between entity set and relationship set
Participation Constraints
Partial Participation Constraints
◦ Each entity in the entity set may or may not participate in the relationship
instance in that relationship set
◦ Optional Participation
◦ It is represented using single line between entity set and relationship set
Participation Constraints
partial total
Sid Name Cid Cname

M
N
Student Enrolled In Extra Courses

Age Address Credit_hr


Relationship between Cardinality and Participation Constraints
Minimum cardinality tells whether the participation is partial or total
• If minimum cardinality = 0, then it signifies partial participation
• If minimum cardinality = 1, then it signifies total participation
Maximum cardinality tells the maximum number of entities that participates in a
relationship set

C1
S1 R1
S2 R2
C2
S3 R3
S4 R4
C3
Keys
◦ Key is used to uniquely identify any record or row of data inside table
◦ It also used to established and identify relationship between tables

Types of Key
◦ Super Key
◦ Candidate Key
◦ Primary Key
Super Key
◦ A super key of an entity set is a set of one or more attributes whose values
uniquely determine each entity in the entity set
◦ If k is a key attribute and any superset of k is also super key
Sid Name Phone Age
1 Praveen 987643214 27
2 Bikal 987654123 25
3 Kiran 985682356 26
4 Puspa 984586932 27
5 Season 985505896 26
Candidate Key
◦ Candidate keys are defined as the minimal set of field which can uniquely
identified each record in table
◦ Candidate Key = Super key whose proper subset is not a super key
◦ It is an attribute or set of attribute that can act as a primary key to identify
each record in the table

Sid Name Phone Age


1 Praveen 987643214 27
2 Bikal 987654123 25
3 Kiran 985682356 26
4 Puspa 984586932 27
5 Season 985505896 26
Candidate Key
Feature in candidate key
1) Candidate key is a minimal form of super key
2) There is no possible subset of candidate key that acts as a key attribute
3) A candidate key can never be null or empty
4) There can be more than one candidate key
5) A candidate key can be a combination of more than one column(attribute)
Primary Key
◦ Primary key is a candidate key that is most appropriate to become the main
key for any table
◦ Its is a key that can uniquely identify each record in table
◦ A primary key is a candidate key that is chosen by the database designer
◦ It can not be null and can not be duplicate

DeptCode DeptName
001 Science
002 English
005 Computer
Foreign Key
◦ It is a column that creates a relationship between two tables.
◦ The purpose of Foreign keys is to maintain data integrity and allow navigation
between two different instances of an entity.
◦ It acts as a cross-reference between two tables as it references the primary
key of another table.

DeptCode DeptName Teacher ID DeptCode Fname Lname


001 Science B002 002 David Warner
002 English B017 002 Sara Joseph
005 Computer B009 001 Mike Brunton
Alternate Key
◦ ALTERNATE KEYS is a column or group of columns in a table that uniquely
identify every row in that table.
◦ A table can have multiple choices for a primary key but only one can be set as
the primary key.
◦ All the keys which are not primary key are called an Alternate Key.
Compound Key
◦ COMPOUND KEY has two or more attributes that allow you to uniquely
recognize a specific record.
◦ It is possible that each column may not be unique by itself within the
database. However, when combined with the other column or columns the
combination of composite keys become unique.
◦ The purpose of the compound key in database is to uniquely identify each
record in the table.
Compound Key
OrderNo ProductID Product Name Quantity
B005 JAP102459 Mouse 5
B005 DKT321573 USB 10
B005 OMG446789 LCD Monitor 20
B004 DKT321573 USB 15
B002 OMG446789 Laser Printer 3
Composite Key
◦ It is a combination of two or more columns that uniquely identify rows in a
table.
◦ The combination of columns guarantees uniqueness, though individually
uniqueness is not guaranteed. Hence, they are combined to uniquely identify
records in a table.
◦ The difference between compound and the composite key is that any part of
the compound key can be a foreign key, but the composite key may or maybe
not a part of the foreign key.
Surrogate Keys
◦ It is An artificial key which aims to uniquely identify each record is called a
surrogate key.
◦ This kind of partial key in dbms is unique because it is created when you don’t
have any natural primary key.
◦ They do not lend any meaning to the data in the table. Surrogate key in DBMS
is usually an integer.
◦ A surrogate key is a value generated right before the record is inserted into a
table.
Surrogate Keys

Fname Lastname Start Time End Time


Anne Smith 09:00 18:00
Jack Francis 08:00 17:00
Anna McLean 11:00 20:00
Shown Willam 14:00 23:00
Reducing E.R Diagrams to Tables
• We can represent the E-R database schema by a set of tables
• Each entity sets and each relationship sets in E-R schema represented by
their corresponding tables
• Each attributes of entity sets and relationship sets are map as columns of their
corresponding tables
• representing E-R schema into tables is converting E-R model of database into
relational model.
• This is because relational models can be easily implemented by RDBMS like
MySQL , Oracle etc
Reducing E.R Diagrams to Tables
Representations of Sets
1) Representation of Strong Entity Sets
2) Representations of Weak Entity Sets
3) Representations of Relationship Sets
1) Representation of Strong Entity Sets
Rule-01: For Strong Entity Set With Only Simple Attributes
◦ A strong entity set with only simple attributes will require only one table in
relational model
- Attributes of the table will be the attributes of the entity set
- The Primary key of table will be the key attribute of the entity sets
Rule-01: For Strong Entity Set With Only Simple Attributes

Roll_no Name Sex

Schema : Student ( Roll_no , Name , Sex )


1) Representation of Strong Entity Sets
Rule-02: For Strong Entity Set With Composite Attributes-
◦ A strong entity set with any number of composite attributes will require only
one table in relational model
◦ While conversion, simple attributes of the composite attributes are taken into
account and not the composite attribute itself
Rule-02: For Strong Entity Set With Composite Attributes

Roll_no First_name Last_name House_no Street City

Schema : Student ( Roll_no , First_name , Last_name ,


House_no , Street , City )
1) Representation of Strong Entity Sets
Rule-03: For Strong Entity Set With Multi Valued Attributes
A strong entity set with any number of multi valued attributes will require two
tables in relational model
- One table will contain all the simple attributes with the primary key
- Other table will contain the primary key and all the multi valued attributes
Rule-03: For Strong Entity Set With Multi Valued Attributes

Roll_no City Roll_no Mobile_no


2) Representations of Weak Entity Sets
◦ Weak entity set does not have its own primary key

Building_No Building_Name Address Door_no Building_no Floor


3) Representations of Relationship Sets
A relationship set will require one table in the relation model

Attributes of the table are-


- Primary Key attributes of the participating entity sets
- Its own descriptive attributes if any
3) Representations of Relationship Sets
a) Mapping of Binary 1:1 relation types into ER

Mid Fid Fname


Name

1 Married 1
Male Female
to

Age Address No of child

Mid Name Age Address Fid Mid Fname No of Child


3) Representations of Relationship Sets
b) Mapping of Binary M:1 relation types into ER

Sid Name Cid Cname

1
Student M Enrolled In Course

Age Address Credit_hr


3) Representations of Relationship Sets
b) Mapping of Binary M:1 relation types into ER

Student Table Course Table

Sid Name Age Address Cid Cid Cname Credit_hr


3) Representations of Relationship Sets
c) Mapping of Binary 1:M relation types into ER

Sid Name Cid Cname

M
Student 1
Enrolled In Course

Age Address Credit_hr


3) Representations of Relationship Sets
c) Mapping of Binary 1:M relation types into ER

Student Table Course Table


Sid Name Age Address Cid Cname Credit_hr Sid
3) Representations of Relationship Sets
d) Mapping of Binary M:N relation types into ER

Sid Name Cid Cname

N
Student M
Enrolled In Course

Age Address Credit_hr


3) Representations of Relationship Sets
d) Mapping of Binary M:N relation types into ER

Sid Name Age Address Cid Cname Credit_hr

Course Table
Student Table

Sid Cid

Enrolled Table
The relational schema for the ER Diagram is
given below as:
• Staff( StaffID , dob , address , WifeID)
• Wife ( WifeID , name )
• Child( ChildID , name , StaffID )
• Task ( TaskID , description)
• Perform(PerformID , StaffID , TaskID )
• Phone(PhoneID , phoneNumber , StaffID)

• Company( CompanyID , name , address)


• Work(WorkID , CompanyID , StaffID,
since)
Extended E-R Features: Specialization
◦ Specialization follows top down design approach
◦ Entity sets are subgroups in distinct entity sets. These subgroups becomes
lower-level entity sets
◦ a lower-level entity set inherits all the attributes and relationship participation
in the higher-level entity set to which it is linked (called attribute inheritance)
◦ The process of subgroupings an entity set is called specialization
◦ In E-R diagram, specialization can be represented by a triangle component
labeled ISA. The label ISA stands for “is a “.
◦ E.g. customer “is a” person.
◦ The ISA relationship also called superclass-subclass relationship
Extended E-R Features: Generalization
◦ A bottom-up design process – combine a number of entity sets that share the
same features into a higher-level entity set.
◦ Specialization and generalization are simple inversions of each other; they are
represented in an E-R diagram in the same way.
◦ The terms specialization and generalization are used interchangeably.
Example:
Aggregation
Problem in E-R model
◦ To illustrate this, let us consider quaternary relationship manages among
employee, branch, job and manager.
◦ Its main job is to record managers who
manages particular job/task perform by
particular employee at particular branch.
◦ Problem
◦ information are redundant
◦ since every employee, branch and
job exist both relationship set “work-on”
and “manages”.

Figure: E-R diagram with redundant relationships


Aggregation
• Aggregation is used when we need to express a
relationship among relationships

• Aggregation is an abstraction through which


relationships are treated as higher level entities

• Aggregation is a process when a relationship


between two entities is considered as a single
entity and again this single entity has a
relationship with another entity

Figure: E-R Diagram with aggregation


Design Constraints on a Specialization/Generalization
◦ Membership Constraint
◦ Dis jointness Constraint
◦ Completeness Constraint
Design Constraints on a Specialization/Generalization
1. Membership Constraints
◦ Constraint on which entities can be members of a given lower-level entity set.
◦ condition-defined
◦ E.g. all customers over 65 years are members of senior-citizen entity set;
senior-citizen ISA person.
◦ user-defined
Design Constraints on a Specialization/Generalization
2. Disjointness Constraints
◦ Constraint on whether or not entities may belong to more than one lower-level
entity set within a single generalization.
◦ Disjoint
◦ an entity can belong to only one lower-level entity set
◦ Noted in E-R diagram by writing disjoint next to the ISA triangle
◦ Overlapping
◦ an entity can belong to more than one lower-level entity set
Design Constraints on a Specialization/Generalization
3. Completeness constraint
◦ Specifies whether or not an entity in the higher-level entity set must belong to
at least one of the lower-level entity sets within a generalization.
◦ total : an entity must belong to one of the lower-level entity sets
◦ partial: an entity need not belong to one of the lower-level entity sets
Relation with UML class diagram
◦ The Unified Modeling Language (UML), is a proposed standard for creating
specifications of various components of a software system.
◦ It is a language that helps to visualize, construct and documents software
systems.
◦ It provides a graphical representation of the entire software. It also helps to
model Object Oriented Programming concepts.
◦ Some parts of UML
◦ Class diagram
◦ Use case diagram
◦ Activity diagram
◦ Implementation diagram
Relation with UML class diagram
Relation with UML class diagram
Class diagram
◦ The most common UML diagram type, class diagrams show the associations
between classes and interfaces.
Relation with UML class diagram
Class diagram
Relation with UML class diagram
Class diagram
Relation with UML class diagram
Use case diagram
◦ Use case diagrams show the interaction between users and the system, in
particular the steps of tasks that users perform (such as withdrawing money or
registering for a course).
◦ The chart then shows how these actions activate and move through the system.
Relation with UML class diagram
Use case diagram
◦ the system.
Relation with UML class diagram
Activity diagram
◦ Activity diagrams depict the flow of tasks between various components of a system.
Relation with UML class diagram
Implementation diagram
◦ Implementation diagrams show the system components and their interconnections,
both at the software component level and the hardware component level.
Alternative data models
Hierarchical Model:
◦ Hierarchical Model was the first DBMS model.
◦ This model organizes the data in the hierarchical tree structure.
◦ The hierarchy starts from the root which has root data and then it expands in the form
of a tree adding child node to the parent node.
◦ This model easily represents some of the real-world relationships like food recipes,
family tree
Alternative data models
Hierarchical Model:
Alternative data models
Hierarchical Model:
Advantages of Hierarchical Model
◦ It is very simple and fast to traverse through a tree-like structure.
◦ Any change in the parent node is automatically reflected in the child node so, the
integrity of data is maintained.
Disadvantages of Hierarchical Model
◦ Complex relationships are not supported.
◦ As it does not support more than one parent of the child node so if we have some
complex relationship where a child node needs to have two parent node then that
can't be represented using this model.
◦ If a parent node is deleted then the child node is automatically deleted.
Alternative data models
Network Data Model:
◦ This model is an extension of the hierarchical model.
◦ It was the most popular model before the relational model.
◦ This model is the same as the hierarchical model, the only difference is that a record
can have more than one parent.
◦ It replaces the hierarchical tree with a graph
Alternative data models
Network Data Model:
Alternative data models
Network Data Model:
Advantages of a Network Database Model
◦ Because it has the many-many relationship, network database model can easily be
accessed in any table record in the database
◦ For more complex data, it is easier to use because of the multiple relationship
founded among its data
◦ Easier to navigate and search for information because of its flexibility
Disadvantage of a Network Database Model
◦ Difficult for first time users
◦ Difficulties with alterations of the database because when information entered can
alter the entire database
“Mrs. Sunaina Pathak is the manager of an art gallery, She wants an
online application to keep track of the artists, paintings, customers, order
and payments details. It is known that the admin should store the
information of the artists and their paintings. Multiple artists can
participate to make a painting. A customer can place an order of any
number of painting but must pay in a single installment.

You might also like