Fundamentals of

Databases and
Data Models
Definition of key terminologies
Standard structure for databases.
 Foundations of Database Terms
1. File
• A file is an ordered arrangement of records in which each
record is stored in a unique identifiable location.
• The sequence of the record is then the means by which
the record will be located.
• In most computer systems, the sequence of records is
either alphabetic or numeric based on the field common to
all records such as name or number.
 2. Record
• A record or tuple is a complete set of related fields.
• For example, table below shows a set of related fields,
which is a record.
• If this were to be a part of a table then we would call it a
row of data.
• Therefore, a row of data is also a record.
S/No Name NDA No LGA Battalion
1 AA Gimba NDA/11254 Chikun Burma
2 A Adedokun NDA/11299 Zaria Dalet
3 AB Sanusi NDA/11191 Isale Eko Mogadishu
 3. Field
• A field is a property or a characteristic that holds some
piece of information about an entity.
• Also, it is a category of information within a set of records.
• For example, Matriculation number of PGD Students
• The first names, or address or phone numbers of people
listed in address book.
 4. Entity
• Usually recognizable concepts, either concrete or
abstract, such as person, places, things, or events which
have relevance to the database.
• Some specific examples of entities are STUDENTS,
LECTURERS, EMPLOYEES, PROJECTS, INVOICES.
 5. Attributes
• A property or characteristics that hold some information
about an entity.
• A ‘Customer’ for example, has attributes such as a name
and an address.
• Any more attributes come to mind?
 What is a Data Model?
• a notation for describing data or information.
• a collection of conceptual tools for describing data, data relationships,
data semantics, and consistency constraints.
• focuses on what data is required and how it should be organized rather
than what operations will be performed on the data.
• a common analogy: data model is equivalent to an architect's building
plans.
• is independent of hardware or software constraints
• focuses on representing the data as the user sees it in the "real world"
• A bridge between the concepts that make up real-world events and
processes
• And the physical representation of those concepts in a database.
• The database design process roughly follows five steps:
1. planning and analysis
2. conceptual design – data modelling
3. logical design
4. physical design
5. implementation
Components of a Data Model (In
Database design view)
Outputs
Input
E-R diagram
(pictorial: contains
data structures)
Planning and Data
Analysis Modelling

Data document
(data objects,
relationships)
 Data model is:
• A "blueprint" or plan for building the physical database.
• Used by database developers.
• must be simple enough to communicate to the end user the
data structure required by the database
• YET detailed enough for the database developer to use to
create the physical structure.
• The Entity-Relation Model (ER) is the most common method
used to build data models for relational databases.
 Why Data Modelling?
• most labor intensive and time consuming part of the database
development process.
• you should no more build a database without a model than you should
build a house without blueprints.
• The goal of the data model is to make sure that the all data objects
required by the database are completely and accurately represented.
• Because the data model uses easily understood notations and natural
language, it can be reviewed and verified as correct by the end-users.
 Reasons for Data Modelling
• For efficient computerization
• Reduce data redundancy
• Disk space problem
• Volume of data transfer
• Objects of documentation
• Describe the computed elements – user notice – technical notice
• For the programmer
• For the system designer
• For the end-users
• Guaranty data integrity
• Valid information irrespective of context
 Other Data Models
• Other well known data models that have been the basis of
database systems.
• The best known models pre dating the relational model –
network and hierarchical model
• Network model – entity types and relationship among
them form a graph
• Hierarchical model – entity types form a tree
 Entity Relationship (ER) Model
• Originally proposed by Peter Chen as a way to unify the
network and relational database views. (Chen 1976)
• ER model is a conceptual data model that views the real
world as entities and relationships.
• A basic component of the model is the Entity-Relationship
diagram which is used to visually represent data objects.
• Since Chen wrote his paper the model has been extended
and today it is commonly used for database design
 Benefits of ER Model
• For the database designer, the utility of the ER model is:
 it maps well to the relational model.
 the constructs used in the ER model can easily be transformed
into relational tables.
 it is simple and easy to understand with a minimum amount of
training.
 The model can be used by the database designer to communicate
the design to the end user.
 Basic Constructs of E-R
Modeling
• The ER model views the real world as a construct of
entities and association between entities.
• Entities
• Attributes
• Relationships
 Entities
• Entities are the principal data object about which information is to be
collected.
• Entities are usually recognizable concepts, either concrete or abstract,
such as person, places, things, or events which have relevance to the
database.
• Entity set is a collection of similar types of entities.
• An entity set may contain entities with attributes sharing similar values.
• Examples are EMPLOYEES, PROJECTS, INVOICES.
• An entity is analogous to a table in the relational model.
 Entities Contd
• An entity is analogous to a table in the relational model.
• Entities are classified as independent or dependent (in some
methodologies, the terms used are strong and weak,
respectively).
• An independent entity is one that does not rely on another
for identification.
• A dependent entity is one that relies on another for
identification.
 Entities Contd – Entity
Occurence
• Entity Occurrence: An entity occurrence (also called an instance) is
an individual occurrence of an entity.
• An occurrence is analogous to a row in the relational table.
• An instance of an entity is like a specific example:
• Bill Gates is an Employee of Microsoft
• SPAM is a Product
• Greenpeace is an Organization
• Flour is an ingredient
 Attributes
