This report has two errors and six warnings.
Indicate conditions you must correct before the objects in the model can move forward to the next stage of development
Indicate conditions that may cause problems later, but do not prevent those objects from progressing to the next stage of development
Indicate conditions that are more severe than warnings in that they should be addressed before continuing to the next stage of development but that do not deny you the ability to proceed anyway. These types of warnings may cause other problems that are difficult to diagnose from the information given at the time (such as during code generation or compilation) so they should be addresses as soon as possible.
Examining our Consistency Check Report, we see that at the top left it shows the model name, the subset name, and the date and time the report was run. Level indicates the consistency check level we selected under the model settings. In this case, BAA represents the Analysis level we selected earlier. BAA stands for Business Area Analysis. Reporting indicates the severity of messages to report, also selected under the model settings. After that, it shows the object that was selected for the consistency check, in our case the EGOLF SERVICES root subject area. Finally it shows the objects within that subject area that had problems. We are going to address each of the problems identified in this report.
Looking at the entity type GOLFER, we have an error and two warnings. The error states that each entity type must have an identifier defined for it. An identifier is a way to uniquely identify each entity of an entity type. For example, your business employs many employees. How does your business uniquely identify each employee? Your company probably identifies employees with something like a unique employee id. A secondary identifier can be their social security number. Likewise, we need a way to uniquely identify every GOLFER. In our case, each GOLFER is going to have a unique User ID. Therefore, we will declare the User ID as the identifier for GOLFER, which will eliminate the error.
GOLFER also has two warnings. These warnings refer to the minimum, maximum, and average number of GOLFERs the business expects to have. The minimum number of golfers would be zero; since this is the default value, we receive no warning. However, the maximum and average values default to zero as well, and the eGolf Services business hopes to have more golfers than that. So the question is, what is the maximum number of golfers the business expects at any point in time and what's the average number? We will assume that marketing research has indicated that we will have a maximum number of 100,000 golfers with an average of 75,000. We will enter these values in after examining the rest of our errors and warnings.
Looking at the relationship membership GOLFER MAINTAINS SCORING RECORD, or more specifically EACH GOLFER SOMETIMES MAINTAINS ONE OR MORE SCORING RECORD, we have two warnings. The warnings state that the estimated cardinality and optionality of this relationship should be defined.
In this case, cardinality deals with the minimum, maximum, and average number of scoring records each golfer will maintain. We know that a golfer needs at least five and preferably 20 scoring records to determine a handicap index. However, we also know that golfers can register without entering any scoring records. Thus, the minimum number of scoring records can be zero, the maximum number 20, and the average five. However, this would only be true if as they entered their 21st scoring record, we deleted their 1st scoring record, maintaining 20 as the maximum number of scoring records maintained by each golfer. However, what if we wanted to keep all of their scores for historical purposes? You need to ask these questions to the users. We will assume the minimum number of scoring records maintained by a single golfer will be zero, the maximum will be 100, and the average will be 20.
Optionality deals with the SOMETIMES aspect of the relationship membership. Essentially, what percentages of golfers sometimes maintain a scoring record? While we know that a golfer can register without ever entering any scoring records, we are anticipating that most will enter at least one scoring record. Therefore, something like 99 percent of the golfers will maintain at least one scoring record.
Entering these values, which we will do shortly, will resolve the relationship membership problems identified previously. However, that relationship also has another relationship membership, EACH SCORING RECORD ALWAYS IS MAINTAINED BY ONE GOLFER that we did not receive any errors or warnings for. What is the cardinality and optionality of this relationship membership? The cardinality in this case is one: each scoring record is maintained by one golfer. In addition, there is no optionality since one golfer always maintains each scoring record.
Finally, SCORING RECORD had similar problems to GOLFER. A golfer will have many scoring records. How can we uniquely identify each scoring record? Each scoring record has the date and time that the game was played. It is unlikely that a golfer can play two games on the same date at the same time, so date and time can be used to uniquely identify each scoring record. However, we can still have two scoring records for the same date and same time played by two different golfers. So to uniquely identify every scoring record, we not only need to know the date and time it was played, but the golfer who maintains it.
What about the average and maximum number of SCORING RECORDS? If we know that we have a maximum number of 100,000 golfers and each will have a maximum number of 100 games, then the maximum number of scoring records would be 10,000,000. The average number of scoring records would be the average number of golfers (75,000) times the average number of games per golfer (5) which is 375,000.
While the previous discussion on entity type and relationship cardinality is accurate, the downstream effect of all this is that eventually we are going to create a database to store all of this data. In addition, the database will be sized based on these numbers. To keep the size of our test database manageable, we will enter significantly smaller numbers into the Toolset.
|
Copyright © 2013 CA.
All rights reserved.
|
|