0% found this document useful (0 votes)
13 views

DB Project Guideline

This document provides guidelines for writing a project proposal and documentation for a database system project. It outlines the typical structure, which includes sections for the abstract, introduction, problem statement, objectives, and methodology. It also provides formatting instructions for aspects like fonts, spacing, numbering, and referencing tables and figures. The guidelines are intended to help students properly structure and format their database system project proposals and documentation.

Uploaded by

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

DB Project Guideline

This document provides guidelines for writing a project proposal and documentation for a database system project. It outlines the typical structure, which includes sections for the abstract, introduction, problem statement, objectives, and methodology. It also provides formatting instructions for aspects like fonts, spacing, numbering, and referencing tables and figures. The guidelines are intended to help students properly structure and format their database system project proposals and documentation.

Uploaded by

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

Madda Walabu University

College of Computing
Department of Computer Science

Fundamentals of Database System Project Writing Guideline


I. Cover page Chapter Two
II. Executive summary/Abstract 2. Business Rules and Requirements Specification
III. Acknowledgement 2.1 Business Rule
IV. Table of Content 2.2 Requirements Specifications
V. List of Figures 2.2.1 Functional Requirement
VI. List of Table 2.2.2 Non-Functional requirements
VII. Acronyms (Abbreviations)
Chapter Three
Chapter One 3. Conceptual and Logical Design
1. Background of the Organization 3.1 Cardinality of Relationship
1.1 Services of the Organization 3.2 E-R Diagram
1.2 Statement of the problem 3.3 Entity with their attributes
1.3 Objective of the project 3.4. Relationship type
1.3.1 General Objective of the project
Chapter Four
1.3.2 Specific Objective of the project
4. Relational Mapping
1.4 Scope of the project
4.1 Relational Schema
1.5 Methodology
4.2 Relational Schema with Referential Integrity
1.5.1 Sampling Techniques
1.5.2 Method of Data Collection
Chapter Five
1.6 Limitation 5. Normalization
5.1 Un-normalized Form
5.2 First Normal Form
5.3. Second Normal Form
5.3. Third Normal Form
5.4. BCNF
General Direction for Proposal and Documentation Writing

1. The topic of the proposal should be current and original.


2. You should have to submit complete proposal to the dept on time.
3. Preliminary parts should be numbered by roman numbers whereas the main body always
numbered using Arabic number in which the introductory part numbered 1.
4. The proposal and documentation must be spiral bonded with plastic cover sheet on the
front page and hard cover at the back page.
5. The projects should be neatly typed on one side and in A4 size Paper only.
6. Typing instructions should be as follow.
i. Set margins 1inch at the top, bottom and right side, and 1.25 at the left sides.
ii. One and a half spacing should be used for typing the entire text.
iii. The general text must be justified and typed in the Font style ‘Book Antiqua’ and
Font size 12.
iv. Heading shall be typed in the Font style ‘Book Antiqua’, Font size 14, bold and
aligned center
v. Subheading should be typed in the Font style ‘Book Antiqua’, Font size 12, bold
and aligned left
vi. Sub-subheading should be typed in the Font style ‘Book Antiqua’, Font size 12,
italic bold and aligned left after one inch from edge
vii. Spacing between paragraphs shall be 10pt.
viii. All Tables, figures, and equations in the document should be center aligned, and
numbered at chapter level. For example, first table in the second chapter should
be numbered as “Table 2.1”, and first figure of the second chapter should be
numbered as “Figure 2.1”. Tables, figures, and equations should be placed as
close as possible to the text where they are referred or discussed. Each figure,
table and equation that is inserted in the document should be discussed in the text,
and should be referenced.

Prep By: Tekalign T. --i--


Part I: Preliminary Parts

1 Abstract
This should be not more than one page in length. The abstract should allow the reader who is
unfamiliar with the work to gain a swift and accurate impression of what the project is about,
how it arose and what has been achieved.

2 List of Tables/Figures
If the project contains figures or tables a list of these should be provided. The list should give the
table or figure number, the title of the table or figure and the page number. If only a few tables
and figures are present, they may be treated on one page. Remember that all figures and tables
used must be referred to in the text. For example “The class diagram shown in Figure 2.1 ....”

3 Acknowledgements
It is normal to thank those who have given help and support (typically your supervisor). Keep
acknowledgements short and business-like.

4 Acronmys
List of abbreviations should be tied closely in the body of the report, and should not be included
in if there are less than five abbreviations in the document.

Prep By: Tekalign T. --ii--


Part II: Main Body
1. INTRODUCTION
Instructions: Provide identifying information for the existing and/or proposed automated
system or situation for which the project applies (e.g., the full names and acronyms for the
development project, the existing system or situation, and the proposed system or situation, as
applicable). Summarize the purpose of the project, the scope of activities that resulted in its
development, the intended audience for the project, and expected evolution of the project. Also
describe any security or privacy considerations associated with use of the project.

1.1 Background of the organization


Instructions: Briefly introduce the system context and the basic design approach or
organization, including dependencies on other systems. Identify if the database will supersede or
interface with other databases, and specifically identify them if applicable. Also identify interfaces
with other systems to the extent that they significantly impact the database design. Discuss the
background to the project, if this will help understand the functionality supported by the database
design contained in this project.
1.2 Statement of the Problem
A problem statement is usually one or two sentences to explain the problem your process impro
vementproject will address. In general, a problem statement will outline the negative points ofth
e current situation and explain why this matters. It also serves as a great communication tool,
helping to get buy-in and support from others. One of the most important goals of any problem
statement is to define the problem being addressed in a way that's clear and precise. Its aimis fo
cus the process improvement team’s activities and steer the scope of the project. When you are
writing statement of problem. When you are writing statement of problems you should
have to apply the 5 'W's (Who, What, Where, When and Why) to the problem statement
A problem statement can be refined as you start to further investigate root cause.
Finally, review your new problem statement against the following criteria:
 It should focus on only one problem.
 It should be one or two sentences long.
 It should not suggest a solution.
