Data Model Dictionary

This is your dictionary!

If you find any errors, or want to add some more terms, please email me (Mike, your friendly neighborhood webmaster). I want this area to be of use to you.
Oh, and I am developing a data-driven dictionary, so stay tuned.

ABIE - Aggregate Business Information Entity
Derived from UBL. See also BBIE

Aggregation - Technique that optimizes data retrieval by summarizing rows of a fact table according to a specific dimension.

Alternate Key - Column or combination of columns, not the primary key columns, whose values uniquely identify a row in a table.

***OBSOLETE***

In addition to providing generation support for the industry leading development tools, AppModeler also generates dynamic, data-driven web sites based on a PDM. With AppModeler’s included Sybase PowerDynamo application server, designers, developers, and web masters alike can dynamically publish their database for use on the Internet/Intranet without any coding required. AppModeler generates the necessary Dynamo templates that link users to data sources directly from a web browser environment. Simply reverse engineer an existing database into a physical data model, or use an existing one. Identify your web server and the data source for storing the dynamic templates, and AppModeler instantly generates web pages including QBE (query-by-example), tabular, and free from presentation style pages. In addition, hyperlinks are generated allowing users to "drill-down" into their data for further, detailed analysis.

ASBIE - Association Business Information Entity
Derived from UBL. See also BBIE

Attribute (CDM) - An attribute is a Data Item that has been "attached" to an Entity. By doing this, a distinction can be made between the generic characteristics of the data item itself (for instance, data type and default documentation) and the entity-specific characteristics (for example, identifying and entity-specific documentation).

Attribute (WAM) - An attribute is an object that qualifies a dimension. For example, Year is an attribute of the Date dimension. Attributes are usually attached to columns in a dimension table. For example, the Month attribute is attached to the Month column in the Time dimension table. Attributes can also be attached to facts, for example in a matrix schema.

BPEL4WS - Business Process Execution Language for Web Services
http://xml.coverpages.org/ni2002-08-12-a.html

Business Rule - Specific business-related information that is linked to database objects. The information can be in the form of business facts or descriptions, or it might be formula or algorithms either client-based or destined for the server. Once defined, business rules can be applied through the database or application code generation.

Business Rule - Definition Type - Characteristics or properties of an object in the information system. For example, a customer is a person identified by a name and an address.

Business Rule - Fact Type - Certainty or existence in the information system. For example, a client may place one or more orders.

Business Rule - Formula Type - Calculation employed in the information system. For example, the total order is the sum of all the order line costs.

Business Rule - Validation Type - Constraint on a value in the information system. For example, the sum of the order totals for a given client must not be greater than that client's allowance.

Cardinality - Cardinality indicates the number of instances (one or many) of an entity in relation to another entity. You can select the following values for cardinality:

Column - Data structure that contains an individual data item within a row (record), model equivalent of a database field.

Conceptual Data Model (CDM) - A CDM represents the overall logical structure of a database, which is independent of any software or data storage structure. A conceptual model often contains data objects not yet implemented in the physical databases. It gives a formal representation of the data needed to run an enterprise or a business activity.

Data Item - A data item is an elementary piece of information in the data dictionary.

Data Store - A data store in a PAM represents a place to put information, either temporarily from process to process, or permanently as a final or finished result of a process.

Data Warehouse - Database that receives data from heterogeneous On-Line Transaction Processing (OLTP) systems and organises it for extraction by On-Line Analytical Processing (OLAP) systems.

DataArchitect - DataArchitect provides traditional data modeling capabilities, including database design, generation, maintenance, reverse-engineering and documentation for database architects. It enables database designers to create flexible, efficient and effective data structures for use by an application's database engine (DBMS).

DataArchitect offers conceptual data model design, automatic physical data model generation, denormalized physical design, multiple database management system (DBMS) and development tool support, and presentation-quality reporting features. Using its reverse engineering capabilities, a designer can obtain a "blueprint" of a database's structure to document and maintain the database or migrate to a different DBMS. These features ensure an optimal database structure for developing large, complex applications.

Database Definition Language (DDL) - This is the syntax that a given DBMS understands and is used to manipulate the structure of the database, from initial database creation to additions, modifications and deletions of all database objects (tables, columns, indexes, etc.) to the eventual removal of the database. Another term used for DDL is "schema". Because each DBMS is slightly different, the DDL statements that each use is also different, sometimes completely alien to each other.

Database Management System (DBMS) - A DBMS contains and controls information in some structured form so that it can be accessed in an efficient manner. Most DBMSs support some form of SQL as the primary access method.

