Database Concepts

Database Concepts

Database Concepts

Mishel Bueller

DBM/380

Sean Kern

April 24, 2005

Databases have been in existence forever in one format or another; whether we are referring to a notebook containing information on a record collection or a card catalog file system in a library. The introduction of the computer brought about faster ways to collect, organize, store, and retrieve data. While database design and implementation has varied over the years, the purpose has not.

Databases come in two flavors: operational and analytical with the prior being the most common. We interact with operational databases regularly. Some examples include: Automated Teller Machines and Point of Sale systems. The data within an operational database is frequently changed or manipulated and is said to be dynamic.

Analytical databases are generally used to study “The Big Picture.” Data is taken from operational databases for long-term study of a specified topic. Since data does not change very often in an analytical database, the data is referred to as static. The knowledge afforded by analytical databases can lead to more informed decisions being made. Some examples of information obtained from analytical databases include: crime rates in a given neighborhood for a several year period, and drop-out rates of college students in programming classes.

A database model is a theoretical blueprint for building a database; much like the OSI model acts as a blueprint for building applications that will operate over a network. The basic concept behind both models is that when the process is followed all the way through, the end result will usually work properly.

The first well-known database model was the hierarchical model. Stemming from the 1950’s, this model used what is known as parent/child relationships to link tables in which data was stored. The hierarchical model had only one base and navigation was difficult. Lack of support for many to many relationships often led to redundant data followed by inaccurate information because the redundant data was not synchronized when changes occurred.

The network database model was designed to improve on the short-comings of the hierarchical model. The intent of providing support for many to many relationships was there, though still far from perfect. According to James Martin, “The enormous cost of seemingly trivial changes has held back application development seriously.” (1976 p. 64)

In 1970 “The relational model developed out of the work by E. F. Codd…” (http://wwwdb.web.cern) Based entirely upon mathematics, data could be accessed through coordinates rather than branches. Linking data using keys enabled it to be synchronically changed and provided a high