I'm currently making a database for my java web app for Tourism.
Only register user can book a tour but can take along several people.
For this, I separate into User table and Guest table, each with its own primary key.
Everything is set so far, but when it comes to making my BookRoomDetail table, I have to fill in which person for which slot in the room. the problem arises when both register user and guest can fill this slot, and they're from 2 different tables.
How do I set the foreign key(or anything else) for this?
As I got your problem, you can add one more field for MainUser in your tblBookRoom Detail as a foreign key. And whenever any user books room you can add his/her primary key and guest primary key in forwhom field.
**tblBookRoomDetail**
ID (Primary key Of Table)
RoomId
For Whom (For MainUser or Guest)
MainUser (MainUser Primary Key Who is doing this reservation)
Slot
FromDate
ToDate
BookId
This is not possible to insert two different primary key value in a column of other table, if you have relation in them.
You can do this without the making the relation in them.
But it's not a good process because if the both key value same in this case you can't identify the actual.
If you want to achieve this goal then you should have a table tblAllUsers which primary key is also primary key of the tblGuest and tblUser and then you can make relation to tblBookRoomDetail table direct to tblAllUsers. In this case you can differentiate the Guest user or Registered Users.
or
Can Create the two different columns in tblBookRoomDetail, one for Guest user and second for Registered user.
Related
Let's take an example of a login table with the columns: id (primary key),username,password,status.
id is primary key but still we authenticate user by searching table through username+password. Doesn't it violate normalisation rule?
Another example: suppose we have two tables, employer and job
employer table's id is used injob table as foreign key but job table itself has its own id
job table
---------
id (primary key) || employer_id (foreign key) || etc etc
Now when we will search job posted by a employer we use employer_id but this table has its primary key?
Primary key on any table is an unique identifier and indexed by default. It does not mean that records will always be searched through that field itself. Now, when you are to link a parent record to a child record, you can use the primary key to establish the relationships.
While trying to get the records, you will make use of primary key as a link between different tables. For example, you have employers and employees. A search might look like: "Get me all the employees for this employer". Now, employer is the main entity here and we are looking for linked employee records for it. Here, employer id will help us fetch related records. A query for the same might appear something like this:
SELECT [COLUMN NAMES HERE]
FROM EMPLOYER INNER JOIN EMPLOYEE ON
EMPLOYER.ID = EMPLOYEE.EMPLOYERID
I suggest you to read some tutorial, but, shortly ... a primary key is an id that is unique and not null and identifies an entry in your table. A foreign key is a reference to an id in another table. As you said, employee and job tables. An id is in most cases generated by a sequence, you don't know its value before inserting the record.
You usually perform seraches through username, name, ... datas that are user-known. In your case, when you search for a job, you will probably perform a Join. A join is a relation (and there are more types) between tables. In your case you will do
select *
from employer emp inner join job jjj on emp.id = jjj.employer _id
The ids are usefull, code-wise, when you have to update/delete a record. In this case usually you know everything about your record, id included, then you will use the id (also because ids usually have indexes, so the queries are faster). You can usually create indexes in the columns you use in filters, in order to reduce the execution time of your queries.
We need to distinguish between business (or candidate) keys and technical (or surrogate) keys. The business key is the data item(s) which uniquely identify this row in the real world. The technical key is a convenience for data management, generated by some computer process such as a sequence or sys_guid().
Yes, the use of technical keys means storing redundant information but this is a case where practicality trumps theory. Primary keys should not change but in real life they can (e.g. people change their name due to various life events). Technical keys have no meaning so do not change. Business keys are often compound keys, which is often inconvenient for enforcing foreign keys (and occasionally highly undesirable, for instance when the business key is a sensitive data item such as Social Security Number).
So, it is common for tables to have an ID column as the primary key, which is used for foreign key relationships, and a unique constraint to enforce the business key.
In your first example username is a business key and id is a technical key. This is one reason why we should have two data models. The Logical Data Model has an Entity called user with a candidate key of username. The physical data model has a Table called user with a primary key of id and a unique key of username.
For your second example, it seems you're modelling a Situations Vacant job board. The relationship between Employer and Job is one to many, that is an employer can advertise many jobs. So the Job table has its own primary key, id, plus a foreign key employer_id which references the primary key of the Employer table. This means we can find all the jobs for a specific employer. But because the job table has its own primary key we can identify each job so that we can distinguish the Janitor job at Harrisons Pharmaceuticals from the Janitor job at Ravi's Cash'n'Carry. (Which incidentally shows why we need technical keys: imagine if the employer_id foreign key was a string of varchar2(128) for each row on the Job table. )
In a Logical Data Model the employer_id would be implied on the Entity job by a link to the Entity employee but would be shown (actually it might, it depends on the tool). In the physical model the column must be added to the dependent table, because database constraints (and joins!) physically need the column in order to work.
So we can see that Normalisation applies to the representation and storage of business data but the practicalities of database engines mean that we need additional columns to manage the data.
I'm trying to make a program that has to manage some databases with derby.
In this program, I'm creating two tables, one called "customers" (that has one primary key that is the ID number of the person), and one called "transactions", in which I want one column to reference to the ID of the customer, which I would do through a Foreign key. However, this customer could perform several transactions, so that the actual key would be a combination of the date of the transaction and the id of the customer. Can this be made through the foreign key? Or am I very confused? I would really appreciate any help you guys could give me.
Thanks a lot
It is best to also have a transaction ID. use that id column as the primary key in your transaction table, and have a foreign key user_id to relate to the user.id. Then you can uniquely identify each transaction, all transactions for a user, or query out other things like all transaction within a day for all users, for a set of users and so on.
I am attempting to create a relationship between two tables in Access 2013. The PROJ table has many fields, with the primary key being PID, which is a randomly generated auto_increment number. I would like to use this as the foreign key for another table (JDD) to create a link between them. The primary key for JDD is another non-randomly generated id, UII, and I want the the PROJ table to autopopulate the PIDs into the JDD table. However, logically, I would assume that since it is a randomly generated number that there is no way to connect them and have them auto-populate unless I manually attached the PID to each UII. Is there anyway around this? Access would let me create the relationship but I couldn't find the plus signs to auto-populate data in the Datasheet view.
Thanks!
I have a table named Communications which contain a user's contact numbers. This can either be a Home, Mobile or Fax number. I'm storing them all in one table and identifying them using a Type column. (0 = Home, 1 = Mobile, 2 = Fax). Communications table has a foreign key UserId which maps to my Users table to show User to Number relation. I want to have a constraint so that each user can only have at most one of each Type of number. What would be the best way to model this?
I'm using Database Diagram in SQL Server Manager Studio 2008 and would like a GUI-ish answer as opposed to SQL query if possible.
You can add a NumberType table, containing the values 0,1,2 as primary key in column NumberType, and add a foreign key from table Communications.NumberType to NumberType.NumberType. This way table Comunications will only be able to contain values 0,1,2 (or whatever NumberTypes you define).
Then you add a primary key (or unique index, if you want some other primary key) to table Communications on columns NumberType and UserId. This makes sure that each user may only have one number of each kind.
Simply use composite key {UserID, NumberType}
It also a good idea to keep {UserID, PhoneNo} unique and to make sure that a phone number is of one type only; while allowing for more than one user to have the same phone number, say home phone for a family. In that case you can try something like this
Note: implement AK (alternate key) as a unique index.
I am creating an application that will require a user to register and create an account.
Should I use the person's Login ID (this is the email address) as the unique record identifier or should I also create a PersonID (or rec_id).
Why should I (or should not) create a rec_id ?
If you use the email address as a primary key in the Person table and foreign key in the related tables, it will be hard to implement the Change Email feature - instead of a single update, you will be forced to add a new record to the Person, update all the related records and then delete the record with old email.
Of course the person's mail address usually should be unique. But an additional record ID can be used as foreign key in other tables and so will make table joining much easier.