of Data Rambling Through My Mind
constantly have random database-related thoughts that
build up over time. I thought it would be useful and
interesting to group some of these thoughts together
into a column, sort of like Andy Rooney meets IT.
you ever wonder why e-mail systems don't use database
management technology? Do you store some of your
e-mails for long periods of time? Do you group them
into folders? Are they hard to find later? And the
substance of the message isn't usually obvious from
the folder name you gave it (which made sense at the
time) or the subject of the e-mail (which might not
have anything to do with the actual content). I'd love
to be able to use SQL against my e-mail system,
writing something like:
FROM ALL OF MY E-MAIL FOLDERS
WHERE TEXT CONTAINS "NEW DB2 PRODUCT
bet a DBMS that interfaces to or integrates with
e-mail would be a rousing success.
you noticed that relational technology is taking a
beating these days? With new "data models"
purported to be better than relational, it seems that
the industry is all too ready to stick a fork in
are no true relational database management systems.
DB2 and Oracle and SQL Server, though based on the
relational model, do not support all of the features
that would make them truly relational. They are better
termed "SQL DBMS products." Before sounding
the death knell for relational, shouldn't we at least
try a fully relational DBMS first? Keep in mind that
the three largest software companies in the world
today are the three biggest providers of
relational--well, SQL--database technology: IBM,
Microsoft, and Oracle. These companies’ database
products are successful because they are useful, and,
in fact, help companies manage and access their data.
is it important for my DBMS to be relational? My DBMS
works just fine as it is, how could relational help?
With SQL, you have a language that is non-orthogonal.
You can write the same data request in many ways. This
can cause performance problems and confuse
programmers. Another problem--current SQL database
systems permit the creation of tables that can contain
duplicate rows. The relational model is based on set
theory, and a set cannot contain duplicate members.
And there are significant features that current SQL
database systems omit, such as domains. A domain is
basically the set of all valid values for a particular
column (or attribute). It is flexible, so you can
define the valid values more precisely than a mere
data type. But a domain actually defines the valid
operations and comparisons that can be performed on
columns assigned to that domain. Because SQL DBMS
products lack domains, it is completely legal to code
the following predicates:
AVG(SALARY) > PHONE_NUMBER
WHERE SHOE_SIZE = IQ
WHERE AGE = FIRST_NAME
are not useful predicates. But if each of these
columns were assigned to a different domain,
comparisons between them would be disallowed, because
comparisons between incompatible domains would be
disallowed. And values outside the scope of the domain
could not be assigned to the column. And these would
be good things because it would boost data integrity
and data quality.