For example: Problems of using paper to record down the records of patient:
 Only one copy, emergent consult problem
 Waste time to search the record
 Waste money on purchase paper
 Waste space for store record

Prep By: Tekalign T. 3|Page


1.3 Objective of the Project
A project objective describes the desired results of a project, which often includes a tangible item.
Objectives can be used in project planning for business, government, nonprofit organizations,
and even for personal use (for example, in resumes to describe the exact position a job-seeker
wants). A project may have one objective, many parallel objectives, or several objectives that
must be achieved sequentially. To produce the most benefit, objectives must be defined early in
the project life cycle. The objective directly address the problem mentioned in the statement of
the problem.
1.3.1 General Objective
Here we must be write the general objective of the system. But in this part you can only write
the main thing that the project can be done shortly. Usually there is one project goal only and
it can be reflected in the title of the project also.

Example:
The general objective of this project is to develop automated court Database management
system for sinana woreda court administration office
1.3.2 Specific Objective
Specific Objectives are statements that describe: results in terms of knowledge, attitude, skill,
aspiration, and behavior. Participant performance, rather than trainer performance or
instructional procedure. Expected performance change at the job site. An objective is specific and
measurable, and must meet time, budget, and quality constraints.
All specific objectives for effective staff development should meet the SMART Criteria.
Specific-each objective has a single key result
Measurable-each objective relates to behavior that can be measured
Attainable-each objective is realistic in terms of the available resources
Relevant-each objective is central to district or job site goals; and makes a difference in job
performance or student achievement

Timely-each objective should be able to be accomplished within the time frame established for
the staff development event.
Example
To study and develop a generic interactive distributed multimedia Database System
To implement developed database system…

Prep By: Tekalign T. 4|Page


When you are writing specific objective use the following keywords (to study, to develop, to
implement, to test) and it is not more than five or six points.
1.4 Project Justification
Project Justification is an attempt to explain why an organization needs to implement a
particular solution to a problem and how this solution can be implemented. It is a process that
starts at the Project Initiation phase to confirm the need for launching a project that addresses
the problem through implementing the solution. Justifying a project means providing the
stakeholders with a comprehensive analysis of the environment to be changed by the project. The
project is justified when the analysis gives an interpretation and evaluation of all the results to
be delivered by the project.
1.5 Assumptions/Constraints/Risks
1.5.1 Assumptions
Instructions: Describe any assumptions or dependencies regarding the database design for the
system. These may concern such issues as: related software or hardware, operating systems, or
end-user characteristics.
1.5.2 Constraints
Instructions: Describe any limitations or constraints that have a significant impact on the
database design for the system.
1.5.3 Risks
Instructions: Describe any risks associated with the database design and proposed mitigation
strategies
1.6 Methodology
The methodology section describes how you studied the problem and what you used like
materials, subjects and equipment and how you performed the project and procedure. The
methodology provide enough detail for replication of your work. Order procedures
chronologically. Use past tense to describe what you did. Don’t mix results with procedure.
1.6.1 Data Collection Techniques
When performing data collection, use the following techniques: Interviews, Questionnaires and
Surveys, Observations, Focus Groups, Ethnographies, Oral History, and Case Studies,
Documents and Records.
Primary Source
A primary source provides direct or firsthand evidence about an event, object, person, or work of
art. Primary sources include historical and legal documents, eyewitness accounts, and results of
experiments, statistical data, pieces of creative writing, audio and video recordings, speeches, and
art objects. Interviews, surveys, fieldwork, and Internet communications via email, blogs, and

Prep By: Tekalign T. 5|Page


newsgroups are also primary sources. In the natural and social sciences, primary sources are
often empirical studies where an experiment was performed or a direct observation was made.
The results of empirical studies are typically found in scholarly articles or papers delivered at
conferences.
Secondary Source
Secondary sources describe, discuss, interpret, comment upon, analyze, evaluate, summarize, and
process primary sources. Secondary source materials can be articles in newspapers or popular
magazines, book or movie reviews, or articles found in scholarly journals that discuss or evaluate
someone else's original project.

Prep By: Tekalign T. 6|Page


1.6.2 Entity Relationship Diagram
An entity-relationship diagram (ERD) is a graphical representation of an information system that shows
the relationship between people, objects, places, concepts or events within that system. In software
engineering an ER model is commonly formed to represent things that a business needs to remember in
order to perform business processes. Consequently, the ER model becomes an abstract data model that
defines a data or information structure that can be implemented in a database, typically a relational
database. An ER model is typically implemented as a database. In a simple relational database
implementation, each row of a table represents one instance of an entity type, and each field in a table
represents an attribute type. In a relational database a relationship between entities is implemented by
storing the primary key of one entity as a pointer or "foreign key" in the table of another entity. There is
a tradition for ER/data models to be built at two or three levels of abstraction. Note that the conceptual-
logical-physical hierarchy below is used in other kinds of specification, and is different from the three
schema approach to software engineering.
Example

Fig. 1.1: Diagram of Entity Relationship Diagram.

Prep By: Tekalign T. 7|Page


1.6.3 Data Flow Diagram
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information
system, modeling its process aspects. A DFD is often used as a preliminary step to create an overview of
the system.[2] DFDs can also be used for the visualization of data processing. A DFD shows what kind
of information will be input to and output from the system, where the data will come from and go to, and
where the data will be stored. It does not show information about the timing of process or information
about whether processes will operate in sequence or in parallel.

Example

Fig. 1.2: Diagram of DFD

Prep By: Tekalign T. 8|Page

You might also like