funcționalitate
mai jos este o listă a funcționalității de bază: Full, sub, SMARTS, similitudine, Formula
căutări structura chimica pot fi combinate cu căutări de proprietate
căutări structura chimica sunt paginate și cache
suport pentru compuși multi-componente (amestecuri)
3 structura chimică entități căutate: ChemicalCompound, Containable și ChemicalCompoundContainer
Importul și exportul de fișiere SD pentru mai sus 3 entități
securitate opțională (autorizare)
cu proiectarea și funcționalitatea MDF este posibil de a construi mai multe tipuri diferite de sistem, cum ar fi sistemele de înregistrare, sisteme de inventar sau doar o bază de date compus simplu. În timp ce ai putea crea, de asemenea, propriul ELN, există, de asemenea, gratuit Indigo ELN. Acest ELN a fost creat de GGA Software Services și este utilizat la Pfizer .spre deosebire de MolDB5R și MYMOLDB , MDF nu este o aplicație web autonomă complet funcțională cu căutare de structuri chimice. După cum sugerează și numele, este un cadru pentru a simplifica crearea unei astfel de aplicații. MDF poate fi, de asemenea, utilizat pentru a crea aplicații desktop locale sau client-server. MDF este destinat dezvoltatorilor de software și nu este destinat utilizării de către oamenii de știință înșiși. Cu toate acestea, caracteristicile MDF sunt foarte robuste. Căutarea structurii chimice se face în baza de date și nu în codul aplicației. Prin urmare, puteți căuta după structura chimică și alte proprietăți în același timp, rezultatele pot fi sortate după mai multe proprietăți și pot fi paginate (clauze SQL OFFSET și LIMIT). Rețineți că dacă efectuați căutarea structurii chimice în codul aplicației, orice interogare va necesita cel puțin două călătorii în baza de date, și anume căutarea structurii și ulterior filtrarea după alte proprietăți, sortare și/sau limitare. Ambele trebuie să se întâmple în aceeași tranzacție. Nu s-a stabilit dacă MolDB5R și MyMolDB fac acest lucru în aceeași tranzacție.
în MDF compușii chimici pot fi asociați cu un container, care în sistemele de înregistrare ar fi un lot sau într-un sistem de inventar foarte mult. Un eșantion specific disponibil fizic într-o sticlă cu coduri de bare poate fi apoi asociat cu un recipient. Aceste containere pot fi, de asemenea, căutate prin structura chimică. Aceasta este fundamentul pentru crearea unui sistem de inventar. Dezvoltatorii pot adăuga oricâte proprietăți suplimentare Doresc fiecărei entități și toate pot fi căutate împreună cu structura chimică.
tot accesul la date în MDF este tranzacțional pentru a preveni inconsecvențele datelor. MDF poate fi configurat pentru a utiliza un bazin de conexiune de baze de date. Atunci când interogarea unui RDBMS crearea unei conexiuni durează adesea mai mult timp decât interogarea în sine și, prin urmare, dacă aveți deja conexiuni deschise timpii de răspuns pot fi reduse.
pentru similitudine căutarea MDF expuse algoritmii furnizați de cartușul Bingo, care sunt Tanimoto, Tversky și metrice euclidiene pentru substructuri.
MDF este gata pentru a fi utilizat cu securitate de primăvară. Securitatea este opțională. MDF oferă securitate la nivel de metodă (autorizare). Nu oferă funcții de autentificare.
manipularea amestecului
MDF acceptă compuși chimici cu mai multe componente. Căutarea după substructură va returna toți compușii care au cel puțin o componentă (structură chimică) care se potrivește cu structura interogării. Acest lucru este important deoarece produsele de reacție care pot fi introduse într-un sistem de înregistrare chimică sunt aproape întotdeauna amestecuri, cu excepția cazului în care se face o purificare extinsă.
dacă o intrare într-un fișier SD importat constă din mai multe structuri deconectate, se presupune că această intrare este un amestec și fiecare structură este stocată ca o structură chimică separată.
normalizarea structurii
implicit MDF stochează structurile chimice pe măsură ce sunt trimise. MDF nu face nici o standardizare/normalizare a structurilor chimice. Depinde de dezvoltator care utilizează MDF pentru a se asigura că structurile chimice sunt normalizate corect înainte de a le salva în baza de date. În prezent, se sugerează ca dezvoltatorii să implementeze o astfel de caracteristică prin suprascrierea metodei preSave() a ChemicalCompoundServiceImpl. Această metodă este apelată înainte ca orice compus chimic să fie creat sau actualizat. În cadrul acestei metode, compusul chimic și toate structurile chimice din care este format pot fi manipulate liber după dorință. Rețineți că fiecare compus salvat va fi procesat prin această metodă.
săruri, solvați și soluții
MDF versiunea curentă 1.0.1 nu are o manipulare specială pentru săruri, solvați sau soluții. MDF va stoca componente separate într-un fișier de structură chimică ca o structură chimică separată. Prin urmare, salvarea unei sare ca 1 = CC = CC = C1. va fi reprezentat ca un amestec al celor doi ioni fără niciun procent stabilit. O căutare exactă a structurii pentru oricare dintre ioni ar returna această sare. Dacă sarea are o sarcină mai mare de 1 și mai mulți ioni asociați cu ea, cum ar fi 1 = CC = C = C1.. sarea va fi depozitată ca un amestec de 1 = CC = C = C1 și fără niciun procent stabilit. Dacă structura chimică este un singur ion, aceasta va fi stocată și căutabilă ca orice altă structură chimică. Dacă acest comportament nu este adecvat într-un caz specific, dezvoltatorii pot implementa funcționalitatea de manipulare a sării și solvatului în metoda preSave ().
unele sisteme comerciale par să nu aibă nici o modalitate de manipulare a soluțiilor. Se recomandă crearea compusului ca și cum ar fi pur și adăugarea informațiilor despre soluție ca câmpuri separate la nivelul compusului.
exemplu aplicație web
a fost creată o aplicație web simplă care utilizează MDF. Aplicația web face uz de primăvară MVC. Aplicația nu utilizează integrarea de securitate și nu utilizează entitățile Containable și ChemicalCompoundContainer. Folosește numai substanțe Chimiceentitate compusă. Aplicația este o bază de date compusă pentru compuși cu mai multe componente. Are o pagină pentru importul structurilor chimice într-un fișier SD în baza de date compusă. Baza de date poate fi căutată prin substructură și proprietăți. Folosește JSME pentru desenarea structurilor chimice (Figura 3). Pagina cu rezultatele căutării afișează rezultatele căutării într-un mod tabelar și paginat. Când se efectuează o căutare a substructurii, substructura va fi evidențiată în rezultatele căutării (Figura 4). Accesările unei căutări pot fi exportate ca fișier SD. Rezultatele căutării conțin un link către o singură vizualizare compusă. Proprietățile compusului pot fi editate și compozițiile pot fi adăugate, editate și șterse (figurile 5, 6). Când editați un compus sau o compoziție, aplicația se ocupă de modificările concurente în mod transparent și este afișat dialogul de rezolvare a conflictelor pe care utilizatorul poate selecta ce valori să utilizeze pentru fiecare proprietate și apoi să salveze noua versiune.
pagina de căutare a aplicației web exemplu folosind MDF. Un utilizator poate căuta în baza de date compusă după substructura chimică și / sau proprietăți precum numele compusului sau numărul CAS.
pagina de rezultate a unei căutări de substructură. Rezultatele sunt afișate într-un tabel paginat generat de datatables plugin JQuery . Imaginile structurii chimice au substructura potrivită evidențiată în roșu. Dacă faceți clic pe imaginea structurii chimice, veți afișa zâmbetele pentru aceasta.
vizualizare individuală compusă. Această pagină web afișează un singur compus. Compusul poate fi editat sau șters făcând clic pe link-ul potrivit din pagină. Există o filă care afișează toate structurile chimice conținute și o filă pentru fiecare compoziție individuală din care este format compusul.
compoziție unică. Afișează aceeași pagină ca figura 5, dar în loc de fila structură combinată, este selectată fila primei compoziții. Compoziția poate fi editată făcând clic pe linkul conform DIN pagină.
performanță
MDF are o problemă principală de performanță la manipularea amestecurilor. Dacă o aplicație utilizează amestecuri, adică compuși cu mai multe componente, o interogare de structură chimică va returna un rând pentru fiecare componentă dintr-un compus care corespunde interogării. Acest lucru este nedorit, deoarece utilizatorii finali doresc să vadă fiecare compus care se potrivește cu interogarea o singură dată. Soluția la problema este de a utiliza o interogare distinctă și acest lucru este în cazul în care problema de performanță se întâmplă. Dacă efectuați o interogare distinctă, întreaga bază de date trebuie căutată indiferent de clauza limită care crește foarte mult timpul de execuție. Rețineți că sortarea are același efect. Deci, sortarea poate avea și o penalizare uriașă de performanță și atunci când paginați, ar trebui să sortați întotdeauna pentru a obține un rezultat previzibil. Pentru a face acest lucru și mai rău cartuș Bingo pentru PostgreSQL nu are încă o implementare adecvată pentru estimarea costurilor, iar costul pentru utilizarea indicelui structurii chimice este greu codificat și subestimat. Acest lucru induce în eroare Planificatorul de interogare PostgreSQL pentru a utiliza întotdeauna o Scanare completă a indexului pe indexul de căutare a structurii chiar și atunci când interogarea are o clauză suplimentară where-clause care limitează foarte mult cantitatea de rezultate. În aceste cazuri, ar fi, de exemplu, mai rapid să utilizați indexul pentru numărul CAS și să utilizați funcția Bingo matchsub pentru filtrare. Funcția matchsub face potrivirea substructurii fără index. Acest lucru este, desigur, mai lent decât cu un index, dar dacă trebuie făcut doar pentru un număr mic de structuri, este mult mai rapid decât scanarea completă a indexului. Pentru a remedia problema estimării costurilor, MDF face unele calcule interne pentru a decide în mod explicit dacă se utilizează indicele structurii sau funcția matchsub. Acest lucru poate îmbunătăți performanța cu un ordin de mărime. Rețineți că furnizorul cartușului Bingo este conștient de această problemă și cronologie pentru fix a fost sfârșitul anului 2013. Problema principală a interogărilor și sortării distincte este totuși inerentă modului în care funcționează bazele de date relaționale și nu poate fi rezolvată decât cu un index de căutare mai bun al substructurii sau cu un hardware mai bun. MDF oferă, de asemenea, o setare pentru a dezactiva interogări distincte la nivel de aplicație pentru baze de date compuse cu o singură componentă.
pentru a compara MDF a fost utilizată aplicația web prezentată anterior. Baza de date conține 525573 compuși unici. Compușii sunt din subsetul de Zinc 13 la referință pH 7 fișierele SD 13_p0.0.sdf, 13_p0. 1.sdf, 13_p0. 10.sdf și 13_p0.11.sdf. Structurile sunt stocate în baza de date ca zâmbete. Importarea fiecăruia dintre fișierele SD, care conțin aproximativ 131.000 de structuri chimice, a durat 12 minute cu indicele de căutare a structurii chimice dezactivat. Reconstruirea indexului după ce toate fișierele SD au fost importate a durat 22 min pe un laptop cu 4 GB RAM, Procesor Core i5-3220m și un SSD Samsung 512GB 830. Asta totalizează la 1 h 10 min pentru a configura o bază de date complet indexată cu o jumătate de milion de compuși. Ca referință suplimentară, același import a fost făcut pe un computer desktop cu 12 GB RAM, i7-875k @ 3.4 GHz și baza de date care rulează pe o unitate Western Digital Green (5400 RPM). Aici importul a durat 8 minute, iar concluzia este că importul este limitat de CPU, mai degrabă decât să fie limitat de viteza de stocare. Generarea indexului a durat aproximativ 22 de minute pe laptop și 20 de minute pe desktop. Concluzia aici este că este limitată mai mult de CPU, dar viteza unității contează și ea. Performanța de import și de generare a indicilor la stocarea structurilor ca molfiles nu a fost comparată.
performanța de căutare a substructurii a fost comparată cu diferite setări de configurare. Căutarea substructurii se face prin cartușul Bingo PostgreSQL și, prin urmare, acest punct de referință reflectă performanța sa, plus orice cheltuieli generale cauzate de MDF. Cu excepția c1ccccc1 autorul a desenat structuri chimice fără semnificație specifică și a testat viteza de căutare. Viteza de căutare a fost determinată de implementarea logbacks a org.slf4j. profiler.Profiler.
primul punct de referință este o referință. Acest punct de referință a folosit opțiunea pentru a dezactiva toate interogările distincte și nu s-a făcut nicio sortare. MDF efectuează un număr de accesări totale la prima apariție a unei căutări de structură chimică, iar numărul este memorat în cache, ceea ce face ca prima pagină să se încarce mai lent decât paginile următoare. Fiecare pagină conține 4 înregistrări. Rezultatele sunt prezentate în tabelul 2 ordonate crescător după numărul de accesări.
benchmark-ul a fost repetat, dar de data aceasta cu interogări distincte activate. Timpul de încărcare a primei pagini este dublat deoarece interogarea de numărare este executată și apoi interogarea reală este executată, care durează aproximativ aceeași perioadă de timp ca interogarea de numărare datorită clauzei distincte. A doua pagină durează întotdeauna jumătate din timp pentru a se încărca în comparație cu prima pagină din același motiv (Tabelul 3). Numărul de accesări este identic cu cel din tabelul 2, deoarece toți compușii din Baza de date constau dintr-o singură componentă.
rezultatele arată că Bingo nu are optimizări pentru o interogare comună a substructurii ca un inel benzenic și, prin urmare, căutarea c1ccccc1 într-o bază de date în care aproape toate moleculele au foarte încet. Pentru a îmbunătăți viteza de căutare într-un astfel de scenariu, se recomandă filtrarea prin proprietăți suplimentare. Prin urmare, criteriul de referință a fost repetat cu un filtru suplimentar de nume compus începând cu „ZINC34”.
Tabelul 4 prezintă beneficiul optimizării MDF ca o soluție a problemei de estimare a costurilor în cartușul Bingo PostgreSQL. Fără această optimizare, valoarea de referință ar avea aceeași performanță ca cea prezentată în tabelul 3.
MDF utilizează, de asemenea, cartușe Bingo similitudine căutarea funcționalitate. Performanța sa a fost testată prin căutarea compușilor cu un scor de similitudine de 0,9 folosind măsura de similitudine Tanimoto cunoscută și sub numele de index Jaccard . Rezultatele sunt prezentate în tabelul 5.
Outlook
pentru generarea reprezentărilor structurii chimice se utilizează setul de instrumente Indigo. Setul de instrumente poate fi configurat pentru a genera structurile în mai multe moduri, inclusiv colorarea heteroatomilor, lungimea și lățimea legăturii și multe altele. În prezent, acest lucru este greu codificate și nu pot fi ajustate de către utilizator. Un pas următor ar fi expunerea acestor opțiuni de configurare, astfel încât acestea să poată fi setate printr-un fișier de proprietăți Java. De asemenea, manipularea sărurilor și solvaților trebuie pusă în aplicare pentru a face MDF utilizabil în zonele în care astfel de compuși sunt importanți.
pentru a face uz de MDF trebuie să fie capabil de a programa în Java și veți avea nevoie de cunoștințe de bază despre cadru de primăvară și cum să-l configurați. Acest lucru limitează publicul țintă. Când utilizați MDF, trebuie să scrieți un cod al plăcii cazanului și, prin urmare, următorul pas ar fi crearea de instrumente suplimentare pentru a facilita utilizarea MDF, cum ar fi generarea automată a claselor de entități și a depozitelor și serviciilor acestora. Aceste instrumente ar trebui să fie configurabile astfel încât un utilizator să poată defini proprietățile dorite pentru fiecare dintre entități și metodele de căutare dorite. O opțiune ar fi un plugin maven. Plugin-uri Maven poate genera cod ca crearea metamodel făcut de plugin-ul QueryDSL-maven. O altă opțiune ar fi adnotările care generează cod la compilare, așa cum face Project Lombok .
ultimul pas ar fi crearea unei platforme de aplicații web care să permită administratorilor să creeze noi aplicații web cu capacitate de căutare a structurii chimice, introducând pur și simplu proprietățile dorite pentru entități într-un formular web și făcând clic pe un buton. Este evident că acest lucru ar necesita un efort semnificativ de dezvoltare.
