Nothing wrong with a child table used by many other tables. In fact that's part of the point of a relational database. To avoid duplication of data. But you need to be careful about being too extreme about it, because it forces joins and joins in SQL mean CPU usage. There is a process in database design which should be followed to find the optimal design for your application.
An entity in one application may become a table in one application, but not in another.
It all depends on your application. In some applications only a single table is needed with a column to indicate the licence type. But if your application requires significantly different attributes for each licence type, so much so that they become different things, then separate tables might be a good idea.
I work in short term insurance and motor insurance is one of the products. We only store licence code(A1-motor cycle, B-car, B1-truck etc), licence issue date and expiry date and whether the licence is issued in the UK, EU or other country. These attributes are all on the driver table.
We only have a licence table which stores reference data for the licence codes.
I have seen some applications that take addresses to extremes. Each physical address is stored in a single table. Then a person is linked to that address in a PERSON_ADDRESS_HISTORY table. So you have a many-to-many relationship by sticking the PERSON_ADDRESS_HISTORY table between the PERSONS table and ADDRESSES table. I guess the advantage to this is that address details themselves only exist in place. This is all wonderful from a theoretical perspective, but a pain in the rear to implement in large OLTP databases, because its an extra join and when you don't really care where the person lived before, its more of a nuisance.
Of course, you come up with perfect design one day and the next day there is a better one.
