<Student Management System >

Database Systems Design

NAME :- Mushammad Hussnain

ROLL NO :- BSCS-F19-13
 Table of Contents

Table of Contents
1. Introduction 1
2. Overview 2
3. Assumptions/Constraints/Risks 3
3.1 Assumptions 3
3.2 Constraints 3
3.3 Risks 3
4. Design Decisions 4
4.1 Key Factors Influencing Design 4
4.2 Functional Design Decisions 4
4.3 Database Management System Decisions 4
4.4 Security and Privacy Design Decisions 5
4.5 Performance and Maintenance Design Decisions 5
5. Detailed Database Design 6
5.1 Data Software Objects and Resultant Data Structures 6
5.2 Database Management System Files 6
6. Database Administration and Monitoring 8
6.1 Roles and Responsibilities 8
6.2 System Information 8
6.2.1 Database Management System Configuration 8
6.2.2 Database Support Software 8
6.2.3 Security and Privacy 9
6.3 Performance Monitoring and Database Efficiency 9
6.3.1 Operational Implications 9
6.3.2 Data Transfer Requirements 9
6.3.3 Data Formats 9
6.4 Backup and Recovery 9

7. ERD, Queries and Tables 10

6.1 Database ERD 11
6.2 Queries 12
6.3 DB Tables made in SQLServer/Oracle 13
 1. Introduction
Instructions: Provide identifying information for the existing and/or proposed automated
system or situation for which the DDD 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 document, the scope of
activities that resulted in its development, the intended audience for the document, and
expected evolution of the document. Also describe any security or privacy
considerations associated with use of the DDD.

Student Management System is software which is helpful for students as well as the school
authorities. In the current system all the activities are done manually. It is very time consuming
and costly.
Our Student Management System deals with the various activities related to the students.
There are mainly 3 modules in this software
• User module
• Student Module
• Mark management
In the Software we can register as a user and user has of two types, student and administrator.
Administrator has the power to add new user and can edit and delete a user. A student can
register as user
and can add edit and delete his profile. The administrator can add edit and delete marks for the
student. All the users can see the marks.
 2. Overview
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 document.

Student management system is an environment where all the process of the student in the
institution is managed. It is done through the automated computerized method. Conventionally this
system is done using papers, file and binders.

This system saves the time of the student and of the administrator. It includes process like
registration of the student’s details, assigning the department based on their course and
maintenance of the record.

This system reduces the cost and workforce required for this job. As the system is online the
information is globally present to everyone. This makes the system easy to handle and feasible for
finding the omission with updating at the same time.

As for the existing system, they use to maintain their record manually which makes it vulnerable to
security. If filed a query to search or update in a manual system, it will take a lot of time to process
the query and make a report which is a tedious job.

As the system used in the institute is outdated as it requires paper, files and the binders, which will
require the human workforce to maintain them. To get registered in the institute, a student in this
system one should come to the university.

Get the forms from the counter while standing in the queue which consumes a lot of the student’s
time as well as of management team. As the number of the student increases in the institute
manually managing the strength becomes a hectic job for the administrator.

This computerized system store all the data in the database which makes it easy to fetch and
update whenever needed.
3. Assumptions/Constraints/Risks
3.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.

3.2 Constraints
Instructions: Describe any limitations or constraints that have a significant impact on
the database design for the system.

3.3 Risks
Instructions: Describe any risks associated with the database design and proposed
mitigation strategies.
4. Design Decisions
Instructions: Utilizing the following subsections, describe decisions made that impact
the proposed database design. This should include the platform and database
management system (DBMS) chosen for the project. Include any other information
relevant to the database design decisions (e.g., Data Conversion Plan, Service Level
Agreements (SLAs)). The Design Decisions section is written at a higher level than the
subsequent Detailed Database Design section, and provides an understanding and
rationale for the content in the Detailed Database Design section. If any of the
information in this section is provided in the SDD, ICD(s), or other documents (e.g.,
Data Conversion Plan), they may be referenced within this section as appropriate.

4.1 Key Factors Influencing Design

Instructions: Describe key functional or non-functional requirements that influenced
the design. If all such decisions are explicit in the requirements, this section shall so
state. Design decisions that respond to requirements designated as critical (e.g., those
for performance, availability, security, or privacy) shall be placed in separate
subparagraphs. If a design decision depends upon system states or modes, this
dependency shall be indicated. If some or all of the design decisions are described in
the documentation of a custom or commercial DBMS, or in the SDD, they may be
referenced in this section. Design conventions needed to understand the design shall
also be presented or referenced.

