Liborio Revilla Alonso libo.revilla @ ehu.es IKT Gerenteordetza. Vicegerencia TIC GT-SCHEMA Cómo modelar las relaciones en un directorio

Liborio Revilla Alonso

libo.revilla @ ehu.es

IKT Gerenteordetza . Vicegerencia TIC

GT-SCHEMA Cómo modelar las relaciones en un directorio

2

GTSCHEMA

Tenemos a las personas en el directorio

Tenemos a TODAS las personas en el directorio

Y están todas juntas (misma rama)

Pero, ¿como podemos responder a estas dos preguntas?

1.- ¿qué somos?2.- ¿donde estamos?

IKT Gerenteordetza Vicegerencia TIC

3

GTSCHEMA

¿Qué somos?Caso fácil

eduPersonAffiliateeduPersonPrimaryAffiliate

• faculty = pdi• staff = pas• student = alumno• member = de la casa• affiliate = externo


4

GTSCHEMA

Ventajas

es estandar

Desventajas

no nos sirve en el 100% de los casos


5

GTSCHEMA

¿donde estamos?

Una persona está relacionada con la universidad de varias maneras:

Donde está localizada (centro) A qué departamento pertenece A qué servicio Qué titulación cursa Qué puesto ocupa en la RPT de la universidad Qué asignaturas estudia Que asignaturas imparte

Además

Todo se puede organizar de forma jerárquica

No son todas obligatorias

Puede haber más


6

GTSCHEMA

Clasificación 1 (Geográfica)campus 1 – centro 1campus 1 – centro 2campus 2 – centro 1

Clasificación 2 (Departamentos)departamento 1departamento 2

Clasificación 3 (Servicios)servicio 1servicio 2

Etc.


7

GTSCHEMA

Clasificación 1a1b1a1b2 a2b1

Clasificación 2a1a2

Clasificación 3a1a2

Etc.


8

GTSCHEMA

En el directorio creamos una rama para guardar las clasificaciones y, dentro de ella, una por cada

clasificación

• dc=uni,dc=es– idnc=clasif,dc=uni,dc=es

• idnc=geog, idnc=clasif,dc=uni,dc=es• idnc=deptos, idnc=clasif,dc=uni,dc=es• idnc=servicios, idnc=clasif,dc=uni,dc=es• idnc=titulacion, idnc=clasif,dc=uni,dc=es• idnc=rpt, idnc=clasif,dc=uni,dc=es• idnc=matricula, idnc=clasif,dc=uni,dc=es• idnc=docencia, idnc=clasif,dc=uni,dc=es


9

GTSCHEMA

Ahora, dentro de cada rama hay que rellenarla con la información propia de la universidad.

Por ejemplo:

dn= CopaAreaCode=a1,idnc=geog,idnc=clasif,dc=uni,dc=es

CopaAreaCode= a1

CopaCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a1

CopaName=Gipuzkoa

Description= Gipuzkoa

dn= CopaAreaCode=a1b2,idnc=geog,idnc=clasif,dc=uni,dc=es

CopaAreaCode= a1b2

CopaCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a1b2

CopaName=Facultad de Derecho

Description= Facultad de Derecho


10

GTSCHEMA

Y a cada usuario se le añade tanto valores como tenga que tener (no todos los usuarios tienen de todo)

Por ejemplo:

dn=uid=ika001,ou=people,dc=uni,dc=escn=apellido1 apellido2, nombresn=apellido1 apellido2givenName=nombreeduPersonAffiliation=studenteduPersonAffiliation=facultyeduPersonAffiliation=staffirisclassifcode=urn:mace:rediris:uni.es:clasif:geog:version:valor_códigoirisclassifcode=urn:mace:rediris:uni.es:clasif:dpto:version:valor_códigoirisclassifcode=urn:mace:rediris:uni.es:clasif:servicio:version:valor_códigoirisclassifcode=urn:mace:rediris:uni.es:clasif:titulacion:version:valor_códigoirisclassifcode=urn:mace:rediris:uni.es:clasif:rpt:version:valor_códigoirisclassifcode=urn:mace:rediris:uni.es:clasif:matricula:version:valor_códigoirisclassifcode=urn:mace:rediris:uni.es:clasif:docencia:version:valor_código


11

GTSCHEMA

Y ya está.

En este momento ya tenemos en el directorio todo lo necesario para poder responder a las preguntas de:

qué relación tiene con la universidad donde está

Fin, ¿fin?

Pero...


12

GTSCHEMA

¿Qué pasa con las personas que tienen doble adscripción a la universidad?

Cuando una persona es pas y pdi a la vez (por ejemplo) tendrá una clasificación geográfica por pas y otra por

pdi.

Y, con lo que hemos comentado hasta ahora, no podemos asociar “qué es” con “dónde está”

Esta idea es importante.


13

GTSCHEMA

Posibles soluciones

1.- No hacer nada

Puede que no nos importe separar esa información ya que no existe ningún servicio que lo necesite

Por ejemplo,¿es necesario que se separen los números de teléfono cuando se realiza una búsqueda?¿y en el caso de listas de distribución dinámicas?

Ventajas: No hay que hacer nada

Inconvenientes: No podemos saber si la pertenencia a un estamento está relacionada con un centro u otro.


14

GTSCHEMA

Posibles soluciones

2.- Una cuenta por cada relación

Va en contra de la filosofía de que, en el directorio, una persona tiene una identidad única.

Ventajas: Cada relación es como si fuera una persona distinta