Datamodel - It would be remiss to have a datamodel web site and never define what a datamodel is. Basically, a datamodel is any method of visualizing the informational needs of a system and typically takes the form of an ERD (Entity Relationship Diagram). PowerDesigner implements conceptual (CDM) and physical (PDM) datamodels.

Datatype (CDM) - Identifies the kind of data that a Data Item represents. These are conceptual representations, not tied to any specific DBMS. The list that follows are just a few examples of Conceptual datatypes:

Datatype (PDM) - Identifies the kind of information that a column in a table on a specific database platform represents. These are actual physical representations and are dependent on the actual DBMS. Some examples might be:

Because each database is different, PowerDesigner has internal tables that map each physical datatype to and from each conceptual datatype.

Dimension - Defines the axis of investigation of a fact. Is attached to a dimension table.

Dimension Hierarchy - Dimension that is split into other more detailed dimensions. Each descending level in a dimension hierarchy corresponds to a finer level of detail. The number of levels in a dimension hierarchy corresponds to the available levels of granularity in a query.

Dimension Table - A dimension table stores data related to the axis of investigation of a fact. For example, geography, time, product. A WAM can have any number of dimension tables. Dimension tables are connected to a central fact table. The primary key in the dimension table migrates as a foreign key in the fact table. Dimension tables can also be connected to other dimension tables to form a hierarchy of dimensions.

Domain - A way of identifying and grouping the types of data items in the model. This makes it easier to standardize data characteristics for attributes/columns in different entities/tables. Some DBMSs will implement domains as "User Defined Datatypes". Another feature of domains is in the maintenance of similar columns. If all "name" columns (LastName, CityName, ProductName, etc.) are defined as a common domain, then changing the datatype from char(40) to char(50) is a one-step procedure, rather than having to visit each table and search for the correct columns.

Entity - Person, place, thing, or concept that has characteristics of interest to the enterprise and about which you want to store information.

External Entity - In a PAM, external entities refer to action agents (or actors, to borrow from object oriented programming) that interact with the processes directly.

Fact - A fact corresponds to the focus of a decision support investigation, for example, Sales, Revenue, and Budget are facts. You attach facts to fact tables. When you create a fact table, a fact with the same name as the table is automatically created.

Fact Table - A fact table stores variable numerical values related to aspects of a business. For example, sales, revenue, budget. These are usually the values you want to obtain when you carry out a decision support investigation. A fact table is at the intersection of dimension tables in a star schema.

A WAM can have a number of central fact tables linked to any number of dimension tables. The fact tables are usually the first tables you create when you create a WAM. Any other fact tables in the WAM are usually generated automatically as a result of aggregating or partitioning the central fact table. These fact tables form a hierarchy of facts. A fact table is attached to a fact. When you create a fact table, WarehouseArchitect automatically creates a fact with the same name and attaches it to the table.

FastProjection - Column will be projected (used in a SELECT) and return hundreds and thousands of rows. See LowFast. Column will be used with the LIKE keyword and has a '%' wildcard prefix, for example WHERE column LIKE '%ing'.

Foreign Key - Column or combination of columns whose values are required to match a primary key in some other table.

HighGroup - Column has a high number (1,001 to infinity) of unique values. Column is part of a join field. You need maximum query speed. Column is used in a GROUP BY clause, argument of a COUNT(DISTINCT), or in the select list of a SELECT DISTINCT. See HighNonGroup.

HighNonGroup - Column has a high number of unique values, but does not fall into the HIGHGROUP categories. Column is a subset of the HIGHGROUP index. See FastProjection.

Identifier - In a CDM, this uniquely identifies an occurrence of an entity. Identifiers relate to primary keys and unique indexes in the PDM.

Identifying Relationship - An identifying relationship is a relationship between two entities in which an instance of a child entity is identified through its association with a parent entity, which means the child entity is dependent on the parent entity for its identify and cannot exist without it. In an identifying relationship, one instance of the parent entity is related to multiple instances of the child.
See Non-Identifying Relationship

Index - An index is a data structure associated with a table that is logically ordered by the values of a key. It improves database performance and access speed.

You normally create indexes for columns that you access regularly, and where response time is important. Indexes are most effective when they are used on columns that contain mostly unique values.

IndexSet - An IndexSet is the Sybase IQ equivalent of a table. An IndexSet has columns but doesn't contain any data.

