I have two "entity" tables: Provider and User. Both Provider and User can have multiple addresses (shipping, billing, etc.).
Rather then put address information in each entity table, I want to create a table that is common to both of them: An address table. I looked into creating, for instance, an address table with a primary key (identity column), entity type (provider or user), entity key (primary key of the parent entity table) and address type (shipping, etc.), along with the necessary address information.
One trouble I'm having is with foreign key constraints. If I have a foreign key from the parent entity table related to an address row, I found that I have a foreign key violation when I try to insert data.
I was thinking on removing the FK in the tables and then create on EF 4.1 the manual mapping but I dont know how can I do this:
http://i49.tinypic.com/2dt56dv.png (here is the image of the tables - objectid in address table holds userid or providerid and objecttype is a varchar that can be "USER" or "PROV")
How can I get around this? I'd like to use one table for addresses but I can't add a child for one parent without having a related row on the other parent. Of course, I'd like to keep using the foreign keys for referential integrity.
Thanks
this is a pretty common scenario.
[Provider table]
ProviderID (PK)
AddressID
[User table]
UserID (PK)
AddressID
[Address table]
AddressID (PK)
Street1
Street2....
Go into provider table and add a FK from Provider.addressID to Address.AddressID
Go into Users table and add a FK from User.addressID to Address.AddressID
that should work and no FK's will be violated.
Related
trying to understand a DB concepts and ran into this question.
Identify relationship is when a parent table pk is child table fk. For example, I have a person table and ssn table. ssn cannot exist without a person and a person can have only 1 ssn and ssn can belong to only 1 person so it should be 1:1 identified relationship.
Question #1: Whey do I need to make person_id as a primary key on SSN table if I can uniquely identity ssn since it's already unique?
When I set person_id in SSN table as a foreign key of id in Person table my SQl workbench creates 1:n relationship. However, it's is not accurate since a person can have only 1 ssn(picture 1)
Question #2 - Why does it happen since it can be 1:1 relationship as well and I can query ssn based on person_id fk easily
If I reamove the person_id from SSN table as a primary key the relationship becomes unidentified (picture 2)
Question #3 - why is it happening since I
still can uniquely identified ssn without person_id field
If I use a workbench to create 1:1 identity relationship it creates a foreign key in the PERSON table, hence making it a child table and SSN a parent table which is not accurate as well
I know that people suggest just simply place a data into a parent table when there is 1:1 identify relationship but what if for example a table already has 20 fields and adding another 20 fields would make it super big, wouldn't be easy to create a separate table and link them into 1:1 relationship (picture 3)
Question #4: It's pretty easy to memorize - if 1:1 set parent table fk as child table pk and if 1:n - set child table fk as parent table pk but I want to understand what is the logic behind it?
Thank you in advance
enter image description here
If it’s 1:1 there is no “parent” or “child” - they are “siblings” of each other.
The requirement as per question title is there because without the reverse foreign key, it would not be 1:1 but would be 1:0..* (one to many).
To guarantee 1:1 both sides must exist and the way to do that is with bidirectional FKs.
I have two (mysql) tables -- company and user. They are structured as follows:
`user`
- id
- company_id (FK to company)
- name
`company`
- id
- name
- admin_user_id (FK to user)
The user table foreign keys to the company table, and vice versa.
I was wondering if the above pattern is ok, and if it's not why it's not, what could be done to improve it.
At a high level, your data model makes sense. However, you have no guarantee that admin_user_id points to a user in the same company. You can solve this by doing:
create table users (
user_id int auto_increment primary key,
company_id int,
name varchar(255),
unique (company_id, user_id) -- redundant but desirable for the foreign key reference
);
create table companies (
company_id int auto_increment primary key,
name varchar(255),
admin_user_id int,
foreign key (company_id, admin_user_id) references users(company_id, user_id)
);
alter table users
add constraint fk_users_company_id
foreign key (company_id) references companies (company_id);
If it is an accurate representation of your business domain then that's what really matters. There is a possible problem in SQL however. SQL only allows one table to be updated at once so either company or user has to come first. Normally you have to allow the constraint to be broken temporarily, either when you insert a new company with no corresponding user, or insert a new user with no corresponding company. To achieve that you can make one of the foreign keys nullable or you can temporarily disable the constraint.
Some data modellers dislike circular dependencies, even in purely conceptual models where the limitations of SQL are irrelevant. A few people will perceive circular dependencies as a modelling mistake - wrongly in my opinion. Disapproval of circular dependencies seems to be associated with ER modelling specifically. Interestingly, circular self-referential dependencies are taken for granted in Object Role Modelling which even has a special notation for them (ring constraints).
I am trying to create a database for work. I have two different types of users: internal and external. Each type has different properties so I just created two separate tables for them. In my internal table I have the following fields:
f_name VARCHAR(32),
l_name VARCHAR(32),
empl_status_id INT,
admin_grp_id INT,
reliab_status_id INT,
supv_id INT
And my external table has the following:
f_name VARCHAR(32),
l_name VARCHAR(32),
email VARCHAR(32),
phone VARCHAR(20),
org_id INT,
supv_id INT
I realize that I could probably create a separate table that contains the names of the users and a foreign key pointing to either internal or external, but that aside, I added a foreign key constraint to my internal table that refers supv_id to another internal user. I called it fk_supv_id. When I tried to do the same for my external user table, I got ERROR 1005 (HY000).
At first I couldn't figure out what the problem was but when I tried doing it with a different name, it worked (i.e. instead of calling it fk_supv_id just like for internal, I called it fk_xtsupv_id).
So my question is, what is the correct way to this? It's the same foreign key in two different tables. In both cases it refers to an internal user. Is there a way to do this without having two different names? Or should I opt for the table of names idea and add the supv_id constraint to that table along with f_name, l_name, and user_type?
Advice and suggestions are appreciated,
Thanks! :)
There are columns and there are foreign keys (FKs) and there are constraints.
You can have a column name in a table regardless of other tables.
A FK is a referencing table and column set and a referenced table and column set. All the names together identify a FK. It's a conceptual thing about a database.
A FK constraint, being a constraint, is a thing whose name must be unique over the database. It has and enforces an associated FK, namely the one described in its declaration. You can have multiple FK constraints in a table enforcing the same FK.
The DBMS has automatic unique names for FK constraints. Eg a name part plus a number part where the constraint is the numberth FK constraint of the table with that name. You can actually have the same nameless FK constraint definition text multiple times in a table and in multiple tables, each for a different FK constraint. (The ones inside a given table enforce the same FK.)
You should have a unique naming scheme for when you want to name them. Referencing and referenced table names should be involved, and when necessary distinguishing column names.
Confusingly, we say FK when we mean FK constraint.
When you say "It's the same foreign key in two different tables," that misuses terms. There are two different FKs involved, and corresponding FK constraints. You mean maybe "it's the same referencing columns and referenced table and columns in both FK constraints" or "it's the same text re referencing in both table declarations' FK constraint declarations". But the FK constraint names must be unique.
When you say "In both cases it refers to an internal user," you are confirming that the type and/or table of the referenced column are the same for both FK constraints. But they are different FK constraints for different FKs.
Names of FKs have to be unique. You need to use two different FK names. I would further suggest that you should include information about the tables being linked in the key name to make it more descriptive.
Currently, I am working on the very beginnings of a user database in MySQL InnoDB. So, I will use that to help demonstrate.
Users Roles
--------------- ---------------
userid (bigint) PK >roleid (tinyint) PK
email (varchar) rolename (varchar)
username (varchar)
password (char)
>roleid (tinyint) FK
created (timestamp)
Right now, I am trying to create a one-to-many relationship between Role and Users, based on roleid. For this, I am thinking that On UPDATE CASCADE and On DELETE Restrict.
That's what I feel like I should do, I'm not sure if it's correct or not. However, I'd like to gain a better understanding of it.
Say I wanted to created one-to-one, then that would look like On UPDATE Restrict and On DELETE Restrict, is that correct?
Sorry, I am completely confused here and I am unable to find a tutorial, blog, or explanation that breaks down the different settings to the Relational Model. Could anyone help explain it these types as well as the other types (many-to-many, many-to-one) based on what I have here?
One role can have many users associated to that role. This entire relationship is represented physically with a foreign key on the USERS table that references the ROLES table.
The ON UPDATE and ON DELETE options in the foreign key constraint help to enforce "referential integrity" in the database, but they don't specify at all what the relationship is between the USERS and ROLES entities.
If I create this foreign key with ON DELETE RESTRICT, when I would try to delete a record from the ROLES table where the key was in use on the USERS table, i would get an error. This has nothing to do with the type of logical relationship that exists - it is just a constraint.
A many to many relationship cannot be modeled using one foreign key. Logically, if A user can have Many Roles, storing the role id on the users table doesn't make sense.
In that case, you would create a table in between, and put the userid and roleid columns on this table, with foreign keys connecting them to users and roles respectively.
USERS USERS_ROLES ROLES
userid PK - userid FK
roleid FK - roleid PK
Here's the MYSQL manual pages about foreign key constraints. It's a good reference and explains what each option means.
Edit:
This touched on the one-to-many and many-to-many relationship types. Rarely will you see a one-to-one type in a database (in those cases merging the tables makes sense). Sometimes for performance you would use it. In these cases, typically your primary key should be the same on both tables:
USERS USERS_EXTENDED_ATTRIBUTES
userid PK - userid PK FK
Only 1 user id should exist on each table for a 1-1 relationship.
In my db I have three tables (I have more but for case is equal, users can be companies or single people).
Users has a primary key id_user;
Company has a primary key id_company and a foreign key users_id_user;
job_offers has a primary key id_job_offers and two foreign keys: company_id_company and company_users_id_user.
My questions are:
Does a primary key make sense in job_offers? I don't think that there is a reason for it.
job_offers has two foreign keys, one related to company and other to users. Is there a problem with this? Does there exist another way to accomplish the same task?
All tables should have a primary key. It sounds like you are asking whether your primary key should be a surrogate key or a natural key.
You might ask the same question of your other tables as well. For instance, assuming the email column in your users table is required and unique, it could be used as a (natural) primary key.
This question is pretty heavily debated, and both approaches can work (as can a mixed approach). If you want to read up on this subject in general, do a google search for "Natural vs. Surrogate Key".
Does a primary key make sense in
job_offers? I don't think that there
is a reason for it.
Yes . I agree that every table should have their own PK.
Should each and every table have a primary key?
I have more but for case is equal,
users can be companies or single
people
job_offers has two foreign keys, one
related to company and other to
users. Is there a problem with this?
Does there exist another way to
accomplish the same task?
The system have two types of users:
normal user (person) and company user.
The job_offers is a table that save
job offers from a company. If a
company user want to post a job , a
record will be inserted to the
job_offers table . Then once the
normal user get this job offer , the
job_offers.company_user_id_user will
be assigned to this normal user 's
userid.
But from your ER diagram , Company.users_id_user is the PK , which cannot be null , and this PK is used in the job_offers.company_users_id_user as a FK. So job_offers.company_users_id_user also cannot be null .
As a result , it cannot handle the situation that a company user just post a job and before a normal user gets this job offer or no one gets this job offer eventually .In this case, job_offers.company_users_id_user should set to null , which violates the job_offers.company_users_id_user 's not null constraint.
I will accomplish the same task using this design:
Users
=================
id_user (PK)
email
activation
password
Company
=================
id_company (PK)
activities
foundation
user_id (FK to Users)
description
job_offer
=================
id_job_offer (PK)
id_company (FK to Company)
description_offer
tags
user_offer
=================
id (PK)
user_id (FK to Users)
job_offer_id (FK to job_offer)
1) make sense a primary key in
job_offers? I think there is no reason
Yes there is - every table ought to have a primary key. It's called 'normalization.'
Your choice might not be very good. I'd say that the two foreign keys together should be the primary key, not the id column.
2) The job offers have two foreign
keys, one related to company and other
to users, any problem ? exists another
way (best way) to make this?
No, that's how many-to-many relationships are done.
I think you're right. There is no need for a separate id field there. The two foreign keys should, together, make up the table's primary key.
Looks fine to me.