List

Simsion, G., Simon, M., and Shanks, G. “Data modeling: Description or design?” Information and Management 49 (2012): 151-163

  • The authors note that data modeling might also be thought of as “reality mapping” (151), or a descriptive process that isn’t necessarily design but documentation. The authors want to argue against this perspective, noting that “there is a choice in the selection of components.”
  • The “Universe of Discourse” perspective is descriptive and considers the model as trivial; the design perspective argues that the model is “the essence” of the process (151).
  • The research question: Is data modeling better characterized as description or design? (151)
  • Why is this question important: 1) Most data modeling research assumes the descriptive characterization, notably in the design of experiments and in the application of ontology. If data modeling is, in fact, design, research results need to be interepreted as such; 2) Data modeling education should include expert level practice; 3) Creative thinking and evaluation of alternative designs are intrinsic to the design process. If data modeling is seen as a design activity rather than description, then data modeling methods should be updated to reflect a design process and explicitly include creative thinking and comparative evaluation (152). [1. These points on the design orientation vs. the description orientation emphasizes the rhetorical nature of database design and should be relied on heavily to draw intersections between the work of database designers and rhetoricians. When thinking about how to provide an in for your readers – rhetoricians and technical writers – this would probably be a good place to start.]
  • Data modeling defined: a set of activities required to specify a conceptual schema that will transform into a database schema but prior to its transformation into a specific DBMS data definition. (152)
  • Lawson’s (very useful) properties of design:

Figure 1

  • A key discovery: The authors posed the problem: “Are business requirements negotiable (by the data modeler?)? They found that folks that considered data modeling a design activity “should be active in exposing new ways of doing business” (153). Description modelers argued the opposite, insisting that businesses determine models and that domain experts, not modelers, should be in command.
  • Another key insight: Design oriented modelers felt that there were more than one correct model; description oriented modelers did not. Again, this binary ended up organizing around the authority of SME/DE.
  • The authors survey data described the modeling process as: 1) Business requirements analysis [2. The key step for your work . . . if this is considered design work, and not description, you might consider the business requirements analysis in an inventional light – it’s here that the design/rhetorical mind flourishes.]; 2) Conceptual data modeling; 3) Logical data modeling; 4) Physical data modeling or Physical database design; and 5) Post-database-design activities (optional) (154).
  • Universe of Discourse: from cs.com wiki – “In formal logic, an argument is defined over a universe of discourse. Every argument and every statement made in that universe applies to all entities in the universe. There are no subdivisions of any kind. Every sentence in formal logic is a context-free sentence.” [3. Obviously, this is diametrically opposed to any rhetorical orientation to language as contextual. The UoD model in it’s absolute form is completely arhetorical but does seem to establish the boundaries of many formal coding languages and database architectures as code leaves no room for ambiguity.]
  • The authors characterize the description orientation as an “accountant of data” while the design orientation is described as an “architect of data.” (155)
  • The authors demonstrated that when challenged with the same data model problem, modelers overwhelmingly developed alternative models. This disrupted the notion of modeling as descriptive and reinforced the notion of modeling as design (157).
  • A big takeaway from the text: “Data modeling teachers should consider it a design activity. Designing data modeling tasks by articulating a domain based on nouns and verbs that relate to the entity types and relationship types (E-R) is a way to teach data modeling notation but it does not teach the practice of data modeling” (159).

Leave a Reply