Identify Physical Database Requirements

VICTORY COLLEGE
Under
ETHIOPIAN TVET-SYSTEM
DATABASE ADMINISTRATION
LEVEL III
LEARNING GUIDE # 02
Unit of Competence: Identify Physical Database Requirements
Module Title: Identify Physical Database Requirements
LEARNING OUTCOME:
LO1: Identify database scope
LO2: Identify database requirements
LO3: Identify security requirements
LO4: Seek Client feedback and approval
I Prepared By: Masresha T…

Learning Outcome 1: Identify Database scope
Inside this reading

LO1. Identify database scope ....................................................................................................................... 1
1.1 Reviewing system architecture and user requirements ................................................................. 2
User Requirements.............................................................................................................................. 2
System Architectures .......................................................................................................................... 3
1.1.1 Operating System ....................................................................................................................... 5
1.1.2 DBMS Software .......................................................................................................................... 6
1.1.3 Configuration: small and large memory model ...................................................................... 9
1.2 Determining Database size and technical specifications.............................................................. 11
1.3 Documenting Database and scope of project ................................................................................ 11
1.4 Evaluating Several database management systems and making appropriate selection ........... 11
II Prepared By: Masresha T…

LO1. Identify database scope
A database is a collection of information related to a particular subject or purpose (e.g., tracking customer
orders or maintaining a music collection). If your database isn't stored on a computer, or only parts of it are,
you may be tracking information from a variety of sources that you have to coordinate and organize yourself.
Database design is the process of coming up with different kinds of specification for the data to be stored in
the database. Design is the part on which we would be engaged to describe how the data should be perceived
at different levels and finally how it is going to be stored in a computer system. Database design classified
into: -
1. Conceptual Design
It is the process of constructing of a model of the information used in an enterprise.
2. Logical Design
It is a process of constructing a model of the information used in an enterprise based on a specific data
model (e.g relational hierarchy or network or project).
3. Physical Design
It is the process of producing a description of the implementation of the database on secondary storage.
Defines specific storage or access methods used by database
Scope is the range of one's perceptions, thoughts, or actions
- The purpose of defining the scope is to define the boundary of the system and the project.
- The scope shows what aspects of the system will and will not be included in the project.
A good database is one that is simple to understand and well planned.
One can use ERDs (Entity-Relationship Diagrams) or EERDs (Enhanced-Entity Relationship Diagrams) in order
to make a good database.
~1~ Prepared By: Masresha T…

The Scope of Good Database Design:
➢ Easy to locate the data.

➢ No redundant data (No repeated).
➢ More security.
➢ Table references (keys like: Primary and foreign keys) are easy to maintain.
1.1 Reviewing system architecture and user requirements

User requirements, often referred to as user needs, describe what the user does with the system, such as what
activities that users must be able to perform. ... System requirements are the building blocks developers use
to build the system
User Requirements
From the model of system components in our generic system, the user component is at the highest layer. The
term user represents primarily the end users of the system, but it can be expanded to include everyone involved
in the system, such as network and system administrators and management. User requirements is the set of
requirements gathered or derived from user input and is what is needed by users to successfully accomplish
their tasks on the system. Typically, when gathering requirements, everyone involved with that network is
considered a potential user. Figure 2.2 shows some example user requirements.
Figure 1: Types of user requirements.
We begin describing requirements at this layer, which will lead to the development of more specific
requirements as we work through each of the components.
From the user perspective, we can ask, "What does it take to get the job done?" This will usually result in a
set of qualitative, not quantitative, requirements. Part of our job in gathering and deriving user requirements
is to make them quantitative whenever possible.

In general, the system should adapt to users and their environments, provide quick and reliable information
access and transfer, and offer quality service to the user. This indicates the following general requirements:
System Architectures
System architecture encompasses decisions as to where to place specific software components. Should certain
components be placed on the same server or on different machines? Enterprises may have a specific high-
speed processing server or high-end reliable storage facility that they’ll want to leverage for specific
components. These decisions will lead to different types of architectural organizations. We can broadly
categorize them into centralized and decentralized organizations.
1. Centralized Organizations: Client-Server Systems
A server is a process implementing a specific service (e.g. database service). The client is a process requesting
that service from a server. The client sends the request and waits for the reply (request-reply behavior). Where
these processes are physically distributed will lead to different multitiered architectural styles.
Remember the three layers discussed above (interface, processing, data layer)? While we distinguish between
three logical levels, there are several ways to physically distribute a client-server application across machines.
The simplest organization is using two types of machines: 1) a client machine with the user interface (layer
one), and 2) the server interface containing the program implementing the process and the data (layers two
and three). In this case, everything is handled by the server while the client is nothing more than a dumb
terminal. This is called a (physically) two-tiered architecture. However, there are other ways to separate
these three layers on two machines. Possibilities range between separation, as mentioned above, to having
everything, except the stored data, running on the client machine. You can see these different variations in the
graphic below.

Figure 2: Variations of physically two-tiered three-layered architectures.
In (physically) three-tiered architectures, one of the servers also has to act as a client. The application is
spread across three machines, one client and two servers. One of the servers may need input from the other
server to process the client request, acting as a client.
Figure 3: Three-tier architecture: one client and two servers with the app server also acting as a client.
Multitiered client-server architectures are a direct consequence of dividing distributed applications into a user
interface, processing components, and data-management components. Different tiers correspond directly with
the logical organization of applications (software architecture corresponds to system architecture). This is
called vertical distribution in which logically different components are placed on different machines. This
allows for each machine to be tailored to a specific function, for example, placing the processing layer on a
high-end processing server.

2. Decentralized Organization: Peer-to-Peer Systems
In modern architectures, clients and servers themselves are distributed, in so-called horizontal distribution.
A client or server may be physically split, but each part operates on its own share of complete data thus
balancing the load. So, instead of having one data store all components have access to, potentially turning into
a bottleneck, each component has its own dataset. These are called peer-to-peer systems. Each process acts
as client and server at the same time, often referred to as servant.
Peer-to-peer architectures evolve around the question of how to organize processes in an overlay network —
a network in which nodes are formed by processes and links represent possible communication channels.
Figure 4: Peer-to-peer system network connected via an overlay network.
As we’ve seen, there are multiple ways of organizing applications into logical components (software
architecture considerations). Whether layered, object/service-oriented, REST, or pub/subscribe is the best
approach largely depends on the application. These components are then placed on different physical
machines (system architecture considerations), either in a client-server or peer-to-peer fashion.
1.1.1 Operating System

