A. The requirement is to design a Database to keep track of Property Tax Appeals.

Email on Janary 26th. 2011
Hey Barry,

Thanks! I really appreciate the quick response!
The primary purpose of the database is to keep track of the necessary filing dates and
filings for each parcel for each year, while keeping it simple enough that the lawyers
(or their assistants) can add new data without too much trouble.

I apologize if I'm getting the nomenclature wrong, but it appears that this assumes a
unique ID for each PK.

In actuality, while some tables would lend themselves to using natural keys
(e.g., client number, parcel number), others do not (e.g., county ID, matter ID,
attorney ID- all of which would be repeated). Would it be appropriate to use
surrogate keys for all the PK's or is that some sort of database design faux pas?

Any chance I could get a snippet or two of sample SQL for creating the tables?

Again thanks!

January 20th. 2011
I have been asked by a colleague to design "a user-friendly multi-user database" that would allow him to
ditch the unwieldy excel spreadsheet he are currently using to track property tax appeals.

I accepted the challenge, despite the fact that I am neither a database designer nor programmer,
but am finding myself stumped at the normalization phase. The details are as follows:

Each "Client" has one or more "Matters" associated with it.
Each "Matter" has one or more "Parcels" associated with it.
Each "Parcel" has one or more "Years" associated with it.
Each "Appeal" is for a particular "Parcel" for a particular "Year" (which is related to a
particular "Matter" that is related to a particular "Client").

Each category has a variety of other information associated with it (e.g. Client_Name,
Matter_Attorney, Parcel_County, Year_AssessedValue, etc.).

For example, a particular Client could have two Matters, each Matter could have ten Parcels, and
each Parcel could have 3 Years. This results in 60 distinct Appeals that need to be tracked.

The purpose of all of this is to be able to generate reports, by Year, by Parcel, by Matter and
by Client not only for internal use (e.g., calendering purposes) but also to provide to the various clients.

I've spent a decent amount of time trying to educate myself about database design and normalization
and have taken several stabs at designing the database, but none of them feel "right" to me, so I'm
finally giving in and asking for help.

I would appreciate any and all thoughts and suggestions


A. The Things of Interest are :-
   A.1 Appeals
   A.2 Others, to be determined

B. How are they related ?
   B.1 Each "Client" has one or more "Matters" associated with it.
   B.2 Each "Matter" has one or more "Parcels" associated with it.
   B.3 Each "Parcel" has one or more "Years" associated with it.
   B.4 Each "Appeal" is for a particular "Parcel" for a particular "Year"



Barry Williams

January 22nd. 2011

Principal Consultant

Database Answers