1
WGU C175 STUDY GUIDE WITH
SUMMARIES
, 2
Data modeling webinar notes 16min
Entities vs. Entity instances
distinction is one is a template and one represents real world thing
Cardinality: modality (minimum)
One to one:
Here Apppointment is linked to one and only one (least common type of relationship)
physician, that is the business rule depicted.
“One appointment record has a minimum of one and a maximum of one appointment
details. One appointment details record is linked to one and only one appointment.”
One to many:
One pet owner owns many pets (at least 1). One pet is owned by one and only one pet
owner (min = 1, max = 1)
Many to many (common)
This must be converted to be implemented in db (w/ intersection table)
“Many students enroll in many courses. Many courses are attended by many
students.”
, 3
Or “One student is enrolled in one to many courses, and one course is attended by one
to many students.”
Cannot be stored in two tables, if so there is redundancy, primary key is not unique.
Solved w/ another table, the course registration table. There is acceptable redundancy,
not as much as before. Note the composite primary key composed of 2 primary keys
from student and course tables.
“One student completes one to many registrations. One registration record is linked to
one and only one student.”
And also:
“One registration record is linked to one and only one course. One course is included in
zero to many registrations.”
Note zero modality for a course no one signs up for.
A new database design scenario to practice reading relationships:
Originally there were tables, many to many for order and product, that was broken into
2 one to many relationships, new table is order line.
“One customer places one to many orders.
One order is linked to min 1 and max 1 customer.
One order includes one to many order lines
One order line record is linked to one and only one order.
, 4
One product is included in min zero (no one ordered it) to max many order lines.
One orderline includes one and only one product.”
This is to practice to read. You can see a many to many relationship was broken.
This is the patient registration system.
Description of real world entities:
This is the patient entity holding information about patients, and then of course we have an
appointment entity. This is appointment details: when a person comes to an appointment, we
gather their blood pressure, temperature, heart rate, et cetera, and the physician might put in
some notes that he or she gathered from the appointment. So, in this scenario, an
appointment will have only one appointment detail linked to it. And then we have a
relationship here between physician and appointment. And then, this is a situation where
originally we had a many to many relationship. Many patients are assigned to many
physicians and many physicians can see many patients.
So in this scenario, a patient can be seeing more than one physician.
And so, this many to many relationship was broken into two one to many relationships.
Read the relationship symbols:
“So we first have the patient to appointment relationship. One patient schedules zero to many
appointments. One patient is linked to a minimum of one and a maximum of one patient. This
relationship, one appointment includes one and only one appointment detail,
and one appointment details is linked to one and only one appointment. One physician
attends one to many appointments, and one appointment is attended by one and only
physician. Here's that many to many relationship that was broken into two one to many
relationships.
We'll read through those relationships.
So here we have one physician assignment has one and only one physician, or one record in
the physician assignment table has one and only one physician.
One physician is linked to one to many physician assignments. And then here, one patient has
zero (not yet assigned to a physician) to many physician assignments, and one physician
assignment is linked to one and only one patient.”
Unary relationship: It’s a one to one relationship. Implementation at db level looks like this:
WGU C175 STUDY GUIDE WITH
SUMMARIES
, 2
Data modeling webinar notes 16min
Entities vs. Entity instances
distinction is one is a template and one represents real world thing
Cardinality: modality (minimum)
One to one:
Here Apppointment is linked to one and only one (least common type of relationship)
physician, that is the business rule depicted.
“One appointment record has a minimum of one and a maximum of one appointment
details. One appointment details record is linked to one and only one appointment.”
One to many:
One pet owner owns many pets (at least 1). One pet is owned by one and only one pet
owner (min = 1, max = 1)
Many to many (common)
This must be converted to be implemented in db (w/ intersection table)
“Many students enroll in many courses. Many courses are attended by many
students.”
, 3
Or “One student is enrolled in one to many courses, and one course is attended by one
to many students.”
Cannot be stored in two tables, if so there is redundancy, primary key is not unique.
Solved w/ another table, the course registration table. There is acceptable redundancy,
not as much as before. Note the composite primary key composed of 2 primary keys
from student and course tables.
“One student completes one to many registrations. One registration record is linked to
one and only one student.”
And also:
“One registration record is linked to one and only one course. One course is included in
zero to many registrations.”
Note zero modality for a course no one signs up for.
A new database design scenario to practice reading relationships:
Originally there were tables, many to many for order and product, that was broken into
2 one to many relationships, new table is order line.
“One customer places one to many orders.
One order is linked to min 1 and max 1 customer.
One order includes one to many order lines
One order line record is linked to one and only one order.
, 4
One product is included in min zero (no one ordered it) to max many order lines.
One orderline includes one and only one product.”
This is to practice to read. You can see a many to many relationship was broken.
This is the patient registration system.
Description of real world entities:
This is the patient entity holding information about patients, and then of course we have an
appointment entity. This is appointment details: when a person comes to an appointment, we
gather their blood pressure, temperature, heart rate, et cetera, and the physician might put in
some notes that he or she gathered from the appointment. So, in this scenario, an
appointment will have only one appointment detail linked to it. And then we have a
relationship here between physician and appointment. And then, this is a situation where
originally we had a many to many relationship. Many patients are assigned to many
physicians and many physicians can see many patients.
So in this scenario, a patient can be seeing more than one physician.
And so, this many to many relationship was broken into two one to many relationships.
Read the relationship symbols:
“So we first have the patient to appointment relationship. One patient schedules zero to many
appointments. One patient is linked to a minimum of one and a maximum of one patient. This
relationship, one appointment includes one and only one appointment detail,
and one appointment details is linked to one and only one appointment. One physician
attends one to many appointments, and one appointment is attended by one and only
physician. Here's that many to many relationship that was broken into two one to many
relationships.
We'll read through those relationships.
So here we have one physician assignment has one and only one physician, or one record in
the physician assignment table has one and only one physician.
One physician is linked to one to many physician assignments. And then here, one patient has
zero (not yet assigned to a physician) to many physician assignments, and one physician
assignment is linked to one and only one patient.”
Unary relationship: It’s a one to one relationship. Implementation at db level looks like this:
