William Kent

From CEOpedia
William Kent
See also

This article is about the computer scientist. For the English architect and landscape designer (c.1685–1748), see other sources.


William Kent - is an American computer scientist (1936–2005), known to colleagues as Bill Kent, who spent about twenty years at IBM and later worked in the database research group of Hewlett-Packard Laboratories. He is remembered above all as the author of Data and Reality (1978) and of the paper "A Simple Guide to Five Normal Forms in Relational Database Theory" (1983), two texts that are still read by students and practitioners of data modelling[1].

Kent's work sits at an odd junction. Half of it is plain engineering advice on how to lay out records so that a database does not contradict itself. The other half is philosophy: what is a "thing", when are two things the same, and can a computer ever hold an honest picture of the world? Most database authors pick one side. Kent wrote about both, and his readers in information management still argue over which half matters more.

Life and career

Kent was born in Budapest, Hungary, in 1936 and came to New York City with his parents as an infant. He took a bachelor's degree at the Polytechnic Institute of Brooklyn and in 1959 moved to California, where he earned a master's degree in mathematics at San Jose State University[1]. On his own website he mentioned degrees in chemical engineering and mathematics, so the route into computing was not a straight one[2].

He then worked for IBM as a programmer for about two decades. That period produced his best-known writing. An early IBM technical report, "A Primer of Normal Forms" (1973), already dealt with normalisation in a formal way[3], and Data and Reality came out with North-Holland in 1978.

After IBM he moved to the Database Technology Department of Hewlett-Packard Laboratories in Palo Alto. There he researched object-oriented data models. His group built Iris, a prototype object-oriented database system that he described as the precursor of HP's OpenODB/Odaptor products, and then Pegasus, a follow-on project for making heterogeneous database systems work together[2]. In the last stage of his professional life he wrote and produced documentation for HP's Electronic Assembly Development Center.

Standards work took a lot of his time. Kent was a founder and the first chairman of the ANSI X3H7 committee on Object Information Management and served as acting chair of the ANSI/SPARC DBSSG Object-Oriented Database Task Group. He also took part in ANSI X3H2 (Database), in IFIP TC2.6 (Data Bases) and in the Object Management Group, where he sat on the Technical Committee, the Object Model Subcommittee and the Database Special Interest Group[2]. He presented at many international conferences, particularly the Very Large Data Bases series.

He retired in 2000 and settled in Moab, Utah, in the red-rock country he loved, where he ran the Petra Gallery and photographed canyons. He died of a heart attack on 17 December 2005, aged 69[1].

Main works

Kent's bibliography is long. His website lists dozens of papers on object identity, types, nulls, time and measurement, many of them HP Labs reports. A short selection:

  • Data and Reality (North-Holland, 1978; republished by 1stBooks, 1998; 3rd edition by Technics Publications, 2012, updated by Steve Hoberman)[4]
  • "Limitations of Record-Based Information Models", ACM Transactions on Database Systems, 1979[5]
  • "The Entity Join", Proceedings of the Fifth International Conference on Very Large Data Bases, Rio de Janeiro, 1979
  • "A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM, February 1983 (first an IBM technical report, 1981)[3]
  • "A Rigorous Model of Object Reference, Identity, and Existence", Journal of Object-Oriented Programming, 1991
  • "The Unsolvable Identity Problem", a talk given in 2003

The 1983 guide is short, six journal pages, yet it became one of the best-known introductions to normalisation. The reason is simple. It explains first through fifth normal forms "in terms that do not require an understanding of relational theory", as Kent put it, and he stressed that the guidelines make sense even for someone who is not using a relational system at all[3].

Key ideas

Data models are maps

Data and Reality opens with a line aimed at cartographers: "A message to mapmakers: highways are not painted red, rivers don't have county lines running down the middle, and you can't see contour lines on a mountain." Kent explained that after years of working with file organisations, indexes, hierarchies, networks and relational models, "it dawned on me that these are all just maps, being poor artificial approximations of some real underlying terrain". He borrowed S.I. Hayakawa's phrase "the map is not the territory"[6].

The book then suggests, "by sheer weight of examples, rather than any kind of proof", a hypothesis: "there is probably no adequate formal modelling system". Real information is too ambiguous and too subjective to be pinned down by deterministic machinery[6]. A bleak conclusion? Kent didn't think so. People still need models to get work done; they just have to stop mistaking them for the world. In the philosophy chapter he wrote flatly: "Data models are tools." They don't contain the "true" structure of information, and much of what users call learning a model is really bending their view of their own business until it fits the tool[6].

Entities, identity and naming

The core topics of the book, in Kent's own later summary, are existence, identity, attributes, relationships, behaviour and modelling[6]. The first chapter, on entities, opens with a deceptively easy question: what counts as one thing? Questions of that kind follow quickly. Is a book one entity, or is each printed copy one? Is an employee who leaves and is rehired the same employee record?

For a recordkeeping system those questions aren't academic. Kent showed that names and identifiers are not the things they denote. The same person can appear under several names; one name can point to several people; an identifier can be reassigned. His 1983 paper makes the point technically. If people have no unique identifiers, a table can hold "John Smith, 123 Main St., New York" and "John Smith, 321 Center St., San Francisco", and no functional dependency appears in the data even though every person has only one address. Spell the same address two ways ("123 Main St., New York" and "123 Main Street, NYC") and the dependency vanishes too[3]. Normal forms, he concluded, are only properly defined where unique and singular identifiers exist.

Attributes versus relationships

Another recurring theme is that the line between an attribute and a relationship is drawn by the modeller, not by nature. An employee's department can be stored as a field (an attribute) or as a link to a department entity (a relationship). Colour can be a property of a car or an entity with its own facts. The 3rd edition still carries chapters titled "Attribute vs. Relationship", "Are Attributes Entities?" and "Attribute vs. Category"[4]. Practical modellers who draw an entity-relationship diagram meet this choice daily, and Kent's point was that neither answer is "correct" in any absolute sense.

Limits of the record

In the 1979 TODS paper Kent turned the same critique on the record model itself: the habit of describing information as fixed-format records of fields, typed and instanced in a rigid way[5]. Record structures bake in assumptions (every instance has the same fields; one record per entity; types fixed in advance) that the real world often breaks. That line of thought led him towards object models at HP, where identity is separate from attribute values.

Example of Kent's normal forms

Kent's informal rule for second and third normal forms is easy to remember: a non-key field must provide a fact about the key, the whole key, and nothing but the key. First normal form is about the shape of the record: "Under first normal form, all occurrences of a record type must contain the same number of fields"[3]. The following hypothetical order file, built for this article, walks through the three steps.

Step 0 - unnormalised. A clerk keeps one line per order with a repeating group of products:

Order Customer Customer name City Products (no., name, qty)
1001 C1 Alder Ltd Leeds P1 Bolts M8 200; P2 Nuts M8 500
1002 C2 Birch plc York P1 Bolts M8 100
1003 C1 Alder Ltd Leeds P2 Nuts M8 300; P3 Washers 1000

Records have a variable number of product entries. That breaks first normal form.

Step 1 - first normal form. One row per order line, every row with the same seven fields. The key is the pair (Order, Product).

Order Product Product name Qty Customer Customer name City
1001 P1 Bolts M8 200 C1 Alder Ltd Leeds
1001 P2 Nuts M8 500 C1 Alder Ltd Leeds
1002 P1 Bolts M8 100 C2 Birch plc York
1003 P2 Nuts M8 300 C1 Alder Ltd Leeds
1003 P3 Washers 1000 C1 Alder Ltd Leeds

Five rows, 35 cells, total quantity 2,100 units. Now look at the trouble. Alder Ltd's city is written four times. If Alder moves to Bradford, four rows must change, and missing one leaves the file contradicting itself. "Nuts M8" appears twice. Delete order 1002 and the only record of Birch plc being in York disappears.

Step 2 - second normal form. Product name depends only on Product, and the customer fields depend only on Order: both are facts about part of the composite key. Split them out:

  • Order line (Order, Product, Qty) - 5 rows
  • Product (Product, Product name) - 3 rows
  • Order (Order, Customer, Customer name, City) - 3 rows

Each product name is now stored once. Alder's city still appears twice, once for each of its orders.

Step 3 - third normal form. In the Order table, Customer name and City are facts about Customer, which is not the key. That's exactly the EMPLOYEE-DEPARTMENT-LOCATION pattern from Kent's paper[3]. Split again:

  • Order (Order, Customer) - 3 rows
  • Customer (Customer, Customer name, City) - 2 rows
Change to make 1NF table after 2NF after 3NF
Alder Ltd moves city (rows to update) 4 2 1
Rename "Nuts M8" (rows to update) 2 1 1
Record a new customer with no orders impossible impossible 1 new row
Delete order 1002, keep Birch plc's city lost lost kept

Oddly enough, the total number of cells barely moves (35 before, 33 after). Storage was never the main argument. Integrity was. With a customer who has 400 order lines instead of 4, the first design needs 400 edits for one change of address; the third needs one.

