DATABASE FUNDAMENTALS

FILE BASED SYSTEM

• It is a collection of programs that perform services for the end user.

• Each Program defines and manages its own data
LIMITATIONS OF FILE BASED SYSTEM APPROACH

• Separation & Isolation Of data

• Duplication Of data
• Program Data Dependence
• Incompatible File Formats
DATABASE SYSTEM

• Database: A collection of related data.

• Database Management System (DBMS): A software package/ system to

facilitate the creation and maintenance of a computerized database.

• Database System: The DBMS software together with the data itself.
Sometimes, the applications are also included. ( Software + Database )
SCHEMA VS METADATA

• Schema is the Layout of your Database.

• Meta Data is the Data about your Database.
• A database metadata consists of lots of information about its schema,
storage, language, security, etc. Whereas a database schema consists of the
structure of data in the database such as how the data is organized into
tables, rows and columns, etc as well as the relationships and constraints
between those data.
REAL WORLD EXAMPLES

• Metadata: The extra information generated when you take a picture with your
phone such as date, location, etc.
• Schema: The layout of a website such us where is the main title, content, etc.
THREE LEVEL/SCHEMA ARCHITECTURE

• External – What the user sees: focus on what different types of users will see when viewing the
database. They are concerned with what data the user will see and how the data will be
presented to the user.

• Conceptual – The logical model: focus on the logical nature of the data representation. They are
concerned with what is represented rather than how it is represented.(define database structures
such as tables and constraints)

• Internal – The physical model: place the emphasis on how the data are represented in the
database or on how the data structures are implemented.
MAPPINGS

• Definition: It is the processes of transforming requests and results between

levels.

• These mappings may be time-consuming. However, a certain amount of

mapping between the conceptual and internal levels is necessary.
• Data independence: The capacity to change the schema at one level without
having to change the schema at the next higher level.
DATA MODELS

• High Level or Conceptual data models provide concepts that are close to the
way many users perceive data, entities, attributes and relationships. (Ex. ERD)

• Physical data models describes how data is stored in the computer and the
access path needed to access and search for data.
ENTITY RELATIONSHIP MODELING

Entity-Relationship Diagram (ERD): identifies information required by the

business by displaying the relevant entities and the relationships between
them.
ENTITY RELATIONSHIP MODELING (CONT’D)

• In building a data model a number of questions must be addressed:

• What entities need to be described in the model?
• What characteristics or attributes of those entities need to be recorded?
• Can an attribute or a set of attributes be identified that will uniquely
identify one specific occurrence of an entity?
• What associations or relationships exist between entities?
DEFINITIONS

• Entity - An entity is a thing in the real world with an independent existence. Physical existence
(for example, a particular person, car) or conceptual existence (for instance, a job, or a
university course). Types of entities: Weak- Regular

• Entity Instance - An instance is a particular occurrence of an entity. For example, each

person is an instance of an entity, each car is an instance of an entity, etc.

• Attribute - The particular properties that describe the entity. An EMPLOYEE entity may be
described by the employee’s name, age, address and salary attributes.
WEAK ENTITY TYPES

• An entity that does not have a key attribute

• A weak entity must participate in an identifying relationship type with an

owner or identifying entity type

• Entities are identified by the combination of:

• A partial key of the weak entity type
• The particular entity they are related to in the identifying entity type
WEAK ENTITY EXAMPLE

• DEPENDENT entity is identified by the dependent’s first name and birth date,
and the specific EMPLOYEE that the dependent is related to. DEPENDENT is a
weak entity type with EMPLOYEE as its identifying entity type via the
identifying relationship type DEPENDENT_OF.
• Another example is a parent entity in a school database.
TYPES OF ATTRIBUTES

• Key: an attribute whose values are distinct (unique) for each entity and can be used to uniquely identify the record.

• Multi-valued: has a set of values for the same entity instance.

• Composite: can be divided into smaller subparts.

• Derived: can be calculated from another attribute or entity.

• Single/Simple: Attributes that are not divisible and have a single value for a particular entity instance.
KEY ATTRIBUTE

• Single Key: For example, SSN of EMPLOYEE

• Composite Key: the combination of the attribute values that together form a
key and must be distinct for each entity. For example, ID and Application_no

• Candidate Key: when an entity type has more than one key, those are
candidate keys
RELATIONSHIPS

• Relationships - A relationship is a connection between entity classes.

1. Degree of a Relationship: is the number of participating entity

2. Cardinality Ratio: specifies the maximum number of relationship