• Describe the entity of which they are associated.
• A particular instance of an attribute is a value.
• For example, “OO Popoola" is one value of the attribute Name.
• The domain of an attribute is the collection of all possible values an
attribute can have. The domain of Name is a character string.
• Attributes can be classified as identifiers or descriptors.
• Identifiers, more commonly called keys, uniquely identifies an
instance of an entity.
• Descriptor describes a non-unique characteristic of an entity instance.
 Attributes Contd
• Attributes of entity PRODUCT might include:

ProductID

Product_Description

Weight

Size

Cost
 Attributes Contd
• A particular instance of an attribute is a value.
• For example, "Chukwudi R. Nnanna" is one value of the attribute Name.
• Identifier is a special attribute used to identify a specific instance of an
entity.
• Typically we look for unique identifiers:
• Personal File Number uniquely identifies an EMPLOYEE
• CustomerID uniquely identifies a CUSTOMER
• We can also use two attributes to indicate an identifier:
• ORDER_NUMBER and LINE_ITEM uniquely identify an item on an order.
 Relationships
• Represents an association between two or more entities.
• Relationships can be thought of as VERBS, linking two or more nouns.
• An example of a relationship would be:
• Employees are assigned to projects
• Projects have subtasks
• Departments manage one or more projects
• Relationships are classified in terms of degree, connectivity, cardinality, and
existence.
• Example: an owns relationship between a company and a computer; a supervises
relationship between an employee and a department.
 24
Classifying Relationships
 Classified by:
i. degree,
ii. connectivity,
iii. cardinality,
iv. direction,
v. and existence
 Not all modeling methodologies use all these classifications.
 25
1. Degree of Relationships
 The number of entities associated with the relationship.
 The general form is n-ary relationship is the where the degree is n.
 Binary, and ternary ,where the degree is 2, and 3, respectively.
 Binary relationships, the association between two entities is the most common type in
the real world.
 A recursive relationship or unary relationship occurs when an entity is related to itself.
 Example might be "some employees are married to other employees".
 Ternary relationship involves three entities and is used when a binary relationship is
inadequate.
 Many modeling approaches recognize only binary relationships.
 Ternary or n-ary relationships are decomposed into two or more binary relationships.
 26
Examples of degree of relationship
1. Unary relationship – only one entity
 An employee manages employees
2. Binary relationship – two entities involved
 A student registers for a course
3. Tenary relationship – three entities involved
 Vehicle parts are supplied by a vendor to a given warehouse
 27
2. Connectivity and Cardinality

 Connectivity of a relationship describes the mapping of associated

entity instances in the relationship.
 The values of connectivity are "one" or "many".
 Cardinality of a relationship is the actual number of related
occurrences for each of the two entities.
 The basic types of connectivity for relations are: one-to-one, one-to-
many, and many-to-many.
 28
Connectivity: one-to-one (1:1)

 One-to-one (1:1) relationship is when at most one instance of a

entity A is associated with one instance of entity B.
 For example,
 “Employees in the company are each assigned their own office.”
 For each employee there exists a unique office and for each office
there exists a unique employee.
 29
Connectivity: one-to-many (1:N)

 One-to-many (1:N) relationships is when for one instance of entity A,

there are zero, one, or many instances of entity B, but for one
instance of entity B, there is only one instance of entity A.
 Example:
 “A department has many employees”
 “Each employee is assigned to one department”
 30
Connectivity: many-to-many (N:M)
 A many-to-many (M:N) relationship is when for one instance of entity A, there are
zero, one, or many instances of entity B and for one instance of entity B there are
zero, one, or many instances of entity A.
One entity from A can be associated with more than one entity from B and vice versa.
An example is:
 “Employees can be assigned to no more than two projects at the same time;
projects must have assigned at least three employees.”
 A single employee can be assigned to many projects; conversely, a single project
can have assigned to it many employees.
 Cardinality between employees and projects is 2
 Cardinality between projects and employees is 3
 31
One – to – One, One – to – Many and Many – to – Many
Mapping

One-to-One One-to-Many Many-to-Many

 32
3. Direction
 The direction of a relationship indicates the originating entity of a binary
relationship.
 The entity from which a relationship originates is the parent entity; the
entity where the relationship terminates is the child entity.
 The direction of a relationship is determined by its connectivity.
 In a one-to-one relationship the direction is from the independent entity
to a dependent entity. If both entities are independent, the direction is
arbitrary.
 With one-to-many relationships, the entity occurring once is the parent.
 The direction of many-to-many relationships is arbitrary.
 Conclusion
• A data model is a plan for building a database.
• To be effective, it must be simple enough to communicate
to the end user the data structure required by the
database yet detailed enough for the database designer to
use to create the physical structure.
• The Entity-Relationship Model is a conceptual data model
that views the real world as consisting of entities and
relationships.
• The model visually represents these concepts by the
Entity-Relationship diagram.
 Conclusion
• The basic constructs of the ER model are entities,
relationships, and attributes.
• Entities are concepts, real or abstract, about which
information is collected.