The concept of database phenomena

            In recent times I have gone through an article on intranet where it has been reflected in the sense that an artistic method feasible to intranet can be put side by side to a composition process where we can endeavor to construct the roof of the house before we place the underpinning, and we may facade somber problems. Let us dispense the concrete for the foundation of the house before we put in the necessary plumbing for water and sewer access, and have to spend more money than we bulldoze for. We can build a house one footstep at a time and as such we can make certain the house which has a strong foundation. Buildings with strong nitty-gritty tending to a certain period. When we have more or less done with the frame of the house, we build a roof. Although the roof of the house is the top of the structure, we do not stop there. It takes more than a covered frame to make a house. We hire an electrician to do the wiring and bring back the plumber to finish the plumbing. Afterward, we hang plaster board, add insulation, finish the exterior, add fixtures, and before we know it, we have a house that we can call home. We build an intranet in the same way, one step at a time. We can initiate on the intranet is about as glamorous as the water and sewer pipes waiting for the foundation to be poured around them; for just when we are ready to roll back our sleeves and dive into the intranet creation process with both feet, we might discover we need to conduct research, planning, or consider the requirements of the intranet. When we finally flesh out the foundation of the intranet, we start to build the framework. The basic components of any intranet are the hardware and software that make it work. The hardware used in the intranet is focused to determine the way the intranet is operated.

            The software our intranet uses will determine what the intranet is used for. Eventually, we finish designing the intranet, but find we still have to develop the hot Java-powered applications for the intranet. Even when we have completed the design and development processes, the intranet still is not over and done with in order to check the structure of the work for flaws. We make sure we have used the right structure and created the best tools. Once all this is done, we finally have an intranet worthy of the CEO's wholehearted embrace. Try to build the whole house at once and we will be overwhelmed. The same is true for any creative process. When we are building our intranet and its applications, we need to manage many things on a level of general organization and on a more specific level. If we mismanage expectations, our intranet might not turn out as we plan. Our potential anticipation and the opportunity of our superiors might be totally different. Before we start to design the intranet and the Java-powered applications for the intranet, make sure our prospect and the expectations of our administrator network. A good way to do this is to ensure that the infrastructure channels are open and used.

            To make certain that our scheme is a devastating success; we should argue outlook throughout the progress of the intranet, principally as we develop our intranet applications. If we develop a rapid prototype of key applications, our superiors should be the ones to verify that the designs meet their expectations. If the model does not meet their outlook, maybe the prototypes were an example of what not to do, or maybe the expectations of management are unrealistic. If our prototypes meet or exceed the expectations of our superiors, we have a green light and our project is well on its way to a successful implementation. We should also manage our personal expectations for the intranet and its applications. Our expectations play a major role in the success of the intranet. Realistic expectations ensure the success of our intranet. If we perceive the intranet as an impossibly large undertaking, we might cripple by virtue of wide range of knowledge in this regard. If we perceive the intranet as a trivial undertaking, we will not produce the best possible structure and tools for our organization. It is best to find a balance in our perceptions about the intranet. As we begin to design the intranet, keep in mind that the intranet creation process is a team effort. Few individuals will be able to handle all aspects of creating the intranet and its applications. For this reason, we should have an accurate perception of our abilities and know when it is in the best interest of the project to delegate tasks.

            Generating an intranet is exhilarating and demanding and as such we have to break a new ground, making efforts for new things, and carry out research work with a new-fangled request. Managing the intranet is the creation of an amazing process in whatever way some one will motivate us. If one way of thinking about the intranet is not motivating we, change tactics. Do whatever it takes to get the job done. We do not limit a few strategies or stick with one strategy when it obviously is not working. Make a list of strategies. If one strategy is not working, switch to a new one. If we do not have a new one, create a new one. The strategy we use can be very basic. A great strategy to start with is to plan to work on the project every day until it is completed. In addition to this strategy, we should add planning to involve both management and users in the development process. The degree of participation for management and users might need to be adjusted throughout the development process. Our role in the project should be a part of our strategy. Initially, we might want to work closely with the development team. Later, we might discover that our best role is to manage the development at a higher level. Or if we are the top programmer or network administrator, we might find that we need to work on application design rather than the actual programming. Adapting our role as necessary can help the project flourishing.

            When we start working on the intranet design and creation process, one of the first things we should do is develop goals. Our goals should take into consideration the complexities and nuances of the intranet we plan to develop for our organization. Goals should be clear and relevant to the problem at hand. Set major goals relevant to the purpose, scope, and audience of the intranet. Also, set minor goals or milestones for the stages of the intranet development and its applications. Goals and milestones help define the intranet development process as a series of steps or achievements. One major goal could be to complete the planning of the intranet; another major goal could be to complete the design of the intranet. The series of steps necessary to complete the major goals are the minor goals or milestones. Our first milestone will be to start work on the intranet. Another milestone might be to select and purchase the necessary intranet software, such as Web server software, browser software, and a Java Development environment. Our goals are to complete the major steps of the development process, such as planning and design. In designing a constructive intranet system, the intranet designer may create or provide rules that pertain specifically to the intranet's law or scope of control, such as the Information Systems department that will have overall responsibility for the intranet after completion. As we start to create the intranet, these rules might seem perfectly acceptable. However, as we conduct planning for the intranet and its applications, we might find that the overall responsibility of the intranet should be divided amongst the departments that will set up intranet servers. If these early rules cannot be modified to fit the current situation, we will have problems. We might encounter delays due to loss of efficiency or the final product might not be what was expected.

            No rule should ever be considered absolutely and even the best of rules should be interpreted as guidelines that can vary depending on the situation. Rules for a complex project like our intranet should be flexible and make sense. A rule that conflicts with something we are trying to do should be reexamined. The rule might be inappropriate for the situation we are trying to apply it and as such our intranet will never be put into action if we avoid working on it. Putting off work until something is due is a poor practice. Relinquish when things do not go our way or when we seem to have a block is another poor practice. Even if we flourish on cut-off date, sketch to work toward intranet's goals and milestones regularly-every day if necessary and possible. We should also plan to work on the intranet and its applications during those times when our thoughts are not flowing. Everyone has bad days and good days. Some days we take more breaks. Some days we work straight through the day and into the night. We might tend toward other destructive behavior besides avoiding or putting off work. Sometimes programmers go to the opposite extreme. They tear things apart impulsively before letting the work cool off so they can look at it objectively. Never hack our code just because a few users didn't like our application's interface. Managing the aspects of the intranet's design and creation is only the beginning. The next step is to determine the best organization for our intranet. Over the years, three models have developed for information systems like our intranet: centralized, decentralized, and a combination of centralized and decentralized. The three computing models are really driven by the types of computers in use at an organization.

            Following the centralized model, all computer resources are centered in one location and under the management of one organization. When we think of centralized computing, think of mainframes and computer centers. With the introduction of file server and client server computing, most organizations moved away from the centralized model toward a decentralized model. In decentralized computing, computer resources are spread throughout the organization and under the management of the departments in which the computers are located. When we think of decentralized computing, think of the high-power workstations and servers. After the big move to decentralize computer resources and dismantle massive computer centers, many managers had a rude awakening to the anarchy decentralized computing can cause. Let us imagine an organization where each department sets the rules and decides the standards, like what hardware and software to purchase and how that hardware and software should be set up. Then imagine the nightmare of trying to support the gauntlet of software and hardware installed throughout an organization the size of AT&T. Because of a lack of control with decentralized computing, many organizations are moving to the happy middle ground of a mixed computing model. In this mixed model, a centralized Information Systems management sets broad policy, such as the direction and purpose of key computing initiatives, and the individual departments are free to work within those guidelines.

            As we thrash out the accomplishment of the intranet with management, we should consider keeping the three working out models in mind. While our organization might currently use a specific model, we can apply any of the models to the design of our intranet and should egg on administration to prefer the mock-up that wills finest hand round our institute. In an ideal world, the concluding pronouncement will be based on the necessary responsibility and control of the intranet resources. Subsequent a centralized model, a specific department within the organization will be responsible for the intranet. This identical division will be accountable for the setup, design, and administration of our intranet servers. The department will also be responsible for creating the necessary publications and applications based on user requests. With a centralized model, there will usually be a formal approval process for new publications, applications and services. This means that if the Human Resources department wanted an application to track employee files, a formal request would be required. Once the request is approved, the intranet developers would work with Human Resources to create the application. The problem with centralized control and formal approval processes is that they put creativity and timeliness in thumbscrews. Following a decentralized model, each department within the organization is responsible for its section of the intranet. All departments that want to create intranet services will have to set up, design and administer their own intranet servers. Each department will also be responsible for creating the publications and applications used by the department.

            When we can draw on a decentralized model, we hack out the prescribed endorsement procedure for new publications, applications, and services. This means anyone can create intranet resources. Greater freedom and few controls means that new services can be set up quickly by anyone who wants to set them up. This freedom and lack of controls can also lead to abuse of the intranet resources. When someone publishes potentially offensive material or when the usefulness of the intranet deteriorates because so much junk has been created? By adopting elements of both the centralized and decentralized model that fit the needs of the organization, we might be able to balance the need for strict control with our artistic self-determination. For paradigm, we could create an intranet with a centralized Web server that links together departmental servers. The IS staff would be responsible for maintaining the central server and updating links to resources throughout the organization. The individual departments would be responsible for maintaining their own servers. To ensure the intranet is not abused, one person within each department could be responsible for that department's intranet resources.

      The real stars on our intranet are the applications we plan to develop. Still, we will need content for our intranet. Most of our content will be in the form of hypertext documents that are served by our Web server and displayed by our chosen Web browser. As we consider the type of content we want to publish on our intranet, think about how we will organize that content. We can organize hypertext documents in many ways. The structure that is best for a particular document depends on the complexity of the material we plan to present. For a small document with limited complexity, a simple structure is often best. Simple structures include linear and linear with alternative paths. The simplest way to structure a hypertext document is in a linear fashion. Using a pure linear structure, we can create a hypertext publication with a structure resembling a traditional print publication. Readers move forward and backward in sequence through the pages of the publication. An alternative path structure gives readers more options or paths through a document. By providing alternative paths, we make the structure of the publication more flexible. Instead of being able to move only forward and backward through the publication, readers can follow a branch from the main path. In a linear structure the branches will rejoin the main path at some point. The hierarchical structure is the most logical structure for a publication of moderate complexity. In this structure, we organize the publication into a directory tree. Readers can navigate through the publication, moving from one level of the publication to the next, more detailed, level of the publication. They can also go up the tree from the detailed level to a higher level and possibly jump to the top level.

            The information bank tree intimately look a lot like the way we store files on our hard drive in a main directory with subdirectories leading to files. We could also think of the hierarchy as a representation of an actual tree. If we invert the tree, the trunk of the tree would be the top level of the publication. The trunk could be the overview of the publication. The large boughs leading from the trunk would be the next level of the document structure. The boughs could be chapter overview pages. Branches leading from the boughs would be the next level, or the pages within chapters. A combined linear and hierarchical structure is one of the most used forms for hypertext publications. This is because it is an extremely flexible, but still highly structured method. Readers can move forward and backward through individual pages. They can navigate through the various levels of the publication by moving up a level or descending to the next level. They can also follow parallel paths through the document. The most complex structuring method is the integrated web. This method lets the reader follow multiple paths from many options. This is a good method to use when we want the reader to be able to browse or wander many times through the publication we have created. Each time through the publication, readers will probably discover something new. After considering the various styles for hypertext documents, we should examine the various tools we will need to develop the intranet. A tool is anything that supports the task we are working on. The tools for unleashing the power of our intranet are based on the existing tools for the Internet itself, which includes protocols, resource tools, and information services. TCP/IP (Transmission Control Protocol Internet Protocol) is the foundation of the worldwide Internet. We must install TCP/IP on our network to enable intranet services. A protocol is a set of rules for programs communicating on the network. It specifies how the programs talk to each other and what meaning to give to the data they receive. Without TCP/IP setting the rules for our network communications, we cannot use Internet technologies. The good news is that if our organization already has access to the World Wide Web; we might already have the necessary TCP/IP structure in place. Additionally, TCP/IP is built in to some operating systems, including Windows 95, Windows NT, and most variants of UNIX. If we have an operating system where TCP/IP is not built in and do not have TCP/IP installed, we will need to purchase TCP/IP software. Fortunately, TCP/IP software is widely available from software vendors.

            An intranet without Web services is like a world without water. The key to the World Wide Web is the hypertext transfer protocol. HTTP offers a means of moving from document to document, or of indexing within documents. Accessing documents published on our intranet involves communications between browsers and servers. In a browser, such as the Netscape Navigator, the HTTP processes are virtually transparent to the user. All the user really has to do is activate links to move through our Web presentation. The browser takes care of interpreting the hypertext transfer commands and communicating requests. The mechanism on the receiving end, which is processing the requests, is a program called the Hypertext Transfer Protocol Daemon (HTTP). A daemon is a UNIX term for a program that runs in the background and handles requests. The HTTP daemon resides on our Web server. Before setting up or installing server software, we must determine what platform the Web server will run on. Until recently, our choices were limited, but this changed rapidly as the World Wide Web grew in popularity. Today, Web server software and server management tools are available for almost every platform. And, like other software developed for use on the Internet, this software is available as freeware, shareware, and commercial software. We will find that UNIX platforms have the most options for server software. Until recently, there was only one good choice for the Windows NT environment, but this has changed. There are now many excellent commercial and freeware choices for Windows NT. For other platforms, there is generally only one choice in server software. Having only one choice of server software for the Windows system which doesn't mean the quality of the server software is poor. Quite the contrary, the quality of the software is often quite good. Tools are an essential part of any operation. Resource tools provide the means for sending and retrieving information. There are three basic tools of intranet working:

            Electronic mail is a great way to communicate. Think of e-mail as a way to send letters to anyone within the company instantly. Many e-mail programs enable delivery of mail to single users or groups of users. Some e-mail programs even provide ways to automate responses. Most browser packages are packaged with e-mail software. File transfer protocol provides the basic means for delivering and retrieving files around the network. The files can be text, sound, or graphics. FTP provides a springboard for many information-based approaches to retrieving information. Many higher level tools that have friendlier interfaces use FTP or a protocol similar to FTP to transfer files. Just about every browser currently available supports FTP. Telnet lets our intensive log into another system and browse files and directories on that remote system. Telnet is valuable because it is easy to use and basic to the network. When we telnet to another computer, we can issue commands as if we were typing on the other computer's keyboard. On some platforms, like UNIX, telnet is a built-in resource. On other platforms, we will need a telnet tool. The basic resource tools are indispensable when used for the purpose that they were designed for. They even provide the fundamental basis for many high-level resource tools, but they simply weren't designed for the advanced manipulation of the wealth of information available on the Internet. This is why dozens of information resource tools have been designed to manipulate networked data.

            At this juncture, there will be a list of high-level resource tools we might want to use on our intranet: A system to automatically gather, index, and serve information on the Internet. Archie is a great tool for searching our intranet's file archives. Once we set up Archie services, users can access Archie resources with their browser. A distributed information service that enables us to move easily through complex webs of network resources. Gopher uses a simple protocol that enables a Gopher client to access information on any accessible Gopher server. Most browsers directly support Gopher. An automated mailing list distribution system. Users can subscribe to LISTSERV lists we set up on the intranet, which enables them to read e-mail posted to the list or to post e-mail to the list. Once we set up a LISTSERV server, users can join lists and participate in lists using standard Internet e-mail software. Most browser packages include e-mail software. A bulletin board system of discussion groups called newsgroups. Users can participate in newsgroups posting messages to the group and can read messages posted by other newsgroup members. Once we set up a newsgroup server, users can browse newsgroups and post information to newsgroups using a newsgroup reader. Most browser packages include a newsgroup reader. A distributed information service for searching databases located throughout the network. It offers indexed searching for fast retrieval and an excellent feedback mechanism that enables the results of initial searches to influence later searches. WAIS servers are best accessed via CGI scripts, which allow users to search databases using their browser. Using HTML development tools, we can quickly and easily create HTML documents for our intranet. HTML editors have features similar to our favorite word processor and enable us to easily create documents in HTML format. Typically, these editors enable us to select HTML elements from a pull-down menu. The menu has brief descriptions of elements we can add to the document. The editor places the element in the document in the proper format, which frees us from having to memorize the format. When creating complex forms, we 'all find HTML editors especially useful. HTML templates enable us to add the functionality of an HTML editor to our favorite word processor. The great thing about templates is that we can use all the word processor's features, which could include checking grammar and spelling.

                        In view of the above, it is evident; knowledge on the structure blocks for creating a perfect intranet is only the first step toward implementing our intranet. Our intranet will require content, which can be well thought-out in a diversity of approach and shaped with a variety of co-worker applications. We will also necessitate setting up basic networking protocols, like TCP/IP, and services like the WWW. Once we have selected the basic tools we have to create the intranet and measured how we will organize it, we can chart it all the way through achievement. More importantly, we 'all are using the familiar features of our word processor to add HTML formatting to our documents. Although the task of creating HTML code is fairly complex, some helper applications called converters try to automate the task. HTML converters convert our favorite document formats into HTML code and vice versa. At the touch of a button, we could transform a Word for Windows file into an HTML document. Converters are especially useful if we 're converting simple documents and are less useful when we 're exchanging documents with complex law its.