✓ Operating System is a set of programs that manages computer hardware and various resources
installed on it.
✓ Analyze various operating systems, noting their strengths and limitations with regards to I/O,
processing, and memory
✓ Define the establishment of the network within the operating system and the management of I/O
✓ Explain the operating system support of applications
✓ Explain the configuration parameters of an operating system that affect a database.
✓ Plan and manage physical resource requirements
✓ Analyze limitations of specific operating systems

You have to check the operating system loaded on your machine whether it is compatible with the DBMS software
you want to install or not.
1.1.2 DBMS Software

A database management system stores data, in such a way which is easier to retrieve, manipulate and helps to
produce information.
Characteristics
Traditionally data was organized in file formats. DBMS was all new concepts then and all the research was done
to make it to overcome all the deficiencies in traditional style of data management. Modern DBMS has the
following characteristics:
✓ Real-world entity: Modern DBMS are more realistic and uses real world entities to design its architecture.
It uses the behavior and attributes too. For example, a school database may use student as entity and their
age as their attribute.
✓ Relation-based tables: DBMS allows entities and relations among them to form as tables. This eases the
concept of data saving. A user can understand the architecture of database just by looking at table names
etc.
✓ Isolation of data and application: A database system is entirely different than its data. Where database is
said to active entity, data is said to be passive one on which the database works and organizes. DBMS also
stores metadata which is data about data, to ease its own process.
✓ Less redundancy: DBMS follows rules of normalization, which splits a relation when any of its attributes
is having redundancy in values. Following normalization, which itself is a mathematically rich and
scientific process, make the entire database to contain as less redundancy as possible.
✓ Consistency: DBMS always enjoy the state on consistency where the previous form of data storing
applications like file processing does not guarantee this. Consistency is a state where every relation in
database remains consistent. There exist methods and techniques, which can detect attempt of leaving
database in inconsistent state.
✓ Query Language: DBMS is equipped with query language, which makes it more efficient to retrieve and
manipulate data. A user can apply as many and different filtering options, as he or she wants. Traditionally
it was not possible where file-processing system was used.
✓ ACID Properties: DBMS follows the concepts for ACID properties, which stands for Atomicity,
Consistency, Isolation and Durability. These concepts are applied on transactions, which manipulate data

in database. ACID properties maintain database in healthy state in multi-transactional environment and in
case of failure
✓ Multiuser and Concurrent Access: DBMS support multi-user environment and allows them to access and
manipulate data in parallel. Though there are restrictions on transactions when they attempt to handle
same data item, but users are always unaware of them.
✓ Multiple views: DBMS offers multiples views for different users. A user who is in sales department will
have a different view of database than a person working in production department. This enables user to
have a concentrate view of database according to their requirements.
✓ Security: Features like multiple views offers security at some extent where users are unable to access data
of other users and departments. DBMS offers methods to impose constraints while entering data into
database and retrieving data atlater stage. DBMS offers many different levels of security features, which
enables multiple users to have different view with different features. For example, a user in sales
department cannot see data of purchase department is one thing, additionally howmuch data of sales
department he can see, can also be managed. Because DBMS is not saved on disk as traditional file system
it is very hard for a thief to break the code.
DBMS is used by various users for various purposes. Some may involve in retrieving data and some may
involve in backing it up. Some of them are described as follows:
Figure 5: DBMS users
A database management system is the software that:
. Enables users to define, create, and maintain the database

. Provides controlled access to the database.
. Interacts with the users, application programs, and the database itself.

. Allows users to insert values, retrieve it when needed, update/modify it when necessary, and delete it if
not required from the database.
➢ Each database application has its own specific strength and weakness.
Some of the common database applications include:
• MySQL
• Oracle
• PostgreSQL
• dBASE
• FoxPro
• SQLite
• IBM DB2
• LibreOffice Base
• MariaDB
• Microsoft SQL Server etc.
Database Support Software

- List and reference the documentation of any DBMS utility software available to support the use or
maintenance of the database.
- Describe all support software, including the operating system, directly related to the database,
including name, version, function, and major operating characteristics.
DBMS vs. Flat File
DBMS Flat File Management System
Multi-user access It does not support multi-user access
Design to fulfill the need for small and large businesses It is only limited to smaller DBMS system.
Remove redundancy and Integrity Redundancy and Integrity issues
Expensive. But in the long term Total Cost of Ownership is It's cheaper
cheap
Easy to implement complicated transactions No support for complicated transactions

Types of DBMS
Types of DBMS
Four Types of DBMS systems are:
• Hierarchical database
• Network database
• Relational database
• Object-Oriented database
Hierarchical DBMS
In a Hierarchical database, model data is organized in a tree-like structure. Data is Stored Hierarchically (top
down or bottom up) format. Data is represented using a parent-child relationship. In Hierarchical DBMS
parent may have many children, but children have only one parent.
Network Model
The network database model allows each child to have multiple parents. It helps you to address the need to
model more complex relationships like as the orders/parts many-to-many relationship. In this model, entities
are organized in a graph which can be accessed through several paths.
Relational model
Relational DBMS is the most widely used DBMS model because it is one of the easiest. This model is based
on normalizing data in the rows and columns of the tables. Relational model stored in fixed structures and
manipulated using SQL.
Object-Oriented Model
In Object-oriented Model data stored in the form of objects. The structure which is called classes which
display data within it. It defines a database as a collection of objects which stores both data members values
and operations.

Advantages of DBMS
• DBMS offers a variety of techniques to store & retrieve data

• DBMS serves as an efficient handler to balance the needs of multiple applications using the same data
• Uniform administration procedures for data
• Application programmers never exposed to details of data representation and storage.
• A DBMS uses various powerful functions to store and retrieve data efficiently.
• Offers Data Integrity and Security
• The DBMS implies integrity constraints to get a high level of protection against prohibited access to data.
• A DBMS schedules concurrent access to the data in such a manner that only one user can access the same
data at a time
• Reduced Application Development Time
Disadvantage of DBMS
DBMS may offer plenty of advantages but, it has certain flaws-
• Cost of Hardware and Software of a DBMS is quite high which increases the budget of your organization.
• Most database management systems are often complex systems, so the training for users to use the DBMS
is required.
• In some organizations, all data is integrated into a single database which can be damaged because of
electric failure or database is corrupted on the storage media
• Use of the same program at a time by many users sometimes lead to the loss of some data.
• DBMS can't perform sophisticated calculations
1.1.3 Configuration: small and large memory model

