Logical Data Model (LDM)

Source: Wikipedia: Logical Data Model

Logical data model

From Wikipedia, the free encyclopedia
Jump to: navigation, search

A logical data model (LDM) in systems engineering is a representation of an organization's data, organized in terms entities and relationships and is independent of any particular data management technology.

* 1 Overview
* 2 History
* 3 Logical data model topics
o 3.1 Why Build Logical Data Model
o 3.2 Logical Modeling Benefits
o 3.3 Logical & Physical Data Model
* 4 See also
* 5 References
* 6 External links

[edit] Overview

Logical data models represent the abstract structure of some domain of information. They are often diagrammatic in nature and are most typically used in business processes that seek to capture things of importance to an organization and how they relate to one another. Once validated and approved, the logical data model can become the basis of a physical data model and inform the design of a database.

Logical data models should be based on the structures identified in a preceding conceptual data model, since this describes the semantics of the information context, which the logical model should also reflect. Even so, since the logical data model anticipates implementation on a specific computing system, the content of the logical data model is adjusted to achieve certain efficiencies.

The term 'Logical Data Model' is sometimes used as a synonym of 'Domain Model' or as an alternative to the domain model. While the two concepts are closely related, and have overlapping goals, a domain model is more focused on capturing the concepts in the problem domain rather than the structure of the data associated with that domain.
[edit] History
The ANSI/SPARC three level architecture, which "shows that a data model can be an external model (or view), a conceptual model, or a physical model. This is not the only way to look at data models, but it is a useful way, particularly when comparing models".[1]

When ANSI first laid out the idea of a logical schema in 1975[2] , the choices were hierarchical and network. The relational model – where data is described in terms of tables and columns – had just been recognized as a data organization theory but no software existed to support that approach. Since that time, an object-oriented approach to data modelling – where data is described in terms of classes, attributes, and associations – has also been introduced.

[edit] Logical data model topics
[edit] Why Build Logical Data Model

* Helps common understanding of business data elements and requirements
* Provides foundation for designing a database
* Facilitates avoidance of data redundancy and thus prevent data & business transaction inconsistency
* Facilitates data re-use and sharing
* Decreases development and maintenance time and cost
* Confirms a logical process model and helps impact analysis.

[edit] Logical Modeling Benefits

* Clarifies functional specifications and avoids assumption
* Confirms business requirements
* Facilitates business process improvement
* Focuses on requirements independent of technology
* Decreases system development time and cost
* Becomes a template for the enterprise
* Facilitates data re-use and sharing
* Faster ROI
* Gathers metadata
* Foster seamless communication between applications
* Focuses communication for data analysis and project team members
* Establishes a consistent naming scheme

[edit] Logical & Physical Data Model

Logical data models are sometimes incorrectly called a "physical data model", which is not what the ANSI people had in mind. The physical design of a database involves deep use of particular database management technology. For example, a table/column design could be implemented on a collection of computers, located in different parts of the world. That is the domain of the physical model.

People often get confused with the fact that logical and physical data models are very different in their objectives, goals and content. Following are some key differences.
Logical Data Model Physical Data Model
Includes entities/tables, attributes/columns/fields and relationships Includes tables, columns, keys, data types, validation rules, database triggers, stored procedures, domains, and access constraints
Uses business names for attributes Uses abbreviated column names limited by the database management system (DBMS)
Is independent of technology (platform, DBMS) Includes primary keys and indices for fast data access.
Is normalized to fourth normal form May be de-normalized to meet performance requirements based on the nature of the database. If the nature of the database is Online Transaction Processing(OLTP) or Operational Data Store (ODS) it is usually not de-normalized. De-normalization is common in Datawarehouses.
[edit] See also

* Core Architecture Data Model
* Database design
* Entity-relationship model
* Logical schema
* Object role modeling

[edit] References

1. ^ Matthew West and Julian Fowler (1999). Developing High Quality Data Models. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
2. ^ American National Standards Institute. 1975. “ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report”. FDT(Bulletin of ACM SIGMOD) 7:2.

[edit] External links

* Building a Logical Data Model By George Tillmann, DBMS, June 1995.

Retrieved from "http://en.wikipedia.org/wiki/Logical_data_model"
Categories: Data modeling

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License