Posts

Showing posts from October, 2024

1st Week: CST 334

Hello and welcome to CST 334 Operating Systems.  Well, it was a busy week reading and reviewing lecture videos, installing a virtual machine, installing a Linux OS on it, and getting everything running for our first lab. I learned how to use the Vim editor and practiced with Bash command lines. We reviewed two's complement, binary, octal, and hexadecimal systems. I studied how the operating system (OS) manages communication between software and hardware. I also learned that the OS is responsible for managing resources such as memory and security, enforcing permissions and managing memory allocation. Depending on the context, the OS switches from User Mode to Kernel Mode to handle privileged operations, such as accessing hardware or managing processes. We also studied a little into the history of how OSes evolved over time, from single-tasking to multi-processing and from non-preemptive to preemptive scheduling. This evolution improves CPU usage because preemptive sch...

8th Week in 363 Database Management Final Week

 Wow, it's the last week. I am Miami at the 2024 first ever Robinhood Summit while I finish the class what a great way to end it. I can believe time passed so fast. Reflecting on everything I learn in class I can say three of the most important things are how relational databases work, their requirements to keep data integrity consistent, and commination within a team is very important.  Relational databases are made of tables, and each table is made up of columns that define specific data types representing different values. Each table has a primary key, which uniquely identifies each record. In addition, relational databases have foreign keys that establish relationships between different tables. Data integrity is maintained through the ACID properties.  A is for atomicity which ensures that transactions are committed fully or not at all. C is for consistency which keeps data consistent and valid. I is for isolation which keeps transactions from updating the same record...

7th Week in 363 Database Management

I’m almost finished with my Database Management course, and we recently learned about MongoDB, which shares some similarities with MySQL. Both MongoDB and MySQL are database management systems that allow you to use compatible programming languages and offer a GUI. They both can be used with the Java programming language, as we used it in our group projects. However, MongoDB and MySQL have some key differences. MongoDB is a NoSQL system, meaning it is a non relational system, unlike MySQL. MongoDB is document oriented and stores data in a flexible, schemaless format, while MySQL is a relational database that uses tables with rows and columns and enforces a strict schema. Choosing MongoDB over MySQL is ideal when the data structure is expected to change frequently. For example, adding or removing fields is easy in MongoDB, but it can be more problematic in MySQL due to its strict schema. However, MySQL is better suited when transactional data is important and needs to follow ACID princip...

6th Week in 363 Database Management

 We are almost there. This week we finally got to do some Java code and connect our mySQL database to our program. I had to trouble shoot a lot of things. For some reason my IntelliJ decided not to work and I spent so much time trying to see why. I also could not connect to my database. I got to work with my team this week, I believe this will be my new team. I learned we need to double check what we all will work on. I had written down who was working on what but maybe we were not to clear and I end up doing the same thing as one of my team mates. It was too bad just I learn we need to better communicate when we will do projects in the future to better understand each person's role. It was a fun week for me, probably the best week in the class because we got o practice more Java with mySQL.  

5th Week in 363 Database Management

If indexes are supposed to speed up performance of query,  what does the author mean by a slow index?  The author writes that using indexes involves more than just performing a tree traversal. While some people assume that index lookups require only tree traversal, additional operations, such as leaf node chaining are also used. When many entries match, the database must read the next leaf node to check for additional matches. This leads to extra performance costs and making it slower. Another thing that contributes to "slow index" is the need to fetch the corresponding table data. Since data might be scattered across many table blocks. This adds extra work and results to the overall delay in performance. The author writes that the use indexes requires not just a tree traversal, but also involves leaf node chaining and fetching table information, all of which slow down performance.