+13236381128
+15199002991
+61480040096
Book a Demo
TRY A SAMPLE SURVEY
en_US Englishfr_FR French
en_US Englishfr_FR French
+13236381128
+15199002991
+61480040096
en_US Englishfr_FR French

Logical Data Model

SHARE THE ARTICLE ON

Logical Data Model Logical Data Model
Table of Contents

A logical data model is a non-specific database model that outlines the objects about which an organization wants to gather data and the relationships between these things.

A root package object always contains logical model objects. There is usually one root package, but we can add additional packages under the root package to group similar objects together. 

What Is Logical Data Model?

A logical data model defines the structure of data pieces as well as the relationships between them. It is distinct from the physical database, which specifies how the data will be implemented. The logical data model acts as a plan for the data that is used. The logical data model expands on the concepts of conceptual data modeling by including more information.

The logical data model combines all of the information pieces that are critical to the day-to-day operation of the organization.

Exploratory Research Guide

Conducting exploratory research seems tricky but an effective guide can help.

Download Now

Components Of Logical Data Model

A logical data model is made up of three major components:

Entities

A person, place, object, event, or notion of interest to a retailer is represented by an entity type. Customers, Item, Retail Store, Web Site, Purchase Order, Retail Transaction, and hundreds of more nouns are examples of entities. Each entity type in the ARTS data model is specified in business terms. Entity types are represented as rectangles in an entity diagram. Each entity type is given a distinct, singular noun phrase as its name. Each entity type instance in a relational data architecture is uniquely identifiable by a primary key. A primary key is one or more properties with values that are used to uniquely identify and differentiate one entity type instance from the others.

Attributes 

An attribute identifies, labels, and specifies a feature or property of a kind of entity. An Item entity type, for example, will include an ItemID attribute to uniquely identify it. It will contain a Name property, which will be used in catalogs and labels. It will contain a Description property, among other things. Attributes are the most fundamental components of a data model. They cannot be broken down into lower-level components. An attribute in a relational data model cannot exist independently of an entity type. As a result, all characteristics are always identified and shown as part of entity types.

A primary key, as explained under entity type, is made up of one or more properties and acts as a unique entity type instance identifier. 

Relationships

A relationship identifies, labels, and specifies a connection between two types of entities. A relationship always connects two and only two sorts of entities. Verb phrases are used to indicate relationship names. Relationship verb phrases can be defined for both directions of a relationship between two things. The entity types linked by a relationship provide two functions: A parent entity is a single entity. A child entity is the second entity. The parent entity and the child entity share the same identity. The child entity type is referred to as a dependent entity type because it inherits the main key of the parent entity type. A foreign key is an attribute shared by a parent and a child entity type. An attribute name in an entity diagram is a foreign key which is designated with a “(FK)” suffix. 

A parent and child entity type can be associated in two ways in a relational data architecture. The first method is through an identifying relationship. An identifying connection indicates that the main key of the child entity is inherited from its parent entity type. That is, the existence of the child entity type is contingent on the presence of its parent entity type. If the parent entity type is destroyed in this circumstance, the child is also deleted. A child entity type, on the other hand, cannot be entered until the parent it refers to is inserted. An identifying connection is represented in an entity diagram by a solid line connecting the parent and child entity types.

A non-identifying connection is the second method parent and child entity types can be associated with. In a non-identifying connection, the parent entity’s primary key is inherited as a non-primary key property by the child object. This signifies that the child entity refers to its parent entity type but is not dependent on its parent’s existence to exist. From the perspective of a relational database, this means that the inherited property may be null – that is, it could point to nothing. A non-identifying connection is represented in an entity diagram by a dashed line connecting the parent and child entity types.

Cardinality is an extra characteristic between parent and child entity types that is included into relationships. Cardinality represents the number of occurrences of a child entity type that may exist for a parent entity type. A Brand, for example, may apply to zero, one, or many Item entity type instances. In contrast, an Item can be referred to by either zero or one Brand. The graphic below depicts these cardinalities. Cardinality may be expressed in a variety of ways to convey the relative counts of parent entity types to child entity types.

The following graphic depicts a NON-IDENTIFYING link between Item and Brand. It also shows how to present foreign keys and cardinality in an entity diagram. It adds Owned Attributes, which are attributes that are NOT inherited from another entity type and are not part of the main key of an entity type.

In addition to cardinality, there is a subtype connection that allows numerous child entity types to inherit attributes from a common parent entity type. This is depicted in the following diagram. The yellow block depicts a retail transaction definition. A RetailTransaction, as depicted here, can have zero, one, or many RetailTransactionLineItem entity objects associated with it. Because a line item cannot exist without a retail transaction header, the RetailTransactionLineItem entities are dependent.

