Home > Data Modeler Concepts and U... > Working with Data Modeler
You can use Data Modeler to create, edit, and delete objects at different hierarchy levels in different kinds of models. Many objects have similar properties, and the methods for performing operations are usually consistent and intuitive. To perform operations on objects (create, edit, delete), you can often use the context menu in the object browser or the toolbar or the Object menu after selecting a diagram.
To perform an operation on an object using the object browser, right-click the appropriate node (or click the node and press Shift+f10) in the hierarchy, and select the command for the desired operation.
For example, to edit an entity, expand the Logical display so that all entities are visible, right-click the name of the entity to be edited, and select Properties.
To perform an operation using a diagram, select the tab for the diagram, and use either the toolbar icons or the Object menu commands.
For example, to create an entity, select the Logical tab; either click the New Entity toolbar icon or click Object , then Logical, then New Entity; then define the entity in the Entity Properties box. To edit an entity, either double-click its box in the diagram or right-click the box and select Properties.
Context Menus (right-click menus) in diagrams contain commands relevant for either the diagram generally or the object or objects currently selected.
For conceptual and usage information about specific kinds of objects, see the following topics:
Data Modeler works with one open database design, consisting of one logical model, optionally one or more relational models based on the logical model, and optionally one or more physical models based on each relational model. The database design can also include a data types model, and business information. To work on another database design, close the current design (click File, then Close), and create or import objects for the other database design.
When you save a database design, the structural information is stored in an XML file (with the extension .dmd
) in a folder or directory that you specify, and subfolders or subdirectories are created as needed under it. The .dmd
file contains pointers to information in these subfolders or subdirectories. For example, for a very basic design named my_db_design
, the following hierarchy might be created starting at the folder or directory in which you created it:
my_db_design.dmd my_db_design businessinfo datatypes subviews logical entity subviews mapping pm rdbms rel 1 subviews table
Additional subfolders or directories may be automatically created later, for example, dataflows
under pm
if you create any data flow diagrams in the process model.
Related Topics
Data Modeler supports supertypes and subtypes in its logical model, but it also provides the data types model, to be CWM compliant and to allow modeling of SQL99 structured types, which can be used in the logical model and in relational models as data types.
Structured types are supported as named user-defined composite types with the possibility of building a supertype/subtypes inheritance hierarchy. You can create and visualize structured types and the inheritance hierarchies of structured types, defining distinct and collection (array) types.
Both logical and relational models can use definitions from the data types model to specify the data type for attributes and columns or to define that a table (entity) is of a certain structured type.
You can build the data types model in one or more of the following ways:
Manually in Data Modeler
By importing from Oracle Designer repository. See Importing an Oracle Designer Model.
The data types model in Data Modeler combines two kinds of data:
One data types diagram, plus an optional set of subviews and auxiliary displays, each associated with the appropriate diagram/subview
Data type object definitions
Subviews are considered as independent diagrams of the data types model, created to represent different subject areas.
The data types model enables you to create and manage object definitions of distinct, structured, collection, and logical types.
All data type model objects (except logical types) are displayed in the object browser tree, but only structured type objects and their interrelations are represented graphically on data types diagrams.
The data types diagram contains graphical representations of structured data types and links between them, as shown in the following figure.
A structured type box contains the name of the object, its defined attributes, and its methods (if any). Diagram links represent various kinds of attributes with a structured data type.
When you are working with a complicated data types model, you may want to create subviews, with each subview describing only a section of that model. You can define several data types subviews for a single data types model, and you can assign a structured type to more than one subview. However, links (references) between two structured types are displayed on the complete data types model and only on subviews to which both types have been assigned.
There is no difference between performing changes in a subview or in the complete data types model. Any changes made are immediately reflected in the complete model and any relevant subviews. However, you can remove a structured type from a subview without deleting it from the data types model.
A user-defined distinct type is a data type derived from an existing logical type, defined in Types Administration dialog box. A distinct type shares its representation with an existing type (the source type), but is considered to be a separate and incompatible type.
A distinct type object can be accessed only in the Distinct Types subfolder of the Data Types folder.
You can create new distinct types or edit the properties of existing distinct types.
Structured types are user defined data types have attributes and methods. They also can be part of a supertype and subtype inheritance hierarchy. A structured type can be defined based on a basic data type, a distinct type, another structured type, or a reference to structured type, or it can be defined as a collection type.
A table or entity can be defined as based on a structured type. Type substitution enables you to describe (graphically on a diagram) instances of which subtypes can be accommodated by the table (entity).
Table column or entity attributes can be defined as based on a structured type, a reference to structured type, a collection type, a distinct type, and basic data types. Type substitution can be defined for a column based on a structured type, and a scope table can be defined for a column based on a reference to a structured type.
A structured type also includes a set of method specifications. Methods enable you to define behaviors for structured types. Like user-defined functions (UDFs), methods are routines that extend SQL. In the case of methods, however, the behavior is integrated solely with a particular structured type.
The expanded structured types subfolder lists all structured type objects, with the hierarchy of attributes and methods for each.
The Oracle Spatial SDO_GEOMETRY type is predefined as a structured type. In addition, you can create new structured types or edit the properties of existing structured types.
Collection types represent arrays or collections of elements (basic type, distinct type, structured type, or another collection) and are mapped to the Oracle VARRAY and nested table types.
You can create new collection types or edit the properties of existing collection types.
Logical types are not actual data types, but names that can be associated with native types or with domains. The presupplied logical types include several from Oracle Multimedia (names starting with ORD); however, ORDIMAGE_SIGNATURE is deprecated and should not be used for new definitions.
You can create logical types and edit their mappings to native types (see Types Administration), and you can associate a domain with a logical type (see Domains Administration).
Related Topics
The process model represents a functional area of an information structures system. The process model, embodied graphically in one or more data flow diagrams, is an analysis technique used to capture the flow of inputs through a system (or group of processes) to their resulting output. The model shows the flow of information through a system, which can be an existing system or a proposed system.
All necessary elements for data flow diagramming are supported in the Data Modeler process model: primitive processes, composite processes with unlimited levels of decomposition, reusable transformation tasks, triggering events, information stores, external agents, record structure for describing external data elements, source-target mapping of data elements, and CRUD (create, read, update, delete) dependencies between primitive process and data elements.
The following are important concepts for the process model:
A process is an activity or a function that is performed for some specific reason. Ultimately each process should perform only one activity.
A primitive process is a standalone process.
A composite process consists of multiple outer processes. The data flow model allows you to drill down to child processes through a composite process. This means that a top-level process can drill down to another full data flow model.
A trigger is something that happens which initiates the execution of a process.
A data flow reflects the movement of single piece of data or logical collection of information. Flows describe the sequence of a data flow diagram. (For more information, see Data Flow Diagrams.)
A data store is a collection of data that is permanently stored.
An external agent is a person, organization, or system that is external to the system but interacts with it. External agents send information to and receive information from processes.
An information store is a passive object that receives or stores information as entities and attributes in the data model. Ultimately, an information store corresponds with one or more entities of the data model.
A transformation task, including input and output parameters, is an execution unit that communicates with surrounding environment that will execute it. An input parameter might be a date for which processing should be done. An output parameter might be a code that indicates whether the operation was successful or not. Transformation itself might involve reading, transforming, and saving information, some of which may not be directly tied to the input and output parameters. (For more information, see Transformation Processes and Packages.)
A role is a set of defined privileges and permissions. Primitive processes connected to information stores (processes that create, read, update, and delete data elements) can be attached to a defined role, thus defining collaboration between roles and data elements. Later, role definitions can be transferred to any particular physical model such that appropriate database roles with defined Select, Insert, and Update permission will be created.
A formal, structured analysis approach employs the data flow diagram (DFD) to assist in the functional decomposition process. A data flow diagram consists of the following components:
External interactors, which are represented by rectangles
Data stores, which are represented by open rectangles (two or three sides)
Processes, which are represented by any rounded object (circle, oval, or square with rounded corners)
A process can represent a system function at one of various levels, from atomic through aggregate.
Data flows, which are represented by arrows, and optionally with labels indicating their content.
In a general data flow diagram, you may want to extract data from external sources and then transform the data before loading the it into the target store or database. You can build transformation packages for use with transformation processes.
For a transformation process, you need to create one or more transformation tasks in a transformation package. After you have the transformation task, you can include that in the main transformation process.
A transformation package is a package as defined in the Object Management Group (OMG) Common Warehouse Metamodel™ (CWM™) Specification, V1.1. This specification introduces transformation packages as follows:
"A key aspect of data warehousing is to extract, transform, and load data from operational resources to a data warehouse or data mart for analysis. Extraction, transformation, and loading can all be characterized as transformations. In fact, whenever data needs to be converted from one form to another in data warehousing, whether for storage, retrieval, or presentation purposes, transformations are involved. Transformation, therefore, is central to data warehousing.
"The Transformation package contains classes and associations that represent common transformation metadata used in data warehousing. It covers basic transformations among all types of data sources and targets: object-oriented, relational, record, multidimensional, XML, OLAP, and data mining.
"The Transformation package is designed to enable interchange of common metadata about transformation tools and activities."
At the core of Data Modeler is the logical model (also called the entity-relationship diagram). It provides an implementation-independent view of enterprise information and acts as the mediator that maps definitions in the dimensional and process models to different physical implementations. A logical model, or a part of it (subject area, subview), can be transformed to one or more relational models.
You can build the logical model in any of the following ways:
Manually in Data Modeler
By importing models in a VAR file, such as those created by Sterling COOL:DBA V2.1 or Sterling Bsnteam V7.2, Cayenne Bsnteam V7.2, Rational Rose, TogetherJ, JDeveloper, MEGA, or PowerDesigner v.12
By importing an existing model created by Data Modeler
By reverse engineering from an imported relational model
The logical model combines two kinds of data:
One logical diagram, plus an optional set of subviews and auxiliary displays, each associated with the appropriate diagram or subview
Logical model object definitions
Subviews are considered as independent diagrams of the logical model, created to represent different subject areas.
The logical model enables you to create and manage object definitions for entities, logical views, attributes, unique identifiers, inheritances, relations, and arcs.
All logical model objects are displayed in the object browser tree.
The logical model diagram contains graphical representations of entities, views, and links (relations and inheritances) between them.
When you are working with a complex logical model, you may want to create subviews, each describing only a section of that model. You can define several logical subviews for a single logical model, and you can assign entities and views to more than one subview. Links (relations) between two entities are displayed on the complete logical model and on logical subviews to which both referenced entities have been assigned.
There is no difference between performing changes in one of the subviews or in the complete logical model. Any changes made are immediately reflected in the complete logical model and any relevant subviews. However, you can remove entities and views from a subview without deleting them from the complete logical model.
To create a subview containing specific entities, you can select the desired entities in the logical model diagram, right-click, and select Create Subview from Selected.
Data Modeler supports the following alternatives for logical model diagramming notation:
Bachman notation
Barker notation
Detailed explanations and examples of each notation style are widely available in textbooks and on the Web. You can set the default notation type for new logical diagrams in the Data Modeler (General Options, Diagram, Logical).
To switch from one notation type to the other (and to see the differences for a diagram), select the logical model diagram and click View, then Logical Model Notation, then the notation that is not the current one.
An entity is an object or concept about which you want to store information. The structure of entity can be defined as collection of attributes or as based on structured type from the data types model. An entity may have candidate unique identifiers, one of which can be defined as primary unique identifier. Usually, an entity is mapped to table in the relational model.
A data attribute (property, data element, field) is a characteristic common to a particular entity. The data type of an attribute can be based on a logical data type, a domain, a distinct type, a collection type, or a structured type, or it can be a reference to structured type. If it a reference to a structured type, a scope entity can be defined. An attribute is mapped to a column in the relational model.
An entity unique identifier can be composed of one or more attributes. For each entity, you can define one primary unique identifier that uniquely identifies each entity occurrence. You can also specify one or more foreign unique identifiers, each of which points to (that is, must contain a value found in) a unique identifier in another entity.
Inheritance defines a hierarchy of entities based on supertypes and subtypes. The supertype and subtype entities represent part of a system that has a recognizable subset of occurrences of an existing entity type. The subsets) are referred to as entity subtypes, with the original entity type being the supertype.
All attributes and relationships of the supertype must belong to all of its subtypes. However, some attributes and relationships of the subtype are added to those of the supertype. Subtypes are usefully defined where an identifiable group of entity occurrences has attributes in addition to those of the supertype.
A relation (data relationship) is a natural association that exists between two or more entities. Cardinality defines the number of occurrences of one entity for a single occurrence of the related entity.
The relationship can be identifying or not identifying, and with a cardinality of 1:1 (one-to-one), 1:N (one-to-many), or N:M (many-to-many). A relationship with N:M cardinality is mapped to a reference table in the relational model. An identifying relationship indicates that the relationship is a component of the primary identifier for the target entity.
An arc is an exclusive relationship group, which is defined such that only one of the relationships can exist for any instance of an entity. For example, a seminar may be able to be taught by a staff member or an external consultant, but not by both. As examples, a seminar for new employees can be taught only by a corporate staff member, while a seminar in using Product XYX can be taught only by an external consultant with special qualifications.
All relations included in an arc should belong to the same entity and should have the same cardinality Any foreign unique identifier (foreign UID) attributes belonging to relationships in an arc should be transferred as Allow Nulls during forward engineering. The meaning of mandatory relationships in an arc is that only one relationship must exist for a given instance of an entity.
To create an arc, do so after creating all the relationships to be included. Select the entity box, select all relationship lines to be included (hold Shift and click each line), and click the New Arc button in the toolbar or click Object, then Logical, then New Arc.
Type substitution is a subclassing mechanism that complements inheritance. Type substitution on the entity level take place only if the following are defined:
Supertype/subtype inheritance between two structured types
Entities based on the structured types which form a data type inheritance hierarchy (supertype/subtype inheritance)
A relational model describes a database in terms of SQL tables, columns, and joins between tables. Each entity that you choose from the logical model is represented as a table in the relational model. Each row is a table represents a specific, individual occurrence of the corresponding entity. Each attribute of an entity is represented by a column in the table.
You can build a relational model in any of the following ways:
Manually in Data Modeler
By forward engineering from the logical model or a subview of the logical model
By importing models in a VAR file, such as those created by Sterling COOL:DBA V2.1 or Sterling Bsnteam V7.2, Cayenne Bsnteam V7.2, Rational Rose, TogetherJ, JDeveloper, MEGA, or PowerDesigner v.12
By importing an existing model created by Data Modeler
By importing an Oracle Designer model
By importing DDL files based on an existing database implementation
By importing from the data dictionary of a supported database type and version
A relational model combines two kinds of data:
One relational diagram, plus an optional set of subviews and auxiliary displays, each associated with the appropriate diagram or subview
Relational model object definitions
Subviews are considered as independent diagrams of the relational model, created to represent different subject areas.
A relational model enables you to create and manage object definitions for tables, views, columns, indexes, and foreign keys, and optionally to associate certain relational model objects with database schemas. A relational model can contain one or more physical models.
All relational model objects are displayed in the object browser tree.
The relational diagram contains graphical representations of tables, views, and links between them.
When you are working with a complex relational model, you may want to create subviews, each describing only a section of that model. You can define several relational subviews for a single relational model, and you can assign tables and views to more than one subview. Links (relations) between two tables are displayed on the complete relational model and on relational subviews to which both referenced tables have been assigned.
If you import from the data dictionary and select more than one schema to import, a relational model is created for all the schemas and a subview is created for each schema.
There is no difference between performing changes in one of the subviews or in the complete relational model. Any changes made are immediately reflected in the complete relational model and any relevant subviews. However, you can remove tables and views from a subview without deleting them from the complete relational model.
A table is an object in which you want to store information. The structure of table can be defined as a group of columns or as based on structured type from data types model. A table may have candidate keys, one of which can be defined as primary key. Usually, a table is mapped to entity from the logical model.
A table column is a characteristic common to a particular table. The data type of a column can be based on a logical data type, a domain, a distinct type, a collection type, or a structured type, or it can be a reference to structured type. If it is a reference to a structured type, a scope table can be defined. Usually, the columns in a table are mapped to the attributes of the corresponding entity from the logical model.
An index is an object that consists of an ordered set of pointers to rows in a base table. Each index is based on the values of data in one or more table columns. Defining indexes on frequently searched columns can improve the performance of database applications.
A relation (data relationship) is a natural association that exists between two or more tables. Relationships are expressed in the data values of the primary and foreign keys. Cardinality defines the number of occurrences in one table for a single occurrence in the related table.
An identifying relationship indicates that the relationship is a component of the primary identifier for the target table.
An exclusive relationship (arc) specifies that only one of the relationships can exist for a given instance in the table. For example, a seminar may be able to be taught by a staff member or an external consultant, but not by both. As examples, a seminar for new employees can be taught only by a corporate staff member, while a seminar in using Product XYX can be taught only by an external consultant with special qualifications.
All relationships in an arc should belong to the same table, and should have the same cardinality. Any foreign key (FK) attributes belonging to relationships in an arc should be transferred as Allow Nulls during forward engineering. The meaning of mandatory relationships in an arc is that only one relationship must exist for a given instance in the table.
To create an arc, do so after creating all the relationships to be included. Select the table box, select all relationship lines to be included (hold Shift and click each line), and click the New Arc button in the toolbar or click Object, then Relational, then New Arc.
A physical model describes a database in terms of Oracle Database objects (tables, views, triggers, and so on) that are based on a relational model. Each relational model can have one or more physical models. The following shows a database design hierarchy with several relational and physical models:
Database design Logical model Relational model 1 Physical model 1a Physical model 1b . . . (other physical models) Relational model 2 Physical model 2a Physical model 2b . . . (other physical models) . . . (other relational models)
Each physical model is based on an RDBMS site object. An RDBMS site is a name associated with a type of database supported by Data Modeler. Several RDBMS sites are predefined (for example, for Oracle 11g and Microsoft SQL Server 2005). You can also use the RDBMS Site Editor dialog box to create user-defined RDBMS sites as aliases for supported types of databases; for example, you might create sites named Test and Production, so that you will be able to generate different physical models and then modify them.
When you export to a DDL file, you specify the physical model to be applied. The generated DDL statements include clauses and keywords appropriate for features specified in that physical model (for example, partitioning for one or more tables).
Physical models do not have graphical representation in the work area; instead, they are displayed in the object browser hierarchy. To create and manage objects in the physical model, use the Physical menu or the context (right-click) menu in the object browser.
The rest of this topic briefly describes various Oracle Database objects, listed in alphabetical order (not the order in which they may appear in an Oracle physical model display).
A cluster is a schema object that contains data from one or more tables.
An index cluster must contain more than one cluster, and all of the tables in the cluster have one or more columns in common. Oracle Database stores together all the rows from all the tables that share the same cluster key.
In a hash cluster, which can contain one or more tables, Oracle Database stores together rows that have the same hash key value.
A context is a set of application-defined attributes that validates and secures an application.
A dimension defines a parent-child relationship between pairs of column sets, where all the columns of a column set must come from the same table. However, columns in one column set (called a level) can come from a different table than columns in another set. The optimizer uses these relationships with materialized views to perform query rewrite. The SQL Access Advisor uses these relationships to recommend creation of specific materialized views.
A directory is an alias for a directory (called a folder on Windows systems) on the server file system where external binary file LOBs (BFILEs) and external table data are located.
You can use directory names when referring to BFILEs in your PL/SQL code and OCI calls, rather than hard coding the operating system path name, for management flexibility. All directories are created in a single namespace and are not owned by an individual schema. You can secure access to the BFILEs stored within the directory structure by granting object privileges on the directories to specific users.
A disk group is a group of disks that Oracle Database manages as a logical unit, evenly spreading each file across the disks to balance I/O. Oracle Database also automatically distributes database files across all available disks in disk groups and rebalances storage automatically whenever the storage configuration changes.
An external table lets you access data in an external source as if it were in a table in the database. To use external tables, you must have some knowledge of the file format and record format of the data files on your platform.
An index is a database object that contains an entry for each value that appears in the indexed column(s) of the table or cluster and provides direct, fast access to rows. Indexes are automatically created on primary key columns; however, you must create indexes on other columns to gain the benefits of indexing.
A role is a set of privileges that can be granted to users or to other roles. You can use roles to administer database privileges. You can add privileges to a role and then grant the role to a user. The user can then enable the role and exercise the privileges granted by the role.
A rollback segment is an object that Oracle Database uses to store data necessary to reverse, or undo, changes made by transactions. Note, however, that Oracle strongly recommends that you run your database in automatic undo management mode instead of using rollback segments. Do not use rollback segments unless you must do so for compatibility with earlier versions of Oracle Database. See Oracle Database Administrator's Guide for information about automatic undo management.
A segment is a set of extents that contains all the data for a logical storage structure within a tablespace. For example, Oracle Database allocates one or more extents to form the data segment for a table. The database also allocates one or more extents to form the index segment for a table.
A sequence is an object used to generate unique integers. You can use sequences to automatically generate primary key values.
A snapshot is a set of historical data for specific time periods that is used for performance comparisons by the Automatic Database Diagnostic Monitor (ADDM). By default, Oracle Database automatically generates snapshots of the performance data and retains the statistics in the workload repository. You can also manually create snapshots, but this is usually not necessary. The data in the snapshot interval is then analyzed by ADDM. For information about ADDM, see Oracle Database Performance Tuning Guide.
A stored procedure is a schema object that consists of a set of SQL statements and other PL/SQL constructs, grouped together, stored in the database, and run as a unit to solve a specific problem or perform a set of related tasks.
A synonym provides an alternative name for a table, view, sequence, procedure, stored function, package, user-defined object type, or other synonym. Synonyms can be public (available to all database users) or private only to the database user that owns the synonym).
A structured type is a non-simple data type that associates a fixed set of properties with the values that can be used in a column of a table. These properties cause Oracle Database to treat values of one data type differently from values of another data type. Most data types are supplied by Oracle, although users can create data types.
A table is used to hold data. Each table typically has multiple columns that describe attributes of the database entity associated with the table, and each column has an associated data type. You can choose from many table creation options and table organizations (such as partitioned tables, index-organized tables, and external tables), to meet a variety of enterprise needs.
A tablespace is an allocation of space in the database that can contain schema objects.
A permanent tablespace contains persistent schema objects. Objects in permanent tablespaces are stored in data files.
An undo tablespace is a type of permanent tablespace used by Oracle Database to manage undo data if you are running your database in automatic undo management mode. Oracle strongly recommends that you use automatic undo management mode rather than using rollback segments for undo.
A temporary tablespace contains schema objects only for the duration of a session. Objects in temporary tablespaces are stored in temp files.
A database user is an account through which you can log in to the database. (A database user is a database object; it is distinct from any human user of the database or of an application that accesses the database.) Each database user has a database schema with the same name as the user.
Business information objects define business-oriented information about model objects, such as responsible parties and information about how to contact them, and identification of relevant offline documentation.
A model object can have zero or more business information objects associated with it, and a business information object can be associated with zero or more model objects. For example, a single document can be used to describe many different entities and attributes, or a single person can be the responsible party for multiple events.
There can also be many-to-many relationships among business objects. For example, a responsible party can have multiple sets of contact information (contact objects), and a contact object can be associated with multiple responsible parties. Similarly, one or more telephone, e-mail, location, and URL objects can be associated with multiple contact objects.
The Data Modeler business information model is based on the Object Management Group (OMG) business information package, which is described in the OMG Common Warehouse Metamodel™ (CWM™) Specification, V1.1 as follows: "The Business Information Metamodel provides general purpose services available to all CWM packages for defining business-oriented information about model elements. The business-oriented services described here are designed to support the needs of data warehousing and business intelligence systems; they are not intended as a complete representation of general purpose business intelligence metamodel. Business Information Metamodel services support the notions of responsible parties and information about how to contact them, identification of off-line documentation and support for general-purpose descriptive information."
The rest of this topic briefly describes business information objects, listed in alphabetical order (not the order in which they appear in the object browser under Business Information).
A contact object groups the various types of related contact information. Each contact object can be associated with multiple email, location, URL, and telephone objects. Conversely, each email, location, URL, and telephone object can be associated with many contact objects. (See also Contact Properties.)
A document object represents externally stored descriptive information about some aspects of the modeled system. A document object can be associated with one or more model objects. (See also Document Properties.)
An email object identifies a single electronic mail address. Through the use of a contact object, you can associate an email address with one or more responsible parties. The sequence of email objects for a contact might be used to represent the order in which to try email addresses in attempting to communicate with a contact. (See also Email Properties.)
A location object identifies a single physical location. Through the use of a contact object, you can associate a location with one or more responsible parties. The sequence of contact objects for a location might be used to represent the order in which to try contacting a person or group associated with a location. (See also Location Properties.)
A resource locator object provides a general means for describing a resource whose location is not defined by a traditional mailing address. For example, a resource locator could refer to anything from a Web address (such as "www.example.com") to a location within a building (such as “Room 317, third file cabinet, 2nd drawer”). (See also Resource Locator Properties.)
A responsible party object represents a person, role, or organization that has a responsibility for, or should receive information about, one or more model objects. The precise meaning of the "responsibility" of a responsible object depends on the specific system being implemented. (See also Responsible Party Properties.)
A telephone object represents telephone contact information. A telephone object can be associated with one or more contacts. (See also Telephone Properties.)
Related Topics