Data abstraction lets developers and administrators display only necessary data to front-end users since they do not need to have access to an entire data silo. Abstraction is used in several areas of software development, and the data layer of an application separates the database from the user interface. The purpose is to leverage better scalability and less refactoring during infrastructure changes.
What Is a DBMS?
A database management system (DBMS) is a tool used as an interface between a user and the raw stored data. Using a DBMS, administrators can view data stored in a database, update or insert new data, and run queries to retrieve data. Administrators can also manage database items such as stored procedures, triggers, tables, indexes, and other objects. A DBMS is often used to build the database and later manage it.
An example of a DBMS is MySQL. MySQL is a relational database, so administrators use the DBMS to view database objects, create tables, or query data. An application uses the DBMS to query data or add data to the database. Because MySQL is a relational database, data is stored in tables with constraints on every column to control the type of data stored.
Another example of a DBMS is MongoDB. MongoDB is a NoSQL open source database that stores unstructured data. Data is stored in documents, and administrators can store any number and type of items in the document. Administrators use the MongoDB DBMS to manage the structure of the database, and applications use it to query and add data.
What Is a Data Abstraction?
Data abstraction is a logical function in an application to separate the raw data from the front end. In simple terms, the data layer handles the connection to the database and querying it from the front end. Data abstraction makes it possible for the front-end application to query data regardless of where the data is stored. Developers can then swap out back-end databases without refactoring large sections of their code to connect and work with a new database engine.
As an example, suppose that you use MongoDB in development until you can determine the type of data you need to work with. You then want to use MySQL in production. The data abstraction layer handles connection to the database and querying from both MongoDB and MySQL without affecting the front-end codebase. Users are unaware of the changes to database engines but can still obtain the information they need.
Levels of Data Abstraction
Data abstraction is an umbrella term that handles several different aspects of managing data. When developers create an application and work with administrators, there are three levels of abstraction: physical, logical, and view. Here’s a brief explanation of these levels:
- Physical/internal level: This level encompasses the infrastructure to house the database, including the network information for the server and the location of the server. For example, the physical components could be a cloud VM with mid-level CPU and memory resources.
- Logical/conceptual level: The logical layer is the code used to connect to the physical layer. It contains the logic for connections, queries, and error handling. Logical layers might include code to connect to multiple databases depending on input factors.
- View/external level: The front-end application lets users view the data. This level of abstraction is the farthest from the raw data storage location, but it formats and presents the data to the viewer so that it can be useful.
Multi-tier Database Architectures
Abstraction layers can be logical layers embedded in your application, but they can also be located on physically different resources. The purpose of multi-tiered abstraction is to make it much easier to scale a single layer without affecting other layers. Multi-tier architecture is also named “n-tier architecture” where administrators can choose to have several tiers for each component in the application.
It’s common to have three tiers in a multi-tier architecture: presentation, data, and application. Here’s a brief description of these tiers:
- Data tier: This tier stores the data and runs the database engine. It can be on a dedicated bare bones server or a virtual machine. Databases can also work in clusters in a data warehouse with complex data pipelines depending on the use case scenario.
- Application tier: This tier handles the application. For example, if the front end is a custom web application, a web server stores the application files and executes it. Users connect to this server to run the application.
- Presentation tier: The presentation tier is distinct from the application tier even though they sound similar. Application tiers have the code base and application logic, while the presentation tier is what the user sees. In a web application, the presentation tier is the CSS and HTML used to format and display application code to the user.
What Are the Benefits of Data Abstraction?
Separating data layers from the front-end application allows for granular scaling of resources. Changes to the data layer would also not affect the front end, so data abstraction limits refactoring of code when another database engine is used or the data tier changes locations.
For example, let’s say your organization decides to move the database to the cloud from on-premises locations. Only the data layer would need to change and no changes to the front-end application code would be necessary. Administrators can scale resources for the data layer without the need to scale resources for the application layer if it isn’t necessary.
Conclusion
In an enterprise application, having a data abstraction layer to connect to your DBMS lets you scale up or down. You can also make changes to the architecture of the data tier in your architecture without many code changes to your codebase. You can use multiple database engines or move your database to a new location without much overhead.
As you plan out your data abstraction architecture, check out Pure Storage® FlashArray™ for unified block and file storage. For storage in the cloud, check out Pure Storage’s cloud block storage.
