Project Analysis & Design Workshop

Project Analysis & Design
Workshop
Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Systems Development Lifecycle
What is required/expected?
Project allocation and project
requirements/objectives description
Documenting Objectives and requirements
Touching the “Finish” line
Presenting and defending your
project work.
How to meet the expectations?
Defining and developing logical model
for Requirements/objectives analysis –
Processes, DFDs, ERDs
SDLC Documenting requirements detailing

and elicitation
What is the System Infrastructure?

Systems If the application is:
Selecting Implementation tech. Implementation /  Stand alone,
 H/W technology  Client-server,
Coding
 Application development  On-line,
environment/language platform  Web-based, mobile etc.

Requirement gathering/collection - Exercise
Make a list of “All” the requirements of the project allocated to you.
These requirements were thoroughly discussed at the step of “Project Objectives”
Make list and keep it with you for upcoming activities

Systems and Systems Thinking
What is a “System” ?
A system is an organized collection of highly integrated parts designed to achieve a
desired outcome. The system has a wide variety of inputs which are manipulated
through a process or series of processes in a manner to produce an output
Input Output
Input The System Output
Input Process Output
What is “System Thinking” ?

The force or interrelationships that shape the behavior of systems. The discipline helps us
to see how to change systems more effectively and to act more to adjust with the
processes of natural world

System as a Process
 The simplest process model of a system is based on Input, Output and the System itself – viewed as process
 The process symbol defines the boundary of the system
 The system is inside the boundary; the environment is outside that boundary
 The system exchange input and output with its environment
Input Output
Environment

Analyzing Data Requirements – Process Modeling
 Process modeling involves graphically representing the functions, or processes, that capture,
manipulate, store, and distribute data between a system and its environment and between
components within a system.
 A common form of a process model is a data flow diagram (DFD).
 Data flow diagrams enable you to model how data flow through an information system, the
relationships among the data flows, and how data come to be stored at specific locations.
 Data flow diagrams also show the processes that change or transform data.

Deliverables for Process Modeling
Set of coherent, interrelated data flow diagrams, such diagrams are:

Context data flow diagram (DFD)
Scope and boundaries of system
DFDs of current system
Enables analysts to understand current system it shows what data
processing functions performed by the current system
DFDs of new logical system
Show data flows, structure and functional requirements of new system
Description of each DFD component,
entries for all of the objects included in all diagrams (in data dictionary
or CASE repository)

DFD Mechanics
There are two different standard sets of DFD symbols each set consists of four symbols
that represent the same things: data flows, data stores, processes,
and sources/sinks (or external entities).
Data Flow
A data flow is as data in motion, moving from one place in a system to another. A data
flow could represent data on a customer order form or a payroll check; it could also
represent the results of a query to a database, the contents of a printed report, or data
on a data entry computer display form.
Data Store
A data store is data at rest. A data store may represent one of many different physical
locations for data; for example, a file folder, one or more computer-based file(s), or
a notebook.
A data store might contain data about customers, students, customer orders, or
supplier invoices.

DFD Mechanics
Process
A process is the work or actions performed on data so that they are transformed, stored, or distributed.
When modeling the data processing of a system, it does not matter whether a process is performed manually or
by a computer.
Source/ Sink
a source/sink is the origin and/or destination of the data. Sources/sinks are sometimes referred to as external
entities because they are outside the system. Once processed, data or information leave the system and go to
some other place.
Sources and sinks are outside the system we are studying, In this respect, we do not consider the following:
 Interactions that occur between sources and sinks
 What a source or sink does with information or how it operates (i.e., a source or sink is a “black box”)
 How to control or redesign a source or sink because, from the perspective of the system we are studying, the
data a sink receives and often what data a source provides are fixed
 How to provide sources and sinks direct access to stored data because, as external agents, they cannot directly
access or manipulate data stored within the system; that is, processes within the system must receive or
distribute data between the system and its environment
Systems &
Project Analysis Analysis
Designand Design - BIIT – Naveed Ashraf
Workshop
DFD Mechanics
 Sources/sinks are always outside the information system and define the boundaries of
the system.
 Data must originate outside a system from one or more sources, and the system must
