As always with the CMDB, there's no single correct answer, but instead think carefully about what you are trying to achieve and what data model will best help you do that. Having said that, here's how I handled this recently for a customer who wanted to keep track of SIMs separately to phones. Sometimes company SIMs were given to users to put into private devices, sometimes they would be inserted into company mobiles. It was important to be able to keep track of both device and SIM either way.
I defined a new CMDB class for SIM, with fields including Phone Number, SIM Number, Mobile network supplier (a reference to the Company table), data tarrif (a reference to a custom table of tarrifs), and size (e.g. Standard/Nano/Micro). I then defined a new class of Phone (a child of the built-in Commiunication Device class)., Under that I defined sub-classes for iPhones, Blackberrys and Nokias.Some may consider different classes for different phone types to be overkill, but it's handy to have device-specific fields sometimes, e.g. for Apple's Device Enrollment Program, or for the unlock code that Blackberrys come with. The Phone class had a field for SIM, so you could assign a SIM to a phone, as you would in real life.
Here's a screenshot of an iPad with a SIM in it. Note that the fields in the SIM section are dot-walked directly from the SIM record. If you change the Phone Number, it's the SIM record which changes, rather than the Phone record.
I decided not to use the relationship editor to connect phone and SIM, as this was not easy to use for those charged with maintaining the database. Instead I added a Parent field to the SIM table. I wrote some Business Rules to keep Phone and SIM in sync, e.g. if the phone was assigned to somebody else., then the SIM would also get assigned to that person, or if Phone X had SIM Y inserted, then SIM Y would have Phone X automaticaly set as it's parent.
Hope this helps to get you started.
