Thesis SIMS

8/11/2019 Thesis SIMS

1/50

Bachelor's thesis

Information Technology

Networking

2013

Hari Krishna Mahat

DESIGNING A LOGICAL DATAMODEL FOR A SALES ANDINVENTORY MANAGEMENT SYSTEM


2/50

ii

TURKU UNIERSITY OF APPLIED SCIENCE, BACHELORS THESIS| Hari Krishna Mahat

BACHELORS THESIS | ABSTRACT

TURKU UNIVERSITY OF APPLIED SCIENCES

Degree programme | Information technology

December 2013| 39

Instructor: Yngvar Wikstrom M.Eng

Author: Hari Krishna Mahat

DESIGNING A LOGICAL DATA MODEL FOR ASALES AND INVENTORY MANAGEMENT SYSTEM

The aim of this thesis was to design a Sales and Inventory Management System (SIM),

that is, a database describing the customer orders and products distributed by the

company.

The SIM system shall help in the management of product sales and processing,

inventory management process and operation outside the book-keeping system

already in use. The SIM system shall be based on a Database Management System.

The purpose of the SIM database system is to maintain the data that is used and

generated from the warehouse staff and sales staff. Then the data stored will be used

to facilitate smooth running of sales operation and stock management. The sole aim

and objective of this thesis was to create a logical data model independent of

Relational Database Management System for Sales and Inventory Management

System.

All the data generated during the business process was studied to design a very well

functioning database that will comfort the growth of company. Sales staff and

warehouse staff were interviewed, in total 11, on their needs and requirements. These

needs and requirements were given high importance throughout the design process. A

system independent logical database design was produced from this project work.

The data dictionary, ER diagrams, conceptual data model, high level data transaction

details, data flow diagrams and logical data model are the outcome of this project work.

KEYWORDS:

(Data model, database, entity-relation, requirements analysis)


3/50

iii

TURKU UNIERSITY OF APPLIED SCIENCE, BACHELORS THESIS| Hari Krishna Mahat

FOREWORD

Sales and Inventory Management System design is a design process of a database

system for a company named RB and Sons Private Limited. RB and Sons is a

distributor company which has acquired contracts from three different manufacturers to

solely distribute their products in the Kathmandu region, Nepal.

RB and Sons is currently using the traditional paper and pen format to maintain the

inventory and to serve their customers. All the billings and stocking are done by writing

reports and producing bills in paper format. This way of keeping records is becoming

challenging as the business is growing as they are acquiring more contracts from more

manufacturers and more customers to serve, hence causing more work load on

inventory management and sales operations.

With more products in line for sales and marketing, the work for sales staff is also

increasing exponentially. RB and Sons is currently employing 7 employees in sales, 2

in delivery, the owner as the CEO and 1 accountant. In total for the time being, RB and

Sons employs 11 members of staff.

I would like to thank and express my appreciation to my supervisor Mr. Yngvar

Wikstrom for being a great advisor and a mentor. All his advices, support and

encouragement during my thesis have been a source of inspiration to me.

I would also like to thank RB and Sons family, for their trust and support on me during

my thesis. Their views, ideas, and suggestion help me very much during many phases

of design process. I am very grateful towards every member of RB and Sons, and

looking forward to work with them also in application development process.

05-12-2013, Turku

Hari Krishna Mahat


4/50

CONTENT

1. INTRODUCTION 1

2. SALES AND INVENTORY MANAGEMENT DATABASE DESIGN PROCESS 2

2.1 Objective of the SIM system 2

2.2 Sales and Inventory Management Database Design phase 2

2.3 Logical Database Design 3

2.4 Physical Database Design 3

3. REQUIREMENT COLLECTION AND ANALYSIS 4

3.1 Requirements collections 4

3.1.1 Examining Documentation 4

3.1.2 Interviewing and Questionnaires 53.2 Database Requirements 7

3.2.1 Initial Database Size 73.2.2 Database Growth 73.2.3 Searches and inquiry 73.2.4 Networking and shared access requirements 83.2.5 Security 83.3 Functional Requirements 8

3.3.1 Administration Functional Requirements 83.3.2 Sale Manager Functional Requirements 93.3.3 Inventory Manager Function Requirements 93.3.4 Salesmen Functional requirements 93.4 Users transaction requirements 10

3.4.1 Data entry 103.4.2 Data update/deletion 10

3.4.3 Data query 10

4 FUNCTIONAL ANALYSIS 12

4.1 Input 12

4.2 Process 12

4.3 Output 135 CONCEPTUAL DATABASE DESIGN 14

5.1 Definition 14

5.2 Conceptual Database Design Methodology 14

5.2.1 Identifying entity types 155.2.2 Identifying relationship types 165.2.3 Determining attribute domains 205.2.4 Determining candidate, primary, and alternate keys 215.2.5 Redundancy check for the conceptual model 225.2.6 Conceptual model validation with users transaction 23

5.2.7 Reviewing the conceptual data model with users 24


5/50

6 LOGICAL DATABASE DESIGN 25

6.1 Definition 25

6.2 Logical database design methodology 25

6.2.1 Deriving relations for the logical data model 256.2.2 Validating relations using normalization 296.2.3 Validating relations against user transactions 306.2.4 Checking integrity constraints 306.2.5 Reviewing logical data model with user 327 DESIGNING SECURITY MECHANISM 34

7.1 Database secutiy threats 34

7.2 Computer-based controls 35

7.2.1 Authentication and authorization 377.2.2 Access controls 38

7.2.3 Views 387.2.4 Encryption 387.2.5 Whitelist and blacklist 398 OVERVIEW OF THE PROJECT WORK 40

8.1 Problems faced Error! Bookmark not defined.

8.2 Preparation and collecting specifications 40

9 SUMMARY ERROR! BOOKMARK NOT DEFINED.

REFERENCES


6/50

FIGURES

Figure 1.A simplified diagram to illustrate the main phases of database design

(Elmasri Navathe, 2011, p.201). 3

Figure 3. Sales view 16

Figure 4. Warehouse view 17

Figure 5. staff users view. 17

Figure 6. Domain pool for ID attributes possible value 21

Figure 7. UML diagram with entities and primary keys 22

Figure 8. Using pathways to validate conceptual model meets user transaction

requirements. 23

Figure 9. UML data model showing all attributes at this stage of development phase. 26

Figure 10. UML diagram representing pk fk mechanism for relationships 29