produce information to one or more sinks (these are principles of open systems, and
almost every information system is an open system).
 If any data processing takes place inside the source/sink, it is of no interest because this
processing takes place outside the system we are diagramming.
A source/sink might consist of the following:
 Another organization or organization unit that sends data to or

receives information from the system you are analyzing (e.g., a
supplier or an academic department—in either case, the
organization is external to the system you are studying)
 A person inside or outside the business unit supported by the
system you are analyzing who interacts with the system (e.g., a
customer or loan officer)
 Another information system with which the system you are
analyzing exchanges information

Difference between Source/Sink and Process
Improperly drawn DFD showing Process as Source/Sink DFD showing proper use of Process

Context Diagram
 The highest-level view of the system, is called a context diagram. In this diagram, Context diagram contains only one process,
no data stores, four data flows, and three sources/sinks. The single process, labeled 0, represents the entire system.
 All context diagrams have only one process, labeled 0. The sources/sinks represent the environmental boundaries of the
system.
 The data stores of the system are conceptually inside one process, data stores do not appear on a context diagram.
Input Output
Context diagram of Hoosier Burger’s food-ordering system
Opening Context to make Level – 0 DFD
 As analyst, you must determine which processes are represented by the
single process in the context diagram.
 In our example, the main processes represent the major functions of the
system, and these major functions correspond to actions such as:
1. Capturing data from different sources (e.g., Process 1.0)

2. Maintaining data stores (e.g., Processes 2.0 and 3.0)
3. Producing and distributing data to different sinks (e.g., Process 4.0)
4. High-level descriptions of data transformation operations (e.g., Process 4.0)
 These major functions often correspond to the activities on the main system
menu.
 Note that the sources/sinks are the same in the context diagram and in this
diagram: the customer, the kitchen, and the restaurant’s manager.
 This diagram is called a level-0 diagram because it represents the primary

individual processes in the system at the highest possible level.
 Each process has a number that ends in .0 (corresponding to the level

number of the DFD).

Identifying Processes - Exercise
Make a list of “All” the Processes and sub-processes that will take ‘input” and
generate “output” to meet the requirements of project allocated to you.
These processes and sub-processes of your project will transformed the “Input”
taken from “End-user” or other processes to the Output”
Make list and keep it with you for upcoming activities

Data Flow Diagraming Rules
 The inputs to a process are different from the outputs of that process.
 Objects on a DFD have unique names.
 process names begin with an action verb, such as Receive, Calculate,

Transform, Generate, or Produce.

Data Flow Diagraming Rules

Decomposition of DFD
 The act of going from a single system to sub-system’s component processes is called (functional) decomposition.
 Functional decomposition is an iterative process of breaking the description or perspective of a system down into finer
and finer detail.
 This process creates a set of hierarchically related diagrams / charts in which one process on a given diagram is
explained in greater detail on another diagram.
 Each resulting process (or subsystem) is also a candidate for decomposition.
 Each process may consist of several sub processes.
 Each sub process may also be broken down into smaller units.
 Decomposition continues until you have reached the point at which no sub process can logically be broken down any
further.
 The lowest level of a DFD is called a primitive DFD,

Decomposing Hoosier Burger’s Food ordering System - Example
Give me two cheeseburgers, one small order of fries, and one regular orange soda
Process 1.0 is a good candidate process for decomposition.
Think about all of the different tasks that Process 1.0 has to perform:
(1) receive a customer order,
(2) transform the entered order into a form meaningful for the kitchen’s system,
(3) transform the order into a printed receipt for the customer,
(5) transform the order into inventory data.

Decomposition of DFD – Detailing the process
Context
ContextLevel
Level
Level - 1
Level - 0

Balancing DFDs
 You must conserve inputs and outputs to a process at the next level of decomposition.
 In other words, Process 1.0, which appears in a level-0 diagram, must have the same inputs and outputs
when decomposed into a level-1 diagram.
 This conservation of inputs and outputs is called balancing.

When to stop decomposition - Primitive DFDs
 Lowest level of decomposition for DFD
 Stop decomposing when:
 Process is a single decision, calculation, DB, operation, such as retrieve, update, create, delete,