4.2 Functional Design Decisions

Instructions: Describe decisions about how the database will behave in meeting its
requirements from a user's point of view (i.e., functionality of the database from an
application perspective), ignoring internal implementation, and any other decisions
affecting further design of the database. Include decisions regarding inputs the
database will accept and outputs (displays, reports, messages, responses, etc.) it will
need to support, including interfaces with other systems. Describe the general types of
processing (sequential versus random for inserts, updates, deletes and queries)
required both for data entering the database, and data most frequently accessed. If
any of this information is provided in ICD(s) or other documents, they may be
referenced.
Describe selected equations/algorithms/rules, disposition, and handling of un-
allowed inputs. Also include decisions on how databases/data files will appear to the
user.

4.3 Database Management System Decisions

Instructions: Describe design decisions regarding the DBMS intended for the initial
implementation. Provide the name and version/release of the DBMS, the reason
for selection, and the type of flexibility built into the database for adapting to
changing requirements.

4.4 Security and Privacy Design Decisions

Instructions: Describe design decisions on the levels and types of security and privacy
to be offered by the database. General descriptions of classifications of users and
their general access rights should be included.

4.5 Performance and Maintenance Design Decisions

Instructions: Describe how performance and availability requirements will be
met. Examples include:
 Describe design decisions on database distribution (such as client/server),
master database file updates and maintenance, including maintaining
consistency, establishing/ reestablishing and maintaining synchronization,
enforcing integrity and business rules.
 Describe design decisions to address concurrence issues (e.g., how the data
are partitioned or distributed to support multiple applications or competing
update functions, if applicable).
 Describe design decisions to support Service Level Agreements (SLAs) for
key functions supported by the database.
 Describe design decisions on backup and restoration including data and
process distribution strategies, permissible actions during backup and
restoration, and special considerations for new or non-standard technologies
such as video and sound. Describe the impact this maintenance will have on
availability.
 Describe design decisions on data reorganization (i.e., repacking, sorting, table
and index maintenance), synchronization, and consistency, including automated
disk management and space reclamation considerations, optimizing strategies
and considerations, storage and size considerations (e.g., future expansion),
and population of the database and capture of legacy data. Describe the impact
this maintenance will have on availability.
 Describe design decisions to support purging and/or archiving of data to ensure
performance and storage objectives are met. Describe the impact this
maintenance will have on availability. Describe any needs to recall archived
data back into the database.
5. Detailed Database Design
Instructions: Describe the design of all DBMS files associated with the system, and any
non-DBMS files pertinent to the database design. The headings and sub-headings in
this section should be structured according to the information to be presented, and
may include discussions about or references to the following:
 Logical Data Model (LDM) and LDM Entity Relationship Diagram (ERD).
 Physical Data Model (PDM) and PDM ERD.
 A comprehensive Data Dictionary showing data stores, data element name,
type, length, source, constraints, validation rules, maintenance (create, read,
update, delete (CRUD) capability), audit and data masking requirements,
expected data volumes, life expectancy of the data, information life-cycle
management strategy or at least an archiving strategy, outputs, aliases, and
description.
 Indexes that will be required for the data objects.
 Planned implementation factors (e.g., distribution and synchronization)
that impact the design.
The detailed database design information can be included as an appendix, which
would be referenced here. If any of the information in this section is provided in the
SDD, ICD(s), or other documents, they may be referenced.

5.1 Data Software Objects and Resultant Data Structures

Instructions: For each functional data object, specify the data structure(s) which will
be used to store and process the data. Describe any data structures that are a major
part of the system, including major data structures that are passed between
components. List all database objects including stored procedures, functions and
function parameters. For functions, give function input and output names in the
description.
Refer as appropriate to the decomposition diagrams. Provide the detailed description
of any non-DBMS files (e.g., property files) that are required for DBMS functioning or
maintenance and are not already addressed in the SDD. Include a narrative description
of the usage of each file that identifies if the file is used for input, output, or both, and if
the file is a temporary file. Also provide an indication of which modules read and write
the file (refer to the Data Dictionary). As appropriate, include file structure information.

5.2 Database Management System Files

