Draw a conceptual model

Mr$.$ Hook owns a dental clinic that provides several different specialties. A dentist in Mr$.$ Hook's clinic is a person who has license number with the Arizona State Board of Dental Examiners. About dentists, Mr$.$ Hook needs to know, in addition to the license, their name $($first and last names$),$ phone number, date of birth, and a list of specialties.

Patients at Mr$.$ Hook's clinic should be able to schedule appointments. An appointment has a date and a time of the day. In addition, it is necessary to know which dentist will see that patient at that time. Different dentists can have appointments at the same date and time, as long as they have different patients.

Patients must be registered at the clinic to be treated. This registration is made on the date of the first appointment and it is available throughout the patient's life at the clinic. Mr$.$ Hook needs to know a patient's full name $($first$,$ middle, last names$),$ full address $($street$,$ apartment$/$unit$,$ city, state, zipcode$),$ phone number, date of birth, and gender identification. Patients have a unique patient ID$.$

As the dentists at Mr$.$ Hook's clinic have different specialties, a patient can schedule appointments with several dentists. For each appointment, in addition to the dentist in charge, it is necessary to know which procedures were performed. A procedure has a registration code, a price $($determined by the Arizona State Board of Dental Examiners$)$ and a brief description.

Your diagram must contain:

Entities, Relationships, attributes, cardinalities, and participation indication.

Entities must be represented as a Weak Entity if needed.

Relationships must be represented as Identifying or ISA if needed.

Attributes must be represented as primary key, derived, multi$-$valued, or composed if needed.

Cardinalities must be represented with $1,$ N$,$ or M only.

Participation in relationships must be represented as total $($double line$)$ or partial $($singl

$1.$ Entity types become rectangles.

$2.$ Attributes of entity types become ovals connected to the associated entity type.

a$.$ Primary keys have the attribute names underscored.

b$.$ Primary keys that require more than one attribute to uniquely identify the entity have all the

PK attribute names underscored with dotted lines.

c$.$ Simple, stored, single$-$valued attributes are single$-$lined ovals.

d$.$ Derived attributes are dotted$-$lined ovals.

e$.$ Multivalued attributes are double$-$lined ovals.

f$.$ These rules also apply to the attributes in a Relationship type, instead of an Entity type.

$3.$ Entity types that don$$t have one or more attributes that could work as a unique identifier $($PK$)$ must

be marked as Weak Entities by using double lined rectangle.

$4.$ When a primary key $($or part of the primary key$)$ of one Entity Set is an attribute in another Entity Set

associated with it$,$ the relationship is known as an identifying relationship, and it should be marked as

such by using a double$-$lined diamond.

ER Diagrams

$5.$ Relationship types become diamonds connected to the associated entity types with a single line.

$6.$ Relationship type$$s attributes are connected to the diamond and follow the same rules as the entity

type attributes.

$7.$ ISA relationships become a triangle pointing up to the parent entity type and the name is usually ISA.

$8.$ Cardinalities must be indicated with a label on the connecting line. The label must be a $1$ or an N$,$

depending on whether the side of the relationship is a $1$ or N$.$ To identify if you should add a $1$ or an N$,$

read the relationship in both directions, always starting with one entity. The side with a $$many$$ should

be N$,$ otherwise, it is $1.$