Generalized Detector Configuration DB Proposal
Gennadiy Lukhanin, Fermilab
(draft 12/03/04)
Table of contents
Table of contents .............................................................................. 2
1 Introduction ................................................................................ 3
2 Design objectives ....................................................................... 3
3 Overview of existing databases ................................................. 3
4 Design blocks ............................................................................. 4
4.1
4.2
4.3
4.4
4.5
5
Hierarchal structure ............................................................................................. 4
Signal connections .............................................................................................. 8
Predefined attributes ......................................................................................... 11
History records .................................................................................................. 14
Final design ....................................................................................................... 14
Conclusion ............................................................................... 15
2
1 Introduction
Modern experiments require complicated equipment, consisting of millions of
parts, so it becomes important to have an accurate tracking capability during construction
and operation phases. CMS collaboration had chosen to address this problem with a
database driven solution. There are four database types proposed by the collaboration for
each sub-detector system: construction, equipment, conditions-online & conditionsoffline. This document is to present a design overview of proposed database schema and
architecture for construction and equipment management databases for HCAL that can be
expended to other sub-detectors. This schema can be extended and reference on/off-line
conditions databases.
2 Design objectives
The major design objectives are: reuse of existing schema components, generic
approach without going deep into component specifics, ensure database integrity by using
constraints, scalability & rapid prototype delivery. Several existing database schemas at
CERN and Fermilab were analyzed and their design patterns will be reused. This
approach will reduce data migration / conversion effort.
3 Overview of existing databases
“Rack Wizard” (Frank Glege) is an inventory management system with a user web
interface. It is used by several LHC projects including CMS. Its schema design
represents hierarchical detector structure and contains GEANT geometry and material
composition of detector parts. It also keeps track of all measurement equipment sitting in
racks.
“HCAL equipment configuration db” (Yuyi Guo) is an equipment database. It
provides information about individual elements, detector map and connection
information.
“RBX-QC” database (Sergey Sergueev) is quality control system for RBXs with
Borland C++ user interface and Paradox database (considering Oracle migration). It has
some elements of construction database.
3
4 Design blocks
4.1 Hierarchal structure
The design pattern, representing a hierarchal structure, is a first schema block. It
was taken from “Rack Wizard” (fig. 0). PHYSICAL PART entity is a super-type (a
parent) for any physical part (or component) that needs to be tracked in the system. This
entity has bare minimum information used to identify the part and does not provide any
details on it. Parts of any kind (or type) must be extended from the PHYSICAL PART
entity. CRATE, BOARD, CABLE, HCAL WEDGE and HCAL TOWER entities must have
a primary key which is a foreign key (at the same time) to the PHYSICAL PART entity.
This constraint will ensure exactly one record for any part entered in the system. All part
attributes should be stored in extended entities: CRATE, BOARD and etc. PHYSICAL
PART should be populated by the extended entity trigger, only.
MATERIAL
# NAME
* DENSITY
parent side
PHYSICAL PART TREE
to
from
SOLID
DETECTOR PART
child side
o SOLID_ID
o MATERIAL_ID
o PART_ID
from
from
# NAME
* SOL_TYPE
to
to
describes
PHYSICAL PART
# PART_ID
o BARCODE
o SERIAL_NUMBER
refers to
to
extends
extends
to
to
extends
to
to
extends
BOARD
HCAL WEDGE
CABLE
HCAL TOWER
o ATTR1
o ATTR2
o ATTR1
o ATTR2
*
*
o
o
o
o ATTR1
o ATTR2
VERSION
BARCODE
LABLE
LENGTH
COMMENTS
extends
CRATE
o ATTR1
o ATTR2
Fig. 0
4
Sample data:
PHYSICAL PART
PART_ID
1
2
3
4
5
6
7
BARCODE
AA1234
AA1235
BB123EE
AA1237
AA1238
BB123E1
AA1240
SERIAL_NUMBER
SWAR1234
SWAR1235
SWAR1236
SWAR1237
SWAR1238
SWAR1239
SWAR1240
CABLE
PART_ID
Length
1
7
Diameter
12
123
5
5.6
BOARD
PART_ID
Size
Power
2
4
5
12
45
123
InstalledBy
45.2
6.2
8.4
Mick
John
Mick
CRATE
Size
PART_ID
3
6
InstalledBy
45.2
6.2
Mick
John
The relationship between parts (or containment) is defined by PHYSICAL PART
TREE entity. It identifies the parent for a given child part. This relationship is shown as a
circle (fig. 1). This design pattern allows any kind of relationships, even invalid ones.
Let’s say CRATE can be contained in a CABLE. This issue can be solved by adding
database constraints.
5
AERAL
#E
* Y
te
i
o
PHYS CALARTREE
m
SD
DEECRPART
o D
o D
o D
h de
m
#E
* E
o
m
s
o
PHYS CALART
#D
o E
o R
so
Fig. 1
There are two types of constraints: design time constraints and run-time constraints.
Design time constraints or foreign keys & check constraints are created during the
database schema design and deployed as a part of it. Foreign keys are represented by
lines on the entity-relationship diagrams. Run-time constraints or logical data driven
constraints can be added or removed at the run time and do not require the schema
change. This design is relying on the second type of constraints. They enable only valid
relationship types (fig. 2). The PART TO PART RELATIONSHIP entity defines a valid
parent-child relationship between two KIND OF PART entities. A PHYSICAL PART
TREE entity (or parent–child relationship) can not be created without specifying a
corresponding PART TO PART RELATIONSHIP entity.
6
MATERIAL
# NAME
* DENSITY
child side
to
PHYSICAL PART TREE
DETECTOR PART
from
o SOLID_ID
o MATERIAL_ID
o PART_ID
parent side
SOLID
from
# NAME
* SOL_TYPE
to
from
describes
has
to
PHYSICAL PART
# PART_ID
o BARCODE
o SERIAL_NUMBER
refers to
belons
PART TO PART RELATIONSHIP
is kind of
# PART_TO_PART_RELATIONSHIP_ID
o PRIORITY
o DISPLAY_NAME
child
specifies
rel child ref
parent
rel parent ref
KIND OF PART
# KIND_OF_PART_ID
* IS_DETECTOR_PART
* EXTENSION_TABLE_NAME
Fig. 2
Sample data:
PHYSICAL PART
PART_ID
1
2
3
4
5
6
7
BARCODE
AA1234
AA1235
BB123EE
AA1237
AA1238
BB123E1
AA1240
SERIAL_NUMBER
SWAR1234
SWAR1235
SWAR1236
SWAR1237
SWAR1238
SWAR1239
SWAR1240
KIND_OF_PART
45
128
128
253
128
253
45
KIND OF PART
KIND_OF_PART_ID
128
45
253
EXTENSION_TABLE_NAME
BOARD
CABLE
CRATE
7
BOARD
PART_ID
Size
Power
2
4
5
InstalledBy
45.2
6.2
8.4
12
45
123
Mick
John
Mick
CRATE
Size
PART_ID
3
6
InstalledBy
45.2
6.2
Mick
John
PART TO PART RELATIONSHIP
PART_TO_PART_RELATIONSHIP_ID
345
1
PARENT_KIND_ID
128
253
CHILD_KIND_ID
128
128
PRIORITY
1
2
PHYSICAL PART TREE
PART_ID
2
5
PARENT_PART_ID
4
3
PART_TO_PART_RELATIONSHIP_ID
345
1
Comment: the last record in PHYSICAL PART TREE says: a board with a barcode
AA1238 is installed in the crate with a serial number BB123EE.
The detector part assembly sequence can be critical in certain cases. The design
introduces a relationship priority model used to define the order in which parts are put
together. Relationships with lover priority numbers should be established first. In our
example we need to attach two boards together before installing them in crate.
4.2 Signal connections
Another aspect of the detector assembly is signal wiring. It comes with a second
schema block (fig. 3). It was taken from HCAL equipment database. Signal wiring is
another form of part to part relationship involving three components: connection start and
end parts and the third one connecting them together. The SIGNAL CONNECTION
TYPE entity is an equivalent of PART TO PART RELEATIONSHIP. Detector
components like circuit boards, modules and others may have multiple connectors
attached to them. This information is stored in CONNECTOR entities. The diagram
reads:” any physical part can have any number of connectors attached to it”. The
8
SIGNAL CONNECTION entity identifies connected parts. Two physical parts can be
connected only if the signal connection type is defined for their kinds (or types).
MATERIAL
# NAME
* DENSITY
parent side
to
PHYSICAL PART TREE
from
SOLID
DETECTOR PART
o SOLID_ID
o MATERIAL_ID
o PART_ID
child side
from
# NAME
* SOL_TYPE
to
from
describes
to
PHYSICAL PART
# PART_ID
o BARCODE
o SERIAL_NUMBER
SIGNAL CONNECTION TYPE
refers to
# SIGNAL_CONNECTION_TYPE_ID
o COMMENTS
defines
conn end part ref
has
conn start part ref
is kind of
conn start point conn end point
cable ref
signal end part
signal start part
cable part
attached to
CONNECTOR
#
*
*
o
CONNECTOR_ID
SIGNAL_DIRECTION
CONNECTOR_LABEL
COMMENTS
SIGNAL CONNECTION
# CONNNECTION_ID
o COMMENTS
defined by
specifies
end con ref
end
conn start ref
conn end ref
KIND OF PART
# KIND_OF_PART_ID
* IS_DETECTOR_PART
* EXTENSION_TABLE_NAME
start con ref
start
Fig. 3
Sample data:
PHYSICAL PART
PART_ID
1
2
3
4
5
6
7
BARCODE
AA1234
AA1235
BB123EE
AA1237
AA1238
BB123E1
AA1240
SERIAL_NUMBER
SWAR1234
SWAR1235
SWAR1236
SWAR1237
SWAR1238
SWAR1239
SWAR1240
KIND_OF_PART
45
128
128
253
128
253
45
KIND OF PART
KIND_OF_PART_ID
128
45
253
EXTENSION_TABLE_NAME
BOARD
CABLE
CRATE
9
BOARD
PART_ID
Size
Power
2
4
5
InstalledBy
45.2
6.2
8.4
12
45
123
Mick
John
Mick
CONNECTOR
CONNECTOR_ID
342
1244
1234
PART_ID
2
2
5
SIGNAL_DIRECTION
in
in
out
LABEL
J45-1
DD32-1
J45-2
CABLE
PART_ID
Length
1
7
Diameter
12
123
5
5.6
SIGNAL CONNECTION TYPE
SIGNAL_CONNECTION_TYPE_ID
56
START_PART_KIND_ID
128
END_PART_KIND_ID
128
SIGNAL CONNECTION
SIGNAL_CON
NECTION_ID
856
SIGNAL_CONNEC
TION_TYPE_ID
56
START_
PART_ID
2
END_PA
RT_ID
5
CABLE_ID
7
START_C
NCTR_ID
342
END_CN
CTR_ID
1234
Comment: the record in SIGNAL CONNECTION table says: two boards with barcodes
AA1235 and AA1238 are connected by the cable AA1240 which is attached to connectors
J45-1 and J45-2 respectfully.
10
4.3 Predefined attributes
There is a special group of attributes that defines some soft of conventions, e.g.
position and numbering schemas, types, categories, grades, phases, stages and etc. These
attributes have fixed values and can be pre-loaded into the database and assigned later to
detector parts (fig. 4). A set of attributes forms an attribute catalog, e.g. a sequence of
numbers 1…16, defining a blade position on a disk, forms a blade-disk position catalog.
Each attribute must have a VALUE, used as a primary identification, and any set of
supplemental description attributes (addition columns in some attribute table) refining the
meaning of it. Attribute catalogs with identical description attribute structures (or same
set of columns) are combined into an attribute entity with one common name. For
example: all positioning and numbering catalogs can be represented by POSITION
NUMBERING SCHEMA entity; all kinds of part types become PART TYPE entity.
This approach significantly reduces the number of entity types (or tables) required to
store them. All attributes are extended from the ATTRBASE entity (attribute super-type
or base class). ATTRBASE is populated by a trigger of the extended attribute entity. The
idea is similar to one described in the first paragraph of section 4.1. The PART TO
ATTRIBUTE RELATIONSHIP entity defines what attribute catalog is used to describe
a given KIND OF PART. A PHYSICAL PART has a list of attributes (ATTRIBUTE
LIST entity) assigned to it.
MATERIAL
# NAME
* DENSITY
parent side
to
PHYSICAL PART TREE
from
SOLID
DETECTOR PART
o SOLID_ID
o MATERIAL_ID
o PART_ID
child side
from
# NAME
* SOL_TYPE
to
from
describes
to
PHYSICAL PART
# PART_ID
o BARCODE
o SERIAL_NUMBER
refers to
is kind of
has attributes
specifies
KIND OF PART
# KIND_OF_PART_ID
* IS_DETECTOR_PART
* EXTENSION_TABLE_NAME
referes to
belogs to part
ATTRIBUTE LIST
# ATTRIBUTE_LIST_ID
POSITION NUMBERING SCHEMAS
o VALUE
extends
combined of
defined by
belongs to
ATTRBASE
base
# ATTRIBUTE_ID
base
belongs to catalog
extends
PART TYPES
o VALUE
referes to
has
ATTR CATALOG
#
*
o
o
ATTR_CATALOG_ID
VISUAL_STYLE
DESCRIPTION
EXTENSION_TABLE_NAME
defined by
PART TO ATTR RELATIONSHIP
refers to
# PART_TO_ATTR_RELATIONSHIP_ID
o DISPLAY_NAME
defined by
Fig. 4
11
Sample data:
PHYSICAL PART
PART_ID
BARCODE
AA1234
AA1235
BB123EE
AA1237
AA1238
BB123E1
AA1240
1
2
3
4
5
6
7
SERIAL_NUMBER
SWAR1234
SWAR1235
SWAR1236
SWAR1237
SWAR1238
SWAR1239
SWAR1240
KIND_OF_PART
45
128
128
253
128
253
45
KIND OF PART
KIND_OF_PART_ID
128
45
253
EXTENSION_TABLE_NAME
BOARD
CABLE
CRATE
BOARD
PART_ID
Size
Power
2
4
5
InstalledBy
45.2
6.2
8.4
12
45
123
Mick
John
Mick
ATTR CATALOG
ATTR_CATALOG_ID
456
675
VISUALSTYLE
Radio button on a
page
Drop down box
on a page
EXTENSION_TABLE_NAME
PART_GRADES
POSITION_NUMBERING_SCHEMAS
Description
Power consumption
grade
Position of a board in
a crate
PART TO ATTR RELATIONSHIP
PART_TO_ATTR_RELATIONSHIP_ID
2345
1632
ATTR_CATALOG_ID
456
675
KIND_OF_PART_ID
128
128
ATTRBASE
ATTRIBUTE_ID
54
55
125
126
78
ATTR_CATALOG_ID
675
675
456
456
675
12
POSITION NUMBERING SCHEMAS
ATTRIBUTE_ID
VALUE
54
55
78
SLOT 1
SLOT 2
SLOT 3
PART GRADES
ATTRIBUTE_ID
RANGE
VALUE
125
126
<10W
>10W
PWR-A
PWR-B
ATTRIBUTE LIST
ATTRIBUTE_LIST_ID
457
856
PART_ID
ATTRIBUTE_ID
4
4
55
126
PART_TO_ATTR_PELATIONSHIP_ID
675
456
Comment: records in ATTRIBUTE LIST table saying: a boards with barcode AA1237 has
two predefined attributes SLOT 2 & PWR-B.
13
4.4 History records
History records will be created as the detector system evolves. Each extended part
entity, e.g. CABLE, CRATE, BOARD (see section 4.1), has a corresponding child history
entity (or child table) attached to it. A history entity has all attributes of a parent
including predefined attributes, described in the previous section. History entities are
implied and not shown on the schema diagram.
4.5 Final design
Fig. 5 has all design blocks put together.
SOLID
# NAME
* SOL_TYPE
to
from
MATERIAL
# NAME
* DENSITY
to
DETECTOR PART
o SOLID_ID
o MATERIAL_ID
o PART_ID
parent side
from
PHYSICAL PART TREE
describes
from
HCAL WEDGE
o ATTR1
o ATTR2
refers to
PHYSICAL PART
has
# PART_ID
o BARCODE
o SERIAL_NUMBER
HCAL TOWER
o ATTR1
o ATTR2
child side
to
extends
to
extends
to
BOARD
o ATTR1
o ATTR2
extends
belons
to
CRATE
o ATTR1
o ATTR2
PART TO PART
RELATIONSHIP
to
extends
to
CABLE
*
*
o
o
o
VERSION
BARCODE
LABLE
LENGTH
COMMENTS
SIGNAL CONNECTION TYPE
# SIGNAL_CONNECTION_TYPE_ID
o COMMENTS
# PART_TO_PART_RELATIONSHIP_ID
o PRIORITY
o DISPLAY_NAME
is kind of
cable ref
has
extends
conn start part ref
conn end part ref
parent
child
defines
conn start point
has attributes
conn end point
cable part
signal start part
signal end part
attached to
conn start ref
rel child ref
rel parent ref
CONNECTOR
# CONNECTOR_ID
* SIGNAL_DIRECTION
* CONNECTOR_LABEL
o COMMENTS
conn end ref
SIGNAL CONNECTION
start con ref
start
# CONNNECTION_ID
o COMMENTS
specifies
defined by
end con ref
KIND OF PART
# KIND_OF_PART_ID
* IS_DETECTOR_PART
* EXTENSION_TABLE_NAME
end
referes to
belogs to part
ATTRIBUTE LIST
# ATTRIBUTE_LIST_ID
combined of
PART TYPES
defined by
extends
o VALUE
defined by
belongs to
referes to
ATTRBASE
base
base
PART TO ATTR RELATIONSHIP
# ATTRIBUTE_ID
# PART_TO_ATTR_RELATIONSHIP_ID
o DISPLAY_NAME
belongs to catalog
defined
refers
to by
extends
ATTR CATALOG
POSITION NUMBERING SCHEMAS
o VALUE
has
# ATTR_CATALOG_ID
* VISUAL_STYLE
o DESCRIPTION
o EXTENSION_TABLE_NAME
Fig. 5
14
5 Conclusion
The described model comes as a logical integration of existing databases into one
compact system design (only 11 core tables), specifically targeted to minimize migration
efforts associated with it. The design was kept at the high level and broken into distinct
functional blocks. These blocks can be used to define project implementation delivery
phases. The addition of run-time constraints offers improved data integrity and flexibility
to add new components at a later time.
15