critique 1

See d is c u ssio n s, s ta ts , a n d a u th or p ro fil e s f o r t h is p ub lic a tio n a t: http s:/ /w ww.r e se a rc h ga te .n et/ p ub lic a tio n /3 227223 En tit y - re la tio n sh ip m od elin g Artic le in IE EE P ote n tia ls · F e b ru ary 1 995 DO I: 1 0.1 109/4 5.4 64652 · So u rc e : I E EE X p lo re CIT A TIO NS 10 REA D S 548 2 a u th ors , i n clu d in g:

So m e o f t h e a u th ors o f t h is p ub lic a tio n a re a ls o w ork in g o n t h ese r e la te d p ro je cts :

Sm art A gin g Vie w p ro je ct Il- Y e o l S o n g Dre xe l U niv e rs it y 252 PU BLIC ATIO NS 2,7 19 CIT A TIO NS SEE P R O FIL E All c o n te n t f o llo w in g t h is p age w as u p lo ad ed b y Il- Y e o l S o n g o n 1 6 M arc h 2 013.

Th e u se r h as r e q ueste d e n han ce m en t o f t h e d ow nlo ad ed f il e . All i n -t e xt r e fe re n ce s un d erlin ed i n b lu e a re a d ded t o t h e o rig in al d ocu m en t an d a re l in ked t o p ub lic a tio n s o n R ese a rc h G ate , l e ttin g y o u a cce ss a n d r e a d t h em i m med ia te ly . A practical how-to guide he Entity-Relationship (ER) model and its accompanying ER diagrams are widely used r for database design and sys- tems analysis. Many books and arti- cles just provide a definition of each modeling component and give exam- ples of the pre-built ER diagrams. As a result, beginners in data modeling have a great deal of difficulty learning how to approach a given problem, what questions to ask in order to build a model, what rules to use while con- structing an ER diagram, and why one diagram is better than another.

Therefore, we will present step-by- step guidelines, a set of decision rules proven to be useful in building ER diagrams, and a case study problem with a preferred answer as well as a set of incorrect diagrams for the prob- lem. These guidelines and decision rules have been successfully used in our beginning Database Management System course for the last five years. The ERD The entity relationship diagram (ERD) is a graphical representation of a problem domain being modeled.

The ERD assists the database design- er in identifying the data and the rules that will be represented and used in a database. The ERD is an implementa- tion-independent representation of a problem domain and it facilitates communication between the end-user and the analyst.

The basic components of the ERD are entities, properties of entities called attributes, and relationships between entities. Entities are primary things of a problem domain about which users need to record data. Ross (1988) pro- vides a list of candidate entity types which can be included: 1) People: humans who carry out some function Employees, Students, Customers 2) Places: sites or locations Cities, Offices, Routes 3) Things: tangible physical objects Equipment, Products, Buildings 4) Organizations:

Teams, Suppliers, Departments 5) Events: things that happen to another entity at a given date and time or as steps in an ordered sequence Employee promotions, Project phases, Account payments among things or entity types.

It describes a meaningful action between associated entity types. From the practical point of view, it is an interaction that needs to be remem- bered by the database system. The degree of a relationship indicates how many entitiy types are participating in the relationship. A unary relationship describes an association of an entity type with itself. A binary relationship, the most common instance, describes an association between two entity 6) Concepts: intangible ideas that track business or other activities Projects, Accounts, Complaints Attributes are properties of entities or relationships. Enti- ties have two properties: iden- tifying attributes and descriptive attributes. Identi- fying attributes uniquely determine each instance of an entity type. They are called entity identifiers or keys. For example, the attribute social security number would uniquely identify each mem- ber or each instance of the entity type, student. Descrip- tive attributes of student might include: year, advisor, and grade point average. Each instance of an entity has a value for each attribute. Val- ues for grade point average might include:

2.5, 3.45, and 4.0. Values for year might include: 1991,1992,1993, and 1994. Only attributes that are meaningful in terms of model- ing the problem under consideration are included in the ERD. For example, we would not include eye color in a student database.

Relationships are another basic component of the ERD. A relation- ship is an association between or types.

An n-ary relationship is an association between three or more entity types. The ER methods that allow only unary and binary relation- ships are called binary models, while ER methods that allow any type of relationship are called n-ary models. DECEMBER ‘94lJANUARY ‘95 0278-6648/94/$4.00 0 1994 IEEE - ____.___- 29 (a) One-to-one (1:l) One customer can have at most one account.

