The Entity Relation Diagram

I l @ ve RuBoard

If you've had any exposure to object-oriented programming, you're sure to have encountered entity relation diagrams (ERD) at some point. At its core , the ERD is a snapshot of all the players that make up an application and how those players relate to each other.

JAVA AND OOP

By its nature, there's no way you can program in Java without developing objects. After all, every Java program is really a class. But, as with any other tool, it can be used in a right way and a wrong way.

Most Java texts try to teach the basics of good object-oriented design, but if you come from a background of mainly developing applets, you might never have worked with more than one or two classes, or even objects. When you begin to develop large applications based on Java, you need to apply object-oriented methodologies to the project, or you'll end up with a mess.

This book tries to introduce and demonstrate good OO design techniques, but there's no replacement for a strong grounding in the technologies. I encourage anyone who is approaching this type of development without a background in OO to pick up a good book on the topic.

An ERD doesn't say anything about how an application works ”that is left to use cases. The ERD is concerned with only the units of information that make up the application and how they connect.

After you've developed the use cases and thought about how you want to implement the application, you transform the ERD into a static class diagram, which is similar to an ERD. In addition to documenting the contents of the objects, however, a static class diagram also documents what the objects do (or at least what methods they implement).

SPEAKING 00

A note about terminology use: In the industry, terms such as ERD, class diagram, and use case have very specific definitions with rules about how to draw the box and lines, what a dotted line means, and such. People make a lot of money writing books about how to make these beautiful diagrams. Specifically, the Unified Modeling Language (UML), which is really just a codification of a collection of tools for representing object-oriented design, has become an industry unto itself.

In my opinion, some people have begun to mistake the model for the thing that the model is supposed to represent. They get so hung up on doing a perfect UML design that they never really get going on the actual application until late in the game. The antithesis of this approach is the extreme programming model, which relies more on short development cycles with frequent customer feedback.

Tools such as UML do have their place. They have several advantages in large projects. For example, tools such as TogetherJ can automatically move between UML designs and actual code/database schemas. You can also be more confident that everyone is looking at the design in the same way.

Personally, I've never bothered a great deal with that degree of formalism; it strikes me as an exercise in getting good at something that's not really about getting the job done. When you see a diagram in this book and it doesn't look like the ones you see in the more formal books, just squint a bit and go for the meaning.

Before we begin an ERD for the Books for Geeks Web site, let's look at a simple ERD for a hypothetical object model of a car with people in it (see Figure 5.1).

Figure 5.1. A very simple ERD.

graphics/05fig01.gif

This rather basic example has two classes, Vehicle and Person . The Vehicle class has a single attribute, an array of Person objects called passengers . The Person class, in turn , has the person's last name, first name , and sex as attributes. The ERD lets you see graphically that the Vehicle class references the Person class through the Passenger attribute. These diagrams were developed using TogetherJ, one of the more popular Java OO tools. While TogetherJ will create Java skeletons and database schemas for you based on your designs, it was used in these examples only to draw diagrams. I'm still of the old school, and I like to do my design work in Emacs.

ERDs are a good way to begin to understand where the information in an application is stored and grouped. It also serves as a template for your database schema because objects usually map nearly one to one into database tables.

I l @ ve RuBoard


MySQL and JSP Web Applications. Data-Driven Programming Using Tomcat and MySQL
MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL
ISBN: 0672323095
EAN: 2147483647
Year: 2002
Pages: 203
Authors: James Turner

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net