What are Data Models?
A software application typically stores business information in files and databases. Data models are a logical representation of the business processes in a organization. They define how the business interacts with people, places, and things. The data model is used as a reference point for determining the rules of relationships between entities within an organization.
The data model creation process is divided into three primary stages. These are domain models, logical models, and physical models. Each stage is completed in a progression ending with the physical model, which represents the actual structure of the database.
The design of the domain model is the first step in creating a data model. This is a high-level view of the business units within an organization and their relationships to each other. Domain data models define the conceptual relationship between organizations and the processes required to complete a business function. An example of a domain model is the relationship between the ordering of a product and the effect the order has on the shipping department.
The enterprise domain model is typically a very high-level view of the organization and does not require the exact details on each type of business requirement. It is important, however, to include all impacted business units within the domain model design. This high-level design is necessary for the project team to understand the detail functions that are required to complete business functions.
Logical data models are the versions of data models that represent the actual business requirements of a company. These models are designed based on the high-level domain models of specific business units within an organization. A sound logical design is critical to create the physical database. This process must clearly define the data elements that are necessary to complete a specific business requirement. Logical data models include how data will be accessed and the relationships between entities within a business process.
A good example of a logical data model could be a modeling of customers for a telephone company. Each customer has a specific name, phone number, address, and phone features. The logical data model would provide the relationships between these types of elements including how the information would be reported and retrieved.
The final layer of data models is the physical data model. This is the area of data models that is used in creating the actual database. The physical data model is the database-specific blue print, which defines how data will be stored within the software application.
@hamje32 - I should point out that not everyone who interacts with the data is a developer. If you’re an analyst the data analysis models listed here are of limited usefulness.
I suppose the most useful one mentioned is the physical data model, knowing how information is stored in the database. You won’t be doing object oriented programming as an analyst.
You get down in the muck and mire of the data itself, writing queries and creating reports. At least that’s what I did when I was an analyst.
@David09 - Yeah, I think it’s the supervisors or software architects who build the domain level model. I’ve programmed for years and never had to mess with it.
As for the logical model, I think there are ways of coding without using object oriented programming, but it gets messy and results in what is known as “spaghetti code.”
That’s where your code twists and turns in various loops and directions to accomplish its intended function. Spaghetti code is ugly.
I work as a developer for a software company. I think of all the conceptual data models listed here, the logical data model is one that most developers are familiar with. That’s because most programming nowadays is what’s known as object oriented, and this falls right in line with the logical data model.
In object oriented programming we create objects (or classes) in the code that model the real world objects the program is supposed emulate. For example a banking application might have a Bank class, with a deposit and withdraw function, as well as a Customer class and so forth. You get the idea.
We look at the real world objects and we create objects in code to mirror. We don’t do this to be clever, but so that the code will be easier to understand and maintain. I love object oriented programming and have been doing it for quite some time now.
Post your comments