Hello again!
It is finally wintertime here in California and as the cold weather settles in we are wrapping up the first semester of our Senior Capstone project. This term has been busy with learning about our projects, defining requirements and creating the necessary documents, and figuring out how we can achieve the goals of our project.
Focusing on the technologies involved in my Capstone project, Ops Normal, which is developing equipment and personnel response for wildland firefighters, I have spent the last several months familiarizing myself with the existing code structure and learning the coding languages Dart and Flutter, which we discussed last time.
The other important technology we’re using in this project is SQLite, which is a local database that is stored within the application and used to store the records and estimates that are generated from the app. This was an area of the legacy code base that needed a substantial overhaul as the previous capstone team made some database schema mistakes that caused issues throughout the program. Let’s dive in and talk a bit about the technical aspects that made the schema change necessary!
In a database schema, each table has a relationship with other tables or entities that is based on either a one-to-one or one-to-many relationship, managed by the usage of a primary key and a foreign key. In some circumstances, you may need a table that has a many-to-many relationship with another table; this type of relationship isn’t directly possible using relational databases, however, it can be achieved by using what is called a composite table to manage the relationship. The composite table creates a one-to-many relationship between the two tables and allows the many-to-many relationship to function as expected.
Whew! Now that that’s out of the way, how does this relate to my project?
The previous team had tables that had many-to-many relationships, but had no composite table to manage the relationship! To correct this, I simplified the database design into two tables with a one-to-many relationship. This simplistic approach also helped with the overall design and clarity of the schema, depicted below.
As my team and I dive into the code base more, we have been able to correct some issues that have persisted from the last few terms and identify areas where we can improve and add new features. It’s been an exciting term learning about the project and determining the next best steps moving forward, and I’m looking forward to next term when we move int the full development cycle!
