Database Management System of

Multi Level marketing organisation

Global office system

By:- Harsh Wardhan

MGM COLLEGE OF ENGINEERING & TECHNOLOGY
NOIDA

CONTENTS
ACKNOWLEDGEMENT
1. Introduction

Motivation

Scope / Feasibility

Functionality

2. Terminology
3. Database
4. Database management
5. Data model
6. RDBMS
Codd's rules
5. Entity
Strong Entity
Weak Entity
6. Attribute
7. Relation
8. KEYS
Super Key

 Candidate Key
Primary Key
Composite key
Foreign Key
9. ER Diagram of MLM organisation management System
10. Extended (Enhanced ) ER Model:
Specialization:
Generalization:
Aggregation:
11. SQL (Structured Query Language)
12. Normalization
Anomalies
Functional dependencies
Normal forms (1nf,2nf)

MLM organisation global office system

INTRODUCTION
This project aims at development of Online MLM industries products/ policies &
Utility which facilitates the Associates to manage their sales business online, and
the database administrators (employee) to modify the backend databases in a
User-Friendly manner.
The Associates are required to register on the server for getting access to the
database and query result retrieval. Upon registration, each user has an account
which is essentially the view level for the Associates. The account contains
comprehensive information of the user entered during registration and permits the
Associates to get access to his past entries of sales, enquire about length of
network , their products & commission , make a fresh registration using D_id,
update his account details, etc.
The database Administrator (employee) is the second party in the transactions. The
administrator is required to login using a master password, once authenticated as
an administrator, one has access and right of modification to all the information
stored in the database at the server. This includes the account information of the
customers, attributes and statistics of sales & network, description of the binary
ratio of network and tags achieved by the Associates, all the new registration of

Associates that have been made, etc. The MLM administrator has the right to
modify any information stored at the server database.

o MOTIVATION This project is dedicated to model the existing MLM

organisation/(other) network marketing systems provide a comprehensive set of
features to enhance their operational limits evaluate their performance in different
scenarios suggest modifications for greater efficiency
O SCOPE AND FEASIBILITY Implementations of this project idea are in industrial
use in the form of online MLM industries. Hence, this can be used for suggesting
improvements in design, performance and greater usability. Apart from the
industrial applications mentioned above, it is a research oriented project as well,
the task of performance evaluation of different database designs, for efficiency, is in
this spirit.
O FUNCTIONALITY The Associates and the MLM Administrators (employee) are the
two parties which interact with the database, who have different view level
schemas to the database information.
Associates Services i. Create an account by registering, uses account details &
online facilities and their organisation and commission ii. Make a new network with
the help of each node of binary tree method, the purchaser are provided to choose
their products/policies etc. s iii. View, modify or cancel the product/policies
registration. iv. Associates are informed, through emails, about updates of policies
and meetings and their commissions. vi. Associates are informed about the various

seasonal offers, targets & competitions. Administrator Services i. Access and

modify Associates accounts or Associates policies.

Terminology
Database
A collection of integrated and related files
Character
Basic building block of information, represented by a byte
Entity
A generalized class of people, places, or things (objects) for
which data are collected, stored, and maintained
E.g., Associates, Employee
Attribute
A characteristic of an entity; something the entity is
identified by
E.g., Associates name, Employee name
Keys

 A field or set of fields in a record that is used to identify the

record
E.g., A field or set of fields that uniquely identifies the
record

Database
A database is an organized collection of data. The data is typically organized to
model relevant aspects of reality (for example, the availability of rooms in hotels),
in a way that supports processes requiring this information (for example, finding a
hotel with vacancies).
A general-purpose database management system (DBMS) is a software system
designed to allow the definition, creation, querying, update, and administration of
databases. Well-known DBMSs include MySQL, PostgreSQL, SQLite, Microsoft SQL
Server, Microsoft Access, Oracle, Sybase, dBASE, FoxPro, and IBM DB2. A database
is not generally portable across different DBMS, but different DBMSs can interoperate by using standards such as SQL and ODBC or JDBC to allow a single
application to work with more than one database.

