Create a logical ERD for each of the problems on the following pages using the crowsfoot format. Be sure that each entity has the entity name at the top of the box, the primary key attribute or attributes in the middle of the box, and the non-key attributes in the bottom of the box. Lines should separate each part of the entity box. The ERD should not have any M:N relationships and all attributes should be placed within an entity. Each entity must have a primary key defined. A primary key may consist of one or more attributes. Please include all required foreign keys and denote the foreign key(s) with the notation (FK) on the ERD. You do not have to differentiate between an identifying or non-identifying relationship. It would be very helpful to include verb phrases for each relationship, but verb phrases are not required on the ERD. If you need to add any assumptions for the business rules, please note those on your diagram.

4. The database will support the placement office of a leading graduate school of business. The primary purpose of the database is to schedule interviews and facilitate searches for jobs by students. Here is additional information about the data to be stored:

Student data include a unique student identifier, a name, a phone number, an email address, a major, and a minor. The placement office in the school of business maintains a standard list of job titles and position descriptions based on the U.S. Department of Labor Bureau of Labor Statistics' list of occupations. (FYI: https://www.bls.gov/soc/) Position data for our HW database include a unique position identifier, job title, and a position description. Examples of job titles are: Systems analyst, network systems administrator, sales computer equipment, marketing analyst, and entrylevel accountant. These are standard job titles that could be downloaded from the Department of Labor into the database for the placement office. In addition, our database will store a position description for each unique position identifier. Here is an example of a data value for a position identifier, job title and position description:

PositionID: 15-1121

Job Title: Computer Systems Analyst

Position Description: Analyze science, engineering, business, and other data processing problems to implement and improve computer systems. Analyze user requirements, procedures, and problems to automate or improve existing systems and review computer system capabilities, workflow, and scheduling limitations. May analyze or recommend commercially available software.

Data about companies who interview students through the placement office include a unique company identifier, and a company name. Each company must relate its open positions into the standard list of positions maintained by the placement office (downloaded from the Department of Labor). For each open position, the company lists the city, state (or province/region) and country for that position. For example, Dell might have the position of sales computer equipment available in Dallas, Nashville, Washington DC, Paris (France), and Perth (Australia).

The database must be able to generate a list of open positions for a given company and for all companies as well as a list of interviewers

Interviewer data include a unique interviewer identifier, a name, a phone and an email address. Each interviewer works for only one company, but a company could have multiple interviewers. An interviewer may interview more than one student during a given day, but will only interview one student during a given interview.

An interview includes a unique interview identifier, a date, a time, a location (building and room), one student and one or more interviewers. More than one interviewer may participate in the interview with the one student and the business school wants to keep track of however many interviewers are participating in the interview. The length of an interview may vary in time.

An interview is not for a particular job. It is possible that an interviewer may interview a student for more than one job at the same time, so do not relate a specific job to a given interview.

An interview is not for a particular job title, so do not relate an interview to the standard list of position job titles.

The data will be used to create schedules for rooms, interviewers, companies, and students.

Keep in mind during your design that an entity almost always consists of more than one entity instance (in other words, it would be odd to have a table with only one row). For example, if you find yourself tempted to create an entity for the placement office then think about what data you will be storing in that entity. This organization has only one placement office so there would be only one instance of that entity. An entity with only one instance isnt really an entity. Also keep in mind that an ERD is not a process diagram. It doesnt really matter who does what, such as how a student will be matched with an interviewer, or where the data comes from you should focus on creating a blueprint of all data necessary to support the application. Finally, think about what the application is supposed to accomplish when designing the required data. Think about what output information (reports and queries) might need to be generated from the system to ensure that your entities are related in such a way that the output could be produced.