Figure 11. Users Real world data flow diagram (DFD) 32

Figure 12. Modified using Entity-Relation (ER) method for global data model (Elmasri &

Navathe, 2011,ch. 3) 33

Figure 13. Users' system environment 36

TABLES

Table 1. Description of entities to form data dictionary (Connolly, 2005, p.444) 15

Table 2. Documentation of attributes and entities (Connolly, 2005, p.450) 19

Table 3. Associating entities with candidate keys, primary key and alternate keys 21

Table 4. Referential integrity constraints 31

Table 5. Threat documentation (Connolly, 2005, p.544) 35

Table 6. Login rule 37

Table 7. Blacklist and whitelist prototype table 39


7/50

NOTATION

ak Alternate Key

CEO Chief Executive Officer

DBDL Database Design Language

DBMS Database Management System

ER Entity-Relationship

ERD Entity-Relationship Diagram

EERD Enhanced Entity-Relationship Diagram

fk Foreign Key

IT Information Technology

pk Primary key

RDBMS Relational Database Management System

SIM Sales and inventory management system

sk Secondary Key

UML Unified Modelling Language


8/50

1

TURKU UNIVERSITY OF APPLIED SCIENCES, BACHELORS THESIS | Hari Krishna Mahat

1. INTRODUCTION

A distributor company, which is using paper pen format to keep their records till the day

wishes to use computer technology to keep track of all its transactions and day to day

operation to achieve its business goal. The company acquires products from the

manufacturers and distributes them to the retail shop in the area. The business is

basically buying and selling different kinds of consumer goods.

The goal of the company is to make warehouse staffs work effectively efficient by using

computer technology. Warehouse staffs were having problems all the time to keep

track of the goods coming in and going out of the warehouse. The sales staffs are

using papers for the orders they receive from the retailers. The problem with paper

orders is that, they are all the time misplaced. On times when several sales persons

need to see the same record, records being in paper format cause problems. These

problems have increased the need for computer technology.

The company at the moment is fully dependent on its staff skills of recording

information using the paper and pen. This dependency of owner among the workers is

wasting money and time. The designed system will be used to maintain the data that is

used and generated to support the distribution operations of the company. Data stored

in the system will be shared among the staff of the company to facilitate the

cooperation and sharing of information between sales and warehouse staff.

This thesis includes only the conceptual design of the computer system and not a

complete implementation of the designed data model. The designed logical data model

will be forwarded to the database programmer who will convert the logical data model

into a fully working database with a user friendly interface. However thesis includes

brief planning of database security and user authentication.


9/50

2


2. Sales and Inventory Management Database DesignProcess

The aim of database design is to produce an integrated database which is accurate

and secure. The objective is to achieve the business goal of the company in a more

efficient way than in the current system. The process aims to design and develop an

integrated database system which will support the application system effectively and

efficiently.

2.1 Objective of the SIM system

The company wanted to resolve all the current problems introducing a computer-based

solution. A Sales and Inventory Management System was considered as the viable

solution for the problems. Using the currently available SIM software would require

technical staff to handle the software. SIM software available in the market today is

expensive for the company to afford and maintain. In addition to the expenses of the

SIM software, hiring a new IT member of staff to maintain the software would be more

costly. Most of the SIM software available would not exactly meet the companys needs

and requirements. Hence, the company decided to develop its own SIM system,

naming it SIM plus which would meet all the needs and requirements of the company.

SIM plus would be developed studying the companys requirements. Staff would befamiliar about the system from the beginning of its development phase.

The SIM plus system would serve the data storage needs of the company. The System

will keep records of all the transaction made during the business and will provide for

future references. The system will be designed and made ready for the implementation,

studying the operational environment and needs of the company. The focus of thesis

work is identifying user requirements and the development of system independent

logical database design which will meet user requirements.

2.2 Sales and Inventory Management Database Design phase

The database design process is divided into different sets of design tasks according to

the design process being followed. This thesiswork shall focus on the logical database

design. The physical database design phase shall only be introduced.


10/50

3


2.3 Logical Database Design

The focus on logical database design is to find the user requirements, study the

existing system finding the problems users are having with the current system and

study the company business environment. The outcome is the development of a

system-independent description of a database that shall fulfil all the requirements.

2.4 Physical Database Design

The physical database design is the actual implementation of the database into the

system. The physical database design depends on the Relational Database

Management System (DBMS) selected by the user or designer. It depends on the

hardware and software environment.

The graphical representation of the database design approach that is followed for this

purpose is shown below:-

Figure 1.A simplified diagram to illustrate the main phases of database designs

(Elmasri Navathe, 2011, p.201).


11/50

4


3. Requirement collection and Analysis

Knowing the requirements and needs of clients is vital to the success of a project.

Hence we will be following some approaches to finding facts. The following are some of

the most widely used fact-finding techniques used to find facts about the needs and

requirements of the company:-

Examining documentation

Interviewing

Observing the enterprise in operation

Research

Questionnaires.

The purpose of using this fact-finding technique is to find out

the aims and objectives of SIM plus from users point of view

the different usersview

the system requirements and performances as well as security

requirements

The functional features company wishes to have in the system.

3.1 Requirements collections

In this step, the methods used to collect the enterprise data requirements have been

described.

3.1.1 Examining Documentation

All the documents from the past operations of company were examined and studied.

The following were the documents that were studied during the process:-

a. Incoming order records

b. Clients records

c. Clientscomplaint records

d. Inventory records

e. Manufacturers records

f. Products list

g. Invoices

h. Staff records.


12/50

5


From the study of the companys documentation, all the possible data and data types

were recorded.

3.1.2 Interviewing and Questionnaires

The CEO and all staff members currently employed in the company were interviewed.

The purpose of the interviews was to gather further information on the problems the

staff are facing and their possible solution from the new system that is to be developed.

The interviews were conducted as a structured interview. All the interviewees were

asked both open-ended as well as closed-ended questions. The following were the

questions asked during the interview.

Questions for the CEO

a. What is your business about?

We are a distributor company. We receive goods from different manufacturers

and supply them to retailers.

b. Why do you feel that you need computer technology?

Currently we are keeping records in paper sheets. The problems with paper

sheets are they get misplaced and records gets lost most of the time, to find

one particular record we have to go through piles of documentation. We thought

computer technology will help us to overcome this problem we are facing with

paper records.

c. Why dont you choose existing Sales and Inventory System?

They are quite expensive to buy and maintain, needs to have one more IT

