[go: up one dir, main page]

0% found this document useful (0 votes)
13 views9 pages

System Design Document: Blood Bank Management System

The System Design Document (SDD) outlines the Blood Bank Management System (BBMS), detailing its architecture, data models, and functionality for stakeholders involved in the project. It serves as a reference for the development team, blood bank administrators, and quality assurance teams, ensuring a comprehensive understanding of the system's design and operational needs. Key sections include assumptions, constraints, and normalization processes related to the database schema.

Uploaded by

gnprachi
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 views9 pages

System Design Document: Blood Bank Management System

The System Design Document (SDD) outlines the Blood Bank Management System (BBMS), detailing its architecture, data models, and functionality for stakeholders involved in the project. It serves as a reference for the development team, blood bank administrators, and quality assurance teams, ensuring a comprehensive understanding of the system's design and operational needs. Key sections include assumptions, constraints, and normalization processes related to the database schema.

Uploaded by

gnprachi
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

System Design Document

for

Blood Bank Management System

Prepared by Group

Number : 34

Vedurupaka Venkata Sai B210437CS vedurupaka_b210437cs@nitc.ac.in

Leela Krishna B210569CS nimmalapudi_b210569cs@nitc.ac.in

K.Lokesh Gupta B210539CS kusumanchi_b210539cs@nitc.ac.in

Utkarsh Kumar B210559CS utkarsh_b210559cs@nitc.ac.in

Instructor: Dr. K.A. Abdul Nazeer

Course: Database Management Systems CS3002D


CONTENTS................................................................................................................................................................. II
1 PURPOSE............................................................................................................................................................ 1

1.1 DOCUMENT OBJECTIVES...........................................................................................................................................................................................1


1.2 TARGET AUDIENCE..................................................................................................................................................................................................... 1
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS............................................................................................................................................ 1
1.4 REFERENCES AND ACKNOWLEDGMENTS............................................................................................................................................................ 2

2 ASSUMPTIONS AND CONSTRAINTS.......................................................................................................... 3

2.1 ASSUMPTIONS............................................................................................................................................................................................................... 3
2.2 CONSTRAINTS................................................................................................................................................................................................................3

3 DATABASE FUNCTIONS................................................................................................................................. 4

3.1 CONTROL-FLOW……………………………………………………………………………………………………………………………...………4

3.2 ENTITY - RELATIONS MODEL................................................................................................................................................................................. 4


3.3 RELATIONAL SCHEMA................................................................................................................................................................................................ 5
3.4 NORMALIZATION.......................................................................................................................................................................................................... 6
3.5 SCHEMA DESCRIPTION.............................................................................................................................................................................................. 7
The primary purpose of this System Design Document (SDD) is to provide a comprehensive
description of the Blood Bank Management System (BBMS). This document explains the purpose,
architecture, data models, and functionality of the BBMS, serving as a crucial reference for the
development team, system administrators, and all stakeholders involved in the project.
Additionally, it lays the foundation for effective project management, quality assurance, and
system testing.

1.1 Document Objectives


1. System Architecture: This section offers a detailed explanation of the architectural
components of the Blood Bank Management System, encompassing hardware,
software, and network components. It provides insights into how the system is
structured and how these components interact to ensure the system's smooth operation.

2. Data Model: In this part, we describe the database schema, entity-relationship


diagrams, and data structures used in the Blood Bank Management System. It outlines
the structure of the database, the relationships between various data entities, and how
data is organized and stored.

1.2 Target Audience

1. Development Team: This includes developers, database administrators, and IT


professionals responsible for the design, development, and maintenance of the BBMS. It
provides them with essential insights into the system's architecture and data model.

2. Blood Bank Administrators: Blood bank managers, executives, and personnel involved in
decision-making processes within the blood bank. The document helps them understand the
technical aspects of the system and how it supports their operational needs.

3. Quality Assurance and Testing Teams: Teams responsible for testing the BBMS to ensure
it functions correctly and adheres to performance and security standards. The document
provides a basis for crafting test cases and evaluating system performance.

4. Blood Bank Staff: Staff working directly with the Blood Bank Management System on a
daily basis, including blood bank technicians, administrators, and operational roles that rely
on the system for their day-to-day tasks. This document gives them a deeper understanding
of the system's inner workings.
1.3 Definitions, Acronyms and Abbreviations

● BBMS: Blood Bank Management System


● SDD: System Design Document
● DBMS: Database Management System
● ERD: Entity-Relationship Diagram
● NITC: National Institute of Technology, Calicut
● 1NF: First Normal Form
● 2NF: Second Normal Form
● 3NF: Third Normal Form

1.4 References and Acknowledgments


● Fundamentals of Database Systems by Ramez Elmasri

● https://dbdiagram.io/

● https://erdplus.com/

● https://mermaid.live/
2.1 Assumptions
The following are assumptions made while developing the project:

Data Migration: Assuming that the BBMS has access to existing data related to blood inventory, donor
and patient information, and other relevant data, which will be migrated into the new database system
without significant data quality issues.

Hardware and Software Availability: Assuming that the necessary hardware, servers, database
management software, and development tools required for the BBMS project are available and meet the
project's technical requirements.

Data Cleansing and Transformation: Assuming that any data cleansing or transformation required
during the migration process is within the project scope and manageable, ensuring that the data in the new
system is reasonably accurate.

Data Security Measures: Assuming that appropriate data security measures, including access controls and
encryption, are in place to protect the BBMS database from unauthorized access and potential security
breaches.

Scalability: Assuming that the BBMS is designed to be scalable, capable of accommodating potential
future growth in terms of blood donation records, patient information, user accounts, and additional
features to meet the evolving needs of the blood bank.

User Acceptance: Assuming that the BBMS will be accepted and utilized effectively by blood bank
employees and staff, with adequate training and user-friendly interfaces to support their daily operations.

Maintenance and Updates: Assuming that the project team will provide regular maintenance, updates,
and enhancements to the BBMS to ensure it continues to function optimally, remains secure, and meets
changing requirements in the field of blood banking.

2.2 Constraints
The design contain the following constraints:

Development and Maintenance Constraints:The BBMS software is exclusively designed,


delivered, and maintained by the project team.

Admin Access Constraints:Admin access to the system is protected with unique and secure
credentials, ensuring the security and integrity of admin-related functions.

User Role-Based Dashboard Constraints: Each employee or user has different credentials
and is provided with a personalized dashboard that aligns with their specific role and
responsibilities within the system.
3.1 Control Flow

3.2 Entity-Relation Model


3.3 Relational Schema
3.4 Normalization

● 1NF - The tables are in 1NF, as there are no multivalued or composite attributes.
Each table cell contains atomic values, and each record is unique. Hence the database
is 1NF normalized.

● 2NF - The tables are already in 1NF as proved above. There are no partial
dependencies, that is, there are no non-prime keys solely dependent on only one part
of a primary key in any of the tables. Hence the database is 2NF normalized.

● 3NF - The tables are already in 2NF as proved above. There are no transitive
functional dependencies in the schema. There are no non-prime keys that are
dependent on another non-prime key in any specific table. Hence the database is
3NF normalized.
3.5 Schema Description

You might also like