GROUP 5

PRESENTATION
ANALYSIS MODELING
Data Modeling
 WHAT IS ANALYSIS MODELING?
• In Analysis Modelling, information, behavior, and functions of the system are
defined and translated into the architecture, component, and interface level design
in the design modeling.

•Objectives of Analysis Modelling:

 It must establish a way of creating software design.
 It must describe the requirements of the customer.
• It must define a set of requirements that can be validated, once the software is built.

• WHAT IS AN ANALYSIS MODEL?

• Analysis Model is a technical representation of the system. It acts as a link
between system description and design model.
 W h a t's in v o lv e d in d a ta a n a ly s is

• Data Dictionary:
It is a repository that consists of a description of all data objects used or
produced by the software. It stores the collection of data present in the software.
It is a very crucial element of the analysis model. It acts as a centralized
repository and also helps in modeling data objects defined during software
requirements.
• Entity Relationship Diagram (ERD):
It depicts the relationship between data objects and is used in conducting data
modeling activities. The attributes of each object in the Entity-Relationship
Diagram can be described using Data object description. It provides the basis for
activity related to data design.
• Data Flow Diagram (DFD):
It depicts the functions that transform data flow and it also shows how data is
transformed when moving from input to output. It provides the additional
information which is used during the analysis of the information domain and
serves as a basis for the modeling of function. It also enables the engineer to
develop models of functional and information domains at the same time.etc
 WHAT IS DATA MODELLING and A DATA
OBJECT?:

• Data modeling is the process of analyzing and defining all the

different data your business collects and produces, as well as the
relationships between those bits of data. Data modeling concepts
create visual representations of data as it’s used at your business, and
the process itself is an exercise in understanding and clarifying your
data requirements.
• Data Object Description:
It stores and provides complete knowledge about a data object present and used
in the software. It also gives us the details of attributes of the data object present
in the Entity Relationship Diagram. Hence, it incorporates all the data objects and
their attributes
 WHY IS DATA MODELLING
IMPORTANT?:
•By modeling your data, you’ll document what data you have, how you use it, and what your
requirements are surrounding usage, protection, and governance. Through data modeling, your
organization:
 Creates a structure for collaboration between your IT team and your business teams.

 Exposes opportunities for improving business processes by defining data needs and uses.

 Saves time and money on IT and process investments through appropriate planning up front.

 Reduces errors (and error-prone redundant data entry), while improving data integrity.

 Increases the speed and performance of data retrieval and analytics by planning for capacity and
growth.

 Sets and tracks target key performance indicators tailored to your business objectives.
•So, it isn’t just what you get with data modeling, but also how you get it. The process itself provides significant benefits.
**Data modeling and data analytics go hand in hand because you need a quality data model to get
the most impactful analytics for business intelligence that informs decision making. The process of
creating data models is a forcing function that makes each business unit look at how they contribute
to holistic business goals. Plus, a solid data model means optimized analytics performance, no
matter how large and complex your data estate is—or becomes**
 DATA MODELLING EXAMPLES:
Conceptual data modeling

•A conceptual data model defines the overall structure of your business and data. It’s used for organizing business
concepts, as defined by your business stakeholders and data architects. For instance, you may have customer,
employee, and product data, and each of those data buckets, known as entities, has relationships with other
entities. Both the entities and the entity relationships are defined in your conceptual model.
Logical data modeling
A logical data model builds on the conceptual model with specific attributes of data within each entity and
specific relationships between those attributes. For instance, Customer A buys Product B from Sales Associate C.
This is your technical model of the rules and data structures as defined by data architects and business analysts,
and it will help drive decisions about what physical model your data and business needs require.
Physical data modeling
A physical data model is your specific implementation of the logical data model, and it’s created by database
administrators and developers. It is developed for a specific database tool and data storage technology, and with
data connectors to serve the data throughout your business systems to users as needed. This is the “thing” the
other models have been leading to—the actual implementation of your data estate.
 HOW TO CHOOSE A DATA MODELLING TOOL:

