WELL XREF
Contents |
Table Use Recommendations
This table is important when wells or well components need to be related to each other. The use of well components is described in What_is_a_Well.
Components of the well table
The WELL Table can be used to store information about Planned and actual wells and for most well components:
Each component should be described on a separate row in the WELL table, using the column WELL_LEVEL_TYPE to state which kind of component you are capturing. When you are done, you may have several rows in the WELL table.
The WELL_XREF table is used to capture the relationships between the various components.
- A Well Set is related to all the objects that make up the set. In some cases, this may include rows for planned and for actual wells, for service or remediation wells in addition to rows for all the components of the well set.
- A Well Origin is typically related to all of the Wellbore components that originate at that surface location.
- A Wellbore is related to the Wellbore Segment components that intersect it, the Wellbore Completion components that it contains, and possibly the Wellbore Contact Interval components that are contained by the completions.
- A Wellbore Completion is related to the Wellbore Contact Interval components that are contained in the completion.
As you populate this table, you can store relationships atomically as parent - child pairs, or you can capture a parent with ALL of the child components that it contains. There are pros and cons to each approach:
Atomic pairs
In this case, you would store these relationships:
- Well set --> Wellbore
- Wellbore --> Wellbore Segment
- Wellbore Segment --> Wellbore Completion
- Wellbore Completion --> Wellbore Contact Interval
Obviouisly, if your data is missing one or more of these levels, you would skip that relationship - don't make them up if you don't know them!!
The advantage is that the relationships are only stored once, so it's less likely for the data to become corrupted (you only have one place to update if the relationship changes). The key disadvantage is that it's a bit more difficult to query, since you would need to use a "connect by" kind of syntax to walk down that relationship tree. That makes your queries a little slower.
Capture the hierarchy
In this case, you would store the relationships from a parent to ALL of the components that are related to it. So, you could end up with(depending on how much data you have available):
- Well Set is related to all the other components
- Wellbore is related to the Wellbore Segments, Wellbore Completions and Wellbore Contact Intervals that it contains
- Wellbore Segments is related to the Wellbore Completions and Wellbore Contact Intervals that it contains
- Wellbore Completions is related to the Wellbore Contact Intervals that it contains
The advantage for this option if you find a parent, you can very easily find all of the components that are in it. Queries are easier to write and faster. However, the disadvantage is that if you need to make a change to the well structure, you have to be quite careful that you update ALL of the necessary relationships - if you miss one the folks who deal with the data later will get very confused and your queries may not return the right data.
Making a decision
When you decide how you are going to manage these relationships, you will have created a Business Rule. It's very important that these be documented very carefully, and that they be followed very consistently. If you do this one way for one project and then another way for another project your data will be very difficult to understand!
We recommend that Business Rules be described in the PPDM DATA MANAGEMENT module.
Table Comment
WELL CROSS REFERENCE: Supports complex relationships between wells. For example, a planned well and the actual well that was drilled, or more complex relationships between a parent well and well bores, re-entries, such as re-completions, side bores etc can all be captured.