3. Participation: specifies the minimum number of relationship instances that each

entity can participate with
1. DEGREE OF A RELATIONSHIP
2. CARDINALITY RATIO
3. PARTICIPATION

a. Total/ Full Dependency/ Mandatory

b. Partial/ Partial Dependency/ Optional

1 1
Emp manage Dept

Partial Full
PARTICIPATION EXAMPLE

Employee Has Car

ERD NOTATIONS
EXAMPLE

• A company is organized into departments. Each department has a unique

name, a unique number, and a particular employee who manages the
department. A department may have several locations.

• A department may control a number of projects, each of which has a unique

name, a unique number, and a single location. A project must controlled by
department
EXAMPLE (CONT’D)

• We store employee’s name, social security number, address, salary, gender

and birth date. An employee must be assigned to one department and must
work on one or more projects, which are not necessarily controlled by the
same department. We keep track of the number of hours per week that an
employee works on each project. We also keep track of the direct supervisor
of each employee.

• We want to keep track of the dependents of each employee for insurance

purposes. We keep each dependent’s first name, gender, birth date and
relationship to that employee.
ERD NARRATIVE

• A database for a banking system is used to control withdrawal, deposit and

loan transactions with customers.
• Banks which use this system have many branches; each branch has a unique
name, unique address and phone.
• The system stores information about customers as unique customer ID, name,
address, and phones.
ERD NARRATIVE (CONT’D)

• Each customer has one Account identified by unique Account number, amount,
last transaction date (Day, Month and Year).
• The system records Transaction number, Transaction type, Transaction date,
Transaction amount and time. The system records the branch name where the
transaction occurred.
• A Customer can make any type of transactions (Withdrawal or Deposit) from
any branch of the bank.
ER-TO-RELATIONAL MAPPING

1. Mapping of Regular Entity Types

2. Mapping of Weak Entity Types
3. Mapping of Binary 1:1 Relation Types
4. Mapping of Binary 1:N Relation Types
5. Mapping of Binary M:N Relation Types
6. Mapping of Multi-valued attributes
7. Mapping of N-ary Relationship Types
1. MAPPING OF REGULAR ENTITY TYPES

• Create table for each entity type

• Choose one of key attributes to be the primary key
2. MAPPING OF WEAK ENTITY TYPES

• Create table for each weak entity.

• Add foreign key that correspond to the owner entity type.
• Choose the primary key : ( FK + weak entity Partial PK if any)
3. MAPPING OF BINARY 1:1 RELATION TYPES

• Merge two tables if both sides are Mandatory.

• Add FK into table with the total participation relationship to represent
optional side.
• Create third table if both sides are optional.
4. MAPPING OF BINARY 1:N RELATION TYPES

• Add FK to N-side table

• Add any simple attributes of relationship as column to N-side table
5. MAPPING OF BINARY M:N RELATION TYPES

• Create a new third table

• Add FKs to the new table for both parent tables
• Add simple attributes of relationship to the new table if any
6. MAPPING OF MULTI-VALUED ATTRIBUTES

• Create new table for each multi-valued attribute

• Table will include two columns
→one for multi-valued attribute
→FK of original table
7. MAPPING OF N-ARY RELATIONSHIP TYPES

• If n > 2 then:
• Create a new third table
• Add FKs to the new table for all parent tables
• Add simple attributes of relationship to the new table if any
DATABASE CONSTRAINTS

• Database constraints are a key feature of database management systems. They

ensure that rules defined at data model creation are enforced when the data is
manipulated ( inserted, updated, or deleted) in a database.
WHY CONSTRAINTS ?

• It is not mandatory
• It ensures at database level that the data is accurate and reliable.
• Having those rules enforced at database level rather than in the application
or presentation layer ensures that the rules are consistently enforced no matter
who manipulates the data and how it is manipulated.
SAME IN EVERY DBMS ?

• Not all database management systems support the same types of constraints.
• There may be special features or considerations for the specific system.
• The syntax for creating constraints also depends on the specific RDBMS.

TRY TO CHECK THIS!

CONSTRAINTS TYPES

• Not Null
• Unique Key
• Primary Key (Not Null + Unique)
• Referential Integrity (FK)
• Domain of Values (Check)
• Default
NOT NULL

• Enforces a column to not accept null values.

• You can not insert a new record or update an existing one without adding a
value to this field.
UNIQUE KEY & PRIMARY KEY

• Ensures that all values in a column are different.

