Objects in a PDM

Previous  Top  Next

The following items are available in a PDM:

 

Object

Tool

Description

Domain

-

A subset of possible data values of a specific datatype.

Table

A tabular structure used to store data.

Column

-

A placeholder for a value (piece of data) in a table.

Primary Key

-

A column or combination of columns whose values uniquely identify a row of data in a table.

View

A server side resultset that can be used as a table, a "virtual table", if you like.

Referential Link

A constraint that tells the database system to ensure a row of data exists in a "master" table for a specific row in a "detail" table, eg: each "order line" should belong to a specific "order".

 

See also: Objects in any Diagram.

 

 

Domain

Domains make it easier to identify the types of information in your model, assigning domains to columns help you standardize data characteristics for columns in different tables. This is the same as Domains in a CDM.

 

Just like a "column" of an Table, each Domain has a datatype. In addition to that, each domain can have a check constraint to create subsets of the available values for a datatype and can have a specified maximum length or precision and a scale. This makes the possible values in a "domain" a sub-set of the available values for a given datatype. Domains can be used as the "datatype" of a column instead of a raw datatype.

 

Domains are not visible in the diagram itself, but are visible in the Diagram Explorer.

 

See also:

Datatypes in a PDM

 

Back to Top

 

 

Table

A table is the structure that's used to physically store your data into "rows" of "records" of data. A single combined piece of information on each row. Each row should be uniquely identifiable by using the values in the primary key columns.

 

In the ideal case, your stored data should not contain NULLs (as this is missing information) but should only contain valid data instead.

 

Tables and Views can be used as the basis for Views and SQL SELECT statements to return data.

 

See also: Creating a Table

 

Back to Top

 

 

View

A view is like a virtual table. A SQL statement defines the view and it's resultset columns, it does not store the data, but offers a resultset that can be used in other views and SQL statements just like a table.

 

By using views, you can keep your applications SQL statement much more simple, hide data from tables or hide columns from tables before making them available to application developers.

 

See also: Creating a View

 

Back to Top

 

 

Referential Link or Foreign Key Constraint

A "referential link", "foreign key constraint" or "referential constraint" are all the same thing. For a database systems that support them, it will create a foreign key constraint object in order to have the database system check that your referring table won't be referring to non-existing referred-to data.

 

For example, let's imagine the following:

 

CREATE TABLE PERSON

(

PERSONID INTEGER NOT NULL PRIMARY KEY,

FIRST_NAME VARCHAR(50) NOT NULL,

LAST_NAME VARCHAR(50) NOT NULL,

SEX CHAR(1) CHECK (SEX IN ('M', 'F') )

);

 

CREATE TABLE IS_CHILD_OF

(

    CHILD_PERSON_ID INTEGER NOT NULL,

    PARENT_PERSON_ID INTEGER NOT NULL,

    PRIMARY KEY (CHILD_PERSON_ID, PARENT_PERSON_ID)

);

A master-detail relationship between a person and his or her children, no constraints

 

You can create two constraints ensuring that table IS_CHILD_OF contains data that exists in table PERSON.

 

ALTER TABLE IS_CHILD_OF ADD CONSTRAINT FK_IS_CHILD_OF_PERSON_PARENT 

  FOREIGN KEY (PARENT_PERSON_ID) REFERENCES PERSON

  (PERSONID);

 

ALTER TABLE IS_CHILD_OF ADD CONSTRAINT FK_IS_CHILD_OF_PERSON_CHILD 

  FOREIGN KEY (CHILD_PERSON_ID) REFERENCES PERSON

  (PERSONID);

Two referential constraints

 

In a diagram, this could look like this:

The graphical version of the above foreign key constraints

 

See also: Creating a Foreign Key Constraint

 

Back to Top

 

 

Next: Datatypes in a PDM