1. Data Models Information Technology
Information Systems 2A
Mkhize, BSc Hons Computer Sciences | Dip Merit IT| ICDL | Proj. Management

2. I thank you for being present. I am indeed honored
The opinion of others does not have to become your reality!

3. Introduction
Presents data models and business rules and how business rules are translated into data model components.
Provides an overview of the evolution of data models, and describes the models at each evolutionary step in detail
Describes UML in the context of the object-oriented model, and how the internet has influenced data models.
Presents different views of data abstraction, incl. the external, conceptual, and physical models
The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.

4. Importance of Data Models
Data Models relatively simple representations, usually graphical, of more complex real-world structures, bolstered by powered database design tools, have made it possible to substantially diminish the potential for errors in database design.
Model is an abstraction of a more complex real – world or event.
Within the database environment, a data model represents data structures and their characteristic, relationship, constraint and transformations.
Data models can facilitate interaction among the designer, the applications programmer and the end user.
The importance of data modeling cannot be overstated. Data constitute the most basic information units employed by a system.
Application are created to manage data and to help transform data into information.

5. Basic Data Modeling Blocks
The basic building blocks of all data models are entities, attributes, relationships and constraints.
An Entity is anything (person; place; thing; or event) about which data are to be collected and stored.
An Attribute is a characteristic of an entity which is equivalent of fields in the file systems.
A Relationship describes an association among entities. Data Models uses three types of relationships:
– One-to-many (1:*) relationship
– Many-to-many (*:*) relationship
– One-to-one (1:1) relationship
A Constraint is a restriction placed on data, which is important because they help to ensure data integrity and are expressed in the form of rules.

6. A one-to-many relationship refers to the relationship between two entities X and Y in which an instance of X may be linked to many instances of Y, but an instance of Y is linked to only one instance of X.
A many-to-many relationship occurs when multiple records in a table are associated with multiple records in another table. For example, a many-to-many relationship exists between customers and products: customers can purchase various products, and products can be purchased by many customers.
a one-to-one relationship is a type of cardinality that refers to the relationship between two entities

7. Intro to Business Rules
When database designers go about selecting of determining the entities, attributes and relationships that will be used to build a data model, they may start by gaining a thorough understanding of what types of data are in the organization, how data are used and in what time frames they are used.
Business Rule is a brief, precise and unambiguous description of a policy, procedure or principle within a specific organization.
It is derived from a detailed description of an organizations environment, help to create and enforce actions within that organization’s environment.
Proper written business rules are used to define entities, attributes, relationships and constraints.

8. Business Rules
Brief, precise, and unambiguous descriptions of a policies, procedures, or principles within a specific organization
Apply to any organization that stores and uses data to generate information
Description of operations that help to create and enforce actions within that organization’s environment
Must be rendered in writing
Must be kept up to date
Sometimes are external to the organization
Must be easy to understand and widely disseminated
Describe characteristics of the data as viewed by the company

9. Discovering Business Rules
The main source of business rules are company managers, policy makers, department managers and written documentation.
The faster and more direct source of business rules is direct interviews with end user. Unfortunately, because perceptions differ, end users sometimes are less reliable source when it comes to specifying business rules.
Too often, interviews with several people who perform the same job yield very different perceptions of what the job components are.

10. Translating Business Rules into Data Model Components
Business rules set the stage for the proper identification of entities, attributes, relationships and constraints.
If the business environment wants to keep track of the objects, there will be specific business rules for them.
Standardize company’s view of data
Constitute a communications tool between users and designers
Allow designer to understand the nature, role, and scope of data
Allow designer to understand business processes
Allow designer to develop appropriate relationship participation rules and constraints
Promote creation of an accurate data model
Generally, nouns translate into entities
Verbs translate into relationships among entities
Relationships are bi-directional

11. Evolution of Data Models

12. Hierarchical Model
The Hierarchical Model was developed in the 1960 to manage large amounts of data for complex manufacturing projects.
It is the logical structural that is represented by an upside – down tree
The hierarchical structure contains levels or segments.
• Advantages
Many of the hierarchical data model’s features formed the foundation for current data models
Its database application advantages are replicated, albeit in a different form, in current database environments
• Disadvantages
Complex to implement
Difficult to manage
Lacks structural independence
Implementation limitations
Lack of standards

14. Network Model
The Network Model was created to represent complex data relationships are effectively than the hierarchical model, to improve database performance and to impose a database standard.
To help establish database standards, the Conference on Data System Languages (CODASYL) created the Database Task Group (DBTG), which was charged to define standard specifications for an environment that would facilitate database creation and data manipulation.
The final DBTG report contained specifications for three crucial database components:
The Network Schema
The Network Subschema
A Data Management Language
Disadvantages
Too cumbersome (awkward / clumsy)
The lack of ad hoc query capability put heavy pressure on programmers
Any structural change in the database could produce havoc in all application programs that drew data from the database
Many database old-timers can recall the interminable information delays

16. Network Model

17. Relational Model
The Relational Model represented a major breakthrough for both users and designers.
And was introduced by E F Codd.
To use an analogy, the relational model produced an ‘automatic transmission’ database to replace the ‘standard transmission’ database that preceded it.
The relational database model is implemented through a sophisticated Relational Database Management System,
which performs the same basic functions provided by the hierarchical and network DBMS system,
in addition to a host of other functions that make the relational database model easier to understand and implement. Figure 2.1 Linking Relational Tables

