On Apr 13, 10:29 am, "noagbodjivic... (AT) gmail (DOT) com"
<noagbodjivic... (AT) gmail (DOT) com> wrote:
I think you have enough responses from the good peeps here at cdt to
see that *as it stands* you cannot determine keys due to a lack of
information. However you could write about what the keys would be,
given certain assumptions. For example, it seems to be an entirely
reasonable assumption that 2 patients will not share the same physical
bed. However, we don't know from the info you have how a bed is
uniquely identified, and this is crucial. For instance, even if we
assume a patient only has one bed,

* does each bed in the hospital have a unique number?
* or does bed numbering restart in each Ward?

If the first of these is the case, then no two possible facts that
would go in your table could have the same bed_number (because we
can't have two people in one bed), and hence {Bed_number} would be a
candidate key for that table. If the second was the case however, no
two facts in the table could share the same Ward number and bed number
combination, so {Bed_number, Ward_number} would be the key.

Remember that a candidate key is just an attribute (or set of
attributes) where for any particular attribute-value, only a single
row in the table ever has that attribute-value. It can also therefore
be used to uniquely identify that row as a whole.

Good luck.