‭CATS‬‭EDITION‬

‭DATABASE‬‭&‬‭SQL‬
‭TESTS‬‭EDITION‬

1‭ .‬ ‭What‬ ‭is‬ ‭the‬ ‭primary‬ ‭purpose‬ ‭of‬ ‭an‬ ‭Entity‬ ‭Relationship‬ ‭(ER)‬ ‭model‬ ‭in‬ ‭Relational‬
‭Database‬‭Management‬‭Systems‬‭(RDBMS)?‬
‭A.‬ ‭Data‬‭storage‬
‭B.‬ ‭Data‬‭manipulation‬
‭C.‬ ‭Data‬‭visualization‬
‭D.‬‭Data‬‭organization‬

‭2.‬‭Define‬‭the‬‭term‬‭"entity"‬‭in‬‭the‬‭context‬‭of‬‭an‬‭ER‬‭model:‬
‭A.‬ ‭A‬‭characteristic‬‭of‬‭an‬‭object‬
‭B.‬ ‭A‬‭distinct‬‭object‬
‭C.‬ ‭A‬‭relationship‬‭between‬‭objects‬
‭D.‬ ‭A‬‭property‬‭of‬‭an‬‭object‬

‭3.‬‭Explain‬‭the‬‭difference‬‭between‬‭an‬‭entity‬‭and‬‭an‬‭attribute‬‭in‬‭an‬‭ER‬‭model:‬
‭A.‬ ‭Entities‬ ‭represent‬ ‭objects‬ ‭while‬ ‭attributes‬ ‭represent‬
‭characteristics‬‭of‬‭those‬‭objects‬
‭B.‬ ‭Entities‬ ‭represent‬ ‭characteristics‬ ‭of‬ ‭objects‬ ‭while‬ ‭attributes‬ ‭represent‬ ‭the‬
‭objects‬‭themselves‬
‭C.‬ ‭Entities‬‭are‬‭used‬‭for‬‭categorization‬‭while‬‭attributes‬‭are‬‭used‬‭for‬‭specialization‬
‭D.‬ ‭Entities‬‭are‬‭used‬‭for‬‭specialization‬‭while‬‭attributes‬‭are‬‭used‬‭for‬‭categorization‬

‭4.‬‭What‬‭is‬‭a‬‭relationship‬‭in‬‭an‬‭ER‬‭model?‬‭Provide‬‭an‬‭example.‬
‭A.‬ ‭A‬‭connection‬‭between‬‭entities,‬‭like‬‭"Employee‬‭works‬‭for‬‭Company"‬
‭B.‬ ‭A‬‭characteristic‬‭of‬‭an‬‭entity,‬‭like‬‭"Employee‬‭ID"‬
‭C.‬ ‭A‬‭category‬‭of‬‭entities,‬‭like‬‭"Employee"‬
‭D.‬ ‭A‬‭hierarchy‬‭of‬‭entities,‬‭like‬‭"Manager‬‭is‬‭a‬‭type‬‭of‬‭Employee"‬

‭5.‬‭Describe‬‭the‬‭cardinality‬‭constraints‬‭used‬‭in‬‭an‬‭ER‬‭model‬‭and‬‭their‬‭significance:‬
‭A.‬ ‭They‬ ‭define‬ ‭the‬ ‭primary‬ ‭key‬ ‭of‬ ‭an‬ ‭entity‬ ‭and‬ ‭their‬ ‭significance‬ ‭is‬ ‭in‬‭uniquely‬
‭identifying‬‭each‬‭entity‬
‭B.‬ ‭They‬ ‭define‬ ‭the‬ ‭types‬ ‭of‬ ‭attributes‬ ‭a‬ ‭certain‬ ‭entity‬ ‭can‬ ‭have‬ ‭and‬ ‭their‬
‭significance‬‭is‬‭in‬‭categorizing‬‭entities‬
 ‭C.‬ ‭They‬ ‭define‬ ‭the‬ ‭number‬ ‭of‬ ‭entities‬ ‭involved‬ ‭in‬ ‭a‬ ‭relationship‬ ‭and‬
