Dave Irvine returns with his series on Access development. In this article, David steps back to discuss some of the underlying concepts of database design. David applies a system analyst’s approach to data design that you might find more useful than some of the more abstract methodologies currently in use.
Part 1 / Part 2
Thinking back on my college days, I remember when my first course on database theory used a text that began, “To define a database, we must first define reality.” I almost blew that course! However, there’s some truth to the statement. Databases are collections of information used to solve real problems, and are models of real items and objects. Data is used to describe the world around us. A company has employees; the database has an employee table. Employee Dave Irvine gets a raise (I like that!); the salaries table is adjusted to reflect that raise. To understand what a database is, and how to use it as a tool to solve real-life problems, you must first understand what the problem is and the environment, or the world, that the problem lives in.
While Access itself is a development product, developers need to think about much more than writing code. When working with clients, it’s crucial to understand the requirements for the application before writing code. In this article, Mike looks at some of the fundamentals of requirements management for the Access developer.
Let me start with a true story from my own consulting history. I won’t tell you who the client was (my lawyer would frown on that, since he had to get involved in extricating us from the situation), but this was well after I was established in the Access field as a trainer, writer, and developer. Along with a couple of other coders, I signed on to do a major job for a mid-sized (about 100 employees) manufacturing company. What they wanted seemed fairly simple: a bill of materials database, with links back to their accounting system, to let them track the custom work they were doing for various clients of their own. The company’s vice president was pretty savvy about PCs himself and had decided that Access was the language of choice for this project.
In this series of articles, David walks through the process of creating a complete Access application. While the application itself is a valuable tool in a developer’s toolkit, David will concentrate in each article on using some feature of Microsoft Access.
Start The Series Here: An Access Project, Part 1: Requirements
When I was a kid, I loved to build models (actually, I still do). I always found it great to take a bunch of plastic pieces and end up with a finished product that looked (hopefully) like an item from real life. Data modeling for my Access applications provides me with the same satisfaction. In a nutshell, data modeling is the design of the informational components of the database — that is, the tables, the relationships, and so forth. Like my more physical modeling, data modeling is the act of taking the pieces (the data items) and putting them together in a way that reflects reality.
In this series of articles, David Irvine walks through the process of creating a complete Access application. While the application itself is a valuable tool in a developer’s toolkit, David will concentrate in each article on using some feature of Microsoft Access.
When I was approached to do this series of articles, I was intrigued. I had discussed the possibilities of doing a one- or two-piece set on developing a real-world application. I wanted to illustrate the ease with which MS Access can be interfaced with other Microsoft products. From that beginning, though, the project has expanded into a series where I will look at a practical application from the requirements phase, through design and development, and on to final release.
I’d like to talk about something that you all know: the real systems development cycle. This is significantly different from the cycle discussed in most systems design books.
All projects begin with a kick-off. This can range from a visit to your cubicle by your manager to a major meeting where managers sign off on some budget document. At the kick-off (or shortly thereafter), a set of dates is published, listing the milestones for the project and when they’re to be achieved.