DataBase

Ch 1
Database Applications

Traditional Applications:

• Numeric and Textual Databases

More Recent Applications:

• Multimedia Databases
• Geographic Information Systems (GIS)
• Data Warehouses
• Real-time and Active Databases
• Many other applications

Database

• An organized collection of logically related data

Data

• meaningful facts, text, graphics, images, sound, video segments

Information

• Data processed to be useful in decision making

Metadata

• Data that describe the properties or characteristics of end-user data and the context of those data
• The database definition or descriptive information is also stored by the DBMS in the form of a database
catalog or dictionary
• information stored in the catalog is called meta-data

Database Management System (DBMS)

• A software package/ system to facilitate the creation and maintenance of a computerized database.
• used to create, maintain, and provide controlled access to user databases

catalog

• contains information such as the structure of each file, the type and storage format of each data item, and
various constraints on the data.

Manipulating a database includes

• functions such as querying the database to retrieve specific data

• involves specifying the data types, structures, and constraints of the data to be stored

Type of DB Models

• File processing system (traditional)

• Hierarchical
• Network
• Relational
• Object-relational
Relational Database

• is a collection of tables that are related to one another based on a common field.

primary key(s)

• unique identifier in data model

• A common field

foreign key

• the primary key of one table is represented in a second table to form a relationship
• may have multiple occurrences

Main Characteristics of the Database Approach or Self-describing nature of a database system:

• DBMS catalog stores the description of a database not only the database
itself but also a complete definition or description of the database (data structures, types, and constraints)
• The description is called meta-data.
• This allows the DBMS software to work with different database applications.

Insulation between programs and data

• Called program-data independence

• is stored in the DBMS catalog separately from the access programs.
• Allows changing data structures and storage organization without having to change the DBMS access
programs.

Data Abstraction

• A data model is used to hide storage details and present the users with a conceptual view of the database.
➢
➢ Programs refer to the data model constructs rather than data storage details

Support of multiple views of the data:

• Each user may see a different view of the database, which describes only the data of interest to that user.

OLTP (Online Transaction Processing)

• is a major part of database applications.

• This allows hundreds of concurrent transactions to execute per second.

Database Users

1. Database administrators
2. Database Designers
3. End-users

Database administrators:

• Responsible for authorizing access to the database

• coordinating and monitoring its use
• acquiring software and hardware resources
• controlling its use and monitoring efficiency of operations
Database Designers:

• Responsible to define the content, the structure, the constraints, and functions or transactions against the
database
• They must communicate with the end-users and understand their needs

End-users:

• They use the data for queries, reports and some of them update the database content

Advantages of Using the Database Approach

• Controlling redundancy in data storage and in development and maintenance efforts.

• Restricting unauthorized access to data.
• Providing backup and recovery services.
• Providing multiple interfaces to different classes of users.
• Easier database design, implementation, anagement, and use
• Ad hoc query capability with SQL
• Powerful database management system
• Representing complex relationships among data.
• Enforcing integrity constraints on the database.
• Drawing inferences and actions from the stored data using deductive and active rules

Components of the DB Environment

• Repository (data dictionary) – centralized storehouse of metadata

• Database Management System (DBMS) – software for managing the database
• Database – storage of the data
• Application Programs – software using the data
• User Interface – text and graphical displays to users
• Database Administrators (DBA) – personnel responsible for maintaining the database
• System Developers – personnel responsible for designing databases and software
• End Users – people who use the applications and databases

data model

• Designing a database that meets the needs of the users.

• is made up entities, attributes, and relationships
• Graphical systems used to capture the nature and relationships among data.
• The most common data modeling representation is the entity-relationship model.
• Various graphical systems exist that can be understood by end users, systems analysts, and database
designers.

Entity

• noun in that it describes a person, a place, an object, an event, or a concept in the business environment for
which information must be recorded.

Attribute

• The data that are captured about the entity

Relationships

• Most relationships are one-to-many (1:M) or many-to-many (M:N).

Relational Databases

• A database that represents data as a collection of tables in which all data relationships are represented by
common values in related tables.

Database Development Process

1. Feasibility Study of Project

2. Requirement Analysis
3. Conceptual Design
4. Logical Design
5. Physical Design
6. Implementation
7. Maintenance

1. Feasibility Study of Project

Purpose : preliminary understanding

• understanding of a business situation and how information systems might help solve a problem or
make an opportunity possible
• Analyze current data processing
• Analyze the general business functions and their database needs
• Justify need for new data and databases in support of business
• Identify scope of database requirements for proposed information system
• Analyze overall data requirements for business function(s) supported by database.

Deliverable –request for project

2. Requirement Analysis

Purpose – state business situation and possible solution

