0% found this document useful (0 votes)
80 views16 pages

Wolkite Bank Management System

This document contains information about a database project for the Commercial Bank of Ethiopia Wolkite branch. It includes the project title, group members, submission date, and instructor. It then discusses the meaning of business rules and provides examples of business rules for a bank. It outlines possible entities for a bank system including their attributes and relationships. It also includes an entity relationship diagram and discusses mapping the ER diagram to tables and normalization forms.

Uploaded by

nebyu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
80 views16 pages

Wolkite Bank Management System

This document contains information about a database project for the Commercial Bank of Ethiopia Wolkite branch. It includes the project title, group members, submission date, and instructor. It then discusses the meaning of business rules and provides examples of business rules for a bank. It outlines possible entities for a bank system including their attributes and relationships. It also includes an entity relationship diagram and discusses mapping the ER diagram to tables and normalization forms.

Uploaded by

nebyu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 16

Wolkite University

College of computing and informatics


Department of information system
Fundamental of database management system
Project title: - commercial bank of Ethiopia Wolkite branch
Management system
SECOND YEAR SECTION B GROUP 2
Group member name ID number
1. Meron Adimasu 223/09
2. Wubete Belete 327\09
3. Sewunet Adimasu 262\09
4. Yordanos Masresha 340\09
5. Yerusalem Fekade

Submitted to Mr. WERKU

Submission date:-25\05\2010 E.C

The meaning of BUSINESSRULE


 Is tell an organization what can do in detail.
 Are intended to assert business structure or to control or influence the behavior the
business.
 Describe the operations of definitions and constraint that apply to an organization.
 Business rules can apply to people processes corporate behavior and computing system in
an organization and are put in place to help the organization its goal.
 Is rule that defines or constrain some aspect of business and always resolves either true or
false.
 Business rule provide detailed guidance about how strategy can translated to action.
 Business rule may be informal or even unwritten documenting the rule clearly and
making sure that they do not conflict is a valuable activity.

BUSINESS RULE OF BANK


Banks take in money as deposits, on which they sometimes pay interest, and then lend it
to borrowers, who use it to finance investment or consumption.
Every employee wear a clear cloth to serve customer.
In case of lose the deposit book the bank should be notified by immediately.
When account is closed the deposit book must be surrendered to bank.
When deposit, withdraw and also transfer are made the deposit book must be presented to
the bank.
Special demand deposit account may be opened on personal application and
identification with initial deposit of birr 50(fifty).
Every customer cannot enter in to the bank with his or her property.
One customer can open different account books.

POSSIBLE ENTITIES OF BANK SYSTEM

There six possible entities in bank system these are below

1. Manager
2. Customer
3. Accountant
4. Branch
5. Account
6. Transaction
Six entities are strong these are: - manager, customer, accountant, branch, account and
transaction.

Entities and their attributes

1. manager
Attributes Type of attribute Data type
manager ID Primary key Int
Name Composite varchar
First name Single valued Varchar
Last name Single valued Varchar
Birth date Single valued Date
Age Derived value Int
Salary Single valued Float
Phone Multi valued Int
Address Composite Varchar
City Single valued Varchar
Region Single valued Varchar
2. Customer
Attributes Type of attribute Data type
customer ID Primary key Int
Name Composite varchar
First name Single valued Varchar
Last name Single valued Varchar
Birth date Single valued Date
Age Derived value Int
Phone Multi valued Int
Gender Single Varchar

3. Accountant
Attributes Type of attribute Data type
accountant ID Primary key Int
Name Composite
First name Single valued Varchar
Last name Single valued Varchar
Birth date Single valued Date
Age derived value Int
Salary Single valued Float
Phone Multi valued Varchar
Address Composite Varchar
City Single valued Varchar
Region Single valued Varchar

4. Branch
Attributes Type of attribute Data type
branch No Primary key Int
branch name Single valued Varchar
branch Location Single valued Varchar

5. Account
Attributes Attribute type Data type
Account No Primary key Varchar
Account type Single valued Varchar
Balance Single valued Float

6. Transaction
Attributes Attribute type Data type
transaction No Primary key Int
transaction type Single valued Varchar
Transaction date Single valued Date
Entity and there key
Entity Primary key Candidate key Foreign
Account Account No Account No Customer ID
Customer Customer ID Customer ID, phone no Accountant No, loan No
accountant accountant ID accountant ID, phone no Branch No
Branch Branch No Branch No No Foreign
Manager manager ID Manager ID, phone no Branch No
Transaction Transaction NO Transaction No Branch No, account No
,Customer Id
RELATION BETWEEN ENTITIES
 Branch and accountant is one relationship.
 Many accountant work- for One branch the cardinality between them
is N: 1.
 Customer and account is one relationship.
 One customer belongs to many accounts the cardinality between them
is 1: N.
 Customer and accountant is one relationship.
 Many Customers served by many accountant the cardinality between
them is N: m.
 Manager and branch is one relationships.
 One manager manages one branch the cardinality between them is 1:
1.
 Branch and transaction is one relationship.
 One branch has many transaction the cardinality between them is 1:
N.
 Customer and transaction is one relation.
 Many customer perform many transaction the cardinality between
them is N:M
 Account and transaction is one relation.
 Many Account perform many transaction the cardinality between
them is N:M
Figure 1: cardinality, participation and relationship

Attribute Domain value Domain


Account no 13 digit integer non-negative
integer
Balance Any Non-negative float Float
number
Account type Valid account type string
Phone no 10 digit integer non- negative
integer
Name Valid string string
Id Any integer integer
Age 2 digit integer integer
Gender Female or male string
city Valid city name in Ethiopia string
region Valid region name in Ethiopia string
Address Valid address in Ethiopia string
Branch location Valid address in Ethiopia string
Birth date Past date up to 2018 non-negative
integer
Branch name Valid bank name in Ethiopia string
Branch No Any integer Integer
Salary Any Float non-negative
float value
Transaction No Any integer Integer
Transaction Valid transaction type in bank string
type
Transaction date Past date up to 2018 non-negative
integer
BANKING SYSTEM ENTITY RELATION DIAGRAM

Figure 1 ER-Diagram
MAPING ENTITY RELATION DIAGRAM TO TABLE
BANKING SYSTEM ENHANCED ENTITY RELATION DIAGRAM
Figure 2 EER-Diagram

Logical design
Normalization form of tables
 Normalization is the process of avoiding errors that causes update, delete, and insert
anomalies from large table by divide in to small table.
1. First Normalization form (1st NF)
In first normalization form no repeating group and the value entries in the table is
single value or atomic.
 All tables After first normalization form are bellows
2. Second Normalization Form (2nd NF)
In 2nd Normalization form make all data depend on the Whole key that means non-key
attribute fully depend on the primary key that or avoid partial dependence.
The table is second normal when it is first normal and there is no partial dependency with
in a table.
Partial dependency is one form of functional dependency in which non-key attributes are
dependent on a part of primary key (composite key).
In our table is not require do second Normalization because first normalization form
our table not contain two primary key (not contain composite key).so our table already in
second normal form. .

3. Third Normalization Form (3rd NF)


It must be in first and second Normalization and each non-key attribute depend on
primary key not depend on non-primary key.
Void transitive dependency
 In our table as we seen in accountant table the non-key attribute city depend on other
non-key attribute region and in manager table the non-key attribute city depend on other
non-key attribute and the non-key attribute city depend on other non-key attribute region.
Physical Database Design

 Here is the SQL command that we wrote on Microsoft SQL server to create database and
table, to update, delete, insert, to insert constraints to the table and from the table.

You might also like