Inconvenientes: Esto es una aberración, nos da más problemas que ventajas (todos los datos -nombre, apellidos, ...- tienen que ser iguales en todas las cuentas)

Es una idea a proscribir


15

GTSCHEMA

Posibles soluciones

3.- Usar sufijos en irisClassifCode

Ejemplo:

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode;x-aff-PAS=urn:mace:rediris.es:uni.es:clasif:geog:version:a1b2c1irisClassifCode;x-aff-PDI=urn:mace:rediris.es:uni.es:clasif:geog:version:a2b1c3d1

Ventajas:si se necesita la separación, se coge el sufijo.Y si no se necesita, se coge el atributo sin el sufijo.

Inconvenientes:no todos los servidores de directorio pueden entender estos sufijoshabría que “unificar” los sufijos (castellano, inglés, euskera, ...)


16

GTSCHEMA

Posibles soluciones

4.- El nombre de la clasificación incluya el estamento

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:PAS:geog:version:a1b2c1irisClassifCode=urn:mace:rediris.es:uni.es:clasif:PDI:geog:version:a2b1c3d1

Ventajas:Podemos tener varias relaciones de cualquier tipo

Inconvenientes:Añadimos un nivel más y duplicamos los árboles (no todos)


17

GTSCHEMA

Posibles soluciones

5.- El estamento es la hoja final del código copa

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a1b2c1d1irisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a2b1c3d1e2

Ventajas: Tenemos un árbol por clasificación. Solo se añade un nivel más.

Inconvenientes:No todos los árboles tiene las mismas ramas al mismo nivel, por lo que puede no ser sencillo saber el estamento de un usuario


18

GTSCHEMA

Posibles soluciones

6.- Tener clasificaciones duplicadas, una por cada relacion

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:PAS_geog:version:a1b2c1irisClassifCode=urn:mace:rediris.es:uni.es:clasif:PDI_geog:version:a2b1c3d1

Ventaja:es sencillo de entender

Problema:hay que mantener varios árboles iguales


19

GTSCHEMA

Posibles soluciones

7.- En vez de tener un código copa, tener un conjunto de valores

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:centro:version:a1b2;depto:ver

sion:a2b7c23;....

Ventaja:En el valor de un atributo tenemos toda la información

Problema:No es sencillo obtener los datos de los usuarios, además de extraer la información del urn, hay que procesar la parte final (INS), que es un conjunto de tuplas separados por el carácter “;”.Su mantenimiento no es sencillo (añadir, borrar o modificar alguno de los componentes del atributo)


20

GTSCHEMA

Posibles soluciones

8.- Tener varios urn en el mismo atributo

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a1b2c1;urn:mac

e:rediris.es:uni.es:clasif:depto:version:a2b1c3d1

Ventaja:Simila al caso anterior. En un atributo tenemos todo.

Problema:Es complejo de procesar. Una vez obtenido el valor del atributo, hay que extraer los diferentes urn de los que está compuesto.Mantenimiento difícil.


21

GTSCHEMA

Posibles soluciones

9.- Utilizar subentradas

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=es dn=idnc=pas,uid=usuario_conflictivo,ou=people,dc=uni,dc=es

irisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a1b2c1

dn=idnc=pdi,uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a2b1c3d1

Ventaja:Es una solución muy clara, cada relación y todo lo necesario que haya que separar, están en un objeto independiente

Problema:Multiplicamos el número de objetos en el directorioNo siempre se puede obtener, de forma sencilla, los datos de las subentradas¿Qué hacemos con los usuarios que sólo tienen una relación?


22

GTSCHEMA

Posibles soluciones

10.- Olvidarnos del directorio y, de alguna manera, consultar la BD corporativa

Ventaja: Es fácil, no hacemos nada en el directorio

Problema:Hay que montar un directorio virtual para que cuando se consulte por la localización de un usuario pasemos como parámetro la relación y solo nos devuelva la localización para esa relación.Vamos que hay que programarlo y puede no ser sencillo.


23

GTSCHEMA

Posibles soluciones

11.- Usar “sillas” para todos los usuarios

dn= uid=usuario_conflictivo,ou=people,dc=uni,dc=esirisClassifCode=urn:mace:rediris.es:uni.es:clasif:silla:version:silla12irisClassifCode=urn:mace:rediris.es:uni.es:clasif:silla:version:silla45

dn= idnc=silla12,ou=sillas,dc=uni,dc=eseduPersonAffiliation=staffirisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a1b2c1

dn= idnc=silla45,ou=sillas,dc=uni,dc=eseduPersonAffiliation=facultyirisClassifCode=urn:mace:rediris.es:uni.es:clasif:geog:version:a2b1c3d1

Ventaja: Tenemos todo lo que se necesita

Problema: Hay que tener claro las “sillas” que hay que tener. Además, para obtener un dato hay que hacer una consulta más al directorio.


24

GTSCHEMA

Posibles soluciones

Tenemos 11 posible soluciones• ¿Cuál es la mejor?• ¿Cuál es la más fácil?• ¿Cuál es la más universal?

Por concretar:

En la EHU tenemos una mezcla de la 1 y de la 2.


25

¿Dudas?¿Preguntas?

¿Todo ha quedado claro?

GTSCHEMAIKT Gerenteordetza Vicegerencia TIC

libo.revilla @ ehu.es

IKT Gerentordetza – Vicegerencia TICGipuzkoako IISIG – CIDIR Gipuzkoa

Documents

Liborio Revilla Alonso libo.revilla @ ehu.es IKT Gerenteordetza. Vicegerencia TIC GT-SCHEMA Cómo modelar las relaciones en un directorio