Research IT Application Development


Use of domains is an effective aid to design and implement consistent databases. In the design world of Erwin, for example, domains insure that all attributes defined by a domain share the same data type and value constraints. In the implementation world of Microsoft SQLServer, domains are known as User Defined Data Types. Indeed, when Erwin is used to generate a SQLServer database schema, its implementation of domains is to build sp_addtype statements for User Defined Data Types. In Oracle, types are created with the CREATE OR REPLACE TYPE statement.
Suppose one had a database  of manufacturing parts, where some parts included other parts. As you can imagine,  there could be a lot of tables with part_id as  an attribute.  By using domains, one avoids problems such  as attributes being half-word integer in some places but full word  integer in others.  
It is not always possible that a concept have the same  attribute name.  For example, in a parts of parts table, there  may be parent_part_id and a child_part_id attributes, but defining  each attribute with the same domain ensures consistency.   Searching the database schema for just part_id could easily  miss these instances.
Domains also facilitate documentation. When  contemplating a system change, by looking up all attributes which  use a given domain, one can see all instances where a change might  impact the system, regardless of how the attributes are named.   If text documentation is attacted to the domain, it is not  necessary to redundantly document its underlying concept at each  attribute.
Domains also facilitate object oriented application  development.  C. J. Date, the relational database expert, maintains that domains are the proper database analog to  programming objects.

Return to previous page