Cita: y asi quedaria bien... pero necesitaria tener 300000 tablas dentro de una base de datos para poder manejar las relaciones que habria dentro de un sistema!:..
No.
Un sistema, como en el que actualmente trabajo, que administra la totalidad de ventas mayoristas, minoristas, cuentas, clientes de todo tipo imaginable, proveedores, facturación, sistemas de pagos, etc. de una entidad que opera a nivel nacional (de punta apunta del país) e incluso con operaciones internacionales y transacciones que aplican a acciones planetarias (y no exagero), administra su operación minorista comercial entera, con con... 622 tablas. Y la extendida (todo el sistema) involucra alrededor de 2.000 más.
Obviamente, estoy hablando del diseño de datos. No de servidores, ni estructuras administrativas o aplicaciones y demás.
Pero la dedicada a las personas jurídicas, impuestos, sistemas de pago, clientes y otras yerbas semejantes, son apenas unas 20, de las cuales media docena administran completamente el sistema de personas.
En tu caso, con dos tablas básicas, mas las tabla padre (que contiene los datos comunes), es suficiente.
Cita: A lo que voy entonces es... La integridad de datos tiene que quedar definida dentro de la base de datos?? (hablo sin pensar en procesos).... porque si es asi, entonces no se de que manera armar mi base de datos, y todo lo que he hecho estos años esta tirado por la ventana!...
Ya que no encuentro la manera de modelar mis datos en una base de datos relacional sin tener incoherencias como la siguiente:
Si tengo una tabla de vehiculos, y una tabla de tipos de vehiculos, en los tipos puede estar definido tanto un Camion, como una Bicicleta... Entonces en la tabla de vehiculos tengo un campo de cantidad de acoplados.... Si el registro es de tipo Camion, cantidad de acoplados va a ser 2 por ejemplo... pero si el registro de vehiculo, tiene relacionado un tipo Bicicleta... va a tener tambien un campo cantidad de acoplados que va a estar vacio!...
Si alguien viene, y manualmente pone un numero 3.... Ahora mi bicicleta tiene 3 acoplados !!!
Y ahi no veo ningun proceso, ni codigo, ni nada!
Más allá de que hay que analizar el sistema con definiciones tangibles de las reglas de negocio (sin lo cual no hay análisis que sirva), te estás ahogando en dedales de agua.
No lo estás pensando ni siquiera a nivel de objetos, entonces se te producen confusiones bastante simples.
Veamos así:
Un vehículo es cualquier unidad u objeto no biológica que pueda desplazarse una distancia X en un tiempo T, y transportar un peso P agregado a su propio peso.
El que tenga ruedas o hélice, o motor fuera de borda, es en primera instancia irrelevante.
Pero la existencia de diferentes tipos de medio en donde el vehículo se desplaza, nos habla de que hay "Clases" o "Categorías" de vehículos. Aire, agua o tierra.
Si lo afinas más, existe una subcategoría en VehiculoTierra que es la tipología: Camión, Auto, Motocicleta, Triciclo, Bicicleta, y si quieres ponemos las patinetas.
Pero por lo pronto, cuando diseñas un sistema no estás creando un sistema de uso universal, algo para que se ingrese cualquier cosa. Le pones restricciones que tienen que ver con las reglas de negocio, entonces si tienes un sistema de administración de taxis, jamás tendrás camiones, motocicletas o bicicletas. Nuca. Y eso se restringe de dos modos: 1) Existen entidades fijas que se usan para restringir el dominio de ciertos atributos de otras entidades. y 2) Esas mismas entidades se usan para alimentar a la aplicación tal que restrinja el ingreso de datos que no deben existir.
¿Se entiende?
Además, cuando analizas más fino aún, verás que si un remolque sólo puede pertenecer a un camión, y no a una bicicleta, la solución se cae de cajón: 1) Si es un remolque, sólo se puede relacionar con un vehículo de la subclase camión, y 2, el mismo camión no puede relacionarse más de una (o dos, según la categoría o modelo de camión) con un camión dado al mismo tiempo.
¿Se va entendiendo?
Este tipo de análisis no puede hacerse en el aire. Hay que escribirlo. Siempre. debe documentarse y definirse claramente cuáles son las reglas, para verificar qué condiciones deben cumplir los datos en la base, y qué requerimientos tendrá la aplicación y las clases controladoras al momento de diseñar las vistas donde estos datos entran o se procesan.
En otras palabras, esto no se soluciona desde un sólo lado, sino que debe hacerse desde ambos.
En la aplicación, los controladores y las entidades, y sus instanciaciones, permiten diseñar las restricciones claramente. En la estructura de datos, existen métodos y técnicas de normalización que permiten mantener la consistencia e integridad de los datos. Y esa integridad de datos debe ser protegida por la base, que siempre debe evitar que el programador intente cosas que no debe hacer.
¿Cómo?
Simple (y largo de hacer): Se usan stored procedures para revalidar lo validado y proteger la base.
No te olvides: Datos "sucios", implica siempre pérdida de información y desastres. Por eso, entre otras cosas, los analistas de datos somos tan estrictos: Protegemos el negocio.
Si nosotros fallamos, siendo la última defensa del sistema, el sistema se cae.