1. Director – Engineering
Data Modelling
Sridhar Pandurangiah
Director – Engineering
Sastra Technologies

2. Agenda Codd’s Rules of Relational Databases Introduction to IDEF
What is IDEF1X?
IDEF1X Concepts
IDEF1X Syntax and Semantics
IDEF1X Strengths
Normalisation
Exercise

3. Codd’s Rules of Relational Database

4. Rule 1 : The information Rule
All information in a relational data base is represented explicitly at the logical level and in exactly one way - by values in tables

5. Rule 2 : Guaranteed access Rule
Each and every datum (atomic value) in a relational data base is guaranteed to be logically accessible by resorting to a combination of table name, primary key value and column name

6. Rule 3 : Systematic treatment of null values
Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported in fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type

7. Rule 4 : Dynamic on-line catalog based on the relational model
The data base description is represented at the logical level in the same way as- ordinary data, so that authorized users can apply the same relational language to its interrogation as they apply to the regular data

8. Rule 5 : Comprehensive data sub-language Rule
A relational system may support several languages and various modes of terminal use (for example, the fill-in-the-blanks mode). However, there must be at least one language whose statements are expressible, per some well-defined syntax, as character strings and that is comprehensive in supporting all the following items
Data Definition
View Definition
Data Manipulation (Interactive and by program).
Integrity Constraints
Authorization.

9. Rule 6 : View updating Rule
All views that are theoretically updatable are also updatable by the system
Not only can the user modify data, but so can the RDBMS when the user is not logged-in.

10. Rule 7 : High-level insert, update and delete
The capability of handling a base relation or a derived relation as a single operand applies not only to the retrieval of data but also to the insertion, update and deletion of data
The user should be able to modify several tables by modifying the view to which they act as base tables.

11. Rule 8 : Physical data independence
Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representations or access methods

12. Rule 9 : Logical data independence
Application programs and terminal activities remain logically unimpaired when information-preserving changes of any kind that theoretically permit un- impairment are made to the base tables

13. Rule 10 : Integrity independence
Integrity constraints specific to a particular relational data base must be definable in the relational data sub- language and storable in the catalog, not in the application programs.

14. Rule 11 : Distribution independence
A relational DBMS has distribution independence.

15. Rule 12 : Non-subversion Rule
If a relational system has a low-level (single-record-at-a-time) language, that low level cannot be used to subvert or bypass the integrity Rules and constraints expressed in the higher level relational language (multiple- records-at-a-time).

16. Introduction to IDEF

17. IDEF Integrated Computer Aided Manufacturing DEFinition
By ICAM – Integrated Computer Aided Manufacturing

18. IDEF Family! IDEF0 Function Modelling Method IDEF1
Information Modelling Method
IDEF1X
Data Modelling Method
IDEF2
Simulation Modelling Method
IDEF3
Process Description Capture method
IDEF4
Object Oriented Design Method
IDEF5
Ontology Description Capture method
IDEF6
Design Rationale
IDEF7
Information System Audit Method
IDEF8
User Interface Modelling
IDEF9
Scenario Driven Interface System Design-Spec
IDEF10
Implementation Architecture Modelling
IDEF11
Information Artifact Modelling
IDEF12
Organisation Modelling
IDEF13
Three schema mapping design
IDEF14
Network Design

19. What is IDEF1X?

20. IDEF1X Method for data modelling
After information requirements are known and decision to implement RDBMS has been taken
Support development of conceptual schemas
Not for OO Systems

21. IDEF1X ELKA ERKA Relationship Model Hughes Aircraft Company Peter Chen
(Entity Link Key Attribute)
Hughes Aircraft Company
ERKA
(Entity Relationship)
Peter Chen
IDEF1X
Relationship Model
Codd

22. IDEF1X Concepts

23. Entity
Entity Name/Number
Represents a set of real or abstract things which have common attributes or characteristics
Identifier-independent
Identifier-dependent
Noun Phrase
Meaningful abbrevations to be defined in glossary
Each entity should have a Unique name
Entity Name/Number
An entity is “identifier-independent” or simply “independent” if each instance of the entity can be uniquely
identified without determining its relationship to another entity. An entity is “identifier-dependent” or
simply “dependent” if the unique identification of an instance of the entity depends upon its relationship to
another entity

24. Domain
A Named and defined set of values that one or more attributes draw their values from
Values seldom change over time
Each domain instance should have a unique value
Base Domain – Value List and Range (Domain Rules)
Typed Domain – Sub types of Base or other Typed domains
No Syntax
For example, State-Code would be considered a domain or Titles [Mr, Mrs, ...
Azimuth which must be between -360 to +360 degrees
The Audio-Frequency domain would have a representation of Hertz (Hz) with a range domain rule added, which constrained the valid instance data to between 1 and 250,000 Hz. The Sonic domain would further constrain the range to that of human hearing or 20 to 20,000 Hz with an additional range domain rule. The Radio-Frequency domain would have a range rule of 1 to 300,000,000.0 Hz. Note that a domain instance must comply with all of the domain rules of its parent domain (if any) and with its own domain rules.

25. View
Collection of entities and assigned domains
No Syntax

26. Attribute
Entity Name/Number
Characteristic or property associated with a set of real or abstract things
Should be unique throughout the model
Should be owned by a single entity
Should have a value
Not to have multiple values
Attribute P1
Attribute P2
Attribute P3
Attribute A1
Attribute A2
Attribute A3
Attribute A4

27. Connection Relationship
Each instance of a parent is associated with one or more instances of the child.
Has an associated cardinality
Zero, One or More
Zero or One Z
Exactly n
One or More n P
From n - m
Reference to a note
Where cardinality is specified
n - m
(n)

28. Identifying Relationship
Entity Name/Number
Instance of child is identified by its association with the parent
Attribute P1
Attribute A1
Attribute A2
Attribute A3
Attribute A4
Relationship Name
Zero, One or More
Entity Name/Number

29. Non-Identifying Relationship
Entity Name/Number
Instance of child can be uniquely without association with the parent
Attribute P1
Attribute A1
Attribute A2
Attribute A3
Attribute A4
Relationship Name
Zero, One or More
Entity Name/Number
For example, if one or more tasks are associated with each project and tasks are only uniquely identified within a project, then an identifying relationship would exist between the entities PROJECT and TASK.
For example,
although an existence-dependency relationship may exist between the entities BUYER and PURCHASEORDER,
purchase orders may be uniquely identified by a purchase order number without identifying the
associated
buyer.

30. Categorisation Relationship
Entity Name/Number
Complete Category Cluster
Incomplete Category Cluster
Attribute P1
Attribute A1
Attribute A2
Attribute A3
Attribute A4
Therefore, the entities SALARIED-EMPLOYEE and HOURLY-EMPLOYEE are categories of the entity EMPLOYEE
Entity Name/Number
Entity Name/Number
Entity Name/Number

31. Primary Keys
Set of attributes that uniquely identify an entity

32. Foreign Keys
In connection or categorisation relationships – Attributes constituting Primary key of parent migrated to the child

33. Normalisation

34. 1st Normal Form
Attributes should be atomic and instances should be unique

35. 2nd Normal Form
There are no non-trivial functional dependencies of a non-key attribute on a part of a candidate-key

36. 3rd Normal Form
There are no non-trivial functional dependencies of a non-key attribute on something else than a superset of a candidate-key

37. Exercise

38. Exercise
Model the information requirements of a Supermarket

39. Queries ? sridhar@sastratechnologies.in
Thank You
Queries ?