Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning
- Choosing the Back End
- The DBA's Toolbox, Part 1
- The DBA's Toolbox, Part 2
- Scripting Solutions for SQL Server
- Building a SQL Server Lab
- Using Graphics Files with SQL Server
- Enterprise Resource Planning
- Customer Relationship Management (CRM)
- Building a Reporting Data Server
- Building a Database Documenter, Part 1
- Building a Database Documenter, Part 2
- Data Management Objects
- Data Management Objects: The Server Object
- Data Management Objects: Server Object Methods
- Data Management Objects: Collections and the Database Object
- Data Management Objects: Database Information
- Data Management Objects: Database Control
- Data Management Objects: Database Maintenance
- Data Management Objects: Logging the Process
- Data Management Objects: Running SQL Statements
- Data Management Objects: Multiple Row Returns
- Data Management Objects: Other Database Objects
- Data Management Objects: Security
- Data Management Objects: Scripting
- Powershell and SQL Server - Overview
- PowerShell and SQL Server - Objects and Providers
- Powershell and SQL Server - A Script Framework
- Powershell and SQL Server - Logging the Process
- Powershell and SQL Server - Reading a Control File
- Powershell and SQL Server - SQL Server Access
- Powershell and SQL Server - Web Pages from a SQL Query
- Powershell and SQL Server - Scrubbing the Event Logs
- SQL Server 2008 PowerShell Provider
- SQL Server I/O: Importing and Exporting Data
- SQL Server I/O: XML in Database Terms
- SQL Server I/O: Creating XML Output
- SQL Server I/O: Reading XML Documents
- SQL Server I/O: Using XML Control Mechanisms
- SQL Server I/O: Creating Hierarchies
- SQL Server I/O: Using HTTP with SQL Server XML
- SQL Server I/O: Using HTTP with SQL Server XML Templates
- SQL Server I/O: Remote Queries
- SQL Server I/O: Working with Text Files
- Using Microsoft SQL Server on Handheld Devices
- Front-Ends 101: Microsoft Access
- Comparing Two SQL Server Databases
- English Query - Part 1
- English Query - Part 2
- English Query - Part 3
- English Query - Part 4
- English Query - Part 5
- RSS Feeds from SQL Server
- Using SQL Server Agent to Monitor Backups
- Reporting Services - Creating a Maintenance Report
- SQL Server Chargeback Strategies, Part 1
- SQL Server Chargeback Strategies, Part 2
- SQL Server Replication Example
- Creating a Master Agent and Alert Server
- The SQL Server Central Management System: Definition
- The SQL Server Central Management System: Base Tables
- The SQL Server Central Management System: Execution of Server Information (Part 1)
- The SQL Server Central Management System: Execution of Server Information (Part 2)
- The SQL Server Central Management System: Collecting Performance Metrics
- The SQL Server Central Management System: Centralizing Agent Jobs, Events and Scripts
- The SQL Server Central Management System: Reporting the Data and Project Summary
- Time Tracking for SQL Server Operations
- Migrating Departmental Data Stores to SQL Server
- Migrating Departmental Data Stores to SQL Server: Model the System
- Migrating Departmental Data Stores to SQL Server: Model the System, Continued
- Migrating Departmental Data Stores to SQL Server: Decide on the Destination
- Migrating Departmental Data Stores to SQL Server: Design the ETL
- Migrating Departmental Data Stores to SQL Server: Design the ETL, Continued
- Migrating Departmental Data Stores to SQL Server: Attach the Front End, Test, and Monitor
- Tracking SQL Server Timed Events, Part 1
- Tracking SQL Server Timed Events, Part 2
- Patterns and Practices for the Data Professional
- Managing Vendor Databases
- Consolidation Options
- Connecting to a SQL Azure Database from Microsoft Access
- SharePoint 2007 and SQL Server, Part One
- SharePoint 2007 and SQL Server, Part Two
- SharePoint 2007 and SQL Server, Part Three
- Querying Multiple Data Sources from a Single Location (Distributed Queries)
- Importing and Exporting Data for SQL Azure
- Working on Distributed Teams
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Enterprise Resource Planning
Last updated Mar 28, 2003.
SQL Server has plenty of uses as a platform for applications. Applications come in all sizes, and one of the largest is Enterprise Resource Planning, or ERP. Enterprise Resource Planning really isn't a piece of software, though; it's a category.
Enterprise Resource Planning Defined
Webopedia defines ERP as:
"Short for enterprise resource planning, a business management system that integrates all facets of the business, including planning, manufacturing, sales, and marketing. As the ERP methodology has become more popular, software applications have emerged to help business managers implement ERP in business activities such as inventory control, order tracking, customer service, finance and human resources."
While that definition is accurate, it's a bit unsatisfying for a DBA. Just how does this affect the database server architecture? It might be more helpful to think of the title as the definition. Let's break it down:
Enterprise: ERP software affects the entire company, all around the world. While I have seen ERP systems implemented in a "silo," where only a few groups actually use it, those projects usually gain little general buy-in and as a result they often fail. Properly implemented, ERP software is pervasive, affecting all workers in the company, even if they don't use the software themselves. It must take into account all parts of the company as a whole, instead of making various parts just work together. This affects the design in ways that don't otherwise occur, such as program flow and data storage.
Resource: ERP software controls the resources of the entire company. Resources include capital (money), personnel, and infrastructure (such as buildings and equipment). While it's common to store data about various resources, interaction between all corporate resources calls for a new level of design.
Planning: This is where the other two parts come together. The individual parts of the overall application include timecards, budgeting, and project planning. To effectively plan, the software must have a historical feature to identify trends. Since the software includes budgets and personnel information, security is quite complex.
Those are only a few of the challenges of implementing an ERP package. One of the largest doesn't have anything to do with technology at all.
Many software installations include only a couple of departments. Some, such as e-mail or Web services, only require the direct involvement of IT. The opposite is true of an ERP implementation. Most often, the business side of the house initiates the project, and IT is brought in later in the game. With the number of resources the project will affect, just about every part of the business has a direct involvement with the implementation of an ERP system, and IT might not be in the driver's seat.
The level of involvement and the number of participating departments makes an ERP implementation very challenging. Add to that the fact that IT normally has free reign over most technical projects (but not here) and you've got the makings for a significant amount of political issues. Expect a lot of meetings and cooperation to pull the implementation together.
SQL Server and ERP
How does SQL Server operate differently with an Enterprise Resource Planning system than with other applications?
Enterprise Resource Planning applications are highly normalized. This means that there are even more tables than in a standard On-Line Transaction Processing application database. Sometimes, many more. In a product like SAP R/3, the number of tables can reach into the thousands!
ERP applications are also network-intense. Since the database model for ERP is OLTP, there are many small transactions. In other OLTP or reporting applications, the data sets are larger and less frequent.
High numbers of users are involved in an ERP system, since it involves so many different departments. Also, because of the number and variety of users, you can expect a more distributed architecture. This means lots of operating systems, browsers, even hardware. In the ERP system at my firm, the clients range from handhelds and phones to PCs and Macs.
Along with the multiple client types at your own firm, you'll probably have to make at least some of the system available to clients and vendors. The security and performance pictures become very complicated when the system has to be opened up to this new audience.
With all these complexities, you'll be glad to learn that you don't have to design the database for commercial products. Of course, if you're rolling your own, you have the design of your life on your hands.
Even if you buy an ERP system, you still need your design skills. Most of these systems are so large that one size does not fit all. This means that most every large commercial product allows a fairly large amount of customization. Most of this customization is done using a tool supplied by the vendor, but in some systems you're still required to design at least views, if not tables. More recently vendor provided tools insulate you from the database layer.
Whether or not you have to design database objects, you'll be involved in the planning for the infrastructure. Here are the various areas you'll need to plan for regarding the database system.
ERP systems vary in the amount of memory they need, but as a rule they implement a structure that buffers as many objects as possible to provide good performance. As with most applications, more is better. The issue comes into play when you get above 3 gigabytes of RAM. At that point you need to make sure you check out the Enterprise version of SQL Server, and pay attention to the options regarding AWE memory.
ERP systems have various levels of complexity. The more complex the logic in the system, the more CPU power is called for to process it. CPU requirements are also dictated a great deal by the ERP system's architecture; if the system is distributed, you can get away with fewer CPU's on the database server. If the business logic is stored primarily in the database, however, you might need more, since the stored procedures and I/O calls affect the CPU load as well.
If the ERP system has several choices for the back end, such as SAP, the processing for business logic isn't normally stored in database stored procedures. This is because the vendor would have to write and maintain several flavors of these stored procedures to take advantage of each RDBMS' platform. Here you're looking more for availability and redundancy than strictly performance from the database server.
Of course you want to consider a full SAN for any serious ERP implementation. The decisions here are affected more by the data set size. Normally in an ERP system the recordsets are quite small, and quite frequent. This means you should optimize your I/O for faster, smaller hits than in a reporting system.
The network is perhaps the most overlooked component of an ERP implementation. Make sure you get an average load per click for the application, and ensure that your network can handle it. We're not talking about user load, since we're focusing on the server, but in how each server communicates. Your vendor should be able to provide this metric, so be sure to insist on it. Network upgrades can be as simple as a new switch, or as complex as a campus rewire.
As you can see, there's a lot to consider in an Enterprise Resource Planning implementation. You should expect to spend a significant amount of "meeting time" and lots of difficult decisions. With proper planning, it can be one of the most rewarding projects a business undertakes. Done improperly, it can adversely affect the bottom line.
CIO has a quick intro to ERP. It's worth looking over.
IFS makes ERP solutions for Europe. Although you might not use their software, this link has a great chart you can use to visualize the various functions in an ERP system.
Really into ERP? These people are.
InformIT Tutorials and Sample Chapters
Laura Brown has a couple of articles regarding ERP. Here's a case study she's done on an ERP system.