Data Modeling

1
Data Modeling

• Entity relationships and
• Data normalization

2
What are . ?

• entities
• occurrences
• attributes
• data elements
• data structures
• keys

3
Some terminology reviewed (contd)

• Entities - items in the system which need to be
  described (people, places, concepts, objects,
  things, events)
• manufacturers
• outlets
• customers

• order
• products
• transactions
• activities
• ILL requests
• library patrons
• journals

4
Some terminology reviewed (contd)

• Occurrences - a single appearance (instance) of
  an entity in the system)
• customer
• toaster
• student

• promotion
• table
• car
• a specific journal
• a single patron
• a designated ILL request

5
Some terminology reviewed (contd)

• Attributes - a property of the entity which needs
  to be described
• customer id
• QOH
• red
• ROP
• description
• address
• name

• Dewey decimal reference number
• patrons name
• Fax
• phone
• occupation
• price
• date

6
Some terminology reviewed (contd)

• Data element - the most fundamental, indivisible,
  attribute. Can not be decomposed.
• apartment number
• street name
• building number
• city
• ZIP code
• state
• patrons last name
• Dewey Decimal section code

7
Some terminology reviewed (contd)

• Data structures - related data elements which
  constitute a unit of information in the business
  process.
• form
• screen
• order
• output documents
• input documents
• ILL request form
• ILL mailing card

8
Some terminology reviewed (contd)

• Keys - an attribute (or many attributes) which
  uniquely distinguishes an occurrence from any
  other occurrence.
• SS number
• inventory number
• SKU
• product number
• UPC
• student number
• ILL request number

9
Data relationships

10
Classes of data relationships

• Unary
• Binary
• Ternary and higher

11
Relationship structures

• One-to-one
• ILL_REQUEST is for a JOURNAL (Binary)
• SHOPPER purchases GROCERY_ITEM (Binary)
• ATHLETE takes DRUG_TEST (Binary)
• PERSON is married to a PERSON (Unary)
• Example STUDENT has SS and has GRADE and an
  ADDRESS
• can you keep these separately connected w/ a
  link?
• can they also be stored as attributes of Student?

12
Collapsing a one-to-one relationship
Attributes
13
Relationship structures (contd)

• One-to-many
• Shopper purchases groceries (Binary)
• Researcher submits journal requests (Binary)
• Student attends classes (Binary)
• Cattle infects cattles (Unary)
• Conferee presents to conferees (Unary)
• Example STUDENT attends CMS3050, CMS3230,
  CMS4410, etc.
• one to how many is this?

14
Relationship structures (contd)

• Many-to-many
• Shoppers purchase groceries (Binary)
• Researchers submit journal requests (Binary)
• Products make up sales x-actions (Binary)
• Students attend cms3050, cms3230, cms4410
  (classes) (Binary)
• Example Researcher 1 and 2, and 3 submit
  requests for journals A, B, C, D
• How many to how many is this?

15
Breaking up a many to many relationship
16
ERD for the ILL example
17
DD-Entity documentation

• Researcher
• Name (the key)
• Address
• Telephone number
• etc.
• Links to
• Placed a request for (or to) ..

18
DD-Entity documentation

• Journal
• Title
• Year
• Issue/volume
• Article title
• Author name
• Page numbers
• Dewey decimal number (key)
• Links to
• Requested by...

19
DD-Entity documentation

• ILL request
• Researcher name (key)
• Dewey decimal number (key)
• Library requested from
• What else?
• Links to
• Requested by.
• Placed a request for..

20
Questions in designing a database ...

• What data are needed by each
• process?
• user?
• Is data acquisition order important?
• What data are parts of other data and/or
  structures?
• What keys are available at the time the data is
  needed?
• Who assigns the keys and when?
• Also see questions in Valacich text, p 190.

21
A good data model should

• Be consistent with the DD
• Be logical only and be independent of the
  physical data storage devices employed
• Should serve to avoid ambiguity
• Physical implementation should find the logical
  model as no obstacle.
• Answer normalized data model!

22
End data modelingbasics