or read or menu choice
 Data store represents single entity such as a customer, employee, product, or order
 Data flows do not need further splitting
 When the system user does not care to see any more detail
 When you believe that you have shown each business form or transaction, computer online
display, and report as a single data flow

Making Forms / screens of your Project - Exercise
Make a form/screen for each of the sub-processes that capture input.
This Input will be “Transformed” to output by writing program for the sub-process in
consideration.
The resulted output might be a report, screen showing results, data saving message
etc, etc.

Integrating DFD with ERD

The Basics
What is Data?
In simple words data can be facts related to any object in consideration.
For example your name, age, height, weight, etc are some data related to you.
A picture , image , file , pdf etc can also be considered data.
What is a Database?
Database is a systematic collection of data. Databases support storage and manipulation of data.
Databases make data management easy.
• An online telephone directory.

• Your electricity service provider is obviously using a database to manage billing , client related issues, to
handle fault data, etc.
• The facebook. It needs to store, manipulate and present data related to members, their friends,
member activities, messages, advertisements and lot more.

DBMS and Query Languages
What is a Database Management System (DBMS)?

Database Management System (DBMS) is a collection of programs which enables its users to access database,
manipulate data, reporting / representation of data.
What is SQL?
Structured Query language, pronounced as "S-Q-L" or sometimes as "See-Quel".
 SQL is the standard language for dealing with Relational Databases.

 SQL can be used to insert, search, update and delete database records.
 SQL can do lots of other operations including optimizing and maintenance of databases.
 Relational databases like MySQL Database, Oracle, Ms SQL server, Sybase, etc uses SQL.

NoSQL
What is NoSQL ?
Its main characteristic is its non-adherence to Relational Database Concepts. NOSQL means
"Not only SQL".
Concept of NoSQL databases grew with internet giants such as Google, Facebook, Amazon etc
who deal with gigantic volumes of data.
When you use relational database for massive volumes of data , the system starts getting slow
in terms of response time. To overcome this , we could of course "scale up" our systems by
upgrading our existing hardware.
The alternative to the above problem would be to distribute our database load on multiple
hosts as the load increases. This is known as "scaling out".
NoSQL database are non-relational databases that scale out better than relational databases
and are designed with web applications in mind.
They do not use SQL to query the data and do not follow strict schemas like relational models.
With NoSQL, ACID (Atomicity, Consistency, Isolation, Durability) features are not guaranteed
always
Normalization
NORMALIZATION is a database design technique that organizes tables in a manner that:
1. Reduces redundancy and dependency of data.

2. Divides larger tables into smaller tables and links them using relationships.
3. Ensure data is stored logically. Edgar Codd
The inventor of the relational model Edgar Codd proposed the theory of normalization
with the introduction of the First Normal Form, and he continued to extend theory
with Second and Third Normal Form. Later he joined Raymond F. Boyce to develop the
theory of Boyce-Codd Normal Form
Raymond F. Boyce
Non-normalized data
Without any normalization, all information is stored in one table as shown below
Movies Rented column has multiple values.

First Normal Form
 Each table cell should contain a single value.

 Each record needs to be unique.

The Keys
 A KEY is a value used to identify a record in a table uniquely. A KEY could be a single column or
combination of multiple columns
 Columns in a table that are NOT used to identify a record uniquely are called non-key columns.
Primary Key
 A primary is a single column value used to identify a database record uniquely.
 A primary key cannot be NULL
 A primary key value must be unique
 The primary key values should rarely be changed
 The primary key must be given a value when a new record is inserted
Composite Key
A composite key is a primary key composed of
multiple columns used to identify a record uniquely
In our database, we have two people with the same
name Robert Phil, but they live in different places.

Second Normal Form
Rule 1- Be in 1NF
Rule 2- Single Column Primary Key
It is clear that we can't move forward to make our simple

database in 2nd Normalization form unless we partition
the table above.
1 NF
We divide our 1NF table into two tables. Table 1 and
Table2. Table 1 contains member information. Table 2
contains information on movies rented.
We have introduced a new column called Membership_id

