Home > Resource Center > Resource Center > technical > MetaData Engine (Database)

Cumulus MetaData Engine (Database)

Metadata Engine (Database)

At the heart of Cumulus Core is Canto's award-winning database engine. The primary advantage to offering customers our own database engine is performance. Cumulus Core's database engine was designed for metadata processing applications, ensuring users can find what they need in moments, not the minutes or hours other database systems can require when querying massive metadata collections.

Fields

The following table describes the metadata field types offered by Cumulus Core:

Field	Data Type Details	Displayed to Users As	Usage Examples
Audio	Stores and plays back audio captured by the client computer's audio system, or by a supported digital camera that records voice.	Series of "VCR" style buttons	Enables users to add voice annotations to asset records using computer microphones. Multiple Audio fields can be added to a catalog enabling several users to record and store audio comments for others. Audio fields can also be used to store and playback the audio captured by audio-enabled digital cameras.
Asset Reference	Stores a special binary field used for asset references. The value is captured when the asset is cataloged.	File system path. The exact format depends on the filing system on which the asset resides. Examples: Windows: d:\Assets\image.tif Mac OS X : Hard Drive:Assets:image.tif Linux/Solaris: /Volume/Assets/image.tif	Though not user-editable, asset reference fields can be displayed for user reference.
Binary	Stores a binary data stream not suitable for other field types.	Not displayed	Offers developers a universal data storage object that can be used with custom applications that either extend or interface with a Cumulus Core-based product.
Boolean	Stores boolean value: 0 or 1.	Checkbox	Provide users yes/no fields. Define field label as needed: "Approved," "Archived," "Complete" etc.
Data Size	Stores the size of an asset.	A number whose format label is based on the data size in the field: bytes, kilobytes, megabytes, or gigabytes.	This field is used to store the size of the cataloged asset. It can also be used to store the size of other assets too, if needed.
Date	Stores a complete date/time pair.	Complete date value, as defined by operating system preferences. Example: 12/19/2006 8:32:21 PM	Asset and asset record modification dates are common uses for Date fields. They can be used for any Date value that must include a calendar date and a time value.
Date Only	Stores only a date value.	Date-only value, as defined by operating system preferences. Example: 12/19/2006	Use any time a date value is required, but a time value is not.
Time Only	Stores a time value only.	HH:MM:SS	Use for any time value, such as the broadcast time for a cataloged video program. Milliseconds can be added after a trailing period. (HH:MM:SS.XXX)
Integer	Stores whole numbers with up to 32-bit precision.	Number	Popular uses include the horizontal or vertical number of pixels in an image. (See also, Long.)
Label	Stores colored codes users assign to asset records.	Label fields can either be displayed as a horizontal stripe through the asset record, or they can paint the background color of the asset record.	Labels are typically used as a means of rating or categorizing assets. Multiple label fields can be added to a catalog, making it possible to provide each user in a work group his or her own.
Length	Stores a length measurement.	The format (inches, centimeters, points, etc.) is determined in the current user's preferences.	The horizontal and vertical dimensions of an image asset are common uses of this field type.
Long	Stores whole numbers with up to 64-bit precision.	Number	Use for any number when 64-bit precision is required . (See also, Integer.)
Picture	Stores bitmap image data that's pasted into the asset record, or gathered or created during cataloging as a thumbnail.	Asset thumbnail or user-pasted image. The size of the image displayed set as "small," medium" or "large." The size of these presets are determined in the active user's preference settings.	The most common use for a Picture metadata field is to store a thumbnail image for the asset. But the field can also be used to store other bitmaps that are pasted into the asset record from the client computer's clipboard. Examples include a scanned release form signed by an actor in a video clip, or an alternate thumbnail used to identify the asset.
Rating	Stores a number of star icons for user labeling purposes.	0 through 5 stars	Enables users to set "star" ratings to assets. Multiple rating fields can be added to a catalog, making it possible to provide each user in a work group his or her own.
Real	Stores decimal numbers with up to 64-bit precision.	Number	Asset license value or acquisition costs are uses for Real fields, but the field can be used for any purpose and labeled to reflect the data contained.
Resolution	Stores the dots-per-inch resolution defined in a bitmapped file.	Number	Some image editing programs enable users to define a dots-per-inch file resolution for certain file formats. This field format can be used to capture and store that information.
String	Stores textual information.	Alphanumeric text	String fields are the most common field type, enabling users to store any textual metadata.
String List	Stores an array of predefined String values.	Drop-down menu, a series of radio buttons, or a series of checkboxes if set to enable multiple value selections.	String List fields enable administrators to offer menus and radio button sets to users. Multiple-selection string list fields enable administrators to define metadata fields such as "Intended Audience," for which there might be several appropriate values, such as "Children," "Teenagers" and "Adults."

