SHARE THE ARTICLE ON
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.
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.
Conducting exploratory research seems tricky but an effective guide can help.
A logical data model is made up of three major components:
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.
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.
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.
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”.
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:
The following are the most significant features of a logical data model:
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.
Data models aren’t only for IT professionals. In today’s commercial environment, data models are required to run a retail firm.
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.
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.
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.
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.
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.