If knowledge is power, connecting a database to your intranet is probably one of the most empowering decisions that you can make to enhance and extend the functionality of your internal site. Throughout history-and especially in the fast-paced world of modern business communications-information (or lack thereof) has been the single most important factor in determining whether a particular company prospers or declines in the face of stiff competition. This being the case, it's extremely important that everyone supporting your company's business objectives-from the chief executive officer all the way down to the administrative assistant's assistant-be fully informed on every issue that will affect them in the performance of their duties. From product feature updates and revised production plans to customer contact lists or internal supply requisitions, an intranet database will help your employees to become more effective in their positions, increase customer satisfaction with your improved performance, and will, in general, make life a great deal easier for all involved in the day-to-day operation of your organization.
In this chapter, you will learn about some of the newest and most powerful database technologies that will be shaping the way both the Internet and your corporate intranet will evolve over the next few years, and how you can strategically develop your database "game plan" to maximize the benefits that these new technologies will provide. You also examine the important issues that you should take into account when including a database system as a major component of an intranet and look at how some of today's major intranet players have incorporated database systems into their individual sites.
This chapter is designed to guide you through the myriad options available to you in the database world-without all the hype generally associated with high-profile marketing plans that most often surround the really exciting and powerful intranet products. You'll be able to make educated decisions rather than seat-of-the-pants guesses, which means that you'll save yourself a good deal of research time and stress, and you'll (most likely) be able to deliver a much better product for your company. Remember that although a database system can ease any number of intranet tasks-from product distribution to scheduling to purchasing-you'll need to make sure that you don't misjudge your company's needs in the database arena, or you'll risk implementing either a low-end and ineffective database solution or an overly powerful and financially prohibitive debacle that can affect your company's communications efforts considerably. Keep in mind that although a database can effectively complement the balance of your intranet's resources, you must be extremely careful when utilizing this technology for sensitive or mission-critical data.
When you're evaluating your company's need for one or more of the many database systems available to you as core components for your intranet, you should realize that although each package is in its most pure sense a traditional database system, in reality the specific features that extend each particular program's functionality can be quite different, resulting in highly differentiated database systems. Familiarizing yourself with the various specialties presented by the different systems is therefore essential. Otherwise, you risk implementing a project that is doomed right from the start due to an inadequate or insufficient technological foundation. Although high-end database systems offered by Informix or Sybase are right for transaction-heavy or extremely data-laden intranets, you may find that more conservative packages such as Paradox or MS Access are both more affordable and practical in light of your particular intranet's needs.
If you've begun to consider whether the database route is the proper choice for your intranet, you've taken the first step in an important process that can ultimately influence how well your system is able to service the needs of your corporation. Generally, three central reasons or goals can serve as adequate justification for involving a database in your intranet design. The first is the ability to search quickly through large collections of data to find specific, relevant, and identifiable sections with ease, as you can see in the process shown in Figure 28.1. If your employees need to locate a customer's purchase order, find out about the status of an office supply requisition, or simply learn about the company's latest changes to the health plan, for example, a database is an excellent way to catalog such data, because important characteristics such as keywords, table fields, and other factors can easily be included in a Web- or intranet-based search system.
A second important goal that relies heavily on an effective database integration is the ability to change, add, or update an important company database from a number of locations, as shown in Figure 28.2. In this case, you are not dependent on having physical access to the machine that hosts the database. This capability is of tremendous importance if your business has a large number of sales or service representatives who need to update the company on sales, requests for parts to be shipped, or any other data that can affect how well your company is received in the business community. Using a database and the appropriate gateway, your employees can update sales records and projections, update customer contact information, and keep support and supply personnel informed of their every move, ensuring that everyone's needs are satisfied. In today's fast-paced and demanding business environment, presenting good news or bad news is acceptable, but surprises are no longer tolerated. With your employees able to update all your important records from their desks or their hotel rooms (or even that greasy spoon on I-70) via a Web browser, you'll be in the best position possible to serve your customers' every need.
Figure 28.2: Intranet databases allow for the remote update of mission-critical information.
The third important need that a database system can service is an extension of what you've just covered, which is the need to provide timely, dynamic data to those employees who service your customers and in general facilitate the day-to-day operations of your organization, as shown in Figure 28.3. Just as a database can help your employees keep your records up-to-date, it is equally important that the information be made accessible in an easy, fast, and powerful fashion to those employees who depend on that data to make material decisions about purchasing needs, sales and repair requests, or scheduling issues. With this need taken care of, your entire corporate operation should, hopefully, proceed in a more fluid, reliable fashion because all employees have sufficient data (that's easily accessible) with which to do their jobs.
Now, just because I haven't mentioned the particular goal that your intranet database is anticipated to resolve, don't take that to mean it's not equally valid to the issues that I've presented. Because these applications of database technology are prevalent within modern intranets, however, taking a second look at your plans before you proceed may be a good idea.
Unlike some of the more exotic and nascent technologies that have come to the forefront of the intranet development scene, database systems have been around for some time. As a result, you've got a wealth of information available to you both in a variety of print publications as well as on any number of company-sponsored or third-party Web sites. Be sure to check these sites for up-to-the-minute developments, upgrades, and technical or implementation advice. Remember, although I can introduce you to some of the more popular and well-known systems that site and database administrators are using today for intranet development, you should put a good deal of thought and research into other options that may have surfaced since this book went to press. Or perhaps you should investigate other avenues that may be tailored more specifically to the particular needs of your organization. As always, you also should feel free to explore new and creative applications within your intranet for the emerging database technologies, and be sure to stretch the design limitations from time to time. With necessity being the mother of invention, you may be surprised at what your design challenges and a bit of inspiration provide!
As database systems have evolved and become more feature-laden and function-specific, your need to understand and appreciate the roles of each individual feature within the scope of your development efforts has become increasingly vital. The initial temptation of many intranet designers is to focus all their effort and energy on one primary (and trusted) database, say Borland's Paradox for Windows, and remain centered on that particular system throughout the life cycle of the internal site. This occurrence is common and understandable-database administrators like to work using the tools with which they are most familiar. Doing so, however, can cause huge headaches not only for your users (your employees) but also the people who depend on your employees for timely, accurate, and near-instant information (generally referred to in business terms as the customer). Depending on any number of factors-from the number of users accessing the system, to the type and amount of data included in the database, to your anticipated hardware or operating system combination, or any of a host of other factors-the database that you select to support your intranet may be the deciding factor in the success or failure of your corporate intranet experiment. Your particular needs may very well turn out to require a heterogeneous mixing of the available database tools and resources to implement your site successfully. Perhaps you need a high-end SQL server for the back-end tasks, working in concert with Web-based clients for general access and some PC-based clients for administration, upkeep, and so on. Make sure that you define the role of your database prior to deciding on your particular system, though, and spend enough time getting a feel for the anticipated usage patterns and your users' needs before you commit to any one technology. By thinking these issues through beforehand, you'll end up saving yourself a lot of time, energy, and frustration. At the same time, you'll end up with a much better intranet for your investment.
In the next few sections, I cover some of the key database resources you may want to consider for your intranet, including Informix, Sybase, Oracle, Microsoft SQL Server, and Paradox for Windows. I also discuss some of the more advanced issues that you need to take into account when providing access to any amount of data via the Web or an intranet. Finally, I showcase a number of powerful and emerging roles that companies have discovered for database systems when included as part of a corporate intranet, and hopefully stimulate your thinking for your own site.
When you're selecting a database system to integrate into your intranet, you should know a bit about the various options available to you. The following sections cover some of the more popular and powerful database systems available today, so you can be in the best position possible when you make your selection.
High End
Informix
Sybase
Oracle
Microsoft SQL Server
Middle
Paradox
Microsoft Access
Low End
Flat file
Informix's strategy revolves around an object-oriented database and program language. Informix rewrote all its base engine from scratch in 1991 following its purchase of Illustra, a company specializing in modeling and navigating complex data. Informix has always been a strong RDBMS vendor, and its latest move could lead to a breathtaking jump over the competition. The Illustra technology will be fundamental to Informix's new capabilities on the intranet. Specifically, Illustra adds support for complex objects, such as video, audio, and images. And, as I said before, they are critical pieces of the strength of the intranet.
Informix plans to expand the Dynamic Scaleable Architecture (DSA) of the Informix engine and merge it with Illustra's object-extensible architecture. The DSA-enabled engine specializes in parallel processing, enabling Informix to perform well in the face of increasing data loads. The database can create multiple threads on different processors to keep a consistent level of performance. This characteristic describes how scaleable a database is. Informix is providing the relational of the ORDBMS, whereas Illustra is providing the object component.
Lastly, through Illustra, Informix's Universal Server (available by the end of 1996) will have the ability to use DataBlades. DataBlades extend the functionality of the database by providing an object-oriented programming interface. The Web DataBlade, for example, allows users to create and maintain HTML-based Web pages that can be deployed against the Universal Server.
For more information about Informix's intranet strategy, visit their home page at www.informix.com.
The Sybase family of intranet-applicable database products revolves around their System 11 suite of applications. When utilized in conjunction with other intranet technologies, Suite 11 can provide for an extremely powerful corporate communications resource. Sybase has gone to great lengths to ensure that the System 11 line is capable of handling the most rigorous intranet data-handling tasks, while simultaneously maintaining high degrees of scalability and performance that are essential in today's information-sharing world. System 11 encompasses all the Sybase database family, including SQL Server 11, Sybase IQ, Sybase MPP, and SQL Anywhere. Sybase's popularity and functionality are due to its core database-engine architecture, which is comprised of fully multithreaded, fully symmetric VSA engines that are capable of controlling and manipulating memory, I/O issues, and various other tasks that have traditionally amounted to bottlenecks for other systems, resulting in greater performance and fewer headaches for database or intranet administrators. Further, unlike other systems that require very specific combinations of hardware and software to achieve optimal performance, SQL Server 11 can function with great utility on any number of platforms with varying configurations, from 12MB single-processor systems to large-scale SMP systems with 12GB of RAM, which gives you great flexibility when integrating System 11 with your current system, as well as allowing you any number of options when considering future expansions.
SQL Server 11, the central component of the system, has been optimized for the sharing of data among a large number of concurrent users, which is an excellent benefit if you plan to implement your intranet in a large user environment. Traditionally, multiple users attempting to access the same areas of information within the database simultaneously had a great impact on system performance, resulting in slow access and frustrated users. Sybase engineers have spent countless hours analyzing hardware, software, and usability factors, however, to determine the most efficient methods of dealing with this problem. As a result, SQL Server 11 is a fully scaleable RDBMS that can take advantage of every aspect of your system, from CPU and RAM to other hardware resources to serve data at exceedingly fast rates.
For more information on the System 11 suite of applications, visit www.sybase.com.
Sybase SQL Server 11 System Requirements
Available for most major UNIX platforms
Windows NT Server
15MB of RAM for SQL Server
48K of RAM per additional user
6MB of disk space to store system software
Oracle, a company that has long been known for its superior database systems, has taken the data-serving needs of the Internet and intranet community into account when designing its latest product, the Oracle Universal Server Suite. The Oracle Universal Server Suite consists of an integrated server, client, and systems management package that have been specifically designed to lessen the design and development cycles that are usually involved in deploying such complex systems; these products are designed as installation-ready and are known to be compatible for almost any use. This is a tremendous advantage for your organization, in that your technical design team can focus its attention on designing functional, full-featured, and robust solutions to your particular needs rather than waste valuable time determining the constraints that your particular combination of software packages imposes on your systems.
Sporting an engine based on its popular Oracle7 Server, the Universal Server Suite has been specifically designed to provide for fast, effective, and powerful integration between your database services and the Oracle Web Server, which lets you get up and running without much hassle. Further, because your data is most likely going to be mission-critical to your organization, it is good to know that the Universal Server Suite has a host of recovery features that maintain and protect your data even in the face of some of the most damaging system failures.
For more information on Oracle's intranet database solutions, visit their home page at www.oracle.com.
Oracle Server System Requirements
Solaris or Microsoft Windows NT
100MHz Pentium processor
64MB of RAM
2GB hard disk space
Oracle Client System Requirements
Windows 95 or Windows NT graphical environment
16MB of RAM
500MB of disk space
Web-based tools require an HTML 2.0-compliant Web browser.
As with almost every other product and service offered by Microsoft, their flavor of the SQL Server has been designed in part as a stand-alone application, but one that is immeasurably enhanced and extended by the functionality of other Microsoft-brand products. (Microsoft hopes that this move will ensure user loyalty and dependence on the software giant.) This means that if you've installed the MS-Internet Information Server (IIS), SQL, and other MS products, you're in a favorable position to design and implement complex intranet systems easily due to the inherent compatibility across the Microsoft suite of applications. Again, this capability is great if every legacy application you've installed was built by Microsoft. If, however, you're dealing with a mix of applications, services, and systems (as in most situations), you're not necessarily at a disadvantage. Microsoft-in trying to convince each and every IS manager to migrate to MS products-has developed a number of software packages to ease the integration of legacy database systems into Web-based intranets, using systems such as Microsoft TransAccess or Information Builders Inc.'s EDA/Open Database Gateway. These systems are fully compatible with MS-SQL and allow your design team to incorporate previously inaccessible data sources into your intranet.
The MS-SQL server is a powerful ally in your efforts to publish real-time information and provide interaction and customization for resources made available to your organization via an intranet. Microsoft's "Active Internet" strategy has evolved with corporate communications in mind. In conjunction with this "Active Internet" strategy, Microsoft has invested considerable time, effort, and financial resources into the development of their ActiveX technology, which is a robust and rather impressive mixing of technologies that will allow users to create and maintain interactive content using a number of software components, scripting languages (see Chapter 34, "Intranet Tools," for information on Microsoft's Visual Basic Script), and other currently available Microsoft applications by embedding them directly into either static or dynamically generated HTML pages. If you're familiar with OLE Controls, the ActiveX technology may seem somewhat familiar because a major component of the ActiveX resource is based on the data sharing that has previously been facilitated by OLE.
Organizations developing and deploying intranet applications will benefit from the same proven technologies that have historically provided MS-SQL with an important role in the corporate database arena-user and application security, data integrity and concurrency controls, data stream encryption, data replication, and transparent distributed transactions.
For more information on MS-SQL 6.5 and its potential for your corporate intranet, visit the Microsoft home page at www.microsoft.com/sql/.
Because some of the database systems that I've already covered may be out of your company's reach due either to technical or financial constraints, there remain some powerful yet somewhat more conservative routes for you to explore, which may be equally as acceptable as the "power" systems. In the following section, I talk about one of the "middleweights" in the database field, Borland's Paradox 7.0, and how it can play an important role in the development of your intranet database system.
Borland's 32-bit Paradox 7.0 is a great improvement over earlier versions of their database package, which is impressive considering that Paradox has always been a multifunctional and useful addition to a corporation's suite of IS tools. Version 7 functionality is extended from earlier versions through a number of features intended to ease database creation, maintenance, and the eventual dissemination of your collected data. This is accomplished through the addition of many "experts," which are essentially automated processes that help you create tables, produce reports or data entry forms, perform mail merges, and import data from other sources. These capabilities can be helpful if your company deals with data from different vendors or currently utilizes multiple types of database technology within the office. Further, if you plan to migrate to a single, new database technology when you implement your intranet, Paradox can convert almost all your legacy database types into viable sources for continued use. Paradox also supports a variety of the major business application suites that are currently available (including Microsoft Office and Perfect Office) so you can easily share data among a host of applications. Additionally, with the new Paradox MS-Exchange/MAPI support, you'll also have the option of distributing some or all of your data via e-mail, which can serve as a fail-safe in the event of a Web server crash.
Paradox 7.0 System Requirements
Intel 386DX PC or higher
Microsoft Windows 95 or Windows NT 3.51
8MB of memory (12MB recommended) for Windows 95
12MB required (16MB recommended) for Windows NT
Hard disk drive with 13MB for compact installation; 30MB for typical installation
One floppy disk drive or CD-ROM drive
VGA or higher resolution monitor
Mouse or other Windows pointing device
For more information on Paradox 7.0 and other intranet solutions offered by Borland, visit their home page at www.borland.com.
For small- and medium-sized intranets, the issues of distribution and replication are not primary concerns. As the intranet grows, however, a new set of management demands will be placed on the organization, and distribution and replication can be implemented to help relieve intranet expansion woes. The question of data efficiency has been widely asked in the information community. Frequently asked questions are, "Where should data be stored?" and "How should we model the relationship between data and users?" The usual answer tells you that data should be close to the source and close to the users who need it. So, if a user in New York uses and updates a database daily, while a user in California uses the same database only once a month, it seems obvious that the physical data should reside in New York, "close" to both the primary user and the primary source (or maintainer). In the same way, database designers think about where data should be stored. Most often, they choose the techniques of distribution and replication to achieve this end.
To distribute your data means to spread it out over more than one source. Distribution could be used to describe one database running on five machines or a table that is half on one database and half in another. In the former case, I mean to say that the five machines act as one virtual machine, so each is a vital component of the single database. In the latter case, the databases are the source of different data (rows) of the same table. A California database, for example, has only California-specific information, and a New York database has only New York-specific data. Note that the data is not duplicated; it exists on the source server alone. If you build a Web application on the intranet to display available items for purchase, the application would query the New York and California databases independently and display the resulting items side-by-side inside the browser.
Almost ironically, a basic premise of the intranet is its distributed architecture. Because the intranet works mainly through pointers (or links), the information inside the intranet is loosely connected by default. Distribution issues usually occur at the WAN level, where network or system bottlenecks between remote sites have a negative impact on overall performance of the intranet. The primary concern of keeping frequently updated data close to the source must be balanced with the need for users far from the source to access the data in a timely manner. The latter requirement brings replication into the picture.
Replication is somewhat complementary to distribution because it simply aims to duplicate data strategically to improve query speed. Good replication strategies try to take advantage of the inherent nature of the type of data access. Replication can be done on a whole database (often called mirroring) or can be done table-by-table. Microsoft, for example, often mirrors its Web servers because of the sheer volume of connections it must contend with in a given day. A large intranet might face the same problem.
Replication is also used when remote users do not have acceptable access times to the source database. In this case, a user might want a summary of financial data from five different international regions. The time to connect to each region varies with amount of network traffic, and so the user might get information on three regions quickly but have to wait a long time to get the updates from the other two regions. One solution might be to collect all the regions' information at night and transmit a whole replicated snapshot of the five regions to a database server near the user.
The preceding solution works well if the user can accept only a one-day view of his or her financial summaries. If a more frequent update sequence is needed, the replication flow must be altered. Most replication-enabled DBMSs can also update dynamically, allowing the database administrator to set a "window" in which remote servers are updated. In the preceding example, the five regional servers could be told to send updated information every two hours to the database near the user. Ideally, this approach would solve the user's problem, but there is still a chance that two hours would not be enough time for one of the regions to update its data completely. In this case, the user would have the most updated view, but one region would be at least zero to two hours out-of-date.
Replication is tuned according to average network availability because it is bandwidth driven. High network availability allows for smaller replication "windows," so data can be transmitted more frequently. If a network is very crowded, replication speed must be slowed, or uncompleted requests might store in a queue for later delivery. In this latter case, the low network availability would cause a bottleneck of old data requests pending, forcing the user to wait longer for the update.
To help summarize and provide you with a few more examples, Table
28.1 summarizes the four basic types of data access.
| Distance to Source | |||
| Close (or local) | |||
| Far (or remote) | |||
Type I data is categorized by a database close to the users who update it the most frequently. Most often, the data can stay in its current position because network speed is less of a factor when the data is close to the source. In certain situations, however, replication might be employed. Consider a group of users who are making updates to only a small section of a large database but need a short turnaround time to show the updated data quickly. Possibly, the large database server is slower because it must deal with requests for many different databases. In this scenario, you can replicate the parts of the database the user group needs and let them manipulate the data on another database server dedicated to them. This way, the group can make timely selects, inserts, or deletes and get results back quickly. Scheduled, batched transactions containing updates could be sent back to the central server. Because this group is also made up of the primary users, there is a smaller chance that other locations would send transactions that would have to be reconciled (possibly causing rollbacks).
Type II data is the most difficult to model because the data source is far away, but the update frequency is high. Often, you must employ a replication strategy to give remote (far) users good access time to the database. Replication ultimately incurs more overhead, but this type of situation leaves few options available, except possibly the installation of a very high-speed communications network (for example, thick fiber). The situation is much like that described for Type I data, except that the chance for out-of-sync data used by other clients is increased by the longer time the updated data needs to travel to the source. In some circumstances, data from the central server can be moved to the remote server, thereby redistributing the data to a new source. The central server then receives replicated "copies" of the data from the remote server.
Type III data is the simplest to address because it deals mostly with clients who want to perform read-only query operations. In other words, they call up information but do not update it often. Because they are close to the data source, access time is good and reconciliation (because of conflicting updates) is avoided. Data can be left distributed.
Type IV data is the same as Type III, except that the clients are remote. A replication technique is best used here because the clients want only read-only query access and do not update frequently. The only problem is a speed constraint (caused by being "far"), which is solved by replicating the portions of the database the clients need.
If you're planning an intranet, you need to consider where data should be stored. An obvious choice might be to take all the company's data and load it into a central Web server. This solution might work well if the organization is small or medium-sized, but one machine might not be able to hold the corporate directory profile if the employee count goes above 50,000. Or perhaps the company's accounting department is off-site and takes longer to upload its data to the central Web server. Managers might see a page with up-to-date project deliverables but out-of-date financial data. Deciding where to store data is a critical analysis phase of intranet database deployment. Designers should look at business needs first and then determine data size, data longevity (how long data is good before it needs to be updated), and data availability (what percent of the time data must be accessible). This equation is often not simple to estimate, and one point to consider is the miniature replication of data the intranet or Internet tends to lead users into.
Most users like to save a copy of the information that they are viewing when it interests them. Others download files for offline examination. Either way, information is being duplicated from the server to the local computer. This duplication might be okay for getting device drivers, recipes, or birth dates, but it is probably not okay for corporate directories or current price lists. The former data is more or less static in nature, and keeping a local copy, while using valuable disk space, is not completely critical to the accuracy of the data. However, dynamic data, like directories or price lists, should be retrieved from a Web server at the time of need, except for exceptional circumstances. The reason the dynamic data would be put on an intranet would be to keep it up-to-date. If users keep local copies to access instead of using the data contained on a Web page, they risk the chance of having "old" data whenever the Web page is updated. The need for proper training is highlighted in this example. The best system will fail if users cannot shift mental gears to adapt to a new environment. Intranet architects need to be aware of how users' occupy their local hard disk space, trying to keep dynamic data at the source, while encouraging users to be cautious about making multiple local copies of data that can be accessed almost any time.
Last, choosing a database vendor who is committed to efficient distribution and replication handling is a prudent choice when you're examining individual databases. Informix, Oracle, Sybase, and Microsoft are all committed to enhancing their product offerings as the economics demand. Although Sybase was first to get a stable replication technology to market in 1993, Informix might be better poised to take advantage of its object-oriented extensions to perform object-based replication. Microsoft bundles a mid-level replication service free with SQL Server 6.0 and 6.5. As OLTP (online transaction processing) moves to the Web, Web servers that rely on files or flat databases will not be able to perform adequately. Often people buy a product without ever examining all its features because they are not of use at the present time. Replication might be one those features, but be sure to evaluate it when selecting your database back end.
Now that you've had an opportunity to review some of the tools and other options that will enable you to integrate a database with your intranet, it's time to discuss some of the many different approaches that your company can embrace when searching for ways to enhance your site's functionality with a database. Granted, if you've come this far, you've probably got at least an inkling of an idea in mind for what you want to accomplish with your new system. Keeping tabs on what the competition is up to with their information systems design is always a good idea, mostly because you don't want to let them get ahead of you in the industry due to a superior corporate information-services infrastructure, but also because you can occasionally pick up a great idea or be inspired by what other companies are attempting to implement.
A number of great sources for information on intranet design are available; many of them deal (in varying degrees) with the topic of database integration and give examples of how real-world companies are utilizing the technologies. One of the best sites to visit is located at Netscape:
home.netscape.com/comprod/at_work/index.html
where you can learn a great deal about intranet database technology through intranet "white papers," demos of intranet technology, and examples of what is en vogue in the corporate intranet scene. (For information on implementing scheduling, see Chapter 36, "Group Scheduling.")
With companies growing, diversifying, and downsizing (often simultaneously these days)-all the while in need of excellent service and productivity-your employees must be able to locate valid and complete contact information that they can utilize to collaborate with colleagues or to touch base with important clients.
A great example of contact information enabled by an intranet database was developed by AT&T. As a huge corporate entity with an employee count in excess of 300,000, the days of utilizing paper-based or static HTML as a medium for distributing contact information throughout its various departments was rapidly drawing to a close. Taking advantage of new technology to save time, effort, and money, AT&T has implemented an intranet database with an HTML front end, allowing for fast searches of the entire company directory based on employee name, address, title, department, or other indexed information. And because the information is easily found within the system, it also has significantly eased the burden of updating more traditional systems, such as paging through any number of huge, static HTML files to find the proper record to update.
In today's helter-skelter business environment, the salesperson who can satisfy a client's needs first (and most effectively) is the one who usually walks away with the sale. This is by no means a revelation that has occurred because of the integration of high-tech systems into the work force. With the introduction of these systems as integral parts of your business plan, however, you can make certain that you're always in a position to react instantaneously to the needs of your clients-any time, anywhere.
Consider John Deere, for example. To empower their employees, John Deere has implemented a parts database that contains not only images of the various mechanical parts that they offer for sale, but also provides specific data on each individual part, from dimensions to instructions for assembly and repair, and so on. This database enables purchasing, sales, and service representatives to access comprehensive information on John Deere products when seeking quotes from vendors, offering sales packages to customers, or verifying orders from the field for service requests, once again allowing for streamlined operations.
Another area in which companies are turning to the Web, intranets, and database technology for assistance is in tracking employee assignments and the subsequent hours spent in servicing each particular task. Currently, companies use a dazzling array of technologies (or, perhaps, antitechnologies) to accomplish this goal: time clocks with punch cards, handwritten tables, Excel spreadsheets, phone reporting, and Lotus Notes interfaces. All of these technologies accomplish the basic task of recording hours but leave much to be desired in terms of data accessibility, flexibility, and overall use to the organization past the simple task of paying the employee.
An intranet-based time-tracking system holds a number of advantages for a company and its payroll office. First, as the information is stored within a database, users can handle it more easily than searching through dust-covered records from previous months, weeks, or even years, hoping to come across the appropriate file. This also means it's easier to store large numbers of past time data and will save quite a bit of space in the office storage area. Second, hours can be submitted and tracked on a daily basis rather than on a weekly or biweekly schedule, as a normal time-card submission would allow. This way, project managers, accountants, and other management personnel can have a more complete understanding of their employees' progress and the state of current projects; they also can more accurately target areas for improvement in their employees' development cycle.
One of the most limiting factors to a successful business is not having the proper resources on hand with which to complete your duties. Whether employees are in need of an expensive computer platform, chemical solutions, or even a box of paper clips, an intranet database can play a vital role in ensuring that employees have near-instantaneous access to whatever item or service is needed. Using a Web interface, employees can browse through the inventory of in-house products and supplies, submit a request that certain items be sent to their location from the master supply room, or-if the company has run out of widgets-can request that the office manager order more.
Now that we've covered the basic-and not-so-basic-ideas, tips, strategies, and rules of thumb of intranet database systems, you've got a bit of work ahead of you. Even as this book goes to print, many of the companies responsible for some of today's most powerful and effective database solutions are developing and releasing new systems, updates, and options at a breakneck pace, which means that you'll have to use your own knowledge, understanding, and instinct if you want to move beyond the scope of what this chapter has covered. However, despite the introduction of newer, more powerful software and faster, more exotic hardware, the underlying concepts and issues involving the integration of database systems into corporate intranets remain basically the same.
From the various high- and middle-end database systems to the many creative ways in which various information systems professionals have melded such systems into highly effective resources for interoffice and intraoffice collaboration, it's clear that the role of the database in the workplace is no longer limited to a small set of complex, user-unfriendly tasks-nor is it solely the realm of your systems administrator. Rather, with the advent of the intranet, database systems are expanding into a new frontier in which they can flourish as centralized information-sharing tools.