GROUP6 MEMBER

1,Samrawit Lamma
2,Zerihun Urael
3,Wube Feleke
4,Elias Demeke
5,Daniel Gizachew
2
Contents
DATA HANDLING.........................................................................................................................................5
SELF EXPLANATORY OF OUR PROJECT.........................................................................................................6
SUPERMARKET........................................................................................................................................6
MANAGEMENT........................................................................................................................................6
SYSTEM....................................................................................................................................................6
SUPERMARKET MANAGEMENT SYSTEM.................................................................................................6
4. DATABASE................................................................................................................................................6
WE NEED A DATABASE:...............................................................................................................................7
7. BUSINESS RULE......................................................................................................................................10
Purchase rule for item...........................................................................................................................10
Sale rule of item....................................................................................................................................11
The report and control rule...................................................................................................................11
CONCEPTUAL DATABASE DESIGN..............................................................................................................12
ENTITIES WITHIN THE ORGANIZATION..................................................................................................12
LIST OF ENTITY IN OUR PROJECT...........................................................................................................12
STRONG ENTITY OF OR PROJECT:..........................................................................................................13
ATTRIBUTE.............................................................................................................................................13
DOMAIN VALUES...................................................................................................................................13
ATTRIBUTE TYPES..................................................................................................................................13
CUSTOMER............................................................................................................................................14
EMPLOYEE.............................................................................................................................................14
SALES.....................................................................................................................................................14
PURCHASE.............................................................................................................................................15
PAYMENT...............................................................................................................................................15
ORDER...................................................................................................................................................15
RECEIPT..................................................................................................................................................16
ITEM......................................................................................................................................................16
RELATIONSHIP.......................................................................................................................................17
DEGREE OF RELATIONSHIP........................................................................................................................17

3
CARDINALITY OF RELATIONSHIP................................................................................................................17
A 1:1 or ONE TO ONE RELATIONSHIP.....................................................................................................17
A 1:M or ONE TO MANY RELATIONSHIP................................................................................................17
M:M or MANY TO MANY RELATIONSHIP...............................................................................................17
KEYS...........................................................................................................................................................21
PRIMARY KEY.........................................................................................................................................21
CANDIDATE KEYS...................................................................................................................................21
FOREIGN KEYS........................................................................................................................................21
DATA INTEGRITY RULES.............................................................................................................................22
ENTITY INTEGRITY RULE.........................................................................................................................22
ENTITY INTEGRITY RULES INTERMS OF OUR PROJECT...............................................................................22
SOME ER and EER DIAGRAM SYMBOLS.....................................................................................................23
STRONG ENTITY................................................................................................................................23
WEAK ENTITY.........................................................................................................................................23
MULTIVALUED ATTRIBUTE.....................................................................................................................23
SINGLE VALUED ATTRIBUTE...................................................................................................................23
DERIVED ATTRIBUTES............................................................................................................................24
COMPOSITE ATTRIBUTES.......................................................................................................................24

4
5
ACKNOWLEDGEMENT

First we would like to express our heartiest thanks to Almighty “GOD” In the
name of GOD, the Most Gracious and the Most Merciful God, all praises to GOD
for the strengths and His blessing in completing of our project. Special
appreciation and heartiest gratitude goes to our supervisor, MrWorku M
throughout this project. His invaluable help of constructive comments and
suggestions throughout the project works have contributed to the success of this
project. We would also to express our appreciation to our friends, Special thanks,
tribute and appreciation to all those their names do not appear here who have
contributed to the successful completion of this project.

We would like to thank all those who assisted, encouraged and supported us during
this project, be assured that the GOD will bless you all for the contributions you
made.

6
DATA HANDLING
To collect information we used Interview from supermarkets using manual system
and customers.

After when we finish our interview we have got the following result.

 The customer’s data and registration are kept manually

 It took long time customers to get their order.
 Salesperson spend time to know whether items available or not and some
time the price of the item.
 It is difficult admin to control the transactions and Summarize data and
