Ejemplo de Mapeo de una Clase a una Entidad Relación

Voy a mostrarles el modelaje de un objeto o clase y su mapeo a un modelo de entidad relación. Este aspecto en el modelaje de sistemas de información es muy importante entender, principalmente cuando queremos hacer una separación entre lo que es el modelo lógico del software y el modelo físico.
En el desarrollo de un sistema de información partimos de objetos reales como fuentes de información, por ejemplo: formularios, informes, kardex, cuadernillos, facturas, recibos, comprobantes, etc. etc., todas estas fuentes de información para el relevamiento de necesidades o requerimientos no están normalizados en almacenamientos o tablas como en un modelo fisico de base de datos, por lo tanto requieren de un tratamiento de conversión denominado Mapeo.
Partamos de un formulario de Pedido de Materiales para una empresa cualquiera:

Este formulario es un objeto de la vida real, puede ser un formulario preimpreso, ahora lo que corresponde es definirlo como una CLASE y esta clase va a necesitar un nombre y sus atributos, para ello vamos a usar un Diccionario de Datos, una herramienta super simple de gran utilidad para modelar información, entonces tenemos lo siguiente:

Como podemos ver, en el DD de la clase usamos los símbolos que nos indican que hay un segmento de elementos de datos que iteran correspondientes al detalle del pedido.

Bien, hasta ahí es parte de un modelo lógico, pero lo que necesitamos es convertirlo en un modelo de implementación o modelo físico que entienda la computadora, entonces lo que hacemos es Mapear la clase a E-R., como sigue a continuación:

Como podemos ver, una clase denominada Pedidos se ha convertido en nueve (9) Tablas Relacionales del modelo de la Base de Datos, tendríamos las tablas: Pedidos, Detalle_pedidos, Solicitantes, Areas, Ctas, Almacenes, Firmas, Materiales y Unidades de Medida. Ahora estas nueve tablas resultantes las diagramamos en un Diagrama E-R, como sigue:

Este proceso tan elemental es un aspecto a que a muchas personas que son muy desarrolladores (programadores) les cuesta entender, en la vida real en el mundo real las cosas (objetos) no estan normalizados y los que son muy técnicos parten justamente al revés, es decir empiezan a definir sus tablas directamente, incluso inventándose los atributos y sin considerar formalmente las reglas de normalización, grave error porque tarde o temprano tendrán problemas en sus modelos de datos. Entiendo que muchas personas, ya sea porque son muy expertas en desarrollo o simplemente por flojera o en algunos caso porque no saben, NO quieren hacer una normalización formal, pero hacerlo les aseguro que les dará una BD muy sólida.