Papers and Publications
Here are links to some papers, publications, and short notes:
"What don't we get about ____?" commentaries on Social Justice issues.
"Copernican Revolution in Data (Processing)" an excerpt from my Database Management McGraw-Hill textbook, 1986. The idea that we must take a data centric view of our information systems and in our organizations is not new.
Gordon C. Everest, "Basic Data Structure Models Explained With A Common Example" Computing Systems 1976, Proceedings Fifth Texas Conference on Computing Systems, Austin, TX, 1976 October 18-19, pages 39-46. (Long Beach, CA: IEEE Computer Society Publications Office). Original paper using a notation for relationship characteristics. Thought to be the first to use what is now called a "fork" to represent multiplicity in a relationship. An updated version appeared as Chapter 4 in Database Management: Objectives, System Functions, and Administration, McGraw-Hill, 1986.
"Improving the Conduct and Delivery of Online Courses" 2009 December.
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.
*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.
*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.