• Analyze situation to determine requirements, to structure those requirements, and to select among
competing system features
• Develop conceptual data model, including entities and relationships, attributes, and business rules

Deliverable –decomposed requirements

3. Conceptual Design

Purpose –thorough analysis

Deliverable – conceptual data model

4. Logical Design
Purpose –information requirements structure
Structure :
Hierarchical DB
Network DB
Relational DB
Object Oriented
• Identify data integrity and security requirements.
• Analyze in detail the transactions, forms, displays, and inquiries (database views) required by the
business functions supported by the database
Deliverable – logical database design
 5. Physical Design

Purpose –develop technology specs

• Define physical organization of data

• structure all information requirements, to develop all technology and organizational specifications
• Define database to DBMS (often generated from repository)
• Decide on physical organization of data
• Design database processing programs

Deliverable – program/data structures, DB technology purchase

6. Implementation
Purpose – testing, training, debugging, installation, documenting
• To write programs, build databases, test and install the new system, train users, and finalize
documentation.

Database implementation:

Code and test database processing programs

Complete database documentation and training materials
Install database and convert data from prior systems
Deliverable – operational programs, documentation, training materials

7. Maintenance
Purpose –monitor, repair, enhance
• To monitor the operation and usefulness of the system, and to repair and enhance the system
Database maintenance:
Analyze database and database applications to ensure that evolving information requirements are
met
Fix errors in database and database applications and recover database it.
Deliverable – periodic audits

Project is reviewed at the end of each development phase

• Re-justify the process under the light of new requirements and available resources
• Renew commitment of stakeholders
• Continue / Revise Scope / Cancel

Ch 2
The first step in database development is database analysis

database development
• is database analysis, in which we determine user requirements for data and develop data models to
represent those requirements.

A conceptual data model

• represents data from the viewpoint of the organization, independent of any technology

BUSINESS RULES

• Are the policies and rules about the operation of a business that a data model represents.
• Are statements that define some aspect of the business
 • Are derived from policies, procedures, events, functions and state constraints on the organization
• Assert business structure
• Control/influence business behavior
• Are expressed in terms familiar to end users
• Are automated through DBMS software

Naming and defining data objects

• Fundamental to understanding and modeling data

Data names should:

• Relate to business, not technical (hardware or software), characteristics.

• Be meaningful: should avoid using generic words such as person.
• Be unique: (e.g., Home Address versus Campus Address)
• Be readable
• Be composed of words taken from an approved list.
• Follow a standard syntax

The E-R model

• is most used as a tool for communications between database designers and end users during the analysis
phase of database development

An entity-relationship model (E-R model)

• logical representation of the data : for an organization or for a business area.

• graphical representation : used to construct a conceptual data model
• representation of the structure and constraints of a database : that is independent of software

The basic constructs of the E-R model are:

• Entities
• Relationships
• Attributes.

Entities:

• instance–person, place, object, event, concept (often corresponds to a row in a table)

Relationships:

• instance–link between entity instances (corresponds to primary key-foreign key equivalencies in related
tables)

Attributes:

• Properties or characteristics of an entity or relationship type (often corresponds to a field in a table)

we present the main features of E-R modeling, using common notation and conventions
 STRONG VERSUS WEAK ENTITY TYPES

A strong entity type

• is one that exists independently of other entity types.

weak entity type

• is an entity type whose existence depends on some other entity type.

• is indicated by the double-lined rectangle

identifying relationship

• The relationship between a weak entity type and its owner

AN ENTITY

SHOULD BE:

• An object that will have many instances in the database

• An object that will be composed of multiple attributes
• An object that we are trying to model

SHOULD NOT BE:

• A user of the database system

• An output of the database system (e.g., a report)

NAMING AND DEFINING ENTITY TYPES

• is a singular noun.
• specific to the organization.
• should be concise, using as few words as possible. (An abbreviation, or a short name)
• should be specified for each entity type name, and the abbreviation

Event entity types should be named for the result of the event, not the activity or process of the event.

The name used for the same entity type should be the same on all E-R diagrams on which the entity type appears.

Classifications of attributes:

• Required versus Optional Attributes

• Simple versus Composite Attribute
• Single-Valued versus Multivalued Attribute
• Stored versus Derived Attributes
• Identifier Attributes

An attribute name is a singular noun or noun phrase

 SIMPLE VS. COMPOSITE ATTRIBUTES

A composite attribute

• An attribute that has meaningful component parts (attributes) which are more detailed attributes
• EX :Address

A simple (or atomic) attribute

• an attribute that cannot be broken down into smaller components that are meaningful for the organization.
• Ex: Mail , Age

MULTI-VALUED AND DERIVED ATTRIBUTES

