Database Structure Overview
The Ebase Project and Drawings
The Ebase project and its drawings are the central storage of all of the drawing data for a project. The project includes links to DWG files and possibly other sub-projects. 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 the current Ebase project and its associated component data at start up. This data is loaded so that you can connect cables sourced from the drawings and/or route them.
Each Cable Scheduler project has its own database. This database can be either a Microsoft Access database or Microsoft SQL Server database.
In this database you will see EDS drawing components and database-only components. If you create cables and other components within Cable Scheduler (database-only components) then this database is the primary storage for the properties of these new components. EDS will manage the link between the Cable Scheduler database and the project 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 drawings.
When Cable Scheduler starts or closes, the drawing data is synchronized with the Cable Scheduler database. 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.
Tags Table
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.
Ratings Tables
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.
Terminal Group Table
Instruments and devices can have Terminal Groups, which are defined groupings of their individual terminals, for example specific input or output channels. The grouping of terminals is stored in tables with names beginning with "TerminalGroup_". These tables contain the definitions of groupings for all instruments and devices and their terminals; the groupings are not stored in the Tags table. Each record in a TerminalGroup_ table consists primarily of a name and links to the parent component and terminals in a group.
Component Categories
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:
Segments Table
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.
System Tables
The following tables do not contain component data. They contain mappings, settings and links that enable you to use the data in the components. These tables have a specialised user interface if they have one at all.
Alias_* - mappings for columns.
Settings - project-specific preferences used by all users in this one project.
TableModificationsTimes - tracks the last modification of each table to enable you to see other users' changes.
Raised_Issues and Raised_Issue-Types - Storage for the notes and instructions in raised issues, and a lookup table for issue type names.
Database Maintenance
If you are using an Access database file you should periodically run > directly inside Access. Deletion of records and other operations can result in a build-up of unused space in the database, which can lower performance and increases the storage space required for backups. Ensure that you have exclusive access to the database at the time. No other user should have it open in Cable Scheduler or Access.
Cable Scheduler logs changes to the [Event_Log] table. If you have enabled logging for changes to terminals or cable-cores/conductors then these log entries can build up quickly. Cable Scheduler does not delete log entries but you may wish to create a query to remove older entries if you no longer need a log of these events once some time has passed. This is entirely optional and the contents of the [Event_Log] table should not cause performance problems.