I.

Introduct
II. Theorary
1. What is a database?

- A database is an organized collection of structured information, or data, typically

stored electronically in a computer system. A database is usually controlled by
a database management system (DBMS). Together, the data and the DBMS, along
with the applications that are associated with them, are referred to as a database
system, often shortened to just database.
Data within the most common types of databases in operation today is typically
modeled in rows and columns in a series of tables to make processing and data
querying efficient. The data can then be easily accessed, managed, modified, updated,
controlled, and organized. Most databases use structured query language (SQL) for
writing and querying data.
- A database should be a repository of data needed for an organization's data
processing. That data should be accurate, private, and protected from damage. It
should be accurate so that diverse applications with different data requirements can
employ the data. Different application programmers and various end-users have
different views upon data, which must be derived from a common overall data
structure. Their methods of searching and accessing of data will be different.
- The role and importance of databases:

+ Database is a very important criteria for patient’s disease analysis

+ It includes patients area of care, administration, reseaech and education.

+ These can be used for local assessment and how to trear a particular disease and how to
improve patient health

+ Database can be used to study about epidemiological studies of disease particularly for
a disease as to which it spreads and also decreasing the particular emerging disease.

+ These database is also used for the Medicare provider Analysis and review database
and also for national rurvery.

+ These database about particular disease is to increase knowledge about that disease and
also forms the care and ciricullam plans about that disease

+ For this prupose database is used in improving patient care.

+ Types of databases
There are many different types of databases. The best database for a specific organization
depends on how the organization intends to use the data.

Relational databases
 Relational databases became dominant in the 1980s. Items in a relational database
are organized as a set of tables with columns and rows. Relational database
technology provides the most efficient and flexible way to access structured
information.

Object-oriented databases
 Information in an object-oriented database is represented in the form of objects, as
in object-oriented programming.

Distributed databases
 A distributed database consists of two or more files located in different sites. The
database may be stored on multiple computers, located in the same physical
location, or scattered over different networks.

Data warehouses
 A central repository for data, a data warehouse is a type of database specifically
designed for fast query and analysis.

NoSQL databases
 A NoSQL, or nonrelational database, allows unstructured and semistructured data
to be stored and manipulated (in contrast to a relational database, which defines
how all data inserted into the database must be composed). NoSQL databases grew
popular as web applications became more common and more complex.

Graph databases
 A graph database stores data in terms of entities and the relationships between
entities.
 OLTP databases. An OLTP database is a speedy, analytic database designed for
large numbers of transactions performed by multiple users.
These are only a few of the several dozen types of databases in use today. Other, less
common databases are tailored to very specific scientific, financial, or other functions. In
addition to the different database types, changes in technology development approaches
and dramatic advances such as the cloud and automation are propelling databases in
entirely new directions. Some of the latest databases include
 Open source databases
 An open source database system is one whose source code is open source; such
databases could be SQL or NoSQL databases.

Cloud databases
 A cloud database is a collection of data, either structured or unstructured, that
resides on a private, public, or hybrid cloud computing platform. There are two
types of cloud database models: traditional and database as a service (DBaaS).
With DBaaS, administrative tasks and maintenance are performed by a service
provider.

Multimodel database
 Multimodel databases combine different types of database models into a single,
integrated back end. This means they can accommodate various data types.

Document/JSON database
 Designed for storing, retrieving, and managing document-oriented
information, document databases are a modern way to store data in JSON format
rather than rows and columns.

Self-driving databases
 The newest and most groundbreaking type of database, self-driving databases (also
known as autonomous databases) are cloud-based and use machine learning to
automate database tuning, security, backups, updates, and other routine
management tasks traditionally performed by database administrators.

2. Base de datos relacional

- A database management system (DBMS) is a "software system that enables users
to define, create, maintain, and control access to a database". RDBMS is an
extension of the word Abbreviations are sometimes used when the underlying
database is relational.

Another definition for a relational database management system is a database

