Free data modeling tool software for linux

Yukatan data model project is the schema definition of the Yukatan webmail database.
The PostgreSQL database structures defined in this file can be used as a backend store of an email message handling application. The database should be created with the "UNICODE" encoding to properly support messages in different languages.
New data types
The special data types commonly used in the Yukatan data model have been made explicit by the introduction of seven new domains. The domains and the related COMMENT statements make field semantics more clear than before.
See the SQL schema file for more detailed documentation on these domains.
Explicitly named constraints
All the table constraints in the database are now explicitly named and documented. This change makes the database implementation more orthogonal and cleans up the documentation.
Renamed fields and tables
All the *address field names have been truncated to *addr, to make it visually clearer that they are always paired with the corresponding *name fields. The change also makes parts of the documentation less repetitive.
The referencesfield table has been renamed to referencefield to avoid the plural form in the table name. Also all the contained references* field names have been renamed to reference*.
Semantic changes
Quite a few changes have been made to the semantics of various fields. The unnecessarily tight constraints on sequence numbers have been replaced with clearer documentation, the format and encoding of most fields has been explicitly documented, and the previously allowed dual use of the enttext and enddata fields has been prohibited.
Dropped envelope data
The envelope data added in version 0.5 of the data model has for now been removed. The reason for the removal is that the envelope data is not an integral part of an email message, and I wanted to make the version 1.0 as clear as possible. The database now stores "email messages" - nothing less, nothing more. Envelope data can and probably will be reintroduced in an incremental version 1.x along with other extensions.
Enhancements:
- cleans up and documents the data model that has developed since version 0.1
- removal of the envelope data added in version 0.5
- enaming and redefinition of some of the fields and tables
- database structure has also been extensively documented

Installation: The simplest way to compile this package is:

1. `cd to the directory containing the packages source code and type `./configure to configure the package for your system.
2. Running `configure might take a while. While running, it prints some messages telling which features it is checking for.
3. Type `make to compile the package.
4. Optionally, type `make check to run any self-tests that come with the package.
5. Type `make install to install the programs and any data files and
6. documentation.
7. You can remove the program binaries and object files from the source code directory by typing `make clean. To also remove the files that `configure created (so you can compile the package for a different kind of computer), type `make disclean. There is also a `make maintainer-clean target, but that is intended mainly for the packages developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution.

JavaPK for Desktop (JPKD) is a Clinical Pharmacokinetic (CPK) Services (or Therapeutic Drug Monitoring, TDM).
It not only inherits all functionalities of JavaPK for Mobile Devices, but also has a built- in algorithm of users defined Bayesian model for individualized pharmacokinetic parameter estimation (UDBM) for batch input data.
Users can define their own pharmacokinetic prediction models with population PK parameters and then use the defined model to solve batch prediction data or applied the defined model to therapeutic drug monitoring (TDM).
JPKD is created for your own personal uses and testing purposes. JPKD shall be used as a guide or a decision support tool only. Medical decisions should NOT be solely based on the results of this program. Although this program has been tested thoroughly, the accuracy of the information cannot be guaranteed. Once you use JPKD, you have automatically agreed with this disclaimer.
Main features:
- Sawchuk-Zaske (aminoglycosides & vancomycin) and Bayesian method for PK parameter estimation
- 15 built-in drugs for TDM (see the below drug lists)
- functions for users defined Bayesian estimation drug models
- portable function for users defined models
- a built-in spread sheet for batch PK parameter estimation & input data manipulation
- application user-defined Bayesian model to TDM
- multiple desktop platforms (WinXP/NT, Mac OS X, Linux PC) supported
Built-in drug lists
- Amikacin
- Carbamazepine
- Cyclosporin
- Digoxin
- Enfuvirtide
- Everolimus
- Gentamicin
- Indinavir
- Lithium
- Phenytoin
- Ritonavir
- Tacrolimus
- Theophylline
- Tobramycin
- Vancomycin

DOG Data Organizer provides a bookmark organizer for various bookmark types.

DOG is a personal knowledge manager based on topic maps. It currently specializes in managing bookmarks.

It imports and exports Netscape, Mozilla, and KDE2 (XBEL) bookmark files, and it imports KDE1 bookmarks and Windows IE Favorites.

Data::FormValidator::Constraints is a Perl module with basic sets of constraints on input profile.

SYNOPSIS

use Data::FormValidator::Constraints qw(:all);
In an Data::FormValidator profile:
constraint_methods => {
email => email(),
fax => american_phone(),
phone => american_phone(),
state => state(),
},

These are the builtin constraints that can be specified by name in the input profiles.
Be sure to check out the SEE ALSO section for even more pre-packaged constraints you can use.

Gtk::CListModel is a simple data model with Gtk::Clist views.

