---
title: "Tablas y Clases en el Diseño Orientado a Objetos"
date: 2008-05-03
author: "Alex Borrás"
source: https://alexborras.com/tablas-y-clases-en-el-diseno-orientado-a-objetos/
site: "El Blog de Alex Borrás"
---

# 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: