Databases and Data Modelling

Presented By :
Jagjit Singh
Senior Technical Trainer
jagjit.e15190@cumail.in
Relational Databases

 A relational database organizes data into rows and columns, which collectively
form a table. Data is typically structured across multiple tables, which can be
joined together via a primary key or a foreign key. These unique identifiers
demonstrate the different relationships which exist between tables, and these
relationships are usually illustrated through different types of data models.
Analysts use SQL queries to combine different data points and summarize
business performance, allowing organizations to gain insights, optimize
workflows, and identify new opportunities.
For example

 imagine your company maintains a database table with customer

information, which contains company data at the account level. There may
also be a different table, which describes all the individual transactions that
align to that account. Together, these tables can provide information about
the different industries that purchase a specific software product.
 Relational databases are also typically associated with transactional
databases, which execute commands, or transactions, collectively. A popular
example that is used to illustrate this is a bank transfer. A defined amount is
withdrawn from one account, and then it is deposited within another. The
total amount of money is withdrawn and deposited, and this transaction
cannot occur in any kind of partial sense.
Transactions have specific properties,
ACID properties are defined as:
 Atomicity: All changes to data are performed as if they are a single operation.
That is, all the changes are performed, or none of them are.
 Consistency: Data remains in a consistent state from state to finish, reinforcing
data integrity.
 Isolation: The intermediate state of a transaction is not visible to other
transactions, and as a result, transactions that run concurrently appear to be
serialized.
 Durability: After the successful completion of a transaction, changes to data
persist and are not undone, even in the event of a system failure.
Relational database vs. relational database management
system

 While a relational database organizes data based off a relational data model, a
relational database management system (RDBMS) is a more specific reference to
the underlying database software that enables users to maintain it. These
programs allow users to create, update, insert, or delete data in the system, and
they provide:
 Data structure
 Multi-user access
 Privilege control
 Network access
Conceptual and Physical Data Models

 Conceptual Data Model: This Data Model defines WHAT the system contains. This
model is typically created by Business stakeholders and Data Architects. The purpose is to
organize, scope and define business concepts and rules.
 Logical Data Model: Defines HOW the system should be implemented regardless of the
DBMS. This model is typically created by Data Architects and Business Analysts. The
purpose is to developed technical map of rules and data structures.
 Physical Data Model: This Data Model describes HOW the system will be implemented
using a specific DBMS system. This model is typically created by DBA and developers.
The purpose is actual implementation of the database.
Characteristics of a conceptual data model

 Offers Organisation-wide coverage of the business concepts.

 This type of Data Models are designed and developed for a business
audience.
 The conceptual model is developed independently of hardware
specifications like data storage capacity, location or software
specifications like DBMS vendor and technology. The focus is to
represent data as a user will see it in the “real world.”
Characteristics of a Logical data model

 Describes data needs for a single project but could integrate with
other logical data models based on the scope of the project.
 Designed and developed independently from the DBMS.
 Data attributes will have datatypes with exact precisions and length
Characteristics of a physical data model:

 The physical data model describes data need for a single project or application though it
maybe integrated with other physical data models based on project scope.
 Data Model contains relationships between tables that which addresses cardinality and
nullability of the relationships.
 Developed for a specific version of a DBMS, location, data storage or technology to be
used in the project.
 Columns should have exact datatypes, lengths assigned and default values.
 Primary and Foreign keys, views, indexes, access profiles, and authorizations, etc. are
defined.
Advantages and Disadvantages of Data Model:

Advantages of Data model:

 The main goal of a designing data model is to make certain that data objects offered by the
functional team are represented accurately.
 The data model should be detailed enough to be used for building the physical database.
 The information in the data model can be used for defining the relationship between tables,
primary and foreign keys, and stored procedures.
 Data Model helps business to communicate the within and across organizations.
Disadvantages of Data model:

 To develop Data model one should know physical data stored