• Both UNIQUE and PRIMARY KEY constraints provide a guarantee for uniqueness for a
column or a set of columns.
• A PRIMARY KEY constraint automatically has a UNIQUE constraint.
• You can have many UNIQUE constraints but only one PRIMARY KEY per table.
• PRIMARY KEY can not contain null values.
• Primary key can consist of single or multiple fields.
UNIQUE KEY & PRIMARY KEY
REFERENTIAL INTEGRITY

• Used to prevent actions that would destroy links between tables.

• FK is a field/s in one table that refers to PK in another table.
CHECK

• Used to limit the value range that can be placed in a column.

• It allows only certain values for this column.
DEFAULT

• Used to set a default value for a column.

• DEFAULT value will be added to all new records if no other value is specified.
CONSTRAINTS CREATION

• Constraints can be defined when we create a table or can be added later.

• They can be explicitly named when created (thus allowing us to identify them
easily), or they can have system-generated names if an explicit name is
omitted.
SQL JOIN

• Join clause to combine rows from two or more tables based on a related
column between them.
TYPES OF JOINS
INNER JOIN
LEFT OUTER JOIN
RIGHT OUTER JOIN
FULL OUTER JOIN
SELF JOIN
EXAMPLE

• The following SQL statement matches customers that are from the same city
TABLE A & TABLE B
RESULT !!!!
ANOTHER EXAMPLE
TWO INSTANCES OF SAME TABLE

• Employee • Manager
RESULT
NON-EQUI JOIN

• Job Grades • Employees

NON-EQUI JOIN
NESTED QUERIES

• A Subquery or Inner query or a Nested query is a query within another SQL

query and embedded within the WHERE or Having clause.
• A subquery is used to return data that will be used in the main query as a
condition to further restrict the data to be retrieved.
• Sometimes it is placed in the FROM clause and called “inline view”
EXAMPLE1
RESULT
EXAMPLE2
EXAMPLE3
DATABASE NORMALIZATION

• Normalization is a database design technique that reduces data redundancy

and eliminates undesirable characteristics like Insertion, Update and Deletion
Anomalies.
• Normalization rules divides larger tables into smaller tables and links them
using relationships.
UN-NORMALIZED DATA
DEPENDENCIES

• 1. (Full) Functional Dependency.

• 2. Partial (Functional) Dependency.
• 3. Transitive (Functional) Dependency.
DEPENDENCIES (CONT’D)

• A constraint that determines the relation of one attribute to another attribute

in a Database Management System (DBMS).
• A functional dependency is denoted by an arrow “→”. The functional
dependency of X on Y is represented by X → Y.
DEPENDENCIES (CONT’D)

• Full Functional Dependency- X → Y is a FFD if removal of any attribute A

from X means that the dependency does not hold any more.
• Partial Functional Dependency- X→Y is a PFD if some attribute A ε X can be
removed from X and the dependency still holds.
• Transitive Functional Dependency- X→Y in a relation R is a TFD if there exists
a set of attributes Z in R that is neither a primary key nor a subset of any key
of R, and both X→Z and Z→Y hold
DATABASE NORMAL FORMS

• 1NF (First Normal Form)

• 2NF (Second Normal Form)
• 3NF (Third Normal Form)
• BCNF (Boyce-Codd Normal Form)
• 4NF (Fourth Normal Form)
• 5NF (Fifth Normal Form)
• 6NF (Sixth Normal Form)
1NF

• For a table to be in the 1NF, it should follow the following 4 rules:

1. It should only have single(atomic) valued attributes/columns.
2. It should not contain repeating groups.
3. Values stored in a column should be of the same domain.
4. All the columns in a table should have unique names.
5. The order in which data is stored, does not matter.
2NF

• For a table to be in the 2nf, it should follow the following rules:

1. It should be in the 1NF.
2. It should not have Partial Dependency.
3NF

• For a table to be in the 3nf, it should follow the following rules:

1. It should be in the 2NF.
2. It should not have Transitive Dependency.
EXAMPLE1
1NF
2NF
3NF
EXAMPLE2
1NF
2NF
3NF
EXAMPLE3
1NF!!
HOMEWORK

• Narrative to ERD to relational model to DDL (Create the physical database)

• DDL, DML, DCL & TCL (def, clauses, Examples)
• Views (def, types)
• Indexes (def, types) (optional)
• Triggers (def, types) (optional)
• Cross Join & Semi-Join (def, examples)
• Database Normalization [BCNF, 4NF, 5NF, …] (optional)