Tuple

About: Tuple is a research topic. Over the lifetime, 6513 publications have been published within this topic receiving 146057 citations. The topic is also known as: tuple & ordered tuplet.

Computing Critical $k$ -Tuples in Power Networks

Abstract: In this paper the problem of finding the sparsest (i.e., minimum cardinality) critical k-tuple including one arbitrarily specified measurement is considered. The solution to this problem can be used to identify weak points in the measurement set, or aid the placement of new meters. The critical k-tuple problem is a combinatorial generalization of the critical measurement calculation problem. Using topological network observability results, this paper proposes an efficient and accurate approximate solution procedure for the considered problem based on solving a minimum-cut (Min-Cut) problem and enumerating all its optimal solutions. It is also shown that the sparsest critical k -tuple problem can be formulated as a mixed integer linear programming (MILP) problem. This MILP problem can be solved exactly using available solvers such as CPLEX and Gurobi. A detailed numerical study is presented to evaluate the efficiency and the accuracy of the proposed Min-Cut and MILP calculations.

System, method, and computer program product for efficiently translating relational tuples to object-oriented objects

Abstract: A procedure for translating tuples received from a relational database management system (RDBMS) to object-oriented objects is described. The procedure operates by instantiating one or more application objects, and then setting base attributes of the application objects using information in the tuples. One or more intermediate objects are created using information in the tuples to represent those application objects having relationship attributes requiring dereferencing. Relationship attributes in the application objects are then set by swizzling the intermediate objects (rather than by swizzling the application objects themselves).

Temporal modules: an approach toward federated temporal databases

Abstract: In a federated database environment, different constituents of the federation may use different temporal models or physical representations for temporal information. This paper introduces a new concept, called a temporal module, to resolve these differences, or mismatches, among the constituents. Intuitively, a temporal module hides the implementation details of a temporal relation by exposing its information only through two windowing functions: The first function associates each time point with a set of tuples and the second function links each tuple to a set of time points. A calculus-style language is given to form queries on temporal modules.Temporal modules are then extended to resolve another type of mismatch among the constituents of a federation, namely, the mismatch involving different time units (e.g., month, week and day) used to record temporal information. Our solution relies on “information conversions” provided by each constituent. Specifically, each temporal module is extended to provide several “windows” to its information, each in terms of a different time unit. The first step to process a query addressed to the federation is to select suitable windows to the underlying temporal modules. In order to facilitate such a process, time units are formally defined and studied. A federated temporal database model and its query language are proposed. The query language is an extension of the above calculus-style language.

Foundation for object/relational databases : the third manifesto : a detailed study of the impact of objects and type theory on the relational model of data including a comprehensive proposal for type inheritance

