Scribd
Upload
121 views2 pages

Project 1 Part 1

The document summarizes a project to design a scalable backend database system for a data entry application. Key aspects of the design included: 1) Normalizing the data and breaking it into sub-databases like contracts in their own table for infrequent access. 2) Modeling relationships between entities as one-to-one, one-to-many, and many-to-many with linking tables. 3) Standardizing a unique key index across all tables in addition to primary keys for easier querying and joining. 4) Learning the importance of consistent naming conventions and schema design within the group to avoid complications when building code.

Uploaded by

api-498226155
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
121 views2 pages

Project 1 Part 1

The document summarizes a project to design a scalable backend database system for a data entry application. Key aspects of the design included: 1) Normalizing the data and breaking it into sub-databases like contracts in their own table for infrequent access. 2) Modeling relationships between entities as one-to-one, one-to-many, and many-to-many with linking tables. 3) Standardizing a unique key index across all tables in addition to primary keys for easier querying and joining. 4) Learning the importance of consistent naming conventions and schema design within the group to avoid complications when building code.

Uploaded by

api-498226155
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/ 2

Amber Beebe

Michael Janes
Ericka Koyama
Justin Thomas
5/19/20

Project 1 Part One: Data Design

The goal of this project was to design a simple, scalable, backend system for a data entry
application. We have to identify all relationships and required columns while recognizing
potential design flaws when writing queries in Java. We wanted to make the database as
flexible as possible, while also having it as normalized as possible.In order to achieve that we
broke down some of the major databases into sub databases, such as having the contract text
be in its own databases ince the info will be accessed infrequently. The final result of our work is
a relational diagram which demonstrates how this data will be stored, updated, and accessed by
the users and applications which interface with it.

The relationships between all of the entities were one-to-one, one-to-many, and in some cases
many-to-many. In the case of many-to-many relationships, we used a linking table in between
both entities, so that each entity could have a one-to-many relationship with the linking table.
We noticed that each doctor can have many patients, but one patient only had one primary. This
doesn’t exclude patients that may have specialty doctors like an ENT (ear nose throat
specialist). We decided that a primary care doctor is different from a specialist and this company
was only interested in primary care physicians. Another key concept we decided on using
varchar instead of an integer for phone numbers; we used varchar to accommodate the
formatting for parts of the phone number, like the parentheses around the area code and
potentially international formats. This should also help when querying and joining on this value
since we can just use a regular string format.

A shared concept we standardized across all tables was a unique key index in addition to
possible primary keys such as social security number. Although each doctor’s and patient’s ssn
was a uniquely identifying attribute, we decided to use an auto-incremented ID column and use
that as a primary key. This allows us to query for an item with revealing the social security
number as a primary key. The final result allows all items to be unique and auto incremented.
An important takeaway from this project was to include naming convention and schema design
as a part of the group planning. There was variance amongst the names of tables, keys, and
indexes in each model produced by a different group member. Something that might have
become a complicated issue when trying to build modular code for the front-end application.

You might also like