A memory of large size and processor with high speed of data processing might be required to run the DBMS
software.
The Database Configuration utility creates the connection settings that will be used by either the management
server or action server installed on the computer. Only Local Administrators or the user who ran the Database
Configuration utility on the computer can access it. If this file is missing or the permissions have been changed,
the management server or the action server may report errors that a connection to the data store cannot be made.
If you have changed your database settings, such as the port, user account access, or computer where it is installed,
you will need to re-run the Database Configuration utility on the management server and all action servers.

1.2 Determining Database size and technical specifications
Database Size means the amount of data to be stored in the designed system.
- You can specify sizes for data and log file in the definition of a database.
- File Growth: You can specify whether a file will grow in size in the future if necessary.
Example: - Specifying memory size during database Creation
When you design a database, you may have to estimate how large the database will be when filled with data.
Estimating the size of the database can help you determine the hardware configuration you will require to do
the following:
• Achieve the performance required by your applications.
• Guarantee the appropriate physical amount of disk space required to store the data and indexes.
Estimating the size of a database can also help you determine whether the database design needs refining.
1.3 Documenting Database and scope of project
Documenting a database means collecting and analyzing information about the organization to be supported by
the database system, and use this information to identify the requirements for the new database system.
- Before attempting to design a database system, you must first identify the scope and boundary of the
project.
- When defining the system boundary for a database system, we include not only the current user views but
also any known future user views.
1.4 Evaluating Several database management systems and making appropriate selection
Evaluating DBMS software means comparing DBMSs software one from the other to select the appropriate one.
The selection must be based on its feature to create a database, disk space it needs, its strength, its flexibility and
cost.
Qualitative and quantitative analysis of different database management systems (DBMS) have been performed in
order to identify and compare those which address requirements such as public domain licensing, free of charge,
high product support, .NET Entity Framework compatibility, good performance, referential integrity, among
others.
➢ Examples for quantitative analysis; .NET Entity Framework compatibility, cost, license, etc.
➢ Examples for qualitative analysis; good performance, referential integrity, and others.
The various types of database software come with advantages, limitations and optimal uses that prospective
buyers should be aware of before choosing a DBMS.

LO2. Identify database requirements
2.1. Reviewing Technical specifications
Technical specifications are typically written by computer department staff that answers specification questions
such as: - What are the hardware and software requirements to run this system?
(Be sure to specify a minimum of disk space to store the data)
- “What is the compatible operating system for the selected DBMS?"
- "How many tables are included in the database and how are they related?"
- describe the file structure for each table.
2.2. Identifying database tables and relationships
2.2.1 Entity, Entity Set and Entity Type
An entity is an object in the real world with an independent existence that can be differentiated from other
objects. An entity might be
• An object with physical existence (e.g., a lecturer, a student, a car)

• An object with conceptual existence (e.g., a course, a job, a position)
• Entity can be roles, events, tangible things or concepts.
Entities can be classified based on their strength. An entity is considered weak if its tables are existence
dependent.
• That is, it cannot exist without a relationship with another entity

• Its primary key is derived from the primary key of the parent entity
o The Spouse table, in the COMPANY database, is a weak entity because its primary key is
dependent on the Employee table. Without a corresponding employee record, the spouse record
would not exist.
An entity is considered strong if it can exist apart from all of its related entities.
• Kernels are strong entities.

• A table without a foreign key or a table that contains a foreign key that can contain nulls is a strong entity
• Generally in database terms, an entity is a table which is responsible for storing records in the database.
• In E-R Diagram, an entity is represented by a rectangle. Example:

Other terms related to Entity include:
. Entity type
. Entity set
. Entity instance
Entity type is a collection of entities that share common properties or characteristics.
Example: - Student is an entity type to all students.
In E-R Diagram, an entity type is represented by a rectangle, and the name is indicated in capital letters.
Example: DEPARTMENT EMPLOYEE
Entity set is a set of entities (collection of Entities/instances) of the same type.
Example: - a company have many employees, and these employees are defined as entities (e1,e2,e3....) and all
these entities having same attributes are defined under ENTITY TYPE employee.
I.e. Entity set is also called Entity Extension.
Figure 1. ERD with entity type EMPLOYEE.
▪ Entity Instance is a single occurrence of a particular entity type. An entity type is described just one time in
the data model, but many instances of that entity type may be represented by data stored in the database.
Example: - There may be hundreds or thousands of employees in an organization – each one is an instance of the
Employee entity type.
Entity type name EMPLOYEE PROJECT
Attributes name Name, Age, salary Pname, Pcode, Location

e1 P1
One entity instance
(Abebe, 25, 3500) (Database, p001, Bahir
Dar)
e2 One entity instance
P2
(Daniel, 42, 2500)
(Water, P002, Gonder) One entity
Entity set e3
P3 instance
(Aster, 32, 3000)
(Entity
.
Extension)
.
Existence dependency
.
An entity’s existence isendependent on the existence of the related entity. It is existence-dependent if it has a
mandatory foreign key (i.e., a foreign key attribute that cannot be null). For example, in the COMPANY
database, a Spouse entity is existence -dependent on the Employee entity.
Kinds of Entities
You should also be familiar with different kinds of entities including independent entities, dependent entities
and characteristic entities. These are described below.
Independent entities
Independent entities, also referred to as kernels, are the backbone of the database. They are what other tables
are based on. Kernels have the following characteristics:
• They are the building blocks of a database.

• The primary key may be simple or composite.
• The primary key is not a foreign key.
• They do not depend on another entity for their existence.
If we refer back to our COMPANY database, examples of an independent entity include the Customer table,
Employee table or Product table.

Dependent entities
Dependent entities, also referred to as derived entities, depend on other tables for their meaning. These entities
have the following characteristics:
• Dependent entities are used to connect two kernels together.

• They are said to be existence dependent on two or more tables.
• Many to many relationships become associative tables with at least two foreign keys.
• They may contain other attributes.
• The foreign key identifies each associated table.
• There are three options for the primary key:
1. Use a composite of foreign keys of associated tables if unique
2. Use a composite of foreign keys and a qualifying column
3. Create a new simple primary key
Characteristic entities
Characteristic entities provide more information about another table. These entities have the following
characteristics:
• They represent multivalued attributes.

