6a:T4ad,An Entity-Relationship diagram is fundamentally a **communication artifact**. Its primary purpose is not merely to document the structure of a database—it is to convey that structure clearly to diverse stakeholders: database administrators, application developers, business analysts, project managers, and domain experts. The single most important factor determining whether an ER diagram communicates effectively or causes confusion is **naming conventions**. Consider two entity names: `TBL_USR_01` versus `Customer`. The first requires a legend, institutional knowledge, and mental translation. The second speaks for itself. At scale—when a model contains hundreds of entities and thousands of attributes—the cumulative cognitive load of poor naming becomes a bottleneck for every person who touches the system. Naming conventions are not cosmetic preferences or bureaucratic overhead. They are **engineering decisions** that affect: - The speed at which new team members understand the system - The likelihood that developers make errors when writing queries - The maintainability of the schema over years and decades - The quality of communication between technical and business teams6b:T4a9,Entities are the nouns of your data model—the things about which you store information. Entity names are the most visible elements in an ER diagram and set the tone for the entire model's readability. **Fundamental Principles for Entity Names** 1. **Use Singular Nouns**: Name entities in the singular form (`Customer`, not `Customers`). The entity represents a *type* of thing, not a collection. The set of all customers is the entity *set*; the entity *type* is singular. 2. **Use Business Domain Language**: Adopt the terminology that domain experts use. If the business calls it a 'Purchase Order', don't rename it 'Transaction' for database convenience. 3. **Be Specific Over Generic**: Prefer `InvoiceLineItem` over `Item`. Generic names cause confusion when the model grows to include other types of items. 4. **Avoid Abbreviations in Conceptual Models**: At the conceptual level, spell out names completely. `DepartmentEmployee` is better than `DeptEmp`. Abbreviations can be introduced (if necessary) in physical naming. 5. **Use Multi-Word Names When Needed**: Don't artificially shorten names. `CustomerAddress` is clearer than trying to combine concepts into a single word.6c:T599,Attributes capture the properties of entities. Since they appear in every query, every application, and every report, attribute naming has a profound impact on system usability. **Fundamental Principles for Attribute Names** 1. **Be Descriptive**: The name should indicate what the attribute stores without requiring context. `order_date` is better than `date` (date of what?). `customer_email` is better than `email` when multiple entities have email addresses. 2. **Include Units When Relevant**: For quantities, consider encoding units: `weight_kg`, `price_usd`, `duration_minutes`. This eliminates dangerous ambiguity. 3. **Use Consistent Suffixes**: Standardize suffixes for common attribute types: - `_id` for identifiers: `customer_id`, `order_id` - `_date` for dates: `order_date`, `birth_date` - `_time` for timestamps: `created_time`, `last_login_time` - `_code` for coded values: `status_code`, `country_code` - `_flag` or `is_` for booleans: `active_flag`, `is_active` - `_count` for quantities: `item_count`, `retry_count` 4. **Avoid Redundant Prefixes**: Don't repeat the entity name in every attribute. If the entity is `Customer`, the attribute should be `phone_number`, not `customer_phone_number`. The context is already established. 5. **Be Consistent Across Entities**: If you use `created_time` in one entity, don't use `creation_timestamp` in another. Consistency reduces cognitive load.6d:T4ec,Relationships are the verbs of your data model—they describe how entities interact. Well-named relationships make an ER diagram readable as a set of natural-language sentences. **Fundamental Principles for Relationship Names** 1. **Use Active Verbs**: Relationships describe actions or associations. Use active voice: - `Places` (Customer places Order) - `Contains` (Order contains LineItem) - `Supervises` (Manager supervises Employee) 2. **Consider Both Directions**: While relationships are drawn in one direction, they can be read both ways. Choose names that work contextually: - `Customer` —Places→ `Order` ✓ - `Order` —Placed by→ `Customer` (implied inverse) 3. **Avoid Generic Names**: Names like `Has`, `Relates`, or `Links` provide no information. Every relationship 'relates' entities—what matters is *how*. 4. **Include Role Names for Ambiguity Resolution**: When multiple relationships exist between the same entities, role names distinguish them: - Employee —`manages`→ Department (as Manager) - Employee —`works_in`→ Department (as Worker) 5. **Use Verb Phrases When Needed**: Sometimes a single verb is insufficient. Use verb phrases: - `Is_Assigned_To` - `Reports_To` - `Is_Located_In`6e:T478,Individual naming practices mean little without organizational standardization. A **Naming Standards Document** (NSD) codifies conventions so that every team member, current and future, follows the same rules. **Components of a Naming Standards Document** A comprehensive NSD should include: 1. **Scope and Purpose**: What artifacts does this standard cover? Why is it important? 2. **General Principles**: Overarching philosophy (clarity over brevity, consistency, domain alignment). 3. **Entity Naming Rules**: Case conventions, singular vs plural, handling of compound names, abbreviation policy. 4. **Attribute Naming Rules**: Suffixes, prefixes (if any), key naming patterns, standard names for common attributes. 5. **Relationship Naming Rules**: Verb requirements, role naming, direction conventions. 6. **Constraint Naming Rules**: Prefixes, patterns for each constraint type. 7. **Reserved Words and Abbreviations**: Approved abbreviations list, SQL reserved words to avoid. 8. **Examples**: Concrete examples demonstrating correct and incorrect naming. 9. **Exception Process**: How to request deviations from the standard.6f:T571,# Database Naming Standards ## 1. General Principles - Clarity over brevity: Use complete words except for approved abbreviations - Consistency: The same concept uses the same name everywhere - Domain alignment: Use business terminology, not technical jargon ## 2. Entity Names - Case: PascalCase (Customer, OrderLineItem) - Number: Singular (Customer, not Customers) - Format: [Qualifier]Noun (SalesOrder, ProductCategory) - Avoid: Technical prefixes (tbl_), abbreviations, generic names ## 3. Attribute Names - Case: snake_case (customer_name, order_date) - Key Suffix: _id (customer_id, order_id) - Timestamp Suffix: _at or _time (created_at, last_login_time) - Boolean Prefix: is_ or _flag (is_active, deleted_flag) ## 4. Approved Abbreviations | Full Word | Abbreviation | Context | |-------------|--------------|---------| | Identifier | id | Primary/foreign keys only | | Number | num | Numeric counters | | Description | desc | Long text fields | ## 5. Constraint Names | Type | Pattern | Example | |-------------|------------------------------|---------| | Primary Key | PK_TableName | PK_Customer | | Foreign Key | FK_ChildTable_ParentTable | FK_Order_Customer | | Unique | UQ_TableName_Column | UQ_Customer_Email | | Check | CK_TableName_Rule | CK_Order_Positive |70:T5bc,Real-world databases rarely start fresh. Most organizations inherit legacy schemas with inconsistent or cryptic naming. How do you improve naming while managing existing dependencies? **The Pragmatic Approach** 1. **Document the Current State**: Create a data dictionary mapping legacy names to their business meanings. This serves immediate understanding needs. 2. **Establish Standards for New Work**: All new entities, attributes, and relationships follow the new naming conventions. No exceptions. 3. **Create Abstraction Layers**: Use views, synonyms, or ORM mappings to present logical names to applications while physical names remain unchanged: ```sql -- Physical table with legacy name CREATE TABLE CUST_MSTR ( CUST_ID INT PRIMARY KEY, CUST_NM VARCHAR(100) ); -- View with clean naming for new applications CREATE VIEW Customer AS SELECT CUST_ID AS customer_id, CUST_NM AS customer_name FROM CUST_MSTR; ``` 4. **Incremental Refactoring**: When touching legacy code, consider renaming as part of the change—only for affected components, not the entire system. 5. **Major Migration Projects**: For large-scale renaming, plan carefully: - Impact analysis: What code, queries, reports, and integrations reference each object? - Transition period: Support both old and new names temporarily (via synonyms or views) - Coordination: Communicate timelines to all dependent teams - Rollback plan: Ability to revert if issues arise63:{"json":{"id":"seed_8661b49f8b8a9b104ab42a972ff10e3f","slug":"er-diagram-best-practices","category":"Database Management Systems","topic":"ER Diagram Best Practices","title":"ER Diagram Best Practices","description":"Master the art of creating professional, maintainable, and communicative Entity-Relationship diagrams. Learn naming conventions, layout principles, documentation standards, common pitfalls, and quality review techniques used by industry professionals.","difficulty":"INTERMEDIATE","estimatedMinutes":55,"pages":[{"id":"seed_850b849f3ba39977684153dc442578b0","title":"Naming Conventions","order":0,"content":[{"id":"opening-hook","title":"The Foundation of Readable Data Models","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the principles and specific practices for naming entities, attributes, relationships, and constraints in ER diagrams. You will learn how to balance descriptiveness with brevity, accommodate different naming styles, avoid common mistakes, and establish conventions that scale across large, evolving data models.","variant":"info"},"type":"callout"}]},{"id":"why-naming-matters","title":"Why Naming Conventions Matter","content":[{"data":{"content":"Before establishing specific rules, we must understand *why* naming conventions deserve rigorous attention. The impact of naming extends far beyond the ER diagram itself—it propagates through the entire software development lifecycle.\n\n**The Propagation Effect**\n\nWhen you name an entity `Cust` on an ER diagram, that abbreviation becomes:\n- A table named `Cust` in the physical database\n- A class named `Cust` or `CustEntity` in the ORM layer\n- References to `cust_id` in dozens of related tables\n- Column names like `cust_nm` and `cust_addr` in reporting systems\n- Documentation that must explain what 'Cust' means to new hires\n\nA poor naming choice at the conceptual level metastasizes into technical debt throughout the system. Correcting it later requires coordinated changes across code, queries, stored procedures, APIs, and documentation—a cost that grows exponentially with time."},"type":"text"},{"data":{"rows":[["During initial design","Confusion in design sessions; multiple interpretations","Easy (rename in diagram tool)"],["After schema implementation","Table/column renames required; scripts affected","Moderate (migration scripts)"],["After application development","ORM classes, queries, APIs must change","High (coordinated refactoring)"],["After production deployment","Downtime risk; backward compatibility concerns","Very High (complex migration)"],["After years in production","Legacy anchor; 'Nobody knows why it's called that'","Often prohibitive (technical debt)"]],"caption":"The Cost of Poor Naming Over Time","headers":["Time Frame","Impact of Poor Naming","Correction Difficulty"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Archaeology Problem","content":"In legacy systems, database engineers often play archaeologist—deciphering cryptic names like `TXNHDR`, `ACCT_MSTR`, or `PRCS_FLG`. Each puzzle wastes engineering time and introduces risk. Thoughtful naming today prevents your work from becoming tomorrow's archaeology project.","variant":"warning"},"type":"callout"},{"data":{"content":"**The Communication Function**\n\nER diagrams serve multiple audiences with different needs:"},"type":"text"},{"data":{"rows":[["Database Administrators","Physical implementation, performance","Clear mapping from model to schema"],["Application Developers","Mapping to code, query writing","Self-documenting joins and references"],["Business Analysts","Requirement traceability","Domain language alignment"],["Domain Experts","Validation of model accuracy","Instant recognition of concepts"],["Future Maintainers","Understanding existing system","Reduced ramp-up time"]],"headers":["Audience","Primary Concern","Impact of Good Naming"]},"type":"table"},{"data":{"content":"Consistent, meaningful names allow each audience to engage with the model without translation overhead. When an attribute is named `order_date` rather than `odt`, a business analyst can verify that the model captures their requirement without asking 'What does odt mean?'"},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"entity-naming","title":"Entity Naming Conventions","content":[{"data":{"content":"$6b"},"type":"text"},{"data":{"left":[{"data":{"items":["`Customer` — Clear, singular, domain-appropriate","`SalesOrder` — Multi-word for clarity","`ProductCategory` — Specific, not generic","`EmployeeDependant` — Business terminology","`PaymentMethod` — Descriptive compound name","`FlightReservation` — Domain-specific noun"],"title":{"icon":"CheckCircle","text":"Good Entity Names","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["`Customers` — Plural form (entity type, not set)","`SO` — Cryptic abbreviation","`Item` — Too generic; which kind of item?","`tbl_customer` — Implementation prefix in conceptual model","`DATA1` — Meaningless identifier","`Misc` — Vague catch-all"],"title":{"icon":"XCircle","text":"Problematic Entity Names","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Case Conventions for Entity Names**\n\nThe choice of case convention should be consistent across the entire model. Common conventions include:"},"type":"text"},{"data":{"rows":[["**PascalCase**","`CustomerOrder`","Standard in ER diagrams; each word capitalized"],["**CamelCase**","`customerOrder`","Rare in entity names; more common in attributes"],["**snake_case**","`customer_order`","Common in physical schemas; less readable in diagrams"],["**UPPER_SNAKE**","`CUSTOMER_ORDER`","Legacy systems; hard to read at scale"]],"headers":["Convention","Example","Characteristics"]},"type":"table"},{"data":{"content":"**Recommended**: Use **PascalCase** for entity names in conceptual and logical ER diagrams. This convention:\n- Clearly distinguishes entities from attributes (which often use different conventions)\n- Reads naturally without word-boundary ambiguity\n- Aligns with object-oriented naming (useful for ORM mapping)\n- Provides visual weight appropriate to primary concepts"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Ubiquitous Language","content":"Domain-Driven Design (DDD) emphasizes the 'Ubiquitous Language'—a shared vocabulary between developers and domain experts. Your ER diagram should reflect this language. If business stakeholders say 'Subscriber' and you model it as 'User', you create translation overhead in every conversation.","variant":"tip"},"type":"callout"},{"data":{"content":"**Handling Special Cases**\n\n**Associative Entities**: When a many-to-many relationship becomes an entity (to hold relationship attributes), name it to reflect its role:\n- `OrderLineItem` (between `Order` and `Product`)\n- `CourseEnrollment` (between `Student` and `Course`)\n- `FlightBookingPassenger` (between `FlightBooking` and `Passenger`)\n\nAvoid generic names like `OrderProductLink` or `StudentCourseJunction`. The entity should describe *what it is*, not just what it connects.\n\n**Weak Entities**: Weak entities should be named independently while their names may hint at the dependency:\n- `DependantPerson` (dependent on `Employee`)\n- `RoomReservation` (dependent on `Room`)\n- `OrderLineItem` (dependent on `Order`)\n\n**Role-Based Entities**: When an entity represents a role that another entity plays:\n- `CustomerContact` (a `Person` playing the role of contact for a `Customer`)\n- `ProjectManager` (an `Employee` assigned as manager to a `Project`)"},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"attribute-naming","title":"Attribute Naming Conventions","content":[{"data":{"content":"$6c"},"type":"text"},{"data":{"rows":[["`_id`","Identifiers (primary and foreign keys)","`customer_id`, `product_id`, `order_id`"],["`_code`","Short coded values, often from a domain","`status_code`, `currency_code`, `country_code`"],["`_date`","Calendar dates (without time component)","`birth_date`, `order_date`, `expiry_date`"],["`_time` / `_at`","Timestamps (date and time)","`created_at`, `last_login_time`, `expires_at`"],["`_flag` / `is_`","Boolean indicators","`active_flag`, `is_deleted`, `is_verified`"],["`_count` / `_num`","Quantities and counts","`line_item_count`, `attempt_num`"],["`_name`","Human-readable names","`first_name`, `product_name`, `company_name`"],["`_desc`","Descriptions (longer text)","`product_desc`, `error_desc`"],["`_amount`","Monetary or quantitative amounts","`total_amount`, `tax_amount`, `discount_amount`"],["`_pct` / `_rate`","Percentages or rates","`tax_pct`, `interest_rate`, `discount_pct`"]],"caption":"Common Attribute Type Suffixes","headers":["Suffix","Use Case","Examples"]},"type":"table"},{"data":{"content":"**Case Conventions for Attributes**\n\nAttributes typically use a different case convention than entities to visually distinguish them:"},"type":"text"},{"data":{"rows":[["**snake_case**","`customer_name`, `order_date`","Most common; clear word boundaries"],["**camelCase**","`customerName`, `orderDate`","Common in ORM mapping; Java/C# style"],["**lowercase**","`customername`, `orderdate`","Not recommended; poor readability at scale"]],"headers":["Convention","Example","When to Use"]},"type":"table"},{"data":{"content":"**Recommended**: Use **snake_case** for attributes, especially when the physical database will use the same convention. This provides clear word separation and is the dominant convention in SQL schemas.\n\n**Key Attribute Naming**\n\nPrimary key attributes deserve special attention:\n\n1. **Surrogate Keys**: If using synthetic identifiers, follow a consistent pattern:\n - `id` — Simple, but ambiguous in joins\n - `entity_id` — e.g., `customer_id`, `order_id` — Explicit and unambiguous\n\n2. **Natural Keys**: Name them descriptively:\n - `isbn` (for Book)\n - `ssn` (for Person, if appropriate)\n - `email` (if serving as a unique key)\n\n**Recommended**: Use `entity_id` pattern for surrogate keys. This makes joins self-documenting:\n```sql\n-- Self-documenting join\nSELECT * FROM Order o\nJOIN Customer c ON o.customer_id = c.customer_id\n\n-- Ambiguous join (what is o.id joining to?)\nSELECT * FROM Order o\nJOIN Customer c ON o.id = c.id -- Wrong!\n```"},"type":"text"},{"data":{"icon":"Info","title":"Foreign Key vs Primary Key Names","content":"A foreign key should typically have the same name as the primary key it references. If `Customer` has `customer_id` as its primary key, then `Order` should have a foreign key named `customer_id`—not `cust_id` or `customer`. This consistency makes join conditions obvious and reduces errors.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"relationship-naming","title":"Relationship Naming Conventions","content":[{"data":{"content":"$6d"},"type":"text"},{"data":{"left":[{"data":{"items":["`Places` — Customer places Order","`Enrolls_In` — Student enrolls in Course","`Supervises` — Manager supervises Employee","`Contains` — Order contains LineItem","`Authors` — Researcher authors Paper","`Resides_At` — Person resides at Address"],"title":{"icon":"CheckCircle","text":"Good Relationship Names","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["`Has` — Too generic; has what? how?","`Links` — Describes mechanism, not meaning","`R1` — Meaningless identifier","`CustomerOrder` — This is not a verb","`Related_To` — Every relationship relates","`(unnamed)` — Missing name entirely"],"title":{"icon":"XCircle","text":"Problematic Relationship Names","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Reading Relationships as Sentences**\n\nA well-named ER diagram can be read as a series of simple sentences. This serves as a validation technique:"},"type":"text"},{"data":{"rows":[["Entity1 —Verb→ Entity2","Customer places Order","✓ Makes business sense"],["Entity (Role) —Verb→ Entity","Manager supervises Employee","✓ Role clarifies ambiguity"],["Entity —Verb→ Entity (with cardinality)","Customer places (one or more) Orders","✓ Cardinality fits reality"]],"headers":["Relationship Pattern","Example Sentence","Validation"]},"type":"table"},{"data":{"content":"**Self-Referential Relationship Naming**\n\nWhen an entity relates to itself, role names become essential:\n\n- `Employee` —Supervises→ `Employee` (as Supervisor → Subordinate)\n- `Person` —Is_Parent_Of→ `Person` (as Parent → Child)\n- `Part` —Contains→ `Part` (as Assembly → Component)\n\nWithout role names, these relationships are ambiguous. Which side is the supervisor? Both ends look identical.\n\n**Ternary and Higher-Order Relationships**\n\nFor relationships involving three or more entities, the name should encapsulate the combined semantics:\n\n- `Supplier` + `Part` + `Project` → `Supplies_For` (Supplier supplies Part for Project)\n- `Doctor` + `Patient` + `Treatment` → `Prescribes` (Doctor prescribes Treatment for Patient)\n- `Student` + `Course` + `Semester` → `Enrolls_During` (Student enrolls in Course during Semester)"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Sentence Test","content":"For every relationship, construct a sentence using the entity and relationship names with cardinality. 'Each Customer places zero or more Orders.' 'Each Order is placed by exactly one Customer.' If the sentence sounds awkward or false, reconsider your naming or modeling.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"constraint-naming","title":"Constraint Naming Conventions","content":[{"data":{"content":"While constraints are primarily a physical schema concern, naming them consistently reduces debugging time and improves maintainability. Error messages that reference `SYS_C00123` are unhelpful; `FK_Order_Customer` tells you exactly what went wrong.\n\n**Constraint Naming Patterns**\n\nStandardize constraint names using a prefix that indicates the constraint type, followed by the table(s) and column(s) involved:"},"type":"text"},{"data":{"rows":[["Primary Key","`PK_`","`PK_TableName`","`PK_Customer`"],["Foreign Key","`FK_`","`FK_ChildTable_ParentTable`","`FK_Order_Customer`"],["Unique","`UQ_`","`UQ_TableName_ColumnName`","`UQ_Customer_Email`"],["Check","`CK_`","`CK_TableName_Description`","`CK_Order_PositiveAmount`"],["Default","`DF_`","`DF_TableName_ColumnName`","`DF_Order_Status`"],["Index","`IX_`","`IX_TableName_ColumnName`","`IX_Order_OrderDate`"]],"headers":["Constraint Type","Prefix","Pattern","Example"]},"type":"table"},{"data":{"content":"**Foreign Key Naming in Detail**\n\nForeign keys are the most common source of constraint errors. A clear naming convention makes troubleshooting immediate:\n\n```\nFK__[_]\n\nExamples:\nFK_Order_Customer -- Order references Customer\nFK_OrderLine_Order -- OrderLine references Order\nFK_OrderLine_Product -- OrderLine references Product\nFK_Employee_Employee_Mgr -- Self-reference with role clarification\n```\n\nWhen an error like `FK_Order_Customer violation` occurs, you immediately know: an operation on Order failed because the referenced Customer doesn't exist (or is being deleted with dependent orders)."},"type":"text"},{"data":{"icon":"Info","title":"System-Generated vs Named Constraints","content":"Most database systems generate constraint names if you don't specify them (e.g., SYS_C00123456). Always explicitly name your constraints. The upfront effort saves hours of debugging when constraint violations occur in production.","variant":"note"},"type":"callout"},{"data":{"content":"**Index Naming**\n\nIndexes support query performance and should be named to indicate their purpose:\n\n```\nIX__[_Column2...]\n\nExamples:\nIX_Order_OrderDate -- Index on order date for range queries\nIX_Order_CustomerID -- Index for customer lookup\nIX_Product_CategoryID_Price -- Composite index\n```\n\nFor unique indexes that aren't constraints:\n```\nUIX__ -- Unique index\nCIX_ -- Clustered index (if explicitly named)\n```\n\n**Check Constraint Naming**\n\nCheck constraints validate data values. Name them to indicate what they check:\n\n```\nCK__\n\nExamples:\nCK_Order_PositiveQuantity -- Quantity must be > 0\nCK_Employee_ValidSalary -- Salary within valid range\nCK_Product_StatusValid -- Status in allowed value list\n```\n\nThe description should hint at the rule without spelling out the entire predicate—that's in the constraint definition itself."},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"naming-standards-document","title":"Establishing a Naming Standards Document","content":[{"data":{"content":"$6e"},"type":"text"},{"data":{"code":"$6f","variant":"default","fileName":"naming-standards-excerpt.md","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Living Document Principle","content":"A naming standards document should be version-controlled, reviewed periodically, and updated as the organization learns. New edge cases will arise; the document should evolve to address them while maintaining backward compatibility.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"legacy-migration","title":"Handling Legacy Systems and Migration","content":[{"data":{"content":"$70"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Hidden Dependencies","content":"Renaming database objects affects more than you see. Stored procedures, scheduled jobs, ETL pipelines, BI reports, external integrations, and documentation all may contain hardcoded references. Discovery before renaming is essential—surprises during migration are costly.","variant":"warning"},"type":"callout"},{"data":{"content":"**Building a Transition Glossary**\n\nFor organizations in transition, maintain a glossary that maps old names to new names:"},"type":"text"},{"data":{"rows":[["`CUST_MSTR`","`Customer`","Table","View abstraction in place"],["`CUST_ID`","`customer_id`","Column","Pending"],["`ORD_HDR`","`Order`","Table","Not started"],["`ORD_DTL`","`OrderLineItem`","Table","Not started"]],"headers":["Legacy Name","New Name","Table/Object Type","Migration Status"]},"type":"table"},{"data":{"content":"This glossary serves multiple purposes:\n- Onboarding: New team members understand both old and new conventions\n- Development: Developers know which name to use where\n- Tracking: Migration progress is visible\n- Communication: Stakeholders see incremental improvement"},"type":"text"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The Discipline of Naming","content":[{"data":{"content":"Naming is the first and most persistent decision in data modeling. Every query written against your schema, every application mapping, every report column header reflects the names you chose at design time.\n\nWe've covered extensive ground on establishing rigorous naming practices:"},"type":"text"},{"data":{"type":"ordered","items":["**Naming choices propagate throughout the system** — A name at design time becomes table names, column names, class names, and documentation across the entire application lifecycle.","**Entities use singular nouns in PascalCase** — Clear, domain-aligned names that read naturally and distinguish entity types from their instances.","**Attributes use descriptive snake_case with standardized suffixes** — Consistent patterns (_id, _date, _flag) create recognizable, self-documenting schemas.","**Relationships are active verbs that form readable sentences** — The 'sentence test' validates both naming and semantics.","**Constraint names should be explicit, not system-generated** — Named constraints dramatically reduce debugging time when violations occur.","**Organizational alignment requires a Naming Standards Document** — Written conventions ensure consistency across teams and time.","**Legacy systems require pragmatic migration strategies** — Views, glossaries, and incremental refactoring bridge old and new conventions."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next**\n\nNaming conventions define *what* we call elements. The next page addresses *where* we place them—the principles of **diagram layout** that transform a technically correct model into one that communicates effectively at a glance."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the principles and practices of naming conventions in ER modeling. Thoughtful naming is an investment in clarity, maintainability, and team productivity that pays dividends throughout the system's lifetime.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_d58e2e520921a9efd72f7eb3f6495075","title":"Diagram Layout","order":1,"content":null,"isLocked":true},{"id":"seed_ee7d595165d41367b84aaeaab03ee6f2","title":"Documentation","order":2,"content":null,"isLocked":true},{"id":"seed_dd359e719aa3823104746db9ac016e53","title":"Common Mistakes","order":3,"content":null,"isLocked":true},{"id":"seed_0403d48a89234f074303eaf42bf64c82","title":"Review Checklist","order":4,"content":null,"isLocked":true}]}}