management system (DBMS) based on the relational model. Most of the
databases widely used today are based on this model.
- Table
It is the primary component of RDMS. A relational database may constitute one or more
tables related together. It is a combination of rows and columns where rows represent
different entries in the database and column represents the features or attributes of those
entries. Each table has a unique name in RDBMS and a primary key to uniquely identify
the entry. These entries are also called entities of the table.
Records
Each row of the table is a record of the single entity. This contains all the information
about the entity and all its corresponding values to all the attributes of the particular
entity. Each record in the table is called a tuple. For example: If we have an employee
table with records of five employees, then each horizontal row with all detail of the
particular employee is a Record.
Field or Column Name
Each column of a table represents a unique attribute of the entity. No two column names
can be the same. They describe various attributes and features of the entity. For example:
In the employee table there can be various attributes like employee name, employee_id
and various other details.
Domain
It is a constraint on the entry of the value in the field of the table. It describes the set of
values that can be accepted as valid inputs in the particular column. For example: In the
Employee_phone_number this field will only accept a ten-digit integer number. The
domain for various attributes can be specified by the user while creating the table. Any
value that lies outside this set of values will not be accepted and an error will be thrown
when such value is entered.

3. Entity-relationship diagram (ERD)

- ERD stands for entity relationship diagram. People also call these types of diagrams
ER diagrams and Entity Relationship Models. An ERD visualizes the relationships
between entities like people, things, or concepts in a database. An ERD will also often
visualize the attributes of these entities.
By defining the entities, their attributes, and showing the relationships between
them, an ER diagram can illustrate the logical structure of databases. This is useful
for engineers hoping to either document a database as it exists or sketch out a
design of a new database.

- An ER diagram can help businesses document existing databases and thereby

troubleshoot logic or deployment problems or spot inefficiencies and help improve
processes when a business wants to undertake business process re-engineering. ERDs
can also be used to design and model new databases and make sure that engineers can
identify any logic or design flaws before they're implemented in production.

 Document an existing database structure

 Debug, troubleshoot, and analyze
 Design a new database
 Gather design requirements
 Business process re-engineering (BPR)
When documenting a system or process, looking at the system in multiple ways increases
the understanding of that system. ERD diagrams are commonly used in conjunction with
a data flow diagram to display the contents of a data store. They help us to visualize how
data is connected in a general way, and are particularly useful for constructing a relational
database
- Elements of an entity-relationship diagram:
+ An entity is any singular, identifiable and separate object. It refers to
individuals, organizations, systems, bits of data or even distinct system components that
are considered significant in and of themselves.

+ The term is used in a number of programming languages/concepts, database

management, systems design and other arenas.

+ Included and excluded properties

By convention, all public properties with a getter and a setter will be included in the
model.

Specific properties can be excluded as follows:

 Data Annotations
 Fluent API
C#Copy
public class Blog
{
public int BlogId { get; set; }
public string Url { get; set; }

[NotMapped]
public DateTime LoadedFromDatabase { get; set; }
}
Column names

By convention, when using a relational database, entity properties are mapped to table
columns having the same name as the property.

If you prefer to configure your columns with different names, you can do so as following
code snippet:

 Data Annotations
 Fluent API
C#Copy
public class Blog
{
[Column("blog_id")]
public int BlogId { get; set; }

public string Url { get; set; }

}
Column data types

When using a relational database, the database provider selects a data type based on
the .NET type of the property. It also takes into account other metadata, such as the
configured maximum length, whether the property is part of a primary key, etc.

For example, SQL Server maps DateTime properties to datetime2(7) columns,

and string properties to nvarchar(max) columns (or to nvarchar(450) for properties that
are used as a key).

You can also configure your columns to specify an exact data type for a column. For
example, the following code configures Url as a non-unicode string with maximum
length of 200 and Rating as decimal with precision of 5 and scale of 2:

 Data Annotations
 Fluent API
C#Copy
public class Blog
{
public int BlogId { get; set; }

[Column(TypeName = "varchar(200)")]
public string Url { get; set; }

[Column(TypeName = "decimal(5, 2)")]

public decimal Rating { get; set; }
}
Maximum length

Configuring a maximum length provides a hint to the database provider about the
appropriate column data type to choose for a given property. Maximum length only
applies to array data types, such as string and byte[].
 Note

Entity Framework does not do any validation of maximum length before passing data to
the provider. It is up to the provider or data store to validate if appropriate. For example,
when targeting SQL Server, exceeding the maximum length will result in an exception as
the data type of the underlying column will not allow excess data to be stored.

In the following example, configuring a maximum length of 500 will cause a column of
type nvarchar(500) to be created on SQL Server:

 Data Annotations
 Fluent API
C#Copy
public class Blog
{
public int BlogId { get; set; }

[MaxLength(500)]
public string Url { get; set; }
}
Precision and Scale

