IDSc 4431. 2014 Spring
Gordon C. Everest, editor, Carlson School of Management, University of Minnesota
NOTE: We tested several links, but they can change.  Please report any links that no longer work.
* - Reading priority (**Higher priority).   Those links followed by "?>" were not working and are being investigated.
NOTES:  ● Several magazines merged into Intelligent Enterprise which was subsequently acquired by InformationWeek (along with many other journals of interest to us.  Unfortunately, they only archived back to 2004.   ● DM Review archives only go back to 1997/11.     ● For tdan (The Data Administration Newsletter), click on ‛Archives'.


DATE, C. J., "Thirty Years of Relational: Relational Really Is Different," Intelligent Enterprise (2:7), 1999 May 11. Unfortunately, this is no longer available online. Intelligent Enterprise  was acquired by InformationWeek and they only archived back to 2004.
Reviews the development of the relational data modeling scheme and compares it to the CODASYL Network model.  Can you determine the differentiating characteristic(s) of a relational data model? See separate link for the figures.

**CODD, E.F., "Is Your DBMS Really Relational?" Computerworld, 1985 October 14, 3 pages. [©)]
Follow the link on the IDSc 4431 course website to access the article.
< > for another abbreviated version.
As you read Codd's 12 rules (actually 13 with Rule 0), which rules help to distinguish a relational DBMS from all other types of DBMSs?  Which rules are uniquely relational as opposed to being good for all DBMSs?  Are the rules helpful to users?  to vendors of DBMS?  to our knowledge of DBMS in general, or Relational in particular? See separate link.

*KENT, William, "A Simple Guide to Five Normal Forms in Relational Database Theory," Communications of the ACM (26:2), 1983 February, pages 120-125. [©)] < >
The classic, comprehensive, and easy to read explanation with examples, of five of the rules of database normalization.

OWENS, John, “Big Data x 5th Normal Form = Really Big Data Errors,” 
Another good example of 5th normal form in particular and the dangers inherent in NOT recognizing it. 


*KEUFFEL, Warren, "Battle of the Modeling Techniques," DBMS (9:8), 1996 August, page 83 (4p). and Letter in response, "What About ORM?" Dick Barden, et al., DBMS (9:10), 1996 October, (2p).
Evidently the link to the “What About ORM?” letter to the editor does not work.
A good account of the evolution of some data modeling schemes.  Compares three major streams: (1) ER modeling originated by Chen, and its manifestation in IDEF1X, originated by the U.S. DoD, developed by Dan Appleton, described in a book by Tom Bruce, and embodied in a design CASE tool called ERwin, now from Computer Associates, (2) NIAM, originated by Sjir Nijssen, and a forerunner of Object Role Modeling (ORM) from Halpin, and (3) the Semantic Object Model (SOM) by David Kroenke, as described in his book and in his Salsa tool.  The comparison suffers from a weak understanding of NIAM, as revealed by a subsequent Letter to the Editor, written by three advocates residing (still) in the Twin Cities.
*HAY, David, “Kinds of Data Models -- And How to Name Them,” a 35 minute video on YouTube along with some discussion.
For an extensive discussion in LinkedIn, go to:
Or go to the “Data Modeling” discussion group on LinkedIn and search for the title above.
David takes a stab at clarifying the notions of Conceptual Model, Logical Model, and Physical Model.  Confusion over the distinctions has raged in the industry for decades.  This video captures the prevailing thinking, but note how it differs from the approach of Halpin (and myself).  Essentially an update of the 3 part article from 2003 (listed next).

HAY, David, "What Exactly IS a Data Model?" a 3 part article, DM Review, 2003 February, March, April.  < >11 for February.  < > for March.  < > for April; be sure to click the embedded link for Figure 1.
An excellent set of articles which go into some depth to explain various levels of data models based on who uses them.  External data models for the business user; conceptual models for the architect; logical models for the designer (recognizing that external and conceptual models are also logical models); and physical models for the database builder.  Each level of data model can be represented diagrammatically using any of various data modeling schemes -- ER, Barker, IE, IDEF1X, UML, ORM.  Hence, the choice of diagram notation is not what differentiates these levels of data models (although there are differences in what each notational scheme can represent - e.g., ternary or many-to-many relationships).  The author also describes business rules, relational databases, and object models, and how they fit into the overall subject of data models.  Hay is understandable, thoughtful, clears up some confusions, and is generally accurate in his writings.

GORMAN, Michael, "Great News – The Relational Model is Dead!" The Data Administration Newsletter(8), 1999 March, (11p).  < >11 or go to the author's web site < > and click on 'SQL Standards' and scroll down to “Great News...”.
Gorman has been the secretary for over 20 years to ANSI X3H2, the committee responsible for the SQL standard.  He describes the basic characteristics of the new SQL:1999 standard and why its data structure is no longer relational.  For x431 focus on the structural aspects - intra-record structures and inter-record relationships.  Figure out what is different from the SQL2 (1992) standard, and your understanding of what is a relational data structure.  There have been subsequent releases.

DATE, C. J., "Great News, the Relational Model is very much alive!" Database Debunkings, 2000 August. <searching for a live URL.  Let me know if you find one.>
A response to Gorman's "Great News" article.  Do you think Date understands what Gorman has to say?


HAY, David, "Object Role Modeling (ORM)," 1999 (6p).  < > scroll down and click on 'A Comparison of Data Modeling Techniques', scroll down, and click on 'ORM' (look at other stuff along the way).
Another summary overview description of ORM, along with a description of other data modeling schemes.