writing reports take lot of time.
 It takes longer to find old records because adminis just retrievingthem from
a database.
 The main method used for this research was interview. Data were collected
from different supermarkets which some half of them use manual system
while others use computerized system and customers of both type of
supermarkets.
 Interviewing the people who worked and have experience how to manage
Supermarket (Ordering, Purchasing, Selling, Payment, & Receipt).To know
the quality and the intensity of the information we need.

7
SELF EXPLANATORY OF OUR PROJECT

SUPERMARKET
A large shop which sells most types of food, household and other goods
needed in the home, in which people take from shelves the things they want
to buy and pay for them as they leave. It is usually situated near a residential
area in order to be convenient to consumers.
MANAGEMENT
Management is a universal phenomenon. It is a very popular and widely
used term. All organizations - business, political, cultural or social are
involved in management because it is the management which helps and
directs the various efforts towards a definite purpose.
SYSTEM
A set of detailed methods, procedures and routines created to carry out a
specific activity, perform a duty, or solve a problem. All systems have
inputs, outputs and feedback mechanisms.
SUPERMARKET MANAGEMENT SYSTEM
This System is aimed to provide information to the customer about
theproduct and services of the supermarket of the country. And it provides
some details about the product/service such as the price, available stock;
discount and etc.

DATABASE
Adatabaseis a collection of related data. Data we mean known facts that can be
recorded and that have implicit meaning. For example, consider the names,

8
telephone numbers and addresses of the people you know.You may have recorded
this data in an indexed address book or you may have stored it on a hard drive,
using a personal computer and software such as Microsoft Access or Excel. This
collection of related data with an implicit meaning is a database.

 A database represents some aspect of the real world, sometimes called the
mini world or the universe of discourse (UoD). Changes to the mini world
are reflected in the database.
 A database is a logically coherent collection of data with some inherent
meaning. A random assortment of data cannot correctly be referred to as a
database.
 A database is designed, built and populated with data for a specific purpose.
It has an intended group of users and some preconceived applications in
which these users are interested.

WE NEED A DATABASE:
 Database is needed to operate large amount of information by
storing, retrieving and managing.

9
 DATABASE AND DATA STRUCTURE
DATABASE
 Database is a well-organized
collection of data that can be
accessed and manipulated.
 Database is a collection of
tables (and possibly stored
procedures functions views
etc.)
 It is the collection of database
objects stored normally on hard
disk.
 Since a database refers to the
permanent storage of data it
typically stored on the hard
drive of computer.
 Is non-volatile memory.
Database is a middleware to
help us store the data into file
system.
10
DATA STRUCTURE
 Data structure is a specialized
format for organizing and
storing data. We need a data
structure when need to answer a
specific say business question
and for that we don’t need all
the data from our database.
Therefore, data structures
consist of algorithms and
patterns that will gather and
organize data so that we can
answer the question quickly.
 It stored normally on RAM.
 Data structure is the memory.
 Is volatile memory.
 Data structure is a logical
representation of how you store
the data into file system.
RELATIONAL DATABASE AND SEARCH ENGINE

Relational database Search engine

11
BUSINESS RULE
 Business rule is that defines or constraints some aspect of business that
identifies the working rule of business/organization.
 Business rule are intended to assert business structure or to control or
influence the behavior of the business.
 Business rules describe the operations, definition and constraints that apply
to an organization. That can apply to people processes corporative
behavior and computing system in an organization and put in place to help
the organization achieve its goals.

BUSINESS RULE OF THE ORGANIZATION

Purchase rule for item
This activity is base this organization and it has different process that
perform by admin of the supermarket.
 First the admin check all item that need to supermarket.
 He /she also check their budget if it fit or not fit to purchase item.
 Next he/she,identify the quantity of item based on their budget.
 Next to this the fill the following form when they purchase the item
Purchase code
Purchased item category
Item name of the item
Quantity of the item
Price of the item
Supplier name and address
Purchase date
 Then after this process is complete they receive the item from supplier and store
