Download DB Client Technologies - OPERA Collaboration Meeting

Emulsion Database Design
Status Report
Extends Opera Internal Note # 38:
“Database Architecture for the European Emulsion Scanning System”
Updated DB Schema
Distributed DB Implementation
DB Client Technologies
DB Client Libraries
Conclusions
Cristiano Bozza
European Emulsion Group
LNGS, May 2003
Updated DB Schema
OPERA European Emulsion Scanning DB
TB_PREDICTIONS
ID
<ak>
Run <pk>
Event <pk>
X
Y
Z
TB_PHYSICSIDS
TB_VERTEXTYPES
ID
<ak>
DESCRIPTION <pk>
ID
<ak>
DESCRIPTION <pk>
FK_PHYSIDS_PREDTRACKS
TB_VERTICES
ID
<pk>
ID_RECONSTRUCTION <fk1>
POSX
POSY
FK_VERTEXTYPES_VERTICES
POSZ
AVERAGEDISTANCE
ID_VERTEXTYPE
<fk2>
FK_VOLTKS_UPVTX
TB_VOLUMETRACKS
ID
ID_RECONSTRUCTION
SIGMA
<pk>
<fk1>
FK_VOLTKS_DOWNVTX
DOWNZ
TB_PREDICTEDTRACKS
ID
ID_PREDICTION
ID_TRACK
ID_PHYSICS
POSX
POSY
POSZ
SLOPEX
SLOPEY
CHI2
FK_PREDICTIONS_PREDTRACKS
FK_PHYSIDS_VOLTKS
<ak>
<pk,fk1>
<pk>
<fk2>
FK_RECON_VOLTKS
FK_RECON_VERTICES
UPZ
DOWNPOSX
DOWNPOSY
DOWNPOSZ
DOWNSLOPEX
DOWNSLOPEY
UPPOSX
UPPOSY
UPPOSZ
UPSLOPEX
UPSLOPEY
MOMENTUM
ENERGY
ID_PARTICLE
<fk4>
RECONSTRUCTIONNOTES
ID_DOWNVERTEX
<fk2>
ID_UPVERTEX
<fk3>
Predictions and Final Results with Physics Info
FK_PROCSTART_PREDTKS
FK_PROCSTART_SELECTION
ID_PROCESS
<pk,fk2>
ID_PREDICTEDTRACK <pk,fk1>
ID_SELECTION
<pk,fk3>
FK_MACHINES_SITE
TB_MACHINES
ID
NAME
ADDRESS
ISSCANNINGSERVER
ISBATCHSERVER
ISDATAPROCESSINGSERVER
ISWEBSERVER
ISDATABASESERVER
ISLOCALMASTERCONTROLLER
ID_SITE
<ak2>
<pk>
<ak1>
TB_RECONSTRUCTIONS
ID
ID_RECONSTRUCTOR
ISCOMPLETE
ID_PROGRAMSETTINGS
ID_PROCESSOPERATION
TB_OPERATIONS
<ak>
<pk,fk1>
<pk,fk2>
ID
<ak>
NAME
<pk>
ISSCANNING
ISTRANSPORT
FK_SELECTIONS_OPS
FK_BATCHES_MACHINES
<fk>
System Management
TB_USERS
ID
USERNAME
PWD
NAME
SURNAME
INSTITUTION
ID_SITE
EMAIL
ADDRESS
PHONE
FK_MACHINES_PROCOPERATIONS
FK_SITES_USERS
<pk>
<pk>
FK_SELECTIONS_USERS
Scanning Predictions
TB_PROC_OPERATIONS
FK_OPERATIONS_PROCOPERATIONS
ID
<ak>
ID_PROCESS <pk,fk3>
ID_OPERATION <pk,fk1>
ID_MACHINE
<fk2>
STARTTIME
FINISHTIME
FK_RECON_USERS
<ak1>
<ak2>
<pk>
<pk>
<fk>
FK_PROCOPS_VTXLOCS
TB_PROCESSES
TB_PROGRAMSETTINGS
ID
<pk>
ID_BRICK <fk>
STARTTIME
FINISHTIME
ID
MODULENAME
MODULEIDENTITY
SETTINGS
ID_AUTHOR
<ak>
<pk>
<pk>
FK_PROGSETTING_BATCHES
FK_TEMPLATEMARKSETS
ID
<pk>
MINX
MAXX
MINY
MAXY
MINZ
MAXZ
TB_VTXLOC_SELECTIONS
ID
ID_PLATE
ID_PROCESSOPERATION
ID_SELECTOR
ID_SELECTIONTEXT
FK_VTXLOC_USERS_VSELS
<fk>
ID
ID_BRICK
ID_MARK
POSX
POSY
MARKROW
MARKCOL
SHAPE
<ak>
<pk,fk>
<pk>
FK_PLATES_BRICK
<pk>
<pk>
FK_BATCHES_REQUESTER
<ak>
<pk,fk2>
<pk,fk1>
<fk4>
<fk3>
FK_BRICKS_PROCESSES
TB_BATCHES
TB_PLATES
TB_TEMPLATEMARKSETS
<pk>
<fk1>
<fk4>
<fk3>
<fk2>
FK_PROGSETTING_RECON
FK_VTXLOC_SEL_VSEL
TB_BRICKS
TB_ALIGNEDBASETRACKS
Event Reconstruction
FK_USERS_PROGSETTINGS
FK_PROCESSES_PROCOPS
FK_PROCSTARTUPS_PROCS
<pk>
<fk2>
ID
ID_MIPBASETRACK
<fk3>
ID_RECONSTRUCTION
<fk1>FK_RECON_ALIGNEDTRACKS
ID_ALIGNEDZONE
FK_RECON_ALIGNEDZONE
ID_VOLUMETRACK
POSX
TB_ALIGNEDZONES
POSY
ID
<ak>
GRAINS
ID_ZONE
<pk,fk1>
AREASUM
ID_RECONSTRUCTION <pk,fk2>
SLOPEX
PLATE
SLOPEY
MAPXX
SIGMA
MAPXY
MAPYX
MAPYY
MAPDX
MAPDY
FK_ALIGN_ZONESTRACKS
MAPDZ
SLOPEDSX
SLOPEDSY
SLOPEMSX
SLOPEMSY
REFX
REFY
REFZ
DOWNZ
UPZ
FK_USERS_PRIVILEGES
TB_SELECTIONS
ID
ID_OPERATION
ID_SELECTOR
SELECTIONTEXT
SELECTIONDATE
DESCRIPTION
FK_VOLTKS_ALIGNBASE
TB_SITES
TB_PRIVILEGES
FK_SITES_PRIVILEGES
ID
<ak>
ID_USER
<pk,fk1>
NAME
<pk>
ID_SITE
<pk,fk2>
LATITUDE
REQUESTSCAN
LONGITUDE
REQUESTWEBANALYSIS
LOCALTIMEFUSE
REQUESTDATAPROCESSING
REQUESTDATADOWNLOAD
REQUESTPROCESSSTARTUP
FK_PROCOPERA_RECON
TB_PROCSTARTUPSELECTIONS
ID
ID_BRICK
PLATE
CALIBRATION
Z
ISCS
EXPOSURESTART
EXPOSUREFINISH
MAPXX
MAPXY
MAPYX
MAPYY
MAPDX
MAPDY
FK_BATCHES_PLATES
<ak>
<pk,fk>
<pk>
<pk>
<fk4>
<fk2>
<fk1>
<fk3>
FK_VTXLOC_VSEL_SELTKS
TB_VTXLOC_SELECTION_REASONS
ID
<ak>
DESCRIPTION <pk>
FK_ZONES_ALIGNEDZONES
FK_VTXLOC_PLATES_SELS
TB_VTXLOC_SELTRACKS
<pk>
FK_MARKS_TEMPLATEMARK
TB_MARKS
ID
<ak>
ID_PLATE
<pk,fk1>
ID_TEMPLATEMARK <fk2>
POSX
POSY
ID
ID_PLATE
ID_MACHINE
ID_PROGRAMSETTINGS
ID_REQUESTER
TEMPLATEMARKS
REQUESTTIME
STARTTIME
ENDTIME
FK_MARKS_PLATE
Bricks and Plates
TB_ZONES
ID
<pk>
ID_BATCH
<fk>
MINX
MAXX
MINY
MAXY
RAWDATAPATH
STARTTIME
ENDTIME
BASETHICKNESS
FK_ZONES_MIPBASE
FK_BATCHES_ZONES
TB_MIPEMULSIONTRACKS
FK_ZONES_MIPEMU
FK_BASE_UPTRACK
ID
<pk>
ID_ZONE <fk>
SIDE
POSX
POSY
GRAINS
AREASUM
SLOPEX
SLOPEY
SIGMA
TB_MIPBASETRACKS
ID
ID_ZONE
POSX
POSY
GRAINS
AREASUM
SLOPEX
SLOPEY
SIGMA
ID_DOWNTRACK
ID_UPTRACK
FK_BASE_DOWNTRACK
Scanning Data
<pk>
<fk1>
ID
<ak>
ID_VTXLOC_SEL
<pk,fk1>
ID_BASETRACK
<pk,fk2>
ID_MOTHERTRACK
FK_VTXLOC_SELRSN_SELTKS
ID_REASON
<fk3>
Vertex Location
FK_VTXLOC_MIPBASE_SELTKS
<fk3>
<fk2>
FK_ALIGNEDBASE_MIPBASE
SELECTIONTEXT
SELECTIONDATE <pk>
DESCRIPTION
<pk>
ISTRANSPORT
PWD
NAME
<pk>
SURNAME <pk>
INSTITUTION
ID_SITE
<fk>
EMAIL
ADDRESS
PHONE
Updated DB Schema
FK_SELECTIONS_USERS
Scanning Predictions
TB_PROC_OPERATIONS
FK_OPERATIONS_PROCOPERATIONS
ID
ID_PROCESS
ID_OPERATION
ID_MACHINE
STARTTIME
FINISHTIME
<ak>
<pk,fk3>
<pk,fk1>
<fk2>
FK_PROCOPS_VTXLOCS
Event R
FK_USERS_PROGSETTINGS
FK_PROCESSES_PROCOPS
FK_PROCSTARTUPS_PROCS
MAPDX
MAPDY
MAPDZ
SLOPEDSX
SLOPEDSY
SLOPEMSX
SLOPEMSY
REFX
REFY
REFZ
DOWNZ
UPZ
TB_PROCESSES
TB_PROGRAMSETTINGS
ID
<pk>
ID_BRICK <fk>
STARTTIME
FINISHTIME
ID
MODULENAME
MODULEIDENTITY
SETTINGS
ID_AUTHOR
<ak>
<pk>
<pk>
FK_PROGSETTING_RECON
TB
ID
ID_PLA
ID_PRO
ID_SEL
ID_SEL
FK_VTXLOC_USERS_VSELS
<fk>
FK_VTXLOC_SEL_VSEL
FK_PROGSETTING_BATCHES
TB_BRICKS
FK_TEMPLATEMARKSETS
ID
<pk>
MINX
MAXX
MINY
MAXY
MINZ
MAXZ
TB_BATCHES
TB_PLATES
TB_TEMPLATEMARKSETS
ID
ID_BRICK
ID_MARK
POSX
POSY
MARKROW
MARKCOL
SHAPE
<ak>
<pk,fk>
<pk>
FK_PLATES_BRICK
<pk>
<pk>
FK_BATCHES_REQUESTER
FK_BRICKS_PROCESSES
ID
ID_BRICK
PLATE
CALIBRATION
Z
ISCS
EXPOSURESTART
EXPOSUREFINISH
MAPXX
MAPXY
MAPYX
MAPYY
MAPDX
MAPDY
FK_BATCHES_PLATES
<ak>
<pk,fk>
<pk>
<pk>
<fk4>
<fk2>
<fk1>
<fk3>
FK_VTXLOC_VSEL_SELTKS
FK_ZONES_ALIGNEDZONES
FK_VTX
TB_VTXLOC_S
<pk>
FK_MARKS_TEMPLATEMARK
TB_MARKS
ID
<ak>
ID_PLATE
<pk,fk1>
ID_TEMPLATEMARK <fk2>
POSX
POSY
ID
ID_PLATE
ID_MACHINE
ID_PROGRAMSETTINGS
ID_REQUESTER
TEMPLATEMARKS
REQUESTTIME
STARTTIME
ENDTIME
FK_MARKS_PLATE
Bricks and Plates
TB_ZONES
ID
<pk>
ID_BATCH
<fk>
MINX
MAXX
MINY
MAXY
RAWDATAPATH
STARTTIME
ENDTIME
BASETHICKNESS
FK_ZONES_MIPBASE
FK_BATCHES_ZONES
TB_MIPEMULSIONTRACKS
FK_ZONES_MIPEMU
FK_BASE_UPTRACK
ID
<pk>
ID_ZONE <fk>
SIDE
POSX
POSY
GRAINS
AREASUM
SLOPEX
SLOPEY
SIGMA
TB_MIPBASETRACKS
ID
ID_ZONE
POSX
POSY
GRAINS
AREASUM
SLOPEX
SLOPEY
SIGMA
ID_DOWNTRACK
ID_UPTRACK
FK_BASE_DOWNTRACK
Scanning Data
<pk>
<fk1>
ID
ID_VTXLOC_SE
ID_BASETRACK
ID_MOTHERTRA
ID_REASON
Verte
FK_VTXLOC_MIPBASE_SELT
<fk3>
<fk2>
REDICTIONS
<ak>
<pk>
<pk>
TRACKS
OPS
Updated DB Schema
TB_PHYSICSIDS
TB_VERTEXTYPES
ID
<ak>
DESCRIPTION <pk>
ID
<ak>
DESCRIPTION <pk>
FK_PHYSIDS_PREDTRACKS
TB_PREDICTEDTRACKS
ID
ID_PREDICTION
ID_TRACK
ID_PHYSICS
POSX
POSY
POSZ
SLOPEX
SLOPEY
CHI2
TB_VERTICES
ID
<pk>
ID_RECONSTRUCTION <fk1>
POSX
POSY
FK_VERTEXTYPES_VERTICES
POSZ
AVERAGEDISTANCE
ID_VERTEXTYPE
<fk2>
FK_PHYSIDS_VOLTKS
<ak>
<pk,fk1>
<pk>
<fk2>
FK_RECON_VERTICES
FK_VOLTKS_UPVTX
TB_VOLUMETRACKS
ID
ID_RECONSTRUCTION
SIGMA
FK_VOLTKS_DOWNVTX
DOWNZ
UPZ
DOWNPOSX
DOWNPOSY
DOWNPOSZ
DOWNSLOPEX
DOWNSLOPEY
UPPOSX
UPPOSY
FK_RECON_VOLTKS
UPPOSZ
UPSLOPEX
UPSLOPEY
MOMENTUM
ENERGY
ID_PARTICLE
RECONSTRUCTIONNOTES
ID_DOWNVERTEX
ID_UPVERTEX
<pk>
<fk1>
<fk4>
<fk2>
<fk3>
Predictions and Final Results with Physics Info
FK_PROCSTART_PREDTKS
FK_MACHINES_SITE
TB_MACHINES
ID
NAME
ADDRESS
ISSCANNINGSERVER
ISBATCHSERVER
ISDATAPROCESSINGSERVER
ISWEBSERVER
ISDATABASESERVER
ISLOCALMASTERCONTROLLER
ID_SITE
<ak2>
<pk>
<ak1>
FK_VOLTKS_ALIGNBASE
TB_SITES
TB_PRIVILEGES
FK_SITES_PRIVILEGES
ID
<ak>
ID_USER
<pk,fk1>
NAME
<pk>
ID_SITE
<pk,fk2>
LATITUDE
REQUESTSCAN
LONGITUDE
REQUESTWEBANALYSIS
LOCALTIMEFUSE
REQUESTDATAPROCESSING
REQUESTDATADOWNLOAD
REQUESTPROCESSSTARTUP
FK_PROCOPERA_RECON
TB_RECONSTRUCTIONS
ID
ID_RECONSTRUCTOR
ISCOMPLETE
ID_PROGRAMSETTINGS
ID_PROCESSOPERATION
FK_BATCHES_MACHINES
<fk>
System Management
TB_USERS
ID
USERNAME
PWD
NAME
SURNAME
INSTITUTION
ID_SITE
EMAIL
ADDRESS
PHONE
FK_MACHINES_PROCOPERATIONS
FK_SITES_USERS
ons
TB_PROC_OPERATIONS
FK_OPERATIONS_PROCOPERATIONS
ID
ID_PROCESS
ID_OPERATION
ID_MACHINE
STARTTIME
FINISHTIME
<ak>
<pk,fk3>
<pk,fk1>
<fk2>
FK_USERS_PROGSETTINGS
TB_PROCESSES
TB_PROGRAMSETTINGS
ID
ID
<pk>
FK_RECON_USERS
<ak1>
<ak2>
<pk>
<pk>
<fk>
FK_PROCOPS_VTXLOCS
FK_PROCESSES_PROCOPS
<ak>
TB_ALIGNEDBASETRACKS
ID
ID_MIPBASETRACK
<fk3>
ID_RECONSTRUCTION
<fk1>FK_RECON_ALIGNEDTRACKS
ID_ALIGNEDZONE
FK_RECON_ALIGNEDZONE
ID_VOLUMETRACK
POSX
TB_ALIGNEDZONES
POSY
ID
<ak>
GRAINS
ID_ZONE
<pk,fk1>
AREASUM
ID_RECONSTRUCTION <pk,fk2>
SLOPEX
PLATE
SLOPEY
MAPXX
SIGMA
MAPXY
MAPYX
MAPYY
MAPDX
MAPDY
FK_ALIGN_ZONESTRACKS
MAPDZ
SLOPEDSX
SLOPEDSY
SLOPEMSX
SLOPEMSY
REFX
REFY
REFZ
DOWNZ
UPZ
FK_USERS_PRIVILEGES
TB_OPERATIONS
ID
<ak>
NAME
<pk>
ISSCANNING
ISTRANSPORT
<pk>
<fk2>
Event Reconstruction
FK_PROGSETTING_RECON
<pk>
<fk1>
<fk4>
<fk3>
<fk2>
Updated DB Schema
Overall structure unaltered, only fine tuning of data types and table columns
To assess performance, tuning must be done in real-life conditions
Not only benchmarks, but real use of DB for test exposure data
Updated DB Schema
DB size estimate
(depends on Physics as well as instrumental needs)
Assumptions for minimum size:
25000 events (OPERA half data set + tests, technical runs...)
Few data from CS (< 100 tracks per sheet), so they are negligible
Intercalibration through 4 track maps per sheet, 100 tracks / map
All sheets in a brick are intercalibrated (conservative)
1 candidate is followed on 28 sheets on average (conservative)
1 “interesting points” per event (vtx, decays, e.m. showers, ...)
3 pass scanning (Vtx location, selection, precision measurement)
100 cosmics / background / fake microtracks in each zone
Updated DB Schema
DB size estimate
(depends on Physics as well as instrumental needs)
Assumptions for maximum size:
50000 events (OPERA full data set + tests, technical runs...)
Few data from CS (< 100 tracks per sheet), so they are negligible
Intercalibration through 4 track maps per sheet, 100 tracks / map
All sheets in a brick are intercalibrated (conservative)
10 candidates are followed on 28 sheets on average (conservative)
3 “interesting points” per event (vtx, decays, e.m. showers, ...)
3 pass scanning (Vtx location, selection, precision measurement)
100 cosmics / background / fake microtracks in each zone
Updated DB Schema
DB size estimate
(depends on Physics as well as instrumental needs)
Results:
Assuming 100 bytes / track + aligned reconstructions, we have
0.11÷2.3 TB
Including safety factors for possible underestimations, the DB size
should stay within
DBSize < 2.5 TB
To estimate the network bandwidth needed, we assume that the
full dataset is read 10 times during 5 years’ data taking
0.055÷1.2 Mbit/s ON AVERAGE
Distributed DB Implementation
Workstation DB Group
Workstation DB Group
Core DB
Scanning DB
Scanning DB
Distributed DB Implementation
Core DB Group:
Centralized location
Full OPERA emulsion data set
Multimaster replication (each machine has one copy)
Scanning DB:
One machine per each scanning site (+ optional backup)
Copy of the subset of locally produced scanning data
Materialized views (each machine stores only locally produced data)
The full dataset is still accessible in a transparent way
Minimum network traffic
Distributed DB Implementation
Pilot DB farm
Core DB Group Simulation:
Two Dell servers with high speed (1 Gbit) Ethernet connection
Scanning DB Simulation:
One Dell server machine with a materialized view of Salerno data
Normal 100 Mbit/s LAN connection
DB Client Technologies
Several client connection technologies are being explored
Goal: highest possible data availability for Oracle data
Windows:
ODBC, OLE DB, Oracle ODP.NET, ADO, ADO.NET
Linux:
Oracle OCI C++ libraries, Perl, Tcl/Tk, Python, GNOME-DB, J2EE
Mono (.NET) Oracle provider
DB Client Technologies
Oracle and Windows:
Working with DB is common practice in the Windows community.
Oracle provides both the DB server and several client tools / libraries.
Oracle 9i Database Server consists of 3 installation disks (2.4 GB).
We have made several performance tests to choose the best access
method. Since our code will be under .NET, the ADO.NET layer was
common to all tests.
OCI C++: low level API, much harder than other methods.
ODBC: general DB library.
OLE DB: 50% faster than ODBC. OK!
Oracle Data Provider (ODP.NET): slightly slower (~10%?) than OLE DB.
DB Client Technologies
Oracle and Linux:
Oracle is fully committed to supporting the Linux operating system.
Indeed, Oracle was the first commercial database available on Linux.
All key Oracle products including Oracle 9i Database, Application Server,
Collaboration Suite, Developer Suite and E-Business Suite.
Oracle 9i Database consists of 3 cpio archive files ( ~ 1.4 Gb).
We installed it on a Red Hat 7.3 Linux Distribution.
DB Client Technologies
Oracle and Linux: OCI C++
Oracle Call Interface (OCI) is the Oracle software allowing access to the
database from an external application.
In principle, you can use this C-based API to build a Database application
from scratch.
Oracle and Linux: Perl
Perl is probably the most famous open source language.
It is an interpreted scripting language easy to learn and extremely quick.
It is widely used in Internet and Database applications.
DB Client Technologies
Oracle and Linux: Perl
Perl Database applications are based on the DBI module, an object
oriented architecture module. This module requires a specific database
dependent driver (DBD::Oracle) to connect to the database
Perl 5 Script
Perl DBI
DBD:: Oracle
Oracle DB
Oracle OCI
DB Client Technologies
Oracle and Linux: Perl
A sample Perl script to access data from Oracle
use strict ;
use DBI ;
# Connection to the DB
my $dbh = DBI -> connect(dbi:Oracle:operadb,operausr,operapwd);
# Database SQL Query
my $sql = qq { SELECT Grains,SlopeX,SlopeY FROM MIPBaseTracks};
# Execute SQL Query
my $sth = $dbh ->prepare ($sql);
$sth -> execute ();
# Loop on the table
While (my ($run,$event,$ntracks)= $sth->fetchrow_array){
# Here you can do whatever you want with the data
}
DB Client Technologies
Oracle and Linux: Tcl/Tk
Tcl is an excellent scripting language created in 1987 by John Ousterhout.
In 1988 he started to develop a graphic tool called Tk.
From that moment on, Tcl/Tk is one of the most favourite language in the
Open Source community.
Oratcl is the module allowing the connection to an Oracle database.
The connection to the database can be tested interactively using the Tcl
shell.
DB Client Technologies
Oracle and Linux: Tcl/Tk
A sample Tcl/Tk script to access data from Oracle
tclsh
%package require Oratcl
%set handle [oralogon operausr/operapwd@operadb]
%set cursor [oraopen $handle]
%orasql $cursor {select Grains,SlopeX,SlopeY from MIPBaseTracks}
%orafetch $cursor
25 0.400 0.003
32 0.231 0.005
……………
%oraclose $cursor
%oralogoff $handle
%exit
DB Client Technologies
Oracle and Linux: Perl/Tk
Tk is wrapped inside Perl. So you can combine Perl quickness
with Tk graphics capabilities.
Oraexplain is the Perl/Tk module used to connect a program to an Oracle
database.
Oraexplain scripts are more complex because they involve graphical
elements like windows, buttons and frames. You can use them to develop
login windows or more complex graphics applications.
DB Client Technologies
Oracle and Linux: Python
Python is a GUI open source and object-oriented
scripting language created by Guido van Rossum.
It is used for any kind of application: GUI, XML, email, ….
DCOracle is the module used to connect a Python script to an Oracle
database.
With Python you can define classes and re-use them in other scripts.
DB Client Technologies
Oracle and Linux: GNOME-DB
The GNOME-DB project aims to provide a free unified data
access architecture to the GNOME project. GNOME-DB is
useful for any application that accesses persistent data
(not only databases), since it now contains a pretty good
data management API.
We are currently testing the GNOME-DB libraries.
Oracle and Windows/Linux: Mono
ADO.NET Data Provider for Oracle databases works on
Windows and Linux with Oracle 8i and higher versions.
We are currently testing the Mono ADO.NET libraries.
Tests in progress: Web applications with Apache, JSP, PHP, Java, JDBC
DB Client Libraries
We are developing a full set of .NET / Mono classes specific to Opera DB
OperaDb
Namespaces in black
OperaDb::Connection
Classes in dark red
OperaDb::Transaction
OperaDb::Scanning
OperaDb::Scanning::Batch
OperaDb::Scanning::LinkedZone
OperaDb::Scanning::MIPBaseTrack
Who does not want to use SQL can
program the DB in C++, C#, VB,
FORTRAN, and so on, using these classes
OperaDb::Scanning::MIPIndexedEmulsionTrack
OperaDb::TotalScan
OperaDb::TotalScan::Layer
OperaDb::TotalScan::Segment
OperaDb::TotalScan::Track
OperaDb::TotalScan::Volume
OperaDb::ComputingInfrastructure
OperaDb::ComputingInfrastructure::Machine
OperaDb::ComputingInfrastructure::ProgramSettings
OperaDb::ComputingInfrastructure::User
OperaDb::ComputingInfrastructure::UserPermissions
OperaDb::ComputingInfrastructure::Site
More classes to come...
DB Client Libraries
Code samples
Sample #1: How to store a scanning zone into Opera DB
C++:
idZone = LinkedZone::Save(pMyZone, idBatch, rawDataPath, startTime, endTime, dbConn, dbTrans);
C#:
idZone = LinkedZone.Save(MyZone, idBatch, rawDataPath, startTime, endTime, dbConn, dbTrans);
Sample #2: How to retrieve a volume reconstruction from Opera DB
C++:
Volume *pVol = new Volume(dbConn, dbTrans, idVolume, true);
C#:
Volume Vol = new Volume(dbConn, dbTrans, idVolume, true);
Sample #3: How to convert a scanning zone from Opera DB to ROOT file
C++:
SySal:: Root::Opera::LinkedZone::Save(new LinkedZone(dbConn, dbTrans, idZone), filePath);
C#:
SySal.Root.Opera.LinkedZone.Save(new LinkedZone(dbConn, dbTrans, idZone), filePath);
Conclusions
The DB architecture that has been proposed some months ago is working
Oracle 9iDS looks a very good choice
(easy to implement, maintain, and develop; widely supported)
Even people that are not familiar with SQL can easily work with the
proposed structure of emulsion DB using interface libraries
All interesting OS are supported by Oracle and by our interface libraries
Conversion to Root data is trivial (1 line of code)
Interface libraries for OperaDB are almost (95%) complete
...everything fine up to now!