Fields can be added and customized at any time, even after catalogs have gone live. If fields are no longer needed, they can be deleted to reduce catalog size.

Administrators can select fields for indexing, and even choose which fields are considered by the QuickSearch tool, which enables users to type in terms like they would using an Internet search engine. Cumulus Core also enables applications to restrict the editing of any given field to a certain user or group. Likewise, fields can be hidden from users or groups that should not see them.

Catalog Scope & Metadata Field Linking

Cumulus Core catalogs point to the assets they contain—they do not contain the assets themselves. The assets themselves can be stored in any location the engine can access, on any medium supported. A single catalog can point to assets stored on the server's locally mounted volumes, networked volumes, Internet-based ftp locations, and even removable volumes, such as optical drives. It doesn't matter which operating system is used to catalog the assets; Cumulus Core takes care of the path conversions needed for others to access what they need.

Asset metadata are typically stored within the catalog, but they can also be stored inside the assets themselves, depending on the scope of the file format's metadata support. Catalog administrators determine if metadata are also stored inside assets. (Cumulus Core supports far more metadata types than do the various metadata-supporting asset formats. For this reason, asset metadata storage is an option and not a restriction.) IPTC and XMP metadata standards are fully supported and, for asset portability's sake, catalogs can be configured to not exceed the limitations of these standards.

Cumulus Core makes it easy to route incoming metadata into catalog fields you choose, thanks to a feature called Field Linking. While the default field links are sufficient for most purposes ("caption" metadata goes into the Caption field, "notes" metadata goes into the Notes field, etc.), you can assign as many custom routings as you need. Field Linking also determines how and when metadata should be written back to the assets.

Formula-based Field Values

Formulas you define can be used to fill an asset record or category metadata field value. Perform numeric calculations, concatenations of other field values, if-then decisions, and much more. Example uses include determining an image’s orientation (square, portrait or landscape), creating space-efficient output displays for views and reports, totaling license values, and more. The built-in formula editor features an in-line help reference to make formula creation easy.

Mirroring

Cumulus Core databases can easily be mirrored to other systems in real time. Supported systems include MySQL, MS SQL 2000/2005, Oracle and even another Cumulus Server, which makes catalog backup easy and Web Access Client load balancing possible. Even while mirroring, the Cumulus Core database remains online and searchable, which means users can rely on it to perform the search types it does so much better than other systems, while they can also search the external systems directly.

Catalog Journaling

Journaling helps ensure your catalogs survive system failures that could otherwise require significant downtime for catalog reconstruction. Journaling is available with all Cumulus Server editions, regardless of platform. A single check box turns on journaling, even for catalogs created in older versions of Cumulus.

Multiprocessor/Multithreading Support

All Cumulus Core databases are multiprocessor aware and multithreaded for maximum performance. Application developers can limit the number of threads available in a Cumulus Core-based application, but the technology itself can support an unlimited number.

User Preference Central Storage

User preference settings are always stored on the server, enabling users to log in from different desktops (or operating systems) and see their personalized interface. Shared user-created resources, such as search queries, are also stored on the server.