One account cannot be owned by more than one customer 1 ER Diagram 1 13 A3 Occurrence Diagram (b) One-to-Many (1 :n) One customer can have many accounts.

One account cannot be owned by more than one customer. I ER Diagram 1 n Occurrence Diagram (c) Many-to-Many (n:m) One customer can have many accounts.

One account may be owned by many customers.

ER Diagram Fig. I CARDINALITY: The expression of the maximum number of entities that can be associated to another entity via a relationship. Occurrence Diagrams show the relationships between occur- rences or instances of each entify. customers. Participation is also a relationship constraint. Participa- tion expresses the minimum number of entities that can be associated with another entity via a relationship. There are two values for participation: total or mandatory participa- tion, and partial or optional participation.

If in every instance an entity must participate in a given relationship then that entity has total participation in the relationship. But if in every instance an entity need not participate in a given relationship then the participation is par- tial. Given the rela- tionship “employee works for depart- ment,” an employee has partial participa- tion in that relation- ship if he or she need not work for a department. An employee has total Cardinality and participation constraints Cardinality is a constraint on the relationship between two entities.

Specifically, the cardinality constraint expresses the maximum number of enti- ties that can be associated with another entity via a relationship. For example, in a binary relationship (a relationship with two participating entities), we can have three possible cardinalities: one-to- one (l:l), one-to-many (l:N), or many- to-many (M:N).

One-to-one cardinality says that, for entities customer and account, one cus- tomer can have at most one account and one account cannot be owned by more than one customer. One-to-many cardi- nality says that one customer can have many accounrs, but one accourzt cannot be owned by more than one customer. Many-to-many cardinality says that one customer can have many accounts and one account may be owned by many participation in the reiationship if he or she must work for at least one depart- ment. Similarly, a department has partial participation in the relationship if it can exist without having any employees. A department has total participation in the relationship if it must have at least one employee. Cardinality and participation con- straints are integrity constraints because they help to ensure the accuracy of the database. These constraints limit the ways in which data from different parts of the database can be associated. For example, let’s say the cardinality of the re 1 at i o n s h i p between c U s t om e I- and accounf is one-to-one, as in Fig. l(a). If customer C1 is associated with account A3, then C1 cannot be associated with any other accounts and A3 cannot be associated with any other customers. Taxonomy In an ER model, an entity is repre- sented as a rectangle containing the name of the entity. The names of attributes are enclosed in an oval connected to the rec- tangle they describe. Attributes may be omitted to avoid cluttering the diagram and in the early development stages.

Relationships are represented by dia- monds between entities. The notation of the ERD varies according to the model- ing approach used. Binary models do not use the diamond to indicate a rela- tionship, do not represent attributes of relationships, and do not allow ternary relationships, that is, relationships between three or more entities. A few notations are illustrated here.

Each diagram in Fig. 2 contains two entities: employee and department. In diagrams a, b, c, and d, the diamond indi- cates the relationship between the enti- ties. These diagrams use n-ary modeling.

Diagrams e through h are examples of binary modeling. They do not represent the relationship with the diamond shape.

Instead, diagrams e, f, and h label the line between the entities with the rela- tionship name. Attributes were not repre- sented in the diagrams for simplicity.

The various circles, lines, arrows, and letters on the diagram indicate cardinality and participation constraints. ER modeling How does one begin creating an enti- ty relationship diagram? In Table 1, we summarize a sequence of steps in data- base design using an ER model. Note that these steps are iterative. First, it is important to study the problem domain at hand. Analyze user requirements and describe them. Having a written description of the problem domain is absolutely recommended.

Next, identify the entity types. The following questions can help the analyst identify entities: What things do we need to store data about? What things are essential to the organization? What things do we talk about in the organiza- tion? What questions and reports do we need to process? What are the important people, places, physical things, organi- zations, events and abstract concepts in the organization?

Nouns are good candidates for entity types. To determine whether a noun should be designated as an entity, the fol- lowing decision rules may be applied. Rule 1 Every entity type should be impor- tant in its own right within the problem domain. ~~ ~ 30 IEEE POTENTIALS Rule 2 IF an object type (noun) has only one property to store THEN it is an attribute of another entity type ELSE it is an enti- tY type.

Rule 3 IF an object type has only one data instance THEN do not model as an enti- tY type.

