System Design (Lecture 3: Logical System design) Dr. M. A. Rouf Dept. of CSE, DUET

The Process of Logical Data Modeling Fact-Finding and Information Gathering for Data Modeling Data models cannot be constructed without appropriate facts and information as supplied by the user community. These facts can be collected by a number of techniques such as sampling of existing forms and files; research of similar systems; surveys of users and management; and interviews of users and management. The fastest method of collecting facts and information, and simultaneously constructing and verifying the data models is Joint Application Development (JAD). 189 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

177 Table 5.4 JAD and Interview Questions for Data Modeling The table above summarizes some questions that may be useful for fact finding and information gathering as it pertains to data modeling. Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Computer-Aided Systems Engineering (CASE) for Data Modeling Data models are stored in the repository. In a sense, the data model is metadata – that is, data about the business’ data. Computer-aided systems engineering (CASE) technology, provides the repository for storing the data model and its detailed descriptions. 189-190 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Computer-Aided Systems Engineering (CASE) for Data Modeling Using a CASE product, you can easily create professional, readable data models without the use of paper, pencil, erasers, and templates. The models can be easily modified to reflect corrections and changes suggested by end-users. Most CASE products provide powerful analytical tools that can check your models for mechanical errors, completeness, and consistency. 190 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Computer-Aided Systems Engineering (CASE) for Data Modeling Not all data model conventions are supported by all CASE products. It is very likely that any given CASE product may force the company to adapt their methodology’s data modeling symbols or approach so that it is workable within the limitations of their CASE tool. 190 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 1st Step - Entity Discovery The first task in data modeling is to discover those fundamental entities in the system that are or might be described by data. There are several techniques that may be used to identify entities. During interviews or JAD sessions with system owners and users, pay attention to key words in their discussion. During interviews or JAD sessions, specifically ask the system owners and users to identify things about which they would like to capture, store, and produce information. Study existing forms and files. Some CASE tools can reverse engineer existing files and databases into physical data models. 190-192 There are several techniques that may be used to identify entities. For example, during an interview with an individual discussing SoundStage’s business environment and activities, a user may state that “We have to keep track of all our members and the many clubs in which they are enrolled.’’ Notice that the key words in this statement are MEMBERs and CLUBs. Both are entities! Another technique for identifying entities is to study existing forms and files. Some forms identify event entities. Examples include ORDERs, REQUISITIONs, PAYMENTs, DEPOSITs, and so forth. But most of these same forms also contain data that describe other entities. Consider a registration form used in your school’s course registration system. A REGISTRATION is itself an event entity. But the average registration form also contains data that describe other entities, such as STUDENT (a person), COURSEs (which are concepts), INSTRUCTORs (other persons), ADVISOR (yet another person), DIVISIONs (another concept), and so forth. These same entities could also be discovered by studying the computerized registration system’s computer files databases, or outputs. Some CASE tools can reverse engineer existing files and databases into physical data models. The analyst must usually clean up the resulting model by physical names, codes, and comments with their logical, business-friendly equivalents. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 1st Step - Entity Discovery A true entity has multiple instances—dozens, hundreds, thousands, or more! Entities should be named with nouns that describe the person, event, place, or tangible thing about which we want to store data. Try not to abbreviate or use acronyms. Names should be singular so as to distinguish the logical concept of the entity from the actual instances of the entity. Define each entity in business terms. Don’t define the entity in technical terms, and don’t define it as ‘data about …’. Your entity names and definitions should establish an initial glossary of business terminology that will serve both you and future analysts and users for years to come. 192 Names may include appropriate adjectives or clauses to better describe the entity—for instance, an externally generated CUSTOMER ORDER must be distinguished from an internally generated PURCHASE ORDER. Dr. M. A. Rouf, Dept. of CSE, DUET

192 Table 5.5 Fundamental Entities for the Soundstage Project No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 2nd Step - The Context Data Model The second task in data modeling is to construct the context data model. The context data model includes the fundamental or independent entities that were previously discovered. An independent entity is one which exists regardless of the existence of any other entity. Its primary key contain no attributes that would make it dependent on the existence of another entity. Independent entities are almost always the first entities discovered in your conversations with the users. Relationships should be named with verb phrases that, when combined with the entity names, form simple business sentences or assertions. Always name the relationship from parent-to-child. 193 Some CASE tools, such as System Architect let you name the relationships in both directions. Dr. M. A. Rouf, Dept. of CSE, DUET

