Week 1

 Week 1 (5/25-6/1)

What did I learn in the first week at CST334: Operating Systems?

This week, I read the required textbook chapter and learned a lot about low-level languages. The chapter also included a brief overview of the history of operating systems, tracing their origins over time. C is a new language for me—my experience has been mostly in object-oriented programming (OOP), so working without objects and instead using structs feels like rewiring everything I know. Fortunately, learning C is directly helping me in my internship, where I’m learning about binary analysis and symbolic execution using angr. These techniques allow users to analyze and manipulate binary code, explore execution paths, and identify vulnerabilities. Working with this powerful Python-based framework is especially useful when analyzing compiled C code without access to the source.

Learning about WSL, Docker, and Ubuntu has also been extremely helpful in understanding the tech stack used in my internship, along with the many tools Linux provides. The software engineers I work with recommend Linux for its security, stability, and seamless development workflow. The buffer overflow exercises in Lab 1 and the memory allocation practice in PA1 were especially effective for deepening my understanding of memory. I also saw how temporary fixes can sometimes work, but using ```malloc``` is a better long-term solution for managing memory.

Perhaps the most valuable takeaway this week was learning how to use VS Code (a Windows IDE) to write and debug code that will be deployed on a Linux server—all within a Windows environment using WSL and Ubuntu. At first, I downloaded gcc.exe through MinGW-w64, thinking I needed it to compile C in VS Code using the C/C++ extension. However, my professor explained that this could interfere with Docker compilation and why it’s important to avoid that. I’ve since disabled the extension to prevent VS Code from adding Windows-specific headers like ```#include "windows.h"```, which would cause compilation issues. So far, I’ve really enjoyed this class and look forward to learning more.

Week 8

 Week 8 (6/19-6/20)

Last week for Intro to Database Systems, what?😧

Briefly summarize what you consider to be the three (3) most important things you learned in this course

1. Queries, especially joins, how to merge data from different tables and subselect. As well as learning how to perform CRUD operations, including select, insert, update, and delete.

2. Reverse and forward engineering, being able to generate an ER diagram based on a database, or creating an ER diagram and generating the database are such great features. After I learned this, I saved so much time, especially in a test. I used to design ER diagrams or wireframes on Lucidchart, which is not as efficient after using this MySQL feature

3. The JDBC API to create a webapp is probably the most useful real-world project, because we get to use Spring boot (open-source framework), mySQL and MongoDB to create a web app. I did something similar before using SQLite and Tomcat but Spring was more compact to use. I also love how we use the same lab to compare the functionality of MySQL and MongoDB and were able to see the differences (pros and cons).

Week 7

 Week 7 (6/11-6/17)

Comparison between MongoDB and MySQL. 

What are some similarities? 

MongoDB and MySQL both support indexing, sharding, replication, and unique keys to help manage and access data efficiently. Each one also allows users to select specific fields in a query (called projection) and provides an “explain” tool to see how a query runs.

What are some differences? 

MySQL is a relational database that utilizes SQL, supports joins, and provides full transaction support, ideal for structured data and complex queries. MongoDB is a NoSQL database that stores flexible, JSON-like documents. It doesn’t support joins or full transactions, but it is easier to scale and better for unstructured or changing data.

When would you choose one over the other?  

Choosing MySQL for strict data structure (tables with clear columns), when we need transactions or joins or when strong consistency is needed, MySQL is the best choice. Choosing MongoDB when flexibility and scalability are required, such as when data is nested (like JSON), when easy scaling across servers is needed, and when speed is crucial, is when MongoDB is a better choice.

Week 6

 Week 6 (6/4-6/10)

Summary of this week's learning:

For lab 17, I learned to open a JDBC connection to course DB, turned off auto-commit, used a preparedStatement to insert the new student (with tot_cred = 0) and run executeUpdate() and print how many rows change, use another PreparedStatement to select id and name for that department and print each. And on success, call commit(); on error, call rollback() and close the connection.

