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:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies