Director – Engineering Data Modelling Sridhar Pandurangiah Director – Engineering sridhar@sastratechnologies.in Sastra Technologies

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

Codd’s Rules of Relational Database

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

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

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

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

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.

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.

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.

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

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

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.

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

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).

Introduction to IDEF

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

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

What is IDEF1X?

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

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

IDEF1X Concepts

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

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.

View Collection of entities and assigned domains No Syntax

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

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)

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

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.

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

Primary Keys Set of attributes that uniquely identify an entity

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

Normalisation

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

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

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

Exercise

Exercise Model the information requirements of a Supermarket

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