A multivalued attribute

• is an attribute that may take on more than one value for a given entity (or relationship) instance.
• is indicated with curly brackets around the attribute name
• EX : Phone number

Derived attribute

• is an attribute whose values can be calculated from related attribute values ex DB

• indicated in an E-R diagram by using square brackets around the attribute name
• Ex : Age , Price and Full Name

IDENTIFIERS (KEYS)

Identifier (Key)

• an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type

Candidate Identifier

• an attribute that could be a key

• Some entities may have more than one candidate identifier.

A composite identifier

• is an identifier that consists of a composite attribute.

Choose Identifiers that

• not change in value , not be null

Substitute new, simple keys for long, composite keys

MODELING RELATIONSHIPS

A relationship

• is an association representing an interaction among the instances of one or more entity types that is of
interest to the organization.
• has a verb phrase name.
 DEGREE OF RELATIONSHIPS

Degree of a relationship

• is the number of entity types that participate in it

– Unary Relationship
– Binary Relationship
– Ternary Relationship

Unary Relationship

• One entity related to another of the same entity type

• Is a relationship type with the same participating entity type in distinct roles

Binary Relationship

• Entities of two different types related to each other

Ternary Relationship

• Entities of three different types related to each other

CARDINALITY OF RELATIONSHIPS

One-to-One

• Each entity in the relationship will have exactly one related entity

One-to-Many

• An entity on one side of the relationship can have many related entities, but an entity on the other side will
have a maximum of one related entity

Many-to-Many

• Entities on both sides of the relationship can have many related entities on the other side

Cardinality Constraints

• the number of instances of one entity that can or must be associated with each instance of another entity

Minimum Cardinality

• If zero, then optional

• If one or more, then mandatory

Maximum Cardinality

• The maximum number

Ch 3
EER Model Concepts

Includes all modeling concepts of basic ER Additional concepts:

• subclasses/superclasses
• specialization/generalization
 • categories (UNION types)
• attribute and relationship inheritance

• model a general entity type (called the supertype) and then subdivide it into several specialized entity types
(called subtypes).
• EER diagrams extend ER diagrams to represent these additional subgroupings, called subclasses or
subtypes
• Each subtype inherits attributes from its supertype and in addition may have special attributes and be
involved in relationships of its own.
• It is not necessary that every entity in a supertype be a member of some subtype

Enhanced ER model:

• extends original ER model with new modeling constructs

Subtype:

• A subgrouping of the entities in an entity type that has attributes distinct from those in other subgroupings

Supertype:

• A generic entity type that has a relationship with one or more subtypes

Attribute Inheritance:

• Subtype entities inherit values of all attributes of the Supertype

• An instance of a subtype is also an instance of the supertype

The U-shaped symbol :

• connecting a subtype of the supertype.

• the direction of the subtype/supertype relationship

o Attributes that are shared by all entities are associated with the supertype.
o Attributes that are unique to a particular subtype are associated with that subtype.
The same is true for relationships.
o Relationships at the supertype level indicate that all subtypes will participate in the relationship
o The instances of a subtype may participate in a relationship unique to that subtype. In this situation, the
relationship is shown at the subtype level.

Two Rules For Using supertype / subtypes

Use this type of relationship when either (or both):

• When there are attributes that apply to some (but not all) of the instances of an entity type
• When the instances of a subtype participate in a relationship unique to that subtype

Attribute Inheritance

• The property by which subtype entities inherit values of all attributes of the supertype.
 Generalization And Specialization

Generalization:

• The process of defining a more general entity type from a set of more specialized entity types.
• BOTTOM-UP
• is the reverse of the specialization process Several classes with common features are generalized into a
supertype
• Example: CAR, TRUCK generalized into VEHICLE

Specialization:

• The process of defining one or more subtypes of the supertype and forming supertype/subtype
relationships.
• TOP-DOWN
• called specific or local attributes.
• The set of subtypes is based upon some distinguishing characteristics of the entities in the supertype
• Example: {SECRETARY, TECHNICIAN} is a specialization of EMPLOYEE based upon job type.
• May have several specializations of the same supertype
• The subtype can also participate in specific relationship types.

Two basic constraints can apply to a specialization/generalization:

1. Disjointness Constraint
2. Completeness Constraint

Disjointness Constraint:

• Specifies that the subtypes of the specialization must be disjoint sets.

• an entity can be a member of at most one of the subtypes of the specialization
o Specified by d in EER diagram
• If not disjoint, specialization is overlapping:
o that is the same entity may be a member of more than one subtype of the specialization
o Specified by o in EER diagram

Whether an instance of a supertype may simultaneously be a member of two (or more) subtypes