For labs 18 and 19, I learned how to use Reverse Engineering and Forward Engineering to create a schema and an ER diagram. I learned how to use the model in MySQL and some other features to establish relationships between tables, and conducted an assessment or peer review with the other two classmates, where I was able to see different ER diagrams and designs and determine if they met the requirements. For Lab 19, I collaborated with my group to create a web application using Spring Boot, a Java-based framework, building upon the concepts introduced in Lab 18 (Prescription). I worked on ControllerPrescriptionCreate and filled out the forms with both existing ("lisinopril") and non-existent drugs ("funny pills").

Week 5

Week 5 (5/28-6/3)

The web site "Use the Index Luke" has a page on "slow indexes".   https://use-the-index-luke.com/sql/anatomy/slow-indexesLinks 

If indexes are supposed to speed up performance of query,  what does the author mean by a slow index?

Based on the site, a “slow index” isn’t a broken index; it’s simply when using an index ends up doing more work than expected, sometimes even more than scanning the entire table. After the database finds the starting point in the B-tree, it may need to traverse a chain of leaf nodes to gather all matching entries (for instance, when looking up a value “23” that appears in multiple locations). If many rows share the same key, the database follows the leaf-node chain and may read dozens or hundreds of index pages just to collect all pointers to matching rows.

Once those index entries are found, the database typically retrieves each matching row from the table one by one. If those rows are scattered across different data pages, each lookup can trigger a random I/O. For example, if your query matches 200 rows, that could mean 200 separate reads to fetch the actual data, resulting in a slower process than a simple full-table scan. In short, the B-tree lookup itself is fast, but the combined cost of following many leaf pointers plus fetching each row individually can make an “indexed” query slower than you’d expect.

Week 4

 Week 4 (5/21-5/27)

Halfway done already? Time sure flies.

Five things I have learned these four weeks of class:

1. Create an ER (Entity Relationship) diagram in MySQL. I have created them in Lucid before, but never in MySQL, and this is a great feature.

2. How to use simple and complex queries

3. How to use the Binary Search Algorithm in Java for OrderedIndex

4. Storage media: Speed, cost, capacity, and volatility, and the types of media: main and flash memory, and magnetic disk

5. Entities, relationships, and attributes (PK and FK) and database design: conceptual, logical, and physical design

Questions I have about databases:

1. When do we implement dotted lines when creating relationships between entities?

2. How efficient is the Boyce-Codd normal form in large datasets and memory?

3. What are some disadvantages of views?

Week 3

 Week 3 (5/14-5/20)

What is an SQL view.  How is it similar to a table? In what ways is it different (think about primary keys,  insert, update, delete operations) ?

In a database, a view is a virtual table based on the result set of an SQL statement. A view contains rows and columns, just like a real table. The fields in a view are fields from one or more real tables in the database.  You can join multiple tables in a view and use the View to present the data as if the data were coming from a single table.

Views can be used as security mechanisms by letting users access data through the view, without granting the users permissions to directly access the underlying base tables of the view.

However, views are different from tables in several ways. A view does not store data itself; it only shows data from the underlying tables. Views do not have primary keys or indexes like regular tables do. Also, you cannot insert, update, or delete data through a view unless it is a simple view based on a single table without aggregates or joins. Even when updates are allowed, the changes affect the base table(s), not the view itself.

MySQL views/tables:

We have completed our study of SQL for this course.  This is not to imply that we have studied everything in the language.  There are many specialized features such as calculating rolling averages, query of spatial data (data with latitude and longitude) coordinates, and more. But take a minute to think about how SQL compares to other programming languages such as Java.  What features are similar , and which are present in one language but not in the other?  For example,  Java has conditional if statements which are similar to SQL WHERE predicates,  the SELECT clause is similar to a RETURN statement in that it specifies what data or expression values are to be returned in the query result (although it is strange that a statement should specify the RETURN as the first part of a SELECT. 

In my opinion, Java and SQL are very different; one is a programming language, and the other is a query language, both are different types of language. In other words, SQL is a language where you declare what you want, for example, to retrieve data; meanwhile, in Java, we have to specify how to do something step by step. However, they share a few features, like the use of arithmetic and logical operations, the WHERE in SQL, and the IF in Java support conditional logic, and the return statement in Java mimics the SELECT statement in SQL to define the output. Other differences include the loops (for, while), which only Java implements, Java uses classes and OOP, while SQL uses tables, rows, and columns. Also, error handling and syntax are handled differently, in SQL with sets and relations, and Java handles individual objects.