oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Applying "Digital Hub" Concepts to Enterprise Software Design, Part 2

by Adam Behringer

In my previous article, I described a scenario where teams of scientists and students would collaborate around some common weather data. We have been tasked with building a software system that allows them all to perform their unique jobs with this set of data. Let's design and create a database that will store the weather data as it is recorded.

Before we dive in, let's think about our design options. If you are not a database administrator or designer, you might be tempted to think of a database as if it were a spreadsheet. After all, database tables have rows and columns, right? If we were to design our database with this paradigm in mind, we might build just one table that contains a column for each type of weather data; perhaps a column for recording the temperature and a column for wind speed. We might also want to collect things like the date of the entry and the name of the scientist who entered the data, so we would create a column for them, too. This type of database is pretty simple to build, and that is what makes it so tempting.

Close your eyes and imagine what will happen if we went down the road with this simple one table design.

Related Reading

Cocoa in a Nutshell
A Desktop Quick Reference
By Michael Beam, James Duncan Davidson

You would probably design and build the database in record time. Everyone in the office would cheer and want to take you to lunch. Development would start immediately on all kinds of cool applications that use the database as a hub. So far, so good. Right? Well doom lurks around the corner. You heard right. Doom!

Six months down the road, thousands of weather samples have been entered into the database and the whole team is deeply focussed on their respective jobs. One of the scientists is about to make a major leap forward in the field of weather prediction! She just needs one little thing. (Uh oh.) Her theory is based on the connection between temperature and atmospheric pressure, but the database is not tracking atmospheric pressure. This new piece of data needs to be collected, stored in the database, and analyzed for all measurements going forward.

Now what are you going to do? It is not as simple as adding an extra field to the table. All of the components that interface with the database will need to be updated, tested, and deployed all over again. And you better make backups, because changing tables in a database full of information sounds risky. At best, things are going to be down for a while, and you are going to have to deal with versioning issues between software, XML, and database schemas. Yuck!

Luckily, you can make decisions today that will avoid your future doom. Instead of hard-coding the measurement types as columns in the database, we will create a table that stores the descriptions of each types as data, not hard-coding it in the schema.

In fact, we will build three tables. The first will hold a list of basic data types that our client applications should know how to validate, such as integer, decimal, and string. The second table will hold measurement types with labels such as temperature, wind speed, and precipitation. Each measurement type will link to a data type. For instance, a temperature could be stored as a decimal number. In other words, the definition of the temperature type would link to the decimal number type. Finally, our third table will store the actual measurements. Each piece of measurement data will have a measurement type associated with it.

With this three-table schema, we will be able to add new measurement types on the fly. We can design our XML and client applications with the same degree of flexibility, which is exactly what we will do in future articles.

Building the Database!

Install xCode, WebObjects, and OpenBase

Before we get started, you will have to make sure that you have the required software on your Macintosh. Though the concepts should be applicable on any platform, this tutorial is based on Apple's Xcode and WebObjects, as well as the OpenBase database. You can get free or trial versions of all three applications from the companies that make them (follow the links). Follow the manufacturers' instructions to download and install each of them, and then we will continue with the tutorial.

First create a new database:

  1. Launch OpenBaseManager. You can find it on your hard drive in /Applications/OpenBase/.
  2. Install a demo license if you have not done that yet.
  3. Click the icon named Local on the left side of the window.
  4. Choose New Database in the Action menu.
  5. Name the new database Weather and click Create.
  6. A window of preference settings for your new database will appear. Make sure that Start Database at Boot is selected and then close the window, saving your changes when prompted.
  1. Highlight your new database by clicking on its name. Then choose Start Database in the action menu. Alternatively, you could press the play button next to your database. The little globe next to the database name will turn green when your database is running.
  2. Quit OpenBaseManager (the database will continue to run in the background).

Create an EOModel

There are many tools you can use to build a database, but since we are going to use WebObjects on this project, we will use EOModeler. EOModeler is an application that ships as part of WebObjects and is used to map a database to Java Objects. Conveniently, if we design a database schema in EOModeler, it can generate the SQL code to build the actual database for us.

Here are the steps to creating a new model:
  1. Launch EOModeler. If you have installed xCode and WebObjects correctly, you can find it in /Developer/Applications/.
  2. Create a new model by choosing New in the Model menu.
  3. You will be asked to select a database adaptor. Choose JDBC and click Next.
  4. The next window allows you to tell the model how to connect to your database. Since we have not created a name or password for our database, all you need to enter is the URL and click OK. The URL is jdbc:openbase://localhost/Weather.
  1. The rest of the options can be left to their default values, so click Finish.
  2. Save your EOModel with the name Weather.

Next, we are going to create the tables discussed in the introduction and implement our design in EOModeler, which is creating a description of the database that we will then use to build the actual database. We're going to go quickly through the steps of creating a model. For more detail on using EOModeler, see Apple's excellent WebObjects documentation on their developer web site.

Instructions for creating entities (entities in EOModeler represent tables in the database):
  1. With your model open in EOModeler, choose Add Entity from the Property menu.
  2. The Entity should show up in the left frame of the window as a child node to Weather. Select it and choose Inspector from the Tools menu in order to show the options available for this Entity.
  3. Type DataType for the name and DATA_TYPE for the table name. You can leave the class set to the default value of EOGenericRecord.
  1. Add an another entity with the name MeasurementType and table name of MEASUREMENT_TYPE.
  2. Add the last entity with a name of MeasuredData and a table name of MEASURED_DATA.
  3. Your EOModel should look like this:

Pages: 1, 2, 3

Next Pagearrow