TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Relational Database vs. NonrelationalL From:JIMCHEVAL <JIMCHEVAL -at- AOL -dot- COM> Date:Thu, 14 May 1998 12:19:34 EDT
In a message dated 98-05-14 10:01:20 EDT, AdamsC -at- MEDISPAN -dot- COM writes:
<< Can anyone out there give me information on differences between a
relational database vs. nonrelational? >>
nonrelational is also called 'hierarchical' or 'flat'.
Basically, before computers, that's all there was. A telephone book is the
obvious example: to find a number, you first have to know higher elements in
the hierarchy of information - first the city, then the name. As a data
element, 'telephone number' ends up at the base of the hierarchy.
Computers allow all data elements to be stored as peers, so that 'city',
'name' and 'telephone number' all have equal importance and are linked via
'relationships', not via a single overall hierarchy. If you have only a
telephone number and want to find the associated name, you can sort or search
based on their relationship to each other. Often, this involves creating
temporary hierarchies (sorts), but the hierarchy is a function of the
particular search and not of any fixed structure in the stored data.
(The specific 'relationship' referred to is actually the data element which
links two or more tables - a customer ID that relates a Customer table to an
Order table, for instance.)
The actual implementation of this fairly simple idea can get extremely
complicated, involving concepts such as 'tuples' and 'referential integrity',
and distinctions between 'rows' and 'records' or 'tables' and 'files' - not to
mention Codd's 12 principles. But the essence of the idea is that in
traditional (flat) files, the data is stored (and retrieved) in a certain
hierarchy, in relational 'files' (really tables in a database) it isn't.
The most common tool for manipulating relational data is SQL (Structured Query
Language), which originated in DB2, but now exists in multiplte flavors
(Oracle, Foxpro, SQLServer, etc.)
