GROUP 5: Documentation

COURSE CODE : HCC202/HAI202/HCS202

Name Surname REG. Number Program

Tinotenda Makamba R216926J HCC

Tyra Sithole R216929J HCC
Takudzwanashe Daudi R216927H HCC
Letwin Mapungwana R216921U HCC
Thelma Dube R216924R HCC
Gift Muzamana R219417Y HCC
Lovemore Kabi R219319C HCC
Albert Dhlumingo R216922D HCC
Beatrice Gandiwa R216932L HCC
Tapiwa Garwe R216889Q HAI
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.

ANALYSIS MODEL?
 Analysis Model is a technical representation of the system. It acts as a link between
system description and design model.

Elements of Analysis Model:

DATA MODELLING:
 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 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 a business stakeholders and data
architects. For instance, one 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 a 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 a Product B from Sales Associate C. This is a 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 one’s data and business needs
require.
Physical data modeling
 A physical data model is a 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 a business system to users as needed. This is the “thing” the other models
have been leading to the actual implementation of your data estate.

IMPORTANCE OF DATA MODELING:

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, an
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 OBJECTS, ATTRIBUTES AND RELATIONSHIPS:

The data model consists of three interrelated pieces of information: the data objects, 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. 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 analysed.

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.

CARDINALITY AND MODALITY

 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.
Cardinality:
 The cardinality describes the number of relations an object possesses for another
object. 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
Modality:
 Modality describes whether the relation is required to be made or not. Its 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.
Differences between Cardinality and Modality

BASIS FOR
CARDINALITY MODALITY
COMPARISON

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.

many-to-many.
ENTITY RELATIONSHIP DIAGRAMS(ERD’S):
 ER-modeling is a data modeling method used in software engineering to produce a
conceptual data model of an information system. Diagrams created using this ER-
modeling method are called Entity-Relationship Diagrams or ER diagrams or ERDs
 An Entity Relationship Diagram (ERD) is a visual representation of different entities
within a system and how they relate to each other
 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.
Components of an ER Diagram
 Entity
 An entity can be a real-world object, either animate or inanimate, that
can be merely identifiable. An entity is denoted as a rectangle in an ER
diagram. For example, in a school database, students, teachers, classes,
and courses offered can be treated as entities
 An Entity can be Represented by a rectangle.

 Attributes
There exist 5 types of attributes i.e. Key Attribute, Composite Attribute,
Single-valued Attribute, Multi-valued Attribute and Derived Attribute.
 Entities are denoted utilizing their properties, known as attributes. All
attributes have values. For example, a student entity may have name,
class, and age as attributes.
 They are represented by an oval shape

 Relationship
 The association among entities is known as relationship. Relationships
are represented by the diamond-shaped box. For example, an employee
works at a department, a student enrols in a course. Here, Works at and
Enrols are called relationships.
 Relationship set
A set of relationships of a similar type is known as a
relationship set. Like entities, a relationship too can have
attributes. These attributes are called descriptive attributes.

 Degree of a relationship set

The number of participating entities in a relationship describes
the degree of the relationship. The three most common
relationships in E-R models are:
  Unary (degree1)
 Binary (degree2)
 Ternary (degree3)

An Example of an ER Diagram:
Cardinality
 Cardinality describes the number of entities in one entity set, which can be
associated with the number of entities of other sets via relationship set.
Types of Cardinalities
1. One to one
2. One to many
3. Many to one
4. Many to many
Purposes of ERD’s
 The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.
 The ERD serves as a documentation tool.
 Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.

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.

QUESTIONAIRES
 Student -
https://docs.google.com/forms/d/e/1FAIpQLSf9eRqzX6KCyZH3rsgv6J9rAD2YVG
BsvOtQb2VWEWZA3_sPrA/viewform?usp=sf_link
 Lecturer -
https://docs.google.com/forms/d/e/1FAIpQLSdX3iaIViM8VBSIqhGJ0Qppq3VTv_
WblNl4ENagauaWdglzJQ/viewform?usp=sf_link
 Technician -
https://docs.google.com/forms/d/e/1FAIpQLSdBBMstwXXHLuxELdMLBIenb-
k35teBLPVyaWgLs9O1jqDTpA/viewform?usp=sf_link