‭their‬‭significance‬‭is‬‭in‬‭specifying‬‭how‬‭instances‬‭of‬‭entities‬‭relate‬‭to‬
‭one‬‭another‬
‭D.‬ ‭They‬‭define‬‭the‬‭types‬‭of‬‭relationships‬‭an‬‭entity‬‭can‬‭have‬‭and‬‭their‬‭significance‬
‭is‬‭in‬‭organizing‬‭entities‬‭into‬‭groups‬

‭6.‬‭What‬‭is‬‭specialization‬‭in‬‭the‬‭context‬‭of‬‭ER‬‭modeling?‬
‭A.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭combining‬‭multiple‬‭entities‬‭into‬‭a‬‭single‬‭entity‬
‭B.‬ ‭It‬ ‭refers‬ ‭to‬ ‭the‬ ‭process‬ ‭of‬ ‭dividing‬ ‭a‬ ‭single‬ ‭entity‬ ‭into‬ ‭multiple‬
‭sub-entities‬‭based‬‭on‬‭characteristics‬
‭C.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭creating‬‭new‬‭attributes‬‭for‬‭an‬‭entity‬
‭D.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭creating‬‭relationships‬‭between‬‭entities‬

‭7.‬‭How‬‭does‬‭generalization‬‭differ‬‭from‬‭specialization‬‭in‬‭ER‬‭modeling?‬
‭A.‬ ‭Generalization‬‭is‬‭the‬‭opposite‬‭of‬‭specialization.‬
‭B.‬ ‭Generalization‬ ‭combines‬ ‭entities‬ ‭while‬ ‭specialization‬ ‭divides‬
‭entities.‬
‭C.‬ ‭Generalization‬‭creates‬‭new‬‭entities‬‭while‬‭specialization‬‭removes‬‭entities.‬
‭D.‬ ‭Generalization‬‭is‬‭the‬‭same‬‭as‬‭specialization.‬

‭8.‬‭Define‬‭the‬‭concept‬‭of‬‭categorization‬‭as‬‭applied‬‭in‬‭an‬‭ER‬‭model.‬
‭A.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭dividing‬‭entities‬‭into‬‭different‬‭types.‬
‭B.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭combining‬‭entities‬‭into‬‭a‬‭single‬‭entity.‬
‭C.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭creating‬‭relationships‬‭between‬‭entities.‬
‭D.‬ ‭It‬‭refers‬‭to‬‭the‬‭process‬‭of‬‭creating‬‭new‬‭attributes‬‭for‬‭an‬‭entity.‬

‭ .‬ ‭Explain‬ ‭the‬ ‭role‬ ‭of‬ ‭keys‬ ‭in‬ ‭establishing‬ ‭relationships‬ ‭between‬ ‭entities‬ ‭in‬ ‭an‬ ‭ER‬
9
‭model.‬
‭A.‬ ‭Keys‬‭are‬‭used‬‭to‬‭define‬‭the‬‭number‬‭of‬‭entities‬‭involved‬‭in‬‭a‬‭relationship.‬
‭B.‬ ‭Keys‬‭are‬‭used‬‭to‬‭uniquely‬‭identify‬‭each‬‭entity‬‭within‬‭an‬‭entity‬‭set.‬
‭C.‬ ‭Keys‬‭are‬‭used‬‭to‬‭categorize‬‭entities‬‭based‬‭on‬‭their‬‭attributes.‬
‭D.‬ ‭Keys‬‭are‬‭used‬‭to‬‭specify‬‭the‬‭types‬‭of‬‭relationships‬‭an‬‭entity‬‭can‬‭have.‬