• They describe other entities.
• They typically have a one-to-many relationship.
• The foreign key is used to further identify the characterized table.
• Options for primary key are as follows:
1. Use a composite of foreign key plus a qualifying column
2. Create a new simple primary key. In the COMPANY database, these might include:
▪ Employee (EID, Name, Address, Age, Salary) – EID is the simple primary key.
▪ EmployeePhone (EID, Phone) – EID is part of a composite primary key. Here, EID is also
a foreign key.

Relationships
Relationships are the glue that holds the tables together. They are used to connect related information between
tables.
- The function of relationship is to share data between entities.

- In E-R Diagram, a relationship is represented by a diamond shape.
- Some example of relationships are: - EMPLOYEES works_on PROJECTS

- EMPLOYEES process PAYMENTS
- EMPLOYEES works_for DEPARTEMENT
Relationship strength is based on how the primary key of a related entity is defined. A weak, or non-
identifying, relationship exists if the primary key of the related entity does not contain a primary key
component of the parent entity. Company database examples include:
• Customer(CustID, CustName)
• Order(OrderID, CustID, Date)
A strong, or identifying, relationship exists when the primary key of the related entity contains the primary
key component of the parent entity. Examples include:
• Course(CrsCode, DeptCode, Description)

• Class(CrsCode, Section, ClassTime…)
Types of Relationships
Below are descriptions of the various types of relationships.
One to many (1:M) relationship
A one to many (1:M) relationship should be the norm in any relational database design and is found in all
relational database environments. For example, one department has many employees. Figure 8.7 shows the
relationship of one of these employees to the department.

A one-to-many (1:N) relationship means a record in Table A can relate to zero, one, or many records in Table B.
Many records in Table B can relate to one record in Table A. The potential relationship is what's important; for a
single record in Table A, there might be no related records in Table B, or there might be only one related record,
but there could be many. Look at the following tables about a company's Customers and Orders.
ORDERS
OrderNum CustomerID OrderDate ShipDate Shipper
76654 20151 2/1/00 2/6/00 USPS
74432 20151 6/30/99 7/2/99 Federal Express
75987 20151 11/10/99 11/12/99 UPS
62922 20493 9/5/99 9/6/99 UPS
65745 20493 10/1/99 10/3/99 USPS
72212 20493 4/22/00 4/25/00 UPS
73547 20493 8/17/99 8/20/99 UPS
69211 21570 5/12/99 5/12/99 Federal Express
70343 21587 10/2/00 10/4/00 UPS
72833 21587 12/14/99 12/17/99 UPS
CUSTOMERS
CustomerID CustomerName Address City State Zip
20151 Engel's Books 19 International Dr Ryebrook NY 10273-9764
20493 Jamison Books 396 Apache Ave Fountain Valley CA 92708-4982
20512 Gardening Galore 79 Gessner Pk Houston TX 77024-6261
20688 Books Abound 51 Ulster St Denver CO 80237-3386
20784 Book World 687 Mountain Rd Stowe VT 08276-3196
20926 The Corner Booksotre 36 N.Miller Ave Syracuse NY 13206-4976
20932 Allendale Books 512 Columbia Rd Someville NJ 08876-2987
21570 In Between the Covers 2008 Delta Ave Cincinnati OH 45208-4468
21587 Books and Beyond 51 Windsor St Cambridge MA 02139-2123
21965 Cover to Cover 12 Harbor St Burlington VT 04982-2977
Above, tables with data about customers and orders that have a one-to-many relationship

The Customers table holds a unique record for each customer. Each customer can (and, we hope, does) place
many orders. Many records in the Orders table can relate to only one record in the Customers table. This is a one-
to-many relationship (1:N) between the Customers table and the Orders table.
In a one-to-many relationship, the table on the one side of the relationship is the primary table and the table on
the many side is the related table.
A one-to-many relationship is the most common relationship found between tables in a relational database. The
following is an example of a form used in a database to display the data from two tables with a one-to-many
relationship.
Figure 2. Example of a one to many relationship.
One to one (1:1) relationship
A one to one (1:1) relationship is the relationship of one entity to only one other entity, and vice versa. It
should be rare in any relational database design. In fact, it could indicate that two entities actually belong in
the same table.
An example from the COMPANY database is one employee is associated with one spouse, and one spouse is
associated with one employee.

A one-to-one (1:1) relationship means that each record in Table A relates to one, and only one, record in Table
B, and each record in Table B relates to one, and only one, record in Table A. Look at the following example of
tables from a company's Employees database:
PERSONAL
EmployeeID FirstName LastName Address City State Zip
EN1-10 Carol Schaaf 2306 Palisade Ave. Union City NJ 07087
EN1-12 Gayle Murray 1855 Broadway New York NY 12390
EN1-15 Steve Baranco 742 Forrest St. Kearny NJ 07032
EN1-16 Kristine Racich 416 Bloomfield St. Hoboken NJ 07030
EN1-19 Barbara Zumbo 24 Central Ave. Ritchfield Park NJ 07660
EN1-20 Daniel Gordon 2 Angelique St. Weehawken NJ 07087
EN1-22 Jacqueline Rivet 3600 Bergeline Ave. Union City NJ 07087
EN1-23 Betsy Rosyln 1800 Boulevard East Weehawken NJ 07086
EN1-25 Will Strick 2100 91st St. North Bergen NJ 07047
EN1-26 Susan Shipe 240 Fifth Ave. New York NY 10018
PAYROLL
EmployeeID PayRate
EN1-10 $25.00
EN1-12 $27.50
EN1-15 $20.00
EN1-16 $19.00
EN1-19 $22.75
EN1-20 $23.00
EN1-22 $22.50
EN1-23 $19.50
EN1-25 $12.50
EN1-26 $14.00
Above, tables with a one-to-one relationship from a database of
information about employees

Each record in the Personal table is about one employee. That record relates to one, and only one, record in the
Payroll table. Each record in the Payroll table relates to one, and only one, record in the Personal table. (This is
what looking at it from both directions means.)
In a one-to-one relationship, either table can be considered to be the primary or parent table.
Many to many (M:N) relationships
For a many to many relationship, consider the following points:
• It cannot be implemented as such in the relational model.

