INFO 340 – Database Management and Information Retrieval

advertisement
INFO 340 – Database Management and Information Retrieval
Spring Quarter, 2004
Information School – Informatics
University of Washington
Assignment 3 (A3)
Entity-Relationship Diagrams
Ryan Prins
Informatics
rprins@u.washington.edu
April 28, 2004
INFO-340: Database Management and Information Retrieval, Spring, 2004, Assignment #3
PART I
Caption
This model diagrams the relationships for an airline. This model includes the flight, aircraft,
certifications, employees, passengers, and seats for flights. The model depicts the relationship
between an aircraft (Aircraft) and the certification (Certified) needed for employees (Employee)
to operate those aircrafts. This could be as simple as taking a class or taking a training class for a
specific model of airplane. This is what the Requires relationship between Aircraft, Certified,
and Employee depicts. Aircraft also depicts a Contains relationship to Seating. This relation is
Page 2 of 7
INFO-340: Database Management and Information Retrieval, Spring, 2004, Assignment #3
meant to show that an aircraft has many seating assignments. This can be seen in the
participation and cardinality constraint in this relationship. It is required for an Aircraft to have
Seating, so it is mandatory and contains many seats. Also, an Aircraft has a has relationship to
Flight since each flight must contain one aircraft. This does not take into account of multiple
flights for the same plane since this would be a different Flight entity. There is also a WorksOn
relationship between Employee and Flight since employees are required to staff flights. The final
relationship is the Requires relationship between Passenger, Seating, and Flight. This
relationship displays that a passenger requires one seat and that a flight requires many seats. But,
it is optional for that seat to be filled on the flight. This is shown in its optional cardinality
constraint.
PART II
Caption
This enhanced entity relationship model diagrams the relationship between programmers,
engineers, and managers that are all working on a project. A Project ConsistsOf many Staff and
Staff each can only WorksOn one Project. The Company also Hires many Staff to be used to
work on projects. The Company also Has many Projects that are being worked on. From this
diagram you can see that a Project is consisted of Staff that is consisted Engineers,
Programmers, and Managers. Of the three positions that are required for the project an engineer
(Engineers) can be both an Applications Engineer (Applications) or a Systems Development
Engineer (System Development). This is shown by the participation and disjoint constraint of
Mandatory, And. There is a similar relationship with the managers (Managers) of the project
(Projects). This relationship differs in the fact that the disjoint constraint changes from And to
Page 3 of 7
INFO-340: Database Management and Information Retrieval, Spring, 2004, Assignment #3
Or. This change displays that a manager (Managers) can be either a Technical Manager
(Technical) or a Business Manager (Business), but not both. There are no subclasses to the
Programmers entity. This is because there are no specializations for this particular entity.
However, each project (Projects) requires that there be engineers (Engineers), programmers
(Programmers), and managers (Managers) as can be seen from the participation and disjoin
constraints.
PART III
Page 4 of 7
INFO-340: Database Management and Information Retrieval, Spring, 2004, Assignment #3
Caption
This entity relationship model diagrams the relationship between hikers, trails and it’s trail info,
messages about trails, scheduling, and partners to hike with. The hikers (users) provide trail info
(ProviedInfo) about a specific (Describes) trail. It is required that a specific TrailInfo has a trail
to assign to. Otherwise the trail information would contain information that is not specific to any
trail. Messages (Messages) can be left by (Post) hikers (Users), hence the multiplicity constraint
of {0..*} on the Post relationship, and these messages then are related to (About) a specific trail.
Hikers can also find partners (Partners) for a specific hike by also finding their specific schedule
(Schedule) to arrange for a particular meeting time. Then the schedule provides details on the
trail that they will be hiking (HikesOn) on. Almost all of the relationships are required, with the
exception of part of the Find ternary relationship and the User Posts Messages relationship. This
because a user does not need to find a partner and schedule for a hike and they are not required to
post messages about a trail.
PART IV
Page 5 of 7
INFO-340: Database Management and Information Retrieval, Spring, 2004, Assignment #3
Caption
This model describes the many different relationships for a particular blog. The blog (Blog) is
OwnedBy it’s Author and the Author Creates Entries that the Blog is ConsistedOf. All of these
parts are required for a blog to work and a Blog can contain many Entries, but one Blog is only
owned by one Author. All of the Entries are OrderedBy Date and consist of a Title and Blurb.
All entries have the option to be commented (Comments) on. Each comment CanBeGiven a
Rating between one and five and a comment can also have a Message. There are also many
Readers who can Leave many comments about a particular entry as well as Browse the
Directory of Blogs. They can also View a particular Blog directly without using the directory. As
was previously stated each Blog is OrganizedIn a Directory of Blogs. In addition to each blog
being listed in the Directory they also each Contain a listing of RelatedBlogs that their readers
might like to also enjoy reading. Also, for each blog to have a purpose they each Concern a
particular TopicOfInterest. This is the basic scope of my blog model diagram for one particular
blog.
Page 6 of 7
INFO-340: Database Management and Information Retrieval, Spring, 2004, Assignment #3
Note
Entities – Are in Italics are come right off of the model diagrams.
Relationships – Are in Bold and come right off of the model diagrams.
In the model for Part IV I have made every aspect of the model and description an entity. This is
because I chose to not use attributes for this parts of the assignment that did not have them
included in the description (Parts II thru IV). So, this is why the model appears to have many
more entities than might be absolutely necessary to convey the problem properly. I felt that I
should stay consistent with the use of entities and after a question was asked in class it was stated
that attributes were not required for this assignment, hence the exclusive use of entities on Parts
II to IV.
Page 7 of 7
Download