Data Model Patterns
"The same components are used repeatedly but configured differently", similar to how a differential works in 2-wheel drive, 4-wheel drive with two differentials, and 4-wheel drive with three differentials vehicles. This highlights the concept of modularity and adaptability in system design, where standardized components can be reconfigured to serve various purposes or contexts.
"The function of the differential remains the same": an input drive shaft results in two output drive shafts that can rotate at slightly different speeds, while the placement of these differentials varies. This illustrates that while the arrangement or context may change, the core functionality of components remains consistent, ensuring predictable behavior across different implementations.
Land titles offices and mineral licenses registers share common components, and organizations may reuse patterns and interrelationships uniquely. This suggests that leveraging existing patterns and relationships can streamline development efforts and promote consistency across different domains or projects within an organization.
Prioritize team comfort with data model patterns, suggesting a review of materials and appendix patterns. Ensuring that team members are familiar with and comfortable using data model patterns can improve collaboration, reduce errors, and accelerate project delivery.
Assemble a lightweight Enterprise Framework (in days):
An enterprise model framework should be used as the foundation for the Data Vault. This provides a structured approach to organizing and managing data assets within an organization.
In its early phases, it can be a one-page diagram showing icons for each pattern, relationship labels, and extra notes on subtypes. This emphasizes the importance of visualization and communication in conveying complex concepts and relationships within the data model.
Examples are shown in Figures 26, 27, and 39 (subtypes are not shown). These figures probably demonstrate how subtypes can be represented or visualized within the data model.
Run two-day workshops to get business and technical people to work together:
The first day involves hands-on exercises with pre-packaged materials in a wildfire emergency response scenario. This provides a practical and engaging way for participants to learn and apply data model patterns in a realistic context.
The goal is to provide perspective unburdened by organizational issues. This helps participants focus on the underlying principles and concepts without being constrained by existing organizational structures or processes.
On the second day, participants apply patterns to their own situations or directly introduce the patterns in their world. This allows participants to tailor the patterns to their specific needs and challenges, promoting adoption and ownership.
Preparation Steps include:
Pick the team (Step #1).
Define the "enterprise" (Step #2), such as the emergency response organization and related agencies during wildfires. Defining the scope of the enterprise helps to focus the modeling efforts and ensure that the resulting data model is relevant and useful.
Team conducts background research on frontline worker roles (Step #3); however, caution is advised against getting too close to the action. Background research helps to inform the modeling process, but it's important to maintain a level of objectivity and avoid getting bogged down in unnecessary details.
Ensure the facilitator grasps foundational data model patterns (Step #4). A knowledgeable facilitator is essential for guiding the workshop and ensuring that participants understand the data model patterns.
Actual workshop preparation includes:
Confirming participant availability, reserving a room equipped with a projector and a screen, and ensuring necessary equipment. Basic logistical considerations are important for ensuring a smooth and productive workshop.
Acquiring whiteboards for the facilitator and exercises. Whiteboards provide a collaborative space for participants to brainstorm and visualize data model patterns.
Photocopying the pattern palette from Figure 38 and the pattern of patterns from Figure 40. These visual aids help participants to understand the data model patterns and how they relate to each other.
Workshop Kick-off:
Address logistical details (kitchen, restrooms, exits) as well as provide participants an opportunity to describe roles. Setting the stage for the workshop is important for creating a comfortable and productive learning environment.
They should also share perspectives, including issues and future aspirations. Encouraging participants to share their perspectives helps to surface valuable insights and ensure that the data model meets their needs.
Pattern introduction: Many participants, possibly half, may not possess an IT background, which can make the concept of data models intimidating, even among IT professionals with restricted exposure to data model patterns.
Start with one pattern, ideally Party / Party Role, to explain what a pattern is. Starting with a simple and familiar pattern helps to ease participants into the topic and build their confidence.
The Party / Party Role pattern is portrayed as an extension of a phone's address book, which includes people, organizations, names, addresses, and contact information. This analogy helps participants to understand the pattern in terms of something they are already familiar with.
The pattern is relatively easy to understand with recorded interrelationships. The Party / Party Role pattern is commonly used and well-understood, making it a good starting point for learning about data model patterns.
Introduce two more uncomplicated patterns: the Agreement and Document patterns. Gradually introducing additional patterns helps to build participants' understanding and avoid overwhelming them.
The Agreement pattern connects to the Party / Party Role pattern, and the Document pattern connects to the Agreement pattern. These connections illustrate how patterns can be combined to model more complex relationships.
The Agreement pattern description is available in the Appendix section named “Pa ern: Agreement“, while Figure 115 shows how the Party / Party Role pattern frequently connects to the Agreement pattern. These references provide additional information and context for the patterns.
The Document pattern description is available in the Appendix section named “Pa ern: Document“, which illustrates its position within an emerging landscape. This description helps to understand where the Document pattern fits within the broader context of data modeling.
Handing out the "Palette of Patterns" (Figure 38 and Figure 41) and discussing each icon’s principles is crucial. The Palette of Patterns provides a visual overview of the available patterns and their key characteristics.
Introducing Pattern Combinations:
Explain how patterns integrate in real-world contexts with enterprise data model schematics. Explaining how patterns are used in practice helps participants to understand their relevance and applicability.
Samples from Figures 26 and 27 and the related text are excellent for starting conversations. These examples provide concrete illustrations of how patterns can be combined to model complex scenarios.
Beginning Model Construction:
Divide workshop attendees into groups with both business and IT staff to encourage diverse opinions and discourse. Encouraging diverse perspectives helps to ensure that the resulting data model meets the needs of all stakeholders.
Emphasize the significance of both viewpoints. Both business and IT perspectives are essential for creating a data model that is both accurate and practical.
The groups should start with an overview model with patterns that indicates the key components of an enterprise. Starting with an overview model helps to establish a common understanding of the enterprise and its key components.
David Hay’s Conceptual Models:
Overview model: Enables communication between business and IT sectors. The overview model serves as a common language for communication between business and IT stakeholders.
Semantic models: Displays various perspectives across the organization. Semantic models provide a more detailed view of the data and its relationships, tailored to specific perspectives within the organization.
Essential model: Consolidates views to address conflicting perspectives. The essential model resolves conflicts and provides a unified view of the data, ensuring consistency across the organization.
Every participant needs an individual copy of the “Palette of Pa erns” and an extra copy to take notes on as a group. This ensures that everyone has the resources they need to participate fully in the workshop.
Initiate the process with the Party / Party Role pattern because everyone understands how parties (people and orgs) and their roles connect, despite complex pattern specifics. Starting with a familiar and intuitive pattern helps to build confidence and momentum.
For the fire accident scenario, the start involves writing essential roles next to the Party icon. This helps to focus the modeling efforts on the specific roles that are relevant to the scenario.
Government employees may have normal jobs but also have fire-related duties. This highlights the importance of capturing all relevant roles and responsibilities within the data model.
The state has organizations like the Country Fire Authority (CFA) whose volunteers are very highly respected. This acknowledges the importance of volunteer organizations in emergency response.
Firgighters on the front lines and an incident management team are also part of the team. These roles are key components of the emergency response organization and should be included in the data model.
Role Classification Critique:
Classifications are not always perfect, and refinement is needed such as "Are CFA volunteers also firefighters?", or "Should incident management roles be distinct?". This highlights the iterative nature of data modeling and the importance of refining classifications as needed.
Even an incomplete list enables beneficial conversations between business and IT sectors. Even an initial, incomplete list of roles can spark valuable discussions and help to clarify requirements.
Introducing the “Pattern of Patterns” Diagram:
Use a printed copy of “Pattern of Patterns” diagram (Figure 40). The Pattern of Patterns diagram provides a visual representation of the relationships between different patterns.
Use the diagram as a checklist for potential pattern interrelationships within the organization as more patterns are included. The diagram can be used to ensure that all relevant pattern interrelationships are considered.
After the Party / Party Role pattern, use the Agreement pattern. Agreements and Party relationships are typically and easily understood. The Agreement pattern is a natural extension of the Party / Party Role pattern and is often used to model contractual relationships.
Agreement Implementation:
An agreement can be signed between Australian emergency reps and an American water-bombing company. This provides a concrete example of how the Agreement pattern can be used to model real-world relationships.
Record discovered contract types manually. Recording contract types manually can help to identify common patterns and inform the data model.
Aircrafts are frequently leased from the Northern Hemisphere. This is because fire seasons for them and us are offset by about six months. This detail highlights the importance of considering seasonal factors when modeling agreements.
During off-peak season "controlled burns" are implemented, following prep, documentation, and approval. Controlled burns are an important part of fire management and should be included in the data model.
Seasonal firefighters can be university students. This highlights the diversity of roles involved in fire management.
Added "Supplier" role beneath the Party roles. The Supplier role represents organizations that provide goods or services related to fire management.
Agreement type examples include an aircraft supplier that corresponds to a party, which simplifies things. This example illustrates how the Agreement pattern can be used to simplify complex relationships.
Revisions Throughout real implementation, changes seem rapid. However, the established patterns keep the changes in check. Using established patterns helps to ensure that changes are consistent and well-understood.
Agreement and Document Relationships:
Documents may not always be linked to agreements or be centrally available. This highlights the importance of considering the different ways that documents can be related to agreements.
Some contracts are considered private or confidential, such as lease contracts or firefighter contracts. Confidentiality considerations should be taken into account when modeling document relationships.
Openly viewable electronic records are needed for burn plans. Burn plans require open access to ensure transparency and accountability.
There are documents not tied to agreements however like arson incident photos or videos from public. No agreement is needed for someone who sets a forest fire. This illustrates that not all documents are related to agreements and that other types of relationships may need to be modeled.
Introduce new patterns gradually and integrate them into the diagrams using hand-wri en subtypes and relationship links. Gradually introducing new patterns helps to build understanding and avoid overwhelming participants.
Share completed work-in-progress models for each team to adopt and encourage viewpoint variety. Sharing work-in-progress models encourages collaboration and helps to ensure that the data model meets the needs of all stakeholders.
Location: Geographic Information System (GIS) is a common implementation. GIS provides a way to model and analyze spatial data related to fire management.
GIS (location subtypes) are "layers", that can be turned on or off:
Roads help to find the best route to the fire. Roads are an important factor for determining the best route to the fire.
Water points help to collect water. Water points are essential resources for fighting fires.
Airports can be used by airplanes to fight the fire. Airports provide a base of operations for aerial firefighting efforts.
In the region, there are parks managed by government agencies, while private land managed by volunteer agencies so National and State Parks are important. Parks and other protected areas are important assets to consider in fire management.
Fire Ignition Points, fire line, burn area, and conservation zones can be points too. These are all important spatial features to consider in fire management.
The Resource or Asset pattern is organized by hierarchy and has a lot of varieties. Subtypes range from Fire Tankers to Vehicles. The Resource or Asset pattern is used to model the resources and equipment used in fire management.
There can be hundereds of subtypes and participants can include representative types in the workshop. Including representative subtypes helps to ensure that the data model is comprehensive and reflects the diversity of resources used in fire management.
Event sub-types include:
Notify central team regarding a fire, spotted by a tower or member of the public. This event type represents the initial notification of a fire.
Fire Cause Allegation: Suggesting the reasons could have been for arson, lightning or a simple campfire. This event type represents the investigation into the cause of a fire.
Status Changes: Event for changing the designation of a fire. This event type represents changes in the status of a fire.
Safety incident: A firefighter may be hurt while performing duties. This event type represents incidents that affect the safety of firefighters.
Communication: Example can be a public SMS message warning people to evacuate. This event type represents communications related to a fire.
Pattern Interrelationships:
Events and tasks are bidirectional. Events and tasks are often related to each other in a bidirectional manner.
The Fire Detection event sparks tasks to assemble and dispatch the first response team. This example illustrates how an event can trigger a task.
The team assesses the fire cause and suspects arson, triggering a Fire Cause Allegation. This example illustrates how a task can trigger another event.
Forensic specialists evaluate the fire cause, which then causes additional tasks. This example illustrates how a task can trigger additional tasks.
Workshop Participants:
First Response. First responders are the first on the scene of a fire.
Fire Cause Forensic Analysis. Forensic specialists investigate the cause of fires.
Fire Line Suppression. Fire line suppression teams work to contain and extinguish fires.
Training/Fitness Assessment: Prepares the team for the fire season. Training and fitness assessments ensure that firefighters are prepared for the fire season.
Tasks such as enforced Rest, Rostered Days Off, and Leave are non-work tasks that go into a calendar. These are examples of non-work tasks that are important for managing firefighter schedules.