Ver Mensaje Individual
  #7 (permalink)  
Antiguo 10/07/2010, 17:50
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: Herencia de Tablas? (Que se recomienda para tablas similares?)

Cita:
Podrias mostrarme mejor como lo plantearias? armarias dos entidades? una Empresa y la otra Sucursal con los mismos atributos en cada una?
Porque en principio no se me ocurre que atributo diferencia a una casa central de una sucursal.
Por empezar, una empresa, aunque posea como atributo solamente un nombre o razón social, requiere existencia como tabla independiente en la base de datos por el sólo hecho de estar representando una entidad del sistema completamente distinta a una sucursal.
Ese sólo hecho ya justifica su presencia, ya que no existe una sucursal que dependa de otra sucursal, pero si existen sucursales que dependen o pertenecen a una empresa. En ese contexto no importa si una instancia de empresa posee mas atributos qu eel nombre, la dirección y su ID... Es necesaria para el modelado del sistema y de la base.
En el mundo real hay muchos atributos que pertenecen a una empresa y que son heredados por la sucursal, tales como CUIT, inscripción a los Ingresos Brutos, Razón Social, etc., y muchos otros que parecen repetirse, como la dirección. La diferencia fundamental entre la dirección de una Empresa y una Sucursal es que en la Empresa dirección jurídica y física pueden no coincidir, pero en la sucursal si.
Como tienen forzosamente atributos distintivos, son tablas distintas y entidades del modelo diferentes. El que no puedas recordar puntualmente de memoria qué atributos las diferencia, no quiere decir que no existan, sino que no están relevados en el análisis del sistema.

Resumiendo: Son dos tablas diferentes con una cardinalidad 1:N, por lo cual la sucursal hereda la ID de la Empresa.
Cita:
Se me ocurrió por ej. que un comercio podría tener mas de una dirección (tal vez si se puede acceder desde dos calles por ej. los supermercados con estacionamiento atras, o por ahi alguien que quiere aclarar que la direccion para hacer una consulta u otro tramite es en otro lado, o alguien que quiere poner una direccion alternativa, por ej. un profesional, no se).
Eso es un tema irrelevante. Los puntos de acceso físicos de una sucursal no componen direcciones de la misma. La dirección de una sucursal esta definida por su declaración ante el fisco y su habilitación ante el municipio. El resto son como mucho "oficinas" o "puntos de acceso " con habilitación, pero no son la dirección de la sucursal, y su registración puede coresponder a otro tipo de documentación que tiene que ver con la estructura física del bien mueble, no con la entidad Sucursal.

Cita:
Por otro lado, la direccion me quedaba con MUCHOS atributos como pudiste ver, y meterlos en la tabla "Comercios" a todos esos atributos me parecia una exageracion.
Lo estaré planteando mal?
Trata de llegar a los atributos mínimos necesarios: Calle, Numero, Barrio, Entre_Calle Altura_C1, Y_Calle, Altura_C2, Localidad, Provincia, Pais, etc.
Si tuviese muchos accesos, y esa situación fuese una constante de las sucursales, podrías analizar si necesitas una tabla de Accesos_A_Sucursal.

Cita:
El usuario (comerciante) entra, registra su comercio y cuando se le pide la direccion, le voy a mostrar las calles en una lista asi no escribe cualquier cosa.
Pero hay mucha gente que no pone Calle y Nro, sino que pone la interseccion, y hay mucha gente que pone las dos versiones, y otros que incluso ponen San Martin 123 (casi Alvear), esta situacion la contemple agregandole un campo "descripcion" a la tabla Direcciones (para que puedan poner mas texto, por ej: "es la puerta roja", "casi peatonal", etc.)
Pero como hago para permitir que pongan la Calle y el Numero y/o las dos calles?
Inicialmente se me habia ocurrido poner DENTRO de direcciones estos campos:
No mezcles las cosas: Esto no es un problema de la base de datos, sino de la aplicación. Es allí donde se resuelve, aunque para ello necesites consultar a la base de datos, por ejemplo, para poner listados de Ciudad, desde la cual puedes hacer un listado de calles, etc. El ehcho de obligar a los usuarios a poner las cosas en un cierto orden y en una forma precisa, es asunto de la aplicación.
Cita:
Porque aunque San Martin esta en muchos lados, en algunos es Bvd, en otros Av. en otros solo calle.
Y aunque este en varias localidades, me interesaba que este repetido el nombre y distinguido con la Localidad. Mi objetivo es que el usuario elija su Localidad y en una lista le aparezcan TODAS las calles de esa localidad.
Está mal igual?
Eso lo tienes que resolver, como dije, en la aplicación. La base sólo guarda datos ya validados. No tiene por qué hacer validaciones. Los lenguajes de programación tienen mñas capacidades para esa tarea.

Respecto de la implementación de la herencia, los gráficos que te pasé ya te lo expresan.
Una entidad hereda a otra cuando no tiene PK propia, sino que usa la de la entidad superior.
Si tuviesen un ID propio, o necesitasen otro atributo para definir su PK, sería una relación y no herencia...
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)