19. Entity Relationship Model
The Entity Relationship (ER) model has become widely accepted standard for data modeling.
Peter Chen first introduced the ER data model in 1976 where it was a graphical representation of entities and their relationship in a database structure that quickly became popular because it complemented the relational database model concepts.
The relational database model and ERM combined to provide the foundation for tightly structured database design.
ER models are normally represented in an entity relationship diagram, which uses graphically representations to model database components.

22. Figure 2.4 The Basic Crow’s foot ERD

23. Object-Oriented (OO) Model
The Object – Oriented Data Model, both data and their relationships are contained in a single structure known as an object.
The OODM reflects a different way to define and use entities.
Unlike an entity, an object includes information about relationships between the facts within the object, as well as information about its relationship with objects.
Therefore, the facts within the object are given greater meaning.
The OODM is said to be a Semantic Data Model because semantic indicates meaning.

24. Comparison of OO Model and ER Model

25. Extended Relational Data Model (ERDM)
Other Models
Extended Relational Data Model (ERDM)
Semantic data model developed in response to increasing complexity of applications
DBMS based on the ERDM often described as an object/relational database management system (O/RDBMS)

26. Database Models and Internet
• Internet drastically changed role and scope of database market
• OODM and ERDM-O/RDM have taken a backseat to development of databases that interface with Internet
• Dominance of Web has resulted in growing need to manage unstructured information

27. Emerging Data Models: Big Data and NoSQL
Big Data refers to a movement to find new and better ways to manage large amounts of Web-generated data and derive business insight from it, while simultaneously providing high performance and scalability at a reasonable cost.
The relational approach does not always match the needs of organizations with Big Data challenges.

28. Big Data
It is not always possible to fit unstructured, social media data into the conventional relational structure of rows and columns.
Adding millions of rows of multi-format (structured and non-structured) data on a daily basis will inevitably lead to the need for more storage, processing power, and sophisticated data analysis tools that may not be available in the relational environment.
The type of high-volume implementations required in the RDBMS environment for the Big Data problem comes with a hefty price tag for expanding hardware, storage, and software licenses.
Data analysis based on OLAP tools has proven to be very successful in relational environments with highly structured data.
Short for Online Analytical Processing, a category of software tools that provides analysis of data stored in a database. OLAP tools enable users to analyze different dimensions of multidimensional data. For example, it provides time series and trend analysis views. OLAP often is used in data mining.

29. DATA Abstraction
A database designer starts with an abstract view of the overall data environment and adds details as the design comes closer to implementation. Using levels of abstraction can also be very helpful in integrating multiple views of data as seen at different levels of an organization.
The different levels of Data Abstraction are as follows:
External Model is the end user’s view of the data environment, which refers to people who use the application programs to manipulate the data and generate information.
Conceptual Model represents a global view of the entire database; it’s a representation of data as viewed by the entire organization. It integrates all external views, entities, relationships, constraints and processes into a single global view of the entire data in the enterprise.

30. External Model is the end user’s view of the data environment, which refers to people who use the application programs to manipulate the data and generate information.
Conceptual Model represents a global view of the entire database; it’s a representation of data as viewed by the entire organization. It integrates all external views, entities, relationships, constraints and processes into a single global view of the entire data in the enterprise.

31. Degrees of Data Abstraction
Way of classifying data models
Many processes begin at high level of abstraction and proceed to an ever- increasing level of detail
Designing a usable database follows the same basic process
American National Standards Institute (ANSI), Standards Planning and Requirements Committee (SPARC)
Defined a framework for data modeling based on degrees of data abstraction(1970s):
External
Conceptual
Internal

32. Internal model Maps the conceptual model to the DBMS.
Internal Model is the representation of the database as seen by the DBMS.
The model requires the designer to match the conceptual model’s characteristic and constraints to those of the selected implementation model.
Internal model Maps the conceptual model to the DBMS.
Internal schema depicts a specific representation of an internal model.

33. NoSQL Database SQL – Structured Query Language – A powerful &flexible relational database language composed of commands that enable users to create database and tables
NoSQL to refer to a new generation of databases that address the specific challenges of the Big Data era.
They have the following general characteristics:
Not based on the relational model, hence the name NoSQL.
Supports distributed database architectures.
Provides high scalability, high availability, and fault tolerance.
Supports very large amounts of sparse (thin / light) data.
Geared toward performance rather than transaction consistency.
The key-value data model is based on a structure composed of two data elements: a key and a value, in which every key has a corresponding value or set of values.
The key-value data model is also referred to as the attribute-value or associative data model.

34. Physical Model
Physical Model operates at the lowest level of abstraction, describing the way data are saved on storage media such as disk or tapes, it requires the definition of both the physical storage devices and the access methods required to reach data within those storage devices, making it both software and hardware dependent.
Operates at lowest level of abstraction, describing the way data are saved on storage media such as disks or tapes
Software and hardware dependent
Requires that database designers have a detailed knowledge of the hardware and software used to implement database design

39. External Models for Tiny Colleges

41. Conceptual Model for Tiny College

42. Internal Model for Tiny College