CST 363 Journal #4, Week #4

 Briefly summarize what you have learned in the course so far. List at least 5 things:

1) Learned proper teamwork. While working on Project #1, I learned how to split up tasks in a project properly and learn from others as well.

2) How to study more effectively. I am learning more and more how to allocate time to my homework so that I'm not stressed or under pressure at the last minute. Watching many videos online and soaking in the material has made me understand more the applications I am working with and give me more knowledge in the field.

3) Of course, learning the ropes of MySQL and database systems. When I was first doing the homework, it was difficult for me to learn certain concepts. Such as, joining many tables. I was wrestling with a homework assignment for a long time stuck on a certain problem, but when I got help I figured out right away the correct way to do joins. Then, after watching videos, taking notes, and getting help, I learned the correct way of how to code in MySQL workbench and use the tools I've learned to solve problems more effectively and easily. 

4) To attend office hours. I notice that if I need help, I should definitely go get it. When attending office hours, I have gained crucial help that made a difference in my journey with MySQL overall. 

5)Brief knowledge on using Spring with Eclipse and MySQL. I learned briefly through the lecture video in this week, week 4, how to utilize the framework Spring in coalition with Eclipse and MySQL and connecting to the Spring application. It was exciting to learn about application development in further detail through this video, and I look forward to using the concepts learned in the upcoming projects!

List at least 3 questions you  have about databases that have not been covered in the course so far:

1. How can I design and implement a database that can handle high traffic and scalability requirements?

2. What are the different database indexing techniques available, and how do they impact query performance?

3. How can I handle concurrency and ensure data consistency in a multi-user database environment?

CST 363 Journal #3, Week 3

1. Third normal form is a principle in database normalization. It builds on the principles of first and second normal form. A table, or relation, is considered to be in third normal form if it satisfies the following conditions:

    1. It is already in first and second normal form. This includes requirements such as having atomic            values, unique column names, rows being unique, no partial dependencies, and splitting tables into         separate tables if there happens to be partial dependencies.

    2. There are no transitive functional dependencies. This means no non-key attribute depends on                 another non-key attribute. 

There are so many reasons why third normal form is important. For one, it reduces data redundancy. If you have attributes depending on non-key attributes, updating rows in your data can become very redundant as it means replicating data over and over again. It is, essentially, less functional. The database design becomes simplified when 3NF is kept and databases can be well-structured. The query performance improves as well when 3NF is kept. Overall, it has so many benefits and creates more reliable database systems. 

2. A view is like a table but it's not a table. A view takes a selection of data but, unless indexed, it's not stored into the actual database. It is a "virtual table" whose contents are defined by a query. It is similar to a table in the way that both are database objects, as well as the fact that views can be used AS tables, even if they are virtual/logical tables that don't exist in an exact location. Some ways that tables and views are different are that, like said above, views are not stored while tables are, tables are used to store the data whereas views are used to extract data, tables execute a fast result whereas views generate a slow result, and lastly it is not an easy task to replace a table directly whereas it's easier to replace a view and recreate it whenever. 

CST 363 Journal #2, Week 2

1)There are many instances where tables could be joined on something other than keys. One example

would be joining two tables based on a common pattern in their column values. If you have two tables

and one has information about products and another has information about customers, you could join

these tables based on a matching keyword.

As an english sentence it would look something like: Join the table products to the table customers based on words from the description column matching words to the customer interests column.

In SQL, it would look like:

SELECT *

FROM products

JOIN customers

ON products.description LIKE '%' || customers.interests || '%';

The wild card % operator matches a common phrase or word with any text before or after the keyword.

2) Using SQL as a query language is interesting to use. I think it is relatively easy starting off, but as things get more complex in the language it gets messier to deal with. When translating from English to SQL what I find most challenging is just simply figuring out the right key words to use, or the right order of things. Before I got help from the TA Sabrina, I was very confused on how the joins worked but as she showed me through her own example it became more clear how I am to order the joins and use them. Now, as things get more complex, it is necessary I really learn the material so that it's not as challenging as it could be. 

CST 363 - Week 1, Journal #1

 1. Relational databases and spreadsheets have major differences that set them apart. Some of those important differences are as follows:

- Relational databases have tables that have a predefined structure, whereas spreadsheets are more flexible and can store data in a variety of formats. 

- Relational databases enforce data integrity such as with foreign keys. A foreign key, for instance, in one table *must* match the primary key in another table. There are also constraints that enforce data is within a specific range or format. On the other hand, spreadsheets rely on manual data entry and are more prone to errors or inconsistencies.

-Scalability: Relational databases are designed to handle large amounts of data and can easily scale as data volume increases, but with spreadsheets it is very difficult to handle data growth and they can become unwieldy. 

2. While using files may seem beneficial to store data, it can get very complicated as the size of the data grows. Also, the features of using a database are very beneficial such as collaboration on modifying data, the querying and analysis features, and security. 

3. What I want to learn in this course that will be useful in my future career is how to properly manage and understand the use of data storage, integration with software systems, and more. I desire to be a very well-rounded individual in learning everything I can, so that in my future career as a software engineer I can attack and address any kind of problem that arises.