Tablas y Clases en el Diseño Orientado a Objetos

Duda en relación al diseño de tablas para aplicaciones en las que se utiliza POO y técnicas de herencia. Parto de la base de que las estructuras de datos están definidas en una base de datos relacional como puede ser MySQL, Access, etc. y no en una base de datos orientada a objetos. Supongamos un breve ejemplo para poder llegar a la cuestión: Se quiere realizar una aplicación para gestionar un club de fútbol donde se deberá almacenar información de varias personas: Jugadores, Técnicos (Entrenadores, Preparadores Físicos, etc.), Árbitros, Directivos y Socios. Se empieza diseñando una Clase Persona que contenga las propiedades típicas: Nombre, Apellido1, Apellido2, Fecha de Nacimiento, Sexo, etc. Y los métodos habituales (Leer, Añadir, Modificar, Borrar) Acto seguido se diseñan una serie de Clases para cada uno de los tipos de personas que vamos a utilizar en la aplicación heredando, todas ellas, las propiedades de la clase Persona e implementado nuevas propiedades específicas de la clase, por ejemplo: Jugadores: Propiedades Nuevas: Demarcación, Equipo Técnicos: Propiedades Nuevas: Titulación, Función Etc. Bien, aquí viene la duda sobre el diseño, ¿Cómo es más correcto definir las tablas de la base de datos?: Caso 1: Se diseña una única tabla que tiene todos los datos posibles de una persona y según en la clase en la que se abre esta tabla se rellenan unas u otras propiedades. Caso 2: Se diseña una tabla de personas con los campos correspondientes a las propiedades de la clase persona. Se diseña una tabla para cada una de las nuevas clases hijas de la clase persona y que tienen una relación de uno a uno con la clase persona. Es evidente que ambas soluciones presentan cada una distintas ventajas e inconvenientes, sin embargo el elegir un sistema u otro condiciona todas la programación posterior que se produzca sobre todo en el apartado de acceso a datos. Me interesa saber si existe una regla concreta para elegir un diseño u otro. Esta mismo problema se volverá a producir cuando estemos en una aplicación de gestión donde tendremos una clase Documento que puede tener varias clases derivadas como Pedido, Albarán y Factura, es importante saber si la regla que se recomiende para el caso anterior es aplicable a cualquier diseño de clases o cada problema puede tener distintas implementaciones en base de datos (Caso 1 o 2) según sus características. Ventajas de 1 tabla: Sencillez en los accesos a tablas cuando se hagan las operaciones E/S tanto para modificar como para listar los registros. Desventajas Que pasa cuando en la aplicación una misma persona puede pertenecer a varias clases distintas, por ejemplo un caso en un Club, en el cual su presidente (clase Directivos) es socio del club (Clase Socios) y además portero del primer equipo (Clase Jugadores). Si sólo hay una tabla de personas de alguna manera tendremos que distinguir a que clase o clases pertenece una persona, existen varias posibilidades: