Temporālās datu bāzes sistēmas veidošana



The scope of the TSQL language 1. TSQL is to be a relational query language.Given that SQL is “intergalactic dataspeak” (Mike Stonebraker’s term), TSQL should whenever possible be consistent with standard SQL, speci?cally, SQL89. It simply doesn’t make sense to base TSQL on competing (and arguably better) query languages such as Quel, Datalog, or Daplex. (Given that my language design work is based on Quel, I ?nd it particularly painful that SQL has dominated over that superior language.) While I strongly agree that interesting research is possible and even desirable in extending the other languages to include temporal support, such extensions are necessarily outside of the scope of TSQL.2. TSQL need not be consistent with existing standards.In general, TSQL need not be consistent with SQL2, which is in the ?nal standardization process, nor SQL3, which is currently being designed. SQL2 contains severe ?aws in its (minimal) handling of time-stamps, and SQL3 is a moving target which, in its present state, is regarded by many as a baroque design with a bewildering array of features. Consistency with the non-temporal aspects of existing standards for SQL, including SQL89, SQL2, and SQL3, is desirable if such consistency does not con?ict with other goals.3. TSQL will not be another standard.While the goal is a fully elaborated language design, there is no expectation that this design will be made into a standard. Of course, one hopes that our results would be acceptable to the standards bodies; at a minimum, our design should be communicated to these bodies. However, it is important to keep in focus the objective of the TSQL design: to provide a basis for future research in temporal databases. It also must be emphasized that TSQL should in no way limit or constrain future research in temporal databases, which should be free to adopt or propose whatever linguistic constructs are appropriate.4. TSQL will not be an object-oriented query language.While temporal object-oriented query languages are being actively investigated, it would be distracting and counter-productive at this stage to attempt to merge the rather disparate approaches of object-oriented and relational languages while also addressing the temporal processing needs. Those involved in object-oriented language design are encouraged to produce, in parallel with this e?ort, a temporal object-oriented extension to SQL. At a later date, the two extensions could be merged.5. TSQL should be comprehensive.TSQL should have constructs, extended in a natural fashion, that support all of the functionality of SQL, including update, aggregates, and schema speci?cation and evolution. Consistent with the modi?er “temporal”, TSQL should support both valid and transaction time.6. The language design should include a formal semantics.Fortunately, there is a tradition of rigor in the temporal database community. The recent publication in TODS of a straightforward semantics of SQL will also help here.7. The language will have an associated algebra.Such an algebra would demonstrate the existence of an executable equivalent to the declarative constructs in the language, and would suggest implementation strategies.8. TSQL will be a language design.The TSQL design should not attempt to de?ne storage structures, indexing structures, access methods, fourth-generation interfaces, support for distributed systems or heterogeneous databases, or optimization techniques. Such aspects, while important, are more properly the target of the research e?orts that will utilize TSQL as a common substrate.9. TSQL should re?ect areas of convergence.The design of TSQL should avoid active areas of research where new results are generated frequently. Such areas include historical indeterminacy and temporal database design.Temporālās vaicājumu valodas pamatkoncepcijas1. Darbam ar temporālām datu bāzēm ir jāizstrādā vaicājumu valoda, kas būtu:1) balstīta uz SQL valodu;2) k?ūtu par SQL valodas papla?inājumu.2. Temporālām vaicājumu valodām jāpapla?ina visas trīs datu mode?a komponentes: 1) datu struktūru;2) datu apstrādes darbības;3) ierobe?ojumus.3. Jebkurai korektai konstrukcijai vaicājumu valodā SQL ir jābūt korektai arī jaunajā valodā. Ir jāsaglabā arī ?o vaicājumu semantika (rezultātiem ir jābūt tādiem pa?iem kā SQL valodas vaicājumiem).SQL and temporal SQL queriesSQL query Relational algebra actions . . . SELECT ...FROM ...WHERE ......Temporal SQL query Tempral algebra actions . . .SELECT ...FROM ...WHILE ...VALID(A) ......Temporal query languages Peuquet (1994) mentions that the development of temporal query languages is a relatively new area, that has not received much attention from research and development until recently. Nevertheless over 20 query languages have been proposed. Most developments are a result of extending existing query languages such as SQL (Structured Query Language) or Quel, a query language for the INGRES relational DBMS, to the spatio-temporal domain. Tansel et?al. (1993) gives a survey of much of the work performed. TOSQL developed by Ariav (1986) is an extension of SQL. It allows access to both current data and their previous versions, but does not include update semantics. Snodgrass (1987) extended Quel to TQuel with language constructs to retrieve facts that have been time stamped with a validity interval. HTQUEL (Homogeneous Temporal Quel) proposed by Gadia (1988) is based on the same query language as TQuel. Time is considered as discrete equidistant time intervals. Kim et?al. (1990) developed ETQL as a front-end system to INGRES. ETQL supports abstract time (including relative time, e.g., last spring) to achieve easier specification of time in queries. In 1994 the specification of TSQL2 was published (Snodgrass et?al., 1994), which later resulted in proposals for an extension to SQL3 called SQL3/temporal. Standard SQL does not include time support except for user-defined time. Neither transaction time nor valid time is available. Date and time support in SQL-92 are similar to that in DB2 (Melton and Simon, 1993). The design for SQL3 only corrected some of the inconsistencies, but contains no additional temporal support over SQL-92 (Pissinou et?al., 1994). However, until 1994 the SQL3 proposals included several constructs that can be useful for temporal extensions (e.g., interval data type). Since then several change proposals were submitted to the ANSI and ISO SQL3 standards committees for adding a new part termed SQL/Temporal ( HYPERLINK "" \l "Snodgras97" Snodgrass, 1997; HYPERLINK "" \l "SnodBohl96a" Snodgrass et?al., 1996b, HYPERLINK "" \l "SnodBohl96b" a). None of these temporal query languages are built for complex spatial queries. Oracle recently announced their support for the HHCODE standard for spatial attributes. Such efforts could induce further developments in the research of temporal query languages including spatial aspects. Commercial database systems often support transaction time mechanism based on tuple time-stamping. Valid time is not supported as a built-in functionality. TSQL2 and SQL3 InteractionsVarious members of the temporal database research community have worked to transfer some of the constructs and insights of TSQL2 into SQL3. The first step was to propose a new part to SQL3, termed SQL/Temporal. This new part was accepted at the Ottawa meeting in January, 1995 as Part 7 of the SQL3 specification. A modification of TSQL2's PERIOD data type is included in that part. Discussions then commenced on adding valid-time and transaction-time support to SQL/Temporal. Two change proposals, ANSI-96-501 and ANSI-96-502, were unanimously accepted by ANSI and forwarded to ISO in early 1997, as MAD-146r2 (pdf) and MAD-147r2 (pdf), prepared for the ISO meeting in Madrid. A discussion of these proposals may be found in "Transitioning Temporal Support in TSQL2 to SQL3," by R. T. Snodgrass, M. H. Bohlen, C. S. Jensen, and A. Steiner, in Temporal Databases: Research and Practice, O. Etzion, S. Jajodia, and S. Sripada (eds.), Springer, pp. 150-194, 1998 (pdf). An etensive comparison between standard SQL and the proposed temporal support may be found in chapter 12 of Developing Time-Oriented Database Applications in SQL, Richard T. Snodgrass, Morgan Kaufmann Publishers, Inc., 1999 (pdf). Due to disagreements within the ISO committee, the project responsible for temporal support was canceled in 2001. However, concepts and constructs from SQL/Temporal were subsequently included in the SQL:2011 standard and have been implemented (via various syntaxes and semantics) in IBM DB2, MarkLogic Server, Microsoft SQLServer, Oracle, SAP HANA, and Teradata Database (see below); other products have included temporal support (see the list below for details). These ideas have also made their way into design patterns for things that change with time. Temporal Facilities in the SQL StandardISO/IEC 9075, Database Language SQL:2011 Part 2: SQL/Foundation, published December 15, 2011 (and weighing in at 1434 pages), includes clauses in table definitions to define "application-time period tables" (essentially valid-time tables), with sequenced primary and foreign keys, This standard also includes single-table valid-time sequenced insertions, deletions, and updates. Nonsequenced valid-time queries are supported. The standard includes clauses for defining "system-versioned tables" (essentially transaction-time tables) with transaction-time current primary and foreign keys and supporting transaction-time current insertions, deletions, and updates as well as transaction-time current and nonsequenced queries. Finally, the standard supports "system-versioned application-time period tables" (a mouthful, essentially bitemporal tables) and supporting temporal queries and modifications of combinations of the valid-time and transaction-time variants just listed for uni-temporal tables.Implementation in OracleOracle 9i, released in 2001, included support for transaction time. Its flashback queries allow the application to access prior transaction-time states of their database; they are transaction timeslice queries. Database modifications and conventional queries are temporally upward compatible. Oracle 10g, released in 2006, extended flashback queries to retrieve all the versions of a row between two transaction times (a key-transaction-time-range query) and allowed tables and databases to be rolled back to a previous transaction time, discarding all changes after that time. The Oracle 10g Workspace Manager includes the period data type, valid-time support, transaction-time support, support for bitemporal tables, and support for sequenced primary keys, sequenced uniqueness, sequenced referential integrity, and sequenced selection and projection, in a manner quite similar to that proposed in SQL/Temporal. These facilities permit tracing of actions on data as well as the ability to perform database forensics, as elaborated in the book "Oracle Forensics: Oracle Security Best Practices", by Paul M. Wright.Oracle 11g, released in 2007, does not rely on transient storage like the undo segments. Rather, it records changes in the Flashback Recovery Area. Validtime queries were also enhanced; see Workspace Manager Valid Time Support. [Oracle documentation]Oracle 12c, released in 2013, continues to support transaction time via the Workspace Manager, implemented as a PL/SQL package, while also supporting the (multi-)temporal features introduced in SQL:2011. (It seems that the valid-time support of prior versions of Workspace Manager has been removed, in favor of the SQL:2011 approach, though the enable_at_valid_time() procedure can specifiy various options for the visibility of table data.) The valid-time aspect (termed "temporal validity") of Oracle 12c is illustrated in an article and a tutorial. A blog post touches on transaction time implemented with the Flashback Data Archive, valid time implemented with temporal validity, and a third dimension called "decision time" also implemented with temporal validity. That blog post cautions that "The support for temporal data management in Oracle 12c is based on sound concepts, but the implementation is currently incomplete. I miss mainly a temporal DML API, temporal integrity constraints, temporal joins and temporal aggregations." Implementation in TeradataTeradata Database 13.10, released October 2010, introduced the period data type, valid-time support, transaction-time support, timeslices, temporal upward compatibility, sequenced primary key and temporal referential integrity constraints, nonsequenced queries, and sequenced projection and selection, in a manner almost identical to that proposed in SQL/Temporal.Teradata Database 14, released February 29, 2012, adds capabilities to create a global picture of an organization's business at any point in time.Implementation in IBM DB2IBM DB2 10 for z/OS, released in October 2010 for z/OS and in April 2012 for Linux, Unix, and Windows, includes the period data type, valid-time support (termed business time), transaction-time support (termed system time), timeslices, temporal upward compatibility, sequenced primary keys, and sequenced projection and selection, in a manner identical to that in SQL:2011. Here is a tutorial on temporal tables in DB2.Implementation in Microsoft SQLServerMicrosoft SQLServer 2016 provides support for a transaction-time backing table recording the history of a designated table, termed a "system-versioned temporal table". Implementation in SAP HANASAP HANA runs on SAP In-Memory Computing Engine, which provides support for History Tables. Such tables provide support for session level and statement level time travel, effectively a transaction-time slice. Implementation in MarkLogic ServerMarkLogic's MarkLogic Server product stores XML documents as a transaction-time database and supports transaction timeslice queries in XQuery (termed "point-in-time queries"), almost identically to that proposed in SQL/Temporal and applied to XQuery in τXQuery.Other Products Providing Temporal SupportStratio released in August 2015 a new version of their open source Lucene index plugin for Apache Cassandra. "One of its features is to index bitemporal data using the 4-R index approach (Bliujute, R. et al.) over four Lucene's date range prefix trees. Each Cassandra node indexes its own local data, allowing to efficiently manage large amounts of bitemporal data spread over hundreds of nodes. It can also be combined with MapReduce frameworks such as Spark and Hadoop to perform massive computations." This brings valid time and transaction time as well as valid-time+transaction-time slices into Big Data.Tom Johnston and Randy Weis have written a book entitled "Managing Time in Relational Databases" (Morgan Kaufmann) in which they present a novel approach called asserted versioning (also described on the book's web page). In this approach, bitemporal requirements are expressed separately and declaratively, in metadata tables.Tom Johnston has written a book entitled "Bitemporal Data: Theory and Practice" (Morgan Kaufmann) proposing three temporal dimensions: state time (i.e., valid time), inscription time (i.e., transaction time), and speech act time (originally called assertion time in his previous book). Asserted Versioning, LLC has developed a set of macros in ERWin that provide support for asserted versioning, included deferred assertions. These macros also provide full temporal upward compatibility and encapsulate the temporal complexity of primary key and foreign keys and of modifications (those not having complex predicates involving other temporal tables) over bitemporal tables (valid and transaction time). One-table updates (without a where clause) are allowed, with sequenced primary key and referential integrity constraints maintained across such updates. Non-sequenced queries are supported by making the begin and end dates explicit. One-table sequenced updates are also supported. Sequenced queries are not yet supported, nor are sequenced updates that reference other tables; those have to be mapped by the user into non-sequenced statements.IBM's DataPropagator can use data replication of a DB2 log to create both before and after images of every row modification to create a transaction-time database that can be later queried.LogExplorer from Lumigent provides an analysis tool for Microsoft SQLServer logs, to allow one to view how rows change over time (a nonsequenced transaction-time query) and then to selectively back out and replay changes, on both relational data and the schema (it effectively treats the schema as a transaction-versioned schema).TimeDB is a Java API and uses JDBC to run as a frontend for Oracle. Temporal statements (queries, updates, and assertions) are compiled into (sequences of) SQL-92 statements which are executed by the backend. TmeDB provides upward compatibility, temporal upward compatibility, and bitemporal support (valid time and transaction time).aTempo's Time Navigator is a data replication tool for DB2, Oracle, Microsoft SQL Server and Sybase that extracts information from a database to build a slice repository, thereby enabling image-based restoration of a past slice; these are transaction time-slice queries.The PolarLake Data Management Platform supports bitemporal data in financial applications, as HYPERLINK "" announced on June 9, 2011. Commenting on the release Warren Buckley, founder and CTO of PolarLake said, “The Investment Banking and Asset Management communities are facing new levels of transparency requirements from Regulators when it comes to Financial Data. Regulators will be keen to know what you knew and when you knew it about particular Data Entities. They will also want to know when your view of that Data Entity changed over time, with detailed history of the changes.”Temporal language TSQLSELECT ...FROM ...WHERE ...WHEN {BEFORE | AFTER | DURING (laikā) | EQUIVALENT | ADJACENT (blakus) | OVERLAP (da?ēji sakrīt) | FOLLOWS (seko) | PRECEDES (ir priek?ā) }Temporal language TempSQLSELECT ...WHILE (time expression, condition)FROM ...WHERE ...GROUP BY ...HAVING ...DURING (time expression, condition)SELECT a.SUR, b.TIME_PERIODWHILE A.SUR = B.SURFROM WORKERS A, PROJECTS BWHERE B.Proj_name = '1. projekts';SQL3 standardSQL3 adds the PERIOD( ) constructor. An SQL data type constructor specifies a new type constructed out of a specified type. Examples are SQL sets, multisets (i.e., with duplicates), and lists (i.e., with ordering). In the case of the period type constructor, you can specify period data types of the SQL datetime data types as well as of exact numerics with a scale of 0 (i.e., integers).Hence, the following period data types are available:PERIOD(DATE)PERIOD(TIME) and PERIOD(TIME WITH TIME ZONE)PERIOD(TIMESTAMP) and PERIOD(TIMESTAMP WITH TIME ZONE)PERIOD(INT) and PERIOD(INTEGER)PERIOD(SMALLINT)PERIOD(NUMERIC)PERIOD(DECIMAL)Predicates:p equals q p = qp before q p PRECEDES qp before?1 q p SUCCEEDS qp meets q END(p) = BEGIN(q)p meets?1 q END(q) = BEGIN(p)p overlaps q BEGIN(p) < BEGIN(q) AND BEGIN(q) < END(p)p overlaps?1 q BEGIN(q) < BEGIN(p) AND BEGIN(p) < END(q)p during q BEGIN(q) < BEGIN(p) AND END(p) < END(q)p during?1 q BEGIN(p) < BEGIN(q) AND END(q) < END(p)p starts q BEGIN(p) = BEGIN(q) AND END(p) < END(q)p starts?1 q2 BEGIN(p) = BEGIN(q) AND END(q) < END(p)p nishes q BEGIN(q) < BEGIN(p) AND END(p) = END(q)p nishes?1 q BEGIN(p) < BEGIN(q) AND END(p) = END(q)p OVERLAPS q p OVERLAPS qp IS NULL p IS NULLDatetime Constructors:beginning(p) BEGIN(p)previous(p) PRIOR(BEGIN(p))last(p) LAST(p)ending(p) END(p)Period (interval) constructors:duration(p) INTERVAL(p), INTERVAL(p AS qual )extract time zone(p) CAST(EXTRACT(TIMEZONE HOURFROM BEGIN(p)) AS HOUR) +CAST(EXTRACT(TIMEZONE MINUTEFROM BEGIN(p)) AS MINUTE)Period Constructors:p + i PERIOD[BEGIN(p) + i, END(p) + i)i + p PERIOD[BEGIN(p) + i, END(p) + i)p - i PERIOD[BEGIN(p) - i, END(p) - i)p extend q not possiblep \ q p P INTERSECT qp - q p P EXCEPT qp [ q p P UNION qp AT TIME ZONE i PERIOD[BEGIN(p) AT TIME ZONE i,END(p) AT TIME ZONE i)p AT LOCAL PERIOD[BEGIN(p) AT LOCAL, END(p) AT LOCAL)Other Operators:CAST(a AS PERIOD) PERIOD[a, a]CAST(p AS CHAR) CAST(p AS CHAR)Temporal SQL languages 1. TSQL2 ir papla?inājums standartam SQL-92 valodai, kas tika izveidots 1993. gadā. Neskatoties uz to, ka kop? valodas izveido?anas jau ir pagājis vairāk par 15 gadiem, mūsdienās TSQL2 valoda līdz pat ?īm brīdim ir populāra.Valoda satur vairākas funkcijas darbam ar laiku un datumiem, tomēr izstrādātāji centās minimizēt datu modeli un implementēt to tā, lai tā saturētu tikai pa?as vienkār?ākas (pamata) operācijas. 3. TOSQL.4. HSQL.5. IXSQL.6. CHRONOSQL.8. ATSQL.9. TOLAP ir SQL valodas papla?inājums, kas pievieno temporālu datu bā?u atbalstu vairāku dimensiju analītiskiem vaicājumiem OLAP. 10. TQuel ir papla?inājums Quel valodai. Tā atbalsta gan reālo, gan arī transakciju laiku. Atbalsta arī agregācijas, datu evolūcijas shēmas un reāla laika nenoteiktības jēdzienu, kad dro?i nav zināms, kāds laiks bija kāda noteikta notikuma laikā.11. T4SQL atbalsta vairākas operācijas, kas tika definētas kā nepiecie?amākās temporālo vaicājumu valodā. Valoda atbalsta vairākas temporālas datu dimensijas, neskaitot reāla laika un transakciju laiku, valoda atbalsta arī divus papildus jēdzienus – pieejamības laiku un notikumu laiku.12. TXQuery ir papla?inājums XQuery valodai, kura ir balstīta uz XML valodu. SQL-2006 standartā tika izstrādāti mehānismi, kuri ?āva izpildīt XQuery valodas vaicājumus SQL vaicājumos. is an open-source, easy to use, framework of components providing functionality for time related applications. Provides basic functionality handling the most common temporal aspects (for the moment instant, period, mediators managing temporal associations). It allows easy design and implementation of time-related applications.The cornerstone of the system is that Instant is an interface you implement. It depends on your business what the instant actually is. A particle physicist will not use the same kind of "instant" as a geologist. Also, java.util.Date is somewhat controversial, and many developers prefer other date frameworks, for immutability and date-only semantics. JTemporal is aimed at replacing some common temporal design patterns by reusable components.JTemporal proposes an API hiding the way the data is stored (in-memory collections, relational or temporal database, or whatever) and gives some temporal facilities to non temporal storage. Some functionalities are inspired by those provided by the temporal databases and by SQL practice. JTemporal tries to move the (redundant) temporal logic from the SQL to OO components. Tutorial - 1 - Basic StructuresThe foundations of JTemporal are Instants and Periods.Instant represents a time point. In the context of your application it could be a date, a millisecond or anything else. It is just an interface, you are supposed to implement it. If you are happy with java.util.Date or java.sql.Date, you can easily adapt it. Many companies have their own date framework, because java.util.Date is more "time" oriented than "date" oriented. For example, when you want to define a contractual date, like the starting day of a new employee, you do not want this date to be interpreted differently when the client application is in a different timezone.The object implementing Instant is expected to be immutable, like for example java.util.Integer. This means that once that object has been created, any of its fields cannot be modified, including recursively the referenced objects. The advantage of immutable objects is that they are inherently thread-safe and that the objects which are referencing them, especially collections, do not need to make defensive copies (cloning). Immutable objects can be used safely as keys of Map collections. As a simple example, in the JTemporal unit tests you can find the class IntInstant, adapting a simple int to be an Instant. Basically an Instant is just a java.parable.Once you have defined your Instants, you can use the Period class. A period is defined by two distinct instants and defines a time segment. It should not be confused with an interval which just defines a duration and not when this duration happens. Periods are immutable. By convention, the period is defined as "half-open", meaning that the start limit instant is part of the defined period, but the end limit instant is not : period = [start,end[There is a particular case, when "end" is the positive infinity: given that infinity-1 = infinity, infinity is always part of the period. The Period class offers some comfortable operations, like intersects(Period), overlaps(Period), contains(Instant), contains(Period), union(Period), etc.?Tutorial - 2 - Modeling temporal associations with unary cardinalitySuppose the following classic scenario. You have an object Employee which is associated to an object Salary. You have a salary for a given period, then another salary for another period. For your employee, at a given instant, there is at most one salary, the salary cardinality is 0..1 (unary).To conceptually represent our scenario, I like the language proposed by Carlson, Estepp and Fowler :The <<temporal>> stereotype indicates that the given cardinality applies at any given instant.?For the implementation, JTemporal provides the TemporalAttribute which is a collection acting as a mediator, managing the temporal aspects. You just put it in between like this:?TreeTemporalAttribute is currently the only implementation of TemporalAttribute. To define a salary, you just call put(period, salary). To know what the salary is at a given instant you call get(instant).When you call put(period, salary), if there is already definition for a period overlapping this period, then the intersecting period will be overwritten, without throwing exception. This behavior can surprise, but it is the same as when you write i=3. That will work in the same way, whether or not i previously contains a value.Internally, the storage is based on a java.util.TreeMap.?Tutorial - 3 - Modeling temporal associations with non-unary cardinalitySuppose now another classic scenario. You have an Employee and many Skill(s).Conceptually, it looks like this:?The only difference with the previous scenario is in the cardinality. The cardinality of [0,n] (called here "multi") applying to Skill requires a different mediator :Currently, TreeTemporalSet is the only implementation of TemporalSet. Here, you still define a skill by calling put(period, skill), but now you get the set of skills active at a given instant by calling valueSet(instant).Internally, TreeTemporalSet organizes the information in two main collections:- a TreeTemporalAttribute (per value) to allow quick access to information related to a given value- a HashMap (per endInstant) to allow quick access to information related to a given instantHere you can see the TreeTemporalSet internal structure, but you do not need to know it unless you want to modify the source code.?Tutorial - 4 - Code sample Suppose we have our employee again, with name, e-mail and skills that can change over the time.Below you can see how this Employee class can look like.A little working demo is included in the distribution zip file.public class Employee { private TemporalAttribute name = new TreeTemporalAttribute(); private TemporalAttribute email = new TreeTemporalAttribute(); private TemporalSet skills = new TreeTemporalSet(); public String getName(FinalDate d) { return (String) name.get(d); } public void setName(Period p, String s) { this.name.put(p, s); } public String getEmail(FinalDate d) { return (String) email.get(d); } public void setEmail(Period p, String s) { this.email.put(p, s);} public Set getSkills(FinalDate d) { return (Set) this.skills.valueSet(d); } public void addSkill(Period p, Skill s) { this.skills.put(p, s);} public void removeSkill(Period p, Skill s) { this.skills.remove(p, s);} public boolean hasSkill(FinalDate d, Skill s) { return this.skills.contains(d, s); } public String toString(FinalDate d) { String ret = "Employee as of " + d + ":" + "\n\tName : " + this.getName(d) + "\n\te-mail: " + this.getEmail(d) + "\n\tskills: " + this.getSkills(d); return ret; }}JTemporal temporal framework for Java0.80 Temporal is a framework of components providing functionalities for time related applications. Provides basic functionalities handling the most common temporal aspects (for example instant, period, temporal association).Packagesnet.sf.jtemporalMain packagenet.sf.jtemporal.spiInterfaces and implementations of .sf.jtemporal.utilGeneric independent tool classes. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download