Volume Number: 16 (2000)
Issue Number: 10
Column Tag: Navigation Services

How to Build an EOModel (or look just like one)

by Patrick Taylor and Sam Krishna

Back in 1996, there wasn't much competition for WebObjects. Nowadays however there are dozens of web application servers on the market, each promising that their package will make it oh-so-easy to publish data from your relational database to the World Wide Web.

If you picked some other web application server you generally had a choice of two solutions: tying yourself to a single vendor's database package (the "simple" solution) or embedding SQL into your page template (the not-so "simple" solution). If writing SQL is your idea of a fun Friday night or if you don't believe that object-oriented classes are a spectacular improvement over SQL., then you probably won't fully appreciate EOF's special charms. But even if you aren't 100% sold on the Enterprise Objects Framework, the sexy EOModeler application might still turn your head.

EOModeler, one of Apple's WebObjects development tools, provides you with a simple way to manage a great deal of the complexity associated with databases. EOModeler lets you graphically design your object/data model.

In EOModel, you replace some of your relational database terminology with object-oriented ones. However, the concepts map quite neatly.

EOEntity

An EOEntity represents an actual class in an object model, one which generally stands for a table in a database. Fundamentally, though, an EOEntity represents some piece of information or data that must be captured and represented in your application.

EOAttribute

An EOAttribute represents a column of data in a database table. EOEntities are composed of EOAttributes. An EOAttribute has two intrinsic data types: a class type and an external type. The class type represents the object type (like a java.lang.String or an NSString) that the attribute will be as an enterprise object's (EO) instance variable. The external type represents the kind of database type (like a VARCHAR) that the attribute will be stored as in the database.

EORelationship

An EORelationship represents a relationship between two EOEntities. There are two fundamental types of relationships: to-one and to-many. What this means is that an EO can have either a to-one relationship to a single EO of a particular type or a to-many relationship to potentially various EOs of a particular type. A few variations on both of these fundamental types exists: many-to-many (where an EO can have a relationship to many EOs of a different type, and EOs of the different type can have multiple relationships back to the original type of EOs), reflexive to-one (where an EO has a relationship back to another EO of the same type) and reflexive many-to-many (where an EO can have to-many relationships back to other EOs of the same type). We will only be covering regular to-one, to-many, and, of course, many-to-many relationships in this article.

EOEntities are Composed of EOAttributes and Connected to Other EOEntities Through EORelationships

EOModeler provides a Wizard that can generate an EOModel from a pre-existing database saving you from much of the effort of recreating an object model from scratch. How complete the object model representation of the underlying database is depends on the adaptor and the database, some adaptors like ODBC provide only basic information like entities and attributes, but not relationships or other database-specific features. You will need to manually modify the EOModel to provide the necessary missing features.

If you're familiar with Microsoft Access' graphical modeling tools, you will rather quickly pick up on the graphical modeling mode in EOModel. You aren't limited however to viewing data flows graphically, EOModeler provides developers with two other views: an outline view and a class browser view.You can view additional information about an EOEntity, EOAttribute or EORelationship with an Inspector.

One interesting thing about EOModeler is that it isn't a one-way only tool, it can generate SQL to create a database from an EOModel. For instance you could generate an EOModel from a MSAccess database and then generate the SQL necessary to recreate the database structure in Oracle 8i. Or you could design your object model from scratch in EOModeler and then using the SQL generator build a database structure. Through its adaptors, WebObjects/EOF provides developers with a remarkable degree of database independence.

An Example Application: ProjectManager

To truly understand EOModeler it helps to see it work in an application. ProjectManager, our example application, is intended to assist a Project Manager in allocating resources for the various projects that he or she manages in a company. One way of describing the entities would be:

• Employees
• Projects
• Departments
• Managers

Real-life Project Managers reading this article will see that we've simplified the number of entities that normally participate in a real project model. However, we can simplify this model even further when we realize that Manager is just a different type of employee and does not need to be its own entity. Further simplified the current set of entities are:

• Employees
• Projects
• Departments

Having identified the entities in this application, we need to make them usable within the ProjectManager object model. Entities are named using the singular form:

• Employee
• Project
• Department

Singular form is used in order to simplify and rationalize the naming of relationships. You will later need to use the plural form, so it's easier to name entities in singular form rather than try to figure out: "What is the plural form of 'Employees'?"

The next thing we do is create the entities in the EOModel. Generally, we have to define three things in order to create an EOEntity: the entity name, the table name, and the class name.

