This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
You will need to either define your foreign key columns on both sides of the relationship if it is bidirectional. If the relationship is not bidirectional you will need to add a key column to the child table only and add a unique constraint to that column.
You are mistaken. A one-to-one relationship implies a situation where A --> B and B --> A. Such an example might include social security numbers and e-mail addresses since having one tends to give you the other. In general, one-to-one relationships across tables aren't that common in a database.
What's more common is what your describing, which is one-to-many relationship. An employee has one company and the company has many employees. You should refrain from referring to this as a one-to-one relationship in any way. The employee may determine the company (as in your example) but the company does not determine the employee, therefore its not one-to-one.