System and method for teaching entity-relationship modeling

BACKGROUND OF THE INVENTION

00011. Field of the Invention

0002The present invention relates to database design, and to educational and pedagogical devices for teaching database design to computer programming students and novices, and particularly to a system and method for teaching entity-relationship modeling.

00032. Description of the Related Art

0004Entity-relationship (ER) modeling is considered to be an effective technique used to develop conceptual data models that represent data storage requirements. The ER diagram (ERD) conceptual data modeling technique was proposed in 1976 by Chen. It is agreed by database design researchers that the development of conceptual data models for data storage requirements is an important step for achieving effective database design. However, long personal experience in using and teaching ER modeling has shown that the task of developing correct and complete conceptual ERD models requires experience in ER modeling. The reason is that the ERD modeling technique provides only a set of notations for developing ERD models.

0005The ER modeling task heavily depends on the modeler's critical thinking and conceptualization abilities. Because there is a lack of useful and clear rules and guidelines in a systematic and procedural format in database design literature, it is noticed that students studying database management courses find the task of ER modeling difficult. Therefore, there is a great need for a systematic method that can improve students' learning of the ER modeling task in shorter time, and to improve the junior modelers' performance of the ER modeling task.

0006The ER diagram conceptual data model views the real world user data requirements as entities and relationships. It provides a visual representation of data objects and their relationships. The ERD modeling technique involves analyzing the data needs of the organization and, on the way, the users view or conceptualization of the data. Because the data model describes data from the perspective of the organization and not from the perspective of the detailed system processes, it leads to a database that is more adaptable to the data needs of the organization. The ERD technique requires the database designer to conceive of the following: a set of constructs (entity, relationships, attribute, identifier, and dependency) for defining data; rules for controlling how the constructs are drawn to form a data model; and a method for constructing the data model using the construct and rules.

0007For the database designer, the utility of the ER model is that it maps well to the relational database model. That is, the constructs used in the ER model can easily be transformed into relational tables. The entity-relationship model is simple and easy to understand; therefore, the model can be used by the database designer to communicate the design to the end user. In addition, the model can be used as a design plan by the database developer to implement a data model in specific database management software.

0008A completed ER diagram model is considered as the blueprint of the database, and the ER diagram is as important to the database designer as a blueprint is to the architect and system builder. Its composition must reflect an organization's business operations/rules accurately if the database is to meet that organization's data requirements. The completed ER diagram model also lets the designer communicate more precisely with those users who commissioned the database design. The completed ER diagram serves as the implementation guide to those who create the actual database.

0009Thus, a system and method for teaching entity-relationship modeling solving the aforementioned problems are desired.

SUMMARY OF THE INVENTION

0010The system and method for teaching entity-relationship modeling employ graphical organizer templates to systematically analyze the data storage requirements of an organization. The student is taught to apply the templates in logical order, from recognizing the organization's business rules and constraints on those rules, through classification of entities, the relationships between entities, distributive aspects of the relationships, attributes of the entities, identifying required and optional entities, and the cardinality of the relationships. The templates place the information in a graphical or chart form, which may then be easily translated into the formal symbolism of an entity-relationship diagram.

0011These and other features of the present invention will become readily apparent upon further review of the following specification and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0012<figref idref="DRAWINGS">FIG. 1</figref> is a flowchart of a method for teaching entity-relationship modeling according to the present invention.

0013<figref idref="DRAWINGS">FIG. 2</figref> is a blank template for a Graphical Organizer #<b>1</b> of a system for teaching entity-relationship modeling according to the present invention.

0014<figref idref="DRAWINGS">FIG. 3</figref> is an exemplary filled out template for a Graphical Organizer #<b>1</b> of a system for teaching entity-relationship modeling according to the present invention.

0015<figref idref="DRAWINGS">FIG. 4</figref> is a blank template for a Graphical Organizer #<b>2</b> of a system for teaching entity-relationship modeling according to the present invention.

0016<figref idref="DRAWINGS">FIG. 5</figref> is an exemplary filled out template for a Graphical Organizer #<b>2</b> of a system for teaching entity-relationship modeling according to the present invention.

0017<figref idref="DRAWINGS">FIG. 6</figref> is a blank template for a Graphical Organizer #<b>3</b> of a system for teaching entity-relationship modeling according to the present invention.

0018<figref idref="DRAWINGS">FIG. 7</figref> is an exemplary filled out template for a Graphical Organizer #<b>3</b> of a system for teaching entity-relationship modeling according to the present invention.

0019<figref idref="DRAWINGS">FIG. 8</figref> is a blank template for a Graphical Organizer #<b>4</b> of a system for teaching entity-relationship modeling according to the present invention.

