Applying Constraints to the Model

There are many constraints to be implemented in any system, so whatever modeling tool you use must have a method of illustrating constraints. Conceptual data modeling, and ORM specifically, is no different, and the ORM techniques offer a methodology for placing rules onto the data model. The final four steps in the conceptual design all deal with designing model constraints. Uniqueness, mandatory role, value, set-comparison, subtype, and ring constraints (defined in the following sections) can play a part in any system.

Again, to simplify this process, you will use only a portion of the system to focus on developing constraints. Consider the order-processing portion of the diagram (see Figure 6.9). As stated in the case study, an order is made by a patient and can be made up of multiple items, and each item represents one of the Billington products.

Figure 6.9. The ORM for the order process.

graphics/06fig09.gif


Some of the constraints have already been used in this chapter's ORM diagrams, although until this point, they have been placed without explanation. To understand these design mechanisms, review Figure 6.10, which indicates the basic charting relationships. In indicating the relationship between entities, you show both cardinality (how many of the entity exists) and optionality (whether an entity has to exist). Mandatory elements are illustrated with a black dot in the modeling process.

Figure 6.10. ORM entity relationships (16 variations).

graphics/06fig10.gif


graphics/alert_icon.gif

Be careful when setting up cardinality and optionality. You must formulate relationships appropriately so that they coincide with the information provided in the case study.


After determining the entities for the model, it is time to implement the first level of constraints into the model. Uniqueness constraints are used in the ORM diagram to indicate that the entries connected with these types of constraints in one or more roles occur only once. You can easily see some examples of uniqueness in the ordering of goods: The order is made on only one date and can be shipped to only one location.

Identifying Uniqueness

As you add uniqueness constraints, you also check the arity of the fact types. In programming, arity represents the number of arguments a function or an operator takes. In some languages, functions can have variable arity, which sometimes means their last or only argument is actually a list of arguments. In ORM, arity relates to the cardinality of entity relationships. It is possible to gain uniqueness in situations where combinations of roles are needed. If identifiers are used, however, this combination is usually not necessary. One optional model for an order item could combine an order with a product to make up an order item. This option would alter the diagram, similar to what is shown in Figure 6.11.

Figure 6.11. Uniting entities to form uniqueness.

graphics/06fig11.gif


This uniqueness constraint ensures that each item ordered is for only one product of one specific order. Each order should already be unique, and you want a product to occur on the order only a single time. Of course, an Order Item ID guarantees this uniqueness. You still need to set a relationship from an Order ID to the Order entity and from a Product ID to the Product entity.

After defining uniqueness throughout the model, you can perform simple arity checks to ensure that each constraint you apply doesn't miss any of the possibilities or incorrectly define the relationship between entities.

The next step of the conceptual design adds mandatory role constraints and checks for logical derivations. Similarly to defining uniqueness, mandatory role definition helps solidify the model and determine which entities are required within any relationship.

What Is Optional? What Is Required?

In any relationship, mandatory elements are those that must be known before the relationship can exist. In the Billington ORM, an Order Item requires an Order to be present, and a Prescription-Drug must come from a Prescription. Many other mandatory relationships are needed; in all cases, the base entities are required before any properties can exist. In ORM, mandatory role "dots" are placed where the element is required. If two or more roles are connected to a circled mandatory role dot, this produces an "or" condition. Either one or the other is required. In the Billington case study, the best example of this condition is when a Doctor or a Patient that is on record must place a call (see Figure 6.12).

Figure 6.12. An "or" condition in ORM.

graphics/06fig12.gif


With an understanding of the uniqueness and mandatory role constraints, now you can turn to cardinality references. Some of the references are easier to see than othersfor example, a mandatory 1:1 mapping from entity type to value type, in which values are either mandatory or optional.

You can also have a composite reference containing two or more values that refer to an entity. An entity can have a physical and a logical name. People can have nicknames that identify them equally as well as their true names. A common situation in which you can find a composite reference is a product having an internal number as well as a product number for the supplier's identification of the product. This relationship is illustrated in Figure 6.13.

Figure 6.13. A composite relationship.

graphics/06fig13.gif


Next in the creation of the conceptual design model is checking for logical derivationsthat is, in some cases a fact can be derived from another. You have already considered calculated entities, but they are not the same thing. You are not concerned with derivatives formed mathematically. To look at this aspect of the conceptual design model, analyze the diagram to see whether any relationships have been omitted. You are looking particularly for relationships that provide a functional relationship to a portion of the diagram.

Such functionality in the Billington case study would be charging a user fee for the call procedure. As mentioned in the case study, at first there will be no charge for this service, but a user fee is under consideration for future implementation. You might also need to consider credit checks as part of your process, but as yet, nothing has been done to incorporate this process. Many other processes need to be addressed, but they are outside the scope of the project. Currently in the diagram there are a Supplier and an Employee object that will, no doubt, also be entities.

Business rules are often implemented as objects in the diagram process. These objects could later become data within a database or a processing component applied through an application. You might want to include a number of these rules, external entities, and processing possibilities in the conceptual design model. In that way, you can minimize future changes to the schema, and update the information when required later, instead of having to completely redo the project.

