Database design too repetitive?

I'm working on a database schema that's driving me a little mad at the moment because I seem to be repeating the same tables to reproduce behaviour for different types.

Basically the system 开发者_C百科consists of live sensors that are monitored over a network, and loggers that are collected via a handset. The sensors and loggers are divided up into Locations, and Locations are divided up into Areas. A location can have up to 1 logger, but can have any number of live sensors.

I'll try and break the rules down:

1. The system can have 0 to many Areas

2. An area can have 0 to many Locations

3. A Location can have 0 to 1 Loggers

4. A Location can have 0 to many LiveAnalogSensors

5. A Location can have 0 to many LiveSwitchSensors

6. A Location can have 0 to many Actions allowed

7. A LiveAnalogSensor must belong to 1 LiveSensorRelay

8. A LiveSwitchSensor must belong to 1 LiveSensorRelay

9. A logger can have 0 to many Readings

10. A LiveAnalogSensor can have 0 to many Readings

11. A LiveSwitchSensor can have 0 to many Readings

12. A Reading can have an Alarm

13. The system can have 0 to many Actions

14. An Alarm can have 0 to 1 Action applied to it

15. An Alarm can have 0 to 1 AlarmResolution

The schema picture is HERE.

So the scenario is, a reading comes in and is stored (either via the Logger download or a live reading coming in over the network). The reading is out of range so it has an alarm code. An alarm gets generated for that reading. An action is eventually applied to it by the user. If a reading comes in that indicates the alarm condition has ended, an AlarmResolution (or AlarmEnd as I called it in the schema) entry is made linked to the Alarm to show that it has ended, and the time it has ended.

On analog alarms, whenever a new reading is higher than the last, a new "Peak" reading is stored, which is what the AnalogSensorReadingAlertPeak table is for.

That is basically it. My issue is how repetitive the schema seems for the different sensors (especially logger and analog-sensor which are basically the same) - and I seem to have a lot of 1 to 0..1 relationships, though I'm less concerned about that.

I'm after a sanity check really. I can think of ways to get rid of the repetitiveness, but it always seems to be at the expense of data integrity.

Thanks.

EDIT: I've revised the title and question slightly after the down vote as it wasn't particularly specific. I hope it's better now..

I'd say it's repetitive if each Sensor (for example) has exactly the same properties (columns). If they differ at all, they should have different tables.

I'd try capturing this using NORMA or similar too to validate the design.

I wouldn't worry too much about too many Zero-To-One relationships. I do worry about having Zero-To-One relationships in the first place. In the long run, these turn out to be One-to-Many relationships.

For me, there is nothing more confusing than that mess of an ER diagram that comes standard in many tools. I use an technique called "Levelized Conceptual Diagrams" to help make sense of my relationships.

You should make a Levelized Diagram - it will make your life really easy when it comes to database designs.

Hopefully I will make this easy - the One side is on the top, the many side on the bottom. Many to many get broken down to two One-to-Many tables.

Repeat until done.

Link to full image: http://i.stack.imgur.com/VKAGZ.jpg

In Oracle, an ARC describes mutually exclusive relationships to other tables. This concept can be implemented in other databases using nullable FK columns.

Depending on the functionality of the tables, you may choose to combine all *Readings or all *Alerts tables into a single table, having nullable foreign key columns to the respective Logger, AnalogSensor, and SwitchSensor tables.

As a consequence, the *AlertEnd and *AlertAction tables can also be combined (probably adding a Type column if required).

Optionally, add views for the three domains (Logger, AnalogSensor, and SwitchSensor) to simulate the original tables.

Why do you need tables with only PK fields? Can't you relate their children directly to their parents?

Also consider creating a limit table with two fields and a contextID key field, so instead of 2 tables with 4 limit fields each (2 upper and 2 lower limit fields,) have a new table with 3 fields and change your existing tables have 2 fields with FK relationships to the new one, with names like upperLimitContextID and lowerLimitContextID.

Also, since the action and end tables have the same PK, consider combining them. Any time there are tables with the same PK they can be combined.