Database Infrastructure for Application Development

• Designing tables and relations (Oracle Designer)

• Creating and maintaining database tables

• d0om - ORACLE and CORBA backends

• Accessing database tables (offline apps)

• Framework Managers and other applications accessing a db.

• Accessing database tables (online apps)

• Framework support for multiple CORBA based manager packages

• Applications loading or accessing data from PCs/spreadsheets

• Web access to database tables

• Applications which need specialized GUIs

• Accounts, mail list, tutorials, etc.

• When is all this going to get really exercised ??

Designing tables and relations (Oracle Designer)

• Use of Oracle Designer strongly encouraged

• Julie Trumbo (offline) and Jeremy Simmons (online) help with designs

• ODS DBAs create designer repositories for each application eg. Smt_calib_design

Problems/risks

• few designer licences - ‘loan’ of licences offsite being arranged e.g. to Indiana

• recalcitrants (e.g Northwestern)

• Developers all work in development database

• DDL to create tables, keys, triggers, etc -- all comes from Oracle designer

• must package in a product and cut a version before will be allowed in production database

• must provide rate and sizing information for DBAs at this time

• methodology for version cuts, evolution to next version is written up

Problems/Risks

• hard work to get people to follow up

• people keeping real data in development database! - not secure

Creating and maintaining database tables

D0OM - ORACLE and CORBA backends

• cannot write data with d0omCORBA backend currently. It is assumed that data read by offline has either come from online -> offline upload, or from a special application which writes to the DB using tailored db server calls for that application

• d0omORACLE writes/reads and creates its own tables on the fly. Application using it must run on a machine with SQL*NET

Problems/risks

• very little use in earnest of either package. No use with large complex C++ structures.

• Will demand maintenance when calibration users ramp up!

Accessing database information (offline applications)

• 3-tier architecture for Calibration data, RCP data, Geometry data (if ever put in Oracle) and other environment, run, luminosity or parameter data fetched from a database. No SQL*NET needed, no licences

• DB server ‘generated’ almost entirely (if using d0om) and in large part otherwise using product db_server_gen (ups product) developed for SAM. Each appl has its own DB server run on any machine with SQL*NET installed.

• RCP manager needs its own simply DB server to conform to its interfaces.

Problems/risks• need a bit of help to build a db server (Steve W., Matt

V.) (done for smt_calib, L3Trig) • calibration will need a caching server later• code for online-> offline loading must be written along

with application

Offline packages which use database

• Calibration --- smt_calibration (Ela) has example code , other subsystems just starting to look at this

– calibration manager uses d0om to do truly deferred I/O.

• RCP --- backend database to be implemented in July (Marc P/Steve White)

• Trigger databases - Level 1/2 Elizabeth - still in prototype stage using direct python ->dcoracle and Level 3 in development

Problems/risks

• calibration managers will need to cache and handle multiple calibrations eventually

• smt example will need mods and maintenance when people start to copy it

• trigger database work going very slowly - needs to meet up with online and XML

• several other packages --- alignment, parameters, luminosity

• calibration fits within online calibration framework. Jeremy has used db_server_gen and then embedded modules directly within python calibration scripts

• hardware database accessed from web using python -> oracle

Problems/risks

• code for online -> offline loading must be written along with applications

Read/write access to database information (online)

• Framework must keep the ORB

• will urgently need this as soon as try to use calibration manager for real

• packaging corba_utils from SAM for use

Framework support for multiple CORBA based manager packages

• Prototyped approach with Al Ito and spreadsheets of survey constants - uploaded to a temp. database table, massaged then stored.

• Veronica Sorin trying to build a similar system

• Tutorial on web shows how to use PC tools (Excel, Access, WORD) to browse a database

Problems/risks

• not an automated process

Applications loading/accessing data from PC/spreadsheets

• Tutorial on the web about

– use of Python and DCORACLE

– use of MISWEB tool

• Harry Melanson has used htmlgen to generate web pages from python script

Problems/Risks

• Web based GUIs with html and Python cannot be very sophisticated

Web access to database tables

• e.g. L3 Trigger application -- need Java or other language tools. Difficult to get right.

Applications which need special GUIs

• Http://d0db.fnal.gov/d0db

Accounts, mail lists, tutorials, etc.

• ??

When is all this going to get really exercised