The RetailTransactionLineItem entity type can be expanded to record item sales data as a SaleReturnLineItem, discount data for a retail transaction as a DiscountLineItem, tax data as a TaxLineItem, or payment data as a TenderLineItem. A retail transaction line item has a set of properties (including the line item number) that are shared by all subtypes (i.e., inheritable by subtype children). A RetailTransactionLineItem entity type instance can only have one subtype. This relational idea of subtype is related to inheritance in object oriented design, which is used to describe classes and objects. Subtype child entity types efficiently describe a retail transaction and the many types of line items required to collect item, discount, tax, and tender data in this example. The sample receipt shows how each subtype of RetailTransactionLineItem reflects different sales receipt line items. 

Domains

A domain is a sort of data representation that is named and can apply to one or more characteristics. Data representation specifies a data type, such as an integer, text, floating point, date, time, or other standard data type, or an extended definition that adds specific features and restrictions to a basic data type. Domains enable the creation of retail-specific data types from SQL basic data types. For example, ARTS has an IdentityGTIN domain type described as: An identification for item at POS – UCC/EAN defines Global Trade Item Number (GTIN). The IdentityGTIN is built on a VARCHAR(14) basic data type, which is supported by the vast majority of SQL standard databases. Domains can also be used to put limitations on the values that can be assigned to an attribute to a domain. For example, Flag domains are limited to two values “YES” or “NO”.

What Is The Need Of Logical Data Model?

Given that data is the most important part of any application, programme, or system, high-quality data processing and storage systems must be based on a solid and reliable underlying data structure. A solid data structure allows application developers to create the finest user interface, processing system, or statistical analysis and reporting setup feasible.

No matter how sophisticated or complex our system is, it must fulfill criteria, obey regulations, and serve the aims of the business or enterprise for which it was designed—otherwise it will be useless. As a result, logical data modeling combines the two most important fundamentals of application development:

  • Business requirements
  • Quality data structure

Characteristics Of Logical Data Model

The following are the most significant features of a logical data model:

  • A logical data model can explain the data requirements for each project. However, it is designed to connect effortlessly with other logical data models if the project requires it.
  • The development and design of a logical data model can be done independently of the database management system. It is unaffected by the kind of database management system.
  • Data characteristics include specific lengths and precisions for data types.
  • There is no main or secondary key established in logical data modeling. At this level of data modeling, it is necessary to double-check and fine-tune connection features that were established prior to constructing relationships.
  • A logical data model is a graphical depiction of a business’s information requirements. It isn’t a database or a database management system in and of itself.
  • A logical data model is distinct from any physical data storage device, such as a file system.
  • A logical data model must be designed to be technology-independent in order to be unaffected by fast technological developments.

See Voxco survey software in action with a Free demo.

Book a Free Demo

Data Model Semantics

Semantics is the study of meaning in languages and logic. In addition to defining entities, properties, connections, and domains, logical models clarify what each instance of these objects implies. These definitions offer the semantic substance of a data model and are critical to a relational model’s commercial relevance. The graphic below depicts the assignment of a definition to Item’s ItemID attribute. Definitions should be written in business language and should reflect the business ideas represented by a data model entity, attribute, relationship, domain, or other model objects.

Why Develop Data Model?

Data models aren’t only for IT professionals. In today’s commercial environment, data models are required to run a retail firm.

The Use of Information as a Currency and Asset

In the twenty-first century, retailing is about managing information as much as it is about managing cash, products, customers, shops, vendors, and other “real world” corporate assets. Because they cannot physically visit and monitor every retail outlet, most retail decision makers rely on information to make their selections. To be valuable, information must be recognised, labeled, characterized, and arranged into a logical structure that decision makers can understand. Data modeling provides a rigorous set of tools and techniques for transforming information into meaningful information.

Data modeling’s formality and discipline are critical in determining what retail reports are genuinely informing decision makers. Take a look at the phrases item, article, product, SKU, and merchandise. They each have various connotations for different people. By specifying each entity type, the data model specifies what each word implies. When some words are used as synonyms, they are clearly stated as such. This is known as a regulated vocabulary, and it is an important value-added aspect of data modeling. It creates a standard language for retailer organizations and individuals to communicate via the use of specifically specified terminology.

Misinterpretation and Inconsistent Semantics Costs

Retailers must handle a complicated set of relationships including consumers, vendors, tax authorities, regulators, workers, and a variety of other parties. Retailers who do not have a single standard way to identify, name, define, and describe things, tender kinds, tax laws, promotions, vendor offers, and the like may have costly transaction processing mistakes. The accuracy of data has a clear and unmistakable influence on the bottom line. If an ordered item is not properly aligned with the vendor’s catalog product code and the order is placed, someone (the consumer, retailer, vendor, etc.) will be charged for it. By requiring a third normal form relational model, the data model reduces this danger by insisting on a consistent representation of each data element in a single place in the data model. The similar problem arises while creating reports. Retailers who lack a standard method of identifying, naming, and describing entities, characteristics, and relationships waste a lot of time and money reconciling inconsistent summary reports. Middle and senior managers in certain firms spend an undue amount of time manually reconciling inconsistently specified data. One of the underlying reasons for data inconsistency is eliminated by data models that provide an enterprise-wide regulated vocabulary.