Some relational data types support the precision and scale facets; these control what
values can be stored, and how much storage is needed for the column. Which data types
support precision and scale is database-dependent, but in most
databases decimal and DateTime types do support these facets. For decimal properties,
precision defines the maximum number of digits needed to express any value the column
will contain, and scale defines the maximum number of decimal places needed.
For DateTime properties, precision defines the maximum number of digits needed to
express fractions of seconds, and scale is not used.

 Note

Entity Framework does not do any validation of precision or scale before passing data to
the provider. It is up to the provider or data store to validate as appropriate. For example,
when targeting SQL Server, a column of data type datetime does not allow the precision
to be set, whereas a datetime2 one can have precision between 0 and 7 inclusive.

In the following example, configuring the Score property to have precision 14 and scale 2

will cause a column of type decimal(14,2) to be created on SQL Server, and configuring
the LastUpdated property to have precision 3 will cause a column of type datetime2(3):
  Data Annotations
 Fluent API
 Note

The Data Annotation for configuring precision and scale was introduced in EF Core 6.0.

C#Copy
public class Blog
{
public int BlogId { get; set; }
[Precision(14, 2)]
public decimal Score { get; set; }
[Precision(3)]
public DateTime LastUpdated { get; set; }
}

Scale is never defined without first defining precision, so the Data Annotation for
defining the scale is [Precision(precision, scale)].

Unicode

In some relational databases, different types exist to represent Unicode and non-Unicode
text data. For example, in SQL Server, nvarchar(x) is used to represent Unicode data in
UTF-16, while varchar(x) is used to represent non-Unicode data (but see the notes
on SQL Server UTF-8 support). For databases which don't support this concept,
configuring this has no effect.

Text properties are configured as Unicode by default. You can configure a column as
non-Unicode as follows:

 Data Annotations
 Fluent API
 Note

The Data Annotation for configuring Unicode was introduced in EF Core 6.0.

C#Copy
public class Book
{
public int Id { get; set; }
public string Title { get; set; }
 [Unicode(false)]
[MaxLength(22)]
public string Isbn { get; set; }
}
Required and optional properties

A property is considered optional if it is valid for it to contain null. If null is not a valid

value to be assigned to a property then it is considered to be a required property. When
mapping to a relational database schema, required properties are created as non-nullable
columns, and optional properties are created as nullable columns.

Conventions

By convention, a property whose .NET type can contain null will be configured as
optional, whereas properties whose .NET type cannot contain null will be configured as
required. For example, all properties with .NET value types (int, decimal, bool, etc.) are
configured as required, and all properties with nullable .NET value types
(int?, decimal?, bool?, etc.) are configured as optional.

C# 8 introduced a new feature called nullable reference types (NRT), which allows

reference types to be annotated, indicating whether it is valid for them to contain null or
not. This feature is enabled by default in new project templates, but remains disabled in
existing projects unless explicitly opted into. Nullable reference types affect EF Core's
behavior in the following way:

 If nullable reference types are disabled, all properties with .NET reference
types are configured as optional by convention (for example, string).
 If nullable reference types are enabled, properties will be configured based
on the C# nullability of their .NET type: string? will be configured as
optional, but string will be configured as required.

The following example shows an entity type with required and optional properties, with
the nullable reference feature disabled and enabled:

 Without NRT (default)

 With NRT
C#Copy
public class CustomerWithoutNullableReferenceTypes
{
public int Id { get; set; }
 [Required] // Data annotations needed to configure as required
public string FirstName { get; set; }

[Required]
public string LastName { get; set; } // Data annotations needed to configure as required

public string MiddleName { get; set; } // Optional by convention

}

Using nullable reference types is recommended since it flows the nullability expressed in
C# code to EF Core's model and to the database, and obviates the use of the Fluent API
or Data Annotations to express the same concept twice.

 Note

Exercise caution when enabling nullable reference types on an existing project: reference
type properties which were previously configured as optional will now be configured as
required, unless they are explicitly annotated to be nullable. When managing a relational
database schema, this may cause migrations to be generated which alter the database
column's nullability.

For more information on nullable reference types and how to use them with EF Core, see
the dedicated documentation page for this feature.

Explicit configuration

A property that would be optional by convention can be configured to be required as

follows:

 Data Annotations
Fluent API

C#Copy
public class Blog
{
public int BlogId { get; set; }

[Required]
public string Url { get; set; }
}
Column collations
 Note
This feature was introduced in EF Core 5.0.

A collation can be defined on text columns, determining how they are compared and
ordered. For example, the following code snippet configures a SQL Server column to be
case-insensitive:

C#Copy
modelBuilder.Entity<Customer>().Property(c => c.Name)
.UseCollation("SQL_Latin1_General_CP1_CI_AS");