staffs, which in our current situation seems more costly. Moreover, existing

system does not exactly meet our needs despite of investing lots of money;they will still require further development and changes to meet our needs.

d. How do you think, development of new system will solve your problem?

This system will be developed according to our business environment. We can

always put our thoughts and ideas in its development. We will familiar with it

since the day of its development. We can develop it considering our future

growth and requirements.


13/50

6


Questions for the warehouse manager

a. What is your job description?

Being a warehouse manager, my job mostly involves managing records of

incoming and outgoing products from the warehouse. Observe the stock in

warehouse, make reports and manage warehouse staff.

b. What kinds of task do you perform in daily basis?

Most part of my job includes managing records and keeping track of goods

available in the warehouse and generate reports. I also have to notify the CEO

when there is a change in the profit margin offered to us by the manufacturer.

Labelling of products and organizing products in warehouse.

c. What kind of data do you work with?

I keep records of products from different manufacturers coming in warehouse. I

keep records of orders sent to my sales personnel and dispatch the orders. I

send re-ordering of products to our suppliers and manufacturers.

d. What do your need to make your work easier and faster?

A system where I can easily record all the products with proper descriptions. A

system which enables to keep track of all products quantity in warehouse andalarms when stock is less than a certain amount. A system which generates

incoming and outgoing products report graphically.

Questions for the sales manager

a. What is your job description?

I manage the entire sales personnel for the company. I deploy our sales

personnel to their local area to collect the orders from our client retailers. I

collect all the sales orders and forward them to warehouse for the delivery. I

keep records of all clients and possible clients in our business region and get us

new clients. I make reports about the most ordered goods in certain time.

b. What kind of task do you perform in daily basis?

I deal with sales orders and our sales personnel. I deploy our sales personnel

on a certain region based on weekly routines. I make calls and receive calls

from clients and possible clients.


14/50

7


c. What kind of data do you work with?

I work with sales orders which include products, quantity, amount, tax. I deal

with clientsinquiries about certain product details. I make frequent inquiries

about the stock quantity for products in the warehouse.

Using these fact finding techniques as described by Connolly in his book: A Practical

Approach to Design, Implementation and Management, the requirements of the

company were collected and analyzed.

3.2 Database Requirements

3.2.1 Initial Database Size

Currently the company employs in total eleven staffs, five sales staffs, two warehouse

staffs a C.E.O and two delivery staff and an accountant. The company is working as a

distributor for three different manufacturers. The number of products each

manufacturer supplies are different from each other. All the products the company

distributes shall be stored in the database of the SIM plus system.

3.2.2 Database Growth

In future the company expects to acquire more distribution contract from other

manufacturers and suppliers. Increases in the types of products from the

manufacturers will result in increased data in the database. The company wishes to

grow more acquiring distributorships from other manufacturers in the future. When

company receives more manufacturers goods to distribute, the data that company

shall handle will increase exponentially.

3.2.3 Searches and inquiry

Most of the searches are made by the sales manager and sales staff. The frequency of

queries will be high during the first business hour by the sales staff. The inquiry shall be

less after the first business hour and will be high again during the mid-day. Warehouse

staff will most likely check the records every afternoon before the closing so the chunks

of data will be searched during that time.


15/50

8


3.2.4 Networking and shared access requirements

Every sales and warehouse member of staff will have their own workstations. Each

workstation will be connected to the local server where the system database will reside.

Each system user will access the system from the interface program installed in the

local workstation. The system server will be connected only to the local intranet. The

system can only be accessed from the local intra network.

3.2.5 Security

The system will be password-protected. Each user will be assigned system access

privileges appropriate to the particular user view. Staff members shall see only the data

necessary to perform their job. The system will be disconnected from World Wide Web

to prevent all possible hacking and cracking from the Internet. The system should only

be accessed from local workstations.

3.3 Functional Requirements

After the staff interviews and the study carried of the documents, the functional

requirements of the company were identified. The functional requirements of the

system vary for each user group. Hence the functional requirements of the system are

categorized for each user. The following are the functional requirements of the system.

3.3.1 Administration Functional Requirements

The CEO acts as the system administrator.

System login function, with password change functionality after login

Create new user of the system with staff details, limit their privileges according

to their job description

Add new item and category into system product list Edit and update product prices

Remove item and category from inventory with precautions message

Delete and update system users


16/50

9


3.3.2 Sale Manager Functional Requirements

System login function through the user interface and change password after

first login.

View inventory status

Products search function by product code or by product name or by product

category

Check bills generated for the day

Check money transaction for the day

Check the bills cancelled

Check returned products

Generate sales-trend graph.

3.3.3 Inventory Manager Function Requirements

System login function through user interface and change password after first

login

Add product details and prices into the system

Check the inventory status, minimum and maximum stock point and order point

Update the inventory according to the sales done in previous day

Create inventory reports of items category-wise, price-wise

Generate inventory-trend graphs.

3.3.4 Salesmen Functional requirements

System login function and change password function

View the inventory status

Product search function by product name or product code or product category

Create purchase order entering purchase details

Cancel the bills in case of error in entering the details Enter the product details for the returned order.


17/50

10


3.4 Userstransaction requirements

The operations operated over the database objects are transaction. The minimum

required user transactions are described in this section which should be implemented

during physical database design process. The transaction requirements for the

company were discovered during the companys document analysis and fact collecting

techniques used to collect users views and ideas about the system.

3.4.1 Data entry

Enter the detail of suppliers

Enter the details of products

Enter product category detailsEnter new and existing staffsdetails

Enter role details of each staff

Enter customer details.

Enter order, order details.

Enter dispatched order details.

Enter payments details.

3.4.2 Data update/deletion

Update/delete staff details.

Update/delete product details.

Update/delete product category details.

Update/delete order, order details.

Update/delete customer details.

Update/delete supplier details.

Update/delete payment details.

3.4.3 Data query

List the details of staffs.

List details of each staff roles.

List details of suppliers.

List details of each product.

List products in stock.


18/50

11


List products reaching minimum stock level.

List products hitting re-order level.

List products by category

List available category details.

List customer details.

List all incoming order details

List all dispatched order

List payment details for recent orders

List orders with credit payments and customer details

List total number of order.

List orders with full payments (balance 0).

In this chapter, the required users transactions are described. The reports that need to

be generated using the systems are described in this chapter. The design of the

reports shall be designed by the physical designer meeting the needs of the companys