the item in the shelf and finally they prepare the item to sale.

Sale rule of item

12
 This activity also the essential activity to this organization and also It
has different step.
First when the customer comes to their supermarket they accept their
costumer and ask the service he need from their supermarket.
 Then they ask theircustomer the item name, then the sales person check the
item in the supermarket when the item is available they ask the quantity of the
item he/she need and they tell the price of the item to costumer, then if the
costumer agree with the price the they receive the payment and give receipt to
them and finally they give the item to costumer.
The report and control rule
 This activity is also very essential activity to this organization and they perfume
daily.
 This activity is usually done at night after the work time up.
 First the sales person and admin meet together
 Then sales person give the report that prepared on their work at that day and the
money collected at that day from sales.
 Their report contain the following
The sale items name and quantity
The stored items name and quantity at that day
The total money they collect from sales at that day
 Then the admin check the report and the money and ask the item exist and does
not exist in the supermarket.

13
 CONCEPTUAL DATABASE DESIGN
Thesteps to build conceptual data model is:-

I. We identify entities
II. Relationship types
III. Identify Attributes
IV. Determine Attribute Domains
V. Determine Candidate,primary,Alternate,and surrogate key Attributes
VI. Consider use of enhanced modeling concepts
VII. Check model for redundancy
VIII. Validate conceptual model against user transactions
IX. Review conceptual model with user

ENTITIES WITHIN THE ORGANIZATION

ENTITY:-Real-world object distinguishable from other objects. An entity is described (in DB)
using a set of attributes.

Entities represent objects or things of interest:

 Physical things like students, lecturers, employees, products

 More abstract things(Conceptual existence ) like modules, courses, projects

LIST OF ENTITY IN OUR PROJECT

 Customer
 Employee
 Payment
 Order
 Receipt
 Item
 Sales
 Purchase

ENTITY SETS/TYPES: A collection of similar entities.

Entity sets broadly classified into three:

 Strong entity
 Weak entity and
14
  Associative entity
STRONG ENTITY OF OR PROJECT:
Customer
Employee
Item
Sales
Purchase
Payment
Order
Receipt

ATTRIBUTE
 Are Properties used to describe each entity or real world object.
 Attributes are pieces of information about entities.
 An attribute is simply one non-null cell in the spreadsheet, or the
conjunction of a column and row. It stores only one piece of data
about the object represented by the table in which the attribute
belongs. For example, the attributes in an invoice might be price,
number, date or paid/unpaid, etc.
DOMAIN VALUES
 Domain is a set of allowable values for one or more attributes.
 Domain contains all possible values that can appear under that
column.
ATTRIBUTE TYPES
 Single valued
 Multi valued
 Derived Attributes
 Composite Attributes

15
CUSTOMER
Attributes Attribute types Data types Size Domain values
Customer ID Single value Varchar Varchar(10) Any String values
Attribute
First Name Single value Varchar Varchar(30) Any String values
Attribute
Last name Single value Varchar Varchar(30) Any String values
Attribute
Gender Single value Varchar Varchar(2) Any String values
Attribute
Address Composite Varchar Varchar(30) Any String values
Attribute
Phoneno Multivalued Varchar Varchar(15) Any integer
Attribute values
Email Multivalued Varchar Varchar(15) Any String values
Attribute
Registration Date Single value Date Date Date(1-
Attribute 30),Month(1-12)
and year

EMPLOYEE
Attributes Attribute types Data types Size Domain values
EmployeeID Single value Attribute Varchar Varchar(50) Any String values
First Name Single value Attribute Varchar Varchar(30) Any String values
Last name Single value Attribute Varchar Varchar(15) Any String values
Gender Single value Attribute Varchar Varchar(2) Male or Female
Address Composite Attribute Varchar Varchar(15) Any String values
Phoneno Multivalued Attribute Varchar Varchar(15) Any integer values
Email Multivalued Attribute Varchar Varchar(15) Any integer values
Salary Single value Attribute double Double Any Double value