‭10.‬‭Discuss‬‭the‬‭importance‬‭of‬‭normalization‬‭in‬‭the‬‭design‬‭process‬‭of‬‭an‬‭ER‬‭model.‬
‭A.‬ ‭It‬‭ensures‬‭that‬‭each‬‭attribute‬‭within‬‭an‬‭entity‬‭has‬‭a‬‭unique‬‭value.‬
‭B.‬ ‭It‬ ‭reduces‬ ‭redundancy‬ ‭and‬ ‭dependency‬ ‭by‬ ‭organizing‬ ‭data‬ ‭into‬
‭multiple‬‭related‬‭tables.‬
‭C.‬ ‭It‬‭establishes‬‭relationships‬‭between‬‭entities‬‭based‬‭on‬‭their‬‭keys.‬
‭D.‬ ‭It‬‭visualizes‬‭the‬‭data‬‭structure‬‭of‬‭an‬‭entity‬‭in‬‭a‬‭hierarchical‬‭format.‬

‭SECTION‬‭B‬‭(Attempt‬‭any‬‭3)‬

1‭ .‬‭Compare‬‭and‬‭contrast‬‭the‬‭advantages‬‭and‬‭disadvantages‬‭of‬‭using‬‭a‬‭generalization‬
‭hierarchy‬‭versus‬‭multiple‬‭specialization‬‭hierarchies‬‭in‬‭an‬‭ER‬‭model.‬

‭Advantages‬‭of‬‭a‬‭Generalization‬‭Hierarchy:‬
 ‭E.‬ S ‭ implifies‬ ‭Design:‬ ‭Combines‬ ‭similar‬ ‭entities‬ ‭into‬ ‭one‬ ‭parent,‬ ‭reducing‬
‭repetition.‬
‭F.‬ ‭Shared‬‭Features:‬‭Child‬‭entities‬‭inherit‬‭common‬‭attributes‬‭from‬‭the‬‭parent.‬
‭G.‬ ‭Flexibility:‬ ‭Focuses‬ ‭on‬ ‭shared‬ ‭features,‬ ‭making‬ ‭it‬ ‭easier‬ ‭to‬ ‭group‬ ‭similar‬
‭entities..‬

‭Disadvantages‬‭of‬‭a‬‭Generalization‬‭Hierarchy:‬

1‭ .‬ L ‭ ess‬‭Detail:‬‭Unique‬‭attributes‬‭for‬‭specific‬‭entities‬‭may‬‭be‬‭overlooked.‬
‭2.‬ ‭Complex‬‭Searches:‬‭Finding‬‭specific‬‭entities‬‭can‬‭require‬‭more‬‭filtering.‬
‭3.‬ ‭Hard‬ ‭to‬ ‭Expand:‬ ‭Managing‬ ‭more‬ ‭entities‬ ‭and‬ ‭relationships‬ ‭becomes‬ ‭tricky‬ ‭as‬
‭the‬‭model‬‭grows.‬

‭Advantages‬‭of‬‭Multiple‬‭Specialization‬‭Hierarchies:‬

1‭ .‬ M ‭ ore‬‭Detail:‬‭Clearly‬‭separates‬‭entities‬‭with‬‭unique‬‭features.‬
‭2.‬ ‭Easy‬‭to‬‭Understand‬‭:‬‭Specific‬‭entities‬‭are‬‭modeled‬‭more‬‭explicitly.‬
‭3.‬ ‭Better‬‭Searches:‬‭Queries‬‭for‬‭specific‬‭entities‬‭are‬‭simpler‬‭and‬‭more‬‭direct.‬

‭Disadvantages‬‭of‬‭Multiple‬‭Specialization‬‭Hierarchies:‬

1‭ .‬ R ‭ epetition:‬‭Common‬‭attributes‬‭may‬‭be‬‭duplicated‬‭across‬‭entities.‬
‭2.‬ ‭Complicated‬‭Design:‬‭Requires‬‭careful‬‭planning‬‭to‬‭avoid‬‭overlaps.‬
‭3.‬ ‭Hard‬‭to‬‭Maintain:‬‭Changes‬‭need‬‭to‬‭be‬‭updated‬‭in‬‭multiple‬‭places.‬

