Wednesday, March 29, 2023

Effective User Management performed by DBA"s.

The user or users with the administrator role are solely responsible for managing users who have been granted database access.

The administrator is in charge of controlling how other users in your organization access your database. The administrator, for example, can add new users, deny access to users who have left the organization, and assist users who are unable to log in.

Administrators are responsible for the following tasks:

  • Create new users
  • Users should be removed.
  • Control user access
  • Configure user connection privileges.
  • Change user permissions.
  • View current user permissions.
  • Passwords for users should be changed.
Database user management typically involves the following tasks:

1. Creating user accounts: The first step in user management is to create user accounts for individuals or groups who need access to the database. Each account is typically assigned a unique username and password.

2. Modifying user accounts: Administrators may need to modify user accounts from time to time, for example, to update passwords or change access permissions.

3. Granting and revoking access permissions: Administrators can assign specific privileges to users, such as read-only access or the ability to make changes to the data. They can also revoke these permissions if necessary.

4. Monitoring user activity: It's important to monitor user activity within the database to identify any suspicious behavior or potential security breaches.

5. Deleting user accounts: When an employee leaves an organization or no longer requires access to a particular database, their user account should be deleted to prevent unauthorized access.

Database Security Best Practices followed by DBA's.

Database security is a combination of controls and countermeasures used to protect a database management system. The best practices cover all aspects of physical and digital data center and information security.

Database security issues stem from a diverse set of security threats. Consider the risks and address each issue before reaching a compromise. The following are examples of common database maintenance issues:

  • Error due to human error.
  • Threats from within.
  • Vulnerabilities in software.
  • Malware.
  • Backup assaults.
  • Physical site security.

Best Database Security Practices performed by DBA's.

The security features protect one or more of the database's following aspects:

  • The database server's physical location.
  • The network infrastructure required to access the database.
  • The information contained within the database.
  • The database administration system.
  • Database-related applications.
Database security has a layered structure. The outside layers encapsulate the inner layers of security closest to the data, providing a barrier of protection around the database.

  • Use Firewalls
  • Use Secure Applications and Software
  • Practice Database Encryption
  • Secure User Access
  • Perform Regular Updates
  • Perform Regular Backups
  • Practice Monitoring
  • Perform Security Testing
  • Define Clear Security Procedures
  • Maintain Hardware Security

Why Is Database Security Critical?

Data security is a high-priority security task. Database security protects data from potentially disastrous situations. The following are some of the consequences of a database breach:

  • Penalties and fines for noncompliance.
  • Repairs are expensive.
  • Intellectual property compromise.
  • Reputational harm.
Conclusion:

Many security aspects are included in database integrity. This post only covers a few of the best security practices for keeping your information system safe.


Tuesday, March 28, 2023

Common Causes of Slow Queries and Technique to improve the Query Performance Effectively

When you run a query, you may notice that the output is much slower than expected, taking a few seconds, minutes, or even hours to load. What could be causing this?

There are numerous causes for a slow query, but a few common ones are as follows:

  • The database size, which is made up of the number of tables and the size of each table. The larger the table, the longer the query will take, especially if you're scanning the entire table each time.
  • Queries that are not optimized can result in slower performance. For example, if your database hasn't been properly indexed, the results of your queries will load much slower.

When you run a query, you should see something like this:Sample SELECT Output

As can be seen, the output includes the number of rows outputted as well as the execution time, which is given in the format 0.00 seconds.
The EXPLAIN statement is a built-in tool that can be used to determine why your query is taking so long to run.

EXPLAIN Your Query's Performance

The EXPLAIN statement provides information about how MySQL executes your statement—that is, how MySQL plans on running your query. With EXPLAIN, you can check if your query is pulling more information than it needs to, resulting in a slower performance due to handling large amounts of data.

This statement works with SELECTDELETEINSERTREPLACE and UPDATE. When run, it outputs a table that looks like the following:

Sample EXPLAIN Output

With SELECT, the EXPLAIN statement tells you what type of select you performed, the table that select is being performed on, the number of rows examined, and any additional information, as shown in the outputted table.

The EXPLAIN statement in this case revealed that the query used a simple select (rather than a subquery or union select) and that 298,980 rows were examined (out of a total of about 300,024 rows).

