DATA MODELING FUNDAMENTALS (P7) ppt

I. Resolution of synonyms is easier than that for homonyms. J. In a recursive entity type, entities within the entity type may be associated with other entities within the same entity type. 2. Enumerate the guidelines for a good definition of an entity. Using these guidelines, define an entity for an organization. 3. Distinguish between entities and entity types using examples. 4. What are two common methods for identifying entity types for an organization? Describe one of the methods with an example. 5. What are homonyms and synonyms in entity types? How could these cause pro- blems in identifying entity types properly? 6. What are the two types of dependencies of weak entity types on their corresponding strong entity types? Describe one of the two types with an example. 7. Discuss the need for generalization and specialization in data modeling. Explain with examples of supersets and subsets. 8. Subsets inherit attributes and relationships from their corresponding superset. Explain this statement with an example. 9. Give an example of an overlapping partial specialization. Describe the entities in the representation. 10. What are conceptual and physical objects? When is it necessary to represent these in a data model? Explain the relationship between a conceptual object and a phys- ical object with an example. 156 CHAPTER 4 OBJECTS OR ENTITIES IN DETAIL 5 ATTRIBUTES AND IDENTIFIERS IN DETAIL CHAPTER OBJECTIVES . Provide an in-depth discussion of attributes and identifiers . Explore the nature and definition of attributes . Discuss attribute domains in detail . Study how constraints work for attributes . Classify attributes by various types . Establish the need and role of identifiers . Present types of keys and the governing rules . Conclude with an attribute validation checklist Open up the database of an organization and look at the data content. What you will find is a huge collection of values. Some of these will be in text form; others in numeric format; and still others in complex formats depending on the type of data stored. What are these values? If CUSTOMER is one of the business objects about which data is collected and stored, then you will find data values for data elements such as customer name, customer address, customer phone number, and so on. If ORDER is another business object in your database, then you will observe data values for such data elements such as order number, order date, order amount, and shipping method. What are these data values? You know that customer name, customer address, and customer phone describe the business object CUSTOMER. These are attributes of the business object. Similarly, order number, order date, order amount, and shipping method are attributes of the business object ORDER. So, the data values you find stored in the database are values of the attributes of the 157 Data Modeling Fundamentals. By Paulraj Ponniah Copyright # 2007 John Wiley & Sons, Inc. business objects. Apart from a few other types of data stored in a database, attribute values form the bulk of the data content. Attributes, therefore, stand out as important components of a data model. What is the true nature of an attribute? How should we understand the role of an attribute in terms of entity types and relationships? What set of values can an attribute of a business object take? Can the value sets be shared among different attributes? Are attributes subject to constraints or restrictions or rules? If so, what types of constraints? Are all attributes of a business object of the same type? If different, how can we differentiate them and depict them in a data model? We will address such questions in detail. In the previous chapters, you have been exposed to various examples of attributes. In Chapter 3, when we considered a case study example, you reviewed the attributes of the different entity types. Now, we want to explore attributes and make an in-depth study. ATTRIBUTES What do we mean by an attribute of a business object? What are values for an attribute? We consider CustomerName as an attribute of a business object or entity type we call CUSTOMER. What does the term CustomerName imply in terms of an entity type known as CUSTOMER? Is it a placeholder to contain values for customer names? Is it a common characteristic of all entities known as customers in that business? How is the term CustomerName used when we access the database for customer names? We wish to explore these questions in detail. When you take into account the various components of a data model, attribute ranks high as an important building block. As the leading component whose values fill up the data content in a database, attributes deserve serious study. Let us get a clear understanding of attributes. Properties or Characteristics Every business object possesses certain properties or characteristics that are relevant to the information requirements. These characteristics describe the various instances of an object set. For example, last name Jones describes an instance of the object EMPLOYEE. Simi- larly, if that employee was hired on 10 /1/2006, hire date is another attribute describing that instance of the object. Figure 5-1 shows attributes of an object STUDENT. Note the names of the attributes written inside the ellipses or ovals. Observe how these are characteristics or descriptors of the individual instances of the object set. So, what are attributes? Inherent Characteristics. Consider the data elements StudentID, StudentName, SocSecNo, StudentPhone, and StudentMajor. These data elements are associated with the object STUDENT. They are innate or natural or intrinsic or inherent properties of STUDENT. Next, think of a particular course for which a student has enrolled. CourseNo is also a data element associated with the object STUDENT. If so, is CourseNo also an attribute of the object STUDENT? Compare the two data elements StudentName and CourseNo. StudentName is a natural characteristic of the object STUDENT, whereas CourseNo does not indicate a basic property of the object. CourseNo does not describe 158 CHAPTER 5 ATTRIBUTES AND IDENTIFIERS IN DETAIL some intrinsic property of STUDENT, but only its relationship with another object called COURSE. Therefore, CourseNo does not qualify to be an attribute of STUDENT. Distinct Characteristic. An attribute is a distinct and specific characteristic of an entity type that is of interest to the organization. Indicates Data. An attribute of an entity type designates the nature of the data that is maintained in the database for that entity type. Describes Entity. An attribute is a simple, separate, distinct, singular property that describes an entity. Grouping of Entities. In our prior discussions on entities and entity types, you must have observed that a group of entities were put together and called an entity type because those entities were similar. Customer entities are grouped together as CUSTO- MER entity type for the reason that the entities share common characteristics. If one cus- tomer entity possesses the characteristics of name, address, and phone, then another customer entity also has these characteristics; yet another customer entity also shares these characteristics. Common characteristics or attributes determine whether a number of entities or “things” may be grouped together as one type. Thus, attributes play a key role in the formation of entity types. An entity set is a set of entities of the same type that share the same properties or attri- butes. An entity set is represented by a set of attributes that are descriptive properties possessed by each member of an entity set. Ownership by Entity. Go back to the data elements StudentID, StudentName, SocSecNo, StudentPhone, and StudentMajor. These data elements are associated with the entity type STUDENT. They are innate or natural or inherent properties of STUDENT. These attributes are “owned” by the entity type STUDENT. In a database, there may be hundreds of attributes. Every one of these attributes is “owned” by some entity type. Each attribute has a name that uniquely identifies it with a description that can be clearly interpreted. An attribute “owned” by an entity type may be either a key attribute or a non –key attribute. Key attributes serve as identifiers FIGURE 5-1 STUDENT object: attributes. ATTRIBUTES 159 for the entity type (more about key attributes in a later section). Non –key attributes constitute the bulk of the data content. These non–key attributes describe the entity type. Attributes of Relationships. Until now, we have been considering attributes insofar as they apply to entity types. However, in certain cases, attributes may be needed to describe relationships as well. Let us look at the case of employees being assigned to pro- jects. Here we have two entity types EMPLOYEE and PROJECT in a many-to-many relationship. One employee may be assigned to one or more projects; one project may be carried out by one or more employees. Think about the types of data that must be collected and stored in the database. For example, you would have to store start date and the duration for each employee on the pro- jects that person has worked on. What are these values? These are values for start date and duration. These are values for attributes known as StartDate and AssignmentDuration. But which entity types “own” these attributes? StartDate for an employee does not make sense; nor does it make sense for a project. Similarly, AssignmentDuration does not make sense for employee or project by them- selves. However, StartDate has meaning for an employee working on a project; the attri- bute StartDate makes sense only when you consider the association of the employee with a specific project. StartDate has to be an attribute of the relationship between EMPLOYEE and PROJECT, not an attribute of either entity type apart from the relationship. Figure 5-2 shows the relationship and its attributes. Mapping Between Sets. Another way to look at attributes: attributes are mappings between an entity set or a relationship set with a set of values. Let us examine this aspect of attributes. Suppose you look at the data content in a database. Let us say we find a number of values in text format indicating names of persons. This is a set of values. Let us say also we find a number of values indicating Social Security numbers. Now we understand that the first set of values is names of students and the second set of values is Social Security numbers of students. A particular name (John Silverstein) and a specific Social Security number (111-44-3456) are those of a certain student. What is the mapping or connection here? The specific student entity from the set of students maps into the values “John Silverstein” and “111-44-3456.” How is the mapping done between entity and the values? It is done through what we call attributes. The attributes StudentName and SocialSecurityNumber provide the mapping between the set of values for names and Social Security numbers and the set of student entities. An attribute associates an entity set with a set of values. A value set in a database gets interpreted in the context of a set of entities. FIGURE 5-2 Attributes of a relationship. 160 CHAPTER 5 ATTRIBUTES AND IDENTIFIERS IN DETAIL Attributes as Data Most people, even many data modelers, think of attributes as data. This is only partially true. Representations of attributes exist in the database as values in the form of text, codes, numeric measures, and even images. In advanced systems, complex values in the form of audio and video compositions may exist representing attributes. When you represent an attribute with an oval in a data model diagram, you are expressing the representation of specific data values from a designated set. The attribute Customer- Phone is manifested in the database as several valid phone numbers stored as data. Your data model showing the attribute CustomerPhone depicts this representation of data values of valid phone numbers. Attributes as Data Holders. Consider the attributes of STUDENT entity type: StudentId, StudentName, SocSecNo, StudentPhone, StudentMajor, and StudentFax. Figure 5-3 shows a set of values for these attributes. Examine these values . The values such as “Networking,” “Web Design,” “Engineering,” and so on are mani- festations of the data model component known as StudentMajor. What is this data model component? What does the name StudentMajor point to? You may think of it as the name for a data holder that contains data values such as mentioned. The representation of an attribute in a data model is the depiction of a data holder. Attributes of a single entity hold values that describe that specific entity. For example, look at the values for the student, Kristin Rogers. The attributes StudentId, StudentName, SocSecNo, StudentPhone, StudentMajor , and StudentFax hold data values “111245,” “Kristin Rogers,” “214-56-7835,” “516-777-9584,” “Networking,” and “516-777-9587,” respectively, for this student. Attributes Indicate Data Storage. When you designate an attribute for an entity type, your data model shows this attribute. For example, when you name an attribute Student- Phone for the entity type STUDENT, you are expressing that the database stores phone numbers as data for each student. The assignment of an attribute for an entity type makes the statement about data storage of values for that attribute in the database. For each entity, a value is to be stored for that attribute. Each entity may have its own value for the attribute to be stored in the database. Entity as Attribute–Value Pairs. Once again, let us rev iew the attributes of STUDENT entity type: StudentId, StudentName, SocSecNo, StudentPhone, StudentMajor, and StudentFax. What can we say about each entity in the set? In particular, how can we describe the entity representing Kristin Rogers? FIGURE 5-3 STUDENT entity type: attribute values. ATTRIBUTES 161 This particular entity may be described as a set of attribute –value pairs as follows: (StudentId, 111245), (StudentName, Kristin Rogers), (SocSecNo, 214-56-7835), (StudentPhone, 516-777-9584), (StudentMajor, Networking), (StudentFax, 516-777-9587). Thus, each entity may be described by a set of (attribute, value) pairs, one pair for each attribute of the entity type. Attribute Values Take a few samples of the values of the attributes shown in Figure 5-3. Examine the data values shown in each column. We want get a clear understanding of attribute values as applicable to any entity type. First of all, when you consider the attribute values for one single entity or instance of the entity type, you will note the values are specific and unique for that entity. Second, the data values for a specific entity instance may themselves change over time. Unique Values for an Instance. Look at one set of values shown in one row of Figure 5-3. These values for the attributes StudentID, StudentName, SocSecNo, and StudentPhone relate to one student, a specific instance of the entity type STUDENT. These attributes do not relate to any random instance of the entity type; they relate to one particular student. Let us say, this student is Mary Williams. Then these attributes are characteristics of Mary Williams. If you observe a specific instance of the entity type STUDENT, namely Mary Williams, then you will note a unique and specific set of values for the attrib utes. This unique set of values descr ibes Mary Williams. In the data model, each instance of an entity type possesses a unique set of values for its attributes. However, this does not mean a value for any attribute may not be repeated for other students. In fact, look at the value for the attribute StudentMajor. For Mary Williams, the value is “Networking.” This value applies to Mary Williams. It may also apply to other students as well. Other students may also have the value “Networking” as the value for the attribute StudentMajor. Changeable Values. You have noted that each instance of an entity type is described by a unique set of values for its attributes. Review the unique set of values for the attributes describing the instance Mary Williams in Figure 5.3. Let us sa y Mary marries John Pearson and changes her name to Mary Pearson. Also, she changes her phone number. What are the implications? What you notice is that although each instance is described by a unique set of values for its attributes, these values may change over time. The values for StudentName and StudentPhone would change, but still the instance refers to the same student. Again, after the changes, a unique set of values for the attributes describes the student Mary Pearson. It is important to note that values of the attributes for an object instance may change, but the instance itself remains the same. 162 CHAPTER 5 ATTRIBUTES AND IDENTIFIERS IN DETAIL Names and Descriptions Attributes in a data model are indicated by their names. In the E-R data model, the attribute names are shown within the ovals that represent the attributes. Attribute names and their descriptions are intended to provide a clear understanding of the nature of the data we want to store about each entity of an entity type. The data model diagram displays the attribute names. Attribute descriptions are written in an accompanying requirements definition document. Attribute Names. Following are a few guidelines for choosing and assigning a name for an attribute. Nouns. Use a noun in the form of a single or compound word. Use minimum number of words. Avoid the use of special characters such as à , #, @, and so on. Logical Not Physical. In choosing a name, conform to logical considerations, not physical characteristics of the attribute. Naming Standards. Follow the naming standards and conventions of your organization. Synonyms and Homonyms. Resolve all issues relating to synonyms and homonyms before finalizing the attribute names. Clarity. Pick a name that is clear, precise, and self-explanatory. CASE Tool. If a CASE tool is being used for data modeling, be guided by the requirements of the CASE tool for assigning attribute names. In Line with Description. Do not let the attribute name contradict the attribute description. To Be Avoided. In the attribute name, avoid abbreviations, acronyms, plural words, possessive forms of nouns, articles, conjunctions, prepositions, and verbs. Attribute Descriptions. Attribute descriptions provided in the supplementary docu- mentation enable clear thinking about the attributes. The descriptions present the rationale for each attribute and explain the reason and role of the attribute. A good attribute description supplements the meaning derived from the name of the attribute. It builds on the name and enhances the understanding. The description must be concise. If any technical terms are used in the descriptions, these terms must be explained. While writing an attribute description, do not simply rephrase the name. The descrip- tion must be able to stand alone by itself. A few examples may be used, but a description by means of just examples is incomplete. Dictionary meaning of the attribute name is not a good description. Avoid technical jargon in the description. ATTRIBUTES 163 ATTRIBUTE DOMAINS In our discussions on attributes, you have noted the use of the term domain. Each attribute is related to a specific domain. A set of data values constitute a domain. Value sets may be a set of integers, a set of valid phone numbers, a set of valid zip codes, and so on. The data set or domain for a particular attribute provides values for individual entities. When you examine the domain for an attribute, you get to know more about the attri- bute. Domain information describes an attribute further. We will study the information that may be obtained from a domain. We will look at examples of attributes and their domains. We will also study special cases of domains. Definition of a Domain First let us get a clear understanding of an attribute domain. What are the characteristics of a domain? How do the values in a domain apply to attributes? What about the nature of the values in a domain? How do they depend on the attribute itself? First let us define a domain. What Is an Attribute Domain? An attribute domain is a set of values that may be assigned to an attribute. A domain defines the possible, allowable, potential values of an attribute. As noted earlier, a domain is simply a set of values. When you relate a set of values to an attribute, the set of values becomes the domain for that attribute. Make a list of all the department numbers in your organization. This list of values of department numbers becomes the domain for an attribute called DeptNo. When you link a set of values to an attribute, then the set of values takes a special role of containing allowable values for the attribute. Every attribute has values for each of the entities for which it is an attribute. If you have an entity type known as DEPARTMENT and it has an attribute DeptName, then this attri- bute has different values for the various occurrences of the entity type. Each department has a specific departmen t name. The set of possible department names constitutes the domain for DeptName. Every attribute must, therefore, have a domain consisting of at least two values. Most attributes have domains consisting of large number of values. We understand that attribute is a term used to indicate a business fact that can have values from a given domain. Examples of Attribute Domains. Let us now consider the example of an entity type and its possible attributes. Entity type: EMPLOYEE Attributes: EmployeeID, SocSecNo, EmpName, EmpZip, Salary, HireDate Examine the values of each of these attributes. You will note that the values for a particular attribute are from a definite set of values. For example, the values for EmployeeID may be any number with six digits. That means, the set of values from which the value of EmployeeID for a particular instance of object EMPLOYEE is the 164 CHAPTER 5 ATTRIBUTES AND IDENTIFIERS IN DETAIL set of numbers from 000001 to 999999. This is the domain of values for the attribute EmployeeID. Domain of an attribute is, therefore, the set of legal or allowable values for that attribute. In the case EmployeeID, the attribute domain is the set of numbers from 000001 to 999999. Attribute domains are sets based on natural limitations as for numbers or characters of the alphabet. Mostly, business rules determine attribute domains. Each attribute has its own domain for its values. Here are some examples of domains for the above attributes: EmployeeID: Set of numbers from 000001 to 999999 SocSecNo: Set of legal 9-digit Social Security numbers EmpName: Any text up to 45 characters EmpZip: Set of legal zip codes Salary: Currency value from 000000.00 to 999999.99 HireDate: Legal values for date greater than January 1, 1900 Domain Information In the above example, you have looked at several examples of domains. Again, remember each domain is a value set. You can examine the values in each domain. For example, when you scrutinize the domain for the attribute Salary, what information about the attribute does this domain convey to you? The values tell you that salary values are numeric and that salary values must fall within a certain range. What about the domain for HireDate? Here you note that the values for this attribute must have a correct date format and that the dates must be after January 1, 1900. How do you set up the domain for an attribute? Generally, the nature of the attribute itself determines the contents of the domain. Beyond this, business rules regarding the attribute shapes the contents of the domain. For example, for the attribute HireDate, the set of values must be numeric and in date format. The nature of this attribute determines this general aspect of the domain. In this organization, all employees were hired after January 1, 1900. Therefore, no HireDate can be before January 1, 1990. This is a business rule. And this business rule determines the special aspect of the domain. Sometimes, the data type is known as the general domain and specific values, ranges, and so on are referred to as the specific domain. Domain Information Content. Having reviewed the examples of domains, what infor- mation should attribute domains include? What should we be able to understand by reviewing the definition and contents of a domain? Domain information must include the following. Data Type. Type of data such as text, numeric, character, integers, audio, and video. Format. Input and display formats for numeric data such as groupings with comma separation. Length. Length for text data and formats such as long integer. ATTRIBUTE DOMAINS 165 [...]... Stored and Derived Values In later phases of database development, you will transform the data model into the physical structure of how data gets stored in the database From our discussion of attributes, you must have realized that the physical data stored in the database consists of values of the attributes of the complete set of all the entities Stored data is really values of the attributes TYPES... ¼ 80.00 4.99 to 24.99 0 to 100 Type Data type governs all attribute values Data type constraints are either stated explicitly or they are implied We have already seen some examples of data types such as numeric, text, and so on In addition to data type, domain constraints include the lengths of the character strings for text data and number of digits for numeric data Note the following examples: Attribute... constraints relating to attributes We studied various types of attributes and noted how these are represented in a data model We reviewed key attributes in sufficient depth During the data modeling process, at each stage, you need to check the data model for completeness and correctness Data modeling is an iterative process After defining the entity types, the next major activity refers to the representation... the business rules correctly The data model must reflect the information requirements and the business rules exactly Sometimes, data modelers tend to misrepresent domains, mix them up, and produce incorrect data models FIGURE 5-5 Incorrect and correct domain split 168 CHAPTER 5 ATTRIBUTES AND IDENTIFIERS IN DETAIL FIGURE 5-6 Model not matching requirements Consider the data model for a university One... entity-relationship data model Optional Attributes In some entity types, a good number of entity occurrences may not have values for specific attributes So, for such entity instances, the database will contain nulls for those attributes Simply, these attributes are not applicable to those entity instances Figure 5-11 shows CUSTOMER entity type with its attributes Various attributes have different data value... certain that all composite attributes are identified and represented in the data model diagram Multivalued Attributes Review each entity type for multivalued attributes Mark multivalued attributes in the data model diagram with proper notation Derived Attributes Wherever needed, ensure that derived attributes are shown in the data model diagram Also, verify that the derivation rules are recorded in the... that each domain contains at least two data values Constraints Review the expressions of constraints through domain definitions and ensure correctness Composite Attributes Go over all composite attributes and ensure that they are properly broken down and shown in the data model diagram Multivalued Attributes Verify representations of multivalued attributes in the data model diagram for correctness Derived... that the most suitable candidate key is chosen as the primary key CHAPTER SUMMARY Attribute values form the bulk of the data content in a database Attributes are distinct, intrinsic, and inherent characteristics of an entity type An attribute designates the nature of data for an entity type; an attribute describes an entity type An attribute associates an entity set with a set of values Each... required information Entity types and their attributes provide static information In isolation, you can obtain information about customers only and nothing else from the attributes of CUSTOMER Data Modeling Fundamentals By Paulraj Ponniah Copyright # 2007 John Wiley & Sons, Inc 183 184 CHAPTER 6 RELATIONSHIPS IN DETAIL entity type Similarly, by themselves, the attributes of ORDER entity type provide... identify individual occurrences of an entity type If you have a CUSTOMER entity type, this represents the complete set of customers The representation of the entity type in a data model portrays the entire set of customers But in a database, we are interested in specific customers Which customers live in Dayton, Ohio? Which customers bought for more than $100,000 last year? Who is the customer that sent . attributes of the business object ORDER. So, the data values you find stored in the database are values of the attributes of the 157 Data Modeling Fundamentals. By Paulraj Ponniah Copyright # 2007. business object in your database, then you will observe data values for such data elements such as order number, order date, order amount, and shipping method. What are these data values? You know that. depending on the type of data stored. What are these values? If CUSTOMER is one of the business objects about which data is collected and stored, then you will find data values for data elements such