‭ se‬ ‭generalization‬ ‭for‬ ‭simplicity‬ ‭and‬ ‭shared‬ ‭features.‬ ‭Use‬ ‭specialization‬ ‭when‬ ‭you‬
U
‭need‬‭more‬‭details‬‭and‬‭clarity‬‭about‬‭each‬‭entity.‬

‭ .‬‭Sozzo‬‭Property‬‭Consultants‬‭maintain‬‭a‬‭table‬‭of‬‭Properties‬‭below,‬‭that‬‭are‬‭available‬
2
‭for‬ ‭the‬ ‭public‬ ‭to‬ ‭consume.‬ ‭Using‬ ‭specialization,‬ ‭design‬ ‭an‬ ‭ER‬ ‭model,‬ ‭including‬ ‭the‬
‭attributes,‬‭to‬‭achieve‬‭better‬‭data‬‭organization.‬
‭ .‬ ‭Using‬ ‭an‬ ‭example‬ ‭scenario,‬ ‭illustrate‬ ‭how‬ ‭you‬ ‭would‬ ‭represent‬ ‭a‬ ‭many-in-many‬
3
‭relationship‬ ‭between‬ ‭entities‬ ‭in‬ ‭the‬ ‭ER‬ ‭model,‬‭including‬‭the‬‭necessary‬‭attribute‬‭and‬
‭cardinality‬‭constraints.‬

‭Entities:‬

‭●‬ ‭Student‬‭:‬‭to‬‭represent‬‭students‬‭in‬‭the‬‭system‬

‭Attributes:‬‭(‬‭
studentID‬ studentName‬
‭,‬‭ ‭)‬

‭●‬ ‭Course:‬‭to‬‭represent‬‭courses‬‭in‬‭the‬‭system‬

‭Attributes:‬ ‭(‬‭
sourseID‬ courseName‬
‭,‬‭ ‭)‬

‭●‬ ‭Enrollment‬‭:‬‭introduction‬‭of‬‭an‬‭associative‬‭entity/junction‬

‭Attributes:‬‭(‬‭
studentID,courseID,date‬
‭)‬

‭Relationship:‬

‭ nrolls‬‭:‬‭A‬‭Student‬‭enrolls‬‭in‬‭one‬‭or‬‭more‬‭Courses,‬‭and‬‭each‬‭Course‬‭is‬‭taken‬‭by‬‭one‬‭or‬
E
‭more‬‭Students.‬‭i.e‬‭Student‬‭↔Enrolls‬‭↔‬‭Course‬

‭Cardinality‬‭vs‬‭Constraints‬‭vs‬‭Participation:‬

‭●‬ ‭Student‬‭↔‬‭Enrollment‬
 ‭Minimum:‬‭0‬‭(Optional,‬‭a‬‭student‬‭may‬‭not‬‭enroll‬‭in‬‭any‬‭course).‬

‭Maximum:‬‭*‬‭(A‬‭student‬‭can‬‭enroll‬‭in‬‭multiple‬‭courses)‬‭i.e‬‭(1:M)‬‭/‬‭(0..*)‬

‭●‬ ‭Course‬‭↔‬‭Enrollment‬

‭Minimum:‬‭1‬‭(Mandatory,‬‭a‬‭course‬‭must‬‭have‬‭at‬‭least‬‭one‬‭student‬‭enrolled)‬

‭Maximum:‬‭*‬‭(A‬‭course‬‭can‬‭have‬‭many‬‭students‬‭enrolled)‬‭i.e‬‭(M:1)‬‭/‬‭(1..*)‬

‭ .‬ ‭Discuss‬ ‭the‬ ‭role‬ ‭of‬ ‭the‬ ‭weak‬ ‭entities‬ ‭in‬ ‭an‬ ‭ER‬ ‭model‬ ‭and‬ ‭provide‬ ‭examples‬ ‭of‬
4
‭scenarios‬‭where‬‭their‬‭use‬‭is‬‭appropriate.‬

