-one- table is not a parent of the associated record in the -many- table, but
rather just related.
An example:
an identifying 1:M would be a building which has many rooms. The -one- table
carries data about the building .. e.g., street address, number of floors, name.
The -many- table carries data about the rooms in the building .. e.g., room number,
capacity, special characteristics. The room cannot exist without the building,
therefore this 1:M is an identifying relationship.
a non-identifying 1:M would be a DVD which has many renters. The -one- table
carries data about the DVD... e.g., the movie name, the artist. The -many- table
carries data about each person who rents that DVD .. e.g., name, price paid.
The DVD can exist on its own, without ever having been rented, and the person
can exist on her own, without ever having rented any DVD, therefore this 1:M
is a non-identifying relationship.
Donna Hinshaw
GH wrote:
weird... about 1:! generalization and 1:m non identifying...
I think that these examples can make it better to understand some of those terms... I am quoting from Database Systems -- Design, Implementation & Management fouth edition by Rob & Coronel (page 23)
Conceptual Modules use three types of relationships to descrive associates amond data: one-to-many, many-to-many, and one-to-one. Database designers usually use shorthand notations 1:M, M:N, and 1:1 for them, respectfully. The following examples illustrate the distinctions among the three.
1. *ONE-TO-MANY Relationships* A painter pains many diffrent paintings, but each one of hem is painted by only that painter. Thus the painter ("the one") is related to the paintings (the "many"). Therefore, database designers lable the relationship "PAINTER paints PAINTINGS" as 1:M. Simillarly, a customer account (the "one") might contain many invoices, but those invoices (the "many") are related to only a singe customer account. The "CUSTOMER generates INVOICE" relationship would also be labled 1:M
2 *MANY-TO-MANY Relationship* An employee might learn many job skills, ans each job skill might be learned by many employees. Database designers label the relationship "EMPLOYEE learns SKILL" as M:N. Similarly, a student can take many courses, and each course can be taken by many students, thus yielding the M:N relationship label for the relationship for the relationship expressed by "STUDENT takes COURSE"
3 *ONE-TO-ONE Relationship* A retail company's management structure may require that eaco one of its stores be managed by a single employee. In turn, each store manager -- who is an employee -- only manages a single store. Therefore the relationship "EMPLOYEE manages STORE" is labled 1:1
Hope that this helps... as per the non identifying and the generalizations... DUNNO
On Thu, 30 Sep 2004 13:14:03 -0400, Joshua Beall <[EMAIL PROTECTED]> wrote:
Hi All,
I've been taking a look at DB Designer 4, and looking through the documentation (http://www.fabforce.net/dbdesigner4/doc/index.html) I am a little unclear on some of their nomenclature:
'1:1' - Ok, one to one. Got it. '1:1' generalization - Don't know this. Obviously different somehow from one to one, but how? '1:n' - One to many, I assume. '1:n non identifying' - Nonidentifying? What does this mean? 'n:m' - Many to many? Again, not sure.
Can anyone help clarify?
Thanks! -Josh
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