Database management

A Database Management System (DBMS), is a software program that enables the

creation and management of databases. Generally, these databases will be more
complex than the text file/spreadsheet example in the previous lesson. In fact,
most of today's database systems are referred to as a Relational Database
Management System (RDBMS), because of their ability to store related data across
multiple tables.
Some of the more popular relational database management systems include:

Oracle
DB2
Sybase Adaptive Server Enterprise
FileMaker
Firebird
Ingres
Informix
Microsoft Access
Microsoft SQL Server
Microsoft Visual FoxPro
MySQL
PostgreSQL
Progress
SQLite
Teradata
CSQL
OpenLink Virtuoso
Process to Design a database management

Database creation

Tables

Adding data to your database

Querying a database

Relational database design

DATA MODEL
Planned data redundancy
A way of organizing data in which the logical database design is altered so
that certain data entities are combined
Summary totals are carried in the data records rather than calculated from
elemental data
Some data attributes are repeated in more than one data entity to improve
database performance
Data model
A map or diagram of entities and their relationships
Enterprise data modeling
Data modeling done at the level of the entire organization
Entity-relationship (ER) diagrams
A data model that uses basic graphical symbols to show the organization of and
relationships between data

RDBMS
A relational database management system (RDBMS) is a database
management system (DBMS) that is based on the relational model as introduced
by E. F. Codd, of IBM's San Jose Research Laboratory. Many popular databases
currently in use are based on the relational database model.

RDBMSs have become[when?] a predominant choice for the storage of information in

new databases used for financial records, manufacturing and logistical information,
personnel data, and much more. Relational databases have often replaced
legacy hierarchical databases and network databases because they are easier to
understand and use. However, relational databases have been challenged by object
databases, which were introduced in an attempt to address the object-relational
impedance mismatch in relational database, and XML databases.

Codd's 12 rules

Rule 0: The system must qualify as relational, as a database, and as

a management system. For a system to qualify as a relational database
management system (RDBMS), that system must use its relational facilities
(exclusively) to manage the database.

Rule 1: The information rule: All information in a relational database (including

table and column names) is represented in only one way, namely as a value in a
table.

Rule 2: The guaranteed access rule: All data must be accessible. This rule is
essentially a restatement of the fundamental requirement for primary keys. It says
that every individual scalar value in the database must be logically addressable by

specifying the name of the containing table, the name of the containing column and
the primary key value of the containing row.

Rule 3: Systematic treatment of null values: The DBMS must allow each field to
remain null (or empty). Specifically, it must support a representation of "missing
information and inapplicable information" that is systematic, distinct from all
regular values (for example, "distinct from zero or any other number", in the case
of numeric values), and independent of data type. It is also implied that such
representations must be manipulated by the DBMS in a systematic way.

Rule 4: Active online catalog based on the relational model: The system must
support an online, inline, relational catalog that is accessible to authorized users by
means of their regular query language. That is, users must be able to access the
database's structure (catalog) using the same query language that they use to
access the database's data.

Rule 5: The comprehensive data sublanguage rule: The system must support at
least one relational language that
1. Has a linear syntax
2. Can be used both interactively and within application programs,
3. Supports data definition operations (including view definitions), data
manipulation operations (update as well as retrieval), security and

integrity constraints, and transaction management operations (begin,

commit, and rollback).
Rule 6: The view updating rule: All views that are theoretically updatable
must be updatable by the system.

Rule 7: High-level insert, update, and delete: The system must support setat-a-time insert, update, and delete operators. This means that data can be
retrieved from a relational database in sets constructed of data from multiple
rows and/or multiple tables. This rule states that insert, update, and delete
operations should be supported for any retrievable set rather than just for a
single row in a single table.

