Đang chuẩn bị liên kết để tải về tài liệu:
Database Modeling & Design Fourth Edition- P9

Database Modeling & Design Fourth Edition- P9: Database technology has evolved rapidly in the three decades since the rise and eventual dominance of relational database systems. While many specialized database systems (object-oriented, spatial, multimedia, etc.) have found substantial user communities in the science and engineering fields, relational systems remain the dominant database technology for business enterprises. | 2.2 Advanced ER Constructs 27 Project are considered many the entity Manager is considered one. This is represented by the following assertions. Assertion 1 One engineer working under one manager could be working on many projects. Assertion 2 One project under the direction of one manager could have many engineers. Assertion 3 One engineer working on one project must have only a single manager Each engineer working on a particular Functional dependency project has exactly one manager but each manager of a project may manage project-name emp-id mgr-id many engineers and each manager of an engineer may manage that engineer on many projects. c One-to-many-to-many ternary relationship Employees can use many skills on any one of many projects and each project has many employees with various skills. Functional dependencies None d Many-to-many-to-many ternary relationship Figure 2.6 continued 28 CHAPTER 2 The Entity-Relationship Model Assertion 3 could also be written in another form using an arrow - in a kind of shorthand called a functional dependency. For example emp-id project-name - mgr-id where emp-id is the key unique identifier associated with the entity Engineer project-name is the key associated with the entity Project and mgr-id is the key of the entity Manager. In general for an n-ary relationship each entity considered to be a one has its key appearing on the right side of exactly one functional dependency FD . No entity considered many ever has its key appear on the right side of an FD. All four forms of ternary relationships are illustrated in Figure 2.6. In each case the number of one entities implies the number of FDs used to define the relationship semantics and the key of each one entity appears on the right side of exactly one FD for that relationship. Ternary relationships can have attributes in the same way that many-to-many binary relationships can. The values of these attributes are uniquely determined by some combination of the keys of the .