CSE-3421
Introduction to Database Systems

York University
Winter 2009
Project #1: Scheming a Schema
A Prescription DB
 
  Assignment

Develop an entity-relationship model (ERM) for the attached case. Clearly identify the entity sets, relationship sets, multiplicity (i.e., 1-many, many-many etc.), attributes, primary keys, and constraints in your model, using the notations and diagramming rules described in the textbook.

Keep in mind that the case is designed to simulate a real life systems analysis situation; hence the conversations are unstructured and sometimes fuzzy. It is your responsibility, as an analyst/designer, to translate what you heard/read into an ERM.

You are the database designer of an information system for tracking medical prescriptions. Base your design on the requirements as expressed below.

 
  Requirements Meeting

During the requirements gathering meeting, OHIP's chief operation officer explains what they want.

We are automating tracking of prescriptions (medicines prescribed) for OHIP holders. We want to develop a database for this that tracks patients (any OHIP holder who has been prescribed medicine), physicians (physicians who prescribe medicine under OHIP), conditions (medical conditions patients have for which medicines are prescribed), prescriptions (the actual precriptions that physicians write for patients), medicines (that are prescribed), and pharmacies (where the patients get their precriptions filled).

Each patient will have a unique OHIP number. We want to know the patient's name, birthdate, address, and the expiry date on his or her OHIP card.

Each OHIP-certified physician (the only physicians we care about here) has a unique physician number assigned to him or her. We want to know the physician's name, address (of his or her main office), and medical specialty.

A physician sees a patient if the patient has ever had an appointment with that physician. We want to track which physicians see which patients. A physician may diagnose a patient to have a condition. A physician may only write a prescription for a patient whom he or she sees, and which treats a condition that the patient has been diagnosed to have. (Note that the physician who writes the prescription does not need to be the same physician who diagnosed the condition.)

We should track the conditions that a given medicine treats. Note that certain medicines may be used to treat different conditions, and that a given condition may be treated by different medicines.

The situtation with medicines is a bit more complicated. A physician prescribes a brand, not a medicine itself. A given medicine may be made by one or more pharmaceutical companies. We call a medicine as made by a given pharmaceutical company a brand.

Thus, we need to track both brands and medicines in the database, and the pharmaceutical companies that make the brands. For each medicine, we want to know its name (which is unique, in this case). For each pharmaceutical company, we want to know its name (unique) and the address of its headquarters. For each brand, we want to know its name, the pharmaceutical company that makes it, what medicine it is, the dosage amount (how much of the medicine is in each pill or designated amount), and its price (per dosage). The brand's name, the name of the company that makes it, and the dosage together suffice to identify a given "brand" as designated in a prescription.

For each precription, we want to know, of course, the patient it is for, the doctor who prescribed it, the brand it is for (which tells us the medicine and dosage), the quantity prescribed (number of dosages), and the date the prescription was written. We also want to know the pharmacy at which the prescription was filled and when (the date), if it was filled.

We want to track OHIP-certified pharmacies (the only pharmacies we care about here). Each such pharmacy has a unique pharmacy number assigned to it. In addition, we want to track the pharmacy's name and address.

We very much would like the database design to enforce the following for us, if it is possible. We want that any prescription must be for medicine that treats a condition that the patient has been diagnosed to have. In other words, we do not want to honour prescriptions for medicines that do not match any of a patient's conditions.

 
  Considerations
  1. In real life, many more data elements than described above would be needed to build a useful prescriptions database for OHIP. We do not, however, want to turn this project into something huge. So keep in mind that this is a highly simplified case.
  2. As a general approach, if a particular constraint is not explicitly given, then assume the least restricted situation. For example, "many" in ERM is less restricted than "at most one".
  3. You are not required to specify the domains of the attributes in this part of the project.
  4. Make sure that you clearly indicate the constraints. For example, if there is/are ISA situation(s), indicate the overlapping and coverage constraints next to the ISA symbol(s).
 
  Deliverables

Due: by 10:30pm Tuesday 31 March.

Hand in a hardcopy of your project. This should include:

  • ERM
    Your full E-R model for the prescriptions database.
  • Documentation
    Paragraphs explaining details about the design.
    • Any clarifications about your ERM that are not evident in the model itself.
    • Any assumptions you had to make with respect to the requirements. (In the real world, these would then be resolved in a second requirements meeting.)
    • Any constraints (business rules) apparent from the requirements that you are unable to model via your ERM.
    The documentation may be minimal, or even absent, if your model has no such needed clarifications.

Hand-written is fine, but use pen, not pencil. Do not use binders, folders, paper clips etc. Use standard size paper (8.5" x 11"), and have the sheets stapled together.

Have a cover page for submitting your work, filling out your student number, etc., as follows:

Student Number
Sur (Family) Name  
Given Name  

Please drop off your assignment in the CSE-3421 drop-off box in the Computer Science & Engineering Building (attached to CSB #1003). Do not hand it into your instructor in class.

If you submit this assignment after the due date/time, but before Wednesday 1 April 5:30pm, there will be a 20% deduction of your score for penalty. This assignment will not be accepted after that time.