‭ ‬ ‭weak‬ ‭entity‬ ‭is‬ ‭an‬ ‭entity‬ ‭that:‬ ‭Cannot‬‭be‬‭uniquely‬‭identified‬‭by‬‭its‬‭own‬‭attributes‬

A
‭alone,‬ ‭relies‬ ‭on‬ ‭an‬ ‭owner‬ ‭entity‬ ‭and‬ ‭a‬ ‭relationship‬ ‭with‬ ‭it‬‭to‬‭have‬‭a‬‭unique‬‭identity‬
‭and‬‭must‬‭have‬‭a‬‭primary‬‭key‬‭that‬‭includes‬‭a‬‭foreign‬‭key‬‭referencing‬‭its‬‭owner‬‭entity.‬

‭Role‬‭of‬‭Weak‬‭Entities:‬

‭1.‬ S ‭ upports‬ ‭Referential‬ ‭Integrity:‬ ‭Ensures‬ ‭that‬ ‭every‬ ‭enrollment‬ ‭record‬‭is‬‭linked‬

‭to‬‭an‬‭existing‬‭student‬‭and‬‭course.‬
‭2.‬ ‭Simplify‬ ‭Relationships:‬ ‭Avoids‬ ‭unnecessary‬ ‭complexity‬ ‭by‬ ‭logically‬
‭representing‬‭entities‬‭that‬‭are‬‭inherently‬‭dependent.‬
‭3.‬ ‭Hierarchical‬ ‭Structures:‬ ‭Captures‬ ‭parent-child‬ ‭or‬ ‭subordinate‬‭relationships‬‭in‬
‭data‬‭structures.‬
‭4.‬ ‭Holds‬ ‭Dependent‬ ‭Data:‬ ‭i.e‬ ‭Enrollment‬ ‭records‬ ‭rely‬ ‭on‬ ‭both‬ ‭ Student‬‭and‬
Course‬‭for‬‭meaning.‬
‭
‭5.‬ ‭Connects‬ ‭Strong‬ ‭Entities:‬ ‭Represents‬‭the‬‭many-to-many‬‭relationship‬‭between‬
‭students‬‭and‬‭courses.‬

‭Scenario:‬

‭●‬ ‭Student‬‭:‬‭this‬‭is‬‭a‬‭strong‬‭entity‬‭and‬‭can‬‭exist‬‭independently‬

studentID‬‭(unique‬‭identifier),‬‭
‭Attributes:‬‭ studentName‬
 ‭●‬ ‭Course:‬‭this‬‭is‬‭a‬‭strong‬‭entity‬‭and‬‭can‬‭exist‬‭independently‬

‭Attributes:‬ ‭
sourseID‬‭(unique‬‭identifier),‬‭
courseName‬

‭●‬ ‭Enrollment‬‭:‬ ‭this‬‭is‬‭a‬‭weak‬‭entity‬‭and‬‭dependant‬

StudentID‬‭and‬‭
‭PK/FK:‬‭A‬‭combination‬‭of‬‭ CourseID‬

‭ .‬‭Explain‬‭how‬‭you‬‭would‬‭handle‬‭complex‬‭relationships,‬‭such‬‭as‬‭ternary‬‭relationships,‬
5
‭in‬‭an‬‭ER‬‭model‬‭providing‬‭a‬‭detailed‬‭example‬‭and‬‭discussing‬‭any‬‭potential‬‭challenges.‬
 ‭ reated‬‭for:‬‭SEC9‬
C
M
🏹‬‭is‬‭not‬‭liable‬‭to‬‭any‬‭damages.‬
‭ ade‬‭for‬‭Personal‬‭revision‬
‭Therefore‬‫‮سهم‬‮ساخن‬‭‬