characteristics.
 This is a navigational system produces complex application
development, management.
 Even smaller change made in structure require modification in the
entire application.
 There is no set data manipulation language in DBMS.
Conclusion

 Data modeling is the process of developing data model for the data to be stored in a Database.
 Data Models ensure consistency in naming conventions, default values, semantics, security while ensuring
quality of the data.
 Data Model structure helps to define the relational tables, primary and foreign keys and stored procedures.
 There are three types of conceptual, logical, and physical.
 The main aim of conceptual model is to establish the entities, their attributes, and their relationships.
 Logical data model defines the structure of the data elements and set the relationships between them.
 A Physical Data Model describes the database specific implementation of the data model.
 The main goal of a designing data model is to make certain that data objects offered by the functional
team are represented accurately.
 The biggest drawback is that even smaller change made in structure require modification in the entire
application.
Entity and Attributes

 Entity and attributes are crucial aspects of RDBMS's ER model. If we have a

collection of laptops that all belong to the same firm, are the same color, and have
the exact specifications, we cannot distinguish them apart just on their looks.
 And this is the reason why we are going to study Entity and Attributes because
we must retrieve data from the database, and each of them must have a distinct
value that may be used to distinguish between two sets of data. As a result, we
can refer to an item as an entity when it becomes uniquely identifiable from the
rest of the records in the database. So let's take a closer look at what an entity is,
as well as entity sets and types.
What is an Entity?

 An entity is a distinct real-world thing, such as a person, a place, or a concept, that can be
uniquely identified. It's an object that stands out from the crowd.
 Types of Entity:
 An entity can be of two types :
 Tangible Entity: The term tangible entities refer to the physical entities that exist in the
real world.
 Example: a student, a keyboard, a bank locker, car, etc.
 Intangible Entity: Entities with solely a cognitive existence and no physical existence.
 Example: a Google Account, a bank account etc.
Example:

 In this particular example given below, we have a table named “Professor,” which contains
multiple entities having attributes(Professor ID, Professor Name, Professor City, Professor
Salary) by which we can understand that every entity contains a unique Professor ID,
which is the key attribute of the table which helps to distinguish between the entities.

Professor_ID Professor_Na Professor_City Professor_Sala

me ry
P01 Tom Sydney $7000
P02 David Brisbane $4500
P03 Mark Perth $5000
Types of Entity type

 Strong Entity Type

 Weak Entity Type
 Strong Entity type
 A strong entity is one that is not reliant on other entities in the schema. A primary
key is always present in a strong entity. A single rectangle represents a strong
entity. A single diamond represents the bond between two powerful creatures.
 When various strong entities are united, they form a strong entity set.
How to represent Strong Entity type:
Weak Entity type

 There is no key attribute for a weak entity type. It is unlikely to

identify a weak entity type on its own. Its distinct identity is reliant
on the presence of another strong entity. A real-life example can
help you understand this:
 There can be children only if the parent exists. There can't be a
separate existence for children. There can be a room only if the
building exits. There can't be a room that exists on its own.
How to represent Weak Entity type:
 For example: Here, we can see that “Address” is a weak entity as the whole entity can not
be identified on its own just by using address entity type because it does not have any key
attribute to identify the entity uniquely.
Entity Set

 A group of entities with the same set of properties is referred to as an entity set. Each entity
in an entity set has its own set of attribute values that distinguishes it from the other
entities in the table. The characteristics of no two entities in an entity set will have
identical values.
 The Table in a database represents an entity set. The Student Table, which has numerous
entities, is shown below. Even though both kids have the name Jhoson, they are uniquely
identified since they have separate roll numbers.
Attributes

 In general, an attribute is a characteristic. In a database management system (DBMS), an

attribute refers to a database component, such as a table.
 Example: In a general Student table we can consider attributes like Roll No, Mobile No,