current report formats.


19/50

12


4 Functional Analysis

In this step of design process, the brief analysis of all the function that user wishes to

have in the system is described.

4.1 Input

The data that shall be fed into the system will be inserted by the user of the system.

The data each user feeds to the system is different. The following are the types of data

that will be fed to the system:

Username, password and new changed password

New user details

Product details and category

Incoming product details

Order details

Cancelled bills

Return products details

Search parameter (product name, product category, product ID )

4.2 Process

After the data is fed to the system, the system will process data to generate output. The

processes that should be processed by the system are as follows:

Authentication of existing username and password

Save any changes to database (add, delete, update products/categories)

Carry the search within database

Generate bill for the sales item

Cancel the bills generated in case of error Produce invoice for the purchase order

Produce bills or reports for return purchase

Validate the inventory stocks

Generate reports on minimum stock point maximum stock point and order point


20/50

13


4.2 Output

The system processes the data that is fed into the system. The system shall produce

different kinds of reports as the outputs. The following are the outputs the system shall

produce:

Product lists

Maximum stock point, minimum stock point, order point

Detailed reports on purchase and sales

Reports on dispatched orders

Reports on due payment from clients over certain period of time

Inventory trends and graphs

User information and clients information

Product details on execution of search query


21/50

14


5 Conceptual Database Design

In this step of project, the conceptual database methodology IS used for database

design during the database development lifecycle for a relational database is

described.

5.1 Definition

Conceptual database design: The process of constructing a model of data used in an

enterprise, independent of all physical consideration. (Connolly, 2005, p.439)

In database design process, the first phase of database design after the collection and

analysis of user requirements is the conceptual database design. The purpose of this

design process is the creation of a conceptual data model independent of Database

Management System software, application programs, programming language,

hardware platforms or any other physical systems. During the process, user

specifications and requirements are closely followed.

The conceptual data model is tested and validated with the users requirements and

specification. A well designed conceptual data model is the key for success of next

phase of design process: Logical Database design and whole database system in

general.

5.2 Conceptual Database Design Methodology

The idea of using a design methodology is to give structure to the procedures,

techniques, tools and documentation to support and facilitate the process of designing.

The following are the steps in methodology that are followed during the conceptual

database design process for the company.

Using the conceptual database design methodology as described by Connolly in hisbook: A Practical Approach to Design, Implementation and Management, the

conceptual data model shall be designed.


22/50

15


5.2.1 Identifying entity types

The process of identifying entity types involves reorganization of user interested

objects. User requirements specification is vital to the success of identification of

entities. The company has two types of staff, namely, warehouse staff and sales staff

who will use the system the most. Hence the entity is identified classifying the entity

type.

a. Identifying warehouse entities

The following are the possible warehouse entities:-

Warehouse staff, products, suppliers, orders

b. Identifying sales entities

The following are the possible sales entities:-

Sales staff, products, customers, orders, payments

c. Documentation of entity types

Table 1. Description of entities to form data dictionary (Connolly, 2005, p.444)

Entity Name Description Aliases Occurrence

Staff Describes all the

staffs in companywarehouse or sales

Employee Warehouse and

sales mainly twotypes of staffs

Product Describes all theitems the companywill be distributing

Distributing items Each product hasits own supplier andis different fromother

Supplier Manufacturer ormanufacturersagents who supplyitems fordistribution

Mainlymanufacturer

Each supplier dealswith its own product

Customers Retailer shops who

orders productsfrom the company

Retailer shops There are many

retailer shops inone local area

Orders Sent by the retailershop containingitems and theirquantity they hasdemand for

Customer orders forproducts

Many orders comefrom customer orcustomers

Payments Payments aremade by customersfor the goodsordered

Customerpayments partial orfull

Payments areeither partial or full


23/50

16


5.2.2 Identifying relationship types

As the two types of entities have been identified, there are two possible views of the

system database, namely, the warehouse view and sales view. Therefore, the

relationship between the attributes will be different in each view.

i. Company has sales and warehouse staff

ii. Sales manager manages sales staff

iii. Sales staff get Orders

iv. Orders has Orders number and Ordering cutomerNo, Customer name

v. Order details contains products

vi. Products has product ID, product name, product price

vii. Product belongs to categories

viii. Categories has category id category id

ix. Each Category product has suppliers

x. Suppliers has supplier ID, supplier name

xi. Products are stored in warehouse

xii. Warehouse is managed by warehouse staff

There are two possible conceptual views, which are shown in the UML diagram below

in figures 3 and 4

Figure 2. Sales view


24/50

17


Figure 3. Warehouse view

Documentation of relationship types using partial ER diagram only with entities and

their respective primary key.

Figure 4. Staff usersview.

Identification and association of attributes to Entities

In this step of design process, the entities that were discovered in earlier step are

assigned with attributes. The possible attributes from the analysis of companys

document and users interviews is documented in this step. The bold names are entities

and following that are the attributes. These attributes are only the proto types; on

further processes these will be more concrete and well defined.


25/50

18


Staff

Staff ID, FirstName, LastName, DateOfBirth, Address, role ID, phone No, username,

password

Role

Role ID, roleName, Description

Customer

Customer ID, FirstName, LastName, Address,phone, Email, BusinessRegNo,

Order

OrderID, BillNo, Staff ID, CustomerID, OrderDate, DispatchedDate, PaymentID,

ErrorMsg, Deleted, Paid,

OrderDetails

OrderId, BillNo, ProductId, Price, OrdQuantity, DelQuantity, Discount, Total, Size,

OrdDate, DispatchDate, OrderDetailID, BillDate

Payment

paymentID, PaymentType, CreditAmount, DebitAmount, Balance, BalanceDate,

Product

ProductID, ProductName, ProductDescription, SupplierID, CategoryID,

QuantityPerUnit, UnitPrice, UnitWeight, Size, Discount, UnitsInStock, UnitsonOrder,

ReorderLevel, ProductAvailable, CurrentOrder, Note

Category

CategoryID, CategoryName, Description,

Supplier

SupplierID, CompanyName, ContactFname, ContactLname, ContactTitle, Address,

Phone, Fax, Email, PaymentMethods, DiscountType

Documentation of Attributes and Entities

The following table 2 is the documentation of above discussed entities and their

respective attributes


26/50

19


Table 2. Documentation of attributes and entities(Connolly, 2005, p.450)

Entity Attributes Description Data Type & Length Null

Staff Staff IDName