SALES
Attributes Attribute Data types Size Domain values
types
Sales no Single value Varchar Varchar(10 ) Any String
Attribute values
Item Name Single value Varchar Varchar(15) Any String
Attribute values
Item type Single value Varchar Varchar(30 ) Any String
Attribute values
Item Single value Int Int Any integer
Quantity Attribute values

16
 Price Single value Double Double Any double
Attribute value
Amount Single value Double Double Any double
paid Attribute value
Sales Date Single value Date Date Date(1-
Attribute 30),Month(1-
12) and year

PURCHASE
Attributes Attribute Data types Size Domain values
types
Purchase no Single value Varchar Varchar(20 ) Any String
Attribute values
Item Name Single value Varchar Varchar(15) Any String
Attribute values
Item type Single value Varchar Varchar(20 ) Any String
Attribute values
Item Quantity Single value Int Int Any integer
Attribute values
Price Single value Double Double Any Double
Attribute values
Amount paid Single value Double Double Any double
Attribute value
Purchase Date Single value Date Date Date(1-
Attribute 30),Month(1-
12) and year

PAYMENT
Attributes Attribute Data types Size Domain values
types
Pay ID Single value Varchar Varchar(10) Any String
Attribute values
Item Quantity Single value int int Any integer
Attribute values
Price Single value Double Double Any double
Attribute value
Amount paid Single value Double Double Any double
Attribute value
Payment Date Single value Date Date Date(1-
Attribute 30),Month(1-
12) and year

17
 ORDER
Attributes Attribute types Data types Size Domain values
OrderID Single value Varchar Varchar(10) Any String values
Attribute
Item Name Single value Varchar Varchar(50) Any String values
Attribute
Item Type Single value Varchar Varchar(30) Any String values
Attribute
Item Quantity Single value Int Int Any integer values
Attribute
Order Date Single value Date Date Date(1-30),Month(1-
Attribute 12) and year

RECEIPT
Attributes Attribute types Data types Size Domain values
Receipt ID Single value Varchar Varchar(10) Any String
Attribute values
Item Name Single value Varchar Varchar(30) Any String
Attribute values
Item Type Single value Varchar Varchar(30) Any String
Attribute values
Quantity Single value Int Int Any integer
Attribute values
Price Single value Double Double Any Double
Attribute Value
Amount paid Single value Double Double Any Double
Attribute Valued
Receipt date Single value Date Date Date(1-
Attribute 30),Month(1-12)
and year

ITEM
Attributes Attribute types Data types Size Domain values
Itemno Single value Varchar Varchar(10) Any String
Attribute values
Item Name Single value Varchar Varchar(30) Any String
Attribute values
Item Type Single value Varchar Varchar(30) Any String
Attribute values
Price Single value Double Double Any Double
Attribute value
Item Quantity Single value Int Int Any integer
Attribute values

18
RELATIONSHIP
 The association among entities is called a relationship.
 For example EMPLOYEE SERVES CUSTOMER.

DEGREE OF RELATIONSHIP
The number of participating entities in a relationship defines the degree of the
relationship.
 Binary = degree 2
 Ternary = degree 3
 N - nary = degree

CARDINALITY OF RELATIONSHIP
A 1:1 or ONE TO ONE RELATIONSHIP
o If T and S are entity
o From entity type S to entity type T is one in which an entity from S is
related to at most one entity from T and vice versa.
o for example Order has Item

A 1:M or ONE TO MANY RELATIONSHIP

o From entity type S to entity type T is one in which an entity
from S can be related to two or more entities from T.
o For example Each Employee Does Many Purchase

M:M or MANY TO MANY RELATIONSHIP

o From entity type S to entity type T is one in which an entity
from S can be related to two or more entities from T, and an entity
from T can be related to two or more entities from S.
o For example Customer Makes order