193-194 Figure 5.11 The SoundStage Context Data Model The ERD communicates the following: A CLUB establishes one or more AGREEMENTs. Members will learn about these agreements through advertisements and other marketing programs. An AGREEMENT is established by exactly one CLUB. The double hash marks mean one-and-only-one. An AGREEMENT binds zero, one, or more MEMBERs. Members join clubs via such an agreement. Why zero? Because a club may be new with no membership as yet. A MEMBER is bound by one or more AGREEMENTs. Note: This is a non-specific (or many-to-many) relationship. A MEMBER belongs to one or more CLUBs. A CLUB enrolls zero, one, or more MEMBERs. Again, the club may be new. Each month or quarter, a CLUB sponsors zero, one, or more PROMOTIONs. Why zero? Again, a club may be just starting, and not yet offering promotions. A PROMOTION is sponsored by exactly one CLUB. Each PROMOTION features exactly one PRODUCT. A PRODUCT is featured in zero, one, or more PROMOTIONs. For example, a CD that appeals to both country/western and light rock audiences might be featured in the promotion for both. Since products greatly outnumber promotions, most products are never featured in a promotion. A PROMOTION generates many MEMBER ORDERs. These are dated orders to which a member must reply by the specified date – else the order is filled. The promotion always generates more than one order; in fact, it generates one order per club member. A MEMBER ORDER is generated for zero or one PROMOTION. Why zero? In the desired system, a member can initiate their own order. It is permissible for more than one relationship to exist between the same two entities if the separate relationships communicate different business events or associations. Thus, A MEMBER responds to zero, one, or more MEMBER ORDERs. This relationship supports the promotion-generated orders. A MEMBER places zero, one, or more MEMBER ORDERs. This relationship supports member-initiated orders. In both cases, a MEMBER ORDER is placed by (is responded to by) exactly one MEMBER. A MEMBER ORDER sells one or more PRODUCTs. A PRODUCT is sold on zero, one, or more MEMBER ORDERs. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 3rd Step - The Key-Based Data Model The third task is to identify the keys of each entity. The following guidelines are suggested for keys: The value of a key should not change over the lifetime of each entity instance. The value of a key cannot be null. Controls must be installed to ensure that the value of a key is valid. 194 NAME would be a poor key since a person’s last name could change by marriage or divorce. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 3rd Step - The Key-Based Data Model The following guidelines are suggested for keys: (continued) Some experts suggest that you avoid intelligent keys because the key may change over the lifetime of the entity instance. An intelligent key is a business code whose structure communicates data about an entity instance (such as its classification, size, or other properties). A code is a group of characters and/or digits that identifies and describes something in the business system. Other experts suggest that you avoid intelligent keys because business codes can return value to the organization because they can be quickly processed by humans without the assistance of a computer. 194 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 3rd Step - The Key-Based Data Model The following guidelines are suggested for keys: (continued) Consider inventing a surrogate key instead to substitute for large concatenated keys of independent entities. This suggestion is not practical for associative entities since because each part of the concatenated key is a foreign key that must precisely match its parent entity’s primary key. If you cannot define keys for an entity, it may be that the entity doesn’t really exist—that is, multiple occurrences of the so-called entity do not exist. 194-195 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 3rd Step - The Key-Based Data Model Business Codes There are several types of codes and they can be combined to form effective means for entity instance identification. Serial codes assign sequentially generated numbers to entity instances. Many database management systems can generate and constrain serial codes to a business’ requirements. Block codes are similar to serial codes except that serial numbers are divided into groups that have some business meaning. Alphabetic codes use finite combinations of letters (and possibly numbers) to describe entity instances. Alphabetic codes must usually be combined with serial or block codes in order to uniquely identify instances of most entities. 195 Block codes are similar to serial codes except that serial numbers are divided into groups that have some business meaning. For instance, a satellite television provider might assign 100-199 as PAY PER VIEW channels, 200-299 as CABLE CHANNELS, 300-399 to SPORT channels, 400-499 to ADULT PROGRAMMING channels, 500-599 to MUSIC-ONLY channels, 600-699 to INTERACTIVE GAMING channels, 700-799 to INTERNET channels, 800-899 to PREMIUM CABLE channels, and 900-999 to PREMIUM MOVIE AND EVENT channels. Alphabetic codes use finite combinations of letters (and possibly numbers) to describe entity instances. For example, each STATE has a unique two character alphabetic code. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 3rd Step - The Key-Based Data Model Business Codes There are several types of codes and they can be combined to form effective means for entity instance identification. (continued) In significant position codes, each digit or group of digits describes a measurable or identifiable characteristic of the entity instance. Significant digit codes are frequently used to code inventory items. Hierarchical codes provide a top-down interpretation for an entity instance. Every item coded is factored into groups, subgroups, and so forth. 195 Significant digit codes are frequently used to code inventory items. The codes you see on tires and light bulbs are examples of significant position codes. They tell us about characteristics such as tire size and wattage, respectively. Hierarchical codes provide a top-down interpretation for an entity instance. Every item coded is factored into groups, subgroups, and so forth. For instance, we could code employee positions as follows: First digit identifies classification (e.g., clerical, faculty, etc.) Second and third digit indicates level within classification Fourth and fifth digits indicate calendar of employment Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 3rd Step - The Key-Based Data Model Business Codes The following guidelines are suggested when creating a business coding scheme: Codes should be expandable to accommodate growth. The full code must result in a unique value for each entity instance. Codes should be large enough to describe the distinguishing characteristics, but small enough to be interpreted by people without a computer. Codes should be convenient. A new instance should be easy to create. 195 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