Table 1
which is the primary key for table 1. Records can be
uniquely identified in Table 1 using membership id
Table 2
Foreign Key
Foreign Key references the primary key of another Table! It helps
connect your tables
 A foreign key can have a different name from its primary key
 It ensures rows in one table have corresponding rows in another
 Unlike the Primary key, they do not have to be unique.
 Foreign keys can be null even though primary keys can not
Membership_ID is the Foreign Key

Transitive Dependency
A transitive functional dependency is when changing a non-key column, might cause any
of the other non-key columns to change
In this table, changing the non-key column Full Name may change Salutation.

3 Normal Form
Rule 1- Be in 2NF Table 1

Rule 2- Has no transitive functional dependencies
To move 2NF table into 3NF, we again divide table and created a new table
which stores Salutations.
In Table 3 Salutation ID is primary key, and in Table 1 Salutation ID is foreign

to primary key in Table 3 Table 2
Table 3
Conceptual Data Modeling
 A detailed model that captures the overall structure of data in an

organization. Independent of any database management system (DBMS) or
other implementation considerations.
 The purpose of a conceptual data model is to show as many rules about the
meaning and interrelationships among data as are possible.
 Conceptual data modeling is typically done in parallel with other

requirements analysis and structuring steps during systems analysis
Systems &
Project Analysis Analysis
Designand Design - BIIT – Naveed Ashraf
Workshop
Process of Conceptual Data Modeling
 Develop a data model for the current system
 Develop a new conceptual data model that includes all

requirements of the new system
 In the design stage, the conceptual data model is

translated into a physical design
 Project repository links all design and data modeling

steps performed during SDLC
Relationship between data

modeling and the SDLC

Deliverables and Outcomes of Conceptual Modeling
 Primary deliverable is an entity-relationship (E-R) diagram or class diagram.

1. E-R diagram that covers data needed in the project’s application
2. E-R diagram for the application being replaced
3. E-R diagram for the whole database from which the new application’s data are extracted
4. E-R diagram for the whole database from which data for the application system being
replaced is drawn
 Second deliverable is a set of entries about data objects to be stored in repository or project
dictionary.
1. Repository links data, process, and logic models of an information system.

2. Data elements included in the DFD must appear in the data model and vice versa.
3. Each data store in a process model must relate to business objects represented in the
data model.

Sample – Conceptual Data Model

Naming and Defining Attributes for ER Moeling
 An attribute name is a noun (such as Customer_ID, Age, or
Product_Minimum_Price).
 An attribute name should be unique. No two attributes of the same entity

type may have the same name, and it is desirable, for clarity, that no two
attributes across all entity types have the same name.
 To make an attribute name unique and for clarity, each

attribute name should follow a standard format. For
example, your university may establish Student_GPA,
as opposed to GPA_of_Student, as an example of the
standard format for attribute naming.
 Similar attributes of different entity types should

use similar but distinguishing names; for example,
the city of residence for faculty and students should be,
respectively, Faculty_Residence_City_Name and
Student_Residence_City_Name.

Naming and Defining Attributes
 An attribute definition states what the attribute is and possibly why it is important.
 An attribute definition should make it clear what is included and what is not included in the attribute’s
value; for example, “Employee_Monthly_ Salary_ Amount is the amount of money paid each month in the
currency of the country of residence of the employee exclusive of any benefits, bonuses, reimbursements,
or special payments.”
 Any aliases, or alternative names, for the attribute can be specified in the definition.
 It may also be desirable to state in the definition the source of values for the attribute. Stating the
source may make the meaning of the data clearer.
 An attribute definition should indicate if a value for the attribute is required or optional. This business
rule about an attribute is important for maintaining data integrity.
 An attribute definition may indicate if a value for the attribute may change once a value is provided and
before the entity instance is deleted. This business rule also controls data integrity.
 An attribute definition may also indicate any relationships that attribute has with other attributes; for
example, “Employee_Vacation_Days_Number is the number of days of paid vacation for the employee. If
the employee has a value of ‘Exempt’for Employee_Type, then the maximum value for Employee_
Vacation_Days_ Number is determined by a formula involving the number of years of service for
 the employee.”