If all columns in a database need to use a certain collation, define the collation at the
database level instead.

General information about EF Core support for collations can be found in the collation
documentation page.

Column comments

You can set an arbitrary text comment that gets set on the database column, allowing you
to document your schema in the database:

 Data Annotations
 Fluent API
 Note

Setting comments via data annotations was introduced in EF Core 5.0.

C#Copy
public class Blog
{
public int BlogId { get; set; }

[Comment("The URL of the blog")]

public string Url { get; set; }
}
Column order
 Note

This feature was introduced in EF Core 6.0.

By default when creating a table with Migrations, EF Core orders primary key columns
first, followed by properties of the entity type and owned types, and finally properties
from base types. You can, however, specify a different column order:

 Data Annotations
Fluent API
C#Copy
public class EntityBase
{
[Column(Order = 0)]
public int Id { get; set; }
}

public class PersonBase : EntityBase

{
[Column(Order = 1)]
public string FirstName { get; set; }

[Column(Order = 2)]
public string LastName { get; set; }
}

public class Employee : PersonBase

{
public string Department { get; set; }
public decimal AnnualSalary { get; set; }
}

The Fluent API can be used to override ordering made with attributes, including
resolving any conflicts when attributes on different properties specify the same order
number.

+ symbols of elements in an entity relationship:

+ some tools to draw ERD:
 =>> so I choose object relationship tool because easy using and easy
operation, can summarize all the content easily.

4. Relational schema
- In databases, relational schema may refer to:

+ A database schema, in the relational paradigm.

+ A (single) relation schema.

+ Database schema. ... The term "schema" refers to the organization of data as

a blueprint of how the database is constructed (divided into database tables in
the case of relational databases). The formal definition of a database schema is
a set of formulas (sentences) called integrity constraints imposed on a database.
-Purpose of relational schema:
+ Table: The primary component of relational schemas is the tables,
which are typically sets of records. Tables are usually subject-based and
each contains a name and data type. The purpose of tables in a relational
database schema is to organize groups of data that developers could
implement in their databases. The number of tables depends on the size of
the project.
+ Attributes: Attributes are the items within each table. Each table has
attributes that define or describe the table's subject. For example, a relational
schema for a bakery might have tables that state ingredients, recipes, types
of baked goods, prices or customer information as attributes. In a relational
database schema, attributes are defining characteristics that determine the
items in a table. These can help further define and connect relationships
between the tables.
+ Relations: Once the relational schema has the right amount of tables, the
developer needs to include relations or connections. Developers often
represent relations by using lines or arrows. The purpose of relations is to
show on the schema how each table connects to one another. The lines or
arrows can show a variety of meanings, such as two attributes being in the
same field.
 + Primary keys: Primary keys are a column or group of columns that
identify fields within tables. Each table has a primary key, which is a unique
identifier for each row. Primary keys have to be different for every field
because a table cannot duplicate rows. The value within the primary key has
to exist (the value cannot be null). It is also important to note that the
developer can only implement one primary key per table.
+ Foreign keys: Foreign keys are also common in relational database
schemas. A foreign key is a column or group of columns that identifies links
between tables. Foreign keys are often primary keys from different tables so
that it's easy to see the connection from one table to the next. The foreign
key is therefore referencing the primary key of a previous table. Unlike
primary keys, foreign keys may have duplicate rows and the values can be
null while still working. Additionally, there can be more than one foreign
key in a table.
- How to convert from ERD to relational schema?
+ Mapping Process:

* Create table for a relationship.

* Add the primary keys of all participating Entities as fields of table with
their respective data types.

* If relationship has any attribute, add each attribute as field of table.

* Declare a primary key composing all the primary keys of participating

entities.

5. Relational database management system( RDBMS)

- A relational database management system (RDBMS) is, as the name suggests,

software that manages a relational database. It is a set of smaller programs designed to
work together, allowing the developer to store, access, and modify data in tables,
transparently and without having to know where the data is physically stored on disk.

You can interact with any relational database management system by using the SQL
programming language. SQL stands for “Structured Query Language”, which allows you
to interrogate structured data stored in tables.

- As mentioned earlier, a relational database management system allows developers to

store and handle data in relational tables.
There are many components that build the core functionality of an RDBMS, each of
which executes specific actions on a database. The diagram below shows some of the
main functionalities an RDBMS provides when you interact with a database.

- Some relational database management systems:

+ Oracle : Oracle is one of the first RDBMS software that many medium
and large organizations use. This software supports various programming
languages and unstructured data. It also functions with other types of
storage, such as cloud, PDF and key-value.
+ MySQL: MySQL is a popular and free open source database that offers
functions for structured data. Many organizations use this in conjunction
with other web systems. This server-side database also allows users to query
the database while receiving a client-side return by using the MySQL client.
Enterprises and other large organizations must obtain a license to use this
database, but developers can enjoy free access.
+ MariaDB: This database server provides users with structured data by
using multiple different platforms and applications such as websites. It often
enhances some of MySQL's capabilities by offering a range of additional
plugins, storage engines and other applications and database tools. These
tools typically allow organizations of varying sizes to use them for a variety
of purposes.
+SQLite: This free, widely used database uses a self-contained, zero-
configuration SQL database engine. Commercial and private organizations
may use it for any purpose. SQLite stores the entire database as a cross-
platform file on a host device and doesn't use a separate server process. It
also has advanced capabilities such as partial indexes and common table
expressions.
 + PostgreSQL: This open-source object-relational database system runs on
most operating systems. Its platforms allow users to develop in-house, web
and commercial software that use relational database management systems.
It manages large scalability and contains a fully relational system catalog in
which users may use multiple schemas.
=>> I choose and using MySQL because it's well known, has a large
community that makes it easy to ask and work with it's free software.
6. Standardized data
- Database normalization or database normalisation (see spelling differences) is the
process of structuring a relational database in accordance with a series of so-
called normal forms in order to reduce data redundancy and improve data integrity. It
was first proposed by British computer scientist Edgar F. Codd as part of
his relational model.
Normalization entails organizing the columns (attributes) and tables (relations)
of a database to ensure that their dependencies are properly enforced by database
integrity constraints. It is accomplished by applying some formal rules either by a
process of synthesis (creating a new database design) or decomposition (improving
an existing database design).

First normal form

 Eliminate repeating groups in individual tables.

 Create a separate table for each set of related data.
 Identify each set of related data with a primary key.

Do not use multiple fields in a single table to store similar data. For example, to track an
inventory item that may come from two possible sources, an inventory record may
contain fields for Vendor Code 1 and Vendor Code 2.

What happens when you add a third vendor? Adding a field is not the answer; it requires
program and table modifications and does not smoothly accommodate a dynamic number
of vendors. Instead, place all vendor information in a separate table called Vendors, then
link inventory to vendors with an item number key, or vendors to inventory with a vendor
code key.

Second normal form

 Create separate tables for sets of values that apply to multiple records.
 Relate these tables with a foreign key.

Records should not depend on anything other than a table's primary key (a compound
key, if necessary). For example, consider a customer's address in an accounting system.
The address is needed by the Customers table, but also by the Orders, Shipping, Invoices,
Accounts Receivable, and Collections tables. Instead of storing the customer's address as
a separate entry in each of these tables, store it in one place, either in the Customers table
or in a separate Addresses table.

Third normal form

 Eliminate fields that do not depend on the key.

Values in a record that are not part of that record's key do not belong in the table. In
general, anytime the contents of a group of fields may apply to more than a single record
in the table, consider placing those fields in a separate table.

For example, in an Employee Recruitment table, a candidate's university name and

address may be included. But you need a complete list of universities for group mailings.
If university information is stored in the Candidates table, there is no way to list
universities with no current candidates. Create a separate Universities table and link it to
the Candidates table with a university code key.

EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not
always practical. If you have a Customers table and you want to eliminate all possible
interfield dependencies, you must create separate tables for cities, ZIP codes, sales
representatives, customer classes, and any other factor that may be duplicated in multiple
records. In theory, normalization is worth pursing. However, many small tables may
degrade performance or exceed open file and memory capacities.

It may be more feasible to apply third normal form only to data that changes frequently.
If some dependent fields remain, design your application to require the user to verify all
related fields when any one is changed.

Other normalization forms

Fourth normal form, also called Boyce Codd Normal Form (BCNF), and fifth normal
form do exist, but are rarely considered in practical design. Disregarding these rules may
result in less than perfect database design, but should not affect functionality.

Normalizing an example table

These steps demonstrate the process of normalizing a fictitious student table.

*Unnormalized table:
Student# Advisor Adv-Room Class1 Class2 Class3
1022 Jones 412 101-07 143-01 159-02
4123 Smith 216 101-07 143-01 179-04

*First normal form: No repeating groups

Tables should have only two dimensions. Since one student has several classes, these
classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above
records are indications of design trouble.