Inheritance - Inheritance allows you to define an entity as a special case of a more general entity. The entities involved in an inheritance have many similar characteristics but are nonetheless different. The general entity is known as a supertype (or parent) entity and contains all of the common characteristics. The special case entity is known as a subtype (or child), entity and contains all of the particular characteristics.

Between entities, it is also possible to define an inheritance link. In an inheritance link, one or more subtype (or child) entities inherit, at the physical level, all or part of the attributes carried by one supertype (or parent) entity.

Joined Indexset - A joined indexset is a set of join relationships.
Sybase IQ uses joined indexsets to speed up queries.
You can define joined indexsets in two ways:

WarehouseArchitect automatically creates Joined Indexsets for fact indexsets. Each automatically generated joined indexset consists of the join relationships that link the fact indexset to the dimension indexsets.

Join Relationship - A join relationship is a predefined join between two indexsets. It links a column in one indexset to a column in another. You create join relationships when you know that the underlying tables in the Sybase SQL Server workspace are typically joined in a consistent way. You can define join relationships in two ways:

Logical Data Model (LDM) - A LDM fills in the gap between a conceptual (CDM) and physical (PDM) datamodel. CDMs are completely devoid of database-level information while PDMs are specific to a certain DBMS. Since there are characteristics of databases that are generic in nature (such as indexes and foreign keys), a LDM stores those characteristics without adding anything specific to a single DBMS.

LowFast - Column has a low number of unique values (1-1,000). Column is part of a join field. See LowDisk.

LowDisk - (Sybase IQ version 11.0 only) Disk space required for a LowFast index is excessive. See HighGroup.

MetaData - "Information about Data". This is the documentation stored in the datamodel about the information system. For instance, a table in a database could have a length business description. The description is metadata about the data in the database.

MetaMetaData - "Information about the MetaData". This is a level of abstration above a datamodel, usually used to transfer metadata between design tools or methodologies. Examples of this are can be found at CDIF and UML.

MetaWorks - MetaWorks is a system designed to provide the PowerDesigner graphical modules (DataArchitect, ProcessAnalyst, WarehouseArchitect, and AppModeler) with the ability to share and store data models in a single point of control, the MetaWorks Dictionary.

MetaWorks runs on the PC and stores data models on a DBMS, which can be Sybase SQL Anywhere (shipping with the PowerDesigner toolset) or any of the market-leading database servers including Sybase, Oracle, Informix, DB2, MS SQL Server and CA OpenIngres.

MetaWorks provides three essential functions: Data Model and Submodel Extraction/Consolidation, Project (or Dictionary) Management, and Environment Administration.

Metric - A metric is a variable or measure that corresponds to the focus of an investigation. Metrics are typically numeric values. For example, Total and Price are metrics. A metric can be the result of an operation or calculation involving several columns of the fact table. Metrics are attached to columns in a fact table. For example, the Sales Total metric is attached to the Sales Total column in the Sales fact table.

Non-Identifying Relationship - A non-identifying relationship is a relationship between two entities in which an instance of the child entity is NOT identified through its association with a parent entity, which means the child entity is NOT dependent on the parent entity for its identify and can exist without it. In a non-identifying relationship, one instance of the parent entity is related to multiple instances of the child.
See Identifying Relationship

Open DataBase Connectivity (ODBC) - An interface that gives PowerDesigner (and other user tools) access to data contained in various DBMSs. Most ODBC drivers are 3rd party products provided for specific database engines or for specific platforms. Because of the variety in drivers, performance and reliability between drivers is inconsistent. But, for the most part, they provide an interface so that tools can access many databases without having to "reinvent the wheel" for each one.

Object Oriented Analysis & Design (OOA&D) - This is a methodology for application development centered around the UML notation standard, developed by Rational Software. The methodology centers around Class, Use Case, Sequence, Activity and Component diagrams.

Object Oriented Design using Prototype Methodology (OODPM) - is a system planning and design method that integrates the two approaches contained in its title.

OODPM focuses primarily on system planning, but also addresses the business specification stage. According to this approach, user needs to be implemented in the future system must be studied, but time must also be dedicated to studying the current situation in order to complete the requirements definition. Experience has shown that users tends to focus on those needs that have not been met by the current system, and tend to ignore the parts of the system that have met their needs. Without a stage to examine the current situation, only partial definition of the requirements is likely to achieved.

In sum, with OODPM, the system analysis and planning process begins with a study of the current situation, but with a view to identifying the needs, rather than the study for its own sake. This means that a defined period of system planning time, proportional to the overall process, is assigned to the study of the current situation. This process ends with the business specifications, or as it is usually called, the business specifications for the new system.