FNameLName

DOBAddressSEXPhoneNoroleIDusernamepassword

Uniquely identifies a member staff

First Name of StaffLast Name of StaffDate of Birth of StaffHome Address or contact addressGender Male M or Femal FContact Phone NumberJob Title ID, Foreign KeyUnique to user, for login functionUnique, encrypted,

5 varchar

15 varchar15 varcharDate30 varchar1 char {M/F}10 Digit number5 var char, F-key15 var char8 to 15 var char

No

NoNoNoNoNoNoN0

Role roleIDroleNameDescr

Uniquely identifies a staff roleJob title of the staffDescription of role

5 var char15 var char30 var char

NoNoNo

CustomerCIDBRegNoNameFnameLname

AddressPhoneEmailStaff ID

Uniquely identifies customerCustomer PAN resgister Number

Firsta name of customerLast name of customerAddress of customer retail shopContact phone of customerEmail address of customerStaff who registers customer

5 var char10 digit

15 var char15 var char30 var char10 digit15 var cha5 varchar

NoNo

NoNoNoNoYesNo

Order OrderIDStaff IDCIDODateErroMsg

Uniquely identifies each orderIdentifies the sales staffCustomer id who ordersIncoming order dateError message if happens

10 digit number5 var char5 var charDate30 var char

NoNoNoNoYes

ODetail OrderIDBillNoODetailIDProductIDUSPSizeOrdQuant

DelQuantDiscountTotalDelDateOrdDate

Identifies order that came inIdentifies the bill generatedIdentifies id for order detailsIdentifies each productUnit price of each product unitSize of productQuantity of product ordered

Quantity of product deliveredDiscounts involvedTotal amount of billOrder dispatch dateDate when order came

10 digit number10 digit number5 var char10 var char5 digitS, M, L6 digit

6 digit number3 digit number7 digit numberDateDate

NoNoNoNoNoNoNo

YesNoNoNo

Payment BillNoPay TypeCrAmountCrDateDrAmountDrDateBalance

Identifies payment bill numberPayment type, cash or bankCredited amountCredit dateDebited amountDebit dateTotal balance (derived)

10 digit number10 var char7 digit numberDate7 digit numberDate7 digit number

NoNoYesYesYesYesNo


27/50

20


Product ProductIDPNamePDescrCatIDsupplierID

QPerUnitUpriceUSPUweightUsizeDiscountUInStockUInOrderReOrLevelNote

Uniquely identifies productProduct NameProduct DescriptionIdentifies product categoryIdentifies product supplier

Product quantity per unitProduct unit priceUnit Selling priceProduct unit weightProduct unit size, S, M, LDiscount offered by supplierProduct units in stockunits in order from supplierProduct margin for re-orderingSome note for product

10 var char15 var char50 var char5 var char5 var char

4 digit number4 digit number4 digit number4 digit number1 var char (S,M,L)3 digit numberNumberNumberNumber50 var char

NoNoNoNoNo

NoNoNoNoNoYesNoNoNoYes

Category CatIDCatNameDesc

identifies product categoryname of the categorycategory description

5 var char15 var char50 var char

NoNoNo

Supplier SupplierIDComNameConfNameConlNameConTitleAddressPhoneFaxEmailPayMethDisType

Uniquely identifies each supplierSupplier company nameContact person first nameContact person last nameCont person job titleAddress of supplierSuppliers phone numberFax numberEmail addressPayment methodsDiscount type

5 var char15 var char15 var char15 var char10 var char30 var char10 digit numberNumber30 varcharVar char3 digit number

NoNoNoNoNoNoNoYesYesNoYes

Some derived attributes and their derivation

In Payment, Balance is to be derived from

Payment . Balance = ODetail . TotalPayment . DrAmount

Payment. Cr.Amount= ODetail. TotalPayment. DrAmount

5.2.3 Determining attribute domains

A domain is a poll of values from which one or more attributes receive their values.

In the database, all the ID attributes are 5 variable characters which shall have their

values in the form of: 2 characters (first and last name initials) + 3 digits (000-999).


28/50

21


Figure 5. Domain pool for ID attributes possible value

5.2.4 Determining candidate, primary, and alternate keys

Those attributes which can uniquely identify entire entity are the candidate keys. One

of these attributes shall be the primary key and the other keys are alternate keys.

Table 3. Associating entities with candidate keys, primary key and alternate keys

Entity Candidate keys Primary key Alternate keys

Staff staffID, DOB name, phone

staffID DOB

Role roleID roleIDCustomer CID, BRegNo,phone

CID BRegNo

Order OrderID OrderID

ODetail ODetailID,OrderID+ProductID

ODetailID OrderID+ProductID

Payment billNo billNo

Product ProductID,productName

ProductID productName

Category CatID, CatName catID CatName

Supplier supplierID,comName

supplierID comName

We using enhanced entity relationship modelling to show entity and primary keys


29/50

22


Figure 6. UML diagram with entities and primary keys

5.2.5 Redundancy check for the conceptual model

The system will be inefficient if there are redundant data. The process of redundancy

check helps in eliminating any duplicate data if there exists any. The conceptual data

model is subjected to the redundancy check. The process carried involves re-

examining all the relationships between the entities. The following were the processes

carried for redundancy check:-

a. Re-examining one-to-one relationships

b. Removing redundant relationships

c. Considering time dimensions

After the process, the conceptual model was found free of any redundancy.


30/50

23


5.2.6 Conceptual model validation with users transaction

At this stage, the conceptual data model that represents the enterprises data

requirements is achieved. The purpose of validation is to ensure the data model

supports the required transactions of the enterprise.

An attempt to carry out enterprise transactions manually using the data model is

performed. The aim is to observe if the transaction succeeds or fails. If the transaction

is successful, there is no problem with the data model, otherwise the conceptual model

needs to be reviewed and redesigned to meet the enterprise transaction requirements.

The following are the approaches carried out to ensure that the conceptual data model

meets the transaction requirements:-

a. Describing transactions

b. Using transaction pathways

The UML diagram 8 is used to describe the conceptual model validation process with

users transaction.

Figure 7. Using pathways to validate conceptual model meets user transactionrequirements.


31/50

24


The UML diagram in Figure 8 was used to validate the transaction process. The

description of each transaction process is as follows:

a. Enter/update/delete staff detail and roles.

b. Enter/update/delete customer details.

c. List staff/customer details and who register which customer.

d. List which customer ordered what products, current orders.

