Clases y Tablas - Por qué no son lo mismo.

Clases y Tablas, Por qué no son lo mismo.


Siempre le insistido a quienes me leen en el Blog (o grupo de Yii en Español) que no es lo mismo "Tabla" que "Clase", sin embargo a veces recibo respuestas de algunas personas que se molestan y defienden a ciegas aquella idea de que "son lo mismo".

Normalmente siempre empiezo por insistir que: "No es lo mismo crear una Arquitectura de Clases, que crear Una Clase con 500 métodos", en este último caso, luciendose de haber hecho un programa de 20.000 lineas que solo él y dios sabrán como funciona.  Por contraparte, la Arquitectura de Clases es delicada, es toda una dama.

Es incorrecto pensar que una Clase, por el hecho de tener atributos igual que una Tabla es entonces inmediatamente "emparejable con una tabla de base de datos". Es un terrible concepto arraigado por la falta de análisis y por el hecho de programar a ciegas.

La Clase es la "idea" maestra, el concepto, mientras que la "tablita de base de datos" es solo una artimaña tosca para guardar la información de la clase.  De aqui que siempre digo que es un error diseñar un sistema pensando en el modelo de base de datos (el diagrama de tablas, el diagrama de entidad-relación).

No siempre una clase es almacenada en una "tabla"

No siempre una "tabla" representa a la Clase, No siempre una tabla representa a una Relación y finalmente no siempre una tabla representa a una Entidad.

Cuales son las diferencias entre Clases de Asociación y Entidades. Concepto.

Caso de Ejemplo de Diseño UML:
Antes de explicar mas abajo necesito que tengas claro este ejemplo de caso de negocio, para que comprendas mejor el diagrama que está mas abajo y los conceptos de Clase-Entidad y Clase-de-Asociación.

"Una persona quiere laborar como agente de ventas para una empresa de RealtyRentals, se le denomina El Agente (primer sustantivo detectado en la conversación). Para poder laborar en la empresa, este Agente necesita adquirir un Plan (segundo sustantivo), este Plan se le cobra mensualmente y le permite realizar ciertas operaciones de acuerdo a su pago (no detallaré qué y cómo, no viene al caso, sino enredamos el ejemplo).  Adicionalmente, este Agente querrá publicar información en su propio website privado, por lo tanto le daremos una LLave de Acceso (tercer sustantivo) para que a través de ella pueda leer recursos web en su propio website.  Esta Llave de Acceso se paga también mensualmente pero separado del pago del Plan de membresía"

Una Clase-Entidad representa a una Entidad, a un objeto Real
Se reconocen por ser un SUSTANTIVO en las conversación con el cliente. De ahí el hecho de que el análisis UML haga énfasis en anotar cuales sustantivos usa el cliente durante su conversación contigo como analista. Por ejemplo: El Agente. Es una clase-entidad porque representa a un ser humano operando como agente de ventas en un negocio. El arte de UML está en saber oir: cuales sustantivos son una real basura y cuales son valiosos.

Una Clase de Asociación. 
Es también una clase, pero enfocada a relacionar dos Clases-Entidad.  Representa la forma en cómo dos objetos se relacionan. Por ejemplo, informa de la relación que ocurrirá cuando el Agente seleccione un Plan.  Ambos Agente y Plan son Clases-Entidades, mientras que La Relación sería: "La historia de Planes adquiridos por El Agente en el Tiempo y Soportados por un Pago"....no adivinaste? "EL INVOICE".

Una Clase de Asociación tiene un diagrama UML específico.
Se representa así como muestro aca abajo: una linea punteada terminando en  flecha que apunta a la linea recta entre las dos entidades a ser relacionadas, indicando que: "La factura guarda la relacion entre las entiadades: el Plan y el Pago".

La relación XY

Siempre hago referencia a que un diagrama XY (la relación XY) que incluye clases-entidad y clases-de-asociación se llama: "Relación XY", porque XY representa la asociación entre la clase X y la Y.

Explicando el Diagrama de Clases



La clase-entidad "AgentPayment" se relaciona con otra clase-entidad "AgentPlan" mediante la clase de asociación: "AgentPlanInvoice".  AgentPayment es independiente es un pago, es único, igual que AgentPlan, son clases simples, que representan una entidad.

AgentPlanInvoice informa cómo estas dos se relacionan (el pago a un plan), no es un objeto "físico" como las primeras, sino es un paso en el tiempo.  AgentPlanInvoice es una Factura que le damos al Agente por querer contratar el AgentPlan seleccionado, esa factura le da acceso por tiempo limitado a usar el sistema.

Verás que también tenemos ResourceKeyInvoice, que según el requisto del cliente (arriba) le da derecho al agente de tener una "llave de recursos web" para que pueda insertar contenido web en el propio website del Agente.

Extensión de Clases

El objeto de mostrar esta extensión aquí es demostrar que no siempre una "Clase" se almacena igual que una  "Tabla".

La extensión aquí se requiere porque AgentPlanInvoice y ResourceKeyInvoice derivan o extienden su funcionalidad de una clase abstracta llamada Invoice que agrupa cosas comunes entre estas, es abstracta porque no puede usarse así "a rin pelao"...(yo soy un invoice !!!,  de quien ? de que tipo ?).

El Invoice (La Factura) le provee a sus clases extendidas la funcionalidad e incluso atributos, podriamos tener en esta clase base (Invoice) un método llamado: "sendByEmail()" el cual enviará este invoice al Agente por correo, sea "de clase" ResourceKey o "de clase" AgentPlan. El símbolo UML para denotar la extensión es la flecha con cabeza blanca sólida.

¿ Cómo almacenar las clases en un modelo de datos ?

He aquí el guiso. Y He aquí porqué siempre digo que hacer el sistema empezando el diagrama de datos es siempre un error que viene de vieja escuela y de fundamentos teóricos oxidados y mal formados, en su mayoría hecho asi por comodidad y por el hecho de no profundizar en el Análisis de Sistemas.

AgentPlanInvoice y ResourcePlanInvoice estan diagramados en dos clases distintas, eso lleva a pensar al diseñador de software que deben ir en dos "tablas" separadas.....de nuevo...esta malo. Una cosa es: Diagramado UML, diagramado de Negocio, otra "diagramado de datos".

En este ejemplo no se requieren dos "tablas" separadas para almacenar a AgentPlanInvoice y ResourceKeyInvoice, sino solo una.  Esto demuestra la razón de mi insistencia. Podrias almacenar AMBAS CLASES en una sola tabla asi:

"AgentInvoice" { agentId, invoiceType,  invoiceNumber, invoiceTotal, expirationDate, creationDate }

Ahora, será tarea de la clase base Invoice, leer un registro de LA TABLA "AgentInvoice" y entregar en consecuencia un objeto de clase AgentPlanInvoice o de ResourceKeyInvoice, según indique el registro de base de datos.

Ahora te habrás dado cuenta que aunque el diagrama UML habla de tres clases (Invoice, AgentPlanInvoice y ResourceKeyInvoice) estas se almacenan en una sola, y no las tres, sino solo dos, ya que Invoice es abstracta.

"El análisis produndo de software es el camino al buen software"