Assumptions, Constraints, and Rules of Business as Reflected in the Data Model

Important retail business assumptions and limits are reflected in data models. The link between taxation, product, and retailer-provided services, for example, is clearly expressed in the way things, taxes, tax authorities, retail transactions, inventory management papers, and so on are associated in a data model. The guidelines governing the way point of scale discounts are treated by a retailer are likewise reflected in the way price modification rules are related to retail transaction sale return items and promotions. The complex web of relationships that define retailer business rules is explicitly presented through entity relationship models. 

Regulatory Reporting and Accountability & Data Modeling

Data models are required for retailers to navigate today’s complicated regulatory reporting environment. The Sarbanes-Oxley Act of 2002 requires rigorous reporting and tracking of operational and financial controls in businesses. This kind of surveillance necessitates that merchants understand how data is organized, filled, kept, and safeguarded. Corporate systems for financials, sales, marketing, inventory, buying, and associated operational systems create data for compliance. Depending on the size and complexity of the company, these systems are part of a collection of applications whose data must be converted into information and then distilled into knowledge for top executives via reports. Data is gathered and stored in data structures such as tables and files, and then converted and transported – to become knowledge in reports signed by business executives. The business and technical metadata for this system data build an information architecture that may both drive the creation of internal controls and provide corporate executives with confidence that the reports they sign are accurate. The data model principles covered in this article provide the type of assistance necessary to facilitate regulatory reporting compliance. Additional data transportation and transformation capability is also required. The ARTS ODM V7.0/7.1 to ARTS DWM V3.0 extract, convert, and load mapping partially meets regulatory requirements for data mobility.

Payment Card Industry (PCI) compliance, which specifies processes shops must adopt to secure their customers’ credit card accounts, necessitates retailers mapping and understanding the types of data they gather. PCI compliance, although focusing on payment-related account identification, is paving the way for further restrictions on customer identity and personal data. All of these regimes need merchants inventorying and comprehending their data assets.

What Happens When Logical Data Model Is Not Developed?

Simply said, there may be problems. Users might become engrossed in procedures and activities if they are not reminded that data, not technology, is the most important factor to consider when creating a new system. A data model that is only focused on physical workflow misses out on reflecting critical business needs.

Tables and files created by designers without having the data pieces described according to business needs are often disorganized and lack a solid underlying structure. Discovering and attempting to include extra data pieces from screen or report layouts during the coding, testing, or even deployment process encourages developers to be reactive rather than proactive. The result is a disjointed organism that is difficult to run and maintain and is riddled with flaws or excess text, minus system documentation, time-sucking and possibly unusable. 

Because the logical data model establishes the structure of data pieces based on core business requirements as well as the links between them, not having one in place means a lot of missed chances for optimizing business processes. Developers end up merely automating current operations or replicating legacy systems on a newer technical platform that may become obsolete in the future.

Using logical data modeling helps data analysts to think independently of the latest technology and concentrate on improving business processes.

As a result, a logical data model must become an essential and irreversible component of any application development effort. It is a critical stage that should ideally come before database design.

Advantages Of Logical Data Model

  • Because data remains stable over time, a logical data architecture is likewise stable and extremely favorable to data re-use and physical data sharing, resulting in less redundant data storage.
  • As other teams weigh in with their (often changing) demands, components of a logical data model may be recycled, re-used, and altered.
  • The costs of developing and maintaining a logical data model are offset in the long term by the benefits it provides, not least by recognising and integrating all business needs and regulations from the start.
  • As a result of the integration and clarity of business rules, components of the construction process, such as design, coding, testing, and deployment, move quicker.
  • Having a logical data model in place makes it easier, and hence less expensive, to make modifications, fix mistakes, or add missing data prior to implementation during the development life cycle.
  • By being proactive, user demands for adjustments can be reduced.
  • Because each business activity and rule is linked inside it, logical data models may be utilized for effect analysis.
  • Because items in the logical data model have textual definitions in business language, system documentation is easy to maintain and retrieve.

Net Promoter®, NPS®, NPS Prism®, and the NPS-related emoticons are registered trademarks of Bain & Company, Inc., Satmetrix Systems, Inc., and Fred Reichheld. Net Promoter Score℠ and Net Promoter System℠ are service marks of Bain & Company, Inc., Satmetrix Systems, Inc., and Fred Reichheld.

Explore Voxco Survey Software

Logical Data Model Logical Data Model

+ Omnichannel Survey Software 

+ Online Survey Software 

+ CATI Survey Software 

+ IVR Survey Software 

+ Market Research Tool

+ Customer Experience Tool 

+ Product Experience Software 

+ Enterprise Survey Software 

Get a Free Demo

Read more