0020<figref idref="DRAWINGS">FIG. 9</figref> is an exemplary filled out template for a Graphical Organizer #<b>4</b> of a system for teaching entity-relationship modeling according to the present invention.

0021<figref idref="DRAWINGS">FIG. 10</figref> is a blank template for a Graphical Organizer #<b>5</b> of a system for teaching entity-relationship modeling according to the present invention.

0022<figref idref="DRAWINGS">FIG. 11</figref> is an exemplary filled out template for a Graphical Organizer #<b>5</b> of a system for teaching entity-relationship modeling according to the present invention.

0023<figref idref="DRAWINGS">FIG. 12</figref> is a blank template for a Graphical Organizer #<b>6</b> of a system for teaching entity-relationship modeling according to the present invention.

0024<figref idref="DRAWINGS">FIG. 13</figref> is an exemplary filled out template for a Graphical Organizer #<b>6</b> of a system for teaching entity-relationship modeling according to the present invention.

0025<figref idref="DRAWINGS">FIG. 14</figref> is a filled out template for a Graphical Organizer #<b>1</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0026<figref idref="DRAWINGS">FIG. 15</figref> is a filled out template for a Graphical Organizer #<b>2</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0027<figref idref="DRAWINGS">FIG. 16</figref> is a filled out template for a Graphical Organizer #<b>4</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0028<figref idref="DRAWINGS">FIG. 17</figref> is a filled out template for a Graphical Organizer #<b>4</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0029<figref idref="DRAWINGS">FIG. 18</figref> is a filled out template for a Graphical Organizer #<b>5</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0030<figref idref="DRAWINGS">FIG. 19</figref> is a filled out template for a Graphical Organizer #<b>6</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0031<figref idref="DRAWINGS">FIG. 20</figref> is a filled out template for a Graphical Organizer #<b>2</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0032<figref idref="DRAWINGS">FIG. 21</figref> is a filled out template for a Graphical Organizer #<b>4</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0033<figref idref="DRAWINGS">FIG. 22</figref> is a filled out template for a Graphical Organizer #<b>4</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0034<figref idref="DRAWINGS">FIG. 23</figref> is a filled out template for a Graphical Organizer #<b>5</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0035<figref idref="DRAWINGS">FIG. 24</figref> is a filled out template for a Graphical Organizer #<b>6</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0036<figref idref="DRAWINGS">FIG. 25</figref> is a filled out template for a Graphical Organizer #<b>2</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0037<figref idref="DRAWINGS">FIG. 26</figref> is a filled out template for a Graphical Organizer #<b>4</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0038<figref idref="DRAWINGS">FIG. 27</figref> is a filled out template for a Graphical Organizer #<b>5</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0039<figref idref="DRAWINGS">FIG. 28</figref> is a filled out template for a Graphical Organizer #<b>6</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0040<figref idref="DRAWINGS">FIG. 29</figref> is a filled out template for a Graphical Organizer #<b>2</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0041<figref idref="DRAWINGS">FIG. 30</figref> is a filled out template for a Graphical Organizer #<b>5</b> of an exemplary company sales processing system illustrating a system and method for teaching entity-relationship modeling according to the present invention.

0042<figref idref="DRAWINGS">FIG. 31</figref> is an exemplary entity-relationship diagram produced from the templates of <figref idref="DRAWINGS">FIGS. 14-30</figref>.

0043Similar reference characters denote corresponding features consistently throughout the attached drawings.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0044The present invention is a system and method for teaching entity-relationship modeling. The system and method employ graphical organizer templates to systematically analyze the data storage requirements of an organization. The student is taught to apply the templates in logical order, from recognizing the organization's business rules and constraints on those rules, through classification of entities, the relationships between entities, distributive aspects of the relationships, attributes of the entities, identifying required and optional entities, and the cardinality of the relationships.

0045Entity relationship (ER) data modeling is a conceptual modeling technique that is concerned with logically or conceptually representing and describing users' data requirements using well-defined constructs. Constructs means the forms used for representing users' data requirements. The constructs used for representation in the ER model include entities, relationships, and attributes.

0046To be able to identify candidate entities accurately, it is necessary to understand the following concepts: Entity, Entity Instance, and the kind of entities that can exist in different kinds of user requirements or different problem domains.

