Motivation for IDEF1X Simplicity Common Standard Useful when relational model is target Air Force 1985 or thereabouts
IDEF1X Objectives To provide a means for completely understanding and analyzing an organization's data resources To provide a common means of representing and communicating the complexity of data To provide a technique for presenting an overall view of the data required to run an enterprise To provide a means for defining an application- independent view of data which can be validated by users and transformed into a physical database design To provide a technique for deriving an integrated data definition from existing data resources
Attributes and Primary keys
Entities strong and weak
Relationships Parent to child relationships. One-to…..
Identifying Relationship
Non-identifying Relationship (Mandatory)
Non-identifying Relationship (Optional)
Non-specific Relationship
Alternate Keys
Foreign Keys
Role Names
The general manager of a small chain of candy stores wants a database to keep track of the stores that it has and the employees that work at them. Each employee only works at a single store. Most employees have another employee that is their mentor. Each store has one manager (which is also an employee). Employees have unique employee numbers. Stores also have unique store ids. For each store he wants to keep track of the city, address (this can be a single attribute in your model), phone and who the store manager is. Attributes for each employee include first name, last name, phone number, and who their mentor is.
Optional or Mandatory Participation Only non-identifying relationships can be Optional. Remember that identifying relationships bring the key into the primary key of the child thus they can’t be NULL. Consider the one-to-many relationship between STORE and EMPLOYEE. Is this optional for EMPLOYEE? That is, can an EMPLOYEE exist with a NULL STORE_ID?
One-to-One What does the Z mean when we have a one-to- one relationship? It is not related to Optional. Consider manages between Employee and Store. An Employee will manage either no store or one store. This does not mean optional. Optional would be mean that a store could exist without a manager.
Roles and Recursive Roles are important when you have a recursive relationship or more than one relationship between entities. Recursive is when an entity is related to itself. Such as employee entity that includes the mentor. The relationship “mentors” is a recursive relationship on the entity employee. The mentor of an employee is another employee. We use role name EMP_MENTOR for the foreign key in the EMPLOYEE relationship. Note that it is an optional non-identifying relationship. Explain.