Hi JH, et al. On Thu, 2 Mar 2000 12:26:27 -0500 "J.H. Lee" <jhlee@bnl.gov> wrote: > Dear Anders, > > I think the proposed dB is well thought out and nicely organized. > I have a few comments/questions on the proposal. Hmm, I think the current run database (called RUNDB on pii3) isn't very good. Actually, I think it should undergo a complete revision. Far to much data is present in the one table that makes up this database. Rather is it should be split into a number of tables. I coould imagine the following: RunHeader: id, runNumber, date, startTime, endTime, irTemperatur, amosphericPres daqMap (reference), many-to-many yellowBeam (reference), many-to-one blueBeam (reference), many-to-one triggers (reference), many-to-many scaledown (reference), many-to-many detectors (reference), many-to-many fields (reference), many-to-one specSetup (reference), many-to-one files (reference), many-to-many supervisor (refernece), many-to-one Beam: id, Energy, ... Triggers: id, name, comment, ... Scaledown: id, name, comment, ... Detectors: (see my up comming document on the BRAT DB classes) Fields: id, name, comment, d1, d2, d3, d4, d5, ... SpectrometerSetup: id, name, comment, refereceMomentumMIDS, refereceMomentumFMS, MIDSAngle, MIDSDist, FFSAngle, BFSAngle, ... Files: id, name, size, fullpath, ... Person: (see my up comming document on the BRAT DB classes) This will insure better safety, lesser size, and so on. If you're familiar with normal-forms (NF) of databases, I doubt that the current RUNDB is even in the second NF. What I propose, I believe to be close to the 4NF, at least it's 3NF. > - Where will calibrated geometry data belong to? > I would propose we have a "Geometry Table" which can > include the "SurveyPoint" and calibrated detector geometry > data. Yeps, that should be `BrahmsGeom', again, see my up comming document on the BRAT DB classes. > - How about the Magnet related information? > I think positions of the magnet should belong to the Geometry > Table. But if we are going to put field readings in the database, > where are they going to go to? Should we just put the reading > into the event stream maybe? I think your right! > - Same question for the environmental parameters. Temperature, > Atmospheric pressure and so on..., if there are more than one > reading per run. If that's the case, you're right. Otherwise, we don't care really. > - I had a discussion with Konstantin about a "File" database. I agree > with him that it would be nice to have that in the dB to keep tracks on > the zillion files we are going to have. Since we are writing > multiple files per run, and the files will have daughter files, > this should be a separate "Table" not belong to the "Run Table". You're are right (see the above schema). > - Some fields for the Run database(table) have been put in. More fields > will be added (or deleted) Uh!? > on as we go along, of course. (See below) Of course!? I believe you're wrong. It's true that during commishioning we'll create/drop tables, add/delete columns from the databases, but this should be minimized. Constructing a good, solid schema from the beginning, will prevent much of such dangerous operations on the DB's. Again, I suggest that you revisit your schema for RUNDB. Also, I'd be happy if you could change the name of the database to 'BrahmsRun' as this will work better with BRAT DB classes - thanks! The promised document will hit the web-pages at the earliest tomorrow (Friday) and at the latest Monday. I'll keep you posted. Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Thu Mar 02 2000 - 16:36:57 EST