When determining why a query is slow, the number of rows examined can be useful. For example, if you notice that your output is only 13 rows, but the query is examining approximately 300,000 rows—nearly the entire table!—this could be the cause of your query's slowness.

In the earlier example, loading about 300,000 rows took less than a second to process, so that may not be a big concern with this database. However, that may not be the case with larger databases that can have up to a million rows in them.

One method of making these queries faster is by adding indexes to your table.

Indexing a Column

Think of indexes like bookmarks. Indexes point to specific rows, helping the query determine which rows match its conditions and quickly retrieves those results. With this process, the query avoids searching through the entire table and improves the performance of your query, particularly when you’re using SELECT and WHERE clauses.

There are many types of indexes that you can add to your databases, with popular ones being regular indexes, primary indexes, unique indexes, full-text indexes and prefix indexes.

Type of IndexDescription
Regular IndexAn index where values do not have to be unique and can be NULL.
Primary IndexPrimary indexes are automatically created for primary keys. All column values are unique and NULL values are not allowed.
Unique IndexAn index where all column values are unique. Unlike the primary index, unique indexes can contain a NULL value.
Full-Text IndexAn index used for searching through large amounts of text and can only be created for charvarchar and/or text datatype columns.
Prefix IndexAn index that uses only the first N characters of a text value, which can improve performance as only those characters would need to be searched.

Now, you might be wondering: if indexes are so great, why don’t we add them to each column?

Generally, it’s best practice to avoid adding indexes to all your columns, only adding them to the ones that it may be helpful for, such as a column that is frequently accessed. While indexing can improve the performance of some queries, it can also slow down your inserts, updates and deletes because each index will need to be updated every time. Therefore, it’s important to find the balance between the number of indexes and the speed of your queries.

In addition, indexes are less helpful for querying small tables or large tables where almost all the rows need to be examined. In the case where most rows need to be examined, it would be faster to read all those rows rather than using an index. As such, adding an index is dependent on your needs.

Be Selective with Columns

When possible, avoid selecting all columns from your table. With larger datasets, selecting all columns and displaying them can take much longer than selecting the one or two columns that you need.

For example, with a dataset of about 300,000 employee entries, the following query takes about 0.31 seconds to load:

SELECT * FROM employee;

Sample SELECT ALL Output

But if we only wanted to see the employee numbers and their hire dates (2 out of the 6 columns) we could easily do so with this query that takes 0.12 seconds to load:

SELECT employee_number, hire_date FROM employee;

Sample SELECT Output with Employee Number and Hire Date

Notice how the execution time of the query is much faster compared to the when we selected them all. This method can be helpful when dealing with large datasets that you only need select specific columns from.

Avoid Leading Wildcards

Leading wildcards, which are wildcards ("%abc") that find values that end with specific characters, result in full table scans, even with indexes in place.

If your query uses a leading wildcard and performs poorly, consider using a full-text index instead. This will improve the speed of your query while avoiding the need to search through every row.

Use the UNION ALL Clause

When using the OR operator with LIKE statements, a UNION ALL clause can improve the speed of your query, especially if the columns on both sides of the operator are indexed.

This improvement is due to the OR operator sometimes scanning the entire table and overlooking indexes, whereas the UNION ALL operator will apply them to the separate SELECT statements.

What are different types of backups and distinguish among them?

