LANDesk's data model is very open and flexible; the database can hold more information than it collects by default, and the console will display whatever you tell it to. It can be very handy to extend the schema to show external information -- some of the utilities on this site do exactly that, and many LANDesk admins have integrated home-grown ERP/CRM solutions, external warranty information, and workflow automation tools into the LANDesk database.

That said, if you introduce an error into your schema, you'll be happy to get away with nothing worse than insiduous corruption of the database. People have locked their consoles out of the database, broken inventory scan inserts, and caused query performance to approximate the glory days of the 386SX. Test early and test often, lest you find yourself explaining that you didn't really mean to break it, your fingers just sorta slipped.

1. Develop what you want to add. I'm going to assume that you know how to design or read a schema, add tables, join tables, or do whatever else it is that you want to do; just get the data into the database and make sure that your schema is clear (to you at least). The extended data could be coming from external sources -- a script, a tool, or a database that is separate from the LANDesk agents; or it could be coming from the LANDesk agents themselves, via LDAPPL3.TEMPLATE or LDSCNHLP.INI; but bear in mind that data inserted via the latter tools are going to go into UNMODELEDDATA if they don't match perfectly with the schema. That distinction will be hidden from you during console and query use, but it may eventually hurt performance.
   

2. Describe it in XML. If you look in your LDMAIN folder, you'll see a file named Datamart.XML, and maybe another one named AssetManager.XML. Read these for examples, but don't modify them... at best, your changes will be erased by an upgrade. Rather, put your additions into an external file, such as Customized.xml. Here's an example from my ldms_nmap scripts:

<table name="NMAP" desc="" metaAdd="Yes" equiJoin="No" displayName="Listening Ports" parentRelation="Computer.Network" parent="NetworkSoftware" tableType="3" image="Network.bmp" rollupIdentity="Yes" >
    <column name="Computer_Idn" type="Int" null="No" />
    <column name="NetworkSoftware_Idn" type="Int" null="No" />
    <column name="ScanTime" type="Varchar(256)" displayName="Scan Time" />
    <column name="GoodScan" type="Int" displayName="Good Scan" />
    <column name="Port" type="Varchar(256)" displayName="Port Scanned" />
    <primaryKey name="Computer_Idn">
        <primaryKeyColumn column="Computer_Idn" />
        <primaryKeyColumn column="NetworkSoftware_Idn" />
    </primaryKey>
    <foreignKey name="R_Connection" foreignTable="NetworkSoftware">
        <foreignKeyColumn column="Computer_Idn" foreignColumn="Computer_Idn" />
        <foreignKeyColumn column="NetworkSoftware_Idn" foreignColumn="NetworkSoftware_Idn" />
    </foreignKey>
</table>

Finally, we tell the system that it's there -- run CoreDBUtil.exe /xml=Customized.xml. If all goes well (meaning that you've tested everything and let it simmer for a day or two with no complaints), then you're probably good to go to production. That code ends up looking like this:

One more warning: A schema extension is difficult to remove or modify, so you don't want to change your mind after the fact. If your schema is no longer reflecting the reality of the database, you may see some unfortunate behavior, including records that can't be deleted (because the transaction includes tables that do not exist, the entire transaction must be rolled back). By way of example, here are the SQL statements requried to remove the NMAP table from my own schema:

select * from metaobjects where objectname='NMAP'
select * from metaobjrelations where metaobjects_idn='234'
delete from metaobjattrrelations where metaobjrelations_idn='230'
delete from metaobjrelations where metaobjects_idn='234'
delete from metaobjects where metaobjects_idn='234'