Relational database proposal example

Abstract

Database systems provide organizations with a wide range of benefits including faster storage and retrieval of information, business intelligence and compliance with information security policies. Despite these numerous benefits, there are challenges that organizations face during the design phase. This proposal presents a database design proposal for a typical healthcare organization to handle events like storage of patient records, physicians, track finances, store medical examinations and treatment and ensure efficient booking of appointment by patients (Doukas, Pliakas, & Maglogiannis, 2010). The proposal will present a conceptual design that includes an ERD model.

Introduction

Manual maintenance of information is becoming difficult and obsolete as healthcare technology advances. In the healthcare industry, the storage of medical records is electronic hence requiring a healthcare organization to store information in a database and access them through a database management system. Currently, healthcare industry faces a challenge of slow information processing, loss of medical records, breaching of information security, massive consumption of papers due to manual storage and inaccuracy in analyzing data. This project aims at addressing these issues through a design of healthcare database using Entity-Relationship modeling. An Entity-Relationship model is a high-level design of the database that shows database entities, attributes, and the relationship between the entities (Earp & Bagui, 2012). Entities are real objects like patients, physicians, and hospitals while attributes are elements that give the objects its characteristics. Attributes include race, age, size, and address.

Solution

Despite the numerous benefits associated with database storage, there are challenges that organizations face during the design phase. However, this solution aims at developing a database design for a typical healthcare organization to handle events like storage of patient records, physicians, track finances, store medical examinations and treatment and ensure efficient booking of appointment by patients. The proposal will present a conceptual, logical and physical design through an Entity-Relationship model. The proposed database will also include a relational schema of the database to allow generation of results based on the desired queries developed in SQL (Al-Masree, 2015).

The project will be limited to design process of the database to yield deliverables like an ERD diagram, list of entities and attributes, a data dictionary, and description of the database design. The steps required to accomplish this objective will begin with the identification of entities and attributes, setting the relationships, presenting the entities in an ERD diagram and developing a data dictionary. A data dictionary will help map the project to a database design.

Resources

This project requires both human resources, financial capital, software components and hardware components. The human resource required include a graphic designer, database administrator, business requirements analysis, and a software engineer. Software requirements for the project include a relational database system like MS Access and SQL server and graphic design software like Adobe suite and Illustrator. Hardware components for the project are five Dell personal computers.

Budget

The table below shows a high-level budget estimation for the project:

Resource Item

Estimated Cost

Human Resource

$21, 000

Software Components

$1,250

Hardware components

$2,500

Total

$23,750

Users

Physicians: these are the database users with a strong knowledge in medical practice. However, these users have a limited experience in database management but can handle basic computer operations including running queries, reading from a database and creating useful information to the database system.

Patients: this includes a group of users with a mixed level of knowledge and competencies. They include computer experts and individuals with physical or technical disabilities. This group include the average users of the database but seeking medical advice from a healthcare facility. They also include family members of individuals seeking medical advice (Doukas et al., 2010).

Conclusion

Conclusively, the healthcare database design is highly recommended because it eliminates the vast expenses of using paper-based records. The design is also affordable because it does not include many stakeholders hence reduced disagreements during execution. Additionally, the design will help in improving the accuracy, security, and usability of the medical database. Upon successful implementation of the project, the project will result in improved return of investment for the hospital organization due to minimal operating costs and optimum delivery of services.

Reference

Al-Masree, H. K. (2015). Extracting Entity Relationship Diagram ( ERD ) From Relational Database Schema. International Journal of Database Theory and Application, 8(3), 15–26.

Doukas, C., Pliakas, T., & Maglogiannis, I. (2010). Mobile healthcare information management utilizing Cloud Computing and Android OS. In 2010 Annual International Conference of the IEEE Engineering in Medicine and Biology Society, EMBC’10 (pp. 1037–1040). https://doi.org/10.1109/IEMBS.2010.5628061

Earp, R., & Bagui, S. (2012). Database Design Using Entity-Relationship Diagrams. Library (Vol. 2012). https://doi.org/10.1201/9780203486054

Database Schema

The Database identified on module 1 will include the following five major entities and their relationships:

1. Physician: the physician entity has a one-to-many relationship with the treatment entity.

1. Patient: this entity has a one-to-many relationship with the appointment entity. Patient entity has a one-to-one relationship with a treatment entity.

1. Appointments: this entity has a one-to-many relationship with the patient entity. A patient will make an appointment (Bracci, Corradi, & Foschini, 2012).

1. Invoice: this entity has a one-to-many relationship with the treatment entity.

1. Treatment: this entity has a one-to-many relationship with the physician entity but a one-to-one relationship with an invoice entity.

Database Diagram

The diagram below shows the Entity Relationship of the database design:

erdplus-diagram

Database Schema

Data Dictionary

The table below shows the data dictionary for the Entity Relationship diagram designed:

Entity

Description

Attributes

Constraints

Physician

This entity will record all the personal and professional information about the physicians in the healthcare center.

Physician id, address, phone, age, degree, gender, shift

Primary key: Physician id

Patient

This entity will store information regarding the patients that can help in identifying them and offering best medical services.

Patient id, name, address, phone, age, gender

Primary key: Patient id

Appointments

An entity that will store the patients’ appointments and services they seek.

Appointment id, date, treatment id, physician id,

Primary key: appointment id,

Foreign key: physician id

Invoice

A financial entity that will store information about the billing for specific customers based on the treatment they receive.

Invoice id, patient id, amount due, invoice date, treatment id,

Primary key: invoice id,

Foreign key: patient id, treatment id

Treatment

This entity will record all the medical services that the entity offers to specific patients and the description of the services.

Treatment Id, patient Id, treatment, treatment cost, date,

Primary key: treatment id

Foreign key: patient id,

Areas of Difficulty

Identifying the database entities was challenging because it requires an interpretation of business requirements to identify the objects. At first, there were numerous entities identified that could lead to enormous database design. However, with closer consideration of the normal routine of a patient-physician healthcare visit, it was possible to determine the relevant entities and eliminate the irrelevant entities.

Developing the Entity Relationship diagram was also difficult because I was not familiar with the development tool. After implementing the first entity, adding attributes and inserting an appropriate relationship, it was easier to complete demonstrating and transfer them to this report.

Reference

Bracci, F., Corradi, A., & Foschini, L. (2012). Database security management for healthcare SaaS in the Amazon AWS Cloud. In Proceedings - IEEE Symposium on Computers and Communications (pp. 000812–000819). https://doi.org/10.1109/ISCC.2012.6249401

Database Schema