Hello all, just joined the forums as it looks like an interesting place and ive picked up a lot of tidbits from other users' posts...

Anyway im working on a project, learning and implementing ER (entity relationship) models. i must develop a drawn design (diagram) to satisfy the following conditions

• Every airplane has a registration number, which is unique, and each airplane is
  of a specific model.
• The airport accomodates several airplane models. Each model is identified by a
  model number (e.g., DC-10), and has a capacity and weight.
• A number of technicians work at the airport. Each technician is identified by
  his/her SSN. Also you need to store the name, address, phone number and ssalary
  of each technician.
• Each technician is an expert on one or more plane models, and his or her expertise
  may overlap with that of other technicians. The expertise of each technician
  needs to be stored.
• The airport has a number of tests that are used periodically to ensure that air-
  planes are still airworthy. Each test has a FAA (Federal Aviation Administration)
  test number, and this is unique. Each test also has a name, and a maximum
  possible score.
• The FAA requires the airport to keep track of the last time an airplane was
  administered a particular test. For each such testing, you need to store the date
  of the test, the total number of man-hours spent on the test, and the score the
  airplane received.

ive tried out many different approaches and i can't get it all to make sense in my head, heres what i have so far

(rectanges=entity types, ovals=attributes, diamonds=relationships)

Has your instructor covered the idea of using tables to store information about relationships (for many-to-many relationships) yet? When is this assignement due?

-PatP

Hey Man,
I didn't add the 'attributes' but I resolved your entities for you.
A few pointers.....

Your teacher ( and business people) don't explain things completely - and programmers aren't smart enough to extract or flush out the complete requirements.

When you hear, or read, what you believe to be 2 entities, and they're in a relationship - question the relationship from both sides

Let me ask this.... Do you own a car? OK... we just looked at a relationship between you and the car from one side

What about the car, does it have ONE owner?

Your teacher only talks about relationships from one side of the relationship - "Each airplane is of a specific model" - IMMEDIATELY... you should start question, 'Can an Airplane Model be the model for only zero, one or many models?'

Many to Many - Pat mentioned this. You have several many-to-many relationships in your model. I showed them in green. A good logical data model shouldn't have many-to-many relationships, they are 'resolved' into what is called associative entites, as I have done in the attached model.

The associative entity (the pickle in the middle guy) has is the child to the two entities that have the many to many.

EXAMPLE: An airplane can be fixed by one or more technicians. A technician can work on one or many aircraft. So an associative entity is a sort of listing of aircraft and technician who can work on them.

Sorry it's 1:30 AM.. I'm not good at expalining associatives at this hour. Your book should expain this.

OK... I DID NOT add the attributes you have or need but here's the rest of your model, or pretty close I think...

Fly On!!!
Vmusic