Campaign Data Model and Schemas
What you must know
Adobe Campaign Classic stores data in a schema-driven, normalized model. Every table is described by an XML data schema: a <srcSchema> with a namespace and name, containing an <element> tree. Out-of-the-box schemas use namespaces such as xtk, nms, and nl; custom schemas should use your own namespace, commonly cus. Attributes map to SQL columns. <link> elements define joins and need a target; an optional revLink creates the reverse link. Cardinality (0-1, 1-1, 0-N, 1-N) describes how many target records can relate to a source record. integrity="true" enforces a foreign key and affects delete behavior and performance, so use it deliberately.
To add fields to an existing table, create a schema extension with the same namespace and name as the original, not a new standalone schema. The platform merges the extension at runtime. System fields such as iId, iCreated, iModified, and iOwner are managed by the platform; do not redefine them. A schema edit is not a database column until the update database wizard runs.
Traps and rule of thumb
Questions often confuse the targeting dimension with the filtering dimension: the targeting dimension is what a transition carries, while the filtering dimension is the table used for conditions and may require a link. Enumerations, defaults, and notNull constraints also change database behavior.
Worked example: add a loyaltyTier string field to recipients by extending nms:recipient with <attribute name="loyaltyTier" type="string" length="20"/>, then run the database update wizard. The field is then available in queries and personalization. Rule: extend an existing targeting dimension when you need extra data on that population; create a new schema only for a genuinely new business entity.