Big Chemical Encyclopedia

Chemical substances, components, reactions, process design ...

Articles Figures Tables About

One-to-Many Relationships

High, low limits for expected test results A one-to-many relationship exists from the Method Record to the Analysis Record since one Method generally is used for the analysis of many samples. [Pg.37]

In the previous examples, a one-to-one correspondence exists between the units and the tasks (e.g., in Fig. 2 each node performs a particular separation task). It is possible, however, to develop more general superstructure representations in which a one-to-many relationship exists between the units and the tasks. An example of a one-to-many relationship is the superstructure for separation shown in Fig. 6 proposed by Sargent and Gaminibandara (1976), this superstructure accommodates sharp splits and has the Petlyuk column embedded as an alternative design. Note, for instance, that column 1 does not have a prespecified separation task. From this example it is clear that superstructures that have one-to-many relationships between units and tasks tend to be richer in terms of embedded alternatives. On the other hand, the more restricted one-to-one superstructures tend to require simpler MINLP models that are quicker to solve. [Pg.184]

This kind of relationship between two tables is called a one-to-many relationship because for any one compound in the epa.compound table, there could be many rows in the logP table, related by the cid column. Once this type of relationship is established between two tables, it easily accommodates other tables of data. For example, if several molecular weight values for each compound were to become necessary, a new table for molecular weight could be created that would use the same compound id to relate to the compound table. The column used to relate two tables is called the key column. In this example, it would be called a primary key in the epa.compound table and a foreign key in the epa.logP table. Keys are discussed further in a later section of this chapter. [Pg.11]

One-to-many relationships are common, but one-to-one relationships are everywhere. For example, in epa.compound Table 2.2, each compound has one formula. It would be possible to create a separate table for formulae, in which case there would be a one-to-one relationship between the epa.compound table and the epa.formula table. There is no fundamental need to separate molecular formulae into a separate table, simply because there is a one-to-one relationship. The relationship is based on understanding the nature of the data, namely understanding that a compound can have only one molecular formula. Nevertheless, data such as molecular formulae is sometimes stored in a separate table, for convenience, for clarity, or because it was added at a later date after the table was constructed. [Pg.11]

In the tables discussed earlier, the experimental or theoretical values were clearly attributable to one structure or compound. In some cases, say, for molecular weight, there was a one-to-one relationship with the compound. In the case of logP shown above, there were many values of logP and the separate table of logP values exhibited a one-to-many relationship with compounds. Consider the case of compound vendors. There are many vendors that supply any one compound and each vendor supplies many compounds. This situation is referred to as a many-to-many relationship between compounds and vendors. A separate table is created to define the unique vendors and the corresponding vendor ids. Along with the unique compound table, a third table is defined that contains only compound ids and vendor ids. The set of rows in this third table with a particular compound id indicates which vendors supply that compound. And the set of rows with a particular vendor id indicates which compounds that vendor supplies. [Pg.12]

Figure 2.1 Entity relationship diagram showing the one-to-many relationship between compounds and logP. Figure 2.1 Entity relationship diagram showing the one-to-many relationship between compounds and logP.
In Chapter 2, the usefulness of relational tables was introduced. Sample data from the U.S. Environmental Protection Agency was used to show the advantage of storing each type of data in a separate table. The data in each table remain related to the proper chemical compound through the use of a unique chemical id, which functions as a unique key relating multiple tables. This technique will be used extensively in this and following chapters. The separation of data into multiple tables also facilitates cases where a compound may have multiple data values, also known as one-to-many relationships. This chapter will show examples of how many-to-many relationships are handled. It will also show more examples of how the choice of data types affects the operation of the database and the applications that use it. [Pg.47]

Finally, any properties contained in the molfile will be stored in a separate table containing the text value copied from the file as well as a numeric value for the property, if that is appropriate for the property. There will be a one-to-many relationship between the structure and property table, allowing any number of properties to be stored for each structure. The function openbabel.molfile properties is shown in the Appendix. It expects a molfile and returns a composite data type, defined as follows. [Pg.129]

Pay special attention to how relationships between tables are established by sharing a common field value. In this example, there is a one-to-many relationship between the Employee and Department tables established by the common DepartmentID field. Here, Robert Adams and Mary Roberts are in the Engineering department DepartmentID = 20). The tables represented here are independent of one another yet easily connected in this manner. It is also important to recognize that the table structure is only a logical structure. How the relational DBMS chooses to represent the data physically is of little concern to the user or database designer. They are shielded from these deteiils by the DBMS. [Pg.81]

Table 21.1 describes elements checked during DaimlerChrysler s PSO process. We forecast that, as quality practices advance, most industries will move to quality standards similar to those described here. The PSO model used by Chrysler will likely be replicated in one form or another. This is particularly true where dominant organizations such as Boeing in aircraft and the Big 3 automakers have the clout of the one-to-many relationship with their suppliers. [Pg.252]

The results of this preliminary investigation accorded with historical perspectives and recent sport coaching interventions of the critical nature and immediacy of mental state changes on performance. The person focused approach must be seen to be timely given the magnitude and frequency of human error attributed to incidents. The economy and utility of an intervention that operates in a one-to-many relationship such as the recoveiy of SA process (one technique that addresses many types of situations), is an attractive prospect to that of the present many-to-many (a specific procedure to deal with each situation) approach in safety training. [Pg.255]

Even in this very simple example there is a one-to-many relationship between an ISPS operator and some Register-Transfer Level operators and there is a VT value that is linked to a Register-Transfer Level value, but does not correspond to any value in the ISPS design representation. These are very simple examples of the complexity of the links that must be maintained as well as the addition of information (operators and values) synthesized in the Workbench. [Pg.266]

Note all tables are in one-to-many relationships, in the direction as shown in figure 6-14 above (for example, one cause can relate to many hazards) except for the relationships between ... [Pg.187]

Configuration Control 1. System hazard log version number, 2. Version details 3. Comments 4. Issued by One to Many relationship with 1. Related j oumal entries... [Pg.190]

A block diagram of the synthesis flow in Hercules and Hebe is shown in Figure 10.1. There is a one-to-many relationship between a HardwareC model and its SIF models, and between a SIF model and its SLIF design points. We now describe the details of each program. Section 10.1 describes the synthesis flow and organization of Hercules. Section 10.2 describes the synthesis flow and organization of Hebe. [Pg.238]


See other pages where One-to-Many Relationships is mentioned: [Pg.316]    [Pg.754]    [Pg.93]    [Pg.9]    [Pg.11]    [Pg.12]    [Pg.80]    [Pg.102]    [Pg.95]    [Pg.295]    [Pg.266]   
See also in sourсe #XX -- [ Pg.9 , Pg.11 ]




SEARCH



Many-to-one

© 2024 chempedia.info