The concept of designing a database

There is no denying the fact that Computing technology has made a permanent change in the ways businesses work around the world. Information that was at one time stored in warehouses full of filing cabinets can now be accessed instantaneously at the click of a mouse button. Orders placed by customers in foreign countries can now be instantly processed on the floor of a manufacturing facility. Even though 20 years ago much of this information had been transported onto corporate mainframe databases, offices still operated in a batch-processing environment. If a query needed to be performed, someone notified the management information systems (MIS) department; the requested data was delivered as soon as possible. In addition to the development of the relational database model, two technologies led to the rapid growth of what are now called client/server database systems. The first important technology was the personal computer. Inexpensive, easy-to-use applications such as Lotus 1-2-3 and Word Perfect enabled employees (and home computer users) to create documents and manage data quickly and accurately. Users became accustomed to continually upgrading systems because the rate of change was so rapid, even as the price of the more advanced systems continued to fall.

The vital decision for a database designer, after the hardware platform and the RDBMS have been preferred, is the structure of the tables. Decisions made at this stage of the design can affect performance and programming later during the development process. The process of separating data into distinct, unique sets is called normalization. The next important technology was the local area network (LAN) and its integration into offices across the world. Although users were accustomed to terminal connections to a corporate mainframe, now word processing files could be stored locally within an office and accessed from any computer attached to the network. After the Apple Macintosh introduced a friendly graphical user interface, computers were not only inexpensive and powerful but also easy to use. In addition, they could be accessed from remote sites, and large amounts of data could be off-loaded to departmental data servers.

According to Dr. Codd, the term SQL can be confusing. The S, for Structured, and the L, for Language, is undemanding enough, but the Q is a little misleading. Q, of course, stands for "Query," which--if taken literally--would restrict you to asking the database questions. But SQL does much more than ask questions. With SQL you can also create tables, add data, delete data, splice data together, trigger actions based on changes to the database, and store your queries within your program or database. Unfortunately, there is no good substitute for Query. Obviously, Structured Add Modify Delete Join Store Trigger and Query Language (SAMDJSTQL) is a bit cumbersome. In the interest of harmony, we will stay with SQL. However, you now know that its function is bigger than its name. The most commonly used statement in SQL is the SELECT statement (see Day 2, "Introduction to the Query: The SELECT Statement"), which retrieves data from the database and returns the data to the user. The EMPLOYEE table example illustrates a typical example of a SELECT statement situation. In addition to the SELECT statement, SQL provides statements for creating new databases, tables, fields, and indexes, as well as statements for inserting and deleting records. ANSI SQL also recommends a core group of data manipulation functions. As you will find out, many database systems also have tools for ensuring data integrity and enforcing security (see Day 11, "Controlling Transactions") that enable programmers to stop the execution of a group of commands if a certain condition occurs.

The context phenomenon pioneers some of the more popular implementations of SQL, each of which has its own strengths and weaknesses. Where some implementations of SQL have been developed for PC use and easy user interactivity, others have been developed to accommodate very large databases (VLDB). This implemented context introduces selected key features of some implementations. In addition to serving as an SQL reference, this article also contains many practical software development examples. SQL is useful only when it solves your real-world problems, which occur inside your code. We use Microsoft Access, a PC-based DBMS, to illustrate some of the examples in this text. Access is very easy to use. We can use GUI tools or manually enter your SQL statements.

In view of the above discussion, it is obvious that in creating an object oriented programming software, the importance SQL is inevitable. In integrating parent-child relationship, SQL is very important. From SQL, Insert, Update and Delete Command are helpful. In a nut shell, we exercise Oracle7, which represent the larger corporate database world, to demonstrate command-line SQL and database management techniques. These techniques are imperative for the reason that the days of the standalone machine are drawing to an end, as are the days when expressive one database or one in commission system was enough. In command-line, simple stand+[cedilla]one SQL statements are entered into Oracle's SQL*Plus tool. This tool then returns data to the screen for the user to see, or it performs the apposite action on the database. Most examples are directed toward the beginning programmer or first-time user of SQL. We begin with the simplest of SQL statements and advance to the topics of transaction running and stored procedure programming. The Oracle RDBMS is circulated with a full complement of development tools. It comprises a C++ and Visual Basic language library (Oracle Objects for OLE) that can link an application to a Personal Oracle database. It also comes with graphical tools for database, user, and object administration, as well as the SQL*Loader utility, which is used to introduce internally and send abroad data to and from Oracle.