There are many different types of backups that you can use to meet your backup and restore needs. The choice of which are available to you depends on the database system that you are using. The commonly used types include. 

  • Full back up: A full backup is a complete copy of all data in the object or objects being backed up. It simplifies the restore and recovery processes because you only need to locate the most recent full backup and restore that single file. However, as the size of your database grows, so do the time, bandwidth, and storage requirements for the backup file. Furthermore, if you decide to keep previous backup copies for safety, you will be storing many instances of a large file. If you only keep one copy, you must accept the risk that if the backup file becomes corrupt, you will be unable to restore your data. Consider that if only a subset of your data changes on a regular basis. You could be redundantly backing up the same data. Storing a complete copy of your data outside of the RDBMS requires you to ensure that it is adequately secured, and the unauthorized users cannot access it. When you restore a full back up, you return the data to the state it was in at the time the backup was taken. However, the database may have processed numerous transactions since then, which should ideally be restored as well.
  • Point in time backup: One solution is to enable logging for each transaction in your database, and then use the information in the log file to reapply the transactions to the restore database. The process of reapplying transactions after restoring a database backup is known as recovery, and it allows you to restore the data to the state it was in at a specific point in time, thus the name point-in-time recovery. For example, if you know that a DML statement executed at 11:05am deleted some data inadvertently, you can restore the most recent full backup and then reapply the transactions up to that point in time, minimizing the loss of data changes that occurred between the last full backup and the moment that the wrong data was deleted.
  • Differential backup: A differential backup is a copy of any data that has changed since the previous full backup. The differential backup file is much smaller than a full backup file, reducing backup time, bandwidth, and storage requirements while still allowing you to restore a recent copy of the data. For example, you could run a full back up once a week on Sunday, followed by a differential backup every day of the week. Each differential backup contains all of the changes that have occurred since the full back up on Sunday, so if you need to restore the database on a Tuesday, you must first restore the full back up from Sunday and then restore the differential backup from Tuesday.
    You do not need to restore Monday’s differential backup, because all the changes in that file are also included in the differential backup from Tuesday.
  • Incremental backup: Incremental backups are similar to differential backups in that they only contain data that has changed since the last backup of any kind. For example, you could run a full backup on a Sunday once a week and then an incremental backup every day of the week. Each incremental backup only contains changes since the previous day's backup, so if you need to restore the database on a Tuesday, you must first restore the full back up from Sunday, then the incremental backup from Monday, and finally the incremental backup from Tuesday. Restoring data from full and incremental backups will take longer than simply restoring a full backup or differential backups, but the time spent performing incremental backups is likely to be less than needed for a differential backup.

Note: Different database systems use different terminology for the log containing the transaction information, for example, MySQL calls it the binary log, Postgres calls it the write-ahead log, and Db2 on Cloud calls it the transaction log. Database transaction logs keep track of all activities that change the database structure and record transactions that insert, update, or delete data in the database.

Difference between hot backups and cold backups:

Hot BackupsCold Backups
Hot backups, or online backups, are those performed on data when it is in use. Cold backups, or offline backups, are those performed on data when it is not in use. 
The advantage of hot backups is that they have no impact on availability and users can  continue with their activities throughout the backup periodAvailability is impacted and users are unable to access  in 24/7 environments
hot backups can result in performance degradation for users while the backup is running and can impact on data integrity if data changes during the backup process. Data Integrety is eliminated as the backup is taken offline.
it is stored on the available serversit is stored on external drivers or on the server which is shut down between the backup's operations.
Lesser data safetyGreater data safety

Summary:

  • Full backups are simple to create and restore but can be slow to run and result in large files. 
  • Point-in-time recovery provides a more granular recovery model than just using full database backups. 
  • Differential backups are quicker to run than full backups, but the restore process can take longer.
  • Incremental backups are even quicker to run, but the restore process can take even longer.
  • Hot, or online, backups allow data to be backed up while the database is active, whereas cold backups require the database to be offline.
  • The backup policy should be determined from recovery and availability needs and data usage patterns. Most managed cloud databases provide automated backup functionality with some configurable options.


Friday, March 24, 2023

Introduction to Backup and Restore techniques performed by DBA's

Backup and restore is a common phrase in database conversations and often used to refer to the process of backing up data for protection purposes-restoring it after data loss from an unplanned shutdown, accidental deletion, or data corruption. However, there are other scenarios when you might want to backup or restore your databases or objects within them.

After reading this post, you will be able to: 

  • Describe common backup and restore scenarios, 
  • Explain the difference between physical and logical backup,
  • List the objects that you can back up and restore, and 
  • Explain what you need to consider when backing up databases and their objects. 

 As a data engineer/Data Ninja, you are likely to perform data backup and restore operations to transfer data from one database to another. This may be to facilitate a change of RDBMS, to share data with or load data from a business partner, or to create a copy of the data for use in another location or system, such as development or test. When backing up databases, you can perform either logical or physical backups. 

Difference between Logical backups and physical backups:

Logical Back up Physical Back up
ContentCreates a file containing DDL (such as create table) and DML commands (such as insert) that recreate the objects and data in the database. As such, you can use this file to recreate the database on the same or another system.Creates a copy of all the physical storage files and directories that belong to a table, database, or other objects, including the data files, configuration files, and log files to aid point-in-time recovery. 
Spacewhen you perform a logical backup and restore, you reclaim any wasted space from the original database because the restore process creates a clean version of the tables. You can't reclaim the wasted space.
PerformanceGenerating logical backups can take a long time for large databases and may impact the performance of other queries that are concurrently running. Physical backups are often smaller and quicker than logical backups; they are useful for large or important databases that require fast recovery times. They are similar to backing up any other types of files on your physical system. 
GranularLogical backups enable you to backup granular objects. For example, you can back up an individual database or table; however, you cannot use it to backup log files or database configuration settings. You typically use import, export, dump, and load utilities to perform logical backups. Physical Backup is less granular objects. For Ex, you won't be able to backup an individual database or table.


You can choose exactly which parts of a database you want to backup. Depending on the RDBMS you are using and type of backup you are performing, you can back up a whole database, the contents of a schema, one or more tables from a database, a subset of data from one or more tables in a database, or a collection of other objects in the database. 

It is essential to check these when using backup and restore as part of your disaster recovery plans, as an invalid back up or an inability to restore can result in data loss. You should also ensure that you secure the transfer and storage location of your back up files at the same level that you secure the data in your database.

When performing backups, some RDBMSs support additional options that you can use: You may be able to configure a compression level for the backup files. Compressing the files will reduce the output file size which can be useful for large databases or if you are backing up to a remote location; however, it comes at a cost of time taken to perform the backup and the restore procedures. You may also be able to encrypt the backup files, to reduce the risk of any data being compromised. But again, this will increase the time taken for the backup and restore.

Summary:

In this post, you understood that: You can use backup and restore for data recovery and other purposes. Physical backups create a copy of the raw database storage files and directories whereas logical backups extract the data from a database and save it in a special format. You can backup whole databases or objects within them. You should always check that your backup is safe and usable and that your restore plan works. You can use backup options to compress or encrypt your files.

Data Security, Ethical and Compliance Considerations by DBA's

Data Security, Ethical and Compliance Considerations

As a database administrator (DBA), one of the most important parts of your role is to safeguard the data in the system. DBA's control the system, so DBA's are responsible for ensuring that the data is secure and complies to all relevant standards. DBA's must also hold themself to the highest ethical standards. Some organizations include a specific database security administrator role that focuses on these duties, but all DBAs need to keep them in mind.

Fundamental Ethics

A foundation of basic ethical concepts supports good data security practices. These should help guide the policies and workflows DBA's create and the actions they take. Some important concepts are:

Transparency: When DBA's collect information, they should tell the owners of the information exactly what data DBA's will collect and what DBA's will do with it. Inform them about how DBA's use the data, how DBA's store it, who will have access to it, and how DBA's will dispose of it when DBA's have finished using it.

Consent: DBA's should get clear consent from data owners before they collect their data. This should detail what data DBA's will be allowed to collect and how DBA's will be allowed to use it.

Integrity: Always be clear about your procedures and policies, and always follow them consistently. As far as DBA's can, make sure that others in your organization also follow the correct procedures and policies.

Secure System Design

The structure of your system is a powerful tool in keeping your data safe. If your system is built to maintain security, it’s much easier to prevent breaches. To make sure your system works for you, consider these factors.

Protection from malicious access: The front line of protection for your data is basic software security. Your firewall and other cybersecurity tools should actively prevent hacking and malware installation, and alert they to threats. Be sure DBA's update this software frequently, to keep scanning lists up to date. Also, educate users about phishing and other ways that they can unwittingly enable malicious access.

Secure storage: The storage they choose for your data must be secure not only from malicious access, but also from hardware failure and even natural disasters. Select your services carefully and make sure they understand their security practices and disaster preparedness plans. Back up your data regularly and reliably to minimize data loss in case of an emergency.

Accurate access: Only those who need certain data should be able to access it. Establish a system of assigning and tracking privileges that assigns each user only the necessary privileges, and controls what they can do with the data. Ensure that your policy complies with any data usage agreements DBA's have made.

Secure movement: Data can be particularly vulnerable to interception when DBA's move it into or out of storage. Be sure to consider safe transfer methods as carefully as DBA's plan safety for the rest of your system.

Secure archiving: At some point, DBA's may want to move data from active storage to an archive. This can protect it from accidental access and make your system more efficient. Make sure your archiving system is as secure as the rest of your storage. Data agreements often specify how long DBA's may use the data, so be sure the archived data is regularly weeded for expired rights and don’t retain any more data than DBA's will need for compliance with organization policy. Eliminate your discarded data securely and completely.

