Revision: 3176
Author: jfuerth
Date: Fri Nov 27 12:10:37 2009
Log: Edited wiki page through web user interface.
http://code.google.com/p/power-architect/source/detail?r=3176
Modified:
/wiki/DomainsFeature.wiki
=======================================
--- /wiki/DomainsFeature.wiki Tue Nov 17 11:10:05 2009
+++ /wiki/DomainsFeature.wiki Fri Nov 27 12:10:37 2009
@@ -1,20 +1,56 @@
-#summary Our ideas about implementing data domains
+#summary Our ideas about implementing domains and user-defined types
#labels Phase-Requirements
-The Architect currently does not support the concept of data domains, but
it's a feature we have been planning to add for some time.
-
-
==Motivation==
# Provide a way of using every native type in all target databases
without requiring a commitment to a single target platform up front
- # Provide the means to create a more compelling logical model by
allowing the use of logical types
- * This also makes it possible to produce simplified diagrams for
reporting users where types are boiled down
to "text," "number," "date/time," and "boolean."
- # Pave the way for an "enterprise metadata repository" that will enhance
the rest of our product suite when used against a database on which logical
types have been defined (either because the model was created in Architect,
or the domains were "retrofitted" over an existing model).
-
+ # Provide a good implementation of the notion of domains that people
expect of a proper data modeling tool
+
+==What are Domains and User-Definable Types?==
+
+Domains:
+ * A logical concept that captures a semantic idea, not only a physical
representation (postal code vs. variable length character field)
+ * Consists of:
+ * Domain name
+ * Data type (a platform independent user-definable type; explained
below)
+ * Length (precision and scale)
+ * Default value
+ * Check Constraint or enumeration of allowed values
+ * If enumerated, this can automatically be carried through to the
physical representation as a proper enum or a check constraint (whatever
is "normal" for each target platform)
+
+Types:
+ * Just a physical representation, but keyed by database platform. /This
is a key feature of SQL Power's Power*Architect that no other tool
provides./
+ * Power*Architect comes with a set of starter types that should be
useful for most situations (i.e. anything you could achieve with previous
versions of Power*Architect)
+ * Plus, you can define new ones and say which actual physical type to
use in each target platform that you care about.
+ * You can always come back later and start to care about additional
platforms in the future
+ * Consists of these properties:
+ * Platform independent:
+ * Type name (this one item identifies the type and is not
platform-dependant)
+ * Basic type ("text," "number," "date/time," "boolean, "
and "other.")
+ * Platform dependent:
+ * Physical data type
+ * We will default this based on standard platform-dependent
representations if Basic Type is not "Other." This will save time in the
majority of cases.
+ * Precision (can be specified with a value, set "not applicable," or
left as a parameter)
+ * Scale (can be specified with a value, set "not applicable," or
left as a parameter)
+ * Default value
+ * inherited from domain or overridden by column definition if not
specified here
+ * Check Constraint or enumeration of allowed values
+ * inherited from domain or overridden by column definition if not
specified here
+
+==How do you use them?==
+
+ * In Column Properties dialog, you can choose to use a type or a domain
(ideally, we'd always use domains, but in practice, it's too tedious to
define enough domains to cover every single attribute in the model)
+ * if you choose a domain, all the particulars of the type are locked
down; you can't vary them from what the domain and its type specify.
+ * if you choose a data type, you can edit all the particulars as usual
+ * There will be a project preference that lets you choose how to display
column type information in the playpen:
+ * Domain name
+ * Type name + length (precision, scale)
+ * Basic type ("text," "number," "date/time," "boolean, " and "other.")
==Implementation Considerations==
# Don't compromise Architect's unique feature of platform-independent
modeling
+ * But make modeling for a heterogeneous environment easy and
straightforward too
# Must preserve forward compatibility for existing .architect project
files
# Think about how this new feature might interact with, enhance, or be
enhanced by the Architect's existing feature set:
* Forward Engineering
@@ -27,25 +63,15 @@
* HTML data model report
* OLAP modeling
-==Proposed Features==
-
- * Domains would appear wherever data types are currently used
- * Add a project setting to choose between displaying Domains and
physical types for a particular database platform
- * Be able to specify domains for columns of existing database tables
- * GUI facility for defining new domains, capturing:
- * Logical type name
- * "Basic" or fundamental type: text, number, boolean, date/time, and
complex/other
- * Physical type in each target database you care about, including
precision and scale plus custom native-coded check constraints (can be
deferred until forward engineering time if desired)
- * Constraints on value
- * Default value
- * Display preferences (number/date format, alignment, display width)
- * Description/documentation of purpose and correct usage
- * Preferred aggregation function
+==Specific Features We Will Implement==
+
+ * Description/documentation of purpose and correct usage
* TODO: Need to consider how reverse engineering will work
-
-==Optional Features==
-
- * Include an example library of semantic types that people could start
with
+ * Include an example library of semantic types that people could start
with
+
+==Not in Scope==
+
+ * Display preferences (number/date format, alignment, display width)
+ * Preferred aggregation functions
* Ability to define a hierarchy of domain types (such as a Monetary base
class which would then have CAD, USD, and so on)
- * A more structured way to define enumerated types that forward engineer
as ENUM or varchar with check constraints depending on target platform
support and idioms
- * Ability to "extract" the domains from a project file so that they can
be used in another project
+ * Ability to "extract" the domains from a project file so that they can
be used in another project (this feature will only be available when
connected to SQL Power's Power*Architect Enterprise Server)
