Diagrames Entitat-Relació en web


[ScreenShot]

Si algun cop vos heu vist en la necessitat de dissenyar i mantenir una base de dades relacional, sabreu lo important que és una bona documentació de tot el procés de disseny, des del model Entitat-Relació fins al codi SQL final. I sobretot lo molt que costa mantenir aquesta documentació al dia cada cop que fem modificacions a la base de dades i, molt especialment en projectes de programari lliure.

Existeixen diverses eines gràfiques que permeten representar el model Entitat-Relació d’una base de dades. Algunes d’elles fins i tot poden, amb major o menor encert, generar-nos el model relacional a partir del diagrama E-R. Totes estan molt be per models petits com la típica biblioteca o sistema de lloguer de pel·lícules. Però quan es tracta de projectes més complexos, representar el model de dades d’una manera llegible resulta cada cop més difícil. I les modificacions i ampliacionss son cada cop més costoses.

Dividir els esquemes en blocs més petits pot ajudar a facilitar la comprensió, però multiplica la feina i en dificulta l’estudi. Al final, cansat de tantes (f)eines gràfiques, he optat per implementar-me la meva pròpia solució. I crec que el resultat ha valgut la pena 🙂


(Versión en castellano(1))

Índex:

  • Per als impacients.
  • Origen de la idea.
  • Instal·lació.
  • Com generar els diagrames.
  • Funcionalitats futures.
  • Com col·laborar.
  • Per als impacients:
    Per als impacients aqui teniu un parell de screenshots:

    (2)
    (3)
    (4)
    (5)
    (6)

    …O també ho podeu veure “en acció” a:
    https://bulma.es.bulma.net/erm/(7)
    Origen de la idea:
    Fa poc he estat “cridat a files” al projecte Bulmagés(8) perque s’estava pensant en arrancar el mòdul de facturació i TPV (actualment Bulmagés només és comptabilitat) i com que per molts és sabut que jo hi estava interessat i, de fet, ja estava fent cosetes pel meu compte, em van demanar de col·aborar-hi.
    La idea era començar amb un TPV perque hi ha una persona a qui li interessa i està disposat a currar-hi per tenir-lo enllestit en poc temps. Va be marcar-se objectíus i aquest és un fàcilment assumible.
    Però tots vam coïncidir en que fer un TPV sense abans tenir definida la Base de Dades de tota la gestió suposaria que en posar-nos amb aquesta segurament hauriem de fer canvis seriosos a la implementació del TPV, cosa que és duplicar feina.
    Per això vam agafar la documentació de la “mitja gestió” que jo tenc funcionant a la empresa a la que treball com a base per fer el disseny de la base de dades de la futura BulmaFACT. I el primer problema que ens vam trobar és que aquell diagrama no es correspòn al 100% amb la base de dades actual perque aquesta ha sofert modificacions que no sempre he disposat de temps d’actualitzar al model Entitat-Relació i fer-ho quadrar amb el relacional i l’SQL de la Base de dades.
    Per tant, vaig haver de partir del model ER que tenia i repescar les millores de notes soltes i de consultes directes sobre la BD en producció. I, lògicament, és previsible que el resultat sigui objecte de modificacions futures ja que es pretén que tot-hom que hi estigui interessat pugui participar en el desenvolupament del projecte.
    A més, això afegeix una complicació extra: Si moltes persones han de participar en el disseny del model de dades, és difícil que tots entenguin a la perfecció la finalitat d’entitats o camps concrets col·locats per altres persones. Si això ja és un problema quan el disseny de la base de dades la fa una sola persona i hem d’anar prenent nota dels nostres propis pensaments per ser capaços d’entendre’ls en el futur, imaginau quan han de ser entesos per moltes persones.
    Aleshores, necessitavem un model ER:

  • Fàcilment modificable
  • Ràpid de consultar
  • Fàcilment comprensible
  • Tant per l’autor…
  • …com per terceres persones que ho hagin de consultar.
  • I si no és molt demanar que modificant una sola fase del disseny, la resta es puguin generar automàticament.
  • Crec que els tres primers punts els hem aconseguit. I el quart està en el TO-DO (el projecte és jove encara ;-)) però pens que no serà gaïre difícil d’assolir.
    Per entendre la idea, si pensam en la naturalesa d’un diagrama ER, veurem que consta de dues parts:

    • Una llista d’entitats amb la corresponent enumeració dels camps que la composen i amb identificacio del camp o camps que formen la clau primaria.
    • Un esquema gràfic on es representen aquestes entitats i les relacions que hi ha entre elles (que, com sabem, de vegades poden contenir algún camp de dades).

    La llista d’entitats és fàcil i es pot fer amb qualsevol editor de text pla (vi comes for help! :-)). Però com més gran és el quocient entre el número de relacions i el d’entitats, més difícil és conseguir una representació gràfica clara i llegible (fins i tot amb llapis i paper) de les relacions existents entre les entitats. Per això és tan difícil trobar una eina CAD adequada.
    Com que això suposava un gran contratemps vaig decidir, en comptes de dibuixar el diagrama, redactar també una llista de les relacions indicant les entitats que relacionen, amb quina cardinalitat i, si en tenen, els camps de dades pertinents i que cadascú es dibuixi, si vol, el seu propi diagrama del que l’interessi, però que el format “oficial” del model ER seria el text pla.
    Amb això es sol·lucionava el punt 1 ja que, per exemple, per afegir una relació al diagrama res més ràpid que escriure-la. I així sorgí la idea que solucionaria el punt 2, perque Crear una aplicació capaç de llegir i indexar tota aquesta informació era relativament trivial i, si be plasmar-la tota de cop i que quedi llegible és, com hem dit, poc menys que impossible, representar una entitat i davora totes les entitats amb que es relaciona i dibuixar-ne les relacions, també era un problema relativament senzill.
    El problema hagués estat fer-ho a ma (repetició de feina) o consultar-ho (anar envant i enrera per un munt de pàgines per seguir el traçat de l’esquema). La idea però, era fer aquesta mateixa representació en format web de manera que, hiperenllaçant les entitats, aquesta navegació es convertiria en instantània.
    Ara només ens quedava el punt 3: Fer que el diagrama fos fàcilment comprensible. En primer lloc pel propi autor, tasca que, com tots sabem, correspòn a un document apart del model ER anomenat Diccionari de Dades i que s’ha de fer al mateix temps que es dissenya el model ER perque si no després no ens recordam de perquè eren la meïtat de coses. Però que a la pràctica tot-hom ho feia després per lo engorrós que resulta passar constantment del ratolí al teclat i vice-versa (ara podem, per exemple, tenir dues pestanyes del konsole amb vim per editar simultàniament MER i DD sense haver d’utilitzar el ratolí per res. A més, ara ja no cal consultar-lo apart, sino que les descripcions dels camps ens surten davora aquests per a l’entitat que estam consultant i en un requadre emergent en passar el ratolí per damunt (anchor amb ‘title’) per als camps de les entitats filles i les relacions.
    …i en segon lloc, per a terceres persones, cas en el qual només queda desitjar que l’autor hagi pres bones notes del que ha fet i de perquè ho ha fet si no volem haver de preguntar-li (o si ell no vol que li preguntin :-P).
    Però així i tot, per a qui no les ha escrites, pot ser complicat trobar una nota en el moment que la necessita. Per aquesta raó, l’aplicació també interpreta certs marcadors que podem utilitzar dins el fitxer de notes per:

    • Delimitar seccions (amb jerarquia).
    • Marcar les notes com a “TO-DO notes” (coses a fer) que surten en vermell, o “Recordatoris o coses fetes”.
    • “Enganxar” la nota a una o vàries entitats o relacions determinades.

    Finalment, si existeix un fitxer anomenat CHANGELOG.txt, a la vista general del diagrama surt reproduït a davall de manera que si tenim diferentes versions podem anar anotant els canvis que anam fent en comparació a la versió anterior.

    Instal·lació:
    La instal·lació és molt senzilla. Vos podeu devallar la darrera versió a:
    http://bulma.net/~joanmi/projectes/erm/(9)
    Per instal·lar-lo només heu de descomprimir el fitxer a un directori accessible via web:
    #tar xvzf nomfitxer.tgz
    Això vos crearà un directori anomenat ‘erm’ i dins aquest directori, a més de l’aplicació en si, trobareu un directori anomenat ‘PROJECTS’. Cada directori que creeu a dins ‘PROJECTS’ serà un nou projecte i cada subdirectori una nova versió.
    Aquí hi heu de crear tres fitxers (o quatre) de text:

    • ERM.txt: Que contendrà el model Entitat-Relació.
    • DD.txt: Pel diccionari de dades.
    • NOTES.txt: Per les anotacions.
    • i, opcionalment, CHANGELOG.txt per l’historial de canvis.

    La sintaxis a utilitzar en cadascun dels fitxers (excepte el CHANGELOG.txt que és lliure) s’explica al següent apartat, encara que també podeu agafar com a referència els fitxers de BulmaFACT(10) que surten enllaçats al peu de cada pàgina. Vos remet concretament als de BulmaFACT i no de BulmaGES en general perque aquests son fets meus i fan ús, al menys en un lloc o altre, de totes les funcionalitats del sistema. En canvi la resta els ha fet en Tomeu Borras agafant aquests com a model (prova de que no és difícil* d’entendre sense documentació :-))
    (*) Ostres! Dit així sembla una indirecta :-P. Però ja m’enteneu 😉
    Com generar els diagrames:
    Els diagrames, com hem comentat, es generen a partir de tres fitxers. El més important és ERM.txt que conté el model E-R. DD.txt conté el diccionari de dades i, com el seu nom indica NOTES.txt les anotacions, comentaris, recordatoris, etc…
    Als tres fitxers, les línies que comencin per punt i coma (;), son enteses com a comentaris. La resta s’explica tot seguit.
    ERM.txt
    A aquest fitxer qualsevol línia que no sigui en blanc o comenci per (;) s’entendrà com una entitat o una relació. El text inicial fins al primer parèntesi (() (entitats) o clau ({) (relacions) és el nom de la entitat o relació. Si es entitat, entre els parèntesis i separats per comes hi aniran els noms dels camps de l’entitat i els que estiguin enclosos entre claudators ([ i ]), s’entendràn com a part de la clau primaria.
    Exemple:

    FACTURA ([Numero], Data)
    LINIA_FACTURA ([Numero], Quantitat, PVP, Descompte)

    Les relacions també poden tenir paràmetres i, si en tenen es posaràn entre parèntesi de la mateixa manera que a les entitats, però abans i entre claus ({ i }) s’indicaran, separades per coma, les dues entitats que relacionen i la cardinalitat corresponent a cada una entre parèntesis.
    Exemple:

    Detall {FACTURA(1), LINIA_FACTURA(1,N)}
    ; Si tengués camps els posariem al final de la forma (Camp1, Camp2…)

    No hi ha cap problema amb definir entitats i relacions mesclades (excepte el bon gust :-P), però per definir una relació es necessari que abans es defineixin les entitats que relaciona. Si no l’aplicació es queixarà. Igual que passarà si ens equivocam amb el nom de l’entitat. Alerta que els noms de les entitats i relacions son sensibles a majúscules/minúscules.
    DD.txt
    En aquest fitxer, encapçalam les entitats amb una línia amb el seu nom entre claudators (per a les entitats) i claus (per a les relacions). Després es posa la descripció de l’entitat o relació i les descripcions dels camps a les línies que comencin amb ‘-‘.
    Exemple:

    [Factura]
    Factura a client.
    – Numero: Numero de factura.

    Com veis, no és obligatori descriure tots els camps. Si ens és mes clar, encara que no els descrivim, també els podem mencionar, però sense els dos punts (:) que marquen l’inici de la descripció. La descripció de l’entitat (o relació) en si també es pot ometre.
    També podem definir constants per estalviar-nos escriure descripcions repetitives. Es poden definir en qualsevol part del fitxer però només seràn vàlides a partir del moment en que es defineixen. Les constants es reconeixen per anar encloses entre els símbols (< i >).
    Exemple:

    <NLI> = Numero de línia.
    [LINIA_FACTURA]
    – Numero: <NLI>
    – Quantitat.
    – PVP: Preu sense IVA.
    – Descompte.

    NOTES.txt
    Finalment, en el fitxer de notes, les línies que comencen en (*) Indiquen l’inici d’un nou punt a recordar. Però si, en canvi, comencen amb () vol dir que son notes de coses que estan per fer. Per exemple, verificacions (o ‘constraints’) que s’han d’implementar però que, òbviament, no ho podem fer encara i volem recordar-nos-en quan sigui el moment.
    Les notes les podem enganxar a una (o també vàries) determinada entitat o relació, de manera que apareguin al ‘post-it’ que hi ha habilitat a l’efecte. Una línia amb una llista d’entitats separades per comes entre claudators indica que la darrera nota s’ha d’enganxar a les entitats esmentades. I el mateix val per a relacions si en comptes de claudators s’utilitzen claus.
    Exemple:

    * Aquesta nota sortirà enganxada a les entitats FACTURA i LINIA_FACTURA i a la relacio Detall.
    [FACTURA, LINIA_FACTURA]
    {Detall}
    – Aquesta altra ens recorda una cosa pendent de fer i sortirà només a FACTURA.
    [FACTURA]

    A més, en qualsevol moment, podem definir seccions posant el nom de les mateixes entre els símbols (< i >) en una línia independent. Les seccions son anidables i en trobar una línia amb (<>) (Sense nom) s’entendrà que acaba la darrera secció definida.
    CHANGELOG.txt
    Finalment el fitxer CHANGELOG.txt, com hem dit, és opcional i el seu contingut és totalment lliure (mentres sigui text pla).

    Funcionalitats futures
    Aquestes son les funcionalitats que tenim pensades implementar en un futur més o menys inmediat:

    • Edició on-line dels models i control de versions.
      • És a dir: Que es puguin editar els fitxers fonts desde la pròpia pàgina i en enviar les modificacions aquestes quedin registrades en forma de fitxer .diff i ens poguem moure per l’”historial” a l’estil CVS.
    • Capacitat per convertir el model ER en model relacional (hi estam treballant)
      • La idea es que qualsevol paràmetre del model relacional final ha de ser controlable des del model entitat relació de manera que poguem efectuar canvis en el relacional simplement fent-los sobre el MER i generant automàticament el relacional.
    • Capacitat de definir tipus de dades ‘DataBase specific’ en apartats específics del DD (per exemple per a Postgress o Mysql) i que d’aquesta manera es pugui generar el codi SQL per construïr la BD.

    Com col·laborar
    Si tens ganes de col·laborar en aquest projecte pots posar-te en contacte amb jo posant un comentari a aquest article o a l’adreça joanmi bulma net (punts i arrobes els poses tu :-)).
    Qualsevol tipus d’ajuda serà bona. Des de col·laboracions en millores o programació de mòduls nous fins a l’elaboració d’un manual millor que aquest article o la traducció d’aquest a l’anglès i altres idiomes.
    I, per suposat, qualsevol suggeriment serà benvingut 🙂Lista de enlaces de este artículo:

  • http://bulma.net/body.phtml?nIdNoticia=2002
  • http://bulma.net/~joanmi/projectes/erm/screenshots/project_select.jpg
  • http://bulma.net/~joanmi/projectes/erm/screenshots/global_view.jpg
  • http://bulma.net/~joanmi/projectes/erm/screenshots/detail1.jpg
  • http://bulma.net/~joanmi/projectes/erm/screenshots/detail2.jpg
  • http://bulma.net/~joanmi/projectes/erm/screenshots/detail3.jpg
  • https://bulma.es.bulma.net/erm/
  • https://bulma.es.bulma.net
  • http://bulma.net/~joanmi/projectes/erm/
  • https://bulma.es.bulma.net/erm/index.php?p=BulmaFACT
  • Este post ha sido traido de forma automatica desde https://web.archive.org/web/20140625063149/http:/bulma.net/body.phtml?nIdNoticia=1997 por un robot nigromante, si crees que puede mejorarse, por favor, contactanos.


    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.