Other Attributes Types
Multivalued Attribute
An attribute that may take on more than one value for each entity instance,
represented on E-R Diagram in two ways:
o double-lined ellipse
o weak entity
Repeating Group
 A set of two or more multivalued attributes that are logically related.
 Conceptually, dependents can also be thought of as entities.
 We separate the repeating data into another entity, called a weak (or
attributive) entity (designated by a rectangle with a double line border),
and then use a relationship
 It is sufficient to show Dep_Name in the weak entity and use a double

underline to designate it as a partial identifier.

Other Attributes Types (Cont…)
Required (Mandatory) attribute

An attribute that must have a value for every entity instance.
Optional attribute
An attribute that may not have a value for every entity instance.
Composite attribute
An attribute that has meaningful component parts.
Derived attribute
An attribute whose value can be computed from related attribute values.

Making Entities and assigning attributes - Exercise
Make a list of “Entities” that you are using in your DFDs for input and output
Attach/assign all possible Attributes with each of the Entity.
Create a table for each of the Entity in your DBMS. Attributes will appear as “Fields”
in your tables.
Normalize the tables and Assign “Keys” for establishing “Relationships” among these
tables

Relationships
A relationship is an association between the instances of one or more entity types that is of interest to the organization.
An association usually means that an event has occurred or that there exists some natural linkage between entity
instances.
Relationship type and instances

(a) Relationship type (Completes)
(b) Relationship instances

Entity types, Relationship Degree and Relationship Cardinality
An E-R model is normally expressed as an entity-relationship diagram (E-R diagram), which is a graphical
representation of an E-R model.

Conceptual Data Modeling and ER Model (Degree of Relationship)
The degree of a relationship is the number of entity types that participate in that relationship.
Unary Relationships Also called a recursive relationship, a unary relationship is a relationship between the
instances of one entity type.

Binary Relationships A binary relationship is a relationship between instances of two entity

types and is the most common type of relationship encountered in data modeling.

Ternary Relationships A ternary relationship is a simultaneous relationship among instances of three entity types.

Conceptual Data Modeling and ER Model (Cardinality in Relationship)
Cardinality
The number of instances of entity B that can (or must) be associated with each instance of entity A.
A video store may stock more than one DVD of a given movie. It is also true that the store may not have a single copy of
a particular movie in stock. We need a more precise notation to indicate the range of cardinalities for a relationship.
Minimum Cardinalities
The minimum cardinality of a relationship is the minimum number of instances of entity B that may be associated with
each instance of entity A.
In example, the minimum number of DVDs available for a movie is zero, in which case we say that DVD is an optional
participant in the Is_stocked_as relationship. When the minimum cardinality of a relationship is one, then we say that
entity B is a mandatory participant in the relationship.
Conceptual Data Modeling and ER Model (Cardinality in Relationship)
Maximum Cardinalities
The maximum cardinality is the maximum number of instances. For our example, this maximum is “many”.
The zero through the line near the DVD entity means a minimum cardinality of zero, whereas the crow’s
foot notation means a “many” maximum cardinality.
The double underline of Copy_Number indicates that this attribute is part of the identifier of DVD, but the
full composite identifier must also include the identifier of MOVIE, Movie_Name.

Mandatory Cardinality - Example
 PATIENT Has_recorded PATIENT_HISTORY.
 Each patient has recorded one or more patient histories (we assume that the initial
patient visit is always recorded as an instance of PATIENT HISTORY).
 Each instance of PATIENT HISTORY is a record for exactly one PATIENT.

One Optional, One Mandatory Cardinality - Example
 EMPLOYEE Is_assigned_to PROJECT.
 Each PROJECT has at least one assigned EMPLOYEE (some projects have more than one).
 Each EMPLOYEE may or (optionally) may not be assigned to any existing PROJECT, or may be
assigned to several PROJECTs.

Optional Cardinality - Example
 PERSON Is_married_to PERSON.
 This is an optional zero or one cardinality in both directions because a person

may or may not be married.

Associative Entity
 An entity type that associates the instances of one or more entity types and contains attributes that