Compliance Issues

Maintaining compliance with all relevant laws and standards is a vital concern. Failure can result in data insecurity, professional censure for your organization, and even legal action. This list includes some of the most common types of standards, but it’s not exhaustive; always find out which regulations and standards apply to your organization.

  • National/international regulations
  • Industry standards
  • Organization best practices 

If DBA's build your system and procedures thoughtfully and maintain them with consistency and vigilance, DBA's can keep the data in your system safe and productive.

Responsibilities of DBA's and their daily top activities.

A typical day for a database administrator includes checking the state of the database and resolving any issues, responding to support tickets, meeting with developers and other stakeholders, and monitoring database activity. Let's know more by reading the following details.

The database lifecycle splits into four stages: 

  • The initial requirements analysis,
  • Designing and planning the database deployment, 
  • Performing the actual implementation, and 
  • monitoring and maintaining day-to-day operations.
Responsibilities of DBA and daily activities
  • In the requirements analysis stage, DBAs to understand the purpose and scope of the database and develop a plan for implementing the database. To do so, DBA's need to works with database objects such as instances, databases, tables, and indexes.
  • A database model represents the design of a database: which instance contains which databases and tables, how the tables relate to each other, how users access the data, and so on.
  • Database Architects and DBAs model the databases and their objects with the help of Entity Relationship Diagrams or ERDs. 
  • They determine appropriate server resources like storage space, memory, processing power, and log file size. They also need to plan for how database objects are physically stored. For example, DBAs can choose to store frequently used data on a high-speed disk array or to store indexes separately from the data for better performance. 
  • In the implementation stage, DBAs roll out the carefully planned design. Another task DBA performs is configuring database security, granting access for database users, groups, and roles, so database objects are accessible only by the specific users and applications authorized to access them. He also automates repeating database tasks such as backups, restores, and deployments to improve efficiency.
  • In populating the database, DBA's might import data from other databases, export data based on a query from a different source, or migrate projects from one environment to another, such as moving a project from the Application Development environment to the Production environment. 
  • In the monitor and maintain stage, DBA's looks after the daily operations of the database. They will monitor the system for long-running queries and help end-users optimize them to run faster and not overuse system resources. A key part of DBA's job is to review reports.
  • Most Relational Database Management Systems have built-in reports to monitor activity, identify expensive queries, resource waits, and other relevant items. Often companies build custom reports on top of these, and DBAs help with that.
  • To keep the databases working at top efficiency, DBA's may also apply upgrades and security patches to database software. They need to stay up to date on issues and advancements in the field so they can recommend and implement emerging database technologies. They might also automate deployments and routine tasks such as backups whenever possible to keep processes working efficiently. In every database, operational issues will sometimes arise. 
  • They troubleshoot these issues, escalating problems where necessary. DBAs are responsible for keeping data safe. Part of DBA"S job is to regularly perform user audits and ensure that only authorized users are allowed to get into the system and that users can only see things they are supposed to see. DBA's reviews logs and alerts, looking for failed logins and data access attempts to identify potential threats and vulnerabilities. 
  • They also maintain database user and application permissions – revoking access to users and groups who should no longer have access and adding new users and roles as required to perform their jobs.

In this post, you understood: Responsibilities of DBA, daily activities and the database life cycle stages are requirements analysis, design and plan, implementation, and monitor and maintain. In the requirements analysis stage, DBAs determine the purpose and scope of the database by interviewing data users and producers, examining the data, and creating samples. In the design and plan stage, DBAs work on logical and physical design. In the implementation stage, DBAs deploy the database. And finally, in the monitor and maintain stage, DBAs manage the daily operations of the database.

Introduction to Relational Database Administration

When you want to be skilled up to become a Data Engineer/Data Ninja, you need to learn working and managing databases. This articles content teaches you the fundamental database administration skills which is required as a Data Ninja. 

The typical workday for a Database Administrator (DBA) looks like, revolving around various activities ranging from designing databases to planning and troubleshooting errors. You will gain experience learning about server objects, configurations, and database objects, including schemas, tables, triggers and events.

The ability to respond/recovery quickly to system failures, corruption, and catastrophic events is a key part of any DBA's job. Crucial to this is the ability to recover data that has been lost, so you will learn to backup and recovery databases and define backup and recovery policies and procedures.