Rule 4 IF a relationship needs to have a unique identifier THEN model it as an entity type.

The fiist three rules are used to eval- uate object types or nouns, and the fourth rule is used to evaluate relation- ships or verbs. Example 1. Address is usually a property of another object type, such as a customer, vendor, or company. Its existence is less important and not meaningful in its own right within the problem domain. Example 2. Suppose we are model- ing a company’s customers and we want to include the city where each cus- tomer resides. If the city’s name is the only attribute we need to store, then, following Rule 2, model city as an attribute not an entity. But if we need to store not only the city’s name but also population, state, and other characteris- tics of a city, then the city should be modeled as an entity type. Example 3. Consider modeling the activities of a trucking company. Since there is only one instance of the truck- ing company, then, according to Rule 3, it is not necessary to represent it in our model as an entity.

We need the fourth rule because one fact can be stated in many different ways in English. In the fourth rule, dis- tinguishing between entities and rela- tionships depends on the function the component plays in the problem domain and how data will be stored about it. Example 4. Consider the three state- ments: customer orders products, cus- tomer pays bills, and reviewer reviews papers. Even though orders and pays appear to represent relationships, we model them as entities since each instance would need a unique number for identification. Information would be stored in the database for each order and payment. Each review is not likely to need a unique identification number.

Thus, by Rule 4, we model reviews as a relationship type. What sentences can be constructed A 6 n 1 Department a) Chen Employee s Department b) Teorey n Employee Department c) Efmasri & Navathe works-for Employee :( -1 Department e) Information Engineering Employee is-worked-for (Martin) b-4 has Department 1 f)Bachman )bE - - - - -[Department] g) IDEFIX works-for Fig. 2 Various notations for ER Diagram representing “one employee works for zero or one department and one department has one or more employ- ees. ” Employee has children (Existence relationship). Professor teaches students (Func- tional relationship). Customer places order (Event rela- tionship). Keep in mind that all relationships are bi-directional. We should be able to state the relationship in both directions.

Expressing the relationships above in the opposite direction yields the follow- ing statements: Children belong to employee. Students are taught by professor. Order is placed by customer.

After an ERD has been built, the fol- lowing rule can aid in validating the diagram. Rule 5 IF any verb refers to nouns which are not selected as entity types THEN do not model it as a relationship type.

If any verb in the ERD fails to fol- low Rule 5, then consider it again care- fully before including it in the diagram.

When entities and relationships have been identified, then the cardinality and participation constraints of the relation- Rule 6 For each A, what is the maximum number of Bs that may be related to it? Rule 7 IF A can exist without being associ- ated with a B THEN A has partial (optional) participation ELSE A has total (mandatory) participation. Example 5. Consider the relationship “Supplier Supplies Account.” For each Supplier, what is the maximum number of Accounts that may be related to it?

Let’s say that in our problem domain, each Supplier may have many Accounts but each Account may have only one Supplier. By Rule 6, the cardinality con- straint for Supp1ier:Account is N: 1 or many to one. Fig. 1 illustrates the cardi- nality constraints. Example 6. In determining the par- ticipation constraint of “supplier sup- plies account,” we follow Rule 7. In our problem domain, supplier may exist without being associated with account.

Therefore, supplier has partial participa- tion in the supply relationship. Howev- er, since account cannot exist without a supplier; account has total participation DECEMBER ‘94/JANUARY ‘95 31 in the supply relationship.

Some basic naming conventions have been established to maintain accu- racy and consistency in the database and to avoid redundancy. Use singular nouns in the diagram for both entity and attribute names. Use verbs in the pre- sent tense for relationship names. Verbs should be meaningful. For example, avoid verbs such as is, has, and do whenever possible. Additionally, well- defined ERDs should satisfy the follow- ing basic rules: All entities and relationships should be connected.

All entity names should be unique.

Each entity must have at least one relationship.

A relationship cannot be directly connected to another relationship.

Every entity must have at least one unique attribute, which serves to identi- fy each instance of that entity. Case study The nouns in the problem description appear in boldface and the verbs are itali- cized to aid in the following analysis.

A database specialist wants to design a part of the database for a small drug store owner as follows:

The owner wants to keep truck of all the suppliers who supply anything to the store. For each supplier, the owner assigns a unique supplier number, and wants to keep the company name, address (number, street, city, state, zip), contact person’s name, phone number, fax number, and a comment for each supplier. For each supply activi- ty, an account is established to keep truck of the date incurred, the total cost of the activity, due date for payment, outstanding balance after some pay- ments, and any special comments relat- ed to the account. For each account, the owner may pay at several different times and in different ways (e.g., cash, check, credit card). For each payment activity, the owner wants to keep the date of pay- ment, amount of payment, method of payment (check: check number; credit card: credit card name, type, and num- ber). Note that one supplier can supply many times and one payment can pay for several accounts of the same supplier. Entity analysis After reading and understanding the problem statement, our first step is to identify entities for the ERD. To do that we examine the nouns in the problem statement.

We test each noun against our three criteria to determine whether it should be included as an entity type.

Our first noun is owner. Recall that an entity type has more than one instance and more than one property. Since there is only one instance of owner, we do not model it as an entity type.

The next noun, supplier, can be classified as an entity type. Several properties of supplier are listed in the problem statement. The statement also refers to more than one supplier. There- fore, according to Rules 1, 2, and 3, we model supplier as an entity.

For each supplier, the owner wants to store the following properties in the database: supplier number, company name, contact person, address, phone number, fax number, and comment.

Each of these attributes except address has only one property to store so we model them as attributes. Address has its component proper- ties number, city, state, and zip so one might be tempted to model it as an enti- ty type. However, the role of address as a property of supplier supersedes the fact that address has properties of its own. In other words, address itself with- out supplier is not important in its own right. Therefore, by Rule 1, we model address as an attribute. Account is the next noun. Account has several properties to be stored in the database: date incurred, total cost, due date, account balance, and comments; and we will store information about numerous accounts. Therefore, we des- ignate account as an entity. Its proper- ties are modeled as attributes. Payment is clearly an entity with multiple instances and various properties.

The properties of paymentdate of pay- ment, amount of payment, and method of payment-are modeled as its attributes.

Cash, check, and credit card appear to be attributes of payment, but actually, they are not attributes themselves, but simply different values for the attribute method of payment. This distinction becomes clearer if we think about storing data in the data- base. For each payment, one of the values:

cash, check, or credit card will be stored in the location containing data about the method of payment. Check number and credit card name, type and number may be modeled as attributes of the method of payment attribute. Relationship analysis Now let’s examine the verbs in the problem statement as candidates for relationships in the diagram. Verbs appear in italics. Of the verbs in the problem statement: keep track, supply, assigns, keep. established, and pay, only supply and pay are possible candidates for relationships between the entities account, supplier, and payment. Keep track and keep appear several times in the problem statement. These terms refer, not to a relationship between enti- ties, but generally to storing data in the database. Therefore, by Rule 5, we do not model them as relationships. Established, in the statement an “account is established,” is an activity performed by the owner or the system itself. Similarly, owner assigns a unique supplier number reflects an activity by the owner. These two verbs do not rep- resent relationships between any of our three entities. Thus, we are left with the verbs supply and pay. A supplier performs a supply activi- ty. The result of a supply activity is an account. Therefore, a good candidate for the relationship between supplier and account is supply. Stated in both directions, the relationship is supplier supplies account and account is sup- plied by supplier. Rule 4 states that if a relationship needs to have a unique identifier, then model it as an entity. Each supply activ- ity is unique, so we may be tempted to model supply as an entity. However, the I’WT] Supplier e Payment Fig. 3 ERD without constraints data for each activity is stored using the entity, account, so it is not necessary to create another entity which stores the same information.

Each payment credits an account so pay is the relationship between payment and account. Expressing the relationship pay in both directions, we can say account is paid by payment and pay- ment pays account. Now we can draw the basic ERD (Fig. 3). We include the entities suppli- er, account, and payment, and the rela- tionships supply and pay. Attributes may be added to the diagram at this point or omitted to avoid clutter.

Analysis of constraints In order to identify the cardinality and participation constraints of each relationship in the ERD, we follow Rules 6 and 7. In our ERD, we begin by asking, “For each supplier, what is the maximum number of accounts that may be created?” From the problem state- ment, we know that one supplier can supply many times and an account is established for each supply activity.

Viewing the relationship in the other direction, we ask, “What is the maxi- mum number of suppliers for which each account may contain information?” From the problem statement we can assume that each account carries infor- mation for a single supplier, since accounts are established for individual supply activities. Thus, for each suppli- er, there may be many accounts and each account may have only one suppli- er. The relationship supplier supplies account is a one-to-many relationship.

