I wonder what these two words mean.
I encountered them in Doctrine's documentation, but I can't understand what they mean.
This has to do with whether common usage (within the application domain) would attempt to access both sides of the relationship from the other side... Invoices to products would probably be unidirectional, as athough we often want to know what products are on an invoice, it is unlikely that you would want to know all the invoices that contain a given product.
Stores to products on the other hand is bi-directional, as we could easily want to access both all the products at a specific store, or find all the stores that sell a specific product.
Bi-Directional is not limited to where the relationship is a many-to-many relationship. An employee to supervisor relationship could easily be bi-directional, if, in our domain model, an employee object will need to be able to access the employee's supervisor object, and of course, the supervisors object contains a property that lists all his assigned employees.
One to Many Bidirectional:
State and City, where State has collection property of Cities, and City has a State property
Many to Many Unidirectional:
Bus and Rider, where Bus has collection property of Riders, but Rider does not have collection property listing all Buses Rider has ridden in (application does not care).
Many to Many Bidirectional:
Person class, where each person has Friends Property, as Collection of other person objects this person is friends with;
or...
Artist and Album classes, where Artist has Albums collection, and Album has Artists Collection (where album is compilation of tracks from multiple artists)
Example:
We have two tables in database: Student Table, Subject Table
Many-To-Many Bidirectional
You need apply the navigation in the database from the following two directions:
Navigation from Student to Subject
A student can enroll for many subjects in the semester.
Navigation from Subject to Student
A Subject can have many different students enrolled for it.
Many-To-Many Unidirectional
You need apply the navigation in the database from the just one direction:
Navigation from Student to Subject
A student can enroll for many subjects in the semester.
Related
So I have 3 main entities. Airports, Customers, and Vendor.
Each of these will have multiple contacts I need to relate to each.
So they way I set it up currently.
I have the following tables..
Airport
Customer
Vendor
I then have one Contacts table and a xref for Airport, Customer, Vendor...
I am questioning that and was thinking a contacts table for each ..
Airport and AirportContacts
Customer and CustomerContacts
Vendor and VendorContacts
Any drawbacks to either of these designs?
To me, the deciding factor is duplication of entities vs "one version of the truth". If a single real-world person can be a contact for more than one of the other entities, then you don't want to store that single person in multiple contact tables, because then you have to maintain any changes to his/her properties in multiple places.
If you put the same "Joe Smith" in both AirportContacts and VendorContacts, then one day when you look and see his city is "Denver" in one table and "Boston" in another table, which one will you consider to be the truth?
But as someone mentioned in comments, if a contact can only be associated with one of the three other entities ("types" as you call them), then putting them in separate tables makes the most sense.
And there's yet a third scenario. Say "Joe Smith" can be a contact for both Airports and Vendors. But say that he has some properties, like his gender and age, which are the same regardless of which "type" he is being considered, but there might be some properties, like phone number, or position/job title, which could depend on the "type". Maybe he uses one phone in his capacity as an Airport Vendor, and a different phone as a Vendor Contact. Moreover, maybe there are some properties that apply to one type of contact that don't apply to the others. In these cases, I would look at some kind of hybrid approach where you keep common properties in a single Contact table, and "Type"-specific properties in their own type-related tables. These type-related tables would be bridge tables that have FKs back to the Contact table and to the main entity table of the "Type" they are related to (Vendor, Customer or Airport).
What I have so far ... Dont mind some of the data types.. just placed quick placeholders..
Thanks in advance.
I am learning and designing a RDBMS of an organization with 2 departments .
Its pretty straightforward but the problem arises when an action in one department leads to action in the other department . Suppose department one does survey of consumers and this survey causes department 2 to introduce a product. The trouble is I have no idea how to connect this relationships of surveying and introducing new products together. I am learning RDBMS on my own.
I believe you are asking how to model a scenario where you can track a department's actions to the records that they create, whether that record is a product or a survey. I have attached a diagram and will attempt to explain the relationships.
Each department can have a number of different actions. These actions can be shared across departments. Every DepartmentAction can have an associated ActionEntity. This ActionEntity shares a 1 to 0..1 relationship with both Product and Survey. Finally, every product and survey can also have the department's id that created the record.
In the question I'm doing at the moment gave two confusing sentences:
1. A property can be either be a house or an apartment. For a house it records ..bula bula
For an apartment, it records .. bula bula
2. A property can be either for sale or rent, or for both. If a property is for sale, it
records .. bula bula. If the property is for rent, it records .. bula bula
These two are in the same question. Do I have to represent it by using subclasses or how?
Many thanks.
Yes, a entity can have multiple subclasses and multiple superclasses. Both faculty staff and student assistants may be subclasses of employees, and a student assistant may be a subclass of both employees and students.
You can create a Property entity with four subclasses, House, Appartment, PropertyForRent and PropertyForSale.
A property may not be both a house and an appartment. Therefore, use a circle with a d in it to indicate that it is disjoint. A property may be both for rent and for sale. Use a circle with an o in it to indicate that it may overlap.
This is described on page 443 in Advanced Data Modelling, and another example can be found on page 30 of this presentation.
Sjoerd's answer is correct.
ER modeling tells you how to diagram subclasses, but it doesn't tell you how to implement them. Nor should it.
If you are interested in designing SQL tables that implement subclasses, look up these topics, or their tags in SO:
Single Table Inheritance
Class Table Inheritance
Shared Primary Key
I am trying to understand why this statement in the book is wrong: "given a C entity, there is at most one related A entity and at most one related B entity".
Is it that it doesn't apply to a specific kind of relationship??
So, if I have an example of a student who is in attendance to a course with a type of subject. The entities are student, attendance, course and subject. Student makes attendance in a room. Also, a student can make attendance for a subject. Does this example apply to the statement?
Thanks for your time.
The author probably means: in a single relationship instance (e.g., student-Bob/course-ABC/attendance123). So there is a single student, a single course and a single attendance record linked in that instance.
Not across all relationship instances in the class (where student Bob could attend many classes over time).
I'm using an ORM (SQLAlchemy, but my question is quite implementation-agnostic) to model a many-to-many relationship between a parent class and its children.. I was wondering, what would be a simple way to express the concept "one of the children is the default/main one"?
For example, I'd need to persist the following:
This Person instance has Address X and Y, the main one is Y.
I saw this implemented using a "middle" class like "PersonAddressRelation" that would contain "Person", "Address" and the "main" flag, but I think it looks a bit cumbersome.. Is there a better way?
The simplest way would be to have a join table, PersonAddressRelation, and also a DefaultAddress column on the Person table that keys to the Address table.
A couple of remarks.
M:N relationships don't specify 'parent' and 'child', as there's no parent nor a child: there are simply two entities having an m:n relationship via a 3rd entity (the intermediate entity).
'Address' is in general not a valid entity type, as semantically it has no identity, similar to a 'name' has no identity (first name, last name). You'll see this when you look at re-using an entity instance of type Address: you won't do that in general. (though you will re-use a Customer entity instance for example, when the customer has multiple orders)
You want to specify an attribute on the M:N relationship (default), as it belongs there. This means that the relationship itself forms an entity (which is the intermediate entity, often it has just two FK fields forming the PK). This is called an 'objectified relationship', as the relationship itself is seen as an entity. Other examples of this are Employee m:n Department and you want to specify the StartDate an employee started for a department the employee works for.
So in general: create the intermediate entity, as it in general should be there, and add the attribute there. In this particular case with Address, be really sure you are re-using Address instances among related entities (Person). If not, merge Address with Person OR if a person can have multiple addresses, create a simple 1:n relationship between Person - Address, to normalize it out, though don't be afraid to merge address data into the entity it is related to, as often address data is really not re-used (so your m:n relationship is really not there: there's no Address instance which is related to multiple person instances.