I'm making a database where I need to create a relationship between 'Modules' and 'Degree' - basically the modules make up the degree - such like:
Module CS 1 is part of Computer Science
Module CS 2 is part of Computer Science
Module PHIL 1 is part of Philosophy
etc.
My table format is as so:
Modules -> Form -> Degree
Modules contains Module Name, and Module ID (PK)
Form contains Module ID and Degree ID (both FK)
Degree contains Degree Name and Degree ID (PK)
I appear to have the issue that regardless, there will be a many-to-many relationship, as there will be multiple Module ID's which correlate to one Degree ID.
Is there a way around this?
This would not be a many-to-many relationship, in fact, that is the entire purposes of the "bridge" table Form.
See the picture below. In the basic ER Diagram (Entity Relationship Diagram, you can read about them here), you can see the following:
There is a ONE-TO-MANY relationship between Module and Form
(i.e., ONE Module ID can appear MANY TIMES in the Form Table, but that Module ID will only appear ONE time in the Module table)
There is a ONE-TO-MANY relationship between Form and Degree
(i.e., ONE Degree ID can appear MANY TIMES in the Form Table, but that Degree ID will only appear ONE time in the Degree table)
Your architecture and usage of a bridge table is indeed one way to eliminate a many-to-many relationship, good job.
Related
Hello I have the following situation:
I have a product instance table that is nothing more than a product already assigned to a department and employee.
Well, but I have the following business logic: the product can be an equipment, or a component, that is, a product can have children.
thinking how a computer case is a device that has patrimony_code, and has child products (components) such as:
motherboard,
memoirs,
vga
etc etc
and all of these components are connected to the equipment.
I arrived at this with less table:
But I encountered some problems:
my components would not need departament_id, as they do not belong to the department but to the equipment that there belongs to the department.
So I came to this modeling, but I don't know if it is a good thing to do this relationship, could someone help me if there is a more clean / solid solution for this?
if I have understood your description correctly, only a piece of equipment can be assigned directly to a department, not the individual components that make up the piece of equipment?
Assuming this is the case then I suggest you split this problem into 2 separate tasks as they are, in reality, unrelated and trying to treat them as a single model is causing confusion:
Model the relationship between an instance of a piece of equipment and a department
Model the hierarchy of components (and their instances) that make up a piece of equipment
Once you have these two models you can then relate them if you need to but logically they are separate and you can change one without affecting the other
Hope this helps?
UPDATE 1
(in response to your questions)
You construct 1 sub-model that covers your Equipment entity and the Component entity (plus any other relevant entities) that describe how your products are modelled.
Your construct a second sub-model that describes how equipment is assigned to a department.
The only entity that would be (necessarily) common to the 2 sub-models is the Equipment entity; though, obviously, you can display both sub-models on the same diagram if that is required - even though they are logically separate (apart from the one common entity: Equipment)
This question already has answers here:
Meaning of "n:m" and "1:n" in database design
(9 answers)
Closed 3 years ago.
I have started a new job recently as .Net Developer, in that for the projects that I am working on requires strong understanding of relationships like
1-N, 1-1 and N-N. I have completely understood 1-1 relationship with real life example like In a Tablets and Billing table if Billing table has TabletId as a foreign key then there is 1-1 relationship between them, but talking about 1-N and N-N relationship regarding same tables how the real life example can be put forward. I have not completely understood.
Tablet
TabletId
Name
description
Maker
ExpiryDate
Billing
BillingId
TabletId F.K
TDate
so from above table structure it is clear that one bill can have one tablet only. but if i want one bill can have multiple tablets then how will i achieve that.
Please give me example of Tablets and Billing table for 1-N and N-N relationships
When talking about relationships in a database, one could be more precise by stating the minimum and maximum links. The relations we usually see in a database are:
1:1 implemented as {1}:{0,1} Example: a user has or doesn't have one address. So, each user has 0 to 1 addresses; an address belongs to one user.
1:n implemented as {1}:{1,n} Example: a user has one or more or no phone numbers. So, each user has 0 to n phone numbers; a phone number belongs to one user.
m:n implemented as {0,m}:{0,n} Example: a product in one or more or no shops; a shop sells one or more or no products.
And here is how we omplement these relations:
The address table has a user ID and it's the table's primary key.
The phone table has a user ID.
There is a bridge table linking product and shop consisting of these two columns: product ID and shop ID.
Of the three relations the first (1:1) is rare. Usually we would rather store the values in a single table. But in the address example we could use it to easily guarantee that a user either has a full address with both street and city and country given or none at all.
The 1:n and m:n relations are both frequent in databases.
I have just started a course on database design and have been given a homework where one of the tasks is to list all the entity types of a fictional hospital according to this pdf: http://docdro.id/mbzdtUg.
I am struggling to figure out what should be an entity type and what should not. I will give you a basic example:
"Staff" is obviously an entity type but each of the staff have to have details regarding their qualifications and work experience. Since a staff member can have multiple qualifications and multiple work experiences these cannot be attributes... right? So should "Staff Qualification" and "Staff Work experience" be an entity type?
According to entity definitions I have read entities should be independent and represent objects that actually exist. What does it mean for an entity to be independent exactly? The "Staff Qualification" and "Staff Work experience" entity types would not exist if the entity type "Staff" didn't exist. Therefore they aren't independent (???) nor do they represent something that exists (physical object). Then what are they if not entity types? Should for example "Appointment" be an entity type? I am really confused... any help is appreciated.
Thanks!
EDIT: Should mention that this should be following a Entity-Relationship model (ER)
EDIT 2: Example 2: A patient can be either a outpatient or a inpatient. Should I make these into 2 entity type or only 1 (Patient)?
Looks like you're on the right track and your understanding is correct. If you foresee that Staff table can have multiple qualifications or work experiences - then qualification and work experience itself should be separated into a different entity table, so should the Appointment.
This is also where the normalization comes into place - because you could have two different staff members have the same work experience (or qualification) - then technically you don't want to just simply have a child table for Staff as that would result in a lot of data duplication. Usually, using normalization principles you would instead create a separate entity table WorkExperience where you would have all your different WorkExperiences. There would be no relationship between Staff and WorkExperiences tables. But you would also create StaffWorkExperiences table (joining table/buffer table), which would be a child of Staff (1:M) , but would also have a constraint to WorkExperiences table (M:1). So essentially you would end up with Staff table linking to StaffWorkExperiences table and the StaffWorkExperiences table in turn linking to WorkExperiences table.
Lastly, if you also have a patient table and the patient can be either outpatient or an inpatient - then that is more like a property and there is no need to have an extra table - so you would have only a patient table and then another column (PatientType or something like that) to describe this particular property.
EDIT
I have added an example schema of how this would look like with a joining table.
I have researched this to no end. I am not the only person who has asked this question... but I would like your thoughts regarding the best practice.
I'm trying to design a Database that will track financial transactions. For the sake of simplicity, each transaction can only have one Category, and each category can only have one Sub-category.
I have a self-referencing table, like this:
Table: Categories
ID, int, primary key
parentID, int, foreign key
description, text
Long story short, you end up with data like this:
1 Auto [null]
2 Bills [null]
3 Healthcare [null]
4 Maintenance 1
5 Gasoline 1
6 Cell Phone 2
7 Rent 2
8 Prescriptions 3
9 Dentist 3
So far, so good. Here is my problem:
I don't know the proper way I'm supposed to relate this all back to my Transactions table. 'Transactions' has a column for 'Category' and 'Subcategory'. Transaction.ID would be the PK, and Categories.ID would be the FK.
With Transactions related to Categories in the manner specified above, that means any value from Categories could be written to Category or Subcategory...
Is it my responsibility as the programmer to control access to the table via a form? In other words, is my only option 'programmatically controlling' what goes into the Category and Subcategory columns?
Remember, each Category can only have one Subcategory. The selected Category should only allow that Category's children...
Am I making sense?
GOOD: Auto -- Maintenance
BAD: Healthcare -- Gasoline
The case you pose is subset of the more general problem of encoding hierarchical data, tree structures, in relational tables. This case has been studied in great detail ever since relational databases first made the scene in the late 1970s.
In bookkeeping systems in particular, the idea of subcategories and categories comes up, every single time. Larger scale industrial systems tend to have a four level system, with overall account type (Expenses), Category (Transportation), Subcategory (Automotive), and sub-subcategory (Gasoline).
Your research might be more productive if you used the following search terms: "Tree structure in relational design". That search yielded the following Wikipedia summary:
http://en.wikipedia.org/wiki/Hierarchical_database_model
You can find lots of related questions and answers here in SO. Search under "nested sets" or "adjancency lists" for a couple of techniques.
Your problem is going to be to simplify the answers you will find down to the case where there are only two levels: category and subcategory.
I think whatever design you choose will want to make the following rule explicit: Subcategory determines category. and you will, IMO, want the DBMS to enforce this rule so that no transaction ends up with a subcategory that is inconsistent with its category.
So your categorizations are not orthogonal and independent (such as gender and city), but rather hierarchical (such as State and County).
In order to enforce a hierarchical categorizations, use a single categorization table with a ID column as primary key, referenced as a foreign key in the data table, and two descriptive fields Category and Subcategory.
To facilitate data entry you might supply a combo box Category which filters the available subcategories. However the actual foreign key reference is supplied by the selection made in the Subcategory combo box, which must list both fields, Category and Subcategory. It would be usual to concatenate these two fields with a delimiter such as dash (-) or pipe(|).
Coming from question “Relation” versus “relationship”
What are definitions of "relation" vs. "relationship" in RDBMS (or database theory)?
Update:
I was somewhat perplexed by comment to my question:
"relation is a synonym for table, and
thus has a very precise meaning in
terms of the schema stored in the
computer"
Update2:
Had I answered incorrectly that question , in terms of RDBMS, having written that relation is one-side direction singular connection-dependence-link,
i.e. from one table to another while relationship implies (not necessarily explicitly) more than one link connection in one direction (from one table to another)?
A RELATION is a subset of the cartesian product of a set of domains (http://mathworld.wolfram.com/Relation.html). In everyday terms a relation (or more specifically a relation variable) is the data structure that most people refer to as a table (although tables in SQL do not necessarily qualify as relations).
Relations are the basis of the relational database model.
Relationships are something different. A relationship is a semantic "association among things".
Relation is a mathematical term referring to a concept from set theory. Basically, in RDBMS world, the "relational" aspect is that data is organized into tables which reflect the fact that each row (tuple) is related to all the others. They are all the same type of info.
But then, your have ER (Entity Relationship) which is a modeling methodology in which you identify objects and their relationships in the real world. Then each object is modelled as a table, and each relationship is modelled as a table that contains only foreign keys.
For instance, if you have 3 entities: Teacher, Student, Class; then you might also create a couple of tables to record these 2 relationships: TaughtBy and StudyingIn. The TaughtBy table would have a record with a Teacher ID and a Class ID to record that this class is taught by this teacher. And the StudyingIn table would have a Student ID and a Class ID to reflect that the student is taking this class.
That way, each student can be in many Classes, and each Teacher can be in many classes without needing to have a field which contains a list of class ids in any records. SQL cannot deal with field containing a list of things.
A relation is a table with columns and rows.
and
relationship is association between relations/tables
for example employee table has relation in branch its called relationship between employee table and branch table