System planning with OODPM is done by defining the activities required for the system. A system activity is defined as a collection of data and processes that deal with a defined subject and are closely linked. Data affiliated with a particular process should be collated in a natural manner; however, should there be tens of data pertaining to a specific process, secondary definition of sub-processes is desirable. One can also add to the activity definition the requirement that the user, on a single screen, process the data in a single, continuous action in a single sequence. A collection of user activities in a particular area with the relationships between them defines an information system. (Some of these user activities may be manual.)

Physical Data Model (PDM) - The PDM specifies the physical implementation of the database. With the PDM, you consider the details of actual physical implementation. It takes into account both software or data storage structures. You can modify the PDM to suit your performance or physical constraints.

Primary Key - Column or combination of columns whose values uniquely identify a row in a table.

Process - A process represents a transformation of data. For example, in a model about the publication of books, selecting a manuscript is a process. Data is sent to the selection process in the form of a manuscript. During selection, the manuscript is transformed either into a manuscript that goes directly to the printer, or into a manuscript that must wait before it is printed.

ProcessAnalyst - To create client/server and Web-based databases and applications, the first recommended step is to discover all the data elements involved in a particular business process. This can be performed using PowerDesigner’s ProcessAnalyst. ProcessAnalyst offers an elegant first step for complex database and application projects. It is the "data discovery" tool where the data flows of the business are captured.

ProcessAnalyst allows designers of complex client/server applications to depict a general description of processes and data flows in a particular business process to gain a comprehensive understanding of its organization. Data flow diagrams are one of the most common methods used to perform data discovery. They show the underlying logical essence of the information system and are highly meaningful to the business analyst. The ProcessAnalyst model describes the computations of data (or value) within a system without regards to when and why the values are computed.

ProcessAnalyst Model (PAM) - The PAM describes the flow of information through a business system. In essence, this is a road map of the possible informational routes, not a sequencing diagram.

Project - In PowerDesginer, all models (CDM, PAM, PDM or WAM) are grouped together into user-defined projects. Projects do not "share" objects at any level. This means that to have a model exist in two projects, there will be two copies of the model.

Query By Example (QBE) - The QBE concept is to direct queries by giving examples of what is to be found. In MetaSite, the standard QBE interface has been merged with standard SQL syntax to give the user more flexibility. For instance, MetaSite supports the "BETWEEN" clause which is standard SQL, but is not QBE.

Recursive Referential Integrity - See Referential Integrity first. One special type of "RI" involves just a single table, tied back to itself. A set of columns is set up as the foreign key, referencing the primary key column(s), but of another record. In this manner, a hierarchy can be created within the table.

For example, an Employee table would typically have EmployeeID as the primary key. Since the employee's manager is typically also an employee, a ManagerID column would point to the employee's manager's record. Furthermore, that manager would have a manager, on up to the president of the company, whose ManagerID would simply be left NULL, or point back to his/her record. The following table demonstrates this:

EmpID	MgrID	Name	Title
1	1	John Smith	President
2	1	Joseph Barnaby	CIO
3	1	Mary Johnson	CFO
4	2	Mark Smithson	Development Manager
5	2	Jerry McGuire	Operations Manager
6	3	Jane Doe	Comptroller
7	3	Michelle Long	Payroll Director

Note: There are 3 distinct tiers in the above table, John has the only record with no parent. Joseph and Mary are in the second layer, being direct reports to John. All other records are underneath those two.

Important Note: There is a serious problem with this design. It looks great, elegant, and simple in the design phase, and even the business users will love it. However, it doesn't reflect real life very well. For instance, what if Mary quits, and it takes 2 months to replace her? You can't delete her record, (ON DELETE RESTRICT is required here. ON DELETE CASCADE would be a terrible mistake, because deleting one employee record could cause many records to be accidentally removed.) so have to go through some strange manipulations to keep the integrity of the table. This structure also doesn't allow historical information to be tracked about previous managers, nor does it allow "dotted line" relationships between employees.

Referential Integrity - Referential integrity refers to rules governing data consistency, specifically the interaction between primary keys and foreign keys in different tables. Referential integrity dictates what happens when you update or delete a value in a referenced column in the parent table and when you delete a row containing a referenced column from the parent table.

Referential integrity as a generation option For certain target databases you can define referential integrity as a generation option. However many databases do not accept referential integrity as a generation option (in a trigger or a declaration). In these cases, when you generate a database generation script, it does not include the definition of referential integrity.