Rule 8: Physical data independence: Changes to the physical level (how the
data is stored, whether in arrays or linked lists etc.) must not require a
change to an application based on the structure.

Rule 9: Logical data independence: Changes to the logical level (tables,

columns, rows, and so on) must not require a change to an application based
on the structure. Logical data independence is more difficult to achieve than
physical data independence.

Rule 10: Integrity independence :Integrity constraints must be specified

separately from application programs and stored in the catalog. It must be

possible to change such constraints as and when appropriate without

unnecessarily affecting existing applications.

Rule 11: Distribution independence :The distribution of portions of the

database to various locations should be invisible to users of the database.
Existing applications should continue to operate successfully :
1. when a distributed version of the DBMS is first introduced; and
2. when existing distributed data are redistributed around the system.
Rule 12: The non subversion rule :If the system provides a low-level (record-at-atime) interface, then that interface cannot be used to subvert the system, for
example, bypassing a relational security or integrity constraint

E R Model:
E R model refers to Entity Relationship model. It is the graphical representation of
database. ER Model describes data as Entities , attributes and relationship.
Entity is the real world object or in other words entity can be anything in the real
world which can be described by its attributes .
Attributes are some properties which describes the entity.
Relationship describe the association among two or more entities.

ENTITY: A generalized class of people, places, or things (objects) for

which data are collected, stored, and maintained .

ENTITY

Weak Entity: Those entities which do not have any primary key are called weak
entities.
Strong Entity: Those entities which have at least one or more primary key are
called strong entities.

Attributes
An attribute is a property or characteristics that hold some information
about an entity. A Customer for example, has attributes such as a
name, and an address.

ATTRIBUTE

Relations
In the relational data model, the data in a database is organized in
Relations . A relation is synonymous with a table. A table consists of
columns and rows, which are referred as field and records in DBMS
terms, and attributes and tuples in Relational DBMS terms.

RELATIONS

Relational Keys

There are many types of keys that can be defined in the relational model. These
have significant importance in maintaining data consistency and correctness in the
database.

a)

Super Key: is the combination of one attribute (field) which has unique

value and any other field in the database. For ex. In any bank , customer is
identified by customer name and account no. So combination of customer name
and account no. formed super key.

b)

Candidate Key: Because in super key we use some extraneous

field while we can identify or separate the entity through one field which
has unique value in the database. This unique attribute is referred as candidate
key. For ex . Customer can be identified through account no. so there is no need to
use extra field customer name.
C)

Primary Key:

Primary key is a candidate key which is used to

restrict duplicity in any field. In candidate key there is no provision to avoid

duplicity so this concept is used. Primary key always be selected to those field at
which we want to apply the restriction to avoid duplicity .

d)

Composite key ; A minimal set of attributes in a table that

uniquely identifies a record.

When there is more than one attribute in the candidate key, it is called
composite key.

e)

Foreign Key: An attribute or a set of attributes of one table that

is matched to candidate
keys of another table (or even the same table). That is, a child table may
reference the
parent table for appropriate attribute values. Please note that the
corresponding attributes
in two different tables must have the same data type and domain

Rg_id

NAME

City_add

asset

MLM ORGANISATION
commission

nominee
D_id

associated

Org_lngth
Tr_id

Associates

Ass_name

sales

purchase

PRODUCTS
& policies

Used by

Login_box

Iso_id

Global_office

Pr_type

Asso_info

Pr_cost
Pr_name

Pr_info

manages
news

Employee
Employee_id
Employee_name
Dependent_name
Start_date
Employment
length

City_add

Mo_no

Emp_salary

