SESSION 1

EXAMPLES OF DATABASE APPLICATIONS

- Purchases from the supermarket
- Purchases using your credit card
- Booking a holiday at the travel agents
- Using the local library
- Taking out insurance
- Renting a video
- Using the internet
- Studying at university

TRADITIONAL FILE-BASED SYSTEMS

File-based systems:
- Collection of application programs that perform services for end users (e.g. reports)
- Each program defines and manages its own data

Limitations of File-Based Approach:

● Separation and isolation of data
○ Each program maintains its own set of data
○ Users of one program may be unaware of potentially useful data in other
programs.
● Duplication of data
○ Same data is held by different programs.
○ Wasted space and potentially different values and/or different formats for the
same item
● Data Dependence
○ File structure is defined in the program code.
● Incompatible file formats
○ Programs are written in different languages, and so cannot easily access
each other’s files.
 ● Fixed Queries/Proliferation of application programs
○ Programs are written to satisfy particular functions.
○ Any new requirement needs a new program.

DATABASE APPROACH
- Data Definition Language (DDL)
- Create, Alter, Drop
- Data Manipulation Language (DML)
- Insert, Update, Delete, Select
- Data Control Language (DCL)
- Grant, Revoke
● Controlled access to database:
○ Security system
○ Integrity system
○ Concurrency control system
○ Recovery control system
○ User-accessible catalogue

COMPONENTS OF DBMS ENVIRONMENT

● Hardware
● Software
● Data
● Procedures
● People

ROLES IN THE DATABASE ENVIRONMENT

- Data Administrator (DA)
- Database Administrator (DBA)
- Database Designers (Logical & Physical)
- Application Programmers
- End Users

HISTORY OF DATABASE SYSTEMS

● First-generation, Hierarchical and Network
- Second generation, Relational
- Third generation,
- Object- relational
- Object-oriented

DATABASE RELATIONS
- Relation schema
- Named relation defined by a set of attribute and domain name pairs.
● Relational database schema
○ Set of relation schemas, each with a distinct name.
PROPERTIES OF RELATIONS
- Relation name is distinct from all other relation names in relational schema.
- Each cell of relation contains exactly one atomic (single) value. • Each attribute has a
distinct name.
- Values of an attribute are all from the same domain.
- Each tuple is distinct; there are no duplicate tuples.
- Order of attributes has no significance.
- Order of tuples has no significance, theoretically.

RELATIONAL KEYS
- Superkey
- Candidate Key
- Primary key
- Alternate Keys
- Foreign Key

INTEGRITY CONSTRAINTS
- Referential Integrity
- If foreign key exists in a relation, either foreign key value must match a
candidate key value of some tuple in its home relation or foreign key value
must be wholly null.
- General Constraints
- Additional rules specified by users or database administrators that define or
constrain some aspect of the enterprise.
 NORMALISATION
IMPORTANT PROPERTIES OF DECOMPOSITION
- Lossless-join property
- Find any instances of the original relation from corresponding instances in the
smaller relations.
- Dependency preservation property
- Enforce a constraint on the original relation by enforcing some constraint on
each of the smaller relations.

Functional Dependency
- Functional dependency adalah setiap atribut yang bukan kunci (non key)
bergantung secara fungsional terhadap primary key.

Transitive Dependency
- Apa itu “transitive dependency”? Transitive dependency biasanya terjadi pada
tabel hasil relasi, atau kondisi dimana terdapat tiga atribut A, B, C. Kondisinya
adalah A ⇒ B dan B ⇒ C. Maka C dikatakan sebagai transitive dependency
terhadap A melalui B.

2NF
- NO FUNCTIONAL DEPENDENCY,
- Intinya adalah pada tahap normalisasi 2NF ini tabel tersebut harus dipecah
berdasarkan primary key.
3NF
- NO PARTIAL TRANSITIVE DEPENDENCY
- Intinya pada 3NF ini, jika terdapat suatu atribut yang tidak bergantung pada
primary key tapi bergantung pada field yang lain maka atribut-atribut tersebut
perlu dipisah ke tabel baru.
 ENTITY RELATIONSHIP MODELLING
COMPONENTS
- Entity/entity type
- Entity is a group of objects with the same properties
- Based on its existence:
- Physical existence (Staff, Property, Customer, Part, etc)
- Conceptual existence (Viewing, Sale, Inspection, Work
experience)
- Strong
- Entity that is not existence dependent on some other entity
- Weak
- Entity that is existence dependent on some other entity
- Relationship
- Relationship is a set of meaningful associations among entities
- Degree is the number of participating entity types in a relationship
- Types
- Binary Association (Degree = 2)
- Ternary relationship called (Degree = 3)
- Quaternary relationship (Degree = 4)
- Recursive relationship
- Relationship where same entity type participates more
than once in different roles
- Attributes
- Property of an entity or a relationship type.
- Attribute Domain
- Set of allowable values for one or more attributes
- Types
- Simple attribute
- Single component with an independent existence
- Composite attribute
- Multiple components, each with an independent
existence
- Single-valued attribute
- Holds a single value for each entity type
- Multi-valued attribute
- Multiple values for each entity type
- Derived attribute
- Represents a derivable value from value of a related
attribute, or set of attributes, not necessarily in the same
entity type
- Multiplicity
- Main type of constraint on relationships
- "multiplicity" refers to the number of occurrences or associations
between entities in a relationship. It is used to describe how many
 instances of one entity can be related to how many instances of
another entity.
- Represents policies established by the user/company.
- Binary relationships:
- One to one 1:1
- One to many 1:*
- Many to many *:*
- Structural constraints
- Cardinality
- Describes maximum number of possible relationship
occurrences for an entity participating in a given
relationship type.
- Participation
- Determines whether all/only some entity occurrences
participate in a relationship
- Can be optional or mandatory

KEYS
- Candidate Key
- Minimal set of attributes that uniquely identifies each occurrence of an
entity type.
- Primary Key
 - Candidate key selected to uniquely identify each occurrence of an
entity type
- Composite Key
- Candidate key that consists of two or more attributes

PROBLEMS WITH ER MODEL

- Fan trap
- Where a model represents a relationship between entity types, but the
pathway between certain entity occurrences is ambiguous.
- Chasm trap
- Where a model suggests the existence of a relationship between entity
types, but pathway does not exist between certain entity occurrences.
THREE ENHANCEMENT TYPES OF THE EER MODEL
- Generalization / Specialisation
- Aggregation
- Composition

Generalization/ Specialization
- Superclass
- an entity type that includes one or more distinct subgroupings of its
occurrences, which require to be represented in a data model.
- Subclass
- a distinct subgrouping of occurrences of an entity type, which require to
be represented in a data model.
- Specialisation
- the process of maximising the differences between members of an
entity by identifying their distinguishing features.
- Generalisation
- the process of minimising the differences between entities by
identifying their common features

Constraints on Generalization/ Specialization

- Participation constraint
- Determines whether every member in a superclass must participate as
a member of a subclass. – May be mandatory (must have subclass,
minimum 1 subclass) or optional (can have no subclass).
- Disjoint constraint
 - Describes relationship between members of the subclasses and
indicates whether a member of a superclass can be a member of one,
or more than one, subclass.
- May be:
- disjoint (OR): maximum 1 subclass
- nondisjoint (AND): can have more than 1 subclass.

Aggregation and Composition

- Aggregation represents a “has-a” or “is-part-of ” relationship between entity
types, where one represents the “whole” and the other the “part.”
- Composition is a specific form of aggregation that represents an association
between entities, where there is a strong ownership and coincidental lifetime
between the “whole” and the “part”