are peculiar to the relationship between those entity Instances; also called a gerund.
 An Associative Entity is an:

 Entity
 Relationship

Representing Supertypes and Subtypes
Supertype
A generic entity type that has a relationship with one or more subtypes.
Subtype
A subgrouping of the entities in an entity type that is meaningful to the organization and
that shares common attributes or relationships distinct from other subgroupings.
 Attributes that are shared by all patients (including the

identifier) are associated with the supertype; attributes that
are unique to a particular subtype (e.g., Checkback_Date for
OUTPATIENT) are associated with that subtype.
 Relationships in which all types of patients participate

(Is_cared_for) are associated with the supertype;
relationships in which only a subtype participates
(Is_assigned for RESIDENT PATIENTs) are associated only
with the relevant subtype.

Rules for Supertypes / Subtypes Relationships
Total specialization rule
Specifies that each entity instance of the supertype must be a member
of some subtype of the relationship.
Partial specialization rule
Specifies that an entity instance of the supertype does not have to
belong to any subtype.
Disjoint rule
Specifies that if an entity instance of the supertype is a member of one
subtype, it cannot simultaneously be a member of any other subtype.
Overlap rule
Specifies that an entity instance can simultaneously be a member of
two (or more) subtypes.
 a PERSON must be (total specialization) an EMPLOYEE, an ALUMNUS, or a

STUDENT, or any combination of these subtypes (overlap);
 an EMPLOYEE must be a FACULTY or a STAFF (disjoint), or may be just an

EMPLOYEE (partial specialization);
 a STUDENT can be only a GRADUATE STUDENT or an UNDERGRADUATE

STUDENT and nothing else (total specialization and disjoint).

Business Rules
Business rules are specifications that preserve the integrity of the logical data model. Four basic types
of business rules are as follows:
1. Entity integrity. Each instance of an entity type must have a unique identifier that is not null.
2. Referential integrity constraints. Rules concerning the relationships between entity types.
3. Domains. Contraints on valid values for attribues.
4. Triggering operations. Other business rules that protect the validity of attribute values.

Making a Conceptual ERD
By applying the database rules, make a first version of ERD that show the attributes
and relationships among the entities for your project.

Project Analysis &amp; Design Workshop

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Analysis &amp; Design Workshop

Uploaded by

Copyright:

Available Formats

Project Analysis & Design

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

SDLC Documenting requirements detailing

What is the System Infrastructure?

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Make a list of “All” the requirements of the project allocated to you.

These requirements were thoroughly discussed at the step of “Project Objectives”

Make list and keep it with you for upcoming activities

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

What is “System Thinking” ?

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

 A common form of a process model is a data flow diagram (DFD).

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Set of coherent, interrelated data flow diagrams, such diagrams are:

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

A source/sink might consist of the following:

 Another organization or organization unit that sends data to or

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

1. Capturing data from different sources (e.g., Process 1.0)

 This diagram is called a level-0 diagram because it represents the primary

 Each process has a number that ends in .0 (corresponding to the level

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Make list and keep it with you for upcoming activities

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

 process names begin with an action verb, such as Receive, Calculate,

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

 Each process may consist of several sub processes.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

 This conservation of inputs and outputs is called balancing.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

 Lowest level of decomposition for DFD

 Stop decomposing when:

 Data flows do not need further splitting

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Make a form/screen for each of the sub-processes that capture input.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

• An online telephone directory.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

What is a Database Management System (DBMS)?

 SQL is the standard language for dealing with Relational Databases.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

NORMALIZATION is a database design technique that organizes tables in a manner that:

1. Reduces redundancy and dependency of data.

Movies Rented column has multiple values.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

 Each table cell should contain a single value.

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

It is clear that we can't move forward to make our simple

We have introduced a new column called Membership_id

Membership_ID is the Foreign Key

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Project Analysis & Design Workshop - BIIT – Naveed Ashraf

Rule 1- Be in 2NF Table 1

In Table 3 Salutation ID is primary key, and in Table 1 Salutation ID is foreign

 A detailed model that captures the overall structure of data in an

 Conceptual data modeling is typically done in parallel with other

Project Analysis & Design Workshop

Project Analysis & Design Workshop