Part of a monthly series of posts highlighting uncovered items of note, and the archival process brought to bear on these items, as we preserve, arrange, and describe the Roland Park Company Archives.
We all know the word “database.” We definitely, definitely know the word database. We know (and often rely on the fact) that our information is in databases: our credit card information, our consumer information, medical records, social security number, phone number, email address(es), driving records, insurance information, purchases, everything. When you call customer service anywhere to do anything, they are usually pulling you up in their database. When you log into a site that stores information on you, like Amazon or your cell phone provider (or every login website ever), the web interface is pulling its data from a database.
So databases are everywhere, and our digital world is one hundred percent reliant on them and the information they store for us. They’re pretty awesome, when they aren’t pretty scary. So why am I mentioning it?
Well, because I want to talk about how they work. One very important part of databases is that most are relational. That means that information stored in two different places (often called tables, within the database) can relate. To relate, they need a key. So hold on, I’ll explain.
If you have a bank account and a credit card with the same bank, you know that when you call you can ask the customer service person about either one. But how, exactly, does the database know that the two accounts are linked? This may seem obvious, but give it a thought. It’s because there’s a piece of information in common between the two, like the fact that you gave your social security number to open both accounts. Your SS# is the unique key that the database uses to know that the Holmes, Sherlock that opened the credit card is the same Holmes, Sherlock that has a bank account. The key (SS#) links them, thus the bank’s database is relational.
The image below is a partial screenshot from a real Access database displaying how the database understands the relationship I just described:
So what does this have to do with the Roland Park Company Records? It has a lot to do with them, and if you think you will ever be interested in using the records, then you most definitely need to read “A Paper Database Part 2: Decoding the Key to the Roland Park Records.”
But I’ll leave you with one thought: what if the link in the above graphic disappeared? What happens when there is no key?