The diagram is marked with a I on the side of the relationship Supply nearer to Supplier, and an N (for many) on the side nearer to Account (see Fig. 4). To identify the cardinality of the rela- tionship payment pays account, we look at the relationship from both directions.

We ask, “What is the maximum number of payments we can accept for each account?” The answer is clearly stated in the problem statement: For each account, the owner may pay at several different times and in different ways. From the opposite direction, “For each payment, what is the maximum number of accounts for which it may pay?” Again, we find the answer in the problem state- ment: One payment can pay for several accounts of the same supplier.

Therefore, the relationship payment pays account is many-to-many. This time, we mark our diagram with an M on one side of the relationship Pay and an N on the other side.

We go through a similar process to determine the participation constraint of each relationship, looking at the rela- tionship from each direction. In a real world situation, the database designers would clarify questions like these with the owner. In this case, we will make assumptions.

Suppliers are generally fairly stable entities. A company maintains relation- ships with several regular suppliers regardless of whether they have out- standing accounts. On the other hand, an account is only created when a supplier supplies merchandise. Since suppliers can exist without having current accounts, Supplier has a partial participa- tion in the Supply relationship. Accounts, however, depend on suppliers for their existence. Thus, Account has total partic- ipation in the Supply relationship.

In representing the cardinality and participation constraints described above in our ERD, we will employ Elmasri and Navathe’s (1994) notation. If an entity has partial participation in the relationship, then a single line is drawn between that entity and the relationship.

A double line indicates total participa- tion. Fig. 4 illustrates the final ERD with cardinality and participation constraints. Common errors A common error that novice design- ers make is failing to recognize the boundaries of a problem domain. They fail to make a distinction between ele- ments that comprise the content of the database and elements that are outside the scope of the database.

For example, in the problem state- ment above, a novice might want to model the verbs keep truck or assigns or established as relationships (see Fig. 321)). These verbs refer to implement- Supplier Account M Fig. 4 Completed ERD for the drug store problem. ing the database and not to its content.

Keep track refers to storing data in the database, established refers to adding an instance of an entity to the database, and ussigns refers to giving a value to an attribute of an entity. In deciding which elements to model, it is valuable to keep in mind the real world situation. Their interactions don’t need to be remem- bered by the system. The system only needs to remember who supplies what account and which payment pays for which account.

Novice users also frequently confuse entities and their attributes or properties, as in Fig. 5 (b). Occasionally, if proper- ties are complex and play a significant role in the problem domain, then they may be modeled as entities. More often, however, properties of an entity should be modeled as attributes.

In our problem statement, a novice Table 1. Database design using the ER model. 1. Understand the problem. Analyze user requirements. What things do we need to keep data about? What things are essential to the organization? What things do we talk about in the organization? - What queries and reports do we need? What are imporfaant people, places, physical things, organizations, events and abstract a) Identify entity types. Assign nouns for entity names.

b) Identify relationship types among (between) entity types. Use meaningful verbs for concepts in the organization? 2. Create ER diagrams.

relationship names, if possible. Otherwise, use abbreviations from each participat- ing entity names.

c) Draw an ER diagram without attributes.

d) Identify relationship types. 1) Mapping cardinality (1 :1, 1 :N, N:l, N:M) 2) Total or partial e) Assign attributes to entity types and relationship types. Usually, an attribute comes from an adjective, an adverb, or a noun. f) Decide the primary key for entity types. Choose a single attribute for entity type. If not possible, create a single attribute for the key.

g) Decide the primary key of relationship types. 1) If 1 :1, then key of either side entity type. 2) If 1 :N, then key of N-side entity type. 3) If N:M, then concatenate keys of two entity types. 4) If ternary, then concatenate keys of participating entity types, h) Create Data Dictionaries. 1) A schema table 2) One table for each object type. Assign a domain type for each attribute. Explain 3) Explain the meaning of each relationship in detail.

depending on cardinalities.

the meaning of attributes, if not intuitive. DECEMBER ‘94/JAN UA RY ‘95 33 Owner (c) Indirect relationship Payment Supplier Payment Account (d) Payment as relationship instead of entity Supplier Account Fig. 5 Incorrect ERDs. user may decide to model address, a property of the entity supplier, as an entity. Modeling address follows Rules 2 and 3 about identifying entities: it has more than one property and it has more than one occurrence. However, address does not follow Rule 1 in that it is not important in its own right. The role of address in the database is more accurate as an attribute of supplier, than as an entity with its own relationships.