• It can be changed into two 1:M relationships.
• It can be implemented by breaking up to produce a set of 1:M relationships.
• It involves the implementation of a composite entity.
• Creates two or more 1:M relationships.
• The composite entity table must contain at least the primary keys of the original tables.
• The linking table contains multiple occurrences of the foreign key values.
• Additional attributes may be assigned as needed.
• It can avoid problems inherent in an M:N relationship by creating a composite entity or bridge entity. For
example, an employee can work on many projects OR a project can have many employees working on it,
depending on the business rules. Or, a student can have many classes and a class can hold many students.
Figure 3 shows another another aspect of the M:N relationship where an employee has different start dates
for different projects. Therefore, we need a JOIN table that contains the EID, Code and StartDate.
Figure 3. Example where employee has different start dates for different projects.
Examine the sample data below. These tables hold data about employees and the projects to which they are
assigned. Each project can involve more than one employee and each employee can be working on more than one
project (the "do more with less" thing). This constitutes a many-to-many (N:N) relationship.
EMPLOYEES
EmployeeID Last Name First Name ProjectNum
EN1-26 O'Brien Sean 30-452-T3
EN1-33 Guya Amy 30-452-T3
EN1-33 Guya Amy 30-482-TC
EN1-33 Guya Amy 31-124-T3
EN1-35 Baranco Steven 30-452-T3
EN1-35 Baranco Steven 31-238-TC
EN1-36 Roslyn Elizabeth 35-152-TC
EN1-38 Schaaf Carol 36-272-TC
EN1-40 Wing Alexandra 31-238-TC
EN1-40 Wing Alexandra 31-241-TC

PROJECTS
ProjectNum ProjectTitle EmployeeID
30-452-T3 Woodworking Around The House EN1-26
30-457-T3 Basic Home Electronics EN1-26
30-482-TC The Complete American Auto Repair Guide EN1-33
31-124-T3 The Sport Of Hang Gliding EN1-26
31-124-T3 The Sport Of Hang Gliding EN1-33
31-238-TC The Complete Baseball Reference EN1-35
31-238-TC The Complete Baseball Reference EN1-35
31-241-TC Improving Your Tennis Game EN1-40
35-152-TC Managing Your Personal Finances EN1-36
36-272-TC Using Electronic Mail Effectively EN1-38
Above, tables with a many-to-many relationship.
Degree of a relationship
The number of entities participating in a relationship is called the degree of the relationship.
Example of mapping an M:N binary relationship type
• For each M:N binary relationship, identify two relations.

• A and B represent two entity types participating in R.
• Create a new relation S to represent R.
• S needs to contain the PKs of A and B. These together can be the PK in the S table OR these together with
another simple attribute in the new table R can be the PK.
• The combination of the primary keys (A and B) will make the primary key of S.

Unary relationship (recursive)
A unary relationship, also called recursive, is one in which a relationship exists between occurrences of the
same entity set. In this relationship, the primary and foreign keys are the same, but they represent two entities
with different roles. See Figure 8.9 for an example.
For some entities in a unary relationship, a separate column can be created that refers to the primary key of
the same entity set.
Figure 4. Example of a unary relationship.
Ternary Relationships
A ternary relationship is a relationship type that involves many to many relationships between three tables.
Refer to Figure 5 for an example of mapping a ternary relationship type. Note n-ary means multiple tables in
a relationship. (Remember, N = many.)
• For each n-ary (> 2) relationship, create a new relation to represent the relationship.
• The primary key of the new relation is a combination of the primary keys of the participating entities that
hold the N (many) side.
• In most cases of an n-ary relationship, all the participating entities hold a many side.

Figure 5. Example of a ternary relationship.
2.3. Identifying data dictionary, table attributes and keys

What is data dictionary?
A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit
of programmers and others who need to refer to them.
* In DBMS, a data dictionary is a file that defines the basic organization of a database.
* Most DBMS keep the data dictionary hidden from users to prevent them from accidentally destroying its
contents.
* A data dictionary may contain:
- The definitions of all schema objects in the database (tables, views, indexes, procedures, functions,
triggers, and so on). Example: Name of the tables, field names of each table, Data type of each field,
Length of each field, constraints of each table and field, etc.
• How much space has been allocated for, and is currently used by the schema objects
- Default values for columns (Constraints on data i.e. range of values permitted)
• Integrity constraint information (Constraints that apply to each field, if any)
• Auditing information, such as who has accessed or updated various schema objects
• Privileges and roles each user has been granted (Access Authorization)
- Description of database users, their responsibilities and their access rights.
Simple Example of data dictionary

Table Name Column Name Data Field constraint Description
type size
EmpID Varchar 15 Primary key Employee identity
Lname Char 15 Last name of employee
Fname Char 5 First name of employee
EMPLOYEE Gender Char 6 Male or female
DeptNumber Varchar 10 Foreign key
Pname Char 17
PROJECT Pcode Char 10 Primary key Project identity
DeptNumber varchar 10 Foreign key
Dname Char 20
DEPARTMEN Dnumber Varchar 10 Department identity

