crispino@kodak.UUCP (steve crispino) (09/22/87)
We're attempting to make a decision about using a relational database. Our purpose is to collect data from multiple systems and make that data available to application code running on a Vax. The other systems use a myriad of data base/collection schemes. The two choices we have are RDP and INGRES. Can anyone give me feedback on the uses of these two products? Please send E-mail to kodak!crispino Cheers, Steve
rkxyv@mergvax.UUCP (Robert Kedoin) (01/05/88)
I am looking for a relational data base system that can be used in a Software Engineering environment. It will be used to track identifiers in source code and libraries as well as assisting in system configuration in later parts of the cycle. I would appreciate any information on systems of this type that come with C source code for a UNIX System V machine. Thank you very much, -Rob Kedoin UUCP: ...philabs\!mergvax\!rkxyv
mebrenna@vela.acs.oakland.edu (Leonardo) (06/06/91)
Does anyone have a good definition of a Relational Database, and a
possible example?
Thanks
Michael E. Brennan | Office Automation, Software Support
mebrenna@vela.acs.oakland.edu (Internet) | Phone 313-370-4561
mebrennan@argo.acs.oakland.edu | Campus Network Support
michael@oasis.oa.oakland.edu (Novell) | Computer & Systems Engin
| @Oakland Universitydhartung@chinet.chi.il.us (Dan Hartung) (06/07/91)
mebrenna@vela.acs.oakland.edu (Leonardo) writes: >Does anyone have a good definition of a Relational Database, and a >possible example? Well, since E.F. Codd invented the concept, he gets to say what it is, and here's something from his book "The Relational Model, Version 2" (1990): "The relational model can be construed as a highly disciplined approach to database management. Adherence to this discipline by users is enforced by the DBMS...." Basically, a relational database is one that has been "normalized", that is, taken through (at minimum) first, second, and third normal forms. These "normal forms" are the processes of eliminating repeating data in favor of index keys. The three basic reasons for what is called "relational integrity" are: -- to keep related data together -- to eliminate redundancy -- to ensure that data is not lost during deletions First Normal Form 1st normal form is the process of putting all repeating groups into separate tables. For instance, if you have an employee database, with fields "Department" and "Manager", these should not be repeated in each employee's record. Instead, a key sould connect the employee with a "Departments" file, where the manager's name is stored. Second Normal Form After achieving 1NF, one can cast a databse into second normal form. This involves ensuring that every field in a table is dependent on the primary key. Thus, in an employee database, a "salary" field might be dependent on "grade level" instead of who the employee is. Third Normal Form Each field must now be dependent only locally on its table key, not by going through another database. Does any of that help? :-) > >Thanks > >Michael E. Brennan | Office Automation, Software Support >mebrenna@vela.acs.oakland.edu (Internet) | Phone 313-370-4561 >mebrennan@argo.acs.oakland.edu | Campus Network Support >michael@oasis.oa.oakland.edu (Novell) | Computer & Systems Engin > | @Oakland University -- Daniel A. Hartung | "What's the difference anyway, between being dhartung@chinet.chi.il.us | safe and being rad, the joke's on us, we've Birch Grove Software | all been had." -- John Wesley Harding
L.Carl.Pedersen@dartmouth.edu (L. Carl Pedersen) (06/08/91)
In my opinion, if one is speaking carefully, there is no such thing as a relational "database". There are only relational database *managers*. In my opinion, a relational database manager (RDBMS) is a program that implements something comparable in power to relational algebra with persistent objects. The objects represent relations, in the mathematical sense, and should be though of as such. The operations allow one to combine relations in various ways e.g., union, subtraction, cartesian product, and to extract meaningful subsets of those relations, or resultant relations, which are also relations. An important idea of these systems, often neglected, is that they operate primarily on relations (aka tables, aggregates) rather than individual rows (aka records). I have heard people claim that relational systems are called same because they allow one to relate data elements to each other. That's nonsense. All database systems do that. The term derives from the mathematical concept of a relation, which is a set of tuples, the elements of which are taken from several domain sets. See Date's book for a more rigorous definition. All of the systems that I am aware of that I accept as "truly" relational support something close to ANSII SQL - at least as a subset. This is an observation, not a definition of relational, but I think it's safe to claim that if a product is truly relational, it should be pretty easy to translate SQL into the language of that product (though not necessarily the reverse). These remarks will probably draw a lot of flack. So be it.
jim@uvmark.uucp (Jim Todhunter) (06/08/91)
In article <1991Jun07.063749.7904@chinet.chi.il.us> dhartung@chinet.chi.il.us (Dan Hartung) writes: >mebrenna@vela.acs.oakland.edu (Leonardo) writes: >>Does anyone have a good definition of a Relational Database, and a >>possible example? > >[... Stuff deleted ...] > >Basically, a relational database is one that has been "normalized", that >is, taken through (at minimum) first, second, and third normal forms. >These "normal forms" are the processes of eliminating repeating data >in favor of index keys. > >[... stuff deleted ...] Just a minor correction to this posting. A relational database does NOT need to be normalized. In fact, some of the most interesting current research is the area of NFNF (non first normal form) relational models. This is a very active area of investigation because there are serious deficiencies in the first normal form model. While Codd dismisses NFNF and OO model out of hand, most others, including Date, do not share his view. (It is interesting to note that CODD's recent book reads very much like a dinosaur's defense of his raison d'etre.) NFNF models can also use indices. The truth is normalization is merely a convenience for that database theorist, making the mathemetical proofs easier. -- James W. Todhunter, Manager, Software Development Vmark Software, Inc., 5 Strathmore Road, Natick, MA 01760, USA Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS
davidm@uunet.UU.NET (David S. Masterson) (06/10/91)
>>>>> On 7 Jun 91 20:55:29 GMT, L.Carl.Pedersen@dartmouth.edu (L. Carl >>>>> Pedersen) said: Carl> This is an observation, not a definition of relational, but I think it's Carl> safe to claim that if a product is truly relational, it should be pretty Carl> easy to translate SQL into the language of that product (though not Carl> necessarily the reverse). Well, maybe not. At least, Dr. E.F. Codd doesn't seem to agree. Judging by his book, I would guess that there things that SQL would allow that a system that is "truly" relational would not. In truth, the language that the system uses doesn't really enter into the question of whether the product is truly relational. If a product is "truly" relational and it supports both SQL and (say) QUEL, then queries in SQL should translate to queries in QUEL and vice versa. The base assumption, though, is that we started with a truly relational system. Carl> These remarks will probably draw a lot of flack. So be it. Flack is such a hard word. I prefer to think of it as creatively seeking the "truth" (tm). ;-) -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
dhartung@chinet.chi.il.us (Dan Hartung) (06/10/91)
jim@uvmark.uucp (Jim Todhunter) writes: > >Just a minor correction to this posting. A relational database does NOT >need to be normalized. In fact, some of the most interesting current >research is the area of NFNF (non first normal form) relational models. >This is a very active area of investigation because there are serious >deficiencies in the first normal form model. While Codd dismisses NFNF >and OO model out of hand, most others, including Date, do not share his >view. (It is interesting to note that CODD's recent book reads very much >like a dinosaur's defense of his raison d'etre.) NFNF models can also use >indices. The truth is normalization is merely a convenience for that >database theorist, making the mathemetical proofs easier. > Thanks -- this is very interesting. I wish I had more of the math background (I come to computers from English lit!); I know just enough to get myself in trouble. :-) I think Codd is very amusing and slices & dices some of his opponents effectively, but I wish he were more open to other avenue of discussion. -- Daniel A. Hartung | "What's the difference anyway, between being dhartung@chinet.chi.il.us | safe and being rad, the joke's on us, we've Birch Grove Software | all been had." -- John Wesley Harding -----------FoxPro Programmer Looking For Work--------------
larry@cs.widener.edu (Larry Sigmond) (06/10/91)
In article <1991Jun08.124337.29813@uvmark.uucp> jim@uvmark.uucp (Jim Todhunter) writes: > >Just a minor correction to this posting. A relational database does NOT >need to be normalized. In fact, some of the most interesting current >research is the area of NFNF (non first normal form) relational models. >This is a very active area of investigation because there are serious >deficiencies in the first normal form model. I'd be interested to hear an example of a deficiency caused by First Normal Form or a reference to the research. __ Laurence Sigmond Logical Systems 215-848-8889 larry@logsys.com -- Laurence Sigmond Logical Systems 215-848-8889 larry@logsys.com
ghm@ccadfa.adfa.oz.au (Geoff Miller) (06/10/91)
jim@uvmark.uucp (Jim Todhunter) writes: >[... stuff deleted ...] >Just a minor correction to this posting. A relational database does NOT >need to be normalized. In fact, some of the most interesting current >research is the area of NFNF (non first normal form) relational models. >This is a very active area of investigation because there are serious >deficiencies in the first normal form model. While Codd dismisses NFNF >and OO model out of hand, most others, including Date, do not share his >view. (It is interesting to note that CODD's recent book reads very much >like a dinosaur's defense of his raison d'etre.) NFNF models can also use >indices. The truth is normalization is merely a convenience for that >database theorist, making the mathemetical proofs easier. I have previously put forward the view that, if you consider a DBMS to be "relational" only if it obeys all of the Commandments of Codd, there is no such animal as a truly relational DBMS. I would also suggest that this does not matter very much! The relational database *model* is extremely useful for database design. However, you can implement a relational model using a number of DBMS products which are quite clearly not "relational" in the sense described above, and as Jim points out, DBMS products which offer NFNF capabilities have a number of uses. Pick is of course one of the leading examples, as Jim could have mentioned (but perhaps he didn't want to be accused of advertising!). Normalisation does have advantages for more that the database theorist, though. Remember that there is a basic law of computing that, if you give a user the chance to enter the same piece of information in two different places you will inevitably end up with two different versions. Normalisation is largely about making sure that each piece of information is stored once and once only. However, you can implement a normalised data *model* in ways which use NFNF structures. >-- > James W. Todhunter, Manager, Software Development > Vmark Software, Inc., 5 Strathmore Road, Natick, MA 01760, USA > Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim > Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy A
dhartung@chinet.chi.il.us (Dan Hartung) (06/10/91)
larry@cs.widener.edu (Larry Sigmond) writes: >jim@uvmark.uucp (Jim Todhunter) writes: >> >>Just a minor correction to this posting. A relational database does NOT >>need to be normalized. In fact, some of the most interesting current >>research is the area of NFNF (non first normal form) relational models. >>This is a very active area of investigation because there are serious >>deficiencies in the first normal form model. > >I'd be interested to hear an example of a deficiency caused by First >Normal Form or a reference to the research. Well, on p. 200 of Codd's book he answers his critics (his sometime partner Date is cited!) about supposed "Alleged Breakdown of Normalization". The criticism seems (and I am interpreting filtered information here) to be based on problems of row insertion and resultant redundancy or nulls in primary relations. Codd says that the relational model has an answer for this, but it's too abstruse for me to follow clearly. I'm not 100% sure this is related to what Jim said, but my guess would be that it is. Hm -- I wanted to get the citation for you, but there seems to be a typo or a lost bibilographic entry. The in-text citation is "Date 1986", but there are only 1984 and 1987 entries in the bibliography. -- Daniel A. Hartung | "What's the difference anyway, between being dhartung@chinet.chi.il.us | safe and being rad, the joke's on us, we've Birch Grove Software | all been had." -- John Wesley Harding -----------FoxPro Programmer Looking For Work--------------
jfr@locus.com (Jon Rosen) (06/10/91)
In article <2421@ccadfa.adfa.oz.au> ghm@ccadfa.adfa.oz.au (Geoff Miller) writes: >I have previously put forward the view that, if you consider a DBMS to >be "relational" only if it obeys all of the Commandments of Codd, there >is no such animal as a truly relational DBMS. I would also suggest that >this does not matter very much! True... >The relational database *model* is extremely useful for database design. >However, you can implement a relational model using a number of DBMS >products which are quite clearly not "relational" in the sense described above ><stuff deleted> Also true... >Normalisation does have advantages for more that the database theorist, >though. Remember that there is a basic law of computing that, if you >give a user the chance to enter the same piece of information in two >different places you will inevitably end up with two different versions. >Normalisation is largely about making sure that each piece of information >is stored once and once only. Not true... normalization is mostly about reducing a data model to its component parts... what this does is generally eliminate redundant ATTRIBUTEs, but KEYS are not only repeated, but often repeated many times... In fact, I have done a comparison of several large systems that were implemented in RAMIS, a mostly hierarchical 4GL database and then reimplemented in DB2... The use of a hierarchy was far more capable of eliminating redundancies than the relational version... This does not mean, however, that the hierarchical version was any easier to use or maintain... This mostly depends on the tools you have to program with, whether they be procedural or 4GL-style... > However, you can implement a normalised >data *model* in ways which use NFNF structures. This is do NOT understand... If you mean that you can use denormalization for performance reasons after having appropriately normalized, I would agree... Otherwise, I fail to see how the use of an NFNF model (which I agree can be very useful in certain applications) can implement a normalized view of the data, since these are essentially contradictory views... Please explain... Jon Rosen
dberg@informix.com (David I. Berg) (06/10/91)
In article <7Q--HLB@cs.widener.edu> larry@cs.widener.edu (Larry Sigmond) writes: >In article <1991Jun08.124337.29813@uvmark.uucp> jim@uvmark.uucp (Jim Todhunter) writes: >> >>This is a very active area of investigation because there are serious >>deficiencies in the first normal form model. > >I'd be interested to hear an example of a deficiency caused by First >Normal Form or a reference to the research. Read S.P.Ghosh's article on Statistical Relationl Databases in "Knowledge and Data Engineering"; 3,1; 3/91; pp 55-64. ___ ___ dberg@cougar.informix.com / ) __ . __/ /_ ) _ __ Informix Software Inc. (303) 850-0210 _/__/ (_(_ (/ / (_(_ _/__> (-' -/~ (_- 5299 DTC Blvd #740 Englewood CO 80111 {uunet|pyramid}!infmx!dberg The opinions expressed herein are mine alone.
davidm@uunet.UU.NET (David S. Masterson) (06/11/91)
>>>>> On 8 Jun 91 12:43:37 GMT, jim@uvmark.uucp (Jim Todhunter) said:
Jim> A relational database does NOT need to be normalized. In fact, some of
Jim> the most interesting current research is the area of NFNF (non first
Jim> normal form) relational models. This is a very active area of
Jim> investigation because there are serious deficiencies in the first normal
Jim> form model. While Codd dismisses NFNF and OO model out of hand, most
Jim> others, including Date, do not share his view. (It is interesting to
Jim> note that CODD's recent book reads very much like a dinosaur's defense of
Jim> his raison d'etre.) NFNF models can also use indices. The truth is
Jim> normalization is merely a convenience for that database theorist, making
Jim> the mathemetical proofs easier.
Hmmm, I'm interested. What are the deficiencies in first normal form? Are
NFNF models processable with relational algebra/calculus?
While I certainly think Codd could have been more complete in his book, he
does make a lot of good points. For instance, he doesn't dismiss the OO model
as easily as he does the UR or BR models, but rather indicates that it has
promise once it answers some of the more difficult database management
questions. I have always had difficulty in seeing the difference between a
complete OODBMS and a relational database with abstract data types (the one
unsurety I have is the prospect of multidimensional relations that this opens
up).
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"L.Carl.Pedersen@dartmouth.edu (L. Carl Pedersen) (06/11/91)
In article <25200@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes: > In article <2421@ccadfa.adfa.oz.au> ghm@ccadfa.adfa.oz.au (Geoff Miller) writes: (stuff deleted) > >Normalisation does have advantages for more that the database theorist, > >though. Remember that there is a basic law of computing that, if you > >give a user the chance to enter the same piece of information in two > >different places you will inevitably end up with two different versions. > >Normalisation is largely about making sure that each piece of information > >is stored once and once only. > > Not true... normalization is mostly about reducing a data model to its > component parts... what this does is generally eliminate redundant > ATTRIBUTEs, but KEYS are not only repeated, but often repeated > many times... In fact, I have done a comparison of several large > systems that were implemented in RAMIS, a mostly hierarchical 4GL > database and then reimplemented in DB2... The use of a hierarchy was > far more capable of eliminating redundancies than the relational > version... I agree with the Geoff. Normalization is primarily intended to eliminate update anomolies. In fact, the various normal forms all have associated update anomolies. Jon is certainly right, though, that keys end up being repeated all over the place. However, I think a relational purist would argue that keys should be totally meaningless - internally generated surrogate keys, so that you would never have to change them. You would not, for example, use a Social Security Number as a key, since it might turn out to be wrong. An SSN would be just another attribute of a person. Some people actually implement things this way, but, of course, this approach has its own problems. I'm not certain about this, but I think Codd has published a proposal for a relational system that essentially requires the use of surrogate keys, but also manages them more or less automatically, making them a more palatable. And, of course, some of the newer object-oriented systems address this issue by allowing one to reference the object directly rather than a key pointing to the object. I'd be interested in people's experience with using surrogate keys, i.e., internally generated keys that are never revealed to the user, instead of real-world keys like SSN's.
jim@uvmark.uucp (Jim Todhunter) (06/12/91)
In article <25200@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes: >In article <2421@ccadfa.adfa.oz.au> ghm@ccadfa.adfa.oz.au (Geoff Miller) writes: >[... much of acrticle deleted ...] > >> However, you can implement a normalised >>data *model* in ways which use NFNF structures. > > This is do NOT understand... If you mean that you can use denormalization > for performance reasons after having appropriately normalized, I would > agree... Otherwise, I fail to see how the use of an NFNF model (which > I agree can be very useful in certain applications) can implement a > normalized view of the data, since these are essentially contradictory > views... Please explain... > > Jon Rosen The following is an excerpt from e-mail I have been sending to people who have asked for some references concerning NFNF models. Although this list is far from comprehensive, it should serve as a good starting point for interest parties. It should also answer the above question. There is a growing interest in NFNF database models. In C.J.Date's "An Introduction to Database Systems" (vol. I, 5th ed., Addison-Wesley, 1989), NFNF models are cited as an interesting area for future research. Date also references several papers on the subject. The activity in this area has been increasing over the years. Some relevant papers are: Howard M. Dreizen and Shi-Kuo Chang, "Imprecise Schema: A Rationale for Relations with Embedded Subrelations", ACM TODS, Vol 14, No. 4, 12/89 G. Ozsoyoglu, Z. M. Ozsoyogu and V. Matos, "Extending Relational Algebra and Relational Calculus with Set-Valued Attributes and Aggregate Functions", ACM TODS, Vol. 12, No. 4, 12/87 Z. Meral Ozsoyogu and Li-Yan Yuan, "A New Normal Form for Nested Relations", ACM TODS, Vol. 12, No. 1, 3/87 Mark A. Roth, Henry F. Korth and Abraham Silberschatz, "Extended Algebra and Calculus for Nested Relational Databases", ACM TODS, Vol. 13, No. 4, 12/88 H. J. Schek and M. H. Scholl, "The relational model with relation-valued attributes", Information Systems, Vol. 11, No. 2, 1986 P. Pistor and F. Anderson, "Designing a generalized NF2 model with an SQL-type language interface", Proc. 12th Int. Conf. Very Large Databases, Kyoto, August 1986 Note: In this last reference, NF2 is read NF-squared, not second normal form. NF-squared is another name for NFNF. -- James W. Todhunter, Manager, Software Development Vmark Software, Inc., 5 Strathmore Road, Natick, MA 01760, USA Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS
ghm@ccadfa.adfa.oz.au (Geoff Miller) (06/12/91)
jfr@locus.com (Jon Rosen) writes: [...bits where he agreed with me deleted...] [...also disagreement over keys deleted because L. Carl Pedersen has already made the point I would have made...] >> However, you can implement a normalised >>data *model* in ways which use NFNF structures. > This is do NOT understand... If you mean that you can use denormalization > for performance reasons after having appropriately normalized, I would > agree... Otherwise, I fail to see how the use of an NFNF model (which > I agree can be very useful in certain applications) can implement a > normalized view of the data, since these are essentially contradictory > views... Please explain... Certainly. Actually, you have reversed what I wrote, which is that you can use a normalised (i.e. at least 3NF) *model* but implement it in a NFNF *structure*. By a strange coincidence I have an example (at a very simple level) ready. We have a file registry system in which the movements of files (i.e. paper binders full of documents, not computer files) have to be recorded. When we modelled the data structures we had a separate table for the movement data (file/part id, who, when). When we implemented this we created a pair of associated multivalued fields in the file/part record. Each file movement inserts a new pair of values at the start of these fields, so that the most recent movement (and hence the current holder of the file) is always the first value. Now, obviously this is not the only way this could have been done, but it seems to me to be the most efficient. To implement a separate table I then have to decide how I handle current location - do I simply identify it as the most recent movement (which could make it slow to retrieve, if it has to sort through a lot of records) or do I store current location in the main file/part table and write a routine to handle movements which will put the old data into an archive file and the new data into the main file? As it is, I have to do neither. Note that I have not created redundant data by using the MV field, I have simply folded one normalised table into another one. As soon as you do this to optimise one part of your processing, of course, you de-optimise (horrible word) another part, and this is why I regard MV fields with considerable caution. In my example it would be harder (but not impossible) to identify all the files which have passed through the hands of a specific individual, but we seldom (so far, never) need to do this. While the MV fields are useful, I still put a lot of emphasis on the fully normalised (i.e. at least 3NF) model as a basis for design. Hope this helps explain my thoughts. Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy
martin@adpplz.UUCP (Martin Golding) (06/13/91)
>When we implemented >this we created a pair of associated multivalued fields in the file/part >record. ^^^^^^^^^^^^^^^^^^^^^^ What particular database (if any, of course) are you using? I immediately thought "aha, one of those aussie closet P*CK users", but then you said: >In my example it would be harder (but not impossible) to identify >all the files which have passed through the hands of a specific >individual, but we seldom (so far, never) need to do this. which would be easy on a P*CK system. I ask because we business types often need to trade off elegance for performance, and one of the groups here is evaluating possible databases. Martin Golding has made no affirmation of fact or promise relating to this posting which has created an express or implied warranty that this posting would conform to any affirmation or promise, and disclaims any warranty of fitness of this posting for any particular purpose whatsoever. {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
spencer@zeus.ocs.com (Spencer Hines) (06/13/91)
In article <1991Jun08.124337.29813@uvmark.uucp> jim@uvmark.uucp (Jim Todhunter) writes: >In article <1991Jun07.063749.7904@chinet.chi.il.us> dhartung@chinet.chi.il.us (Dan Hartung) writes: >>mebrenna@vela.acs.oakland.edu (Leonardo) writes: >>>Does anyone have a good definition of a Relational Database, and a >>>possible example? >> >>[... Stuff deleted ...] >> >>Basically, a relational database is one that has been "normalized", that >>is, taken through (at minimum) first, second, and third normal forms. >>These "normal forms" are the processes of eliminating repeating data >>in favor of index keys. >>[...More Stuff deleted...] Just a note that in my experience no one in the real (read customer) world has the faintest idea about this underlying meaning, and really won't believe you if you tell them. Most application databases don't really support this. In some cases, a truly relational database would in fact be death to performance. Also, in my experience, every vendor claims that everything about their implementation is relational, often not true at all from a technical point of view. My point is that don't assume that someone is referring to the technical sense of relational. They may mean that they want file interrelatedness, SQL, and so on.
jim@uvmark.uucp (Jim Todhunter) (06/16/91)
In article <CIMSHOP!DAVIDM.91Jun10181624@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Hmmm, I'm interested. What are the deficiencies in first normal form? Are >NFNF models processable with relational algebra/calculus? >[ ... text deleted ... ] There are several examples in the literature showing that relational algebra/calculus can be applied to NFNF models. Some of the references I posted a few days ago include such discussions. -- James W. Todhunter, Manager, Software Development Vmark Software, Inc., 5 Strathmore Road, Natick, MA 01760, USA Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS
antoine@cl.bull.fr (Antoine Haraoui) (06/20/91)
I have read some of the given definitions for a RDB. Actually those are rules for designing an Entity/Relationship model rather than definitions. If we are going to talk about normalisation so why not talk about integrity and consistency rules... In my (and some others) opinion a RDB is : 1- A database where the files are seen as tables and nothing but tables. i.e. rows and columns. 2- All fields are atomic. In other words, there is only one value at any column-row intersection. 3- It supports at least the selection, projection, and natural join relational operators. Any database respecting those three rules is considered to be relational. We can go ahead and talk about first, second, third, Boyce-Codd, fourth, ... normal forms. As well as integrity and consistency rules... But then we will be talking about a totaly different subject; We will be talking about given a set of data, how can we have a good design to represent those data in a relational database. After all even the conventional so called 3rd generation designs can be normalised! Any comments will be appreciated. Antoine G. HARAOUI, Bull S.A. e-mail: Antoine.Haraoui@cl.bull.fr Software Development Methodology tel : (33-1) 3080 7629 Bulltel->2377629 Av. Jean-Jaures, PC F30D01, fax : (33-1) 3080 7078 Bullfax->2377078 78340 Les Clayes sous Bois, France
davidm@uunet.UU.NET (David S. Masterson) (06/22/91)
>>>>> On 20 Jun 91 08:41:18 GMT, antoine@cl.bull.fr (Antoine Haraoui) said:
Antoine> I have read some of the given definitions for a RDB. Actually those
Antoine> are rules for designing an Entity/Relationship model rather than
Antoine> definitions. If we are going to talk about normalisation so why not
Antoine> talk about integrity and consistency rules...
When talking about a relational model, these are all things that should be
considered, otherwise you've short-changed yourself on your implementation of
a relational database.
Antoine> In my (and some others) opinion a RDB is :
Antoine> 1- A database where the files are seen as tables and nothing but
Antoine> tables. i.e. rows and columns.
As Codd points out, thinking of a relational database as modeling a collection
of tables is, strictly speaking, incorrect. Tables tend to denote some order
and are much more loosely defined than a mathematical relation. For instance,
its quite possible to have duplicate rows in a table whereas a "true" relation
must not.
Antoine> 2- All fields are atomic. In other words, there is only one value at
Antoine> any column-row intersection.
Quite correct, although the definition of "atomic value" is still open. Some
want to extend that to include objects, but then the question of what is an
object is opened...
Antoine> 3- It supports at least the selection, projection, and natural join
Antoine> relational operators.
What about update operators? Actually, just talking about these three
operators opens questions about NULL support and integrity constraints.
Antoine> Any database respecting those three rules is considered to be
Antoine> relational. We can go ahead and talk about first, second, third,
Antoine> Boyce-Codd, fourth, ... normal forms. As well as integrity and
Antoine> consistency rules... But then we will be talking about a totaly
Antoine> different subject; We will be talking about given a set of data, how
Antoine> can we have a good design to represent those data in a relational
Antoine> database. After all even the conventional so called 3rd generation
Antoine> designs can be normalised!
True, but then again you can also do object oriented programming in assembler!
The point of these normalization forms and integrity and consistency rules was
that, for a relational database to be truly useful, it should conform to all
these points. If a database doesn't conform, then chances are that some part
of the relational model is not as useful as it could be in this database. For
instance, violation of integrity rules may cause join operations to provide
the wrong results.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"rbw00@ccc.amdahl.com ( 213 Richard Wilmot) (06/22/91)
In article <599@clbull.frcl.bull.fr> antoine@cl.bull.fr (Antoine Haraoui) writes: [....] >After all even >the conventional so called 3rd generation designs can be normalised! ^^^ ^^ should be I certainly had good success in developing stable IMS database designs through normalization. Normalization is a part of database design practice (conceptual design phase), while data storage methods (IMS, DB2, Focus, GemStone, etc.) are implementation and maintenance considerations. Right on Antoine. >Antoine G. HARAOUI, Bull S.A. e-mail: Antoine.Haraoui@cl.bull.fr >Software Development Methodology tel : (33-1) 3080 7629 Bulltel->2377629 >Av. Jean-Jaures, PC F30D01, fax : (33-1) 3080 7078 Bullfax->2377078 >78340 Les Clayes sous Bois, France -- Dick Wilmot | I declaim that Amdahl might disclaim any of my claims. (408) 746-6108