e. Enter/update/delete order.

f. List products in order by order number of each customer.

g. Enter/update/delete order details

h. List credit, debit, balance amounts for each order/bill.

i. Enter/update debit/credit amount for each order/bill.

j. List products in each order.

k. Update/delete products from order (if out of stock).

l. List/update/delete/ products from category or category.

m. List/update/delete supplier details.

5.2.7 Reviewing the conceptual data model with users

The conceptual data model has been verified with enterprise data requirements and

transaction requirements. The data model is reviewed along with the user and user is

happy with the positive signs of development process of a well designed database,

ready to implement. The next step of the design process is to produce a logical

database design from this data model.


32/50

25


6 Logical Database Design

In this phase of project, the conceptual data model produced in last step is translatedinto logical data model. The process of translation was conducted following certain

process which is described in this chapter

6.1 Definition

Logical database design: The process of constructing a model of the data used in an

enterprise based on a specific data model, but independent of a particular DBMS and

other physical considerations. (Connolly, 2005, p.439)

The objective of logical database design is to convert the conceptual data model into a

logical data model. The logical data model is then validated to check structural

correctness and support for the required enterprise transactions. A single logical data

model that is correct, unambiguous and comprehensive representation of enterprise

data requirements is achieved on the completion of logical database design

methodology.

6.2 Logical database design methodology

The purpose of using a design methodology is to give structure to the procedures,

techniques, tools and documentation to support and facilitate the process of designing.

The following are the steps in methodology that are followed during the logical

database design process for the company.

6.2.1 Deriving relations for the logical data model

The relationship between entities and attributes are derived during this step. The

compositions of each relation are described using Database Definition Language

(DBDL). The name of each relation is specified using DBDL followed by list of

attributes enclosed in brackets. The primary key (pk), alternate key (ak), secondary key

(sk) and foreign keys (fk) of the relations are identified.

The relationship between the entities is represented using the primary key/ foreign key

mechanism. The parent and child entity are identified to place the foreign key

attribute(s). The parent entity posts its primary key as foreign key into the relation that

represents child entity. All the primary keys in the ER diagram are represented by


33/50

26


being underlined. The relations and attributes of all entity are shown in the diagram 9

below:

Figure 8. UML data model showing all attributes at this stage of developmentphase.


34/50

27


Relations in Database Definition Language (DBDL)

a. Staff has role

Staff (Staff ID, firstname, lastname, DOB, Sex, address, phone, username,

password, Role ID)

Primary Key Staff ID

Alternate Key username

Foreign Key Role ID refrences Role (Role ID)

Role (Role ID, rolename, description)

Primary Key Role ID

b. Staff registers customers

Customer (CID, BRegNo, fname, lname, address, phone, email, staffID)

Primay Key CID

Alternate Key BRegNo

Foreign Key staffID references Staff (staffID)

c. Customer makes order

Order (OderID, OrderDate, ErroMsg, staffID, CID)

Primary Key OrderID

Foreign Key staffID references Staff (Staff ID)

Foreign key CID references Customer (CID)

d. Order has Order details

ODetail (OdetailID, unitprice, size, Quantity, discount, total, DDate, billDate,

BillNo, OrderID, ProductID)

Primary Key OdetailID

Foreign Key BillNo references Payment (BillNo)

Foreign Key OrderID references Order (OrderID)

Foreign Key ProductID references Product (prodcutID)

Payment (BillNo, payType, CrAmount, CrDate, DrAmount, DrDate, Balance)

Primary Key BillNo

Product (ProdcutID, PName PDescr QperUnit, Uprice, USP, Uweight, Usize,

Discount, UInstock, UInOrder, ReorderLevel, Note, SupplierID, CatID)

Primary Key ProductID

Foreign Key SupplierID references Supplier (SupplierID)

Foreign Key CatID references Category (CatID)


35/50

28


e. Product belongs to category






Category (CatID, catName, Description)

Primary Key catID

f. Supplier supplies product

Supplier (SupplierID, comName, confName, conLname, conTitle, Address,

Phone, fax, Email, PayMeth, DiscType)

Primary Key supplierID






The following UML diagram in Figure 10 represents the relationship using the primary

key and foreign key attributes mechanism. The primary key is underlined and foreign

key is indicated by (fk) at the end of attributes in the table.


36/50

29


Figure 9. UML diagram representing pk fk mechanism for relationships

6.2.2 Validating relations using normalization

The objective of using the normalization technique is to minimize the number of

attributes in entities supporting data requirements of enterprise. This process helps in

reducing of data redundancy and solving update anomalies. Some of the redundancies

are, nevertheless, essential to form joints in relationship between entities.

The process of normalization of DATA follows different normalization steps, namely

First Normal Form (1NF), Second Normal Form (2NF), Third Normal Form (3NF),

Fourth Normal Form (4NF), and Fifth Normal Form (5NF). However, for our purpose we

are following only up to 3NF as recommended in general. The relations that we are

deriving from the conceptual data model, however, might already be in 3NF form. The

conceptual model is yet validated using the normalization technique. The relations that

are not in 3NF are identified and corrected.


37/50

30


6.2.3 Validating relations against user transactions

The purpose of this step is to ensure that the logical data model supports the required

transactions. Although the transaction requirements were validated already during the

conceptual data model design process, the logical data model is also validated against

the users transactions requirements.

The primary key/foreign key links from the ER diagram, relations, and data dictionary

are used for validation. The process was performed manually as before. All the

required transactions were performed successfully validating the logical data model to

be correct.

6.2.4 Checking integrity constraints

The constraints in a database are defined to protect the database from being

incomplete, inaccurate, or inconsistent are known as integrity constraints. Integrity

constraints are mostly controlled by DBMS. The project work is concerned only with

high-level design, defining required integrity constraints irrespective of how this might

be achieved. It is said (Connolly, 2004) that a logical data model that defines and

includes all required integrity constraints is a true representation of enterprise data

requirements. In this process, the following types of integrity constraints areconsidered:-

Required data

The attributes that must not be null shall be assigned a value. Some defaults

values are defined to the attributes that requires.

Attribute domain constraints

The domain pool is the group of attribute values from which the value may be

acquired. For gender/sex attribute, the domain pool has only two values M or F

Multiplicity

Entity integrity

The primary key that uniquely represents entity shall not be null or duplicated.

Referential integrity

Attributes which are involved in relationship shall not be null, in case of deletion of

