Breaking Out of Access: The Pilgrimage of a Newbie Data Phreak!

My first database class is out of the way, and I am looking for greener pastures. An introduction to databases can be flat out grueling, if not downright hellish! You are entering a world of relationships between data, tables, attributes and a few other words that actually have meaning. Hmm, meaning, thats what I need in my life! Actually that is what I love about databases, words have definition and ambiguity is avoided at all costs. But therein lies the rub (yet again) between IT professionals and the 'other' people. IT professionals have to get these definitions and business processes nailed down, which is not to unlike nailing jello to a wall. Interesting thing about the database concept is that it really is a beautiful tapestry of meaning, where solid facts get nailed to esoteric ambiguity. Studying the database concept is philosophical, and mental, and while the database has its roots in hard factual knowledge there is something altogether quite delicious about it. Consider my recent exploit in my first database project.

So here is the introduction. A database is merely a compilation of data. Now that statement really doesn't mean a whole lot to us lay-people so let me tell a little story.My assignment for the class was to go out and find someone who may need a database, design and create it in MS Access. I will avoid the specifics about project management here and just try and stick with the facts.

My Father is retiring and is going to start a vineyard. He is in the medical field and we both have in common a love and interest in Mathematics and Science, particularly Statistics. He wants to track the production of his vineyards, as well as the growth of his vines over time etc, etc, etc, ad nauseum. So I offered to build a database for him, (using MS Access of course). He asked what a database was, I told him exactly what I said above, that a database was just a way of storing data. I was trying to avoid a conceptual conversation detailing E.F. Codd or C.J. Date terminology, however I found that I really wasnt giving my father a proper view of the depth of the relational database when he followed up with this question. "You mean its like electronic file cabinets?" I winced, "Uhhh, yaaa kinda like that...." My father then said, "Well, is it like a file cabinet or not?", I had to answer him now, "No actually its not like a file cabinet at all. Let's pretend that you want to start storing stuff, not any particular stuff, just stuff in general. Now we are going to build something very unique to store all this stuff, and because we want the most detailed storage facility in the world we are going to design and build it ourselves." "you with me?" My father nodded. "Ok, great. So what we do, is create a huge wall of individual drawers, not file drawers to hold many items, but rather a single little drawer to hold just ONE item,,,,," Dad interupted, "you mean like a single drawer to hold this ONE pen?" "Well actually,,," I said, "that is a good idea but to really build the storage facility we want, we need to take the pen apart and put the ink filler in one drawer, the spring in another drawer, the plunger in another drawer,,,and so one..." Dad says, "NO KIDDING?!" half amazed. "Yup, that is how the database kinda starts, what you dont realize is that we have to build about a thousand of those drawer-walls, and then connect the walls with a network of tubes so that we don't have to store that one single pen-part in another location." "Then whenever you want a pen, you just run an SQL statement, and the drawers start feeding the tubes, the output is directed to the form or report we want to see and the next thing you know you get in your hand a perfectly assembled pen. Provided of course we put the RIGHT kind of pen parts in the database!" I exhaled as if I had run a marathon.

In a certain vernacular I am sure what I told my Dad was accurate, in some academic circles though, I'm sure I condescended the concept a lot. But when you really think about it, if you had to really explain it, this is a good way to do it. However, there are some people you meet that arent happy with a 'pat' answer, and with the database concept there is no real pat answer, which is why a good database administrator is hard to find. When I talk about a good database administrator, I definitely am not talking about some guy/gal busily pushing data from one place to another using a strange and foreign SQL language, but rather, a good database person is one who knows how to shuffle ideas and concepts and can put concepts to facts and vice versa. This is something the IT profession lacks, not to say they dont exist, they just arn't in abundance. I was amazed to find that during my classes presentation of the end product, how most people avoided a discussion of the mental process they went through to end up with the database they displayed. They rather, just put the database through a projector which put it up on the wall, and they said, "Here is my database." They were shocked when the professor said, "Ya, that's great but how did you get there? How did you normalize? What method did you use to ensure your design reduces redundancy?" It took me three weeks to get that part out of the way. Sometimes the ends don't justify the means, and while you can get away with a lot in business circles (most don't care how its done as long as its done) the good database professional looks down the road after he/she is gone and thinks, "Is this the best way to go on this? Will my successors be able to make sense of all these tables?" So for them the 'pat' answer is not OK, nor does Ockham's razor bear down on the situation.

Staring out into the field where a vineyard might someday be, the sun set behind the trees on the beautiful side of Oklahoma, and my dad thought hard about what I had just told him. He looked at me and said, "Wow, that made a lot of sense!" Pleased with my success at explaining an IT concept to a non-IT person, I leaned back in my chair, stared at the sun-smitten horizon and finished my scotch. That is when my dad suddenly said, "What the hell is an SQL statement?!"

Popular White Paper On This Topic

1 Comments

Hi
Just stumbled over this article when searching information for an IT class in college to become an MBA.
If only our teacher had been able ,a year ago, to present his class on relational databases with that sort of "hollistic appetizer" I would not have found myself meandering in a foggy forest for the rest of the same year.
It is amazing how "professionals"spezialized in one topic are unable to remember their first steps.
Excuse all orthographic and grammar mistakes.I am German.
Margareta

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.

What challenges does a successful business manager face in transitioning to a career in IT? Follow this experienced Marketing ...
more

What challenges does a successful business manager face in transitioning to a career in IT? Follow this experienced Marketing Executive as he pursues a Master’s Degree in Information Technology, sharing his experiences, discoveries, and learnings as he navigates the challenging shift from the business world to the IT world.
less

Receive the latest blog posts:

Share Your Perspective

Share your professional knowledge and experience with peers. Start a blog on Toolbox for IT today!