 |
Description  |
|
|
FIELD OF THE INVENTION
This invention relates in general to computer database management systems,
and in particular to a database management system which manages multiple
versions of data.
BACKGROUND OF THE INVENTION
Modern computer installations generate, manipulate, and store enormous
quantities of data. Data base management systems have emerged as an
indispensible component of such installations, serving the purpose of
promoting efficient data storage and program design, enhancing file
maintenance and modification, and eliminating data redundancy. The typical
data base management system (DBMS) includes programs which interface with
designers and users, accept and understand models or tables for subsequent
use in organizing data, organize data according to the models or tables,
store and retrieve the data in the actual data base contained in a
computer storage subsystem, perform queries on the data, and generate
reports based on the stored data.
A DBMS may be designed to store data according to any of a variety of data
models, where the data model is the basic organizational concept for the
underlying data base. These models, or schemas, for data base organization
can be divided into several different classes, including hierarchical,
network, relational, and entity- relationship. A detailed discussion of
these types of databases may be found in "The Database Book," by Mary E.
S. Loomis, Macmillan Publishing Company, New York, N.Y. 10022 (1987). The
present invention is applicable to all of the above database schemas. The
preferred embodiment is described with particular reference to the
entity-relationship modelling methodology provided by the Repository
Manager/MVS product, which uses the DB2 relational DBMS as a back end to
manage the storage and retrieval of data on the computer hardware.
Entity-relationship databases are discussed in "The Entity-Relationship
Model--Towards a Unified View of Data," by Peter Chen, ACM Trans. on Data
Base Systems, Vol. 1 (1976). Relational databases and DB2 in particular is
discussed in "IBM Database 2: General Information," IBM Publication
GC26-4373 (1990). The Repository Manager/MVS product is discussed in
"Repository Manager: Concepts and Facilities," IBM Publication SR21-3608
(1990).
A significant problem in maintaining any data base whose data entries
represent objects, events, people, or relationships in the real world, is
that although those things may change over time, the typical DBMS
maintains only a single version of any given entry, making it impossible
to concurrently represent a thing in its past, present, and future states.
A second significant problem, which arises in maintaining a data base
which is shared among a plurality of users, involves the toleration of
concurrent but independent work on the same data entries by different
users without sacrificing the semantic consistency of the data. Yet a
third problem in maintaining a data base involves maintaining a record of
the state of the data base itself as it existed at given times in the
past. Such information is often needed for error recovery and for
audit-trail purposes. Typical solutions to this problem involve taking
"snapshots" of the data base and logging change activity, so that if
necessary the data base can be "reconstructed" as it existed at some point
in the past. This reconstruction is usually a time-consuming batch
procedure, and a system so constructed cannot allow the past and current
data bases to be accessed concurrently.
A solution to all of these problems is to maintain versions of the data
entries. These versions may correspond to the different states of the
real-world things represented, or to work in progress by different users.
Such an approach is called versioning, and in general requires that the
DBMS control the creating of the versions and all access to them, both to
assure the semantic consistency of the data in all its versions, and to
free users from the need to deal with the additional complexity that such
a versioning scheme requires. Users of non-versioned data base systems
sometimes simulate versioning by giving qualified names to the data base
entries. However, this approach is undesirable, because it conceals from
the DBMS the true identity of the things represented, and makes it
impossible for the DBMS to verify the semantic consistency of the data
base.
The generally preferred approach to implementing versioning is to provide
direct versioning of entries in the DBMS, with the versioning managed by
the DBMS to preserve the semantic validity of the data in the system. Such
a system provides both parallel and serial versioning, with the capability
for the user to define a hierarchy of versions, and to direct the DBMS to
move versions of data from one hierarchy level to another. It also
provides historical versioning of the database, allowing the user to view
the data as it existed at any arbitrarily-selected time in the past. It
provides a simplified programming interface that allows a user tool to
interact with the data as though it were not versioned, the specification
of which version is seen being made outside the program.
A versioned entity-relationship database management system (VDMS) typically
includes several external interfaces for use in manipulating entities and
relationships in the database. These interfaces make versioning
transparent to the user. The add interface is an external interface for
adding an entity or relationship. The instance added may or may not be the
first version of the entity or relationship. The update interface is an
external interface for updating an entity or relationship. An update may
or may not result internally in the creation of a new version of the
entity or relationship. The delete interface is an external interface for
deleting an entity or relationship. A delete does not result internally in
the deletion of an instance. It may or may not result internally in the
creation of a new version of the entity or relationship, which is flagged
as "deleted." The retrieval interface is an external interface for finding
out what entities exist and what their properties are, including the
relationships in which they are involved.
In ER data management systems generally, when an entity is updated it
retains all of its relationships, and when an entity is added it starts
with no relationships. However, satisfying both of these requirements
presents special problems for ER database management systems having
versioning capability. The first problem involves relationship
preservation during update. In a VDMS whose interfaces make versioning
transparent, when the update interface is used to update an entity, a new
version of the entity may be created by the VDMS. As long as the part key
of the entity is not changed, if the retrieval interface is used to find
out what relationships the entity is the source or target of, it should
yield the same results before and after the update.
The second problem involves relationship absence after add. In a VDMS whose
interfaces make versioning transparent, when the add interface is used to
add an entity, there may already be versions of that entity which exist
but are not seen from the current point of view. There may also already be
relationships of which those entity versions serve as the source or
target. After the entity is added, the retrieval interface should indicate
that the entity is not the source or target of any relationships from the
current point of view.
One way to satisfy the principle of "relationship preservation during
update" is to have each relationship instance connect a specific version
of a source to a specific version of a target, but when a new version of
the relationship source or target is created via the update interface,
automatically create new relationship instances connecting the new source
or target version to all of the same instances the previous version was
connected to. However, this can result in an enormous number of
relationship instances. Consider the simple case of two entities connected
by a relationship. If the update interface were used to update each entity
five times, creating a new entity version each time, twenty five
relationship instances would result, thus, in practice, and particularly
for a VDMS which creates revisions to track past states of an entity, this
approach is not feasible.
Another way to satisfy the principle of "relationship preservation during
update" is to have each relationship instance connect any version of a
source to any version of a target. However, this can cause problems
satisfying the principle of "relationship absence after add" if the
relationship source and target are identified by their part keys. For
example, consider the following sequence of events, which deals with two
entities (A and B) and a relationship between them (A.B). The example
assumes a two-level variant hierarchy with Production as the root variant,
and Test as its only child. Therefore, the search path for the Test point
of view is Test.fwdarw.Production, and the search path for the Production
point of view is Production.
1. From the Production point of view, the add interface is used to add a
Production version (the first version) of two entities A and B. These
instances are seen from both the Production the Test points of view.
2. From the Test point of view, the delete interface is used to delete the
entity A. A "deleted" Test version of A is created. The Production version
of A is still seen from the Production point of view.
3. From the Production point of view, the add interface is used to add a
Production version (the first version) of relationship A.B. This instance
is seen from the Production point of view. In some VDMS's, A.B might also
immediately become part of the Test point of view, while in others, it
might only become part of the Test point of view after some action is
taken to refresh the Test point of view with recent changes from the
Production point of view. In either case, once A.B becomes part of the
Test point of view, it does not serve to connect A and B there, because A
has been deleted.
4. From the Test point of view, the add interface is used to re-add entity
A. A Test version of A is created.
5. From the Test point of view, which includes relationship A.B, the
retrieval interface is used to find out what relationships A is the source
or target of. Because we have assumed that relationships connect any
version of their source to any version of their target, A is found to be
related to B via relationship A.B, in violation of the principle of
"relationship absence after add."
Thus, the above methods fail to provide for both relationship preservation
during update and relationship absence after add in a manner that does not
result in excessive multiplicity of data. Moreover, no other method has
heretofore been available which provides a VDMS with the ability to
resolve sources and targets of relationships while complying with these
requirements.
SUMMARY OF THE INVENTION
In accordance with the present invention, a versioned entity-relationship
data management system is provided with a method for resolving sources and
targets of relationships. For each entity instance, a lifetime ID is
recorded. When the add interface is used to add an entity, a value is
assigned to the lifetime ID, which value has never been used before for an
instance of the entity type. When the update interface is used to update
an entity, the lifetime ID is maintained unchanged. If the update results
in a new version, the new version is given the same lifetime ID value as
that for as the version that was the basis for the update. Thus, once the
add interface has been used to add an entity, all versions of the entity
produced by subsequent uses of the update interface have the same lifetime
ID as the original version. If the delete interface is then used to delete
the entity, and the add interface is later used to add an instance with
the same part key, that instance will have a different lifetime ID.
For each relationship instance, lifetime IDs are recorded for the
relationship, its source, and its target. These lifetime IDs do not
include a specific version of the source or target for the relationship.
When the add interface is used to add a relationship, a value is assigned
to the lifetime ID, which value has never been used before for an instance
of the relationship type. Also, the lifetime IDs of the source and target
of the relationship are recorded in the relationship instance. When the
update interface is used to update a relationship attribute, the lifetime
ID of the relationship and the lifetime IDs of the source and target are
maintained unchanged. If the update results in a new version of the
relationship, the new version is given the same lifetime ID value as that
for the version that was the basis for the update.
Within the scope of the part types which are defined as the source and
target of a relationship type, each instance of a relationship serves to
connect any version of the part whose lifetime ID matches that specified
for the source, and which has not been deleted, with any version of the
part whose lifetime ID matches that specified for the target, and which
has not been deleted.
Using a given variant map, if the retrieval interface indicates that a
given entity is the source of a given relationship, and the update
interface is then used to update that entity, the same version of the
relationship still connects the new version of the entity to its target,
since the lifetime ID was not changed in the entity instance and the
entity version was not recorded in the relationship. Thus, relationships
are preserved during an update. When the add interface is used to add an
entity, it is assigned a never-before-used lifetime ID, which cannot
therefore be recorded in any already-existing relationship instance. Thus,
relationships are absent after an add.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating the components of a computer system
for use in conjunction with the present invention.
FIG. 2 is a block diagram representation of a part in an instance diagram.
FIG. 3 is a block diagram representation of variants in an instance
diagram.
FIG. 4 is a block diagram representation of effective time variants in an
instance diagram.
FIG. 5 is a block diagram representation of revisions in an instance
diagram.
FIG. 6 is a block diagram of a derivation graph.
FIG. 7 is a diagrammatic representation of the components of an entity
instance key.
FIG. 8 is a diagrammatic representation of the components of a relationship
instance key.
FIG. 9 is a diagrammatic representation of search paths.
FIG. 10 is a block diagram illustrating a variant hierarchy for a variant
domain.
FIG. 11 is a block diagram illustrating variant hierarchies for the Pay,
Com, and Inv variant domains.
FIG. 12 is a block diagram illustrating two variant hierarchies with
variant maps.
FIG. 13 is a diagrammatic representation of a variant map example.
FIG. 14 is a diagrammatic representation of another way to define variant
maps.
FIG. 15 is a flowchart illustrating a procedure for setting and maintaining
the lifetime ID of a version of an entity.
FIG. 16 is a flowchart illustrating a procedure for setting and maintaining
the lifetime ID of a version of a relationship.
FIG. 17 is a flowchart illustrating a procedure for determining whether a
relationship connects a source and target.
DETAILED DESCRIPTION OF THE INVENTION
1.0 GLOSSARY OF TERMS
To facilitate understanding the present invention and the versioning
architecture in which it is implemented, the following glossary of terms
is provided. It is to be noted that terms used in the specification but
not included in this glossary are considered as defined according the
normal usage of the computer science art, or alternatively according to
normal dictionary usage.
active revision. A revision which is still allowed to undergo changes.
Changes to the revision are made in place, i.e. without causing a new
revision to be created. All revisions are either active or frozen.
active version. A version which is still allowed to undergo changes.
Changes to the version are made in place, i.e. without causing a new
version to be created. All versions are either active or frozen.
add. A request to a VDMS to create a new part. The part must not have been
visible from the view of data of the requestor.
alternate search path. Any search path that is based on an alternate
variant hierarchy and hence can be used only for retrievals of data in the
repository, not for changes to that data.
alternate variant hierarchy. Any variant hierarchy for a variant domain
other than its primary variant hierarchy. Search paths based on an
alternate hierarchy can be used to retrieve repository data, but not to
perform changes to it.
attribute. A value associated with an entity. Each entity type has
associated one or more attributes. Some E/R systems also permit
relationship types to have attributes. An attribute is analogous to a
field in a record or a column in a relational table.
branch. The subset of a variant hierarchy that is obtained by starting at a
leaf node and traversing the hierarchy from the leaf node to its parent,
then to its parent's parent, and so forth, up to and including the root
node of the hierarchy.
cardinality. A constraint that determines for a given relationship type how
many connections may be made between sources and targets.
There are the following four cardinalities:
1 to 1 (1--1) - using the relationship type a given source may be connected
to only a single target and that single target may have no other sources.
1 to many (1-m) - using the relationship type a given source may be
connected to one or more targets where each of the targets may have no
other sources.
many to 1 (m-1) - using the relationship type one or more sources may be
connected to a single target and where no other the sources may be
connected to any other target.
many to many (m--m) - using the relationship type one or more sources may
be connected to one or more targets. With many to many there are no
restrictions as to how parts are connected.
change. The alteration of existing data or the creation of new data. The
alteration is the result of an add, update, or delete request. Other
requests may be provided by the data management system that result in a
change.
A change can be the result of an explicit request or it may be a triggered
change that was performed automatically by the data management system as
the result of another change.
commit. Actually applying to the repository a set of changes. Changes are
not visible to other users until they have been committed. After
requesting a set of changes the user can request to either have changes
committed or to have the changes undone (called a restore).
commit scope. The commit scope is the time between the first alteration to
repository data following a prior commit or restore (or the start of the
repository session if there were no prior commits or restores) and the
subsequent commit or restore.
context. A context is a permanently stored named collection of values for
environmental variables that govern the processing of the VDMS. At any
given time each session is using one particular context, with that context
being called the current context. For those values that are not specified
on add, update, or delete request the value in context is used, i.e. the
context value serves as a "default" value.
controlling relationship. A relationship which if deleted causes, based on
the definition of the relationship type, its source, target, or both to
also be deleted. This is an example of a triggered change.
current revision. A revision whose revision end time is logically infinity.
A current revision may be either active or frozen. All revisions that are
not current must be frozen.
current version. A version whose contents represent the current time, i.e.
a version that is not an historical record of the past. A current version
may be either active or frozen. All versions that are not current must be
frozen.
data integrity. The syntactic and semantic integrity provided by a VDMS.
For an E/R VDMS this might include referential integrity, relationship
semantics (cardinality, mandatory, and controlling), and constraint
checking.
default variant domain. The current context contains a default variant
domain for each variant default group. When a new part is added without
explicit indication into which variant domain to place the part, the part
is placed in the default variant domain for the variant default group that
contains the part type.
delete. A request to a VDMS to remove an existing part. The part must have
been visible from the view of data of the requestor.
delete propagation, A set of triggered changes (all deletes) that occurs as
the result of a delete request due to referential integrity enforcement or
controlling relationships.
derivation graph. A directed acyclic graph which indicates what version or
versions a given version is derived from.
Any version can be derived from 0 or more versions and can have 0 or more
versions derived from it. No version can be derived either directly or
indirectly from itself.
dependent entity. An entity that is the target of an owning relationship.
directed acyclic graph. An arrangement of nodes and connecting branches
which may fork in the direction of travel, but may never loop back on
itself. There is not necessarily a common ancestor. There may be more than
one path between two nodes.
See also "hierarchy" and "network." All hierarchies are also directed
acyclic graphs, but not all directed acyclic graphs are hierarchies. All
directed acyclic graphs are also networks, but not all networks are
directed acyclic graphs.
Following is an example of a directed acyclic graph:
##STR1##
drawdown. The creation of a version at the working variant level, when one
did not already exist at that level, that is a copy (except for values
that identify which version) of the first version that physically exists
higher in the search path.
A drawdown may be done either explicitly or in plicitly. A drawdown is done
implicitly in logical mode when there is a request to add, update, or
delete a part. In this case a drawdown is first done implicitly and then
the requested change is made to the version that was just drawn down to
the working variant level.
drawdown-from identifier. The last-change identifier of the version which
was the source of the drawdown. The drawdown-from identifier is set in the
resultant version at the time of the drawdown.
effective time versioning. An implementation of the basic versioning
mechanisms in which variants represent states of a part effective at
different periods in time.
Each variant has an attribute for storing the point in time at which the
variant becomes effective, and an attribute for storing the point in time
at which it ceases to be effective.
The effective time is also known as the variant time.
entity. A part that represents a thing, such as an enterprise model process
or a source program. In an E/R versioned-data management system parts are
either entities or relationships.
frozen revision. A revision which is no longer allowed to be changed.
Changes to the revision will cause a new active revision to be created.
All revisions are either active or frozen.
frozen version. A version which is no longer allowed to be changed. Changes
to the version will cause a new active version to be created. All versions
are either active or frozen.
hierarchy. An arrangement of nodes and connecting branches which never
forks in the direction of travel, though two paths going in the same
direction may merge together. Eventually all paths come together at a
common (root) node. There is exactly one path between any two nodes.
Also known as a tree.
See also "directed acyclic graph" and "network." All hierarchies are also
directed acyclic graphs, but not all directed acyclic graphs are
hierarchies. All hierarchies are also networks, but not all networks are
hierarchies.
Following is an example of a hierarchy:
##STR2##
higher. That portion of a hierarchy (or branch) from, but not including, a
given node through and including the root node.
independent change. In a versioned-data management system when two users,
without knowledge of the other change, change the same part so that the
two changes are applied to different versions of the part. An attempt to
promote the two changes to a common version requires a reconciliation of
the two changes, to prevent the second promote from unintentionally
overlaying the change associated with the first promote.
instance. This is the same as "version."
instance key. The full key that identifies a particular instance (version)
of a part.
inverse relationship. A relationship that connects the same source and
target as another relationship but goes in the opposite direction. The
source of the inverse relationship is the target of the other relationship
and the target of the inverse relationship is the source of the other
relationship.
last-change identifier. An identifier, which could be implemented as a
timestamp, of the last change to a variant of a part. The identifier is
set to a value that has not yet been used for changes to the part. The
identifier is set as a result of an add, update, or delete. It is not set
as a result of a variant being promoted.
lifetime ID. An identifier associated with a part whose value has not been
previously used for any other current version of the part. A lifetime ID
is assigned to a part when the part is created as a result of an add
request. The lifetime ID remains unaltered when a part if changed as a
result of an update or delete request. The lifetime ID is stored in the
versions of a part.
logical delete. An indication, via a flag in a version of the part, that
the part is to be considered to have been deleted. A delete request causes
a logical delete. A Logical delete is required to prevent other versions
of the part, such as those higher in the search path, from being accessed.
logical relationship. These are the normal relationship types. They
logically connect one source part to one target part. Updating a source or
target part, even if it causes the creation of a new version, does not
change which logical relationships point to that source or target. A new
part created via an add is born with no logical relationships pointing to
it. Logical relationships have their own versioning, which need not be the
same as the versioning of the source or target.
lower. That portion of a hierarchy (or branch) from, but not including, a
given node through and including the leaf node.
mandatory relationship. A constraint where if a part has an associated
mandatory relationship then the part cannot exist without the relationship
also existing, Since the relationship cannot be added until after the part
is added this constraint is not enforced immediately, but is instead
enforced when the data is committed.
network. An arrangement of nodes and connecting branches which may loop
back on itself. There may be more than one path between nodes.
See also "directed acyclic graph" and "hierarchy." All directed acyclic
graphs are also networks, but not all networks are directed acyclic
graphs. All hierarchies are also networks, but not all networks are
hierarchies.
Following is an example of a network:
##STR3##
old tool. A tool that was written against a data management system that
does not support versions of the data. These tools assume that the
repository contains only a single version for each part.
ordered relationship. A relationship where the order in which the
relationship parts are accessed is user determined. For a relationship
that is not ordered the order is system determined, usually by a collating
sequence on the relationship part key.
owning relationship. A relationship that is both mandatory and controlling
on its target and where the part key of the target contains as a prefix
the part key of its parent. The target must be an entity and is called a
dependent entity.
overlap. When used in reference to the variant or revision time cursors, an
instance is said to overlap the variant/revision time cursor if the
following is true:
______________________________________
(instance start time less than cursor end time OR
instance start time less than or equal cursor start time) AND
instance end time greater than cursor start time
______________________________________
parallel versioning. Use of a version or set of versions of a part to
maintain more than one active state of the same part at one time. Each
active state may be operated on independently by actions such as Update
and Delete.
A parallel version or set of versions may be created to represent
differences in the target environment, differences from model to model,
differences from release to release, differences from one period of time
to another, differences from user to user, etc.
Parallel versions may be ordered or unordered with respect to each other.
Parallel versioning is represented by variants.
part. An entity or a relationship.
A part may have many versions which represent different states of the part.
part key. That which identifies a particular part among all the parts of
the same part type.
physical relationship. These are special relationship types used for
purposes such as maintaining derivation history. They connect one source
version to one target version, They are not versioned.
primary variant hierarchy. The one variant hierarchy for a given VDMS
installation whose search paths can be used to perform changes to the data
in the repository.
promote. Changing the variant ID of a version of a part to the variant ID
that is one element higher in the variant hierarchy. If a variant already
existed at the higher level it is replaced. A previous request to change a
variant that was at a level other than the working variant level caused
the changes to be applied to a new variant at the working variant level.
By using promote the change can be moved up the variant hierarchy until it
applies to the variant against which the original change was requested.
A promote can be either a PROMOTE.sub.-- NORMAL or a PROMOTE.sub.-- FORCE.
PROMOTE.sub.-- FORCE. A form of promote where the requestor has
acknowledged that reconciliation has been performed as a result of a
previous independent change. The promote will fail if a subsequent
promoted independent change occurred.
promote group. A named group of instances related to some user task, such
as a fix to a given programming error. The purpose of the promote group is
to make it easier to promote all such related instances together. At any
given time there is a current promote group per session. All operations
that cause an instance to be altered cause the instance to be added to the
current promote group if it is not already in the group.
PROMOTE.sub.-- NORMAL. The initial promote that is attempted when doing a
promote. The promote will fail if a promoted independent change occurred
since the time of the initial draw down.
referential integrity. Referential integrity refers to the enforcement by
an E/R VDMS of the restriction that a relationship instance can only exist
if both its source and target instances exist. If the source or target of
a relationship is deleted then the relationship is also deleted. This is
an example of a triggered change.
relationship. A part that represents a connect between two other parts,
where the other parts could be an entity or another relationship. Each
relationship is directional where the starting part being connected is
called the source and the terminating part being connected is called the
target. In an E/R versioned-data management system, parts are either
entities or relationships.
repository. This refers to either the place where a data management system
stores its data or to the data itself.
restore. Undoing a set of changes. After requesting a set of changes the
user can request to either have the changes applied (commit) or have the
changes undone.
resultant version. In a versioned-data management system an add, update, or
delete request can cause the change to be applied either directly to the
original version or cause a drawdown of the original version to a new
version at the working variant with the change applied to the new version.
The version that actually gets the change applied is the resultant
version.
retrieval. A request to a VDMS to read the contents of an existing part.
The part must be visible from the view of data of the requestor.
revision. A version which is organized serially with respect to other
revisions in a set. (The set is called a variant.) Revisions are
sequentially ordered in time such that there is exactly one "current"
revision in any set. They represent historical states of a part. Because
they represent an online historical record, no revision can ever be
changed once work on it has been completed. A user request to update
versioned data for a frozen revision of a part will result in the
automatic creation of a new "current" revision.
revision key. That which identifies a particular revision among all the
revisions of a variant.
revision time. The time range, stored as a start and end timestamp, when a
revision was active in the repository. The start time is the time when the
revision was created and the end time is the time the revision was
superseded by a more current revision.
revision time cursor. The revision time cursor represents either a range of
times between the revision cursor start time and the revision cursor end
time, not including the end time itself, or a single point in time in
which case the end time is set equal to the start time. Each of the two
times takes the form of a timestamp. The revision time cursor restricts
the view of data for any request to instances whose revision time range
overlaps with the revision time cursor.
search path. An ordered list of variant IDs starting with a given variant
ID and progressing higher in the variant hierarchy up to and including the
root variant ID.
The domain for all data service actions is limited to those versions whose
variant ID values match those of one of the elements in the search path.
In addition the variants within the domain are ordered based on the
ordering in the search path.
For any given node in any variant hierarchy there is a corresponding search
path which starts with the variant ID value at that node.
serial versioning. Use of versions of a part which are serially ordered in
time, such that each version supersedes its predecessor in a linear
fashion.
Such a set of versions represents the evolution of a part over time. The
latest version represents its current state.
Serial versioning is represented by revisions.
source. The part that is at the starting end of a relationship.
target. The part that is at the terminating end of a r | | |
