Sort by

recency

|

17 Discussions

|

  • + 0 comments

    A relation is in 2NF if it is in 1NF and every non-prime attribute is fully functionally dependent on the whole of every candidate key. What are the best tips for finding an affordable crypto press release distribution? I want to know how to find effective but Cheapest Crypto Press Release Service. Here, we assume that the composite key for the borrow relation is {memberno, serialno}, and the other relations like movie, serial, and customer have their own keys:

    movie(serialno) where serialno is a key. serial(serialno) where serialno is a key. customer(memberno) where memberno is a key. Now, all non-prime attributes (such as description, director, and name, addr) depend entirely on the full candidate key (not just part of it). For example, description is functionally dependent on serialno, and memberno depends on name, addr. Since there are no partial dependencies (where a non-prime attribute would depend on only part of a composite key), the relation is in 2NF.

  • + 0 comments

    this structured representation is a great starting point for building an efficient movie library database. 11xplay pro new id

  • + 0 comments
    movie(DESCRIPTION,serialno)
    description->director,serialno
    serialno->description
    
    serial(SERIALNO,director)
    serialno->director
    
    customer(name,addr,MEMBERNO)
    name,addr -> memberno
    memberno -> name,addr
    
    borrow(memberno,DATE,SERIALNO)
    serialno,date -> memberno
    

    1NF valid 2NF valid 3NF valid BCNF <=> A->B were A not CANDIDATE KEY, even though name,addr -> memberno in customer looks invalid by the complementary axiom we have that name, addr is actually a key of customer!

  • + 0 comments

    Extending my process of identifying the normal forms here: https://www.hackerrank.com/challenges/database-normalization-6/forum/comments/1225774

    For 3NF, non-prime attributes must be directly dependent on CK, not transitively dependent:

    serial.director: depends on serialno (is CK)
    borrow.memberno: depends on serialno,date (is CK)
    

    It is in 3NF.

    For BCNF, every determinant must be a CK:

    description -> director,serialno (description is CK)
    serialno -> description (serialno is CK)
    serialno -> director (serialno is CK)
    memberno -> name,addr (memberno is CK)
    serialno,date -> memberno (serialno,date is CK)
    name,addr -> memberno (name,addr is CK)
    
  • + 0 comments

    3.5 ans