and Age where we have Roll No as a key or primary attribute.
Types Of Attributes:

 There are numerous types of attributes, including the following:

 Simple Attribute & Composite Attribute
 Single Valued Attribute & Multi-valued Attribute
 Stored Attribute & Derived Attribute
 Key Attribute & Non-key Attribute
Simple Attribute

 Simple attributes are those that cannot be further divided into sub-
attributes.
 For example, A student's roll number of a student or the employee
identification number. These attributes are usually assigned by an
organization and are used to identify an individual within that
organization uniquely. Databases and other systems often use simple
attributes to track and manage information.
Composite Attributes

 Composite attributes are made up of two or more simple attributes. For example, a person's
address may be a composite attribute that is made up of the person's street address, city,
state, and zip code. Composite attributes can be used to create more complex data models
and can be helpful when trying to represent data in a concise way.
Single Valued Attributes

 Single-valued attributes can only have one value. For example, a person's Social Security
Number is a single-valued attribute. Social Security Numbers are used to uniquely identify
individuals in the United States and are, therefore, single-valued attributes.
 Examples of single-valued attributes include employee numbers, customer numbers, and
product codes. Single-valued attributes are typically used to provide a unique identifier for
an entity and are often used in databases.
Multivalued Attributes

 Multivalued attributes can have more than one value. For example,
a person may have multiple email addresses or phone numbers.
Multivalued attributes in DBMS are often used to store information
about relationships between entities. For instance, an employee
entity might have a multivalued attribute called "dependents" that
stores the names of the employee's dependents. Multivalued
attributes can also be used to represent hierarchical data.
Derived Attributes

 Derived attributes are based on other attributes and are not stored directly in the database.
 For example: Consider a database of employees. Each employee has a date of birth, and
we might want to calculate their age. However, age is a derived attribute because it can be
determined from the date of birth. As such, it would not make sense to store it directly in
the database. Here is an example diagram of a derived attribute in DBMS:
Key Attributes

 DBMS's key attributes are used to uniquely identify each row in a table. Usually, there is
more than one key attribute in a table (primary key and foreign key).
 For example: In a table of employees, the employee ID would be the primary key, while
the manager ID would be the foreign key.
Stored Attributes

 In a DBMS, stored attributes are the data that remain constant and fixed for an entity
instance. These values help in deriving the derived attributes.
 For example: consider a customer entity in a bank. The customer's name, age, and address
would be stored attributes. The customer's account balance (a derived attribute) could be
calculated based on the transactions (another stored attribute) associated with the customer.
UNIQUEIDENTIFIER Data Type

 The unique identifier is a column or field in your database. Unique

identifiers in a database are used to distinguish fields from each
other. A unique identifier is used when information is called from
the database and needs to be distinguished from other information in
the database.
Relationships

 A relationship in DBMS is the way in which two or more data sets are linked, i.e., any
association between two entity types is called a relationship. So entity takes part in the
relationship, and it is represented by a diamond shape.
For example

 A teacher teaches students. Here, " teaches " is a relationship and this is the relationship
between a Teacher entity and a Student entity.
 We have two entity types of 'Customer'(Customer_id, Name, City, Phone) and
'Account'(Account_no, Type, Balance). We store the data of 'Customer' in one table and his
accounts details in the 'Account' table. Now, to link these two tables we need to insert the
primary key 'Customer_id' of the 'Customer' table in the 'Account' table. This key acts as a
foreign key for the 'Account' table and refers to a column with the same name in the
'Customer' table. This is how a relationship between two tables is established.
Types of relationships

 One-to-One Relationship
 One-to-Many or Many-to-One Relationship
 Many-to-Many Relationship

 One-to-One Relationship
 Such a relationship exists when each record of one table is related to only one record of the
other table.
For example

Such a relationship is not very common. However, such a