Abstract: Preface. I. PRELIMINARIES. 1. Background and Overview. What is The Third Manifesto? Why did we write it? Back to the relational future. Some guiding principles. Some crucial logical differences. Topics deliberately omitted. The Third Manifesto: A summary. 2. Objects and Relations. Introduction. What problem are we trying to solve? Relations vs. relvars. Domains vs. object classes. Relvars vs. object classes. A note on inheritance. Concluding remarks. II. FORMAL SPECIFICATIONS. 3. The Third Manifesto. RM Prescriptions. RM Proscriptions. OO Prescriptions. OO Proscriptions. RM Very Strong Suggestions. OO Very Strong Suggestions. 4. A New Relational Algebra. Introduction. Motivation and justification. BREMOVE(c), BRENAME(c), and BCOMPOSE(c). Treating operators as relations. Formal definitions. Transitive closure. 5. Tutorial D. Introduction. Types and expressions. Scalar definitions. Tuple definitions. Relational definitions. Scalar operations. Tuple operations. Relational operations. Relations and arrays. Statements. Syntax summary. Mapping the relational operations. III. INFORMAL DISCUSSIONS AND EXPLANATIONS. 6. RM Prescriptions. RM Prescription 1: Scalar types. RM Prescription 2: Scalar values are typed. RM Prescription 3: Scalar operators. RM Prescription 4: Actual vs. possible representations. RM Prescription 5: Expose possible representations. RM Prescription 6: Type generator TUPLE. RM Prescription 7: Type generator RELATION. RM Prescription 8: Equality. RM Prescription 9: Tuples. RM Prescription 10: Relations. RM Prescription 11: Scalar variables. RM Prescription 12: Tuple variables. RM Prescription 13: Relation variables (relvars). RM Prescription 14: Real vs. virtual relvars. RM Prescription 15: Candidate keys. RM Prescription 16: Databases. RM Prescription 17: Transactions. RM Prescription 18: Relational algebra. RM Prescription 19: Relvar names, relation selectors, and recursion. RM Prescription 20: Relation-valued operators. RM Prescription 21: Assignments. RM Prescription 22: Comparisons. RM Prescription 23: Integrity constraints. RM Prescription 24: Relvar and database predicates. RM Prescription 25: Catalog. RM Prescription 26: Language design. 7. RM Proscriptions. RM Proscription 1: No attribute ordering. RM Proscription 2: No tuple ordering. RM Proscription 3: No duplicate tuples. RM Proscription 4: No nulls. RM Proscription 5: No nullological mistakes. RM Proscription 6: No internal-level constructs. RM Proscription 7: No tuple-level operations. RM Proscription 8: No composite attributes. RM Proscription 9: No domain check override. RM Proscription 10: Not SQL. 8. OO Prescriptions. OO Prescription 1: Compile-time type checking. OO Prescription 2: Single inheritance (conditional). OO Prescription 3: Multiple inheritance (conditional). OO Prescription 4: Computational completeness. OO Prescription 5: Explicit transaction boundaries. OO Prescription 6: Nested transactions. OO Prescription 7: Aggregates and empty sets. 9. OO Proscriptions. OO Proscription 1: Relvars are not domains. OO Proscription 2: No object IDs. 10. RM Very Strong Suggestions. RM Very Strong Suggestion 1: System keys. RM Very Strong Suggestion 2: Foreign keys. RM Very Strong Suggestion 3: Candidate key inference. RM Very Strong Suggestion 4: Transition constraints. RM Very Strong Suggestion 5: Quota queries. RM Very Strong Suggestion 6: Generalized transitive closure. RM Very Strong Suggestion 7: Tuple and relation parameters. RM Very Strong Suggestion 8: Special ("default") values. RM Very Strong Suggestion 9: SQL migration. 11. OO Very Strong Suggestions. OO Very Strong Suggestion 1: Type inheritance. OO Very Strong Suggestion 2: Types and operators unbundled. OO Very Strong Suggestion 3: Collection type generators OO Very Strong Suggestion 4: Conversions to/from relations OO Very Strong Suggestion 5: Single-level store IV. SUBTYPING AND INHERITANCE. 12. Preliminaries Introduction. Toward a type inheritance model. Single vs. multiple inheritance. Scalars, tuples, and relations. Summary. 13. Formal Specifications. Introduction. IM Proposals. 14. Informal Discussions and Explanations. Introduction. IM Proposal 1: Types are sets. IM Proposal 2: Subtypes are subsets. IM Proposal 3: "Subtype of" is reflexive. IM Proposal 4: Proper subtypes. IM Proposal 5: "Subtype of" is transitive. IM Proposal 6: Immediate subtypes. IM Proposal 7: Single inheritance only. IM Proposal 8: Global root types. IM Proposal 9: Type hierarchies. IM Proposal 10: Subtypes can be proper subsets. IM Proposal 11: Types disjoint unless one a subtype of the other. IM Proposal 12: Scalar values (extended definition). IM Proposal 13: Scalar variables (extended definition). IM Proposal 14: Assignment with inheritance. IM Proposal 15: Comparison with inheritance. IM Proposal 16: Join etc. with inheritance. IM Proposal 17: TREAT DOWN. IM Proposal 18: TREAT UP. IM Proposal 19: Logical operator IS_T(SX). IM Proposal 20: Relational operator RX:IS_T(A). IM Proposal 21: Logical operator IS_MS_T(SX). IM Proposal 22: Relational operator RX:IS_MS_T(A). IM Proposal 23: THE_ pseudovariables. IM Proposal 24: Read-only operator inheritance and value substitutability. IM Proposal 25: Read-only parameters to update operators. IM Proposal 26: Update operator inheritance and variable substitutability. What about specialization by constraint? 15. Multiple Inheritance. Introduction. The running example. IM Proposals 1-26 revisited. Many supertypes per subtype. Type graphs. Least specific types unique. Most specific types unique. Comparison with multiple inheritance. Operator inheritance. 16. Tuple and Relation Types. Introduction. Tuple and relation subtypes and supertypes. IM Proposals 1-11 still apply. Tuple and relation values (extended definitions). Tuple and relation most specific types. Tuple and relation variables (extended definitions). Tuple and relation assignment. Tuple and relation comparison. Tuple and relation TREAT DOWN. IM Proposals 18-26 revisited. Appendixes. Appendix A. A Relational Calculus Version of Tutorial D. Introduction. Boolean expressions. Builtin relation operator invocations. Free and bound range variable references. Relation UPDATE and DELETE operators. Examples. Appendix B. The Database Design Dilemma. Introduction. Encapsulation. Discussion. Further considerations. Appendix C. Specialization by Constraint. Introduction. A closer look. The "3 out of 4" rule. Can the idea be rescued? Appendix D. Subtables and Supertables. Introduction. Some general observations. The terminology is extremely bad. The concept is not type inheritance. Why? Appendix E. A Comparison with SQL3. Introduction. RM Prescriptions. RM Proscriptions. OO Prescriptions. OO Proscriptions. RM Very Strong Suggestions. OO Very Strong Suggestions. IM Proposals (scalar types, single inheritance). IM Proposals (scalar types, multiple inheritance). IM Proposals (tuple and relation types). History of the wrong equation in SQL3. Appendix F. A Comparison with ODMG. Introduction. Overview. RM Prescriptions. RM Proscriptions. OO Prescriptions. OO Proscriptions. RM Very Strong Suggestions. OO Very Strong Suggestions. IM Proposals (scalar types, single inheritance). IM Proposals (scalar types, multiple inheritance). IM Proposals (tuple and relation types). Appendix G. The Next 25 Years of the Relational Model? Remarks on republication. Introduction. Background. The Third Manifesto and SQL. Technical content. More on SQL. Miscellaneous questions. Appendix H. References and Bibliography. Index. 0201309785T04062001

System and method for confirmationally-flexible molecular identification

Abstract: A reference storage process populates a data structure so that the data structure contains all of the molecular structures and/or rigid substructures in the database classified according to attributes of tuples. In a preferred embodiment, the tuples are derived from sites (e.g. atomic sites) of the molecular structures and the attributes can be derived from geometric (and other) information related to the tuples. The attributes are used to define indices in the data structure that are associated with invariant vector information (e.g. information about rotatable bond(s) in skewed local coordinate frames created from tuples). These representations are invariant with respect to the rotation and translation of molecular structures and/or the rotation of substructures about attached rotatable bond(s). Accordingly, the invariant vector information is classified in the data structure with the respective tuple attributes in locations determined by the index derived from the respective tuple. A matching process creates one or more tuples, skewed local reference frames, and indices (called test frame tuple indices) for the structure (substructures) of a test molecule using the same technique that was used to populate the data structure. The test frame tuple index accesses the invariant vector information and tallies the frequency of matching in order to determine the identity of molecules/substructures in the database that are structurally similar to the test molecule. This identification can be achieved even in the presence of conformationally flexible molecules in the database.