I have the following tables in a relational database:
[Sensor]
LocationId [PK / FK -> Location]
SensorNo [PK]
[AnalogSensor]
LocationId [PK/FK -> Sens
The second option is also fraught with issues - e.g. for Sensors (and assuming that SensorNo is a surrogate key), because you don't have a base table, the SensorNo surrogate is either not unique between the sub class tables, unless you use a klugey mechanism to issue keys across all the sub-class tables (or use a guid).
This would be amplified if you had user interface which 'combines' different types of sensors, e.g. a list showing a union of Analog and Switch sensors.
I would recommend that you stay with your first pattern, and then encapsulate the insertion and maintenance of these tables with well tested, transactional code.
e.g. Create Insertion Procedures for the various SubTables, which insert the respective base and subclass records under a unit of work. You can go further by then revoking INSERT privileges on ANY of the tables thus forcing insertion via the SPROC's.
You could also run a daily integrity report which checked that there were no violations of your inheritance structure.