Data, Information & Knowledge Database DBMS Types of Models E-R Model.

Data, Information & Knowledge

Database

DBMS

Types of Models

E-R Model

Knowledge is what we know

helps us know where things are

It also contains our beliefs and expectations.

It is from this “map” that we base our decisions,

constantly updated

You can’t currently store knowledge in anything other than the brain

two sources that the brain uses to build this knowledge - information and data.

facts of the World

description of the World.

We can perceive this data with our senses, and then the brain can process this.

knowledge was limited by our direct experiences.

can capture data in information, to be accessed at different times.

The information can be lost, but the data can’t be.

Data is always correct (I can’t be 29 years old and 62 years old at the same time)

but information can be wrong (there could be two files on me, one saying I was born in 1981, and one saying I was born in 1948).

Information captures data at a single point. The data changes over time.

Mistake : information is always an accurate reflection of the data.

Collection of data ?

not every collection of data is a database

An organized collection of related data

Eg ?

Keep records of our: Clients Staff Volunteers

To keep a record of activities and interventions;

Keep sales records;

Develop reports;

Perform research

A software package/ system to facilitate the creation and maintenance of a computerized database.

A database's properties are determined by its supporting DBMS and vice-versa

Availability Efficient access Abstraction

• Protection or Security measures to prevent unauthorized access

• Reliable storage & recovery of 100s of GB• Querying/updating interface and API• Support for many concurrent users• Backup and recovery services.

DataData InformationInformation KnowledgeKnowledge ActionAction

Is to transformIs to transform

Navigationalpointers from one record to another. eg: hierarchical model, Network model

Relational modelsearch for data by content, rather than by following links

Entity-relationship modelto overcome the problems of Relational model as a modelling lang.

Object database and the XML database : for multimedia, engg, documents etc.

for representation of real-world

represents overall logical structure of information grouping of data elements inter-relationships between groups

simple and easy-to-use

permits top-down approach for controlling details

useful as a tool for communication between designer and user during requirements analysis and conceptual design

Entity

Entity set Strong entity type Weak entity type ( discriminator / partial key)

Attributes Simple and composite attributes Single valued and multi valued attributes Stored and derived attributes Null attribute Key attribute

Relationships Degree

Cardinality

Mapping cardinalities One to one One to many Many to one Many to many

Participation constraints Total participation Partial participation

Keys Super key Candidate key Primary key Foreign key

Why EER Modelling?

Inheritance

Specialization

Generalization

Emergence of new technologies

Semantic data modeling concepts

Employee Secretary Technician Engineer Manager Clerk

Sub class Super class Inheritance

Define a set of subclasses of an entity type

Establish additional specific attributes with each sub class

Establish additional specific relationship types between each subclass and entity types or other sub classes

The set of subclasses is based upon some distinguishing characteristics of the entities in the superclass

• May have several specializations of the same superclass ▪ {PERMANENT_EMPLOYEE, TEMPORARY_EMPLOYEE}

based on method of pay▪ {FACULTY, CLERK, TECHNICIAN}

based upon job type

• specific attributes▪ Eg : TypingSpeed of SECRETARY

• specific relationship types▪ Eg: HOURLY_EMPLOYEE can BELONG TO some TRADE UNIONs etc.

Inverse process of specialization

Identify the common features of several entity types

Generalize them into a single super class

Eg : Employee is a generalization of {SECRETARY, ENGINEER, TECHNICIAN}

Types of specialization

Constraints on specialization

Specialization & Generalization Hierarchies Lattices

Summary

Predicate defined

Condition specified

Conditions are specified on the values of some attributes in the superclass

Defining predicate

Eg: JobType = “Secretary”

Attribute defined If all subclasses in a specialization have membership condition on

same attribute of the superclass

Defining attribute

Eg: JobType

User Defined No condition for determining the membership of the subclass

Specified individually for each entity by the user

“Secretary”“Engineer”

“Technician”

Job Type Defining attribute

Defining predicate

Disjointness Constraint Subclasses of the specialization must be disjoint An entity can be a member of at most one of the subclasses of the

specialization Not disjoint Overlap

Notation

d ODisjointness Overlapping

A patient can either be outpatient or resident, but not both

A part may be both purchased and manufactured

Completeness Constraint Total

every entity in the superclass must be a member of some subclass in the specialization/ generalization

Shown in EER diagrams by a double line Eg: Employee {Hourly_Employee, Salaried_Employee}

Partial allows an entity not to belong to any of the subclasses Shown in EER diagrams by a single line Eg: Employee need not be {Secretary, Technician, Engineer}

A patient must be either an outpatient or a resident patient

A vehicle could be a car, a truck, or neither

Hierarchy: Every subclass has only one superclass single inheritance

Lattice: A subclass can be subclass of more than one superclass multiple inheritance

Same for generalization hierarchies or lattices

Shared subclass: A subclass with more than one superclass

In a lattice or hierarchy, a subclass inherits attributes not only of its direct superclass, but also of all its predecessor superclasses

Specialization top down approach

Generalization bottom up approach

In practice, the combination of two processes is employed

Binary or ternary relationships ?

Constraints on n-ary relationships

Aggregation

Union / Category

On the basis of semantics of the situation

SupplierProject

Part

Supply

SupplierProject

Part

Supplies

Can supply

Uses

Solution 1:

Include the ternary relationship + 1 or more of the binary relationships (if they rep. diff. meanings & if all are needed for the appln.)

Solution 2:

Represent the ternary relationship as weak entity type with NO partial key & identifying relationships.

1. Cardinality Ratio Notation

1, M, N

2. Min, Max Notation

ER Model can’t represent relationships among relationships

Aggregation : To represent relationship between a whole object & its

component parts

Relationships are treated as higher level entities

Chapter 4-51

CAR

Chassis (steel frame)

OtherSystems

Drive-train

represents IS-PART-OF (component) relationship

Root class: CARComponent Classes: Chassis, Drive-Train, Other Systems, WheelsRoot class: WheelsComponent Classes: Tires, Tubes, Hub-Caps

Wheels

Tires Hub-CapsTubes

Suppose we want to record managers for tasks performed by an employee at a branch

Engineering_Manager Engineer Manager Salaried Employee

Need to model a single superclass/subclass relationship with more than one superclass

subclass = collection of objects i.e. a subset of the “union” of distinct entity types

SHARED SUB CLASS

subset of the intersection of its superclasses

shared subclass member must exist in all of its superclasses

Attribute Inheritance : Total

CATEGORY

subset of the union of its superclasses

category member must exist in any of its superclasses

Attribute Inheritance : Selective

THANK YOU !!!