T
Data dictionaries do not contain any actual data from the database, only book keeping information for managing
it.
What is an advantage of a Data Dictionary?
When a new user is introduced to the system or a new administrator takes over the system, identifying table
structures and types becomes simpler.
➢ Table attributes
Attributes
Each entity is described by a set of attributes (e.g., Employee = (Name, Address, Birthdate (Age), Salary).
Each attribute has a name, and is associated with an entity and a domain of legal values. However, the
information about attribute domain is not presented on the ERD.

- An attribute is a property that describes an entity.
- Each attribute has a particular value based on the defined data type.
- The set of all possible (allowable) values of an attribute is called attribute domain.
- As a convention, attributes are named with an initial capital letter followed by lowercase letters.
- In E-R Diagram, an attribute can be represented by an ellipse (oval) shape with a line connected it to the
associated entity. Example:
- It can also be represented by listing them within the entity rectangle, under the entity name.
Example: EMPLOYEE
Emp_Id
Fname
Lname
*
In the entity relationship diagram, shown in Figure 6, each attribute is represented by an oval with a name
inside. *
Figure 6. How attributes are represented in an ERD.
Types of Attributes
There are a few types of attributes you need to be familiar with. Some of these are to be left as is, but some
need to be adjusted to facilitate representation in the relational model. This first section will discuss the types
of attributes. Later on we will discuss fixing the attributes to fit correctly into the relational model.

1. Simple (Atomic) vs Composite attribute
Simple attributes are those drawn from the atomic value domains; they are also called single-valued
attributes. In the COMPANY database, an example of this would be: Name = {John} ; Age = {23}
Composite attributes are those that consist of a hierarchy of attributes. Using our database example, and
shown in Figure 8.3, Address may consist of Number, Street and Suburb. So this would be written as →
Address = {59 + ‘Meek Street’ + ‘Kingsford’}
. In E-R Diagram, simple attributes can be represented by an ellipse shape. Example:

. In E-R Diagram, composite attributes can be represented by branched ellipse shape:
Example:
. The value of composite attribute is the concatenation of the values of its constituent simple attributes.
Figure 7. An example of composite attributes.
2. Single-valued vs Multi-valued attributes

Single -valued: have only single value (the value may change but has only one value at one time).
Example: name, sex, Id.no, color of eyes.
Multivalued attributes are attributes that have a set of values for each entity. Have more than one value.

- In E-R Diagram, Multi-valued attributes can be represented by double ellipse (oval) shape.
Example: colour attribute for a car, college degree for a person, address.
Figure 8. Example of a multivalued attribute.
3. Stored vs derived attributes

. In some cases, the value of two or more attributes can be related.
Example: the Age and Birth-Date attributes of a person
-- The Age attribute is derived from the Birth-Date attribute.
-- Age attribute is derived attribute, and the Birth-Date attribute is stored attributed
In E-R Diagram, Derived attributes can be represented by dotted ellipse.
Figure 9. Example of a derived attribute.

4. Null values A null is a special symbol, independent of data type, which means either unknown or
inapplicable. It does not mean zero or blank. Features of null include:
• No data entry
• Not permitted in the primary key
• Should be avoided in other attributes
• Can represent
o An unknown attribute value
o A known, but missing, attribute value
o A “not applicable” condition
• Can create problems when functions such as COUNT, AVERAGE and SUM are used
• Can create logical problems when relational tables are linked
Default value: assumed value if no explicit value.
Keys
An important constraint on an entity is the key. The key is an attribute or a group of attributes whose values
can be used to uniquely identify an individual entity in an entity set.
Types of Keys
There are several types of keys. These are described below.
✓ Types of Keys in Relational Database Model

. Super key
. Candidate key
. Primary key
. Alternate key
. Foreign key
Super Key is an attribute or a composite attribute which functionally determines all of the entity’s attributes.
Since, a super key may contain additional columns that are not necessary for unique identification; we’re
interested in identifying super keys that contain only the minimum number of columns necessary for unique
identification.

Candidate key: is a simple or composite key that is unique and minimal. It is unique because no two rows in a
table may have the same value at any time. It is minimal because every column is necessary in order to attain
uniqueness.
From our COMPANY database example, if the entity is Employee(EID, First Name, Last Name, SIN,
Address, Phone, BirthDate, Salary, DepartmentID), possible candidate keys are:
• EID, SIN
• First Name and Last Name – assuming there is no one else in the company with the same name
• Last Name and DepartmentID – assuming two people with the same last name don’t work in the same
department
Composite key
A composite key is composed of two or more attributes, but it must be minimal.
Using the example from the candidate key section, possible composite keys are:
• First Name and Last Name – assuming there is no one else in the company with the same name
• Last Name and Department ID – assuming two people with the same last name don’t work in the same
department
Primary key
The primary key is a candidate key that is selected by the database designer to be used as an identifying
mechanism for the whole entity set. It must uniquely identify tuples in a table and not be null. The primary
key is indicated in the ER model by underlining the attribute.
• A candidate key is selected by the designer to uniquely identify tuples in a table. It must not be null.
• A key is chosen by the database designer to be used as an identifying mechanism for the whole entity
set. This is referred to as the primary key. This key is indicated by underlining the attribute in the ER
model.

In the following example, EID is the primary key:
Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)
Secondary key
A secondary key is an attribute used strictly for retrieval purposes (can be composite), for example: Phone
and Last Name.
Alternate key
Alternate keys are all candidate keys not chosen as the primary key.
Foreign key
A foreign key (FK) is an attribute in a table that references the primary key in another table OR it can be null.
Both foreign and primary keys must be of the same data type.
In the COMPANY database example below, DepartmentID is the foreign key:
Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)
2.4. Developing database reports using acceptance criteria

What does Database Reports mean?
Database reports are the formatted result of database queries and contain useful data for decision-making and
analysis. Most good business applications contain a built-in reporting tool; this is simply a front-end interface that
calls or runs back-end database queries that are formatted for easy application usage.
For example, a banking software application may contain specifically defined reports on all customers with large
deposits or reports on monthly loan summaries for all customers.
Database reports are developed based on acceptance criteria and requirements.
The reports are normally used to provide hard copy printouts for reviews at meetings or to mark up the information
in your database that needs updating.

LO3. Identify security requirements
3.1 Reviewing system security
Reviewing system security includes:
- Application System security
- Computer System security
- Network system security
- DBMS security
- Financial and business system security
System security means Control of access to a computer system's resources, specially its data and operating system
files.
- It covers access and use of the database at the system level, such as a username and password.
- Application System security

Application system security is the use of software, hardware, and procedural (technical) methods to protect
applications from external threats.
- The most basic software to ensure application security is application firewall that limits the execution of
files or the handling of data by specific installed programs.
- Computer System security
The term computer system security refers to the collective processes and mechanisms by which sensitive and
valuable information and services are protected from publication (unauthorized activities), tampering (corrupting)
or collapse.
- Network system security
Network security is a specialized field in computer networking that involves securing a computer network
infrastructure.
Network security is typically handled by a network administrator or system administrator who implements the
security policy, network software and hardware needed to protect a network and the resources accessed through
the network from unauthorized access and also ensure that employees have adequate access to the network and
resources to work.

3.2 Clarifying and confirming DBMS and user security
Security within the DBMS protects the integrity of the data, records and databases. It can provide
encryption protection at the data level.
Database Security means protection of the: - data from malicious attempts to steal (view) or
modify data.
- Database from unauthorized users.
- Data security covers access and use of database objects (such as tables and views) and the
actions that users can have on the objects.
- User security lets your application use security rules to determine what it shows.
DB security
Data is a valuable entity that must have to be firmly handled and managed as with any economic
resource. So some part or all of the commercial data may have tactical importance to their
respective organization and hence must have to be kept protected and confidential. In this chapter,
you will learn about the scope of database security. There is a range of computer-based controls
that are offered as countermeasures to these threats.
What is Database Security?
Database security is the technique that protects and secures the database against intentional or
accidental threats. Security concerns will be relevant not only to the data resides in an
organization's database: the breaking of security may harm other parts of the system, which
may ultimately affect the database structure. Consequently, database security includes
hardware parts, software parts, human resources, and data. To efficiently do the uses of security
needs appropriate controls, which are distinct in a specific mission and purpose for the system.
The requirement for getting proper security while often having been neglected or overlooked
in the past days; is now more and more thoroughly checked by the different organizations.

