Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 42 views

    Logical Database Design: Translating Unary and Ternary Relationships

    Uploaded by

    Arun Kumar Singh
    This document discusses translating unary and ternary relationships into logical database designs. For unary one-to-many relationships, it creates a relation for the entity with a foreign key referencing its primary key. For unary many-to-many, it creates relations for the entity and relationship, with the relationship's primary key consisting of the entity's primary keys. For ternary relationships, it creates relations for each entity and a relationship relation with a primary key of the entities' primary keys.

    Copyright:

    © All Rights Reserved
    Download as PPT, PDF, TXT or read online from Scribd

    Logical Database Design: Translating Unary and Ternary Relationships

    Uploaded by

    Arun Kumar Singh
    42 views30 pages
    This document discusses translating unary and ternary relationships into logical database designs. For unary one-to-many relationships, it creates a relation for the entity with a foreign key referencing its primary key. For unary many-to-many, it creates relations for the entity and relationship, with the relationship's primary key consisting of the entity's primary keys. For ternary relationships, it creates relations for each entity and a relationship relation with a primary key of the entities' primary keys.

    Original Description:

    database

    Original Title

    dbms

    Copyright

    © © All Rights Reserved

    Available Formats

    PPT, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses translating unary and ternary relationships into logical database designs. For unary one-to-many relationships, it creates a relation for the entity with a foreign key referencing its primary key. For unary many-to-many, it creates relations for the entity and relationship, with the relationship's primary key consisting of the entity's primary keys. For ternary relationships, it creates relations for each entity and a relationship relation with a primary key of the entities' primary keys.

    Copyright:

    © All Rights Reserved
    Download as PPT, PDF, TXT or read online from Scribd
    Download as ppt, pdf, or txt
    42 views30 pages

    Logical Database Design: Translating Unary and Ternary Relationships

    Uploaded by

    Arun Kumar Singh
    This document discusses translating unary and ternary relationships into logical database designs. For unary one-to-many relationships, it creates a relation for the entity with a foreign key referencing its primary key. For unary many-to-many, it creates relations for the entity and relationship, with the relationship's primary key consisting of the entity's primary keys. For ternary relationships, it creates relations for each entity and a relationship relation with a primary key of the entities' primary keys.

    Copyright:

    © All Rights Reserved
    Download as PPT, PDF, TXT or read online from Scribd
    Download as ppt, pdf, or txt
    of 30

    Logical Database Design

    Translating Unary and Ternary Relationships


    Translating Unary One-to-Many
    Relationships
    • Create a relation for the entity type
    • Within the same relation, include a foreign key
    attribute that references the primary key values;
    this foreign key must have the same domain as the
    primary key
    Example of Unary One-to-Many
    Relationship

    MANAGES
    EMPLOYEE

    Employee(EmployeeID, Name, JobTitle, ManagerID)


    Sample Data for Unary One-to-Many
    Relationship
    Translating Unary Many-to-Many
    Relationships
    • Create a relation for the entity type
    • Create a relation to represent the many-many
    relationship. The primary key of the relationship
    relation consists of two attributes, which both take
    their values from the primary key of the entity
    relation. Include nonkey attributes of the
    relationship.
    Example of Unary Many-to-Many
    Relationship

    COMPONENT
    ITEM

    Quantity

    ITEM(Item_No, Description, Unit_Cost)


    COMPONENT(Item_No, Component_No, Quantity)
    Sample Data for Unary Many-to-Many
    Relationship
    CourseNo

    PRE-REQUISITE
    COURSE
    CourseName

    Units

    COURSE(CourseNo, Name, Units)


    PREREQUISITE(CourseNo, PrereqNo)
    Translating Many-Many-ManyTernary
    Relationships
    • Create a relation for each of the three entity types
    • Create a relation to represent the relationship. The
    default primary key of this relation consists of the
    three primary key attributes from the participating
    entities.
    Example of Ternary Many-Many-Many
    Relationship (empprojternary.mdb)
    SKILL

    EMPLOYEE PROJECT

    ASSIGNMENT

    EMPLOYEE(EmployeeID,Name)
    SKILL(SkillCode, Description)
    PROJECT(ProjectID,Description,BillingRate)
    ASSIGNMENT(EmployeeID,SkillCode,ProjectID)
    Access Implementation of Ternary:
    (empprojternary.mdb)
    Ternary versus Binary Relationships

    A ternary relationship is not the same as three binary


    relationships. For example, if the project-
    employee-skill relationship were to be modeled as
    three binary relationships, as shown on the next
    slide, we would lose information about which skill
    a particular employee uses on a particular project.
    Three Binaries: (empprojbinary.mdb)
    ATTAINS
    ASSIGNED_TO

    PROJECT EMPLOYEE SKILL

    PROJECT_SKILLS

    EMPLOYEE(EmployeeID,Name)
    SKILL(SkillCode, Description)
    PROJECT(ProjectID,Description,BillingRate)
    ASSIGNED_TO(EmployeeID,ProjectID)
    ATTAINS(EmployeeID,SkillCode)
    PROJECT_SKILL(ProjectID,SkillCode)
    Access Implementation of Three
    Binaries: (empprojbinary.mdb)
    Sample Data for Three Binaries:
    (empprojbinary.mdb)
    Relationship Data for Three Binaries:
    (empprojbinary.mdb)
    EmployeeProjects Query: (empprojbinary.mdb)

    The EmployeeProjects
    query provides
    information about
    (1) Which projects a
    particular employee
    is working on
    (2) Which employees are
    working on a
    particular project
    We see that a particular employee can work
    on many projects (for example,
    employee1 works on project1 and
    project2) and that a particular project
    can have many employees working on
    it (for example, project1 has employee1
    and employee3 working on it).
    EmployeeSkills Query: (empprojbinary.mdb)

    The EmployeeSkills query


    provides information
    about
    (1) Which skills a
    particular employee
    has attained
    (2) Which employees
    have attained a
    particular skill

    We see that a particular employee can


    attain many skills (for example,
    employee1 knows Java, C++, and
    Visual Basic), and that a particular skill
    can be attained by many employees
    (for example, C++ is known by
    employee1 and employee2).
    Project_Skills Query: (empprojbinary.mdb)

    The Project_Skills query


    provides information
    about
    (1) Which skills are used
    on a particular project
    (2) Which projects use a
    particular skill

    We see that a particular project can require


    many skills (for example, project1
    requires Java and C++), and that a
    particular skill can be required by many
    projects (for example, C++ is required
    on Project1 and Project3).
    Information we cannot extract from the
    binary design: (empprojbinary.mdb)
    We cannot find out which particular skills a particular employee uses on
    a particular project. If we execute the following query, we may think
    we are finding the answer ……

    But ……………..
    We get output that indicates that an employee uses all of his/her skills on
    any project he/she is involved with. For example, employee3 has three
    skills (Java, Visual Basic, and Access); employee3 works on project1
    and project3; the output indicates that employee3 uses all three skills
    on both of those projects. If you were to add a fourth skill to employee3,
    that fourth skill would show up for any project employee3 is involved
    with. With the binary design, there is no way to indicate that employee3
    uses Java on project1 and uses Access and Visual Basic on project3.
    Sample Data for the Ternary Design:
    (empprojternary.mdb)
    Relationship Data for the Ternary Design:
    (empprojternary.mdb)

    In the ternary design, we capture information about which skills a particular


    employee uses on a particular project. For example, in the relationship
    relation, Assignment_Ternary, we can enter the information that
    employee3 uses Java on project1 and uses Access and Visual Basic on
    project3:
    We can then query the database to find out which skills a particular
    employee uses on a particular project. For example, we can find out
    which skills employee3 uses on project3:
    We can also query the database to find out in which project(s) a particular
    employee uses a particular skill:
    And we can query the database to find out which employee(s) use a
    particular skill on a particular project:
    Therefore, the ternary design provides us with the correct information about
    which skill(s) a particular employee uses on a particular project.
    We do lose some information in the ternary design since we only record
    employee skills in relation to a particular project. For example,
    employee2 is shown as having only one skill – C++ . It is possible that
    employee2 knows Visual Basic as well, but this fact has not been
    recorded because employee2 is not currently using Visual Basic on any
    project.

    You might also like