- Views of Data
- A Brief History of Data Architecture
- Advanced Data Management·Meta-data
- Graphics·Data Modeling
- Using Entity/Relationship and Object Models
- Normalization
- Data Modeling Conventions
- Entity/Relationship Model Validation
- The Requirements Analysis Deliverable·Column One
- Data and the Other Columns
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Data and the Other Columns
Data and Activities
In conjunction with the Column Two part of the project, the Requirements Analysis project should deliver an activity/entity cross reference (“CRUD Matrix”). This allows for finding activities without entity types and entity types without activities. Activities without entities may be spurious, or they may be a sign that something was overlooked in the data model. Entity types without activities may simply mean that maintenance activities were overlooked. (See more on the activity/entity type matrix on page 195.)
Data and Locations
There have always been two issues when one sets out to build a distributed database: Where should the data reside? Where are they to be used? This is one case, however, where technology is rapidly rendering these questions less important. It is now possible to make the data in all entities available everywhere. Still, when the physical database configuration is being laid out, it will be useful to know the locations from which data for each entity type will come, and the locations where they will be used.
Data, People, and Organizations
A very important part of the documentation for a data model is identification of the roles (if not the individual people) who will be responsible for each entity type and attribute. Certain people will “own” an entity type, meaning that those people are ultimately responsible for its data quality. The same or other people are responsible for updating it. Yet others have permission to see it. This matrix is required if data quality is to be established.
Documentation of each entity type should include identification of at least the role responsible for the quality of its information, if not the individual person so responsible.
Data and Timing
In Chapter 7 is defined the “entity life history” technique for describing the states an occurrence of an entity type can go through in the course of its life. Understanding the structure of data, as revealed in an entity/relationship diagram, does not completely reveal the nature of the entities involved. It is in the life history—the succession of states—that this is revealed. State/transition diagrams show that sequence of states. Entity life histories show how timing (events) determines the passage of entities from one state to another.
Data and Business Rules
Fundamentally, business rules are about data. In Row Three, especially, a business rule constrains what data may be or must be created in the course of business operations. The discovery and definition of business rules must be carried out in conjunction with the development of the data model.