We consider database security about the following situations:
• Theft and fraudulent.

• Loss of confidentiality or secrecy.
• Loss of data privacy.
• Loss of data integrity.
• Loss of availability of data.
These listed circumstances mostly signify the areas in which the organization should focus on
reducing the risk that is the chance of incurring loss or damage to data within a database. In
some conditions, these areas are directly related such that an activity that leads to a loss in one
area may also lead to a loss in another since all of the data within an organization are
interconnected.
What is a Threat?
Any situation or event, whether intentionally or incidentally, can cause damage, which can
reflect an adverse effect on the database structure and, consequently, the organization. A threat
may occur by a situation or event involving a person or the action or situations that are probably
to bring harm to an organization and its database.
The degree that an organization undergoes as a result of a threat's following which depends
upon some aspects, such as the existence of countermeasures and contingency plans. Let us
take an example where you have a hardware failure that occurs corrupting secondary storage;
all processing activity must cease until the problem is resolved.
Computer-Based Controls
The different forms of countermeasure to threats on computer systems range from physical
controls to managerial procedures. In spite of the range of computer-based controls that are
preexisting, it is worth noting that, usually, the security of a DBMS is merely as good as that
of the operating system, due to the close association among them.

Most of the computer-based database security are listed below:
• Access authorization.
• Access controls.
• Views.
• Backup and recovery of data.
• Data integrity.
• Encryption of data.
• RAID technology.
What is Access Controls?
The usual way of supplying access controls to a database system is dependent on the granting
and revoking of privileges within the database. A privilege allows a user to create or access
some database object or to run some specific DBMS utilities. Privileges are granted users to
achieve the tasks required for those jobs.
The database provides various types of access controls:
• Discretionary Access Control (DAC)

• Mandatory Access Control (MAC)
3.3 Identifying, evaluating and recording DB performance recovery and audit trails.
What is auditing?
Auditing is the monitoring and recording of selected user database actions.
Database performance can be defined as the optimization of resource use to increase throughput
and minimize contention, enabling the largest possible workload to be processed.
Database Recovery is responsible for preserving the database consistency after a failure of any
kind (transaction, system or media). Relevant information solely for recovery is saved in a log
during normal transaction processing.

Every Database Management System should offer backup facilities to help with the recovery of a
database after a failure. It is always suitable to make backup copies of the database and log files at
the regular period and for ensuring that the copies are in a secure location. In the event of a failure
that renders the database unusable, the backup copy and the details captured in the log file are used
to restore the database to the latest possible consistent state.
Recovery performance focuses primarily on crash recovery rather than on recovery after
restoring a backup. However, optimizations are possible for recovery after restoring from a
backup.
An audit trail (or audit log) is a record showing who has accessed a computer system and
what operations he or she has performed during a given period of time. Audit trails are useful
both for maintaining security and for recovering lost transactions.
Most accounting systems and database management systems include an audit trail component.
In addition, there are separate audit trail software products that enable network administrators
to monitor use of network resources.
Database auditing involves observing a database so as to be aware of the actions of database

users.
Database administrators and consultants often set up auditing for security purposes.

LO4. Seek Client feedback and approval
• Presenting DB scope and technical requirements to user for feedback
Present database scope, technical requirements and security documentation to user for feedback
is very important to develop a successful database.
. Review user feedback and adjust database as required
. Present database and documentation to user for final approval
What is feedback?
Feedback is a Process in which the effect or output of an action is 'returned' to modify the next
action.
• Reviewing user feedback to adjust DB.

• Presenting DB and documentation to user for final approval
There are two main approaches to improving the effectiveness of database interfaces. One is to
raise the level of abstraction for the content of the user-database interaction. The relational model
belonging to the logical level has replaced the hierarchical and network models that belong to the
lower physical level. It is likely that the relational model will eventually be replaced by models
belonging to the even higher conceptual level, such as entity relationship models and object-
oriented models. The second approach is to enhance the actual interaction process. This can be
done by providing better feedback to the user. Feedback can be in the form of more comprehensible
error messages, and the provision of a natural language interpretation of user's query. Such a
feedback system was developed, and its effectiveness tested in an experiment. The results showed
that the feedback system enhanced user performance greatly. Specifically, users who used the
feedback system were 12.9% more accurate than those without the feedback system. They were
also 41.2% more confident of their answers, and they took 29.0% less time than those without the
feedback system

Analyse feedback
1. Analyse all feedback
This may sound obvious, but it is vital that you actually analyse all the feedback you get –
otherwise why bother collecting it in the first place!
Whilst some feedback may give fairly standard or unremarkable details (which will also be useful
– see the section below on trends), some may contain information that could potentially be a major
breakthrough for your business.
2. Categorize (and sub-categorize) feedback
You will find rapidly that feedback will start to fall into more general categories – these could
include the speed of your service (or lack of), accuracy, courtesy and helpfulness of particular
staff, price and choice of products, availability or location etc.
Sorting feedback into categories will immediately help to show a wider picture of how the
customer views your business and services. Of course some customers may comment on a number
of categories and you can file these accordingly.
You will probably find that sub-categories are also very useful. This will help to highlight the less
noticeable elements of your business operations, which could actually prove to be very significant
to your overall proposition. Often these ‘hidden’ elements are the ones that are significantly
pleasing or annoying your customers and website visitors.
3. Use negative and positive feedback
Inevitably feedback will range from complaints to (hopefully) high praise! It makes sense to divide
the results using these criteria, as your response to each will vary greatly. It is worth pointing out
at this juncture that positive comments are just as valuable as complaints because they show you
what pleases and excites your repeat customers. Compliments will also motivate your team and
thanking customers for positive feedback helps to build customer loyalty.
In a similar way, negative comments will highlight why customers leave and go to your
competitors. You need to close the loop and resolve these problems – this is a well proven way of
retaining more business. In both cases, your business will improve and thrive by reacting positively
to feedback.
Try Email Campaign Feedback
Start delivering email messages your audience craves with Mopinion for Email.
4. Look at root causes
Naturally you need to understand what is driving customer loyalty if you want to improve it and
customer feedback will help you to do this. Therefore, it is useful to make the analysis of root
causes a priority above settling more complex or niche problems reported by your customers.
To achieve this, it is vital to have a management system in place which will qualify feedback and
help you search through potentially large amounts of data. You also need to be able to determine
the data which will help identify root causes of issues, before you move onto more complex (and
sometimes niche) problems that will result from these.
5. Understand the value of the customer
All customers are valuable to your business, but some are more valuable than others! It is important
to understand the value of a customer/group of customers so you can prioritise changes to your
sales funnel or customer management regime.