• Disjoint Rule: An instance of the supertype can be only ONE of the subtypes
• Overlap Rule: An instance of the supertype could be more than one of the subtypes

Completeness Constraint:

• Total specifies that every entity in the supertype must be a member of at least one subtype in the
specialization/generalization
o Shown in EER diagrams by a double line
• Partial allows an entity not to belong to any of the subtypes
o Shown in EER diagrams by a single line

we have four types of specialization/generalization:

 • Disjoint, total
• Disjoint, partial
• Overlapping, total
• Overlapping, partial

Generalization usually is total because the superclass is derived from the subclasses.

Subtype Discriminator:

• An attribute of the supertype whose values determine the target subtype(s)

Disjoint

• a simple attribute with alternative values to indicate the possible subtypes

Overlapping

• a composite attribute whose subparts pertain to different subtypes.

Each subpart contains a Boolean value to indicate whether or not the instance belongs to the associated subtype

Ch 4
Relational data model

• The relational data model represents data in the form of tables

• called normalization

The E-R model was developed for other purposes:

• understanding data requirements and business rules about the data

• not structuring the data for sound database processing, which is the goal of logical database design.

Relation

• A relation is a named, two-dimensional table of data.

A table consists of

• rows (records)
• columns (attribute or field)

Requirements for a table to qualify as a relation:

Each relation (or table) in a database has a unique name.

• An entry at the intersection of each row and column is atomic (or single valued).There can be only one
value associated with each attribute on a specific row of a table; no multivalued attributes are allowed in a
relation.
• Every row must be unique (can’t have two rows with exactly the same values for all their fields).
• Attributes (columns) in tables must have unique names.
 NOTES:

• The word relation (in relational database) is NOT the same as the word relationship (in E-R model).
• Relations (tables) correspond with entity types.
• Rows correspond with entity instances.
• Columns correspond with attributes

Key Fields

Keys are special fields that serve two main purposes:

1- Primary keys
• unique identifiers of the relation in question.
• Ex: employee numbers, social security numbers
2- Foreign keys
• identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent
relation (on the one side of the relationship)

Keys

• can be simple (a single field) or composite (more than one field).

• usually are used as indexes to speed up the response to user queries

– A relational database may consist of any number of relations.

– The structure of the database is described through the use of a schema.

Schema:

• is a description of the overall logical structure of the database.

There are two common methods for expressing a schema:

Short text statements

• in which each relation is named and the names of its attributes follow in parentheses.

A graphical representation

• in which each relation is represented by a rectangle containing the attributes for the relation

three main types of constraints in the relational model:

• Domain constraints
• Entity integrity constraints
• Referential integrity constraints

Domain Constraints

• All of the values that appear in a column of a relation must be from the same domain. (or it could be null, if
allowed for that attribute).
• is the set of values that may be assigned to an attribute.
A domain definition consists of the following components:

domain name, meaning, data type, size (or length), and allowable values or allowable range.

Entity Integrity

• The entity integrity rule is designed to ensure that every relation has a primary key.
• No primary key attribute may be null. All primary key fields MUST have data.

Referential Integrity

• rule states that any foreign key value (on the relation of the many side) MUST match a primary key value
in the relation of the one side. (Or the foreign key can be null)
• For example: Delete Rules

Basic operations for changing the database:

• INSERT a new tuple in a relation

• DELETE an existing tuple from a relation
• MODIFY an attribute of an existing tuple

Mapping Regular Entities to Relations

Regular entities:

• are entities that have an independent existence and generally represent real-world objects, such as persons
and products.
• rectangles with a single line.

Weak entities:

• are entities that cannot exist except with an identifying relationship with an owner (regular) entity type.
• by a rectangle with a double line.

Associative entities:

• are formed from many-to-many relationships between other entity types

• represented by a rectangle with rounded corners

Simple attributes:

• E-R attributes map directly onto the relation

Composite attributes:

• Use only their simple, component attributes

Multivalued Attribute:

• Becomes a separate relation with a foreign key taken from the superior entity
Mapping Weak Entities

Primary key composed of:

• Partial identifier of weak entity

• Primary key of identifying relation (strong entity)

Mapping Binary Relationships:

The procedure for representing relationships depends on both

• the degree of the relationships (unary, binary, or ternary)

• the cardinalities of the relationships.

Mapping Unary Relationships

• One-to-Many–Recursive foreign key in the same relation

• foreign key attribute is added to the same relation; this attribute references the primary key values in the
same relation.
• called a recursive foreign key

Mapping Ternary (and n-ary) Relationships

• One relation for each entity and one for the associative entity

Mapping Supertype/Subtype Relationships

• One relation for supertype and for each subtype