CSUMB CS Online Learning Journal - Ryan

 This first week of CST334 was definitely a challenge. This class is about operating systems and works with Linux and C. I am not familiar with either of these pieces of software so I had to spend some time getting familiar with them. There were many supplemental tutorials provided and I found myself going through the material multiple times. I feel like I am beginning to grasp some of the concepts for operating systems but still have a lot to learn. This week I started to learn how to navigate in Linux and write code in C. I am finding that my experience with other languages such as Java is somewhat helping me to understand C. Many of the fundamental programming concepts are the same, like declaring variables or writing functions. I learned how to compile C code from the terminal and how to use tools like GDB to assist with code debugging. 

 For me this class was definitely a challenge and I feel I will need to revisit many of the concepts covered in this course. The three most important things I learned in this class is how to work with SQL, how to design a database using ERDs and implementing MongoDB in a real application.  I enjoyed learning about SQL because it is a different language from many of the languages I had seen before. It also seems to be one of the most common languages in use for working with database information. The ERD section of this class was also useful. I found that it really helped to start to develop a database and identify all of the important entities and define their relationships. This would prove useful as I moved on to the actual database creation because it was a matter of referencing the ERD and creating the appropriate components. MongoDB was a good experience and made working with a database in an application a lot more streamlined. I still need to practice and get familiar wit...

This week we learned how to implement a different type of database using MongoDB. For our group project this week we changes the SQL code to MongoDB code. Both of these database applications do a fine job of working with data and saving it to a database. I did find that MongoDB seemed more streamlined than working with SQL. With SQL there seemed to be more setup as in creating prepared statements, and then executing queries. With MongoDB it seemed like a good chunk of the code was abstracted away and this made for cleaner looking code at the call site. If I had to choose I would likely go with MongoDB as it seemed more approachable.

     This week was a real challenge for me, but I feel like this week I learned the most about how databases operate. I found it interesting to use a java application to communicate with the SQL workbench to query for data and add updates to the SQL Database. I imagine this is a very simplified version of how complex database programs work. I was also able to understand the programming a little more because the code we wrote mimicked what we would write to perform a query in SQL. I have attained a better understanding of how a database is often separate from the main program and APIs are used to create a bridge for the two pieces of software to communicate.     I am looking forward to next week where it appears we will be working with MongoDB. I have heard about this database API from some of the mobile app project tutorials I have completed previously. I think next week will give me a good foundation on how to use the database and possible incorporate it into s...

 This learning journal entry is in response to the following article: https://use-the-index-luke.com/sql/anatomy/slow-indexes Q: If indexes are supposed to speed up performance of query, what does the author mean by a slow index? In the article the author refers to a slow index as an index where the database traversing not only the index tree structure but also multiple leaf nodes to find all matches. What this means is that although indexes help the database close in on the requested data without having to look at every node, it can still be slow because it will need to follow multiple branches to ensure it finds all of the matching keys. With leaf nodes possibly having many matches the requested data can span across multiple blocks.  Slow indexes are a myth due to the mistaken belief that the index lookup only involves tree traversal when in reality is also involves following leaf node chains and fetching the table data where there is no limit to the amount of block access r...

 This weeks learning journal prompts are: 1.  Briefly summarize 5 things what you have learned in the course so far.   2. List at least 3 questions you still have about databases. 1. SQL - Learning how to use SQL was great for me. I had never previously used SQL and I found it to be a very approachable and simple programming language. I learned how to perform queries and build tables to organize data in a manner that was accessible and practical.    Entity Relationship Diagrams - These diagrams I found to be very useful in the initial build out of a database and helps create a visual representation of entities, their attributes and relationships. The ERD can also be used to generate the code required in SQL to model the ERD.   Database Design Process - The text and lectures provided some good guidelines on the process to create a database. I learned how to understand the database requirements by speaking with the end users and also the process of analy...

  Someone described normalization rule as  "a non-key column depends on the key, the whole key, and nothing but the key, so help me Codd."  Key refers a primary or other candidate key of a table.  If the key has multiple columns, then "whole key" means  all columns together and not just some part of the key.  Explain in your words what 3rd normal form is and why it is important. What is an SQL view.  How is it similar to a table? In what ways is it different? 1. From the research I conducted online, 3rd normal form is where a table is organized in such a way that there are no transitive relationships in this system. This means that the key and associated values of a table are directly related. For example, if you have a table with a course id (primary key), course title, instructor and salary in a table, the instructor and salary columns can be moved into a separate table because the instructor and salary are not dependent on the course id and title. 2...