Kent added a warning that is often skipped in textbooks. Normalised designs "tend to penalize retrieval", because data once read from one record must now be joined from several, and "there is no obligation to fully normalize all records when actual performance requirements are taken into account"[3]. Fourth and fifth normal forms, which he treated next, deal with multi-valued facts such as an employee's several skills and several languages; the example above stops at third because most business files do too.

Influence

The normal-forms guide became a common reading in database courses and practitioner training because it gave working programmers a vocabulary that didn't require relational algebra. Kent's acknowledgment thanked Ted Codd, Ron Fagin and Chris Date, the people who had defined the forms formally[3], and Codd's 1970 relational model paper remained his starting point[7].

Data and Reality had a slower, stranger career. Kent himself admitted in 1998 that, despite critical acclaim, the book had been "a sleeper for over twenty years" outside a small circle of enthusiasts[6]. Its readers, though, were influential. Richard Soley, chairman of the Object Management Group, credited Kent with reminding him that data "was only a representation of reality, and not the reality itself"[6]. In 2012 data modelling author Steve Hoberman prepared a third edition with updated examples and commentary, and the publisher added a note by Chris Date on the republication[4].

The book's questions about identity and meaning later found a second audience among people working on ontologies, topic maps and the semantic web, where the same problems (when do two identifiers refer to one thing?) reappear at internet scale. Pieter Wisse, for example, built a 2008 paper on ontology around a reading of Data and Reality through Russell's logical atomism[8]. In knowledge management and enterprise information management the book is a common reference whenever a project discovers that "customer" means three different things in three departments.

Criticism and limitations

Kent's work has its critics, and he anticipated some of them.

  • Problems without solutions. Data and Reality is mostly a catalogue of difficulties. Reviewers praised it for "not offering an own solution as remedy for all evils"[6], but a practitioner who wants a method may close it feeling unarmed. Kent did sketch his own ideas of a good modelling system near the end, yet these are tentative.
  • Constraints not removed. Wisse argued that Kent draws attention to limiting assumptions but, when it comes to practising conceptual modelling, doesn't remove them; the object remains the basic unit of his ontology[8].
  • Informality. The 1983 guide admits that "in its informality it may be imprecise in some technical details" and refers readers to Date for a rigorous treatment[3]. Its "single-valued fact" is close to, but not the same as, a functional dependency, and its design guidelines are slightly stronger than the formal definitions.
  • Normalisation is not the whole of design. Kent himself said normal forms cover only redundancy inside a single record type; redundancy across record types, and the whole job of choosing the initial data elements, lie outside them[3].
  • Dated technology. Many examples in the 1978 text refer to punched cards, hierarchical and network databases. That is partly why the 2012 edition was rewritten.
  • Pessimism about formal models. Readers trained in relational theory, which rests on predicate logic, may find his claim that no adequate formal modelling system probably exists too sweeping. He offered it as a hypothesis supported by examples, not as a proof[6].

Related approaches

Kent's work is usually read alongside the relational model of E.F. Codd[7] and Peter Chen's entity-relationship model[9], both of which supply the formal tools he questioned. Today his ideas show up in discussions of information quality, data governance, master data and the information life cycle, anywhere an organisation has to decide what its data actually refers to. For background on how data turn into meaningful information see data and information and information processing.

References

Footnotes

  1. ↑ Family of William Kent, William (Bill) Kent, 1936-2005 (obituary), bkent.net, 2005
  2. ↑ Kent W., Bio, bkent.net, 2000-2001
  3. ↑ Kent W., A simple guide to five normal forms in relational database theory, Communications of the ACM, 1983, sections 1-3, 6-9
  4. ↑ Kent W., Hoberman S., Data and Reality, 3rd edition, Technics Publications, 2012 (publisher's description and table of contents)
  5. ↑ Kent W., Limitations of record-based information models, ACM Transactions on Database Systems, 1979, pp. 107-131
  6. ↑ Kent W., Data and Reality, 2nd edition, 1stBooks, 1998, prefaces and chapter 12 "Philosophy"
  7. ↑ Codd E.F., A relational model of data for large shared data banks, Communications of the ACM, 1970
  8. ↑ Wisse P., The ontological atom of behavior, Sprouts, 2008
  9. ↑ Chen P.P., The entity-relationship model - toward a unified view of data, ACM Transactions on Database Systems, 1976
William Kent — recommended articles
Database — Entity-relationship diagram — Data and information — Information management — Management information system — Information system development — Quality of information
Retrieved from CEOpedia