FRANK, Maurice, "DBMS Interview: Asymetrix Corp.'s Dr. Terry Halpin - Black Belt Design," DBMS (8:9), 1995 September, page 38 (5p). 
An interesting interview in which Halpin provides some background information about himself, his job at Asymetrix (acquired by Visio which was acquired by Microsoft so Halpin ended up working for Microsoft until 2002 September), ORM and how it compares to ER modeling and Kroenke's Semantic Object Model, and on CASE tools for data modeling, in particular, InfoModeler (which eventually became VisioEA from Microsoft). 

*BECKER, Scot A., "Arguments against the Use of ORM (and their Rebuttals)", Journal of Conceptual Modeling (14), 2000 June. 
Recognizing that ORM is not widely used (but is widely misunderstood), Becker provides rebuttals to several of the most common arguments against the use of ORM.
HALPIN, Terry, Ken EVANS, Patrick HALLOCK, and Bill MacLEAN, Database Modeling with Microsoft Visio for Enterprise Architects, Morgan Kaufmann, 2003, 426 pages.
Indispensable in explaining how to use the Microsoft VisioEA data modeling tool, and how the tool supports the concepts and constructs in ORM.  It also provides some background and context for understanding VisioEA.  Expansion of the material originally published in the Journal of Conceptual Modeling.  No longer important since we are now using NORMA.

EVEREST, Gordon C., "NIAM/OR Modeling:  Student and Expert Solutions," International Conference on Conceptual Modeling - ER96, Cottbus (Berlin), Germany, 1996 October 7-10, 17 pages.
        [available as separate handout later]


*DATE, C. J.  "Subtypes and Supertypes: Setting the Scene," Database Programming & Design, 1999 Feb.
One of few authors who gets in right and really understands the notions of subtypes and supertypes in a data structure, and how that contrasts with subtyping and inheritance in an object-oriented programming language (they are different!).


HAY, David C., "Data Model Views," The Data Administration Newsletter (12), 2000 April.   < >. 
Discusses combining different user views into a comprehensive, conceptual enterprise view of data, and conversely, the presentation of subparts of a conceptual enterprise data model to different users or for different purposes.   Emphasizes the importance of separating the way (part of) a model is presented from the underlying conceptual model.  Provides several examples of situations where views are useful - to highlight a hierarchical view within a more complex conceptual model, when different users see things differently, etc.  Concentrate on the first three pages and the Recommendations at the end.

HAY, David C., "Making Data Models Readable," Information Systems Management (15:1), 1998 Winter, pages 21-33.  Available at:  < > and scroll down to find it under 'Data Model Quality.'
Another from a solid contributor with a sound understanding of data modeling.  Hay demonstrates a passion for helping people understand how to read a graphical data model.  This article is filled with suggestions to improve readability and to avoid confusion and ambiguity in the presentation of  data models.


*EVEREST, Gordon C., "Users Do Logical Database Design," CAD/CAM Databases '87 Conference Proceedings, Management Roundtable, Inc., Boston, MA, 1987 April, 28 pages. 
Describes an actual experience in conducting database design project meetings with a group of users - the process, the product, some observations made along the way, and a discussion of lessons learned. 

*SIMSION, Graeme, "Data Modelling: News from the Ivory Tower," The Data Administration Newsletter, 2007 January, 8 p.  < >
After many years in the practitioner/consulting world, Simsion went back to the University of Melbourne to look at data modeling from a research perspective.  He found a big disconnect.  This paper is a preliminary report of his findings, and a good follow-on to his earlier paper, "You're Making it up!"  (see below).

*SIMSION, Graeme, "Data Modeling Essentials: Five Things You Should Know," Information Age, 2005 February. < posted on course website >
From a practitioner and consultant in data modeling, Simsion makes some statements about the nature and practice of data modeling.  Some of his ideas were (and still are) quite controversial.  However, he does know what he is talking about stemming from a broad base of experience.

SIMSION, Graeme, "You’re Making it up! Data Modeling: Analysis or Design?" The Data Administration Newsletter, 2004 October. < >
More on the nature and practice of data modeling.

*PELKKI, Matthew H., Gordon C. EVEREST, and Dietmar W. ROSE, "Using Accelerated and Extended Approaches for Data Planning and Design," the Compiler(13:3), 1995 Fall, pages 27-33. [©]
This research study compares and contrasts these two distinctly different approaches to conducting database design projects, stemming from a unique opportunity at the Minnesota Department of Natural Resources.  It describes how the projects were undertaken, makes some observations, and then draws some conclusions and generalizations about how a design project should or should not be conducted. 

EVEREST, Gordon C., "Collaborative ORM Data Modeling:  Educational Experience using a Wiki."  Presented at the annual ORM Workshop, Vilamoura, Algarve, Portugal, 2007 November 28-30.


*Von HALLE, Barbara and David PLOTKIN, "The Art of Letting Go: Relaxing your data focus can do wonders for your Business Rules," Database Programming & Design (10:2), 1997 February, pages 11-14 (3p).
Read this to discover how they define business rules.  What is included in the notion of business rules?  Is this something new?  How do business rules relate to common generally accepted concepts in the realm of database management?

HALPIN, Terry, "Business Rules and Object-Role Modeling," Database Programming & Design (9:10), 1996 October, pages 66-72 (6p).  Available at < > and click on 'ORM in Detail' or to < > to download a .pdf file.
ORM in a nutshell - a good overview/review - duplicates the text.  Anything new here under business rules?