Campeonato APT : la nueva base de datos APT

[astrologix]

Por si a alguno de vosotros le interesa el tema de las bases de datos relacionales, os pongo el diagrama de entidades-relaciones que he elaborado en el marco de una base Access para la gestión de los pitboss APT.

La idea es organizar los datos de manera a permitir en el futuro no sólo saber los resultados de cada pitboss, sino también poder hacer estadísticas varias y cuestionar la base con "querys" interesantes, por ejemplo saber para un jugador dado con qué rasgos de líderes se le dan mejor las partidas, o bien, en qué mangas ha sido tercero, etc, etc. El único límite es la imaginación.

Mi próximo paso será hacer lo mismo, pero con una base MySQL accesible por internet en una web dedicada. Pero para ello tengo que aprender un poquito más los secretos del PHP. Y me tengo que alquilar un espacio web en algún servidor.


(hacer clic para agrandar)

[jm_ruiz]

[jasev]

Si necesitas una manita con PHP+MySQL, dame un toque.

[Percebaal]

Ahi va que chulo Astro!!!

Hay que ver como te lo curras, sin ti esto no sería lo mismo, te mereces un 10!!!

[koningtiger]

Muy chulo Astro, cuando tengas datos si me los pasas, podría hacer algunos gráficos muy chulos con Qlikview, una herramienta de BI con la que desarrollo.

[quiquejavi]

La "milk"!!!
Eres una fiera del Access querido amigo...

[Magno]

e pectacutar
un pitboss tienen N "participante", que es esto? porque no es la clave Id_Pit* Id_Lid*?
Seria mejor no tener un Id_part que no aporta nada. Y mejor tener a igual semantica, igual nomencaltura. Asi tener por un lado Id_pit y por otro Id_Pitboss. Y por un lado tener Id_libder y por otro Id_Lid.
Por el bien de tu salud mental cuando comiences a sacar consultas, usa las mismas nomenclaturas para atributos que son lo mismo.


Ahora bien. un pitboss tiene N lideres. Fijos. CAda lider es ocupado por sucesivos jugadores. Supongo que ahi entra la entidad "papel"


Pero los atributos Titular, equipo, sustituto, remplazante se sobreponen en semantica y la combinacion de valores en estos atributos te llevaria a inconsistencias.
Te recomiento agrupar semantica en un atributo que sea "Clase" que pueda tener los valores
Titular/Suplente/Remplazante

A este le agregaria un par de atributos de desde y hasta cuando fue el suplente.

[astrologix]

Pato, me alegro que lo hayas examinado Veo que eres del oficio

La entidad Participante es auxiliar. Participante en tanto que lider en la partida (no jugador, sino máquina). Sólo para resolver la relación N:M entre el pitboss y los líderes que lo componen (EDIT : un mismo líder-máquina puede participar en varios pitboss). Access no permite, que yo sepa, concatenar identificantes.

En el otro cabo, hay una relación N:M entre jugador y líder. Por eso como bien dices está la entidad Papel.

No veo como se pueden llegar a inconsistencias con esos atributos. Piensa que un jugador puede ser titular en una partida con el lider A y si es eliminado, luego puede ser sustituto (o reemplazante) con el lider B, en la misma partida. Por ello esos atributos están en la entidad Papel, que es la que liga al jugador con el lider (y con un pitboss dado). Renuncié a meter los plazos desde y hasta cuando, etc. por ser ya una microgestión fastidiosa. Si fuera necesario, para control, la haré en una hoja Excel aparte. EDIT : Los atributos Titular, Sustituto, etc, son de tipo SI/NO.

En cuanto a confundir identificantes, para Access no hay problema, ya que gestiona dinámicamente las relaciones, que no hay que escribir en SQL. Las consultas se construyen por "drag and drop". Pero es cierto que faltó rigor para llamarlos de la misma manera

Quedó claro ?

[Dreyius]

Joder que maquina! como os lo currais. A mi todo esto me suena a chino, que soy industrial no informatico . Pero la verdad suena genial!

[Magno]

asique Acceso no permite claves compuesas.. que ostia


y bueno, con 5 tablas y 40 atributos te puedes dar el lujo de ser un poco tolerante en la nomenclatura.. pero cuando andas con sistemas de 700 tablas y 8000 atributos no


bueno, pero regresando a la entidad "papel"

qeue pasa si tienes que Magno juega un Pitboss X con una civ Y

tendrias el regstro

Magno, X,Y S, , N,N, , ,

o sea, es el titular

y luego llaga Astro a darme una mano y me suplanta

Astro, X,Y, N, , S, N, , ,

no?

pero que significaria si tenes

Astro, X,Y, S, , S, S, , ,

es semanticamente inconsisitente
si usaras un atributo Clase con los valores T/S/R no podrias tener inconsistencias al menos ahi


no?

[astrologix]

Originally posted by Magno_uy


pero que significaria si tenes

Astro, X,Y, S, , S, S, , ,

es semanticamente inconsisitente
si usaras un atributo Clase con los valores T/S/R no podrias tener inconsistencias al menos ahi


no?

Esa combinación es posible si cometes errores manuales en la entrada de datos, es cierto. Normalmente, sólo un S es posible, los otros estarían a N, a no ser que te equivoques o que haya excepciones (que te describo en el párrafo siguiente). Pero vamos, eso es improbable, ya que hay pocos datos que entrar. Y el error se vería rapidamente.

Por otro lado, el atributo Clase no sería enteramente satisfactorio, ya que en una partida un jugador podría pasar del estatuto Sustituto al de Reemplazante, si el Titular abandona. O incluso podría pasar a Equipo, si los dos jugadores deciden compartir todo en un momento dado. Interesa tener la posibilidad de reflejar esos cambios en un solo registro.

Como bien dices, si se tratase de una BD gigantesca, esas libertades serían fuentes de errores y no se podrían tolerar, pero aqui los registros serán pocos por año y los tendré muy vigilados.

Agradezco mucho tus reflexiones, de repente dejé de sentirme sólo

[astrologix]

Originally posted by Magno_uy
asique Acceso no permite claves compuesas.. que ostia

Bueno, aclaro que estoy usando Access 2000. No sé si alguna versión posterior aporta mejoras en ese sentido.

[Magno]

ha si.. todo se puede arreglar con programación!!

pero la experiencia indica que un buen diseño de base, te ahorrara miles de lineas de codigo.. y miles de lineas menos, son decenas de bugs en testeo y decenas de bugs menos en testeo, son varios errores en produccion menos..
y un error en producción, puede ser un cliente menos


pero bueno.. ahi seremos muy tolerante ante esos posibles errores

[astrologix]

Para entrar los primeros datos de Gaya, me construí unas pantallas que evitan tener que entrar numeritos en los registros, ya que puse asistentes que facilitan el trabajo.

Hay dos pantallas:
a) para rellenar la tabla Participante
b) para rellenar Papel

Y luego, conforme vayan llegando las mangas, utilizaré la pantalla siguiente :




Ya he hecho ensayos con los Pitboss Isla y Esfinge, y funciona de maravilla

[X_MiTH_X]

Yo me medio entero, pero no acabo de pillarlo completamente.

También creo que pienso como Magno. ¿Porqué no llamas a los campos iguales de la misma manera en las distintas tablas? Yo prefiero tener que meter en la consulta de que tabla obtengo el campo a llamar de forma diferente los campos en cada tabla cuando hablan de lo mismo.


También puedo echar manos con el PHP si es necesario.