Relationship - A relationship is a named connection or association between entities. For example, in a CDM that manages human resources, the relationship Member links the entities Employee and Team, because employees can be members of teams. This relationship expresses that each employee works in a team and that each team has employees.

An occurrence of a relationship corresponds to one instance of each of the two entities involved in the relationship. For example, the employee Martin working in the Marketing team is one occurrence of the relationship Member.

Reverse Engineering - Reverse engineering is the act of reading existing database information (either from DDL scripts or from ODBC sources)

Schema - Another term for DDL. A distinction between the terms is that DDL is usually reserved to the structure of the database, while schemas might include scripts to load data into the structures or assign security permissions to users.

Segment - A segment is the part of a data flow that enters or leaves a split/merge. Each segment is a data flow with its own properties and number in the order of object creation.

Split/Merge - A split/merge is an object that either splits a data flow into several data flows so that it can send data to different destinations, or merges data flows from different sources into one data flow. A split/merge that sends data to several destinations has a single incoming flow and multiple outgoing flows. A split/merge that joins data flows from different sources has multiple incoming flows and a single outgoing flow.

The flows going into and coming out of the split/merge are called primary and secondary flows. The primary flow is the single flow that enters or leaves the split/merge. It can be unidirectional or bidirectional. A secondary flow is one of the multiple flows entering or leaving the split/merge. Secondary flows are unidirectional. Primary and secondary flows are collectively called segments.

Structured Query Language (SQL) - SQL is a language used to communicate with a DBMS and provides a fairly common syntax for applications to use.

Stored Procedure - A stored procedure is SQL code placed in a special area inside the DBMS, therefore each platform has a slightly (or greatly) different way of treating them. In some cases, stored procedures are treated very much like tables masking much of the internal logic from the client application. Triggers are specialized stored procedures.

Sub-Type (Entity) - An entity involved in an inheritance relationship with a parent Super-Type. The resulting table can inherit certain attributes from the parent or be consolidated, along with other sub-types, into the parent table.

For example, an entity called Account for a banking system might have several sub-types for each type of account, such as Checking, Savings, Credit, Loan, etc. There are common Account attributes for each type of account which are placed in the Account entity. In each sub-type are placed specific attributes to that type.
The resulting table structures could be an Account table with dominant 1:1 relationships to the four dependent tables.

Subject Area - A subject area is a summary of things in which the enterprise is interested. It corresponds to a collection of information related to a high level function.
In a conceptual model, subject areas typically define the limits between systems, or areas of interest within the company. For instance, the Employee Subject Area could contain all entities and data items related to employees.

Super-Type (Entity) - An entity involved in an inheritance relationship with one or more Sub-Types. The key attributes or all attributes from this entity can be inherited to each of the sub-types, or the sub-type attributes can be consolidated into the resulting parent table. See the example above.

Trigger - A trigger is a special form of stored procedure that goes into effect when you insert, delete, or update a specified table or column. You can use triggers to enforce referential integrity. Referential integrity triggers exist for certain databases, such as Sybase and Oracle.

Unified Modeling Language (UML) - This is a modeling language created by the Rational Software company to implement the OOA&D methodology.
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

View - Data structure that results from an SQL query and that is built from data in one or more tables.

Viewer - Viewer provides read-only, graphical access to PowerDesigner modeling and metadata information. It delivers read-only access to process, conceptual, physical, and warehouse models as well as a MetaBrowser for viewing across all object types in the central database dictionary. In addition to providing a graphical view into the modeling information, Viewer provides full reporting and documenting capabilities across all models.

WarehouseArchitect - A Data Warehouse (DW) is a subject-oriented information system specifically designed for decision support. A DW environment organizes and provides information in a way that business users best understand. From a data modeling perspective, a DW is an infrastructure that manages the flow of information, from source to delivery. The source is the operational information contained in various database systems, programs stored in flat files, or external sources such as the Internet. The delivery is provided by end-user tools generally installed on a PC. You use these tools to enter business queries that the DW environment processes. You get answers to those queries in easy-to-read forms and graphical reports.

WarehouseArchitect supports all three DW layers in terms of data modeling, metadata and data import, and interfaces with the various third-party tools that have an active part in the DW environment.

WarehouseArchitect Model (WAM) - The WAM contains all necessary graphic and textual information to describe a Data Warehouse environment.

Visitors on this page: [an error occurred while processing this directive]
Last Updated: [an error occurred while processing this directive]