Other errors are modeling indirect or redundant relationships and inappropri- ately modeling object types as relation- ships rather than as entities. Given our problem statement, one may be tempted to model the relationship payment pays supplier as in Fig. 5(c) or supplier pays account as in Fig. S(d) rather than pay- ment pays account. It is true that a pay- ment goes to a supplier, but that relationship is indirect. A payment directly goes to an account which belongs to a supplier. Thus payment in Fig. 5(c) is indirect, and cannot exist without the relationship between pay- ment and account. Also, it is difficult to explicitly represent the fact that one payment can pay for several accounts of the same supplier.

We can only tell implicitly by read- ing the check number for the various payments. If the payment is made in cash, there is no way to identify that it paid for more than one account.

If the representation used in Fig. S(d) is used, then the attrib- utes related to payments: date of payment, amount of payment, and method of payment, are now attributes of the relationship Pay.

This representation can add unnecessary complexity to the model. Ordinarily, a relationship is uniquely represented by the identifiers of the entities which participate in it. If the relationship includes a time-dependent attribute like date of payment, then that attribute must also be included in the primary key for that relation- ship. Additionally, instances of date of payment and amount of payment will require redundant representation because they will have to be included for each account covered by a payment.

Finally, in business practice, each payment activity usually requires a unique identifier.

Therefore, following Rule 4, it is more appropriate to model payment as an entity than as a relationship. As an entity, the representation is more straightforward and less likely to include redundant or inaccurate infor- mation.

Limitations Two limitations of our guidelines are that they don’t account for incomplete requirements analysis or for ambiguity in the problem description. If the prob- lem description is incomplete, then the resulting analysis based on this approach will also be incomplete. We assume that the analysis is complete. If the problem specification is modified, the analysis and resulting ERD should be modified as well. In English, one concept can be represented in many dif- ferent ways.

For example, we can say that “cus- tomer orders products” or “customer places an order to buy products.” Order is used as a verb in the first sentence and as a noun in the second. We mini- mize this problem by adopting Rule 4. Conclusion ERD constructs discussed here include entities, relationships, attributes, cardinality constraints and participation constraints. We didn’t include other constructs such as weak entity, ternary relationship, and generalization/special- ization to simplify our discussion. Our rules are heuristics which we have found useful for most cases to build ERDs in the early stages of analysis.

However, these rules may need some refinement in some problem domains Read more about it Ahrens, J. and Song, I.Y. (1991).

“EER Data Modeling Aids for Novice Database Designers,” Proceedings of the 2nd International Conferences of the Information Resources Manage- ment, Memphis, TN, May 19-22, 1991, Bruce, T. (1992). Designing Quali- ty Databases with IDEFlX Information Models. New York, New York: Dorset House Publishing. Chen, P.P., (1976). “The Entity Relationship Model - Toward a Unified View of Data,” ACM Transactions on Database Systems, 1 :I, pp. 9-36. Elmasri, R. and Navathe, S., (1994).

Fundamentals of Database Systems 2nd Ed., Redwood City, CA: Benjamin/ Cummings Publishing Company, Inc. Ross, R.G., (1988). Entity Model- ing: Techniques and Application, Data- base Research Group, Inc.

Shlaer, S. and Mellor, S.J. (1988). Object-Oriented Systems Analysis:

Modeling the World in Data, Engle- wood Cliffs, NJ: Yourdon Press. Teorey, T.J., Yang, D., and Fry, J.P., (1986), “A Logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model,” Computing Sur\,eys, 18: 12, June, pp. 197-222. pp. 99-1 14.

About the authors 11-Yeol Song is an Associate Profes- sor in the College of Information Stud- ies at Drexel University. He has published over thirty technical articles in various conference proceedings and journals. He was the guest editor of Journal of Computer & Software Engi- neering for a special issue entitled Methodologies and Tools for Intelligent Information Systems. Kristin Froehlich is a graduate stu- dent at the College of Information Stud- ies, Drexel University, pursuing an M.S.

in Information Systems. She has a B.A.

in Psychology from Franklin & Mar- shall College in Lancaster, PA. Her areas of interest include computer-based training, database design methodologies and multimedia applications. 34 IEEE POTENTIALS ___ ____-_____ . __ View publication statsView publication stats