Valerie Harvey harvey at rmu.edu
Wed Jan 4 13:51:45 EST 2006

Kenneth Lloyd wrote:

Between the domains of computer
programming, software engineering, and computer science - and even the
liberal arts domain - there has been no talk of using an intermediate
modeling language like the UML to relate them.  I find this sort of
in that the formalism underlying the UML directly relates to the
math and graph theory, patterning, best practices, and so much more. "

Kirby Ulmer wrote (if I got it right):
"So, for example, SQL appears in math class in tandem with Venn
sort of as an application for Boolean logic and the concepts of union
intersection.  They query against pre-filled databases, likely involving
popular music and films, other content of intrinsic interest.  
They might come to SQL again later, in a biology class, and so some
queries against a genome or species DB."

My experiences lead me to see three roads to SQL: (1) early teaching of
Prolog (as was envisioned for the middle school level in the UK some
time ago), (2) set theory/Venn diagrams, as has been mentioned (and,
even categorical logic), and (3) information modeling. About 20 years
ago I began using Prolog early in computer science database courses to
introduce relational concepts and get student accustomed to working with
predicates (I now do that within the context of a discrete math course).
I found students with prior Prolog experience did much better in SQL. In
spite of "warts," I would like to see SQL interoduced earlier. Set
theory makes a good context for teaching SQL. I like the recommendation
of teaching UML. Beginning in 1988 I spent several years on NCITS
(formerly X3) standards committees, including the old Database Systems
Study Group, and in this context learned the important of information
modeling. I learned the weakness of modeling tables rather than objects,
and I learned that one needed to model above the "technology level."
Relational databases have their own artifacts, the most intrusive and
troublesome of which have to do with multiples. When I asked consultant
members of the DBSSG what were lead most commonly to the sorts of
problems (disasters) that afflicted database designs they were called in
to deal with (on an emergency basis), I was told that the root of most
of the troubles could be seen in multiples (therefore a modeling problem
that needs to be addressed before one can worry too much about SQL). If
your modeling technology directly models many-to-many relationships, for
example, you do not have to interpose an intersection (or junction)
table to accumulate combinations of foreign keys. This means students
can focus on recognizing many-to-many relationships and the presence of
multiples in interpreting the information gained from systems analysis.
They learn what kinds of (simple) questions to ask to be certain they
have a correct understanding of the business rules. It is possible to
design exercises and assessment that focuses on the capability the
recognize relationships. They come to see the power of what is expressed
in cardinalities (not a revealing word, in German the term
Beziehungstypen in easy to understand). Because of accessibility (free
download) and relatively short learning curve, I have used
TableDesigner, based on David Kroenke's Semantic Object Model concepts.
In this tool, the students can create a design and then implement it in
MS Access, MS SQL Server, or as a schema. Then it is obvious that
correct specification of cardinalities at the (semantic) object level is
sufficent to gain a correct implementation (with the appropriate
artifact tables, if needed, and foreign keys) in a particular
technology, such as SQL or MS Access. Engineers, marketing experts,
management, the people Haim Kilov calls the Subject Matter Experts
(SMEs), are not interested in the "third table" in many to many
relationships and shouldn't have to discuss it. The emphasis should be
on getting a correct model and specification in the first place. I have
found that people who want to work with databases learn best by first
developing (and populating) some simple ones, whether in SQL or in the
VA's File Manager architecture (and among my teaching assignments has
been teaching clinicians and hospital administrators how to extract
useful data from VA FileMan databases in an extremely complex hospital
information system with thousands of files/tables). 

So, to repeat, I like the idea of introducing SQL earlier, and of using
UML (or an alternative) to help people think about the design of
databases and queries.

Valerie Harvey

Valerie J Harvey RT(R) PhD
Professor, Computer & Information Systems
Robert Morris University
6001 University Boulevard
Moon Township, PA 15108-1189
412-262-8467 (Moon)
412-227-6831 (Pgh)
Office (Moon): Nicholson Center, Room 445
Office (Pgh): ACE Center, Room 705D

More information about the Math-thinking-l mailing list