Discussion Post I
i. A strong entity does not imply or depend on any strong type or entity relationship, nor does it carry entity state information (Han et al., 2020). A stronger entity is one that can be created and destroyed without any side effects. For example, a stronger entity called foo is created and destroyed. Strong entities are a fundamental unit of Java. They do the following: Perform all operations with the same abstract class.
ii. Strong entities from the equipped chart are Loan, Customer, Bank, Account.
iii. The weak entity is the one whose existence depends on at least one other entity (Han et al., 2020). The weak entity is also called a dependent entity. Dependent entities are important because they are used for the schema's dependency (inherent relationship). The strength of the dependent entity is measured by its cardinality (Han et al., 2020). The wimpy entities from the given chart are Bank_branch, and the partial key is branch no.
iv. The constraints on a table include the columns and their relationships to each other. The database system enforces the constraints (Han et al., 2020). The DBMS determines the integrity of a table by searching the constraints on the table. The exact branch can have multiple accounts, but it should have the bank code; branch no is the partial key for bank_branches.
v. CUSTOMER > A_C (0,n)
LOAN > L_C (1,n)
CUSTOMER > L_C (0,n)
BANK > BRANCHES (1,n)
BANK_BRANCH > BRANCHES (1,1)
LOAN > LOANS (1,1)
References
i. Han, X. F., Jin, H. M., & Yan, Y. (2020). Analysis of spin-phase diagrams for R x Y 1-x Co 5 (R identical to Pr, Tb, Dy and Ho) and R x Pr 1-x Co 5 (R identical to Sm, Gd, Tb, Dy, Ho and Er).
ii. Okamoto, H. (2018). Supplemental Literature Review of Binary Phase Diagrams: Ag-Te, B-Mo, C-Nd, Cd-Te, Ce-S, Co-Er, Fe-La, Fe-V, Ho-Mo, Ho-V, Ni-Th, and Ni-U. Journal of Phase Equilibria and Diffusion, 39(6), 953-965.
Discussion Post II
i. Ideally, strong entities are called primary key entities. There are four strong BANK database entity types. These are ACCOUNT, BANK, CLIENT and LOAN. Furthermore, each of these entities has a primary key, which makes them independent (Elmasri & Navathe, 2016).
ii. Weak entity types depend on strong entity types and contain a partial key. As per the figure, we do have a weak entity type. BANK_BRANCH is the weak entity that depends on BANK. Its partial key is Branch_no, and it specifies the relationship BRANCHES with BANK by denoting that a bank can have multiple branches (Elmasri & Navathe, 2016).
iii. Partial lock Branch_no belongs to weak entity BANK_BRANCH. According to the relationship shown in the diagram, it seems that duplicate values of branch_no are not possible within the unique values of the BANK entity. Basically, different BANKs can have the same branch_no. Also, the relationship between BANK and BANK_BRANCH is BRANCH. Looking at the higher image, the BANK Code and BANK_BRANCH Branch_no attributes are one of the key combinations to define a BANK with BANK_BRANCH for a customer (Elmasri & Navathe, 2016).
iv. Several relationships are present between the entities of the BANK database. The relationship between BANK and BANK_BRANCH is BRANCH and there will be constraints for each bank with many branches (1, N). While each BANK_BRANCH can only have one BANK (1, 1). While the relationship between BANK_BRANCH and ACCOUNT entities is ACCTS. The binding relationship between BANK_BRANCH and ACCOUNT is (0, n) because each BANK_BRANCH can have zero or `N' accounts. Also, a specific account must be included in each BANK_BRANCH (1, 1). The same rule applies to the LOAN relationship between BANK_BRANCH and LOY. In addition, the A_C relationship between ACCOUNT and CLIENT has constraints on (1, n) where one account matches one customer, and the account number "N" can be correlated with the number of customers "N". In some cases, a customer may have no account or multiple bank accounts (0, n). Similarly, for the L_C relationship between LOANS and CLIENT, the value of constraints (1, n) means that 1 Loan must be present or more. However, customers cannot borrow or borrow more than once, which means (0, n) is limited (Elmasri & Navathe, 2016).
Summarizing
Relation: Participation Constraint
BANK-BANK_BRANCH: (1, n), (1, 1)
BANK_BRANCH-ACCOUNT: (0, n), (1, 1)
BANK_BRANCH-LOAN: (0, n), (1, 1)
ACCOUNT-CUSTOMER: (1, n), (0, n)
LOAN-CUSTOMER: (1, n), (0, n)
References
i. Elmasri, R., & Navathe, S. (2016). Fundamentals of Database Systems (7th ed.). Pearson.
Discussion Post III
i. List the strong (nonweak) entity types in the ER diagram.
An entity is the main building block of ER diagrams. An entity is represented in a rectangle box. A strong entity is represented in a single rectangle box (Elmasri & Navathe, 2015). From the given diagram the strong entity types are Bank, Loan, Account, Customer.
ii. Is there a weak entity type? If so, give its name, its partial key, and its identifying relationship.
A weak entity is represented by a double rectangle in an ER diagram (Elmasri & Navathe, 2015). From the given ER diagram weak entity is ‘Bank Branch'. The partial key is used to identify the attributes of a weak entity. However, only a part of the set can be identified using a partial key. From the diagram Branch no. is the partial key. The identifying relationship of Bank Branch is "Branches".
iii. What constraints do the partial key and the identifying relationship of the weak entity type specify in this diagram?
In the given ER diagram partial key Branch number specifies that all the branch no. under a specific branch is always unique (Elmasri & Navathe, 2015). Similarly, identifying the relationship of the weak entity "Branches" helps to maintain the uniqueness in "Branch no." that is related to the Bank entity. So, "Bank code" and "Branch no" help to identify Banks uniquely with the full identifier.
iv. List the names of all relationship types, and specify the (min,max) constraint on each participation of an entity type in a relationship type. Justify your choices.
Various relationship types are one to one relationship, one to many relationships, many to one relationships, many to many relationships (AfterAcademy, 2019). In the given ER diagram various relationship types are Branches, Accts, A_C, L_C, Loans.
(min,max) constraints:
Bank to Bank_Branch has one to many relationships which means a Bank can have 1 to N number of Bank_Branches. Also, Bank_Branch has total participation in relation.
A Bank_Branch can have 0 to N Accounts. Also, the Account has total participation in the relation type.
An Account and customer has many to many relationships which means the account can have several customers and several customers can have accounts. Also, the Account has total participation in relation type.
A Loan and Customer can have many to many relationships which mean loans can be given to multiple customers and multiple customers can have multiple loans. Also, Loan has total participation in the relation.
Relation between a Loan and Bank_Branch is many to one. All the loans are related to a single branch. A Bank_Branch can have multiple loans. Also, Loan has total participation in relation type.
References
i. AfterAcademy. (2019). What are the different types of relationships in DBMS? AfterAcademy.
ii. Elmasri, R., & Navathe, S. (2015). Fundamentals of Database Systems. Pearson.