Extended(Enhanced ) ER Model:
The ER modeling concepts are sufficient for representing traditional database
application. For more complex database application such as telecommunications ,
CAD/CAM , GIS etc , we need more complex requirements than traditional
applications. In late 1970s database designers have tried to design more accurate
ER model , which reflects the data properties and constraints more accurately . So
extended(Enhanced ) ER model have some enhanced features than normal ER
model. It uses the concepts of Specialization , Generalization , Aggregation.
Specialization:
Specialization is the process through which we can relate one entity to more than
one entity. In other words specialization is the process to defining a set of
subclasses of an entity type.
Generalization:
Generalization is just reverse of Specialization. Generalization is the process to
define a generalized entity type from the given entity type. For ex. consider the two
entity software and holiday accommodation. Because both have some common
attributes, their combination make a super entity called products. So it is the
process to identify the common features (attributes) from
Two or more entity and generalized them into a super entity.

E_R DIAGRAM NOTATION FOR AN ATRIBUTE DEFINEND SPECIALISATION ON

JOB TYPE

GENERALIZATION (b) Generalizing software and holiday

accommodation package into a supper class products

Brand

price

Iso_reg no

An org products

specification

license

software

Time_ses
sion

places

Holiday accommodation
package

Aggregation:
Aggregation is the combined part of specialization and generalization. It is the
process to define both specialized and generalized entity. Manager is a employee
works on branch and manage the works of branch. It shows the relationship
between two relations.

JOB

Employee

Works
on

manages

Manager

Branch

SQL(Structured Query Language)

SQL (Structured Query Language) is a special-purpose programming
language designed for managing data held in a relational database management
systems (RDBMS).
Originally based upon relational algebra and tuple relational calculus, SQL consists
of a data definition language and a data manipulation language. The scope of SQL
includes data insert, query, update and delete, schema creation and modification,
and data access control. Although SQL is often described as, and to a great extent
is, a declarative language (4GL), it also includes procedural elements.
SQL was one of the first commercial languages for Edgar F. Codd's relational model,
as described in his influential 1970 paper "A Relational Model of Data for Large
Shared Data Banks".[5] Despite not adhering to the relational model as described by
Codd, it became the most widely used database language.[6][7]
SQL became a standard of the American National Standards Institute (ANSI) in
1986, and of the International Organization for Standards (ISO) in 1987.[8] Since
then, the standard has been enhanced several times with added features. But code
is not completely portable among different database systems, which can lead
to vendor lock-in. The different makers do not perfectly follow the standard, they
add extensions, and the standard is sometimes ambiguous.

NORMALIZATION
Normalization is process, by which we ca create an efficient database or
we design an efficient database . we have to reduce the redundancy and
increase the efficiency.

Problems addressed by normalization

An Update Anomaly. Employee 519 is shown as having different

addresses on different records.
An Insertion Anomaly. Until the new faculty member is assigned to
teach at least one course, his details cannot be recorded.
A Deletion Anomaly. All information about Dr. Giddens is lost when
he temporarily ceases to be assigned to any courses.
A table that is not sufficiently normalized can suffer from logical
inconsistencies of various types, and from anomalies involving data
operations. The same information can be expressed on multiple records;
therefore updates to the table may result in logical inconsistencies.
For example, each record in an "Employees'
Skills" table might contain an Employee ID, Employee Address,
and Skill; thus a change of address for a particular employee will
potentially need to be applied to multiple records (one for each of
his skills). If the update is not carried through successfullyif,
that is, the employee's address is updated on some records but not
othersthen the table is left in an inconsistent state. Specifically,
the table provides conflicting answers to the question of what this
particular employee's address is. This phenomenon is known as
an update anomaly.
There are circumstances in which certain facts cannot be recorded
at all. For example, each record in a "Faculty and Their Courses"
table might contain a Faculty ID, Faculty Name, Faculty Hire
Date, and Course Codethus we can record the details of any
faculty member who teaches at least one course, but we cannot
record the details of a newly-hired faculty member who has not
yet been assigned to teach any courses. This phenomenon is
known as an insertion anomaly.
There are circumstances in which the deletion of data
representing certain facts necessitates the deletion of data
representing completely different facts. The "Faculty and Their
Courses" table described in the previous example suffers from

this type of anomaly, for if a faculty member temporarily ceases