relationship is used for security purposes. In the above example,
we can easily store the passport id in the ‘Person’ table only.
But, we make another table for the ‘Passport’ because Passport
number may be sensitive data and it should be hidden from
certain users. So, by making a separate table we provide extra
security that only certain database users can see it.
One-to-Many or Many-to-One Relationship

 Such a relationship exists when each record of one table can be related to one or more than
one record of the other table. This relationship is the most common relationship found. A
one-to-many relationship can also be said as a many-to-one relationship depending upon
the way we view it.
 For example, If there are two entity type ‘Customer’ and ‘Account’ then each ‘Customer’
can have more than one ‘Account’ but each ‘Account’ is held by only one ‘Customer’. In
this example, we can say that each Customer is associated with many Account. So, it is a
one-to-many relationship. But, if we see it the other way i.e many Account is associated
with one Customer then we can say that it is a many-to-one relationship.
Many-to-Many Relationship

 Such a relationship exists when each record of the first table can be
related to one or more than one record of the second table and a
single record of the second table can be related to one or more than
one record of the first table. A many-to-many relationship can be
seen as a two one-to-many relationship which is linked by a 'linking
table' or 'associate table'. The linking table links two tables by
having fields which are the primary key of the other two tables. We
can understand this with the following example.
Example:

 If there are two entity type ‘Customer’ and ‘Product’ then each customer can buy more
than one product and a product can be bought by many different customers.
Entity Relationship Modeling (ERDs)

 What is an ER diagram?
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such
as people, objects or concepts relate to each other within a system. ER Diagrams are most
often used to design or debug relational databases in the fields of software engineering,
business information systems, education and research. Also known as ERDs or ER Models,
they use a defined set of symbols such as rectangles, diamonds, ovals and connecting lines to
depict the interconnectedness of entities, relationships and their attributes.
Uses of entity relationship diagrams

 Database design:
ER diagrams are used to model and design relational databases, in terms of logic and
business rules (in a logical data model) and in terms of the specific technology to be
implemented (in a physical data model.) In software engineering, an ER diagram is
often an initial step in determining requirements for an information systems project.
It’s also later used to model a particular database or databases.
Database troubleshooting:

 ER diagrams are used to analyze existing databases to find and resolve problems in logic
or deployment. Drawing the diagram should reveal where it’s going wrong.
Business information systems:
The diagrams are used to design or analyze relational databases used in business processes.
Any business process that uses fielded data involving entities, actions and interplay can
potentially benefit from a relational database.
 Business process re-engineering (BPR): ER diagrams help in analyzing
databases used in business process re-engineering and in modeling a new
database setup.
 Education: Databases are today’s method of storing relational information for
educational purposes and later retrieval, so ER Diagrams can be valuable in
planning those data structures.
 Research: Since so much research focuses on structured data, ER diagrams can
play a key role in setting up useful databases to analyze the data.
The components and features of an ER diagram

 Entity
 A definable thing—such as a person, object, concept or event—that can have data stored
about it. Think of entities as nouns. Examples: a customer, student, car or product.
Typically shown as a rectangle.
 Entity set: Same as an entity type, but defined at a particular point in time, such as students
enrolled in a class on the first day. Other examples: Customers who purchased last month,
cars currently registered in Florida. A related term is instance, in which the specific person
or car would be an instance of the entity set.
 Entity categories: Entities are categorized as strong, weak or associative. A strong
entity can be defined solely by its own attributes, while a weak entity cannot. An
associative entity associates entities (or elements) within an entity set.
Entity keys:

 Refers to an attribute that uniquely defines an entity in an entity set. Entity keys can be
super, candidate or primary. Super key: A set of attributes (one or more) that together
define an entity in an entity set.
 Candidate key:
A minimal super key, meaning it has the least possible number of attributes to
still be a super key. An entity set may have more than one candidate key. Primary key: A
candidate key chosen by the database designer to uniquely identify the entity set. Foreign
key: Identifies the relationship between entities.
ERD symbols and notations
THANKS