Lesson 1 — Purpose, Requirements, and Core Components
Data modeling is a discipline of agreement before it is a diagram
Chapter 5 defines data modeling as the process of discovering, analyzing, and scoping data requirements and then representing and communicating those requirements precisely in a data model. The order matters. The model is not supposed to be an attractive picture created after technical decisions have already been made; it is the controlled representation of what the organization has learned and agreed about its data.
A useful mental picture is a construction project. Business people may say, “We need a customer portal.” That statement is not yet a data design. Modeling asks what Customer means, what information must be remembered, what makes one customer different from another, which business events connect Customer to Order or Account, which values are valid, and which rules must remain true when technology changes.
Why models matter
Models act as important Metadata and communication artifacts. They help an organization:
- create a shared vocabulary;
- make implicit knowledge explicit;
- define project scope;
- retain knowledge that otherwise lives in people’s heads;
- communicate requirements among business people, analysts, architects, designers, developers, and DBAs;
- support application customization, integration, replacement, Master Data Management, Data Governance, and architecture work;
- reduce rework by finding ambiguity before implementation.
A model therefore has value even when no new database is being built.
Exam trap: model ≠ diagram
A model is the complete representation and can contain multiple diagrams, definitions, rules, issues, lineage, and supporting Metadata. A diagram is one visual view of that representation. If a question says “the diagram looks good,” do not assume the model is complete.
Four broad kinds of data Chapter 5 says organizations model
| Type | What it does | Examples / clue |
|---|---|---|
| Category information | Classifies or assigns types | product color, order status |
| Resource information | Describes enduring resources used by operations | Customer, Supplier, Facility, Organization, Account |
| Business event information | Records operational occurrences | Order, Supplier Invoice, Cash Withdrawal, Business Meeting |
| Detail transaction information | Captures fine-grained, often high-volume interaction detail | POS line detail, clickstream, sensor reading |
The distinction is purpose and granularity, not whether all four eventually live in the same technology.
Four core model components
Entity
An entity is a type or concept about which the organization collects information. Student is an entity. One particular student — for example, Jane — is an entity instance.
Think type vs occurrence.
Chapter 5 also uses familiar semantic categories such as Who, What, When, Where, Why, How, and Measurement as useful ways to recognize candidate entities. These are thinking aids, not a rule that every model must contain exactly seven entity groups.
A good entity definition should be clear, accurate, and complete. Those definition qualities are easy to confuse with later model-review qualities.
Relationship
A relationship expresses an association among entities. “Student enrolls in Course” is a relationship. The relationship captures a business rule; it is not merely a line drawn to make a diagram connected.
Attribute
An attribute is a property that identifies, describes, or measures an entity. Student Birth Date, Course Title, or Order Amount are attributes.
Domain
A domain defines the complete valid value set or value structure for an attribute. Order Status is an attribute; {Open, Closed, Cancelled} can be its domain.
This distinction is fundamental:
Attribute = the property. Domain = what values are valid for that property.
Stop-and-check
- Why is “we already have a physical schema” not a complete answer to a data-modeling requirement?
- Classify
Student, one named student,Student Birth Date, and the allowed range of birth dates. - Explain why a model can be useful Metadata even when no new database is being created.
Answer check
- Modeling begins with requirements/meaning and can span conceptual, logical, and physical levels plus definitions, issues, and lineage. A schema is one implementation representation.
Student= entity; named student = instance;Student Birth Date= attribute; allowed values/rules = domain.- It preserves explicit organizational knowledge, vocabulary, rules, scope, and relationships that support communication and governance.
Source anchors: Chapter 5 introduction and core components, current Mastery Lab pp. 123–135.