INFN-Pisa Glast Database in Pisa A practical solution based on MSAccess Luca Latronico INFN Pisa

INFN-Pisa Requirements and conventions Requirements from Proposal of conceptual design of the GLAST Tracker Construction Database (UCSC – SLAC – INFN Pi – Hiroshima Un.) soon in CyberDocs local independent DBs at various institutions central SLAC DB for higher level data (i.e. production monitoring during construction) interface between local DBs local DB take care of data flow from local suppliers web read-only access to local DBs Naming Conventions from Naming Convention for GLAST Tracker Construction and Tray Orientation in Tracker Tower – UCSC for each part unique ID + location PartIDlocation (example) StripS DetectorDH00012[A-D] (L0001B) LadderL0001[F0-B3] (T123B2) TrayT123[G1tr0-G16tr18] (G03tr18) include ManID in ladders, trays enrich tray coding to include type (superglast, top, bottom)

INFN-Pisa MS Access Pros availability (institutes, manufacturers) runs on Windows (manufacturers) built-in import/export of Office docs (e.g. Excel worksheets) familiar “look” (manufacturer) no extra cost (manufacturer) lots of wizards and predefined macros to speed up programming and reporting SQL compliant Cons limited workflow control (mandatory fields) limited web access web I/O possible in principle but …… forced to program in VB and ASP for web scripts very little insight into core of db no automatic backup no user access/action log file evaluation prototype in use and under development

INFN-Pisa System properties relational DB engine : MS Jet Access distributed on local NT network security : NT accounts/permissions + project accounts one data repository (back-end DB) distributed user interfaces (replicated) data and interface backups (replicated) manual backup by replicas synchronization tool web interface (queries/reports) connected to a data server copy through ODBC DSN ASP scripts running on a test PWS (unstable) core data repository upgradeable to SQL Server for real client/server architecture, if needed

INFN-Pisa System architecture I/O Central repository Local replicas Web client ODBC ASP (read-only) DB Interface Users offices Clean room DB Interface I/O DB Interface Data backup DB Interface Data data server Production and quality monitoring

INFN-Pisa Data Transfer local DB export SQL query exchange table exchange table exchange DB ftp import SQL query Local Institute/ManufacturerPisa requests for manufacturers: MSAccess2000 run export query upload Pisa server exchange table exchange DB link Pisa DB requests for institutes: local DB supporting SQL and ODBC set up a server (Pisa, SLAC) two working examples using Access as local DB: ladder assembly from local supplier TMCM from UCSC

INFN-Pisa Relationship

INFN-Pisa Open discussion on naming conventions PartIDlocation (example) StripS DetectorDH00012[A-D] (L0001B) LadderL0001[F0-B3] (T123B2) TrayT123[G1tr0-G16tr18] (G03tr18) applied convention: proposed convention: PartIDlocation (example) StripS DetectorDH00012[A-D] (L0001B) LadderLG0001[F0-B3] (T123B2) TrayTLS123[G1tr0-G16tr18] (G03tr18) manufacturer tag [G (G&A), P (MiPot), L (Laben)] manufacturer tag [G (G&A), P (MiPot), L (Laben)] + type tag [T (Top), B (Bottom), G (Glast), S (SuperGlast), E (Empty)]

INFN-Pisa Open discussion on naming conventions reasons for extra tags : necessary to uniquely identify parts from different suppliers and of different types parts-basic information included in names offer a built-in-the-name selection rule for parts assembly (can be broken!) present db implementation uses old convention internally but: records contained in db tables can be uniquely identified only using multiple primary keys, i.e.: [dbID] =[ID serial nb.]+[manufacturer tag]+[type tag(when present)] parts names are displayed with extra tags in user interface (parts data sheets and web interface)

INFN-Pisa Open discussion on naming conventions open questions: technically no problem in keeping both naming conventions but high risk of end up talking two different languages do we really want a set of names for construction and a different one for integration and running? In this case manufacturer tag has to be removed from SSD names for consistency (thus forcing use of different IDs for SSDs from different suppliers)

INFN-Pisa Main DB mask

INFN-Pisa Example queries for SSD selection relevant parameters sort test/production date selection V depletion selection example

INFN-Pisa Example Report I Selected time SSD statistics

INFN-Pisa Example Report II Ladders statistics report content can be exported to Excel for further analysis

INFN-Pisa Web interface installed on a Personal Web Server example queries (SELECT type) are working: following problems solved: - data type mismatch (e.g. HTML doesn’t have a Date type but SQL does!) - use of proposed new naming convention when displaying parts test on IIS needed goal: provide script for reporting production quality monitoring

INFN-Pisa Plans finalize data queries and periodic reports for monitoring translate queries and reports into scripts for remote production monitoring install a full-functioning web server test web interface get feedback from users: improve interface check speed with much data write and test data queries for selection get feedback from tracker community agree on data transfer protocol