Reading Notes #3

Databases and the Entity Relationship Model in Database
I have used many different databases in my career as a student, from high school to the present. The wikipedia page on databases is very technical, and I don't understand all of the software terms, but I have a better understanding of a database having used one. Requiring both database programmers and administrators, it requires a staff to be created and maintained. The one aspect I hadn't realized was the number of different types of databases-- cloud databases, graph databases, and knowledge databases, to name a few. Databases also have three different types of architecture- internal, external, and conceptual. One of the issues with databases is security and controlling who can access the information in a database. This is most obvious in the ULS holdings available online... one must either be signed on to the Internet on a campus computer, or you have to authenticate yourself with your Pitt ID-- showing the database you have permission to enter the database. A database also requires a large amount of space to store all the information-- so a large harddrive or server, but there are many different options depending on your needs and budget. Reading this article about databases definitely shows me that I know very little about computers or programming!

Entity-relationship Model is a part of software engineering, and coming from a humanities background, I had never heard of it before. It is very helpful to see information visually, especially organizationally. The ER Model helps you to achieve this and to determine what the needs will be of your database. Built of "entities," each part of the database is separate and related to other parts in sets. In order to demonstrate these relationships, different shapes and lines signify different relationships, but there are many different versions of these diagramming notations.

Database Normalization Process
Phlonx gives a good introduction to the database normalization process using diagrams. The hardest part was memorizing those three normal forms!:

1. No repeating elements or groups of elements
2. No partial dependencies on a concatenated key
3. No dependencies on non-key attributes 

The first scenario is keeping track of invoices, a very applicable problem for businesses. An Excel document may work, but it isn't as efficient or as helpful as a database would be. However, I was never an Excel whiz, so this normalization process looks daunting. Despite the diagrams and pictures, I have a hard time understanding "atomicity" and other terms used, and I'm sure that fully understanding how to complete this task comes with hands-on experience. It looks so complicated! Even at the end, the author says that he is only scratching the surface of the topic! After reading this piece, I am definitely more appreciative of those databases and their developers who help me to find the information I need and quickly!