2 votes 2 votes i think answer is 4. given ans. is 3 pls confirm. mohit chawla asked Feb 4, 2017 mohit chawla 1.5k views answer comment Share Follow See all 32 Comments See all 32 32 Comments reply dd commented Feb 4, 2017 reply Follow Share possible merging $E_1 R E_4$ Or $E_1 R E_2$ Or, $E_1 R E_3$ And remaining two are separate. 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share answer will be 5..all E1,E2,E3,E4 will have separate tables...one will be for R having primary keys of E1,E2,E3,E4... 2 votes 2 votes Pavan Kumar Munnam commented Feb 4, 2017 reply Follow Share https://gateoverflow.in/113663/madeeasy#a113869 1 votes 1 votes dd commented Feb 4, 2017 i edited by dd Feb 4, 2017 reply Follow Share @sudsho can we do this ? $\begin{align*} &E_1RE_2\left ( {\color{red}{\bf C}}{\color{blue}{\bf A}}BD{\color{Magenta} E}{\color{Magenta} G} \right ) \qquad {\color{Magenta}{E} } \text{ references to }E_4 \\ &\qquad\qquad\qquad\qquad\qquad \;\;\;\; {\color{Magenta}{G}} \text{ references to }E_3 \\ &\qquad\qquad\qquad\qquad\qquad \;\;\;\; {\color{Magenta}{C} } \text{ is primary key (NO NULL)} \\ &\qquad\qquad\qquad\qquad\qquad \;\;\;\; {\color{Magenta}{A} } \text{ is an alternative key (NULL allowed) } \\ \\\hline \\ &E_3\left ( {\color{Red}{ \bf G}}H \right ) \qquad \text{G is primary key}\\ \\\hline \\ &E_4\left ( {\color{Red}{ \bf E}}F \right ) \;\qquad \text{E is primary key}\\ \end{align*}$ 0 votes 0 votes mohit chawla commented Feb 4, 2017 reply Follow Share @debashish , i am not good in this concept. yeah there is one to one relationship b/w E1-E4 , E1-E2, E1-E3 but you can merge the relationship ! not the entity table itslef. suppose u have a relationship(one to one) where boys and girls are 2 entity set and relationship is married. now u can merge relationship to either of the entity and make them as a table but how can u merge 2 entitites. merging is only benificial if it we take same time to the case where we won't merge so that u do not have wastage of space problem. but here if you merge that won't be good in practical sense. correct me if i am wrong! 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share debashish we only merge in case of 1:1 with total participation on both sides...so we cant merge any entity here...and in case of n ary relationships we need 1 more table for relation also having primary keys of all the entities put together the primary key of that table...hence 5 tables are required here... 0 votes 0 votes mohit chawla commented Feb 4, 2017 reply Follow Share no sudsho, again let me give you same example , u can merge the relationship with any of the 2 entity even if they are not in fully participation. same example of boys, girls and married. now for boys table u have all the boys even though some boys are not taking part in relationship. and same for girls side. and one boy can only marry to one girl this is a constraint. now the relationship married to catches all the instances where one boy is married to one girl here no. of boys participating in this relationship is always a subset of boys entity and same case for girls. so we can merge the relationship and the boys which are not participating can be filled with null values. correct me if i am wrong.. 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share ^ if u think like this then we can even merge m:n there also there wont be any problem..just manage the primary keys.. main thing is such database models are not practically feasible..there will be lot of redundancies... "and the boys which are not participating can be filled with null values" so merge only if there is total participation on both sides and that too only in case of 1:1 to avoid spurious tuples....m sure about this u can trust me on this... here by merging i mean to merge 2 entities... 0 votes 0 votes mohit chawla commented Feb 4, 2017 reply Follow Share @sudsho, i trust you bhai, no doubt about that. as i am weak in this concept bear with me pls. my point was that u don't have to create extra tuples in table of entity while when you consider a m:n relationship then u really do not know how may instances of one entity have taken part in that relation so whenevr you try to merge, there can be a case where u have to introduce new tuples to table due to merging of these. that is the reason why m:n can not be merge, atleast maine ese smgha hai. u can take i:n relationship n uspe bhi ye concpt shi baithta hai. i do not think it is proper reasoning but it is somewhat convincing. n bhai if you find any improper thing in my reasoning then et me know where so that i can corect it. and pls refer some good source to solve it. 0 votes 0 votes dd commented Feb 4, 2017 reply Follow Share ......... 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share because of these unneccessary NULLs only we dont do this deabshis....this is only when u have taken few tuples...suppose u take 1k tuples...imagine the no of NULL values that will be there... thats why its nt a practical feasible model... @pikachu is this is what ur doubt was? or anything else? 2 votes 2 votes dd commented Feb 4, 2017 reply Follow Share thats why its nt a practical feasible model OK , will it be ok to say that, this merging is not possible at all or can not be done while the QS is asking minimum possible tables ? 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share this merging is possible but if asked in question about minimum or anything dont do this as this is not a practical dbms relational schema... 1 votes 1 votes dd commented Feb 4, 2017 reply Follow Share I understood what you have said. But for exam purpose ? 0 votes 0 votes dd commented Feb 4, 2017 reply Follow Share OK .... 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share i have told this for exam purpose only :) no merging for partial participation 1 votes 1 votes mohit chawla commented Feb 4, 2017 reply Follow Share what debashish did was exactly my point which i have written that due to many NULL values m:n is not possible in my prev. comment but when relationship is one to one then the probelm comes where that subset property exist, i.e you do not need to insert seperate tuples due to merging while you have to in case of M:N reltionship.so NULL value here won't cause any probelm in my opinion. i might be wrong on this. but suppose you go and run one query which is to extract all boys and their repective counter part. you can do this by processing every tuple of entity boy. i hope you get my point. here NULL values are not creating unness. redundancy as nothing is repeating in my opinion and if they are, can @sudsho you provide me an example where you find redundancy due to this. PS i might be wrong on this. kindly correct me if you find me wrong. 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share so NULL value here won't cause any probelm in my opinion. why so? isnt u unneccesary making ur database large? where u have seen this that we can merge 1:1 with partial participation except made easy notes? 1 votes 1 votes mohit chawla commented Feb 4, 2017 reply Follow Share haha...made easy notes!! cool !! ok bhai! we won't get much out of this discussion. can u refer me some good resorces where i can get some confidence to solve such kind of problems OR pls post a comment or answer to this ques. stating general rules for converting ER to Relational. i shall be thankful bhai :) 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share i said made easy because every made easy student says the same..they have taught to merge :P i am conidering 2 entities and a relationship between them 1. for 1:1 with partial participation or total participation on only one side .... 2 tables 2.for 1:1 with total participation on both sides.....only 1 table 3.for 1:n or n:1 we need ...2 tables(put key in N side) 4.for m:n whether partial or total participation we need ....3 tables(2 for entities 1 for relationship) 5.for n ary relationships...first apply above methods and then u also need one table for the relationship having primary keys of all entities.. 6.for multivalued attributes one more table.. just keep these points in mind u can solve any question related to this :) 3 votes 3 votes bad_engineer commented Feb 4, 2017 reply Follow Share for second point are you sure we can merge them any reference??? 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share in second case, the minimum number of tables is 1 only if they are not participating in any other relationships other than this relationship.... Otherwise we require 2 tables to represent these 2 entities. 1 votes 1 votes bad_engineer commented Feb 4, 2017 reply Follow Share yup that true... 0 votes 0 votes Rahul Jain25 commented Feb 4, 2017 reply Follow Share @sudsho what about total participation on both sides in m:n relationship?? 0 votes 0 votes sudsho commented Feb 4, 2017 reply Follow Share ^ cant merge...separate tables...point 4 :) 0 votes 0 votes Rahul Jain25 commented Feb 4, 2017 reply Follow Share I thought it might be different when participation on both side. Thanks☺ 1 votes 1 votes Smriti012 commented Feb 4, 2017 reply Follow Share What to do if we have "IS A" relationship triangles between er- diagram??? 0 votes 0 votes Smriti012 commented Feb 4, 2017 reply Follow Share see this: 0 votes 0 votes sushmita commented Apr 15, 2017 reply Follow Share @ Debashish, Sudsho, so whats the final answer 3 or 5?? which one to follow? 0 votes 0 votes sushmita commented Apr 15, 2017 reply Follow Share then how we can represent the relationship of E2 and E3 in R?? 0 votes 0 votes Bikram commented Apr 19, 2017 reply Follow Share @Mohit @sushmita You can merge E4 with any one of the other tables, and keep others two you have to include the keys of E4 in that table thats it..as a total participation answer is 3 see this https://gateoverflow.in/113663/madeeasy#a113869 same question 0 votes 0 votes sushmita commented Apr 19, 2017 i edited by sushmita Apr 19, 2017 reply Follow Share @Bikram sir, instead of one-one if it had been 1:n relationships, then we will make a separate table for the relation R, even in case of total participation??? 0 votes 0 votes Please log in or register to add a comment.