"The Relational Data Model [components]:
1. Structural part (tables)
2. Integrity part - keys (entity integrity) and foreign keys (referential integrity)
3. Manipulative part - Structured Query Language (SQL) or relational algebra"
--Course syllabus, School of CS & IS, Birbeck University
12/29/02
|
"There's no formal, standard definition of an XML database, although the XML:DB
Initiative (www.xmldb.org) describes such a database as one that defines a logical
model for an XML document (not for the data in the document), and manages documents
based on that model. The key point is the database "thinks and acts" based on XML - XML
goes in, and XML comes out, even though these products can physically store the
documents in an object or relational database or a proprietary storage model, such as
indexed files ... critics also point to the immaturity of the products and of XML
standards; the absence of a standard, reliable query language to match the SQL used in
relational databases; and possible data integrity problems."
--Unknown source
12/22/02
|
"Is there a standard Java implementation of the "relational model" (as described, e.g.
by C. J. Date in INTRODUCTION TO DATABASE SYSTEMS), with classes representing the usual
relational entities (tables, records, fields), and methods corresponding to the usual
relational operations? We have data stored in flat files, and we would like to perform
standard relational operations, such as joins, sorts, and generating views. I suppose
that we could set up a database server (e.g. MySQL, Oracle), and use the Java database
access API, but this goes against our goal to supply a simple stand-alone application.
After all, our application does not need to access huge amounts of data, so accessing
it via a traditional DB server is overkill anyway. Using flat files to store the data
allows us to easily bundle the necessary data with the rest of the application. But
still we would like to regularize the way the program manipulates the data internally,"
along the lines of the standard relational model."
--alt.comp.lang.java.programmer
12/15/02
|
"25. Suppose you are given the task of designing a tool to display simple frequency distributions on discrete-valued data elements. Assume that a frequency distribution would consist simply of the number of occurrences of each value for a particular data element, perhaps displayed in graphical form as a simple bar chart. The input to this tool is conceptually a "worksheet" of rows (records) and columns (data elements). The user would select data elements one at a time and would receive an individual frequency distribution bar chart for the selected data element.
Which of the following storage formats for a given "worksheet" makes computing the
frequency distribution in the context of the above tool most efficient?
a. A fully normalized relational database, potentially with multiple relations.
b. A separate flat file for each data element.
c. A single flat file with contiguously stored records.
d. A non-normalized relational database organized as a star schema."
Answer: 25b.
--Sample Question, Certified Software Development Professional, IEEE Computer
Society
12/08/02
|
Although Figure 14 includes a logical persistence model, the reality is that most experienced object mappers go straight from their OO models to their physical persistence model. The extra information that logical persistence models contain such as domain values for attributes (something significantly more complex in the OO world considering many attributes are other objects) and candidate keys (a spectacularly bad idea as we saw previously) can actually be included in your class model if needed. On the other hand, the one advantage of modeling candidate keys is that they indicate potential ways that your users will access data -- important information for tuning your database. However, how your users will interact with your system should be reflected in your use cases so once again I'm not so sure we actually need to model candidate keys.
--Scott Ambler, Mapping Objects To Relational Databases
12/01/02
|
"I need to design a pet database where customers get registered and then post their pet
deals. They are either for sale or just rehoming. Can someone please take a few moments
to have a look at what I have done so far and tell me if it is any good. This is my 6th
time redesigning the tables."
--https://dbforums.com
11/24/02
|
"Sorry to bother you with MySQL, but I don't have a clue about it... We are running a
little MySQL database here and nobody is really familiar with it (to put it politely).
Now we are discussing a backup "strategy" for it. The word is that you simply need to
copy the data files to a different disk (or tape) and that's it. Is that right? Even
when the database is running and open for users? Does anybody have some hints on how to
back up MySQL databases?"
--ORACLE Mailing List
11/17/02
|
Q:I need to know what are the main differences between relational DBs and old ones
(like dBase and other index based). I'd like to know pros and bad sides. If anyone know
a site where I can gather what I need, please post its address.
A: The primary difference is in the systems original intention. The "old" database
systems provided indexed (i.e., fast) access and very little overhead. They were
designed for maximum speed. "Relational" database systems are primarily concerned with
the integrity of the data first and speed second. They enforce referential integrity
and provide commit and rollback features (i.e, transactions) and are generally logged
for recoverability.
--http://dbforums.com
11/10/02
|
Q: Personally, I try set all columns NOT NULL whenever possible. Any other ideas?
A: Design to what your data dictates, although in most RDBMS's there is a slight
performance and size advantage to NOT NULL, so I design NOT NULL where I can and only
in certain cirucmstances do I use NULL.
Q: What would you suggest for a datetime field where the value is not known and should
therefore be not-applicable?
A: NULL sounds good to me.
--http://dbforums.com
11/03/02
|
"I want to gain some data support about using normalized database is better than
denormalized database because another development team suggest to break down some large
tables into so many smaller tables, they think that can speed up the performance of
database. But, I don't agree with them. Therefore, there involve some many arguments,
such transaction time, query time, and so on.
Do you have any research result or data that can prove which database design is better?
What's the best database design methodologies if these databases are distributed in
three or more locations and they will replicated frequently?"
--http://dbforums.com
10/27/02
|
"I heard about the Logical Design of the Software products. What is this logical
Design? Will it be usefull to do before starting the project? If any one knew about
this please explain me how to do. And if we have any tools or some other softwares for
LD. Please let me know."
--http://dbforums.com
10/14/02
|
Experience has shown that natural keys are one of the greatest mistakes of relational theory ... because they have business meaning.
--Scott Ambler, Persistence Modeling in the UML
10/06/02
|
"A PRIMARY KEY and a UNIQUE index are very similar. In fact, a PRIMARY KEY is just a
UNIQUE index with the name PRIMARY. This means that a table may contain only one
PRIMARY KEY because you can't have have two indexes with the same name."
--MySQL's Paul DuBois
09/29/02
|
"If your back-end database isn't a good match for your front-end development, you need
a new database. Cache, the high performance database from InterSystems, is a powerful
fusion of today's mainstream technologies: objects and SQL. Unlike Oracle and other
relational databases, Cache takes advantage of its efficient multidimensional data
engine to implement an advanced object model. It does not try to hide a cumbersome
relational engine beneath object-like wrappers."
--InterSystems Promotional Ad
09/22/02
|
"BM: I am writing a postgraduate assignment paper on the above topic. I have surfed and
checked on numerous reference books on this topic but not much of help is given. The
concentration was more on OODBMS mapped into RDBMS. My query here is: are the same, as
in vice-versa mapping? Anyone with some answer/clue to that pls reply me.
SL: Isn't this the case, where: Most OODBMSs are relational, but not all RDBMSs are OO?
So once you have an OODBMS, isn't it redundant to say "map to RDBMS"? Or are you saying
you just want to remove the OO properties of the DBMS? I sure wouldn't want that job!"
--Online Exchange
09/15/02
|
"Deferred to Design are the compromises between introducing new tables to eliminate
data redundancy (Normalization) and achieving acceptable performance. For design,
normalization requires that each data element have no internal structure (this rule is
part of putting data into first normal form). But this normalization is not the
analyst's concern as he builds the initial model. Indeed, at this early stage, there is
no realistic way of knowing whether the designer will choose to normalize the data--
and if so, what level of normalization will be achieved."
--Coad and Yourdon, OBJECT ORIENTED ANALYSIS
09/08/02
|
"Mr. Pascal seems to be unimpressed with XML as another presentation method tool. All
computer languages which retrieve data stored relationally normally report it back out
to the user in their own hierarchical view. I don't see XML to be any different in that
respect, but I do see the benefit of XML being the common interface for all desktops
with no need for plug-ins or run-time deployments. the DB 1/0 can still happen on the
DB end of the communication link while the presentation can be done with XML on the
client end on the communication link."
--Presentation evaluation
09/01/02
|
"I'm talking from a PHP point of view, dealing with an SQL database when I'm thinking
of blobbing some XML. As everything would be processed afterwards then some extra XML
processing wouldn't matter. It would also mean that different entries could have
different fields (as it were) so the data setup is not so set in stone. This is
essentially an RDB though with an added twist."
--http://forums.devshed.com
08/25/02
|
"As far as I understood the idea of relational databases, is that it's the concept of
creating a data storage method whereby data is separated into smaller chunks by means
of identifying links between those chunks of data. "
--Online exchange, http://forums.devshed.com/
08/18/02
|
"Oracle, having invented the relational database, continues to lead and revolutionize
the database industry by introducing Oracle®iFS (Internet File System) and
Oracle®interMediawith Oracle8i. Oracle®iFS, the Internetfile system, provides the
easy-to-use functionality of a file system combined with the advantages of all data,
such as text and web pages, in a single server data integration with the cost savings
of a single server."
--Oracle8i Enterprise Edition, Technical Data Sheet
08/11/02
|
Q: Could anybody point me the difference(s) between DBMS and RDBMS?? Because in DBMS
also as in RDBMS, we can related two or more tables, if a column exists in another
table for relation??"
A: DBMS = Data Base Management System; RDBMS = Relational Data Base Management System.
But actually I do not know any DBMS that's not an RDBMS.
--Online Exchange
08/04/02
|
"Java is object-oriented; relational databases aren't. As a result, it's decidedly
difficult to shoehorn a Java object into a stubbornly primitive-oriented database
table. Luckily, the wind is changing, and newer database systems, including
object-oriented database management systems (OODBMS) and Java-relational database
management systems (see sidebar), provide direct support for storing and manipulating
objects. While a regular relational database can store only a limited number of
primitive types, a JDBMS system can store entire, arbitrary Java objects."
--William Crawford, AN INTRODUCTION TO JDBC, PART II, www.onjava.com
07/28/02
|
"Hanson's point, echoed by others, is that XML data is fundamentally different from
relational data. "XML data are extremely well-suited to hierarchical storage," says
Hanson, who is a former database administrator. "In XML databases, an online tax return
can be stored in its entirety. In a relational database, each line of the return would
have to be a different table [of data in rows and columns]."Trying to "force fit" an
XML document into the rigid relational structure can waste storage space and lead to
inefficiencies in queries and retrievals."
--John Cox, Working Out the Bugs in XML, Network World
07/21/02
|
"...overly rigid adherence to relational table designs will lead to poor performance
... User-centered table design, rather than theory-centered table design will yield a
system that better meets the users' requirements."
--Kevin Loney, ORACLE 8i DBA HANDBOOK
07/05/02
|
"No major application will run in third normal form."
--George Koch, ORACLE 8, THE COMPLETE REFERENCE
06/28/02
|
"As far as I understood the idea of relational databases, is that it's the concept of
creating a data storage method whereby data is separated into smaller chunks by means
of identifying links between those chunks of data."
--http://forums.devshed.com/
06/15/02
|
"What do you think Multivalue technology should be called? * Supra-relational
* Multi-relational
* Extended relational
* Multivalue
* Other "
--Database Trends and Applications Survey, DAMA Conference
06/09/02
|
"The main advantage of XML databases is their free-form, document-oriented storage
engines. There is no need to specify the structure of XML documents before storing
them. As a result, messy, semi-structured data is handled well by native XML
databases."
--Timothy Dick, Data Exchange Analysis, Infoworld
05/31/02
|
"Even though the tables are independent, you can easily see that they are related. The
city name in one table is related to the city name in the other. This relationship is
the basis for the name relational database."
--Koch and Loney, ORACLE: THE COMPLETE REFERENCE
05/24/02
|
By supporting what it calls the "three faces" of database design -- XML, relational,
and object data -- IBM's database will be able to to interact with XML documents,
structured information such as row and columns, and data written in object-oriented
programming languages, namely Java and C++. As such, the goal of all three [DBMS]
vendors is to more effectively run searches across structured and unstructured data
sets."
--Database titans embrace XML, Infoworld
05/12/02
|
"Is it possible that XML enables a more faithful 'version' of Relational Theory than
the current generation of DBMSs and SQL? Mark Milodragovich believes so, and will
present several specific arguments for how XML, XML query languages, and XSL can offer
advantages over current implementations of relational databases and query languages.
Why is XML the best implementation of Relational Theory we've seen yet?
* How does XML overcome several common pitfalls of relational database design?
* How can "hierarchical" data structures and "relational" data structures peacefully
coexist?
* How can XML extend the power of relational out onto the world "wild" web?
* Should you reconsider your use of nulls, system generated keys, "recursive" tables,
nested tables, repeating groups, multiple inheritance? The answers may surprise you.
As we invent the Semantic Web we have a new opportunity to get it right, or at least
get it 'righter'."
--http://www.datamodel.org/
04/12/02
|
"Does anyone have any information about any tools that can be used to reverse engineer
an existing IBM IMS database into a hierarchical model?"
--http://www.datamodel.org/
04/05/02
|
"With Oracle9i anything you can model in Java, you can model in Oracle. If just a few
good programmers see the value of using this existing reliable infrastructure rather
than recreating it, we can get on with the next paradigm shift, which is to model
our business problems as objects instead of relationally mapped to Java objects. We're
still stuck in the relational rut just as the hierarchical and network databasers of
the past were stuck in a rut when relational technology first came out."
--http://www.oreilly.com/
03/24/02
|
"... although hierarchical ... databases no longer pose a serious threat to RDBMSes,
the jury is still out on whether or not Web serviceswill spur RDBMS vendors to adopt
native XML databases ... Solutions that consolidate multirelational data structures
into a single XML view, such as Software AG's Tamino, could become a tempting approach
to simplify development and management issues."
--Mario Apicella, Relational Databases Extend their Reach, Infoworld
03/14/02
|
Q: a)Airplanes have to be maintained at least once a year, but at the latest every
50000 miles
b)Employees have to spend their yearly holidays until January of the following year.
Any help?
A: TRIGGERS!
--http://www.datamodel.org/bbs/
02/18/02
|
Q: Can anyone help explain the 12 rules, whether Microsoft Access satisfies
these rules and/or point me into the right direction.
A: As to whether or not MS Access satisfies all the rules, that is a matter of
debate. For my money, Access satisfies most of the rules, but only when it is
used to support a single user at a time. When you start looking at mulitple
concurrent users, Access falls further and further away from compliance.
--http://www.datamodel.org/bbs/
02/07/02
|
|