to be assigned to any courses, we must delete the last of the
records on which that faculty member appears. This phenomenon
is known as a deletion anomaly.

Functional Dependency: Attribute B has a functional

dependency on attribute A i.e. A B if, for each value of
attribute A, there is exactly one value of attribute B. If value of A
is repeating in tuples then value of B will also repeat. In our
example, Employee Address has a functional dependency on
Employee ID, because a particular Employee ID value
corresponds to one and only one Employee Address value. (Note
that the reverse need not be true: several employees could live at
the same address and therefore one Employee Address value
could correspond to more than one Employee ID. Employee ID is
therefore not functionally dependent on Employee Address.) An
attribute may be functionally dependent either on a single
attribute or on a combination of attributes. It is not possible to
determine the extent to which a design is normalized without
understanding what functional dependencies apply to the
attributes within its tables; understanding this, in turn, requires
knowledge of the problem domain. For example, an Employer
may require certain employees to split their time between two
locations, such as New York City and London, and therefore
want to allow Employees to have more than one Employee
Address. In this case, Employee Address w would no longer be

functionally dependent on Employee ID.

Trivial Functional Dependency: A trivial functional

dependency is a functional dependency of an attribute on a

superset of itself. {Employee ID, Employee Address}
{Employee Address} is trivial, as is {Employee Address}
{Employee Address}.
Full Functional Dependency: An attribute is fully functionally
dependent on a set of attributes X if it is
- functionally dependent on X, and
- not functionally dependent on any proper subset of X. {Employee
Address} has a functional dependency on {Employee ID, Skill},
but not a full functional dependency, because is also dependent
on {Employee ID}.
Transitive Dependency: A transitive dependency is an indirect
functional dependency, one in which XZ only by virtue of
XY and YZ.

Multivalued Dependency: A multivalued dependency is a

constraint according to which the presence of certain rows in a
table implies the presence of certain other rows: see the
Multivalued Dependency article for a rigorous definition.
Join Dependency: A table T is subject to a join dependency if T
can always be recreated by joining multiple tables each having a
subset of the attributes of T.
Normal Forms
The normal forms (abbrev. NF) of relational database theory provide
criteria for determining a table's degree of vulnerability to logical
inconsistencies and anomalies. The higher the normal form applicable to
a table, the less vulnerable it is to inconsistencies and anomalies. Each
MBA 758 DATABASE MANAGEMENT SYSTEM table has a "highest normal
form" (HNF): by definition, a table always meets the requirements of its
HNF and of all normal forms lower than its HNF; also by definition, a table
fails to meet the requirements of any normal form higher than its HNF.
First normal form: A table is in first normal form (1NF) if and only if
it represents a relation. Given that database tables embody a relation-like
form, the defining characteristic of one in first normal form is that it
does not allow duplicate rows or nulls. Simply put, a table with a unique
key (which, by definition, prevents duplicate rows) and without any
null able columns is in 1NF.
Second normal form: The criteria for second normal form (2NF) are:
The table must be in 1NF.
None of the non-prime attributes of the table are functionally dependent on
a part (proper subset) of a candidate key; in other words, all functional
dependencies of non-prime attributes on candidate keys are full functional
dependencies. For example, consider an "Employees' Skills" table whose
attributes are Employee ID, Employee Name, and Skill; and suppose that
the combination of Employee ID and Skill uniquely identifies
records within the table. Given that Employee Name depends on
only one of those attributes namely, Employee ID the table is
not in 2NF.
In simple, a table is 2NF if it is in 1NF and all fields are
dependant on the whole of the primary key, or a relation is in
2NF if it is in 1NF and every non-key attribute is fully dependent
on each candidate key of the relation.
Note that if none of a 1NF table's candidate keys are composite
i.e. every candidate key consists of just one attribute then we
can say immediately that the table is in 2NF.
All columns must be a fact about the entire key, and not a subset
of the key.