For example, some customers may only buy from you during a sale whilst more loyal customers
will continue to buy from you on an ongoing basis. Obviously repeat customers are more important
to your revenue than those which ‘cherry pick’ certain deals, so it makes sense to prioritise the
‘voice’ of customers that come back to you again and again.
This also applies to making a business case for internal changes. For example, if you want to invest
in schemes designed to drive up customer loyalty you need to be aware of how much this will be
worth to your business compared to the cost of implementing it (investment cost Vs return on
investment) to ensure it is worthwhile.
6. Look for trends
Of all the criteria you use to analyse customer feedback, identifying trends is one of the most
important. Trends will show where you are getting things right or wrong and will become even
more important when your volume of feedback increases.
Looking at individual feedback, you might find particularly strong opinions or complaints.
However, these need to be seen in the context of your overall sales. For example, one customer
may have a terrible experience with a product you have sold them, but then the rest of the
customers who have bought the same item may give a glowing review.
Looking at longer term trends can also help to ascertain if you have a statistical aberration or a
genuine trend that needs to be addressed. If a trend rises or decreases on a regular basis you can
be fairly certain this is an important factor that will need to be focussed upon – be that a negative
or a positive.

7. Don’t compare unrelated data
You may have an urge to compare different geographies, completely separate parts of the business
or different survey results – but this can be very misleading. Taking results out of context (even if
they may seem related) can offer a very distorted view.
For example, customers in different regions or countries can be notoriously different to those in
other parts of the world (through cultural or lifestyle difference etc.) Some markets may be stronger
than others, which can be for a number of different reasons and not necessarily down to the quality
or availability of your products or services. Each sector or region needs to be seen in its wider
complex and the feedback data considered with this in mind.
8. Alert the right teams and individuals within your organisation
With all the insights from your collected feedback it is important to ensure everyone involved with
customer service and support is aware of the results.
Be it pricing issues, quality of products, logistical issues or website problems – the appropriate
managers need to be made aware so they can carry out the right actions (even if this is to continue
doing the right things!) Equally, customer-facing teams will be well-informed to help potentially
frustrated customer with known queries.
9. Consolidate results and determine a plan of action
Once you have sorted through and understand the feedback results it is time to put together a
feasible and effective plan of action to address any issues.
You also need to ensure that the parts of your service which work well and have had positive
feedback continue to do this going forward. When you are addressing issues it can be easy to
disrupt the parts of the process that work well, so you need to be aware of this.

10. Use automated tools to reduce your workload
Hopefully your feedback process will prove to be popular with your customers and generate a high
volume of results. This is a ‘nice problem’ to have, but you might consider using specialised and
automated tools to help you make sense of it, such as text and sentiment analysis. This will identify
which words are used most and in which combinations, along with whether feedback is positive,
neutral or negative.
Automatic learning systems are the next step for analysing feedback. These use machine learning
to automatically assign feedback to the right category and ascertain which feedback is useful,
depending on your chosen criteria. This offers a truly powerful and accurate way of assessing
feedback, yet reduces the hours required by your team to do so.

Identify Physical Database Requirements

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Identify Physical Database Requirements

Uploaded by

Copyright:

Available Formats

VICTORY COLLEGE

Module Title: Identify Physical Database Requirements

LO2: Identify database requirements

LO3: Identify security requirements

LO4: Seek Client feedback and approval

I Prepared By: Masresha T…

Inside this reading

1.1 Reviewing system architecture and user requirements ................................................................. 2

System Architectures .......................................................................................................................... 3

1.1.1 Operating System ....................................................................................................................... 5

1.1.2 DBMS Software .......................................................................................................................... 6

1.1.3 Configuration: small and large memory model ...................................................................... 9

1.2 Determining Database size and technical specifications.............................................................. 11

1.3 Documenting Database and scope of project ................................................................................ 11

II Prepared By: Masresha T…

It is the process of constructing of a model of the information used in an enterprise.

Scope is the range of one's perceptions, thoughts, or actions

A good database is one that is simple to understand and well planned.

~1~ Prepared By: Masresha T…

➢ Easy to locate the data.

1.1 Reviewing system architecture and user requirements

Figure 1: Types of user requirements.

~2~ Prepared By: Masresha T…

1. Centralized Organizations: Client-Server Systems

~3~ Prepared By: Masresha T…

~4~ Prepared By: Masresha T…

Figure 4: Peer-to-peer system network connected via an overlay network.

1.1.1 Operating System

~5~ Prepared By: Masresha T…

1.1.2 DBMS Software

~6~ Prepared By: Masresha T…

Figure 5: DBMS users

A database management system is the software that:

. Enables users to define, create, and maintain the database

~7~ Prepared By: Masresha T…

Database Support Software

~8~ Prepared By: Masresha T…

Four Types of DBMS systems are:

~9~ Prepared By: Masresha T…

• DBMS offers a variety of techniques to store & retrieve data

DBMS may offer plenty of advantages but, it has certain flaws-

1.1.3 Configuration: small and large memory model

~10~ Prepared By: Masresha T…

~11~ Prepared By: Masresha T…

• An object with physical existence (e.g., a lecturer, a student, a car)

• That is, it cannot exist without a relationship with another entity

• Kernels are strong entities.

~12~ Prepared By: Masresha T…

Example: - Student is an entity type to all students.

Example: DEPARTMENT EMPLOYEE

Entity set is a set of entities (collection of Entities/instances) of the same type.

I.e. Entity set is also called Entity Extension.

Figure 1. ERD with entity type EMPLOYEE.

Entity type name EMPLOYEE PROJECT

Attributes name Name, Age, salary Pname, Pcode, Location

~13~ Prepared By: Masresha T…

• They are the building blocks of a database.

~14~ Prepared By: Masresha T…

• Dependent entities are used to connect two kernels together.

• They represent multivalued attributes.

~15~ Prepared By: Masresha T…

- The function of relationship is to share data between entities.

- Some example of relationships are: - EMPLOYEES works_on PROJECTS

- EMPLOYEES works_for DEPARTEMENT