195-197 Figure 5.12 The SoundStage Key-Based Data Model The figure above is the key-based data model for the SoundStage project. We have eliminated all non-specific relationships by resolving them into associative entities and one-to-many relationships (as described earlier in the chapter). Since all of our relationships are now one-to-many, we have adopted the common practice of naming the relationship from parent-to-child. The inverse relationship, while not shown, is implicit. We call your attention to the following noteworthy items: Many entities have a simple, single-attribute primary key (PK1). In the PRODUCT entity, either one of two attributes could uniquely identify an instance of the entity. We designate them as separate primary keys (PK1 and PK2). Notice how the primary keys for AGREEMENT and PROMOTION were constructed. Each has a concatenated key. Part of that key is inherited from the parent entity CLUB. You can tell that because CLUB NAME is also a foreign key (FK). When one entity contributes its key to another entity across a relationship, the relationship is said to be identifying – because it helps to identify the child entity. Notice that all of the attributes that comprise the concatenated key have the same primary key number, PK1. We resolved the non-specific relationship between ORDER and PRODUCT by introducing the associative entity ORDER ON A PRODUCT. Each associative entity instance represents one product on one order. The parent entities contributed their own primary keys to comprise the associative entity’s concatenated key (PK1). Also notice that each attribute in that concatenated key is a foreign key that points back to the correct parent instance. CLUB MEMBERSHIP is a ternary relationship that simultaneously associates one MEMBER, CLUB, and AGREEMENT. Thus, the concatenated key consists of four attributes contributed by the three participating parent entities. All relationships contribute foreign keys from parent-to-child. You just learned that if the contributed foreign key helps to uniquely identify instances of the child entity, the relationship is said to be identifying. On the other hand, if the foreign key plays no role in identifying instances of the child entity, then it is recorded as non-key data in our model. It’s only purpose is to point to a child entity’s specific parent. For example, MEMBER NUMBER in the MEMBER ORDER entity serves only to point to the correct MEMBER entity instance for an order. In this case, the relationship is called non-identifying. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 4th Step - Generalized Hierarchies At this time, it would be useful to identify any generalization hierarchies in a business problem. 197 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

