A physical data model is a design schema for information assets that defines the physical structures and relationships of data within a subject domain or application. Physical data models are independent of implementation or platform details.
Physical data models are typically generated from logical data models by using modeling tools, although they can be reverse-engineered from existing databases. Physical data models represent designs for storing data, unlike implemented data resources, which represent actual databases and data files. A physical data model can implement multiple logical data models and can be implemented by multiple database schemas and data files.
You can use bridges to import physical data models from design tools such as IBM® InfoSphere® Data Architect and CA ERwin Data Modeler. When you import a physical data model by using a bridge, you can choose to create a corresponding database schema that implements the physical data model. The database schema is saved in the metadata repository for use in InfoSphere DataStage® and QualityStage® jobs. To create a database schema from a physical data model, you must install prerequisite software that is listed in this technote: http://www.ibm.com/support/docview.wss?uid=swg27038230.
You can use InfoSphere Metadata Asset Manager to set implementation relationships between logical data models, physical data models, database schemas, data files, and their contained assets.
Asset type | Definition | Components of the identity of the asset | Contained asset types |
---|---|---|---|
Physical data model | A design schema for information assets that defines the physical structures and relationships of data within a subject domain or application. A physical data model can implement a logical data model and can be implemented by a database schema or a data file. |
|
Design table, design stored procedure, and physical domain |
Design table | An asset that represents a table structure in the physical data model. The design table defines the design column, the design candidate key, and the design foreign key. A design table can implement a logical entity and can be implemented by a database table or data file structure. |
|
Design column, design candidate key, and design foreign key |
Design column | A relevant property or characteristic of a design table that defines the meaning and purpose of a unit of data. A design column can implement an entity attribute and can be implemented by a database column or a data file field. |
|
|
Design candidate key | A unique semantic identifier that defines the identity constraint of a design table. |
|
|
Design foreign key | A non-unique identifier that defines a relationship between two design tables. |
|
|
Design stored procedure | An asset that represents the stored procedure structure in the physical data model. The design stored procedure also defines the design stored procedure parameters. A design stored procedure can be implemented by a stored procedure. |
|
Design stored procedure parameter |
Design stored procedure parameter | A parameter that is used by a design stored procedure. |
|
|
Physical domain | A user-defined data type or global attribute that can be reused in multiple design tables. A physical domain can implement a logical domain and can be implemented by a database domain. |
|
Physical domain field |
Physical domain field | A data field that is contained by a physical domain. For example a domain named address might contain fields for number and street. |
|