by: Gordon C. Everest, Professor Emeritus, <firstname.lastname@example.org>
Carlson School of Management, University of Minnesota.
Dr. Everest enjoys giving talks to data management professionals and students. These presentations are very well received, engaging with lots of stimulating discussion and interaction. They are challenging, informative, and fun. Even after lunch the attendees will not fall asleep!
Click Brief Resume for a biographical sketch.
LIST OF POSSIBLE TALKS:
In the listing below, there is a short description, suggestions for TIME duration, and WHERE the talk has been given. Each of these can stand alone; with some basic understanding of databases. Presentation talks can range from 1 hour to a ½ day or more. Some can be cut from their recommended time to a shorter time, say 1 hour. Most would have a substantial workshop/hands-on, and discussion component, when presented in a half day.
The more popular topics are marked **. Each is described in more detail on a separate page, just click on the title. The longer descriptions can serve as an abstract for your announcement.
This presentation challenges the common understanding of conceptual, logical, and physical data models and offers some alternative ways to think about them. Rather than thinking of levels of data models, we should think in terms of stages of data models. Data modeling schemes differ in when particular constructs are introduced. For example, at what stage can we introduce foreign keys, identifiers, or first normal form? Do these belong in the initial stages of data models? I would argue not. The presentation wraps up with a chart showing the sequence in which various data modeling constructs are introduced. This presentation can be broken down into two.
Presented as a half day to DAMA Kansas City chapter, 2015 September.
Here we challenge the traditional view of these being levels of data models. First, by looking at the dictionary meaning of these three terms. Then presenting an alternative view. We conclude that a conceptual model, as commonly viewed, is not a different type of model, but rather an abstracted view of a more detailed underlying model. Thus, it is a matter of presentation not of modeling. We also conclude that all data models are logical models since they are developed according to some logical data modeling scheme. There is also confusion about what elements of a data model are moving into physical storage and implementation. If these three terms do not help us distinguish data models, what do we call a data model which includes all of the semantic detail of the user domain being modeled, but without including any constructs or elements which are really in the physical implementation realm. Is a relational data model logical or physical (with its entities, attributes, and tables satisfying 1NF)?
This makes a good 1 hour presentation.
WHERE: Data Modeling Zone, Portland 2016 October; DAMA Minnesota, 2016 June.
Fact Modeling is a different way of thinking about data modeling, as distinct from the popular ER or Relational (ERel) modeling scheme. It is based on the modeling of facts taken from narratives of user domain experts. Rather than modeling data we are actually modeling the world of the user domain. From that we can design a database. An elementary fact sentence consists of one predicate phrase and one or more objects. For example, "Person works in Department" is a binary fact. With constraints it might read "Person must work in at most one Department." In language, the nouns become objects, the verbs or predicates become relationships, and the qualifiers generally suggest constraints.
This session is a combination of the next two presentations (ER Limitations and ORM Intro) with more emphasis on generic Fact-Based or Fact-Oriented Modeling.
TIME: 2-4 hours, the longer version includes more on the problems with ERel data modeling which motivate the need for the Fact Modeling approach, and a demo of NORMA, the open source modeling tool for ORM. It is like magic to see the relational tables automatically generated from an ORM diagram, guaranteed to be fully normalized.
WHERE: half day tutorial at Enterprise Data World, San Diego, 2016; Data Modeling Zone, Portland, OR, 2014 (rated 8.7/10); DAMA Puget Sound (Seattle) Chapter, 2014.
This one really challenges you to think about what we do as data modelers. It not only tells you what is wrong with ER/Relational modeling but also points to a better way to do data modeling using Object Role Modeling (ORM). It is a good one for my first talk to a group. Some of this has been shortened and incorporated in "Fact Modeling Fundamentals."
TIME: best for half day.
WHERE: DAMA Portland and Sacramento, 2008; presented as a 3 hour workshop at DAMA International EDW Symposium, 2008 - very well received with a rating of 8.8/10 overall, and Effectiveness of speaker = 9.1, one attendee said "We need to have this talk again next year for those who missed it"; Minnesota chapter of Professional Association of SQL Server users (PASSMN), 2007 (Overall presentation rating was 4.9 on a 5 point scale, with a 5.0 on speaker's presentation skills); DAMA Iowa, 2005; DAMA Minnesota, 2001
"Introduction to Object Role Modeling (ORM) -- A Better Way to do Data Modeling"
A good follow-on to "Overcoming the Limitations of ER Modeling." Having whetted your appetite with the problems of ER/Relational modeling and after giving you a taste of Object Role Modeling (ORM) as a better way to do data modeling, this presentation delves more deeply into the basics of ORM.
TIME: Best as an all day tutorial, but could be a half day, or even an hour.
WHERE: Data Modeling Zone, Baltimore, 2012/10; DAMA EDW 2011 as a ½ day workshop entitled "Rethinking how we do data modeling"; PASSMN, 2008; Given as a 3 hour workshop at DAMA International EDW Symposium, 2007;
"Data Modeling Challenges -- try to find the right answers"
Presented with several data modeling situations or scenarios, attendees are asked to answer some questions, pick the correct model from among several plausible but wrong choices, or to develop a data model design for a given set of semantics. These problems are cast in an ER or Relational modeling scheme. Each challenge is used to illustrate and emphasize design principles which are often not recognized. We also suggest alternative ways of thinking about modeling problems to more easily arrive at the correct solution. Even though these modeling problems are rather simple, they are still challenging, even to a seasoned, professional data modeler/architect.
TIME: good for 1 hour. Done a few years back at EDW.
Even experienced data modelers often have trouble with normalization -- recognizing and knowing how to correct violations of the five normal forms -- especially to explain it to business users. Normalization is based upon some very simple concepts and principles. Learn how to do normalization correctly. A seemingly dry subject which comes alive and challenging in this presentation. Both novice and experienced data modelers can learn something from this one.
TIME: good for 2+ hours, could be done in 1 hour.
WHERE: Data Modeling Zone, North Carolina, 2015/10 and DMZ Portland, OR, 2014/10; DAMA EDW, San Francisco as a ½ day workshop in 2010 (rated 9.6/10 omitting one outlier - a disgruntled attendee who lacked the necessary background); DAMA International Symposium 2005; DAMA-MN, 1999;
**"Subtypes and Supertypes - the data modeler's most important construct"
Gets past the myths and misunderstandings, and shows you how to use subtypes and supertypes.
TIME: good for 2+ hours (could be cut to 1 hour)
WHERE: DAMA EDW, Austin, TX, 2014 as a ½ day workshop (rated 9.1/10); Data Modeling Zone, Baltimore, 2012/10; DAMA Phoenix, 2009; DAMA Iowa, 2006; DAMA-MN, 2005/6; DAMA International 2 hour presentation (a double session), 2006/4.
**"Presenting Data Model Diagrams... so people can understand them"
Some principles/guidelines, with several examples, both good and bad.
TIME: good for 2+ hours, could be done in 1 hour.
WHERE: DAMA EDW Conference, Chicago, 2011; DAMA Minnesota Presentation, 2006 November.
"Conducting Data Modeling Project meetings - best practices"
Best practices in working with business subject matter experts to gather information requirements which can lead to the design of databases to support their applications. Describes different methods (extended series of meetings, accelerated JAD session, interviews), when and how best to use them, and advanced preparations. Based on actual experiences and a comparative research project.
TIME: good for 2+ hours, could be done in 1 hour.
WHERE: Data Modeling Zone, North Carolina, 2015/10; DAMA EDW, Atlanta, 2012 (rating 8.0/10); DAMA International Symposium, 2004; DAMA-MN, 2004.
Compares and contrasts eight distinct types of databases: Single flat file, Hierarchical file, CODASYL network, Relational, ANSI SQL (1992 and 1999), Object-Oriented (and the Object-Relational hybrid), Dimensional model (star and snowflake), Object Role Model (ORM). What distinguishes each? This one is colorful and of more general interest -- always well received.
TIME: tight for 1 hour; comfortable in 2+. Sparks many questions and much discussion, to fill a half day.
WHERE: DAMA Minnesota chapter, MnIPS (Minnesota Information Professional Society), 2004.
Presents an overview and taxonomy of collaborative mechanisms, then presents experiences with students in groups using a Wiki for a comprehensive data modeling project. Points up some significant weaknesses when using a Wiki for data modeling,. Overcoming the weaknesses presents some challenges to the developers of data modeling tools.
TIME: - Comfortable in 1 hour; 2 hours allows an extended discussion with attendees on their use of collaborative mechanisms, and what needs to change to provide effective collaboration to virtual teams.
WHERE: International Workshop on Object-Role Modeling, Algarve, Portugal, 2007/11; MnIPS (Minnesota Information Professional Society), 2008; DAMA Minnesota chapter, 2009; DAMA International EDW Symposium, 2009 (rating 8.14/10).
An introduction to the subject of data warehousing -- objective, origin, and evolution; Inmon v. Kimball -- are they really different?; the basics of "cubes" v. star schemas, fact v. dimension tables (are they normalized?), snowflake; warehouse v. data marts; processing demands and new approaches for a data warehouse management system (e.g., star joins); architecting and managing the data warehouse environment.
TIME: could be one hour to a whole day.
WHERE: Keynote talk for a Data Warehousing Symposium, 2010; University of Wisconsin, Eau Claire, 20th annual information systems conference, 2005.