Spreadsheets often use the third dimension, but tables should not. Another way to look at
this problem is with a one-to-many relationship, do not put the one side and the many
side in the same table. Instead, create another table in first normal form by eliminating
the repeating group (Class#), as shown below:

Student# Advisor Adv-Room Class#

1022 Jones 412 101-07
1022 Jones 412 143-01
1022 Jones 412 159-02
4123 Smith 216 101-07
4123 Smith 216 143-01
4123 Smith 216 179-04

*Second normal form: Eliminate redundant data

Note the multiple Class# values for each Student# value in the above table. Class# is not
functionally dependent on Student# (primary key), so this relationship is not in second
normal form.

The following tables demonstrate second normal form:

Students:

Student# Advisor Adv-Room

1022 Jones 412
4123 Smith 216

Registration:

Student# Class#
1022 101-07
1022 143-01
Student# Class#
1022 159-02
4123 101-07
4123 143-01
4123 179-04

*Third normal form: Eliminate data not dependent on key

In the last example, Adv-Room (the advisor's office number) is functionally dependent on
the Advisor attribute. The solution is to move that attribute from the Students table to the
Faculty table, as shown below:

Students:

Student# Advisor
1022 Jones
4123 Smith
Name Room Dept
Jones 412 42
Smith 216 42

Faculty:

7. Query language

- Query language (QL) refers to any computer programming language that requests and
retrieves data from database and information systems by sending queries. It works on
user entered structured and formal programming command based queries to find and
extract data from host databases.

Query language may also be termed database query language.

- Commonly Used SQL Statements

The following is a list of commonly used SQL commands that can be used to
create tables, insert data, change the structure of the tables, and query the data.

Defining and Creating Tables

CREATE
The CREATE statement is used to create tables in a database. The statement can define
the field names and field data types within a table. The CREATE statement is also used
to define the unique identities of the table using primary key constraints. It is also used to
describe the relationships between tables by defining a foreign key.

Template:

CREATE TABLE [tableName] (

Column_1 Datatype1,

Column_2 Datatype2..

);

ALTER

The ALTER statement is used to change the structure of a table in the database. The
statement can be used to create a new column or change the data type of an existing
column.

Template:

ALTER TABLE [tableName]

ADD Column_1, Datatype_1

DROP

The DROP statement is used to delete a table from a database. It must be used with
caution as deletion is irreversible.

Template:

DROP TABLE [tableName]

Adding, Modifying, and Deleting Data

INSERT

The INSERT statement is used to add records or rows to a table. The name of the table to
insert records into is defined first. Then, the column names within the table are defined.
Finally, the values of the records are defined to insert into these columns.
Template:

INSERT INTO [tableName] (Field_1,…,Field_N)

VALUES (Value_1,…,Value_N)

UPDATE

The UPDATE statement is used to modify records in a table. The statement changes the
values of a specified subset of records held in the defined columns of the table. It is a
good practice to filter rows using a WHERE clause when updating records. Otherwise, all
records will be altered by the UPDATE statement.

Template:

UPDATE [tableName]

SET Column_1 = Value_1, …, Column_N = Value_N

WHERE [filter citeria]

DELETE

The DELETE statement is used to delete rows from a table based on criteria defined
using a WHERE clause. The statement should be used carefully, as all deletion in a
database is permanent. If a mistake is made using a DELETE statement, the database will
need to be restored from a backup.

Template:

DELETE FROM [tableName]

WHERE [filter criteria]

8. System testing

- System testing is the testing of a complete and fully integrated product. After
Integration test and Unit test

Normally, a software product is only tested on 1 because of the demo

environment, but system testing ensures that the system operates on many
different environments, integrating with many different software and systems.
 System testing is a type of black box testing. System deals with the external
workings of the software from the user's point of view.

- After completing the integration testing process we need to further check the
compatibility and interact with the external peripherals of the application to check its
usability.

System testing is the thorough check verification of each input in the

application to test the desired results.

Test the user's experience with the application.

III. Practice

- To make a 2-hand clothing sales system, we need first an admin to manage the entire
store system. Then we need to put products with high quality into the store to improve
the reputation. When a customer buys a product, it will include price, size, .. and more
forms of payment. Finally, at step 1, we pay and ship to customer 2, who are direct
buyers.

- Admin : username, ID, password, name

Customer : ID, address, fullname, phone
Store :quality, id
Product : date, id, price, fullname
Payment methods : id, phone, name
Shipping : id, name phone