Security of data and databases is crucial. To ensure data is secure, the blog helps you to learn about database security and user management, including creating and resetting user passwords, creating groups. Ongoing monitoring and optimization of databases are essential tasks that enable DBAs to respond to issues before they become problems.

Being able to automate processes is a skill that enables DBAs to make database administration easier. You can automate many functions, from managing alerts to generating and sending reports. You can create these automation tasks using standard Linux and Unix shell commands or cron jobs. 

Let's get started to become a Data Ninja...

The Topics are as follows.

Introduction to DBA

Responsibility of DBA

Data security, Ethical and Compliance

Introduction to Backup and Restore

Types of Back up

Common cause of Slowness of Queries

Data Security Best Practices

Effective User Management

Top 15 Database Monitoring Tools

Saturday, March 4, 2023

Introduction to Database, Characteristics, Actor on/behind the scenes and Advantages of DBMS approach.

 What is Database? 

A database is a collection of related data. Here Data means known facts that can be recorded and have implicit meaning. for ex: Name, telephone number and address.

Database has a following implicit properties:

  • Database represents some aspect of real world.
  • Database is a coherent collection of related data with some inherent meaning.
  • Database is designed, built and populated with data for specific purpose.
  • database can be of any size and complexity.

A database management system (DBMS) is a collection of programs that enables user to create and maintain the database. The DBMS facilitates the process of defining, constructing, manipulating and sharing the databases among various users and applications.

There are several different types of database models have been developed so far, for example, flat, hierarchical, network and relational. These models describe the operations that can be performed on them as well as the structure of the conforming databases. Normally there is a database schema which describes the exact model, entity types, and relationships among those entities.

 Flat Databases have the following characteristics −

  • simple
  • long and dominant
  • useful for very small scale and simple applications.
Relational Databases have the following characteristics.
  • Self-describing nature of database system.
  • Insulation between programs and data and data abstraction.
  • Support multiple views of data.
  • sharing of data and multiuser transaction processing.
Actors on the scenes are as follows:
  • Database Administrator (DBA)
  • Database Designer
  • End users - Casual, Parametric, Sophisticated, Standalone.
  • System analyst and application programmers.
Workers behind the scenes are as follows:
  • DBMS designer and implementor.
  • Tool developers
  • operator and maintenance personnel.

Advantages of using DBMS approach:
  • Controlling redundancy
  • restricting unauthorized access.
  • providing persistent storage for program objects.
  • Providing storage structure for efficient query processing.
  • providing backup, recovery, multiple user interfaces.
  • enforcing integrity.



What is Multidimensional Database, Advantages and Disadvantages of it?

A multidimensional database, also known as a multi-dimensional data structure or a hypercube, is a type of database that is optimized for the storage and analysis of data that has multiple dimensions or attributes.

In a multidimensional database, data is organized into a cube-like structure where each dimension represents a different attribute of the data. For example, a sales database might have dimensions for time, product, and location. The data can be viewed and analyzed in different ways by slicing and dicing the cube along different dimensions.

The multidimensional databases use MOLAP (multidimensional online analytical processing) to access its data. They allow the users to quickly get answers to their requests by generating and analyzing the data rather quickly.

Multidimensional databases are designed to handle large volumes of data and complex queries efficiently, making them ideal for business intelligence, data mining, and other analytical applications. They use specialized data structures and algorithms to support fast, interactive queries and allow users to explore data from different angles and perspectives.

Some examples of multidimensional database systems include Oracle OLAP, Microsoft Analysis Services, and SAP Business Warehouse.

Advantages of Multidimensional Databases

Some advantages of multidimensional databases are −

Increased performance

The performance of the multidimensional databases is much superior to that of normal databases such as relational database.

Easy maintenance

The multidimensional database is easy to handle and maintain 

Better data presentation

The data in a multidimensional database is multi faceted and contains many different factors. Hence, the data presentation is far superior to conventional databases.

Disadvantages of Multidimensional Databases

One of the disadvantages of multidimensional databases are that it is quite complex, and it takes professionals to truly understand and analyze the data in the database.

Introduction to Database Management System

 A Database Management System (DBMS) is a collection of programs that enables user to create and maintain a database. The DBMS is a general-...