SINOPSYS
my $model = tie @data, Gtk::CListModel,
titles => ["Fruit", "Price", "Quantity"];
# all data manipulation is done on @data now
push @data, ["Oranges", 5, 16];
# Create a view (a Gtk::Clist widget) to represent the data
# Include only some of the data in the view (fruit type and price)
# Also, do not include fruits that cost more than 6 price units.
my $clist = $model->create_view(main,
titles => [Fruit, Price],
filter => sub {$_[1] > 6? () : @_});

Gtk::CListModel lets you keep your data in a perl array and easily create a numer of different views on that data using Gtk::CList widgets. The views can show only some of the columns, or a subset of the data or even munge the data with user-defined filters.

All the data manipulations will be performed on a tied array and the changes will be propagated to the views created for that data.

To create the model use tie:

my $model = tie @data, Gtk::CListModel,
titles => ["head1", "head2",...];

The titles attribute should be an array reference with the titles of the columns of data. They will be used also for the default titles in the views.

You can also provide the initial data using the data attribute. Remember that the data elements you insert and retreive from the @data array are array references with as many items as the columns in the model. The order is the one defined by the titles attribute.

Later you can manipulate the @data array with the usual perl array operators, push, splice and so on.

METHODS

create_view ($name[, %options])

Create a Gtk::Clist widget that represents the data in the model. The name can be used later to disconnect the view from the data.

Options can be one of the following:

titles

An array reference of the titles of the columns to display in the list in the order they should appear in the view. The default is the titles specified at the model creation.

filter

A function that can manipulate the data just before it is inserted in the Gtk::CList. The function will receive the data and can either make a copy and modify the data or return an empty list. In the latter case the data will not be added to the view or, if the corresponding row was already present, it will be removed from the view.

postfilter

A function that receives the view, the row and the data that was just inserted/modified in the view. By default all the data is inserted in the views as text. This filter can be used to display pixmaps, for example or do any other kind of manipulations on the Gtk::CList row.

remove_view ($name)

Disconnect the named view from the data. The current data displayed in the view will not be affected, but changes in the model will not propagate to this view anymore.

map_row ($clist, $row)

Get the index in the data array cooresponding to the row displayed in the Gtk::CList widget.

Hydrate is a Java tool that provides for fast efficient and error-free transformation of data between three different representations: relational databases, objects in an object-oriented programming language and extended markup language (XML).
Each of these representations has its strengths and weaknesses as shown in the diagram below; but which should you use as a basis for your application design?
Hydrate relaxes some of the pressure on this decision by providing tools for moving data from one representation to another, guided by a master UML class representation of that data.
- You want to lay a domain object model view over an existing database or set of databases. Hydrate gives you the tools to design that model in UML and map your existing data to that model. Once in the object space, you can perform complex manipulations on the objects, calculate results and save information back to a relational cache for searching or reloading, as well as converting the results to XML for sending to downstream systems or transforming to a readable format for display.
- Your project involves taking various data files fed from external systems that you want to pull into an object model on your server before writing the results down to a fully relational database. You can now respond to requests from external systems by rehydrating the data from its relational form and sending it out as XML documents or transforming those documents to a readable format for display.
- You are building a data warehouse in which you have the broad specifications for the model, but want to provide for flexibility and adaptability for future unpredicted requests. Based on a core data model, Hydrate gives you the tools to create you database schema, and write information to it, but more significantly to subsequently lay a completely different object model perhaps aggregating some of the data over the top of that schema to process it in unforeseen ways.
- You need to integrate data from many different data sources in a highly performant manner. SQL permits you to read a huge data set a row at a time and perform running calculations and filtering on that data. But the performance pressures can lead to code that is highly coupled with the database and what do you do if you need to integrate data from elsewhere in order to complete your calculations? Hydrate permits you to operate in the object space and integrate information from other sources on-the-fly.
Main features:
- To integrate legacy and other data schemas over which you have little control. Map data from many different data sources into a single self-consistent in-memory model. Different parts of the same object, as well as different sub-populations of the same object type can be drawn from different data sources, different schemas and even different database architectures.
- Load, populate and connect up multiple object types from a single query. There is no limit to the number of object types that can be loaded from a single query, or to the complexity of the relationships that can be resolved between them. Objects read from a query are automatically merged into objects already in memory.
- Full control over the SQL that runs against the database (if you need it). Any SQL queries simultaneously from multiple JDBC drivers, even using database specific optimizations, as long as they returns a result set.
- Access and manipulate the same data through the rich and powerful XML toolset. Use the same meta data that describes your objects to easily read from, write to and validate any consistent XML schema. Use XML for display, data transmission or XSLT transformation. Load XML data back into objects.
- Highly optimized performance for reading and writing SQL and XML. Since native types are used and SQL chatter is non-existent, database performance is comparable with doing the mapping by hand. XML reading and writing uses SAX exclusively.