[pyar] [OT] Consulta implementacion de un grafo de categorias

[Rafael E. Ferrero]

El 6 de agosto de 2013 10:22, Pablo Ziliani <pablo en kultroom.com> escribió:

>  Hola Rafael,
>
> Evidentemente ya tuviste una respuesta satisfactoria. Igual no te escribo
> con una solución sino para plantearte la siguiente duda: ¿por qué
> categoría? empleador y proveedor no me parecen buenos ejemplos de categoría
> (mucho menos de tag), más bien lo que parece describir es una relación, con
> la empresa o al menos con la entrada en el directorio de contactos. Esa
> relación podría (o no) establecerse a través de terceras entidades, pagos,
> altas, facturas, remitos, ...
>
> En mi cabeza un contacto puede ser Médico, Farmacia, o Clínica pero si es
> proveedor, empleado o cliente no lo determina el mismo mecanismo que
> establece que algo es "rojo", "azul" o "verde" o si es "importante", de
> "trabajo", "personal", etc. Las posibles relaciones son un conjunto cerrado
> determinado de antemano (a diferencia de los tags o las categorías que
> pueden ser creados y borrados sin afectar demasiado al sistema).
>
> En fin, más que una duda terminó siendo una opinión de alguien
> probablemente poco calificado para emitirla :)
>
> Saludos,
> Pablo
>
>
> On 08/05/2013 10:17 AM, Rafael E. Ferrero wrote:
>
>  Buenas !!... Se me planteó hacer que a ciertas entidades de un modelo se
> le puedan asignar categorías. En principio serían categorías de la clase
> Contactos (de la empresa), planteamos que toda persona relacionada de una u
> otra manera por la empresa la cargamos como contacto (ya sea empleado,
> proveedor o cliente) a su vez algunos de estos contactos requieren
> información específica por lo que extendemos la clase contacto a por
> ejemplo Médico, Farmacia, entre otros.
>  Volviendo al tema de las categorías se me planteo que sobre un contacto
> se le puedan asignar categorias si es un proveedor se le asigne esa
> categoria, si es médico tambien se le asigne dicha categoria... el problema
> que surge es que entre las categorias hay ciertas restricciones, por
> ejemplo un contacto con la categoria de empleado no se le debe poder
> asignar la categoría de proveedor.
>  Se me ocurrió hacer un árbol NO binario donde un nodo puede tener más de
> un padre y más de un hijo pero no se me ocurre como aplicar estas
> restricciones de forma elegante.
>  Alguien tiene una punta por donde pueda investigar? o alguien ya lidió
> con esto y sabe de alguna librería donde obtener el algoritmo? (es para un
> sistema en Free Pascal pero ya me lo recorri a todo google y no encontré
> mucho... lo tendré que hacer yo)
>
> Gracias por el tiempo de antemano.
>
>  Saludos
>
>
>
>   --
> Rafael E. Ferrero
> Claro: (03562) 15514856
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.arhttp://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

Hola Pablo, si bien las respuestas anteriores me ayudaron en algo, la
implementación obviamente la termine ideando yo de acuerdo a mis
necesidades... networkx excede en muchísimo mis requerimientos y encima
tengo que implementarlo en Freepascal.

Por otro lado el hecho de que a un contacto de la empresa (y repito, no
solo los contactos sino, también, los documentos, etc) sean tratados como
categarías en un principio viene de acuerdo a los requerimientos que nos
fueron planteados.

Si bien, como decís vos, un cliente o un proveedor puede ser tal de acuerdo
a si le hice o me hizo una factura.

A ver si me explico mejor, tengo la clase madre de todas las personas
(fisicas y/o juridicas de la empresa) y la llamamos contactos  de la cual
heredan luego el resto de las clases y de la cual cada una cuenta con más
información:

Contactos
|||||_ Medicos
|||    ||_Especialistas
|||    |_Socios
|||__Empresas
|||__Farmacias
||__Clinicas
|___Titulares
       |_Adherentes

Así nomás podes ver que los medicos tienen todos los datos comunes de un
contacto, pero tambien tienen todos los datos de medicos, si es socio
tambien tendrá más información y si es especialista otra serie más.
Cómo médico debe ser unicamente proveedor, pero nada le impide ser cliente
(o sea titular de un plan)

Cada clase puede tener muchas categorias (por ejemplo los adherentes pueden
tener N categorias asociadas, que hoy hay algunas establecidas pero tal vez
mañana tengan otras por la misma dinamica de la ley quen nos regula (y esto
es solo la punta del iceberg), también es (sobre todo en los adherentes)
que si tienen X categoría no se le puede asignar la categoria Y.

Para simplificar la emisión de resúmenes que son muchos y variables,
decidimos que era más facil esforzarnos mas en tener una agrupacion de
categorias (o llamalo como quieras) para clasificar las entidades y luego
poder filtrar por ahí... si queres un listado o resumen de todas las
facturas emitidas a clientes empresas o clientes titulares o toda las
deudas con Proveedores Medicos o listar todas las deudas con Proveedores
Medicos que son a su vez Clientes Titulares y en base a ello obtener las
diferencias a favor o encontra, etc, etc, etc...

Por el momento me parece que puedo hacer así:


restricciones_categorias
                                                                    *
        *
                                                                    |
        |
                                                                    |
        |

1        1
Contactos 1------* categorias_contacto *------1 categorias 1------*
agrupaciones_categorias *------1 restriccion_intergrupos
                                                                    1

1
1     1
                                                                    |
        |

|      |
                                                                    |

|
|      |
                                                                    *

*
*     *

relaciones_categorias
restricciones_entregrupos


En restricciones_categorias tomo dos categorias, categoria1 es la que se
desea agregar, la categoria2 es la que debe o no debe estar entre las
categorias ya elegidas para la entidad, es decir si deseo agregar la
categoria titular, la categoria cliente debe estar en la lista de
categorias o bien si elijo la categoria empresa no debe tener la categoria
consumidor final.

En relacioens_Categorias solo tengo la relacion entre una categoria hija y
sus padres.

Las categorias pretendo poder agruparlas en conjuntos y que entre dicho
conjunto se cumplan condiciones logicas, es decir si pongo en un conjunto
las categorias de iva, las mismas tendran una condicion logica XOR ya que
no puede haber más de una de esas categorias elegidas.
A su vez un conjunto puede ser subconjunto de uno mayor y la relacion entre
estos conjuntos también tendrían una condicion logica, el ejemplo seria un
conjunto que tenga a la categoria consumidor final y al subconjunto
condiciones de iva, en este caso la IVA Responsable Inscripto estará en dos
grupos, en este caso la condicion de categorias dentro de cada grupo sería
XOR y entre los grupos seria OR ...

Es medio complicado explicarlo aca, pero espero que se entienda aunque sea
un poco, asi si estoy mal alguien me corrija, y si estoy bien tal vez a
alguien le sirve.

Saludos a todos que son unos GROSOS !! (no se imaginan todo lo que aprendí
leyendo mails por acá y en el chat)

-- 
Rafael E. Ferrero
Claro: (03562) 15514856
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130806/06230dbf/attachment.html>