Tuesday, June 25, 2024

CST 334 - Week 1

 For the first week of CST 334, we did some readings that helped explain the purpose and design of an operating system. Two of the main purposes of an operating system are acting as a resource manager and to provide a layer of abstraction between the user and the hardware. This allows the average user to interact with the computer's software and components without having to have a thorough knowledge of low-level language.

During the lab portion of this week, we covered how to use GDB to trace our steps through a program. We utilized GDB in my computer architecture class, but I never quite got the hang of it. Hopefully I will get more practice using it in this class as it seems more comprehensive than my constant use of print statements. For the programming assignment, we brushed up on some C programming by doing some string manipulation and playing with pointers. It was definitely a good refresher.

Thursday, June 13, 2024

CST 363 - Week 8

 This course covered a wide range of important topics regarding the design and use of databases. Three of the most interesting and important topics we covered were the use of MySQL and how to use joins, views, and subqueries to most efficiently retrieve data, the important of transactions and how mishandling them can create a cascading mistake, and how indexes can be very useful, but utilizing them in a database design must be well-balanced as to avoid negatively impacting performance.

Tuesday, June 11, 2024

CST 363 - Week 7

MongoDB and MySQL are similar in many ways. They both are free-to-use and open source. They both provide a way to handle and analyze large amounts of data easily. In addition, they are also both capable of being used in tandem with other coding languages, like Java and Python. Both database management systems contain encryption features that allow for needed security.

The most obvious difference between the two systems is that MySQL is a relational system and MongoDB is a non-relational, or NoSQL, system. MySQL stores data using specifically defined schema, which leaves less room for flexibility, while MongoDB stores information like a hash map using key/value pairs. MySQL is more limited when it comes to scalability, while the use of sharded clusters allow MongoDB to be extremely easy to scale.

One reason, I would choose MySQL over MongoDB would be when I need the data formatting to be clear and consistent. For example, employee records all need the same information, so the row/column structure maintains that record-keeping would be consistent. It also allows for some desirable safety features, like referential integrity. However, I really enjoyed the flexibility of MongoDB, so I would choose it when foreign keys aren't as necessary and I want the ability to store data using different schemas. I also though the JSON style structure was easy to understand as that's something that I've had exposure to in other programming areas, while MySQL statement can be complex and take some getting used to.

Tuesday, June 4, 2024

CST 363 - Week 6

 This week we focused mainly on how to use JDBC, which is Java API that is used for database connectivity. We utilized its tools to connect our database design with a web application that simulates registering new doctors and patients and writing/filling prescriptions. For the application, we used PreparedStatements in a Java program to put together SQL statements for database queries/inserts. It was very interesting to learn how to connect my knowledge in Java with what I've learned about databases in this class. It was also fun to get a refresher in the way the web app is viewed on the page, since it's been a while since I've done any web development.

Tuesday, May 28, 2024

CST 363 - Week 5


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

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



Because databases are supposed to speed up performance, many people have concerns when they don't return data as quickly as expected. A "slow index" is the name given when this occurs. The myth of the slow index was originated by the idea that an index search simply traverses the tree, but in reality it requires multiple steps of the tree traversal, following the leaf node chain, and fetching the data from the table. For the tree traversal, the index lookup will act quickly, but for the other two steps, they are potentially accessing many blocks while trying to ensure accurate matching, which will slow down the index lookup.

Monday, May 20, 2024

CST 363 - Week 4

 At the halfway point of the course, I feel like I've learned a lot of information regarding databases. Some of the things that stand out are
    1) Virtual tables - These allow you to utilize a specific scope of data held in the database tables, but they aren't actually stored in memory
    2) Composite primary keys - Up until now, I'd only ever utilized single-column primary keys, so it was interesting to learn that unique combinations of columns can act as a composite primary key
    3) The idea of a cascade - I always thought it was very complicated how tables were related, but learning about how they keys can connect tables and create a domino effect when data is updated or deleted made me less intimidated by the subject
    4) Aggregate functions - These allow you to select a summarized value from a set of rows. For example, you may choose to SELECT AVG(test_scores) FROM our_class in order to find the average test score achieved.
    5) Relational Algebra - Codd's operations, which are used for manipulating tables. These provide the theoretical foundation of SQL and each algebraic expression can be translate to an equivalent SQL query


I'm not sure if I have specific questions regarding databases, but I do have weak topics. My biggest weakness is definitely regarding what goes on behind the scenes. Computer architecture is not my strong suit, so I'm still trying to get a handle on how data is stored and how indexes, etc. actually work. Another topic I'd like to get more comfortable with is normalization. Right now I'm going back and forth between understanding and having to re-trace my thinking every time I consider normalizing a table. The third topic I could use improvement with is the idea of different joins. I feel very comfortable with some types of joins yet very unsure of how to use other efficiently.

Monday, May 13, 2024

CST 363 - Week 3

 1. Third normal form eliminates redundancies by eliminating columns that are dependent on non-key columns. For example, if you had a table representing restaurant pricing during happy hour that contained the item name, time of day, and price. The column representing price would be dependent on the column representing the time of day, but the prices could be repeated. Third normal form would eliminate the column of prices and would include a new table with columns for time and price. This is important because repeat data can lead to slower processing times and inconsistencies if all of the data isn't updated correctly.

2. A SQL view can also be called a virtual table. You are able to view information in the view similarly to how you would use an actual table. One major difference is that the data shown in database tables is actually stored in the system, whereas a view is dependent on the database tables that it queries from. It doesn't hold any data itself. Effectively, a view is a pre-determined query that allows complex queries to be more easily accessed. For example, when comparing data from different tables in a database, it may be easier to create a view to allow those data points to be more simply accessed.