The most applicable and clear example of a database system I can think of from personal experience is UCLA’s Degree Audit Reporting System (DARS). DARS is “a document that evaluates your progress toward meeting UCLA graduation requirements in your major. The system is “a critical tool you will use to select classes and plot your academic course” (admission.ucla.edu). From much first-hand experience, DARS is definitely a well-configured database system that presumably includes all four of the components Kroenke lists within his definition of database systems in Database Concepts; the database, database management system (DBMS), database application, and users.
The database, a “self-describing collection of related records” (13), of DARS contains every course at UCLA. The specifications are most likely refined into tables labeled something like “Undergraduate General Education Courses”, “Lower Division Major Courses”, “Upper Division Major Courses”, etc. These are the bits of data that are pulled to create the audit report.
The most complicated element of any database system, the database management system is a conglomerate of “related tables” and other configurations of the system. The DBMS is a complex computer program that “receives requested encoded in SQL (Structured Query Language) and translates those requests into actions on the database” (12). I was not surprised to learn that the companies that use database systems almost never write the DBMS programs. They are almost always outsourced to an outside software vendor. Therefore, UCLA most likely did not write its own DBMS program. I looked into finding out what company the university used to create DARS’s DBMS, but was unsuccessful.
Next, the application program has three functions within itself. First, it creates and processes forms. Next, the application program processes user queries – meaning it responds to a user who needs to find a piece of information. Lastly, the program formats the found results of the user’s request as a report (16). This process of the application program is very clear-cut in regards to DARS. As a student user, I inquire about my current progress with my courses. I click a few options, including my expected graduation date, major, and minor and nearly immediately am presented with a formatted report. It is clear that the application program is calling upon the related tables within the DBMS to determine what I have and have not completed thus far in my enrollment at UCLA.
Lastly, as the user, I am the final component of this database system. What is the point in making such a complex system? It seems so simple as I enter a few requisites that I sometimes take for granted how calculated and detailed DARS really is. Sure, one could make a list of all the courses at UCLA and simply check off which of the ones I have completed. However, in order to supply me with correct information, DARS employs much more contingent data, i.e. the courses I need to complete my major, minor, etc. Kroenke concludes his overview of database systems by explaining why we have database systems anyway, “The purpose of a database is to help people keep track of things. Lists can be used for this purpose, but it a list involved more than one topic, problems occur when data are inserted, updated, or deleted” (19). I cannot imagine how difficult it would be to keep track of my progress (including inserting completed courses, updating my minor, etc.) without the advent of a database like DARS.