•The good news is, a quality business intelligence tool will include all the data modeling tools you need, other
than the specific software products and services you choose to create your physical model. So you’re free to
choose the one that suits your business needs and existing infrastructure best. Ask yourself these questions when
evaluating a data analytics tool for its data modeling and analytics potential.
Is your data modeling tool intuitive?

•The technical folks implementing the model might be able to handle any tool you throw at them, but your
business strategists and everyday analytics users—and your business as a whole—aren’t going to get optimum
value out of the tool if it’s not easy to use. Look for an intuitive, straightforward user experience that helps your
team with data storytelling and data dashboards.

How does your data modeling tool perform?

•Another important attribute is performance—speed and efficiency, which translate into the ability to keep the
business running smoothly as your users run analyses. The best planned data model isn’t really the best if it can’t
perform under the stress of real-world conditions—which hopefully involve business growth and increasing
volumes of data, retrieval, and analysis.
Does your data modeling tool require maintenance?

•If every change to your business model requires cumbersome changes to your data model, your business won’t
get the best out of the model or the associated analytics. Look for a tool that makes maintenance and updates
easy, so your business can pivot as needed while still having access to the most up-to-date data.
Will your data be secure?

•Government regulations require that you protect your customer data, but the viability of your business requires
protecting all your data as the valuable asset it is. You’ll want to make sure the tools you choose have strong
security measures built-in, including controls for granting access to those who need it and blocking those who
don’t.
 DATA OBJECTS, ATTRIBUTES AND
RELATIONSHIPS:
• The data model consists of three interrelated pieces of information: the data object, the attributes that
describe the data object, and the relationships that connect data objects to one another. Data objects.
A data object is a representation of almost any composite information that must be understood by software.
• Data objects.
• A data object is a representation of almost any composite information that must be understood by
software. By composite information, we mean something that has a number of different properties or
attributes. Therefore, width (a single value) would not be a valid data object, but dimensions
(incorporating height, width, and depth) could be defined as an object.

A data object can be an external entity (e.g., anything that produces or consumes information), a
thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role
(e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse),
or a structure (e.g., a file). For example, a person or a car can be viewed as a data object in the sense
that either can be defined in terms of a set of attributes. The data object description incorporates the
data object and all of its attributes.

Data objects (represented in bold) are related to one another. For example, person can own car, where
the relationship own connotes a specific "connection” between person and car. The relationships are
always defined by the context of the problem that is being analyzed.

A data object encapsulates data only—there is no reference within a data object to operations that act
on the data.
 Attributes:
• Attributes define the properties of a data object and take on one of three different
characteristics. They can be used to (1) name an instance of the data object, (2) describe
the instance, or (3) make reference to another instance in another table. In addition, one or
more of the attributes must be defined as an identifier—that is, the identifier attribute
becomes a "key" when we want to find an instance of the data object. In some cases,
values for the identifier(s) are unique, although this is not a requirement. Referring to the
data object car, a reasonable identifier might be the ID number.
•Relationships.
Data objects are connected to one another in different ways. Consider two data objects, book
and bookstore. . A connection is established between book and bookstore because the two
objects are related. But what are the relationships? To determine the answer, we must
understand the role of books and bookstores within the context of the software to be built. We
can define a set of object/relationship pairs that define the relevant relationships. For
example,
A bookstore orders books.
A bookstore displays books.
A bookstore stocks books.
A bookstore sells books.
A bookstore returns books.

•The relationships orders, displays, stocks, sells, and returns define the relevant
connections
 C a rd in a lity v s M o d a lity

Cardinality and Modality are the two data modelling concepts used for
understanding the information domain of the problem. For analysing the data
objects, data attributes and relationships structures, the terms given above are very
important.

•The major difference between cardinality and modality is that the cardinality is
defined as the metric used to specify the number of occurrences of one object
related to the number of occurrences of another object. On the contrary, modality
signifies whether a certain data object must participate in the relationship or not.
Comparison Chart

BASIS FOR COMPARISON CARDINALITY MODALITY

Basic Maximum number of Minimum number of row

