So you've got some abnormal data, and you want to fix it up? My instance has lots abnormal data, because nobody has ever tried to clean it up, and it's more than three years old. I had many "messy" fields to choose from, so I started with an easy one: the CPU Type field on the computer form.
The first step is to create a configuration in the Field Normalization application. Configurations come in two flavors: a normalization or a transformation. In this case I could readily identify a handful of "normal" values that I wanted to end up with (Xeon, Pentium, SPARC, etc.) — so normalization, not transformation, is what I need. So I clicked on Field Normalization → Normalizations and then clicked "New"…A few seconds later, I had the screen at right. Here's what each of those fields does:
- Name: This is a human-readable name, not used by the system at all. It's here so you can give the normalization a convenient moniker that makes sense to you.
- Table: A mandatory field that specifies the table being normalized. The choice list shows all the tables in your instance, as you can normalize a field in any of them. As you might imagine, it's important to get this setting right! I want this field to be normalized in all kinds of computers, not just some of them — so I'm defining this normalization in the base computer table. If I had only wanted this normalization to apply to (say) Windows server, I'd have defined it in that table instead.
- Field: Another mandatory field, this one specifying the field to be normalized. The choice list shows all the fields from the table specified above that have a type that can be normalized (these types are defined in Field Normalization → Normalization Field Types, which I'll talk more about in a later post). All you need to do here is to pick your abnormal field.
- Mode: There are three choices here — "Off", "Test", and "Active". When you first create a configuration, this will default to Test, and that's where you want it. Choosing Off does just what you'd think: it turns this normalization off completely. Choosing Test means that the normalization will work for you (actually, anyone with the "normalizer_tester" role) but won't affect either other users or existing (extant) data. Choosing Active means that this normalization is rockin' and rollin': it will work for all users, and you can go back and "fix" all your messy extant data. Test mode is exactly what you want while you're developing and testing a new configuration.
- Normalize query: Checking this box enables normalization on certain kinds of queries (from the user interface or from scripts — much more on this in a later post). Currently, queries with an is or is not (or == or != in a script) operator can be normalized. For example, if you were to create a filter that said "CPU Type is Intel Xeon L3344", it would be normalized into "CPU Type is Xeon". Naturally, if you uncheck the box, this behavior doesn't happen.
- Coalesce each normal: You'll want to be very, very careful with this checkbox — it's powerful and sometimes very useful, but it can result in records being automatically deleted. I'll talk much more about this in a later post. For the purposes of the CPU Type field, I don't want this feature, so it's not checked.
- Raw field: This choice defaults to "none", and often that's what you'll want. But in this case, I wanted to keep the value that was actually stored to the record, before normalization. To do this, I created a new field Raw CPU Type (it could have had any name, of course) before I created this configuration. Then I simply selected it from the choice list. Now each time a value is written to a computer record, the normalized value goes into the CPU Type field, and the raw (i.e., not normalized) value goes into the Raw CPU Type field. That lets me find or report on the data either way, which can be quite useful.
Whew! That's about enough for one day, don'tcha think?
1 Comment