Fig. 7.15 The SoundStage Key-based data model with generalization 197-198 Figure 5.13 The SoundStage Key-Based Data Model with a Generalization Hierarchy The SoundStage minicase at the beginning of this chapter identified at least one supertype/subtype structure. Subsequent discussions uncovered the generalization hierarchy shown in the figure above. We had to layout the model somewhat differently because of the hierarchy; however, the relationships and keys that were previously defined have been retained. We call your attention to the following: The SoundStage CASE tool automatically draws a dashed box around generalization hierarchy. The subtypes inherited the keys of the supertypes. We disconnected PROMOTION from PRODUCT as it was shown earlier, and reconnected it to the subtype TITLE. This was done to accurately properly assert that MERCHANDISE is never featured on a PROMOTION. Fig. 7.15 The SoundStage Key-based data model with generalization Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 5th Step - The Fully Attributed Data Model The fifth task is to identify the remaining data attributes. The following guidelines are offered for attribution. Many organizations have naming standards and approved abbreviations. The data or repository administrator usually maintains such standards. Many attributes share common base names such as NAME, ADDRESS, DATE. Unless the attributes can be generalized into a supertype, it is best to give each variation a unique name such as: CUSTOMER NAME vs SUPPLIER NAME Names must be distinguishable across projects. Logical attribute names should not be abbreviated. 197 Choose attribute names carefully. Many attributes share common base names such as NAME, ADDRESS, DATE. Unless the attributes can be generalized into a supertype, it is best to give each variation a unique name such as: CUSTOMER NAME CUSTOMER ADDRESS ORDER DATE SUPPLIER NAME SUPPLIER ADDRESS INVOICE DATE EMPLOYEE NAME EMPLOYEE ADDRESS FLIGHT DATE Some organizations maintain reusable, global templates for these common base attributes. This promotes consistent data types, domains, and defaults across all applications. Physical attribute names on existing forms and reports are frequently abbreviated to save space. Logical attribute names should be clearer – for example, translate the order form’s attribute COD into its logical equivalent, AMOUNT TO COLLECT ON DELIVERY; translate QTY into QUANTITY ORDERED, and so forth. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 5th Step - The Fully Attributed Data Model The following guidelines are offered for attribution. (continued) For attributes that have only YES or NO values, name as questions. For example, CANDIDATE FOR A DEGREE? Each attribute should be mapped to only one entity. Foreign keys are the exception – they identify associated instances of related entities. An attribute’s domain should not be based on logic. 197 An attribute’s domain should not be based on logic. For example, in the SoundStage case we learned the values of MEDIA were dependent on the type of product. If the product type is a video, the media could be VHS tape, 8mm tape, laserdisc, or DVD. On the other hand, if the product type is audio, the media could be cassette tape, CD, or MD. The best solution would be to assign separate attributes to each domain: AUDIO MEDIA and VIDEO MEDIA. Dr. M. A. Rouf, Dept. of CSE, DUET

Fig. 7.16 The SoundStage fully attributed data model with 199-201 Figure 5.14 The SoundStage Fully Attributed Data Model No additional notes provided. Fig. 7.16 The SoundStage fully attributed data model with Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 6th Step - The Fully Described Model The last task is to fully describe the data model. This task is the most time consuming. This task can be started in parallel with the key-based model or fully attributed model, but it is usually the last data modeling task completed. At this time the descriptions for the attributes are still incomplete – they require domains. Most CASE tools provide extensive facilities for describing the data types, domains, and defaults for all attributes to the repository. 199 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

How to Construct Data Models 6th Step - The Fully Described Model Additional descriptive properties may be recorded for attributes such as: Who should be able to create, delete, update, and access each attribute? How long should each attribute (or entity) be kept before the data is deleted or archived? 199 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

Data modeling should remain a value-added skill for many years. The Next Generation Data modeling should remain a value-added skill for many years. The demand for data modeling as a skill is dependent on two factors: (1) the need for databases, and (2) the use of relational database management system technology to implement those databases. There is some belief that relational database technology will eventually be replaced by object technology. If that were to happen, data modeling would be replaced by object modeling techniques. Even as object database technology becomes available, we expect the relational database industry to add object features and technologies to their product lines. 199 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

CASE technology will continue to improve. The Next Generation CASE technology will continue to improve. Today’s better CASE tools provide a two-way synchronization between the logical data models and their database designs. This synchronization will likely extend as CASE vendors enable their tools to directly communicate and interoperate with database management systems and working databases. 202 No additional notes provided. Dr. M. A. Rouf, Dept. of CSE, DUET

An Introduction to Systems Modeling System Concepts for Data Modeling Summary Introduction An Introduction to Systems Modeling System Concepts for Data Modeling The Process of Logical Data Modeling How to Construct Data Models The Next Generation 170-202 Dr. M. A. Rouf, Dept. of CSE, DUET