EOModeler's default behaviour is to assign any EOEntity's class name to EOGenericRecord, which is simply a data object that can be used to manipulate an EO's data without going to the trouble of defining a class or class behavior. In this case we'll give the Employee entity the class name Employee.

Common practice in EOModeling is to borrow the database convention of naming tables and columns with all upper case characters. While it isn't necessary to maintain the same names, the entity,table and class names are the same for this example.

Once we've finished filling out the required information for the EOEntity, we can start defining the EOAttributes we want to track in each EOEntity. In the Employee entity, we want to track certain things:

• First Name
• Last Name
• Employee Number
• Address
• Salary
• Department
• Manager
• Start Date
• Title

Here's how we model that information:

• firstName
• lastName
• employeeNumber
• employeeID
• streetAddressOne
• streetAddressTwo
• city
• state
• zipCode
• salary
• departmentID
• startDate
• title

You'll notice some things right off. First, the Attributes start off lower case but are intercapped since spaces aren't used between words.The names are descriptive to assist in recognition. You can name entities with acronyms or nonsensical names, but you're only punishing yourself. You'll also notice that there isn't always a one-to-one mapping between the identified items and the actual entity.

For our application, Address is more complex than what can be represented usefully in a single attribute - because of certain postal conventions, modeling it usefully requires that we use several smaller attributes, like streetAddressOne, streetAddressTwo, etc. (these address rules apply in the United States but may differ in other countries). You will also notice that the employee's department only appears as a departmentID. We have a departmentID instead of actual department attributes because in our application the employee's department information is actually a relationship that an Employee has with a Department. There are two reasons for choosing this: it conserves resources by storing an ID (32 or 64 bits long) rather than multiple potentially redundant entries (16 bits per Unicode character).

When you model a particular attribute, you need to define:

• attribute name
• attribute class value
• attribute external type
• attribute column name
• attribute width (if defining an attribute that tracks a string object)

We also define whether or not an attribute is a class property. Class properties are identified with a small diamond to the left hand side of the attribute name. When attributes are identified as class properties they can be manipulated in code. Attributes that are not marked as class properties are handled automatically by the EOF subsystem.

A word on class properties: any primary or foreign keys should not be marked as class properties (ie missing the small diamond). The EOF subsystem should manage any primary or foreign keys automatically. This way a lot of the magic of EOF is used to deal with key generation with the database.

After all the attributes are defined the EOEntity should look like this:

EORelationships

EORelationships represent relationships from one EO to another EO (or groups of EOs). There are two fundamental types of relationships: to-one and to-many. Since our mythical company only assigns employees to a single department, Employee should have a to-one relationship to Department.

Our mythical company has multiple employees in each department so Department will have an inverse to-many relationship back to Employee.

Department and Project entities must track the following types of information:

• name
• budget

• name
• clientName

Here are pictures of the fully modeled Department and Project entities without relationships:

Employees aren't limited to working on a single project and each project will tend to have several employees assigned to it. Because of this we need to create a more complex type of relationship between Project and Employee than those we've discussed. The type of relationship that represents these complex systems is called a "many-to-many" relationship. Unlike to-One and to-Many relationships, Many-to-Many relationships can't be represented just by an EORelationship.

What is required to create a Many-to-Many relationships is a 'Join Entity'. A Join Entity is a special type of EOEntity that links two entities to each other in a many-to-many relationship. The Join Entity stores the Primary Keys for each of the two joined entities. Following common practice, we'll name the join entity EmployeeProject to show its place in the relationship between Employee and Project.

EmployeeProject will only have two attributes and two relationships. The two attributes will be employeeID and projectID, respectively. The two relationships will be named employee and project, respectively. Here is what the fully modeled EmployeeProject join entity looks like:

ShortCut!

There is a shortcut in EOModeler which simplifies the creation of many-to-many relationships. Here are the steps to the shortcut:

• Select the two entities you wish to join
• Select from the Properties menu, 'Join in Many-to-Many relationship' or select the Many-to-Many icon on the toolbar.

After the Join Entity has been created, you will need to fill in the table name and the attributes' column names. It will look something like this:

Once modeling is complete, here is a diagram of what your model should look like with entities, attributes, and relationships:

You have now built an object-relational model without writing a single line of code. No SQL was needed and, for the most part, you could use any database you wanted. The database portion is often the most difficult and painful part of the development process.