Adding a few actpity-tracking tables

Our WDTU organization is a profitable and productpe radio station. We track historical information about our advertisers, royalties owed, and listenership. We track the music that is played, the rates we charge for advertisements based on the time of day, and we provide a public service by broadcasting a variety of government and other public service announcements.

We aren't going to cover all these features and functions in the following detailed exercises. However, it's always good to have a complete view of the system on which we are working, even if we are only working on one or two components. In this case, the parts of the system not covered in detail in our exercises will be opportunities for you to extend your studies and practice on your own.

Any system development should start with a design document that completely spells out the goals and the functional design details. Neither system design nor project management will be covered in this book, but when we begin working on production projects, proper attention to both of these areas will be critical to success. Use of a proven project management methodology can make a project much more likely to be on time and within budget.

Based on the requirements our analysts have gpen us, we need to expand our application design. We started with a Radio Show table, one reference table (Radio Show Type), and pages for each of them. We earlier entered some test data and added a few additional fields to the Radio table (which we will not add to our pages here).

Now we will add a supplemental table, document (header and line) tables, plus a ledger (actpity history) table relating to Playlist actpities. Following this, we will also create some pages for our new data structures.

Our WDTU application will now include the following tables:

• Radio Show: A master list of all programs broadcast by our station.
• Radio Show Type: A reference list of possible types of radio shows.
• Playlist Header: A single instance of a Radio Show with child data in the form of playlist lines.
• Playlist Line: Each line represents one of a list of items and/or durations per Radio Show.
• Playlist Item Rate: A list of rates for items played during a show as determined by our advertising sales staff or the royalty organization we use.
• Radio Show Ledger: A detailed history of all the time spent and items played during the show with any related royalties owed or advertisement revenue expected.
• Listenership Ledger: A detailed history of estimated listenership provided by the ratings organization to which we subscribe.
• Publisher: A reference list of the publishers of content that we use. This will include music distributors, news wires, sports, and weather sources, as well as WDTU (we use material that we publish).

Remember, one purpose of this example system is for you to follow along in a hands-on basis in your own system. You may want to try different data structures and other object features. For example, you could add functionality to track volunteer actpity, perhaps even detailing the type of support the volunteers provide.

For the best learning experience, you should be creating each of these objects in your development system to learn by experimenting. During the course of these exercises, it will be good if you make some mistakes and see some new error messages. That's part of the learning experience. A test system is the best place to learn from mistakes with the minimum cost.