19
  Each customer can make order many times.
 Each Customer does payment.
 Each Payment has receipt
 There is Employee does not serves customer
 Every Order has Item
 Employee does sales
 Employee does purchase
 All purchase has payment
 Each sales has payment

Entities Relationship Participation Cardinality Degree

Customer- Makes Full-Full M-N Binary
Order

Payment- Paid by Full-Full N-1 Binary

Customer
Employee- Serves Partial-Full M-N Binary
Customer
Receipt- Has Full-Full 1-1 Binary
Payment
Employee- Offer Partial-Full M-N Binary
Item
Order-Item Has Partial-Partial 1-1 Binary
Employee- Does Partial-Partial M-N Binary
Sales
Employee- Does Partial-Full 1-M Binary
Purchase
Purchase- Has Full-Partial M-N Binary
Payment
Sales-Payment Has Full-Partial M-N Binary
Employee- Does Partial-Full M-N Binary
sales

20
21
22
Figure 1.1 Diagram of the Cardinality, Participation, and Degree of Entities
relationships

KEYS
PRIMARY KEY
1. Customer:-Customer ID
2. Employee:-Employee ID
3. Order:-OrderID
4. Receipt:- Receipt ID
5. Item:- Item no
6. Sales:- Sales no
7. Purchase:- Purchase no
8. Payment:-Payment ID
CANDIDATE KEYS
1. Customer:- Customer ID ,Phone no, andEmail
2. Employee:- Employee ID, Phone no and Email
3. Order:- OrderID, Order Date
4. Receipt:- Receipt ID
5. Item:- Item no
6. Sale:- Sales no
7. Purchase:- Purchase no
8. Payment:-Payment ID

FOREIGN KEYS
1. Customer:- Payment ID
2. Employee:- NO
3. Order:- NO
4. Receipt:- NO
5. Item:- NO

23
 6. Sale:- NO
7. Purchase:- Employee ID
8. Payment:- Receipt ID

DATA INTEGRITY RULES

 Data integrity constraints refer to the accuracy and correctness of
data in the database. Data integrity provides a mechanism to
maintain data consistency for operations like INSERT, UPDATE,
and DELETE.
ENTITY INTEGRITY RULE
 Entity integrity specifies that there should be no duplicate rows in
a table.
 The entity integrity constraints states that no primary key value can
be Null. This is because the primary key value is used to identify
individual tuple in a relation, having Null values for the primary
key implies that we cannot identify some tuples.

ENTITY INTEGRITY RULES INTERMS OF OUR PROJECT

24
SOME ER and EER DIAGRAM SYMBOLS

STRONG ENTITY
 Strong entity is entity type one whose existence does not depend on other
entity

WEAK ENTITY
 An entity type that is existence-dependent on some other entity type.
Weak entity does not have a primary key.

MULTIVALUED ATTRIBUTE
 More than one value will be associated with that attribute.
SINGLE VALUED ATTRIBUTE
 Single-value attribute means, there is only one value associated with that
attribute.

25
DERIVED ATTRIBUTES
 The value of the derived attribute can be derived from the values of other
related attributes or entities.
COMPOSITE ATTRIBUTES
 The composite attribute is one which can be further subdivided into simple
attributes.

26
27
28
29
 1. Logical Database Design/Normalization Process
1. First normal form(1NF)

In first normal form all columns must contain only atomic or single values.

In first normal form of a table there are no repeating groups (columns) with in a row.

30
 2. Second normal form(2NF)

 The table is second normal when it is first normal and there is no partial dependency with
in a table.
 Partial dependencies one form of functional dependency in which non-key attributes are
dependent on a part of primary key (composite key).

31
32
 3 Third Normalization(3NF)

 .There are two basic requirements for a database to be in third normal form
 The database must already meet the requirements of both 1NF and2NF.
 All database columns must depend on the primary key, meaning that any column's
value can be derived from the primary key only.
 So in 3nf each non-primary key attributes are independent on other non-key attributes
and depends only on the key in addition to being 2NF

33
34