0047An “entity” is something the user is interested to store data about, including a fundamental thing (such as student, course, book, etc), or an action entity (such as student's enrolment), which is based on an event or a business transaction. The other condition that qualifies an entity is that an entity must have characteristics or attributes to become a legitimate entity. An entity in the ERD model terminology is a representation of a set of entity instances with common characteristics. For example, a set of individual students with common characteristics (such as ID, Name, Address, Phone, Date of Birth, etc.) may be represented by the Entity STUDENT. The following rule, which can be used for identifying candidate entities, can be formulated. A candidate entity must at least satisfy the following three conditions: (1) the entity must represent some thing, or an interaction between things, for which the user is interested to store data about; (2) the entity must have characteristics (at least one), and not itself be a characteristic of an entity; and (3) a candidate entity must represent one thing or one concept.

0048An “Entity Instance” is the individual thing that is represented by an Entity. For example, a particular student named Mohammad Al-Ali is an entity instance of the entity STUDENT.

0049Entities may be categorized as fundamental entities and derived entities.

0050A “fundamental entity” is an entity that represents a thing in the user's requirements. Examples are Student or Book in a library system, or a Bank Account in a Banking system. This kind of entity is a fundamental entity. Fundamental entities may be further categorized as “physical” and “conceptual” entities.

0051A “derived entity” is an entity that is derived from an interaction or relationship between one or more fundamental entities. Example of a derived entity is the associative entity or bridge entity that is usually introduced in the ERD model to resolve M:M (many-to-many) relationship between two entities. For example, student-enrolment entity is introduced into the ERD model of a Student Registration System to resolve the M:M relationship that represents the business rule: a student can enroll in one or more classes, and one class can be used to enroll many students.

0052An entity that can result from a 1:M (one-to-many) relationship that can exist between a multivalued attribute of an entity and the entity itself is another example of a derived entity. For example, consider the business rule “a faculty possesses more than one qualification,” which the user is interested to store data about in the database. The multi-valued attribute, faculty's qualifications, can be best modeled as an entity related to the Faculty entity as 1:M between the Faculty and Faculty qualification entities.

0053A “physical entity” is an entity that is concrete and tangible. For example, Student is a physical entity. A “conceptual entity” is an entity that is intangible and not seen, but it exists. For example, Bank Account and Course are conceptual entities. These physical and conceptual entities can be considered as fundamental entities. Some fundamental entities are type entities. Most of the time, type entities are not obvious in the given user's data requirements. For example, a bank account may be Saving, Checking, Credit, or Loan Account. In this business rule, an account type is not mentioned, but it can be deduced because it is not a good idea to keep Account Type details as part of the Bank Account entity details. Each account type may be used by a number of bank accounts, which means one account type can be associated with many bank accounts.

0054Usually, this kind of relationship between the type entity and the related entity is one to many (1:M). Because storing data facts (details) of type entities is important and needed by users in many applications, it is necessary to propose type entities in ERD models, even if they are not clearly written in business rules of the problem domain. One important modeling activity is the conceptualization of entities, which is concerned with the identification and validation of entities, relationships, and attributes.

0055To support and guide the thinking/cognitive processes of the modeler/learner during the ER modeling task, the present invention uses a set of formulated graphical organizers. A graphical organizer (described below) will be used to define entities, relationships, and attributes respectively. In general, a good understanding of a user's requirements represented by the business rules of a problem domain is a key factor in achieving correct and complete identification of entities, relationships, and attributes.

0056“Relationships” are associations between data entities. For example, a student enrolls in a number of classes (course sections). This statement indicates there is a relationship between the student entity and class entity. Relationships result from business rules (which describe business operations/transactions) or natural relationships between entities.

0057In ER diagram modeling technique, three types of relationships are used to represent associations between data entities. These are: a one-to-one relationship, represented as 1:1; a one-to-many relationship, represented as 1:M; and a many-to-many relationship, represented as M:M. For example, the relationship “An instructor can only coordinate one course” is a 1:1 relationship; the relationship “An instructor teaches one or more courses” is a 1:M relationship; and the relationship “A student may enroll in one or more classes and one class may be used to enroll one or more students” is a M:M relationship.

0058Usually, M:M relationships result in a new entity called an associative entity (bridge entity). In general, the associative entity represents data characteristics of a business operation involving two entities. For example, the students' enrollment details that result from the enrollment business action/operation need to be represented by a new associative entity.

0059Relationships can be classified into three categories: M:M (many-to-many); 1:M (one-to-many); and 1:1 (one-to-one).

0060M:M relationships may be further categorized into action-based relationships and recursive relationships. An “action-based relationship” represents an interaction between two or more entities. Usually, action-based relationships are represented by a many-to-many relationship in the ER diagram model, thereby resulting in an Associative or Bridge Entity. Because implementing many-to-many relationships results in data redundancy, a bridge entity is introduced to resolve a many-to-many (M:M) relationship into two one-to-many (1:M) relationships.

0061A “recursive relationship” results when each entity instance can be related to a set of entity instances of the same entity. For example, a course has zero or many prerequisite courses, and one course can be used as a prerequisite for zero to many courses. If the relationship between instances of the same entity is M:M, then a new bridge entity will result from the M:M recursive relationship.

00621:M relationships can be further categorized as dependency relationships, master-details relationships, whole-part relationships, and recursive relationships. An entity may result from a “dependency relationship” between two entities. For example, an employee has children, and the user wants to keep data about the employee and their children. In other cases, a dependency relationship may result when an entity may be identified to resolve a multivalued attribute that can exist in a fundamental entity. For example, the employee entity has an attribute called qualification. But some employees have multiple qualifications. This means the qualification attribute will have multiple values, which cannot be handled in one attribute. This situation represents a dependency relationship between the employee entity and employee's qualifications, and therefore it is best modeled as 1:M relationship existing between the employee entity and the employee's qualifications entity.

0063An entity may result from a “master-detail relationship” between two entities. For example, an order has order items and an invoice has invoice lines.

0064An entity may result from a “whole-part relationship” between two entities. For example, a building has rooms, and a room has furniture items.

0065A one-to-many “recursive relationship” results when one entity instance is related to another instance of the same entity. For example, an employee manages zero or many employees. If the recursive relationship between instances of the same entity is 1:M, then a new entity may result from the recursive relationship.

00661:1 relationships may be further categorized into a general-special relationship, a recursive relationship, a dependency relationship, and a whole-part relationship. An entity may result from a “general-special relationship” between two entities. For example, an employee is a person.

0067A 1:1 “recursive relationship” may result, for example, when one employee manages one department in an organization. In this case, no new entity will result from this kind of recursive relationship. A 1:1 “dependency relationship” is exemplified, e.g., by the business rule that a book has one publisher. A 1:1 “whole-part relationship” is exemplified, e.g., by the business rule that one car has one engine.

0068Database design, when based on the ERD modeling process, consists of a set of modeling activities that are mainly concerned with the identification, refining, and integration of entities, attributes, and relationships in a complete ERD model that satisfies a user's database needs. ER modeling is an iterative rather than a linear or sequential process. The iterative process is based on the repetition of certain modeling activities to produce a complete ERD model

0069User data requirements are usually gathered from interviewing an organization's users, reviewing and observing business operations, procedures, forms, reports, and other documentation related to the organization's functions. After collecting the user's requirements, the data need to be organized into business rules to form a problem domain. Business rules describe business activities (that is, business operations or business transactions). Also, some business rules have restrictions and exceptions.

0070Basically, the ERD modeling process starts with the organization and interpretation (understanding) of business rules existing in the given problem domain. Then the modeler starts the identification of entities; linking the entities using relationships; and lastly, the modeler identifies attributes of entities, including keys. However, these activities run in a few cycles until a satisfactory ERD model is reached. Therefore, the process is an iterative process consisting of two major phases, namely, the Organization of Business Rules and Modeling Activities.

0071Each of the two phases has a number of steps. The proposed process according to the present invention is depicted graphically in <figref idref="DRAWINGS">FIG. 1</figref>. In order to support the critical thinking involved in the above two phases of the ER modeling task, a series of six graphical organizers are formulated and used in the process, as indicated.

0072In the first phase, Graphical Organizer #<b>1</b> is used to list the business rules with their restrictions or constraints, as well as exceptions to the rules, as indicated at step <b>10</b>.

0073The second phase involves several steps. For each business rule identified on Graphical Organizer #<b>1</b>, a Graphical Organizer #<b>2</b> is prepared to organize and recognize the elements of the business rule and the category of relationship between entities, using Graphical Organizer #<b>3</b> to resolve M:M relationships, all as indicated at step <b>12</b>. From the foregoing analysis, an ERD segment is drawn for each business rule, as indicated at step <b>14</b>. Then Graphical Organizer #<b>4</b> is used to identify the attributes of each entity, and the attributes are added to the corresponding ERD segment, as indicated at step <b>16</b>.

0074Graphical Organizer #<b>5</b> is used to define the optional and mandatory participation of the entities in the various relationships, and the appropriate ERD segment is modified accordingly, as indicated at step <b>18</b>. Next, Graphical Organizer #<b>6</b> is used to define the cardinality of the entities, and the appropriate ERD segment is notated accordingly, as indicated at step <b>20</b>. The ERD segment for the selected business rule is verified against the relevant organization's documentation and requirements, as indicated at step <b>22</b>, repeating steps <b>12</b>-<b>20</b> as required.

0075Steps <b>12</b> through <b>22</b> are repeated for each business rule, as indicated at step <b>24</b>. Finally, each of the ERD model segments are integrated into a single ERD model, as indicated at step <b>26</b>.

0076A blank Graphical Organizer #<b>1</b>, designated generally as <b>28</b> in the drawings, is shown in <figref idref="DRAWINGS">FIG. 2</figref>, and an exemplary completed template <b>28</b> is shown in <figref idref="DRAWINGS">FIG. 3</figref>. Graphical Organizer #<b>1</b> is used to organize the information related to each one of the business rules that exist in the given user's requirements into a format that is easy to interpret and that focuses on recognizing the elements of business rule: entities, relationships and constraints and/or exceptions. A business rule briefly describes a business process/operation that exists in a user's requirements.

0077The template <b>28</b> is broadly divided into separate sections for each business rule by numbered boxes <b>30</b> that extend across the width of the template <b>28</b>. Each numbered box <b>30</b> is followed by a sequence of boxes of smaller width, including a box <b>32</b> for statement of the business rule, a labeled box <b>34</b> for statement of constraints and restrictions on the business rule, and a labeled box <b>36</b> for statement of exceptions to the business rule. <figref idref="DRAWINGS">FIG. 3</figref> shows a sample filled-out template <b>28</b>, the two business rule statements applying to different users or organizations to illustrate how Graphical Organizer #<b>1</b> can be adapted to different organizations.

0078<figref idref="DRAWINGS">FIG. 4</figref> shows a blank Graphical Organizer #<b>2</b>, designated generally as <b>38</b> in the drawings, and an exemplary completed template <b>38</b> is shown in <figref idref="DRAWINGS">FIG. 5</figref>. Graphical Organizer <b>2</b> is used to organize the information related to each one of the business rules developed in Graphical Organizer #<b>1</b> into a format that is easy to interpret and recognize the elements of business rule. The elements of a business rule include the actor and/or things, the action, event and/or relationship between actors or things. Based on the understanding and recognition of the business rule's elements, the modeler will try to define candidate entities and relationships and then make conclusion on the kind of relationship connectivity (1:1, 1:M, or M:M).

0079Therefore, Graphical Organizer <b>2</b> helps the cognitive processes involved in formatting a business rule, recognizing its elements, and concluding the ERD segment for the business rule. This organization and refinement of textual user requirements is assumed to help guide the modeler through the process of ER modeling. For example the Graphical Organizer <b>2</b> shown in <figref idref="DRAWINGS">FIG. 4</figref> can be considered as a template used to refine the problem domain business rules/operations/activities. This graphical organizer or template helps lead the modeler to determine the business rule key elements, which are useful for the identification of candidate entities and relationships.

0080The template <b>38</b> has a top section including boxes <b>40</b> for restating the particular business rule being examined, its constraints/restrictions and exceptions. Below the top section is a middle section of labeled boxes <b>42</b> arranged in rows to show the relationship between pairs of entities and their distributive aspect (1:1, 1:M, or M:M). Below the middle section is a bottom section of labeled boxes <b>44</b> for stating conclusions regarding the distributive classification of the relationship, and for identifying any parent and child entities. <figref idref="DRAWINGS">FIG. 5</figref> shows an exemplary Graphical Organizer #<b>2</b>, filled out for a sales processing system.

0081A blank Graphical Organizer #<b>3</b>, designated generally as <b>48</b> in the drawings, is shown in <figref idref="DRAWINGS">FIG. 6</figref>, and an exemplary completed template <b>48</b> is shown in <figref idref="DRAWINGS">FIG. 7</figref>. Graphical Organizer #<b>3</b> is used to clarify the distributive aspects of a M:M (many-to-many) relationship, and to identify any associative, bridge, or child entities that have corresponding intermediate 1:M and M:1 relationships. Since the M:M relationship does not translate well into a database, it is common in the design phase to create a bridge entity to split the M:M relationship into two 1:M relationships. The template <b>48</b> contains a row of labeled outside blocks <b>50</b> for the parent entities situated above blocks <b>52</b> identifying the parent entities as the “1” component of the relationship, and a central box <b>54</b> for identifying the bridge entity situated above a split column block <b>56</b> identifying the bridge entity as the “M” component of the 1:M and M:1 relationships.

0082A blank Graphical Organizer #<b>4</b>, designated generally as <b>58</b> in the drawings, is shown in <figref idref="DRAWINGS">FIG. 8</figref>, and an exemplary completed template <b>58</b> is shown in <figref idref="DRAWINGS">FIG. 9</figref>. Graphical Organizer #<b>4</b> is used to define the attributes of an entity based on the characteristics of the entity. For example, the characteristics of a student entity are ID, Name, Address, Phone, Date of Birth, etc. The template <b>58</b> includes a rectangular identification block <b>60</b> for identifying the entity by name, a definition block <b>62</b> immediately below the identification block <b>60</b>, and a split column of blocks <b>64</b> and <b>66</b> immediately below the definition block <b>62</b> for listing each attribute and a description of the attribute respectively, corresponding to the entity named in identification block <b>60</b>. Attributes may be notated on an ERD adjacent the entity.

0083A blank Graphical Organizer #<b>5</b>, designated generally as <b>68</b> in the drawings, is shown in <figref idref="DRAWINGS">FIG. 10</figref>, and an exemplary completed template <b>68</b> is shown in <figref idref="DRAWINGS">FIG. 11</figref>. Graphical Organizer #<b>5</b> is used to define the entity participation in a relationship between two entities. Graphical Organizer #<b>5</b> includes a split column of entity name blocks <b>70</b> and <b>72</b> for naming the two entities being considered in the template <b>68</b>, each entity name block having a corresponding distribution block <b>71</b> and <b>73</b> embedded therein to indicate the distributive character of the named entity in the entity relationship, as determined in Graphical Organizer #<b>2</b>, i.e., distribution blocks <b>71</b> and <b>73</b> will contain an entry of “1” or “M” according to whether the entity corresponds to a one or many in a 1:1, 1:M or M:M relationship.

0084Immediately below the entity name blocks <b>70</b> and <b>72</b>, the template <b>68</b> includes blocks <b>74</b> for stating the business rule, its constraints/restrictions, and exceptions, which are also carried over from Graphical Organizer #<b>2</b>. Below the business rule blocks <b>74</b> is a split column of blocks <b>75</b><i>a </i>and <b>75</b><i>b</i>, which contain statements of the rule for determining whether the named entity's participation in the relationship is mandatory or optional. Finally, the template <b>68</b> includes a split column of conclusion blocks <b>76</b><i>a </i>and <b>76</b><i>b </i>to summarize the corresponding conclusion for the two entities named in entity name blocks <b>70</b> and <b>72</b>. The mandatory or optional nature of the entity's participation in the relationship may be symbolically notated on the ERD by a circle drawn through the connecting line between the entities to reflect that the relationship is optional.

0085A blank Graphical Organizer #<b>6</b>, designated generally as <b>78</b> in the drawings, is shown in <figref idref="DRAWINGS">FIG. 12</figref>, and an exemplary completed template <b>78</b> is shown in <figref idref="DRAWINGS">FIG. 13</figref>. Graphical Organizer <b>6</b> is used to define the entity cardinality in a relationship between two entities. Graphical Organizer #<b>6</b> includes a split column of entity name blocks <b>80</b> and <b>82</b> for naming the two entities being considered in the template <b>78</b>, each entity name block having a corresponding distribution block <b>81</b> and <b>83</b> embedded therein to indicate the distributive character of the named entity in the entity relationship, as determined in Graphical Organizer #<b>2</b>, i.e., distribution blocks <b>81</b> and <b>83</b> will contain an entry of “1” or “M” according to whether the entity corresponds to a one or many in a 1:1, 1:M or M:M relationship.

0086Immediately below the entity name blocks <b>80</b> and <b>82</b>, the template <b>78</b> includes blocks <b>84</b> for stating the business rule, its constraints/restrictions, and exceptions, which are also carried over from Graphical Organizer #<b>2</b>. Below the business rule blocks <b>84</b> is a split column of blocks <b>85</b><i>a </i>and <b>85</b><i>b</i>, which contain statements of the rule for determining the cardinality of the named entity in the relationship, i.e., the minimum and maximum numbers of the related entity connected with the named entity. Finally, the template <b>78</b> includes a split column of conclusion blocks <b>86</b><i>a </i>and <b>86</b><i>b </i>to summarize the corresponding conclusion for the two entities named in entity name blocks <b>80</b> and <b>82</b>. The cardinality of each entity may be symbolically notated on the ERD.

EXAMPLE

0087The application of the templates can be illustrated by application to a sales company database application. For purposes of the example, a marketing company wishes to create an information system to process and manage their sales business operations. Products sold by the company are supplied by vendors. The company resells the products to business customers on credit basis. Each customer must have a record in the sales company's database.

0088The customers can have credit limits for their accounts. When a customer purchases products, they receive invoices for their purchases and by the 20^thday of the month they receive statements for their monthly purchases, which should be paid within seven days after the statement date.

0089The invoice that a customer receives includes a number of line products. Each line in the invoice shows a line number, product description, number of units, charged price per unit, and total value per line, etc. Each line in an invoice refers to a certain product, which exists in the database.

0090The application of the proposed method is based on the proposed process shown in <figref idref="DRAWINGS">FIG. 1</figref>, which consists of two phases. Phases one and two are implemented and the resulting ERD model follows.

0091<figref idref="DRAWINGS">FIG. 14</figref> shows the implementation of phase one by execution of the Graphical Organizer #<b>1</b> template <b>100</b> to identify and summarize the business rules and their corresponding constraints/restrictions and exceptions. Four business rules are identified in template <b>100</b>, designated as the first <b>102</b>, second <b>104</b>, third <b>106</b>, and fourth <b>108</b> business rules, respectively.

0092Phase two may then be implemented by the execution of the various templates shown in <figref idref="DRAWINGS">FIGS. 15-30</figref>. <figref idref="DRAWINGS">FIG. 15</figref> shows a Graphical Organizer #<b>2</b>, designated as template <b>110</b>, directed towards the first business rule <b>102</b>. Template <b>110</b> identifies a Vendor entity at block <b>112</b> and a Product entity at block <b>114</b>.

0093<figref idref="DRAWINGS">FIG. 16</figref> shows a Graphical Organizer #<b>4</b> template, designated as template <b>116</b>, completed to show the attributes of the Vendor entity identified by template <b>110</b>. <figref idref="DRAWINGS">FIG. 17</figref> shows a Graphical Organizer #<b>4</b> template, designated as template <b>118</b>, completed to show the attributes of the Product entity identified by template <b>110</b>. <figref idref="DRAWINGS">FIG. 18</figref> shows a Graphical Organizer #<b>5</b>, designated as template <b>120</b>, completed for the Vendor-Product relationship identified as 1:M by template <b>110</b>, and concludes that the Product entity is optional to the Vendor entity, and that the Vendor entity is also optional to the Product entity.

0094<figref idref="DRAWINGS">FIG. 19</figref> shows a Graphical Organizer #<b>6</b> template, designated as template <b>122</b>, showing the cardinality of the Vendor and Product entities in the Vendor-Product relationship, viz., (0,M) for the Vendor entity and (0,1) for the Product entity.

0095<figref idref="DRAWINGS">FIG. 20</figref> shows a Graphical Organizer #<b>2</b> template, designated as template <b>124</b>, completed for the second business rule <b>104</b> identified by template <b>100</b>. Template <b>124</b> names the entities identified by the second business rule <b>104</b> as the Customer entity in block <b>126</b> and the Invoice Entity in block <b>128</b>.

0096<figref idref="DRAWINGS">FIG. 21</figref> shows a Graphical Organizer #<b>4</b> template, designated as template <b>130</b>, summarizing the attributes of the Customer entity identified by template <b>124</b>. <figref idref="DRAWINGS">FIG. 22</figref> shows a Graphical Organizer #<b>4</b> template, designated as template <b>132</b>, summarizing the attributes of the Invoice entity identified by template <b>124</b>. <figref idref="DRAWINGS">FIG. 23</figref> shows a Graphical Organizer #<b>5</b> template, designated as template <b>134</b>, completed for the Customer-Invoice relationship identified as 1:M by template <b>124</b>, and concludes that the Invoice entity is mandatory to the Customer entity, and that the Customer entity is also mandatory to the Invoice entity. <figref idref="DRAWINGS">FIG. 24</figref> shows a Graphical Organizer #<b>6</b> template, designated as template <b>136</b>, showing the cardinality of the Customer and Invoice entities in the Customer-Invoice relationship, viz., (1,M) for the Customer entity and (1,1) for the Invoice entity.

0097<figref idref="DRAWINGS">FIG. 25</figref> shows a Graphical Organizer #<b>2</b> template, designated as template <b>138</b>, completed for the third business rule <b>106</b> identified by template <b>100</b>. Template <b>138</b> names the entities identified by the third business rule <b>106</b> as the Invoice entity in block <b>140</b> and the Line Entity in block <b>142</b>.

0098<figref idref="DRAWINGS">FIG. 26</figref> shows a Graphical Organizer #<b>4</b> template, designated as template <b>144</b>, completed to show the attributes for the Line entity identified by template <b>138</b>. <figref idref="DRAWINGS">FIG. 27</figref> shows a Graphical Organizer #<b>5</b> template, designated as template <b>146</b>, completed for the Invoice-Line relationship identified as 1:M by template <b>138</b>, and concludes that the Line entity is mandatory to the Invoice entity, and that the Invoice entity is also mandatory to the Line entity. <figref idref="DRAWINGS">FIG. 28</figref> shows a Graphical Organizer #<b>6</b> template, designated as template <b>148</b>, showing the cardinality of the Invoice and Line entities in the Invoice-Line relationship, viz., (1,M) for the Invoice entity and (1,1) for the Line entity.

0099<figref idref="DRAWINGS">FIG. 29</figref> shows a Graphical Organizer #<b>2</b> template, designated as template <b>150</b>, completed for the fourth business rule <b>108</b> identified by template <b>100</b>. Template <b>150</b> names the entities identified by the fourth business rule <b>108</b> as the Product entity in block <b>152</b> and the Line Entity in block <b>154</b>. The relationship is characterized as a 1:M relationship between the Product and Line Entities.

0100<figref idref="DRAWINGS">FIG. 30</figref> shows a Graphical Organizer #<b>5</b> template, designated as template <b>156</b>, completed for the Invoice-Line relationship identified as 1:M by template <b>150</b>, and concludes that the Line entity is optional to the Product entity, and that the Product entity is mandatory to the Line entity.

0101<figref idref="DRAWINGS">FIG. 31</figref> shows an Entity-Relationship Diagram (ERD) prepared from the information that is graphically organized in <figref idref="DRAWINGS">FIGS. 14-30</figref>. The following symbolic notation conventions are observed in the ERD of <figref idref="DRAWINGS">FIG. 31</figref>. Entities are shown in rectangular boxes <b>160</b>. Relationships are shown by solid lines <b>162</b> connecting the boxes, which are annotated by text labels <b>164</b> adjoining or breaking the connecting lines adjacent the corresponding entity. The connecting lines <b>162</b> are annotated by cardinality notation <b>166</b> adjacent the corresponding entity boxes <b>160</b>.

0102Many entities on a given side of a relationship are notated by a crow's-foot <b>168</b>. A circle <b>170</b> in the connecting line <b>162</b> denotes the possibility that entities may be related, but not in all instances. A single bar <b>172</b> in a connecting line indicates there is one entity on that side of the relationship. A double bar <b>174</b> indicates that there is one and only one entity on that side of the relationship. The completed entity-relationship diagram makes the design of the corresponding database a considerably easier task.

0103It will be seen by those skilled in the art that the six templates in the system of the present invention organize the data in a graphical manner that readily corresponds to the symbolic notation of ERD modeling. It will also be seen by those skilled in the art that the templates, executed in the proper sequence, provide a systematic approach to organizing the data required for completing an ERD model, rather than general guidelines that result in a hit-and-miss approach.

0104The present inventor has tested the method of teaching entity-relationship modeling upon groups of computer science students, including a control group (fifty-two students) and a group (sixty-four students) trained in the use of the templates, and evaluated the results on a scale of 0-100 using T-test and Levene's test and found that students trained in the use of the templates scored significantly higher (mean of 75.9844 vs. mean of 65.3846), confirming the validity of the system and method of the present invention.

0105It will be obvious to those skilled in the art that the templates may be computerized into forms written in hypertext markup language (HTML), extensible markup language (XML), Java®, JavaScript® (Java and JavaScript are trademarks of Sun Microsystems, Inc.), C, C++, Visual Basic® (Visual Basic is a trademark of Microsoft Corporation), or numerous other programming languages. Such forms may be used to gather data in a logical, systematic, and organized manner (testing the forms for consistency and completeness, prompting for the entry of further data or forms when necessary) as input data for a Computer Aided Software Engineering (CASE) program or other drawing program that may be used to draw or to automatically generate an Entity-Relationship Diagram from the data entries in the templates.

0106When the templates are computerized, the templates or computerized forms, together with any associated scripting program or application program for verifying the completeness and consistency of the templates and for integrating the data supplied by the templates into a CASE or other drawing program will be stored on a computer readable medium with instructions that, when executed by a computer processor, will display the forms on a monitor, accept and store data for completing the templates from an input device (such as a keyboard), parse the data, and translate the data into a form usable by the CASE or other drawing program.

0107The term “computer readable medium” refers to a hard disk drive, a floppy diskette, a ZIP disk, any other magnetic storage media capable of storing coded program instructions, an optical or laser storage device, such as a compact disk or laser disk, paper tape, punch cards, or any other media for the storage of program instructions readable by a disk storage device or reader.

0108It is to be understood that the present invention is not limited to the embodiments described above, but encompasses any and all embodiments within the scope of the following claims.