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.
In part 1, Glenn Lloyd started outlining his approach to data modeling. This month, he finishes his discussion of the rules that ensure that your database will actually work after you’ve built it.
Last month I had developed a data model based on one of my client’s needs. The point of the article wasn’t to show off that particular database but, instead, to show how to start with your users’ requirements and end up with a data model. The next step is to go from the data model to an actual database.
Thorough, thoughtful, and accurate data modeling should be the starting point of detailed database design. But a surprising number of developers have little or no understanding of data modeling and shy away from what sounds like a non-profitable and time-consuming task. Glenn Lloyd looks at the typical design pitfalls that trap Access beginners and shows the basic techniques that ensure success.
My call came from a community service organization that provides specialized services both locally and remotely across the vast expanse of Northern Ontario. They were unable to solve a problem with their Access database – a problem that was both embarrassing and damaging to their relations with their membership (and to the community at large). Several months earlier, one of their key members had died. Now, despite their best efforts, his widow and the other organizations with which he had been associated were still receiving their periodic mailings addressed to him. As I listened to the story, I realized that the problem indicated a faulty database design. The staff that had developed the database had no training or understanding of relational design principles and rationale. What they had known was how they wanted to see their data laid out in reports and had designed a data structure that matched those report layouts.