Friday, February 24, 2017

CST 363 Week 8

CST 363 Week 8

The course at times was challenging. This was mostly due to the fact that I am working full time at a bank, have a 2 year old daughter, and am concurrently taking discrete math and computer architecture courses. It feels good to be done with the course. I went from having a basic understanding of what a database is to being able to write in SQL to create and manipulate databases. My team worked well together and we were able to finalize our project of creating a database a day before the due date.
Here is a sample of our database design.

This was a great introduction to databases and I feel like I have just scratched the surface of this field.

Tuesday, February 21, 2017

CST 363 Week 7

CST 363 Week 7

This week I learned about big data and the new forms of databases that are being implemented for them. I was able to learn about how data marts are used in data warehouses to help process large amounts of data for big corporations.
I also learned how OLAP is implemented to dynamically access data through the use of dimensions. A three dimensional OLAP report was examined.
With this knowledge I was able to create an OLAP report through Excel PivotTables. 
The different types of distributed databases was then explored. These include: 


I learned the difference between scale up (larger processor) vs. scale out(more servers). The No SQL movement and Hadoop were also explored.

Our group was able to complete the database design and add the data to the tables this week.

Tuesday, February 14, 2017

CST 363 Week 6

CST 363 Week 6

This week I learned about the basic concepts with regards to database security. I learned that permissions are managed using SQL Data Control Language statements GRANT and REVOKE. User accounts were explored and their relation to groups and objects. One very important aspect of database security is that permissions generally aren't assigned to individual users but are instead assigned to groups.
Next I was able to retain the basics behind DBMS security guidelines. They are as follows:
  • Run the DMBS behind a firewall
  • Apply the latest operating system and DBMS service packs and fixes
  • Limit DBMS functionality to needed features
  • Protect the computer that runs the DBMS
  • Manage accounts and passwords
  • Encryption of sensitive data transmitted across the network
  • Encryption of sensitive data stored in databases
In general DBMS security features should be used before application level security.
I learned about database recovery via rollback/ rollforward and how it is the preferred method of recovery. We were able to apply this concept through Assignment 11 in MySQL.
I also learned about how to apply user defined functions and triggers in a DBMS.

It would have been nice to spend  a bit more time exploring these concepts as I felt retention of this would come easier with practice but that is why I bought my own books so I may learn on my own.

Tuesday, February 7, 2017

CST 363 Week 5

CST 363 Week 5

This week I learned about how transactions and ACID properties are used in a DBMS. The acronym ACID stands for Atomic, Consistent, Isolation, and Durable. I learned about a logical unit of work within a transaction.

I then explored concurrency problems that can occur with multiple users updating a database concurrently. These problems include dirty reads, nonrepeatable reads, and phantom reads. It was then learned that locking is a way to avoid concurrency issues. I learned about the various isolation levels for locking and how to avoid a deadlock. These isolation levels in order of the weakest to strongest locking are Read Uncommitted, Read Committed, Repeatable Read, and Serializable. I also learned about the differences between optimistic and pessimistic locking.

SQL views were also explored this week. It was learned that this is a good way to create different views that may be used later within a DBMS. I learned about the properties of SQL views and how to implement the syntax for an SQL view in MySQL. Views may be used to hide data, hide complicated syntax, and ensuring consistent results from multiple developers working on a single database.