attributes value in parent entity, default values are defined.

General constraints


38/50

31


The attributes: total, balance, CrAmount, DrAmount from ODetail and payment shall

always have default value as 0.00. The attribute ReorderLevel is defined to have a

certain number as default value like 100 Units.

The table 4 shows referential integrity constraints for the relation in the staff user

view of enterprise database:

Table 4. Referential integrity constraints

Staff (Staff ID, firstname, lastname, DOB, Sex, address, phone, username,password, Role ID)Primary Key Staff IDAlternate Key username

Foreign Key Role ID references Role (Role IDON UPDATE CASCADE ON DELETE SET DEFAULT (SALESMEN ROLE)Role (Role ID, rolename, description)Primary Key Role IDON UPDATE CASCADE ON DELETE NO ACTIONCustomer (CID, BRegNo, fname, lname, address, phone, email, staffID)Primary Key CID -> ON UPDATE CASCADE ON DELETE NO ACTIONAlternate Key BRegNoForeign Key staffID references Staff (staffID)ON UPDATE CASCADE ON DELETE SET TO DEFAULT (SALES MANAGER)Order (OderID, OrderDate, ErroMsg, staffID, CID)Primary Key OrderID -> ON UPDATE CASCADE ON DELETE NO

ACTION /CHECKForeign Key staffID references Staff (Staff ID) ON UPDATE CASCADEON DELETE SET TO DEFAULT (SALES MANAGER ID)Foreign key CID references Customer (CID) ON UPDAGE CASCADEON DELETE NO ACTIONODetail (OdetailID, unitprice, size, Quantity, discount, total, DDate, billDate,BillNo, OrderID, ProductID)Primary Key OdetailID ON UPDATE CASCADE ON DELETE NOACTIONForeign Key BillNo references Payment (BillNo) ON UPDATE/DELETENO ACTIONForeign Key OrderID references Order (OrderID) ON UPDATE/DELETE

NO ACTIONForeign Key ProductID references Product (prodcutID) ON UPDATECASCADE ON DELETE NO ACTIONPayment (BillNo, payType, CrAmount, CrDate, DrAmount, DrDate, Balance)Primary Key BillNo ON UPDATE/DELETE NO ACTION/CHECK

Product (ProdcutID, PName PDescr QperUnit, Uprice, USP, Uweight, Usize,Discount, UInstock, UInOrder, ReorderLevel, Note, SupplierID, CatID)Primary Key ProductID ON UPDATE/DELETE CASCADEForeign Key SupplierID references Supplier (SupplierID) ONUPDATE/DELETE CASCADEForeign Key CatID references Category (CatID) ON UPDATE/DELETECASCADE


39/50

32


Category (CatID, catName, Description)Primary Key catID ON UPDATE/DELETE CASCADE

Supplier (SupplierID, comName, confName, conLname, conTitle, Address,Phone, fax, Email, PayMeth, DiscType)Primary Key supplierID ON UPDATE/DELETE CASCADE

6.2.5 Reviewing logical data model with user

The logical data model achieved at this stage is reviewed with users to ensure that the

model is the true representation of the enterprise data requirements. The relationship

between the logical data model and the data flow diagram is reviewed. The data flow

diagram shows the real time data that flows in enterprise that is being saved in

database and logical data model shows the structure of the stored data of the

enterprise.

Figure 10. UsersReal world data flow diagram (DFD)


40/50

33


The relationship between the logical data model and the data flow was used to check

consistency and completeness of each other. It was ensured that the data stored

represents the whole number of entity types and the attributes on the data flow belong

to the entity type.

Figure 11. Modified using Chens Entity-Relation (ER) method for globaldata model (Elmasri & Navathe, 2011, ch. 3)


41/50

34


7 Designing Security Mechanism

The database stores enterprise resources and data that should be properly secured

using proper controls. The objective of this step is to design security mechanism that

meets the security requirements documented during the requirements collection and

analysis stage of database system development lifecycle. The DBMSs provides

different kind of security controls, so it also depends on the selection of RDBMS,

however in this step we design general security mechanism that should be followed

during the physical implementation of database design.

There are two types of database security generally provided by DMBSs:

system security;

data security;

The use and access of database at the system level protected by usernames and

password is defined by system security mechanism.

The use and access of database objects such as relations and views and users

privileges to carry out operations on these objects is defined by data security

mechanism.

7.1 Database secutiy threats

The effective implementation of security requires identification of security breach and

threats. The following are the identified threats:

- theft and fraud;

- loss of confidentiality;

- loss of privacy;

- loss of availability;

The documentation of possible known threats is documented in the table below. The 5

table consist of all the known threats.


42/50

35


Table 5. Threat documentation (Connolly, 2005, p.544)

Threat Theft and

Fraud

Loss of

confidenti

ality

Loss of

privacy

Loss of

integrity

Loss of

availabilit

y

Access imposing other person

Unauthorized amendment or copying of

data

Program alteration (trap door)

Inadequate policies and procedures that

allow a mix of confidential and normaloutput

Wire trapping

Illegal entry by hacker

Blackmail

Data, program, equipment theft

Inadequate staff training

Viewing and disclosing unauthorized

data

Physical change to equipment

Connection problems

Virus attack

Data corruption due to power loss or

surge

7.2 Computer-based controls

It is important to know the system environment to find the possible threats and danger

to the database. The following figure shows the current working system environment of

the enterprise along with the possible future environment:


43/50


44/50

37


7.2.1 Authentication and authorization

The mechanism to check whether a user is the person who he or she claims to be is

known as user authentication. The system admin is responsible for allowing staff to

have access to the system. The staff is identified with a unique identifier, and with each

identifier is a password chosen by the user. The identifier will authenticate the staff to

user the computer system. The DBMS login identifier and workstation identifier must be

same, but this also depends on the DBMS company decides to use.

The process of granting certain rights and privilege to the user that enables them to

have legitimate access to a system or systems object is authorization. The

authorization controls are built into the software and it governs what users can access

and how they can access. The process of authorization involves authentication of user

and their privileges on database table, view, procedure, trigger or any other object that

is created within the system. The following table 6 shows the authentication and

authorization log file system

Table 6. Login rule

User account Login failure

counter

Password

expire

Max. login

failure

Max. login

failure action

CEO/administrator Count

unsuccessful

login attempts

Password

expired every

60 days

3 attempts lock account

Sales manager

Warehouse

manager

Warehouse staff

Sales staff

Count

unsuccessful

login attempts

Password

expire every

90 days

5 attempts lock account

The locked accounts shall only be unlocked by the CEO/administrator or the Database

Administrator (DBA).


45/50

38


7.2.2 Access controls

The access controls for a database system is based on granting and revoking user

privileges. A privilege allows user to create, read, modify, and write some database

objects such as relation, view, table or index or to run certain DBMS utilities.

The user should get only the privileges they need to perform their task. Granting

excessive user privileges are always a security issues. The privilege that is granted to

the user depends on their roles and job description. There are four types of user in the

company and their privilege is different from each other.

The selected DBMS keeps track of privileges that are granted to users and can be

revoked when needed ensuring users still can access database objects he or she

needs to complete their task. The two types of access controls available in most of the

commercial DMBS are:

Discretionary Access Control (DAC)

Mandatory Access Control (MAC)

7.2.3 Views

The view mechanism provides user to access objects and utilities from the DBMS

hiding backbone structure of the database. A view is a virtual dynamic result created

from one or more relational operations operating on the base relations to produce

another relation.

The views that shall be created will be accessed and viewed only through the interface

program that will be designed. The user interface designed shall not have any inputs

for Structured Query Language (SQL). The interface should define every view in the

interface through menus and should be restricted according to the user privileges.

7.2.4 Encryption

The encoding of data by a special algorithm that makes the data unreadable by any

program without a special decryption key is known as encryption. Though the data at

the moment will be transmitted over the secure local network, but in future, it might be

essential to transmit data over insecure network. To transmit data securely over

insecure network, the use of cryptosystem is important. The cryptosystem should

include:


46/50

39


An encryption key to encrypt the data;

An encryption algorithm, that uses encryption key to transform plaintext to cipher

text;

A decryption key to decrypt the cipher text;

A decryption algorithm, that uses decryption key to decrypt cipher text to plaintext

The data that shall be stored into the database system will be encrypted using Data

Encryption Standard (DES) algorithm. The encryption and decryption key provided by

DES is always kept secret.

7.2.5 Whitelist and blacklist

The objective of whitelist and blacklist is to register those that are being provided

certain privilege, service, mobility, access or recognition. Those which are on the list

will be accepted or denied according on which list they belong.

Those which are in the whitelist shall be accepted and those on the blacklist will be

denied. All the possible sql injection parameters shall be listed in blacklist. The table 7

below shows blacklist and whitelist created during security design phase:

Table 7. Blacklist and whitelist prototype table

Blacklist Whitelist

Sql injection characters like:-

), ;, and EXEC

