My CS Degree Journey

WK08: Final Reflections on Databases With both group projects finished and my final exam turned in, it's a good moment to pause and reflect. This journal captures the three most important lessons I'm taking from the course. Course outcome In this course I learned to design reliable databases by translating messy real-world rules into normalized schemas with clear keys, foreign keys, and constraints. I strengthened my SQL by writing efficient JOINs and aggregations and by using execution plans and indexing to turn slow queries into fast, scalable ones. Finally, I learned how ACID transactions and isolation levels protect correctness under concurrency and failures, and when to use compensating transactions. Together, these skills - good modeling, performance-aware querying, and transactional thinking - give me the confidence to build data features that are both accurate and efficient.

WK07: Document Databases in Practice This week we shifted gears to a completely different kind of database: document-oriented storage. We spent a lot of time hands-on with the most popular example - MongoDB. I'll be honest: I was nervous at first. It's brand-new for me and we had two labs to complete. I wasn't sure I'd have enough time. But it turned out simpler than I expected. Our group project that used Java to write to MongoDB felt lighter than the SQL version - no hand-writing SQL statements, no fiddly parameter assignments; you build a Java object/document and persist it. That mental model made CRUD feel very straightforward. MongoDB vs. MySQL MongoDB and MySQL have a lot in common: both let you create, read, update, and delete data; both use indexes (including unique ones) to speed things up; both have solid drivers and tools. The big difference is how they model data and how that feels in code. MySQL is relational: tables with fixed schemas, foreign keys, and jo...

WK06: Database Programming – Bridging Code and Data This week focused on how general-purpose programming languages talk to databases. I already work in .NET with C# and Dapper, so many patterns felt familiar - opening connections, parameterized commands, mapping rows to objects. It was nice to see the theory behind the practices I use daily. Java's JDBC sits in the same conceptual space as ADO.NET + Dapper: you load a driver, obtain a Connection, issue PreparedStatements for safe, reusable SQL, stream results via a ResultSet, and manage transactions. The idioms differ, but the building blocks rhyme. ZyBooks Readings Recap The readings framed database programming from first principles to practice. We started with language paradigms - imperative (procedural, object-oriented) vs. declarative - and why databases lean on declarative SQL: complex queries are easier to express and let the optimizer choose fast plans. But full applications need control flow, so you combine SQL with a host ...

WK05: Under the Hood - Storage, Design, and Transactions This week, the big picture came into focus.  Earlier modules dug into how data lives on disk - from storage media and table layouts to single- and multi-level indexes, alternatives like bitmap/hash, and how tablespaces/partitions and physical design shape access paths. In parallel, the database design track kept sharpening the modeling lens: entities/relationships, cardinality, weak vs. strong entities, supertypes/subtypes, and how to implement all that cleanly with attributes and keys - then normalize (1NF → 3NF → BCNF) before selectively denormalizing when the read patterns demand it. Together, those tracks gave me both the conceptual design and the physical storage and indexing for reasoning about queries. On top of that foundation, this week, we added Transaction Management: what a transaction is, why ACID matters, and how schedules interleave work. I practiced spotting anomalies (dirty, non-repeatable, phantoms) and alig...