Week 4 Reading Notes

Entity Relationship Model (wikipedia)

We covered entity relationship models last semester in LIS 2005, Understanding Information. This article was a good refresher about conceptual databases and conceptual modelling. I remember the different pieces (or shapes, if you will) with the ideas also suggested in the reading. Specifically, that "entities" mimic "nouns," "relationships" mimic "verbs," and finally, that "attributes" are "descriptors."

While reading this article, I was struck with the idea that most of these conceptual models, like the entity relationship model, are used at the beginning of a process, before a database even exists. The idea is that it's a sketch, to see how things could possibly relate. I'm curious about the way that bottom up design would work in an entity relationship model, particularly in something like social tagging or a folksonomy.  There, the relationshp are somewhat arbitrary, or at least harder to pin down because they are derivative of what many individuals thought about the "entities" in question. I wonder if there have been any parallels between user created systems and established database systems of organizations? I think it could be a fascinating project to make organizational sense out of the "system" of others, especially if that system was able to grow and expand.
The limits of creating a bottom up conceptual model, I guess, are that it would be outdated the moment someone added a new entity, attribute, or relationship to the organizational scheme on which the conceptual model was based.

Still, it's worth a thought!

Database Normalization

Normal forms of database information and the relationship created between entities looks like a precise art. Looking at the first tables of invoices, I could make sense of what the information was and what it was trying to convey. Each normal form made it a little clearer while also more confusing. At the end of the reading, when the parts were broken into clearly delineated entities and relationships, it seemed so clear that the representation of different parts was the way that the invoice information should be organized. I don't think I would have gotten to that stage on my own. As it was, I had to read and re-read the information several times to make sense of it.

I think the concatenated primary forms are the most difficult to make sure that there is no overlap, and that they are not violating the second normal form. It was also interesting to look at the differences between how the normalizing process stripped away a recognizable system of organizing information, like an invoice, into very distinct parts. I think it will take some practice to be able to think with the normal forms.

Database (wikipedia)

I feel like databases are as ubiquitous in our lives as the air we breathe. The gist that I'm getting from our readings and classwork is that databases, management, and creation are the underpinnings of 21st century western civilization. There are so many parts and pieces that compose a database, however, that sometimes it's challenging to really wrap my head around what's what. I think it's also sometimes challenging for me to understand the nuances of different parts because my brain has yet to fully absorb the information and create new manners of thinking and understanding. I traditionally have been very people oriented, working more with groups and individuals in real time, and less with abstract concepts and data. Once I make the connections and proper correlations, I am sure that I will have a better grasp, but I don't think I transcend my role as an end user. I will have a better appreciation for the developers, administrators, and for the often unnoticed presence of databases in every day life.