associations between the associations.

table rows.

Types One-to-one, one-to-many, Nullable and not nullable.

 CARDINALITY:
•Cardinality describes that a data model must be able to represent the number of occurrences
of an object/s in a given relationship. It can be expressed in the pattern of “one” or “many”. In
database designing, we usually define a group of objects and represent the object/relationship
pairs that bind them. Assuming a simple pair – Object “a” related to object “b” does not provide
sufficient information for software engineering purposes. So, to interpret how many occurrences
of one object is related to how many occurrences of other objects the cardinality is devised.

•Let’s take an example of a bank account having the tables PAN card and debit cardholder,
each individual can have a unique PAN card number and on the basis of it, that person could
own a single (i.e., one-to-one) or several different accounts in different banks (i.e., one-to-
many). For associating two objects, any of the three relations can be made.

 One-to-one – In this relation, the occurrence of object “x” can relate to only one occurrence
of object “y” and vice-versa.
 One-to-many – One occurrence of object “x” can relate to multiple occurrences of the object
“y”. However, the object “y” can only relate to a single occurrence of “x”.
 Many-to-many – Multiple occurrences of object “x” can relate to multiple occurrences of
object “y” and vice-versa.
 WHAT IS MODALITY?
•The Modality is completely different from the cardinality. Its value is computed as “o” when
there is no requirement for the relationship to occur or if the relationship is optional. The
modality value is “1” if there is a compulsion for the occurrence of a relationship. In simple
words, it describes whether a relationship between two or more entities is even required or not.

•Let’s take an example of a PAN card and its related debit cardholders. In the Debit card holder
table, there will be a PAN card number, which makes a link to the PAN card holder as a bank
account holder is necessarily required to have a PAN card. Now, if the modality is in this
example is “0” then there presents a row without a PAN card number but if it is “1” then we
should have a value in the PAN card number.

•So, here if the modality is “0” or more than “0” which specifies the Debit cardholder does not
have any PAN card number hence is not needed to be held. The debit card holder table not only
maintains the active cardholder data but also the data of users who have closed their bank
accounts and this is called the NULLABLE column due to its acceptance of an empty field.

•When the modality is 1, the debit cardholder must be having a PAN card number, which means
a bank account with no PAN card number cannot be included in the table. Therefore this column
is considered to be a NOT NULL column as it does not accept null values.
 KEY DIFFERENCES BETWEEN
CARDINALITY AND MODALITY:
• Cardinality is nothing but the maximum number of objects that can participate in
a relationship. In contrast, modality is the possibility of making relations
between objects.
• There can be three cases possible in cardinality – one-to-one, one-to-many and
many-to-many. As against, the modality of the given relationship can be nullable
or non-nullable.
 What is an ER diagram?
•An Entity Relationship Diagram (ERD) is a visual representation of different entities within a
system and how they relate to each other. For example, the elements writer, novel, and a
consumer may be described using ER diagrams the following way:
 Entity Relationship Diagrams In Software Engineering:

Entity relationship diagrams are used in software engineering during the planning stages of the software
project. They help to identify different system elements and their relationships with each other. It is often
used as the basis for data flow diagrams or DFD’s as they are commonly known.
•For example, an inventory software used in a retail shop will have a database that monitors elements
such as purchases, item, item type, item source and item price. Rendering this information through an
ER diagram would be something like this:

•ER diagram example with entity having attributes

•In the diagram, the information inside the oval shapes are attributes of a particular entity.
Benefits

•ER diagrams constitute a very useful framework for creating and manipulating databases.
First, ER diagrams are easy to understand and do not require a person to undergo extensive
training to be able to work with it efficiently and accurately. This means that designers can use
ER diagrams to easily communicate with developers, customers, and end users, regardless of
their IT proficiency.
•Second, ER diagrams are readily translatable into relational tables which can be used to
quickly build databases. In addition, ER diagrams can directly be used by database developers
as the blueprint for implementing data in specific software applications.
•Lastly, ER diagrams may be applied in other contexts such as describing the different
relationships and operations within an organization.