I have three tables in my PostgreSQL database:
User - Contains a username and password
MaleProfile - Contains information related to each male user
FemaleProfile - Contains information related to each female user
Initially, instead of having separate MaleProfile and FemaleProfile tables, I had a single Profile table. In that situation, I would have had a one-to-one relationship between the User table and the Profile table. But I've since decided that I really need separate profile tables for men versus women. In this new situation, each record in the User table must map to one and only one record in either the MaleProfile table or the FemaleProfile table (but not both). From the other direction, each record in the MaleProfile table maps to one and only one record in the User table. The same holds true for each FemaleProfile record.
Strictly speaking, the relationship between the User table and each of the profile tables is one to zero-or-one. But are these relationships essentially just one-to-many relationships in the sense that "many" in this case means just zero or one (but not more than one)? If so, would I express them as you would any one-to-many relationship by creating a foreign key column in the MaleProfile table and in the FemaleProfile table, each of which points to the PK column in the User table? Would I need to add any additional constraints to the profile tables to maintain referential integrity?
Thank you.
Just make sure the referencing column in your male/female tables has a uniqueness constraint on it as well as a foreign key constraint. This is a 1-to-1/0 relationship, not 1-to-many.
CREATE TABLE MaleProfile
(UserId INT NOT NULL PRIMARY KEY
REFERENCES "User" (UserId));
I believe that you should put the employeeID number in the profile tables and enforcing a unique constraint in those tables. Although I can't really think of how to keep someone from having both a male and female entry, I believe that this way is the way to go.
Check out https://stackoverflow.com/a/669015/1504882 to see a similar situation to yours, but instead with different types of employees.
Related
In my application I'm creating a case having a supervisor, but as the supervisor can be either an employee or an external supervisor, I'd like to be able to save either an employee id for the internal reference or a string for the name of the external supervisors name.
How should I implement this? Is having a table "case" and the sub-tables "case_internal_sv" and "case_external_sv" the way to go?
There's not a lot of information in your question on which to base an answer.
If there is common data and functionality across all types of supervisors then you will probably want one table to hold that common data. That table would establish the primary key values for supervisors and the case table would have a foreign key into this table. Information that is unique to either internal or external supervisors would go into separate tables and those tables would also have a foreign key back to the common supervisor level data.
This design is superior because you only have one place to go in order to find a list of all supervisors and because you can enforce the supervisor / case relationship directly in the database without a lot of code or additional constraints to ensure that "one and only one" of two columns is populated.
It's sufficiently superior, from a database point of view, that I'd consider using this design even if the data for internal and external supervisors is completely disjoint (which it's unlikely to be).
If your database allows you to define multiple primary keys you could have field employee and field employee_type combine to form the unique primary key. If not you could have an autogenerated primary key for the table and have a field for employee type and a field for employee_id.
What database are you using?
Having tables too normalized can do more harm than help. You should evaluate the benefits/drawbacks of having sub-tables based on your requirements.
A simple solution can be to have a 'sv_type' column in 'case' table. And have two columns
'internal_sv_id', a nullable foreign key to the employee table
'external_sv_name', a nullable string to save external name.
Then check for supervisor in one of these two columns based on the 'sv_type'
This design might not fully conform to 3rd normal form, but it can save lot of costly joins and allow integrity with employee table.
As for me, I'd go for the simplest solution in case of doubt.
I'm trying to design my database with very basic tables and I am confused on the CORRECT way to do it.
I've attached a picture of the main info, and I'm not quite sure how to link them. Meaning what should be a foreign key, or should some of these tables include of LIST<> of the other tables.
UPDATE TO TABLES
As per your requirements, You are right about the associative table
Client can have multiple accounts And Accounts can have multiple clients
Then, Many (Client) to Many (Account)
So, Create an associate table to break the many to many relationship first. Then join it that way
Account can have only one Manager
Which means One(Manager) to Many(Accounts)
So, add an attribute called ManagerID in Accounts
Account can have many traedetail
Which means One(Accounts) to Many(TradeDetails)
So, add an attribute called AccountID in TradeDetails
Depends on whether you are looking to have a normalized database or some other type of design paradigm. I recommend doing some reading on the concepts of database normalization and referential integrity.
What I would do is make tables that have a 1 to 1 relationship such as account/manager into a single table (unless you can think of a really good reason not to). Add Clientid as a foreign key to Account. Add AccountID as a foreign key to TradeDetail. You are basically setting up everything as 1 to many relationships where the table that has 1 record for the id has the field as a primary key and the table that has many has it as a foreign key.
I am preparing for an exam from databases and there is this one thing that puzzles me. From what I've read both sides of any relationship can be constrained to be NOT NULL. I've seen it in at least 2 books and various articles.
Nobody however explains how to insert values into these tables. As far as I know it is not possible in most databases (with the exception of Oracle) to insert into multiple tables at once. That means that it would be needed to insert into one of the tables first. However at that moment there doesn't exist a corresponding entry in the second table so I cannot reference it which violates the NOT NULL constraint.
Another problem is that it is hard to enforce the relationship from both sides in 1:N or M:N relationship. (I can only think of triggers)
So the question is: Are these relationships really implementable or are they just "theoretical" concept which is not used in real life?
To implement a relationship between two entities (tables) in SQL, the primary key of a table (Table1) is make the foreign key in the other table (Table2). If it’s two way mandatory relationship (NOT NULL for both tables) then the entries should be first inserted in Table1 which has the primary key first and then the entries for the other Table2 containing the primary key of the Table1 as the foreign key should be inserted. Check this link for more details and an example.
i am a student and i have a question about database schema , i already created the Entity Relationship Diagram [ERD] and in this step i should do the database schema , must all the entities on my database has a relation between them and the other entities ? i.e : each entity should have a foreign key for the entity before it , because i can create all the tables and only 2 tables can have a relation between them and i control the other tables using C# program i am going to create .
** in my ERD all the entities have a relation between each other .
...must all the entities on my database has a relation between them and
the other entities?
No. Entities of course can stand on their own. Although in practice if you're finding that you have very few relationships you're probably doing something wrong...
You're sort of right in saying that only two tables can have a relationship but I'd word it as a relationship can have only two participants; tables can certainly relate to more than just one other table.
Any time you create tables in the database if there is a relationship between the information in the tables then you should create a relationship to make sure that when the data is entered into the tables that the reference data will be there. This will enforce referential integrity. For example:
Employees Database:
EmployeeInfoTable:
pk EmployeeID
EmployeeName
EmployeeDateHired
fk SalaryID
EmployeeLoginTable
pk LoginID
fk EmployeeID
Username
Password
SalaryTable
pk SalaryID
SalaryRange
So what this would do is make sure that if you add a salary to an employee it has to exist in the Salary table and if you added a login then you would have to have an employee to reference. It's just an added layer of security to make sure that the data that is being input into the database is valid and can be used.
While you can technically control this with C# or whatever programing language you want it's easy to forget these little rule especially in a database that has like 200 tables or more. So getting in the habit of using relationships and maintaining referential integrity is a very good thing to do.
All entities need not have relationships with each other. A relationship will only exist between two entiries in the ERD if one entity somehow relates to the other.
The general rule of thumb for creating table is:
Each entity in the ERD will have a table for it
For a one-to-many relationship in the ERD, the many side table will contain a foreign key to the one side table
For a many-to-many relationsip, there will be a separate table for the relationship that will contain foreign keys to both the entity tables
If a relationship has an attribute, there will be a separate table for the relationship that will contain foreign keys to both the entity tables
the primary key should always be id due to convention, and your foreign keys could be called othertablename_id so if a table has a link to all the other tables it will need a key for each one of those.
for example: if dogs has more than one owners but owners can only have one dog, you could just have dog_id in the owner table. but then you would have to query the owners table to find all the owners of one dog.
if dogs have more than one owner and owner can have more than one dog, then you have to have a join table called dogs_owners with id and both foreign key dog_id and owner_id
of course you can name your tables and fields whatever you want but it's convention to use id and _id
yes an entity usually equates to just one table, apart from when you have many-to-many relationships between your entities.
When creating a junction table in sql to handle a many-to-many releationship between two tables, should the foreign key columns in the junction table be able to store null values?
It is a bad idea to do that because it stores no information.
A junction table is a link between 2 tables. If a record exists, by definition it must have the id from both sides to make a "junction" link. Otherwise it carries no useful information and is known as a waste-of-space.TM
No. It doesn't make sense to store a row representing the absence of a relationship in a table you designed to store the presence of relationships.
In addition to the other answers:
the two columns referencing the other tables are usually the primary key of that junction table. So per definition they cannot be null.
There are some circumstances where those columns do not make up the complete primary key (e.g. when having an attribute as part of the link and allowing multiple links with different attributes) - but then that attribute is part of the PK.