{"id":17220,"date":"2026-09-06T08:30:45","date_gmt":"2026-09-05T23:30:45","guid":{"rendered":"https:\/\/www.sambuichi.jp\/?p=17220"},"modified":"2026-09-06T08:30:45","modified_gmt":"2026-09-05T23:30:45","slug":"why-a-single-hierarchical-table-matters-to-rdb-architects","status":"publish","type":"post","link":"https:\/\/www.sambuichi.jp\/?p=17220&lang=en","title":{"rendered":"Why a Single Hierarchical Table Matters to RDB Architects"},"content":{"rendered":"

Views: 0<\/p>

\n

Why a Single Hierarchical Table Matters to RDB Architects<\/h1>\n
\nChatGPT\uff08Editor\uff1aSAMBUICHI, Nobuyuki\uff09<\/span>
\n2026-09-06<\/span>\n<\/div>\n<\/div>\n
\n
\n
\n
\n

Relational databases are excellent for operational processing.
\nThey are optimized for updating current data, enforcing integrity, joining normalized tables, and supporting transactions in real time.<\/p>\n<\/div>\n

\n

But long-term preservation is a different problem.<\/p>\n<\/div>\n

\n

A historical business record is useful only if the information needed to understand it can still be reconstructed years later.
\nThat often requires more than the transaction rows themselves.
\nIt may also require the exact historical master data, the correct schema version, code tables, join rules, and application-specific logic that existed when the transaction was created.<\/p>\n<\/div>\n

\n

Structured Tidy Data Tables address that different requirement.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

1. Start from the semantic object model<\/h2>\n
\n
\n

Consider a small accounting model with four classes:<\/p>\n<\/div>\n

\n
    \n
  • \n

    JournalEntry<\/code><\/p>\n<\/li>\n

  • \n

    JournalLine<\/code><\/p>\n<\/li>\n

  • \n

    TaxDetail<\/code><\/p>\n<\/li>\n

  • \n

    Account<\/code><\/p>\n<\/li>\n<\/ul>\n<\/div>\n

    \n

    A JournalEntry<\/code> contains one or more JournalLine<\/code> occurrences.
    \nA JournalLine<\/code> may contain repeating TaxDetail<\/code> occurrences and references one Account<\/code>.
    \nEach class keeps its own unique identifier: entry_id<\/code>, line_id<\/code>, tax_id<\/code>, and account_id<\/code>.<\/p>\n<\/div>\n

    \n
    \n\"UML\n<\/div>\n
    Figure 1. UML semantic object model<\/div>\n<\/div>\n
    \n

    The semantic model is the authority.
    \nIt defines the classes, attributes, cardinalities, and relationships.
    \nThe question is how to preserve and exchange data derived from that model.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

    \n

    2. What an RDB designer normally does<\/h2>\n
    \n
    \n

    A conventional relational implementation decomposes the model into separate relations.<\/p>\n<\/div>\n

    \n
    \n\"Conventional\n<\/div>\n
    Figure 2. Conventional E-R representation<\/div>\n<\/div>\n
    \n

    This is a natural design for operational processing.<\/p>\n<\/div>\n

    \n

    2.1. JournalEntry<\/h3>\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n
    entry_id<\/th>\nentry_date<\/th>\njournal_code<\/th>\ndescription<\/th>\n<\/tr>\n<\/thead>\n
    \n

    H001<\/p>\n<\/td>\n

    		\n

    2026-09-01<\/p>\n<\/td>\n

    		\n

    SALES<\/p>\n<\/td>\n

    		\n

    Sale of Product X<\/p>\n<\/td>\n<\/tr>\n

    \n

    H002<\/p>\n<\/td>\n

    		\n

    2026-09-02<\/p>\n<\/td>\n

    		\n

    PURCHASE<\/p>\n<\/td>\n

    		\n

    Purchase of Material A<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    \n

    2.2. JournalLine<\/h3>\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n
    entry_id<\/th>\nline_id<\/th>\ndebit_credit_code<\/th>\naccount_id<\/th>\namount<\/th>\n<\/tr>\n<\/thead>\n
    \n

    H001<\/p>\n<\/td>\n

    		\n

    D001<\/p>\n<\/td>\n

    		\n

    debit<\/p>\n<\/td>\n

    		\n

    1100<\/p>\n<\/td>\n

    		\n

    100.00<\/p>\n<\/td>\n<\/tr>\n

    \n

    H001<\/p>\n<\/td>\n

    		\n

    D002<\/p>\n<\/td>\n

    		\n

    credit<\/p>\n<\/td>\n

    		\n

    4000<\/p>\n<\/td>\n

    		\n

    100.00<\/p>\n<\/td>\n<\/tr>\n

    \n

    H002<\/p>\n<\/td>\n

    		\n

    D003<\/p>\n<\/td>\n

    		\n

    debit<\/p>\n<\/td>\n

    		\n

    5000<\/p>\n<\/td>\n

    		\n

    80.00<\/p>\n<\/td>\n<\/tr>\n

    \n

    H002<\/p>\n<\/td>\n

    		\n

    D004<\/p>\n<\/td>\n

    		\n

    credit<\/p>\n<\/td>\n

    		\n

    2100<\/p>\n<\/td>\n

    		\n

    80.00<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    \n

    2.3. TaxDetail<\/h3>\n\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n
    entry_id<\/th>\nline_id<\/th>\ntax_id<\/th>\ntax_category<\/th>\ntax_rate<\/th>\ntax_amount<\/th>\n<\/tr>\n<\/thead>\n
    \n

    H002<\/p>\n<\/td>\n

    		\n

    D003<\/p>\n<\/td>\n

    		\n

    T001<\/p>\n<\/td>\n

    		\n

    Standard<\/p>\n<\/td>\n

    		\n

    10<\/p>\n<\/td>\n

    		\n

    8.00<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    \n

    2.4. Account<\/h3>\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n
    account_id<\/th>\naccount_name<\/th>\naccount_type<\/th>\n<\/tr>\n<\/thead>\n
    \n

    1100<\/p>\n<\/td>\n

    		\n

    Cash<\/p>\n<\/td>\n

    		\n

    Asset<\/p>\n<\/td>\n<\/tr>\n

    \n

    4000<\/p>\n<\/td>\n

    		\n

    Sales<\/p>\n<\/td>\n

    		\n

    Revenue<\/p>\n<\/td>\n<\/tr>\n

    \n

    5000<\/p>\n<\/td>\n

    		\n

    Purchases<\/p>\n<\/td>\n

    		\n

    Expense<\/p>\n<\/td>\n<\/tr>\n

    \n

    2100<\/p>\n<\/td>\n

    		\n

    Accounts Payable<\/p>\n<\/td>\n

    		\n

    Liability<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    \n

    For an application database, this decomposition is often exactly what is wanted.
    \nEach class has its own relation, and foreign keys reconstruct the business structure.<\/p>\n<\/div>\n

    \n

    For exchange and long-term preservation, however, the same design creates another problem:
    \none semantic business record is spread across several tables or files.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

    \n

    3. Historical archiving is a different problem<\/h2>\n
    \n
    \n

    Suppose a historical JournalLine<\/code> contains only:<\/p>\n<\/div>\n

    \n
    \n
    account_id = 1100\r\namount     = 100.00<\/code><\/pre>\n<\/div>\n<\/div>\n
    \n
    Years later, 1100<\/code> is meaningful only if the corresponding historical Account<\/code> master data is also available and still carries the meaning that applied at the time.<\/p>\n<\/div>\n
    \n
    The same issue applies to:<\/p>\n<\/div>\n
    \n
      \n
    • \n
      tax codes,<\/p>\n<\/li>\n
    • \n
      parties,<\/p>\n<\/li>\n
    • \n
      currencies,<\/p>\n<\/li>\n
    • \n
      products,<\/p>\n<\/li>\n
    • \n
      organizational units,<\/p>\n<\/li>\n
    • \n
      and other referenced master data.<\/p>\n<\/li>\n<\/ul>\n<\/div>\n
      \n
      Header and Line data must also be preserved as one consistent set.
      \nRestoring one without the other can leave broken references or an incomplete business record.<\/p>\n<\/div>\n
      \n
      A database backup can preserve the operational state, but future reuse may then depend on restoring the correct:<\/p>\n<\/div>\n
      \n
        \n
      • \n
        database version,<\/p>\n<\/li>\n
      • \n
        schema,<\/p>\n<\/li>\n
      • \n
        master data,<\/p>\n<\/li>\n
      • \n
        code tables,<\/p>\n<\/li>\n
      • \n
        application logic,<\/p>\n<\/li>\n
      • \n
        and join rules.<\/p>\n<\/li>\n<\/ul>\n<\/div>\n
        \n
        That is workable for disaster recovery.
        \nIt is not always the best form for a portable historical archive.<\/p>\n<\/div>\n
        \n\n\n
        \n
        Important<\/div>\n<\/td>\n
        		\n
        \n
        Normalization is excellent for operational processing, but a normalized database is not automatically a self-contained historical record.<\/p>\n<\/div>\n
        \n
        For long-term preservation, the information needed to understand a transaction should travel together, even when the operational application stores it across several tables.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n
        \n
        4. Why not simply flatten everything?<\/h2>\n
        \n
        \n
        One alternative is to export a flat CSV in which JournalEntry attributes are copied onto every JournalLine row.<\/p>\n<\/div>\n
        \n
        That creates another problem.<\/p>\n<\/div>\n\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n
        entry_id<\/th>\nentry_date<\/th>\ndescription<\/th>\nline_id<\/th>\naccount_id<\/th>\namount<\/th>\n<\/tr>\n<\/thead>\n
        \n
        H001<\/p>\n<\/td>\n
        		\n
        2026-09-01<\/p>\n<\/td>\n
        		\n
        Sale of Product X<\/p>\n<\/td>\n
        		\n
        D001<\/p>\n<\/td>\n
        		\n
        1100<\/p>\n<\/td>\n
        		\n
        100.00<\/p>\n<\/td>\n<\/tr>\n
        \n
        H001<\/p>\n<\/td>\n
        		\n
        2026-09-01<\/p>\n<\/td>\n
        		\n
        Sale of Product X<\/p>\n<\/td>\n
        		\n
        D002<\/p>\n<\/td>\n
        		\n
        4000<\/p>\n<\/td>\n
        		\n
        100.00<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \n
        entry_date<\/code> and description<\/code> are repeated for every line.
        \nIf TaxDetail<\/code> repeats, the duplication grows again.<\/p>\n<\/div>\n
        \n
        The file is rectangular, but the ownership of facts becomes blurred.
        \nA value that semantically belongs to JournalEntry<\/code> is physically copied onto JournalLine<\/code> rows.<\/p>\n<\/div>\n
        \n
        Structured Tidy Data avoids both extremes:<\/p>\n<\/div>\n
        \n
          \n
        • \n
          it does not require one physical table per semantic class; and<\/p>\n<\/li>\n
        • \n
          it does not duplicate parent attributes on child rows.<\/p>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n
          \n
          5. What is a Structured Tidy Data Table?<\/h2>\n
          \n
          \n
          A Structured Tidy Data Table is one sparse, model-governed table that can carry occurrences of several semantic classes.<\/p>\n<\/div>\n
          \n
          The essential rules are simple:<\/p>\n<\/div>\n
          \n
            \n
          1. \n
            One row represents one class occurrence.<\/p>\n<\/li>\n
          2. \n
            An attribute value appears only on the row of the class that owns it.<\/p>\n<\/li>\n
          3. \n
            Repeating classes create additional rows, not numbered columns such as Tax1<\/code>, Tax2<\/code>, Tax3<\/code>.<\/p>\n<\/li>\n
          4. \n
            Hierarchical occurrence columns preserve the parent-child context.<\/p>\n<\/li>\n
          5. \n
            References remain explicit.<\/p>\n<\/li>\n
          6. \n
            Blank cells are structural: they usually mean that the column belongs to another class, not that a required value is unknown.<\/p>\n<\/li>\n<\/ol>\n<\/div>\n
            \n
            A simplified example is shown below.<\/p>\n<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
            class<\/th>\ndEntry<\/th>\ndLine<\/th>\ndAccount<\/th>\ndTax<\/th>\nentry_id<\/th>\nentry_date<\/th>\nline_id<\/th>\ndebit_credit<\/th>\namount<\/th>\ntax_id<\/th>\ntax_rate<\/th>\ntax_amount<\/th>\naccount_id<\/th>\naccount_name<\/th>\n<\/tr>\n<\/thead>\n
            \n
            JournalEntry<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n\n
            H001<\/p>\n<\/td>\n
            		\n
            2026-09-01<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            JournalLine<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            D001<\/p>\n<\/td>\n
            		\n
            debit<\/p>\n<\/td>\n
            		\n
            100.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            Account<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            1100<\/p>\n<\/td>\n
            		\n
            Cash<\/p>\n<\/td>\n<\/tr>\n
            \n
            JournalLine<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            D002<\/p>\n<\/td>\n
            		\n
            credit<\/p>\n<\/td>\n
            		\n
            100.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            Account<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            4000<\/p>\n<\/td>\n
            		\n
            Sales<\/p>\n<\/td>\n<\/tr>\n
            \n
            JournalEntry<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n\n
            H002<\/p>\n<\/td>\n
            		\n
            2026-09-02<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            JournalLine<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            D003<\/p>\n<\/td>\n
            		\n
            debit<\/p>\n<\/td>\n
            		\n
            80.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            TaxDetail<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            T001<\/p>\n<\/td>\n
            		\n
            10<\/p>\n<\/td>\n
            		\n
            8.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/tr>\n
            \n
            Account<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            5000<\/p>\n<\/td>\n
            		\n
            Purchases<\/p>\n<\/td>\n<\/tr>\n
            \n
            JournalLine<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            D004<\/p>\n<\/td>\n
            		\n
            credit<\/p>\n<\/td>\n
            		\n
            80.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            Account<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n\n
            2100<\/p>\n<\/td>\n
            		\n
            Accounts Payable<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
            \n\n\n
            \n
            Note<\/div>\n<\/td>\n
            		\nThe class column is included for explanatory purposes to indicate the Class to which each row belongs. It is not a column defined in the actual data.\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n
            \n
            The table looks unusual to an RDB designer because several semantic classes coexist in one physical table.
            \nThat is deliberate.<\/p>\n<\/div>\n
            \n
            The table is not intended to replace the operational database.
            \nIt is a portable representation of the semantic dataset.<\/p>\n<\/div>\n
            \n\n\n
            \n
            Note<\/div>\n<\/td>\n
            		\nIn the following example, TaxDetail and Account are non-repeating Classes and are therefore represented in the same physical row as their parent JournalEntry. This does not alter the semantic Class hierarchy; it only reflects the physical row layout.\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n
            class<\/th>\ndEntry<\/th>\ndLine<\/th>\nentry_id<\/th>\nentry_date<\/th>\nline_id<\/th>\ndebit_credit<\/th>\namount<\/th>\ntax_id<\/th>\ntax_rate<\/th>\ntax_amount<\/th>\naccount_id<\/th>\naccount_name<\/th>\n<\/tr>\n<\/thead>\n
            \n
            JournalEntry<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n\n
            H001<\/p>\n<\/td>\n
            		\n
            2026-09-01<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            JournalLine
            \n(Account)<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n\n
            D001<\/p>\n<\/td>\n
            		\n
            debit<\/p>\n<\/td>\n
            		\n
            100.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n\n
            1100<\/p>\n<\/td>\n
            		\n
            Cash<\/p>\n<\/td>\n<\/tr>\n
            \n
            JournalLine
            \n(Account)<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n\n
            D002<\/p>\n<\/td>\n
            		\n
            credit<\/p>\n<\/td>\n
            		\n
            100.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n\n
            4000<\/p>\n<\/td>\n
            		\n
            Sales<\/p>\n<\/td>\n<\/tr>\n
            \n
            JournalEntry<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		<\/td>\n\n
            H002<\/p>\n<\/td>\n
            		\n
            2026-09-02<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
            \n
            JournalLine
            \n(TaxDetail)
            \n(Account)<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            1<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n\n
            D003<\/p>\n<\/td>\n
            		\n
            debit<\/p>\n<\/td>\n
            		\n
            80.00<\/p>\n<\/td>\n
            		\n
            T001<\/p>\n<\/td>\n
            		\n
            10<\/p>\n<\/td>\n
            		\n
            8.00<\/p>\n<\/td>\n
            		\n
            5000<\/p>\n<\/td>\n
            		\n
            Purchases<\/p>\n<\/td>\n<\/tr>\n
            \n
            JournalLine
            \n(Account)<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		\n
            2<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n\n
            D004<\/p>\n<\/td>\n
            		\n
            credit<\/p>\n<\/td>\n
            		\n
            80.00<\/p>\n<\/td>\n
            		<\/td>\n<\/td>\n<\/td>\n\n
            2100<\/p>\n<\/td>\n
            		\n
            Accounts Payable<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
            \n
            6. Why this form matters<\/h2>\n
            \n
            \n
            The unusual shape preserves three useful properties at the same time:<\/p>\n<\/div>\n
            \n
              \n
            1. \n
              One portable dataset.<\/strong>
              \nA complete business record can travel as one governed table instead of a collection of application-specific relations.<\/p>\n<\/li>\n
            2. \n
              No duplication of parent attributes.<\/strong>
              \nJournalEntry<\/code> facts stay on the JournalEntry<\/code> row and are not copied to every JournalLine<\/code>.<\/p>\n<\/li>\n
            3. \n
              Explicit hierarchy and reference context.<\/strong>
              \nThe relationship among JournalEntry<\/code>, JournalLine<\/code>, TaxDetail<\/code>, and Account<\/code> remains visible and machine-processable.<\/p>\n<\/li>\n<\/ol>\n<\/div>\n
              \n
              For an RDB architect, the key distinction is purpose:<\/p>\n<\/div>\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n
              Operational RDB<\/th>\nStructured Tidy Data Table<\/th>\n<\/tr>\n<\/thead>\n
              \n
              Optimized for current transaction processing<\/p>\n<\/td>\n
              		\n
              Optimized for exchange, inspection, archival, and analysis<\/p>\n<\/td>\n<\/tr>\n
              \n
              Several normalized physical tables<\/p>\n<\/td>\n
              		\n
              Several semantic classes can coexist in one sparse table<\/p>\n<\/td>\n<\/tr>\n
              \n
              Relationships are reconstructed through joins<\/p>\n<\/td>\n
              		\n
              Hierarchy is carried by occurrence context and explicit references<\/p>\n<\/td>\n<\/tr>\n
              \n
              Master data may live elsewhere<\/p>\n<\/td>\n
              		\n
              Reference information needed for interpretation can travel with the dataset<\/p>\n<\/td>\n<\/tr>\n
              \n
              Depends on the operational schema and application conventions<\/p>\n<\/td>\n
              		\n
              Governed by the shared semantic model<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
              \n
              7. Why this is also useful for AI<\/h2>\n
              \n
              \n
              Structured Tidy Data is well suited to AI-assisted analysis because the information needed to understand a transaction can be preserved in one model-governed dataset.<\/p>\n<\/div>\n
              \n
              In a conventional normalized RDB, an AI system may need more than the transaction rows.
              \nIt may also need:<\/p>\n<\/div>\n
              \n