Instructions: Provide an appropriate level of detailed design of the DBMS files, based
on the DBMS chosen. Describe file structures and their locations. Explain how data
may be structured in the selected DBMS, if applicable. For networks, detail the specific
distribution of data. Note any changes to the LDM, which occur because of software or
hardware requirements or to support performance objectives. Include the following
information, as appropriate (refer to the Data Dictionary):
 Physical description of the DBMS schemas, sub-schemas, records, sets,
tables, storage page sizes, etc. A PDM ERD should be included in an appendix.
 Objects created to support access methods (e.g., indexed, via set,
sequential, random access, sorted pointer array, etc.)
 Distribution, partitioning, or other compartmentalization of the data to
support design.
 Estimate of the DBMS file size or volume of data within the file, and data
pages, including overhead resulting from access methods and free space.
 Definition of the update frequency of the database tables, views, files,
areas, records, sets, and data pages. Also provide an estimate of the
number of transactions, if the database is an online transaction-based
system.
6. Database Administration and Monitoring
Instructions: Within the following sub-sections, describe the requirements and
strategies to maintain the database operationally considering the following:
 Required availability and requirements for standby sites of the data stores,
both DBMS and non-DBMS to satisfy continuity of operations and meet
required
Service Level Agreements (SLAs).
 Any database specific application and user support scenarios that are
not documented in the SDD.
 Any monitoring and performance goals/requirements, and how the DDD supports
them.
 Required maintenance of the data stores to maintain acceptable performance.
 Backup and recovery strategies needed to implement the DDD.
 Any security and/or privacy considerations.

6.1 Roles and Responsibilities

Instructions: Identify the organizations and personnel responsible for the following
database administrative functions: database administrator, system administrator, and
security administrator. Describe specific administration skill requirements applicable
to the database.

6.2 System Information

Instructions: Document the DBMS configuration, hardware configuration, database
software utilities, and any support software used. If any of these software elements
or hardware configurations are not CMS-standard architecture, indicate the date
these
items were approved or a waiver was granted.

6.2.1 Database Management System Configuration

Instructions: Identify the vendor, version or release date and targeted hardware for the
DBMS chosen for the initial implementation of the database. Describe any restrictions
on the initialization and use of the DBMS to support any intended distributed
processing. Identify the minimum hardware configurations for the environment on
which the database will reside. Describe the storage device and storage requirements.
Provide sizing formulas for determining the storage required to support the
database content and associated software. Estimate the internal and peripheral
storage requirements. Identify multiple storage requirements for distributed
processing.

6.2.2 Database Support Software

Instructions: List and reference the documentation of any DBMS utility software
available to support the use or maintenance of the database. Describe all support
software, including the operating system, directly related to the database, including
name, version, function, and major operating characteristics. Cite documentation
10
by

10
title, number, and appropriate sections. Examples of such software include
database management systems, query languages, report writers, storage allocation
software, database-loading software programs, file processing programs, and data
cleaning software.

6.2.3 Security and Privacy

Instructions: Describe the use and management of integrity and access controls that
apply to all database components such as schema, sub-schema, partitions or physical
files, records or tables, sets or relations, and data elements. Describe any tools or
sub- schemas that will support security and privacy requirements.

6.3 Performance Monitoring and Database Efficiency

Instructions: Provide appropriate detailed subparagraphs that relate to the section
named Performance and Maintenance Design Decisions. Describe what parties will
be responsible for monitoring performance (to include space utilization, system
resource consumption, and query performance metrics), along with tools that will help
provide this monitoring. If interfaces with other systems impact maintenance, provide
a description of those interfaces with other application software including those of
other operational capabilities and from other organizations. For each interface, specify
the
information described in the following sub-sections.

6.3.1 Operational Implications

Instructions: Describe operational implications of data transfer, refresh and update
scenarios and expected windows, including security considerations. If any of these
are documented in the SDD or the ICD, they can be referenced here.

6.3.2 Data Transfer Requirements

Instructions: Describe data transfer requirements to and from the software, including
data content, format, sequence, volume/frequency and any conversion issues. If any
of these are documented in the SDD or the ICD, they can be referenced here.

6.3.3 Data Formats

Instructions: Describe formats of data for both the sending and receiving systems,
including the data item names, codes, or abbreviations that are to be interchanged,
as well as any units of measure/conversion issues. If any of these are documented in
the SDD or the ICD, they can be referenced here.

6.4 Backup and Recovery

11