This presentation prepared for MIS 421 / MBA 575 at Western Washington University. Material in this presentation drawn from Richard T. Watson, Data Management: Databases and Organization, 5 th Ed., the instructor’s experience, and other sources as noted. Some items © 2006 John Wiley & Sons. All rights reserved.

Data Modeling Basic Structures MIS 421 Dr. Steven C. Ross Fall 2011

Data Modeling* “Data modeling is a method for determining what data and relationships should be stored in the database.” (p. 156) “It is also a way of communicating the design.” (Ibid.) * Quotations from Richard T. Watson, Data Management: Databases and Organization, 4 th Ed.

Goal “The goal of data modeling is to identify the facts that must be stored in the database.” (p. 156) Not concerned with how the data will be stored Not concerned with how the data will be processed

Components of a Data Model Entity Attribute Relationship Identifier

Entity A thing about which data is stored Person, place, tangible, concept, event Look for nouns used in the organization Singular name Some methods use a plural name Represented by a rectangle Entity name in uppercase letters SHARE

Attribute Describes an entity Name is singular, and unique within the entity (or the entire data model) If desired, use a modifier to create unique names Name in lowercase letters Single value, possibly null, never multiple SHARE *share code share name share price share quantity share dividend share PE

Composite Attributes Early in modeling, might create attributes such as name or address Can they be divided into segments? If a query could be based on the segments, then create separate, “atomic” attributes Acceptable compromise: use composite attributes when modeling, with policy that dictates division into atomic attributes when creating DB

Relationship Describes a link between two (or more) entities two instances of the same entity A relationship can have two descriptors Not always shown Each has a degree STOCK *stock code stock name stock price stock quantity stock dividend stock PE NATION *nation code nation name exchange rate

Identifier Uniquely distinguishes an instance of an entity If a weak entity, the identifier of the parent is a portion of the identifier Prefix the identifier with an asterisk No part of the identifier can be null

Meaningful Identifiers Occur when some attribute of the entity can be inferred from the identifier’s value Advantages Recognizable and rememberable Administrative simplicity Disadvantages Identifier exhaustion Reality changes Loss of meaningfulness Usually: use surrogates instead

Entity Types Independent Weak or dependent Associative or intersection Aggregate Subordinate

Independent Entity Central to the data model Foremost in client’s mind Clearly distinguishable name Single, arbitrary identifier

Weak Entity Also called “Dependent Entity” Relies on another entity for its existence and identification Modeling [in this book …] Plus sign above relationship line signifies [in Visio …] Solid relationship line Identifier is a composite including independent entity’s identifier If too unwieldy, create arbitrary id – which will change it to an independent entity

Associative Entity Also called “Intersection Entity” By-product of M:M relationships Name may exist or be hyphenated combo Identifier – Might be combination of other item identifiers only  current status Might also include time  historic data If too unwieldy, create arbitrary id – which will change it to an independent entity

Aggregate Entity Created when several entities have similar attributes Example – street address – which could belong to Customer Supplier Employee Or all of the above

Subordinate Entity Stores data about an entity that can vary among instances See supertype/subtype presentation (following slides) for more information

Supertypes and Subtypes Material drawn from Hoffer, J.A., Prescott, M.B., and McFadden, F.R., Modern Database Management, 6 th edition. Upper Saddle River, NJ: Pearson Education, 2002.

Supertypes and Subtypes “One of the major challenges in data modeling is to recognize and clearly represent entities that are almost the same; that is, entity types that share common properties but also have one or more distinct properties that are of interest to the organization.” Supertype Subtype 

Attributes Subtypes inherit all supertype attributes Subtypes have attributes that are different from other subtypes 

Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

All employee subtypes will have emp nbr, name, address, and date-hired Each employee subtype will also have its own attributes Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

When to use Super/Subtypes Attributes apply to some but not all instances of an entity Instances of a subtype participate in relationships unique to that subtype Generalization and specialization generalization: from sub to super specialization: from super to sub 

Both outpatients and resident patients are cared for by a responsible physician Only resident patients are assigned to a bed Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

All these types of vehicles have common attributes Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

So we put the shared attributes in a supertype Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

Applies only to purchased parts Only applies to manufactured parts Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

Created 2 subtypes Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

Constraints Completeness must every supertype member also be a subtype member? total or partial specialization Disjointedness can an instance of a supertype be in more than one subtype? disjoint or overlap subtype discriminator Boolean attribute 

A patient must be either an outpatient or a resident patient Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

A vehicle could be a car, a truck, or neither Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

A patient can either be outpatient or resident, but not both Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

A part may be both purchased and manufactured Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

A simple attribute with different possible values indicating the subtype Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

Hierarchies Subtypes can be supertypes as well a subtype is subordinate to one and only one supertype … a supertype can have many subtypes Attributes are assigned at the highest possible level Subtypes inherit attributes from all supertypes above them in the hierarchy 

Diagram from Hoffer, J.A., Prescott, M.B., and McFadden, F.R.

Unary, Binary, Ternary, n-ary Refers to number of distinct entities in the relationship 1 = unary 2 = binary (most common) 3 = ternary More than 3 = n-ary

Ternary Relationships Might first appear to be three M:M relationships Example: agent books a tour for a customer BOOKING *bookingno bookingdate CUSTOMER *custno custfname custlname TOUR *tourno tourname tourdate AGENT *agentno agentfname agentlname

A Well-Formed Data Model All construction rules are obeyed There is no ambiguity All entities are named Every entity has an identifier All relationships are represented, using the correct notation Relationships are labeled to avoid misunderstanding All attributes of each entity are listed All attribute names are meaningful and unique

High-Fidelity Data Model Faithfully describes the world it is supposed to represent All relationships are recorded and are of the correct degree No compromises or distortions Complete … understandable … accurate … syntactically correct

Skill Builder* A horse competes in at most one race on a course (race track) on a particular date. Over time, a horse can compete in many races on many courses. A horse’s rider (jockey) can ride many horses and a horse can have many jockeys. There is only one jockey riding a horse in a given race. Courses vary in their features, such as the length of the course and the type of surface (e.g., dirt or grass). Design a database to keep track of the results (as a time – e.g., 1:30.23 minutes) of horse races. * Adapted from Richard T. Watson, Data Management: Databases and Organization, 4 th Ed., p. 172

The Answer

Next Lecture Normalization