When large databases are split into multiple databases and concatenated for ease of maintenance, all databases can be created with the same structure (see Sample 1 below). As the administrator, this database design serves both you and the reviewer. The generic naming of the primary database prevents confusion for the reviewers because they can simply launch the primary database without having to be concerned about multiple databases. The design also benefits you because databases are similarly named and the structure allows for ease of maintenance when indexing or reindexing is needed.
This database structure allows you to index individual databases without having to take the all databases offline. Reviewers can continue working in other databases while you perform the maintenance. Simply notify the review team when records with Bates numbers x through y will be offline.
Concatenated Databases Sample 1
Database File |
Description |
|---|---|
Columbia.dcb |
Primary database with no records to associate with a .cat file. |
Columbia1.dcb |
Import first set of load files and link any images. Index and place database on network to begin review by concatenating to the primary database, Columbia.dcb. |
Columbia2.dcb |
Create a copy of the Columbia1 structure and load additional documents that were received. Index and concatenate to the primary database. |
Columbia3.dcb |
Repeat |
Alternate concatenated database designs can be used. As an example, Transcripts must be organized in a separate database because of the template structure required to import these files. If your database includes Transcripts, you may want to design a concatenated database based on document type (see Sample 2 below)
Concatenated Databases Sample 2
Database File |
Description |
|---|---|
Hunter.dcb |
Primary database with no records to associate with a .cat file. |
Hunter Edoc.dcb |
Database containing electronic documents. |
Hunter Email.dcb |
Database containing emails and attachments. |
Hunter Transcripts.dcb |
Database containing transcripts. |
Hunter.cat |
.cat file linking individual databases with the empty database, allowing viewers to launch them individually or as a concatenated set. |
When various database types are concatenated and saved in a .cat file, all databases in the set automatically launch when the primary database is accessed in Concordance – as long as the .cat file has the same name as the primary database and is saved in the same directory folder as the primary database. This concept is useful when separating documents by source or custodian as well. Users can then choose to only view certain documents by custodian or document type by launching the individual database or review all records together by launching the primary database that has the associated .cat file.
The concatenated text file (.cat) is used to keep track of concatenated databases. The file contains the list of database names and their file paths for the databases in the concatenated database set. If you open a database and Concordance finds a database .cat file by the same name in the same directory as the .dcb file, the databases in the list are automatically opened and concatenated. Since the Reindex function updates all actively concatenated databases, you can search, edit, and use the group as if they were one.
When managing concatenated databases, be aware of the following:
•Index databases individually
•Reindexing is done on all the databases in the concatenated set in turn
•Pack databases individually
•Data imports only append to primary database
•Exports only use a selected database’s field structure from a concatenated set
•Security is applied to databases individually
•Only run productions on individual databases
•Only replicate individual databases
|
You can export from a concatenated set of databases as long as the field names are the same; however, the field type is inherited from only one selected database. Data may be truncated if the field size and data size of one of the concatenated databases exceeds the field size of the selected database structure. |
Concatenated databases have the following limitations:
•You can join databases with differing structures and they can be edited, sorted, and printed. However, the structures must be identical to use certain options such as Overlay and Export.
•You cannot replicate or create a production from a concatenated database.
•When using the Ditto feature, only documents in the primary database can be used for copying data.
•When exporting concatenated databases, only the data in fields that are identically named and formatted in the concatenated set will be exported.
•When importing records into a concatenated database, records are updated when the fields of an imported record match an existing record. When the fields do not match, the imported record is appended to the main database, which is the first database in the concatenated set. However, when using the Overlay option, importing records with mismatched fields can cause a loss of data.
•Records cannot be packed from the concatenated database. They can only be packed from the original, unconcatenated database.
•Concordance displays an appropriate error message if you try to use one of the restricted options. Some options, such as Modify, operate only on the primary database in the concatenated list.
|
Only files with the same file type can be concatenated together. DCB files can be concatenated with DCB files, but not FYI files. |
Security for concatenated databases includes the following guidelines:
•Security settings need to be set up in each database. Setting security in a concatenated database set only affects the primary database.
•The user name and password must be the same for all databases in the concatenated set when security is enabled.
•When the user name and password in the primary database does not exist in a secondary database, and security is enabled, the concatenated database will not open. The user receives a message that they do not have access rights to the specific database.
•When a secondary database has security enabled and the primary database does not have security enabled, the user is prompted for the user name and password when using the secondary database. The user name and password entered becomes the user name and password for the concatenated database set.
Reviewing Concatenated Databases
When reviewing concatenated databases, it can sometimes be difficult to distinguish data from each individual database. When you are searching data on multiple databases, the query results from a same name field intermingle in the Table view. You can use one or more of these methods to help:
•Reference the Concordance title bar for an individual record’s database and document name
•Reference field names for each database displayed in the Table view
•Change the font color and size for each database in the Table View using table layouts
You can also adjust your Table Layouts if field names are similar to sort across the joined databases. Copy the .LAYOUT file from one database to other concatenated databases to use the same table layouts in Table View. Each concatenated database will be listed in the Table Layout dialog with public/private layouts that have been created. If necessary, you will need to manually rearrange fields to have them display in the same columns for sorting purposes.
Applying tags to concatenated databases is as simple as applying tags to individual databases. You can even add tags from one database to another database in a concatenated set. When databases are concatenated, all tags from both databases are displayed in the Tags Panel. If a reviewer applies a tag from one database to a document residing in another database, the tag is then added to the database where it never existed before.
Searching Concatenated Databases
When searching concatenated databases, Concordance searches across all concatenated databases - searching each dictionary file one by one.
Saving queries executed on concatenated databases is the same process as saving them when reviewing one database at a time. All searches from all databases in the concatenated set are saved. Query files are stored in a .qry file, and can be restored on a concatenated set as you would a single database. You just need the databases to be joined when you save the query and when you re-run the query. Re-running the queries on a concatenated database set searches any updates made since the last time any database was reindexed.