{"id":9606,"date":"2026-10-13T05:36:29","date_gmt":"2026-10-13T05:36:29","guid":{"rendered":"https:\/\/www.learn-vp.com\/ru\/gallery\/mastering-data-modeling-concept-to-vpascode-uml\/"},"modified":"2026-10-13T05:36:31","modified_gmt":"2026-10-13T05:36:31","slug":"mastering-data-modeling-concept-to-vpascode-uml","status":"publish","type":"gallery","link":"https:\/\/www.learn-vp.com\/ru\/gallery\/mastering-data-modeling-concept-to-vpascode-uml\/","title":{"rendered":"Mastering Data Modeling: From Concept to VPasCode with UML"},"content":{"rendered":"
\n

\"Conceptual,<\/p>\n

When designing complex software systems, the gap between a business idea and a functioning database can feel insurmountable. The secret to bridging this gap is not to rush to the database, but to climb the ladder of abstraction step-by-step. As shown in the “Choose the modeling level” diagram, effective data modeling requires distinct phases: Conceptual<\/strong>, Logical<\/strong>, and Physical<\/strong>. Each phase serves a specific audience and purpose, and conflating them often leads to rigid, unchangeable systems.<\/p>\n

In this tutorial, we will explore these three modeling levels using a classic Customer<\/em> and Order<\/em> domain. We will also see how to implement the middle step\u2014the Logical Model\u2014using the VPasCode<\/strong> editor within Visual Paradigm UML.<\/p>\n

Level 1: The Conceptual Model (The “What”)<\/h2>\n

The Conceptual model is the conversation starter. It is designed for business stakeholders, product managers, and architects. At this stage, technical details like data types, primary keys, or SQL syntax are irrelevant distractions.<\/p>\n

    \n
  • Focus:<\/strong> Business concepts, domain entities, and high-level relationships.<\/li>\n
  • Key Feature:<\/strong> Minimal technical detail. For example, a relationship is simply “places” rather than a foreign key constraint.<\/li>\n
  • Example:<\/strong> A simple diagram showing a Customer<\/em> icon connected to an Order<\/em> icon via an arrow labeled “places”.<\/li>\n<\/ul>\n

    The goal here is to validate the business logic. Does a Customer place<\/em> an Order? Yes. Is that the right mental model for the business? If not, you fix it here, before writing a single line of code.<\/p>\n

    Level 2: The Logical Model (The “How” – Abstract)<\/h2>\n

    Once the concepts are agreed upon, we move to the Logical Data Model (LDM). This is where the structure is defined without being tied to a specific database technology (like PostgreSQL vs. Oracle). It is the blueprint that architects and developers use to understand data requirements.<\/p>\n

    Key Components of the Logical Model<\/h3>\n

    As illustrated in the center panel of your reference image, the Logical model introduces:<\/p>\n

      \n
    1. Attributes:<\/strong> Defining the data inside the entities (e.g., name<\/code>, placedAt<\/code>).<\/li>\n
    2. Identifiers:<\/strong> Defining the Primary Keys (e.g., id: UUID<\/code>).<\/li>\n
    3. Multiplicities:<\/strong> Defining the cardinality of relationships (e.g., 1 Customer to 0..* Orders).<\/li>\n
    4. Rules:<\/strong> Constraints that apply to the data, independent of the database engine.<\/li>\n<\/ol>\n

      VPasCode Implementation:<\/strong><\/p>\n

      To create this in Visual Paradigm using the VPasCode<\/code> editor, you define the entities and their relationships using a domain-specific language. Below is the code snippet representing the Logical Model shown in your image.<\/p>\n<\/p>\n

      entity Customer {\n  id: UUID\n  name: String\n}\n\nentity Order {\n  id: UUID\n  placedAt: DateTime\n  total: Money\n}\n\nCustomer \"1\" -- \"0..*\" Order : places<\/code><\/pre>\n
      In this snippet, we use abstract types like UUID<\/code>, DateTime<\/code>, and Money<\/code>. These are placeholders that represent the logical requirement, not the specific SQL type yet.<\/p>\n