An organisation must track docking stations as a new class of configuration item. The new records need the standard configuration item columns, must appear in reporting and searches that already run across all configuration items, and must also carry three columns unique to docking stations. Which data model approach meets all three needs?
- ACreate a standalone table with copies of the configuration item columns plus the three new ones, then add it as a data source to the existing configuration item reports.
- BAdd the three new columns to the Configuration Item table itself and a choice field marking which records are docking stations, leaving every configuration item on one table.
- CCreate a new table that extends the Configuration Item table and define the three unique columns on that child table, leaving the inherited columns defined on the parent. Correct
- DCreate a many to many relationship between the Configuration Item table and a small table of docking station attributes, so each configuration item can be paired with its extra columns.
Why A is wrong: Copying columns produces a table that looks right, which is why it tempts, but an unrelated table is not part of the configuration item hierarchy, so existing queries across configuration items still miss its records.
Why B is wrong: This keeps reporting simple, so it attracts, but it forces three columns that are meaningless for every other class onto the shared parent table and loses the type distinction the model needs.
Why C is correct: Correct, because extension makes the new table a subtype whose records are also configuration items, so inherited columns and existing cross class queries apply while the child holds its own columns.
Why D is wrong: A relationship table is a genuine construct for linking records, but it models associations between rows rather than a subtype, so a docking station would remain a plain configuration item with a linked row.