Through the model, you can also determine transitive patterns of functional dependencies that might exist. For example, if a particular product is a Billington brand, you can then determine the supplier ID without ever looking at the actual value of the ID. For the sake of simplifying the design and because there is little transitivity in your model, you will forgo this type of exploration.

In the next step of the conceptual design process, you examine more definitive constraints. Constraints on the possible values or range of values for an entity, set-comparison constraints that examine multiple values, and subtype constraints focus on values and rules for the design.

Design and Development of Data Rules

Various value constraints can be added to the conceptual design model. In this manner, you can show a visual display of the permitted values for an entity's data. You can, for example, show whether a permitted value must be positive, is character data, must be one of the valid state/province codes, or has any other restriction. These restrictions identify rules that need to be implemented in the system.

The Billington system has several value constraints that you can consider. Value constraints worth considering have been noted in the following list (the list is not intended to be exhaustive; it is more a set of examples of constraints that can be in place):

  • No distribution of a medication that has no refills

  • Preventing an order that has insufficient stock on hand

  • Ensuring that the selling price is equal to or greater than the last cost price

  • Value choices given for alternatives in packaging

  • Order date values within an acceptable range of dates

  • Value choices given for methods of order shipment

  • Country codes being "CA" or "US"

  • State/province codes being valid for the United States or Canada

  • Value choices for the Doctor's specialization

Of course, there are other possibilities that have not been stated in the previous list. However, the list should provide several examples of where value checks could be implemented into the Billington system. Other checks would take value choices and create subsets of categories from these choices.

A set-comparison constraint specifies a subset, an equality, or an exclusion. These constraints are applied between compatible roles or sequences of compatible roles. Compatible roles are played by the same object type or by object types with the same supertype. In the Billington system, you can consider the Patient to be a supertype made up of American and Canadian subtypes. Each subtype needs to be defined, as the case study specifies that each subtype has special handling. If you set up a subset constraint, the subset must always fit the role from which it was derived. For example, an American/Canadian patient must always fit into the Patient role, as illustrated by the two constraints in Figure 6.14.

Figure 6.14. A subset constraint and a value constraint.

graphics/06fig14.gif


In ORM, you can also have an equality constraint, which is a pairing of subset constraints. An equality constraint is placed based on a comparison that is "Equal." An example might be paying GST (Goods and Services Tax) if, and only if, the patient is Canadian.

You could easily perform subtyping on the Billington products because both Billington brand products and other brand products are sold, and each could be considered a subtype of Brand. Another example of a subtype is the types of available packaging for some goods; also drugs can be classified as narcotic or non-narcotic and over-the-counter or not-over-the-counter. There are numerous other subtypes in the case study that help lead to restrictions and constraints.

During this step of the conceptual design, many other aspects of the system are given more detail. With the added detail, the conceptual design model becomes more meaningful, and you can see a closer picture of all interactions that are going to occur in the proposed system. In fact, after completing this subtyping and defining all applicable constraints, only one step and one final set of checks must be performed.

Constraining a Ring Around the Rosies

The last set of constraints to add to your design is commonly referred to as ring constraints. After applying this set of constraints, you also complete a final set of validations of your model. After completing the final version of the model, you'll look ahead to the next phase of development. Even in this stage, the conceptual design will undergo slight modifications in future development before it has truly been finalized.

Ring constraints in the system are put in place to mandate or prevent cyclical situations. One such check in the Billington system might be preventing a Doctor from prescribing medications to himself or herself. A ring constraint might also be needed to allow distribution of medications to a minor. A child as a patient in the system would require a parent, guardian, or other responsible individual who would also be regarded as a patient in the system.

Although ring constraints are placed into an ORM diagram as a single entity relationship, the rules for cardinality and optionality in the drawing style remain the same. There are essentially four different models for drawing a ring constraint into the conceptual model (see Figure 6.15).

Figure 6.15. Ring constraint alternatives.

graphics/06fig15.gif


There are a few variations to ring constraints that allow for multiplicity of relationships. In some situations, you might actually want to assign a specific numerical condition to a ring constraint. Assume for the sake of argument that a single individual can have a maximum of three children for which he or she is responsible. You can diagram this relationship by using a " 3 indicator on the model attached to the constraint.

In most systems, ring constraints are uncommon. However, as a final step in designing a conceptual model, you should analyze the system to see whether any are present.

Now you need to perform a final check of the system. By comparing the ORM against all known information derived from the case study, if nothing was missed, the ORM should be consistent with all data, avoid redundancy, and be a complete representation of the system.

After drafting the conceptual model and drawing the final ORM, you can make decisions about the database system that will be used. One feature of going through the conceptual design process is that it creates a picture of the data so that all involved can better understand the system. In preparing a conceptual design, particularly with ORM tools, data interrelationships and definitions of the data structure become more complete.

Validate the Conceptual Design

Before starting this process, you might have had a preconceived notion of what the database design was going to look like. By taking care to work through the steps of ORM, you tend to flesh out the system and bring in elements that would otherwise be overlooked. Anything missed in the conceptual design becomes harder to implement further along in the project. Heaven forbid the coding be finished only to find out that major elements need redesign. Obviously, this can prove to be very costly.



Analyzing Requirements and Defining. Net Solution Architectures (Exam 70-300)
MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300: Analyzing Requirements and ... Exam 70-300 (Pro-Certification)
ISBN: 0735618941
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net