Database Structure Overview
The Project Database
The Project database is the Ebase project and is named after the Ebase project name. This will be referred to as the "Project Database". The project database is the central storage of all of the data. Typically the project database not only includes component data, it also includes links to DWG files and possibly other project links. These external files linked to the project contain important information that is required by the project at reporting and processing time.
The Cable Scheduler Database
Cable Scheduler automatically defaults to loading current Ebase project and its associated components at start up. This data is loaded so that you can "connect cables" already in the project and/or route them.
Cable Scheduler has its own database. In this database you will see EDS project components however if you create cables and other components within Cable Scheduler then this database becomes the primary storage for some properties of these new components and this causes the Cable Scheduler database to becomes an external file of the project database. EDS will manage the link between the Cable Scheduler database and the project database in all cases.
The Cable Scheduler database contains tables. The tables contain records for component tags, component data, raceway segment data, raceway group data and project configuration data. The database is relational. There are many links between the records in different tables for component tags and component ratings.
Synchronizing the Databases
EDS will manage the link between the Cable Scheduler database and the project database.
When Cable Scheduler loads the Project database is synchronized with the Cable Scheduler database and when it closes down the same occurs. During a Cable Scheduler session you can request that this synchronization occurs.
Components in the Cable Scheduler Database
Data for components is stored in two types of tables: "tags" tables and "ratings" tables.
Each component has one tag record in a tags table. The tag record contains the naming of the component. It also contains all of the relational links to other components and to rating records. A database can contain one tags table or many tags tables.
The names of the tags tables begin with "Tags_". Each tags table has the same basic structure. You can add columns to tags tables, however you should not remove any of the columns that are present in the supplied sample as these are used by Cable Scheduler to make relational links. You can add and remove tags tables as required, however there should always be at least one.
Each component can have one ratings record in a ratings table, although this is not essential. The ratings record contains the specification of the component.
The names of the ratings tables begin with a component category name, for example "Device_" or "Cable_". Each ratings table has data columns that are specific to a particular type of component, and generally different to other types of components. There will generally be many different ratings tables.
You can add or remove columns from the ratings tables as required. You can add and remove ratings tables as required. If a component does not have a ratings record, then any specification for that component must be stored in its tag record.
Each ratings table appears as a folder under a component category, see Category Tree. You can move a component from one folder to another and the data will be shifted from one ratings table to another but, if the column structure of the two ratings tables is different, you may lose data from those mismatched columns.
Components are divided into categories, for example: Enclosures, Devices, Cables, etc. The type of a component is defined by a value in the tag record for that component. The full list of component types is defined by the Cable Scheduler program. The tags for different component types can be stored in the same tags table.
Cable Routing Components
Data for cable routing is stored in three types of tables:
Each raceway segment (e.g. a tray) from your Paneldes model will have one raceway segment record in the segments table. The segment record contains the naming of the component. It also contains all of the relational links to parenting components and contains the segment's rating data. A database can contain one segments table.
The name of the segments table begins with the prefix "RacewaySegments_". You can add columns to segments table; however you should not remove any of the columns that are present in the supplied sample as these columns are used by Cable Scheduler.
Raceway Groups Table
Each raceway group, whether it is partial or complete, will have one raceway group record in the raceway group table. The raceway group record contains the naming of the group and its status (group type and segment type). It also contains all of the relational links to parenting components and some summary routing data. A database can contain one raceway groups table.
The name of the raceway groups table is prefixed with "RacewayGroups_". You can add columns to the raceway group table, however you should not remove any of the columns that are present in the supplied sample as these are used by Cable Scheduler.
Raceway Links Tables
All relational links between raceway segments, raceway groups and cables are kept in the raceway links tables. When you associate items during cable routing in Cable Scheduler these tables hold the association data.
These primarily hold the database indices of the two items being linked.
There is a table containing links for Raceway groups to cables. This stores the information about a cable being guided or routed by a particular raceway group.
There is a table containing links for Raceway groups to other raceway groups. This records that a group includes the segments of another raceway group.
There is a table containing links for Raceway groups to raceway segments. This stores the link that a group contains a segment PLUS the segment's order in the group. It also contains the split part of the segment if that segment was split during routing and any bottleneck data relating to the segment.
Global Project Data Table
The database contains a global table, named "ProjectData", with a single record that contains the constant data for the entire project, for example: customer reference and project title. This data can be shown on any diagram or report with a special #PJ:...# formula.
The data in this table is edited on the Project Data page of the preferences dialog.