Special characters except in password

field and email address

Combination like, CategoryID=1 or1=1

Escape characters in the form filed

input only Aa-Zz and 0-9 in put field or

combination

Local network: MAC filter (only companys

computer)

applications on companies computer

shall be listed

The process of defining black list and whitelist also depends on the DBMS system

implemented. Some of the DMBS might already do have inbuilt black and white list.


47/50

40


8 Overview of the project work

The aim of this project work was to produce a clear and good conceptual and logical

data model. The objective of the project was to produce a database design based on

the companys working environment. The data requirements of company were studied

using the documents produced in their day-to-day business life.

8.1 Problems faced

During the project work, the most hectic problems were to study piles of documents

stored in paper format. Documents were not stored in any kind of orders, neither

chronological nor alphabetical. Most of the time was consumed in understanding the

business and types and amounts of data generated every day.

The other problem faced was conducting staff interviews. The questions to be asked

needed to be structured according to the job description. Every question answered by

different staff member was different according to their own problems and issues and

their way of solving them. Summarizing those answers identifying entities and relations

was not easy, either.

8.2 Preparation and collecting specifications

During the project work, lots of studies were needed to complete the task, to structure

the designing methods, from those studies and my earlier studies in the subject matter,

and now applying them in real work gave me more knowledge in database designing.

Getting knowledge is no project outcome, but is accepted (same content)

The challenges I faced during the project work have increased my confidence on

tackling challenges that I may face during my work life in the same field. The time

management was one of the greatest challenges during the project work. The time that

I had for the project was very. Managing the time for studies, planning the project work,

and starting to do the work was very challenging. Although I believe I have finished my

project work on time, I still have the feeling that I could have done it better and sooner if

I would have had all the time that I thought I would need.

The process of communication with the company for which I was doing my project work

has helped me develop good communication skills. Studying the business documents,

interviewing the company staff, and observing the company day-to-day operations has

made my business understanding very good. It was a privilege to be able to see inside


48/50

41


of a distribution company and how all its mechanism works. It was a good experience

in the field of database designing.


49/50

42


9 Summary

The logical data model that has been produced during the project is fully capable of

defining the data requirements of the enterprise. During the project work, all the data

requirements, functional requirements, and transaction requirements were closely

observed and described in this document. The document produced now is ready for the

physical implementation of the SIM database system.

During the project work, the data dictionary, ER diagrams, conceptual data model, high

level transaction details, data flow diagrams and logical data model were produced,

which are starting point for the physical database design and implementation.

The document produced from enterprise requirements collection and analysis is very

useful and important for the application development.

After the enterprise chooses platforms and required hardware components and

software, the project goes to the next level as illustrated in Figure 1 where the

application designer will design the application and physical database and will be

implemented as a Sales and Inventory Management (SIM) System.


50/50

43

REFERENCES

Connolly, T. (2004). Database Systems: A Practical Approach to Design,

Implementation and Management (4th Edition). 4 Editions. Addison Wesley

Weldon, J.(1981), Database Administration, New York and London: Plenum Press

Norman, M. (2003). Database Design Manual: using MySQL for Windows (Springer

Professional Computing). 4th Edition. London: Springer-Verlag.

Elmasri, R. and Navathe, S. (2011), Fundamentals of Database System. 6 thEdition,

USA: Pearson Education Limited

Database Analysis. 2013. Database Analysis. [ONLINE] Available

at:http://db.grussell.org/section004.html. [Accessed 17 October 2013].

Course: Systems Engineering. 2013. Course: Systems Engineering. [ONLINE]

Available at: http://ocw.metu.edu.tr/course/view.php?id=22.. [Accessed 7 October

2013].

Database System Concepts. 2013. Database System Concepts. [ONLINE] Available

at: http://cnx.org/content/m28150/latest/.. [Accessed 17 November 2013]

Thesis SIMS

Documents

Transcript of Thesis SIMS